Pith. sign in

REVIEW 2 major objections 5 minor 56 references

Cassandra lets Byzantine fault-tolerant replicas keep ordering transactions inside network partitions with weak certificates, then safely reconcile those provisional chains once connectivity returns.

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 →

T0 review · grok-4.5

2026-07-12 06:33 UTC pith:BIPBINNM

load-bearing objection Solid systems paper that actually delivers non-zero recoverable BFT progress under partitions where every baseline goes to zero, with standard proofs and thorough eval. the 2 major comments →

arxiv 2607.02856 v1 pith:BIPBINNM submitted 2026-07-03 cs.DC cs.DB

Cassandra: Consensus with Partial Progress via Robust Partitionable View Synchronization

classification cs.DC cs.DB
keywords BFT consensusnetwork partitionspartial livenessview synchronizationproof of availabilitypacemakerpermissioned blockchaintwo-tier certification
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.

Traditional BFT consensus freezes when the network splits so that no two-thirds majority of replicas can talk. Cassandra shows that useful, safety-preserving progress is still possible: any connected group of at least one-third of the correct replicas can keep proposing and certifying transactions with a weaker certificate, then automatically fold those provisional branches into a single committed log once a strong quorum reappears. The mechanism is a two-tier certificate (Proof of Availability versus Proof of Reliability), a deterministic rule that lets every replica pick the strongest proposal without a fixed leader, and a pacemaker that advances rounds on weak evidence while tuning timeouts off the critical path. Under stable conditions the protocol stays competitive with existing systems; under severe partitions it keeps producing speculative work that is not discarded. The result matters for geo-distributed databases and permissioned blockchains that face real partition events.

Core claim

Cassandra establishes that BFT consensus can satisfy Partial Liveness: while the network is partitioned, any synchronous connected component containing at least f+1 correct replicas continues ordering new client transactions via Proof-of-Availability certificates, and that accumulated progress remains recoverable and can be incorporated into final Proof-of-Reliability commits once connectivity is restored, without ever violating safety.

What carries the argument

The two-tier certification framework: a Proof of Availability (PoA) formed by a weak quorum of f+1 votes, which certifies recoverable partial progress inside a partition, and a Proof of Reliability (PoR) formed by a strong quorum of n-f votes, which alone justifies commitment. Paired with a deterministic proposal-priority rule and a decoupled pacemaker that advances rounds on either a PoR or a weak Round Certificate, this lets each partition extend its own chain and later reconcile implicitly.

Load-bearing premise

The system assumes that after every disruption there will eventually be a long enough stable period among the reachable replicas for their local timeouts to catch up to the true message delay, and that the cryptographic keys for certificates were set up before any permanent split.

What would settle it

Partition more than f replicas for longer than any timeout-calibration window, then restore connectivity: if the previously isolated components either commit conflicting transactions or fail to incorporate any of their PoA-certified proposals into the final log, the partial-liveness claim is false.

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

If this is right

  • Any connected component of only f+1 correct replicas can keep ordering and speculatively executing transactions during a partition.
  • Divergent PoA-backed histories reconcile automatically once a strong quorum is reachable again, without an explicit merge protocol.
  • Under stable networks Cassandra remains competitive (900K TPS at 16 replicas, 480K TPS at 104).
  • Speculative PoA work is preserved and can produce a recovery burst after reconnection.
  • Round advancement no longer requires a strong quorum of new-view messages.

Where Pith is reading between the lines

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

  • Intra-shard consensus in sharded blockchains could adopt the same weak-quorum progress so a shard does not stall when only f+1 honest replicas remain connected.
  • Geo-distributed deployments that experience recurring regional partitions would accumulate less wasted work and recover faster than pure strong-quorum designs.
  • The background multiplicative timeout calibration could be reused by other partially-synchronous protocols that currently leave timeouts permanently inflated after transient spikes.
  • Speculative execution of PoA-backed proposals offers a measurable intermediate progress metric for systems that previously reported only zero or full throughput under CAP stress.

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

