Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

Practical One-Round-Trip BFT Replication

T0 review · 4 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

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

Pith's one-line read Aspen shows that a leaderless Byzantine fault-tolerant protocol can commit in 2Δ+ε even under concurrent requests, using clock-based ordering and extra replicas.

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

arxiv 2601.03390 v2 pith:QO3CW7BV submitted 2026-01-06 cs.DC

Daniel Qian , Xiyu Hao , Jinkun Geng , Yuncheng Yao , Aurojit Panda , Jinyang Li , Anirudh Sivaraman This is my paper · ORCID
classification cs.DC
keywords Byzantinefaulttoleranceleaderlessconsensusspeculativeexecutionlow-latencyreplicationclocksynchronizationquorumsystemsstatemachinepartialsynchrony
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper 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.

What carries the argument

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.

What would settle it

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

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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

Reading between the lines

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

  • 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.
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 / 5 minor

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.

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 (4)
  1. [§5.6.3, Fig. 7] 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.
  2. [§5.6.4] 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.
  3. [§5.6, §3] 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.
  4. [§6.2–§6.6] 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.
minor comments (5)
  1. [§6.4] 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.
  2. [Abstract/§1] Typo: 'an new protocol' should be 'a new protocol'.
  3. [Fig. 10] The rightmost plot contains the typo 'T ype' where 'Type' is intended.
  4. [References] 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.
  5. [§6.2] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity found: the 2Δ+ε latency is a by-construction message-delay accounting identity, the ETA ordering is a mechanism rather than a fitted prediction, and the unproven REPAIR claim is a correctness gap, not a circular one.

full rationale

Aspen's load-bearing claims are either analytic descriptions of its own protocol structure or measured experimental results, not predictions derived from fitted inputs. The 2Δ+ε end-to-end latency follows from the designed message pattern (client-to-proxy delay deemed negligible, proxy-to-replica delivery, ETA wait ε, replica-to-client reply) and is stated as the protocol's best-case path, not as an empirical prediction. The sequencing layer's ordering property is also by construction: replicas release requests when local clocks reach their ETAs, so any request arriving before its ETA is observed after the same ETA at every replica; this is a mechanism definition, not a reduction. The n=3f+2p+1 intersection argument in §5.6.3 is a standalone quorum-counting derivation from the protocol's own quorum sizes, not a restatement of its conclusion. The evaluation measures latency and throughput on a country-wide testbed; γ is a deployment-specific tuning knob explicitly said to require a per-deployment sweet spot, so the reported numbers are measurements, not out-of-sample predictions from a fitted model. The self-citations to Nezha/Tiga for the ETA idea are attribution for an idea, and the idea's use is described self-containedly in §5.3; no uniqueness theorem or prior-author result is imported as the load-bearing justification. The genuine weakness is that REPAIR's safety/liveness is asserted rather than proven: §5.6.3's log-construction rule and §5.6.4's view/round interaction are underspecified, and no protocol invariants are given. That is an omitted-proof / correctness concern, not circularity, because it does not reduce the claimed guarantee to the paper's own inputs. Accordingly, the circularity score is 0.

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

Aspen's central claims rest on synchronized clocks, accurate delay estimates, rollback-capable applications, borrowed quorum-resilience results, and an unproven REPAIR subprotocol. The only numerical parameter fitted to the evaluation data is γ and, indirectly, the ETA estimator parameters (q, window size). No new physical entities are introduced; proxies and ETAs are architectural components.

free parameters (4)
  • γ (ETA conservativeness factor) = 0.25 for main evaluation; 0.1 in §6.4; varied in §6.6
    Controls how much ETAs overestimate one-way delay; trades fast-path probability against added ε latency; explicitly tuned to the deployment in §6.6.
  • q (percentile for one-way-delay estimate) = not reported
    Moving q-th percentile of delay samples defines the ETA in §5.3; the value is chosen in the implementation and never stated.
  • p (extra replicas beyond 3f+1) = p=1 (n=6) for headline comparison; p varied 0–4 in §6.4
    Number of diverged or faulty replicas tolerated on the fast path; an operator/deployment choice that changes cost and reliability, not fitted to data.
  • syncTimeout and checkpoint interval I = not reported
    Govern how often replicas broadcast SYNC and checkpoint; affect alignment/repair frequency and latency; exact values not provided.
