Pith. sign in

REVIEW 2 major objections 5 minor 47 references

Orcaella: Hybrid Fault Tolerance with Client-Selectable Finality Latency

T0 review · 2 major / 5 minor · reviewed 2026-07-11 · grok-4.5

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

Pith's one-line read A tight bound of n ≥ 5f + 3c + 1 maximises two-message-delay BFT commits under separate Byzantine and crash caps, with a client-selectable four-delay path for extra safety.

desk verdict Tight hybrid 2-delay bound with a dual-path protocol that is already implemented and measured; the necessity argument is the real contribution. read the letter →

arxiv 2607.04789 v1 pith:HPDJDZIK submitted 2026-07-06 cs.DC cs.CR

Lefteris Kokoris-Kogias , Alberto Sonnino This is my paper · ORCID
classification cs.DCcs.CR
keywords Byzantinefaulttolerancehybridmodeltwo-message-delayconsensusquorumintersectionalive-but-corruptfaultsclient-selectablefinalityDAG-basedSMRpartialsynchrony
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

Classical partially synchronous BFT needs three message delays and n ≥ 3f + 1. Two-delay protocols have required the harsher n ≥ 5f + 1 because every silent replica must be treated as a potential equivocator. This paper separates fully Byzantine faults (f) from mere crashes (c) and proves that any vote-counting protocol whose two-delay commits stay safe across view changes needs at least n ≥ 5f + 3c + 1, with unique optimal thresholds q = n − f − c and k = 2f + c + 1. The resulting protocol, Orcaella, exposes two client-selectable finality paths: a two-delay VoteQC path safe against f equivocators, and a four-delay CheckpointQC/FinalityQC path that tolerates an additional f_abc < n − 3f − 2c alive-but-corrupt replicas. Core liveness holds only while at most f replicas equivocate; if that regime is broken the system enters a synchronous recovery epoch that preserves only the resilient-path safety guarantee. Concrete configurations around n = 100 therefore let operators trade offline tolerance, one-RTT safety, and two-RTT safety according to the expected threat model without abandoning the two-delay commit.

What carries the argument

The triple of counting constraints (Liveness q ≤ n − f − c, Reachability k ≤ 2q − n − f, Exclusivity k ≥ n − q + f + 1) that force the bound of Theorem 1 and fix the unique optimal Fast-Path quorum and view-change accept thresholds used by every certificate in Orcaella.

What would settle it

Exhibit a vote-counting two-delay protocol that remains live under f Byzantine and c crash faults, keeps Fast-Path commits safe across view changes, and works for some n < 5f + 3c + 1, or show that the three counting constraints of Theorem 1 are not simultaneously necessary.

Watch

Extended reading notes

Core claim

Any vote-counting protocol that is live under f Byzantine and c crash faults and whose Fast-Path commits remain safe across view changes requires n ≥ 5f + 3c + 1. At that minimal size the only thresholds that simultaneously satisfy liveness, reachability of committed values, and exclusivity against conflicting digests are q = n − f − c = 4f + 2c + 1 and k = 2f + c + 1. The same thresholds support a dual-path protocol in which clients can optionally wait two extra delays for safety against additional alive-but-corrupt faults.

Load-bearing premise

Core liveness is claimed only for executions in which at most f replicas ever equivocate; once that regime is broken the protocol halts normal operation and relies on a strictly synchronous recovery epoch that preserves only resilient-path safety.

Editorial extensions

If this is right

  • Operators can size committees for concrete (f, c) pairs that give better liveness than pure 5f + 1 while retaining a true two-message-delay commit.
  • Clients may choose, per transaction, whether to accept one-RTT finality against f equivocators or wait two extra delays for safety against an additional f_abc alive-but-corrupt replicas.
  • When f = 0 the same protocol and code path reduce to an optimal crash-only CFT deployment with n = 2c + 1.
  • A DAG instantiation (OrcDAG) realises the same thresholds by treating causal edges as votes, so existing uncertified-DAG fabrics can adopt the hybrid bound without new message types.

