Pith. sign in

REVIEW 4 major objections 6 minor 17 references

AlDBaran: Towards Blazingly Fast State Commitments for Blockchains

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

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

Pith's one-line read AlDBaran claims an authenticated Merkle-tree state store can sustain roughly 48 million updates per second on a 96-core server by keeping the hot path in DRAM and computing the state root only once per block.

desk verdict Genuinely engineered system with a novel hot/cold split and real measured throughput, but the headline 48M/s is conditional on uniform keys and the 50 Gbps claim doesn't survive the paper's own arithmetic. read the letter →

arxiv 2508.10493 v1 pith:ZYKZBEJQ submitted 2025-08-14 cs.CR cs.GT

Bernhard Kauer , Aleksandr Petrosyan , Benjamin Livshits This is my paper
classification cs.CRcs.GT
keywords authenticateddatabaseMerkletreeblockchainstatecommitmentconcurrentupdatessparsehistoricalproofsSIMDhashingsnapshots
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

AlDBaran is an authenticated database, a key-value store that continuously maintains a Merkle-tree commitment to blockchain state. The paper claims that by keeping the entire hot path in DRAM, sharding the key space across threads without locks, and recomputing the tree root only once per block, such a database can process about 48 million state updates per second on a 96-core server and about 8 million on a laptop, with historical inclusion and exclusion proofs generated offline from snapshot files. If true, state commitments stop being the bottleneck for blockchains aiming at millions of transactions per second, and chains without native state commitments could add light-client and rollup support. The central trade baked into the design is static sharding: the speed depends on updates spreading evenly across key-space shards.

What carries the argument

The load-bearing mechanism is a lock-free, statically sharded sparse binary Merkle tree inside the in-memory Pleiades engine. The top bits of each hashed key select a thread-owned subtree, so concurrent updates never contend; a deterministic breadth-first node layout lets the CPU prefetch the next node into cache; a throughput-oriented SIMD hash built on BLAKE2 hashes multiple tree branches at once; and lazy root computation defers all top-level hashing to the end of a block. Snapshot files, written asynchronously, are the only persistent artifact and feed the separate Hyades proof engine.

What would settle it

Run Pleiades on the same 96-core server with all keys sharing one six-bit prefix, or with a Zipfian key distribution, and check whether throughput falls toward the single-core rate of roughly 0.64 million updates per second; if it stays near 48 million, the sharding assumption is not load-bearing.

Watch

Extended reading notes

Core claim

AlDBaran's central claim is that an authenticated database can serve blockchain state commitments at network line rate if the database eliminates disk I/O from the critical path and separates the in-memory state updater (Pleiades) from the historical proof engine (Hyades). Pleiades applies every update to a sparse binary Merkle tree in DRAM, dispatches updates to thread-private subtrees by the first bits of the key so no locks are needed, stops per-update hashing at per-thread subtree roots, and only recomputes the top of the tree once per block. Snapshots transfer state asynchronously to Hyades, which builds compact 64-bit entries and can answer inclusion and exclusion proofs for any histor

Load-bearing premise

The scaling claims assume the first six bits of keys distribute updates evenly across shards; the benchmarks use uniformly random 256-bit keys, so a workload that concentrates on one shard would collapse throughput to that shard's serial rate.

Editorial extensions

If this is right

  • A blockchain processing one million transactions per second with roughly three state updates per transaction needs about 3 million updates per second; AlDBaran's measured 48 million per second leaves a wide margin on the same machine.
  • Blockchains without production state commitments, including the high-throughput chain the paper identifies, could add light-client and rollup support by plugging AlDBaran in.
  • Historical inclusion and exclusion proofs can be served from snapshot files without touching the hot path, enabling per-block or intra-block commitments and applications such as time-weighted average price aggregation at arbitrary granularity.
  • Because snapshots are the only persistent storage and can be disabled, resource-constrained deployments can trade historical proofs for roughly double the update throughput.
  • The design runs on ordinary CPUs and portable hardware, so the speedup does not depend on specialized accelerators or kernel modifications.

