Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

BlueBottle: Fast and Robust Blockchains through Subsystem Specialization

T0 review · 3 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 BlueBottle claims that splitting consensus into a fast, lower-resilience core and a slower guard layer that audits and recovers it yields sub-second finality at high throughput without giving up strong safety and liveness.

desk verdict BB-Core is a credible 5f+1 DAG protocol with real latency gains; BB-Guard's recovery guarantee is unsupported because the threat model lets the adversary corrupt all guards. read the letter →

arxiv 2511.15361 v2 pith:APAVCNK6 submitted 2025-11-19 cs.DC cs.CR

Preston Vander Vos , Alberto Sonnino , Giorgos Tsimos , Philipp Jovanovic , Lefteris Kokoris-Kogias This is my paper · ORCID
classification cs.DCcs.CR
keywords BlueBottleDAG-basedBFTconsensusn=5f+1finalitylatencyguardlayeraccountablesafetysynchronousrecoveryblockchaintrilemma
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

BlueBottle's central claim is that the blockchain trilemma—security, latency, decentralization—can be dodged rather than optimized by specialization. The paper proposes two cooperating layers: BB-Core, a small set of validators running a DAG-based consensus that tolerates only about 20% Byzantine faults (n=5f+1) but commits transactions in two message delays, under half a second, at over 200,000 tx/s; and BB-Guard, a much larger, slower set of validators that continuously audits the core, detects equivocations or stalls, provably identifies at least f+1 misbehaving core validators, and restarts the core or picks a canonical fork. If the architecture works as claimed, blockchains can offer optimistic sub-second finality while retaining a recovery path when the fast layer is attacked. The paper backs the core with formal safety/liveness theorems and an implementation comparison showing 20–25% lower latency than Mysticeti at equal throughput, and it sketches an asynchronous variant.

What carries the argument

The load-bearing objects are the uncertified DAG with waves of two rounds, and the pair of decision rules that use strong certificates (4f+1 votes) to commit and weak certificates (2f+1 votes) to chain indirect decisions; the 5f+1 node count is exactly what makes the direct-vs-indirect consistency lemmas go through. On the guard side, the central gadget is the blameset: a set of at least f+1 core validators with cryptographic proof of equivocation (safety) or missed rounds (liveness), agreed upon by guard validators via Byzantine broadcast, which then drives exclusion/slashing and protocol restart.

What would settle it

Run BB-Guard with the paper's own stake distribution and an adversary who corrupts all guard validators (which the S_f ≤ (S-1)/2 budget allows) plus 3f+1 core validators; if the adversary equivocates in the core and then blocks guard agreement, the system should fail to restore a canonical fork or make progress. A concrete check: instrument the guard protocol and see whether blameset agreement completes when less than a majority of guards are honest.

Watch

Extended reading notes

Core claim

The paper's discovery is that lowering the fault threshold from n=3f+1 to n=5f+1 makes two-message-delay commitment possible in a DAG-based protocol, and that the lost resilience can be compensated by a synchronous guard layer rather than by slowing the core. Concretely, BB-Core's decision rules use 4f+1-vote strong certificates for direct commit and 2f+1-vote weak certificates for indirect commit, with Lemmas 1–2 showing no honest validator can directly commit while another directly or indirectly skips—the quorum intersection property that needs 5f+1 nodes. BB-Guard then monitors the committed sequence for equivocations and liveness failures, forms blamesets of at least f+1 provably faulty

Load-bearing premise

The entire recovery story hinges on the guard validators maintaining an honest majority when the core is under attack, but the paper's own stake numbers let the adversary corrupt far more stake than the guards collectively hold—so that honesty is assumed, not guaranteed.

Editorial extensions