assumptions (6)
  • domain assumption Partial synchrony model with reliable, authenticated channels and computationally secure cryptography
    §3; standard for BFT, but its correctness for Aspen's specific fast/slow path interactions is not proved in this paper.
  • domain assumption Proxy and replica clocks are synchronized closely enough (e.g., <1 ms skew in §6.1); Byzantine clocks degrade performance but not safety
    §3 and §5.3; the ETA ordering layer depends on this and would trigger frequent REPAIR if clock skew or delay estimates are poor.
  • domain assumption The application state machine supports rollback / speculative execution
    §3; speculation requires rollback, and the implementation relies on application-provided abort and snapshot interfaces (§6.1).
  • domain assumption One-way-delay estimates obtained from periodic probes are a reliable predictor of near-future delivery times
    §5.3; the sequencing layer is best-effort, so performance of the fast path depends on network predictability; this is an empirical premise, not a guarantee.
  • domain assumption The parameterized fast-path quorum result n=3f+2p+1 from prior literature is sound
    §2.1 and §4; Aspen borrows this resilience bound from prior fast Byzantine consensus results rather than re-proving it.
  • ad hoc to paper REPAIR, as adapted from PBFT with non-overlapping rounds and modified view changes, preserves safety and liveness
    §5.6; this is Aspen's own unproved subprotocol; a flaw here would invalidate the claimed BFT guarantees.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Practical One-Round-Trip BFT Replication." pith.science (2026). https://pith.science/paper/QO3CW7BV

@misc{pith2026260103390,
  author       = {Pith},
  title        = {Pith review of: Practical One-Round-Trip BFT Replication},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QO3CW7BV}},
  note         = {Machine review of arXiv:2601.03390}
}
abstract

As Byzantine Fault Tolerant (BFT) protocols are increasingly adopted for user-facing applications such as payments and smart contracts, it is crucial that they provide low latency. To reduce latency, some BFT consensus protocols use a leaderless, speculative, fast path where clients broadcast requests directly to replicas, enabling end-to-end commit latency of two message delays ($2\Delta$). However, such a fast path is extremely fragile: concurrent requests can cause replicas to diverge when they receive requests in different orders, triggering costly recovery procedures. This paper presents Aspen, a leaderless speculative BFT protocol that handles concurrent requests while achieving near-optimal latency of $2\Delta + \epsilon$. The $\epsilon$ term is a short waiting delay introduced by Aspen's best effort ordering layer, which uses loosely synchronized clocks and network delay estimates to provide a tentative order. To make its fast path even more robust to intermittent divergence, Aspen adds extra replicas ($n = 3f + 2p + 1$) as well as novel recovery mechanisms that allow the system to tolerate divergence while preserving safety and performance. In experiments with geo-distributed replicas, Aspen reduces the median latency of requests by $1.1\times$--$3.8\times$ compared to state-of-the-art BFT protocols, while sustaining up to $0.75\times$ the peak throughput of throughput-optimized designs.

Figures

Figures reproduced from arXiv: 2601.03390 by the authors.