Reading between the lines

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

  • The same counting technique may yield tighter hybrid bounds for fully asynchronous or optimistically responsive protocols that currently treat every silence as Byzantine.
  • Economic incentive layers could dynamically re-allocate the (f, c, f_abc) budget as measured network conditions change, turning the static design space of Figure 1 into a live control knob.
  • The single-ChkProp-per-height locking rule that buys unique CheckpointQCs is also the rule that can permanently split honest checkpoint proposals; any practical deployment will need a clean timeout-and-recovery path for that liveness hole even before a full VoteQC fork.
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

2 major / 5 minor

Summary. The paper studies the fault tolerance of two-message-delay commit under a mixed model of f Byzantine (equivocating) and c crash faults. It proves a tight necessity bound for vote-counting protocols: n ≥ 5f + 3c + 1, with forced thresholds q = n - f - c and k = 2f + c + 1 at the minimal n (Theorem 1). The three counting constraints (liveness, reachability, exclusivity) are each forced by an explicit adversarial strategy. The authors then present Orcaella, which exposes a Fast-Path (VoteQC, 2 delays, safety against f) and a Resilient Path (CheckpointQC + FinalityQC, 4 delays) that additionally tolerates f_abc < n - 3f - 2c alive-but-corrupt faults. Core liveness holds only while at most f replicas equivocate; if that regime is violated, the protocol enters a synchronous recovery epoch that preserves only Resilient-Path safety. An uncertified-DAG instantiation (OrcDAG) is implemented and evaluated against Mysticeti and Hydrangea, quantifying the latency gained by trading the classic 3f+1 budget.

Significance. If the necessity result holds, it cleanly separates the cost of crash faults from Byzantine faults for the optimal 2-delay path and gives operators an explicit (f, c) design space that recovers 5f+1 when c = 0. The dual-path client model and the double-signing bound for checkpoints are a natural FlexibleBFT-style extension that does not degrade core liveness under the stated assumptions. The evaluation is concrete and reproducible (open-source fork of Mysticeti), and the latency-vs-fault-tolerance trade-off is measured under realistic geo-distribution. The work is a solid incremental contribution to hybrid-fault low-latency SMR rather than a paradigm shift, but the tight bound and the fully specified view-change/recovery machinery make it useful for both theory and systems practice.

major comments (2)
  1. Theorem 6 (core liveness) is scoped only to executions with at most f equivocators. When that regime is violated, Algorithm 2 switches to a strictly synchronous recovery model with known Δ_sync. The abstract and introduction present the dual-path architecture as a continuous client-selectable trade-off; the manuscript should state more prominently (e.g., in the abstract and §I) that Resilient-Path liveness is not guaranteed under partial synchrony once AbC-induced VoteQC forks appear, and that recovery relies on a stronger network assumption. This is a scoping issue rather than a correctness error, but it is load-bearing for how the contribution is advertised.
  2. Lemma 7 (unique CheckpointQC) and the single-ChkProp-per-height rule are correctly used for safety, yet the same rule can permanently split honest checkpoint proposals and lose Resilient-Path liveness until recovery. The paper acknowledges the trade-off in §III but does not quantify how often honest replicas can be forced into such a split under realistic asynchrony or leader faults. A short discussion or a simple adversarial schedule would strengthen the claim that the Resilient Path remains useful in practice.
