State is the bottleneck. Transaction execution is cheap; the permanent storage of its resulting state is not. Every new smart contract, token, or NFT adds kilobytes to the global state that every node must store and process forever.
the-ethereum-roadmap-merge-surge-verge
Blog
What Makes Ethereum Storage Hard to Fix
Ethereum's state bloat is a critical bottleneck for scalability and decentralization. This analysis dissects the technical debt, economic disincentives, and consensus-layer complexity that turn storage upgrades into a multi-year, high-stakes puzzle.
introduction
THE STORAGE PROBLEM
The Elephant in the Room: Ethereum's Unbounded State
Ethereum's core scaling bottleneck is not compute or bandwidth, but the unbounded, permanent, and expensive growth of its state.
Statelessness is the goal. The canonical solution is a shift to stateless clients, where validators verify proofs of state changes without storing the full state. This requires widespread adoption of Verkle trees to make proofs efficient.
The transition is painful. Migrating from Merkle-Patricia to Verkle trees is a hard fork-level event requiring coordinated upgrades across all clients and tooling. Interim solutions like state expiry (EIP-4444) face complex data availability challenges.
Evidence: The Ethereum state size exceeds 1 Terabyte and grows by ~50 GB/year. Projects like zkSync and Starknet avoid this via validity proofs and off-chain data availability, demonstrating the architectural advantage of not inheriting Ethereum's state model.
key-trends
THE STATE TRILEMMA
The Core Constraints: Why Storage is a Multi-Front War
Scaling Ethereum's state is not a single problem, but a battle across three fundamental and conflicting dimensions.
01
The State Bloat Problem: Exponential Growth vs. Fixed Bandwidth
Ethereum's state grows with every new contract and user, but node hardware and network bandwidth do not. This creates a centralizing force, pricing out solo validators.
- State size has grown to ~1 TB+, requiring high-end SSDs.
- Synchronization time for new nodes can take weeks, harming decentralization.
- Every 100k gas of execution permanently increases global state by ~1KB.
~1 TB+
State Size
Weeks
Sync Time
02
The Access Cost Problem: Merkle Proofs Are Not Free
Reading and proving state is computationally expensive. Every SLOAD opcode and Merkle proof verification adds overhead, directly capping throughput and inflating gas costs.
- ~2100 gas base cost for a cold
SLOAD. - ZK-EVMs like zkSync and Scroll must prove state accesses, making proofs heavier.
- This is the core bottleneck for scaling rollup execution on L1.
2100 gas
Base SLOAD Cost
~40%
Tx Gas Overhead
03
The Statelessness Frontier: Verkle Trees & EIP-4444
The canonical solution path replaces Merkle Patricia Tries with Verkle Trees for efficient stateless clients and enforces state expiry via EIP-4444. This is a multi-year protocol overhaul.
- Verkle Trees reduce witness sizes from ~1 KB to ~150 bytes.
- EIP-4444 will prune historical data older than 1 year from execution clients.
- Creates a new market for portal network and historical data providers.
~150 bytes
Verkle Witness
1 Year
State Retention
04
The Layer-2 Escape Hatch: Rollups as State Silos
Rollups like Arbitrum, Optimism, and zkSync externalize state growth to their own networks, but merely shift the problem. Their sequencers now face the same trilemma, leading to centralized sequencers and proprietary data availability solutions.
- Arbitrum Nitro state is ~500 GB and growing.
- Forces reliance on EigenDA, Celestia, or expensive L1 calldata.
- Highlights the need for scalable DA layers as a primitive.
~500 GB
L2 State Size
$0.001
Target DA Cost/Tx
05
The Economic Problem: Who Pays for Forever?
Users pay a one-time gas fee to write state, but the network bears the perpetual cost of storing and serving it. This is a massive subsidy and economic misalignment.
- Uniswap v3 factory contract: ~$3M in creation gas, > $0 in ongoing storage fees.
- Proposals like State Rent or Regenerative Storage have failed due to complexity.
- Current model incentivizes state pollution and contract spam.
$3M
Creation Cost
$0
Ongoing Rent
06
The Specialized DA Layer: Celestia, EigenDA, Avail
A new architectural split: decouple data availability and consensus from execution. This allows L2s to post cheap data commitments, pushing state growth onto specialized networks.
- Celestia scales DA with data availability sampling (DAS).
- EigenDA leverages Ethereum's restaking security for ~10 MB/s blob throughput.
- Reduces L2 costs but introduces new trust assumptions and bridging complexity.
~10 MB/s
DA Throughput
-99%
vs. L1 Calldata Cost
deep-dive
THE CORE CONSTRAINT
The Trilemma of State Management: Performance, Decentralization, Backwards Compatibility
Ethereum's state growth is constrained by a fundamental trilemma where improving one axis degrades another.
State growth is exponential. Every new account, NFT, and ERC-20 token permanently expands the global state, increasing hardware requirements for node operators and threatening decentralization.
Performance requires pruning. Solutions like stateless clients or state expiry (EIP-4444) reduce storage load but break backwards compatibility for older nodes and require complex witness data.
Decentralization demands full nodes. Maintaining a full archival node is the gold standard for trust but requires storing over 15TB of data, a barrier that centralizes infrastructure.
Evidence: The Verkle Trie upgrade aims to enable stateless validation, but its deployment timeline is measured in years due to the immense complexity of upgrading Ethereum's core data structure.
THE COST OF PERSISTENCE
The State of the State: Quantifying the Bloat
A comparison of the primary data structures and scaling proposals for Ethereum's state, highlighting the core trade-offs in storage, access, and decentralization.
| Core Metric / Feature | Merkle Patricia Trie (Current) | Verkle Trees (EIP-6800) | Stateless Clients / State Expiry |
|---|---|---|---|
State Size (Approx.) | ~200 GB & Growing | ~50 GB (Projected) | ~0 GB (Client-Side) |
Witness Size for a Block | ~1-2 MB | < 250 KB | ~10-20 KB |
Proof Size per Account Access | ~3 KB | ~150 Bytes | < 100 Bytes |
Supports Stateless Validation | |||
Requires Historical Data Pruning | |||
Node Storage Requirement | Full Archive (~12 TB) | Full (~200 GB) | Minimal (< 50 GB) |
Primary Bottleneck | Disk I/O for State Reads | Prover Computation | Witness Bandwidth & Availability |
Implementation Timeline | Live | Post-Prague/Electra (2025+) | Research Phase (EIP-4444) |
risk-analysis
THE STATE SIZE CRISIS
The Bear Case: What Could Go Wrong with Storage Upgrades?
Ethereum's core scaling challenge is not compute, but the relentless, expensive growth of its state. Fixing it risks breaking the network's core guarantees.
01
The Problem: State Bloat is a Security Tax
Every full node must store the entire state (~1TB+), creating a massive centralization force. The cost to sync and run a node is a security tax that pushes validation to centralized providers like Infura and Alchemy.\n- State grows ~50 GB/year, compounding the problem.\n- Node count is inversely correlated with state size, threatening Nakamoto Consensus.
1TB+
State Size
-70%
Node Decline
02
The Solution: Statelessness & History Expiry
The canonical roadmap (Verkle Trees, EIP-4444) aims to make nodes stateless. Clients would store only block headers and proofs, not the full state. Old history would expire, capping storage requirements.\n- Verkle Trees enable ~1 MB proofs vs. today's ~300 MB.\n- EIP-4444 would prune history >1 year, requiring decentralized archives.
1 MB
Proof Size
1 Year
History Kept
03
The Risk: Breaking Light Clients & Tooling
Statelessness and history expiry break fundamental assumptions. Wallets, explorers, and indexers that rely on full historical access will fail without new infrastructure. This creates a massive coordination problem for the entire ecosystem.\n- The Graph and Etherscan need new data pipelines.\n- Light clients must evolve to use new proof systems.
100%
Tooling Rework
High
Coordination Risk
04
The Risk: Weak Subjectivity & Reorgs
Pruning history introduces weak subjectivity: new nodes must trust a recent checkpoint. This opens attack vectors for long-range reorgs if an attacker can obscure the canonical chain. The security model shifts subtly from pure Nakamoto Consensus.\n- Requires social consensus on checkpoint blocks.\n- Increases reliance on client diversity and honest majority.
7 Days
Checkpoint Window
New
Attack Vector
05
The Risk: Execution Layer Fragmentation
Solutions like EIP-4844 (blobs) and Danksharding push data to a separate layer. This creates a two-tiered data system where availability and execution are decoupled. If the data layer fails or censors, execution fails. It's a complexity explosion for core devs.\n- Celestia and EigenDA compete as external data layers.\n- Introduces new liveness assumptions.
2-Tier
Data System
High
Dev Complexity
06
The Risk: The Inertia of $200B+
Ethereum is a $200B+ live system. Any storage upgrade must be backwards compatible and activated via contentious hard fork. The risk of a chain split or critical bug is existential. Progress is gated by the slowest, most conservative client team.\n- Geth's dominance (>80%) is a systemic risk for upgrades.\n- Political inertia can stall fixes for years.
$200B+
At Risk
>80%
Client Dominance
future-outlook
THE STATE BOTTLENECK
The Long Road to Statelessness: A Pragmatic Timeline
Ethereum's state growth is a fundamental scaling constraint that demands a multi-year, multi-phase solution, not a single upgrade.
State is the bottleneck. The global state—the database of every account and smart contract—must be stored and processed by every node, creating a centralizing force that limits throughput and increases hardware costs.
Verkle Trees are the prerequisite. The current Merkle-Patricia Trie structure is too inefficient for stateless verification. The shift to Verkle Trees, a more complex cryptographic accumulator, enables proofs small enough for block propagation.
Full statelessness is a spectrum. The endgame is where validators verify blocks without storing state, but clients like Geth and Erigon will implement intermediate steps like state expiry and history expiry to manage growth.
The timeline is 2025-2027. Verkle integration is the 2025 milestone. Full stateless validation, requiring widespread client adoption of new proof formats, is a post-2026 target, contingent on ecosystem tooling readiness.
takeaways
THE STATE ROOT BOTTLENECK
TL;DR for Protocol Architects
Ethereum's storage isn't just expensive; it's a first-principles constraint on scalability, security, and decentralization.
01
The 256-Bit Prison
The Merkle Patricia Trie requires a full state root hash for consensus, forcing every node to store and compute over the entire state. This creates an O(n) scaling problem for validators.
- State size grows ~50 GB/year, compounding the sync burden.
- Statelessness is the only escape, shifting proof burden to users via Verkle tries and witnesses.
~1 TB
Full Archive Node
O(n)
Sync Complexity
02
The Gas Price Mismatch
Storage opcodes (SSTORE) are priced for worst-case historical growth, not current hardware. This creates permanent economic distortion.
- One-time write costs ~20k gas, but subsidizes future reads for all.
- Solutions like EIP-4444 (historical expiry) and state rent are politically toxic; they break composability or require invasive protocol changes.
20k gas
Base SSTOREs
~0%
Utilization
03
The Data Availability Choke Point
Rollups must post data to L1 for security, making Ethereum a ~80 KB/sec data availability layer. This cap defines all L2 throughput.
- Proto-danksharding (EIP-4844) introduces blobs to decouple DA from execution gas, targeting ~1.5 MB/sec.
- The core trade-off remains: more DA bandwidth directly weakens small node viability, pressuring decentralization.
80 KB/s
Current DA Cap
10-100x
Blob Scaling
04
The Execution Layer Anchor
Storage isn't just data; it's synchronized global state enabling atomic composability. Any 'fix' that breaks this breaks Ethereum's core value proposition.
- Alt-VMs (Fuel, Solana) optimize for state growth by sacrificing this model, opting for local state and parallel execution.
- Ethereum's path (Verkle, PBS, Danksharding) is a multi-year, conservative upgrade to preserve atomic composability at higher scale.
Atomic
Composability
5+ years
Roadmap
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall