Statelessness is the prerequisite for scaling Ethereum's validator set. It requires nodes to validate blocks without storing the full state, relying on cryptographic proofs called witnesses.
the-ethereum-roadmap-merge-surge-verge
Blog
Verkle Trees and the End of Large Witnesses
A technical breakdown of how Verkle Trees, a core component of Ethereum's 'Verge' upgrade, eliminate witness bloat to enable stateless clients and secure scaling. This is the unsung hero of the post-Merge roadmap.
introduction
THE WITNESS BOTTLENECK
Introduction: The Unscalable Cost of Proof
Ethereum's scalability is fundamentally limited by the exponential growth of state witness sizes required for stateless clients.
Merkle Patricia Tries fail because witness size grows linearly with the state accessed. A complex Uniswap V3 swap can generate a 1 MB witness, making block propagation untenable.
Verkle Trees solve this by using vector commitments. They compress witness size from O(N) to O(log N), enabling the 1 TB state to be proven with a constant ~150 byte proof.
The evidence is in the data: A 2023 Ethereum Foundation analysis showed a single ERC-20 transfer requires a 300 KB Merkle proof versus a 150 byte Verkle proof, a 2000x reduction.
key-trends
THE END OF LARGE WITNESSES
Executive Summary: Why Verkle Trees Matter Now
Verkle trees are a cryptographic accumulator upgrade that solves Ethereum's most pressing scaling bottleneck for nodes and wallets.
01
The Problem: Witness Bloat Kills Statelessness
Ethereum's current Merkle-Patricia trees require massive ~1 MB witnesses for block validation, making stateless clients impossible. This caps decentralization by demanding hundreds of GB of SSD for full nodes.
- Bottleneck: Stateless validation is the prerequisite for Verifiable Execution and ultimate scalability.
- Consequence: Without a fix, solo staking and light client usability hit a hard ceiling.
~1 MB
Witness Size
500+ GB
Node Requirement
02
The Solution: Vector Commitments & KZG Proofs
Verkle trees replace hashes with KZG polynomial commitments, collapsing witness size by ~200x. A single, constant-sized proof can verify thousands of account states.
- Mechanism: Proves membership via a ~100 byte witness instead of hashing up a tree.
- Enabler: Unlocks practical stateless clients, allowing validators to verify blocks without storing state.
~200x
Smaller Witness
< 150B
Proof Size
03
The Catalyst: Ethereum's Verge & Endgame Scaling
Verkle trees are the core primitive for The Verge, enabling statelessness which is foundational for Verkle Proofs of Execution and full danksharding. This is not an incremental upgrade—it's a prerequisite.
- Downstream Impact: Enables ultra-light clients, reduces sync times to minutes, and slashes hardware requirements.
- Strategic Timing: Essential for onboarding the next 100M+ users without sacrificing decentralization.
Minutes
Sync Time
100M+
User Capacity
deep-dive
THE STATE PROOF PROBLEM
The Anatomy of a Bottleneck: From Merkle to Verkle
Verkle trees solve the state witness bottleneck that plagues stateless Ethereum clients by collapsing proof size from kilobytes to under 150 bytes.
Merkle proofs are fat. A standard Merkle Patricia Trie proof for an Ethereum account is ~1KB, scaling linearly with tree depth. This makes stateless clients, which must fetch proofs for every state access, impractical for network bandwidth.
Verkle trees use vector commitments. They replace hashes with polynomial commitments (like KZG), allowing a single proof to attest to multiple sibling values. This flattens the proof structure, decoupling size from tree depth.
The witness size collapses. A Verkle proof for the same account is ~150 bytes, a 6-7x reduction. This is the threshold where stateless and Verkle-based clients become viable, enabling nodes to sync and validate without storing the full state.
Ethereum's roadmap depends on it. The Ethereum Foundation's PSE team is implementing Verkle trees for the Verge upgrade. This is a prerequisite for full statelessness and the scalability of future zk-EVM execution layers.
STATEFULNESS
Witness Size Showdown: MPT vs. Verkle Trees
A technical comparison of witness data structures for stateless clients, focusing on the shift from Merkle Patricia Tries (MPT) to Verkle Trees to solve the witness size bottleneck.
| Feature / Metric | Merkle Patricia Trie (MPT) | Verkle Tree | Implication for Stateless Clients |
|---|---|---|---|
Proof Type | Merkle Proof | Vector Commitment Proof | Verkle uses polynomial commitments (e.g., KZG) for constant-size proofs. |
Witness Size for 1 Account (~100B) | ~1-3 KB | ~150-200 Bytes | Verkle reduces witness size by ~15x, enabling practical stateless verification. |
Tree Branching Factor | 16 (Hexary) | 256 (256-ary) | Higher arity reduces tree depth, minimizing proof path length. |
Tree Depth for 2^30 Accounts | ~64 | ~4 | Shallower tree directly shrinks the number of hashes needed in a proof. |
Requires Pre-Compiled Contract for Verification | Verkle verification requires elliptic curve operations, necessitating a gas-costing precompile (e.g., EIP-7702). | ||
Primary Bottleneck for Stateless Ethereum | Witness Bandwidth | Proof Generation Compute | MPT's large witness was the blocker; Verkle shifts the constraint to prover cost. |
Compatible with Existing EVM State | Ethereum's transition to Verkle Trees requires a complex, one-time state conversion (Verkle Trie EIP). |
counter-argument
THE VERKLE REALITY
The Steelman: Is This Just Another Delayed Upgrade?
Verkle Trees are a non-negotiable prerequisite for stateless clients, not an optional performance tweak.
Verkle Trees eliminate large witnesses. A 'witness' is the proof data a node must send to validate a transaction. Current Merkle Patricia Trie witnesses are megabytes large, making statelessness impossible. Verkle Trees use vector commitments to compress this to kilobytes.
This is not a throughput upgrade. Unlike EIP-4844's blobs or Danksharding, Verkle Trees target node hardware requirements, not chain capacity. The goal is to lower the sync and storage burden for validators, enabling lightweight stateless clients.
Statelessness enables protocol-level scaling. With small witnesses, nodes verify blocks without storing state. This reduces the hardware floor for running a Geth or Erigon client, directly combating centralization from state growth.
Evidence: Post-Verkle, witness size drops from ~1.5MB to ~150KB. This 90% reduction is the minimum threshold for stateless client viability, a prerequisite for the next Ethereum scaling phase.
builder-insights
VERKLE TREES AND THE END OF LARGE WITNESSES
The Builder's Perspective: What Changes
Verkle trees fundamentally alter the data economics of Ethereum's execution layer, enabling stateless clients and shifting the burden of state from nodes to provers.
01
The Problem: Witness Bloat
Current Merkle Patricia Tries require massive ~1-2 MB witnesses for state proofs, making stateless clients impractical. This caps node decentralization and inflates Layer 2 proving costs.
- Bottleneck for zkEVMs and light clients
- Gas cost for accessing deep storage slots
- Bandwidth overhead for every state access
1-2 MB
Witness Size
~100x
Overhead
02
The Solution: Vector Commitments
Verkle trees replace hashes with KZG polynomial commitments, collapsing proof size. A witness for 1000 storage slots shrinks from megabytes to ~150 bytes.
- Enables stateless validation for all nodes
- Fixed-size proofs independent of tree depth
- Single proof for multiple key-value pairs
~150 B
Proof Size
99.9%
Reduction
03
The New Stack: Prover-Centric Architecture
With tiny witnesses, the computational burden shifts to specialized provers. This creates a new market for prover-as-a-service and redefines node roles.
- Light clients become first-class citizens
- zkRollups like zkSync and Starknet see proving cost drop
- RPC providers (Alchemy, Infura) integrate proving layers
PaaS
New Market
~500ms
Proof Gen
04
The End of State Sync Headaches
Node operators no longer need to store or sync the full state. Bootstrapping a node goes from hours/days to minutes, radically improving network resilience and client diversity.
- Instant sync for Geth, Nethermind, Erigon
- Hard fork deployment becomes trivial
- Attack surface for state-DoS shrinks
Minutes
Sync Time
0 GB
State Storage
05
The Gas Cost Revolution
Storage access opcodes (SLOAD, SSTORE) become dramatically cheaper as their cost decouples from witness size. This enables new on-chain application patterns previously too expensive.
- Cheaper storage-heavy DeFi (Uniswap V4 hooks)
- Viable fully on-chain games (Dark Forest)
- Reduced L1<>L2 messaging costs
10-100x
Cheaper SLOAD
New Apps
Enabled
06
The New Attack Vector: Prover Centralization
The shift to a prover market introduces new risks. Cheap, centralized proving services could become single points of failure or censorship, undermining the stateless ideal.
- Requires decentralized prover networks (e.g., Espresso Systems)
- Proof fraud detection becomes critical
- MEV extraction may shift to proof ordering
New Risk
Centralization
Critical
Security Layer
future-outlook
THE STATE PROOF
The Verge is the Foundation, Not the Ceiling
Verkle Trees enable stateless clients, which are a prerequisite for scaling the network's validator count, not the scaling solution itself.
Verkle Trees enable statelessness. Ethereum's current Merkle Patricia Trie requires nodes to store the entire state, creating a hardware bottleneck for validators. Verkle Trees use vector commitments to shrink proofs, allowing validators to verify blocks without holding state.
Statelessness unlocks validator scaling. The primary bottleneck for increasing the validator set is not consensus overhead but state growth. Stateless verification removes the hardware requirement, enabling lightweight validators and a more decentralized, secure network.
This is infrastructure, not throughput. Unlike rollups like Arbitrum or Optimism that scale transactions, Verge scales the consensus layer. It's the foundation upon which future scaling, like danksharding, builds. The Verge's metric is validator count, not TPS.
Evidence: A stateless client witness for a block is ~150 MB with Merkle trees. With Verkle Trees, it collapses to ~150 bytes. This 1,000,000x reduction makes stateless verification practical.
takeaways
STATEFUL SCALING
TL;DR: The Verke Tree Thesis
Verkle trees are the cryptographic upgrade that makes stateless clients viable, solving Ethereum's witness size problem and unlocking the next phase of decentralization.
01
The Problem: Witnesses Are Too Damn Big
To validate a state change, a client needs a 'witness'—proofs of all relevant account data. With Merkle Patricia Tries, these proofs are massive (~1-2 MB), making stateless clients and light clients impractical.\n- Bottlenecks bandwidth and storage for nodes.\n- Blocks Layer 2 rollups like Arbitrum and Optimism from posting efficient proofs.
~1-2 MB
Witness Size
>100 GB
State Growth/Yr
02
The Solution: Vector Commitments + Polynomials
Verkle trees replace hashes with vector commitments (e.g., Pedersen commitments) and KZG polynomial commitments. This allows for extremely efficient proofs by leveraging mathematical properties instead of hash concatenation.\n- Key Innovation: Proof size is constant, regardless of tree depth.\n- Enables true stateless validation and ultra-light clients.
~150 bytes
Witness Size
~99%
Reduction
03
The Killer App: Stateless Ethereum
With tiny witnesses, nodes no longer need to store the entire state. They can validate blocks using proofs provided by the network, radically lowering hardware requirements.\n- Decentralizes validation, countering node centralization trends.\n- Unlocks secure light clients for wallets, enabling trust-minimized access from mobile devices.
~100 GB → ~1 GB
Node Storage
Any Device
Client Target
04
The Ripple Effect: Supercharged Rollups
Verkle proofs are a boon for ZK-Rollups like zkSync and StarkNet. They allow provers to efficiently commit to large state chunks, reducing proof generation costs and latency. Optimistic Rollups also benefit from cheaper fraud proofs.\n- Accelerates the modular blockchain thesis.\n- Reduces finality times and fees for end-users.
10-100x
Proof Efficiency
$B+ TVL
Impact Scope
05
The Trade-off: Hard Fork Required
Implementing Verkle trees is a consensus-breaking change. It requires a coordinated hard fork and a complex, one-time migration of the entire Ethereum state. This is a massive engineering undertaking on par with The Merge.\n- Risks: Implementation bugs, chain splits, migration failures.\n- Timeline: Post-Electra upgrade, likely 2025+.
1
Hard Fork
Months
Migration Period
06
The Competitor: Alternative State Models
Verkle trees aren't the only path. Celestia uses data availability sampling and fraud proofs, avoiding state execution entirely. Solana and Monad opt for extreme hardware scaling with parallel execution. Avail and EigenDA focus purely on data.\n- Contrast: Ethereum chooses cryptographic elegance over hardware reqs.\n- Outcome: A more decentralized, cryptographically secure base layer.
Multiple
Architectures
L1 Diversity
Ecosystem Result
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