{"id":"a75fffcb-756c-4a83-bf59-5431989e4034","arxiv_id":"2509.09795","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Three Setchain implementations, especially Hashchain, show orders-of-magnitude higher throughput than the underlying CometBFT ledger while adding light-client epoch proofs.","lead":"Setchain relaxes blockchain's strict ordering of transactions, grouping them into unordered epochs. This paper presents three implementations on CometBFT, with Hashchain reaching tens of thousands of elements per second and commit latency below 4 seconds.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Hashchain can order the same epochs differently on distinct correct servers; the f+1 consolidation threshold is not a deterministic function of ledger order.","rationale":"The reader's weakest assumption focused on Property 7 and the Section 2 assumption that servers cannot create valid elements and do not collude with clients. That is a legitimate modeling concern, but it is explicit in the paper and can be defended as a boundary of the system model. The more load-bearing problem is internal to Hashchain: the epoch-consolidation rule depends on each server's local success in retrieving batches from possibly Byzantine signers, and this local dependency is not ordered by the ledger. As shown by the n=4, f=1 example, two correct servers can consolidate two hashes in different orders, violating Consistent-Gets. The proof of Lemma 24 does not address this asymmetry; it assumes the f+1-th signature counted by every correct server is the same ledger transaction, which is not guaranteed. Since the claimed contribution is a Byzantine-tolerant Setchain with verifiable epoch-proofs, and Hashchain is the primary algorithm, this safety violation invalidates the central correctness claim as written. The empirical throughput measurements may still be reproducible, and the issue may be repairable by deriving epoch numbers from the deterministic ledger order rather than from local retrieval outcomes, but the current manuscript does not support the claimed Byzantine-tolerant correctness. I therefore recommend REJECT rather than CONDITIONAL, while noting that a revised consolidation rule could restore the result.","tokens_in":29639,"tokens_out":9794,"duration_ms":90160,"concrete_test":"Run Hashchain with n=4 servers, f=1, and a Byzantine server B that signs a hash h1 for a batch it holds, serves Request_batch(h1) to server C1, and drops Request_batch(h1) from server C2. Arrange ledger order: B(h1), C1(h1), C2(h2), C3(h2), where h2 is a second batch. After both h1 and h2 have been consolidated, call S.get() on C1 and C2 and compare the history sequences. If they differ (e.g., [h1,h2] versus [h2,h1]), Property 6 fails. Equivalently, write a TLA+ or model-checking specification of Hashchain with nondeterministic Byzantine responses to Request_batch and search for a reachable state where two correct servers return H[i] != H'[i] for i <= min(h,h').","verdict_should_be":"REJECT","load_bearing_attack":"The central correctness claim for Hashchain is Property 6 (Consistent-Gets), proved in Lemma 24 (Appendix C.3). The proof assumes that all correct servers observe the same 'f+1-th signature' for a hash and therefore consolidate the same batch at the same point in the ledger order. This is false. In Algorithm Hashchain, Lines 25-31 make a server count a signer only after it successfully retrieves the batch via Request_batch; Line 39 adds the signer only after that successful retrieval. A Byzantine signer may answer Request_batch for one correct server and drop or delay it for another, so the local moment at which |hash_to_signers[h]| reaches f+1 can differ across correct servers. Consequently, different hashes can be assigned epoch numbers in different orders. Concretely, take n=4, f=1. Byzantine server B signs hash h1 and serves the batch to server C1 but not to server C2. Ledger order: B(h1), C1(h1), C2(h2), C3(h2). C1 counts B and C1, consolidates h1 first, then h2. C2 cannot retrieve from B, does not count B, counts C2 and C3 for h2, and consolidates h2 before h1. Both servers are correct and see the same final ledger, yet their histories are [h1,h2] and [h2,h1], permanently violating Property 6. This is a safety violation internal to Hashchain, independent of the Section 2 assumption that servers cannot create valid elements or collude with clients. It directly undermines the claim that the proposed algorithms implement a correct Byzantine-tolerant Setchain, and it also breaks the epoch-proof guarantees because f+1 consistent proofs for epoch i would not exist when correct servers disagree on history[i].","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a family of Setchain implementations on top of a block-based ledger (CometBFT): Vanilla, Compresschain, and Hashchain. It extends the Setchain object with epoch-proofs that let a light client validate an epoch from f+1 signatures, and it states eight correctness properties. Correctness proofs are given in Appendix C, and a performance evaluation on clusters of 4, 7, and 10 servers reports throughput up to tens of thousands of elements per second and commit latency below 4 seconds. Hashchain, the main contribution, replaces batches by hashes and consolidates an epoch when f+1 servers have signed the batch hash.","tokens_in":29869,"tokens_out":9412,"duration_ms":93866,"significance":"Setchain is a plausible scalability layer for applications that tolerate intra-epoch reordering, and the paper is the first to provide a real implementation on CometBFT with epoch-proofs. If the correctness claims held, the throughput results (20,061 el/s for Byzantine-tolerant Hashchain with hash-reversal versus about 955 el/s for the bare ledger) would be a useful data point. The paper's honest reporting of the hash-reversal bottleneck and its analytical throughput model are strengths. However, the central safety proof for Hashchain is flawed, so the contribution as written does not establish a correct Byzantine-tolerant Setchain.","major_comments":[{"comment":"Property 6 (Consistent-Gets) does not hold under the stated Byzantine model, so Lemma 24 is false. The proof assumes that because all correct servers observe the same ledger blocks in the same order, the f+1-th signature used to consolidate a hash is the same for all correct servers. But in Algorithm Hashchain a server counts signer w for hash h only after it has obtained a valid batch for h (Lines 25-31) and then executes Line 39. A Byzantine signer B can answer Request_batch(h1) to server C1 and drop it for server C2. Take n=4, f=1 and suppose the ledger order of hash-batches is B(h1), C1(h1), C2(h2), C3(h2), where C1 is correct and, after retrieving h1 from B, appends its own hash-batch. C1 counts B and itself for h1 and consolidates h1 before h2; C2 cannot count B, counts C2 and C3 for h2, and consolidates h2 before h1 (later consolidating h1 after retrieving it from C1). Both servers are correct and see the same ledger, but their epoch histories are [h1,h2] and [h2,h1], permanently violating Property 6. The local threshold event in Line 40 depends on network-dependent retrieval success rather than only on ledger order, so the proof's key step 'by Properties 9 and 10, it will be the f+1-th signature w receives for hash hs' is invalid. This is a safety violation in the central Hashchain algorithm and must be fixed, for example by making consolidation depend only on ledger-visible f+1 signatures and then retrieving the batch from a correct signer, with a reworked proof.","section":"Appendix C.3 (Lemma 24); Algorithm Hashchain, Lines 25-31 and 39-40"},{"comment":"The Add-before-Get guarantee rests entirely on the assumption that 'a server cannot create a valid element by itself, and that clients and servers do not collude.' This is not a consequence of the stated PKI model, since servers are also processes with key pairs and can invoke client operations. In the 'open permissioned' model that the paper targets, validators are typically also clients, and in permissionless settings committee members are drawn from the same population as transaction issuers. As stated, the safety guarantee is therefore conditional on a substantial external restriction (e.g., elements must be signed by an authority that cannot be a server). The paper should state this restriction explicitly and, ideally, give an instantiation of valid_element that enforces it or discuss how the assumption can be relaxed.","section":"Section 2, Property 7; Lemmas 7, 15, 25"}],"minor_comments":[{"comment":"The quantitative throughput claims are based on single experimental runs; please report the number of repetitions and the variance (error bars or confidence intervals). In particular, the 133,882 el/s figure is obtained by the 'Hashchain Light' configuration that removes hash-reversal and validation and assumes all servers correct; this should be clearly labeled as an upper-bound study rather than as throughput of the Byzantine-tolerant Hashchain. Even with this caveat, the Byzantine-tolerant Hashchain throughput of about 20,061 el/s is still meaningfully above the bare ledger.","section":"Section 4.1, Table 2 and Figure 2"},{"comment":"There are typos: 'CommetBFT' and 'Haschain' should be 'CometBFT' and 'Hashchain'.","section":"Section 4.1, right panel of Figure 2"},{"comment":"The analytical throughput formulas assume all n servers are correct and sign each hash-batch. Since the paper's model allows up to f Byzantine servers, the formulas should be described as upper bounds for the fully Byzantine case, and the text should make this explicit.","section":"Appendix D"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is well within scope for a distributed-systems/blockchain venue. The main obstacle is not presentation but the safety proof for Hashchain: the consolidation rule in the current algorithm makes the epoch order depend on per-server retrieval success, which is not deterministic in the Byzantine model. I would not support acceptance until the consolidation rule is changed so that the f+1-th signature event is a deterministic function of ledger order and the proofs are reworked. I do not see evidence of citation manipulation; the self-citation to the original Setchain paper is appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the stress-test note is right: the f+1 consolidation rule in Hashchain is not a deterministic function of ledger order, and Lemma 24 (Consistent-Gets, Property 6) has a real gap. The n=4, f=1 counterexample works. Byzantine B signs h1 and serves the batch to C1 but not C2. Ledger order B(h1), C1(h1), C2(h2), C3(h2) is legal. C1 counts B and C1 and consolidates h1 first. C2 cannot retrieve from B, never counts B, and consolidates h2 before h1 — or never consolidates h1. Both servers are correct, see the same ledger, and their histories differ permanently. That is a safety violation under the paper's own model, and it also breaks the epoch-proof guarantee: a light client at C1 can collect f+1 valid proofs for G1 as epoch 1, while one at C2 collects f+1 valid proofs for G2 as epoch 1. The Section 3 sketch has the same flaw: the algorithm counts a signer only after a successful Request_batch, so \"same logic from observed blocks\" is false. The scenario also strands h1's elements in C2's the_set but never in history — a separate Eventual-Get violation.\n\nSecond, the paper has real value. The epoch-proof mechanism is genuinely new and works for Vanilla and Compresschain; those two algorithms are implemented and their proofs reduce cleanly to the ledger properties. The evaluation is honest — it admits the hash-reversal bottleneck, measures with and without it, and reports compression ratios. The analytical throughput formulas are sanity checks, not fitted predictions.\n\nSoft spots, in proportion. The Hashchain bug dominates: it is the paper's primary contribution, and the conclusion's \"formally verified\" phrase overstates handwritten proofs, one of which is wrong. The performance baseline is bare CometBFT (955 el/s); any batching scheme beats that, and the paper's own related work lists systems a league ahead. No error bars or repeated trials — a real but minor issue since the qualitative trends are visible. The Property 7 model assumption (servers cannot create valid elements, no collusion) is explicit but narrow; the Hashchain bug does not depend on it.\n\nWho this is for: distributed systems readers interested in Setchain or in batching over BFT ledgers. It deserves a serious referee — exactly the kind of subtle safety bug peer review should catch — but as presented the main algorithm is unsafe and needs a redesigned consolidation rule before the throughput claims can be trusted.","headline":"First, the stress-test is right: Hashchain can violate Consistent-Gets under its own model, and the same scenario breaks Eventual-Get; the epoch-proof idea and the two simpler algorithms are still worth a referee's time.","tokens_in":30532,"tokens_out":13287,"would_cite":false,"duration_ms":481395,"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":"Setchain algorithms show that replacing a blockchain's total order with unordered epochs yields far higher throughput and verifiable light-client proofs.","keywords":["Setchain","blockchain scalability","Byzantine fault tolerance","epoch-proofs","CometBFT","hash batching","throughput","finality"],"falsifier":"On the performance side, reproduce the 10-server, 0.5 MB-block experiment with a 25,000 el/s sending rate and measure committed elements per second; a number far below the reported roughly 20,000 el/s with hash-reversal would refute the throughput claim. On the semantic side, give one Byzantine server client privileges and check whether an element no client ever added can enter an epoch; if it does, Property 7 (Add-before-Get) is violated.","tokens_in":29387,"feed_emoji":"⚡","tokens_out":7394,"duration_ms":61347,"temperature":0.7,"pith_summary":"The paper aims to show that a blockchain's throughput bottleneck is largely due to requiring a total order over every transaction, and that replacing that with a sequence of unordered sets (epochs) removes much of the bottleneck. It proposes three algorithms built on top of an existing block-based ledger: Vanilla, which simply writes each element as a ledger transaction; Compresschain, which batches and compresses elements into one ledger transaction; and Hashchain, which appends only a signed hash of a batch and later reconstructs the batch through a distributed lookup. The reported measurements put Hashchain at tens of thousands of elements per second—more than an order of magnitude above the underlying ledger's roughly 955 elements per second—with commit latency below four seconds. The paper also introduces epoch-proofs, signatures that let a client verify an epoch by contacting a single server rather than many.","feed_headline":"Unordered epochs push blockchain throughput up 140x","feed_subtitle":"Hashchain batches elements into signed hashes and reaches finality under four seconds; light clients still verify epochs with a quorum of…","key_machinery":"The central object is the Setchain: a grow-only set of elements partitioned into epochs, where elements inside an epoch are unordered and only epoch boundaries impose a total order. The mechanism that carries the throughput argument is batching with hash anchoring: Hashchain collapses a large batch of elements to a fixed-size signed hash, appends that hash to the ledger, stores the batch off-chain, and only consolidates a batch into an epoch after f+1 servers have signed the same hash, guaranteeing at least one honest server can produce the original batch. Epoch-proofs—each server's signature over Hash(epoch, history[epoch])—are appended to the ledger so a client can trust an epoch with f+1 matching proofs. In Compresschain, the analogous mechanism is lossless compression of batches before appending; in Vanilla, each element is a separate ledger transaction and throughput matches the ledger.","core_discovery":"On its own terms, the paper's central claim is that a Byzantine-tolerant Setchain—an ordered sequence of unordered epochs—can be implemented on any block-based ledger, and that the hash-based version, Hashchain, achieves throughput orders of magnitude above the ledger itself while preserving the safety and liveness properties required of a Setchain. The key empirical claim is that Hashchain reaches an average of 20,061 elements per second with hash-reversal enabled and 133,882 elements per second when hash-reversal is disabled, compared with roughly 955 elements per second for the bare CometBFT ledger, with finality (f+1 epoch-proofs in the ledger) latency below four seconds.","pith_inferences":["The same hash-anchoring pattern generalizes beyond Setchain: any replicated object whose payload is large and whose ordering is not the bottleneck can append a signed digest and serve the payload off-chain, at the cost of a retrieval step and a quorum of signers.","Because the paper's validity condition assumes clients and servers do not collude, a natural adversarial test is to let a Byzantine validator behave as an ordinary client and attempt to inject an element with no preceding client add; the Add-before-Get property would fail if such an element is ever included in an epoch.","The authors' proposed extension to a full blockchain—optimistically validating transactions in parallel within an epoch and applying effects sequentially only after consolidation—implies a trade-off between epoch size and per-validator resource requirements; larger epochs improve throughput but can exclude weaker servers.","Comparing the three algorithms suggests that compression gives a modest constant-factor gain over Vanilla, whereas the gain from Hashchain is structural because its on-chain footprint is fixed-size; further work should focus on making off-chain retrieval cheaper rather than improving compression."],"forward_implications":["If the algorithms are correct, any application that needs ordering only across epoch barriers—digital registries, voting systems, certificate issuance—can run on a Setchain at a fraction of the ledger's per-element cost.","The throughput of Hashchain is bounded mainly by the ledger block size and the cost of off-chain batch retrieval, not by the consensus itself; the paper's analytical model predicts over one million elements per second at 4 MB blocks and over thirty million at 128 MB blocks.","Light clients can verify epoch membership with f+1 epoch-proofs obtained from a single server, reducing access cost from contacting multiple servers to one round trip per add and one per get.","Because the algorithms are implemented on CometBFT, they inherit its f < n/3 resilience bound even though the Setchain algorithms only require f < n/2, so switching to a weaker consensus service could raise fault tolerance or reduce overhead.","The measured bottleneck in hash-reversal suggests that replacing the naive batch-distribution service with a more efficient one, such as fewer signers or optimistic validation, would directly translate into higher throughput."],"supporting_citations":[{"why":"Defines the Setchain object and its safety and liveness properties, which the three algorithms implement and prove.","marker":"[12]"},{"why":"Documents the design and performance of CometBFT, the block-based ledger all three algorithms run on.","marker":"[13]"},{"why":"Describes the Tendermint consensus engine used inside CometBFT to finalize blocks.","marker":"[10]"},{"why":"Supplies the real Arbitrum transactions used as Setchain elements in the evaluation.","marker":"[25]"},{"why":"Specifies SHA-512, the hash used to build hash-batches and epoch-proofs.","marker":"[28]"},{"why":"Specifies Brotli, the compression format used by Compresschain and the source of its compression ratios.","marker":"[4]"},{"why":"Specifies EdDSA/ed25519, the signature scheme used for epoch-proofs and hash-batch signatures.","marker":"[24]"},{"why":"Provides the high-speed ed25519 signature implementation used in the experiments.","marker":"[6]"}],"fun_headline_variants":["Setchain: Byzantine-tolerant epochs scale blockchain 140x","Hashchain: 133k elements/sec on CometBFT, finality in 4s","Setchain's unordered epochs achieve 140x throughput","Unordered epochs: scalable blockchain without total order"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The argument that every element in an epoch was genuinely added by a client rests on the assumption that a server cannot create a valid element on its own and never colludes with clients; if a Byzantine server can also act as a client, that guarantee breaks even though throughput is unaffected.","fun_headline_variants_meta":{"raw":{"variants":["Setchain: Byzantine-tolerant epochs scale blockchain 140x","Hashchain: 133k elements/sec on CometBFT, finality in 4s","Setchain's unordered epochs achieve 140x throughput","Unordered epochs: scalable blockchain without total order"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000967,"raw_usage":{"total_tokens":4107,"prompt_tokens":933,"completion_tokens":3174,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":3101}},"tokens_in":549,"tokens_out":3174,"duration_ms":20825,"temperature":1.0,"reasoning_tokens":3101,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T15:58:37.791684+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On the performance side, reproduce the 10-server, 0.5 MB-block experiment with a 25,000 el/s sending rate and measure committed elements per second; a number far below the reported roughly 20,000 el/s with hash-reversal would refute the throughput claim. On the semantic side, give one Byzantine server client privileges and check whether an element no client ever added can enter an epoch; if it does, Property 7 (Add-before-Get) is violated.","supporting_citations":[{"cited_title":"Di stributed Ledger Tech- nologies: Research and Practice 3(2) (jun 2024)","cited_arxiv_id":null,"evidence_quote":"Defines the Setchain object and its safety and liveness properties, which the three algorithms implement and prove."},{"cited_title":"In: 27th USENIX Securit y Symposium (USENIX Security 18)","cited_arxiv_id":null,"evidence_quote":"Supplies the real Arbitrum transactions used as Setchain elements in the evaluation."},{"cited_title":"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf (Mar 2012), federal Information Processing Standards Publication 18 A","cited_arxiv_id":null,"evidence_quote":"Specifies SHA-512, the hash used to build hash-batches and epoch-proofs."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Specifies EdDSA/ed25519, the signature scheme used for epoch-proofs and hash-batch signatures."},{"cited_title":"Journal of Cryptographic Engineer- ing 2(2), 77–89 (Sep 2012)","cited_arxiv_id":null,"evidence_quote":"Provides the high-speed ed25519 signature implementation used in the experiments."}],"review_version":2}