Pith. sign in

REVIEW 4 major objections 6 minor 2 cited by

QMDB: Quick Merkle Database

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2501.05262 v3 pith:T5TTHC4Y submitted 2025-01-09 cs.NI cs.DB

Isaac Zhang , Ryan Zarick , Daniel Wong , Thomas Kim , Bryan Pellegrino , Mignon Li , Kelvin Wong This is my paper · ORCID
classification cs.NIcs.DB
keywords QMDBauthenticateddatastructureMerkletreeappend-onlylogblockchainstatemanagementkey-valuestoreSSDoptimizationhistoricalproofs
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

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.

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 (4)
  1. [Abstract; §3.2; §3.3; §5] 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.
  2. [§4.1] 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."
  3. [§4.2, Table 3] 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.
  4. [Abstract; §4.4, Table 4] 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.
minor comments (6)
  1. [§4.4] Table 4 is referred to as "Table 4.4" in the text; it should be "Table 4."
  2. [§7] In the acknowledgments, "throuhgput" is a typo for "throughput."
  3. [§3.5] The term "N+1 serializability" is used but not defined; please explain the exact consistency property that QMDB provides.
  4. [§4.3] 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.
  5. [§3.4] 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.
  6. [§3.1] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: headline throughput and capacity claims rest on external benchmarks and arithmetic extrapolations from stated memory formulas, not on fitted or self-cited inputs.

full rationale

QMDB's central claims are not produced by fitting a parameter to the outcome. The 6x vs RocksDB and 8x vs NOMT results are measured against external implementations on the same hardware; NOMT parameters were checked with NOMT's authors ([1]), and the comparison is normalized by workload. The 'one SSD read per state access' and 'O(1) IOs' statements are design-level descriptions of the CRUD path (Sections 3.2-3.3) using the default in-memory indexer, not predictions fitted from measured data. The 2.3 bytes/entry memory footprint and the 280-billion-entry capacity are arithmetic extrapolations from the stated hybrid-indexer memory formula (Section 4.4 and Table 4), and the paper itself labels the 280B figure as a 'maximum theoretical number of entries' and says it 'conservatively extrapolate[s]'. The abstract's conjunction of the single-read property with the 2.3 bytes/entry footprint is internally inconsistent because Section 5 states the hybrid indexer 'requires one additional SSD read per lookup'; that is a consistency or evidence caveat, not a circular derivation, and it does not make any result equivalent to its input by construction. The paper does not rely on load-bearing self-citations or on a uniqueness theorem imported from the authors' prior work; related systems such as LVMT, MoeingADS, and NOMT are external and are not used to justify QMDB's design. No fitted parameter is renamed as a prediction, and no known result is repackaged as new while depending on itself. The fact that the authors define the benchmark workload and run their own implementation is normal experimental practice; the comparisons target independently implemented systems, so independent replication is needed but that is a standard evidence requirement rather than circularity.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claims rest on hand-chosen system parameters (twig size, key truncation, compaction threshold) and domain assumptions about blockchain workloads. No physical or hidden entity is introduced; the twig is an implemented data structure. The most fragile assumption is that the indexer can deliver one SSD read per state access while keeping the 2.3 bytes per entry footprint, which is contradicted by Section 5 for the hybrid indexer.

free parameters (3)
  • Twig size = 2048 entries
    Chosen in implementation (Section 3.1); determines DRAM footprint, SSD write amortization, and proof depth. Not derived from first principles.
  • Indexer key truncation length = 9 most significant bytes of key hash (2 bytes shard + 7 bytes key)
    Chosen to fit the index in DRAM; increases collision probability and affects lookup correctness and performance (Section 3.2).
  • Active entry ratio threshold for compaction = unspecified
    The paper says compaction triggers when the active entry ratio per shard is below a predefined threshold, but the threshold value and exact rule are not given; determinism depends on it (Section 3.1).
