Ethereum co-founder Vitalik Buterin has outlined EIP-8288, a proposal that could significantly change how the network handles cryptographic proofs, privacy transactions and post-quantum signatures. Buterin wants the recursive STARK mempool design considered for Ethereum’s I-star upgrade, which he describes as a potential next step after Frames.
The proposal moves computationally intensive cryptographic work away from Ethereum’s core execution path and into the mempool. The goal is to let nodes aggregate that work into recursive STARK proofs before transactions reach a block, potentially reducing the amount of computation and data that Ethereum must process directly. (cryptotimes.io)
EIP-8288 Moves Heavy Cryptography Into the Mempool
One of the biggest potential benefits is cheaper post-quantum security. Buterin points to quantum-safe signatures such as SPHINCS- as an example, noting that signature data can be around 3 kilobytes and does not necessarily need to be placed directly onchain under the proposed architecture.
The same approach could be applied to privacy protocols. Buterin estimates that highly optimized private transactions can currently require roughly 300,000 gas, while quantum-safe versions could reach around 10 million gas. He argues that recursive STARK aggregation could bring the latter down to the low tens of thousands of gas. These figures are projections from the proposal, not measured costs from a deployed Ethereum implementation. (odaily.news)
The architecture is based around what Buterin calls “dependency frames.” Instead of putting every signature or proof directly into the transaction’s main execution path, a transaction can reference statements that need to be proven, such as a signature matching a particular public key.
Related: Ethereum Co-Founder Says AI Debate Is Missing the Biggest Question
Mempool nodes would then collect these dependencies and recursively prove them together. Buterin describes a process in which nodes periodically gather new transaction envelopes, remove expired transactions, generate a recursive STARK covering the dependencies and broadcast a new envelope containing that proof.
This could create a significant difference in how Ethereum handles cryptographic workloads. Rather than forcing every transaction to carry and individually verify large pieces of cryptographic data, the network would verify a much smaller aggregated representation of the underlying work.
Buterin estimates that each node could send one STARK of roughly 100 to 300 kilobytes per processing interval, while transactions would continue to propagate through the network as they do today. At the block level, the proposed onchain overhead would consist of one STARK plus 96 bytes for each statement being proven. (bankless.com)
Privacy and New Cryptography Could Become Cheaper
Another major use case is private account abstraction. The proposal could allow account ownership logic to remain private while enabling users to change ownership across multiple onchain positions without revealing which specific objects are being transferred or modified.
That could matter for users managing complicated DeFi positions, privacy notes and other assets. Instead of exposing every ownership change onchain, the transaction could prove that the required conditions were satisfied without revealing all of the underlying information.
EIP-8288 could also make Ethereum more flexible when new cryptographic standards emerge. Buterin argues that developers could wrap new signature or proof systems inside STARKs rather than waiting for Ethereum to add native EVM support for every new cryptographic algorithm.
That could become increasingly important as the industry prepares for potential quantum computing threats. Algorithms such as ML-DSA and other post-quantum schemes generally have different performance and data characteristics from the cryptography used throughout today’s blockchain infrastructure.
Related: Ethereum Price Eyes $2,700 as 116,000 ETH Leave Exchanges
The proposal also has implications for Ethereum’s developer architecture. If cryptographic verification is moved into a standardized proof environment, developers would interact with dependency statements rather than writing every signature or proof verification directly into the main execution logic.
There is, however, a major design decision still to be made. Ethereum would need to agree on a common instruction set for the recursive STARK environment. Buterin identified RISC-V as the leading candidate, which would effectively give Ethereum a canonical execution language for this class of cryptographic computation. (bankless.com)
EIP-8288 is not an activated Ethereum upgrade, and its proposed cost reductions should not be interpreted as current network performance. The idea still requires engineering, testing, security review and agreement within Ethereum’s development process. The EIP system itself distinguishes between proposal stages, meaning publication does not automatically mean a change will reach the network. (eips.ethereum.org)
Still, the direction is significant. Ethereum would be separating ordinary transaction logic from increasingly complex cryptographic computation and using recursive proofs to compress that work before it reaches the blockchain’s critical path. If the architecture works as intended, it could make quantum-safe signatures, privacy applications and future cryptographic systems substantially cheaper to use.
For Ethereum, the bigger question is whether this approach can become a practical foundation for the network’s next generation of cryptography. Vitalik’s proposal suggests that recursive STARKs could eventually turn Ethereum’s mempool into more than a waiting room for transactions. It could become a distributed proving layer that prepares complex computation before the blockchain records its final result.
About The Author
