Verkle trees are a prerequisite for stateless Ethereum. They replace Merkle Patricia Tries by using vector commitments and polynomial commitments, allowing proofs to be constant-sized regardless of data size. This enables light clients to verify state without storing it.
Verkle Trees Replace Hashing with Math
Ethereum's Verkle trees replace Merkle hashing with polynomial commitments (KZG). This reduces proof sizes from ~1 MB to ~150 bytes, enabling stateless clients and solving the state growth problem. It's the core cryptography of the Verge.
Introduction
Verkle trees replace cryptographic hashing with polynomial math to enable stateless clients and solve Ethereum's state growth crisis.
The core innovation is KZG commitments. Unlike hash-based Merkle proofs that grow linearly, a KZG proof for a Verkle tree is ~100 bytes. This reduces witness sizes by ~95%, making stateless validation computationally feasible for the first time.
This directly enables stateless clients. A node like Geth or Erigon will no longer need to store the entire state trie. It can validate blocks using compact proofs, radically lowering the hardware barrier to running a full node and securing the network.
Ethereum's current state is 600+ GB. The Verkle transition, part of the Verkle Tree EIP-6800, is the only viable path to sustainable state growth. Without it, node centralization becomes inevitable, undermining Ethereum's core security model.
The Core Argument
Verkle Trees replace cryptographic hashing with polynomial commitments, collapsing proof sizes and enabling stateless clients.
Verkle Trees replace hashing. Merkle Patricia Tires rely on hash concatenation, forcing proofs to include every sibling node. Verkle Trees use vector commitments via KZG proofs, requiring only a single proof point per path.
Proof size collapses logarithmically. A Merkle proof for a 1-billion-leaf tree is ~1 KB. A Verkle proof for the same tree is ~150 bytes. This enables practical stateless validation for clients like Geth or Erigon.
Stateless clients become viable. Nodes no longer need to store the entire state. They verify execution against a tiny witness, a prerequisite for scaling architectures like Ethereum's Verge and zk-rollup data availability.
Evidence: Ethereum's current witness for a simple transfer is ~3 KB. Post-Verkle, the same witness is projected to be under 150 bytes, a 20x reduction critical for light client adoption.
The State of the State
Verkle trees replace Merkle hashing with polynomial commitments to collapse proof sizes and enable stateless clients.
Verkle trees replace hashing. Merkle proofs require hundreds of kilobytes for state verification, a bottleneck for light clients. Verkle trees use KZG polynomial commitments to generate constant-sized proofs, compressing verification data by 99%.
Statelessness becomes viable. This compression enables stateless clients that verify state without storing it, removing the primary barrier to node decentralization. The Ethereum Foundation's Prague/Electra upgrade prioritizes this transition.
Witness sizes collapse. A Merkle proof for a single storage slot is ~3KB. A Verkle proof for the same slot is ~150 bytes. This efficiency gain directly enables zk-EVM architectures like Polygon zkEVM and Scroll to scale state management.
The Cryptographic Shift: Merkle vs. Verkle
Blockchain state growth is breaking traditional Merkle proofs, forcing a fundamental cryptographic upgrade.
The Problem: Witness Size Bloat
Merkle proofs for complex state (e.g., an account with 1000 NFTs) become massive, requiring ~1-3 KB per proof. This cripples Layer 2 rollup efficiency and makes light client proofs impractical for real-time verification.
- Bandwidth Bottleneck: High cost for cross-chain messaging and bridges.
- Storage Overhead: Limits stateless client adoption.
The Solution: Vector Commitments
Verkle trees replace hash-based siblings with polynomial commitments (like KZG or IPA). A single proof can attest to multiple values along a path, collapsing proof size.
- Constant-Size Proofs: ~100-200 bytes regardless of tree depth or accessed values.
- Enables Statelessness: Clients can verify state without storing it, a prerequisite for Ethereum's Verge upgrade.
The Trade-Off: Trusted Setup & Complexity
Popular Verkle constructions (KZG) require a one-time trusted setup ceremony, a cryptographic burden Merkle trees avoid. Implementation complexity shifts from simple hashing to advanced elliptic curve algebra.
- Prover Overhead: More computational work to generate proofs.
- Ecosystem Readiness: Requires new client libraries and audit cycles, as seen in Ethereum's Pectra dev timeline.
The Competitor: zk-SNARKs for State
Projects like Mina Protocol and zkSync use recursive SNARKs for constant-size state proofs (~22 KB for the entire chain). This is a different, more comprehensive cryptographic approach.
- Succinct Security: Cryptographic certainty in a tiny package.
- Heavier Proving Cost: Orders of magnitude more compute than Verkle proof generation.
The Impact: Light Clients & L2s
Verkle trees make self-validating light clients feasible, breaking reliance on centralized RPC providers. For L2s like Arbitrum and Optimism, it drastically reduces the cost of publishing state commitments to L1.
- Decentralized Verification: Mobile devices can verify chain state.
- Cheaper Rollups: Lower L1 data costs for state diffs.
The Timeline: Ethereum's Path Forward
Verkle trees are a core component of Ethereum's roadmap, specifically The Verge. Implementation is progressing via the Verkle Trie EIP-6800. This is a multi-year, client-wide overhaul requiring consensus across Geth, Nethermind, Besu.
- Post-Pectra Focus: Major development target for 2025+.
- Node Operator Shift: Requires hardware upgrades for proof generation.
Proof Size Comparison: The Hard Numbers
Quantifying the state proof compression achieved by replacing hash-based Merkle proofs with polynomial commitment-based Verkle proofs.
| Proof Characteristic | Merkle Tree (Hexary Patricia) | Verkle Tree (KZG Commitment) | Reduction Factor |
|---|---|---|---|
Witness size for 1,000 accounts | ~3 MB | ~150 KB | ~95% |
Proof size per storage slot access | ~1 KB | ~100-150 bytes | ~90% |
Gas cost for a simple transfer (est.) | ~21,000 gas | ~3,000 gas | ~85% |
Stateless client sync bandwidth | Gigabytes | < 1 MB |
|
Enables stateless validation | |||
Primary cryptographic primitive | Keccak256 hashes | KZG polynomial commitments | |
Proof aggregation capability |
How Verkle Trees Actually Work: Polynomials Over Hashes
Verkle trees replace Merkle tree's hash concatenation with polynomial commitments, collapsing proof size from O(log n) to O(1).
Verkle trees use polynomial commitments to commit to state data. Instead of hashing child nodes together, a parent commits to a polynomial whose evaluations are the child hashes. This enables a single proof to verify all siblings simultaneously.
Proofs shrink to constant size because you verify one polynomial evaluation, not a logarithmic hash path. A Verkle proof for 1 billion leaves is ~150 bytes, versus ~1KB for a Merkle proof in Ethereum's hexary Patricia trie.
The core primitive is KZG commitments, the same cryptographic tool used in Ethereum's Proto-Danksharding (EIP-4844). This creates a unified cryptographic stack for both data availability and state proofs.
This enables stateless clients. Light clients verify state with a tiny, constant-sized witness, eliminating the need to store the entire trie. This is the prerequisite for the Verkle-based Ethereum statelessness roadmap.
Why Builders Care: The Ripple Effects
Verkle Trees replace Merkle proofs with polynomial commitments, fundamentally altering the state proof game for Ethereum and its L2s.
The End of the Witness Size Bottleneck
Merkle proofs require ~1-2KB per proof, making stateless clients and Layer 2 operations like ZK-Rollup proofs prohibitively large. Verkle proofs are constant size (~150 bytes), regardless of tree depth.
- Enables Stateless Clients: Nodes can validate blocks without storing the entire state, reducing hardware requirements by ~90%.
- Unlocks L2 Efficiency: Drastically reduces the cost of generating validity proofs for zkSync, Starknet, and Scroll, accelerating finality.
Supercharging Cross-Chain Infrastructure
Light clients for bridges like LayerZero and Axelar rely on efficient state verification. Verkle proofs make trust-minimized bridging ~100x cheaper to verify on-chain.
- Enables On-Chain Light Clients: Makes it feasible to run an Ethereum light client inside another VM (e.g., Cosmos, Solana).
- Secures Intent-Based Systems: Projects like UniswapX and Across can build more secure, verifiable solvers with minimal overhead.
The Modular State Access Primitive
Verkle Trees transform state access into a portable, cryptographic primitive. This isn't just an Ethereum upgrade; it's a new standard for any system needing succinct state proofs.
- Creates New Design Space: Enables decentralized storage networks (like Arweave, Celestia) to offer verifiable execution states.
- Future-Proofs L1s: Provides a clear path for Monad, Berachain, and other high-performance chains to implement stateless validation from day one.
The Trade-Offs: Not a Free Lunch
Verkle trees trade computational complexity for storage efficiency, introducing new bottlenecks.
Proving overhead replaces storage overhead. Verkle trees shrink node size by ~90% compared to Merkle Patricia Tries, but generating a proof requires complex elliptic curve cryptography instead of simple hashing.
Client verification becomes asymmetric. Light clients perform cheap verifications, but full nodes and Ethereum consensus clients now shoulder the heavier computational burden of proof construction.
Witness size is the critical metric. The primary scaling benefit is reducing proof size for zk-rollups like StarkNet and stateless clients, not raw state size reduction for existing full nodes.
Evidence: The Ethereum Foundation's Portal Network prototype shows verkle proofs are ~200 bytes versus ~3KB for Merkle proofs, enabling practical statelessness.
The Road to The Verge
Verkle Trees replace Merkle trees with polynomial commitments to enable stateless clients and exponential scalability.
Verkle Trees are stateless enablers. They replace Merkle tree hashes with KZG polynomial commitments, allowing clients to verify proofs without storing the entire state. This eliminates the primary bottleneck for node decentralization.
Proofs shrink from kilobytes to bytes. A Verkle proof for a single state element is ~150 bytes versus a Merkle proof's ~1KB. This orders-of-magnitude compression is the prerequisite for The Verge's stateless execution model.
Ethereum's roadmap depends on this. The Prague/Electra upgrade (Pectra) will implement Verkle Trees as a core component of the stateless future, following the Dencun upgrade's success with proto-danksharding (EIP-4844).
Evidence: Vitalik Buterin's original proposal demonstrates a 20x reduction in witness size, a non-negotiable requirement for scaling block gas limits without centralizing node hardware.
TL;DR for CTOs and Architects
Verkle Trees replace Merkle Patricia Tries with polynomial commitments, enabling stateless clients and solving Ethereum's biggest scaling bottleneck.
The Problem: State Bloat Kills Decentralization
Full nodes require ~1-2 TB of SSD to store the current state, creating prohibitive hardware costs. This centralizes validation and makes light clients insecure, relying on trusted RPCs.
- State growth is ~50 GB/year
- Light client proofs are ~1 MB per block, impossible for mobiles
- No path to stateless validation with Merkle trees
The Solution: KZG Polynomial Commitments
Verkle Trees use KZG commitments (or IPA) to create constant-sized proofs for any state element, regardless of tree depth. This is the cryptographic engine.
- Witness size drops from ~1 MB to ~150 bytes
- Enables true stateless clients and 1-of-N trust models
- Foundation for The Verge in Ethereum's roadmap
The Architecture: Vector Commitment Trees
A Verkle Tree is a depth-optimized, wide tree where each node commits to many children (e.g., 256) using a polynomial. This flattens the structure dramatically.
- Tree depth reduced from ~7 to ~4 for Ethereum
- Single proof verifies all accessed storage slots
- Parallelizable proof generation and verification
The Impact: Unlocking Statelessness
This enables stateless validation, where validators only need block headers and tiny witnesses, not the full state. This reshapes client design and network topology.
- Mobile phones can become full validators
- Danksharding becomes viable for data availability
- RPC load plummets as clients self-verify
The Trade-off: Prover Compute Cost
The win in proof size comes at the cost of higher computational load for provers (e.g., block builders). KZG requires elliptic curve operations, which are heavier than simple hashes.
- ~10-100x more CPU for witness generation
- Requires optimized libraries (e.g., Arkworks, KZG ceremonies)
- A known, acceptable trade for scaling decentralization
The Ecosystem: Who's Implementing It
Ethereum's Prague/Electra upgrade (Pectra) will deploy Verkle Trees via the Verkle Trie EIP. This is a multi-client, consensus-layer change.
- Core Dev Teams: Geth, Nethermind, Besu, Erigon
- Testnets: Already live (Kaustinen)
- Followed by: zkEVMs (Scroll, Polygon zkEVM) and other L1s
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.