Verkle trees are a cryptographic data structure designed to replace the Merkle Patricia Trie (MPT) used in Ethereum’s state storage. “Verkle” is a portmanteau of vector commitment and Merkle tree — the key innovation is using polynomial-based commitments (specifically KZG/Kate commitments) rather than hash-based proofs, which produces witnesses (proofs of state) that are orders of magnitude smaller than Merkle Patricia Trie witnesses. Smaller witnesses are critical for stateless clients — Ethereum nodes that can verify the chain’s full state validity without storing gigabytes of state data themselves, by relying on compact witnesses included with each block. Verkle trees are a central component of Ethereum’s long-term scalability roadmap, planned for inclusion in the Verge upgrade phase.
Why Ethereum Needs Verkle Trees
Ethereum’s state is currently stored in a Merkle Patricia Trie (MPT). For a stateless client to verify the execution of a block, it needs a witness — a proof of all the state values the block touches (account balances, contract storage, code). The MPT witness problem:
MPT witness size:
- For each piece of state accessed, the proof must include all sibling nodes along the path from leaf to root
- Average path length: ~24 nodes in a hexary trie
- Each sibling node: 32 bytes
- One state access: ~768 bytes of proof data
- A block accessing 1,000 distinct state items: ~768KB of witness data
768KB per block is too large to include in block propagation efficiently. Full nodes must store the state themselves — keeping the current multi-hundred-GB Ethereum state requirement.
Verkle witness size:
- Vector commitments allow proof of multiple values in a single compact commitment
- A Verkle witness for the same 1,000 state accesses: ~150–200KB (rough estimate)
- Further compression via multiproof techniques: ~100KB or less
How Verkle Trees Work
The following sections cover this in detail.
Vector Commitments vs. Hash Commitments
A hash-based commitment (Merkle tree) proves that a value v is at position i in a tree by providing the hash path — all sibling hashes needed to recompute the root. Adding a new leaf or proving 100 leaves requires 100 independent inclusion paths.
A vector commitment scheme commits to a vector [v_0, v_1, ..., v_k] with a single short commitment C, and proves v_i = x with a single short proof π, where:
- The commitment
Cis the same regardless of how many values you later prove - A multiproof lets you prove many positions
(i_1, v_1), (i_2, v_2), ...with a proof that grows sub-linearly with the number of positions
Ethereum’s Verkle trees use KZG polynomial commitments (the same scheme used in blob transactions (EIP-4844)):
- Arrange values as coefficients of a polynomial
- The “commitment” is the polynomial evaluated at a secret point (using a KZG trusted setup)
- Proving an opening
P(z) = vtakes a constant-size proof (~48 bytes) - Combining proofs for multiple openings into one multiproof: efficient aggregation
Tree Structure
Ethereum’s planned Verkle tree uses a width-256 tree (each inner node commits to 256 children) in a depth-bounded structure, with KZG commitments at each inner node:
“`
[Root commitment]
[Inner node commitment] … (256 children)
[Leaf stems] (256 values per stem)
“`
This uses fewer levels than the MPT (less depth), and the wide branching factor combined with vector commitments yields smaller witnesses.
Impact on Ethereum
| Feature | Current (MPT) | Post-Verkle |
|---|---|---|
| State proof (witness) size | ~768 bytes/access | ~150 bytes/access (estimated) |
| Stateless client feasibility | No (witnesses too large) | Yes |
| Block with witnesses | Not practical | ~100–300KB |
| Full node storage requirement | Full state (hundreds of GB) | Stateless possible |
| Prover complexity | Simple hash operations | Elliptic curve operations (KZG) |
| Trusted setup required | No | KZG ceremony (done for EIP-4844) |
Stateless clients would let users run full verification nodes on consumer hardware without syncing or storing the full Ethereum state — a significant decentralization win.
History
- 2018 — Dankrad Feist and others begin Ethereum research into alternative state trie designs to address the state size problem.
- 2021 — Verkle tree for Ethereum formally proposed by Vitalik Buterin, Dankrad Feist, and Justin Drake; early specifications published.
- 2022–2023 — KZG trusted setup ceremony runs for EIP-4844 (blobs) — the same cryptographic machinery that Verkle trees will reuse.
- 2022–2023 — Verkle tree specifications refined; implementations begin in execution client codebases (Go-Ethereum/Reth).
- 2024 — “The Verge” stage of Ethereum’s roadmap (following “The Surge” for scaling and “The Scourge” for MEV) targeted for Verkle tree activation as part of stateless client enablement.
- 2025 — Verkle testnet activations proceed; full mainnet inclusion targeted for a future hard fork post-Pectra.
Common Misconceptions
“Verkle trees make Ethereum proofs zero-knowledge.”
Verkle witnesses are compact proofs of state inclusion, not zero-knowledge proofs. They prove “this account has this balance” efficiently, but they don’t hide information. ZK-EVMs (separate technology) can be built on top of Verkle trees, but the Verkle tree itself is not a ZK system.
“Verkle trees solve Ethereum’s state bloat.”
Verkle trees enable stateless clients by shrinking witness sizes — but they don’t delete existing state or reduce how much state grows over time. State expiry (a separate proposal) would address state growth; Verkle trees address the witness size problem for stateless verification.
“Verkle tree implementation is straightforward.”
Migrating Ethereum’s live state from MPT to Verkle trees while maintaining consensus is one of the most technically complex Ethereum upgrades ever attempted. It requires converting hundreds of GB of state data in a coordinated transition and updating all execution clients simultaneously.
Criticisms
- KZG trusted setup dependency — Verkle trees require the KZG trusted setup ceremony (already run for EIP-4844). If the ceremony’s “toxic waste” (the secret scalar) were to be reconstructed by a sufficiently powerful attacker, the commitment scheme’s security would be compromised. This is considered computationally infeasible with the EIP-4844 ceremony’s scale (~140,000 participants) but represents a theoretical trust assumption.
- Elliptic curve computation cost — KZG operations are more computationally expensive than hash operations. Witness generation (computing KZG proofs) takes more time than constructing Merkle proofs — a trade-off between verification efficiency and generation cost.
- Migration complexity — Converting Ethereum’s existing MPT state to Verkle format requires an extremely careful, battle-tested migration protocol. Bugs in the migration could cause consensus splits between clients.
- Delayed timeline — Verkle trees have been “on the roadmap” since 2021; the complexity of implementation and the prioritization of other upgrades (Merge, Surge/blob transactions) repeatedly pushed the activation timeline back.
Social Media Sentiment
Verkle trees generate genuine excitement among Ethereum researchers and developers — enabling stateless clients is widely seen as one of the most meaningful steps towards decentralization and censorship resistance (more people running nodes). r/ethereum discussions position Verkle trees alongside sharding and PBS as long-term fundamental shifts. Critics on Crypto Twitter/X sometimes frame the delay as “Ethereum always five years away from completing its roadmap,” while supporters point to the genuine technical complexity of producing a live state migration at scale. The topic is primarily developer/researcher-focused; retail discussion is limited.
Last updated: 2026-04
Related Terms
Sources
- Buterin, V. et al. (2021). Verkle Trees for Ethereum State. Ethereum Research (ethresear.ch).
- Feist, D. (2022). KZG Polynomial Commitments and Applications to Verkle Trees. Ethereum Foundation Blog.
- Kuszmaul, J. (2022). Verkle Trees. Verkle.info.
- Guillaume, B. (2022). Ethereum Verkle Tree Implementation Notes. go-ethereum GitHub.