In the next 5 years, Vitalik will expand Ethereum in this way

On February 27, 2026, Vitalik Buterin published a lengthy article titled "Hyper-scaling state by creating new forms of state" on Ethereum Research.

In this article, Vitalik Buterin further outlined the scaling path for Ethereum. This article discusses Ethereum's scaling not only from a technical perspective but also from an overall architectural viewpoint, providing a phased scaling plan aimed at laying the foundation for Ethereum to continuously expand its network capacity in the coming years.

At the same time, he also posted a tweet on X, further explaining this article. We attempt to understand in simple terms what Vitalik's newly proposed scaling plan is and why it is necessary.

Short-term and Long-term Expansion of Execution Resources and Data Resources

Vitalik pointed out at the beginning of the article, "To scale Ethereum in the next five years, we need to scale three types of resources":

• Execution resources: EVM computation, signature verification, etc.

• Data resources: Transaction senders, receivers, signatures, etc.

• State resources: Account balances, code, storage

The first two have short-term and long-term scaling plans.

For execution resources, short-term scaling can achieve about 10-30 times growth through Block Access Lists (BAL), ePBS, and gas fee repricing, while long-term scaling can achieve about 1000 times growth through ZK-EVM. Additionally, for certain specific types of computations (signatures, SNARK/STARK), off-chain aggregation can enhance performance by about 10,000 times.

For data resources, short-term scaling can achieve about 10-20 times growth through p2p improvements and multi-dimensional gas, while long-term scaling can achieve about 500 times growth through Blobs + PeerDAS.

Short-term scaling focuses on making Ethereum run faster. Currently, Ethereum is slow because the current verification method is serial—checking transactions one by one. If a transaction gets stuck, the entire verification process gets stuck.

Therefore, the upcoming Glamsterdam upgrade this year will introduce Block Access Lists (BAL) and ePBS.

Block Access Lists allow block packagers to inform validators in advance: "The transactions in this block will access these accounts and storage locations." With this information, validators can prepare in advance by loading this data from the hard drive into memory. Then, validators can check multiple transactions in parallel instead of one by one. It's like an assembly line in a factory: previously, one worker was responsible for the entire product, but now multiple workers handle different parts simultaneously.

ePBS separates the block packaging and verification process—block builders are responsible for packaging transactions, proposers are responsible for proposing blocks, and validators are responsible for verifying blocks. Each role focuses on its own work, allowing block builders to package more transactions aggressively because proposers and validators will help check, alleviating concerns about security.

Gas fee repricing + multi-dimensional gas can be considered the "core technique." Currently, all operations on Ethereum use the same gas fee. However, Vitalik's idea is that different operations should have different prices.

In particular, creating new states (such as creating new accounts or deploying new contracts) should incur a special "state creation fee." This is because creating new states is the most expensive operation. It not only consumes computational resources but also storage resources. Moreover, this cost is permanent—once created, the state will always exist.

Thus, Vitalik's idea is to make creating new states more expensive while making ordinary transactions cheaper.

The method to achieve this is the "reservoir mechanism." Imagine there are two buckets, one holding "state creation fees" and the other holding "ordinary gas fees." When contracts call each other, gas will automatically borrow from both buckets, ensuring that there is no confusion.

Ordinary users' transactions will become cheaper because these transactions do not incur "state creation fees." Developers who want to create new states will need to pay higher fees. This way, the overall capacity of the network will surge, but the growth of states will be controlled, preventing the hard drives of full nodes from exploding.

Long-term expansion aims to strengthen the mainnet itself and reduce reliance on Layer 2. This includes a phased rollout of Blobs + PeerDAS and ZK-EVM.

Blobs, a form of temporary large file storage, are currently mainly used by Layer 2. In the future, the Ethereum mainnet will also use Blobs to store data. However, this raises a problem—if every node has to download all the Blobs, the network will be overwhelmed.

This is where PeerDAS comes in—there's no need to download all the data, only a small portion. It's like a sampling survey; you don't need to ask everyone, just a small group to infer the situation of the entire population. Combined with ZK proofs, even if you only download 1/16 of the total data, you can still verify the integrity of the data.

Next is the phased rollout of ZK-EVM, which allows validating a block without needing to re-execute all transactions in the block. Nodes can simply trust the ZK proof, reducing the verification cost from "executing all transactions" to "verifying a ZK proof."

Vitalik's plan is for some nodes to trial ZK verification in 2026. By 2027, more nodes will be encouraged to use it. Ultimately, for a block to be valid, it must contain three out of five proof types from different proof systems. He expects that all nodes (except indexing nodes) will eventually rely on ZK-EVM proofs.

State Expansion Without a "Magic Bullet"

Now let's look at the "state resources" that have not been discussed in the short-term and long-term expansions. Although in the short term, it is still possible to improve by about 5-30 times through synchronization with Block Access Lists, p2p improvements, and database optimizations, what about the long term?

Vitalik's answer is, there is none.

Why is it so difficult to scale state resources? The state of Ethereum is like a massive database. This database contains all account balances, all contract codes, and all storage location data.

Currently, this database is not large, only about 100 GB, but if the state expands 20 times, it would be 2 TB. What about in a longer time frame? 8 TB?

The problem is not that hard drives can't hold it, but rather:

• Database efficiency is affected: Modern databases use tree structures (like Merkle trees) to organize data. When writing new data, the entire tree needs to be updated. This means that if you want to make X updates, it results in X operations at the database level, rather than just updating once and performing one database operation. The more updates, the more operations, and writing will slow down dramatically.

• Synchronization difficulties: A newly joined node in the Ethereum network needs to download the entire state to validate new blocks. If the data size reaches 8 TB, most people's current internet speeds would take a long time to download.

Solutions do exist, but Vitalik believes they all have issues:

• "Strong state statelessness": Nodes do not need to store the complete state, only requiring users to provide Merkle proofs. Vitalik believes this solution has issues with centralization of state storage, dynamic storage access leading to transaction failures, and bandwidth cost problems.

• "State expiration": Infrequently accessed states are automatically removed from active status. Nodes only need to store the most recently accessed states, significantly reducing storage space. Vitalik believes there is a fundamental "existence problem," which is how to prove that a state "never existed" when creating a new state. For example, when creating a new account, it would require proving that the new account address has never been created on Ethereum. This means that every new account creation would need to check 10 years of historical data, making the process complex and expensive.

Vitalik's ultimate approach is to combine these two solutions and propose several new forms of state, which represents a comprehensive change to the architecture of Ethereum's state resources:

• Temporary storage: A type of storage that automatically expires. For example, a new tree could be created that resets every month. This storage can be used for temporary data, such as order books, liquidity pools, and temporary counters, which typically do not require permanent storage. After a month, old orders expire, and new liquidity pools are created.

• Periodic storage: Similar to temporary storage, but with a longer period, such as one year.

• Restricted storage: Certain storage can only be accessed in specific ways. For example, the balance storage of an ERC20 token may only be accessible through specific interfaces. This way, the system can optimize for this type of storage.

At the same time, existing forms of state will be retained. Thus, execution may become 1000 times cheaper (through ZK-EVM), but creating new states may only become 20 times cheaper.

Vitalik believes that with new forms of state, developers will have choices. They can continue using existing forms of state but pay higher fees, or redesign applications to use new forms of state for lower fees. For common use cases (like ERC20 balances, NFTs), there will be standardized workflows, while for more complex use cases (like DeFi), developers will need to find ways to optimize themselves.

This strategy is quite interesting, suggesting that developers can think creatively to lower costs, benefiting the broader Ethereum user base.