pith. sign in

arxiv: 2607.02275 · v1 · pith:X4XX4QEOnew · submitted 2026-07-02 · 💻 cs.DC

Cadence: Extreme Pipelining with Multiple Concurrent Proposers

Fatima Elsheimy , Mohammad Mussadiq Jalalzai , Tobias Klenze , Jovan Komatovic , Mike Setrin , Victor Shoup , Kushal Babel , Lioba Heimbach
show 1 more author
Jason Milionis
This is my paper

Pith reviewed 2026-07-03 05:49 UTC · model grok-4.3

classification 💻 cs.DC
keywords Byzantine fault tolerancemulti-proposer consensusextreme pipeliningcensorship resistanceconsensus protocolpartial synchronyoptimal resilienceblockchain consensus
0
0 comments X

The pith

Cadence achieves short-term censorship resistance and hiding at the fast-path latency of single-leader consensus using extreme pipelining and multiple concurrent proposers.

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

The paper presents Cadence as a Byzantine fault-tolerant consensus protocol that divides time into slots, with each slot producing one block via its own independent consensus instance. Multiple concurrent proposers per slot ensure that a transaction included by any correct proposer cannot be censored or deferred under synchrony, and that proposals cannot be crafted reactively to others. Extreme pipelining runs these instances without blocks depending on prior completions or propagations, decoupling the block interval from network latency. A general framework converts any one-shot consensus meeting the slot-consensus specification into this multi-shot form, instantiated here with Chorus for three-round fast-path finalization and Conductor for slot management. The work proves safety, liveness, censorship resistance, and hiding under partial synchrony with optimal resilience of n equals 3f plus 1, and reports simulation results of 219 ms average finalization over 200 validators.

Core claim

Cadence divides time into equally spaced slots, one block per slot, each finalized in its own consensus instance. Blocks do not build directly on their predecessor, so instances run independently and none waits for an earlier block to finish or propagate. Cadence also removes the single-leader monopoly over transaction inclusion and ordering: under multiple concurrent proposers, several validators propose for each block, and it guarantees that, under synchrony, a transaction a correct proposer includes cannot be censored or deferred, and that no proposer can craft its proposal in reaction to the others. To realize extreme pipelining, the paper introduces a general framework that turns any on

What carries the argument

Extreme pipelining, which decouples block intervals from network latency by running independent consensus instances per slot without predecessor dependencies, combined with the multi-proposer mechanism that enforces short-term censorship resistance and hiding.

If this is right

  • Block intervals can be set arbitrarily low because each slot's consensus runs independently without waiting for prior blocks to propagate or finalize.
  • Under synchrony, any transaction included by a correct proposer receives short-term protection from censorship or deferral.
  • No proposer can observe or react to other proposals when crafting its own, due to the hiding guarantee.
  • Fast-path finalization occurs in three communication rounds, with speculative finality one round earlier, at optimal resilience.
  • The orchestrator keeps the number of open slots bounded even when the network is asynchronous.

Where Pith is reading between the lines

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

  • The decoupling of block intervals could support sustained high throughput in validator sets larger than the simulated 200 without proportional latency increases.
  • The hiding property might be verified in practice by checking whether proposers can still coordinate reactions in controlled synchronous testbeds.
  • Similar frameworks for converting one-shot protocols could extend to other multi-shot settings where independence between instances is required.
  • The reported 50 ms average transaction wait time at 100 ms intervals indicates a potential reduction in user-perceived delay compared to leader-based systems.

Load-bearing premise

The general framework that converts any one-shot consensus satisfying the slot-consensus specification into a multi-shot protocol preserves independence of instances and does not introduce hidden dependencies or latency that would couple block intervals back to network delays.

What would settle it

An execution under synchrony in which a transaction included by a correct proposer is excluded from the finalized block for that slot, or a measurement showing finalization latency exceeding three rounds on the fast path under partial synchrony with n equals 3f plus 1.

Figures

Figures reproduced from arXiv: 2607.02275 by Fatima Elsheimy, Jason Milionis, Jovan Komatovic, Kushal Babel, Lioba Heimbach, Mike Setrin, Mohammad Mussadiq Jalalzai, Tobias Klenze, Victor Shoup.

