Vitalik Outlines Ethereum's Next Five Years: Execution Efficiency, Data Sharding, State Layering

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 outlined Ethereum's scaling roadmap. This piece doesn't just discuss Ethereum scaling from a technical perspective; it provides a phased scaling strategy from an overall architectural viewpoint, aiming to lay the foundation for Ethereum to continuously expand its network capacity in the coming years.

Simultaneously, he also posted a thread on X, offering further explanation of the article. We will attempt to break down what this newly proposed scaling strategy by Vitalik is all about and why it's being proposed.

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

At the beginning of the article, Vitalik points 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 both short-term and long-term scaling solutions.

For execution resources, short-term scaling through Block Access Lists (BAL), ePBS, and Gas repricing aims for approximately 10-30x growth. Long-term scaling via ZK-EVM targets about 1000x growth, and for specific types of computation (signatures, SNARK/STARK), off-chain aggregation could boost performance by roughly 10,000x.

For data resources, short-term scaling through p2p improvements and multi-dimensional Gas aims for about 10-20x growth. Long-term scaling via Blobs + PeerDAS targets approximately 500x growth.

Short-term scaling focuses on making Ethereum run faster. The current slowness is due to the serial nature of verification—checking transactions one by one. If one transaction gets stuck, the entire verification process halts.

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

Block Access Lists allow block builders to inform validators in advance: "The transactions in this block will access these accounts and storage locations." With this information, validators can prepare ahead of time, loading this data from disk to memory. Then, validators can check multiple transactions in parallel instead of sequentially. It's like an assembly line: previously, one worker handled the entire product; now, multiple workers process different parts simultaneously.

ePBS separates the block building and validation processes—block builders are responsible for assembling transactions, proposers for proposing blocks, and validators for verifying blocks. With each role performing its specific task, block builders can more aggressively pack more transactions because proposers and validators will check their work, alleviating security concerns.

Gas repricing + multi-dimensional Gas could be considered the "core move." 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 state (like 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 computational resources but also storage resources. Moreover, this cost is permanent—once created, the state persists indefinitely.

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

The implementation method is a "reservoir mechanism." Imagine two buckets: one holds the "state creation fee," the other holds "ordinary Gas fees." When contracts call each other, Gas is automatically borrowed from the two pools, ensuring no chaos.

Ordinary user transactions will become cheaper because they don't pay the "state creation fee." Developers who want to create new state will need to pay higher fees. This way, the network's overall capacity surges dramatically, but state growth is controlled, preventing full nodes' hard drives from exploding.

Long-term scaling is about making the mainnet itself bigger 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 primarily used by Layer 2s. In the future, the Ethereum mainnet itself will also use Blobs to store data. But a problem arises—if every node has to download all Blobs, the network would be overwhelmed.

This is where PeerDAS comes in—nodes don't need to download all the data, only a small portion. It's like sampling: you don't need to ask everyone, just a small group to infer the situation of the whole population. Combined with ZK proofs, even if you only download 1/16 of the total data, you can confirm data integrity.

Then there's the phased rollout of ZK-EVM, which means validating a block no longer requires re-executing all transactions within it. Nodes can simply trust the ZK proof. The cost of verification drops from "executing all transactions" to "verifying one ZK proof."

Vitalik's plan is: in 2026, some nodes trial ZK verification. By 2027, encourage more nodes to adopt it. Finally, for a block to be valid, it must include proofs from 3 out of 5 different proof systems. He anticipates that eventually, all nodes (except indexers) will rely on ZK-EVM proofs.

State Scaling: No "Silver Bullet"

Now let's look at the "state resource," which hasn't been discussed in the short-term and long-term scaling sections. In the short term, it's still possible to achieve about 5-30x improvement through synchronization with Block Access Lists, p2p improvements, and database optimization. But what about the long term?

Vitalik's answer is: there isn't one.

Why is state resource so difficult to scale? Ethereum's state is like a massive database. This database stores all account balances, all contract code, and all storage location data.

Currently, this database isn't huge, only about 100 GB. But if state is scaled 20x, that's 2 TB. And over a longer time? 8 TB?

The problem isn't that hard drives can't hold it, but rather:

- Database efficiency is impacted: Modern databases use tree structures (like Merkle trees) to organize data. When writing new data, the entire tree needs updating. This means if you perform X updates, at the database level, that's X operations again, not just one update triggering one database operation. More updates mean more operations, and writes can slow to a crawl.

- Synchronization difficulty: 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 speeds would take a very long time to download it.

Solutions exist, but Vitalik believes they all have problems:

- "Strong statelessness": Nodes don't need to store the full state; users only need to provide Merkle proofs. Vitalik believes this scheme has issues with state storage centralization, dynamic storage access causing transaction failures, and bandwidth costs.

- "State expiry": Infrequently accessed state is automatically removed from the active state. Nodes only need to store recently accessed state, greatly reducing storage space. Vitalik identifies a fundamental "existence problem": when creating a new state, how do you prove that a certain state "never existed"? Suppose you create a new account; you need to prove that the new account address has never been created on Ethereum before. This means each new account creation would require checking 10 years of historical data, making new account creation complex and expensive.

Vitalik's ultimate method is to combine these two schemes, proposing several new forms of state. This represents a holistic change to Ethereum's state resource architecture:

- Temporary storage: Storage that automatically expires. For example, a new tree could be created that resets automatically every month. This storage could be used for temporary data like order books, liquidity pools, temporary counters—data that typically doesn't need permanent storage. After a month, old orders expire, and new liquidity pools are created.

- Periodic storage: Similar to temporary storage but with longer cycles, like 1 year.

- Restricted storage: Certain storage can only be accessed in specific ways. For example, an ERC20 token's balance storage might only be accessible through a specific interface. This allows the system to optimize for this type of storage.

Simultaneously, existing state forms are retained. Thus, execution might become 1000x cheaper (via ZK-EVM), but new state creation might only become 20x cheaper.

Vitalik believes that with new state forms, developers have choices. Continue using existing state forms but pay higher fees, or redesign applications to use new state forms and obtain 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 figure out their own optimizations.

This strategy is quite interesting, having a flavor of developers using their brains to reduce costs, with the broader Ethereum user base benefiting.