2 major / 5 minor

Summary. Cassandra is a BFT consensus protocol that preserves classical safety while enabling partial progress under network partitions. It replaces strong-quorum-only commitment with a two-tier certification scheme (weak-quorum PoA for recoverable local ordering, strong-quorum PoR for final commit), eliminates designated-leader dependence via all-to-all proposal exchange and a deterministic certificate-priority rule (with threshold-coin tie-break), and uses a decoupled pacemaker that advances rounds on PoR or weak-quorum Round Certificates while calibrating local timeouts off the critical path. Safety, liveness under partial synchrony with recurring GSTs, and Partial Liveness (any connected component of ≥f+1 correct, timeout-sufficient replicas continues to produce recoverable PoA progress) are claimed via Theorems 1–3 and proved in Appendix A. A dual-path optimization (linear fast path with base-path fallback), optional dissemination layer, and speculative PoA execution are evaluated against Tusk, AutoBahn, PBFT, HotStuff, SpotLess and RCC, showing competitive stable-state throughput/latency and non-zero speculative throughput under f+1 and n/2 partitions.

Significance. If the claims hold, Cassandra supplies a clean, CAP-aware middle ground for permissioned BFT systems: partitions no longer force zero useful progress, yet final commits remain classical and safe. The combination of two-tier certificates, partitionable leader election, and a weak-quorum-capable pacemaker is a coherent design contribution that is orthogonal to sharding and DAG mempools and could be reused as an intra-shard component. Strengths that raise confidence include a full Appendix A proof suite built on standard quorum-intersection, single-vote and lock-monotonicity arguments, an open-source C++ implementation inside Apache ResilientDB, and a multi-scenario evaluation (scalability to 104 replicas, three partition patterns, Byzantine delay/tail-forking, geo-regional partition, ablation) that independently supports the 0-to-1 progress claim. The free parameters (K, α, δmin) are confined to timeout calibration and do not appear in the safety or partial-liveness statements.

major comments (2)
  1. §4.1.1 / Fig. 6 / Lemma 5: The Two-PoR commit rule is stated clearly, but the manuscript never quantifies how much provisional PoA work is discarded when a competing higher-priority branch wins after recovery. Because Partial Liveness is defined as “recoverable” progress that “can be incorporated,” a short bound or experimental measurement of the fraction of PoA-certified proposals that ultimately become ancestors of a committed PoR (under the f→n/2→f and geo-partition scenarios of Fig. 12) is needed to make the usefulness claim precise rather than qualitative.
  2. §2 / Lemma 6 / Theorem 3: Partial Liveness is conditioned on every correct replica inside the component already being timeout-sufficient (δi ≥ Δ). The background SyncTimeout service itself requires a 2f+1 SYNC-READY collection to form a SYNC-CERT; under a permanent or long-lived partition that never contains a strong quorum, calibration cannot succeed and the δi ≥ Δ premise may never hold. The paper should either (a) state an explicit additional assumption that each component experiences at least one calibration-success window, or (b) show that RC-based round advancement alone still yields PoAs even with mis-calibrated (but finite) timeouts, so that the partial-progress claim does not silently depend on a strong-quorum calibration step.
minor comments (5)
  1. Fig. 12 caption and §7.3: Distinguish more explicitly in the plots (or legend) between final committed TPS and speculative PoA TPS; the text already does so, but the figures themselves can be misread as ordinary throughput.
  2. §5.1: The fast-path collector is described as “e.g., the next-round leader”; a one-sentence statement that any fixed deterministic collector works (and that the base-path fallback is independent of that choice) would remove a minor ambiguity.
  3. §4.2.3: The optional multiplicative decrease of δi (factor α) is mentioned only in prose; adding the precise predicate “elapsed < δi/α” to the pseudocode of Fig. 9 would improve reproducibility.
  4. Related Work: A short comparison paragraph with Raptr’s prefix-consensus and with AutoBahn’s dissemination-only partial progress would help readers locate Cassandra’s novelty more quickly.
  5. Typographical: “stabalized” → “stabilized” (several places); “tai-forking” in the reader summary is a transcription error—the manuscript correctly says “tail-forking.”

