Pith. sign in

REVIEW 3 major objections 4 minor 77 references

Multimmit claims a total ordering of multi-chain transaction blocks in one round of voting, ordering a block disseminated at time t by t+3δ in expectation and t+2δ at best, with a faulty producer's damage limited to its own chain.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-01 08:40 UTC pith:SUDUBHXJ

load-bearing objection Real new protocol idea with careful proofs, but the abstract's unconditional t+3δ latency claim is not supported by the protocol's own extension-bound rules, and the manuscript is an unfinished draft with no experiments or related work. the 3 major comments →

arxiv 2607.21021 v1 pith:SUDUBHXJ submitted 2026-07-23 cs.DC

Multimmit: Extending Blocks for Faster Finality

Andrew Lewis-Pye , Patrick O'Grady This is my paper
classification cs.DC MSC 68M1468W15
keywords State Machine ReplicationByzantine fault tolerancepartial synchronymulti-chain consensusfinality latencycensorship resistancedata availabilityone-round voting
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Multimmit aims to show that a multi-chain blockchain can combine the robustness of certified designs with the speed of uncertified ones: no processor ever blocks or fetches data on the critical path, yet a transaction block that has reached the voters is placed in the total order roughly three message delays after dissemination, two at best, measured from the block itself rather than from a leader proposal. The mechanism is to have each voter cast a single vector vote reporting, per chain, how far it supports the leader's proposal, and to let those same votes attach fresh blocks beyond the proposal. This removes the leader's proposal leg from the critical path and makes the frontier leader-proof: a leader that wants its own block finalised cannot exclude a fresh, well-circulated honest block. If right, the protocol gives one-round finality with a near-optimal good-case latency and no easy way for a handful of faulty producers to deny the system its fast path.

Core claim

The central claim is that with n≥5f+1 processors, one round of voting per view suffices to finalise a total ordering over many parallel transaction chains, provided votes are cast relative to a leader's per-chain proposal and may extend that proposal with fresh blocks. A transaction block disseminated at time t is ordered by t+3δ in expectation and t+2δ at best, measured from the block's own dissemination; in the common case (correct leader, up to f faulty others) the same figures hold, with placement at most t+5δ when queued behind a lagging faulty chain. The protocol further proves an inclusion theorem: if a fresh honest block reaches all correct processors before they vote, then any view

What carries the argument

The load-bearing object is the per-chain vector vote: each voter reports the highest position on each chain for which it has DA-voted the leader's proposed entries, plus up to e payload hashes as extensions anchored at the voter's reported position. Consensus runs on two kinds of notarisation: a V-QC, whose safe-to-extend tips are obtained by discarding the top f votes per chain and licenses view exit, and an L-QC, whose finalised tips discard the top 3f votes per chain and finalise after n−f votes. Extensions are counted branch-by-branch: safe-to-extend tips can be carried by 2f+1 attestations, while immediate order-finality for an extension block requires unanimity at n=5f+1. A determinist

Load-bearing premise

The load-bearing premise is that an honest block is fresh and well-circulated by the time voters act: every correct processor has received and DA-voted the block and all ancestors above the previous safe-to-extend tip before sending its view-v vote, and the block is within e heights of that tip (the hypotheses of Theorem 3).

What would settle it

A concrete check: run or simulate the protocol with n=5f+1, one honest producer disseminating a fresh block b to all correct processors before they vote in a view, and a leader that finalises its block in that view; Theorem 3 predicts that b appears in every view-v V-QC's tip and in the log emitted by the next finalised leader block. Missing b in any such run refutes the censorship-resistance claim. Likewise, in a correct-leader view after synchrony, an honest chain's block disseminated at time t should be finalised by t+3δ in expectation and placed by t+5δ when queued — a trace violating thos

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Transaction latency drops by about two message delays relative to certified multi-chain designs and to Raptr: t+3δ in expectation and t+2δ at best, without requiring data to be fetched on the critical path.
  • Faulty producers cannot spoil the optimistic path: a withheld block delays only its own chain, and honest chains' blocks are still finalised on schedule, costing other chains at most a one-view wait for placement.
  • A leader cannot have its block finalised while excluding a fresh, well-circulated honest block: either the view finalises nothing, or the honest block's membership is settled in that view and it is ordered by the next finalised leader block.
  • Every block that enters the ordering is guaranteed available for retrieval, and consensus traffic stays at tens of kilobytes per view, independent of transaction volume.
  • The extraction thresholds are tight: at n=5f+1 unanimity is required for immediate extension finality, while for larger n a relaxation to ⌈(n+3f)/2⌉ votes becomes safe.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the unanimity requirement for extension finality is the price of leader-independent censorship resistance; if only membership is needed rather than immediate ordering, weaker thresholds already suffice, which could support intermediate designs.
  • Editorial inference: the inclusion theorem implies a simple censorship detector — monitor whether a view finalises a leader block while omitting a block that reached all honest voters before they voted; the theorem says this cannot happen.
  • Editorial inference: the paper itself marks the experimental evaluation and related-work survey as unfinished (Sections 7 and 8 are placeholders), so the latency and size figures are analytic claims awaiting measurement; a prototype under message loss would test whether the t+3δ bound survives real network conditions.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. Multimmit proposes a Byzantine fault-tolerant SMR protocol for n≥5f+1 that combines a Minimmit-style single-round-vote consensus layer with multi-chain transaction-block dissemination. Each view's leader proposes per-chain tips; voters report per-chain how far they have DA-voted and may attach up to e extension blocks; L-QCs finalise quorum-supported prefixes and V-QCs govern safe extension. The paper claims t+3δ expected / t+2δ best-case ordering from a transaction block's dissemination, graceful fault localisation, and leader-independent censorship resistance. Section 5 contains formal proofs of consistency, liveness, availability, membership finality, and an exact threshold theorem for extension extraction; Sections 7–8 are placeholders and Section 6 is explicitly incomplete.