assumptions (4)
  • domain assumption Blockchain workloads do not need range queries, prefix scans, or spatial locality, so QMDB can safely drop these KVDB features.
    Sections 1 and 4.1 justify eliminating features found in RocksDB; if a target blockchain relies on such operations, the performance comparison is not valid.
  • ad hoc to paper The deterministic compaction and twig pruning rules keep the active-entry ratio and tree shape consistent across nodes in a consensus network.
    Section 3.1 states compaction 'must be deterministic when used in a consensus system' but no proof or full algorithm is given.
  • domain assumption The Merkle tree can be recomputed on startup from twig hashes and does not need persisted upper nodes, because upper nodes are immutable once all descendant entries are initialized.
    Section 3.1 relies on immutability of full and pruned twigs to keep Merkleization in memory; if a twig's ActiveBits or entries can change after flush, the root becomes stale.
  • domain assumption Key truncation to 9 bytes does not break inclusion or exclusion proofs because collision handling in the B-tree resolves ambiguous prefixes.
    Section 3.2 says truncation 'slightly increases the likelihood of key collisions' but does not specify full-key resolution or the extra IO cost when collisions occur.

how reviews work

0 comments
Cite this review

Pith. "Pith review of QMDB: Quick Merkle Database." pith.science (2026). https://pith.science/paper/T5TTHC4Y

@misc{pith2026250105262,
  author       = {Pith},
  title        = {Pith review of: QMDB: Quick Merkle Database},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T5TTHC4Y}},
  note         = {Machine review of arXiv:2501.05262}
}
read the original abstract

