Vitalik's latest speech details EIP-8288: Ethereum scaling welcomes the "ultimate solution," future transactions will be both fast and cheap

Speaker: Vitalik Buterin

Compiled by: 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—one that allows Ethereum to achieve extremely high scalability while maintaining privacy and decentralization, and all three can be realized simultaneously. This proposal is likely to truly change the operational architecture of many components in blockchain. It can change a lot, but surprisingly, implementing it into the existing Ethereum is not too difficult. This is EIP-8288: Recursive Signature and Aggregation.

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

Today, I want to focus on several major issues that everyone is very concerned about: quantum security, privacy, and scalability. Currently, a significant problem is that quantum security and privacy are in great conflict with scalability:

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

• If we switch to quantum secure signatures (regardless of which type of quantum-resistant signature scheme), the gas consumption would be between 100,000 to 300,000 gas, depending on the size of the parameters chosen (for example, whether compatibility with blockchain wallets is needed). But no matter how you choose, the cost will be several times higher than today’s transactions—quantum secure signatures are large and expensive.

The second issue: privacy protocol proofs are also large and expensive. Anyone who has used any privacy protocol based on zero-knowledge (ZK) technology will know that on Ethereum, such operations consume at least about 350,000 gas. Due to the inefficiency of many of these protocols, the actual cost can sometimes reach around 1,000,000 gas—this is very expensive. Today, a typical transaction might only cost a few cents, while such transactions could 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 likely even more. In other words, if we let everyone start using "quantum secure + privacy" transactions now, 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 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 pre-computation files (which are large and costly). If you do not natively support these schemes in the EVM or do not have corresponding pre-computation files, then verifying any of these signatures 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 with 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 put all these signatures and STARK proofs (these large, complex objects) on-chain, but rather keep them off-chain and complete the aggregation within the mempool.

Specifically: when a user sends a transaction, there is a batch of nodes in the mempool that are already 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: when a user sends a transaction, a large object (signature/proof) is sent along with it, but this large object itself will never actually go on-chain. What goes on-chain is only a single STARK proof used to verify that all signatures and proofs contained in all user transactions indeed exist and are valid.

This mechanism is built on the foundation of EIP-8141 (native account abstraction), which will be introduced in the next hard fork. EIP-8141 consolidates nearly a decade of research in the Ethereum community on account abstraction, allowing each transaction to directly and precisely declare its 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 "dependencies." There are two types of dependencies: one corresponds to signatures, and the other corresponds to proofs (STARK). Unlike the current model where signatures are directly embedded in the transaction body, the new mechanism has the transaction itself 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 along, what is ultimately written into the block is only a micro-frame structure carrying the dependencies. Each dependency's data occupies only 96 bytes, with most even as low as 65 bytes. The remaining large cryptographic entities are absorbed and aggregated within the mempool, ultimately presented on the blockchain ledger in the form of a single proof.

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

Nodes collect all observed envelope objects within a fixed time window, perform local aggregation calculations, and then broadcast them out. During broadcasting, all originally discrete independent proofs are replaced by a global aggregated proof that mathematically rigorously covers the correctness of all underlying signatures in this batch.

This indicates that before the block packing nodes officially execute state updates, the Ethereum network has already completed the majority of high-intensity verification calculations in the non-consensus layer of the mempool stage.

The Essence of the Architecture: "Specialized Sharding"

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

This approach is not fragile; rather, it is very robust—any node can take on any part of this work. What we are essentially doing is splitting each transaction into two parts:

• One part describes "what this transaction does, how it interacts with the state, and how it interacts with other transactions";

• The other part is the large, heavy part of this transaction—the pure verification work.

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

Essentially, what we are doing is moving the work away from the validators, even moving it away from the nodes that pack blocks, pushing this part of the work to those nodes that are between "the user sends a transaction" and "the block packing nodes actually include the transaction in the block," which are off-chain.

What This Means for Ethereum

From a technical perspective, this means that Ethereum is super-scaling a specific type of computation. I believe this is also a trend we will increasingly see as Ethereum continues to evolve.

Ethereum, which was born ten years ago, focuses on fully general computation but lacks scalability. So what we are doing now is splitting the computation into different types and then specifically making those types that are "inherently more suitable for scaling" 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 handled in a less efficient manner smaller and easier to manage. EIP-8288 is precisely a super-scaling of the two types of objects: "signature verification" and "zero-knowledge proof verification."

Another interesting point 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 also much simpler. EIP-8288 is likely to become the first scenario on Ethereum to truly introduce RISC-V (or similar instruction sets). The reason is: EIP-8288 allows users to submit proofs, and when users submit proofs, they need to express the statements they are verifying in some language—RISC-V is precisely 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 in privacy scenarios is ZK-STARK) and immediately pushes it into the mempool; the first relay node that follows will recursively compress it with hundreds or thousands of similar proofs across the network into a single entity.

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

• One category is "dependencies"—those parts that must be ensured to be correct for the transaction to be valid;

• The other category is "business logic"—what the transaction itself 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 parallel on a massive scale, with almost no significant changes needed to the development experience of Ethereum developers.

Practical Value for Developers, Users, and Layer 2

For anyone building applications on-chain, the core significance of all this is that the most expensive operations today will become much cheaper.

• The execution overhead of quantum secure transactions will be compressed to nearly negligible levels;

• Privacy-protecting applications built on zk-SNARK/STARK will be freed from the constraints of high gas fees, popularizing them at a civilian cost while inherently possessing quantum resistance.

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 to batch process settlements every 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 to batch process settlements every 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.

The Ultimate Evolution: Pushing Computation to the Edge

Finally, if there are other calculations you want to perform, but the execution cost within the EVM is too high, I hope we can truly begin to shift direction—no longer allowing the Ethereum protocol itself to bear all the calculations that everyone wants to perform directly, but rather encouraging users to complete this part of the computation locally on their clients and then publish a proof that can be verified on Ethereum.

Essentially, this achieves the scalability of Ethereum by moving computation away from the "center" of the chain and pushing it to the "edge." The result is that the most expensive things on Ethereum today (various forms of security, various forms of privacy, and various compatibilities with external applications) are currently too costly for people to engage in, but in the future, they will become much cheaper and truly accessible to everyone.

I hope this is just the first step in transforming Ethereum from the architecture it has used almost since its inception into a completely different and more powerful new architecture—this new architecture will truly combine two things: one is the very early and simple blockchain concept from Satoshi Nakamoto; the other is the extremely powerful and modern cryptographic technologies that we have continuously accumulated thereafter.

Ecological Participation and Progress

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

• Network-level simulation models: Early simulation tools for memory pool topology and aggregation propagation mechanisms have been opened;

• Test network operation: The EIP-8141 test network supporting frame transaction forms has been put into testing;

• Algorithm optimization competitions: Special algorithm competitions aimed at the developer community are being promoted, focusing on the efficient implementation of the underlying proof system;

• Code implementation and validation: The underlying prototype codebase has taken shape, allowing ecological developers to conduct independent client implementations and formal verification.

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