Significance. If the latency claims are appropriately qualified, this is a potentially significant contribution to the high-throughput BFT literature. The protocol avoids Autobahn's certification round trip and Raptr's order-sensitivity without putting fetching on the critical path; one-round finality at n≥5f+1 is combined with per-chain vote vectors and extension votes. The formal specification is unusually complete, and the Section 5 proofs are careful; the exact-threshold Theorem 4 is a strong piece of analysis. However, the paper's headline latency claim is not supported by the formal sections and is contradicted by the protocol's own parameters. Those claims must be corrected before the contribution can be assessed.

major comments (3)
  1. [Abstract; §3.6; §3.7; §4] The unconditional latency claim is inconsistent with the protocol's rules. With the suggested d=3, e=2, consider a correct leader who proposes at time 0 with proposed tip H on chain i (no payload entries above H), and a correct producer of chain i who disseminates H+1,H+2,H+3 just before time 0, with all correct voters receiving them before voting. Voters' reported position for chain i is 0, and by Table 3/§4 extensions are limited to e=2 blocks above the reported position; hence no vote counts for H+3, and no L-QC of that view can finalise or order it. H+3 is ordered only by a later view. This directly contradicts the abstract's 'ordered by t+3δ in expectation and t+2δ at best' and §3.7's 'a single L-QC orders everything attested by all voters'. The guarantee that actually holds is the conditional one of Theorem 3(ii): blocks within e of Tips(Q)_i. The §3.6 timing calculation ignores th
  2. [Section 5; §3.6] The paper never proves the latency theorem that the abstract announces. Lemma 11 bounds finalisation of a correct-leader view from the first correct entry into the view (t+2δ vote, t+3δ finalisation), not from transaction-block dissemination. No theorem in Section 5 relates block dissemination time to the next vote event, and the 'waits on average δ' in §3.6 is an informal average over an unspecified process. It also ignores the e<d queueing described above and the fact that blocks arriving after some voters have already voted are not attested by those voters. If the latency statements are a central contribution, formalise them under an explicit timing/production model (or state them as conditional on the block being within e of the current safe-to-extend tip and received by all correct processors before every vote in the view). Otherwise, the manuscript should clearly demote these numbe
  3. [Sections 6–8] The manuscript is incomplete in ways that affect the paper's claims. Section 7 ('Experiments') is a placeholder, Section 8 ('Related work') is explicitly 'to be written', and Section 6 ends with bracketed items 'to include'. A journal submission needs either the missing material or an explicit statement that no experimental evaluation is provided. The current state prevents acceptance.
minor comments (4)
  1. [§3.4 footnote] Typo: 'vote andlateralso nullify' should read 'vote and later also nullify'.
  2. [§1.1] Typo: 'including forgreedyByzantine leaders' should read 'including for greedy Byzantine leaders'.
  3. [§3.8] The size estimates are useful, but it would help to state the wire size of a vote in the common case explicitly (the text says 'a few hundred bytes' without a concrete upper bound under the stated parameters).
  4. [§5.2, data availability] The retrieval convention is described only informally; since 'Extractable SMR' is the formal guarantee, a short formal statement of the retrieval liveness claim would tighten the paper. This is a presentation point, not a correctness concern.

Circularity Check

0 steps flagged

No substantive circularity: the self-cited Minimmit skeleton is re-derived in Section 5, leaving only a non-load-bearing self-citation.

full rationale