Circularity Check

0 steps flagged

No significant circularity: Safety/Liveness/Partial Liveness rest on standard quorum-intersection and protocol definitions, independent of evaluation numbers or self-citations.

full rationale

The derivation chain for Theorems 1–3 (and the supporting Lemmas 1–11 in Appendix A) is self-contained. Safety follows from classical BFT ingredients—strong-quorum intersection of size 2f+1 (Lemma 1), single-vote per round (Lemma 2), PoR uniqueness, lock monotonicity under the Two-PoR rule, and the resulting locked-set argument—none of which is defined in terms of the target claim or fitted to data. Liveness and Partial Liveness likewise follow from the explicit model (partial synchrony with recurring GSTk, pre-established threshold keys, local timeouts calibrated off-path) together with the protocol’s own definitions of PoA (f+1 votes), RC, deterministic priority, and data availability; the probability bound (2f+1)/n for coin-resolved good rounds is a direct counting argument, not a fitted parameter. Evaluation metrics (TPS/latency under partitions) are measured post-hoc and never appear inside the theorems. Self-citations (ResilientDB platform, prior multi-leader or DAG works) are used only for implementation and comparison baselines; they do not supply any uniqueness theorem or ansatz that forces the central claims. Consequently the paper exhibits none of the six circularity patterns.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 3 invented entities

Standard BFT and partial-synchrony assumptions plus a small number of protocol parameters (K, α, δmin) that affect only performance, not safety. No new physical entities; the invented constructs are protocol certificates and rules whose properties are proved from the listed axioms.

free parameters (3)
  • K (timeout-calibration interval in rounds)
    System parameter controlling how often the background SyncTimeout service runs; chosen by implementer, affects only calibration frequency.
  • α (timeout-decrease threshold)
    Pre-set constant (example α=4) that decides when a successful calibration halves δi; performance tuning only.
  • δmin (minimum local timeout)
    Lower bound on the multiplicative-decrease of δi; implementation constant.
axioms (4)
  • domain assumption n ≥ 3f+1 replicas, at most f Byzantine; strong quorum 2f+1, weak quorum f+1
    Standard BFT resilience model stated in Section 2 and used throughout the proofs.
  • domain assumption Partial synchrony with unbounded sequence of stabilized periods GSTk after which messages among mutually reachable correct replicas arrive within unknown finite Δ
    Network model of Section 2; required for both ordinary liveness and the timeout-calibration argument.
  • domain assumption Authenticated channels via unforgeable digital signatures and collision-resistant hash; threshold signatures (f+1,n) and (2f+1,n) set up before any runtime partition
    Crypto assumptions of Section 2; threshold keys must be generated while fully connected.
  • domain assumption Correct replicas cast at most one vote per round and follow the deterministic priority and locking rules
    Protocol honesty assumption used in Lemmas 2–5 of the safety proof.
invented entities (3)
  • Proof of Availability (PoA) certificate no independent evidence
    purpose: Weak-quorum (f+1) certificate that certifies data availability and enables partial progress / speculative execution without final commitment
    Core two-tier construct introduced in Section 3; properties proved from quorum intersection, no external independent evidence required beyond the protocol definition.
  • Proof of Reliability (PoR) certificate no independent evidence
    purpose: Strong-quorum (2f+1) certificate that justifies locking and the two-PoR commit rule
    Standard strong certificate specialized to the two-tier framework; safety rests on classical quorum intersection.
  • Decoupled pacemaker with background SyncTimeout calibration no independent evidence
    purpose: Advance rounds with weak quorums (RC) while calibrating local timeouts off the critical path
    Protocol mechanism of Section 4.2; correctness argued under partial synchrony, not an external physical entity.

pith-pipeline@v1.1.0-grok45 · 31924 in / 2827 out tokens · 30000 ms · 2026-07-12T06:33:25.283040+00:00 · methodology

