Pith. sign in

REVIEW 3 major objections 5 minor 80 references

Leader Rotation Is Not Enough: Scrutinizing Leadership Democracy of Chained BFT Consensus

T0 review · 3 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read By modeling adversarial strategies as a Markov decision process, the paper shows that all four major chained BFT protocols have a zero attack threshold: even an arbitrarily small fraction of Byzantine nodes can lower chain quality below…

desk verdict A serious first quantitative pass at leadership democracy in chained BFT, with a plausible zero-threshold result; the Streamlet MDP overstates censorship and the exact quantitative rankings need correction before the paper's findings are used as-is. read the letter →

arxiv 2501.02970 v3 pith:RMGNPVET submitted 2025-01-06 cs.CR cs.DC

Jianyu Niu , Yining Tang , Runchao Han , Chen Feng , Yinqian Zhang This is my paper · ORCID
classification cs.CRcs.DC
keywords chainedBFTconsensusleadershipdemocracychainqualitycensorshipresilienceMarkovdecisionprocessforkingattacksleaderrotation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

Chained BFT protocols such as HotStuff, Streamlet, and Fast-HotStuff rotate the leader every view, a design believed to give every node a fair chance to propose blocks and resist censorship. This paper argues that leader rotation alone is not enough: by modeling optimal adversarial strategies with a Markov decision process, it shows that an adversary controlling an arbitrarily small fraction of nodes can drive chain quality below the ideal $1-\alpha$ and exclude honest blocks from the main chain. The result holds for all four protocols studied, with chained HotStuff suffering the largest degradation. The paper also shows that small changes, such as broadcasting quorum certificates or randomizing the proposing rule, can substantially improve leadership democracy, while exposing an unavoidable trade-off among linear message complexity, responsiveness, and optimal leadership democracy.

What carries the argument

The key instrument is a Markov decision process specialized to chained BFT: the state is a triple $(l_a, l_h, L)$ counting uncommitted adversarial blocks, uncommitted honest blocks, and the identity of the current leader, with actions Adopt, Wait, Release, plus Withhold for Streamlet. Because neither chain quality nor censorship resilience is a linear objective, the authors use a transformation from the optimal-selfish-mining literature that converts the non-linear objective into a family of standard MDPs, solved by binary search over the target value. The framework isolates two design components, the voting pattern (direct votes, leader relay, broadcast, leader-broadcast) and the proposing rule (deterministic versus random), and shows how each one changes the resulting metrics.

What would settle it

Run the MDP with an expanded action space allowing two hidden adversarial blocks and simultaneous forks on the four original protocols; if chain quality at some fraction $\alpha$ is strictly lower than the paper's reported curves, its optimal-strategy claim is falsified. Alternatively, deploy a small testnet of roughly 31 nodes running Streamlet with one Byzantine proposer under perfectly synchronous communication, count committed honest blocks over thousands of views, and check whether the fraction stays at $1-\alpha$ or falls below it.

Watch

Extended reading notes

Core claim

The central discovery is that the attack threshold of all four examined chained BFT protocols is zero: for any fraction $\alpha>0$ of Byzantine nodes, an adversary can deviate from the protocol and force chain quality $Q(\alpha)<1-\alpha$ and censorship resilience $C(\alpha)<1$, and these attacks are riskless because deterministic consensus rules let an adversarial block always win the fork it creates. Chained HotStuff is the worst case: its three-chain structure and 'extend the highest QC' proposing rule let a single adversarial block override up to two honest blocks, whereas the other protocols can override only one. The results are obtained by solving an MDP whose states track uncommitted honest and adversarial blocks and the current leader's identity, with actions adopt, wait, release, and an additional withhold action for Streamlet, and the predicted metrics are validated on a small-scale testnet implementation of the four protocols.

Load-bearing premise

The analysis rests on the MDP's assumption that an adversary holding at most one hidden block and never forking simultaneously loses no attacking power; if that simplification is wrong, the computed thresholds and countermeasure guarantees could be off.

Editorial extensions

If this is right

  • An adversary controlling a single Byzantine node can reduce chain quality below $1-\alpha$ in all four protocols, so deployments that assume leadership fairness under attack are unsound without modification.
  • Chained HotStuff has the worst leadership democracy: at a Byzantine fraction of $1/3$, chain quality drops by $0.29$ and censorship resilience by $0.56$ from the optimal values.
  • Switching Fast-HotStuff from direct-vote to leader-broadcast quorum certificates gives it optimal chain quality and censorship resilience without changing any consensus rule.
  • Introducing a random proposing rule raises the chain-quality attack threshold of Two-chain HotStuff and chained HotStuff from zero to about $0.285$, although censorship resilience remains imperfect.
  • No modification of the four protocols can simultaneously provide linear message complexity, responsiveness, and optimal censorship resilience; protocol designers must accept a trade-off among these goals.

