Ethereum draft proposes shared payments for batch proofs

Ethereum contributor Marchhill has submitted a draft proposal to enable generic proof verification and sponsored batch processing, allowing multiple transaction claims to share a proof while retaining separate payments and signatures.

Marchhill’s proposal, submitted to Ethereum’s EIP repository on Nov. 13, would activate the LEANSTARK_SCHEME reserved in EIP-8288 and introduce rules for sponsored batches. The submission remains under development and has not been adopted as an Ethereum network upgrade.

The draft brings generic verification, proof identity, resource limits, dependency summaries and batch payments into one proposal. It supersedes an earlier submission, pull request #12654, while an EIP number and a dedicated discussion thread remain to be assigned.

Ethereum batch proofs would separate sponsor and member payments

At the center of the draft is a payment arrangement in which a sponsor covers each retained batch leaf, an individual proof component containing several claims. Member transactions would pay according to their own submitted claims.

A builder could include any valid subset without asking members to sign again. Someone whose transaction was ready for inclusion would therefore not need a fresh signature solely because other members of the original group were left out, according to the proposed mechanism.

The draft would preserve individual transaction nonces and receipts. A nonce identifies a transaction’s place in an account’s transaction sequence, while a receipt records its execution result. Sharing proof work would leave those records attached to the separate transactions.

Payment matching would be checked during finalization, with recursive proofs authenticating the sources used in the batch. The submission distinguishes the work of establishing that claims are valid from the work of confirming that the necessary payments accompany them.

Discounted claims and sponsor payments would go directly to block builders. Ordinary proofs covering a single statement would remain eligible for the public mempool, where transactions wait to be included in blocks.

Generic verification builds on EIP-8288

The underlying EIP-8288, authored by Vitalik Buterin and Thomas Coratger, proposes aggregating cryptographic signatures and proofs outside Ethereum’s main execution process. Transactions would identify the statements they need verified, and a recursive STARK would establish their validity at block level.

STARKs are cryptographic proofs that demonstrate a computation was performed correctly without requiring every verifier to repeat it. Recursion allows one proof to verify other proofs, combining their results.

EIP-8288 currently reserves the generic leanSTARK scheme rather than permitting its use in dependency frames. Marchhill’s submission proposes enabling that path and replacing the base draft’s bare data-hash statement with a stable digest representing a list of claims.

The design follows earlier discussion of cryptographic verification, including Buterin’s support for handling complex cryptography through aggregated proofs. His comments concerned the underlying architecture; Marchhill’s draft sets out a specific verification and payment arrangement.

Proposed charges remain subject to calibration

The supplied revision lists provisional charges of 15,400 gas for native verification and 572,000 gas for ordinary generic verification. It assigns 5,100 gas to the intrinsic proof share, 675,000 gas to a leaf payment and 4,200 gas to a batch claim.

Leaf payments carry a separate charge because binding payments add fixed work beyond ordinary verification, the draft explains. Claims and payments would incur no additional intrinsic proof share. The figures require joint calibration, so they do not establish a final fee schedule or a confirmed saving for users.

Resource controls include a provisional block limit of 16,384 distinct dependencies, applied independently of gas, alongside a corresponding inclusion-list fit rule. A leaf could contain up to 256 claims, while a proof step could have 16 inputs. Neither figure is a block-wide limit.

Activation would require full-block performance measurements

Before activation, the proposal requires measurements covering the complete processing schedule, late sponsor repair, and per-proof charges that fit within transaction gas limits, including required overhead.

Its benchmark material distinguishes measured individual-node and single-machine block results from modeled 16-worker figures. The draft requires the evidence and remaining performance gaps to be recorded in its benchmark material.

An invalidated sponsorship could waste a builder’s work, and the submission says inclusion gas would not reimburse that work. Concrete commitment construction and encodings remain in the pinned proof-system specification. The proposal introduces no new networking messages.