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 Ethereum's scaling path. This article discusses Ethereum's scaling not only from a technical perspective but also from an overall architectural viewpoint, providing a phased scaling plan aimed at laying 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, further explaining this article. We attempt to understand in simple terms what Vitalik's newly proposed scaling plan is and why it is necessary.

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

Vitalik pointed out at the beginning of the article, "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: senders, receivers, signatures of transactions, etc.

• State resources: account balances, code, storage

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

For execution resources, short-term growth of about 10-30 times can be achieved through Block Access Lists (BAL), ePBS, and gas fee repricing, while long-term growth of about 1000 times can be achieved through ZK-EVM. Additionally, 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 of about 10-20 times can be achieved through p2p improvements and multidimensional gas, while long-term growth of about 500 times can be achieved through Blobs + PeerDAS.

Short-term scaling focuses on making Ethereum run faster. Currently, Ethereum is slow because the verification method is serial—checking transactions one by one. If one transaction gets stuck, the entire verification process is halted.

Therefore, the upcoming Glamsterdam upgrade this year will introduce Block Access Lists (BAL) and ePBS.

Block Access Lists allow 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 by loading this data from the hard drive 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 was responsible for the entire product; now, multiple workers handle different parts simultaneously.

ePBS separates the block packaging and verification process—block builders are responsible for packaging transactions, proposers are responsible for proposing blocks, and validators are responsible for verifying blocks. Each role performs its own tasks, allowing block builders to package more transactions aggressively, as proposers and validators will help check without worrying about security issues.

Gas fee repricing + multidimensional gas can be considered the "core technique." Currently, all operations on Ethereum 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 new states is the most expensive operation. It not only consumes computational resources but also storage resources. Moreover, this cost is permanent—once created, the state will persist indefinitely.

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

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

Ordinary users' transactions will become cheaper because these transactions do not incur "state creation fees." Developers who wish 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 drives of full nodes from exploding.

Long-term expansion aims to strengthen the mainnet itself and reduce reliance on Layer 2. This includes a 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 will also use Blobs to store data. However, this raises a problem—if every node has to download all the Blobs, the network will be overwhelmed.

This is where PeerDAS comes in—there's no need to download all the data, just a small portion. It's like a sampling survey; you don't need to ask everyone, just 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.

Next is the phased rollout of ZK-EVM, which allows validating a block without needing to re-execute all transactions within the block; nodes can simply trust the ZK proof, reducing the verification cost from "executing all transactions" to "verifying a ZK proof."

Vitalik's plan is for some nodes to trial ZK verification in 2026. By 2027, more nodes will be encouraged to adopt it. Ultimately, for a block to be valid, it must contain three out of five proof types from different proof systems. He anticipates that all nodes (excluding indexing nodes) will eventually rely on ZK-EVM proofs.

State Expansion Without a "Magic Bullet"

Now let's look at the "state resources" that have not been discussed in the short-term and long-term expansions. Although in the short term, it is still possible to enhance it 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, there is none.

Why is it so difficult to scale state resources? The state of Ethereum is like a massive database. This database contains all account balances, all contract codes, and all data at storage locations.

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

The issue is not that hard drives can't hold 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 needs to be updated. This means that if you want to make X updates, it results in X operations at the database level, rather than just updating once and performing one database operation. The more updates, the more operations, and writing can slow down dramatically.

• Synchronization difficulties: A newly joined node in 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 would take a long time to download.

There are solutions, 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 solution has problems with centralization of state storage, dynamic storage access leading to transaction failures, and bandwidth costs.

• "State expiration": Infrequently accessed states are automatically removed from active status. 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 state "never existed" when creating a new state. For example, when creating a new account, it would require proving that the new account address has never been created on Ethereum. This means that each new account creation would need to check 10 years of historical data, making it complex and costly.

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

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

• Periodic storage: Similar to temporary storage but with a longer period, such as one year.

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

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

Vitalik believes that with new forms of state, developers will have choices. They can continue to use existing forms of state but pay higher fees, or redesign applications to use new forms of state and benefit from lower fees. For common use cases (like ERC20 balances, NFTs), there will be standardized workflows, while for more complex use cases (like DeFi), developers will need to find ways to optimize themselves.

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