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 clarified the scaling path for Ethereum. This article does not only discuss Ethereum's scaling from a technical perspective but also provides a phased approach to scaling from an overall architectural perspective, aiming to lay 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 to further explain this article. We try to understand in simple terms what the new scaling proposal proposed by Vitalik is and why it needs to be done.

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

At the beginning of the long article, Vitalik pointed out, "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: sender, receiver, signatures of transactions, etc.

- State resources: account balances, codes, storage

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

For execution resources, short-term scaling can achieve about 10-30 times growth through block access lists (BAL), ePBS, and gas fee repricing. Long-term scaling can achieve about 1000 times growth through ZK-EVM, and for certain specific types of computations (signature, SNARK/STARK), off-chain aggregation can improve 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. Long-term scaling can achieve about 500 times growth through Blobs + PeerDAS.

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

Thus, this year's Glamsterdam upgrade will introduce block access lists (BAL) and ePBS.

The block access list allows 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 and load this data from the hard disk into memory. Then, validators can check multiple transactions in parallel, rather than checking them one by one. It’s like an assembly line in a factory: previously, one worker was responsible for the entire product, now multiple workers can handle different parts simultaneously.

ePBS separates the packaging and verification processes of the block—the block builders are responsible for packaging transactions, proposers are responsible for proposing blocks, and validators are responsible for verifying blocks. Each role has its own responsibilities, performing its part well, allowing block builders to package more transactions more aggressively, as proposers and validators will help them check without worrying about security issues.

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

Specifically, 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 occupies not only computational resources but also storage resources. Moreover, this cost is permanent—once created, this state will always exist.

Therefore, Vitalik's idea is: make creating new states more expensive, but make ordinary transactions cheaper.

The implementation method 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 fees will automatically borrow from both buckets, ensuring that there is no confusion.

Ordinary user transactions will become cheaper because these transactions do not need to pay the "state creation fee." On the other hand, developers wanting 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 disks of full nodes from exploding.

The long-term expansion aims to strengthen the mainnet itself, 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 for Layer 2. In the future, the Ethereum mainnet will also use Blobs to store data. But then the problem arises—if each node has to download all the Blobs, the network will be overwhelmed.

This is where PeerDAS comes into play—there's no need to download all data, just a small part. It's similar to a sample survey; you don't need to ask everyone, just a small number, to infer the situation of the entire group. Combined with ZK proofs, even if you only download 1/16 of the entire data, you can still confirm data integrity.

Then there is the phased rollout of ZK-EVM, which makes it no longer necessary to re-execute all transactions in a block to verify it—nodes can directly trust the ZK proof, reducing the verification cost from "executing all transactions" to "validating a ZK proof."

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

No "Silver Bullet" for State Expansion

Now let’s take a look at the "state resources" in short-term and long-term expansion that have not yet been discussed. 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, none.

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

Currently, this database is not large, only about 100 GB, but if the state is expanded by 20 times, it will become 2 TB. What if it takes longer? 8 TB?

The problem is not that the hard disk cannot hold it, but that:

- 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 if you want to make X updates, it translates to X operations on the database level, rather than updating once and counting as one database operation. The more updates, the more operations, and the writing will slow down drastically.

- Synchronization difficulties: A node newly 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 speeds will 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; they only need users to provide Merkle proofs. Vitalik believes this approach has issues with the centralization of state storage, dynamic storage access leading to transaction failures, and bandwidth cost problems.

- "State expiration": Infrequently accessed 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 "existence problem," which is how to prove that a certain state "never existed" when creating a new state. If a new account is created, it needs to be proven that the address of the new account has never been created on Ethereum. This means that the creation of each new account will require checking 10 years of historical data, making it complex and expensive.

Vitalik's final approach is to combine these two proposals and introduce several new forms of state, which signifies a comprehensive change in the architecture of Ethereum's state resources:

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

- Periodic storage: Similar to temporary 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 be accessible only through specific interfaces. This way, the system can optimize such storage.

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

Vitalik believes that with the new forms of state, developers will have choices. They can continue using the existing state forms but pay higher fees, or redesign their applications using the new state forms and enjoy 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, implying that developers can think creatively to lower costs, benefiting a wide range of Ethereum users in the process.

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