minor comments (5)
  1. Figure 1 caption and the concrete examples in §I use n = 100 / n = 99 inconsistently; align the numbers.
  2. Table I lists σ as a state root but the chaining formula σ_s = H(σ_{s-1} ∥ h) appears only in prose; a short formal definition would help.
  3. Related-work comparison with Hydrangea (n = 3f + 2c + k + 1) is accurate but could note more clearly that Hydrangea’s optimistic path can be faster under zero faults while Orcaella never falls back from its 2-delay path under the core f bound.
  4. Appendix D (CFT-only deployment) is useful; a one-sentence pointer in the main evaluation section would make it easier to find.
  5. Minor typographical issues: “fall-back” vs “fallback”, “instantiate” → “instantiation” in §V, and a few missing spaces around math in the abstract.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Theorem 1's n ≥ 5f+3c+1 bound is forced by three independent counting constraints from explicit adversarial strategies, not by definition, fit, or self-citation.

full rationale

The paper's central result (Theorem 1) is a pure combinatorial necessity argument for vote-counting protocols. It introduces three inequalities—Liveness (q ≤ n−f−c), Reachability (k ≤ 2q−n−f), and Exclusivity (k ≥ n−q+f+1)—each justified by a concrete adversarial schedule that would violate safety or liveness if the inequality failed. Their conjunction yields n ≥ 5f+3c+1 with unique thresholds q = 4f+2c+1 and k = 2f+c+1 at the minimum; sufficiency is then proved by separate lemmas (quorum intersection, Fast-Path uniqueness, View-Change Invariance, etc.) that use those thresholds rather than presuppose them. No parameter is fitted to data and then re-presented as a prediction; no uniqueness theorem is imported from the authors' prior work to forbid alternatives; the single-ChkProp locking rule and f_abc bound are derived from the same intersection arithmetic. The OrcDAG implementation re-uses the authors' Mysticeti codebase, but that is an engineering substrate whose latency numbers are fresh measurements under the new decision rules, not algebraic restatements of earlier claims. The derivation chain is therefore self-contained and non-circular.

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

The central bound is a pure counting result under the classical partial-synchrony and hybrid-fault model; no numeric parameters are fitted to experimental data. The protocol re-uses standard cryptographic and network assumptions and the previously published alive-but-corrupt notion. The only paper-specific modeling choices are the vote-counting template itself and the single-ChkProp locking rule that enables the resilient path.

assumptions (6)
  • domain assumption After an unknown GST, message delays among correct replicas are bounded by a known constant Δ (partial synchrony).
    Standard Dwork-Lynch-Stockmeyer model used for all liveness claims (Section II, Theorem 6).
  • domain assumption At most f replicas may equivocate; at most c may crash without equivocating; the two classes are disjoint.
    Hybrid fault model that defines the counting arguments of Theorem 1 and the core-execution regime of Theorem 6.
  • domain assumption Digital signatures are unforgeable and channels are authenticated.
    Standard cryptographic assumption stated in Section II; used for all certificate validity.
  • ad hoc to paper A protocol is vote-counting if it finalizes on q matching first-round votes and recovers by re-proposing a digest that appears in at least k of the highest-view reports inside a quorum of ViewChange messages.
    Definition that scopes the necessity claim of Theorem 1; the paper proves the bound only inside this class.
  • domain assumption State roots bind history: σ_s = H(σ_{s-1} ∥ h) so a checkpoint at height s determines all lower heights.
    Used for Checkpoint Chain Consistency (Lemma 8) and for the recovery rule that adopts the highest CheckpointQC.
  • ad hoc to paper Recovery epochs run under a known, pessimistic synchronous bound Δ_sync with lock-step rounds.
    Required for the Byzantine-broadcast repair of Algorithm 2; stronger than the partial-synchrony model used for normal operation.
invented entities (1)
  • Client-selectable Resilient Path (CheckpointQC + FinalityQC chain)
    purpose: Give clients that wait two extra delays safety against an additional f_abc < n-3f-2c alive-but-corrupt replicas without degrading core Fast-Path liveness.
    The dual-path architecture and the exact f_abc bound are introduced in this paper; the underlying AbC notion is taken from FlexibleBFT.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Orcaella: Hybrid Fault Tolerance with Client-Selectable Finality Latency." pith.science (2026). https://pith.science/paper/HPDJDZIK