Reading between the lines

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

  • Because the zero-threshold result is driven by deterministic fork resolution, the same style of attack is likely to appear in later chained BFT variants that preserve an 'extend the highest QC' rule or a longest-certified-chain rule, even if they change the commit depth.
  • The countermeasures suggest a transferable design rule: whenever a protocol lets the adversary choose deterministically between two valid continuations, the adversary gains guaranteed censorship power, and injecting unpredictability at the proposing step dilutes that power.
  • The restricted adversary model, at most one hidden block and no simultaneous forks, is conservative; an adversary allowed to hold multiple hidden blocks or fork simultaneously would likely achieve the same or lower metrics, so the reported thresholds for the original protocols may be optimistic.
  • The trade-off finding implies that permissionless chains built on these protocols are exposed to MEV-style front-running by any validator with a tiny stake, not only by large colluding groups.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes a unified MDP-based evaluation framework with two metrics—chain quality Q(α) and censorship resilience C(α)—for chained BFT protocols, and applies it to 2CHS, CHS, Streamlet, and FHS. The central claim is that all four protocols have a zero attack threshold: for any positive fraction α of Byzantine nodes, an adversary can drive Q(α) below the optimal 1−α and censor honest blocks. The paper also identifies the design components (voting pattern, proposing rule) responsible for the vulnerability, proposes countermeasures for three of the protocols, and validates the original-protocol attack predictions with Bamboo experiments in Appendix D.

Significance. If the central claim is correct, the paper has substantial significance: it challenges the common fairness premise of chained BFT protocols and provides a quantitative framework that can guide future designs. The concrete strengths are the reproducible Bamboo experiments with error bars (Appendix D), the explicit optimality proof for FHS-C (Theorem 1 and Corollary 1), and the clear connection between protocol rules and the identified attacks. The significance is tempered by two load-bearing gaps: the Streamlet MDP model appears to overestimate censorship success, and the claimed optimality of the MDP solutions rests on an unproven restriction of the adversary's power.