If this is right

  • Finality latency for the optimistic path drops to two message delays (under 0.5s in the authors' geo-distributed tests), with throughput above 200,000 tx/s.
  • A 5f+1 DAG protocol can be safe and live; the paper's Lemmas 1–8 show direct and indirect decision rules never conflict, and honest leaders are committed every O(f) rounds.
  • When core corruption exceeds f (up to 3f), equivocations become provable: any safety or liveness violation yields a valid blameset of f+1 misbehaving core validators.
  • After exclusion, the core's honest majority is restored (from 4f+1 honest out of 5f+1 to 2f+1 honest out of 4f+1 after removing f+1 misbehaving), enabling a re-run of consensus.
  • Clients can choose between fast finality (~1 RTT, safe under the core assumption) and checkpoint finality (safe against up to 60% malicious core stake).

Reading between the lines

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

  • The guard layer's recovery guarantee presumes an honest majority among guard validators, but the paper's stake split puts only about 1/6 of total stake with the guards while the adversary is allowed up to 1/2; so the 'honest majority among guards' is an added assumption, not derived from the threat model (§5.2, §5.4).
  • The recovery procedure itself is sketched, not specified: §5.4 explicitly says it focuses on regaining honest majority and not on the specifics of re-running consensus afterwards, and Appendix C leaves most liveness proofs for a 'full version online'. Until those are supplied, the end-to-end robustness claim is incomplete.
  • The claimed performance advantage is established only against Mysticeti, a 3f+1 protocol; comparison with other 5f+1 protocols (Kudzu, Hydrangea) is left to future work, so 'unmatched in the BFT literature' is not yet directly tested.
  • A testable extension: BB-Core-Async guarantees deterministic direct commitment when the number of leader slots per round exceeds 3f; sweeping that parameter would show how quickly the async variant's latency approaches the synchronous one.
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

3 major / 5 minor

Summary. BlueBottle is a two-layer blockchain consensus architecture. The core layer, BB-Core, is a DAG-based partially synchronous BFT protocol with n=5f+1 validators that aims to commit in two message delays, and is evaluated against Mysticeti on a geo-distributed AWS testbed. The guard layer, BB-Guard, is a synchronous set of guard validators that monitors BB-Core for equivocations and liveness failures, runs Byzantine agreement over blame sets, and recovers safety/liveness by excluding or slashing faulty core validators. The paper claims that BlueBottle achieves optimistic sub-second finality at high throughput while maintaining strong safety and liveness under a mild synchrony assumption.

Significance. The BB-Core protocol is a genuinely interesting contribution: it appears to be the first DAG-based consensus protocol with n=5f+1, and the two-delay commit path with 20-25% latency reduction over Mysticeti is a concrete, reproducible result backed by an open-source implementation. The safety/liveness lemmas for BB-Core in Section 4 are largely standard and plausible. However, the overall BlueBottle claim depends critically on BB-Guard's recovery guarantees, and that part of the paper contains a load-bearing gap: the stated stake distribution does not imply an honest majority among guard validators, so the recovery and even the detection mechanisms are not guaranteed under the paper's own threat model. This prevents the paper from substantiating its central security claim.

major comments (3)
  1. [§2.2, §5.2, §5.4, Algorithm 4] The guard honest-majority assumption is not entailed by the threat model. From Eq. (2), S_c >= 5(S-1)/6, so guard stake S_g <= (S+5)/6 ≈ S/6. The adversary may corrupt up to S_f <= (S-1)/2 stake. It can therefore corrupt all guard validators (cost ≈ S/6) and still have ≈ S/3 stake left, which remains below the 3/5 core-stake cap required by invariant (1). Section 5.4 asserts that guards 'maintain honest majority' without deriving it, and Algorithm 4 RECOVER relies on guards running Byzantine agreement. With no honest guard majority, no recovery, slashing, or even reliable liveness-failure detection is guaranteed. This invalidates the global safety and liveness claims, including Lemmas 15-16.
  2. [§5.5, Lemma 16] Lemma 16's proof uses '|H|=S_f+1' as the number of honest guards, but S_f was defined in §5.2 as the adversary's global stake, not as a function of the guard set. No model connects global stake to an honest majority of guards. The proof therefore assumes the very property it needs to establish. The liveness recovery guarantee of BB-Guard is unsupported as stated.
  3. [Appendix C] The asynchronous variant BB-Core-Async is presented as a contribution, but Appendix C states: 'We only provide the lemmas with only a few of them proven due to lack of space. We plan to release a full version online.' Several liveness lemmas (e.g., Lemma 26-31) are asserted without complete proofs. Since the paper explicitly claims this variant as part of the system, the missing formal support prevents verification of the asynchronous claims and should be supplied.
minor comments (5)
  1. [§2.2] The notation 'S_a' for guard stake is inconsistent with 'S_g' used elsewhere; presumably a typo.
  2. [§5.2] The displayed condition 'P vi∈core stake_i >= 5S/6' is malformed and should be typeset properly.
  3. [§6] The abstract and Section 1 claim 'under 0.5s at over 200,000 tx/s', but Figure 3 shows latency above 600ms at 300k tx/s for 50 validators. The claimed operating point (200k tx/s) is not directly plotted; please include it or clarify the exact claim.
  4. [§2.2] The global threat model says 'n=2f+1' while the core later uses n_c=5f_c+1; the two uses of f are not clearly related. This makes the stake/number translation in §2.2 harder to follow.
  5. [§5.4] The discussion of what happens after the core regains honest majority is only sketched ('we focus on showing how to regain honest majority... not on the specifics'). For a claimed recovery path, more detail is needed.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: BB-Core's safety/liveness proofs and the measured latency comparison are self-contained; the guard-layer quorum gap is a correctness concern, not a circular reduction.

full rationale

No circular derivation chain is present. BB-Core's decision rules (Algorithms 1–3) are stated independently of the security theorems, and Section 4 proves safety and liveness from quorum-intersection arguments (Lemmas 1–8) rather than by presupposing the claimed guarantees. The 20–25% latency advantage over Mysticeti is an externally measured benchmark result against a separate open-source implementation, not a fitted parameter or a quantity defined in terms of the claim. The guard-layer recovery argument in Section 5 uses Byzantine agreement and blameset construction; although §5.4 asserts that honest guards 'maintain honest majority' without deriving it from the §2.2 stake budget (where S_g ≤ S/6 while the adversary may control S_f ≈ S/2), and Appendix C states that several async lemmas are unproven due to lack of space, these are correctness/completeness gaps rather than circular reductions: no equation, fitted value, or renamed result is reused as its own prediction. Self-citations to Mysticeti and related work are disclosed and do not carry the central derivation; the core protocol's proofs are independent of those citations.

Assumptions & free parameters 2 free parameters · 7 assumptions · 0 invented entities

No new physical or cryptographic entities are introduced. Blamesets and the guard layer are protocol components rather than free-floating inventions. The main uncovered assumptions are the guard-layer honest majority, the synchrony assumptions, and the partially inconsistent stake distribution model.

free parameters (2)
  • leadersPerRound = 2 in evaluation; protocol allows 1..4f+1
    Hand-chosen configuration parameter; affects latency and throughput but is not fitted to match a target result.
  • Leader timeout / network delay bound = 1s leader timeout in evaluation; proofs use 2Δ; guard timers 2Δ/4Δ
    Chosen for experiments and recovery timers; liveness arguments depend on these bounds.
assumptions (7)
  • standard math Standard cryptographic assumptions (hash functions, Ed25519 signatures) hold.
    Used throughout for block validation and equivocation evidence; stated in §2.2.
  • domain assumption BB-Core operates in a partially synchronous network with a known delta after GST.
    Theorem 2 (liveness) and Lemma 5 assume partial synchrony with bounded message delay after GST.
  • domain assumption BB-Guard operates in a synchronous network with known delay bound Δ.
    Lemmas 15 and 16 rely on synchrony to detect equivocations and liveness stalls.
  • domain assumption Adversary is static and controls at most S_f ≤ (S−1)/2 total stake.
    Threat model in §5.2; used in stake-distribution calculations.
  • ad hoc to paper Guard validators maintain an honest majority (unstated).
    Needed for Byzantine agreement/recovery in §5.4; not derived from the S_f budget because guards collectively hold ≤S/6 of stake.
  • domain assumption Core stake is at least 5S/6 and guard stake at most S/6.
    Chosen in §2.2 to preserve checkpoint safety; conflicts with the equal per-validator stake assumption in §5.2.
  • standard math For the async variant, a threshold common coin from an adaptively secure threshold signature scheme exists.
    Used in Appendix C for probabilistic liveness; standard construction, but setup is not detailed in the main text.

how reviews work

0 comments
Cite this review

Pith. "Pith review of BlueBottle: Fast and Robust Blockchains through Subsystem Specialization." pith.science (2026). https://pith.science/paper/APAVCNK6

@misc{pith2026251115361,
  author       = {Pith},
  title        = {Pith review of: BlueBottle: Fast and Robust Blockchains through Subsystem Specialization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/APAVCNK6}},
  note         = {Machine review of arXiv:2511.15361}
}
read the original abstract

