Ethereum’s state currently lives in a hexary Merkle Patricia Trie, a structure that traces back to the network’s 2015 launch. For years, the plan to replace it centered on Verkle trees, a newer design built on vector commitments instead of plain hashing. Then, on March 3, 2026, Vitalik Buterin posted a proposal that changed the roadmap again: skip the Verkle-tree endpoint and move straight to a binary tree paired with STARK proofs. That single post reshaped how thousands of engineers think about state proofs, stateless clients, and the future of Ethereum’s Verge upgrade. This piece breaks down what Merkle trees and Verkle trees actually are, what the benchmark data says about proof size and speed, and why the industry’s favorite next-generation structure just got passed over.
Why State Proofs Are a Growing Problem
Every blockchain full node stores a copy of the entire state: every account balance, every contract’s storage, every byte that determines what is true on-chain right now. That works fine when the state is small. It gets expensive as the chain grows, since running a full node starts to require more disk, more RAM, and more bandwidth every year. A stateless client flips the model: instead of storing the whole state, it verifies each block using the block itself plus a compact witness proving that the relevant pieces of state are correct.
The catch is that the witness has to be small enough to actually ship with every block. Send a multi-megabyte proof with each block and you have just moved the bandwidth problem from storage to network traffic. That constraint is the entire reason Ethereum researchers spent years chasing Verkle trees, and it is the same constraint now pushing the roadmap toward binary trees and STARK proofs instead. Every comparison in this article, from proof size to verification speed to trusted-setup requirements, ultimately comes back to one question: how small can a witness get without making it too expensive to produce or check?
What Is a Merkle Tree?
A Merkle tree is a hash-based commitment structure. Every leaf holds a hash of some data, and every parent node hashes the concatenation of its children. Climb the tree far enough and you land on a single root hash that commits to every leaf below it. Change one byte in one leaf and the root changes too, which is exactly the property that makes Merkle trees useful for tamper detection.
Proving that a specific leaf belongs to the tree does not require sending the whole dataset. The prover hands over the leaf plus the sibling hashes along the path to the root, and the verifier recomputes the path and checks it against the known root. For a balanced binary tree with n leaves, that proof needs roughly log₂(n) hashes. Ethereum does not use a plain binary Merkle tree for its state, though. It runs a hexary Merkle Patricia Trie, where each branch can hold up to 16 children and paths get compressed using Patricia-trie techniques, all hashed with Keccak-256.
The appeal of Merkle trees comes down to simplicity. There is no trusted setup, no exotic math, and no elliptic-curve dependency. A collision-resistant hash function is the only cryptographic assumption doing the work, which is also why Merkle trees adapt cleanly to post-quantum hash functions. That combination has kept them as the default choice for blockchain state, transaction logs, and content-addressed storage for well over a decade.
The idea is old by cryptography standards. Ralph Merkle patented the concept of hash trees in 1979 as a way to authenticate large sets of data without hashing everything at once, years before anyone was thinking about blockchains. What changed decades later was not the underlying math but the scale it needed to support: a global, permissionless ledger that had to let strangers verify each other’s data without a trusted intermediary. Merkle’s original insight turned out to be exactly the tool that problem needed.
What Is a Verkle Tree?
A Verkle tree swaps plain hashing for vector commitments at each internal node. Instead of hashing a list of child hashes together, an inner node commits to an entire vector of values in one shot. A verifier can then confirm that position i in that vector holds a specific value without needing every other sibling in the path, which is the entire point: fewer bytes per proof.
Ethereum’s Verkle proposal uses 32-byte keys split into a 31-byte stem and a 1-byte suffix, with extension nodes and inner nodes both supporting up to 256 children. That branching factor is far wider than the binary or hexary trees most engineers are used to, and it is a direct byproduct of how much data a single vector commitment can cover.
Vector Commitments and KZG, Explained
The commitment scheme most associated with Ethereum’s Verkle design is a KZG polynomial commitment. Treat a vector of values as evaluations of a polynomial at fixed points, then commit to that polynomial using a structured reference string generated during a one-time trusted setup ceremony. Proving that position i holds value v_i means producing an evaluation witness, and the verifier checks a pairing equation to confirm it. Multiple positions can be proven together in a single aggregated proof, which is where Verkle trees pull ahead of Merkle trees on witness size.
That efficiency comes at a cost. KZG commitments depend on elliptic-curve pairing assumptions, they require a trusted setup, and they are not post-quantum secure. None of those trade-offs are dealbreakers today, but they explain why Ethereum researchers kept looking for alternatives even after years of Verkle-tree development.
The term itself is younger than most people assume. John Kuszmaul coined “Verkle tree,” a blend of “vector commitment” and “Merkle tree,” in a 2018 research paper written through MIT’s PRIMES program, well before Ethereum adopted the design as a leading candidate for its state-proof problem. What started as an academic exercise in combining two existing cryptographic tools became, within a few years, one of the most closely watched pieces of the Ethereum roadmap.
Merkle Tree vs Verkle Tree: Full Specs Comparison
The table below lines up the two structures across the properties that matter most for engineers evaluating either one for a real system.
| Property | Merkle Tree | Verkle Tree |
|---|---|---|
| Underlying primitive | Cryptographic hash function (Keccak-256, SHA-256) | Vector commitment (typically KZG polynomial commitment) |
| Typical branching factor | 2, or 16 in Ethereum’s hexary Patricia trie | Up to 256 in Ethereum’s design |
| Single-leaf proof, ~1 billion leaves | About 1 KB (Vitalik Buterin, 2021) | Under 150 bytes (Vitalik Buterin, 2021) |
| Trusted setup required | No | Yes, a KZG ceremony |
| Post-quantum secure | Yes, hash-based | No, relies on elliptic-curve pairings |
| Native proof aggregation | Limited without extra tooling | Multiple positions in one proof |
| Verification method | Recompute the hash path | Elliptic-curve pairing check |
| Core cryptographic assumption | Collision resistance | Discrete-log and pairing assumptions |
| Update cost after one write | Recompute O(log n) hashes | Recompute the polynomial commitment along the path |
| Production maturity | Two decades of deployment | Testnet and research stage |
| Known production users | Bitcoin, Git, Certificate Transparency, IPFS, Ethereum’s current state trie | Ethereum’s Kaustinen testnet, academic prototypes |
| Ethereum’s 2026 roadmap status | Still runs mainnet state today | De-prioritized in favor of a binary tree plus STARK proofs |
Read across that table and a pattern emerges quickly: almost every row where Verkle trees pull ahead involves proof size or aggregation, and almost every row where Merkle trees pull ahead involves maturity, simplicity, or long-term security assumptions. That is not a coincidence. Verkle trees were purpose-built to solve one problem, compact multi-key witnesses, and they solve it well. They were never meant to replace Merkle trees everywhere, only in the specific corner of blockchain design where witness size is the binding constraint.
Proof Size Benchmarks: From 1 Kilobyte to 150 Bytes
Vitalik Buterin’s original 2021 write-up on Verkle trees put the size gap in concrete terms: a tree holding a billion pieces of data needs about 1 kilobyte for a proof under a traditional binary Merkle tree, but a Verkle tree can produce the same proof in under 150 bytes. That is roughly a sevenfold cut for a single leaf, and the gap widens further once a prover needs to open many leaves at once, since Verkle proofs aggregate natively while Merkle proofs mostly do not.
Scale that math up to Ethereum-sized workloads and the numbers get more dramatic. One widely cited 2026 Ethereum witness-size analysis estimates that proving around 1,000 state leaves costs roughly 3.5 MB under the current Merkle Patricia Trie, versus about 150 KB for an equivalent Verkle proof, a reduction of close to 23 times. A separate 2026 estimate covering 1,000 Ethereum accounts put Merkle Patricia Trie witnesses closer to 170 KB against roughly 150 KB for Verkle trees, and under 25 KB for the emerging binary-tree-plus-STARK design that Ethereum is now leaning toward.
Those numbers should not be read as a single controlled benchmark. Proof size depends heavily on how many keys get queried, how the tree branches, whether metadata rides along with each node, and whether the final proof gets recursively compressed by a SNARK or STARK layer on top. Still, every dataset points the same direction: Verkle-style commitments beat plain Merkle Patricia Trie proofs by somewhere between 7x and 23x, depending on the workload.
// Simplified Merkle proof verification
function verifyMerkleProof(leaf, proof, root, index) {
let computedHash = leaf;
for (const sibling of proof) {
computedHash = (index % 2 === 0)
? hash(computedHash, sibling)
: hash(sibling, computedHash);
index = Math.floor(index / 2);
}
return computedHash === root;
}
// proof.length grows with log2(n) -- a Verkle opening
// replaces this loop with a single pairing check instead.Benchmark Comparison Across Three Independent Sources
Because no single lab has published one authoritative benchmark, the responsible approach is to line up several independent results side by side and note where they agree. The table below pulls together Vitalik Buterin’s original 2021 estimate, a 2025 academic benchmarking paper, and a 2026 Ethereum-scale witness analysis.
| Source | Workload | Merkle-side result | Verkle-side result |
|---|---|---|---|
| Vitalik Buterin, 2021 proposal | Single proof, ~1 billion leaf tree | ~1 KB | <150 bytes |
| 2026 Ethereum witness-size analysis | ~1,000 state leaves | ~3.5 MB (Merkle Patricia Trie) | ~150 KB |
| Academic paper, arXiv 2504.14069 (2025) | Stateless-client benchmark harness | SNARK-based binary Merkle: slow generation, fast constant verification | ~1 MB proofs, seconds-scale proving and verification |
The three sources do not share a common test rig, so the raw numbers cannot be averaged together. What they do share is direction: every independent measurement puts Verkle-style commitments ahead of plain Merkle Patricia Trie proofs on size, while showing that the actual proving and verification cost depends far more on the surrounding proof system (SNARK, STARK, or native commitment opening) than on which base structure sits underneath it. The full methodology and hardware specifications for the academic benchmark are available in the arXiv paper on stateless Ethereum clients.
Proof Generation and Verification Speed Compared
Smaller proofs do not automatically mean faster proofs, and the 2025-2026 benchmark data shows exactly why. A 2025 academic paper benchmarking Verkle trees against SNARK-based binary Merkle trees found Verkle proving and verification landing in the range of seconds, with proof sizes near 1 MB in that particular test harness. SNARK-based binary Merkle trees in the same paper showed slow proof generation but fast, close to constant verification time once the proof existed.
A separate 2026 measurement tells a friendlier story for Verkle trees: proof generation for a tree with roughly 1 billion leaves in under 20 milliseconds on a consumer machine with 32 GB of RAM, with single-proof verification landing between 8 and 15 milliseconds on a 16-core CPU. The two results are not directly comparable, since they measure different pipelines (one appears to include a heavier SNARK layer, the other looks closer to native Verkle witness generation), but together they illustrate a real pattern: the proving system wrapped around a commitment scheme often matters more than the commitment scheme itself.
A third 2026 estimate for 1,000-account state proofs reported Merkle Patricia Trie generation above 500 milliseconds and verification above 300 milliseconds, against roughly 200 milliseconds and 100 milliseconds for Verkle trees, and around 150 milliseconds and under 50 milliseconds for the binary-tree-plus-STARK approach. Read those three data points together and a consistent hierarchy emerges: plain Merkle Patricia Trie proofs are cheapest to build but heaviest to transmit, Verkle proofs shrink transmission at the cost of pairing-based verification, and binary-tree-plus-STARK designs aim to capture both wins by pairing a simple hash tree with a recursive proof layer.
Cost and Infrastructure Comparison
None of these structures carry a retail price tag, but they do carry real infrastructure costs in bandwidth, storage, and engineering hours. The table below translates the proof-size gap into a daily bandwidth estimate for a node processing roughly 1,000 state accesses per block, using Ethereum’s roughly 12-second block time (about 7,200 blocks per day) as the baseline.
| Structure | Witness per 1,000 accesses | Illustrative daily bandwidth (7,200 blocks) | Trusted setup | Post-quantum safe |
|---|---|---|---|---|
| Merkle Patricia Trie (current Ethereum state) | ~3.5 MB | ~25.2 GB | No | Yes |
| Verkle tree | ~150 KB | ~1.08 GB | Yes, KZG ceremony | No |
| Binary tree + STARK | <25 KB | <180 MB | No | Yes |
Those bandwidth figures are illustrative, built directly from the witness-size estimates above, not a measured production workload. Even so, the gap explains why stateless-client research keeps chasing smaller proofs: shrinking a full node’s per-block data load from tens of gigabytes to a few hundred megabytes a day lowers the hardware bar for running a validator, which matters for decentralization far more than it matters for any single cloud bill.
Engineering cost is harder to put a number on but just as real. A Merkle tree implementation can be reviewed by almost any cryptography engineer familiar with hash functions, and audit firms have two decades of prior art to compare against. A KZG-based Verkle tree needs engineers comfortable with elliptic-curve pairings, polynomial commitments, and trusted-setup ceremonies, which narrows the available talent pool and typically stretches audit timelines. Teams evaluating a migration should weigh that staffing and audit cost alongside the raw byte savings, since a smaller proof that takes twice as long to ship safely is not automatically the better trade.
Ethereum’s Verge Roadmap in 2026: Why Verkle Trees Got Sidelined
Ethereum’s Verge phase has always centered on one goal: let clients verify blocks without storing the entire state, using compact witnesses instead. For years, Verkle trees were the leading candidate to make that possible. Then, on March 3, 2026, Vitalik Buterin described a different plan: replace Ethereum’s hexary Keccak Merkle Patricia Trie with a binary tree built on a more efficient hash function, with implementation work led by Guillaume Ballet and collaborators.
Why Binary Trees and STARKs Won Out
The pivot is architectural, not a retreat from the Verge’s goals. Binary trees are simpler to implement than 256-way Verkle nodes, hash-based commitments skip the KZG trusted-setup requirement entirely, and STARK proofs carry a transparency and post-quantum profile that elliptic-curve pairings cannot match. Binary trees also fit recursive proving systems more naturally, since a uniform circuit design is easier to build around two-way branching than 256-way branching.
The trade-off cuts the other way on raw proof size. A plain binary Merkle witness is larger than a Verkle witness for the same query, which is exactly the gap shown in the benchmark tables above. Ethereum’s bet is that recursive or aggregated STARK proofs can compress many state accesses into one succinct proof, clawing back the size advantage Verkle trees would otherwise hold, without the trusted setup or pairing dependency. As of September 2026, this remains a stated roadmap direction rather than a scheduled mainnet fork with a confirmed activation date.
Real-World Deployments: Where Merkle Trees Run Today
Merkle-style structures show up in far more places than blockchain state. Five deployments illustrate how broadly the pattern has spread.
- Bitcoin block headers. Every block header commits to its transactions through a binary Merkle root, letting SPV wallets verify a transaction with a short inclusion proof instead of downloading the full block. See the Bitcoin developer reference for the exact structure.
- Git’s object model. Every commit, tree, and blob in a Git repository is content-addressed and linked into a hash graph, commonly described as a Merkle DAG, which is why changing a single file changes every commit hash above it.
- Certificate Transparency logs. CT logs use append-only Merkle trees to issue inclusion and consistency proofs for TLS certificates, giving browsers and auditors a way to catch mis-issued certificates. The Certificate Transparency project documents the full log format.
- IPFS content addressing. IPFS links files and directories into a Merkle DAG, which is what allows two nodes with the same file to deduplicate storage automatically. The IPFS documentation covers the design in detail.
- Ethereum’s current state trie. Every account balance, contract storage slot, transaction, and receipt on Ethereum today is committed to through a hexary Merkle Patricia Trie, the same structure the Verge is trying to eventually replace.
Where Verkle Trees Are Being Tested
Verkle trees have a far smaller production footprint than Merkle trees, and that gap is one reason Ethereum kept its options open. Ethereum’s own Kaustinen testnet has served as the primary proving ground, generating the proof-size and proof-generation numbers cited earlier in this piece. Client teams used successive Kaustinen iterations to test how Verkle witnesses behaved under real transaction load rather than synthetic benchmarks alone, which is exactly the kind of data that eventually fed into the decision to consider alternatives.
Outside of that testnet and a handful of academic benchmarking papers, there is no confirmed large-scale production blockchain currently running Verkle trees for its main state. Vector commitments as a broader research area do show up in academic literature and specialized authenticated-database prototypes, but claims of wide production adoption beyond Ethereum’s research track should be checked against a project’s own technical documentation before being repeated as fact. That narrow footprint is worth sitting with: a cryptographic structure can be theoretically superior on paper and still take years, or never arrive at all, if the surrounding engineering, tooling, and consensus among client teams do not converge in time.
Pros and Cons of Merkle Trees
Advantages:
- Simple design that is easy to audit and implement correctly
- No trusted setup of any kind
- Strong compatibility with post-quantum, hash-based cryptography
- Two decades of production hardening across Bitcoin, Git, and TLS infrastructure
- Cheap to generate and verify with modern hash functions
Disadvantages:
- Proof size grows with tree depth and can balloon for high-fanout structures like Ethereum’s hexary trie
- Multiple proofs often repeat the same sibling hashes without specialized aggregation
- Large state witnesses get expensive fast for blocks touching many unrelated keys
- No native way to open many positions in a single compact proof
- Patricia-trie style compression adds implementation complexity even though the base hashing stays simple
Pros and Cons of Verkle Trees (and the Binary-STARK Alternative)
Verkle tree advantages: dramatically smaller multi-key witnesses in favorable workloads, a high branching factor that shortens tree depth, native aggregation of many opened positions into one proof, and a strong fit for stateless blockchain clients.
Verkle tree disadvantages: a mandatory KZG trusted setup, reliance on elliptic-curve pairings that are not post-quantum secure, meaningfully higher implementation complexity, and a difficult migration path away from an existing Merkle Patricia Trie.
Binary tree plus STARK advantages: simple two-way branching logic, no trusted setup, a transparency and post-quantum profile that fits long-term security assumptions, and natural compatibility with recursive proving systems. Disadvantages: plain binary Merkle witnesses are larger than Verkle witnesses before compression, STARK proving can be computationally expensive, and the surrounding proof-system engineering may end up more complex than either simpler alternative despite the underlying tree being easier to reason about.
It helps to think of these three options as points on a triangle rather than a straight line from worse to better. Merkle trees optimize for simplicity and long-term trust assumptions. Verkle trees optimize for raw proof size today, accepting a trusted setup and a weaker post-quantum story in exchange. Binary trees paired with STARKs try to sit closer to the Merkle corner on trust assumptions while borrowing the compression that made Verkle trees attractive in the first place, betting that a heavier proving system is worth the trade. No single point on that triangle is correct for every project, which is exactly why Ethereum spent years testing one design before pivoting to another.
5 Use Cases: Which Structure Fits Your Project
- Audit logs and certificate transparency. Stick with a plain Merkle tree. There is no trusted setup to manage, the tooling is mature, and post-quantum compatibility matters for anything meant to stay verifiable for decades.
- Blockchain light clients and stateless validation. This is the scenario Verkle trees and binary-tree-plus-STARK designs were built for. Pick whichever your target chain implements, since compatibility with the base layer outweighs a marginal proof-size difference.
- Content-addressed storage and deduplication. Merkle DAGs, as used by Git and IPFS, remain the right tool. Deduplication depends on matching hashes, not on compact multi-key proofs.
- Database replica repair. Distributed databases that diff replicas to find inconsistencies, a pattern popularized by Amazon’s Dynamo design and used in systems like Cassandra, rely on plain Merkle trees for anti-entropy checks. Vector commitments add complexity here without a clear benefit.
- Long-term archival and government or regulated systems. Favor hash-based Merkle structures over KZG-based Verkle trees. The absence of a trusted setup and the post-quantum safety margin both matter more than shaving bytes off a proof.
- Rollup and cross-shard state proofs. Vector commitments can still make sense here today, but track Ethereum’s binary-tree-plus-STARK work closely, since the ecosystem’s direction of travel is moving away from KZG-based Verkle trees for this exact use case, and a design choice made now could need revisiting within a year or two.
None of these recommendations are permanent. A team building a rollup in 2024 would have reasonably chosen Verkle trees as the forward-looking option, and the same team revisiting that decision in 2026 now has a credible, hash-based alternative that did not exist in production form two years earlier. Revisit the choice on a fixed schedule rather than assuming whatever was correct at launch stays correct through the life of the project.
Migration Guide: Moving Off a Merkle Patricia Trie
Teams running their own chain or state-storage layer and considering a move away from a classic Merkle Patricia Trie should treat this as a multi-quarter engineering project, not a config change. The steps below reflect how Ethereum client teams have approached the same problem.
- Measure your actual witness sizes and query patterns first. The size gap between Merkle and Verkle proofs varies enormously by workload, so benchmark your own state shape, average number of keys touched per block, and current proof sizes before committing to a new structure. A migration justified by a benchmark from someone else’s workload is a common and avoidable mistake.
- Decide whether a trusted setup is acceptable for your threat model. If it is not, a binary-tree-plus-STARK design or a hash-based alternative rules out KZG-based Verkle trees immediately, and you should scope the project around that constraint from day one rather than discovering it mid-implementation.
- Prototype the new tree structure against a snapshot of real state, not synthetic data, since branching factor and key distribution both affect proof size in practice. Synthetic benchmarks tend to flatter whichever structure the benchmark author is promoting.
- Update client software to support both the old and new state formats during a transition window, mirroring how Ethereum plans to phase in its binary-tree proposal alongside the existing hexary trie. Running two formats in parallel costs extra engineering time but avoids a hard cutover that could split the network if any client lags behind.
Testing on a Testnet Before Any Mainnet Commitment
- Run the new structure on a public or private testnet, the same role Ethereum’s Kaustinen testnet has played for Verkle-tree experiments, and collect proof-generation and verification timings under realistic load.
- Coordinate a hard fork or protocol upgrade only after client teams, auditors, and node operators have all validated the new format independently.
- Monitor bandwidth and storage on validator or full-node hardware after rollout, since the entire point of the migration is usually to reduce that load, and you want data confirming it actually did.
What Cryptography Experts and Ethereum Researchers Say
Vitalik Buterin’s original 2021 proposal remains the clearest technical explanation of why Ethereum pursued Verkle trees in the first place. He wrote that “Verkle trees are a powerful upgrade to Merkle proofs that allow for much smaller proof sizes,” in a post laying out the case for the design (source).
He was specific about the mechanism behind that improvement, explaining that “instead of needing to provide all sister nodes at each level, the prover need only provide a single proof that proves all parent-child relationships between all commitments along the paths from each leaf node to the root” (source). That single-proof property is what lets Verkle witnesses stay compact even as the number of opened positions grows.
On the actual size difference, Buterin quantified it directly: “if a tree contains a billion pieces of data, making a proof in a traditional binary Merkle tree would require about 1 kilobyte, but in a Verkle tree the proof would be less than 150 bytes” (source). That figure is the benchmark this entire comparison keeps returning to.
The project’s own technical documentation frames the trade-off in similar terms. The Verkle Trees documentation describes Merkle trees as “a data structure with the key benefit of being efficient (but not efficient enough for Ethereum’s scaling ambitions) to prove that a certain piece of data exists in the Merkle tree” (source). Ledger Academy’s glossary entry summarizes the cryptographic shift in plain terms as well, noting that “Verkle trees use a more advanced mathematical technique called vector commitments” (source).
The Verdict: Merkle vs Verkle in 2026
Merkle trees remain the right default for the overwhelming majority of systems. They need no trusted setup, they hold up against quantum attacks, and they have been battle-tested inside Bitcoin, Git, and Certificate Transparency for years without a major structural failure. If your system does not need to compress thousand-key state proofs down to kilobytes, a Merkle tree is simpler, cheaper to audit, and easier to hire for.
Verkle trees earned their reputation honestly. A sevenfold to twenty-three-fold reduction in proof size is not a marginal win, and for a blockchain trying to let ordinary laptops validate blocks without storing terabytes of state, that difference is the entire ballgame. But Ethereum’s own March 2026 pivot toward binary trees and STARK proofs is the loudest signal in this space: even the project that popularized Verkle trees is betting its post-quantum future on hash-based commitments layered with recursive proofs, not on KZG pairings. For teams building today, that means treating Verkle trees as a proven research milestone rather than the final answer, and watching Ethereum’s binary-tree-plus-STARK work as the design most likely to define the next decade of compact state proofs.
The practical takeaway for most engineering teams outside of core blockchain protocol work is simpler than the roadmap drama suggests. If you are logging audit trails, verifying file integrity, or building a content-addressed store, a Merkle tree will do the job with fewer moving parts and no cryptographic ceremony to coordinate. If you are building a light client, a rollup, or anything that needs to prove access to a large, shared state as cheaply as possible, study both Verkle trees and the binary-tree-plus-STARK approach before picking a side, because the field is still moving and the “winning” design in 2026 may not be the one still standing in 2028.
Frequently Asked Questions
Is a Verkle tree just a faster Merkle tree?
No. A Verkle tree replaces hash-based parent nodes with vector commitments, typically KZG polynomial commitments. The performance gain comes from a different cryptographic primitive, not from optimizing the same hashing approach Merkle trees use.
Did Ethereum cancel its Verkle tree plan?
Not exactly. Ethereum has moved away from KZG-based Verkle trees as the final design for the Verge, favoring a binary tree combined with STARK proofs instead, based on Vitalik Buterin’s March 2026 proposal. The broader goal of compact, stateless-friendly proofs has not changed, only the cryptographic machinery behind it.
Why does a Verkle tree need a trusted setup and a Merkle tree does not?
Verkle trees typically use KZG polynomial commitments, which require a structured reference string generated through a one-time trusted setup ceremony. Merkle trees rely only on a collision-resistant hash function, which needs no setup ceremony at all.
Are Verkle trees post-quantum secure?
No. KZG-based Verkle trees depend on elliptic-curve pairing assumptions that quantum computers could eventually break. Merkle trees, built on hash functions, are considered far more resistant to quantum attacks, which is one reason Ethereum’s newer binary-tree proposal favors hashing over pairings.
How much smaller are Verkle tree proofs compared to Merkle tree proofs?
Estimates vary by workload. Vitalik Buterin’s original 2021 example showed roughly a sevenfold reduction, from about 1 KB to under 150 bytes, for a single-leaf proof in a billion-leaf tree. Larger, Ethereum-scale estimates for around 1,000 state leaves show closer to a twenty-three-fold reduction.
Which blockchains actually use Verkle trees today?
As of September 2026, no major production blockchain runs Verkle trees for its primary state. Ethereum’s Kaustinen testnet has been the main testing ground, alongside academic benchmarking papers, but mainnet deployment has not happened and the roadmap has shifted toward a different design.
Do Bitcoin or Git use Verkle trees?
No. Bitcoin’s block headers and Git’s object model both rely on classic Merkle-style hash trees. Neither project has announced plans to adopt Verkle trees or vector commitments.
Should a new project choose a Merkle tree or a Verkle tree in 2026?
For most projects, a Merkle tree is still the safer default given its maturity, lack of trusted setup, and post-quantum compatibility. Verkle trees, or the emerging binary-tree-plus-STARK approach, make sense specifically for systems that need to compress large, multi-key state proofs, such as blockchain light clients aiming for statelessness.