major comments (3)
  1. [V-A3 / Table IV] The 'Withhold' action in the Streamlet MDP assigns reward (Bh, Ba, Oh) = (lh, 1, 1) deterministically whenever the current leader is honest and la = 1, i.e., it assumes the honest leader's block is always censored. In the actual Streamlet protocol, creating a hidden certified adversarial block requires collecting 2f honest votes in addition to the adversary's own vote, so f of the n honest nodes remain unaware of that block. The next honest leader is unaware only with probability f/n, not with probability 1; with probability 2f/n the honest leader has already seen the certified block and will extend it, so no honest block is lost. The model therefore overstates the adversary's censorship success rate for Streamlet. While a first-order correction still yields Q(α) < 1−α for every α>0, so the qualitative zero-threshold claim likely survives, the exact Q(α) and C(α) curves for Streamlet in Figures 3 and 4, and especially Finding 2 that 2CHS, FHS, and Streamlet have identical chain quality, are not justified without incorporating this awareness probability. The transition probabilities and rewards in Table IV must be revised or the claim must be restricted to a weaker statement.
  2. [IV-A] The MDP model restricts the adversary to at most one hidden adversarial block (la ∈ {0,1}) and to a small lh range ({0,1} or {0,1,2}) based on the assertion in Section IV-A that 'the adversary will not choose to initiate multiple forks simultaneously' because it would not increase the probability of overriding an honest block. This is a load-bearing modeling assumption for the claimed optimality of the computed attack strategies and for the countermeasure thresholds in Section VI-B. If a more complex adversary using multiple hidden blocks or simultaneous forks could achieve lower chain quality, the exact quantitative results (Figures 3-4, Table II) and the claimed optimality of the countermeasures would change, even though the qualitative zero-threshold conclusion would likely strengthen. The paper provides no formal proof that the restriction is without loss of generality. A formal argument, or at least a rigorous bound showing that additional adversarial power cannot improve the adversary's utility, is needed before the optimality statements can be accepted.
  3. [VI-B.3 / Table II] The countermeasure results for 2CHS-C, CHS-C (and the claim about FHS-C's optimality) are presented as evaluation results, but they are MDP predictions only. Unlike the original-protocol results, they are not validated in the Bamboo testbed, which is used in Appendix D for the original protocols. The random proposing rule introduces a stochastic branch-selection mechanism whose real-network behavior (including the effect of message delay on the fork structure) may differ from the MDP model. Please either add experimental validation of the countermeasures in the same style as Appendix D, or clearly and consistently state that the countermeasure results are model predictions that have not yet been empirically validated.
minor comments (5)
  1. [III-A] The sentence 'we assume nodes communicate through point-to-pointThe topic of attacks on permissionless blockchains with wide usage is important and timely., authenticated, and reliable channels' contains an apparent text corruption or unintended insertion. This must be cleaned up; it appears to be a non-technical fragment embedded in the model description.
  2. [V-A1] The text says the state transition and reward matrices for 2CHS and FHS 'are shown in Table III', but the table in the main text is labeled Table I. The reference should be corrected.
  3. [Appendix D] There are several typos: 'cencorship' in the captions and text of Figures 11 and 12 and in Section V-B2, 'Syetem' in reference [22], and 'The theory values' in Appendix D. A thorough copyedit is needed.
  4. [V-B2] Finding 1 states that the attack thresholds 'are zero.' Strictly, with a finite number of nodes n, the smallest positive fraction is 1/n, so the threshold is 1/n rather than 0 in any concrete instantiation. The 'zero' wording is acceptable as a limit statement, but it should be phrased precisely to avoid the implication that a positive fraction smaller than 1/n is meaningful.
  5. [Figures 3 and 4] If the Streamlet model is corrected per the major comment above, the overlapping curves for 2CHS, FHS, and Streamlet will separate; the figures and the accompanying text in Finding 2 must be updated to show the individual curves and the corrected comparison.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the MDP framework is built from explicit protocol rules, the FHS-C result is supported by an independent theorem, and the Bamboo experiments provide external validation.

full rationale

The derivation chain is not circular. The metrics Q and C are defined independently of the MDP outcomes, and the MDP states, actions, transitions, and rewards are constructed from each protocol's stated proposing, voting, committing, and leader-election rules rather than from the conclusions being drawn. The zero-threshold finding follows from computed optimal policies and is separately checked against the open-source Bamboo platform, which is code-reproduced external evidence. The FHS-C optimality result is supported by a standalone theorem and corollary, not by the MDP itself. The self-citations that appear are used for protocol description or benchmark provenance and are not load-bearing for the central claim. The Streamlet Withhold transition's deterministic Oh=1 reward is a modeling-accuracy concern rather than a circular reduction, because the model's output is not identical to its input by construction and the paper supplies protocol-level reasoning for the attack. No fitted parameter is renamed as a prediction, and no uniqueness theorem is imported from the authors' prior work.

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

The central claims rest on a deliberately restricted adversary model and standard BFT assumptions. The only free numeric parameter is the tie-breaking probability gamma in the countermeasure analysis, which is set to 0.5 without sensitivity analysis. No new physical or protocol entities are introduced.

free parameters (1)
  • gamma (tie-breaking probability) = 0.5
    In the random proposing-rule countermeasures for 2CHS-C and CHS-C, an honest leader chooses between two equal-length forks with probability gamma = 0.5 (Section VI-B2). The chain quality and censorship results in Table II depend on this value, and no sensitivity analysis is provided.
assumptions (4)
  • ad hoc to paper Adversary is restricted to at most one hidden adversarial block and cannot launch multiple simultaneous forks
    Stated in Section IV-A as a simplification of the action space. The paper argues multiple forks are suboptimal, but this is asserted rather than formally proven; the countermeasure analysis depends on this restriction.
  • domain assumption Network is synchronous after GST with a known bound Delta
    Standard BFT assumption stated in Section III-A; the analysis is restricted to the post-GST synchronous period, and asynchrony is only discussed informally in Appendix A1.
  • domain assumption n = 3f + 1 and leader election probability is alpha for Byzantine nodes
    Standard BFT quorum assumption and random leader election model stated in Section III-A; used throughout the MDP transition probabilities.
  • standard math Sapirshtein et al. transformation for non-linear MDP objectives is valid
    Used in Section V-B1 to convert the chain-quality ratio objective into a family of standard MDPs, citing [46]. The transformation properties are standard and cited.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Leader Rotation Is Not Enough: Scrutinizing Leadership Democracy of Chained BFT Consensus." pith.science (2026). https://pith.science/paper/RMGNPVET

@misc{pith2026250102970,
  author       = {Pith},
  title        = {Pith review of: Leader Rotation Is Not Enough: Scrutinizing Leadership Democracy of Chained BFT Consensus},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RMGNPVET}},
  note         = {Machine review of arXiv:2501.02970}
}
read the original abstract

