State growth is exponential. Every new smart contract, NFT mint, and wallet creation permanently expands the state trie. This data must be stored and accessed by every full node, creating a centralizing force that pushes node operators to expensive hardware.
the-ethereum-roadmap-merge-surge-verge
Blog
Ethereum Without Massive State Databases
An analysis of Ethereum's existential state growth problem and the technical path—Stateless Ethereum and Verkle trees—to preserve decentralization while enabling mass scalability.
introduction
THE STATE BLOAT
The Unspoken Crisis: Ethereum is Drowning in Its Own Data
Ethereum's core scaling bottleneck is its ever-growing, mandatory state database, not raw transaction throughput.
The bottleneck is access, not execution. Modern L2s like Arbitrum and Optimism demonstrate that execution is cheap. The real cost is proving state transitions back to L1, where calldata and storage proofs consume the most gas.
Statelessness is the only viable path. The Verkle tree transition and concepts like EIP-4444 (history expiry) aim to make nodes stateless verifiers. This shifts the data burden to a decentralized network of portal clients.
Evidence: Ethereum's state size exceeds 200GB and grows by ~50GB/year. A solo staker today needs 2TB SSDs, a requirement that doubles every 4 years without intervention.
key-trends
THE SYBIL IN THE MACHINE
Why State Bloat is an Existential Threat
Ethereum's state—the ledger of every account, contract, and balance—grows perpetually, creating a silent tax on every node and a centralizing force that undermines the network's core value proposition.
01
The Node Choke Point
Full nodes must store the entire state history, requiring terabytes of fast SSD storage and hundreds of GB of RAM. This creates prohibitive hardware costs, pushing validation to centralized providers like Infura and Alchemy, reintroducing single points of failure.
- Centralization Risk: <10% of nodes can sync the chain from genesis.
- Hardware Spiral: Requirements double every ~2-3 years, outpacing consumer tech.
2+ TB
State Size
>90%
Infura Reliance
02
The Gas Fee Anchor
Every state access (SLOAD) and modification (SSTORE) is priced in gas. A bloated, unoptimized state tree increases the computational overhead for these operations, making base-layer transactions permanently expensive and pushing activity to L2s not as a choice, but as a necessity.
- Inefficient Access: Deep Merkle Patricia Trie lookups get slower as it grows.
- L2 Dependence: Becomes a structural, not strategic, requirement.
~2100 gas
Base SLOAD Cost
$10B+ TVL
L2 Escape Hatch
03
Verkle Trees & Statelessness
The canonical solution is a shift to Verkle Trees (enabling stateless clients) and EIP-4444 (historical expiry). Nodes would only need a tiny proof of relevant state, not the entire database. This is a first-principles rewrite of Ethereum's data model.
- Stateless Clients: Validators need only block headers and proofs.
- History Expiry: Old chain data moves to decentralized storage (e.g., Ethereum Portal Network, BitTorrent).
~1 MB
Proof vs. 2 TB
Post-2025
Target Timeline
04
The Rollup Scaling Fallacy
Rollups (Arbitrum, Optimism) batch transactions but ultimately post their state roots and proofs back to L1. They amplify, not solve, state growth on the settlement layer. Each rollup's compressed activity still inflates the L1 state, making the core problem worse for the systems meant to save it.
- Data Availability: All L2 transaction data still hits L1 (as calldata or blobs).
- Settlement Overhead: Finality requires L1 state updates, consuming resources.
100x TPS
But 10x State Growth
Proto-Danksharding
Partial Relief
05
Modular Chains vs. Integrated Solutions
Alternative architectures like Celestia (modular DA) and Monad (parallel EVM) attack the problem differently. They separate execution from consensus/data availability or use advanced execution engines to process state changes more efficiently, reducing the burden on any single layer.
- Data Availability Layers: Specialized chains for cheap blob storage.
- Parallel Execution: Processes unrelated state changes simultaneously, improving hardware utilization.
10,000+ TPS
Theoretical Cap
-99%
DA Cost
06
The Economic Time Bomb
Unchecked state growth makes running a node a negative-sum game for anyone not extracting massive MEV or staking rewards. This erodes the credible neutrality and censorship resistance that gives the chain value. The network's security budget becomes a subsidy for state storage, not validation.
- Validator Attrition: Rising costs push out smaller operators.
- Security/Decentralization Trade-off: Becoming a permanent trilemma.
$1M+
Annual Node Cost
Existential
Risk Level
deep-dive
THE STATE CRISIS
Deconstructing Statelessness: From Merkle-Patricia to Verkle
Ethereum's statelessness upgrade replaces its bloated state database with cryptographic proofs, enabling nodes to validate without storing terabytes of data.
Statelessness is a paradigm shift from storing state to verifying proofs. A node downloads a witness (a cryptographic proof of state) with each block instead of holding the entire state trie. This reduces the hardware requirement from terabytes to gigabytes, enabling lightweight clients and decentralized staking pools like Rocket Pool to scale.
The Merkle-Patricia Trie is obsolete for this purpose. Its proof sizes are too large (kilobytes per transaction) because each node hash depends on all child hashes. The Verkle Trie uses vector commitments, allowing constant-size proofs regardless of tree depth. This is the cryptographic prerequisite for practical stateless verification.
Verkle trees enable stateless clients, which only need the block header and a witness. This architecture mirrors zk-rollups like zkSync, where validity is proven, not re-executed. The Ethereum execution layer becomes a verification engine, not a storage system, drastically lowering the barrier to running a node.
Evidence: Current Ethereum state growth exceeds 1 TB. A Verkle proof for a simple transfer is ~150 bytes, versus ~1 KB for a Merkle proof. This 85% reduction makes statelessness feasible for the first time.
ETHEREUM STATELESSNESS SOLUTIONS
State Growth: The Hard Numbers
Comparison of approaches to mitigate Ethereum's state bloat, a primary bottleneck for node decentralization and sync times.
| Metric / Feature | Full Archive Node (Baseline) | Verkle Trees (EIP-6800) | Stateless Clients (Theoretical) | History Expiry (EIP-4444) |
|---|---|---|---|---|
Current State Size (GB) | ~15,000 GB | N/A (Future) | N/A (Theoretical) | ~15,000 GB |
Witness Size per Block | N/A | < 250 KB | 1-2 MB | N/A |
Sync Time (Full Archive) | 6-8 weeks | Projected: < 1 week | Projected: < 1 day | 6-8 weeks |
Node Storage Requirement |
| Projected: ~2 TB SSD | < 500 GB SSD |
|
State Growth Rate (Annual) | ~100 GB | ~100 GB | ~100 GB | ~0 GB (for pruned history) |
Backward Compatibility | ||||
Requires Hard Fork | ||||
Primary Benefit | Complete historical access | Enables stateless verification | Ultra-light node sync | Caps storage bloat |
counter-argument
THE TRADEOFF
The Devil's Advocate: Is Statelessness Over-Engineering?
Statelessness solves a real scaling problem but introduces massive complexity that may not justify its benefits for most L2s.
Statelessness is a nuclear option for a problem that rollups have already contained. Ethereum's state growth is a threat to solo stakers, but L2s like Arbitrum and Optimism operate with centralized sequencers and bounded state. Their execution environments are already isolated from Ethereum's state bloat.
The complexity cost is prohibitive. Implementing Verkle trees and witness protocols requires a fundamental re-architecture of the EVM. This development overhead distracts from higher-impact scaling vectors like data availability layers (Celestia, EigenDA) and parallel execution.
The primary beneficiary is decentralization, not throughput. Statelessness preserves the solo staker model by removing the need for massive SSDs. For applications, the tangible benefit is marginal compared to existing ZK-rollup (zkSync, Starknet) scaling.
Evidence: The Ethereum roadmap prioritizes Proto-Danksharding (EIP-4844) before full statelessness. This sequence reveals the pragmatic assessment: improving data availability for rollups delivers more immediate scaling than the multi-year statelessness overhaul.
protocol-spotlight
STATELESS FUTURE
Builders in the Trenches: Who's Preparing Now?
The path to a scalable, stateless Ethereum is being paved by teams solving the hardest data availability and verification problems today.
01
Celestia: The Data Availability Layer
Decouples execution from consensus and data availability, enabling rollups to post data cheaply without bloating Ethereum.\n- Enables stateless rollups via Data Availability Sampling (DAS) and Namespaced Merkle Trees.\n- Radical cost reduction for L2s; posting data is ~100-1000x cheaper than calldata on Ethereum mainnet.
~100-1000x
Cheaper Data
Modular
Architecture
02
Ethereum's Verkle Trees & Stateless Clients
Core protocol upgrade replacing Merkle Patricia Tries with Verkle Trees, enabling stateless clients and ultra-light nodes.\n- Proof size reduction from ~300 KB to ~150 bytes, making witness-based validation feasible.\n- Eliminates the state growth bottleneck, allowing nodes to verify blocks without storing the entire world state.
~150 bytes
Witness Size
Prague/Electra
Target EIP
03
zkSync & StarkNet: Native Stateless Provers
ZK-Rollups are inherently stateless-friendly; their validity proofs verify state transitions without re-executing history.\n- State diffs, not full tx data: Post only minimal state changes, not full transaction inputs.\n- Leverages Ethereum as a DA layer today, but can seamlessly switch to cheaper alternatives like Celestia or EigenDA.
ZK-Native
Architecture
State Diffs
Data Model
04
EigenDA: Restaking for High-Throughput DA
Leverages Ethereum's economic security via restaking to provide a high-throughput Data Availability layer for rollups.\n- Capital-efficient security derived from $10B+ in restaked ETH.\n- Designed for hyperscale with 10-100 MB/s data throughput targets, directly serving the stateless execution future.
$10B+
Security Pool
10-100 MB/s
Throughput
05
The Portal Network: Light Client Supremacy
A peer-to-peer network of lightweight clients that collectively serve Ethereum's state, making full nodes optional.\n- Distributes state across thousands of nodes via Distributed Hash Table (DHT).\n- Enables true stateless verification for wallets and dApps, accessing state on-demand without trust.
P2P DHT
Network
Light Clients
Target
06
Fuel: Parallelized Stateless Execution
A parallel execution engine built from first principles for a stateless environment, using UTXOs and strict state access lists.\n- Native support for state diffs and fraud proofs in a modular stack.\n- Achieves maximal throughput by eliminating contention; performance scales with cores, not consensus.
Parallel
Execution
UTXO Model
State
future-outlook
THE HARDWARE FLOOR
The Verge Timeline: Pragmatic Optimism for Node Operators
Verkle Trees and EIP-4444 will collapse Ethereum's state growth, making solo staking viable on consumer hardware.
Verkle Trees are the catalyst. They replace Merkle Patricia Tries with polynomial commitments, collapsing witness sizes from ~1 MB to ~150 bytes. This directly enables stateless clients, where validators no longer store the full state.
EIP-4444 enforces the purge. It mandates clients prune historical data older than one year, delegating it to decentralized networks like the Portal Network or specialized indexers. This cuts the required storage from multi-TBs to ~500 GB.
The hardware floor drops. Post-Verge, a solo validator runs on a modern laptop with an NVMe SSD, not a server rack. This reverses centralization pressure from professional node services like Infura and Bloxroute.
Evidence: The current Ethereum archive node requires ~12TB. Post-EIP-4444, a consensus client needs <1TB. Verkle proofs reduce bandwidth for block propagation by ~99%, enabling global participation.
takeaways
THE STATELESS FUTURE
TL;DR for CTOs and Architects
Ethereum's state growth is an existential scaling threat. These are the core strategies to build without it.
01
The Problem: The State Bloat Tax
Full nodes require storing the entire ~1TB+ state, centralizing infrastructure and raising sync times to weeks. Every transaction pays a hidden tax for this global synchronization.
- Cost: Node ops spend $10k+/month on fast SSD arrays.
- Risk: Leads to <5,000 full nodes, creating systemic fragility.
1TB+
State Size
<5k
Full Nodes
02
The Solution: Verkle Trees & Stateless Clients
Replace Merkle Patricia Tries with Verkle Trees, enabling stateless validation. Clients verify blocks with tiny ~1KB proofs instead of storing state.
- Impact: Node requirements drop from TB SSD to ~GB RAM.
- Goal: Enable 1M+ lightweight validators, radically decentralizing consensus.
~1KB
Witness Size
1M+
Node Target
03
The Bridge: EIP-4444 & History Expiry
Prune historical data older than 1 year from execution clients. Nodes serve expired data via decentralized networks like Portal Network or BitTorrent.
- Result: Client disk needs drop by ~90%.
- Ecosystem: Enables light clients as first-class citizens for wallets and dApps.
-90%
Disk Use
1 Year
Retention
04
The Execution Layer: Rollups & Specialized DA
Push execution and most state off-chain. Rollups (Arbitrum, Optimism) post minimal data to L1. Validiums (StarkEx) and Volitions use external Data Availability layers like Celestia or EigenDA.
- Scale: Reduces L1 state growth by 100-1000x per transaction.
- Trade-off: Introduces DA security assumptions beyond Ethereum.
100-1000x
Growth Reduction
$0.001
Target Tx Cost
05
The Endgame: PeerDAS & Full Separation
Ethereum's PeerDAS (Peer-to-Peer Data Availability Sampling) fragments blob data across the network. This completes the separation: consensus secures data availability, execution is verified via proofs.
- Vision: A network where no single node holds all the data.
- Foundation: Enables massively scalable L2s without increasing L1 state.
1.3 MB/s
Target Blob Throughput
100%
Data Redundancy
06
The Architect's Choice: Statefulness as a Service
Protocols like EigenLayer, Espresso, and AltLayer offer shared sequencing and state management. Your app doesn't manage state; it rents security and synchronization from a decentralized marketplace.
- Shift: From infrastructure ops to economic security.
- Efficiency: Pooled resources slash costs for high-frequency state apps.
Shared
Sequencing
Market
Security
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