{"id":"81f4e2b4-6b63-4bd3-91b7-d47b66c4f682","arxiv_id":"2501.05262","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"QMDB uses append-only twigs and an in-memory index to make blockchain state updates and proof generation faster, reporting up to 2.28 million updates per second, with benchmark caveats.","lead":"QMDB is a database design for blockchains that stores key-value data and its Merkle proof tree as one append-only log, grouping entries into 'twigs' so proofs can be computed in memory without extra disk reads. The paper reports throughput up to 6x higher than RocksDB and 8x higher than NOMT, but several benchmark caveats and configuration mismatches mean those numbers need independent confirmation.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The abstract's headline conjunction is unsupported: 'one SSD read per state access' and '2.3 bytes per entry' come from different indexer configurations, so the two properties cannot hold simultaneously in one deployment.","rationale":"The load-bearing concern is not the fairness of the RocksDB/NOMT comparisons, though those are real; it is that the abstract's signature claim bundles together two configuration-dependent properties that cannot coexist in a single deployment. The 'one SSD read per state access' and 'O(1) IOs for updates' are explicitly tied to the default in-memory indexer in §3.2–3.3, while the '2.3 bytes per entry' footprint is explicitly tied to the hybrid indexer in §5 and §4.4. Since the hybrid indexer adds an SSD read per lookup, the I/O advantages disappear exactly in the configuration that delivers the low memory footprint. This is a logical inconsistency in the central claim, not a matter of tuning. The paper deserves credit for shipping code, for the novel twig abstraction, and for honestly reporting that the hybrid indexer costs an extra read; the problem is that the abstract erases that trade-off. The reader's verdict of CONDITIONAL is appropriate: the underlying architecture may be sound, but the paper must present each indexer configuration with its own I/O and memory profile, and the abstract must not imply simultaneous achievement of the best of both.","tokens_in":17,"tokens_out":7640,"duration_ms":112183,"concrete_test":"Instrument the open-source QMDB (github.com/LayerZero-Labs/qmdb) to count actual SSD reads per state access (e.g., with blktrace) under the default in-memory indexer and the hybrid indexer on the same workload and hardware. If the hybrid configuration shows an extra SSD read for resolving the offset before reading the entry—two reads per lookup instead of one—whereas the in-memory configuration shows one, the abstract's combined 'one SSD read per state access ... 2.3 bytes per entry' claim is falsified as stated. A simpler analytical check: re-derive the read path in §3.3 using the hybrid indexer description in §5 and show that the indexer lookup itself must read an SSD-resident log-structured file, adding exactly the 'additional SSD read' the paper admits.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central performance/resource claims are configuration-dependent, and the abstract conflates two mutually exclusive indexer configurations. §3.2 states the default in-memory indexer costs ~15.4 bytes per key and serves lookups in memory to minimize SSD I/Os. §3.3 then defines Read as querying the indexer for the file offset followed by a single SSD read, so the 'one SSD read per state access' and 'O(1) IOs for updates' claims rely on that indexer. §5 explicitly says the hybrid indexer that achieves 2.3 bytes per key 'requires one additional SSD read per lookup.' Thus a deployment using the low-memory hybrid indexer (the one behind the 2.3 bytes/entry and 280-billion-entry scaling claims in §4.4 and Table 4) pays two SSD reads per state access and two reads per update, not one. The abstract's sentence 'one SSD read per state access, O(1) IOs for updates, and in-memory Merkleization on a memory footprint as small as 2.3 bytes per entry' presents these as simultaneous properties of one design, but the paper's own prose shows they are realized in different configurations. This is not a minor wording issue: it changes the I/O complexity used to justify the headline performance and the consumer-grade PC claim (§4.4 uses the in-memory indexer for the 150k updates/s numbers and the hybrid indexer for the 15-billion-entry numbers, so no single configuration delivers both high throughput and the 2.3 bytes/entry footprint). The reader's weakest assumption correctly identifies this conflation.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents QMDB, an authenticated key-value store for blockchain state that unifies KV storage and Merkle tree storage in an append-only structure of fixed-size \"twigs.\" The design performs Merkleization entirely in DRAM while persisting entries to SSD, with the aim of reducing write amplification and DRAM requirements for blockchain nodes. The authors report up to 6x higher update throughput than RocksDB, up to 8x higher than NOMT, up to 2.28 million state updates per second, a memory footprint as low as 2.3 bytes per entry, and, by extrapolation, a capacity of 280 billion entries on a single server. The paper also claims historical state proofs. The architecture is coherent and the I/O complexity analysis is clear, but the headline claims are configuration-dependent and the benchmark methodology is preliminary, so the central claims need revision.","tokens_in":13537,"tokens_out":6010,"duration_ms":54543,"significance":"If the architecture realizes the claimed properties, it could substantially reduce both DRAM and SSD I/O requirements for verifiable databases, potentially lowering the hardware barrier for blockchain participation. Strengths of the paper include a clear identification of a real bottleneck, a novel twig-based append-only design with a plausible in-memory Merkleization mechanism, experimental results at billion-entry scale, a consumer-grade hardware test, and an open-source implementation. However, the abstract and Section 1 present as simultaneous properties that the paper itself shows come from different indexer configurations, and the comparisons to RocksDB and NOMT rest on weak or non-standard baselines. The significance is therefore conditional on correcting these presentation and methodology issues.","major_comments":[{"comment":"The abstract states that QMDB \"enables one SSD read per state access, O(1) IOs for updates, and in-memory Merkleization on a memory footprint as small as 2.3 bytes per entry.\" This conjunction is unsupported by the paper's own text. Section 3.2 says the default in-memory indexer consumes about 15.4 bytes per key, and Section 3.3 says the CRUD operations are presented for that default indexer, which yields one SSD read per lookup. Section 5 says the hybrid indexer \"uses only 2.3 bytes per key but requires one additional SSD read per lookup.\" Thus a deployment using the hybrid indexer to achieve the 2.3 bytes/entry footprint pays two SSD reads per lookup/update, while a deployment using the in-memory indexer to achieve one SSD read per access has a footprint of about 15.4 bytes per entry. A single configuration does not simultaneously deliver both properties. This is a load-bearing issue because the abstract and Section 1 use the conjunction to argue that QMDB is both I/O-optimal and DRAM-minimal. Please rewrite the abstract and the introduction to separate configuration-specific claims, and state explicitly which indexer was used for each reported benchmark.","section":"Abstract; §3.2; §3.3; §5"},{"comment":"The 6x throughput claim compares QMDB, which uses sharding, a multi-stage pipeline, and an in-memory indexer, to a single unsharded RocksDB instance with default parameters and without Merkleization. The paper acknowledges this is preliminary, but the abstract still presents \"6× over the widely used RocksDB\" as a headline result. This comparison is not apples-to-apples, and a more defensible baseline would be a tuned and sharded RocksDB instance, or at least a RocksDB configuration with recommended write/compaction settings. Since the RocksDB result is a central quantitative claim, the limitation should be stated prominently in the abstract or the claim should be softened to \"up to 6× over an untuned single-instance RocksDB.\"","section":"§4.1"},{"comment":"The 8x speedup over NOMT is presented as a normalized comparison, but the two systems are run with different transaction mixes: QMDB uses a 9-write, 15-read, 1-create, 1-delete workload, whereas NOMT's default workload is a 2-read, 2-write transaction. The normalization simply multiplies transaction count by the number of state updates per transaction, which does not account for the different read/write ratios and is not a standard benchmarking methodology. Additionally, NOMT is a prerelease version, as the paper notes. The combination of a non-common workload and a prerelease baseline makes the \"8×\" claim difficult to interpret. A fairer comparison would use a common workload or a more rigorous normalization, and the prerelease status of NOMT should be reflected in the abstract's wording.","section":"§4.2, Table 3"},{"comment":"The abstract states that QMDB \"has proven the capacity to scale to 280 billion entries on a single server,\" but Section 4.4 says the 280 billion number is a \"conservative extrapolation\" from experiments that reached 15 billion entries. The extrapolation is based on DRAM and SSD capacities, but the paper does not provide the formula, the assumed average entry size, or the overhead model, making the result non-reproducible. Extrapolation is not proof, and a reader cannot verify the calculation. Please rephrase the abstract to say \"estimated to scale\" or \"projected to scale,\" and include the extrapolation formula and assumptions in Section 4.4.","section":"Abstract; §4.4, Table 4"}],"minor_comments":[{"comment":"Table 4 is referred to as \"Table 4.4\" in the text; it should be \"Table 4.\"","section":"§4.4"},{"comment":"In the acknowledgments, \"throuhgput\" is a typo for \"throughput.\"","section":"§7"},{"comment":"The term \"N+1 serializability\" is used but not defined; please explain the exact consistency property that QMDB provides.","section":"§3.5"},{"comment":"The statement that 2.28 million updates per second is sufficient to support over one million token transfers per second assumes each transfer causes exactly two state updates; this assumption should be stated explicitly.","section":"§4.3"},{"comment":"The historical proof mechanism is described only qualitatively; the paper does not specify the proof size, the number of SSD reads required to traverse OldId/OldNextKeyId chains, or an asymptotic bound. Adding these costs would make the feature easier to evaluate.","section":"§3.4"},{"comment":"The compaction rule is said to be deterministic and to keep the active-entry ratio above a threshold, but the paper does not explain how this invariant is maintained across nodes in a consensus network, especially under different transaction histories. A brief note on the consensus-safety properties would be helpful.","section":"§3.1"}],"recommendation":"major_revision","confidential_remarks":"The paper comes from an industrial lab and the benchmark results are based on the authors' own utilities. The comparisons are against a prerelease NOMT and a default-configuration, unsharded RocksDB, which weakens the headline numbers. The most important issue is the conflation of the two indexer configurations in the abstract, which overstates what a single deployment can achieve. The extrapolation to 280 billion entries is presented as proof rather than projection. These issues are fixable with careful rewording and a more transparent methodology, so I recommend major revision rather than rejection. A commit hash or exact version of the open-source code used for benchmarks would also improve reproducibility."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe thing to know about QMDB: the storage engine is new and the core trick is real. Grouping state updates into fixed-size append-only twigs with a 256-byte ActiveBits bitmap, then Merkleizing only twig roots in memory, is a legitimate way to compress the Merkle layer by orders of magnitude. The OldId/OldNextKeyId pointer graph for historical inclusion/exclusion proofs is also new and neat; it lets you reconstruct old state without keeping per-block snapshots. I don't see those pieces in the MPT/NOMT/MoeingADS lineage. The architecture is coherent, and the O(1) update I/O story follows from the append-only twig plus in-memory indexer.\n\nWhere the paper goes soft is in the headline numbers. The abstract says 'one SSD read per state access... in-memory Merkleization on a memory footprint as small as 2.3 bytes per entry,' but those two properties come from different indexer configurations. The in-memory indexer is ~15.4 bytes per key and gives the single-read path; the hybrid indexer is ~2.3 bytes per key but 'requires one additional SSD read per lookup' (Section 5). No single configuration delivers both. That matters because the 2.3 bytes/entry drives the 280-billion-entry scaling table and the 'consumer PC' claim, while the single-read claim drives the O(1) I/O justification. The paper needs to state which configuration is being benchmarked in each experiment and stop implying they're simultaneous. This is not a nitpick; it changes the resource/performance tradeoff.\n\nThe comparisons are also weaker than they first look. RocksDB is run unsharded, untuned, and without Merkleization, so 6x over RocksDB is a lower bound, not a fair baseline. NOMT is prerelease, uses a different workload, and throughput is normalized by update count, which can flatter append-only designs. No error bars, no shipped benchmark artifact (the repo link is in the paper, but the eval code isn't clearly described). That said, the authors acknowledge most of these caveats in the text, which is more honest than usual for a systems paper.\n\nBottom line: the central idea holds up and deserves serious scrutiny. Send it to peer review, but the review should demand fair baselines and a configuration-by-configuration breakdown of the claims. If the numbers replicate, this is a meaningful advance for blockchain node economics.","headline":"A genuinely new verifiable DB architecture with credible O(1) I/O claims, but the abstract oversells by merging benchmarks from two different indexer configurations.","tokens_in":14115,"tokens_out":2134,"would_cite":false,"duration_ms":20084,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"QMDB merges key-value storage and Merkle proofs in one append-only tree, claiming 6-8x throughput gains and one SSD read per state access.","keywords":["QMDB","authenticated data structure","Merkle tree","append-only log","blockchain state management","key-value store","SSD optimization","historical proofs"],"falsifier":"On identical hardware, populate the same multi-billion-entry workload under both indexers and measure reads per lookup and DRAM per entry; the central claim holds only if the in-memory indexer holds near 15.4 bytes per key with one read per lookup and the hybrid indexer holds near 2.3 bytes per key with exactly one extra read per lookup. Also, extrapolate DRAM per entry at 15 billion entries toward the claimed 280-billion capacity; if marginal overhead grows super-linearly, the extrapolated maximum is unsupported.","tokens_in":12986,"feed_emoji":"⚡","tokens_out":6256,"duration_ms":55484,"temperature":0.7,"pith_summary":"The paper introduces QMDB, a verifiable key-value store that fuses the physical storage of blockchain state with the Merkle tree that authenticates it. Its central claim is that grouping all state updates into fixed-size immutable subtrees, called twigs, lets Merkleization run entirely in DRAM and reduces state access to one SSD read, updates to O(1) I/O, and write amplification to near zero. If that holds, QMDB would deliver up to 6x the update throughput of RocksDB and up to 8x that of NOMT, a leading authenticated database, and sustain 2.28 million state updates per second across 14 billion entries. The authors further claim that this makes million-token-transfer-per-second blockchains feasible and lowers full-node hardware requirements to consumer-grade hardware.","feed_headline":"Append-only twigs give QMDB 8x speedup over NOMT","feed_subtitle":"A unified key-value and Merkle store claims one SSD read per state access and millions of updates per second.","key_machinery":"The load-bearing object is the twig: a fixed-depth, fixed-size immutable subtree (2048 leaves in the implementation) that stores a 32-byte Merkle root and a 256-byte ActiveBits bitmap in DRAM instead of the full state. Twigs progress through Fresh, Full, Inactive, and Pruned states; only the fresh twig accepts appends, and full twigs are flushed to SSD in one sequential write. This compression is what makes in-memory Merkleization possible: all Merkleization reads and writes touch only tree metadata, never entry contents.","core_discovery":"QMDB's core discovery is that the Merkle tree's metadata, not its leaves, is what makes authentication expensive; by freezing leaves into append-only twigs of 2048 entries, each twig can be represented in DRAM by a 32-byte root hash and a 256-byte ActiveBits bitmap. Because full twigs are immutable, the system never needs to read or write entry data to update the Merkle root, so state updates cost one SSD read plus an amortized batched write, and Merkleization costs zero SSD I/O. The paper claims this design achieves 601K updates per second at 6 billion entries against RocksDB, 8x normalized throughput over NOMT at 4 billion keys, and 2.28 million updates per second with asynchronous and direct I/O, with benchmarks up to 15 billion entries and an extrapolated capacity of 280 billion on a single server. The 2.3 bytes-per-entry memory figure comes from a hybrid indexer, which the paper says adds one SSD read per lookup. It also introduces a graph formed by OldId and OldNextKeyId pointers that supports historical inclusion, exclusion, and full state reconstruction proofs at arbitrary block heights.","pith_inferences":["The paper's two headline properties are measured in different configurations: the in-memory indexer costs about 15.4 bytes per key and gives one SSD read per lookup, while the hybrid indexer costs 2.3 bytes per key but adds one SSD read per lookup, so a deployment cannot claim both at once.","The 9-byte truncated key in the default indexer raises collision probability; the paper describes this as a controlled trade, but the effect on adversarial workloads is not quantified.","Because twig roots depend on the sequence of entries, consensus compatibility requires deterministic compaction and replay rules; the paper says compaction must be deterministic but leaves reorg handling to the chain.","The 8x speedup against a prerelease NOMT with a different pipelining model and a normalized workload may narrow as both systems mature; the paper acknowledges both are pre-release."],"forward_implications":["If the claims hold, a full blockchain node could run on roughly $540 hardware while sustaining tens of thousands of operations per second with billions of entries.","State synchronization can proceed at twig granularity with inclusion proofs, making peer-to-peer sync simpler.","Historical proofs at the latest block enable applications such as time-weighted average price queries without archive nodes.","Per-transaction state roots become cheap enough to feed ZK-proof generation pipelines at maximum parallelism.","The write-amplification reduction could let chains with large state run on flash rather than DRAM-heavy servers."],"supporting_citations":[{"why":"The leading verifiable database used as the baseline for QMDB's claimed 8x normalized throughput advantage.","marker":"[10]"},{"why":"Provides the recommended RocksDB parameters for the comparison, establishing the general-purpose KV store baseline.","marker":"[9]"},{"why":"Defines the O(log N) per-update cost of Merkle Patricia Tries that motivates QMDB's twig design.","marker":"[17]"},{"why":"A prior authenticated storage design using vector commitments that QMDB contrasts with its unified, append-only approach.","marker":"[13]"},{"why":"A recency-segregation ADS whose compaction strategy QMDB extends and compares against in write-amplification terms.","marker":"[14]"},{"why":"A prior append-only Merkle tree ADS whose batched compaction motivates QMDB's streaming and low-memory indexer.","marker":"[22]"},{"why":"Defines Merkle Mountain Ranges, an append-only accumulator that cannot handle live updates, motivating twig-based live state.","marker":"[23]"},{"why":"A verifiable ledger database with deferred verification, used to contrast QMDB's real-time state verification.","marker":"[26]"}],"fun_headline_variants":["QMDB hits 2.28M state updates/s with one SSD read per access","Append-only twigs: one SSD read, 8x NOMT, 2.28M updates/s","QMDB: 2.3 bytes per entry, historical proofs, 1M TPS","QMDB: first to 1M token transfers/sec with 2.28M updates/s","QMDB's twigs: 8x NOMT, 1 SSD read, 2.3 bytes per entry"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The selling point that one SSD read serves every state access while DRAM stays at 2.3 bytes per entry rests on two different indexer configurations, not a single one; if that combined claim must hold at once, the paper does not yet show it.","fun_headline_variants_meta":{"raw":{"variants":["QMDB hits 2.28M state updates/s with one SSD read per access","Append-only twigs: one SSD read, 8x NOMT, 2.28M updates/s","QMDB: 2.3 bytes per entry, historical proofs, 1M TPS","QMDB: first to 1M token transfers/sec with 2.28M updates/s","QMDB's twigs: 8x NOMT, 1 SSD read, 2.3 bytes per entry"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001469,"raw_usage":{"total_tokens":5954,"prompt_tokens":1041,"completion_tokens":4913,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":657,"completion_tokens_details":{"reasoning_tokens":4783}},"tokens_in":657,"tokens_out":4913,"duration_ms":33577,"temperature":1.0,"reasoning_tokens":4783,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:13:20.537762+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On identical hardware, populate the same multi-billion-entry workload under both indexers and measure reads per lookup and DRAM per entry; the central claim holds only if the in-memory indexer holds near 15.4 bytes per key with one read per lookup and the hybrid indexer holds near 2.3 bytes per key with exactly one extra read per lookup. Also, extrapolate DRAM per entry at 15 billion entries toward the claimed 280-billion capacity; if marginal overhead grows super-linearly, the extrapolated maximum is unsupported.","supporting_citations":[{"cited_title":"Introducing nomt","cited_arxiv_id":null,"evidence_quote":"The leading verifiable database used as the baseline for QMDB's claimed 8x normalized throughput advantage."},{"cited_title":"Setup options and basic tuning - rocksdb wiki","cited_arxiv_id":null,"evidence_quote":"Provides the recommended RocksDB parameters for the comparison, establishing the general-purpose KV store baseline."},{"cited_title":"Reth: A modular and high-performance ethereum execution layer client","cited_arxiv_id":null,"evidence_quote":"Defines the O(log N) per-update cost of Merkle Patricia Tries that motivates QMDB's twig design."},{"cited_title":"M., Y ANG , G., W U, M., X U, W., AND LONG , F","cited_arxiv_id":null,"evidence_quote":"A prior authenticated storage design using vector commitments that QMDB contrasts with its unified, append-only approach."},{"cited_title":"Moltdb: Accelerating blockchain via ancient state segregation","cited_arxiv_id":null,"evidence_quote":"A recency-segregation ADS whose compaction strategy QMDB extends and compares against in write-amplification terms."},{"cited_title":"MoeingADS","cited_arxiv_id":null,"evidence_quote":"A prior append-only Merkle tree ADS whose batched compaction motivates QMDB's streaming and low-memory indexer."},{"cited_title":"Merkle mountain ranges","cited_arxiv_id":null,"evidence_quote":"Defines Merkle Mountain Ranges, an append-only accumulator that cannot handle live updates, motivating twig-based live state."},{"cited_title":"GlassDB: An Efficient Verifiable Ledger Database System Through Transparency","cited_arxiv_id":"2207.00944","evidence_quote":"A verifiable ledger database with deferred verification, used to contrast QMDB's real-time state verification."}],"review_version":1}