Vitalik Sets the Tone for 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 further outlines Ethereum’s scaling roadmap. The piece not only discusses Ethereum’s scalability from a technical perspective but also provides a phased architectural approach aimed at laying a foundation for the network’s continued capacity expansion over the coming years.

He also posted a tweet on X to further explain the article. We aim to break down and understand in simple terms: what exactly is this new scaling proposal Vitalik is introducing, and why is he doing it?

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

Vitalik begins by stating, “To scale Ethereum over the next five years, three types of resources need to be expanded”:

• 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 expansion plans.

For execution resources, short-term improvements include block access lists (BAL), ePBS, and gas fee re-pricing, achieving roughly 10-30x growth. Long-term, ZK-EVM aims for about 1000x increase, and for certain computations (signatures, SNARK/STARK), off-chain aggregation can boost performance by approximately 10,000x.

For data resources, short-term improvements involve p2p enhancements and multi-dimensional gas, resulting in about 10-20x growth. Long-term, Blobs + PeerDAS are expected to enable roughly 500x expansion.

Short-term expansion focuses on making Ethereum faster. Currently, Ethereum’s slowness stems from serial verification—checking transactions one by one. If a transaction stalls, the entire validation process stalls.

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

BAL allows block proposers to inform validators in advance: “This block’s transactions will access these accounts and storage locations.” With this info, validators can pre-load data from disk into memory, enabling parallel verification of multiple transactions instead of sequential checks. It’s like an assembly line: instead of one worker handling the entire product, multiple workers handle different parts simultaneously.

ePBS separates block packing from validation—block builders package transactions, proposers propose blocks, and validators verify them. Each role does its part, allowing block proposers to pack more transactions aggressively, since proposers and validators will assist in checking without compromising security.

Gas fee re-pricing combined with multi-dimensional gas is considered the “core move.” Currently, all operations use a single gas fee. Vitalik’s idea is that different operations should have different prices.

In particular, creating new state (e.g., creating accounts, deploying contracts) should have a special “state creation fee,” because it’s the most expensive operation. It consumes both compute and storage resources, and this cost is permanent—once created, the state persists indefinitely.

Vitalik proposes making new state creation more costly while making regular transactions cheaper.

The implementation uses a “reservoir mechanism”: imagine two buckets—one for “state creation fees” and another for “regular gas.” When contracts call each other, gas is automatically drawn from both buckets, ensuring proper accounting.

Regular user transactions become cheaper because they don’t pay the “state creation fee.” Developers wanting to create new states pay higher fees. This approach dramatically increases overall network capacity while controlling state growth, preventing full nodes’ storage from exploding.

Long-term, the goal is to strengthen the mainnet itself, reducing reliance on Layer 2 solutions. This includes phased rollouts of Blobs + PeerDAS and ZK-EVM.

Blobs, a temporary large file storage system primarily used for Layer 2, will eventually be adopted by the mainnet for data storage. But this raises a problem: if every node downloads all Blobs, the network could be overwhelmed.

PeerDAS addresses this by enabling nodes to download only a small subset of data—like sampling surveys—asking a small portion of nodes to infer the whole. Combined with ZK proofs, even downloading just 1/16 of the data can verify integrity.

The phased rollout of ZK-EVM allows nodes to verify blocks without re-executing all transactions—trusting ZK proofs instead. Verification costs drop from “execute all transactions” to “verify a ZK proof.”

Vitalik plans for, by 2026, some nodes to test ZK verification, and by 2027, more nodes to adopt it. Ultimately, a block will be valid if it contains at least 3 out of 5 proof types from different systems. He expects that all nodes (except index nodes) will rely on ZK-EVM proofs.

No “magic bullet” for state resource expansion

Now, let’s look at the “state resources” that haven’t been addressed in short-term or long-term plans. Although short-term improvements—via BAL synchronization, p2p enhancements, and database optimizations—can yield about 5-30x gains, what about long-term?

Vitalik’s answer: none.

Why is expanding state resources so difficult? Ethereum’s state is like a massive database containing all account balances, contract codes, and storage data.

Currently, this database is around 100 GB, but expanding it 20x would be 2 TB; longer-term, possibly 8 TB.

The issue isn’t storage capacity but:

• Database efficiency: modern databases use tree structures (like Merkle trees). Updating data requires updating the entire tree, meaning multiple operations per change, which slows down performance exponentially as updates increase.

• Synchronization difficulty: new nodes must download the entire state to validate blocks. With 8 TB, most users’ current internet speeds make this process very slow.

Proposed solutions exist, but Vitalik sees problems with all:

• “Statelessness”: nodes don’t store full state, only Merkle proofs. Vitalik argues this centralizes state storage, introduces dynamic access issues leading to transaction failures, and increases bandwidth costs.

• “State expiration”: inactive states are automatically deleted, reducing storage. Nodes only store recently accessed states. But Vitalik points out a fundamental problem: how to prove a state “never existed.” For example, creating a new account requires proving that the address was never previously created, which involves checking 10 years of history—making new account creation complex and costly.

His ultimate approach combines these ideas, proposing new state forms as part of a comprehensive overhaul:

• Temporary storage: auto-expiring storage, e.g., a new tree that resets monthly. Suitable for transient data like order books, liquidity pools, temporary counters—data that doesn’t need permanent storage.

• Periodic storage: similar but with longer cycles, e.g., yearly.

• Restricted storage: data accessible only via specific interfaces, e.g., ERC20 balances accessible through standard methods, allowing for optimization.

Existing state formats are retained. This means execution could become 1000x cheaper via ZK-EVM, but new state creation might only be 20x cheaper.

Vitalik believes that with these new state forms, developers can choose: continue with existing states at higher costs or redesign applications to use new, cheaper states. Standard workflows will emerge for common cases (ERC20, NFTs), while complex use cases (DeFi) will require custom optimization.

This strategy encourages developers to think creatively about cost reduction, ultimately benefiting the broader Ethereum user base.