Ethereum co-founder Vitalik Buterin and Thomas Coratger have proposed consolidating cryptographic checks for transactions in blocks that need them, but a key verification mode remains unusable under the draft’s current rules.
Their Ethereum Improvement Proposal, EIP-8288, would have transactions list signature or proof dependencies in 96-byte entries. Users would supply the underlying proofs, while nodes handling pending transactions and block builders would combine them. A block containing dependencies would carry one recursive STARK checking their validity; a block without dependencies would have an empty proof field.
The authors say checking signatures separately can be costly. They estimate that proposed hash-based signatures would each require about two to three kilobytes of data and 150,000 to 200,000 gas to verify. The draft also says STARK proofs can exceed 128 kilobytes and cost millions of gas to verify individually.
For a leanSPHINCS dependency, EIP-8288 proposes a 3,000-gas verification charge. It would add 30,000 gas to the transaction’s intrinsic gas as that dependency’s share of the recursive STARK field. That totals 33,000 gas for one such dependency before other transaction charges.
The authors aim to lower the cost of including advanced signatures and privacy proofs in blocks. Under their design, users would produce proofs, nodes and builders would aggregate them, and transaction payers would cover the proposed gas charges. In a September essay, Buterin argued for distributing verifiable work among participants before it reaches a block.
Buterin’s broader argument suggests the design could reduce Ethereum’s reliance on precompiles, protocol-provided shortcuts for specific cryptographic calculations. The proposal does not establish that outcome.
The general leanSTARK route remains incomplete. Under the draft’s current validity rule, any frame using LEANSTARK_SCHEME is invalid until get_deps_hash is defined. The aggregation verification key and reference implementation are also unfinished. EIP-8288 depends on EIP-8141, a separate draft for frame transactions. Both remain drafts; EIP-8288 requires a network upgrade to take effect and lists no activation date.
