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

In this article, Vitalik Buterin further outlined Ethereum's scaling path. This piece is not just a technical discussion of Ethereum's scalability but also provides a phased approach to scaling from a holistic architectural perspective, aiming to provide a foundation for continuously expanding the network's capacity over the next few years.

Additionally, he also tweeted about this article on Twitter, further elaborating on its content. We are trying to understand in simple terms what Vitalik's new scaling proposal is and why it is being done.

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

In the opening of the lengthy article, Vitalik pointed out that "to scale Ethereum over the next five years, three resources need to be scaled":

- 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, in the short term, approximately 10-30x growth will be achieved through Block Access Lists (BAL), ePBS, and Gas Fee Repricing, while in the long term, approximately 1000x growth will be achieved through ZK-EVM, and for certain types of computation (signatures, SNARK/STARK), off-chain aggregation can boost performance by around 10000x.

For data resources, in the short term, approximately 10-20x growth will be achieved through p2p improvements and multi-dimensional Gas, while in the long term, approximately 500x growth will be achieved through Blobs + PeerDAS.

Short-term expansion aims to make Ethereum run faster. Ethereum is slow now because the current validation is serial—one transaction at a time. If a transaction gets stuck, the entire validation process gets stuck.

Therefore, in the upcoming Glamsterdam upgrade later this year, Block Access Lists (BAL) and ePBS will be introduced.

The Block Access List allows the block producer 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 disk into memory. Then, validators can check multiple transactions in parallel instead of one by one. It's like a factory assembly line: instead of one worker handling the entire product, now multiple workers process different parts simultaneously.

ePBS separates the block packaging and validation processes—the block builder is responsible for packing transactions, the prover proposes the block, and validators validate the block. Each role does its own job well, allowing the block builder to more aggressively pack more transactions because the proposer and validators help validate, eliminating security concerns.

Gas Fee repricing + Multi-dimensional Gas could be considered a "core move." Currently, all operations in Ethereum use the same Gas fee. However, Vitalik's idea is that different operations should have different prices.

In particular, creating new state (such as creating a new account, deploying a new contract) should have a special "state creation fee" because creating new state is the most expensive operation. It consumes not only computing resources but also storage resources. Moreover, this cost is permanent—once created, this state will exist indefinitely.

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

The implementation method is the "reservoir mechanism." Imagine two buckets, one holding the "state creation fee" and the other holding the "ordinary Gas fee." When contracts call each other, Gas will automatically borrow from both buckets to ensure orderly execution.

Transactions from regular users will become cheaper because they do not need to pay the "state creation fee." Developers wanting to create new state will need to pay a higher fee. This way, the overall network capacity expands significantly, but state growth is controlled to prevent full node disk explosions.

The long-term expansion plan is for the mainnet itself to grow stronger and reduce reliance on Layer 2. This includes Blobs + PeerDAS and the phased rollout of ZK-EVM.

Blobs, a temporary large file storage, currently used mainly for Layer 2. In the future, the Ethereum mainnet itself will also use Blobs for data storage. However, a problem arises—if every node has to download all the Blobs, the network will be overwhelmed.

This is where PeerDAS comes in—no need to download all data, just a small part. Similar to sampling surveys, not everyone needs to be asked; just a small group can infer the situation of the entire population. Combined with ZK proof, even if only 1/16 of all data is downloaded, you can confirm data integrity.

Next is the phased rollout of ZK-EVM, which makes validating a block no longer require re-executing all transactions in the block. Nodes simply need to trust the ZK proof, reducing the cost of validation from "executing all transactions" to "validating a ZK proof."

Vitalik's plan is to have some nodes trial ZK validation by 2026. By 2027, more nodes are encouraged to use it. Finally, for a block to be valid, it must contain 3 out of 5 proof types from different proof systems. He anticipates that all nodes (excluding archive nodes) will eventually rely on ZK-EVM proofs.

No "Magic Bullet" for State Expansion

Now let's look at the "state resources" in short and long-term scalability that haven't been discussed yet. Although in the short term, improvements can still be made by synchronizing with the block access list, P2P enhancements, and database optimizations to achieve about a 5-30x improvement, what about the long term?

Vitalik's answer is, none.

Why is state expansion so difficult? Ethereum's state is like a huge database that contains all account balances, contract codes, and storage data of all positions.

Currently, the database is not large, only about 100 GB, but if the state is expanded 20 times, it will be 2 TB. What about a longer period? 8 TB?

The issue is not about the disk space, but:

- Database efficiency is affected: Modern databases use tree structures (such as Merkle trees) to organize data. When writing new data, the entire tree needs to be updated. This means that if you need to do X updates, at the database level, it will be X operations instead of one update operation. The more updates, the more operations, and the write speed will slow down significantly.

- Difficulty in synchronization: A new node joining 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 speed would take a very long time.

There are solutions, but Vitalik believes they all have issues:

- "Strong statelessness": Nodes do not need to store the complete state, only requiring users to provide a Merkle proof. Vitalik believes this solution suffers from centralized state storage, dynamic storage access leading to transaction failures, and bandwidth cost problems.

- "State expiry": Inactive states are automatically removed from the active state. Nodes only need to store the most recently accessed states, significantly reducing storage space. Vitalik believes there is a fundamental "existential problem" wherein, when creating a new state, proving that a state "has never existed" poses a challenge. For example, when creating a new account, it would need to be proven that the new account address has never been created on Ethereum. This implies that creating each new account would require checking 10 years of historical data, making new account creation complex and expensive.

Vitalik's ultimate approach is to combine these two solutions, proposing several new forms of state, which represent an overarching change to Ethereum's state resource architecture:

- Ephemeral Storage: Storage that automatically expires. For example, a new tree could be created that resets every month. This type of storage can be used for temporary data, order books, liquidity pools, temporary counters, and other data that typically do not need to be stored permanently. After a month, old orders expire, and new liquidity pools are created.

- Periodic Storage: Similar to ephemeral storage but with a longer cycle, such as 1 year.

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

Simultaneously, retaining the existing forms of state. This means execution may be made 1000 times cheaper (through ZK-EVM), while creating new states may only be 20 times cheaper.

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

This strategy is quite interesting, as it requires developers to put on their thinking caps to reduce costs, ultimately benefiting the broader Ethereum user base.

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