Speaker: Vitalik Buterin
Compiled by: Yuliya, PANews
Hello everyone! Welcome to ETHShanghai 2026. Today I want to discuss with you a rather complex technical topic that is crucial to Ethereum's future—it can enable Ethereum to achieve extremely high scalability while also balancing privacy and decentralization, and all three can be achieved simultaneously. This proposal is very likely to truly change the operating architecture of many components in the blockchain. It can change many things, but unexpectedly, actually landing it in existing Ethereum is not too difficult. This is EIP-8288: Recursive Signature and Aggregation.
Core Pain Point: The Irreconcilability of Security, Privacy, and Scalability
Today I want to focus on several major issues that everyone cares about very much: quantum security, privacy, and scalability. Currently, a big problem is that both quantum security and privacy currently conflict greatly with scalability:
A normal Ethereum transaction currently consumes about 21,000 gas; independently verifying an ECDSA signature (about 65 bytes) takes about 4,000 gas.
If replaced with quantum-safe signatures (regardless of which type of post-quantum signature scheme), gas consumption will be roughly between 100,000 and 300,000 gas, depending on the chosen parameter size (for example, whether it needs to be compatible with blockchain wallet scenarios). But no matter how you choose, the cost will be several times higher than today's transactions—quantum-safe signatures are large and expensive.
The second problem: proofs for privacy protocols are likewise large and expensive. If anyone has used any privacy protocol based on zero-knowledge (ZK) technology, they will know that on Ethereum, such operations cost at least about 350,000 gas. Because many such protocols are not designed very efficiently, sometimes the actual cost can even reach around 1 million gas—this is very expensive. Today a normal transaction may cost only a few cents, while such transactions may cost 20 cents, or even two dollars.
A more serious problem is: if you want both quantum security and privacy, you need to use STARK proofs to replace the previous schemes. However, a STARK proof consumes about 8 million gas, and very likely more. That is to say, if we now let everyone start using "quantum-safe + privacy" transactions, Ethereum's original processing capacity of about 25 TPS will plummet to around 0.25 TPS, almost losing usability.
Another problem is: people may also want to support custom cryptographic schemes. For example, switching from today's elliptic curves to future lattice-based cryptography. The problem is that every time you want to support such new schemes, it increases the size of the protocol itself and requires more precomputation files (large in size, high in cost). And if you do not natively support these schemes in the EVM, or do not have corresponding precomputation files, then verifying any such signature on-chain will consume a very large amount of gas.
In other words, all our goals in security and privacy are actually hindering scalability, at least under the current architecture.
Core Solution: Move Aggregation Computation Forward into the Mempool
So, how do we solve this problem? This is the core mechanism implemented by EIP-8288.
The core idea is: instead of directly putting all these signatures and all these STARK proofs (these huge, structurally complex objects) on-chain, we keep them off-chain and complete aggregation inside the mempool.
Specifically: when a user sends a transaction, there is a group of nodes in the mempool, and these nodes are already working before the transaction is packaged into a block. What these nodes do is called "aggregation"—they replace a large number of signatures and proofs with a single proof, which can verify that all these signatures and proofs really exist and are valid.
So from the user's perspective: the user sends a transaction, and along with the transaction they also send this huge object (signature/proof), but this huge object itself never actually goes on-chain. What actually goes on-chain is only a single STARK proof, used to verify that all signatures and all proofs contained in all user transactions really exist and are valid.
This mechanism is built on top of EIP-8141 (native account abstraction), which will be introduced in the next hard fork. EIP-8141 condenses nearly a decade of research by the Ethereum community in the field of account abstraction. It allows each transaction to directly and precisely explicitly declare its constituent components, signature specifications, and verification algorithms, giving transactions stronger programmability and typed structure.
In EIP-8288, we added a new frame type, which can be understood as a "dependency." There are two kinds of dependencies in total: one corresponds to signatures, and one corresponds to proofs (STARK). Unlike the current model where signatures are directly embedded in the transaction body, under the new mechanism the transaction itself contains only an abstract declaration indicating what type of signature and proof the transaction depends on. When the transaction is broadcast, although the complete data is sent along with it, what is ultimately written into the block is only the micro frame structure carrying the dependencies. The data occupied by each dependency is only 96 bytes, and most are even as low as 65 bytes. The rest of the huge cryptographic entities are absorbed and aggregated inside the mempool, and ultimately appear on the blockchain ledger only in the form of a single proof.
Under this architecture, each node in the mempool continuously listens for a data carrier called an "envelope." A single envelope can encapsulate multiple transactions and their accompanying proofs.
Nodes use a fixed time period as a window, continuously collect all envelope objects observed during that period, perform local aggregation computation, and then broadcast it out. During broadcast, all originally discrete independent proofs have been replaced by one global aggregate proof, which mathematically rigorously covers the correctness of all underlying signatures in this batch.
This shows that before the block packaging nodes formally execute state updates, the Ethereum network has already completed the vast majority of high-intensity verification computation at the mempool stage in the non-consensus layer.
Architectural Essence: "Specialized Sharding"
One way to understand this mechanism is to view it as a kind of specialized sharding. Its idea is: we can pick out those extremely expensive parts of computation involving extremely large amounts of data, and let the entire distributed network process this part of the computation in parallel in a very loose, unstructured way.
This approach is not fragile; on the contrary, it is very robust—any node can take on any portion of this work. What we are doing is essentially splitting each transaction into two parts:
One part explains "what this transaction does, how it interacts with the state, and how it interacts with other transactions";
The other part is the huge, heavy-cost part of this transaction—that is, pure verification work.
By specifically sharding and stripping off the verification load, the data payload that the main chain consensus layer ultimately requires all network verification nodes to jointly bear is strictly compressed into an extremely small range of 100 to 300 KB per block. This overhead is only about twice the current Ethereum block data volume, and as the network's overall throughput expands linearly, the proportion of this constant overhead in the total network load will continue to be diluted.
Essentially, what we are doing is: moving work away from validators, and even away from the nodes that package blocks, pushing this part of the work to those off-chain nodes located between "the user sends a transaction" and "the node packaging the block actually includes the transaction in the block."
What Does This Mean for Ethereum?
From a technical perspective, this means Ethereum is hyper-scaling a specific class of computation. I think this is also a trend we will see more and more as Ethereum continues to develop.
Ethereum, born ten years ago, focused on fully general computation, but also completely lacked scalability. So what we are doing now is splitting computation into different types, and then specifically making those types of computation that are "naturally more suitable for scaling" extremely scalable—we are building these more specialized "small tools" to accomplish this.
At the same time, we are also making those computations that must be handled in a less efficient way smaller and easier to handle. EIP-8288 is precisely the hyper-scaling of two types of objects: "signature verification" and "zero-knowledge proof verification."
Another interesting point is this: I know many people have long been curious about when Ethereum will move to RISC-V—because compared with the current approach, RISC-V or some other more modern instruction set is far more efficient, and also much simpler. And EIP-8288 is very likely to become the first scenario on Ethereum that truly introduces RISC-V (or a similar instruction set). The reason is that EIP-8288 allows users to submit proofs, and when users submit proofs, they need to use some language to express the claims they are verifying—RISC-V is exactly that language.
That is to say, verification logic expressed in RISC-V only needs to be executed as a single physical computation locally on the user's client: the user generates the corresponding proof (in privacy scenarios, this is a ZK-STARK), and then immediately pushes it into the mempool; the first relay node that follows will immediately recursively compress it together with hundreds or thousands of similar proofs across the network into a single entity.
This is also equivalent to dividing the entire computation into two major categories:
One category is "dependencies"—that is, the parts that must be guaranteed correct in order for the transaction to be valid;
The other category is "business logic"—that is, what the transaction itself actually does.
Business logic can therefore become lighter and cleaner, which also means that the part of block-building logic that depends on transaction ordering will also become simpler. And the "dependencies" part can be processed in parallel at an extremely large scale, with almost no need for any major changes to the development experience of Ethereum developers.
The Practical Value for Developers, Users, and Layer 2
For anyone building applications on-chain, the core significance of all this is: the most expensive operations today will become much cheaper.
The execution overhead of quantum-safe transactions will be compressed to a nearly negligible low level;
Privacy-preserving applications built on zk-SNARK/STARK will escape the constraints of high Gas fees, become widespread at an affordable cost, and natively have quantum resistance.
Beyond privacy scenarios, the application efficiency of zk-SNARK in scaling (especially Layer 2) will see a qualitative leap. At present, many ZK-Rollups, in order to amortize the high Gas cost of publishing state proofs to the mainnet, are often forced to lengthen the submission cycle, settling in batches at frequencies of ten minutes or even an hour. This severely constrains final confirmation speed during periods of low network transaction activity.
At present, many ZK-Rollups, in order to amortize the high Gas cost of publishing state proofs to the mainnet, are often forced to lengthen the submission cycle, settling in batches at frequencies of ten minutes or even an hour. This severely constrains final confirmation speed during periods of low network transaction activity.
The Endgame Evolution: Pushing Computation Completely to the Edge
Finally, if there is other computation you want to do but it is too expensive to execute inside the EVM, I hope we can truly begin to shift direction—no longer having the Ethereum protocol itself directly bear all the computation everyone wants to do, but instead encouraging users to complete this part of the computation locally on their clients, and then publish a proof, so that this proof is verified on Ethereum.
Essentially, this is scaling Ethereum by moving computation out of the "center" of the chain and pushing it to the "edge." The result is: the things that are most expensive on Ethereum today (various forms of security, various forms of privacy, and various forms of compatibility with external applications) are not done by people today because they are too expensive, and in the future they will all become much cheaper and truly usable by everyone.
I hope this is only the first step in transforming Ethereum from the architecture it has almost used since its birth into a completely different and even more powerful new architecture—a new architecture that truly combines two things: one is the very simple early blockchain idea from Satoshi Nakamoto; the other is the extremely powerful and extremely modern cryptographic technology we have continuously accumulated since then.
Ecosystem Participation and Implementation Progress
At present, early exploration and engineering validation around this approach are being carried out intensively, and the technical community can already participate in building from multiple entry points:
Network-level simulation models: early simulation tools for mempool topology and aggregation propagation mechanisms have been opened;
Testnet operation: the EIP-8141 testnet supporting the frame transaction form has been put into testing;
Algorithm optimization competitions: special algorithm competitions for the developer community are being advanced, focusing on efficient implementation of the underlying proof system;
Code implementation and verification: the underlying prototype codebase has taken shape, for ecosystem developers to carry out independent client implementations and formal verification.
A large number of underlying technical pieces are being rapidly filled in. Developers are welcome to participate deeply in this technical process and help this revolutionary architecture become a reality standard on the Ethereum mainnet as soon as possible.
