Full nodes are a liability because they require storing over 1TB of historical state data. This cost and complexity pushes node operation towards professionalized infrastructure providers like Infura and Alchemy, directly undermining the network's decentralization.
the-ethereum-roadmap-merge-surge-verge
Blog
Stateless Ethereum and Easier Node Recovery
Ethereum's state is a 1TB+ anchor dragging down node operators. The Verge's stateless architecture, powered by Verkle Trees and the Portal Network, aims to eliminate this burden, enabling near-instant node sync and recovery. This is the prerequisite for true global-scale decentralization.
introduction
THE SYNC PROBLEM
The 1TB Anchor: Why Your Ethereum Node is a Liability
Ethereum's state growth creates an unsustainable operational burden, making full nodes a centralization risk.
Stateless clients are the solution by separating execution from state storage. A node verifies blocks using cryptographic proofs (witnesses) instead of a local database, reducing hardware requirements from terabytes to gigabytes. This mirrors the design philosophy behind zk-rollups like StarkNet.
Ethereum's Verkle Tree transition is the critical upgrade enabling this. It replaces the Merkle Patricia Trie with a structure that produces smaller, constant-sized proofs, making witness propagation across the p2p network feasible.
The recovery benefit is instant sync. A new node downloads only the latest block header and a verifiable witness, bypassing weeks of historical sync time. This resilience is a prerequisite for mass adoption, as seen in lighter L2 client designs.
key-trends
STATELESSNESS & RECOVERY
The Three Pillars of The Verge
The Verge's core innovation is decoupling state from execution, solving Ethereum's most critical scaling and decentralization bottlenecks.
01
The Problem: State Bloat Kills Decentralization
Full nodes require storing the entire Ethereum state (~1TB+), making solo staking and node operation prohibitively expensive. This centralizes network security to a few large providers like Infura and Alchemy.
- State growth outpaces consumer hardware, creating a centralization pressure.
- Sync times of weeks for new nodes create a poor user and developer experience.
- Bandwidth costs for state updates are a primary bottleneck for Layer 2s like Arbitrum and Optimism.
1TB+
State Size
Weeks
Sync Time
02
The Solution: Stateless Clients with Verkle Proofs
Clients no longer store state locally. Instead, they verify execution using compact cryptographic proofs (Verkle proofs) provided by block producers. This mirrors the trust model of light clients but for full validation.
- Node requirements drop from terabytes to gigabytes, enabling consumer hardware.
- Instant sync from genesis, removing the biggest barrier to new node operators.
- Enables single-slot finality by making block propagation and verification orders of magnitude faster.
~99%
Storage Cut
Minutes
New Sync Time
03
The Enabler: Peer-to-Peer State Recovery Networks
Stateless clients need a robust, decentralized source for state witnesses (Verkle proofs). The network incentivizes nodes to serve these proofs, creating a distributed recovery layer. This is the missing piece protocols like Portal Network are building.
- No single point of failure unlike current RPC provider reliance.
- Incentivized bandwidth ensures liveness and data availability.
- Fault tolerance allows nodes to recover state after downtime without a full re-sync.
P2P
Architecture
Zero Trust
Assumption
deep-dive
THE STATE PROOF
From Merkle Patricia to Verkle: The Proof, Not the Data
Verkle trees replace Merkle Patricia Tries to enable stateless clients by shrinking witness sizes from gigabytes to kilobytes.
Statelessness requires tiny proofs. A stateless client verifies blocks without storing the full state, relying on a witness (a proof of state inclusion). Merkle Patricia Tries produce witnesses too large for propagation, often gigabytes, which breaks the model.
Verkle trees use vector commitments. Unlike Merkle trees with 2-child branches, Verkle trees use polynomial commitments (like KZG) for wide branches. This allows a single proof for multiple siblings, collapsing the proof size logarithmically. Witnesses shrink to ~150 bytes.
Node recovery becomes trivial. With compact Verkle proofs, new nodes sync by downloading the latest block header and a tiny witness. This eliminates the multi-day sync times that plague current Geth or Erigon implementations, enabling near-instant node deployment.
Evidence: The EIP-6800 specification. The formal Ethereum proposal benchmarks Verkle proofs at 1-2 KB for a complex transaction versus a Merkle proof of ~1 MB. This 1000x reduction is the prerequisite for stateless Ethereum and light client scaling.
ETHEREUM NODE ARCHITECTURE
Stateful vs. Stateless: A Node Operator's Reality Check
A first-principles comparison of state management paradigms, quantifying the operational trade-offs for node runners.
| Core Metric / Capability | Traditional Stateful Node | Stateless Ethereum (Verkle Proofs) | Stateless Light Client |
|---|---|---|---|
State Storage Requirement |
| ~50 GB (SSD) | < 1 GB (RAM/SSD) |
Initial Sync Time (Fast) | 5-15 days | Target: < 1 day | Target: < 1 hour |
Bandwidth for Block Validation | ~50 Mbps sustained | ~10 Mbps sustained + proof downloads | < 5 Mbps sustained |
Hardware Cost (Annualized) | $1000-3000 | Target: $200-500 | < $100 |
Supports Full Execution & Validation | |||
Can Recover from Crash Without Resync | |||
Requires Trusted Sync Committee | |||
Implementation Status | Mainnet (Geth, Nethermind) | Devnet (Pectra Upgrade Path) | Mainnet (EIP-4844 enabled) |
counter-argument
THE RECOVERY MECHANISM
The Centralization Trap: Won't The Portal Network Just Re-Centralize?
Statelessness and the Portal Network shift the centralization risk from hardware to data availability and social consensus.
Statelessness enables trivial recovery. A node operator recovers from a crash by downloading only the latest state root and block headers, not the entire history. This reduces the hardware centralization pressure that currently forces nodes onto expensive, centralized cloud providers like AWS.
The centralization risk shifts to data. The network's liveness depends on a sufficient number of Portal Network clients (e.g., Trin, Fluffy) serving light clients with proofs. If these portal clients centralize, the network re-centralizes at the data layer.
Recovery relies on social consensus. A node verifying a state root must trust that the underlying data is available somewhere honest. This creates a weakest-link dependency on the decentralized client ecosystem, similar to light client security in Cosmos IBC or Polkadot.
Evidence: The current Ethereum mainnet has ~5,000 consensus nodes but relies on ~3 major execution client implementations. Portal Network client diversity must exceed this to avoid a similar implementation monoculture risk that threatens network resilience.
takeaways
STATELESSNESS & RECOVERY
TL;DR for Protocol Architects
Statelessness decouples execution from state, enabling radical node efficiency and instant recovery.
01
The Problem: State Bloat is a Centralizing Force
Full nodes require storing the entire ~1TB+ state, creating prohibitive hardware costs and slow sync times. This limits participation to professional operators, undermining decentralization.
- Barrier to Entry: High SSD costs and bandwidth exclude home validators.
- Sync Hell: Initial sync can take days, crippling node recovery.
- Centralization Pressure: Pushes infrastructure to centralized providers like AWS.
~1TB+
State Size
Days
Sync Time
02
The Solution: Verkle Trees & Stateless Clients
Replace Merkle Patricia Tries with Verkle Trees, enabling stateless validation. Clients verify blocks using small cryptographic proofs (~1KB) instead of holding full state.
- Witness-Based Validation: Nodes receive a 'witness' proof for relevant state, slashing storage needs by >99%.
- Instant Sync: New nodes can join the network in minutes, not days.
- Enables Light Clients: Paves the way for trust-minimized light clients in wallets and dApps.
~1KB
Proof Size
>99%
Storage Saved
03
The Architecture: Separating Execution from State
Decouple the roles: Stateless Execution Clients process transactions, while State Providers (potentially a separate p2p network) serve the required proofs. This mirrors a microservices architecture for blockchain.
- Fault Isolation: A crashed execution client can reboot instantly, fetching fresh state proofs.
- Specialization: Enables optimized hardware for state serving (high I/O) vs. execution (high CPU).
- Resilience: Node recovery becomes trivial, strengthening network liveness against attacks.
Minutes
Recovery Time
Modular
Architecture
04
The Trade-off: Bandwidth for Storage
Statelessness swaps storage overhead for increased bandwidth. Each block requires transmitting witnesses, increasing p2p network load. This is the core scalability trade-off.
- Bandwidth Tax: Estimated ~1-5 MB witness per block vs. ~50KB today.
- Witness Propagation: Requires efficient gossip protocols to avoid latency spikes.
- Provider Incentives: A robust market for state providers (with staking/SLASSA) is critical for liveness.
~1-5 MB
Witness Size
P2P Load
New Bottleneck
05
The Precedent: Near Protocol's Nightshade
NEAR Protocol's sharding design (Nightshade) is a live example of stateless validation in production. Chunk-only validators do not hold full shard state, relying on state proofs.
- Proven Scalability: Enables ~100k TPS theoretical capacity across shards.
- Fast Finality: One-second block times with instant state finality.
- Validation: Demonstrates the feasibility of the stateless paradigm at scale.
~100k
TPS Capacity
1s
Finality
06
The Roadmap: Post-Merge, Pre-Scaling
Statelessness is the prerequisite for Verkle Trees, then EIP-4444 (history expiry), and ultimately full danksharding. It's the foundational upgrade for Ethereum's next scalability leap.
- Verkle Testnets: Active development on Kaustinen testnet.
- History Pruning: EIP-4444 will cut ~500GB of historical data requirement.
- Endgame: Enables a network where solo staking on a Raspberry Pi is feasible.
~500GB
History Pruned
Raspberry Pi
Node Target
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