0 comments
read the original abstract

Replicated databases and permissioned blockchain systems rely on Byzantine Fault-Tolerant (BFT) consensus to maintain a globally consistent order of transactions across distributed replicas. These protocols preserve safety even under asynchrony, as they commit a transaction only after agreement among a strong quorum of replicas. During network partitions, however, when no strong quorum is reachable, they lose liveness and cannot make useful progress. In this paper, we present Cassandra, a consensus protocol that enables partial progress without sacrificing safety. Cassandra achieves this through a two-tier certification framework that decouples availability from commitment, allowing each partition to extend its own chain and reconcile these chains once the network is restored. To support this, Cassandra introduces a pacemaker that advances views without requiring a strong quorum and calibrates each replica's timeout off the critical path. Our evaluation results show that Cassandra remains competitive with state-of-the-art BFT protocols under stable conditions, sustaining 900K TPS at 16 replicas and 480K TPS at 104 replicas, with latency ranging from 0.31s at 16 replicas to 0.75s at 104 replicas. Under severe partitions, Cassandra maintains non-zero speculative throughput through PoA-backed progress, preserving work that can be reconciled once connectivity is restored.

Figures

Figures reproduced from arXiv: 2607.02856 by Dakai Kang, Daniel P. Hughes, Junchao Chen, Mohammad Sadoghi, Shaokang Xie, Suyash Gupta.

