Summary
Ethereum’s three scaling resources — execution, data, and state — have asymmetric long-term scaling paths. ZK-EVMs solve execution (1000×); PeerDAS solves data (500×); but there is no equivalent “magic bullet” for state. Vitalik (Feb 2026) proposes a barbell solution: keep existing state nearly as-is (it becomes relatively more expensive) while introducing new, much cheaper but more restrictive forms of state — temporary storage and UTXOs — designed from the ground up for high scalability.
The Three Resources
| Resource | Short term | Long term |
|---|---|---|
| Execution | ePBS + BALs → 10–30× | ZK-EVMs → 1000× |
| Data | p2p improvements → 10–20× | BiB + PeerDAS → 500× |
| State | BALs sync + p2p → 5–30× | No magic bullet (this post) |
Why state is different: to build a block you need the full state. Sharding techniques that work for computation and data do not work for state. Decreasing the gas limit does not make state smaller.
Why Existing Approaches Are Insufficient
Strong Statelessness (Rejected for General Use)
- Requires every transaction to include Merkle branch witnesses
- ~1000 bytes per storage slot accessed → simple ERC20 transfer becomes 4 KB
- Backwards incompatible with applications that have dynamic state access patterns (onchain order books, appendable lists)
Cold State
- State not accessed >1 year is “cold” — accessible but with async delay
- Builders don’t need to store it; they ping a decentralized network when needed
- Problem: deep multi-hop dependency graphs; brittle infrastructure dependency
State Expiry
- After ~1 year, inactive state is removed; must be “resurrected” with a proof
- Fatal flaw: when creating new state at address X, you must prove X was never created in any previous year — this requires lookups proportional to Ethereum’s age
- Not backwards-compatible: even with new address-period mechanisms (CREATE3), existing ERC20s use
sha256(...)storage slots, which the protocol cannot understand as “new”
The Barbell Solution
Keep existing state (permanent storage), but accept it becoming relatively more expensive as execution scales:
- Execution may get 1000× cheaper; state creation may only get 20× cheaper
- Creating a new storage slot may eventually cost more than verifying a STARK
Add new, cheaper but restricted forms of state:
1. Temporary Storage
- New tree that zeroes out each period (e.g., 1 month)
- Ideal for: auctions, governance votes, in-game events, fraud proof games
- ERC20 balances on temporary storage: solved via out-of-order resurrection with bitfield tracking to prevent double-spending
- After period N: store a bitfield (1 bit per state entry) in permanent storage
- To resurrect: provide branch proving historical ownership → flip bit → cannot resurrect again
- Scale: 1000× execution × 1-month expiry → ~8 TB temporary state + 16 GB/month permanent bitfield
2. UTXOs
- Zero-expiry version: contracts create records, immediately go to history
- Per-block bitfield stores “spent/unspent” status (permanent, but tiny)
- Can reuse existing LOG mechanism + bitfield on top
- ERC20s, NFTs, CDPs all buildable on UTXOs
- Hybrid: last-month trees directly accessible (no witnesses); older records require witnesses
3. Weak Statelessness Storage Tree
- Requires Merkle branches to access (alternative: nodes store top N-8 levels = 1/256)
- Lives alongside existing tree (witness-required cheap + witness-free expensive)
- Inferior to temporary storage: junk accumulates in tree; Merkle branches for useful state become longer over time
Developer Experience (Sketch)
| State object | Storage type |
|---|---|
| User accounts + AA state | Permanent (always accessible) |
| Smart contract code | Permanent |
| NFTs, ERC20 balances | UTXOs or temporary |
| Auction/governance/fraud-proof games | Temporary |
| Core DeFi contracts | Permanent (composability) |
| Individual CDPs, positions | UTXOs or temporary |
Developers can continue using permanent storage for everything (reasonable fees). Opting into UTXOs/temporary storage achieves very low fees but requires redesigning application logic.
Key Tradeoffs
- Relative price shift: storage becomes vastly more expensive relative to computation at full scale. Mental model of “what is cheaper” inverts from today
- Backwards incompatibility: explicit — Vitalik acknowledges this is a necessary cost; the only viable path
- Developer choice: simple applications keep using permanent storage; DeFi/gaming protocols rewrite to use cheaper storage tiers for high-scalability
Relationship to Existing Work
- BALs (EIP-7928): enable builders to sync state more efficiently, providing ~5–30× short-term improvement. They do not solve the long-term state problem
- VOPS: already a very limited form of tiered state (validator-accessible data below full state)
- Strong statelessness (EIP-161 access lists direction): applicable only for exceptional cold state, not general state
- EIP-2930 access lists: transaction-level, not protocol-level state tiering
Open Questions
- How to standardize ERC20/NFT contracts to use UTXOs while maintaining UX (“if you went in a cave for a month”)?
- When does creating a new storage slot become more expensive than verifying a STARK in practice?
- How do DEXs and lending protocols handle CDPs in UTXOs with complex multi-hop state reads?
- What is the gas pricing model for temporary storage across period boundaries?
Related Pages
- Block-Level Access Lists (BALs) and Parallel Execution (EIP-7928) — Short-term state efficiency; BAL sync improvement
- Data Availability: Blobs, PeerDAS, and Block-in-Blobs — PeerDAS and BiB solve data scaling; state is the remaining gap
- Ethereum Protocol Roadmap 2026 — 1000× scaling goals; Strawmap; zkEVM timeline
- Frame Transactions and Native Account Abstraction (EIP-8141) — AA-VOPS as a limited form of tiered state
Key Sources
- Hyper-scaling state by creating new forms of state (Vitalik Buterin, Feb 2026) — Permanent vs. temporary vs. UTXO storage; developer experience sketch; barbell solution rationale