2 min read
Add as a preferred source on Google

Ethereum Draft Would Aggregate Transaction Proofs Across Its Mempool

The current text makes frames using the STARK proof dependency type invalid until a dependency hash is defined.

Mentioned assets
Small frosted cubes sit inside a single clear block / TokenPost.ai
Small frosted cubes sit inside a single clear block / TokenPost.ai

EIP-8288 proposes using Ethereum’s mempool to aggregate transaction signatures and proofs before block inclusion, targeting data and verification costs for post-quantum signatures while leaving STARK-based privacy uses for future work.

Clients would submit signatures and proofs with transactions. Mempool nodes would combine the material in successive rounds, reducing the number of separate proofs carried forward. The proposal treats the network’s transaction pool as shared capacity for generating and aggregating proofs.

A block builder would combine proofs for the transactions selected for a block into one block-level proof. Validators could check that proof to verify thousands of signatures and proofs, rather than examining each item separately. The approach is intended to distribute processing among nodes without requiring block builders to handle every proof from scratch.

EIP-8288 estimates that hash-based quantum-resistant signatures can take two to three kilobytes of data and 150,000 to 200,000 gas to verify directly. Those estimates apply to the signature type described in the proposal, not to every quantum-resistant signature. The EIP also says STARK proofs can exceed 128 kilobytes and cost many millions of gas to verify directly.

ZeroDev founder Derek Chiang’s visualization describes adding nodes as a way to increase signature and proof processing capacity while keeping each node’s proof-transfer bandwidth steady. Chiang projects that the design could eventually support tens of thousands of post-quantum and privacy transactions per second. That is a projection; privacy transactions remain a proposed future use case, not a capability fully specified in the current draft.

The current EIP permits its signature dependency type, but frames using the STARK proof dependency type are invalid until that type’s dependency hash is defined. The draft also leaves two protocol constants and a reference implementation to be determined. Putting the proposal into use would require an Ethereum network upgrade.

Simon Yoon

Reporter

Simon Yoon reports on blockchain technology for TokenPost. Send corrections or tips to info@tokenpost.com.

Loading…