With the growing popularity of blockchains, modern chained BFT protocols combining chaining and leader rotation to obtain better efficiency and leadership democracy have received increasing interest. Although the efficiency provisions of chained BFT protocols have been thoroughly analyzed, the leadership democracy has received little attention in prior work. In this paper, we scrutinize the leadership democracy of four representative chained BFT protocols, especially under attack. To this end, we propose a unified framework with two evaluation metrics, i.e., chain quality and censorship resilience, and quantitatively analyze chosen protocols through the Markov Decision Process (MDP). With this framework, we further examine the impact of two key components, i.e., voting pattern and leader rotation on leadership democracy. Our results indicate that leader rotation is not enough to provide the leadership democracy guarantee; an adversary could utilize the design, e.g., voting pattern, to deteriorate the leadership democracy significantly. Based on the analysis results, we propose customized countermeasures for three evaluated protocols to improve their leadership democracy with only slight protocol overhead and no change of consensus rules. We also discuss future directions toward building more democratic chained BFT protocols.

Figures

Figures reproduced from arXiv: 2501.02970 by the authors.

Figure 1
Figure 1. The propose-vote paradigm of chained BFT protocols. The yellow crown denotes the leader in a view. choose four representative and influential chained BFT proto￾cols: Two-chain HotStuff (2CHS), chained HotStuff (CHS), Streamlet, and Fast-HotStuff (FHS). (See detailed reasons for choosing them in §VII.) Due to space constraints, we refer readers to Appendix B for detailed descriptions of these chained BFT protocols. A… view at source ↗
Figure 2
Figure 2. Four different voting patterns. Here, DV, BV, LRV, and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The chain quality of 2CHS, CHS, FHS, and Streamlet. The [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: The censorship resilience of 2CHS, CHS, FHS, Streamlet. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 6
Figure 6. Figure 6: Forking case in 2CHS-C. The adversarial blocks are denoted [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 8
Figure 8. Figure 8: The chained blocks in CHS. Block Bv, Bv+1 and Bv+2 are consecutive blocks. Nodes will commit Bv when receiving proposal of Bv+3, and lock at Bv+1. The adversarial block Bv+4 could override two honest blocks. the two-phase committing rule) to enable the protocol to reac…
Figure 9
Figure 9. Figure 9: The chained blocks in FHS. Block Bv and Bv+1 are consecutive blocks. Nodes will commit Bv when receiving proposal of Bv+2, and lock at Bv+1. The adversarial block Bv+3 could override one honest block. and 2CHS belong to posterior forking attacks and result in an advers…
Figure 12
Figure 12. Figure 12: Comparison between experimental results (denoted by the [PITH_FULL_IMAGE:figures/full_fig_p018_12.png]
Figure 11
Figure 11. Figure 11: Comparison between experimental results (denoted by the [PITH_FULL_IMAGE:figures/full_fig_p018_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

80 extracted references · 77 canonical work pages

  1. [1]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Working Paper, 2008

    work page 2008

  2. [2]

    Zerocash: Decentralized anonymous payments from Bitcoin,

    E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, “Zerocash: Decentralized anonymous payments from Bitcoin,” in S&P, May 2014, pp. 459–474

    work page 2014

  3. [3]

    Ethereum,

    “Ethereum,” https://ethereum.org/en/, retrieved Oct, 2024

    work page 2024

  4. [4]

    Algorand: Scaling Byzantine agreements for cryptocurrencies,

    Y . Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, “Algorand: Scaling Byzantine agreements for cryptocurrencies,” in SOSP, 2017

    work page 2017

  5. [5]

    Dumbo: Faster asynchronous BFT protocols,

    B. Guo, Z. Lu, Q. Tang, J. Xu, and Z. Zhang, “Dumbo: Faster asynchronous BFT protocols,” in CCS, 2020, pp. 803–818

    work page 2020

  6. [6]

    The Honey Badger of BFT protocols,

    A. Miller, Y . Xia, K. Croman, E. Shi, and D. Song, “The Honey Badger of BFT protocols,” in CCS, 2016, pp. 31–42

    work page 2016

  7. [7]

    Tendermint: Byzantine fault tolerance in the age of blockchains,

    E. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,” M.Sc. Thesis, University of Guelph, Canada , Jun 2016

    work page 2016

  8. [8]

    Casper the friendly finality gadget,

    V . Buterin and V . Griffith, “Casper the friendly finality gadget,” CoRR, vol. abs/1710.09437, 2017

    arXiv 2017

Show all 80 references
  1. [9]

    HotStuff: BFT consensus with linearity and responsiveness,

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

    2019

  2. [10]

    DiemBFT v4: State machine replication in the Diem blockchain,

    D. Team, “DiemBFT v4: State machine replication in the Diem blockchain,” Technical Report. Diem. https://developers. diem. com/papers/diem-consensus . . . , Tech. Rep., 2021

    2021

  3. [11]

    Streamlined blockchains: A simple and elegant approach (a tutorial and survey),

    E. Shi, “Streamlined blockchains: A simple and elegant approach (a tutorial and survey),” in Asiacrypt, 2019

    2019

  4. [12]

    Fast-HotStuff: A fast and robust BFT protocol for blockchains,

    M. M. Jalalzai, J. Niu, C. Feng, and F. Gai, “Fast-HotStuff: A fast and robust BFT protocol for blockchains,” TDSC, pp. 1–17, 2023

    2023

  5. [13]

    HotStuff-2: Optimal two-phase responsive BFT,

    D. Malkhi and K. Nayak, “HotStuff-2: Optimal two-phase responsive BFT,” Cryptology ePrint Archive , 2023

    2023

  6. [14]

    No-commit proofs: Defeating livelock in BFT,

    N. Giridharan, H. Howard, I. Abraham, N. Crooks, and A. Tomescu, “No-commit proofs: Defeating livelock in BFT,” Cryptology ePrint Archive, 2021

    2021

  7. [15]

    Marlin: Two-phase BFT with linearity,

    X. Sui, S. Duan, and H. Zhang, “Marlin: Two-phase BFT with linearity,” in DSN, 2022

    2022

  8. [16]

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

    R. Gelashvili, L. Kokoris-Kogias, A. Sonnino, A. Spiegelman, and Z. Xiang, “Jolteon and Ditto: Network-adaptive efficient consensus with asynchronous fallback,” in FC, 2022

    2022

  9. [17]

    BeeGees: stayin’ alive in chained BFT,

    N. Giridharan, F. Suri-Payer, M. Ding, H. Howard, I. Abraham, and N. Crooks, “BeeGees: stayin’ alive in chained BFT,” in PODC, 2023

    2023

  10. [18]

    XuperChain Platform,

    X. Lab, “XuperChain Platform,” June 2021. [Online]. Available: https://github.com/xuperchain/xuperchain

    2021

  11. [19]

    Introduction to Hyperchains,

    “Introduction to Hyperchains,” https://blog.matter-labs.io/ introduction-to-hyperchains-fdb33414ead7, retrieved Oct, 2024

    2024

  12. [20]

    Three attacks on Proof-of-Stake Ethereum,

    C. Schwarz-Schilling, J. Neu, B. Monnot, A. Asgaonkar, E. N. Tas, and D. Tse, “Three attacks on Proof-of-Stake Ethereum,” in FC, 2022

    2022

  13. [21]

    Aptos homepage,

    “Aptos homepage,” https://aptoslabs.com, retrieved Oct, 2024

    2024

  14. [22]

    Syetem and methods for selection and utilizing a committee of validator nodes in a distributed system,

    Y . Guo, Q. Yang, H. Zhou, W. Lu, and S. Zeng, “Syetem and methods for selection and utilizing a committee of validator nodes in a distributed system,” Cypherium Blockchain, Feb 2020, patent. [Online]. Available: https://github.com/cypherium/patent

    2020

  15. [23]

    Flow: Separating consensus and compute–block formation and execution,

    A. Hentschel, Y . Hassanzadeh-Nazarabadi, R. Seraj, D. Shirley, and L. Lafrance, “Flow: Separating consensus and compute–block formation and execution,” arXiv preprint arxiv:2002.07403 , 2002

    2002 arXiv

  16. [24]

    EVM and the road to Zilliqa 2.0 - Upgrading network efficiency,

    J. McKane, “EVM and the road to Zilliqa 2.0 - Upgrading network efficiency,” https://blog.zilliqa.com/ evm-and-the-road-to-zilliqa-2-0-upgrading-network-efficiency/, retrieved Oct, 2024

    2024

  17. [25]

    Revolution Proof of Stake,

    “Revolution Proof of Stake,” https://revolution.deso.com/, retrieved Oct, 2024

    2024

  18. [26]

    Optimal Good-Case Latency for Rotating Leader Synchronous BFT,

    I. Abraham, K. Nayak, and N. Shrestha, “Optimal Good-Case Latency for Rotating Leader Synchronous BFT,” in OPODIS, 2021

    2021

  19. [27]

    Pili: A simple, fast, and robust family of blockchain protocols,

    T. H. Chan, R. Pass, and E. Shi, “Pili: A simple, fast, and robust family of blockchain protocols,” Cryptology ePrint Archive, Report 2018/980., Tech. Rep., 2018

    2018

  20. [28]

    On the optimality of optimistic responsiveness,

    N. Shrestha, I. Abraham, L. Ren, and K. Nayak, “On the optimality of optimistic responsiveness,” in CCS, 2020

    2020

  21. [29]

    Practical Byzantine fault tolerance,

    M. Castro, B. Liskov et al. , “Practical Byzantine fault tolerance,” in OSDI, vol. 99, 1999, pp. 173–186

    1999

  22. [30]

    On the performance of pipelined HotStuff,

    J. Niu, F. Gai, M. M. Jalalzai, and C. Feng, “On the performance of pipelined HotStuff,” in INFOCOM, 2021

    2021

  23. [31]

    Dissecting the performance of Chained-BFT,

    F. Gai, A. Farahbakhsh, J. Niu, C. Feng, I. Beschastnikh, and H. Duan, “Dissecting the performance of Chained-BFT,” in ICDCS, 2021

    2021

  24. [32]

    Blockbench: A framework for analyzing private blockchains,

    T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, and K.-L. Tan, “Blockbench: A framework for analyzing private blockchains,” in SIGMOD, 2017

    2017

  25. [33]

    The performance of Byzantine fault tolerant blockchains,

    G. Shapiro, C. Natoli, and V . Gramoli, “The performance of Byzantine fault tolerant blockchains,” in NCA, 2020

    2020

  26. [34]

    The BEDROCK of BFT: A unified platform for BFT protocol design and implementation,

    M. J. Amiri, C. Wu, D. Agrawal, A. E. Abbadi, B. T. Loo, and M. Sadoghi, “The BEDROCK of BFT: A unified platform for BFT protocol design and implementation,” arXiv preprint arXiv:2205.04534, 2022

    2022 arXiv

  27. [35]

    Diablo: A benchmark suite for blockchains,

    V . Gramoli, R. Guerraoui, A. Lebedev, C. Natoli, and G. V oron, “Diablo: A benchmark suite for blockchains,” in Eurosys, 2023

    2023

  28. [36]

    Be aware of your leaders,

    S. Cohen, R. Gelashvili, L. K. Kogias, Z. Li, D. Malkhi, A. Sonnino, and A. Spiegelman, “Be aware of your leaders,” in FC, 2022

    2022

  29. [37]

    Majority is not enough: Bitcoin mining is vulnerable,

    I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is vulnerable,” COMMUN ACM, vol. 61, no. 7, pp. 95–102, 2018

    2018

  30. [38]

    Selfish mining in Ethereum,

    J. Niu and C. Feng, “Selfish mining in Ethereum,” in ICDCS, July 2019, pp. 1306–1316

    2019

  31. [39]

    Fruitchains: A fair blockchain,

    R. Pass and E. Shi, “Fruitchains: A fair blockchain,” in PODC, 2017, pp. 315–324

    2017

  32. [40]

    Asymptotically optimal validated asynchronous Byzantine agreement,

    I. Abraham, D. Malkhi, and A. Spiegelman, “Asymptotically optimal validated asynchronous Byzantine agreement,” in PODC, 2019

    2019

  33. [41]

    Simplex consensus: A simple and fast consensus protocol,

    B. Y . Chan and R. Pass, “Simplex consensus: A simple and fast consensus protocol,” in TCC, 2023

    2023

  34. [42]

    The Bitcoin backbone protocol: Analysis and applications,

    J. Garay, A. Kiayias, and N. Leonardos, “The Bitcoin backbone protocol: Analysis and applications,” in Eurocrypt, 2015

    2015

  35. [43]

    Ouroboros: A provably secure proof-of-stake blockchain protocol,

    A. Kiayias, A. Russell, B. David, and R. Oliynykov, “Ouroboros: A provably secure proof-of-stake blockchain protocol,” in CRYPTO, 2017

    2017

  36. [44]

    Lay down the common metrics: Evaluating Proof-of-Work consensus protocols’ security,

    R. Zhang and B. Preneel, “Lay down the common metrics: Evaluating Proof-of-Work consensus protocols’ security,” in S&P, 2019

    2019

  37. [45]

    Do the rich get richer? fairness analysis for blockchain incentives,

    Y . Huang, J. Tang, Q. Cong, A. Lim, and J. Xu, “Do the rich get richer? fairness analysis for blockchain incentives,” in SIGMOD, 2021

    2021

  38. [46]

    Optimal selfish mining strategies in Bitcoin,

    A. Sapirshtein, Y . Sompolinsky, and A. Zohar, “Optimal selfish mining strategies in Bitcoin,” in FC, 2017

    2017

  39. [47]

    On the security and performance of Proof of Work blockchains,

    A. Gervais, G. O. Karame, K. W ¨ust, V . Glykantzis, H. Ritzdorf, and S. Capkun, “On the security and performance of Proof of Work blockchains,” in CCS, 2016

    2016

  40. [48]

    On the necessity of a prescribed block validity consensus: Analyzing Bitcoin unlimited mining protocol,

    R. Zhang and B. Preneel, “On the necessity of a prescribed block validity consensus: Analyzing Bitcoin unlimited mining protocol,” in CoNEXT, 2017

    2017

  41. [49]

    HotShot network,

    “HotShot network,” https://github.com/EspressoSystems/HotShot/blob/ develop/docs/HotShotDocs/main.md, retrieved Oct, 2024

    2024

  42. [50]

    Nar- whal and Tusk: a DAG-based mempool and efficient BFT consensus,

    G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, “Nar- whal and Tusk: a DAG-based mempool and efficient BFT consensus,” in Eurosys, 2022

    2022

  43. [51]

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

    R. Neiheiser, M. Matos, and L. Rodrigues, “Kauri: Scalable BFT consensus with pipelined tree-based dissemination and aggregation,” in SOSP, 2021

    2021

  44. [52]

    Scaling blockchain consensus via a robust shared mempool,

    F. Gai, J. Niu, I. Beschastnikh, C. Feng, and S. Wang, “Scaling blockchain consensus via a robust shared mempool,” in ICDE, 2023

    2023

  45. [53]

    BFT protocol forensics,

    P. Sheng, G. Wang, K. Nayak, S. Kannan, and P. Viswanath, “BFT protocol forensics,” in CCS, 2021

    2021

  46. [54]

    State machine repli- cation scalability made simple,

    C. Stathakopoulou, M. Pavlovic, and M. Vukoli ´c, “State machine repli- cation scalability made simple,” in Eurosys, 2022

    2022

  47. [55]

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

    J. Neu, E. N. Tas, and D. Tse, “Ebb-and-flow protocols: A resolution of the availability-finality dilemma,” in S&P, 2021. 15

    2021

  48. [56]

    Damysus: streamlined BFT consensus leveraging trusted components,

    J. Decouchant, D. Kozhaya, V . Rahli, and J. Yu, “Damysus: streamlined BFT consensus leveraging trusted components,” in Eurosys, 2022

    2022

  49. [57]

    Streamlet: Textbook streamlined blockchains

    B. Y . Chan and E. Shi, “Streamlet: Textbook streamlined blockchains.” IACR Cryptol. ePrint Arch. , 2020

    2020

  50. [58]

    Thunderella: Blockchains with optimistic instant confirmation,

    R. Pass and E. Shi, “Thunderella: Blockchains with optimistic instant confirmation,” in Eurocrypt, 2018

    2018

  51. [59]

    Bounds on the time to reach agreement in the presence of timing uncertainty,

    H. Attiya, C. Dwork, N. Lynch, and L. Stockmeyer, “Bounds on the time to reach agreement in the presence of timing uncertainty,” J. ACM, vol. 41, no. 1, p. 122–152, jan 1994

    1994

  52. [60]

    HotStuff: BFT consensus in the lens of blockchain,

    M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “HotStuff: BFT consensus in the lens of blockchain,” arXiv preprint arXiv:1803.05069, 2018

    2018 arXiv

  53. [61]

    Flexible advancement in asynchronous BFT consensus,

    S. Liu, W. Xu, C. Shan, X. Yan, T. Xu, B. Wang, L. Fan, F. Deng, Y . Yan, and H. Zhang, “Flexible advancement in asynchronous BFT consensus,” in SOSP, 2023

    2023

  54. [62]

    Goldfish: No more attacks on Proof-of-Stake Ethereum,

    F. D’Amato, J. Neu, E. N. Tas, and D. Tse, “Goldfish: No more attacks on Proof-of-Stake Ethereum,” Cryptology ePrint Archive , 2022

    2022

  55. [63]

    SoK: Transparent dishonesty: front-running attacks on blockchain,

    S. Eskandari, S. Moosavi, and J. Clark, “SoK: Transparent dishonesty: front-running attacks on blockchain,” in FC, 2020

    2020

  56. [64]

    Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability,

    P. Daian, S. Goldfeder, T. Kell, Y . Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels, “Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability,” in S&P, 2020

    2020

  57. [65]

    Markov Decision Process (MDP),

    “Markov Decision Process (MDP),” https://en.wikipedia.org/wiki/ Markov decision process, retrieved Oct, 2024

    2024

  58. [66]

    M. L. Puterman, Markov decision processes: discrete stochastic dynamic programming. John Wiley & Sons, 2014

    2014

  59. [67]

    Sigaud and O

    O. Sigaud and O. Buffet, Markov decision processes in artificial intel- ligence. John Wiley & Sons, 2013

    2013

  60. [68]

    State machine replication in the Libra blockchain,

    M. Baudet, A. Ching, A. Chursin, G. Danezis, F. Garillot, Z. Li, D. Malkhi, O. Naor, D. Perelman, and A. Sonnino, “State machine replication in the Libra blockchain,” The Libra Assn., Tech. Rep , vol. 1, no. 1, 2019

    2019

  61. [69]

    EIP 1011: Hybrid Casper FFG,

    D. Ryan and C.-C. Liang, “EIP 1011: Hybrid Casper FFG,” ThunderCore, April 2018. [Online]. Available: https://eips.ethereum. org/EIPS/eip-1011

    2018

  62. [70]

    Cosmos: A network of distributed ledgers,

    J. Kwon and E. Buchman, “Cosmos: A network of distributed ledgers,” 2016

    2016

  63. [71]

    The availability-accountability dilemma and its resolution via accountability gadgets,

    J. Neu, E. N. Tas, and D. Tse, “The availability-accountability dilemma and its resolution via accountability gadgets,” in FC, 2022

    2022

  64. [72]

    Peerreview: Practical accountability for distributed systems,

    A. Haeberlen, P. Kouznetsov, and P. Druschel, “Peerreview: Practical accountability for distributed systems,” ACM SIGOPS , vol. 41, no. 6, pp. 175–188, 2007

    2007

  65. [73]

    Accountability and forensics in blockchains: XDC consensus engine DPoS 2.0,

    G. Wang, J. Wang, L. Lai, and F. Yu, “Accountability and forensics in blockchains: XDC consensus engine DPoS 2.0,” arXiv preprint arXiv:2108.01420, 2021. APPENDIX A. Discussion

    2021 arXiv

  66. [74]

    The results already show the degradation of leadership democracy under attack and also reveal some insights for building better chained BFT protocols

    Leadership Democracy during Asynchrony: This paper focuses on analyzing leadership democracy when the network is synchronous ( i.e., after GST). The results already show the degradation of leadership democracy under attack and also reveal some insights for building better chai...

  67. [75]

    Besides, the round-robin policy is another popular one, where the leader in each view is pre-determined rather than randomly selected

    Leadership Democracy under Round Robin Policy: This paper focuses on the random leader election policy since it is commonly used in blockchains, especially permissionless ones [20], [21], [22], [49]. Besides, the round-robin policy is another popular one, where the leader in e...

  68. [76]

    #𝐵!"$ (a) The protocol rules. 𝐵!𝐵!

    Future Directions for Chained BFT Consensus: We provide several future directions for protocol design. Evaluating design components under attack. Our work advocates the need for more attention on leadership democ- racy. In particular, our evaluation results illustrate that exi...

  69. [77]

    The following are the rules of 2CHS

    Two-chain HotStuff: Two-chain HotStuff originates from Casper FFG, which adds chaining based on Tendermint and extends to a two-chain locking mechanism. The following are the rules of 2CHS. • Proposing rule. The leader proposes a block B to extend the highest certified block. ...

  70. [78]

    #𝐵!"$𝐵!"% 𝐵!

    Chained HotStuff: Chained HotStuff (CHS) [9] cre- atively adopts a three-chain committing rule (rather than 𝐵!𝐵!"#𝐵!"$𝐵!"% 𝐵!"& Figure 8: The chained blocks in CHS. Block Bv, Bv+1 and Bv+2 are consecutive blocks. Nodes will commit Bv when receiving proposal of Bv+3, and lock a...

  71. [79]

    Fast- HotStuff adds a small overhead to the block during an unhappy path (when the primary fails)

    Fast-HotStuff: Fast-HotStuff [12] has lower latency compared to 2CHS and is resilient to a forking attack. Fast- HotStuff adds a small overhead to the block during an unhappy path (when the primary fails). The protocol rules are as follows: • Proposing rule. A leader proposes ...

  72. [80]

    proposed a sim- ple block proposing and voting rule : the longest cer- tified chain rule

    Streamlet: Streamlet [57], Chan et al. proposed a sim- ple block proposing and voting rule : the longest cer- tified chain rule. Streamlet is built based on Streamlined blockchains [11], and has simplified the protocols by removing the notion of freshness. • Proposing rule . T...

Pith tools

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