Ethereum releases a scalability roadmap. How is this one different?

Ethereum Releases Roadmap for Scalability: What’s Different This Time?

Author: @VitalikButerin
Translation: Peggy

Source:

Reprint: Mars Finance

Editor’s Note: As the Ethereum ecosystem continues to grow, how to expand the network without sacrificing security and decentralization has become a core issue. In this article, Vitalik Buterin further outlines Ethereum’s scalability path: short-term improvements through Gas mechanism optimization, block validation parallelization, and other technical upgrades, and long-term strategies relying on ZK-EVM and blobs data architecture to increase network capacity.

Overall, this roadmap offers a phased approach to expansion, aiming to lay a foundation for Ethereum’s sustained network growth in the coming years.

Below is the original text:

Let’s talk about scaling. It mainly divides into two parts: short-term scaling and long-term scaling.

Short-term Scaling

Regarding short-term scaling, I’ve covered some points elsewhere. The core ideas are roughly as follows:

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

· ePBS (also to be introduced in Glamsterdam) has several features, one of which allows us to safely use a larger proportion of each slot’s time for block validation, instead of just a few hundred milliseconds as now.

· Gas re-pricing will ensure that the gas costs of various operations align with their actual execution times (and other associated costs). We are also exploring multidimensional gas mechanisms, allowing different resources to have separate limits. Combining these approaches enables us to use a larger share of slot time for validation without worrying about extreme cases.

Regarding multidimensional gas, we have a phased roadmap. The first phase, in the Glamsterdam upgrade, will separate “state creation cost” from “execution and calldata costs.”

For example, currently: a SSTORE operation costs 5,000 gas if changing a storage slot from non-zero to non-zero; 20,000 gas if from zero to non-zero.

In Glamsterdam’s gas re-pricing, this additional cost will be significantly increased (e.g., to 60,000). The goal is to raise the gas limit while allowing execution capacity to grow faster than state size.

As I’ve explained before:

Therefore, in Glamsterdam: this SSTORE operation will consume 5,000 “regular gas” plus, for example, 55,000 “state creation gas.”

Note that: state creation gas does not count toward the approximately 16 million transaction gas limit.

This means creating larger contracts than currently will become possible.

How is multidimensional gas implemented in the EVM?

A challenge here is that the EVM’s design assumes gas has only one dimension, with opcodes like GAS and CALL based on this assumption.

Our solution is to maintain two invariants:

If you initiate a call with X gas, then this call has X gas available for “regular operations,” “state creation,” or other future dimensions.

If the GAS opcode reports Y gas, and you initiate a call consuming X gas, then after the call, you still have at least Y − X gas for subsequent operations.

The implementation introduces N+1 gas dimensions. By default, N=1 (for state creation), and the extra dimension is called reservoir.

EVM execution logic:

• Prioritize consuming gas from dedicated dimensions when possible

• If insufficient, then consume from the reservoir

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

Creating three new states with SSTORE, the gas changes as follows: (100,000, 100,000) → (45,000, 95,000) → (0, 80,000) → (0, 20,000)

Under this design:

• GAS opcode returns the reservoir amount

• CALL passes a specified amount of gas from the reservoir, along with all non-reservoir gas

Multidimensional Gas Pricing

We will further introduce multi-dimensional pricing, allowing different resource dimensions to have varying floating gas prices.

This will bring:

• Better long-term economic sustainability

• More efficient resource allocation

See details in:

The reservoir mechanism also addresses the sub-call problem mentioned at the end of that article.

Long-term Scaling

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

Blobs

For blobs, we plan to iteratively improve PeerDAS, aiming for a data throughput of about 8 MB/sec.

This scale:

• Is sufficient to meet Ethereum’s own needs

• Does not intend to become a “global data layer”

Currently, blobs are mainly used for Layer 2. Future plans include writing Ethereum block data directly into blobs.

The purpose is to enable verification of a highly scalable Ethereum network without downloading and re-executing the entire chain:

• ZK-SNARKs eliminate the need for re-execution

• PeerDAS + blobs allow data availability verification without downloading all data

ZK-EVM

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

2026: Client support for ZK-EVM will emerge, allowing nodes to participate in attestation using ZK-EVM. However, these are not yet sufficiently secure for the entire network to depend on. Nonetheless, about 5% of the network using ZK-EVM is acceptable. (If issues arise with ZK-EVM, you won’t be penalized or slashed, but you might build on invalid blocks, risking loss of rewards.)

2027: We will recommend a larger proportion of nodes run ZK-EVM, focusing on formal verification and security improvements. Even with only 20% of the network using ZK-EVM, we can significantly raise the gas limit, as this provides low-cost validation paths for solo stakers, who themselves constitute less than 20%.

Once the technology matures: we will introduce a 3-of-5 proof mechanism, meaning a block must contain at least 3 proofs from five different systems to be considered valid. By then, most nodes will rely on ZK-EVM proofs, except for index nodes.

Long-term: continue improving ZK-EVM for robustness and formal verification, possibly involving VM-level changes such as RISC-V.

See details in: