{"id":"8cc6a096-5ed2-4288-ad5d-beb435013d69","arxiv_id":"2601.03390","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Aspen combines clock-based request scheduling, extra replicas, and speculative execution to make leaderless BFT replication commit in 2Δ+ε under contention, with measured latency benefits over prior protocols.","lead":"Aspen is a new Byzantine-fault-tolerant replication protocol that lets clients confirm requests in two network delays plus a short wait, even when requests arrive in different orders. It works by having proxies stamp requests with arrival-time estimates, adding extra replicas so a few out-of-sync replicas do not break the fast path, and falling back to a PBFT-style repair when needed.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"REPAIR's safety/liveness is asserted but not proven; the round/view interaction (§5.6.4) and log-construction rule (§5.6.3) are under-specified, so the BFT guarantee rests on an unverified argument.","rationale":"The reader's weakest assumption—that REPAIR preserves safety and liveness as claimed—is exactly the soft spot I identify. The fast-path quorum intersection argument in §5.6.3 appears mathematically sound, and the empirical latency results are credible. However, the paper's assertion of a partial-synchrony guarantee is not backed by a proof or a released artifact, and the evaluation exercises no Byzantine behavior. The protocol description leaves critical details unspecified: deterministic log construction from H, the handling of holes in indices, the ordering of f+1-supported requests, and the round/view-change interaction that the authors themselves flag as idiosyncratic. These are precisely the places where a subtle safety or liveness bug would hide. A formal model check, even for small parameters, would substantially raise confidence; failure would demonstrate a real flaw. Since the reader already conditioned acceptance on such evidence, my read does not change the verdict.","tokens_in":19541,"tokens_out":15869,"duration_ms":141451,"concrete_test":"Specify Aspen's REPAIR/ALIGN (including view change and log construction) in TLA+ and model-check safety for f=1, p=1, n=6 with Byzantine leaders and clients: the invariant that every request committed via fast path or a previous REPAIR round is present at the same index in the log after any subsequent REPAIR, and that no two conflicting requests are committed at the same index. If the model checker finds a violation, the safety claim fails; if it explores all states without violation, the proof gap is closed for that parameterization.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim that Aspen achieves BFT safety and liveness under partial synchrony rests entirely on the REPAIR subprotocol. The paper provides no protocol invariants or proof. §5.6.3 argues that any fast-path-committed request appears in f+p+1 logs of H via an intersection-counting argument; while the count is plausible, the actual log-construction algorithm is not specified: how are preserved requests placed when their original indices contain holes, and how are requests supported by only f+1 logs deterministically ordered? §5.6.4 explicitly flags 'the main idiosyncrasy' in adapting PBFT view change to Aspen's round structure—after starting a view change in round i, a replica that sees f+1 REPAIR-DONE must exit i using the REPAIR-HISTORY and continue the view change in the next round—but no correctness argument or pseudocode is given for this path. A subtle error here could let a committed request be dropped or reordered across rounds, breaking safety. Liveness of REPAIR (leader failure detection, view-change timeouts) is also unspecified, so the partial-synchrony liveness guarantee is unsupported. Since the evaluation (§6) runs only fault-free scenarios, no empirical evidence tests these worst-case guarantees.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"Aspen is a leaderless, speculative BFT state-machine-replication protocol that targets near-optimal end-to-end commit latency of 2Δ+ε. Clients send requests to proxies, which attach estimated times of arrival (ETAs) computed from synchronized clocks and one-way-delay measurements; replicas hold requests until their ETA, execute speculatively, and reply with log hashes. A client commits after receiving n−p consistent speculative replies. The protocol uses n=3f+2p+1 replicas to tolerate f Byzantine faults and up to p diverging replicas on the fast path, and it relies on periodic synchronization/checkpointing, an ALIGN subprotocol, and a PBFT-style REPAIR fallback for safety and liveness under partial synchrony. The paper reports a GCP deployment with six replicas, comparing against PBFT, Zyzzyva, Autobahn, Bullshark, HotStuff, and Flutter, and reports 1.2–3.3× latency improvements and roughly 19K requests/s, along with sensitivity studies of p, alignment, and ETA conservativeness.","tokens_in":19885,"tokens_out":7129,"duration_ms":75138,"significance":"If the correctness claims were fully substantiated, the paper would make a useful contribution: it replaces the usual no-contention condition of leaderless speculative BFT with a best-effort ETA ordering layer, introduces extra replicas to absorb divergence, and adds proactive alignment to keep the fast path viable. The implementation and evaluation are substantial, and the sensitivity studies in §6.4–§6.6 provide useful engineering insight. The main weakness is that the BFT core — especially REPAIR, its view-change/round interaction, and log construction from REPAIR-HISTORY — is only sketched and never proved. Since the abstract and §3 assert safety and liveness under partial synchrony, this is a load-bearing gap. The evaluation also contains no Byzantine-fault runs, so the worst-case guarantees are entirely unexercised. The reported latency improvements are plausible, but the central correctness claim remains conditional.","major_comments":[{"comment":"The log-construction algorithm from a REPAIR-HISTORY H is underspecified, yet it is exactly the mechanism that must preserve fast-path-committed requests. The paper gives an intersection-counting argument that such requests appear in f+p+1 logs of H, but it never defines the actual deterministic procedure: how are entries placed when two requests are supported by different subsets at the same index, how are holes in the reconstructed log filled, and how is the hash chain H(k) maintained across these choices? Figure 7's caption concedes that 'the resulting log depends on the choice of H'; deterministic application of the same H is not enough if the construction rule is not fully specified. Please provide pseudocode for log construction and prove that it preserves every request that is committed on the fast path and yields identical logs at all correct replicas.","section":"§5.6.3, Fig. 7"},{"comment":"The internal view-change interaction with Aspen's round structure is the most fragile part of the fallback protocol. The paper states that after exiting REPAIR into round i+1 a replica must still participate in view changes for round i, and that a replica that started a view change in round i must exit i upon seeing f+1 REPAIR-DONE and then continue the view change in i+1. No message sequence, certificate structure, or invariant is given to show that a view change in round i cannot cause a committed request to be dropped or reordered when replicas are in different rounds. Because REPAIR is the basis for the claimed partial-synchrony safety and liveness, this is load-bearing. Please specify the full view-change protocol and prove round/view safety.","section":"§5.6.4"},{"comment":"The paper asserts that Aspen 'guarantees safety and liveness under partial synchrony' but provides no protocol invariants, no theorem statements, and no proof sketches beyond informal prose. The only concrete correctness arguments are the intersection count in §5.6.3 and the ALIGN replay rule in §5.5. For a protocol with speculative execution, rollback, checkpointing, and a modified PBFT view change, this is insufficient; a subtle bug in Algorithm 1's CHECK-CONFLICT-PROOF or in the ALIGN/REPAIR handoff could break safety. I recommend adding an appendix with stated invariants and proofs (or at least rigorous proof sketches) for fast-path commit, checkpoint quorum intersection, ALIGN safety, and REPAIR safety/liveness.","section":"§5.6, §3"},{"comment":"The evaluation contains no Byzantine-fault experiments. All runs are fault-free (the paper's 'typical conditions'), and the only perturbation is a burst-induced delay in §6.3. There are no runs with an equivocating replica, a faulty REPAIR leader, a malicious proxy, or a partition. Given that the protocol's headline claim is Byzantine fault tolerance under partial synchrony, the absence of any adversarial scenario leaves the safety/liveness properties untested empirically. This would be less concerning if the proofs above were present, but currently both dimensions are missing. Please add at least one Byzantine-fault scenario around REPAIR/view change and report error bars or percentiles rather than single-point averages in Table 2 and Figure 8.","section":"§6.2–§6.6"}],"minor_comments":[{"comment":"The text says 'we set δ=0.1 for the sequencing layer' but the sequencing-layer parameter is called γ elsewhere (§6.2, §6.6, Fig. 12). Please use a consistent parameter name.","section":"§6.4"},{"comment":"Typo: 'an new protocol' should be 'a new protocol'.","section":"Abstract/§1"},{"comment":"The rightmost plot contains the typo 'T ype' where 'Type' is intended.","section":"Fig. 10"},{"comment":"References [8] and [24] both appear as 'The next 700 BFT protocols' with different author lists. Please verify whether one citation is mislabeled or the reference list is duplicated.","section":"References"},{"comment":"Figure 9's 'peak fast path throughput' is measured by removing consistency checks, which effectively measures raw networking and cryptography throughput. This should be described as an upper bound on the fast path, not as the protocol's achieved fast-path throughput.","section":"§6.2"}],"recommendation":"major_revision","confidential_remarks":"The paper has a promising practical design and the experimental work is substantial, but the correctness core is not yet established. The lack of a formal or even detailed safety/liveness argument for REPAIR and the round/view interaction is likely to be a serious objection from both systems and theory reviewers. I would ask the authors to add a rigorous proof appendix and at least one Byzantine-fault experiment before considering acceptance. The paper may be salvageable, but in its current form the central BFT guarantee is asserted rather than demonstrated."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth your time. Aspen is a leaderless speculative BFT protocol that tries to keep the 2Δ fast path under contention, and it does so with a combination I haven't seen before: a best-effort ETA sequencing layer, p extra replicas to absorb divergence, and periodic alignment. The pieces are prior art, but the specific assembly is new, and the paper is honest about what it costs — throughput is 3.5x lower than Autobahn/Bullshark, and the authors say so plainly.\n\nThe implementation is detailed and the evaluation is real: wide-area experiments across four GCP regions, careful measurement of fast-path vs repair behavior, and a sensible study of how γ trades off latency against divergence. They also show that alignment meaningfully cuts repair rounds. The protocol description is mostly clear, and the fast-path logic — client commits on n−p consistent replies — is straightforward and well explained.\n\nThe soft spot is exactly where the reader put it. REPAIR is asserted to guarantee safety and liveness under partial synchrony, but no invariants or proofs are given. The log-construction argument in §5.6.3 is a sketch, and §5.6.4 explicitly flags the round/view interaction as an idiosyncrasy without a correctness argument. If there is a bug in REPAIR or at round boundaries, the BFT guarantee collapses even though the measured latency numbers stand. The evaluation also runs zero Byzantine faults, so the adversarial part of the guarantee is untested. No artifact is released. The latency improvement over Flutter is modest — 0.85x — and the headline 2Δ+ε number depends on γ tuned on the same deployment. These are real limitations, but none of them are fatal to the core design idea.\n\nMy take: the paper is coherent, the systems claims are measured and believable, and the missing proof is a genuine gap rather than a manufactured one. This deserves a serious referee, not a desk reject. I'd send it to a systems venue with a conditional accept: require a formal safety/liveness argument for REPAIR — or at least a precise, checkable invariant — and ideally an artifact release and one adversarial evaluation scenario. If the authors can deliver that, this becomes a solid published result. If not, it remains a useful systems paper with an unsupported BFT claim.","headline":"Aspen is a credible systems contribution with a genuinely new fast-path design, but the paper's BFT safety/liveness claim rests on an unproven repair protocol and needs referee scrutiny.","tokens_in":20394,"tokens_out":1381,"would_cite":true,"duration_ms":17551,"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":"Aspen shows that a leaderless Byzantine fault-tolerant protocol can commit in 2Δ+ε even under concurrent requests, using clock-based ordering and extra replicas.","keywords":["Byzantine fault tolerance","leaderless consensus","speculative execution","low-latency replication","clock synchronization","quorum systems","state machine replication","partial synchrony"],"falsifier":"A targeted search: run a fault-injection harness with f Byzantine replicas and adversarial message delivery that forces divergence; after a fast-path commit of request x, trigger REPAIR and check whether every constructed log contains x at the same index. A violation occurs if some constructed log omits a fast-path committed request despite the claimed intersection of size n−f−p. Concretely, with f=2, p=1, n=8, construct an H of 6 logs from a fast-path quorum of 7 replicas where 3 of those supporting replicas later diverge; the claimed guarantee is that x still appears in f+p+1=3 logs of H, an","tokens_in":19436,"feed_emoji":"⚡","tokens_out":5325,"duration_ms":47739,"temperature":0.7,"pith_summary":"The paper tries to establish that the 'no-contention' caveat of leaderless speculative BFT is not fundamental. It presents Aspen, which orders requests through a best-effort sequencing layer that attaches estimated arrival times (ETAs) to every request, so replicas release requests at roughly the same local time even if they arrive in different orders. To absorb residual divergence, Aspen runs on n=3f+2p+1 replicas, tolerating up to p diverged replicas on the fast path, and periodically aligns diverged replicas and falls back to a leader-based repair protocol when needed. If true, this means user-facing BFT applications can enjoy near-optimal two-message-delay latency without requiring contention-free conditions or trusting a leader. The experimental deployment reports 1.2–3.3× median latency gains over existing protocols while sustaining about 19,000 requests per second.","feed_headline":"Leaderless BFT commits in nearly two message delays under load","feed_subtitle":"Aspen adds a clock-based ordering layer and extra replicas to keep the fast path stable when requests collide.","key_machinery":"The central object is the best-effort sequencing layer: proxies compute for each request an estimated time of arrival η, replicas hold requests in a priority queue ordered by η, and release them when local clocks reach η. This converts the fast-path condition from 'no contention' to 'accurate one-way-delay estimation.' The second mechanism is the parameterized replica set n=3f+2p+1, whose fast-path quorum n−p intersects any repair-history set of n−f logs in at least f+p+1 entries, exactly enough to preserve committed requests during log reconstruction. The third is the background checkpoint/ALIGN/REPAIR machinery that detects divergence, realigns replicas, and provides a fallback.","core_discovery":"On its own terms, Aspen claims that the combination of (1) proxy-assigned ETAs based on synchronized clocks and one-way delay estimates, (2) a fast-path quorum of n−p replicas over n=3f+2p+1 total replicas, and (3) background checkpointing with ALIGN for diverged replicas and a leader-based REPAIR fallback, yields a leaderless speculative BFT protocol with end-to-end latency 2Δ+ε during normal operation and guaranteed safety/liveness under partial synchrony. The load-bearing correctness argument is a quorum-intersection counting: any fast-path-committed request appears in f+p+1 logs of the repair history H, so log reconstruction preserves all committed requests.","pith_inferences":["The ETA-ordering trick could be grafted onto other leaderless or DAG-based BFT protocols, potentially lowering their latency without changing their safety arguments.","The paper's p parameter gives system designers a tuning knob, but since network delays are often correlated across replicas, the marginal gains from extra replicas diminish; choosing p should be guided by measured correlation, not worst-case independence.","REPAIR's safety depends on a carefully designed interaction between leader-based views and Aspen's rounds; a formal machine-checked proof (or a targeted counterexample search) would either close or expose the gap left by the sketch.","If clock synchronization quality degrades, the fast-path commit rate will drop, but the fallback keeps liveness; a testable extension is to measure commit-rate sensitivity to clock error directly."],"forward_implications":["If Aspen's claims hold, BFT consensus can be made leaderless and speculative without a no-contention assumption, putting the practical floor near 2Δ+ε instead of 3Δ or 4Δ.","Synchronized clocks become a performance optimization, not a correctness dependency: Byzantine or poorly synchronized clocks degrade latency but do not breach safety or liveness.","Operators can buy resilience to network reordering by adding replicas (p), at the cost of throughput and infrastructure.","Diverged replicas can be proactively realigned to a checkpoint quorum, keeping the fast path stable and reducing repair invocations.","The protocol trades off throughput for latency, with reported peak throughput roughly 3× lower than throughput-oriented designs."],"fun_headline_variants":["Leaderless BFT keeps 2Δ+ε latency under concurrent load","Aspen uses clocks and extra replicas to stop BFT divergence","Speculative BFT survives collisions at near-optimal speed","Aspen: leaderless BFT with robust fast path at 2Δ+ε"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the REPAIR subprotocol—a leader-based agreement and view-change procedure adapted to Aspen's round structure—actually preserves safety and liveness as claimed; the paper presents the design but does not give a complete invariant-based proof, and a subtle bug at round boundaries would void the BFT guarantees.","fun_headline_variants_meta":{"raw":{"variants":["Leaderless BFT keeps 2Δ+ε latency under concurrent load","Aspen uses clocks and extra replicas to stop BFT divergence","Speculative BFT survives collisions at near-optimal speed","Aspen: leaderless BFT with robust fast path at 2Δ+ε"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000231,"raw_usage":{"total_tokens":1349,"prompt_tokens":796,"completion_tokens":553,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":540,"completion_tokens_details":{"reasoning_tokens":475}},"tokens_in":540,"tokens_out":553,"duration_ms":5725,"temperature":1.0,"reasoning_tokens":475,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T12:17:16.898399+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A targeted search: run a fault-injection harness with f Byzantine replicas and adversarial message delivery that forces divergence; after a fast-path commit of request x, trigger REPAIR and check whether every constructed log contains x at the same index. A violation occurs if some constructed log omits a fast-path committed request despite the claimed intersection of size n−f−p. Concretely, with f=2, p=1, n=8, construct an H of 6 logs from a fast-path quorum of 7 replicas where 3 of those supporting replicas later diverge; the claimed guarantee is that x still appears in f+p+1=3 logs of H, an","supporting_citations":[],"review_version":1}