Figure 1
Figure 1. PBFT has an end-to-end latency of 5∆ an optimistic fast path that requires all 3 f +1 replicas [29,35]. In other words, this fast path requires the absence of faults. This approach can be further generalized to a parameterized fast path that uses n = 3 f +2p+1 replicas and requires n− p replicas to be correct [35, 43, 48]. Aspen relies on this parameterized model, in essence skipping PBFT’s step 4 . One challenge of… view at source ↗
Figure 2
Figure 2. Summary of low-latency techniques in prior works [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. In case 1, messages a and b, multicasted from prox￾ies p0 and p1, arrive on replicas in different orders, but the ETAs (ta and tb) successfully order the requests as (a,b). In case 2, message d arrives late to replica r, and thus replica r see an inconsistent sequence of requests: (c,d), compared with replica s, where c and d arrived on time, resulting in a sequence of (d,c). In case 2, we say r and s have diverged.… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Replica state in Aspen After executing a request, replicas reply to clients with the execution result and a hash of their logs, which allows clients to determine if results are safe to use (i.e., will eventually be committed). Results are safe to use if one of 2 condit…
Figure 5
Figure 5. Figure 5: Alignment of the log of diverged replicas [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 7
Figure 7. Figure 7: An example of a proposed history H for a repair round i with f = 1 and p = 1 (i.e. n = 6). a,b, c have consis￾tent consistent histories in f + p+1 logs. d,e, f , are included since they appear at least f +1 times. g only appears once, so is not included for the round. …
Figure 8
Figure 8. Figure 8: Throughput and latency of protocols under increasing load [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Throughput-latency curve of Aspen, annotated with [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 11
Figure 11. Figure 11: Performance of Aspen with and without alignment [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: Median request commit latency, and proportions of [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

  1. Duet: Co-Optimizing P2P Message Propagation and Rotating-Leader Consensus

    cs.DC 2026-07 conditional novelty 6.0 of 10

    Recorded network geography lets Duet rotate proposers in latency order and broadcast blocks over latency-aware trees with a gossip fallback driven by consensus votes, yielding up to 7.26× peak throughput over gossip o...

Reference graph

Works this paper leans on

52 extracted references · cited by 1 Pith paper

  1. [1]

    https : / / developers.neo.org / docs / n3 / foundation / consensus / dbft

    Consensus mechanism: Neo developer resources. https : / / developers.neo.org / docs / n3 / foundation / consensus / dbft. Accessed: 2024- 03-06

    2024

  2. [2]

    Ganger, Garth R

    Michael Abd-El-Malek, Gregory R. Ganger, Garth R. Goodson, Michael K. Reiter, and Jay J. Wylie. Fault- scalable byzantine fault-tolerant services. InProceed- ings of the Twentieth ACM Symposium on Operating Systems Principles, SOSP ’05, page 59–74, New York, NY , USA, 2005. Association for Computing Machinery

    2005

  3. [3]

    Revisit- ing fast practical byzantine fault tolerance, 2017

    Ittai Abraham, Guy Gueta, Dahlia Malkhi, Lorenzo Alvisi, Rama Kotla, and Jean-Philippe Martin. Revisit- ing fast practical byzantine fault tolerance, 2017

    2017

  4. [4]

    Good-case latency of byzantine broadcast: a complete categorization

    Ittai Abraham, Kartik Nayak, Ling Ren, and Zhuolun Xiang. Good-case latency of byzantine broadcast: a complete categorization. InProceedings of the 2021 ACM Symposium on Principles of Distributed Comput- ing, PODC’21, page 331–341, New York, NY , USA,

    2021

  5. [5]

    Bolosky, Miguel Castro, Gerald Cermak, Ronnie Chaiken, John R

    Atul Adya, William J. Bolosky, Miguel Castro, Gerald Cermak, Ronnie Chaiken, John R. Douceur, Jon Howell, Jacob R. Lorch, Marvin Theimer, and Roger P. Watten- hofer. Farsite: federated, available, and reliable storage for an incompletely trusted environment. 36(SI):1–14, December 2003

    2003

  6. [6]

    Aguilera, Naama Ben-David, Rachid Guer- raoui, Antoine Murat, Athanasios Xygkis, and Igor Zablotchi

    Marcos K. Aguilera, Naama Ben-David, Rachid Guer- raoui, Antoine Murat, Athanasios Xygkis, and Igor Zablotchi. ubft: Microsecond-scale bft using disag- gregated memory. InProceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, V ol- ume 2, ASPLOS 2023, page 862–877, New York, NY , USA,...

    2023

  7. [7]

    Hyper- ledger fabric: a distributed operating system for permis- sioned blockchains

    Elli Androulaki, Artem Barger, Vita Bortnikov, Chris- tian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukoli´c, Sharon Weed Cocco, and Ja...

  8. [8]

    The next 700 bft protocols.ACM Trans

    Pierre-Louis Aublin, Rachid Guerraoui, Nikola Kneže- vi´c, Vivien Quéma, and Marko Vukoli´c. The next 700 bft protocols.ACM Trans. Comput. Syst., 32(4), 1 2015

    2015

Show all 52 references
  1. [9]

    Amazon Time Sync Service expands Microsecond-Accurate time to 87 additonal EC2 in- stance types

    AWS. Amazon Time Sync Service expands Microsecond-Accurate time to 87 additonal EC2 in- stance types. https://aws.amazon.com/about-aws/ whats-new/2024/04/amazon-time-sync-service- microsecond - accurate - time - additonal - ec2 - instance-types/, 2024. Accessed: 08/31/2024

    2024

  2. [10]

    Deploying intrusion-tolerant scada for the power grid

    Amy Babay, John Schultz, Thomas Tantillo, Samuel Beckley, Eamon Jordan, Kevin Ruddell, Kevin Jordan, and Yair Amir. Deploying intrusion-tolerant scada for the power grid. In2019 49th Annual IEEE/IFIP Interna- tional Conference on Dependable Systems and Networks (DSN), pages 32...

    2019

  3. [11]

    Mysticeti: Reach- ing the limits of latency with uncertified dags, 2024

    Kushal Babel, Andrey Chursin, George Danezis, Anas- tasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, and Mingwei Tian. Mysticeti: Reach- ing the limits of latency with uncertified dags, 2024

    2024

  4. [12]

    Hy- brids on steroids: Sgx-based high performance bft

    Johannes Behl, Tobias Distler, and Rüdiger Kapitza. Hy- brids on steroids: Sgx-based high performance bft. In Proceedings of the Twelfth European Conference on Computer Systems, EuroSys ’17, page 222–237, New York, NY , USA, 2017. Association for Computing Ma- chinery

    2017

  5. [13]

    Practical byzantine fault tolerance

    Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. InProceedings of the Third Sympo- sium on Operating Systems Design and Implementation, OSDI ’99, page 173–186, USA, 1999. USENIX Associ- ation

    1999

  6. [14]

    Chrony Team. Chrony. https : / / chrony - project.org / index.html , 2024. Accessed: 09/11/2024

    2024

  7. [15]

    Upright cluster services

    Allen Clement, Manos Kapritsos, Sangmin Lee, Yang Wang, Lorenzo Alvisi, Mike Dahlin, and Taylor Riche. Upright cluster services. InProceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Prin- ciples, SOSP ’09, page 277–290, New York, NY , USA,

  8. [16]

    Corbett, Jeffrey Dean, Michael Epstein, An- drew Fikes, Christopher Frost, JJ Furman, Sanjay Ghe- mawat, Andrey Gubarev, and et al

    James C. Corbett, Jeffrey Dean, Michael Epstein, An- drew Fikes, Christopher Frost, JJ Furman, Sanjay Ghe- mawat, Andrey Gubarev, and et al. Spanner: Google’s globally-distributed database. In10th USENIX Sympo- sium on Operating Systems Design and Implementation (OSDI 2012), p...

    2012

  9. [17]

    Hq replication: A hybrid quorum protocol for byzantine fault tolerance

    James Cowling, Daniel Myers, Barbara Liskov, Rodrigo Rodrigues, and Liuba Shrira. Hq replication: A hybrid quorum protocol for byzantine fault tolerance. InPro- ceedings of the 7th Symposium on Operating Systems Design and Implementation, OSDI ’06, page 177–190, USA, 2006. USE...

    2006

  10. [18]

    Consensus in the presence of partial synchrony.J

    Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony.J. ACM, 35(2):288–323, apr 1988

    1988

  11. [19]

    Tiga: Accelerating geo-distributed transac- tions with synchronized clocks

    Jinkun Geng, Shuai Mu, Anirudh Sivaraman, and Balaji Prabhakar. Tiga: Accelerating geo-distributed transac- tions with synchronized clocks. InProceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles, SOSP ’25, page 555–571, New York, NY , USA, 2025. Associa...

    2025

  12. [20]

    Nezha: Deployable and high-performance consensus using synchronized clocks, 2023

    Jinkun Geng, Anirudh Sivaraman, Balaji Prabhakar, and Mendel Rosenblum. Nezha: Deployable and high-performance consensus using synchronized clocks, 2023

    2023

  13. [21]

    Exploiting a natural network effect for scalable, fine- grained clock synchronization

    Yilong Geng, Shiyu Liu, Zi Yin, Ashish Naik, Bal- aji Prabhakar, Mendel Rosenblum, and Amin Vahdat. Exploiting a natural network effect for scalable, fine- grained clock synchronization. In15th USENIX Sym- posium on Networked Systems Design and Implementa- tion (NSDI 18), page...

    2018

  14. [22]

    Autobahn: Seam- less high speed bft

    Neil Giridharan, Florian Suri-Payer, Ittai Abraham, Lorenzo Alvisi, and Natacha Crooks. Autobahn: Seam- less high speed bft. InProceedings of the ACM SIGOPS 30th Symposium on Operating Systems Princi- ples, SOSP ’24, page 1–23, New York, NY , USA, 2024. Association for Computi...

    2024

  15. [23]

    Sbft: A scalable and decentralized trust infrastructure

    Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael Reiter, Dragos- Adrian Seredinschi, Orr Tamir, and Alin Tomescu. Sbft: A scalable and decentralized trust infrastructure. In2019 49th Annual IEEE/IFIP International Conference on De- pendable...

    2019

  16. [24]

    The next 700 bft protocols

    Rachid Guerraoui, Nikola Kneževi´c, Vivien Quéma, and Marko Vukoli´c. The next 700 bft protocols. InPro- ceedings of the 5th European Conference on Computer Systems, EuroSys ’10, page 363–376, New York, NY , USA, 2010. Association for Computing Machinery

    2010

  17. [25]

    Resilientdb: global scale resilient blockchain fabric.Proc

    Suyash Gupta, Sajjad Rahnama, Jelle Hellings, and Mo- hammad Sadoghi. Resilientdb: global scale resilient blockchain fabric.Proc. VLDB Endow., 13(6):868–883, February 2020

    2020

  18. [26]

    Suyash Gupta, Sajjad Rahnama, Shubham Pandey, Nat- acha Crooks, and Mohammad Sadoghi. Dissecting bft consensus: In trusted components we trust! InProceed- ings of the Eighteenth European Conference on Com- puter Systems, EuroSys ’23, page 521–539, New York, NY , USA, 2023. Ass...

    2023

  19. [27]

    Hotstuff-1: Linear consensus with one-phase speculation.Proc

    Dakai Kang, Suyash Gupta, Dahlia Malkhi, and Mo- hammad Sadoghi. Hotstuff-1: Linear consensus with one-phase speculation.Proc. ACM Manag. Data, 3(3), June 2025

    2025

  20. [28]

    Cheapbft: resource-efficient byzantine fault tolerance

    Rüdiger Kapitza, Johannes Behl, Christian Cachin, Tobias Distler, Simon Kuhnle, Seyed Vahid Moham- madi, Wolfgang Schröder-Preikschat, and Klaus Stengel. Cheapbft: resource-efficient byzantine fault tolerance. InProceedings of the 7th ACM European Conference on Computer System...

    2012

  21. [29]

    Zyzzyva: Speculative byzantine fault tolerance.ACM Trans

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. Zyzzyva: Speculative byzantine fault tolerance.ACM Trans. Comput. Syst., 27(4), 2010

    2010

  22. [30]

    K. Kursawe. Optimistic byzantine agreement. In21st IEEE Symposium on Reliable Distributed Systems, 2002. Proceedings., pages 262–267, 2002

    2002

  23. [31]

    Revisiting optimal resilience of fast byzantine consen- sus

    Petr Kuznetsov, Andrei Tonkikh, and Yan X Zhang. Revisiting optimal resilience of fast byzantine consen- sus. InProceedings of the 2021 ACM Symposium on Principles of Distributed Computing, PODC’21, page 343–353, New York, NY , USA, 2021. Association for Computing Machinery

    2021

  24. [32]

    The byzantine generals problem.ACM Trans

    Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem.ACM Trans. Program. Lang. Syst., 4(3):382–401, jul 1982

    1982

  25. [33]

    Sundial: Fault-tolerant clock synchroniza- tion for datacenters

    Yuliang Li, Gautam Kumar, Hema Hariharan, Hassan Wassel, Peter Hochschild, Dave Platt, Simon Sabato, Minlan Yu, Nandita Dukkipati, Prashant Chandra, and Amin Vahdat. Sundial: Fault-tolerant clock synchroniza- tion for datacenters. InProceedings of the 14th USENIX Symposium on ...

    2020

  26. [34]

    Practical Uses of Synchronized Clocks in Distributed Systems

    Barbara Liskov. Practical Uses of Synchronized Clocks in Distributed Systems. InProceedings of the Tenth Annual ACM Symposium on Principles of Distributed Computing, 1991

    1991

  27. [35]

    Martin and L

    J.-P. Martin and L. Alvisi. Fast byzantine consensus. In 2005 International Conference on Dependable Systems and Networks (DSN’05), pages 402–411, 2005

    2005

  28. [36]

    The stellar consensus protocol: A federated model for internet-level consensus

    David Mazières. The stellar consensus protocol: A federated model for internet-level consensus. https: //www.stellar.org/papers/stellar- consensus- protocol.pdf, 2015. White Paper. 14

    2015

  29. [37]

    Fast leaderless byzantine total order broadcast, 2024

    Matteo Monti, Martina Camaioni, and Pierre-Louis Ro- man. Fast leaderless byzantine total order broadcast, 2024

    2024

  30. [38]

    Graham: Synchronizing clocks by leveraging local clock properties

    Ali Najafi and Michael Wei. Graham: Synchronizing clocks by leveraging local clock properties. InPro- ceedings of the 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 2022), pages 453–466, Renton, W A, USA, April 2022. USENIX As- sociation

    2022

  31. [39]

    Firefly: Scalable, ultra- accurate clock synchronization for datacenters

    Pooria Namyar, Yuliang Li, Weitao Wang, Nandita Dukkipati, Kk Yap, Junzhi Gong, Chen Chen, Peixuan Gao, Devdeep Ray, Gautam Kumar, Yidan Ma, Ramesh Govindan, and Amin Vahdat. Firefly: Scalable, ultra- accurate clock synchronization for datacenters. InPro- ceedings of the ACM S...

    2025

  32. [40]

    Achilles: Efficient tee-assisted bft consensus via rollback resilient recovery

    Jianyu Niu, Xiaoqing Wen, Guanlong Wu, Shengqi Liu, Jiangshan Yu, and Yinqian Zhang. Achilles: Efficient tee-assisted bft consensus via rollback resilient recovery. InProceedings of the Twentieth European Conference on Computer Systems, EuroSys ’25, page 193–210, New York, NY ...

    2025

  33. [41]

    Win- tersteiger

    Mark Russinovich, Edward Ashton, Christine Avanes- sians, Miguel Castro, Amaury Chamayou, Sylvan Cleb- sch, Manuel Costa, Cédric Fournet, Matthew Kerner, Sid Krishna, Julien Maffre, Thomas Moscibroda, Kartik Nayak, Olya Ohrimenko, Felix Schuster, Roy Schwartz, Alex Shamis, Olg...

    2019

  34. [42]

    Schneider

    Fred B. Schneider. Implementing fault-tolerant services using the state machine approach: a tutorial.ACM Com- put. Surv., 22(4):299–319, December 1990

    1990

  35. [43]

    Kudzu: Fast and Simple High-Throughput BFT

    Victor Shoup, Jakub Sliwinski, and Yann V onlanthen. Kudzu: Fast and Simple High-Throughput BFT. In Dariusz R. Kowalski, editor,39th International Sympo- sium on Distributed Computing (DISC 2025), volume 356 ofLeibniz International Proceedings in Informatics (LIPIcs), pages 42...

    2025

  36. [44]

    K2: On optimizing distributed transactions in a multi-region data store with truetime clocks.Proc

    Haoze Song, Yongqi Wang, Xusheng Chen, Hao Feng, Yazhi Feng, Xieyun Fang, Heming Cui, and Linghe Kong. K2: On optimizing distributed transactions in a multi-region data store with truetime clocks.Proc. VLDB Endow., 18(6):1756–1769, February 2025

    2025

  37. [45]

    Bullshark: Dag bft protocols made practical

    Alexander Spiegelman, Neil Giridharan, Alberto Son- nino, and Lefteris Kokoris-Kogias. Bullshark: Dag bft protocols made practical. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communi- cations Security, CCS ’22, page 2705–2718, New York, NY , USA, 2022. Ass...

    2022

  38. [46]

    Neobft: Accelerating byzantine fault tolerance using authenticated in-network ordering

    Guangda Sun, Mingliang Jiang, Xin Zhe Khooi, Yunfan Li, and Jialin Li. Neobft: Accelerating byzantine fault tolerance using authenticated in-network ordering. In Proceedings of the ACM SIGCOMM 2023 Conference, ACM SIGCOMM ’23, page 239–254, New York, NY , USA, 2023. Associatio...

    2023

  39. [47]

    EPaxos revisited

    Sarah Tollman, Seo Jin Park, and John Ousterhout. EPaxos revisited. In18th USENIX Symposium on Net- worked Systems Design and Implementation (NSDI 21), pages 613–632. USENIX Association, April 2021

    2021

  40. [48]

    Banyan: Fast rotating leader bft

    Yann V onlanthen, Jakub Sliwinski, Massimo Albarello, and Roger Wattenhofer. Banyan: Fast rotating leader bft. InProceedings of the 25th International Middleware Conference, Middleware ’24, page 494–507, New York, NY , USA, 2024. Association for Computing Machinery

    2024

  41. [49]

    White rabbit project

    WhiteRabbit Team. White rabbit project. https: / / gitlab.com / ohwr / project / white - rabbit / - / wikis/home, 2025. Accessed: 12/08/2025

    2025

  42. [50]

    Domino: using network measurements to reduce state machine replication latency in wans

    Xinan Yan, Linguan Yang, and Bernard Wong. Domino: using network measurements to reduce state machine replication latency in wans. InProceedings of the 16th International Conference on Emerging Network- ing EXperiments and Technologies, CoNEXT ’20, page 351–363, New York, NY ,...

    2020

  43. [51]

    Reiter, Guy Golan Gueta, and Ittai Abraham

    Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham. Hotstuff: Bft consensus with linearity and responsiveness. InPro- ceedings of the 2019 ACM Symposium on Principles of Distributed Computing, PODC ’19, page 347–356, New York, NY , USA, 2019. Asso...

    2019

  44. [2009]

    Association for Computing Machinery

Pith tools

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