Figure 1
Figure 1. Figure 1: Cadence architecture. In normal operation, Conductor schedules consecutive slot deadlines τ apart. Each deadline belongs to an independent single-shot Chorus instance. Here every slot has three concurrent proposers; on finalizing, the slot emits one slot-numbered block that merges the proposals it includes. In slot s+1 the last proposer disseminates only partially (dotted), forcing the slower fallback path… view at source ↗
Figure 2
Figure 2. Figure 2: The MCP problem and its five guarantees. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: The slot consensus primitive for a slot s: its interface and its guarantees. The slot’s proposers submit their proposals as input (violet arrows), and every validator eventually finalizes a block for the slot as output (green arrows). 3.2 Orchestrator While slot consensus looks at one slot in isolation, the orchestrator spans all of them. Its responsibility is to schedule the slots, that is, to determine t… view at source ↗
Figure 4
Figure 4. Figure 4: The orchestrator primitive: its interface and its guarantees. Validators notify the orchestrator that [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Our framework as the composition of its two building blocks: a single orchestrator, and one slot [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: From a plaintext proposal to its Merkle root, step by step. [PITH_FULL_IMAGE:figures/full_fig_p011_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: A meta-block, the object Chorus agrees on. Once it is agreed upon, the slot’s block follows with no further agreement: each validator independently recovers the proposal behind every positive entry (discarding any invalidly encoded one) and assembles them into the same well-defined block (see Section 4.4). 4.2 Fast Path The fast path of Chorus follows the familiar structure of single-leader consensus, in w… view at source ↗
Figure 8
Figure 8. Figure 8: The Chorus fast path for a slot with two proposers p1 and p2 (n = 4, f = 1). Proposer p1 disseminates its (encrypted) proposal as one chunk per validator (orange), while p2 stays silent (gray, dashed). At deadline D, each validator broadcasts one vote per proposer (blue, dashed), ⟨yes, r1⟩ for p1 and ⟨no⟩ for p2, carrying along the chunk it received (small squares) and its decryption share (diamonds). On 2… view at source ↗
Figure 9
Figure 9. Figure 9: The Chorus fallback path (n = 4, f = 1). Each validator broadcasts either a fast vote (see Section 4.2) or, failing that, a no-fast-vote together with a per-proposer fallback-yes/fallback￾no vote (violet, dashed). It then proposes a meta-block (fast or fallback; orange) to the slot’s single black-box fallback agreement, which finalizes one (green) as the slot’s. 4.4 From Meta-Blocks to Proposals (and Hence… view at source ↗
Figure 10
Figure 10. Figure 10: Recovering the proposals from a (fast or fallback) meta-block. [PITH_FULL_IMAGE:figures/full_fig_p016_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: How a single validator pi computes its proposed deadline for window 2’s first slot (W = 3, p = 2). Healthy (top): no gap; lagging (bottom): gap exists. Note that different correct validators may complete the first p slots at slightly different times, and so arrive at different proposed deadlines for window 2; they must nonetheless agree on a single one. To this end, the validators feed their proposed dead… view at source ↗
Figure 12
Figure 12. Figure 12: How validators agree on the deadline (n = 4, f = 1; p4 Byzantine). An ACS instance delivers all correct validators the same vector of 2f+1 proposed deadlines, of which each correct validator takes the median as the agreed deadline e2. Since at most f entries are Byzantine, the median always lies between the smallest and largest honest proposed deadline in the common vector. 18 [PITH_FULL_IMAGE:figures/fu… view at source ↗
Figure 13
Figure 13. Figure 13: Scheduling the next window inside a “good” (post-GST) window. By time [PITH_FULL_IMAGE:figures/full_fig_p019_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Interaction between the orchestrator O and slot consensus instances S[·] in the extreme-pipelining framework (Algorithm 1). Teal solid arrows: O outputs open(s), upon which the framework invokes participate() on S[s] (and propose(·) if pi ∈ s.proposers). Implicit skip (slot s3): the orchestrator has no “skip” output, so a slot is skipped simply by never being opened — no open(s3) is issued, no slot consen… view at source ↗
read the original abstract

We present Cadence, a Byzantine fault-tolerant multi-proposer consensus protocol with arbitrarily low block intervals, optimal resilience, and optimal fast-path latency. Cadence divides time into equally spaced slots, one block per slot, each finalized in its own consensus instance. Blocks do not build directly on their predecessor, so instances run independently and none waits for an earlier block to finish or propagate; we call this extreme pipelining, decoupling the block interval from network latency. Cadence also removes the single-leader monopoly over transaction inclusion and ordering: under multiple concurrent proposers (MCP), several validators propose for each block, and it guarantees that, under synchrony, a transaction a correct proposer includes cannot be censored or deferred (short-term censorship resistance), and that no proposer can craft its proposal in reaction to the others' (hiding). To realize extreme pipelining, we introduce a general framework that turns any one-shot consensus meeting our slot-consensus specification into a multi-shot protocol. We instantiate it for MCP with two protocols of our own: Chorus, a slot consensus whose fast path finalizes a block in an optimal three rounds, with speculative finality one round earlier, and Conductor, an orchestrator that opens slots at an even cadence, more slowly under asynchrony to keep open slots bounded. To our knowledge, Cadence is the first MCP protocol to provide short-term censorship resistance and hiding at the fast-path latency of single-leader consensus. We prove safety, liveness, censorship resistance, and hiding under partial synchrony with optimal resilience (n = 3f+1). In simulation over Monad's 200 validators with five proposers per slot, finalization averages 219 ms (167 ms to speculative finality); at a 100 ms block interval a transaction waits on average 50 ms to enter a proposal.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The paper presents Cadence, a Byzantine fault-tolerant multi-proposer consensus protocol that achieves arbitrarily low block intervals via extreme pipelining: time is divided into slots with one block per slot, each finalized in an independent consensus instance that does not build directly on its predecessor. It introduces a general framework converting any one-shot consensus meeting a slot-consensus specification into a multi-shot protocol, instantiated via Chorus (three-round fast path with speculative finality) and Conductor (slot orchestrator). Cadence claims short-term censorship resistance and hiding under synchrony, with proofs of safety, liveness, censorship resistance, and hiding under partial synchrony at optimal resilience (n=3f+1). Simulations on 200 validators with five proposers per slot report average finalization of 219 ms (167 ms speculative) and 50 ms average wait at 100 ms intervals.

Significance. If the central claims hold, the work would be significant for distributed consensus, as the first MCP protocol to deliver short-term censorship resistance and hiding at single-leader fast-path latency while decoupling block interval from network latency. The general framework for one-shot to multi-shot conversion, the proofs under partial synchrony, and the reproducible simulation results on a realistic validator count are explicit strengths that would strengthen the contribution if the independence preservation is verified.

major comments (1)
  1. [Abstract] Abstract (description of the general framework): the claim that the framework 'preserves independence of instances and does not introduce hidden dependencies or latency that would couple block intervals back to network delays' is load-bearing for the extreme pipelining and 'first MCP protocol' claims, yet the abstract provides no slot-consensus specification, conversion steps, or proof sketch; any violation of independence would directly undermine the decoupling from network latency.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for their thoughtful review and for highlighting the importance of clearly substantiating the general framework's independence claim in the abstract. We address the major comment below.

read point-by-point responses

  1. Referee: [Abstract] Abstract (description of the general framework): the claim that the framework 'preserves independence of instances and does not introduce hidden dependencies or latency that would couple block intervals back to network delays' is load-bearing for the extreme pipelining and 'first MCP protocol' claims, yet the abstract provides no slot-consensus specification, conversion steps, or proof sketch; any violation of independence would directly undermine the decoupling from network latency.

    Authors: We agree that the abstract, as a high-level summary, does not include sufficient detail on the slot-consensus specification or conversion steps to fully support the independence claim on its own. The full specification, conversion procedure, and formal proof of independence (showing no hidden dependencies or latency coupling) appear in Sections 3 and 4 of the manuscript. To address this, we will revise the abstract to concisely reference the slot-consensus specification and state that the framework preserves instance independence as proven in the body, thereby strengthening the presentation of the extreme-pipelining contribution without altering the underlying claims. revision: yes

Circularity Check

0 steps flagged

No circularity; protocol constructed from independent components

full rationale

The paper introduces a general framework to convert one-shot slot-consensus instances into a multi-shot protocol with extreme pipelining, instantiated via Chorus (three-round fast path) and Conductor (slot orchestration). Independence of instances, censorship resistance, and hiding are asserted as design properties of this construction under partial synchrony and n=3f+1, with proofs claimed but not reduced to self-referential equations or prior self-citations in the provided text. No load-bearing step equates a claimed prediction or uniqueness result to its own inputs by construction; external network assumptions and the slot-consensus specification provide the separation. This is the normal case of a self-contained protocol description.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The protocol rests on standard BFT network and fault assumptions plus the new slot-consensus framework; no free parameters or invented entities are described in the abstract.

axioms (2)
  • domain assumption Partial synchrony: after some unknown global stabilization time, messages are delivered within a known bound
    Invoked for the liveness and censorship-resistance proofs under partial synchrony.
  • domain assumption Optimal resilience bound n = 3f + 1 with at most f Byzantine faults
    Stated as the resilience achieved by the protocol.

pith-pipeline@v0.9.1-grok · 5905 in / 1453 out tokens · 29963 ms · 2026-07-03T05:49:49.390287+00:00 · methodology

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

39 extracted references · 4 canonical work pages · 1 internal anchor

  1. [1]

    Multiple Concurrent Proposers: Why and How.CoRR, abs/2509.23984, 2025

    Pranav Garimidi, Joachim Neu, and Max Resnick. Multiple Concurrent Proposers: Why and How.CoRR, abs/2509.23984, 2025

    work page arXiv 2025

  2. [2]

    Automated market making and arbitrage profits in the presence of fees

    Jason Milionis, Ciamac C Moallemi, and Tim Roughgarden. Automated market making and arbitrage profits in the presence of fees. InInternational Conference on Financial Cryptography and Data Security, pages 159–171. Springer, 2024

    2024

  3. [3]

    Constellation

    Anza. Constellation. White Paper v0.9,https://anza.xyz/constellationwhitepaper, March 2026. Ac- cessed: June 2026

    2026

  4. [4]

    Separating agreement from execution for byzantine fault tolerant services

    Jian Yin, Jean-Philippe Martin, Arun Venkataramani, Lorenzo Alvisi, and Mike Dahlin. Separating agreement from execution for byzantine fault tolerant services. InProceedings of the Nineteenth ACM Symposium on Operating Systems Principles, SOSP ’03, page 253–267, New York, NY, USA, 2003. Association for Computing Machinery

    2003

  5. [5]

    Sing a song of simplex

    Victor Shoup. Sing a song of simplex. In38th International Symposium on Distributed Computing (DISC 2024), volume 319 ofLIPIcs, pages 37:1–37:22, 2024

    2024

  6. [6]

    Impossibility of Distributed Consensus with One Faulty Process.Journal of the ACM (JACM), 32(2):374–382, 1985

    Michael J Fischer, Nancy A Lynch, and Michael S Paterson. Impossibility of Distributed Consensus with One Faulty Process.Journal of the ACM (JACM), 32(2):374–382, 1985

    1985

  7. [7]

    A New Broadcast Primitive for BFT Protocols

    Manu Drijvers, Tim Gretler, Yotam Harchol, Tobias Klenze, Ognjen Maric, Stefan Neamtu, Yvonne-Anne Pig- nolet, Rostislav Rumenov, Daniel Sharifi, and Victor Shoup. A New Broadcast Primitive for BFT Protocols. CoRR, abs/2410.22080, 2024

    work page arXiv 2024

  8. [8]

    Practical Byzantine fault tolerance

    Miguel Castro and Barbara Liskov. Practical Byzantine fault tolerance. InProceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI ’99, pages 173–186, Berkeley, CA, USA, 1999. USENIX Association

    1999

  9. [9]

    Reiter, Guy Golan Gueta, and Ittai Abraham

    Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham. Hotstuff: Bft consensus with linearity and responsiveness. InProceedings of the 2019 ACM PODC, PODC ’19, page 347–356, New York, NY, USA, 2019. Association for Computing Machinery

    2019

  10. [10]

    SBFT: a Scalable and Decentralized Trust Infrastructure

    Guy Golan-Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael K. Reiter, Dragos- Adrian Seredinschi, Orr Tamir, and Alin Tomescu. SBFT: a scalable decentralized trust infrastructure for blockchains.CoRR, abs/1804.01626, 2018

    work page internal anchor Pith review Pith/arXiv arXiv 2018

  11. [11]

    Jalalzai, Jianyu Niu, Chen Feng, and Fangyu Gai

    Mohammad M. Jalalzai, Jianyu Niu, Chen Feng, and Fangyu Gai. Fast-hotstuff: A fast and robust bft protocol for blockchains.IEEE Trans. Dependable Secur. Comput., 21(4):2478–2493, July 2024

    2024

  12. [12]

    Monadbft: Fast, responsive, fork-resistant streamlined consensus, 2026

    Mohammad Mussadiq Jalalzai, Kushal Babel, Jovan Komatovic, Tobias Klenze, Sourav Das, Fatima Elsheimy, Mike Setrin, John Bergschneider, and Babak Gilkalaye. Monadbft: Fast, responsive, fork-resistant streamlined consensus, 2026

    2026

  13. [13]

    Asynchronous verifiable information dispersal

    Christian Cachin and Stefano Tessaro. Asynchronous verifiable information dispersal. InProceedings of the 19th International Conference on Distributed Computing, DISC’05, page 503–504, Berlin, Heidelberg, 2005. Springer-Verlag

    2005

  14. [14]

    MIP-10: Deterministic RaptorCast

    Category Labs. MIP-10: Deterministic RaptorCast. Monad Improvement Proposals, no. 10, April 2026. Online serial. 25

    2026

  15. [15]

    Good-case latency of byzantine broadcast: a complete categorization

    Ittai Abraham, Kartik Nayak, Ling Ren, and Zhuolun Xiang. Good-case latency of byzantine broadcast: a complete categorization. In Avery Miller, Keren Censor-Hillel, and Janne H. Korhonen, editors,PODC ’21: ACM Symposium on Principles of Distributed Computing, Virtual Event, Italy, July 26-30, 2021, pages 331–341. ACM, 2021

    2021

  16. [16]

    Asynchronous execution.https://docs.monad.xyz/monad-arch/consensus/ asynchronous-execution

    Monad Foundation. Asynchronous execution.https://docs.monad.xyz/monad-arch/consensus/ asynchronous-execution. Online; accessed 2026-04-30

    2026

  17. [17]

    Monad initial specification proposal.https://category-labs.github.io/ category-research/monad-initial-spec-proposal.pdf

    Category Labs. Monad initial specification proposal.https://category-labs.github.io/ category-research/monad-initial-spec-proposal.pdf. Online; accessed 2026-06-07

    2026

  18. [18]

    Time is money: Strategic timing games in proof-of-stake protocols

    Caspar Schwarz-Schilling, Fahad Saleh, Thomas Thiery, Jennifer Pan, Nihar Shah, and Barnab´ e Monnot. Time is money: Strategic timing games in proof-of-stake protocols. In5th Conference on Advances in Financial Technologies (AFT 2023), volume 282 ofLeibniz International Proceedings in Informatics (LIPIcs), pages 30:1–30:17. Schloss Dagstuhl – Leibniz-Zent...

    2023

  19. [19]

    Timing games in responsive consensus protocols

    Kaya Alpturer, Kushal Babel, and Aditya Saraf. Timing games in responsive consensus protocols. arXiv:2510.25144,https://arxiv.org/abs/2510.25144, 2025

    work page arXiv 2025

  20. [20]

    Weighted batched threshold encryption with applications to mempool privacy

    Amit Agarwal, Kushal Babel, Sourav Das, Babak Poorebrahim Gilkalaye, Arup Mondal, Benny Pinkas, Peter Rindal, and Aayush Yadav. Weighted batched threshold encryption with applications to mempool privacy. IEEE SP, 2026

    2026

  21. [21]

    Btx: Simple and efficient batch threshold encryption.Cryptology ePrint Archive, 2026

    Amit Agarwal, Sourav Das, Babak Poorebrahim Gilkalaye, Peter Rindal, and Victor Shoup. Btx: Simple and efficient batch threshold encryption.Cryptology ePrint Archive, 2026

    2026

  22. [22]

    Beast-mev: Batched threshold encryption with silent setup for mev preven- tion.Cryptology ePrint Archive, 2025

    Jan Bormet, Arka Rai Choudhuri, Sebastian Faust, Sanjam Garg, Hussien Othman, Guru-Vamsi Policharla, Ziyan Qu, and Mingyuan Wang. Beast-mev: Batched threshold encryption with silent setup for mev preven- tion.Cryptology ePrint Archive, 2025

    2025

  23. [23]

    On the limits of encrypted mempools

    Pranav Garimidi, Joseph Bonneau, and Lioba Heimbach. On the limits of encrypted mempools. a16z Crypto Research, July 2025

    2025

  24. [24]

    Hotstuff-1: Linear consensus with one-phase speculation, 2024

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

    2024

  25. [25]

    Extended abstract: Hotstuff-2: Optimal two-phase responsive bft

    Dahlia Malkhi and Kartik Nayak. Extended abstract: Hotstuff-2: Optimal two-phase responsive bft. Cryp- tology ePrint Archive, Paper 2023/397, 2023.https://eprint.iacr.org/2023/397

    2023

  26. [26]

    Jolteon and ditto: Network-adaptive efficient consensus with asynchronous fallback, 2021

    Rati Gelashvili, Lefteris Kokoris-Kogias, Alberto Sonnino, Alexander Spiegelman, and Zhuolun Xiang. Jolteon and ditto: Network-adaptive efficient consensus with asynchronous fallback, 2021

    2021

  27. [27]

    Moonshot: Optimizing chain-based rotating leader bft via optimistic proposals, 2024

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

    2024

  28. [28]

    Hydrangea++: Enhancing hydrangea with optimistic proposals.https: //supra.com/documents/hydrangea-plus-plus.pdf, 2025

    Nibesh Shrestha and Aniket Kate. Hydrangea++: Enhancing hydrangea with optimistic proposals.https: //supra.com/documents/hydrangea-plus-plus.pdf, 2025

    2025

  29. [29]

    Shoal++: High through- put DAG BFT can be fast and robust! In22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI), pages 813–826

    Balaji Arun, Zekun Li, Florian Suri-Payer, Sourav Das, and Alexander Spiegelman. Shoal++: High through- put DAG BFT can be fast and robust! In22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI), pages 813–826. USENIX Association, 2025

    2025

  30. [30]

    Raptr: Prefix consensus for robust high-performance bft, 2025

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

    2025

  31. [31]

    Gatling: Rapid-fire consensus from parallel composition, 2026

    Giulia Scaffino, Max Resnick, and Joachim Neu. Gatling: Rapid-fire consensus from parallel composition, 2026

    2026

  32. [32]

    Prefix consensus for censorship resistant BFT, 2026

    Zhuolun Xiang, Andrei Tonkikh, and Alexander Spiegelman. Prefix consensus for censorship resistant BFT, 2026

    2026

  33. [33]

    AMP: Arc multi-proposer protocol with bounded inclusion guarantees, 2026

    Daniel Cason, Gordon Liao, Sergio Mena, Nenad Miloˇ sevi´ c, Adi Seredinschi, Alessandro Sforzin, Jo˜ ao Sousa, and Preston Vander Vos. AMP: Arc multi-proposer protocol with bounded inclusion guarantees, 2026

    2026

  34. [34]

    Solana alpenglow consensus, increased bandwidth, reduced latency

    Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer. Solana alpenglow consensus, increased bandwidth, reduced latency. 2025

    2025

  35. [35]

    Narwhal and tusk: A dag-based mempool and efficient bft consensus, 2022

    George Danezis, Eleftherios Kokoris Kogias, Alberto Sonnino, and Alexander Spiegelman. Narwhal and tusk: A dag-based mempool and efficient bft consensus, 2022

    2022

  36. [36]

    Bullshark: Dag bft protocols made practical

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

    2022

  37. [37]

    All you need is dag

    Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman. All you need is dag. In Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing, PODC’21, page 165–175, New York, NY, USA, 2021. Association for Computing Machinery

    2021

  38. [38]

    Mysticeti: Reaching the limits of latency with uncertified dags, 2024

    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, 2024

    2024

  39. [39]

    no proposal

    Ran Canetti. Universally Composable Security: A New Paradigm for Cryptographic Protocols. In42nd Annual Symposium on Foundations of Computer Science, FOCS 2001, Las Vegas, Nevada, USA, October 14-17, 2001, pages 136–145. IEEE Computer Society, 2001. 26 Organization of the Appendix This appendix gives the formal treatment underlying the body. It restates t...

    2001