Vitalik Buterin used his ETHShanghai 2026 presentation to explain EIP-8288, a proposal called Recursive Signature and Aggregation. He described it as a way for Ethereum to pursue very high scalability without dropping privacy or decentralization, and said the changes needed to fit it into Ethereum may be less difficult than many would expect.
Why the current model runs into limits
Buterin focused on three issues: quantum safety, privacy, and scalability. In his account, both quantum-safe cryptography and privacy systems clash with Ethereum’s current cost structure.
A standard Ethereum transaction today uses about 21,000 gas, he said. Verifying a single ECDSA signature, roughly 65 bytes in size, costs about 4,000 gas.
Quantum-safe signatures are far more expensive under the current setup. Depending on parameter choices and whether the design needs to work with blockchain wallet use cases, Buterin said verification would land around 100,000 to 300,000 gas. His point was simple: quantum-safe signatures are large and costly.
Privacy protocols have the same problem. He said operations in privacy systems built on zero-knowledge technology cost at least around 350,000 gas on Ethereum, and in less efficient designs the figure can reach roughly 1 million gas. A normal transaction may cost only a few cents, while these transactions can cost $0.20 or even $2.
The conflict becomes sharper when both goals are combined. If users want quantum safety and privacy at the same time, Buterin said STARK proofs are needed in place of the earlier approaches. A single STARK proof costs around 8 million gas, possibly more. If every user moved to transactions with both quantum safety and privacy, Ethereum’s throughput of about 25 TPS would fall to roughly 0.25 TPS, by his estimate.
He also pointed to another constraint: support for custom cryptography. If the ecosystem wants to move from elliptic curves to lattice-based cryptography or other schemes, native support means more precompiles and a larger protocol footprint. Without native support, on-chain verification becomes extremely gas-intensive. In his framing, Ethereum’s security and privacy goals are blocking scalability under the current architecture.
The core idea: aggregate before transactions reach the chain
EIP-8288 tries to solve that by moving aggregation into the mempool. Instead of putting all signatures and STARK proofs on-chain, the proposal keeps those large and complex objects off-chain and lets mempool nodes aggregate them before block inclusion.
From the user’s perspective, a transaction is still sent together with the large signature or proof object. That object, though, never needs to be written into the blockchain. What reaches the chain is a single STARK proof that attests that all signatures and proofs tied to the included transactions exist and are valid.
Buterin said the mechanism depends on EIP-8141, the native account abstraction proposal expected in the next hard fork. He described EIP-8141 as the product of nearly a decade of Ethereum research on account abstraction, allowing each transaction to explicitly declare its components, signature rules, and verification algorithm.
Under EIP-8288, Ethereum would add a new frame type that acts as a dependency. There are two dependency classes: one for signatures and one for proofs, specifically STARKs. Rather than embedding signatures directly in the transaction body, the transaction would carry an abstract declaration of what kind of signature and proof it depends on. Full data would still travel during broadcast, but only a tiny frame structure carrying the dependency would be written into the block.
Each dependency uses only 96 bytes of data, he said, and many are as small as 65 bytes. The rest of the heavy cryptographic material is absorbed and aggregated inside the mempool, then represented on-chain by a single proof.
In this design, mempool nodes continuously watch a data container Buterin called an envelope. One envelope can package multiple transactions and their associated proofs. Nodes collect all envelopes seen during a fixed time window, run local aggregation, and broadcast the result. By the time that broadcast happens, the separate proofs have been replaced by one global aggregated proof that mathematically covers the correctness of all underlying signatures in the batch.
That means most of the expensive verification work is completed in the mempool, outside the consensus layer, before a block builder performs the state transition.
A form of specialized sharding
Buterin said one way to understand the architecture is to treat it as specialized sharding. The network takes the most expensive and data-heavy part of computation and processes it in parallel in a loose, unstructured way.
He split each transaction into two parts. One part describes what the transaction does, how it interacts with state, and how it interacts with other transactions. The other part is the large and expensive verification workload. By isolating and sharding that verification burden, the data load that the consensus layer must carry can be compressed to around 100 KB to 300 KB per block.
He said that overhead is only about twice the size of current Ethereum block data, and as network throughput scales linearly, the share of that constant overhead in the total load would keep shrinking.
In practical terms, the work is moved away from validators and even away from the nodes that build blocks. It is pushed to off-chain nodes that sit between the user sending a transaction and the builder deciding to include it.
What it changes for Ethereum’s computation model
Buterin argued that Ethereum is moving toward hyper-scaling for specific categories of computation. Ethereum, as launched a decade ago, was built around fully general computation but not around scalability. The new direction is to split computation into types, then build highly scalable tools for the categories that are naturally easier to scale.
In that framework, the computations that must remain less efficient are made smaller and easier to handle. EIP-8288 is aimed squarely at signature verification and zero-knowledge proof verification.
He also said the proposal could become Ethereum’s first real use case for RISC-V or a similar instruction set. Many people have asked when Ethereum might move in that direction, he noted, because RISC-V and other modern instruction sets are simpler and more efficient than the current approach. Under EIP-8288, users can submit proofs, and those proofs need a language to express the claims being verified. In his telling, RISC-V can serve as that language.
The verification logic expressed in RISC-V would only need to be executed once on the user’s local client. The user generates the proof — in privacy use cases, a ZK-STARK — and pushes it into the mempool. The first relay node that receives it can then recursively compress it together with hundreds or thousands of similar proofs from across the network into a single object.
That effectively divides computation into two broad classes: dependencies, which must be correct for the transaction to be valid, and business logic, which is the actual action the transaction performs. Business logic becomes lighter and cleaner, and the block-building logic that depends on transaction ordering becomes simpler. Dependencies, by contrast, can be processed in parallel at very large scale with little disruption to the developer experience, according to Buterin.
Implications for developers, users, and Layer 2
For application builders, Buterin said the main result is that some of the most expensive operations on Ethereum today would become much cheaper.
- The execution cost of quantum-safe transactions would be pushed down to nearly negligible levels.
- Privacy applications built with zk-SNARKs or STARKs would no longer be constrained by high gas costs and would come with native quantum resistance.
- zk-SNARK-based scaling, especially in Layer 2 systems, would become much more efficient.
He pointed to current ZK-Rollup practice as an example. Many rollups stretch out their submission intervals in order to amortize the high gas cost of posting state proofs to Ethereum mainnet, often settling in batches every 10 minutes or even every hour. During periods of low transaction activity, that slows final confirmation. EIP-8288 is meant to reduce that cost pressure.
Pushing computation to the edge
Near the end of the talk, Buterin widened the frame. If some computation is too expensive to run inside the EVM, he said, Ethereum should stop trying to make the protocol itself execute everything users may want. Instead, users can do the computation locally on the client, publish a proof, and have that proof verified on Ethereum.
He described this as moving computation away from the center of the chain and out toward the edge. In that model, the capabilities that are most expensive on Ethereum today — different forms of security, different forms of privacy, and compatibility with external applications — could become much cheaper and more broadly usable.
Buterin said he hopes this is only a first step in changing Ethereum from the architecture it has used almost since birth into a very different and more powerful one, combining the early, simple blockchain ideas associated with Satoshi Nakamoto and the much more advanced cryptographic techniques developed since then.
Early participation and engineering progress
Buterin said early exploration and engineering work around the proposal is already under way, and the technical community can participate from several angles.
- Network-level simulation models for mempool topology and aggregation propagation are already open.
- An EIP-8141 testnet that supports frame-style transactions is already in testing.
- An algorithm competition for developers is under way, focused on efficient implementation of the underlying proof system.
- A prototype codebase has taken shape and is available for independent client implementations and formal verification.
He said many of the low-level building blocks are being assembled quickly and invited developers to help push the architecture toward becoming a practical standard on Ethereum mainnet.