Bitaigen Research February 27 2026 – Vitalik Buterin Publishes “Hyper‑scaling State by Creating New Forms of State”
On *Ethereum Research* Vitalik Buterin released a lengthy article titled “Hyper‑scaling state by creating new forms of state.”
In the piece, Buterin further clarifies Ethereum’s scaling roadmap. The article examines not only the technical side of scaling but also the overall architecture, presenting a multi‑stage plan intended to lay the groundwork for continuously expanding the network’s capacity over the coming years.
He later posted a series of tweets on X (formerly Twitter) to explain the main points. Below we break down the proposed scaling approach and the motivations behind it in plain language.
From the perspective of the Bitcoin‑Core editorial team, we have compiled Vitalik’s latest five‑year roadmap for Ethereum, dissecting the technical logic and potential impact of execution efficiency, data sharding, and state layering. This guide helps readers grasp the key on‑chain scaling trends; the rest of the article expands on each component in detail. We also discuss the long‑term significance of these solutions for the broader ecosystem.
Short‑Term and Long‑Term Expansion of Execution and Data Resources
At the start of the article, Vitalik writes:
“To scale Ethereum over the next five years, we need to expand three kinds of resources.”
- Execution resources – EVM computation, signature verification, etc.
- Data resources – transaction senders, receivers, signatures, and other payload data.
- State resources – account balances, contract code, and storage.
The first two categories have both short‑term and long‑term upgrade paths.
Execution Resources
| Horizon | Expected uplift |
|---------|-----------------|
| Short‑term | ~10‑30× via Block Access Lists (BAL), ePBS, and gas‑price redesign |
| Long‑term | ~1 000× with a ZK‑EVM; for specialized workloads (signatures, SNARK/STARK) off‑chain aggregation could reach ~10 000× |
Data Resources
| Horizon | Expected uplift |
|---------|-----------------|
| Short‑term | ~10‑20× through p2p improvements and multidimensional gas |
| Long‑term | ~500× via Blobs + PeerDAS |
The short‑term goal is simply to make Ethereum run faster. Today, transaction validation is largely serial – each transaction is checked one after another, and a single stuck transaction stalls the whole verification pipeline.
Accordingly, this year’s Glamsterdam upgrade will introduce Block Access Lists (BAL) and ePBS.
- Block Access Lists let block proposers announce in advance which accounts and storage slots a block will touch. Validators can then preload those pieces of data from disk into RAM, enabling them to parallelise the verification of multiple transactions—much like moving from a single worker completing an entire assembly line to several workers handling different stages simultaneously.
- ePBS (ex‑Post Block‑State) decouples block construction from validation. The *block builder* focuses on packing transactions, the *proposer* on submitting the block, and the *validator* on checking it. With responsibilities split, builders can be more aggressive about including transactions because proposers and validators share the burden of safety checks.
- Gas‑price redesign + multidimensional gas is the core lever. Currently, every operation pays the same gas price. Vitalik argues that different operation types should carry different fees. In particular, creating new state (e.g., opening a fresh account or deploying a contract) should incur a dedicated “state‑creation fee” because it consumes both compute and permanent storage. The idea is to raise the cost of state creation while lowering the fee for ordinary transactions.
The implementation uses a “reservoir mechanism”: imagine two separate pools of funds – one for state‑creation fees and another for regular gas. When contracts call each other, gas is automatically drawn from both pools, ensuring a balanced allocation. For end users, ordinary transactions become cheaper; developers who introduce new state must pay more. This dynamic helps increase overall throughput while curbing unchecked state growth that could otherwise fill full‑node disks.
Long‑Term Expansion
The long‑term ambition is to make the mainnet itself more powerful, reducing reliance on Layer 2 solutions. This involves phased roll‑outs of Blobs + PeerDAS and a ZK‑EVM.
- Blobs are currently a temporary large‑file storage mechanism used by Layer 2s. In the future, the Ethereum base layer will also store blobs. However, if every node had to download *all* blobs, network bandwidth and storage pressure would become untenable.
- PeerDAS (Peer‑sampled Data Availability Sampling) mitigates that problem. Nodes only need to download a small random subset of the total blob data (e.g., 1/16). Coupled with a succinct zero‑knowledge proof, they can still be confident that the whole blob is available, much like a statistical audit where a tiny sample verifies the entire dataset.
- The ZK‑EVM rollout will let nodes verify blocks without re‑executing every transaction. Instead, they check a succinct ZK proof that attests to the correctness of the state transition. Verification cost drops from “run all transactions again” to “verify a single proof.” Vitalik plans a 2026 pilot where a subset of nodes use ZK verification, a 2027 expansion, and eventually each valid block will contain 3 out of 5 different proof types from distinct proof systems. He expects that, apart from specialized indexing nodes, all full nodes will eventually rely on ZK‑EVM proofs.
No Magic Bullet for State Scaling
Now let’s look at the third resource class – state resources – which is not covered by the short‑ or long‑term solutions above. In the short term, synchronising with Block Access Lists, p2p upgrades, and database optimisations could still yield a 5‑30× improvement, but the long‑term picture remains unclear.
Vitalik’s answer: *There is currently no viable, scalable solution.*
Why Is State Hard to Scale?
Ethereum’s state is essentially a massive key‑value database that records every account balance, contract bytecode, and storage slot. At present the database sits around 100 GB. Scaling it 20‑fold would push it to 2 TB, and a further 8‑fold increase would approach 8 TB.
The bottleneck is not disk capacity but two structural issues:
- Database efficiency degrades as the tree (e.g., a Merkle‑Patricia trie) grows. Adding a new leaf forces the entire path up to the root to be recomputed, which triggers many low‑level writes. As the tree deepens, write latency grows exponentially, eventually creating a hard write‑throughput ceiling.
- Sync cost skyrockets. A brand‑new node must download the *entire* state before it can start validating blocks. With a multi‑terabyte state, even a high‑speed residential broadband connection would take days or weeks to sync, hindering decentralisation.
Limits of Existing Proposals
- Strong statelessness – nodes store no state and rely on users to provide Merkle proofs for each accessed item. Vitalik warns that this could centralise storage, cause transaction failures due to dynamic data availability, and increase bandwidth costs.
- State expiry – prune rarely‑used state while keeping recent, active entries. The fundamental challenge is proving non‑existence. For example, when creating a new account, the protocol must demonstrate that the address has *never* been used before, which would require scanning the entire historical state – an operation that is prohibitively expensive.
New Forms of State
Building on those observations, Vitalik sketches several novel state abstractions that would reshape Ethereum’s state architecture:
| Form | Description | Typical Use‑Case |
|------|-------------|------------------|
| Ephemeral storage | Automatically expires (e.g., resets each month). Implemented as a rotating tree. | Order books, liquidity‑pool counters, temporary metrics. |
| Periodic storage | Similar to ephem‑eral but with a longer lifespan, such as one year before reset. | Seasonal incentive programs, time‑bounded governance data. |
| Restricted storage | Accessible only through a predefined interface (e.g., ERC‑20 balances readable solely via the standard `balanceOf` call). | Enables targeted optimisation for high‑frequency token queries. |
The existing canonical state model would continue to exist alongside these alternatives. In the execution layer, the ZK‑EVM could still deliver roughly a 1 000× speed‑up, while the creation fee for the new state types might increase by only ~20×.
Developers can therefore choose:
- Stick with the traditional state model and pay higher creation fees, or
- Redesign contracts to leverage the new state forms, obtaining lower costs.
Common patterns (e.g., ERC‑20 balances, NFT metadata) are likely to converge on standardised workflows using the restricted or periodic storage models. More intricate DeFi constructions will require developers to engineer their own optimisations.
This strategy nudges the community toward cost‑conscious design while still delivering tangible benefits to everyday Ethereum users.
---
*Note for global users:* When converting crypto assets to fiat, USD is the most widely accepted reference currency. Residents of the United States should use Binance.US (or other regulated U.S. exchanges) rather than the global Binance platform. Users in other jurisdictions can typically use Binance.com via SEPA (for EUR) or SWIFT (for other currencies).
*Tax disclaimer:* Crypto gains may be taxable in your local jurisdiction; please consult a qualified tax professional for advice.
💡 Register on Binance with referral code B2345 for the maximum trading fee discount. See Binance complete guide.
⚠️ Risk Disclaimer: Crypto prices are highly volatile. This is not investment advice.
