Speaker: Vitalik Buterin

Translation: Yuliya, PANews

Hello everyone! Welcome to ETHShanghai 2026. Today, I want to discuss a rather complex but crucial technical topic for the future of Ethereum — a topic that allows Ethereum to achieve extremely high scalability while also balancing privacy and decentralization, and all three can be achieved simultaneously. This proposal is likely to truly change the operational architecture of many components within blockchain. It can change a lot of things, but surprisingly, implementing it into the existing Ethereum is not too difficult. This is EIP-8288: Recursive Signature and Aggregation.

Core Pain Points: The Incompatibility of Security, Privacy, and Scalability

Today, I want to focus on several major issues that everyone is very concerned about: quantum safety, privacy, and scalability. Currently, a large problem is that quantum safety and privacy conflict significantly with scalability:

• A typical Ethereum transaction currently consumes about 21,000 gas; independently verifying an ECDSA signature (about 65 bytes) costs around 4,000 gas.

• If we switch to quantum-safe signatures (regardless of the type of post-quantum signature schemes), the gas consumption would likely range between 100,000 to 300,000 gas, depending on the chosen parameter sizes (for example, whether it needs to be compatible with blockchain wallets). But no matter what you choose, the costs will be several times higher than today's transactions — quantum-safe signatures are both large and expensive.

The second issue: the proof of privacy protocols is also large and expensive. If anyone has used any zero-knowledge (ZK) technology-based privacy protocols, they know that on Ethereum, this kind of operation costs at least about 350,000 gas. Since many of these protocols are not designed very efficiently, sometimes the actual costs can even reach around 1,000,000 gas — this is very expensive. A typical transaction today might only cost a few cents, while this type of transaction could cost up to 20 cents or even two dollars.

The more serious problem is: if you want both quantum safety and privacy, you will need to use STARK proofs to replace the previous solutions. However, a STARK proof consumes about 8 million gas, and likely even more. In other words, if we immediately let everyone start using “quantum safe + privacy” transactions, Ethereum's original processing capacity of about 25 TPS would plummet to around 0.25 TPS, almost losing usability.

Another issue is: people may also wish 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 this type of new scheme, it increases the protocol's own size, requiring more pre-computed files (which are large and costly). If you do not natively support these schemes in the EVM, or if there are no corresponding pre-computed files, then verifying any such signature on-chain will consume a massive amount of gas.

In other words, all our goals in security and privacy are actually hindering scalability, at least in the current architecture.

Core Solution: Pre-aggregating Computation in the Mempool

So, how do we solve this problem? This is the core mechanism implemented by EIP-8288.

The core idea is: we do not directly place all these signatures and all these STARK proofs (which are large and complex objects) directly on-chain. Instead, we keep them off-chain, completing the aggregation inside the mempool.

Specifically: when a user submits a transaction, there is a group of nodes in the mempool that begin working before the transaction is packed into a block. What these nodes do is called "aggregation" — they replace a large number of signatures and proofs with a single proof that can verify that all these signatures and proofs indeed exist and are valid.

So from the user's perspective: the user submits a transaction, and along with the transaction, there is this large object (signature/proof), but this large object itself will never actually be put on-chain. What goes on-chain is only a single STARK proof that verifies that all signatures and all proofs in the user transactions indeed 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 area of account abstraction, allowing each transaction to directly and explicitly declare its components, signature specifications, and verification algorithms, imparting greater programmability and structured typing to transactions.

In EIP-8288, we added a new frame type, which can be understood as "dependencies," consisting of two types of dependencies: one for signatures and one for proofs (STARK). Unlike the existing model where signatures are directly embedded in the transaction body, the new mechanism allows the transaction itself to only contain an abstract declaration indicating what type of signatures and proofs the transaction depends on. When the transaction is broadcast, although the complete data is sent alongside, the only thing written into the block is a micro-frame structure carrying the dependencies. Each dependency's data occupies only 96 bytes, with most even as low as 65 bytes. The rest of the large cryptographic entities are absorbed and aggregated within the mempool, ultimately presented as a single proof in the blockchain ledger.

In this architecture, the nodes in the mempool continuously listen for a data carrier called "envelope." A single envelope can encapsulate multiple transactions and their accompanying proofs.

Nodes, within fixed time periods, continuously collect all observed envelope objects during that period, perform local aggregation computations, and then broadcast. During the broadcast, all originally discrete independent proofs are replaced with a globally aggregated proof that rigorously covers the correctness of all underlying signatures in this batch.

This indicates that before the block packaging node officially executes state updates, the Ethereum network has already completed most of the high-intensity verification computations during the non-consensus layer in the mempool phase.

Architectural Essence: "Specialized Sharding"

One way to understand this mechanism is to view it as a form of specialized sharding. The idea is: we can extract those extremely expensive parts of computation, which involve massive data amounts, allowing the entire distributed network to parallel process this part of the computation in a very loose, unstructured way.

This method is not fragile; instead, it is very robust — any node can undertake any part 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 that large, heavy portion of the transaction — the pure verification work.

