On February 27, 2026, Vitalik Buterin published a long article on Ethereum Research titled "Hyper-scaling state by creating new forms of state."

In this article, Vitalik Buterin further outlines Ethereum's scaling roadmap. This piece does not merely discuss Ethereum scaling from a technical perspective, but rather provides a comprehensive, phased architectural approach designed to lay the foundation for Ethereum’s continued network capacity growth over the coming years.

At the same time, he also posted a tweet on X further explaining the article. We aim to break it down simply to understand what Vitalik’s newly proposed scaling solution is, and why he is doing it.

Short-term and long-term expansion of computational and data resources

Vitalik points out at the beginning of the long-form post, "To scale Ethereum over the next five years, three resources need to be scaled":

- Execution resources: EVM computation, signature verification, etc.

- Data resources: sender, receiver, signature, etc. of the transaction

- Status resources: account balance, code, storage

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

For execution scalability, short-term gains of 10-30x will be achieved through Block Access Lists (BAL), ePBS, and gas fee repricing, while long-term gains of approximately 1000x will come from ZK-EVM. For certain specific types of computations—such as signatures and SNARKs/STARKs—off-chain aggregation can improve performance by up to 10,000x.

For data resources, short-term growth of approximately 10-20x will be achieved through P2P improvements and multidimensional gas, while long-term growth of approximately 500x will be realized through Blobs + PeerDAS.

Short-term expansion focuses on making Ethereum run faster. Currently, Ethereum is slow because its validation method is sequential—transactions are checked one after another. If one transaction gets stuck, the entire validation process halts.

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

The access list allows block producers to inform validators in advance: “The transactions in this block will access these accounts and storage locations.” With this information, validators can preload the required data from disk into memory. This enables validators to check multiple transactions in parallel rather than one at a time—similar to an assembly line: previously, one worker handled the entire product; now, multiple workers process different parts simultaneously.

ePBS separates the processes of block building and validation—block builders are responsible for packaging transactions, proposers for proposing blocks, and validators for verifying blocks. Each role focuses on its specific task, allowing block builders to more aggressively package more transactions, since proposers and validators will check for security, eliminating the need to worry about safety issues.

Gas fee repricing + multidimensional gas could be called a “core move.” Currently, all Ethereum operations use the same gas fee. But Vitalik’s idea is that different operations should have different prices.

In particular, creating new state (such as creating a new account or deploying a new contract) should incur a special "state creation fee," as creating new state is the most expensive operation—it consumes not only computational resources but also storage resources, and this cost is permanent: once created, the state persists indefinitely.

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

The method implemented is the "reservoir mechanism." Imagine two buckets: one holds "state creation fees," and the other holds "standard gas fees." When contracts call each other, gas is automatically borrowed from both reservoirs to ensure everything stays in order.

Transactions by regular users will become cheaper because they won't be charged a "state creation fee." Developers who wish to create new states, however, will need to pay higher fees. This significantly increases the network's overall capacity while keeping state growth in check, preventing full nodes' hard drives from overflowing.

Long-term expansion involves strengthening the mainnet itself and reducing reliance on Layer 2 solutions. This includes the phased rollout of Blobs + PeerDAS and ZK-EVM.

Blobs, a temporary large-file storage solution, are currently primarily used by Layer 2s. In the future, the Ethereum mainnet will also use Blobs to store data. But a problem arises—if every node must download all Blobs, the network will be overwhelmed.

This is where PeerDAS comes in—you don’t need to download all the data, just a small portion. Like a sample survey, you don’t need to ask everyone; asking a small group is enough to infer the status of the entire population. Combined with ZK proofs, even if you only download 1/16 of the total data, you can still verify its integrity.

Then comes the phased rollout of ZK-EVM, which eliminates the need for nodes to re-execute all transactions in a block—instead, they can simply trust the ZK proof, reducing verification cost from "executing all transactions" to "verifying a single ZK proof."

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

No "magic bullet" state expansion

Now let’s examine the “state resources” not yet covered in short-term versus long-term scaling. While short-term improvements such as synchronization with block access lists, p2p enhancements, and database optimizations can still boost performance by 5 to 30 times, what about the long term?

Vitalik's answer is no.

Why is state scaling so difficult? Ethereum’s state is like a massive database. This database stores the balances of all accounts, the code of all contracts, and the data in all storage locations.

This database is still small, at only about 100 GB, but if the state expands 20 times, it will be 2 TB. What about longer-term? 8 TB?

The issue is not that the hard drive doesn't have enough space, but rather:

- Database efficiency is impacted: Modern databases organize data using tree structures (such as Merkle trees). When writing a new piece of data, the entire tree must be updated. This means that if you perform X updates, the database must perform X operations, rather than completing one update with a single database operation. The more updates, the more operations—and write speeds can slow to a crawl.

- Synchronization challenges: A new node joining the Ethereum network must download the entire state to verify new blocks. With data sizes reaching 8 TB, most users’ current internet speeds would require a very long time to download.

Solutions exist, but Vitalik believes they all have issues:

- "Strong statelessness": Nodes do not need to store the full state, only requiring users to provide Merkle proofs. Vitalik believes this approach has issues with centralized state storage, transaction failures due to dynamic state access, and bandwidth costs.

- "State expiration": States that are infrequently accessed are automatically removed from active status. Nodes only need to store recently accessed states, significantly reducing storage requirements. Vitalik identifies a fundamental "problem" — when creating a new state, how to prove that a certain state "never existed." For example, when creating a new account, one must prove that the new account address has never been created on Ethereum. This means that creating each new account requires checking 10 years of historical data, making account creation complex and expensive.

Vitalik’s final approach combines both solutions, proposing several new forms of state—an overall change to Ethereum’s state resource architecture:

- Temporary storage: A type of storage that automatically expires. For example, a new tree can be created that resets automatically each month. This type of storage is ideal for temporary data such as order books, liquidity pools, and temporary counters—data that typically does not require permanent retention. After a month, old orders expire and new liquidity pools are created.

- Periodic storage: Similar to temporary storage, but with a longer duration, 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 a specific interface, allowing the system to optimize this storage.

Meanwhile, preserve the existing state format. This means execution may be up to 1,000 times cheaper (via ZK-EVM), but new state creation may only be 20 times cheaper.

Vitalik believes that with the new state format, developers have a choice: continue using the existing state format but pay higher fees, or redesign their applications to use the new state format and enjoy lower fees. For common use cases (such as ERC20 balances and NFTs), standardized workflows will be available, while for more complex use cases (such as DeFi), developers will need to devise their own optimization strategies.

This strategy is quite interesting, somewhat like developers using their ingenuity to reduce costs, with the broader Ethereum user base benefiting as a result.

Click to learn about the open positions at BlockBeats

Welcome to the official BlockBeats community:

Telegram subscription group: https://t.me/theblockbeats

Telegram group: https://t.me/BlockBeats_App

Official Twitter account: https://twitter.com/BlockBeatsAsia