The formal analysis is self-contained. Section 5 defines notarisations and proves Lemmas 1–12 and Theorems 1–4 from the protocol rules rather than appealing to the self-cited Minimmit paper [21]. The statements 'Multimmit inherits this skeleton wholesale' (§3.1) and 'Following Minimmit, we reason about notarisations' (§5.1) describe design lineage; the view-progression and consistency arguments are re-proved in Lemmas 5, 6, 10 and 11 rather than imported. The one-round finality threshold n≥5f+1 is cited to external work [41], not to the authors' own results. No parameter is fitted and then renamed a prediction: there are no empirical fits, and the Raptr comparison uses independent prior work. Theorem 3's inclusion guarantee is obtained by counting correct votes under explicit dissemination and freshness hypotheses (every correct processor DA-votes b before the view-v vote; b is within e of Tips(Q)_i), so the hypotheses are not the conclusion. The abstract's unqualified 'ordered by t+3δ in expectation' is a correctness/rigor concern rather than a circular one: the protocol's own extension bound e and Theorem 3's freshness assumptions are needed for in-view placement, so the advertised figure appears to be stated more broadly than the formal rules support (see §3.5, §3.7 and Theorem 3(ii)). Similarly, the explicit placeholders for experiments and related work (§7 '[Andy: To be added]', §8 '[Andy: To be written]', §6 '[Further items to include...]') are missing support, not circular reductions. The only notable self-citation is [21], which shares two authors with this paper; because the present paper re-proves the adapted consensus skeleton, that self-citation is not load-bearing. Score 2 reflects that minor self-citation and the absence of any circular step in the derivation chain.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 0 invented entities

The argument rests on standard distributed-computing assumptions and two small protocol constants (d, e). V-QCs, L-QCs, vote vectors, and extension votes are protocol messages/constructs, not new physical entities with external falsifiable handles, so no invented entities are listed.

free parameters (3)
  • pipelining depth d = 3 (example)
    Chosen design constant bounding how many uncertified blocks a producer may run ahead; DA-voting rules and proposal sizes depend on it (§3.2, §3.8).
  • extension bound e = 2 (example)
    Chosen design constant capping how many fresh blocks a vote may attest beyond the proposed tip; Theorem 3 and the censorship guarantee quantify over blocks within e (§3.5, §4).
  • batch bound B / production interval θ = unspecified policy
    Pacing parameters; liveness requires only that production occurs within bounded time. They are not fitted to data and do not affect the central latency proofs.
axioms (4)
  • domain assumption n ≥ 5f+1 with at most f Byzantine faulty processors
    Assumed throughout Section 2; all quorum thresholds and finality arguments derive from this resilience bound.
  • domain assumption Partial synchrony: messages after GST are delivered within known Δ, while GST is unknown; correct processors' clocks advance in real time
    Standard partial-synchrony model; liveness proofs use the 2Δ timeouts and after-GST delivery bound (§2, §5.2).
  • domain assumption Perfect cryptography: signatures, PKI, collision-resistant hashing, aggregate signatures, and threshold signatures cannot be forged or broken
    Stated in Section 2; correctness proofs identify certificates with actual notarisations only under unforgeability.
  • domain assumption Correct producers sign at most one block per height and follow parent rules
    Used throughout, e.g. Lemma 1 and Theorem 3, to ensure chain uniqueness and that incompatible blocks imply faulty producers.

pith-pipeline@v1.3.0-alltime-deepseek · 48672 in / 14285 out tokens · 153826 ms · 2026-08-01T08:40:34.556760+00:00 · methodology

0 comments
read the original abstract

To meet the throughput demands of modern blockchain systems, protocols for State Machine Replication (SMR) increasingly have many processors disseminate blocks of transactions in parallel, with consensus then establishing a total ordering on the blocks of all producers. Such designs face a choice as to when a block may enter the ordering. Certified approaches wait for a quorum to attest a block's availability, which is robust but adds message delays to every transaction. Uncertified approaches let proposals reference blocks immediately, which is fast but degrades rapidly when referenced data must be fetched on the critical path. Raptr, the state of the art, takes a middle course, finalising the longest prefix of the leader's proposal that a quorum holds, so that no processor ever blocks or fetches. The remaining weakness is sensitivity to order: if the data behind a single early batch is withheld, the proposal finalises little or nothing, so individual faulty producers can still deny the system its optimistic path. We present Multimmit, a protocol for $n \ge 5f+1$ processors combining a consensus layer requiring one round of voting per view with multi-chain data dissemination. Votes are cast relative to the leader's proposal, reporting per chain how far the voter can support it, and may themselves attest fresh blocks beyond it. A transaction block disseminated at time $t$ is ordered by $t+3\delta$ in expectation and $t+2\delta$ at best, measured from the block's dissemination rather than the leader's proposal. Degradation under faults is graceful: a faulty producer delays only its own chain's blocks, costing other chains at most a one-view wait for placement. No leader can both finalise its leader block and exclude a fresh, well-circulated block of an honest chain. Consensus traffic is tens of kilobytes per view, independent of transaction volume.

