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

null

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

In this article, Vitalik Buterin further sorts out Ethereum’s expansion path. This article not only talks about Ethereum’s expansion from a technical perspective, but also provides a set of phased expansion plans from an overall architectural perspective, aiming to provide the foundation for Ethereum’s continued expansion of network capacity in the coming years.

At the same time, he also posted a tweet on X to further explain the article. We tried to understand what Vitalik’s new expansion plan is and why it is doing it.

Short- and long-term expansion of executive resources and data resources

Vitalik began his long article by stating that “in order to scale Ethereum in the next five years, three resources need to be scaled”:

• Execution Resources: EVM computation, signature verification, etc

• Data resources: sender, receiver, signature, etc. of the transaction

• State resources: account balance, code, storage

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

For execution resources, short-term growth of about 10-30x through block access lists (BALS), ePBS, and gas fee repricing, long-term growth of about 1000x through ZK-EVM, and for some specific types of computation (signatures, SNARKs/STARKs), off-chain aggregation can increase performance by about 10,000 times.

For data resources, P2P improvement and multi-dimensional gas can achieve about 10-20 times growth in the short term, and about 500 times growth through Blobs + PeerDAS in the long term.

The short-term expansion is aimed at making Ethereum run faster. Ethereum is now slow because the current verification method is serial—checking transactions one after the other. If a transaction gets stuck, the entire verification process gets stuck.

Therefore, this year’s Glamsterdam upgrade will launch Block Access List (BAL) and ePBS.

The block access list allows the block packer to tell the validator in advance that the transactions in this block will access these accounts and storage locations. With this information, the validator can prepare in advance to load this data from the hard disk to memory. Validators can then check multiple transactions in parallel instead of checking them one by one. It’s like an assembly line in a factory: where a worker used to be responsible for the entire product, now multiple workers work on different parts at the same time.

ePBS separates the packaging and validation processes of blocks – block builders are responsible for packaging transactions, proposers are responsible for proposing blocks, and validators are responsible for verifying blocks. Each role does their part of their job, so the block builder can package more transactions more aggressively, because the proposer and validator will check for him without worrying about security.

Gas fee repricing + multi-dimensional gas may be said to be the “core move”. Now, all operations on Ethereum use the same gas fee. But Vitalik’s idea is that different operations should have different prices.

In particular, there should be a special “state creation fee” for creating a new state (e.g., creating a new account, deploying a new contract). Because creating a new state is the most expensive operation. It not only takes up computing resources but also storage resources. Moreover, this cost is permanent – once created, this state will remain in place.

So, Vitalik’s idea is: make creating a new state more expensive, but make ordinary transactions cheaper.

The method of realization is the “reservoir mechanism”. Imagine two buckets, one for the “state creation fee” and the other for the “normal gas fee”. When contracts call each other, gas will automatically borrow from the two libraries to ensure that it will not be chaotic.

Transactions for regular users will become cheaper because they do not have to pay a “state creation fee”. Developers who want to create a new state will need to pay a higher fee. In this way, the overall capacity of the network skyrockets, but the state growth is controlled and the hard disks of all nodes will not explode.

Long-term expansion is to make the mainnet bigger and stronger and reduce dependence on Layer 2. This includes Blobs + PeerDAS vs. ZK-EVM phased rollouts.

Blobs, a temporary large file storage, are now mainly used by Layer 2. In the future, the Ethereum mainnet itself will also use blobs to store data. But the problem also arises - if every node has to download all the blobs, the network will be blown up.

This is where PeerDAS comes in—you don’t need to download all the data, just a small portion of it. Just like a sample survey, you don’t need to ask everyone, you only need to ask a small group of people to infer the situation of the entire group. Combined with ZK proofs, you can confirm data integrity even if only 1/16 of the total data is downloaded.

Then there is the phased rollout of ZK-EVM, which eliminates the need to re-execute all transactions in a block to verify a block, and the node can directly trust the ZK proof, reducing the cost of verification from “executing all transactions” to “verifying a ZK proof”.

Vitalik’s plan is to trial ZK verification on some nodes in 2026. By 2027, more nodes are encouraged to use it. Finally, for a block to be valid, it must contain 3 of the 5 proof types from different proof systems. He expects that all nodes (except inodes) will eventually rely on ZK-EVM proofs.

There is no “magic bullet” state expansion

Now let’s look at the “state resources” that have not been discussed in the short and long term. Although in the short term, it can still be improved by about 5-30 times through synchronization with block access lists, P2P improvements, and database optimization, but what about in the long term?

Vitalik’s answer is, no.

Why are state resources so hard to scale? The state of Ethereum is like a huge database. This database contains the balance of all accounts, the codes of all contracts, and the data of all storage locations.

Now the database is not big, only about 100 GB, but if you expand the state by a factor of 20, it is 2 TB. What about a longer time? 8 TB？

The problem is not that the hard drive won’t fit, but:

• Database efficiency is affected: Modern databases use tree structures, such as Merkle trees, to organize data. When a new data is written, the entire tree needs to be updated. This means that if you want to do X updates, you will do X more operations at the database level, instead of one update and one database operation. The more updates and the more operations there are, the writes will be slow to the point of explosion.

• Synchronization Difficulties: A new node joining the Ethereum network needs to download the entire state to validate a new block. If the data scale is up to 8 terabytes, most people’s current internet speeds will be much lower.

There are solutions, but Vitalik thinks there are problems:

• “Strong statelessness”: Nodes do not need to store complete state, only need to provide Merkle proofs from users. Vitalik believes that this solution has problems with centralization of state storage, dynamic storage access leading to transaction failures, and bandwidth costs.

• “Status Expired”: Infrequently accessed statuses are automatically removed from active status. Nodes only need to store recently accessed state, which can greatly reduce storage space. Vitalik believes that there is a fundamental “existential problem” of how to prove that a state “never existed” when a new state is created. Suppose a new account is created, then it needs to prove that the new account address was never created on Ethereum. This means that every new account creation requires checking 10 years of historical data, making it complicated and expensive to create a new account.

Vitalik’s final approach is to combine these two schemes and propose several new state forms, which are a complete change to Ethereum’s state resource architecture:

• Temporary storage: A type of storage that automatically expires. For example, you can create a new tree and automatically clear it every month. This storage can be used for temporary data, such as order books, liquidity pools, temporary counters, etc., which usually do not need to be stored permanently, and after a month, the old order expires and a new liquidity pool is created.

• Periodic storage: Similar to temporary storage but with a longer period, like 1 year.

• Restricted storage: Some storage can only be accessed in a specific way. For example, the balance storage of an ERC20 token may only be accessible through a specific interface. This allows the system to optimize this storage.

At the same time, the existing state form is retained. This way, execution may be 1000 times cheaper (via ZK-EVM), but new state creation may only be 20 times cheaper.

Vitalik believes that with the new state form, developers have options. Continue to use the existing state form but pay a higher fee, or redesign the app and use the new state form for a lower fee. For common use cases (e.g., ERC20 balances, NFTs), there are standardized workflows, while for more complex use cases (e.g., DeFi), developers need to find ways to optimize themselves.

This strategy is quite interesting, and it means that developers use their brains to reduce costs, and the majority of Ethereum users benefit from it.