On February 27, 2026, Vitalik Buterin published a long article on Ethereum Research entitled "Hyper-scaling state by creating new forms of state".
In this article, Vitalik Buterin further outlines Ethereum's scaling path. This article goes beyond a purely technical discussion of Ethereum scaling; it provides a phased scaling solution from an overall architectural perspective, aiming to lay the foundation for Ethereum's continued expansion of network capacity in the coming years.
He also posted a tweet on X, further explaining the article. We'll try to understand in simple terms what Vitalik's newly proposed scaling solution is and why he's doing it this way.
Short-term and long-term expansion of execution resources and data resources
At the beginning of his lengthy post, Vitalik pointed out that "in order to scale Ethereum over the next five years, three resources need to be scaled":
- Execution resources: EVM computation, signature verification, etc.
- Data resources: Transaction sender, receiver, signature, etc.
- State resources: account balance, code, storage
The former two have short-term and long-term expansion plans.
For execution resources, short-term growth of approximately 10-30 times can be achieved through Block Access List (BAL), ePBS, and Gas fee repricing, while long-term growth of approximately 1000 times can be achieved through ZK-EVM. Furthermore, for certain types of computation (signatures, SNARK/STARK), off-chain aggregation can improve performance by approximately 10,000 times.
For data resources, in the short term, we can achieve a growth of about 10-20 times through p2p improvements and multi-dimensional gas, and in the long term, we can achieve a growth of about 500 times through Blobs + PeerDAS.
Short-term expansion focuses on making Ethereum run faster. Ethereum is currently slow because its verification method is sequential—checking transactions one after another. If a transaction gets stuck, the entire verification process stalls.
Therefore, the upcoming Glamsterdam upgrade this year will introduce the Block Access List (BAL) and ePBS.
The block access list allows the block packer to inform the validators in advance: "The transactions in this block will access these accounts and storage locations." With this information, the validators can prepare in advance by loading this data from the hard drive into memory. Then, the validators can examine multiple transactions in parallel, instead of one by one. It's like a factory assembly line: where previously one worker was responsible for the entire product, now multiple workers handle different parts simultaneously.
ePBS separates the block packaging and verification processes—block builders are responsible for packaging transactions, proposers are responsible for proposing blocks, and validators are responsible for verifying blocks. Each role performs its specific task well, allowing block builders to more aggressively package more transactions, as proposers and validators will check them for them, eliminating concerns about security.
Gas fee repricing, combined with multi-dimensional gas pricing, could be considered the "core strategy." Currently, all Ethereum operations 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 a new state is the most expensive operation. It consumes not only computational resources but also storage resources. Moreover, this cost is permanent—once created, the state persists.
Therefore, Vitalik's idea is to make creating new states more expensive, but make ordinary transactions cheaper.
The method used to achieve this is a "reservoir mechanism". Imagine two buckets, one holding "state creation fees" and the other holding "regular gas fees". When contracts call each other, gas is automatically borrowed from both buckets to ensure that there is no chaos.
Transactions for regular users will become cheaper because they won't incur a "state creation fee." Developers who want to create new states will need to pay a higher fee. This results in a surge in overall network capacity, but state growth is kept under control, preventing full nodes from overloading their hard drives.
Long-term expansion aims to strengthen the mainnet itself and reduce reliance on Layer 2. This includes phased rollout using Blobs + PeerDAS and ZK-EVM.
Blobs, a temporary storage method for large files, are currently primarily used by Layer 2. In the future, the Ethereum mainnet itself will also use Blobs to store data. However, this raises a problem—if every node has to download all Blobs, the network will be overwhelmed.
This is where PeerDAS comes in—it doesn't require downloading all the data, only a small portion. Like a sampling survey, you don't need to ask everyone; you only need to ask 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 confirm data integrity.
Then there's ZK-EVM's phased rollout, which makes it so that verifying a block no longer requires re-executing all the transactions in the block. Nodes can simply trust the ZK proof, reducing the cost of verification from "executing all transactions" to "verifying a ZK proof".
Vitalik's plan is for some nodes to try ZK verification in 2026. By 2027, more nodes will be encouraged to use it. Finally, for a block to be valid, it must contain three of the five proof types from different proof systems. He anticipates that all nodes (except index nodes) will eventually rely on ZK-EVM proofs.
Expanding the scope of the state without a "miracle cure"
Now let's look at "state resources," which haven't been discussed in the short-term and long-term scaling sections. While in the short term, improvements of about 5-30 times can still be achieved through synchronization with the block access list, P2P improvements, and database optimizations, what about in the long term?
Vitalik's answer was no.
Why is state resource so difficult to scale? Ethereum's state is like a giant database. This database stores the balances of all accounts, the code of all contracts, and data from all storage locations.
The database is currently small, only about 100 GB, but if the state is expanded 20 times, it will be 2 TB. What about over a longer period? 8 TB?
The problem isn't that the hard drive can't hold it, but rather:
- Database efficiency is impacted: Modern databases use tree structures (such as Merkle trees) to organize data. When new data is written, the entire tree needs to be updated. This means that if you need to perform X updates, there will be X operations at the database level, instead of one update and one database operation. The more updates, the more operations, and writes will become incredibly slow.
- Synchronization difficulties: A new node joining the Ethereum network needs to download the entire state before it can verify a new block. If the data size reaches 8 TB, it will take most people a very long time to download it with their current network speeds.
There are solutions, but Vitalik believes they all have problems:
- "Strong statelessness": Nodes do not need to store the complete state; they only need users to provide Merkle proofs. Vitalik believes that this scheme suffers from issues such as centralized state storage, transaction failures due to dynamic storage access, and bandwidth costs.
- "State Expiration": Infrequently accessed states are automatically removed from the active state list. Nodes only need to store recently accessed states, significantly reducing storage space. Vitalik believes there is a fundamental "existential problem": how to prove that a state "never existed" when creating a new state. For example, creating a new account requires proving that the new account address has never been created on Ethereum. This means that creating each new account would require checking 10 years of historical data, making account creation complex and expensive.
Vitalik's ultimate approach is to combine these two approaches and propose several new forms of state, which represents a complete change to the Ethereum state resource architecture:
- Temporary storage: A type of storage that expires automatically. For example, a new tree can be created and automatically reset to zero each month. This type of storage can be used for temporary data, such as order books, liquidity pools, and temporary counters. This data usually does not need to be stored permanently. After a month, the old orders expire, and a new liquidity pool is created.
- Periodic storage: Similar to temporary storage, but with a longer period, such as 1 year.
- Restricted Storage: Some storage can only be accessed in a specific way. For example, the balance of an ERC20 token might only be accessible through a specific interface. This allows the system to optimize such storage.
At the same time, the existing state form is preserved. In this way, execution may be 1000 times cheaper (via ZK-EVM), but the creation of new state may only be 20 times cheaper.
Vitalik argues that the new state format gives developers a choice: continue using the existing state format but pay higher fees, or redesign the application to use the new state format and obtain lower fees. For common use cases (such as ERC20 balances and NFTs), there will be standardized workflows, while for more complex use cases (such as DeFi), developers need to find their own ways to optimize.
This strategy is quite interesting, and it seems to suggest that developers can use their ingenuity to reduce costs, while Ethereum users benefit from it.
