The Complete Picture of EVM Architecture Evolution: Ethereum's Phased Scaling Strategy

As the Ethereum ecosystem rapidly expands, how to scale the network while maintaining security and Decentralization has emerged as one of the most important challenges. The technological roadmap presented by Vitalik Buterin outlines a comprehensive approach towards optimizing and scaling EVM. It is a strategy to gradually increase Ethereum’s processing capacity through two different layers, short-term and long term.

Short-term Efficiency Improvement of Ethereum EVM: Gas Optimization and Parallelization of Block Validation

The short-term scaling strategy focuses on maximizing the operational efficiency while leveraging the existing EVM machine design. Technical improvements centered around the Glamsterdam upgrade are expected to steadily enhance the network’s processing capacity.

The introduction of a block-level access list mechanism will enable the parallelization of the block validation process in EVM. Previously, the validation tasks were executed in a sequential manner, but now they can be processed simultaneously by multiple processes, resulting in a reduction in overall block generation time. This is a direct improvement that enhances the transaction processing speed across the entire network.

The ePBS (Encrypted Proposer-Builder Separation), which is also scheduled to be introduced in Glamsterdam, has several key features. Notably, it can extend the time allocated for block validation in each slot from the conventional hundreds of milliseconds to a larger time fraction. This creates more room in the validation process, allowing for more data to be processed securely.

The Mechanism of Multidimensional Gas: Innovations in EVM Design

The gas repricing mechanism represents a fundamental shift in the design philosophy of EVM, rather than just a fee adjustment. If the gas costs for various operations are accurately aligned with their execution time and corresponding resource consumption, it will enable a more efficient allocation of network resources.

The introduction of multidimensional gas will evolve the gas mechanism, which has been managed in a single dimension, into a structure that allows for independent cap management for multiple resource types. In the first phase, it is planned to separate the “state creation cost” from the “execution and calldata cost” in the Glamsterdam upgrade.

For a specific example, in the current SSTORE operation, changing a storage slot from zero to non-zero consumes 20,000 gas. After the repricing in Glamsterdam, this cost is expected to rise significantly to around 60,000 gas. This seemingly negative change actually has a strategic purpose. By simultaneously expanding the gas limit, it is possible to greatly exceed the speed at which the execution capacity of block validation expands compared to the speed of the blockchain’s state size expansion.

In the existing design of EVM, gas is implemented as a single dimension. Therefore, all opcodes such as GAS and CALL are based on this premise, but the transition to multidimensional gas requires maintaining this basic assumption without changing it and ensuring backward compatibility.

The adopted solution must adhere to the following immutable conditions. First, if a call is initiated with X gas, that call must own the X gas and must be usable for normal operations, state creation, or potentially other dimensions that may be added in the future. Second, if the GAS opcode currently indicates that there is Y gas available, then even if a call consuming X gas is issued, there must be at least Y - X gas remaining after the call returns, which must be available for subsequent operations.

In the specific implementation, N+1 gas dimensions are introduced. By default, N=1 (state creation), and the additional dimension is called “reservoir.” The EVM execution logic prioritizes consuming gas from dedicated dimensions as much as possible and consumes additional gas from the reservoir when insufficient.

For example, in a situation where the owned gas is (100000 state creation gas and 100000 reservoir), if SSTORE is used to create a new state three times, the transition of gas will be (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000). In this design, the GAS opcode returns the reservoir, and CALL operates by passing a specified amount of gas from the reservoir while simultaneously passing all gas except for the reservoir.

The introduction of multidimensional pricing that applies different fluctuating gas fees across multiple resource dimensions is expected to improve long-term economic sustainability and achieve better resource allocation efficiency.

Long term scaling path: Fusion of ZK-EVM and Blobs

While short-term improvements enhance the efficiency of existing EVM machines, long-term scaling strategies are looking at more fundamental design changes. Two key technological directions, ZK-EVM (zero-knowledge proof-based EVM execution verification) and Blobs, will shape the future of Ethereum.

As of 2026, the emergence of ZK-EVM compatible clients is finally becoming a reality. Nodes are approaching a stage where they will be able to participate in attestation (signature verification for the network) using ZK-EVM. However, in this initial stage, these clients have not yet reached a sufficient level of security, so the entire network cannot fully rely on them. It is acceptable for about 5% of the nodes in the network to use ZK-EVM, but any adoption beyond that will be postponed. At this stage, if issues arise with the ZK-EVM proof, staking rewards for individual nodes will not be forfeited, but there is a possibility of invalid block construction, which could lead to revenue losses for those nodes.

By 2027, it will progress to a stage where more nodes are recommended to run ZK-EVM. This will be a time when formal verification and continuous improvement in security are emphasized. Importantly, it is noted that if 20% of the nodes in the network use ZK-EVM, it will enable the provision of low-cost verification paths for solo stakers, significantly improving the gas limit. Considering that the total number of solo stakers is itself less than 20% of the network, improvements at this stage will benefit many users.

At the stage where the technology has matured sufficiently, a 3-of-5 consensus proof mechanism is scheduled to be introduced. This means that for a block to be considered valid, it must include at least three proofs from five different proof systems. This diverse proof mechanism will help reduce the risks associated with relying on a single technology and further enhance the resilience of the network. In subsequent stages, it is expected that most nodes will transition to relying on ZK-EVM proofs, excluding those nodes that require indexing functions.

In the long term, the aim is to further robustly improve the ZK-EVM and implement more rigorous formal verification. At this stage, structural changes at the virtual machine level, including directions such as RISC-V, will also be considered. This suggests the potential for fundamentally evolving the EVM machine design itself.

Evolution to Blobs and Advanced Data Layers

Regarding Blobs, the continuous improvements in the PeerDA transport layer aim to eventually achieve a data throughput of about 8 MB/second. This level of data processing capability is sufficient to meet the demands of Ethereum itself. However, it is not intended for Ethereum to become a global-scale data layer; rather, it is at a level that meets the demands of an independent network.

Currently, Blobs are mainly utilized for data storage in Layer 2 solutions (L2). As a future evolution, there is consideration for directly writing the data of the Ethereum block itself into Blobs. The purpose of this change is extremely significant. It will enable the validation of a highly scaled Ethereum network without having to download and re-execute the complete chain.

The realization of this goal involves the combination of two important technologies. First, ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) eliminate the need for the re-execution process itself. Next, PeerDAS and Blobs enable the verification of data availability without downloading all the data. This combination makes it possible for even lightweight nodes to participate fully in network verification.

The overall scaling strategy for Ethereum demonstrates an approach to gradually expand network capacity while balancing short-term efficiencies and long term structural evolution. Continuous optimization of the EVM and the phased introduction of new validation technologies will determine the development of the Ethereum network in the coming years.