Ethereum Draft Proposes Shared Proof Verification and Split Payments
An Ethereum draft by contributor Marchhill proposes sharing cryptographic proof verification across batches while keeping each member transaction’s signature, nonce and receipt separate. Sponsors would pay for batch leaves that are retained, while members would pay for their own claims. A builder could include a valid subset without asking members to sign again.
- Shared verification could reduce repeated proof-checking work, but that benefit has not been demonstrated.
- The draft lists provisional charges and resource limits, not a final fee schedule.
- Payment accounting, performance and an ambiguity in the LEANSTARK specification still need attention.
A proposal, not a scheduled upgrade
Marchhill’s submission is pull request #12664, which supersedes pull request #12654. In the revision discussed here, it remains a draft with no assigned EIP number, dedicated discussion thread or mainnet activation date.
That distinction matters. The draft’s charges and limits are proposals under development, not Ethereum rules or a promise that users will pay less.
How batch proof verification could work
The draft builds on the dependency-verification approach in EIP-8288. Transactions can declare cryptographic dependencies, meaning claims that need to be checked. A recursive STARK can then attest to those dependencies collectively at the block level.
A STARK is a cryptographic proof that lets a verifier check a specified computation or claim without re-running the computation from scratch. Verification still takes work, and someone must generate the proof. Any efficiency gains would come from sharing or combining verification, not making cryptographic work disappear.
Marchhill’s draft would enable the LEANSTARK_SCHEME, reserved in EIP-8288 for use in dependency frames. It also proposes replacing the base draft’s bare data-hash statement with a stable digest representing a list of claims.
There’s a specification question to resolve. The supplied EIP-8288 text says LEANSTARK is reserved until get_deps_hash is defined for it, while other passages describe verifying LEANSTARK dependencies. That inconsistency does not, by itself, establish what the current implementation supports. The relevant specification language needs clarification.
Who pays, and what a leaf means
The draft describes a batch leaf as a unit the sponsor pays for if it is retained in the block. Member transactions separately pay according to their own submitted claims. In practice, the proposed arrangement splits costs between sponsoring a retained part of the batch and submitting individual claims.
The draft does not explain the precise accounting well enough to treat the charges as a settled fee formula. It also says a builder could include any valid subset without requiring members to sign again. Transactions would keep their own signatures, nonces and receipts. A nonce marks a transaction’s place in an account’s sequence, while a receipt records its execution result.
The proposal checks payment matching during processing, with recursive proofs authenticating the sources used in the batch. It directs discounted-claim and sponsor payments to block builders. That identifies the intended recipient, but does not explain the full payment path or mean builders and block proposers are interchangeable.
Ordinary proofs covering a single statement would remain eligible for the public mempool, where transactions wait for possible inclusion in a block. Discounted claims and sponsor payments, the draft says, would instead go directly to builders.
Provisional charges and limits
The revision lists five provisional charges: 15, 400 gas for native verification; 572, 000 gas for ordinary generic verification; 5, 100 gas for the intrinsic proof share; 675, 000 gas for a leaf payment; and 4, 200 gas for a batch claim.
The labels show what each charge relates to, but the figures are not a complete or final accounting schedule. The draft says they need joint calibration. These numbers alone do not show what users might save or how total costs compare once proof generation, aggregation, transaction processing and builder incentives are included.
The proposed block limit is 16, 384 distinct dependencies, separate from the gas limit. It caps the number of different dependencies a block can carry. A corresponding inclusion-list fit rule is intended to limit what can fit on such a list. A leaf could contain up to 256 claims, and a proof step could have up to 16 inputs. Those last two figures apply per leaf and per proof step, not across the whole block.
Performance and builder risk remain open
Before activation, the draft calls for measurements of the complete processing schedule, late sponsor repair and per-proof charges that fit within transaction gas limits, including required overhead. “Late sponsor repair” is named as a test case, but the draft details summarized here do not explain exactly how it works.
The benchmark material separates measurements on individual nodes and a single machine from figures modeled for 16 workers. A modeled result is not the same as demonstrated performance across Ethereum’s network. The available figures do not show that the full design is ready for deployment.
The draft also flags a risk for builders: if sponsorship is invalidated, they could lose the work already spent preparing the batch. Inclusion gas would not reimburse that work. The potential loss has not been quantified, so it remains a design concern rather than a measured cost.
The proposal adds no networking messages. Concrete commitment construction and encodings remain in the pinned proof-system specification, outside the scope of this payment-and-verification proposal.
Questions and answers
-
Has Ethereum adopted the proposal?
No. The submission remains a draft, with no EIP number or activation date in the revision discussed here.
-
Who pays for a retained batch leaf?
The sponsor pays for each retained leaf, while member transactions pay for their own submitted claims. The final accounting still needs clarification.
-
Would members need to sign again if only part of a batch is included?
Under the proposed mechanism, no. A builder could include a valid subset without requiring members to sign again.
-
Are the listed gas charges final?
No. They are provisional figures that need calibration, not a confirmed fee schedule or proof of user savings.
-
What must happen before activation?
The draft calls for performance testing of the full processing schedule, late sponsor repair and per-proof charges that fit within transaction gas limits, including overhead.
Shared verification could reduce duplicate proof-checking, but Marchhill’s proposal has yet to show it will lower total costs or meet its performance requirements. Its case depends on measured results, clearer payment accounting and a specification implementers can rely on.