Quick Merkle Database (QMDB) addresses longstanding bottlenecks in blockchain state management by integrating key-value (KV) and Merkle tree storage into a single unified architecture. QMDB delivers a significant throughput improvement over existing architectures, achieving up to 6X over the widely used RocksDB and 8X over NOMT, a leading verifiable database. Its novel append-only twig-based design 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, enabling it to run on even modest consumer-grade PCs. QMDB scales seamlessly across both commodity and enterprise hardware, achieving up to 2.28 million state updates per second. This performance enables support for 1 million token transfers per second (TPS), marking QMDB as the first solution achieving such a milestone. QMDB has been benchmarked with workloads exceeding 15 billion entries (10X Ethereum's 2024 state) and has proven the capacity to scale to 280 billion entries on a single server. Furthermore, QMDB introduces historical proofs, unlocking the ability to query its blockchain's historical state at the latest block. QMDB not only meets the demands of current blockchains but also provides a robust foundation for building scalable, efficient, and verifiable decentralized applications across diverse use cases.

Figures

Figures reproduced from arXiv: 2501.05262 by the authors.

Figure 1
Figure 1. Entries are inserted sequentially into the leaves of the Fresh twig, and all leaves have the same depth. The [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. QMDB prefetches data (prefetcher), performs the state transition (updater), then commits the updated state to the Merkle tree and persistent storage (commit￾ter). State updates are parallelized in QMDB through sharding and pipelining. QMDB shards its key space into contiguous spans us￾ing the most significant bits—for example, the first 4 bits can create 16 shards—with boundary nodes to de￾fine logical boundaries th… view at source ↗
Figure 3
Figure 3. shows the throughput of QMDB compared to RocksDB (storing the application-level key-values with no Merkleization), demonstrating that QMDB de￾livers 6× more updates per second than RocksDB. This speedup is in fact an underestimate of QMDB’s advan￾tage over RocksDB-based systems, given that all bench￾marks compare QMDB with Merkleization to RocksDB Reads Updates Insertions Deletions 0 100 200 300 400 500 600 700 Ops … view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. AlDBaran: Towards Blazingly Fast State Commitments for Blockchains

    cs.CR 2025-08 conditional novelty 6.0 of 10

    A split in-memory/disk architecture with lock-free sharded sparse Merkle updates and SIMD hashing is claimed to sustain 48M state updates/s (24M with history) on a 96-core AWS machine.

  2. FAFO: Over 1 million TPS on a single node running EVM while still Merkleizing every block

    cs.DC 2025-07 conditional novelty 6.0 of 10

    FAFO, an ahead-of-formation transaction scheduler with Bloom-filter conflict detection, reports 1.1M native transfer TPS on a single node with per-block Merkleization.

Reference graph

Works this paper leans on

27 extracted references · 27 canonical work pages · cited by 2 Pith papers

  1. [1]

    https://github.com/ thrumdev/nomt/issues/611

    Reproducing benchmark numbers. https://github.com/ thrumdev/nomt/issues/611

    work page

  2. [2]

    Amazon Quantum Ledger Database (QLDB), 2019

    A MAZON WEB SERVICES . Amazon Quantum Ledger Database (QLDB), 2019

    work page 2019

  3. [3]

    Sql ledger: Cryptographically verifiable data in azure sql database

    A NTONOPOULOS , P., K AUSHIK , R., K ODAVALLA , H., R OS- ALES ACEVES , S., W ONG , R., A NDERSON , J., AND SZY- MASZEK , J. Sql ledger: Cryptographically verifiable data in azure sql database. In Proceedings of the 2021 international con- ference on management of data (2021), pp. 2437–2449

    work page 2021

  4. [4]

    Optimization of merkle tree structures: A focus on subtree implementation

    A YYALASOMAYAJULA , P., AND RAMKUMAR , M. Optimization of merkle tree structures: A focus on subtree implementation. In 2023 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC) (2023), IEEE, pp. 59–67

    work page 2023

  5. [5]

    Efficient sparse merkle trees: Caching strategies and secure (non-) membership proofs

    D AHLBERG , R., P ULLS , T., AND PEETERS , R. Efficient sparse merkle trees: Caching strategies and secure (non-) membership proofs. In Secure IT Systems: 21st Nordic Conference, Nord- Sec 2016, Oulu, Finland, November 2-4, 2016. Proceedings 21 (2016), Springer, pp. 199–215. 10

    work page 2016

  6. [6]

    Accelerating merkle pa- tricia trie with gpu

    D ENG , Y., Y AN, M., AND TANG , B. Accelerating merkle pa- tricia trie with gpu. Proceedings of the VLDB Endowment 17 , 8 (2024), 1856–1869

    work page 2024

  7. [7]

    Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC

    D WORKIN , M. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. Special Publication 800-38D, NIST, 2007

    work page 2007

  8. [8]

    Towards merkle trees for high-performance data systems

    E L-HINDI , M., Z IEGLER , T., AND BINNIG , C. Towards merkle trees for high-performance data systems. In Proceedings of the 1st Workshop on Verifiable Database Systems(2023), pp. 28–33

    work page 2023

Show all 27 references
  1. [9]

    Setup options and basic tuning - rocksdb wiki

    F ACEBOOK . Setup options and basic tuning - rocksdb wiki. https://github.com/facebook/rocksdb/wiki/ Setup-Options-and-Basic-Tuning , 2024. Accessed: 2024- 12-21

    2024

  2. [10]

    Introducing nomt

    H ABERMEIER , R. Introducing nomt. Blog post, May 2024

    2024

  3. [11]

    Nomt: Scaling blockchains with a high- throughput state database

    H ABERMEIER , R. Nomt: Scaling blockchains with a high- throughput state database. Presented at sub0 reset 2024, Novem- ber 2024

    2024

  4. [12]

    J EON , K., L EE, J., K IM, B., AND KIM, J. J. Hardware ac- celerated reusable merkle tree generation for bitcoin blockchain headers. IEEE Computer Architecture Letters (2023)

    2023

  5. [13]

    M., Y ANG , G., W U, M., X U, W., AND LONG , F

    L I, C., B EILLAHI , S. M., Y ANG , G., W U, M., X U, W., AND LONG , F. Lvmt: An efficient authenticated storage for blockchain. ACM Transactions on Storage 20, 3 (2024), 1–34

    2024

  6. [14]

    Moltdb: Accelerating blockchain via ancient state segregation

    L IANG , J., C HEN , W., H ONG , Z., Z HU, H., Q IU, W., AND ZHENG , Z. Moltdb: Accelerating blockchain via ancient state segregation. IEEE Transactions on Parallel and Distributed Sys- tems (2024)

    2024

  7. [15]

    G., AND KAMINSKY , M

    L IM, H., F AN, B., A NDERSEN , D. G., AND KAMINSKY , M. Silt: a memory-efficient, high-performance key-value store. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles (New York, NY , USA, 2011), SOSP ’11, As- sociation for Computing Machinery, p. 1–13

    2011

  8. [16]

    G., AND KAMINSKY , M

    L IM, H., H AN, D., A NDERSEN , D. G., AND KAMINSKY , M. Mica: a holistic approach to fast in-memory key-value storage. In Proceedings of the 11th USENIX Conference on Networked Systems Design and Implementation (USA, 2014), NSDI’14, USENIX Association, p. 429–444

    2014

  9. [17]

    Reth: A modular and high-performance ethereum execution layer client

    P ARADIGM . Reth: A modular and high-performance ethereum execution layer client. https://github.com/paradigmxyz/ reth, 2022. Accessed: 2024-11-25

    2022

  10. [18]

    Merkle mountain ranges: Historical block hash accumulator

    P ROTOCOL , H. Merkle mountain ranges: Historical block hash accumulator. https://docs.herodotus.dev/herodotus- docs/protocol-design/historical-block-hash- accumulator/merkle-mountain-ranges . Accessed: 2024-11-18

    2024

  11. [19]

    {mLSM}: Making authenticated storage faster in ethereum

    R AJU , P., P ONNAPALLI , S., K AMINSKY , E., O VED , G., KEENER , Z., C HIDAMBARAM , V., AND ABRAHAM , I. {mLSM}: Making authenticated storage faster in ethereum. In 10th USENIX Workshop on Hot Topics in Storage and File Sys- tems (HotStorage 18) (2018)

    2018

  12. [20]

    Introducing SP1: A performant, 100% open-source, contributor-friendly zkVM, 2024

    R OY, U. Introducing SP1: A performant, 100% open-source, contributor-friendly zkVM, 2024. Retrieved on December 20, 2024

    2024

  13. [21]

    Veritasdb: High throughput key-value store with integrity

    S INHA , R., AND CHRISTODORESCU , M. Veritasdb: High throughput key-value store with integrity. Cryptology ePrint Archive (2018)

    2018

  14. [22]

    MoeingADS

    S MART BCH T EAM. MoeingADS. https://github.com/ smartbch/moeingads, 2024. Accessed: 2024-11-25

    2024

  15. [23]

    Merkle mountain ranges

    T ODD , P. Merkle mountain ranges. https: //github.com/opentimestamps/opentimestamps- server/blob/master/doc/merkle-mountain-range.md ,

  16. [24]

    Ethereum: A secure decentralized generalized trans- action ledger

    W OOD , G. Ethereum: A secure decentralized generalized trans- action ledger. In Ethereum Yellow Paper(2014)

    2014

  17. [25]

    Ledgerdb: A centralized ledger database for universal audit and verification

    Y ANG , X., Z HANG , Y., WANG , S., Y U, B., L I, F., L I, Y., AND YAN, W. Ledgerdb: A centralized ledger database for universal audit and verification. Proceedings of the VLDB Endowment 13, 12 (2020), 3138–3151

    2020

  18. [26]

    Y UE, C., D INH , T. T. A., X IE, Z., Z HANG , M., C HEN , G., OOI, B. C., AND XIAO, X. Glassdb: An efficient verifiable ledger database system through transparency. arXiv preprint arXiv:2207.00944 (2022). 11

    2022 arXiv

  19. [2016]

    Accessed: 2024-11-18

    2024

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.