By implementing sharding peeling specifically for verification loads, the data load that needs to be jointly borne by all verification nodes on the main chain consensus layer is strictly compressed within an extremely small range of 100 to 300KB per block. This cost is only about twice that of the current Ethereum block data size, and as the network's overall throughput linearly expands, this constant cost will be continuously diluted in the total load of the entire network.

Essentially, we are moving work off validators, even from the nodes packaging blocks, and pushing that work to those nodes located between "the user submits a transaction" and "the nodes packaging blocks actually include the transaction in blocks."

What This Means for Ethereum?

From a technical perspective, this means that Ethereum is hyper-scaling a certain class of specific computations. I believe this is also a trend that we will increasingly see as Ethereum continues to evolve.

Ethereum, born ten years ago, aimed for completely general computation but lacked scalability entirely. So what we are doing now is breaking computation into different types, and specifically making those types that are “naturally more scalable” extremely scalable — we are building these more specialized "tools" to accomplish this.

At the same time, we are also making those computations that must be done in a less efficient manner smaller and easier to handle. EIP-8288 is precisely a hyper-scaling of the two types of objects: "signature verification" and "zero-knowledge proof verification."

Another interesting aspect is: I know many people have been curious about when Ethereum will switch to RISC-V — because compared to the current solutions, RISC-V or some other more modern instruction sets are much more efficient and simpler. And EIP-8288 is likely to become the first scenario on Ethereum to truly introduce RISC-V (or similar instruction sets). The reason is that EIP-8288 allows users to submit proofs, and when users submit proofs, they need to express the statements they are verifying using a language — and RISC-V is that language.

In other words, the verification logic expressed in RISC-V only needs to execute a single physical computation locally on the user client: the user generates the corresponding proof (which would be ZK-STARK in privacy scenarios), and then pushes it into the mempool; the first relay node that follows will compress it with hundreds or thousands of similar proofs across the entire network recursively into a single entity.

This also effectively divides the entire computation into two broad categories:

• One category is "dependencies" — those parts necessary to ensure the transaction is valid and correct;

• The other category is "business logic" — that is what the transaction actually does.

Business logic can thus become lighter and cleaner, which also means that the part of the block construction logic that depends on transaction order will become simpler. The "dependencies" part can be processed in massive parallelism, with minimal impact on the Ethereum developers' development experience.

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 costs of quantum-safe transactions will be compressed to nearly negligible levels;

• Privacy protection applications built on zk-SNARK/STARK will break free from high gas fees, becoming popular at civilian costs, and will be natively quantum resistant.

Aside from privacy scenarios, the application efficiency of zk-SNARK in scaling (especially Layer 2) will see a qualitative leap. Currently, many ZK-Rollups are often forced to extend submission cycles, settling in batches at intervals of ten minutes or even an hour to dilute the high gas costs of publishing state proofs to the mainnet. This severely restricts the final confirmation speed during network transaction troughs.

Currently, many ZK-Rollups are often forced to extend submission cycles, settling in batches at intervals of ten minutes or even an hour to dilute the high gas costs of publishing state proofs to the mainnet. This severely restricts the final confirmation speed during network transaction troughs.

Endgame Evolution: Pushing Computation to the Edge

Finally, if there are other computations you wish to conduct that are too costly to execute within the EVM, I hope we can truly begin to shift directions — no longer letting the Ethereum protocol itself bear all computations everyone wants to perform, but encouraging users to complete this part of computation locally on their client and then publish a proof for that proof to be verified on Ethereum.

Essentially, this achieves Ethereum's scalability by moving computation from the "center" of the chain to the "edge." The result is that those things today considered the most expensive on Ethereum (various forms of security, various forms of privacy, and compatibility with external applications) will, because they are too expensive to handle now, become much cheaper in the future, truly usable by everyone.

I hope this is just the first step in transforming Ethereum from the architecture it has been using since its inception into a fundamentally different and more powerful new architecture — one that truly integrates two things: one is the very simple blockchain concepts from Satoshi Nakamoto’s early ideas; the other is the extremely powerful and modern cryptographic technologies we have continually built up thereafter.

Ecological Participation and Implementation Progress

Currently, early exploration and engineering verification around this proposal are intensively underway, and the technical community can participate in the development from multiple entry points:

• Network-level simulation models: Early simulation tools for mempool topology and aggregation propagation mechanisms are now available;

• Test network operation: A test network supporting frame transaction formats for EIP-8141 has been launched for testing;

• Algorithm optimization competitions: A specialized algorithm competition for the developer community is ongoing, focusing on efficiently implementing the underlying proof system;

• Code implementation and verification: The underlying prototype codebase has taken shape, available for ecological developers to implement independent clients and conduct formal verification.

A large number of underlying technical puzzles are being rapidly filled in, and we welcome all developers to deeply participate in this technological process to promote this revolutionary architecture to become the reality standard of the Ethereum mainnet as soon as possible.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。