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 elaborated on the scalability path of Ethereum. This article discusses Ethereum's scalability not only from a technical perspective but also from a holistic architectural viewpoint, providing a phased approach to scalability aimed at laying a foundation for Ethereum's continued expansion of network capacity in the coming years.

At the same time, he also posted a tweet on X further explaining the article. We attempt to understand in simple terms what this newly proposed scalability plan by Vitalik is and why it needs to be done.

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

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

- Execution Resources: EVM calculations, 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 expansion plans.

For execution resources, short-term growth can be achieved through block access lists (BAL), ePBS, and gas fee repricing for an estimated 10-30 times increase, while long-term growth can be achieved through ZK-EVM for an estimated 1000 times, and 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 growth can be achieved through p2p improvements and multi-dimensional gas for an estimated 10-20 times increase, while long-term growth can be achieved through Blobs + PeerDAS for an estimated 500 times increase.

Short-term expansion focuses on making Ethereum run faster. The current slowness of Ethereum is due to the fact that the current validation method is serial—checking transactions one at a time. If one transaction gets stuck, the entire validation process gets stuck.

Therefore, the upcoming Glamsterdam upgrade this year will introduce block access lists (BAL) and ePBS.

Block access lists allow block packers 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, loading this data from hard drives 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 handled the entire product, now multiple workers handle different parts simultaneously.

ePBS separates the block packing and validation process—block builders are responsible for packing transactions, proposers are responsible for proposing blocks, and validators are responsible for validating blocks. Each role performs its respective duties, allowing block builders to pack more transactions more aggressively since proposers and validators will assist in checking without worrying about security issues.

Gas fee repricing + multi-dimensional gas can be said to be the "core trick." Currently, all operations on Ethereum use the same type of gas fee. But Vitalik's idea is that different operations should have different prices.

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

Therefore, Vitalik's idea is: make state creation more expensive, but make ordinary transactions cheaper.

The implementation method is the "reservoir mechanism." Imagine there are two barrels, one storing "state creation fees," and the other storing "ordinary gas fees." When contracts call each other, gas will automatically borrow from these two barrels, ensuring there is no chaos.

Ordinary user transactions will become cheaper because they do not need to pay the "state creation fee." However, developers wanting to create new states will need to pay higher fees. This way, the overall capacity of the network will increase tremendously while controlling state growth, preventing full nodes' hard drives from exploding.

Long-term expansion aims to make the mainnet itself larger and stronger, reducing reliance on Layer 2. This includes the 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 itself will also use Blobs to store data. But with this comes a challenge—if every node must download all the Blobs, the network will be overburdened.

Here, PeerDAS will help—there's no need to download all the data, only a small portion needs to be downloaded. It is like a survey; you don’t have to ask everyone, just a small sample can infer the situation of the entire group. Combined with ZK proof, even if you only download 1/16th of the data, you can confirm its integrity.

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 ZK proofs, reducing the cost of validation from "executing all transactions" to "validating a ZK proof."

Vitalik's plan is to trial ZK validation with some nodes in 2026. By 2027, more nodes will be encouraged to use it. Ultimately, to be valid, a block must include 3 of the 5 proof types from different proof systems. He anticipates that all nodes (excluding indexing nodes) will ultimately rely on ZK-EVM proofs.

No "Panacea" for State Expansion

Now let’s take a look at the "state resources" that haven't been discussed yet in short-term and long-term expansion. Although in the short term, it is still possible to enhance 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, none.

Why is it so difficult to expand state resources? The state of Ethereum is like a huge database. This database holds all account balances, all contract codes, and all data for storage locations.

Currently, this database isn't large, only about 100 GB, but if the state expands 20 times, that would be 2 TB. What if given more time? 8 TB?

The problem isn't that hard drives can't handle 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 must be updated. This means if you are doing X updates, there are X operations at the database level, instead of just updating once and making one operation. The more updates, the more operations, and writing can slow down tremendously.

- Synchronization difficulties: A new node joining the Ethereum network needs to download the entire state to validate new blocks. If the data size reaches 8 TB, the download will take a long time with most people's current internet speeds.

Solutions exist, but Vitalik believes they all have issues:

- "Strong state statelessness": Nodes do not need to store the complete state, only require users to provide Merkle proofs. Vitalik believes this solution is plagued by centralized state storage, dynamic storage access leading to transaction failures, and bandwidth cost issues.

- "State expiration": Infrequently accessed states are automatically removed from active states. Nodes only need to store recently accessed states, greatly reducing storage space. Vitalik believes there is a fundamental "existence problem" when creating a new state, as it requires proving that a state "never existed." For instance, when creating a new account, proof is needed that the new account address has never been created on Ethereum, meaning the creation of each new account requires checking 10 years of historical data, making the task complex and costly.

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

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

- Periodic storage: Similar to temporary storage but for a longer period, like one year.

- Restricted storage: Some storage can only be accessed in specific ways. For example, the balance storage of an ERC20 token may only be accessible through certain interfaces. This allows the system to optimize such storage.

At the same time, the existing forms of state will be retained. As a result, execution may become 1000 times cheaper (via ZK-EVM), but the creation of new states might only be 20 times cheaper.

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

This strategy is quite interesting, suggesting that developers think creatively to reduce costs, benefiting the wider Ethereum user base.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。