Verkle trees solve state growth. They replace Merkle proofs with KZG polynomial commitments, reducing witness sizes from ~300 kB to ~150 bytes. This enables stateless validation where nodes verify blocks without storing the entire state.
the-ethereum-roadmap-merge-surge-verge
Blog
Verkle Trees and Cryptography at Scale
An analysis of Verkle Trees as the cryptographic cornerstone of The Verge, enabling stateless clients, exponential state growth, and solving Ethereum's final scaling bottleneck.
introduction
THE STATE SCALING
The Merge Was Theater. The Surge is Engineering. The Verge is Mathematics.
Verkle trees replace Merkle trees with polynomial commitments to compress Ethereum's state size, enabling stateless clients.
Statelessness enables client diversity. Light clients become first-class citizens, verifying execution with minimal data. This breaks the hardware requirement spiral that centralizes nodes on AWS/GCP infrastructure.
The cryptography is non-trivial. KZG commitments require a trusted setup, but Ethereum's EIP-4844 proto-danksharding ceremony provides this foundation. The math shifts the bottleneck from storage I/O to computational verification.
Evidence: A stateless Ethereum client verifier downloads ~1 MB per block versus the current >1 TB full state. This is the prerequisite for the Vitalik's Endgame scaling roadmap.
key-trends
SCALING CRYPTOGRAPHY
The State Crisis: Why Verkle Trees Are Non-Negotiable
Ethereum's state size is a ticking bomb; Merkle proofs are the fuse. Verkle trees are the cryptographic defusal kit.
01
The Merkle Proof Bottleneck
Merkle proofs for state access are the primary bottleneck for stateless clients and light clients.\n- Proof size explodes with tree depth (e.g., ~1KB for Ethereum).\n- Bandwidth cost makes light clients impractical for real-time verification.\n- This directly blocks the path to stateless validation, the holy grail for node decentralization.
~1KB
Proof Size
O(log n)
Complexity
02
Verkle Trees: Vector Commitments in Practice
Verkle trees replace hashes with vector commitments (like KZG or IPA).\n- Constant-size proofs (~200 bytes) regardless of tree size.\n- Enables single-proof witness for accessing multiple unrelated state values.\n- The cryptographic primitive making stateless Ethereum and ultra-light clients physically possible.
~200B
Proof Size
O(1)
Verification
03
The Gas Cost Implosion
Smaller proofs directly translate to lower L1 execution costs and unlock new L2 designs.\n- Witness data becomes cheap enough to include in blocks.\n- ZK-Rollups (like zkSync, Scroll) benefit from cheaper state inclusion proofs.\n- Paves the way for verifiable light clients on L2s, enabling secure cross-chain bridges.
-90%+
Witness Cost
10x
L2 Efficiency
04
Polynomial Commitments: The Math That Makes It Work
KZG commitments bind a prover to a polynomial without revealing it.\n- Trusted setup required (one-time ceremony, like Ethereum's).\n- Pairing-based cryptography enables efficient proof aggregation.\n- Alternative Inner Product Arguments (IPA) are trustless but slightly less efficient, used by projects like Mina Protocol.
1
Trusted Setup
48 Bytes
Commitment Size
05
The Stateless Client Future
Verkle trees enable nodes to validate blocks without storing the full state.\n- Node hardware requirements plummet, decentralizing the network.\n- Sync time for new nodes drops from days to hours.\n- Critical for Ethereum's Verge roadmap and similar scaling efforts on Polygon, Arbitrum.
~100GB
Node Storage
Hours
Sync Time
06
The L2 & Interop Acceleration
Verkle proofs are a foundational primitive for the modular stack.\n- Optimistic Rollups (like Arbitrum, Optimism) get cheaper fraud proofs.\n- ZK-Rollups (like Starknet, Polygon zkEVM) simplify state verification.\n- Enables light client bridges (like Succinct, Polymer) that are secure and cheap.
$10B+
TVL Impact
~500ms
Bridge Latency
deep-dive
THE STATE SCALING BREAKTHROUGH
From Merkle to Verkle: A Cryptographic Leap, Not a Step
Verkle trees replace Merkle proofs with polynomial commitments, enabling stateless clients and solving Ethereum's state growth crisis.
Statelessness is the goal. Verkle trees enable nodes to validate blocks without storing the entire state, a prerequisite for scaling to millions of transactions per second.
Merkle proofs are too large. A standard Merkle proof for a single account is ~1KB; a Verkle proof is ~150 bytes. This 85% reduction makes stateless verification practical.
Polynomial commitments replace hashes. Instead of chaining SHA-256 hashes, Verkle trees use KZG or IPA commitments, allowing proofs that combine data from multiple tree branches.
Ethereum's Portal Network is the primary driver. It requires lightweight clients to sync and verify data, a task impossible with current Merkle-Patricia trees.
Verkle trees are not incremental. They require a hard fork and a one-time state conversion, a complexity that protocols like Polygon zkEVM and zkSync have already navigated for their own state trees.
CRYPTOGRAPHIC STATE PROOFS
The Proof is in the Proof Size: MPT vs. Verkle
A quantitative comparison of Merkle Patricia Trees (MPT) and Verkle Trees, the cryptographic data structures underpinning Ethereum's state proof generation.
| Cryptographic Metric | Merkle Patricia Tree (MPT) | Verkle Tree (KZG) | Why It Matters |
|---|---|---|---|
Witness Size for 1,000 Accounts | ~170 KB | ~150 B | State sync and light client bandwidth drops from MBs to KBs. |
Proof Aggregation | Enables stateless clients; validators don't store full state. | ||
Primary Cryptographic Primitive | Keccak256 (Hash) | KZG Polynomial Commitments | KZG allows constant-size proofs regardless of data size. |
Ethereum Execution Layer Integration | Pre-Cancun (Historical) | Post-Cancun / EIP-6800 | Verkle Trees are the prerequisite for Verkle-based statelessness. |
Prover Time Complexity | O(n log n) | O(n) | Linear scaling is critical for high-throughput L2s and zkEVMs. |
Node Type Required for Verification | Full Archive Node | Light Client | Drastically lowers hardware requirements for network participation. |
Key Innovation | Deterministic Sparse Merkle Tree | Vector Commitments + IPA | Inner Product Arguments (IPA) enable the compact proof structure. |
counter-argument
THE STATE CRISIS
The Devil's Advocate: Complexity, Tooling, and The Great Node Purge
Verkle trees solve state growth but introduce cryptographic complexity that will purge amateur node operators.
Verkle trees are a node operator purge. They replace Merkle Patricia Tries with polynomial commitments, shrinking proof sizes from kilobytes to ~150 bytes. This enables stateless clients but demands new cryptography libraries and hardware acceleration.
The tooling gap is a systemic risk. Current dev environments like Hardhat and Foundry are built for Keccak hashes. Integrating KZG commitments and Bandersnatch curves requires a full-stack rewrite of compilers, debuggers, and indexers.
Proof aggregation becomes mandatory. Without it, the constant overhead of Verkle proofs per transaction crushes L2s like Arbitrum and Optimism. Projects like Supranational are building dedicated hardware to keep sync times under 10 seconds.
Evidence: Ethereum's current state is ~1 TB. A stateless Verkle client requires ~1 GB, but generating proofs needs a 32-core server. This creates a professionalized, centralized node layer.
takeaways
CRYPTOGRAPHY AT SCALE
Architectural Implications: What Verkle Trees Unlock
Verkle trees replace Merkle Patricia Tries, enabling stateless clients and radically new scaling architectures by compressing proof sizes.
01
The Stateless Client Revolution
The Problem: Full nodes must store the entire world state (hundreds of GBs), creating a massive hardware barrier for validators and light clients.\n- The Solution: Verkle proofs are ~1-2 KB vs. Merkle's ~300 KB, enabling stateless clients.\n- Key Benefit: Validators only need a block header and a tiny proof, slashing sync times and hardware costs.
~1-2 KB
Proof Size
-99%
State Load
02
ZK-Rollup Throughput Explosion
The Problem: ZK-SNARK/STARK provers for rollups like zkSync and Starknet are bottlenecked by Merkle tree proof generation for state updates.\n- The Solution: Verkle trees allow for constant-size proofs regardless of tree depth, drastically reducing prover overhead.\n- Key Benefit: Enables 10,000+ TPS per rollup by making state inclusion proofs trivial for the prover.
10,000+
TPS Potential
O(1)
Proof Complexity
03
The End of the Gas Token Monoculture
The Problem: Paying for execution in the native L1 token (e.g., ETH) is a UX and capital efficiency nightmare for applications and users.\n- The Solution: Stateless verification via Verkle trees enables secure, trust-minimized gas sponsorship and account abstraction at the protocol level.\n- Key Benefit: DApps like Uniswap or AA wallets can pay fees for users in any token, abstracting the base layer entirely.
Any Token
Pay Gas With
~0
User Friction
04
Cross-Chain Sync Becomes Trivial
The Problem: Light clients for bridges (e.g., IBC, LayerZero) require inefficient Merkle proofs, making secure sync expensive and slow.\n- The Solution: Sub-1KB Verkle state proofs can be verified on-chain by another chain's smart contract for pennies.\n- Key Benefit: Enables minimal-trust bridges and omnichain applications with latency and cost comparable to a simple contract call.
<$0.01
Verify Cost
~1s
Finality Latency
05
Decentralized Storage Finally Works
The Problem: Storing blockchain state on decentralized networks like Arweave or Filecoin is pointless if retrieving and proving it is slower and costlier than a centralized server.\n- The Solution: Verkle trees generate tiny proofs for any piece of state, making retrieval from decentralized storage networks efficient and verifiable.\n- Key Benefit: Enables truly decentralized history and state storage, completing the full-stack decentralization promise.
100%
Data Availability
Local-Speed
Retrieval
06
SNARKs Become the Universal Verifier
The Problem: General-purpose zkVMs (e.g., RISC Zero, zkVM) are inefficient at verifying complex state transitions because Merkle proofs are large and variable-sized.\n- The Solution: Verkle's constant-size, SNARK-friendly proofs allow a single zkSNARK to verify the entire execution and state transition of a block.\n- Key Benefit: Unlocks single-slot finality and light-super-clients that verify the chain with a cryptographic proof, not social consensus.
Single-Slot
Finality
One Proof
Verify Chain
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