Figure 1
Figure 1. Figure 1: Comparison between traditional BFT protocols and [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: A round of Cassandra. out, a weak quorum of 𝑓 +1 replicas requests a round advancement. In both cases, there is sufficient information for lagging replicas to jump immediately to the highest certified round. Convergence toward a common round is guaranteed because round numbers increase monotonically and replicas accept certificates only for strictly higher rounds. During synchronous periods, certificates p… view at source ↗
Figure 3
Figure 3. Figure 3: Cassandra’s Proposal and Local Log Chain. certification (refer to [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Utility and Helper Functions for Cassandra The proposal with the highest Score(·) is designated as the Strongest Proposal of round 𝑟, which we denote as 𝑆𝑃𝑟 . Each replica then broadcasts a Vote for 𝑆𝑃𝑟 . If a proposal gathers 𝑄 = 2𝑓 +1 votes, a PoR is formed. If it times out before forming a PoR but gathers 𝑄weak = 𝑓 +1 votes, a PoA is formed. 4.1.1 Locking and Commitment. Replicas independently interpret… view at source ↗
Figure 6
Figure 6. Figure 6: An Example of Two-PoR Commit Rule Cassandra instead deploys a decoupled pacemaker: round ad￾vancement remains certificate-driven on the critical path, while timeouts are calibrated off the critical path through a background synchronization service. This design simultaneously supports: (i) partial progress within weak connected components of at least 𝑓 +1 replicas, and (ii) fast catch-up and convergence onc… view at source ↗
Figure 5
Figure 5. Figure 5: Pseudocode of Round Logic in Cassandra formed for a chain extending 𝑏𝑟 , at least 𝑓 +1 honest replicas par￾ticipating in 𝑃𝑜𝑅𝑟+1 become locked on the proposal containing 𝑏𝑟 . Due to quorum intersection and the single-vote rule, no conflicting proposal can subsequently gather a strong quorum in round 𝑟+1 or beyond. Hence, two conflicting proposals cannot both satisfy the two-PoR commit condition, ensuring th… view at source ↗
Figure 8
Figure 8. Figure 8: Timeout Calibration prevent replay of stale synchronization messages. If a calibration attempt fails, replicas keep retrying in the background using higher synchronization views, while the main protocol remains unchanged and continues running. Phase 1: ⟨SYNC-READY⟩. After every 𝐾-th round, if replica 𝑝𝑖 is not undergoing a timeout-calibration, it initiates a calibration attempt in synchronization view 𝜈 by… view at source ↗
Figure 7
Figure 7. Figure 7: Pseudocode of the Pacemaker (after some GST) and whose value is not known a priori. Because the actual delay can differ across stable periods—particularly after long partitions or asymmetric delays—replicas’ local timeouts may become misaligned. To address this, existing pacemakers perform timeout calibration, but they do so on the critical path. To address this, Cassandra runs a periodic background timeou… view at source ↗
Figure 10
Figure 10. Figure 10: Fast Path Workflow in Good Cases superseded. Because PoA formation guarantees data availability, the proposals on these branches remain retrievable; however, only the branch incorporated into a subsequent PoR can be finalized. Merging in Cassandra is therefore implicit and protocol-driven: no separate reconciliation procedure is required, as the normal proposal-selection and certification process automati… view at source ↗
Figure 9
Figure 9. Figure 9: Pseudocode of Background Timeout Calibration [PITH_FULL_IMAGE:figures/full_fig_p008_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Fallback from Fast Path to Base Path quorum of vote shares before the timer expires, the replica abandons the fast path and falls back to the base path ( [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Evaluation summary across scalability and partition scenarios. [PITH_FULL_IMAGE:figures/full_fig_p011_12.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

56 extracted references · 5 linked inside Pith

  1. [1]

    [n. d.]. Cassandra: Consensus with Partial Progress via Robust Partitionable View Synchronization (Extended Version). https://github.com/apache/incubator- resilientdb/blob/cassandra/Cassandra_extended.pdf

  2. [2]

    [n. d.]. Cassandra Source Code. https://github.com/apache/incubator-resilientdb/ tree/cassandra

  3. [3]

    Mustafa Al-Bassam, Alberto Sonnino, Shehar Bano, Dave Hrycyszyn, Sarah Meiklejohn, and George Danezis. 2018. Chainspace: A Sharded Smart Contracts Platform. InNDSS

  4. [4]

    Ahmed Alquraan, Hatem Takruri, Mohammed Alfatafta, and Samer Al-Kiswany

  5. [5]

    InUSENIX OSDI

    An Analysis of Network-Partitioning Failures in Cloud Systems. InUSENIX OSDI. 51–68

  6. [6]

    Amazon Web Services. 2025. Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region. https://aws.amazon. com/message/101925/. (Accessed: 07-01-2026)

  7. [7]

    Apache ResilientDB. [n. d.]. Apache ResilientDB (Incubating). https://resilientdb. apache.org/

  8. [8]

    Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. 2017. Hijacking Bitcoin: Routing Attacks on Cryptocurrencies. In2017 IEEE Symposium on Security and Privacy (SP). IEEE, 375–392. doi:10.1109/SP.2017.29

  9. [9]

    Balaji Arun and Binoy Ravindran. 2022. Scalable Byzantine Fault Tolerance via Partial Decentralization. InPVLDB

  10. [10]

    Eric A. Brewer. 2000. Towards Robust Distributed Systems. InACM PODC

  11. [11]

    Miguel Castro and Barbara Liskov. 1999. Practical Byzantine Fault Tolerance. In USENIX OSDI. 173–186

  12. [12]

    Miguel Castro and Barbara Liskov. 2002. Practical Byzantine Fault Tolerance and Proactive Recovery. InACM Transactions on Computer Systems. 398–461

  13. [13]

    Cloudflare. 2025. Cloudflare outage on December 5, 2025. https://blog.cloudflare. com/5-december-2025-outage/. Accessed: 07-01-2026

  14. [14]

    Cloudflare. 2025. Cloudflare outage on November 18, 2025. https://blog.cloudflare. com/18-november-2025-outage. Accessed: 07-01-2026

  15. [15]

    Cryptonary. 2021. Solana Network Went Down Again; Mainnet Beta Restarts After 7 Hours of Outage. InOnline resource

  16. [16]

    George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegel- man. 2022. Narwhal and Tusk: A DAG-Based Mempool and Efficient BFT Con- sensus. InACM EuroSys

  17. [17]

    Reiter, and Haibin Zhang

    Sisi Duan, Michael K. Reiter, and Haibin Zhang. 2018. BEAT: Asynchronous BFT Made Practical. InACM CCS

  18. [18]

    Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. 1988. Consensus in the Presence of Partial Synchrony. InJournal of the ACM. 288–323

  19. [19]

    Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. 1999. Secure Distributed Key Generation for Discrete-Log Based Cryptosystems. InEURO- CRYPT. 295–310

  20. [20]

    Seth Gilbert and Nancy Lynch. 2012. Perspectives on the CAP Theorem. InIEEE Computer

  21. [21]

    Neil Giridharan, Florian Suri-Payer, Ittai Abraham, Lorenzo Alvisi, and Natacha Crooks. 2024. AutoBahn: Seamless High Speed BFT. InACM SOSP

  22. [22]

    Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu

    Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael K. Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu. 2019. SBFT: A Scalable and Decentralized Trust Infrastructure. InIEEE DSN

  23. [23]

    Suyash Gupta, Jelle Hellings, and Mohammad Sadoghi. 2021. Fault-Tolerant Dis- tributed Transactions on Blockchain. InSynthesis Lectures on Data Management

  24. [24]

    Suyash Gupta, Jelle Hellings, and Mohammad Sadoghi. 2021. RCC: Resilient Concurrent Consensus for High-Throughput Secure Transaction Processing. In IEEE ICDE

  25. [25]

    Suyash Gupta, Sajjad Rahnama, Jelle Hellings, and Mohammad Sadoghi. 2020. ResilientDB: Global Scale Resilient Blockchain Fabric. InPVLDB. 868–883

  26. [26]

    Hughes, Joshua Primero, and Mohammad Sadoghi

    Jelle Hellings, Daniel P. Hughes, Joshua Primero, and Mohammad Sadoghi. 2023. Cerberus: Minimalistic Multi-Shard Byzantine-Resilient Transaction Processing. InJournal of Systems Research

  27. [27]

    Jelle Hellings and Mohammad Sadoghi. 2021. ByShard: Sharding in a Byzantine Environment. InPVLDB

  28. [28]

    Kendric Hood, Joseph Oglio, Mikhail Nesterenko, and Gokarna Sharma. 2021. Partitionable Asynchronous Cryptocurrency Blockchain. InIEEE ICBC

  29. [29]

    Van Jacobson. 1988. Congestion Avoidance and Control. InACM SIGCOMM

  30. [30]

    Dakai Kang, Suyash Gupta, Dahlia Malkhi, and Mohammad Sadoghi. 2025. HotStuff-1: Linear Consensus with One-Phase Speculation. InSIGMOD

  31. [31]

    Dakai Kang, Sajjad Rahnama, Jelle Hellings, and Mohammad Sadoghi. 2024. SpotLess: Concurrent Rotational Consensus Made Practical Through Rapid View Synchronization. InIEEE ICDE

  32. [32]

    Jonathan Katz and Yehuda Lindell. 2014. Introduction to Modern Cryptography (2nd Edition). InChapman and Hall/CRC

  33. [33]

    Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman

  34. [34]

    InACM PODC

    All You Need is DAG. InACM PODC

  35. [35]

    Keshav, W

    S. Keshav, W. Golab, B. Wong, S. Rizvi, and S. Gorbunov. 2018. RCanopus: Making Canopus Resilient to Failures and Byzantine Faults. InarXiv preprint arXiv:1810.09300. Conference’17, July 2017, Washington, DC, USA Shaokang Xie, Dakai Kang, Junchao Chen, Suyash Gupta, Daniel P. Hughes, and Mohammad Sadoghi

  36. [36]

    Fischer, and Bryan Ford

    Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ismail Khoffi, Lars M. Fischer, and Bryan Ford. 2018. OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding. InIEEE S&P

  37. [37]

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. 2007. Zyzzyva: Speculative Byzantine Fault Tolerance. InACM SOSP

  38. [38]

    Andrew Lewis-Pye. 2022. Quadratic Worst-Case Message Complexity for State Machine Replication in the Partial Synchrony Model. InarXiv preprint arXiv:2201.01107

  39. [39]

    Andrew Lewis-Pye and Ittai Abraham. 2023. Fever: Optimal Responsive View Synchronisation. InarXiv preprint arXiv:2301.09881

  40. [40]

    Andrew Lewis-Pye, Dahlia Malkhi, Oded Naor, and Kartik Nayak. 2024. Lumiere: Making Optimal BFT for Partial Synchrony Practical. InACM PODC

  41. [41]

    Hanzheng Lyu, Shaokang Xie, Jianyu Niu, Ivan Beschastnikh, Yinqian Zhang, Mohammad Sadoghi, and Chen Feng. 2025. Orthrus: Accelerating Multi-BFT Consensus Through Concurrent Partial Ordering of Transactions. InIEEE ICDE

  42. [42]

    Hanzheng Lyu, Shaokang Xie, Jianyu Niu, Chen Feng, Yinqian Zhang, and Ivan Beschastnikh. 2025. Ladon: High-Performance Multi-BFT Consensus via Dynamic Global Ordering. InACM EuroSys

  43. [43]

    Hanzheng Lyu, Shaokang Xie, Jianyu Niu, Mohammad Sadoghi, Yinqian Zhang, Cong Wang, Ivan Beschastnikh, and Chen Feng. 2025. HYDRA: Break- ing the Global Ordering Barrier in Multi-BFT Consensus. InarXiv preprint arXiv:2511.05843

  44. [44]

    Jean-Philippe Martin and Lorenzo Alvisi. 2005. Fast Byzantine Consensus. In IEEE DSN

  45. [45]

    Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. 2016. The Honey Badger of BFT Protocols. InACM CCS

  46. [46]

    Pedersen

    Torben P. Pedersen. 1991. A Threshold Cryptosystem without a Trusted Party. InEUROCRYPT. 522–526

  47. [47]

    Mohammad Sadoghi. 2025. The Problems of Consensus: An Ethical Inquiry into Democratic and Decentralized Principles. InSpringerBriefs in Philosophy

  48. [48]

    Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris Kokoris- Kogias. 2022. Bullshark: DAG BFT Protocols Made Practical. InACM CCS

  49. [49]

    Chrysoula Stathakopoulou, Tudor David, Matej Pavlovic, and Marko Vukolic

  50. [50]

    InJournal of Systems Research

    Mir-BFT: Scalable and Robust BFT for Decentralized Networks. InJournal of Systems Research

  51. [51]

    Chrysoula Stathakopoulou, Matej Pavlovic, and Marko Vukolic. 2022. State Machine Replication Scalability Made Simple. InACM EuroSys

  52. [52]

    Andrei Tonkikh, Balaji Arun, Zhuolun Xiang, Zekun Li, and Alexander Spiegel- man. 2025. Raptr: Prefix Consensus for Robust High-Performance BFT. InarXiv preprint arXiv:2504.18649

  53. [53]

    Shaokang Xie, Dakai Kang, Hanzheng Lyu, Jianyu Niu, and Mohammad Sadoghi

  54. [54]

    InarXiv preprint arXiv:2501.01062

    Fides: Secure and Scalable Asynchronous DAG Consensus via Trusted Components. InarXiv preprint arXiv:2501.01062

  55. [55]

    Reiter, Guy Golan Gueta, and Ittai Abra- ham

    Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abra- ham. 2019. HotStuff: BFT Consensus with Linearity and Responsiveness. InACM PODC

  56. [56]

    Mahdi Zamani, Mahnush Movahedi, and Mariana Raykova. 2018. RapidChain: Scaling Blockchain via Full Sharding. InACM CCS. Cassandra: Consensus with Partial Progress via Robust Partitionable View Synchronization Conference’17, July 2017, Washington, DC, USA A Correctness Proof This section provides the full proofs of Theorems 1, 2, and 3. A.1 Safety We assum...