Blockchain consensus faces a trilemma of security, latency, and decentralization. High-throughput systems often require a reduction in decentralization or robustness against strong adversaries, while highly decentralized and secure systems tend to have lower performance. We present BlueBottle, a two-layer consensus architecture. The core layer, BB-Core, is an n=5f+1 protocol that trades some fault tolerance for a much lower finality latency with a medium-sized core validator set. Our experiments show that BB-Core reduces latency by 20-25% in comparison to Mysticeti. The guard layer, BB-Guard, provides decentralized timestamping, proactive misbehavior detection in BB-Core, and a synchronous recovery path. When it observes equivocations or liveness failures in the core -- while tolerating up to f<3n/5 faulty nodes in the primary layer -- guard validators disseminate evidence, agree on misbehaving parties for exclusion or slashing, and either restart the core protocol (for liveness violations) or select a canonical fork (for safety violations). Together, these layers enable optimistic sub-second finality at high throughput while maintaining strong safety and liveness under a mild synchrony assumption.

Figures

Figures reproduced from arXiv: 2511.15361 by the authors.

Figure 1
Figure 1. The structure of the BB-Core DAG. Left: A wave consisting of two rounds (Propose and Decision). Right: Wave patterns in the BB-Core protocol (each round initiates a new overlapping wave). Algorithm 3 Helper Functions validators ▷ The set of validators async ▷ Whether the protocol is asynchronous procedure GETDECISIONBLOCKS(w) rdecision ←DECISIONROUND(w) return DAG[rdecision] procedure GETLEADERBLOCKS(w, rank) ▷ Vali… view at source ↗
Figure 2
Figure 2. Example with six validators and two leader slots per round. Initially, all proposer slots are in the undecided state. The validator examines the portion of the DAG shown in [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. WAN throughput-latency performance comparison of BB-Core (n = 5f + 1) and Mysticeti (n = 3f + 1) with a 512B transaction size. The y-axis starts at 300 ms to zoom in on the latency difference between the systems. 7. Making the Core Asynchronous We study BB-Core under partial synchrony and also introduce an asynchronous variant. The asynchronous algo￾rithm mirrors the partially synchronous one, except for the orange-… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: WAN throughput-latency performance comparison [PITH_FULL_IMAGE:figures/full_fig_p020_4.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. Multimmit: Extending Blocks for Faster Finality

    cs.DC 2026-07 conditional novelty 7.0 of 10

    Multimmit finalises transaction blocks in one voting round with roughly 3δ average latency from dissemination, confining a faulty producer's damage to its own chain.

Reference graph

Works this paper leans on

61 extracted references · 7 linked inside Pith · cited by 1 Pith paper

  1. [1]

    Ethereum: A Secure Decentralised Generalised Transac- tion Ledger,

    G. Wood, “Ethereum: A Secure Decentralised Generalised Transac- tion Ledger,” 2014

    2014

  2. [2]

    Avalanche Platform,

    K. Sekniqi, D. Laine, S. Buttolph, and E. G. Sirer, “Avalanche Platform,” 2020

    2020

  3. [3]

    Scal- able and Probabilistic Leaderless BFT Consensus through Metasta- bility,

    T. Rocket, M. Yin, K. Sekniqi, R. van Renesse, and E. G. Sirer, “Scal- able and Probabilistic Leaderless BFT Consensus through Metasta- bility,” 2020

    2020

  4. [4]

    Solana: A New Architecture for a High Performance Blockchain,

    A. Yakovenko, “Solana: A New Architecture for a High Performance Blockchain,” 2017

    2017

  5. [5]

    Mysticeti: Low-Latency DAG Consensus with Fast Commit Path,

    K. Babel, A. Chursin, G. Danezis, L. Kokoris-Kogias, and A. Son- nino, “Mysticeti: Low-Latency DAG Consensus with Fast Commit Path,” 2024

    2024

  6. [6]

    The sybil attack,

    J. R. Douceur, “The sybil attack,” inInternational workshop on peer- to-peer systems. Springer, 2002, pp. 251–260

    2002

  7. [7]

    Proof-of-stake blockchain: Ouroboros,

    A. Kuc ¸i, C. Cachin, and G. A. Marson, “Proof-of-stake blockchain: Ouroboros,” 2021

    2021

  8. [8]

    The sui blockchain,

    The Sui team, “The sui blockchain,” http://sui.io, 2023

    2023

Show all 61 references
  1. [9]

    Consensus in the presence of partial synchrony,

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

    1988

  2. [10]

    Flexible byzantine fault tol- erance,

    D. Malkhi, K. Nayak, and L. Ren, “Flexible byzantine fault tol- erance,” inProceedings of the 2019 ACM SIGSAC conference on computer and communications security, 2019, pp. 1041–1053

    2019

  3. [11]

    Optimal flexible consensus and its application to ethereum,

    J. Neu, S. Sridhar, L. Yang, and D. Tse, “Optimal flexible consensus and its application to ethereum,” in2024 IEEE Symposium on Security and Privacy (SP). IEEE, 2024, pp. 3885–3903

    2024

  4. [12]

    Cordial Miners: Fast and Efficient Consensus for Every Eventuality,

    I. Keidar, O. Naor, O. Poupko, and E. Shapiro, “Cordial Miners: Fast and Efficient Consensus for Every Eventuality,” in37th International Symposium on Distributed Computing (DISC 2023), 2022

    2023

  5. [13]

    Mahi-Mahi: Low-Latency Asynchronous BFT DAG- Based Consensus,

    P. Jovanovic, L. K. Kogias, B. Kumara, A. Sonnino, P. Tennage, and I. Zablotchi, “Mahi-Mahi: Low-Latency Asynchronous BFT DAG- Based Consensus,” in2025 IEEE 45th International Conference on Distributed Computing Systems, ser. ICDS ’25, 2025

    2025

  6. [14]

    All You Need is DAG,

    I. Keidar, E. Kokoris-Kogias, O. Naor, and A. Spiegelman, “All You Need is DAG,” inPODC’21: Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing, 2021

    2021

  7. [15]

    Shoal++: High throughput dag bft can be fast!

    B. Arun, Z. Li, F. Suri-Payer, S. Das, and A. Spiegelman, “Shoal++: High throughput dag bft can be fast!”arXiv preprint arXiv:2405.20488, 2024

    2024 arXiv

  8. [16]

    Sailfish: Towards improving latency of dag-based bft,

    N. Shrestha, R. Shrothrium, A. Kate, and K. Nayak, “Sailfish: Towards improving latency of dag-based bft,”Cryptology ePrint Archive, 2024

    2024

  9. [17]

    Shoal: Improving dag-bft latency and robustness,

    A. Spiegelman, B. Arun, R. Gelashvili, and Z. Li, “Shoal: Improving dag-bft latency and robustness,”arXiv preprint arXiv:2306.03058, 2023

    2023 arXiv

  10. [18]

    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

  11. [19]

    Alpenglow,

    Q. Kniep, J. Sliwinski, and R. Wattenhofer, “Alpenglow,” https: //www.anza.xyz/alpenglow-1-1, 2025

    2025

  12. [20]

    Fast byzantine consensus (fab paxos),

    J.-P. Martin and L. Alvisi, “Fast byzantine consensus (fab paxos),” in Proceedings of the International Conference on Dependable Systems and Networks, ser. DSN ’05, 2005

    2005

  13. [21]

    Kudzu: Fast and Simple High-Throughput BFT,

    V . Shoup, J. Sliwinski, and Y . V onlanthen, “Kudzu: Fast and Simple High-Throughput BFT,” 2025

    2025

  14. [22]

    Hydrangea: Optimistic two-round partial synchrony,

    N. Shrestha, A. Kate, and K. Nayak, “Hydrangea: Optimistic two-round partial synchrony,” Cryptology ePrint Archive, Paper 2025/1112, 2025. [Online]. Available: https://eprint.iacr.org/2025/ 1112

    2025

  15. [23]

    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,”arXiv preprint arXiv:2004.10617, 2020

    2004 arXiv

  16. [24]

    Ham- merhead: Leader reputation for dynamic scheduling,

    G. Tsimos, A. Kichidis, A. Sonnino, and L. Kokoris-Kogias, “Ham- merhead: Leader reputation for dynamic scheduling,” in2024 IEEE 44th International Conference on Distributed Computing Systems (ICDCS). IEEE, 2024, pp. 1377–1387

    2024

  17. [25]

    Sync hotstuff: Simple and practical synchronous state machine replication,

    I. Abraham, D. Malkhi, K. Nayak, L. Ren, and M. Yin, “Sync hotstuff: Simple and practical synchronous state machine replication,” in2020 IEEE Symposium on Security and Privacy, ser. SP ’20, 2020

    2020

  18. [26]

    Byzantine Agreement, Broadcast and State Machine Replication with Near-optimal Good- case Latency,

    I. Abraham, K. Nayak, L. Ren, and Z. Xiang, “Byzantine Agreement, Broadcast and State Machine Replication with Near-optimal Good- case Latency,” arXiv cs.CR 2003.13155, 2020

    2003 arXiv

  19. [27]

    Practical byzantine fault tolerance,

    M. Castro and B. Liskov, “Practical byzantine fault tolerance,” in Proceedings of the Third USENIX Symposium on Operating Systems Design and Implementation (OSDI), New Orleans, Louisiana, USA, February 22-25, 1999, M. I. Seltzer and P. J. Leach, Eds. USENIX Association, 1999, ...

    1999

  20. [28]

    SBFT: A Scalable and Decentralized Trust Infrastructure,

    G. Golan Gueta, I. Abraham, S. Grossman, D. Malkhi, B. Pinkas, M. Reiter, D.-A. Seredinschi, O. Tamir, and A. Tomescu, “SBFT: A Scalable and Decentralized Trust Infrastructure,” in2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2019

    2019

  21. [29]

    Zyzzyva: Speculative byzantine fault tolerance,

    R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva: Speculative byzantine fault tolerance,” inProceedings of the 21st ACM SIGOPS Symposium on Operating Systems Principles, ser. SOSP ’07. Association for Computing Machinery, 2007

    2007

  22. [30]

    The latest gossip on BFT consensus,

    E. Buchman, J. Kwon, and Z. Milosevic, “The latest gossip on BFT consensus,” arXiv cs.DC 1807.04938, 2019

    2019 arXiv

  23. [31]

    Simplex Consensus: A Simple and Fast Consensus Protocol,

    B. Y . Chan and R. Pass, “Simplex Consensus: A Simple and Fast Consensus Protocol,” inTheory of Cryptography: 21st International Conference, ser. TCC 2023. Springer-Verlag, 2023

    2023

  24. [32]

    Good-case Latency of Byzantine Broadcast: A Complete Categorization,

    I. Abraham, K. Nayak, L. Ren, and Z. Xiang, “Good-case Latency of Byzantine Broadcast: A Complete Categorization,” inProceedings of the 2021 ACM Symposium on Principles of Distributed Computing, ser. PODC’21, 2021

    2021

  25. [33]

    Revisiting Optimal Resilience of Fast Byzantine Consensus,

    P. Kuznetsov, A. Tonkikh, and Y . X. Zhang, “Revisiting Optimal Resilience of Fast Byzantine Consensus,” inProceedings of the 2021 ACM Symposium on Principles of Distributed Computing, ser. PODC’21, 2021

    2021

  26. [34]

    Revisiting Fast Practical Byzantine Fault Tolerance: Thelma, Velma, and Zelma,

    I. Abraham, G. Gueta, D. Malkhi, and J.-P. Martin, “Revisiting Fast Practical Byzantine Fault Tolerance: Thelma, Velma, and Zelma,” arXiv CS.DC 1801.10022, 2018

    2018 arXiv

  27. [35]

    The next 700 bft protocols,

    P.-L. Aublin, R. Guerraoui, N. Kne ˇzevi´c, V . Qu´ema, and M. Vukoli ´c, “The next 700 bft protocols,”ACM Trans. Comput. Syst., vol. 32, no. 4, 2015

    2015

  28. [36]

    Consensus in one communication step,

    F. V . Brasileiro, F. Greve, A. Most´efaoui, and M. Raynal, “Consensus in one communication step,” inProceedings of the 6th International Conference on Parallel Computing Technologies, ser. PaCT ’01. Springer-Verlag, 2001

    2001

  29. [37]

    Simple and Efficient Oracle-Based Consensus Protocols for Asynchronous Byzantine Sys- tems ,

    R. Friedman, A. Mostefaoui, and M. Raynal, “ Simple and Efficient Oracle-Based Consensus Protocols for Asynchronous Byzantine Sys- tems ,”IEEE Transactions on Dependable and Secure Computing, vol. 2, no. 1, pp. 46–56, 2005

    2005

  30. [38]

    Optimistic byzantine agreement,

    K. Kursawe, “Optimistic byzantine agreement,” inProceedings of the 21st IEEE Symposium on Reliable Distributed Systems, ser. SRDS ’02. IEEE Computer Society, 2002

    2002

  31. [39]

    Thunderella: Blockchains with optimistic instant confirmation,

    R. Pass and E. Shi, “Thunderella: Blockchains with optimistic instant confirmation,” inAdvances in Cryptology – EUROCRYPT 2018. Springer International Publishing, 2018

    2018

  32. [40]

    On the optimality of optimistic responsiveness,

    N. Shrestha, I. Abraham, L. Ren, and K. Nayak, “On the optimality of optimistic responsiveness,” inProceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’20. Association for Computing Machinery, 2020

    2020

  33. [41]

    Optimistic, Signature-Free Reliable Broadcast and Its Applications,

    N. Shrestha, Q. Yu, A. Kate, G. Losa, K. Nayak, and X. Wang, “Optimistic, Signature-Free Reliable Broadcast and Its Applications,” 2025

    2025

  34. [42]

    2-round bft in simplex style forn= 5f−1,

    I. Abraham and L. Ren, “2-round bft in simplex style forn= 5f−1,” https://decentralizedthoughts.github. io/2025-08-06-5fminus1-simplex/, Aug. 2025, decentralized Thoughts. Accessed: 2025-11-13. [Online]. Available: https: //decentralizedthoughts.github.io/2025-08-06-5fminus1-simplex/

    2025

  35. [43]

    Casper the Friendly Finality Gadget,

    V . Buterin and V . Griffith, “Casper the Friendly Finality Gadget,” arXiv cs.CR 1710.09437, 2019

    2019 arXiv

  36. [44]

    The Availability-Accountability Dilemma and Its Resolution via Accountability Gadgets,

    J. Neu, E. N. Tas, and D. Tse, “The Availability-Accountability Dilemma and Its Resolution via Accountability Gadgets,” inFinancial Cryptography and Data Security: 26th International Conference, ser. FC ’22, 2022

    2022

  37. [45]

    BFT Protocol Forensics,

    P. Sheng, G. Wang, K. Nayak, S. Kannan, and P. Viswanath, “BFT Protocol Forensics,” inProceedings of the 2021 ACM SIGSAC Con- ference on Computer and Communications Security, ser. CCS ’21. Association for Computing Machinery, 2021

    2021

  38. [46]

    Accountable Liveness,

    A. Lewis-Pye, J. Neu, T. Roughgarden, and L. Zanolini, “Accountable Liveness,” inProceedings of the 2025 on ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’25, 2025

    2025

  39. [47]

    Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and Impossibilities,

    E. N. Tas, D. Tse, F. Gai, S. Kannan, M. A. Maddah-Ali, and F. Yu, “Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and Impossibilities,” in2023 IEEE Symposium on Security and Privacy, ser. SP ’23, 2023

    2023

  40. [48]

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

    2024

  41. [49]

    Ed25519 for consensus-critical contexts,

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

    2024

  42. [50]

    Rustcrypto: Hashes,

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

    2024

  43. [51]

    writev(3) - linux man page,

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

    2024

  44. [52]

    Sapling (minibytes),

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

    2024

  45. [53]

    Validator deployment amd configuration,

    T. S. Team, “Validator deployment amd configuration,” https://docs. sui.io/guides/operator/validator/validator-config, 2025

    2025

  46. [54]

    Asynchronous byzantine agreement with subquadratic communication,

    E. Blum, J. Katz, C.-D. Liu-Zhang, and J. Loss, “Asynchronous byzantine agreement with subquadratic communication,” inTheory of Cryptography: 18th International Conference, TCC 2020, Durham, NC, USA, November 16–19, 2020, Proceedings, Part I 18. Springer, 2020, pp. 353–380

    2020

  47. [55]

    Random oracles in constan- tipole: practical asynchronous byzantine agreement using cryptogra- phy,

    C. Cachin, K. Kursawe, and V . Shoup, “Random oracles in constan- tipole: practical asynchronous byzantine agreement using cryptogra- phy,” inProceedings of the nineteenth annual ACM symposium on Principles of distributed computing, 2000, pp. 123–132

    2000

  48. [56]

    Combining asynchronous and synchronous byzantine agreement: The best of both worlds,

    J. Loss and T. Moran, “Combining asynchronous and synchronous byzantine agreement: The best of both worlds,”Cryptology ePrint Archive, 2018

    2018

  49. [57]

    On the Adaptive Security of the Threshold BLS Signature Scheme,

    R. Bacho and J. Loss, “On the Adaptive Security of the Threshold BLS Signature Scheme,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022

    2022

  50. [58]

    Short signatures from the weil pairing,

    D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weil pairing,” inInternational conference on the theory and application of cryptology and information security. Springer, 2001, pp. 514–532

    2001

  51. [59]

    Bingo: Adaptivity and Asynchrony in Verifiable Secret Sharing and Distributed Key Generation,

    I. Abraham, P. Jovanovic, M. Maller, S. Meiklejohn, and G. Stern, “Bingo: Adaptivity and Asynchrony in Verifiable Secret Sharing and Distributed Key Generation,” inAdvances in Cryptology – CRYPTO 2023, 2023

    2023

  52. [60]

    Reaching Consensus for Asynchronous Distributed Key Generation,

    I. Abraham, P. Jovanovic, M. Maller, S. Meiklejohn, G. Stern, and A. Tomescu, “Reaching Consensus for Asynchronous Distributed Key Generation,”Distributed Computing, vol. 36, 2023. Appendix A. Implementation We implement a networked, multi-coreBB-Coreval- idator in Rust by for...

    2023

  53. [61]

    We experimentally increase the load of transactions sent to the systems, and record the throughput and latency of commits

    https://github.com/phvv/mysticeti/tree/odontoceti (commite02aeba) rate. We experimentally increase the load of transactions sent to the systems, and record the throughput and latency of commits. As a result, all plots Section 6 illustrate the steady-state latency of all system...

Pith tools

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