On February 27, 2026, Vitalik Buterin published a lengthy 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. Rather than addressing Ethereum scaling solely from a technical perspective, the article provides a comprehensive, phased architectural strategy designed to lay the foundation for sustained network capacity growth over the coming years.
At the same time, he 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 begins the long-form post by stating, "To scale Ethereum over the next five years, three resources need to be scaled":
- Execution resources: EVM computation, signature verification, etc.
- Data resources: sender, recipient, signature, and other transaction details
- Status resources: account balance, code, storage
The first two have short-term and long-term expansion plans.
For execution scalability, short-term gains of 10x to 30x will be achieved through Block Access Lists (BAL), ePBS, and gas fee repricing; long-term gains of approximately 1000x will come from ZK-EVM. Additionally, for certain 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 enabled by Blobs + PeerDAS.
Short-term expansion focuses on making Ethereum run faster. Currently, Ethereum is slow because its verification process is sequential—transactions are checked one after another. If one transaction gets stuck, the entire verification process halts.
Therefore, this year's Glamsterdam upgrade will introduce Block Access Lists (BAL) and ePBS.
The access list allows block proposers to inform validators in advance: “The transactions in this block will access these accounts and storage locations.” With this information, validators can preload the relevant 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 simultaneously handle different parts.
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 verify their work, eliminating security concerns.
Gas fee repricing combined with multidimensional gas could be considered a “core move.” Currently, all operations on Ethereum 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: make creating new state more expensive, but make regular transactions cheaper.
The method implemented is the "reservoir mechanism." Imagine two tanks: one holds "state creation fees," and the other holds "standard gas fees." When contracts call each other, gas is automatically borrowed from both tanks to ensure everything stays in order.
Transactions by regular users will become cheaper since they won't be charged a "state creation fee." Developers wishing to create new state, 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 becoming overwhelmed.
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 mechanism currently used primarily by Layer 2 solutions, will eventually be used by Ethereum's mainnet itself to store data. However, a problem arises—if every node must download all blobs, the network would 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 subset is enough to infer the status of the entire group. 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, nodes 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, select 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 types of proofs from different proof systems. He expects that, in the end, all nodes—except indexing nodes—will 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 syncing 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 so difficult to scale? 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 would reach 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 new data, the entire tree must be updated. This means that if you perform X updates, the database must execute X separate operations—not just one operation to update once. The more updates, the more operations, causing write speeds to plummet.
- 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; they only require 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": Infrequently accessed states are automatically removed from active status. Nodes only need to store recently accessed states, significantly reducing storage requirements. Vitalik identifies a fundamental "problem" with this approach: when creating a new state, how do you prove that a particular state "never existed"? For example, when creating a new account, you must prove that the new account’s address has never been created on Ethereum. This means that every new account creation would require checking 10 years of historical data, making account creation complex and expensive.
Vitalik's final approach combines both solutions by introducing several new forms of state, representing 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 storage is suitable 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 designated interface, allowing the system to optimize such storage.
At the same time, retain the existing state format. This means execution could be up to 1,000 times cheaper (via ZK-EVM), but creating new state might 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—like DeFi—developers will need to devise their own optimization strategies.
This strategy is quite interesting, somewhat like developers using their ingenuity to reduce costs, benefiting Ethereum users broadly.