Stateless clients require small proofs. A client verifying a single account state in a Merkle tree must download a proof containing every sibling hash along the path to the root. This proof size scales logarithmically with state size, becoming megabytes for Ethereum's hundreds of millions of leaves.
the-ethereum-roadmap-merge-surge-verge
Blog
Why Verkle Trees Rely on Polynomial Commitments
A technical breakdown of why Ethereum's Verge upgrade ditches Merkle trees for polynomial commitments (KZG) to enable stateless clients, reduce proof sizes by ~99%, and unlock the next scaling frontier.
introduction
THE PROOF SCALING PROBLEM
The Merkle Tree is a Bottleneck, Not a Foundation
Merkle trees create prohibitive proof sizes for stateless clients, which Verkle trees solve by using polynomial commitments.
Verkle trees use vector commitments. Instead of hashing sibling nodes, a Verkle tree node commits to all its children with a single polynomial commitment, like KZG. A proof for any child is a constant-sized cryptographic evaluation, not a path of hashes.
Proof size collapses from kilobytes to hundreds of bytes. This is the cryptographic breakthrough enabling practical statelessness. Projects like Ethereum's Verkle tree transition and Polygon zkEVM's state management adopt this to make light clients viable and sync times trivial.
The bottleneck shifts from I/O to computation. Verkle tree proofs trade bandwidth for more on-chain verification work, a favorable trade-off as hardware improves. This is a prerequisite for zk-rollup scalability and witness-based stateless execution across all EVM chains.
key-trends
WHY VERKLE TREES NEED POLYNOMIALS
The Stateless Client Imperative: Three Data Points
Stateless clients are the endgame for scaling node decentralization, but they require a new cryptographic primitive to make state proofs practical.
01
The Merkle Proof Bottleneck
Traditional Merkle Patricia Tries require ~1 KB proofs per account access, making stateless validation infeasible for Ethereum's ~1 TB state. The witness size for a block would be ~1-2 GB, crippling network bandwidth.
- Witness Bloat: Proof size scales linearly with tree depth.
- Bandwidth Choke: Nodes cannot download gigabyte-sized proofs per block.
~1-2 GB
Witness Per Block
~1 KB
Per Account Proof
02
Polynomial Commitment Compression
Verkle Trees use KZG commitments or IPA to compress proof data. A single polynomial commitment can represent thousands of state elements, collapsing proof size.
- Constant-Sized Proofs: A single ~48-byte KZG proof can verify multiple values.
- Vector Commitment: Proves an entire branch's state in one cryptographic object, enabling ~95% reduction in witness size.
~48 bytes
KZG Proof Size
-95%
Witness Size
03
The Stateless Future
With Verkle Trees, clients only need the block header and a tiny proof to validate execution, enabling phone-scale nodes. This mirrors the trust-minimized security model of light clients but for full execution.
- Decentralization Preserved: Lowers hardware requirements, countering node centralization.
- Sync Speed: Near-instant state sync, as nodes don't download historical state.
Phone-Scale
Node Hardware
Near-Instant
State Sync
deep-dive
THE STATE PROOF BOTTLENECK
Merkle Proofs vs. KZG Commitments: The Proof Size War
Verkle trees replace Merkle proofs with KZG polynomial commitments to solve the proof size explosion inherent to stateless clients.
Merkle proof size scales linearly with tree depth, creating a bandwidth bottleneck for stateless clients. A 256-bit proof for a 1-billion-leaf tree requires ~1KB, which is impractical for on-chain verification or light clients.
KZG commitments compress state proofs to a constant 48 bytes. This uses polynomial evaluations and a trusted setup, similar to the one used by Ethereum's EIP-4844 for proto-danksharding.
The trade-off is cryptographic assumptions. KZG requires a trusted setup and pairing-based cryptography, while Merkle trees rely only on hash functions. This is a deliberate complexity-for-scalability swap.
Evidence: Ethereum's stateless client roadmap explicitly adopts Verkle trees. This reduces witness sizes from kilobytes to under 150 bytes, enabling practical light client sync and stateless validation.
WHY VERKLE TREES RELY ON POLYNOMIAL COMMITMENTS
Cryptographic Showdown: Merkle vs. KZG for State Proofs
A first-principles comparison of the cryptographic primitives underpinning state proof systems, explaining the shift from Merkle trees to KZG polynomial commitments for stateless clients and Verkle trees.
| Cryptographic Primitive | Merkle Tree (e.g., Ethereum 1.0) | KZG Polynomial Commitment (e.g., Verkle Tree Core) | Vector Commitment (e.g., RSA Accumulator) |
|---|---|---|---|
Proof Size per Witness | ~1-2 KB (for 1k leaf depth) | 48 bytes (constant) | ~1 KB (constant) |
Proof Aggregation | |||
Update Cost (Recompute Root) | O(log n) hashes | O(1) (single group op) | O(n) group ops |
Witness Complexity | O(log n) sibling hashes | O(1) evaluation proof | O(1) membership proof |
Trust Assumption | None (CRH in RO Model) | Trusted Setup (SRS) | Strong RSA Assumption |
Key Enabler for Stateless Clients | |||
Primary Use Case in Production | Blockchain State Roots (Bitcoin, Eth1) | Ethereum's Verkle Trees, EIP-4844 Blobs | Diem (Libra) Blockchain |
counter-argument
THE TRUST MINIMIZATION
But What About Trusted Setups and Alternatives?
Verkle trees use polynomial commitments to eliminate the trusted setup required by older accumulator designs.
Verkle trees eliminate trusted setups. They replace the KZG polynomial commitment scheme, which requires a one-time ceremony, with a trust-minimized cryptographic primitive. This avoids the persistent security risk of a compromised setup.
The alternative is a state explosion. A traditional Merkle tree for Ethereum's state would require proofs too large for a single block. Verkle trees compress this data using vector commitments from polynomial algebra.
KZG commitments are the practical choice. Compared to generic SNARKs or bulletproofs, KZG offers constant-size proofs and efficient aggregation. This is why projects like Ethereum's danksharding and zkSync's state management adopt it.
Evidence: A 1 MB Merkle proof for Ethereum's state shrinks to ~150 bytes with a KZG-based Verkle tree. This orders-of-magnitude reduction is non-negotiable for stateless clients.
takeaways
THE STATE PROOF BOTTLENECK
TL;DR for Protocol Architects
Verkle Trees solve Ethereum's state growth crisis by replacing Merkle Patricia Tries with polynomial commitments for efficient, small proofs.
01
The Problem: Merkle Proofs Are Too Fat
Merkle Patricia Trie (MPT) proofs for a single account are ~1-3 KB. For a block with 1000 transactions, witness sizes balloon to ~1-3 MB, crippling sync and light client viability.
- Witness Bloat: Proof size scales linearly with tree depth.
- Bandwidth Hog: Full nodes must serve massive proofs to light clients.
- Sync Barrier: Historical state sync is prohibitively slow.
~1-3 MB
Per Block Proof
O(log n)
Size Complexity
02
The Solution: KZG Polynomial Commitments
Verkle Trees use KZG commitments (or IPA) to bind all sibling nodes in a vector. A single proof can attest to multiple values at different tree paths.
- Constant-Size Proofs: A single ~100-200 byte proof can verify thousands of key-value pairs.
- Vector Arguments: Prove membership for many leaves in one go.
- Trusted Setup Required: Relies on a one-time ceremony (like Ethereum's EIP-4844 KZG).
~200 B
Proof Size
O(1)
Verification
03
The Architecture: Statelessness & Witness Compression
Verkle Trees enable stateless clients and state expiry. Execution clients no longer need to store the full state; they execute blocks using compact witnesses.
- Stateless Validation: Nodes verify blocks with a witness, not the full state.
- Witness ~1-2 KB: Drastically reduces bandwidth for light clients like Helios or Erigon.
- Enables State Expiry: Old state can be pruned, bounding active state size.
~1-2 KB
Witness Size
>90%
Reduction
04
The Trade-off: Complexity & New Cryptography
You're swapping database engineering complexity for cryptographic complexity. KZG requires a trusted setup and more complex precompiles than simple hashes.
- Cryptographic Agility: Future upgrades (e.g., to STARKs) are possible but non-trivial.
- Prover Overhead: Generating proofs is computationally heavier than Merkle proofs.
- New Attack Surface: Potential vulnerability in the polynomial commitment scheme itself.
Trusted Setup
New Assumption
Higher
Prover Cost
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