State is the database. Ethereum's state is the global ledger of all account balances, smart contract code, and storage. Every full node must store and update this entire dataset to validate new blocks, creating a massive hardware burden.
the-ethereum-roadmap-merge-surge-verge
Blog
Ethereum Without State: What That Actually Means
The Verge's stateless client model uses Verkle trees and witnesses to decouple execution from storage. This is the final piece for sustainable scalability, enabling ultra-light nodes and ending the hardware arms race.
introduction
THE BOTTLENECK
The State is the Problem
Ethereum's state growth is the primary constraint on decentralization, security, and scalability.
State growth is exponential. Each new account, NFT mint, or DeFi interaction adds permanent data. This state bloat forces node operators to upgrade hardware constantly, centralizing the network around professional entities.
Statelessness is the solution. The core research, like Verkle Trees and EIP-4444, aims to separate execution from historical data. Validators will only need a cryptographic proof of state, not the full data, radically lowering node requirements.
Witness size is the trade-off. Stateless clients require 'witnesses'—proofs that a transaction's data is valid. The challenge is compressing these proofs; current Verkle Tree prototypes target ~200 byte witnesses, a 20-30x improvement over Merkle proofs.
key-trends
THE SCALING BOTTLENECK
The State of the State: Why This Matters Now
Ethereum's state is its greatest asset and its primary constraint. Managing it defines the next era of scaling.
01
The Problem: The State Bloat Tax
Every full node must store the entire history and state (~1TB+), creating a centralizing force and a hard scaling limit. This imposes a tax on every user through:\n- Exponentially growing sync times (weeks for new nodes)\n- High hardware requirements (>2TB SSD, 32GB RAM)\n- Inelastic block space limiting TPS
1TB+
State Size
~2 Weeks
Sync Time
02
The Solution: Stateless Clients & Verkle Trees
Decouple execution from storage. Clients verify blocks using cryptographic proofs instead of holding full state. This is enabled by:\n- Verkle Trees: Replacing Merkle Patricia Tries for efficient (~1KB) witness proofs.\n- Witness Protocols: Distributing state data via a peer-to-peer network.\n- Near-instant sync: New nodes can join the network in minutes, not weeks.
~1KB
Witness Size
Minutes
New Sync Time
03
The Consequence: The Rise of Specialized Networks
A stateless Ethereum enables a new architectural paradigm where execution and data availability are unbundled. This validates the design of:\n- Rollups (Arbitrum, Optimism): Pure execution layers.\n- Modular DA (Celestia, EigenDA): Specialized data availability layers.\n- Solo Stakers: Radically lower hardware requirements, combating centralization.
100k+
Potential Validators
$0.01
Target TX Cost
04
The Risk: The Liveness-Assumption Shift
Statelessness trades one set of problems for another. Clients now rely on the network to provide state witnesses, introducing new risks:\n- Witness Availability: Malicious actors could withhold data, stalling the chain.\n- P2P Network Strain: The bandwidth burden shifts from storage to real-time data retrieval.\n- Complexity Attack Surface: New cryptographic primitives (Verkle, KZG) must be battle-tested.
New
Attack Vector
Critical
P2P Reliance
deep-dive
THE STATE PROBLEM
Deconstructing Statelessness: Verkle Trees & Witness Protocols
Statelessness replaces the need for nodes to store the entire Ethereum state, enabling radical scalability and decentralization.
Statelessness decouples execution from storage. A validator no longer needs the 1TB+ state to verify a block. It uses a compact cryptographic proof, or witness, to confirm state transitions.
Verkle Trees are the enabling data structure. They replace Merkle Patricia Tries with polynomial commitments, collapsing witness sizes from ~1MB to ~150KB. This makes stateless clients viable.
The witness protocol is the new bottleneck. Clients must fetch and verify these proofs. Solutions like Portal Network and Ethereum's history expiry (EIP-4444) are prerequisites for reliable witness distribution.
Evidence: Current state growth is ~50GB/year. Post-Verkle, a validator's witness requirement drops 99%, enabling consumer hardware to participate.
ETHEREUM STATE MANAGEMENT
The Hardware Divide: Full Node vs. Stateless Verifier
A direct comparison of hardware and operational requirements for validating the Ethereum network, contrasting the traditional full node with the proposed stateless future.
| Feature / Metric | Full Node (Current) | Stateless Verifier (Post-Verkle) |
|---|---|---|
State Storage Required |
| ~1-10 MB |
Minimum RAM | 16-32 GB | 1-2 GB |
Initial Sync Time | 5-10 days | < 1 hour |
Bandwidth per Month | ~1-2 TB | < 100 GB |
Can Propose Blocks | ||
Hardware Cost (Est.) | $1000-$2000 | < $100 |
Verifies Execution via | Full State Execution | Witness + ZK Proofs (e.g., zkEVM) |
Primary Constraint | Storage I/O Bottleneck | Witness Bandwidth & Proof Verification |
counter-argument
THE ARCHITECTURAL TRADE-OFF
The Steelman: Complexity, Coordination, and New Centralization Vectors
Statelessness solves state bloat by externalizing data, but creates new systemic risks in coordination and centralized data dependencies.
Statelessness externalizes execution state to a separate data availability (DA) layer, fundamentally separating compute from storage. This forces a new architectural paradigm where nodes verify proofs instead of storing history, similar to how zk-rollups like StarkNet operate today.
Coordination overhead becomes the bottleneck. Every transaction now requires fetching state witnesses from a separate network, introducing latency and complex p2p protocols. This is a harder coordination problem than the current Ethereum mempool.
New centralization vectors emerge in the data supply chain. The system relies on a small set of professional provers and data providers (e.g., EigenDA, Celestia operators) to generate validity proofs and serve data, creating potential censorship points.
Client diversity faces a new threat. Stateless clients depend on untrusted data sources, making them vulnerable to data withholding attacks if the prover-builder-separator (PBS) ecosystem consolidates, mirroring current MEV-Boost relay centralization risks.
takeaways
STATELESSNESS PRIMER
TL;DR for Protocol Architects
Ethereum's stateless future is a fundamental re-architecture of client data management, not just a performance tweak.
01
The Problem: State Bloat is a Security Threat
Full nodes today must store the entire state (~1TB+), creating prohibitive hardware requirements and centralization pressure. This is a direct attack on Ethereum's credible neutrality and censorship resistance.\n- State size grows ~50 GB/year\n- Sync time for new nodes can take weeks\n- Hardware cost creates validator oligopoly risk
1TB+
State Size
~50 GB/yr
Growth
02
The Solution: Verkle Trees & Witnesses
Replace Merkle Patricia Tries with Verkle Trees, enabling stateless clients. Validators no longer store state; they verify execution using cryptographic proofs called witnesses.\n- Witness size targeted at ~250 KB per block\n- Enables light clients with full security guarantees\n- Paves way for single-slot finality by simplifying consensus
~250 KB
Witness Target
~500ms
Proof Verify
03
The Architecture: Separation of Execution & Consensus
Statelessness finalizes the separation of concerns from The Merge. The Consensus Layer (CL) orders blocks and attests, while the Execution Layer (EL) validates proofs.\n- CL Client: Handles consensus, receives block + witness\n- EL Client: Validates witness, executes transaction, returns state diff\n- Danksharding becomes feasible as data availability is decoupled from execution
2 Layers
Decoupled
10x+
Node Scalability
04
The Implication: Redefining the L2 Stack
With the base layer stateless, rollups (Arbitrum, Optimism, zkSync) and validiums become the primary state managers. This shifts complexity and data availability guarantees off-chain.\n- Base Layer: Pure settlement & consensus\n- L2s: Host execution state, provide proofs\n- Bridges & Interop: Must adapt to proving state membership (e.g., layerzero, Across)
L1 -> L2
State Shift
$30B+ TVL
Affected
05
The Trade-off: Prover Centralization Risk
Witness generation becomes a new, computationally intensive role. If not democratized, it creates a prover oligarchy, reintroducing centralization. Projects like Succinct, RiscZero, and Nil Foundation are building generalized proof markets to mitigate this.\n- Witness generation is CPU/GPU intensive\n- Requires economic incentives for decentralized provers\n- Critical for long-term client diversity
New Role
Prover
High
Stakes
06
The Timeline: A Multi-Year, Multi-Upgrade Path
This isn't a single hard fork. It's a coordinated sequence: Verkle Trees (Prague/Electra), Full Statelessness, then History Expiry. Each step requires major client refactoring (Geth, Nethermind, Besu).\n- Verkle Testnets live in 2024\n- Production EIPs likely 2025-2026\n- History Expiry post-2026 to prune ancient state
2025-2026
Target EIPs
3+ Upgrades
Phased Path
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