Reading between the lines

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

  • The headline 48 million updates per second assumes uniformly random keys spread evenly across shards; a deployment facing adversarial or skewed key distributions would need dynamic rebalancing or a different dispatch rule before the number transfers.
  • The split into a hot in-memory engine and an offline proof engine implies a scale-out architecture where snapshot files are shipped over the network to separate proof-serving machines; the paper gestures at this possibility but does not benchmark it.
  • The SIMD trick of transposing short hash inputs to fill registers could generalize to any short-input hashing workload, not just Merkle tree updates.
  • If the 50 Gbps line-rate claim is taken at face value, the next bottleneck moves to snapshot I/O and network distribution; an end-to-end measurement with snapshot shipping enabled would be a natural stress test.
Share X Bluesky LinkedIn Reddit HN

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 AlDBaran, an authenticated database for blockchain state commitments, split into Pleiades (an in-memory, lock-free, sharded sparse Merkle tree) and Hyades (a snapshot-based historical proof generator). The central performance claims are a sustained 48M state updates/s on a 96-core AWS i7ie-metal-48xl machine without history, 24M updates/s with snapshots at 500 ms, and roughly 8M/5M updates/s on an Apple M4 Pro. The authors also claim 50 Gbps network-throughput capability, historical inclusion/exclusion proofs, and an order-of-magnitude advantage over QMDB. The paper includes architectural details, proof-generation and verification algorithms, a benchmark study, and a comparison with QMDB measured on the same hardware.

Significance. If the throughput claims hold, AlDBaran would be a significant step toward making authenticated state commitments feasible for very high-throughput blockchains: 48M updates/s at roughly three updates per transaction corresponds to about 16M TPS, far above any deployed chain. The architectural separation of an in-memory merkleization hot path from asynchronous snapshot-based proof generation is a plausible and useful design direction. The paper also reports measurements on specific hardware, provides both history-enabled and history-disabled numbers, and includes a same-machine comparison against QMDB, which is valuable. However, the headline claims rest on workload assumptions and some arithmetic that are not yet fully supported; these issues are load-bearing and need to be addressed before the paper can be accepted.

major comments (4)
  1. [§4.1, §7.1.1] The static key-prefix sharding described in §4.1 makes the 48M/s headline conditional on a uniform key distribution. The paper states that 'the first six bits of the key determine which thread updates are dispatched to' and that leaf assignment is static, with no rebalancing or work-stealing. However, the only reported workload uses '256-bit uniformly random keys' (§7.1). Blockchain state updates are typically highly skewed toward hot accounts; all updates to a single account are routed to one shard, turning that shard into a serial bottleneck at the single-core rate of about 0.64M updates/s reported in §7.1.1. The paper does not report a skewed or repeated-key workload, and the text is ambiguous about whether the sharding prefix is taken on the raw key or on its hash. This is a structural property of the design, not a measurement artifact. Please either clarify that sharding is on the h
  2. [§7.1.2] The 50 Gbps claim is inconsistent with the paper's own numbers. The text states that 'Each update serializes 400 bytes of snapshot data' and that enabling Hyades 'cuts the performance in half to 24M ups.' If 24M updates/s each produce 400 bytes, the serialized stream is 24e6 × 400 × 8 = 76.8 Gbps, not 50 Gbps. If the intended statement is that the system can sustain 50 Gbps, then the maximum update rate for this snapshot format is 50e9/8/400 ≈ 15.6M updates/s, which contradicts the reported 24M/s with history. The abstract's claim that the system is 'capable of handling state updates efficiently at a network throughput of 50 Gbps' therefore needs either a corrected arithmetic statement, a measured network-throughput benchmark, or a clear definition of the relationship between update rate, serialized bytes, and the 50 Gbps figure.
  3. [§5.3] The paper introduces 'Throughput Optimized SIMD-friendly Hash functions' (TOSH-functions) but does not specify whether these are new cryptographic hash functions or merely a SIMD-friendly software layout for an existing hash such as BLAKE2s. Earlier in §5.1 the authors argue that 'blake2s is the optimal hash function,' yet §5.3 says the implementation 'makes use of the throughput-optimized hash functions that were designed specifically for AlDBaran. We call these TOSH-functions.' If TOSH is a novel hash function, its preimage resistance and collision resistance are not analyzed, which would undermine the core security of the Merkle commitments. If TOSH is just a SIMD batching scheme applied to BLAKE2s, the terminology is misleading and should be corrected. This point is load-bearing because the root hash provides the integrity guarantee.
  4. [§7.3] The experimental summary states 'Tuning snapshot to 500ms gives 2× over baseline state updates per second; disabling yields another 2×.' This is confusing: Figure 11 and the text in §7.1.2 show that enabling 500 ms snapshots reduces throughput by half relative to snapshots disabled, so the factor descriptions appear inverted. Please clarify the baseline and the direction of each effect, since this summary is the main place where a reader extracts the tunable trade-offs.
minor comments (6)
  1. [§7.1] The benchmark section states that the workload has 90% updates, 5% inserts, and 5% deletes, but the reported QMDB comparison in §8.2 uses '1,280,000 TPS' and '803,000 TPS' without specifying whether these are transactions/s or updates/s. Since the paper elsewhere carefully distinguishes updates from transactions, this unit inconsistency should be fixed.
  2. [Figure 9] Figure 9 is a table, not a figure. Also, the table lists 'QMDB v0.2.0' and 'FAFO/QMDB,' but §8.2 refers to 'QMDB v1' and 'QMDB v2'; the correspondence should be stated explicitly.
  3. [§7.2.3] The text says enabling prefetching gives a '25% increase' in one paragraph and 'approximately 20%' in the next. These are not necessarily contradictory, but the presentation would benefit from a single consistent statement with the exact configuration.
  4. [§4.3] The ABA pattern discussion says 'the fact that the value has changed' is preserved with fine-grained versioning, but the variable name 'version' is re-used in Algorithm 1 and Algorithm 2 with different meanings (a version number vs. a per-entry version field). Distinguishing these would improve readability.
  5. [General] The paper does not provide a URL or availability statement for the 'reference implementation as a Rust library.' Given that the performance claims are central and the paper mentions 'minimal dependencies,' an artifact link or repository identifier would substantially aid reproducibility.
  6. [§4.2] Observation 3 says 'On 64-bit architectures all nodes are represented as single 64-bit numbers, meaning that pre-image collisions are much more likely than hash collisions.' As written this is cryptic; if leaf addresses are truncated to 64 bits, this deserves a clearer explanation with the exact representation and its security implications.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the headline throughput is measured and the 50 Gbps figure is a unit conversion from measured update rate and per-update serialized bytes.

full rationale

The paper's central claims are benchmark results, not derived predictions. Section 7.1.1 reports 'the 96-core AWS machine sustained over 48M state updates per second' as a measurement; Section 8.2 compares against QMDB using the same AWS machine and reports measured QMDB rates (1,280,000 TPS and 803,000 TPS). No equation is fitted to a subset of data and then renamed as a prediction. The '50 Gbps' claim in the abstract and Section 7.1.2 is a throughput conversion: the paper states 'Each update serializes 400 bytes of snapshot data' and computes a byte rate from a thread count (64 cores / 128 threads at ~50 MB/s per thread). That is arithmetic on a fixed serialized size, not a circular derivation. The tunables (snapshot frequency, subtree-root count, prefetching) are varied and their effects reported (Section 7.3), which is ordinary systems optimization; the headline number is a measured operating point, not a fitted parameter masquerading as a prediction. The only self-referential citation is the Eclipse blog in Section 7.1.2, but it is not load-bearing for the state-commitment claims. The static key-prefix sharding concern (Section 4.1) is an external-validity assumption about workload uniformity, not a circularity: it does not make the measured throughput equivalent to the design input by construction. No load-bearing uniqueness theorem, ansatz-smuggling citation, or renaming of a known result was found.

Assumptions & free parameters 4 free parameters · 4 assumptions · 1 invented entities

The central claim rests on tuned configuration parameters (sharding, snapshot cadence, page size, hash mode) and on domain assumptions about blockchain block semantics, key distribution, and asynchronous persistence. No new physical or mathematical entity is required, but the TOSH hash naming introduces an unverifiable component without a definition.

free parameters (4)
  • Tree sharding depth (thread prefix bits and sub-tree count) = 6 bits for threads and 10 bits for sub-trees on a 64-core CPU; described as manually tunable
    Chosen based on core count and workload; Section 7.2.2 reports a 37% throughput difference by varying the number of sub-tree roots.
  • Snapshot period = 500 ms in the headline comparison; disabled for the 48M/s peak
    Selected empirically; a 500 ms snapshot period halves throughput to 24M/s on AWS and to roughly half on the M4, so the headline number is configuration-dependent.
  • Memory allocation and paging configuration = 2 MiB huge pages plus deterministic allocator and explicit prefetch instructions
    Deterministic allocation gives a measured ~25% gain; availability varies by cloud provider (Zen 4 has prefetch disabled), making the headline number hardware-dependent.
  • Hash function choice = blake2s used through a SIMD-transposed TOSH mode
    Selected by hand based on the property list in Section 5.1; the TOSH construction is not fully specified, so the exact hashing configuration is an unstated implementation detail.
assumptions (4)
  • domain assumption The Merkle root needs to be updated only once per block; intra-block observability is optional.
    Stated as Observation 2 in Section 4.1. The lazy root computation and low overhead of Pleiades depend on this blockchain-specific assumption.
  • domain assumption Static assignment of leaf keys to threads and sub-trees produces balanced shards under the expected workload.
    Section 4.1 partitions by the first key bits; Section 7.1 benchmarks only uniformly random 256-bit keys. Adversarial or skewed key-prefix distributions are not analyzed.
  • domain assumption Snapshot persistence and proof generation are fully asynchronous and can be offloaded without blocking the in-memory update path.
    Sections 3 and 8.1 rely on this split to keep disk I/O off the critical path; the 50 Gbps claim assumes a storage/network system that consumes snapshot records at the full update rate.
  • domain assumption The chosen hash function, including the TOSH SIMD mode, satisfies the cryptographic properties of a Merkle-tree hash.
    Sections 5.1 and 5.3 discuss desirable properties but do not give a construction or security argument for TOSH; a flawed custom mode would break the authenticated structure.
invented entities (1)
  • TOSH (Throughput Optimized SIMD-friendly Hash) functions
    purpose: SIMD-transposed hashing of 16 Merkle-tree nodes in parallel
    The paper names TOSH functions and attributes large speedups to them, but provides no formal construction, test vectors, or external security analysis. If TOSH is only an implementation mode of blake2s, that needs to be stated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AlDBaran: Towards Blazingly Fast State Commitments for Blockchains." pith.science (2026). https://pith.science/paper/ZYKZBEJQ

@misc{pith2026250810493,
  author       = {Pith},
  title        = {Pith review of: AlDBaran: Towards Blazingly Fast State Commitments for Blockchains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZYKZBEJQ}},
  note         = {Machine review of arXiv:2508.10493}
}
read the original abstract

The fundamental basis for maintaining integrity within contemporary blockchain systems is provided by authenticated databases. Our analysis indicates that a significant portion of the approaches applied in this domain fail to sufficiently meet the stringent requirements of systems processing transactions at rates of multi-million TPS. AlDBaran signifies a substantial advancement in authenticated databases. By eliminating disk I/O operations from the critical path, implementing prefetching strategies, and refining the update mechanism of the Merkle tree, we have engineered an authenticated data structure capable of handling state updates efficiently at a network throughput of 50 Gbps. This throughput capacity significantly surpasses any empirically documented blockchain throughput, guaranteeing the ability of even the most high-throughput blockchains to generate state commitments effectively. AlDBaran provides support for historical state proofs, which facilitates a wide array of novel applications. For instance, the deployment of AlDBaran could enable blockchains that do not currently support state commitments to offer functionalities for light clients and/or implement rollups. When benchmarked against alternative authenticated data structure projects, AlDBaran exhibits superior performance and simplicity. In particular, AlDBaran achieves speeds of approximately 48 million updates per second using an identical machine configuration. This characteristic renders AlDBaran an attractive solution for resource-limited environments, as its historical data capabilities can be modularly isolated (and deactivated), which further enhances performance. On consumer-level portable hardware, it achieves approximately 8 million updates/s in an in-memory setting and 5 million updates/s with snapshots at sub-second intervals, illustrating compelling and cost-effective scalability.

Figures

Figures reproduced from arXiv: 2508.10493 by the authors.

Figure 1
Figure 1. Comparison to closely related projects. More academic work is described in Section 9. single-writer high-contention system during block appli￾cation. While MerkleDB is battle-tested and production-ready, (having been audited by OpenZeppelin in March 2023 as we mentioned earlier), it cannot escape the funda￾mental trade-offs of its layered design. In summary, MerkleDB’s use of a radix-16 Merkle Trie guarantees compac… view at source ↗
Figure 2
Figure 2. Architecture of AlDBaran. Merkle metadata are persisted together in one unified, append-only log structure. This eliminates redundant storage and the communication overhead between layers, which is a major source of its 6 − 8× performance gain over systems like RocksDB+MPT. The central innovation in QMDB’s design is the “twig” A twig is a fixed-size Merkle sub-tree that holds a batch of 2,048 leaf entries. All state… view at source ↗
Figure 3
Figure 3. A comparison of concurrent Merkle tree implementation families from El-Hindi et al. [8]. The original figure does not differentiate between compile-time mutual exclusion of thread interference, and run-time mutual exclusion via mutexes. We have updated the picture to illustrate this point. submitted external queries. The raw data for the state updates can be similarly stored separately, in a desegre￾gated fashion, f… view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: An illustration of the layout of nodes in sparse Merkle tree of AlDBaran. Nodes closer to the state root are drawn to symbolize that they are logical and not instantiated objects. Observation 3. The keys cannot be omitted, because a Sparse Merkle Tree may map several k…
Figure 5
Figure 5. Figure 5: SIMD layout illustrated. The inputs are split into chunks (numbered 1 to 8), and designated with Latin letters. The computations are parallel horizontally, and sequential vertically. key that are part of the tree, calculating the determinis￾tic address of each node and…
Figure 6
Figure 6. Figure 6: Data layout of the inclusion proof. Boxes indicate entries with their labels. The dotted arrows represent the file locations in the snapshot file. The dashed lines represent logical connection, while solid lines physical presence. 7 5 4 1 0 6 3 2 A D e p t h 0 1 2 3 4 …
Figure 7
Figure 7. Figure 7: A logical representation of the Merkle proof as a linked structure. The solid lines represent physically instantiated objects, such as node references, while dashed lines represent information that must be inferred. order. Specifically, we evaluate ℎ0 =𝐻(ℎKey|ℎValue) (…
Figure 10
Figure 10. Figure 10: Scaling with Key Sizes in-memory data store — Pleiades. This would allow workloads that need an as-fast-as-possible state commit￾ment (re)-computation to operate without the overhead of interacting with (typically slower) persistent storage [PITH_FULL_IMAGE:figures/f…
Figure 9
Figure 9. Figure 9: Comparing AlDBaran to QMDB and FAFO. eliminates state commitment computation as a through￾put bottleneck, being able to operate at line speed on fast networks. Furthermore, our implementation of Pleiades does not require a special kernel or accelerator card. 7.1.3 Thro…
Figure 11
Figure 11. Figure 11: The effects of snapshot period on runtime performance [PITH_FULL_IMAGE:figures/full_fig_p018_11.png]
Figure 12
Figure 12. Figure 12: The effects of varying the number of subtree roots on the Pleiades (in-memory data storage) throughput. Measured on the Apple M4 Macbook Pro roots is determined by a few key factors. The latency budget determines the upper bound on the amount of twig roots. Thus findi…
Figure 13
Figure 13. Figure 13: Evaluating prefetching. enabling larger pages improves performance overall, but to a significantly lesser extent (as seen in [PITH_FULL_IMAGE:figures/full_fig_p019_13.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

17 extracted references · 17 canonical work pages

  1. [1]

    Block-STM vs

    Fikunmi Ajayi-Peters. Block-STM vs. Sealevel: A Com- parison of Parallel Execution Engines — eclipse.xyz. https://www.eclipse.xyz/articles/block-stm-vs-sealevel-a- comparison-of-parallel-execution-engines , 2024. [Accessed 07-07-2025]

    work page 2024

  2. [2]

    FastVer: Making Data Integrity a Commodity

    Arvind Arasu, Badrish Chandramouli, Johannes Gehrke, Esha Ghosh, Donald Kossmann, Jonathan Protzenko, Ravi Rama- murthy, Tahina Ramananandro, Aseem Rastogi, Srinath Setty, Nikhil Swamy, Alexander Van Renen, and Min Xu. FastVer: Making Data Integrity a Commodity. In Proceedings of the International Conference on Management of Data , 2021

    work page 2021

  3. [3]

    Concerto: A High Concurrency Key-Value Store with In- tegrity

    Arvind Arasu, Ken Eguro, Raghav Kaushik, Donald Koss- mann, Pingfan Meng, Vineet Pandey, and Ravi Ramamurthy. Concerto: A High Concurrency Key-Value Store with In- tegrity. In Proceedings of the ACM International Conference on Management of Data , 2017

    work page 2017

  4. [4]

    Phan, and Luca Henzen

    Jean Philippe Aumasson, Willi Meier, Raphael C.W. Phan, and Luca Henzen. BLAKE2, pages 165–183. Information Security and Cryptography. Springer, Switzerland, 2014

    work page 2014

  5. [5]

    RISE: The gigagas layer 2

    Samuel Battenally, Hai Nguyen, and Thanh Nguyen. RISE: The gigagas layer 2. RISE labs , May 2024

    work page 2024

  6. [6]

    On Scalable Integrity Checking for Secure Cloud Disks

    Quinn Burke, Ryan Sheatsley, Rachel King, Owen Hines, Michael Swift, and Patrick McDaniel. On Scalable Integrity Checking for Secure Cloud Disks. 2025

    work page 2025

  7. [7]

    Accelerating Merkle Patricia Trie with GPU

    Yangshen Deng, Muxi Yan, and Bo Tang. Accelerating Merkle Patricia Trie with GPU. 17(8), 2024

    work page 2024

  8. [8]

    Towards Merkle Trees for High-Performance Data Systems

    Muhammad El-Hindi, Tobias Ziegler, and Carsten Binnig. Towards Merkle Trees for High-Performance Data Systems. In Proceedings of the Workshop on Verifiable Database Systems , 2023

    work page 2023

Show all 17 references
  1. [9]

    Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing

    Rati Gelashvili, Alexander Spiegelman, Zhuolun Xiang, George Danezis, Zekun Li, Dahlia Malkhi, Yu Xia, and Run- tian Zhou. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing

  2. [10]

    L VMT: An Efficient Authenticated Storage for Blockchain

    Chenxing Li, Sidi Mohamed Beillahi, Guang Yang, Ming Wu, Wei Xu, and Fan Long. L VMT: An Efficient Authenticated Storage for Blockchain. ACM Transactions on Storage, 20(3), August 2024

    2024

  3. [11]

    MoltDB: Accelerating Blockchain via Ancient State Segregation

    Junyuan Liang, Wuhui Chen, Zicong Hong, Haogang Zhu, Wangjie Qiu, and Zibin Zheng. MoltDB: Accelerating Blockchain via Ancient State Segregation. 35(12):2545–2558

  4. [12]

    LETUS: A Log- Structured Efficient Trusted Universal BlockChain Storage

    Shikun Tian, Zhonghao Lu, Haizhen Zhuo, Xiaojing Tang, Peiyi Hong, Shenglong Chen, Dayi Yang, Ying Yan, Zhiy- ong Jiang, Hui Zhang, and Guofei Jiang. LETUS: A Log- Structured Efficient Trusted Universal BlockChain Storage. In Companion of the International Conference on Manage...

    2024

  5. [13]

    V2FS : A Verifiable Virtual Filesystem for Multi-Chain Query Authentication

    Haixin Wang, Cheng Xu, Xiaojie Chen, Ce Zhang, Haibo Hu, Shikun Tian, Ying Yan, and Jianliang Xu. V2FS : A Verifiable Virtual Filesystem for Multi-Chain Query Authentication. In International Conference on Data Engineering (ICDE) . Ieee, 2024

    2024

  6. [14]

    An Example of Parallel Merkle Tree Traversal: Post-Quantum Leighton-Micali Signature on the GPU

    Ziheng Wang, Xiaoshe Dong, Yan Kang, Heng Chen, and Qiang Wang. An Example of Parallel Merkle Tree Traversal: Post-Quantum Leighton-Micali Signature on the GPU. 21(3), 2024

    2024

  7. [15]

    Solana: A new architecture for a high performance blockchain v0.8.13

    Anatoly Yakovenko. Solana: A new architecture for a high performance blockchain v0.8.13. 2018

    2018

  8. [16]

    GlassDB: An Efficient Verifiable Ledger Database System Through Transparency

    Cong Yue, Tien Tuan Anh Dinh, Zhongle Xie, Meihui Zhang, Gang Chen, Beng Chin Ooi, and Xiaokui Xiao. GlassDB: An Efficient Verifiable Ledger Database System Through Transparency. 16(6), 2023

    2023

  9. [17]

    QMDB: Quick Merkle Database

    Isaac Zhang, Ryan Zarick, Daniel Wong, Thomas Kim, Bryan Pellegrino, Mignon Li, and Kelvin Wong. QMDB: Quick Merkle Database. Layer Zero Labs , January 2025. arXiv:2501.05262 [cs]. 23

    2025 arXiv

Pith tools

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