@misc{pith2026260704789,
  author       = {Pith},
  title        = {Pith review of: Orcaella: Hybrid Fault Tolerance with Client-Selectable Finality Latency},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HPDJDZIK}},
  note         = {Machine review of arXiv:2607.04789}
}
read the original abstract

Classical partially synchronous state machine replication, as in PBFT, tolerates f Byzantine replicas among n at least 3f+1 using three communication steps per request. Recent protocols such as Minimmit achieve two-message-delay decisions under stronger size assumptions, notably n at least 5f+1 when any silent replica must be counted as a potential equivocator. Hydrangea and Kudzu treat mixed Byzantine and crash faults, focusing on providing a fast-path under optimistic conditions while maintaining a fall-back commitment path similar to PBFT. In this paper, we also consider a mixed model, but focus on studying the fault tolerance of the 2-message-delay commit. For this, we prove a tight bound of n at least 5f+3c+1. Extending this result, we also show that there exists a more resilient commit path that allows an extra f_abc < n-3f-2c alive-but-corrupt faults at 4-message-delays. Core liveness is claimed in executions with at most f equivocators; if this regime is violated (e.g., AbC-induced forks), the protocol enters synchronous recovery, where only the resilient-path safety guarantee is preserved. As a result, for f=16, c=6, and n=99, we obtain a commit path that tolerates 22% of replicas failing for liveness, 16% equivocating for 1-RTT safety, and 54% equivocating for 2-RTT safety.

Figures

Figures reproduced from arXiv: 2607.04789 by the authors.

