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 architecture 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 this new scaling proposal entails and why it is necessary.

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 sender, receiver, 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 around 10-30x growth via Block Access Lists (BAL), ePBS, and gas fee re-pricing; long-term, ZK-EVM aims for approximately 1000x increase, with off-chain aggregation for certain computations (signatures, SNARK/STARK) boosting performance by about 10,000x.

For data resources, short-term gains come from p2p improvements and multi-dimensional gas, achieving roughly 10-20x growth; long-term, Blobs + PeerDAS are projected to enable about 500x expansion.

Short-term expansion focuses on making Ethereum faster. Currently, the network is slow because verification is serial—transactions are checked one after another. If a transaction stalls, the entire validation process stalls.

Therefore, this year’s Glamsterdam upgrade will introduce 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—like an assembly line: instead of one worker handling the entire product, multiple workers handle different parts simultaneously.

ePBS separates block building 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, reducing security concerns.

Gas fee re-pricing combined with multi-dimensional gas is a “core move.” Currently, all operations use the same gas fee. Vitalik suggests different operations should have different prices.

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

His idea is to make creating new states more costly, while making regular transactions cheaper.

The implementation uses a “reservoir mechanism.” Imagine two buckets: one for “state creation fees,” 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 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, is currently mainly used for Layer 2. In the future, Ethereum mainnet will also store data via Blobs. But this raises a problem—if every node downloads all Blobs, the network could be overwhelmed.

PeerDAS addresses this by allowing nodes to download only a small portion of data—like sampling in surveys: you don’t need to ask everyone, just a subset, and infer the whole. Combined with ZK proofs, even downloading only 1/16 of the data can still verify integrity.

The phased rollout of ZK-EVM makes block verification no longer require re-executing all transactions. Nodes can simply trust ZK proofs, reducing verification from “execute all transactions” to “verify a ZK proof.”

Vitalik plans to have some nodes test ZK verification by 2026, encouraging more nodes to adopt it by 2027. Ultimately, a block will need to include at least 3 out of 5 different proof types from various systems. He expects that, eventually, 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 discussed in short-term or long-term plans. Although in the short term, improvements via BAL, p2p, and database optimization can yield about 5-30x growth, 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, 8 TB or more.

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: A new node joining the network must download the entire state to validate new blocks. With 8 TB of data, most users’ current bandwidth makes this process very slow.

Proposed solutions exist, but Vitalik believes they all have issues:

• “Stateless clients”: Nodes don’t store full state, only Merkle proofs from users. Vitalik argues this centralizes state storage, introduces dynamic access costs, and bandwidth overhead.

• “State expiration”: Infrequently accessed states are automatically pruned. Nodes only store recent states, reducing storage needs. But Vitalik points out a fundamental problem: how to prove a state “never existed” when creating a new account? For example, creating a new account requires proving that the address has never been used before, which involves checking 10 years of history—making new account creation complex and costly.

His ultimate approach combines these ideas, proposing new state forms that fundamentally alter Ethereum’s state architecture:

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

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

• Restricted storage: certain storage can only be accessed via specific interfaces. For example, balances of an ERC20 token might only be accessible through designated functions, enabling optimization.

He also suggests retaining existing state forms. With these, execution could become 1000x cheaper via ZK-EVM, but creating new states might only be 20x cheaper.

Vitalik believes that with new state forms, developers will have options: continue using current state models at higher costs or redesign applications to leverage new, cheaper state forms. Standard workflows will emerge for common cases (ERC20 balances, NFTs), while more complex use cases (DeFi) will require developers to optimize themselves.

This strategy encourages developers to think creatively to reduce costs, ultimately benefiting the broader Ethereum user base.