Original Author: @VitalikButerin
Translation: Peggy, BlockBeats

Editor's Note: As the Ethereum ecosystem continues to grow, achieving network scalability without sacrificing security and decentralization has become a core issue. In this article, Vitalik Buterin further outlines Ethereum's scalability path: in the short term, improving execution efficiency through Gas mechanism optimization, block validation parallelization, and other technical upgrades; in the long term, relying on ZK-EVM and blobs data structure to drive network scalability.

Overall, this roadmap provides a phased scalability plan designed to lay the foundation for Ethereum to continuously expand its network capacity in the coming years.

The following is the original text:

Now let's talk about scaling. It can mainly be 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 idea is roughly as follows:

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

· ePBS (also to be introduced in Glamsterdam) has multiple features, one of which is: it allows us to safely use a larger proportion of time in each slot to validate blocks, instead of just using a few hundred milliseconds like now.

· Gas repricing will ensure that the gas cost of various operations remains consistent with their actual execution time (and other costs they incur). We are also early in exploring a multidimensional gas mechanism, allowing different resources to have separate limits. The combination of these two can allow us to use a larger proportion of slot time in block validation without worrying about extreme scenarios.

Regarding multidimensional gas, we have laid out a phased roadmap. The first phase is in the Glamsterdam upgrade, where the "state setup cost" is separated from the "execution and calldata costs."

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

In a gas repricing event in Glamsterdam, this additional cost will be significantly increased (e.g., increased to 60000). The goal of this is to raise the cost while making the expansion rate of execution capability significantly higher than the expansion rate of state size.

Regarding the reasons, I have written before: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Therefore, in Glamsterdam: This SSTORE operation will consume 5000 "base gas," e.g., 55000 "state-creating gas."

It is important to note: State-creating gas does not count towards the approximately 16 million transaction gas limit.

This means: Creating larger contracts than now will become possible.

How is Multi-dimensional Gas achieved in the EVM?

Here is an issue: The EVM's design assumes gas has only one dimension; for example, GAS, CALL, and other opcodes are all 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 "base operations," "state creation," or any potential future additional dimensions.

If the GAS opcode tells you that you currently have Y gas, and then you initiate a call that consumes X gas, after the call returns, you 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 execution logic of the EVM is:

If possible, prioritize consuming gas from specialized dimensions.

If it's not enough, consume from the reservoir.

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

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

In this design:

The GAS opcode returns the reservoir

CALL will pass a specified amount of gas from the reservoir and all non-reservoir gas

Multi-Dimensional Gas Pricing

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

This will bring:

Better long-term economic sustainability

Optimized resource allocation efficiency

See more at: https://vitalik.eth.limo/general/2024/05/09/multidim.html

The reservoir mechanism neatly solves 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 continue iterating on PeerDAS, aiming to eventually achieve a data throughput of roughly 8 MB/second.

This scale:

Is sufficient to meet Ethereum's own needs

And is not intended to become a "global data layer."

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

The purpose of doing this is to allow people to validate 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: Clients supporting ZK-EVM will emerge, allowing nodes to participate in attestation with ZK-EVM. However, they are not yet secure enough to allow the entire network to depend on them for operation. Nevertheless, it is acceptable if about 5% of the network uses them. (If there are issues with ZK-EVM, you will not be penalized in slashing, but you may build on invalid blocks, resulting in loss of revenue.)

2027: We will start recommending a larger proportion of nodes to run ZK-EVM, while focusing on formal verification and security enhancements. Even if only 20% of the network uses ZK-EVM, we can significantly increase the gas limit, as this provides a low-cost validation path for solo stakers, and the proportion of solo stakers is less than 20%.

Post-technical maturity: We will introduce a 3-of-5 compulsory proof mechanism. That is, a block must contain at least 3 proofs from 5 different proof systems to be considered valid. By then, we expect that most nodes will rely on ZK-EVM proofs, except for nodes that need to do indexing.

Long-term: Continue to improve ZK-EVM to make it more robust and undergo stricter formal verification. This stage may also involve changes at the virtual machine level, such as the direction of RISC-V.

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

[Original Article Link]

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia