{"id":"bf9b8375-84a8-44e8-845a-7402d73fc2f1","arxiv_id":"2508.10493","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"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.","lead":"AlDBaran is a new in-memory authenticated database for blockchains that claims to process state updates at 48 million per second on a 96-core server by keeping everything in RAM and writing historical data asynchronously. Its significance is that it could let high-throughput blockchains generate state proofs fast enough to support light clients and rollups.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Static key-prefix sharding (Sec 4.1) makes the 48M/s headline conditional on uniform key distribution; hot-account workloads can collapse throughput to a single shard's core rate.","rationale":"The central claim is that AlDBaran sustains 48M state updates/s on 96 cores, enabling multi-million-TPS chains. For that claim to hold, the lock-free sharding of Sec 4.1 must actually deliver near-linear scaling on the workloads the paper targets. The benchmark uses uniformly random keys, which is the ideal case for prefix sharding. Real blockchain workloads contain hot accounts; a single hot account routes all its updates to one shard, and the paper provides no intra-shard parallelization or rebalancing mechanism that would let other cores help. The reported single-core peak of 0.64M/s thus becomes the ceiling for any shard whose key prefix is popular. This is the same assumption the Pith Reader identified. I do not see a more fundamental flaw: the architecture is coherent, the paper honestly reports 24M/s with history enabled, and the QMDB comparison, while unreplicated, is not internally contradictory. The missing code artifact and undefined TOSH naming are real problems for reproducibility, but they are secondary to the workload-dependence of the headline throughput. A simple benchmark with Zipfian/hot-spot keys would settle the concern: if throughput degrades as predicted, the abstract's unconditional 48M/s claim is misleading; if it holds up, the design is robust and the reader's conditional verdict can be upgraded.","tokens_in":25493,"tokens_out":10330,"duration_ms":104018,"concrete_test":"Use the same Pleiades-bench configuration as Sec 7.1 on the same AWS i7ie-metal-48xl, but replace the uniform-random key generator with (a) a Zipfian workload over 1B keys with skew 0.9 and 1.1, and (b) a hot-spot workload in which one key receives 10% of all updates and 100 keys receive 50%, with the remaining updates uniform. Run each for 10 minutes and record sustained updates/s. If throughput in (a)/(b) stays above ~40M/s, the sharding concern is resolved. If it drops toward the single-core 0.64M/s or scales with the number of hot shards, the headline claim is workload-dependent and the paper must qualify it.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.1 partitions the key space into a fixed number of shards by a key prefix (first six bits in the 64-core example), with no rebalancing or work-stealing. The 48M/s result (Sec 7.1.1) is obtained with 256-bit uniformly random keys, which distribute updates almost perfectly across shards. The paper's stated target is multi-million-TPS blockchains, whose workloads are not uniform: a small set of hot accounts (AMMs, staking pools, popular tokens) receives a large fraction of updates, and all updates to a single account are routed to the same shard. That shard then becomes a serial bottleneck at the single-core rate (~0.64M updates/s, reported in Sec 7.1.1), capping total throughput far below 48M/s regardless of how many other cores are idle. The paper does not report any skewed or repeated-key workloads, so the representative-workload assumption is untested. If the implementation hashes keys before taking the sharding prefix, the raw-key skew might be mitigated, but the text of Sec 4.1 says 'the first six bits of the key' without specifying whether this is the user key or its hash, and no benchmark demonstrates resilience to hot keys. This is a structural property of the design, not a measurement artifact.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":25789,"tokens_out":6221,"duration_ms":69600,"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":[{"comment":"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","section":"§4.1, §7.1.1"},{"comment":"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.","section":"§7.1.2"},{"comment":"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.","section":"§5.3"},{"comment":"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.","section":"§7.3"}],"minor_comments":[{"comment":"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.","section":"§7.1"},{"comment":"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.","section":"Figure 9"},{"comment":"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.","section":"§7.2.3"},{"comment":"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.","section":"§4.3"},{"comment":"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.","section":"General"},{"comment":"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.","section":"§4.2"}],"recommendation":"major_revision","confidential_remarks":"The paper is clearly within the scope of an authenticated-data-structure venue, and the measured throughput, if reproducible, is notable. My main concern is not the absence of a theoretical proof but the fact that the headline numbers rest on two unverified assumptions: uniform key distribution across static shards and a consistent network-byte arithmetic. The TOSH-function ambiguity is also a security-relevant gap. These are fixable with additional experiments and clarifications, so I do not recommend rejection, but the revision is substantial rather than cosmetic."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"AlDBaran is the first authenticated database I've seen that cleanly separates the in-memory Merkle hot path from historical proof generation and makes the separation pay off: Pleiades gets 48M updates/s on a 96-core AWS box with no history, 24M with snapshots enabled, and the M4 numbers (8M/5M) are believable for a laptop. The engineering is real: deterministic slab allocation, explicit prefetching, SIMD-transposed hashing, lock-free key sharding. That's a coherent set of techniques that together produce a useful system. The paper is worth reading for the design alone.\n\nThe soft spots are mostly around validation. The 50 Gbps claim doesn't survive arithmetic: 24M updates/s times 400 bytes/snapshot data is about 9.6 GB/s, which is 76.8 Gbps, not 50. The QMDB comparison rests on two unreplicated runs, and the authors admit they couldn't reproduce QMDB's published numbers. That's honest, but it means the \"at least 10x faster\" claim isn't backed by a controlled comparison. There are no error bars or repeated runs, and the TOSH hash functions, which are load-bearing for the SIMD speedup, are referenced but never specified. A custom hash that isn't defined can't be security-reviewed.\n\nThe stress-test concern about static key sharding is valid and load-bearing. The paper benchmarks uniformly random 256-bit keys, and the design routes each key to a shard by a fixed prefix with no rebalancing. Real blockchain workloads have hot accounts; if those land in one shard, throughput drops to that shard's single-core rate (~0.64M/s). Section 4.1 says \"the first six bits of the key\" without stating whether that's the raw key or its hash. If it's the raw key, the attack is trivial; if it's the hash, an adversary can still grind for a prefix that concentrates accounts. Either way, the paper needs a skewed-workload benchmark or a design change (e.g., hashing before sharding plus work-stealing) before the headline generalizes.\n\nThat said, none of this kills the central design. The architecture is sensible, the measured numbers are real, and the authors are upfront about the conditions. This is a paper I'd send to peer review, with the expectation of major revision: release the code and config, add variance, fix the Gbps math, specify TOSH, and address skewed workloads. I'd bring it to a reading group and cite it in related work.","headline":"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.","tokens_in":26326,"tokens_out":2421,"would_cite":true,"duration_ms":25844,"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":"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.","keywords":["authenticated database","Merkle tree","blockchain state commitment","concurrent updates","sparse Merkle tree","historical proofs","SIMD hashing","snapshots"],"falsifier":"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.","tokens_in":25330,"feed_emoji":"⚡","tokens_out":5557,"duration_ms":52884,"temperature":0.7,"pith_summary":"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.","feed_headline":"48 million state updates per second, no disk I/O in the hot path","feed_subtitle":"AlDBaran's split design keeps Merkle hashing in RAM and serves historical proofs from snapshots, beating QMDB by an order of magnitude.","key_machinery":"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.","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the state-of-the-art baseline whose measured throughput AlDBaran compares against on identical hardware.","marker":"[17]"},{"why":"Provides the concurrent Merkle tree design-space analysis and the splitting idea that motivates the lock-free sharding.","marker":"[8]"},{"why":"Furnishes the observation that storage operations dominate execution time and serves as a comparative authenticated-storage design.","marker":"[10]"},{"why":"Provides the versioned, optimistic-concurrency model that AlDBaran's version numbering is most similar to.","marker":"[1]"},{"why":"Defines the high-throughput blockchain workload parameters, including parallel execution, 400ms blocks, and three updates per transaction, that set the performance target.","marker":"[15]"},{"why":"Supplies the BLAKE2 hash family with the short-input and salting properties the SIMD optimization relies on.","marker":"[4]"}],"fun_headline_variants":["AlDBaran: 48M state updates/s, no disk I/O in hot path","State at line rate: AlDBaran hits 50 Gbps without disk","AlDBaran beats QMDB by 10x with 48M updates/s","AlDBaran splits hot path from history for 50 Gbps states"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["AlDBaran: 48M state updates/s, no disk I/O in hot path","State at line rate: AlDBaran hits 50 Gbps without disk","AlDBaran beats QMDB by 10x with 48M updates/s","AlDBaran splits hot path from history for 50 Gbps states"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000764,"raw_usage":{"total_tokens":3269,"prompt_tokens":828,"completion_tokens":2441,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":572,"completion_tokens_details":{"reasoning_tokens":2366}},"tokens_in":572,"tokens_out":2441,"duration_ms":18985,"temperature":1.0,"reasoning_tokens":2366,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:23:14.974922+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"QMDB: Quick Merkle Database","cited_arxiv_id":"2501.05262","evidence_quote":"Supplies the state-of-the-art baseline whose measured throughput AlDBaran compares against on identical hardware."},{"cited_title":"Towards Merkle Trees for High-Performance Data Systems","cited_arxiv_id":null,"evidence_quote":"Provides the concurrent Merkle tree design-space analysis and the splitting idea that motivates the lock-free sharding."},{"cited_title":"L VMT: An Efficient Authenticated Storage for Blockchain","cited_arxiv_id":null,"evidence_quote":"Furnishes the observation that storage operations dominate execution time and serves as a comparative authenticated-storage design."},{"cited_title":"Block-STM vs","cited_arxiv_id":null,"evidence_quote":"Provides the versioned, optimistic-concurrency model that AlDBaran's version numbering is most similar to."},{"cited_title":"Solana: A new architecture for a high performance blockchain v0.8.13","cited_arxiv_id":null,"evidence_quote":"Defines the high-throughput blockchain workload parameters, including parallel execution, 400ms blocks, and three updates per transaction, that set the performance target."},{"cited_title":"Phan, and Luca Henzen","cited_arxiv_id":null,"evidence_quote":"Supplies the BLAKE2 hash family with the short-input and salting properties the SIMD optimization relies on."}],"review_version":1}