QMDB
QMDB (Quick Merkle Database) is a verifiable database built by Commonware and LayerZero. It unifies key-value storage and Merkle tree maintenance into a single system, solving one of the oldest performance bottlenecks in blockchain infrastructure.
The core insight is an append-only twig design. Instead of mutating state in place (the way every Merkle Patricia Trie implementation works), QMDB organizes data into fixed-size immutable subtrees called “twigs” — each holding exactly 2,048 leaf entries. New writes append; old entries get marked inactive. This means:
- One SSD read per state access (the indexer gives you the file offset directly)
- O(1) I/O for updates — new entries go to an in-memory twig, flushed to SSD in a single sequential write when full
- Merkleization happens entirely in memory — only the tree’s right edge changes, so you never touch disk for hash updates
Traditional Merkle Patricia Trie systems incur O((log N)^2) I/O because they store both the Merkle tree and state in separate key-value stores. QMDB collapses this.
The numbers
On an AWS c7gd.metal (64 vCPUs, 256GB DRAM, 2 NVMe SSDs):
- 6x throughput over RocksDB
- 8x throughput over NOMT (the previous state-of-the-art verifiable database)
- 601K updates/sec at 6 billion entries
On high-end hardware (i8g.metal-24xl): 2.28 million updates/sec, supporting over 1 million token transfers per second.
On a $540 mini PC (AMD R7-5825U, 64GB DDR4, 4TB NVMe): still hits 150K updates/sec up to 1 billion entries. Consumer-grade hardware running verifiable state at scale.
They tested with 15 billion entries — 10x Ethereum’s 2024 state size. Theoretical max is 280 billion entries on a single machine.
Memory efficiency
The memory footprint is remarkably small. For 1 billion entries, QMDB needs roughly 160MB of DRAM for twig roots and bitmaps. The in-memory indexer uses ~15.4 bytes per key. A hybrid SSD-optimized variant drops that to 2.3 bytes per key.
When a twig goes fully inactive (all entries overwritten), it gets pruned — the entire 2,048-entry subtree compresses down to a single 32-byte hash and a 256-byte bitmap. That’s 99.9% compression.
Why it matters
Every blockchain stores state — account balances, contract storage, token ownership. Proving that state is correct (or that something doesn’t exist) requires Merkle proofs. The faster you can update state and compute proofs, the more transactions your chain can process.
QMDB also supports historical state queries at any block height and exclusion proofs (proving a key doesn’t exist), which are hard problems in most Merkle tree implementations. They achieve this by maintaining keys in lexicographic order via a Merkle Mountain Range layered over a sequential log of updates.
The paper is thorough and the code is MIT/Apache-2 licensed. Commonware wrote a good companion blog post explaining the design decisions and how QMDB fits into their broader infrastructure work.