Figure 1
Figure 1. Fault-tolerance design space at n = 100. Typical 3f + 1 protocols treat every fault as Byzantine, covering the region f +c ≤ 33 (orange) at the cost requiring 3 message delays to commit. Orcaella instead covers the region 5f + 3c + 1 ≤ n (green), trading some fault tolerance for its 2-message-delay commit. Each solid green line is one example config’s runtime frontier: a cap (f, c) tolerates any mix down to (0, f + … view at source ↗
Figure 2
Figure 2. Runtime fault tolerance of the benchmarked configurations. [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 6
Figure 6. Per-protocol latency at high load (100k tx/s); queuing segment stacked. 0 20k 40k 60k 80k 100k Throughput (tx/s) 0 5 10 15 20 25 Latency improvement vs Mysticeti (%) OrcDAG (f=10,c=0) OrcDAG (f=6,c=6) OrcDAG (f=8,c=3) OrcDAG (f=2,c=13) [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗
Figures from the paper (3 more)
Figure 5
Figure 5. Figure 5: Per-protocol latency at low load (10k tx/s); queuing ablated. E. Understanding the latency trade-off We zoom into [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 8
Figure 8. Figure 8: When the quorum is forced to include the slow region (minimal [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: EU (multi-region) crash-only OrcDAG run; mean ± stdev. deviations. In this lightly-loaded regime the commit latency is load-independent and essentially flat: OrcDAG commits with a mean latency of about 22 ms at 1k tx/s and about 23 ms at 10k tx/s, with a standard devia…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 2 linked inside Pith

  1. [1]

    Practical byzantine fault tolerance,

    M. Castro and B. Liskov, “Practical byzantine fault tolerance,” inProc. OSDI, 1999

    1999

  2. [2]

    Minimmit: Fast finality with even faster blocks,

    B. K. Chou, A. Lewis-Pye, and P. O’Grady, “Minimmit: Fast finality with even faster blocks,” arXiv:2508.10862, 2025

    arXiv 2025

  3. [3]

    Hydrangea: Optimistic two-round partial synchrony with improved fault resilience,

    N. Shrestha, A. Kate, and K. Nayak, “Hydrangea: Optimistic two-round partial synchrony with improved fault resilience,” Cryptology ePrint Archive, Report 2025/1112, 2025

    2025

  4. [4]

    Kudzu: Fast and simple high-throughput BFT,

    V. Shoup, J. Sliwinski, and Y. Vonlanthen, “Kudzu: Fast and simple high-throughput BFT,” inDISC, 2025

    2025

  5. [5]

    Flexible byzantine fault tolerance,

    D. Malkhi, K. Nayak, and L. Ren, “Flexible byzantine fault tolerance,” inProc. ACM CCS, 2019

    2019

  6. [6]

    SoK: Consensus in the age of blockchains,

    S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn, and G. Danezis, “SoK: Consensus in the age of blockchains,” inACM AFT, 2019

    2019

  7. [7]

    Consensus in the presence of partial synchrony,

    C. Dwork, N. Lynch, and L. Stockmeyer, “Consensus in the presence of partial synchrony,”J. ACM, vol. 35, no. 2, pp. 288– 323, 1988

    1988

  8. [8]

    Implementing fault-tolerant services using the state machine approach: A tutorial,

    F. B. Schneider, “Implementing fault-tolerant services using the state machine approach: A tutorial,”ACM Computing Surveys, vol. 22, no. 4, 1990

    1990

Show all 47 references
  1. [9]

    Be aware of your leaders,

    S. Cohen, R. Gelashvili, E. Kokoris-Kogias, Z. Li, D. Malkhi, A. Sonnino, and A. Spiegelman, “Be aware of your leaders,” in Financial Cryptography, 2022

    2022

  2. [10]

    Streamlet: Textbook streamlined blockchains,

    B. Y. Chan and E. Shi, “Streamlet: Textbook streamlined blockchains,” inProceedings of the 2nd ACM Conference on Advances in Financial Technologies, 2020, pp. 1–11

    2020

  3. [11]

    HotStuff: BFT consensus with linearity and responsiveness,

    M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “HotStuff: BFT consensus with linearity and responsiveness,” in PODC, 2019

    2019

  4. [12]

    Jolteon and Ditto: Network-adaptive efficient con- sensus with asynchronous fallback,

    R. Gelashvili, L. Kokoris-Kogias, A. Sonnino, A. Spiegelman, and Z. Xiang, “Jolteon and Ditto: Network-adaptive efficient con- sensus with asynchronous fallback,” inFinancial Cryptography and Data Security (FC), 2022

    2022

  5. [13]

    Beluga: Block synchronization for BFT consensus protocols,

    T. Kichidis, L. Kokoris-Kogias, A. Koshy, I. Sergey, A. Sonnino, M. Tian, and J. Zhang, “Beluga: Block synchronization for BFT consensus protocols,” https://arxiv.org/abs/2511.15517, 2025

    2025 arXiv

  6. [14]

    Sync hotstuff: Simple and practical synchronous state machine repli- cation,

    I. Abraham, D. Malkhi, K. Nayak, L. Ren, and M. Yin, “Sync hotstuff: Simple and practical synchronous state machine repli- cation,” in2020 IEEE Symposium on Security and Privacy (SP). IEEE, 2020, pp. 106–118

    2020

  7. [15]

    Authenticated algorithms for byzantine agreement,

    D. Dolev and H. R. Strong, “Authenticated algorithms for byzantine agreement,”SIAM Journal on Computing, vol. 12, no. 4, pp. 656–666, 1983

    1983

  8. [16]

    On expected constant-round protocols for byzantine agreement,

    J. Katz and C.-Y. Koo, “On expected constant-round protocols for byzantine agreement,” inAdvances in Cryptology–CRYPTO

  9. [17]

    Springer, 2006, pp. 445–462

    2006

  10. [18]

    Narwhal and Tusk: A DAG-based mempool and efficient BFT consensus,

    G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, “Narwhal and Tusk: A DAG-based mempool and efficient BFT consensus,” inEuroSys, 2022

    2022

  11. [19]

    Bullshark: DAG BFT protocols made practical,

    A. Spiegelman, N. Giridharan, A. Sonnino, and L. Kokoris- Kogias, “Bullshark: DAG BFT protocols made practical,” in ACM CCS, 2022

    2022

  12. [20]

    Mysticeti: Reaching the latency limits with uncertified DAGs,

    K. Babel, A. Chursin, G. Danezis, A. Kichidis, L. Kokoris-Kogias, A. Koshy, A. Sonnino, and M. Tian, “Mysticeti: Reaching the latency limits with uncertified DAGs,” inNDSS, 2025

    2025

  13. [21]

    BlueBottle: Fast and robust blockchains through subsystem specialization,

    P. Vander Vos, A. Sonnino, G. Tsimos, P. Jovanovic, and L. Kokoris-Kogias, “BlueBottle: Fast and robust blockchains through subsystem specialization,” 2025

    2025

  14. [22]

    Mahi-Mahi: Low-latency asynchronous BFT DAG-based consensus,

    P. Jovanovic, L. Kokoris-Kogias, B. Kumara, A. Sonnino, P. Ten- nage, and I. Zablotchi, “Mahi-Mahi: Low-latency asynchronous BFT DAG-based consensus,” 2024

    2024

  15. [23]

    Sailfish: Towards improv- ing the latency of DAG-based BFT,

    N. Shrestha, A. Kate, and K. Nayak, “Sailfish: Towards improv- ing the latency of DAG-based BFT,” inIEEE Symposium on Security and Privacy (S&P), 2025

    2025

  16. [24]

    Shoal: Improving DAG-BFT latency and robustness,

    A. Spiegelman, B. Arun, R. Gelashvili, and Z. Li, “Shoal: Improving DAG-BFT latency and robustness,” inFinancial Cryptography and Data Security (FC), 2024

    2024

  17. [25]

    HammerHead: Leader reputation for dynamic scheduling,

    G. Tsimos, A. Kichidis, A. Sonnino, and L. Kokoris-Kogias, “HammerHead: Leader reputation for dynamic scheduling,” in IEEE ICDCS, 2024

    2024

  18. [26]

    Mysticeti: Low-latency DAG consensus with fast commit path,

    M. Labs, “Mysticeti: Low-latency DAG consensus with fast commit path,” https://github.com/asonnino/mysticeti, 2024

    2024

  19. [27]

    Twins: BFT systems made robust,

    S. Bano, A. Sonnino, A. Chursin, D. Perelman, Z. Li, A. Ching, and D. Malkhi, “Twins: BFT systems made robust,” inProc. International Conference on Principles of Distributed Systems (OPODIS), 2021

    2021

  20. [28]

    An empirical study of consensus protocols’ DoS resilience,

    G. Giuliari, A. Sonnino, M. Frei, F. Streun, L. Kokoris-Kogias, and A. Perrig, “An empirical study of consensus protocols’ DoS resilience,” inACM AsiaCCS, 2024

    2024

  21. [29]

    Solana Alpenglow consensus: Increased bandwidth, reduced latency,

    Q. Kniep, K. Sliwinski, and R. Wattenhofer, “Solana Alpenglow consensus: Increased bandwidth, reduced latency,” Anza white paper, v1.1, 2025

    2025

  22. [30]

    Solana decentralization: Facts and figures,

    Helius, “Solana decentralization: Facts and figures,” https:// www.helius.dev/blog/solana-decentralization-facts-and-figures, 2024, accessed June 2026

    2024

  23. [31]

    Suiscan: Sui mainnet explorer,

    Suiscan, “Suiscan: Sui mainnet explorer,” https://suiscan.xyz/ mainnet/home, accessed June 2026

    2026

  24. [32]

    Sui Lutris: A blockchain combining broadcast and consensus,

    S. Blackshear, A. Chursin, G. Danezis, A. Kichidis, L. Kokoris- Kogias, X. Li, M. Logan, A. Menon, T. Nowacki, A. Sonnino, B. Williams, and L. Zhang, “Sui Lutris: A blockchain combining broadcast and consensus,” inACM CCS, 2024

    2024

  25. [33]

    Interactive consistency with multiple failure modes,

    P. Thambidurai and Y.-K. Park, “Interactive consistency with multiple failure modes,” inProceedings of the 7th Symposium on Reliable Distributed Systems. IEEE, 1988, pp. 93–100

    1988

  26. [34]

    Upright cluster services,

    A. Clement, M. Kapritsos, S. Lee, Y. Wang, L. Alvisi, M. Dahlin, and T. Riche, “Upright cluster services,” inProceedings of the ACM SIGOPS 22nd symposium on Operating systems principles, 2009, pp. 277–290

    2009

  27. [35]

    XFT: Practical fault tolerance beyond crashes,

    S. Liu, P. Viotti, C. Cachin, V. Quema, and M. Vukolic, “XFT: Practical fault tolerance beyond crashes,” in12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), 2016, pp. 485–500

    2016

  28. [36]

    FastPay: High- performance byzantine fault tolerant settlement,

    M. Baudet, G. Danezis, and A. Sonnino, “FastPay: High- performance byzantine fault tolerant settlement,” inACM AFT, 2020

    2020

  29. [37]

    Zef: Low- latency, scalable, private payments,

    M. Baudet, A. Sonnino, M. Kelkar, and G. Danezis, “Zef: Low- latency, scalable, private payments,” inWPES@CCS, 2023

    2023

  30. [38]

    Stingray: Fast concurrent transactions without consensus,

    S. Sridhar, A. Sonnino, and L. Kokoris-Kogias, “Stingray: Fast concurrent transactions without consensus,” https://arxiv.org/ abs/2501.06531, 2025

    2025 arXiv

  31. [39]

    All you need is DAG,

    I. Keidar, E. Kokoris-Kogias, O. Naor, and A. Spiegelman, “All you need is DAG,” inPODC, 2021

    2021

  32. [40]

    T. T. Team, “Tokio,” https://tokio.rs, 2024

    2024

  33. [41]

    Ed25519 for consensus-critical contexts,

    H. de Valence, “Ed25519 for consensus-critical contexts,” https: //crates.io/crates/ed25519-consensus, 2024

    2024

  34. [42]

    Performance of EdDSA and BLS signatures in committee-based consensus,

    Z. Li, A. Sonnino, and P. Jovanovic, “Performance of EdDSA and BLS signatures in committee-based consensus,” inAp- PLIED@PODC, 2023

    2023

  35. [43]

    Rustcrypto: Hashes,

    RustCrypto, “Rustcrypto: Hashes,” https://github.com/ RustCrypto/hashes, 2024

    2024

  36. [44]

    writev(3) – linux man page,

    Die.Net, “writev(3) – linux man page,” https://linux.die.net/ man/3/writev, 2024

    2024

  37. [45]

    Sapling (Minibytes),

    Meta, “Sapling (Minibytes),” https://github.com/facebook/ sapling/tree/main/eden/scm/lib/minibytes, 2024

    2024

  38. [46]

    The part-time parliament,

    L. Lamport, “The part-time parliament,”ACM Transactions on Computer Systems (TOCS), vol. 16, no. 2, pp. 133–169, 1998. Algorithm 4: Decision Rules 1:leadersPerRound▷A number between 1 andq 2:waveLength▷Set to2forOrcaella 3:procedureTryDecide(r committed,r highest) 4:S←[ ]▷Hold...

    1998

  39. [47]

    To ensure data persistence and crash recovery, we employ a Write-Ahead Log (WAL)

    for asymmetric cryptography and blake2 [42] for cryptographic hashing. To ensure data persistence and crash recovery, we employ a Write-Ahead Log (WAL). The WAL optimizes I/O operations through vectored writes [43] and efficient memory-mapped file usage with the minibytes [44]...

Pith tools

Reviewed July 11, 2026 · model on record in the stance chip above.