Figures

Figures reproduced from arXiv: 2607.21021 by Andrew Lewis-Pye, Patrick O'Grady.

Figure 1
Figure 1. Figure 1: The two layers. Producers extend their own chains of transaction blocks continuously [PITH_FULL_IMAGE:figures/full_fig_p009_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The two extraction rules on one chain, for [PITH_FULL_IMAGE:figures/full_fig_p013_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Extracting the total ordering. Columns are chains [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Best-case ordering of a transaction block disseminated at time [PITH_FULL_IMAGE:figures/full_fig_p015_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

77 extracted references · 18 linked inside Pith

  1. [1]

    Revisiting fast practical byzantine fault tolerance.arXiv preprint arXiv:1712.01367, 2017

    Ittai Abraham, Guy Gueta, Dahlia Malkhi, Lorenzo Alvisi, Rama Kotla, and Jean-Philippe Martin. Revisiting fast practical byzantine fault tolerance.arXiv preprint arXiv:1712.01367, 2017

    Pith/arXiv arXiv 2017

  2. [2]

    Sync hotstuff: Simple and practical synchronous state machine replication

    Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Maofan Yin. Sync hotstuff: Simple and practical synchronous state machine replication. In2020 IEEE Symposium on Security and Privacy (SP), pages 106–118. IEEE, 2020

    2020

  3. [3]

    Good-caselatencyofbyzantine broadcast: A complete categorization

    IttaiAbraham, KartikNayak, LingRen, andZhuolunXiang. Good-caselatencyofbyzantine broadcast: A complete categorization. InProceedings of the 2021 ACM Symposium on Principles of Distributed Computing, pages 331–341, 2021

    2021

  4. [4]

    Malicious security comes for free in consensus with leaders

    Mark Abspoel, Thomas Attema, and Matthieu Rambaud. Malicious security comes for free in consensus with leaders. Cryptology ePrint Archive, 2020

    2020

  5. [5]

    Succinct erasure coding proof systems.Cryptology ePrint Archive, 2021

    Nicolas Alhaddad, Sisi Duan, Mayank Varia, and Haibin Zhang. Succinct erasure coding proof systems.Cryptology ePrint Archive, 2021

    2021

  6. [6]

    Shoal++: High throughput DAG BFT can be fast!arXiv preprint arXiv:2405.20488, 2024

    Balaji Arun, Zekun Li, Florian Suri-Payer, Sourav Das, and Alexander Spiegelman. Shoal++: High throughput DAG BFT can be fast!arXiv preprint arXiv:2405.20488, 2024

    Pith/arXiv arXiv 2024

  7. [7]

    Mysticeti: Reaching the limits of latency with uncertified dags.arXiv preprint arXiv:2310.14821, 2023

    Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris- Kogias, Arun Koshy, Alberto Sonnino, and Mingwei Tian. Mysticeti: Reaching the limits of latency with uncertified dags.arXiv preprint arXiv:2310.14821, 2023

    arXiv 2023

  8. [8]

    Cadence: Extreme pipelining with multiple concurrent proposers.arXiv preprint arXiv:2607.02275, 2026

    Kushal Babel, Fatima Elsheimy, Lioba Heimbach, Mohammad Mussadiq Jalalzai, Tobias Klenze, JovanKomatovic, JasonMilionis, MikeSetrin, andVictorShoup. Cadence: Extreme pipelining with multiple concurrent proposers.arXiv preprint arXiv:2607.02275, 2026

    Pith/arXiv arXiv 2026

  9. [9]

    The Swirlds hashgraph consensus algorithm: Fair, fast, Byzantine fault tolerance

    Leemon Baird. The Swirlds hashgraph consensus algorithm: Fair, fast, Byzantine fault tolerance. Technical report, Swirlds Tech Report SWIRLDS-TR-2016-01, 2016

    2016

  10. [10]

    Aggregate and verifiably en- crypted signatures from bilinear maps

    Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Aggregate and verifiably en- crypted signatures from bilinear maps. InAdvances in Cryptology—EUROCRYPT 2003. Springer, 2003

    2003

  11. [11]

    Short signatures from the weil pairing

    Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pairing. InIn- ternational conference on the theory and application of cryptology and information security, pages 514–532. Springer, 2001

    2001

  12. [12]

    Asynchronous Byzantine agreement protocols.Information and Computa- tion, 75(2):130–143, 1987

    Gabriel Bracha. Asynchronous Byzantine agreement protocols.Information and Computa- tion, 75(2):130–143, 1987. 51

    1987

  13. [13]

    Consensus in one communication step

    Francisco Brasileiro, Fabíola Greve, Achour Mostéfaoui, and Michel Raynal. Consensus in one communication step. InInternational Conference on Parallel Computing Technologies, pages 42–50. Springer, 2001

    2001

  14. [14]

    PhD thesis, 2016

    Ethan Buchman.Tendermint: Byzantine fault tolerance in the age of blockchains. PhD thesis, 2016

    2016

  15. [15]

    The latest gossip on bft consensus.arXiv preprint arXiv:1807.04938, 2018

    Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on bft consensus.arXiv preprint arXiv:1807.04938, 2018

    Pith/arXiv arXiv 2018

  16. [16]

    Casper the friendly finality gadget.arXiv preprint arXiv:1710.09437, 2017

    Vitalik Buterin and Virgil Griffith. Casper the friendly finality gadget.arXiv preprint arXiv:1710.09437, 2017

    Pith/arXiv arXiv 2017

  17. [17]

    Asynchronous verifiable information dispersal

    Christian Cachin and Stefano Tessaro. Asynchronous verifiable information dispersal. In 24th IEEE Symposium on Reliable Distributed Systems (SRDS’05), pages 191–201. IEEE, 2005

    2005

  18. [18]

    Practical byzantine fault tolerance

    Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. InOSDI, volume 99, pages 173–186, 1999

    1999

  19. [19]

    Practical byzantine fault tolerance and proactive recov- ery.ACM Transactions on Computer Systems (TOCS), 20(4):398–461, 2002

    Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance and proactive recov- ery.ACM Transactions on Computer Systems (TOCS), 20(4):398–461, 2002

    2002

  20. [20]

    Simplex consensus: A simple and fast consensus proto- col

    Benjamin Y Chan and Rafael Pass. Simplex consensus: A simple and fast consensus proto- col. InTheory of Cryptography Conference, pages 452–479. Springer, 2023

    2023

  21. [21]

    Minimmit: Fastfinality with even faster blocks.arXiv preprint arXiv:2508.10862, 2025

    BrendanKobayashiChou, AndrewLewis-Pye, andPatrickO’Grady. Minimmit: Fastfinality with even faster blocks.arXiv preprint arXiv:2508.10862, 2025

    arXiv 2025

  22. [22]

    Be aware of your leaders

    Shir Cohen, Rati Gelashvili, Lefteris Kokoris-Kogias, Zekun Li, Dahlia Malkhi, Alberto Sonnino, and Alexander Spiegelman. Be aware of your leaders. InInternational Conference on Financial Cryptography and Data Security. Springer, 2022

    2022

  23. [23]

    Nar- whal and tusk: a dag-based mempool and efficient bft consensus

    George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. Nar- whal and tusk: a dag-based mempool and efficient bft consensus. InProceedings of the Seventeenth European Conference on Computer Systems, pages 34–50, 2022

    2022

  24. [24]

    Moonshot: Optimizing chain-based rotating leader bft via optimistic proposals.arXiv preprint arXiv:2401.01791, 2024

    Isaac Doidge, Raghavendra Ramesh, Nibesh Shrestha, and Joshua Tobkin. Moonshot: Optimizing chain-based rotating leader bft via optimistic proposals.arXiv preprint arXiv:2401.01791, 2024

    Pith/arXiv arXiv 2024

  25. [25]

    Lynch, and Larry Stockmeyer

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

    1988

  26. [26]

    Chonkybft: Consensus protocol of zksync.arXiv preprint arXiv:2503.15380, 2025

    Bruno França, Denis Kolegov, Igor Konnov, and Grzegorz Prusak. Chonkybft: Consensus protocol of zksync.arXiv preprint arXiv:2503.15380, 2025

    Pith/arXiv arXiv 2025

  27. [27]

    Simple and efficient oracle-based consensus protocols for asynchronous byzantine systems.IEEE Transactions on Dependable and Secure Computing, 2(1):46–56, 2005

    Roy Friedman, Achour Mostefaoui, and Michel Raynal. Simple and efficient oracle-based consensus protocols for asynchronous byzantine systems.IEEE Transactions on Dependable and Secure Computing, 2(1):46–56, 2005. 52

    2005

  28. [28]

    Aleph: A leaderless, asynchronous, byzantine fault toler- ant consensus protocol.arXiv preprint arXiv:1810.05256, 2018

    Adam Gągol and Michał Świętek. Aleph: A leaderless, asynchronous, byzantine fault toler- ant consensus protocol.arXiv preprint arXiv:1810.05256, 2018

    Pith/arXiv arXiv 2018

  29. [29]

    Jolteon and Ditto: Network-adaptive efficient consensus with asyn- chronous fallback

    Rati Gelashvili, Lefteris Kokoris-Kogias, Alberto Sonnino, Alexander Spiegelman, and Zhuolun Xiang. Jolteon and Ditto: Network-adaptive efficient consensus with asyn- chronous fallback. InInternational Conference on Financial Cryptography and Data Se- curity. Springer, 2022

    2022

  30. [30]

    No- commit proofs: Defeating livelock in BFT

    Neil Giridharan, Heidi Howard, Ittai Abraham, Natacha Crooks, and Alin Tomescu. No- commit proofs: Defeating livelock in BFT. Cryptology ePrint Archive, 2021

    2021

  31. [31]

    Autobahn: Seamless high speed bft

    Neil Giridharan, Florian Suri-Payer, Ittai Abraham, Lorenzo Alvisi, and Natacha Crooks. Autobahn: Seamless high speed bft. InProceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles, pages 1–23, 2024

    2024

  32. [32]

    Refined quorum systems

    Rachid Guerraoui and Marko Vukolić. Refined quorum systems. InProceedings of the twenty-sixth annual ACM symposium on Principles of distributed computing, pages 119– 128, 2007

    2007

  33. [33]

    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 dependable systems and networks (DSN), pages 568–580. IEEE, 2019

    2019

  34. [34]

    Fast-HotStuff: A fast and robust BFT protocol for blockchains.IEEE Transactions on Dependable and Secure Computing, 2023

    Mohammad M Jalalzai, Jianyu Niu, Chen Feng, and Fangyu Gai. Fast-HotStuff: A fast and robust BFT protocol for blockchains.IEEE Transactions on Dependable and Secure Computing, 2023

    2023

  35. [35]

    HotStuff-1: Linear consensus with one-phase speculation.arXiv preprint arXiv:2408.04728, 2024

    Dakai Kang, Suyash Gupta, Dahlia Malkhi, and Mohammad Sadoghi. HotStuff-1: Linear consensus with one-phase speculation.arXiv preprint arXiv:2408.04728, 2024

    Pith/arXiv arXiv 2024

  36. [36]

    All you need is dag

    Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman. All you need is dag. InProceedings of the 2021 ACM Symposium on Principles of Distributed Computing, pages 165–175, 2021

    2021

  37. [37]

    Cordial miners: Fast and efficient consensus for every eventuality.arXiv preprint arXiv:2205.09174, 2022

    Idit Keidar, Oded Naor, Ouri Poupko, and Ehud Shapiro. Cordial miners: Fast and efficient consensus for every eventuality.arXiv preprint arXiv:2205.09174, 2022

    Pith/arXiv arXiv 2022

  38. [38]

    Solana alpenglow consensus

    Quentin Kniep, Jakub Sliwinski, and Roger Wattenhofer. Solana alpenglow consensus. https: // www. scribd. com/ document/ 895233790/ Solana-Alpenglow-White-Paper, 2025

    2025

  39. [39]

    Zyzzyva: speculative byzantine fault tolerance

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. Zyzzyva: speculative byzantine fault tolerance. InProceedings of twenty-first ACM SIGOPS symposium on Operating systems principles, pages 45–58, 2007

    2007

  40. [40]

    Optimistic byzantine agreement

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

    2002

  41. [41]

    Revisiting optimal resilience of fast byzantine consensus

    Petr Kuznetsov, Andrei Tonkikh, and Yan X Zhang. Revisiting optimal resilience of fast byzantine consensus. InProceedings of the 2021 ACM Symposium on Principles of Dis- tributed Computing, pages 343–353, 2021. 53

    2021

  42. [42]

    Thebyzantinegeneralsproblem.ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982

    LeslieLamport, RobertShostak, andMarshallPease. Thebyzantinegeneralsproblem.ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982

    1982

  43. [43]

    Lumiere: Makingoptimal bft for partial synchrony practical

    AndrewLewis-Pye, DahliaMalkhi, OdedNaor, andKartikNayak. Lumiere: Makingoptimal bft for partial synchrony practical. InProceedings of the 43rd ACM Symposium on Principles of Distributed Computing, pages 135–144, 2024

    2024

  44. [44]

    The pipes model for latency anal- ysis.Cryptology ePrint Archive, 2025

    Andrew Lewis-Pye, Kartik Nayak, and Nibesh Shrestha. The pipes model for latency anal- ysis.Cryptology ePrint Archive, 2025

    2025

  45. [45]

    The Carnot bound: Limits and possibilities for bandwidth-efficient consensus.arXiv preprint arXiv:2603.11797, 2026

    Andrew Lewis-Pye and Patrick O’Grady. The Carnot bound: Limits and possibilities for bandwidth-efficient consensus.arXiv preprint arXiv:2603.11797, 2026

    Pith/arXiv arXiv 2026

  46. [46]

    Permissionless consensus.arXiv preprint arXiv:2304.14701, 2023

    Andrew Lewis-Pye and Tim Roughgarden. Permissionless consensus.arXiv preprint arXiv:2304.14701, 2023

    Pith/arXiv arXiv 2023

  47. [47]

    Beyond optimal fault tolerance.arXiv preprint arXiv:2501.06044, 2025

    Andrew Lewis-Pye and Tim Roughgarden. Beyond optimal fault tolerance.arXiv preprint arXiv:2501.06044, 2025

    Pith/arXiv arXiv 2025

  48. [48]

    Morpheus consensus: Excelling on trails and auto- bahns.arXiv preprint arXiv:2502.08465, 2025

    Andrew Lewis-Pye and Ehud Shapiro. Morpheus consensus: Excelling on trails and auto- bahns.arXiv preprint arXiv:2502.08465, 2025

    arXiv 2025

  49. [49]

    Fast and secure global payments with Stellar

    Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, and Jed McCaleb. Fast and secure global payments with Stellar. InProceedings of the 27th ACM Symposium on Operating Systems Principles, 2019

    2019

  50. [50]

    Flexible Byzantine fault tolerance

    Dahlia Malkhi, Kartik Nayak, and Ling Ren. Flexible Byzantine fault tolerance. InPro- ceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019

    2019

  51. [51]

    BBCA-chain: One-message, low latency BFT consensus on a DAG.arXiv preprint arXiv:2310.06335, 2023

    Dahlia Malkhi, Chrysoula Stathakopoulou, and Maofan Yin. BBCA-chain: One-message, low latency BFT consensus on a DAG.arXiv preprint arXiv:2310.06335, 2023

    Pith/arXiv arXiv 2023

  52. [52]

    Fast byzantine consensus.IEEE Transactions on Dependable and Secure Computing, 3(3):202–215, 2006

    J-P Martin and Lorenzo Alvisi. Fast byzantine consensus.IEEE Transactions on Dependable and Secure Computing, 3(3):202–215, 2006

    2006

  53. [53]

    Multi-threshold Byzantine fault tolerance

    Atsuki Momose and Ling Ren. Multi-threshold Byzantine fault tolerance. InProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021

    2021

  54. [54]

    Kauri: Scalable BFT consensus with pipelined tree-based dissemination and aggregation

    Ray Neiheiser, Miguel Matos, and Luís Rodrigues. Kauri: Scalable BFT consensus with pipelined tree-based dissemination and aggregation. InProceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles, 2021

    2021

  55. [55]

    Ebb-and-flow protocols: A resolution of the availability-finality dilemma

    Joachim Neu, Ertem Nusret Tas, and David Tse. Ebb-and-flow protocols: A resolution of the availability-finality dilemma. In2021 IEEE Symposium on Security and Privacy (SP), pages 446–465. IEEE, 2021

    2021

  56. [56]

    Thunderella: Blockchains with optimistic instant confirmation

    Rafael Pass and Elaine Shi. Thunderella: Blockchains with optimistic instant confirmation. InAdvances in Cryptology–EUROCRYPT 2018: 37th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Tel Aviv, Israel, April 29-May 3, 2018 Proceedings, Part II 37, pages 3–33. Springer, 2018. 54

    2018

  57. [57]

    Implementing fault-tolerant services using the state machine approach: A tutorial.ACM Computing Surveys (CSUR), 22(4):299–319, 1990

    Fred B Schneider. Implementing fault-tolerant services using the state machine approach: A tutorial.ACM Computing Surveys (CSUR), 22(4):299–319, 1990

    1990

  58. [58]

    Practical threshold signatures

    Victor Shoup. Practical threshold signatures. InInternational conference on the theory and applications of cryptographic techniques, pages 207–220. Springer, 2000

    2000

  59. [59]

    Sing a song of simplex.Cryptology ePrint Archive, 2023

    Victor Shoup. Sing a song of simplex.Cryptology ePrint Archive, 2023

    2023

  60. [60]

    Kudzu: Fast and simple high- throughput bft.arXiv preprint arXiv:2505.08771, 2025

    Victor Shoup, Jakub Sliwinski, and Yann Vonlanthen. Kudzu: Fast and simple high- throughput bft.arXiv preprint arXiv:2505.08771, 2025

    arXiv 2025

  61. [61]

    Hydrangea++: Enhancing hydrangea with optimistic proposals

    Nibesh Shrestha and Aniket Kate. Hydrangea++: Enhancing hydrangea with optimistic proposals. 2025

    2025

  62. [62]

    Hydrangea: Optimistic two-round partial synchrony with improved fault resilience.Cryptology ePrint Archive, 2025

    Nibesh Shrestha, Aniket Kate, and Kartik Nayak. Hydrangea: Optimistic two-round partial synchrony with improved fault resilience.Cryptology ePrint Archive, 2025

    2025

  63. [63]

    Sailfish: Towards improving the latency of dag-based bft

    Nibesh Shrestha, Rohan Shrothrium, Aniket Kate, and Kartik Nayak. Sailfish: Towards improving the latency of dag-based bft. In2025 IEEE Symposium on Security and Privacy (SP), pages 1928–1946. IEEE, 2025

    1928

  64. [64]

    Bosco: One-step byzantine asynchronous con- sensus

    Yee Jiun Song and Robbert Van Renesse. Bosco: One-step byzantine asynchronous con- sensus. InInternational Symposium on Distributed Computing, pages 438–450. Springer, 2008

    2008

  65. [65]

    Shoal: Improving dag- bft latency and robustness

    Alexander Spiegelman, Balaji Arun, Rati Gelashvili, and Zekun Li. Shoal: Improving dag- bft latency and robustness. InInternational Conference on Financial Cryptography and Data Security, pages 92–109. Springer, 2024

    2024

  66. [66]

    Quorum Store: How consensus horizontally scales on the Aptos blockchain

    Alexander Spiegelman and Brian Cho. Quorum Store: How consensus horizontally scales on the Aptos blockchain. Aptos Labs blog,https://medium.com/aptoslabs, 2023

    2023

  67. [67]

    Bull- shark: Dag bft protocols made practical

    Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris Kokoris-Kogias. Bull- shark: Dag bft protocols made practical. InProceedings of the 2022 ACM SIGSAC Confer- ence on Computer and Communications Security, pages 2705–2718, 2022

    2022

  68. [68]

    Mir-BFT: High-throughput BFT for blockchains.arXiv preprint arXiv:1906.05552, 2019

    Chrysoula Stathakopoulou, Tudor David, and Marko Vukolić. Mir-BFT: High-throughput BFT for blockchains.arXiv preprint arXiv:1906.05552, 2019

    Pith/arXiv arXiv 1906

  69. [69]

    Marlin: Two-phase BFT with linearity

    Xiao Sui, Sisi Duan, and Haibin Zhang. Marlin: Two-phase BFT with linearity. In2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2022

    2022

  70. [70]

    Raptr: Prefix consensus for robust high-performance bft.arXiv preprint arXiv:2504.18649, 2025

    Andrei Tonkikh, Balaji Arun, Zhuolun Xiang, Zekun Li, and Alexander Spiegelman. Raptr: Prefix consensus for robust high-performance bft.arXiv preprint arXiv:2504.18649, 2025

    Pith/arXiv arXiv 2025

  71. [71]

    Odontoceti: Ultra-fast DAG consensus with two round commitment

    Preston Vander Vos. Odontoceti: Ultra-fast DAG consensus with two round commitment. arXiv preprint arXiv:2510.01216, 2025

    arXiv 2025

  72. [72]

    Banyan: Fast rotating leader bft

    Yann Vonlanthen, Jakub Sliwinski, Massimo Albarello, and Roger Wattenhofer. Banyan: Fast rotating leader bft. InProceedings of the 25th International Middleware Conference, pages 494–507, 2024. 55

    2024

  73. [73]

    Bluebottle: Fast and robust blockchains through subsystem specialization

    Preston Vander Vos, Alberto Sonnino, Giorgos Tsimos, Philipp Jovanovic, and Lefteris Kokoris-Kogias. Bluebottle: Fast and robust blockchains through subsystem specialization. arXiv preprint arXiv:2511.15361, 2025

    Pith/arXiv arXiv 2025

  74. [74]

    Strengthened fault tolerance in Byzantine fault tolerant replication

    Zhuolun Xiang, Dahlia Malkhi, Kartik Nayak, and Ling Ren. Strengthened fault tolerance in Byzantine fault tolerant replication. In2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS). IEEE, 2021

    2021

  75. [75]

    Fides: Scalable censorship-resistant DAG consensus via trusted components.arXiv preprint arXiv:2501.01062, 2025

    Shaokang Xie, Dakai Kang, Hanzheng Lyu, Jianyu Niu, and Mohammad Sadoghi. Fides: Scalable censorship-resistant DAG consensus via trusted components.arXiv preprint arXiv:2501.01062, 2025

    Pith/arXiv arXiv 2025

  76. [76]

    Dispers- edLedger: High-throughput Byzantine consensus on variable bandwidth networks

    Lei Yang, Seo Jin Park, Mohammad Alizadeh, Sreeram Kannan, and David Tse. Dispers- edLedger: High-throughput Byzantine consensus on variable bandwidth networks. In19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), 2022

    2022

  77. [77]

    Hotstuff: Bft consensus with linearity and responsiveness

    Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abraham. Hotstuff: Bft consensus with linearity and responsiveness. InProceedings of the 2019 ACM Symposium on Principles of Distributed Computing, pages 347–356, 2019. 56

    2019