Editor's Note: As the Ethereum ecosystem continues to expand, how to achieve network scaling without sacrificing security and decentralization has become a core issue. In this article, Vitalik Buterin further outlines Ethereum's scaling path: in the short term, improving execution efficiency through technical enhancements like Gas mechanism optimization and block validation parallelization; in the long term, relying on ZK-EVM and blobs data architecture to drive network capacity growth.

Overall, this roadmap provides a phased approach to scaling, aiming to lay the foundation for Ethereum to continuously increase network capacity in the coming years.

Below is the original text:

Now let's talk about scaling. This is mainly divided into two parts: short-term scaling and long-term scaling.

Short-Term Scaling

Regarding short-term scaling, I have written about it elsewhere. The core ideas are roughly as follows:

· Block-level access lists (to be introduced in the Glamsterdam upgrade) can enable parallelization of block validation.

· ePBS (also to be introduced in Glamsterdam) has several features, one of which is: it allows us to safely use a larger proportion of time per slot to validate blocks, rather than just a few hundred milliseconds as is currently the case.

· Gas repricing will ensure that the gas cost of various operations aligns with their actual execution time (and other costs they incur). We are also exploring a multidimensional gas mechanism in the early stages, allowing different resources to have separate caps. Combining these two can enable us to use a larger proportion of slot time for block validation without worrying about extreme cases.

Regarding multidimensional gas, we have developed a phased roadmap. The first phase is in the Glamsterdam upgrade, separating "state creation cost" from "execution and calldata cost."

For example, currently: an SSTORE operation that changes a storage slot from non-zero → non-zero costs 5000 gas; if from zero → non-zero, it costs 20000 gas.

In a gas repricing during Glamsterdam, this additional cost will be significantly increased (e.g., to 60000). The goal is to increase the gas limit while allowing execution capacity to scale much faster than state size.

For the reasons, I have written about it here: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Therefore, in Glamsterdam: this SSTORE operation will consume 5000 "regular gas" and, for example, 55000 "state creation gas."

Note: State creation gas will not count toward the ~16 million transaction gas limit.

This means: It will be possible to create larger contracts than currently possible.

How is Multidimensional Gas Implemented in the EVM?

This raises a question: The EVM is designed with the default assumption that gas is one-dimensional, e.g., GAS, CALL, and other opcodes are based on this assumption.

Our solution is to maintain two invariants:

If you initiate a call with X gas, that call will have X gas available for "regular operations," or "state creation," or other dimensions that may be added in the future.

If the GAS opcode tells you that you have Y gas, and then you initiate a call that consumes X gas, after the call returns, you will still have at least Y − X gas available for subsequent operations.

The specific implementation is: We introduce N+1 gas dimensions. By default, N = 1 (state creation), and the additional dimension is called the reservoir.

The EVM execution logic is:

If possible, consume gas from the dedicated dimension first.

If insufficient, consume from the reservoir.

For example, if you have: (100000 state creation gas, 100000 reservoir)

If you use SSTORE to create new state three times, the gas change process is: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)

Under this design:

The GAS opcode returns the reservoir value.

CALL will pass the specified amount of gas from the reservoir, along with all non-reservoir gas.

Multidimensional Gas Pricing

Later, we will further introduce multidimensional pricing, allowing different resource dimensions to have different floating gas prices.

This will bring:

Better long-term economic sustainability

Optimal resource allocation efficiency

For details: https://vitalik.eth.limo/general/2024/05/09/multidim.html

And the reservoir mechanism just solves the sub-call problem mentioned at the end of that article.

Long-Term Scaling

Long-term scaling mainly includes two directions: ZK-EVM and Blobs.

Blobs

For blobs, we plan to continuously iterate on PeerDAS, ultimately aiming for a data throughput capacity of about 8 MB/second.

This scale:

Is sufficient to meet Ethereum's own needs

Is not intended to be a "global data layer."

Currently, blobs are mainly used for L2. The future plan is to have Ethereum block data itself written directly to blobs.

The purpose of this is to enable people to verify a highly scaled Ethereum network without downloading and re-executing the entire chain:

ZK-SNARKs eliminate the need for re-execution

PeerDAS + blobs allow verification of data availability without downloading all the data

ZK-EVM

For ZK-EVM, our goal is to gradually increase the network's reliance on it.

2026: Clients supporting ZK-EVM will emerge, allowing nodes to use ZK-EVM for attestation. However, they will not be secure enough for the entire network to rely on. But it would be acceptable if about 5% of the network uses them. (If the ZK-EVM fails, you won't be slashed, but you might build on an invalid block and lose profits.)

2027: We will begin to recommend a larger proportion of nodes to run ZK-EVM, while focusing on formal verification and security improvements. Even if only 20% of the network uses ZK-EVM, it can allow us to significantly increase the gas limit, as this provides a low-cost verification path for solo stakers, who themselves make up less than 20% of the network.

After technical maturity: We will introduce a 3-of-5 mandatory proof mechanism. That is, a block must include at least 3 proofs from 5 different proof systems to be considered valid. By then, we expect that most nodes, except those needing to index, will rely on ZK-EVM proofs.

Long-term: Continue to improve ZK-EVM, making it more robust and conducting stricter formal verification. This phase may also involve changes at the virtual machine level, such as moving towards RISC-V.

For details: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052