Fast Tendermint: Speeding Up a Foundational Consensus Protocol

Fast Tendermint: Speeding Up a Foundational Consensus Protocol Preston Vander Vos # Circle Research, USA

Daniel Cason # Circle Research, Switzerland

arXiv:2608.13434v1 [cs.DC] 13 Aug 2026

Abstract Tendermint is among the most widely studied and deployed Byzantine fault-tolerant (BFT) consensus protocols, owing in part to its native leader-rotation mechanism that subsumes complex view changes. Like most partially-synchronous BFT protocols, Tendermint tolerates f < n/3 Byzantine processes and decides in three communication steps. Motivated by the push for lower-latency blockchains, a recent line of work shows that consensus can be solved in two communication steps when f < n/5. We present Fast Tendermint, an adaptation of Tendermint to the n > 5f setting that decides in two communication steps in the good case, while preserving Tendermint’s leader-rotation structure. Fast Tendermint collapses Tendermint’s prevote and precommit steps into a single voting step and merges the locked and valid state. We give proofs of agreement, validity, and termination, and a formal specification in Quint, a modern surface syntax for TLA+ , used to model-check the protocol. 2012 ACM Subject Classification Theory of computation → Distributed algorithms Keywords and phrases BFT consensus, Tendermint, partial synchrony, good-case latency

1

Introduction

Consensus is a fundamental abstraction in fault-tolerant distributed systems, at the core of state-machine replication (SMR) [17, 23]; Byzantine fault-tolerant (BFT) consensus [19] gained renewed attention with the advent of blockchain-based [22] SMR. Inspired by PBFT [8] and the DLS protocol [11], Tendermint [5] has become one of the most widely studied [2, 3, 4, 7] and deployed [10, 13, 16, 20] BFT consensus protocols. Unlike classical BFT protocols, where leader changes are an exceptional event triggered by suspected faults, Tendermint builds in leader rotation as every round designates a new leader. A direct consequence is that Tendermint avoids the complex view-change procedures of classical, PBFT-style protocols. Leader rotation and progress are handled by a single, uniform mechanism, simplifying both reasoning about the protocol and its implementation. Like most partially-synchronous BFT protocols, Tendermint assumes f < n/3 and consequently decides in three communication steps, a tight lower bound at this fault tolerance [1]. Motivated by the ongoing push to make blockchains ever faster, a recent line of work departs from this setting and instead operates with f < n/5 [9, 14, 21, 26] or below the f < n/3 threshold [24, 25]. At this reduced degree of fault tolerance, BFT consensus can be solved in two communication steps. In fact, there are algorithms with good-case latency of two communication steps with n ≥ 5f − 1 [1, 15]; however, the additional structural complexity required at this tighter bound appears to have discouraged its adoption in practice. Instead of creating a new 5f + 1 consensus protocol from scratch, can an existing, battletested protocol be adapted to this setting? We answer affirmatively with Tendermint, which has been deployed in production blockchains [16, 20] and has stood the test of time. Our contribution is the Fast Tendermint protocol, which can decide after one step of voting by receiving n − f precommits for a proposed value. Tendermint, by comparison, can decide after two steps of voting, n − f prevotes and then n − f precommits for a proposed value.

2

Fast Tendermint

We accompany it with rigorous safety and liveness proofs, as well as a formal verification in Quint [12], a modern surface syntax for TLA+ [18], used to model-check the protocol1 .

2

Model and Properties

Fast Tendermint relies on the same system model as the original Tendermint consensus algorithm [5]. We consider a system of n processes that communicate by exchanging messages. At most f processes may be Byzantine and behave arbitrarily; correct processes follow the protocol. Fast Tendermint requires n > 5f while the original Tendermint requires n > 3f . We assume a public-key infrastructure: protocol messages are signed, public keys are known to all processes, and correct processes only consider messages with valid signatures. We consider the partially-synchronous system model [11]: there is a bound ∆ and a Global Stabilization Time (GST ) such that every message sent after GST is reliably delivered within ∆. On top of it, we assume the same gossip communication property as Tendermint: Gossip communication: If a correct process sends a message m at time t, then all correct processes receive m before max{t, GST } + ∆. Furthermore, if a correct process receives a message m at time t, then all correct processes receive m before max{t, GST } + ∆. Fast Tendermint solves Byzantine consensus with external validity [6], a BFT consensus variation motivated by blockchain systems, defined by the following properties: Agreement (safety): No two correct processes decide on different values. Validity (safety): Decided values satisfy the application-specific predicate validate(). Termination (liveness): All correct processes eventually decide on a value.

3

Fast Tendermint Protocol

This section walks through Fast Tendermint, depicted in Algorithm 1, and highlights its differences from Tendermint. Fast Tendermint proceeds as a sequence of consensus instances, called heights, where each height decides a value. As heights are independent of each other, we focus on the operation of a single height and omit heights from the pseudo-code and messages. A height consists of one or more rounds, always starting from round 0. Each round is led by a designated process, the proposer, and is an attempt to reach a decision. A round in Fast Tendermint consists of two steps: propose and precommit. Each step has an associated message: PROPOSAL and PRECOMMIT. Compared with the original Tendermint, the intermediate prevote step and the associated message are dropped. The core state of a process in Tendermint is stored in two pairs of variables, storing a value and a round: locked and valid. A process locks a value when it sends a precommit for it, then rejects values that are not its locked one—locked is a safety mechanism. A value becomes valid when other processes may have locked it; a correct proposer re-proposes its highest known valid value as it should be an acceptable value—valid is a liveness mechanism. In Fast Tendermint, these two variables are merged into valid, which is a pair (round, value). Ordinary operation: Processes start a height from round r = 0, with empty valid = (−1, nil). Process proposer(r) calls getValue() to obtain a value v to propose, then broadcasts ⟨PROPOSAL, r, v, −1⟩ (line 15), where a broadcast also delivers the message to the sender. Upon receiving this proposal, a process applies the fresh-proposal rule (line 18): provided

1

Available at https://github.com/circlefin/formal-tendermint/tree/master/fast-tendermint.

P. Vander Vos and D. Cason

3

Algorithm 1 Fast Tendermint consensus: tolerates f Byzantine faults with n > 5f processes. 1: roundp := 0 2: stepp ∈ {propose, precommit} 3: decisionp := nil 4: validp := (−1, nil)

▷ (round, id(value))

5: function StartRound(round) 6: roundp ← round 7: stepp ← propose 8: if proposer(roundp ) = p then 9: if roundp > 0 then 10: WaitForValid(timeoutPrecommit(roundp )) 11: if validp .value = nil then 12: proposal ← getValue() ▷ Fresh proposals carry a full value v 13: else 14: proposal ← validp .value ▷ Re-proposals carry a value identifier id(v) 15: broadcast ⟨PROPOSAL, roundp , proposal, validp .round⟩ 16: else 17: schedule OnTimeoutPropose(roundp ) after timeoutPropose(roundp ) 18: upon ⟨PROPOSAL, roundp , v, −1⟩ from proposer(roundp ) while stepp = propose do 19: if validate(v) ∧ (validp .round = −1 ∨ validp .value = id(v)) then 20: broadcast ⟨PRECOMMIT, roundp , id(v)⟩ 21: else 22: broadcast ⟨PRECOMMIT, roundp , nil⟩ 23: stepp ← precommit 24: upon ⟨PROPOSAL, roundp , id(v), vr⟩ from proposer(roundp ) with 0 ≤ vr < roundp AND 2f + 1 ⟨PRECOMMIT, vr, id(v)⟩ while stepp = propose do 25: if validp .round ≤ vr ∨ validp .value = id(v) then 26: if validp .round ≤ vr then 27: validp ← (vr, id(v)) 28: broadcast ⟨PRECOMMIT, roundp , id(v)⟩ 29: else 30: broadcast ⟨PRECOMMIT, roundp , nil⟩ 31: stepp ← precommit 32: upon 2f + 1 ⟨PRECOMMIT, roundp , id(v)⟩ with roundp > validp .round do 33: validp ← (roundp , id(v)) 34: upon n − f ⟨PRECOMMIT, r, ∗⟩ for the first time with r ≥ roundp do 35: schedule OnTimeoutPrecommit(r) after timeoutPrecommit(r) 36: upon ⟨PROPOSAL, r, v, −1⟩ from proposer(r) AND n − f ⟨PRECOMMIT, r′ , id(v)⟩ do 37: decisionp ← v 38: function WaitForValid(timeout) ▷ Run by the proposer of rounds > 0 39: while (validp .round < roundp − 1) ∧ ! timeout.elapsed() do 40: if 2f + 1 ⟨PRECOMMIT, r, id(v)⟩ with r > validp .round then 41: validp ← (r, id(v)) 42: function OnTimeoutPropose(round) 43: if round = roundp ∧ stepp = propose then 44: broadcast ⟨PRECOMMIT, roundp , nil⟩ 45: stepp ← precommit 46: function OnTimeoutPrecommit(round) 47: if round ≥ roundp ∧ decisionp = nil then 48: StartRound(round + 1)

validate(v) holds, and since valid is empty, it broadcasts ⟨PRECOMMIT, r, id(v)⟩, where id(v) is a short unique identifier of v. Once the proposal and n − f matching precommits for id(v) have been received, the decision rule (line 36) fires and the process decides v. Faulty proposer: As in Tendermint, non-proposer processes schedule a timeout when starting round r (line 17). If it expires before a proposal is received, the process broadcasts

4

Fast Tendermint

⟨PRECOMMIT, r, nil⟩. A faulty proposer can also equivocate, proposing different values to different processes; this may produce conflicting votes. To handle both situations, whenever a process receives n − f precommits for any value, the quorum any rule (line 34) schedules a timeout. If it expires before a decision is reached, the process starts the next round r + 1. Valid values: A value is valid in a round if no other value can be decided in that round. In Tendermint, a value is valid if it receives n − f prevotes; in Fast Tendermint, if it receives 2f + 1 precommits from the same round, as proven in Lemma 2. When this happens for id(v) in the process’s current round, the observation rule (line 32) sets valid = (roundp , id(v)). It can also happen for a previous round vr < roundp , as part of the re-proposal rule (line 27). A process with a non-empty valid value rejects, by default, any received proposal for a different value, broadcasting a ⟨PRECOMMIT, r, nil⟩; the exception to this rule is described next. Re-proposals: A proposer with a non-empty valid value re-proposes it by broadcasting ⟨PROPOSAL, r, id(v), vr⟩, where id(v) is the valid value and vr the associated valid round. At a receiving process q, the re-proposal rule (line 24) is activated provided that the 2f + 1 precommits from round vr supporting the re-proposal were received. They can override a conflicting validq if vr ≥ validq .round, in which case q broadcasts ⟨PRECOMMIT, r, id(v)⟩. Round skipping: In Tendermint, late processes jump to a higher round r′ after receiving f + 1 messages from round r′ . In Fast Tendermint, for the sake of safety, the observation rule needs to capture valid values before a process moves to a higher round. For this reason, the quorum any rule, with an n − f quorum, is the only allowed path to skip rounds. Remarks: Fast Tendermint makes some additional optimizations. Re-proposals carry the value identifier id(v) rather than the full value v, so only the original fresh proposal carries v. This allows valid to be updated from 2f + 1 precommits alone, not requiring a proposal for v. The validate() predicate is only evaluated in the fresh-proposal rule; Theorem 4 explains how validity is ensured in other rules. The WaitForValid() method is introduced for the sake of liveness, as detailed in Lemma 5. Before proposing in a round r > 0, the proposer runs it for an amount of time so as to learn a valid value from round r − 1, if any.

4

Correctness Proofs

In the protocol, precommit messages and the valid state carry value identifiers id(v) rather than full values v. We assume id is collision-resistant, so id(v) = id(w) implies v = w. ▶ Lemma 1. Any two sets of n − f and 2f + 1 processes share at least one correct process. Proof. The two sets intersect in at least (n − f ) + (2f + 1) − n = f + 1 processes. Since at most f processes are faulty, at least one process in the intersection is correct. ◀ ▶ Lemma 2. If n − f processes precommit for id(v) in round r (v can be decided in round r), then no correct process sets valid = (r′ , id(w)) for any id(w) ̸= id(v) and r′ ≥ r. Proof. We prove the claim by induction on r′ , where r′ is the highest round that any correct process has entered. Since no correct process has entered any round > r′ , at most f precommits from faulty processes exist for rounds > r′ . Updates to valid in Fast Tendermint require 2f + 1 precommits in a round, so we can safely disregard rounds > r′ and prove the lemma by showing that no id(w) ̸= id(v) receives 2f + 1 precommits in any round r′ ≥ r. Base case 1 (r′ = r): By Lemma 1, the n − f processes that precommit for id(v) and the 2f + 1 processes that precommit for id(w) share at least one correct process. Correct processes only send one precommit per round, so id(w) = id(v).

P. Vander Vos and D. Cason

Base case 2 (r′ = r + 1): Denote by C the set of correct processes that join round r + 1. While in round r, processes in C receive n − f precommits for round r to trigger the quorum any rule. Since at most f correct processes did not precommit for id(v) in round r, and at most f processes are faulty, at least n − 3f > 2f precommits received by every process in C are for id(v). When receiving those messages, every process p in C has validp .round < roundp , as no id(w) ̸= id(v) receives 2f + 1 precommits in round r (Base case 1). Thus, by the observation rule, all processes in C set valid = (r, id(v)). At most f correct processes are not in C and there are at most f faulty processes, so at most 2f < 2f + 1 processes can precommit for id(w) ̸= id(v) in round r + 1. Inductive step (r′ > r+1): Assume for all rounds r′′ with r+1 ≤ r′′ < r′ , no id(w) ̸= id(v) received 2f + 1 precommits in round r′′ . We prove the lemma for round r′ . By the induction hypothesis, no process in C updated its valid to id(w) ̸= id(v) before round r′ . Therefore, processes in C that precommit in round r′ still have valid.value = id(v) and do not precommit for id(w) ̸= id(v). Again, there are at most f correct processes not in C and f faulty processes that can precommit for id(w), totaling 2f < 2f + 1. ◀ ▶ Theorem 3. Fast Tendermint satisfies Agreement. Proof. Suppose correct processes p and q decide v and w, respectively. By the decision rule, p (resp. q) observed n − f precommits for id(v) (resp. id(w)) in some round rp (resp. rq ). Without loss of generality, rp ≤ rq . Since id(v) received n − f precommits in round rp , by Lemma 2, no value other than id(v) can receive 2f + 1 precommits in any round r ≥ rp . This includes round rq , where q observed n − f > 2f + 1 precommits for id(w). Consequently, id(w) = id(v). By collision-resistance of id, w = v. ◀ ▶ Theorem 4. Fast Tendermint satisfies Validity. Proof. The fresh-proposal rule requires the application-specific validate(v) predicate to attest the validity of v in order to produce a precommit for id(v). The re-proposal rule and the decision rule do not check for validity. They assume that v is valid based on 2f + 1 previous precommits or n − f precommits for id(v), respectively. Let r be the earliest round in which any correct process precommits for id(v). Since the re-proposal rule requires 2f + 1 previous precommits for id(v) and at most f processes are faulty, it cannot be triggered. The precommits in round r from correct processes were therefore broadcast by the fresh-proposal rule, establishing validate(v). ◀ ▶ Lemma 5. Let p = proposer(r) be a correct process, r > 0, and vr be validp .round when p broadcasts its proposal. If p started round r at time t > GST + timeoutPrecommit(r − 1) and timeoutPrecommit(r) > 2∆, then vr is the maximum validq .round among every correct process q that joins round r. Proof. Since validq .round is updated to the current round via the observation rule or to a previous round via the re-proposal rule, the maximum value it can reach in a process q is its current round. Since this happens before q enters round r, vr ≤ r − 1. Correct processes start round r > 0 upon the expiration of timeoutPrecommit(r − 1). Since p scheduled it after GST , from the gossip communication property, every correct process q will schedule the timeout (line 35) at most ∆ after p, then enter round r by t + ∆. The last opportunity for a correct process q to update validq .round before entering round r is immediately before timeoutPrecommit(r − 1) expires, namely, by t + ∆. The same messages that lead q to update its valid are thus received by p by t + 2∆. Since

5

6

Fast Tendermint

WaitForValid() is run for at least 2∆, the proposer p updates vr to the maximum of validq .round among every correct process q, before broadcasting its proposal for round r. ◀ ▶ Lemma 6. If r > 0 is a round such that: (1) the first correct process enters round r at time t > GST + timeoutPrecommit(r − 1), (2) p = proposer(r) is a correct process, (3) timeoutPropose(r) > 2∆ + timeoutPrecommit(r), and (4) timeoutPrecommit(r) > 2∆, then all correct processes decide in round r. Proof. By the gossip communication property, since the system is past GST , every correct process enters round r by t + ∆, including the proposer p. So Lemma 5 applies and the round vr carried in p’s proposal is the maximum validq .round across all correct processes q. Proposer p broadcasts its proposal for v, which reaches every correct process by t + 2∆ + timeoutPrecommit(r). Condition (3) ensures timeoutPropose(r) has not elapsed, so every correct process accepts p’s proposal and broadcasts a precommit for id(v). The time from when the first correct process precommits until all correct processes have received all n − f correct precommits is no longer than 2∆ (< timeoutPrecommit(r) by condition (4)). This is because, by the gossip communication property, the proposal arrives within ∆ to all correct processes and every precommit between correct processes is received by all others within an additional ∆. It follows that every correct process decides v in round r. ◀ ▶ Theorem 7. Fast Tendermint satisfies Termination. Proof. Lemma 6 establishes sufficient conditions under which a round r yields a decision. It remains to show that these conditions are met within a bounded interval after GST . If a correct process triggers the decision rule at time t, by the gossip communication property every correct process receives the same messages and also triggers it by time max{t, GST } + ∆. Note that this rule is not restricted by the process’s current round. If no decision is reached prior to GST , Lemma 6 requires (1) GST to be reached before the first correct process to enter round r schedules timeoutPrecommit(r − 1), and (2) a correct process p to be proposer(r). Since processes advance past unsuccessful rounds and the proposer role rotates among all processes, after GST there is guaranteed to be a round that satisfies the necessary conditions. Finally, the adoption of adaptive timeouts, which increase over rounds, ensures that the timing conditions (3) and (4) of Lemma 6 are eventually satisfied, even if ∆ is unknown. ◀

5

Related Work

Fast Tendermint is one of several BFT protocols that aim to decide after a single voting round. Kudzu [24] operates with n ≥ 3f + 2t + 1 processes, committing in two rounds when at most t of them are faulty and in three rounds under the full f Byzantine budget. With t = f , its fast path is similar to that of Fast Tendermint. Hydrangea [25] parameterizes its fault budget with n ≥ 3f + 2c + k + 1 and commits in two rounds when at most ⌊(c + k)/2⌋ processes are faulty, where c bounds crash faults and k ≥ 0 is a tunable parameter. Retaining a failure-optimal slow path, as both protocols do, is an open question for Fast Tendermint. Alpenglow [14] claims a two-round commit while simultaneously tolerating up to 20% Byzantine and 20% crash faults, yet this combined guarantee has been refuted [25]. Moreover, once its erasure-coded dissemination layer is accounted for, end-to-end finality requires three communication rounds rather than two [26]. Minimmit [9] and BlueBottle [26], like Fast Tendermint, achieve two-round commits with n > 5f without a slow path. Minimmit’s view progression rule is similar to Fast Tendermint’s

P. Vander Vos and D. Cason

observation rule and may allow for further speed-up. BlueBottle belongs to a recent (relative to the original Tendermint) line of BFT consensus protocols that construct and decide over a directed acyclic graph (DAG) rather than a single leader’s chain. Two-round finality is in fact achievable at the tighter bound n ≥ 5f − 1 [1, 15] by identifying and excluding faulty leaders. However, the added logic required to achieve this bound, in addition to the complex view changes of these protocols, does not make the trade-off currently beneficial for real-world deployments.

6

Conclusion

Fast Tendermint adapts Tendermint to the n > 5f setting and decides in two communication steps in the good case while preserving Tendermint’s per-round leader rotation that subsumes complex view changes. The protocol drops the prevote step and merges locked and valid states into a single variable, yielding a minimal modification to a long-deployed consensus protocol. Future work includes its full implementation and experimental evaluation. References 1

2

3

4

5 6

7

8 9 10 11 12

Ittai Abraham, Kartik Nayak, Ling Ren, and Zhuolun Xiang. Good-case latency of byzantine broadcast: a complete categorization. In Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing, PODC’21, page 331–341, 2021. doi:10.1145/3465084.3467899. Andy Amoordon and Henrique Rocha. Presenting Tendermint: Idiosyncrasies, weaknesses, and good practices. In IEEE 2nd International Workshop on Blockchain Oriented Software Engineering (IWBOSE), 2019. doi:10.1109/IWBOSE.2019.8666541. Yackolley Amoussou-Guenou, Antonella Del Pozzo, Maria Potop-Butucaru, and Sara TucciPiergiovanni. Correctness of Tendermint-Core blockchains. In 22nd International Conference on Principles of Distributed Systems (OPODIS), pages 16:1–16:16, 2018. doi:10.4230/LIPIcs. OPODIS.2018.16. Yackolley Amoussou-Guenou, Antonella Del Pozzo, Maria Potop-Butucaru, and Sara TucciPiergiovanni. Dissecting Tendermint. In Proceedings of the 7th International Conference on Networked Systems (NETYS), pages 166–182, 2019. doi:10.1007/978-3-030-31277-0_11. Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on BFT consensus. 2018. arXiv:1807.04938. Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. Secure and efficient asynchronous broadcast protocols. In Advances in Cryptology — CRYPTO 2001, pages 524–541, 2001. doi:10.1007/3-540-44647-8_31. Daniel Cason, Enrique Fynn, Nenad Milosevic, Zarko Milosevic, Ethan Buchman, and Fernando Pedone. The design, architecture and performance of the Tendermint blockchain network. In 40th International Symposium on Reliable Distributed Systems (SRDS), pages 23–33, 2021. doi:10.1109/SRDS53918.2021.00012. Miguel Castro and Barbara Liskov. Practical Byzantine fault tolerance and proactive recovery. ACM Transactions on Computer Systems, 20(4):398–461, 2002. doi:10.1145/571637.571640. Brendan Kobayashi Chou, Andrew Lewis-Pye, and Patrick O’Grady. Minimmit: Fast finality with even faster blocks, 2026. arXiv:2508.10862. CometBFT Contributors. CometBFT: A distributed, Byzantine fault-tolerant state machine replication engine. https://github.com/cometbft/cometbft, 2026. Accessed: 2026-05-15. Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM, 35(2):288–323, 1988. doi:10.1145/42282.42283. Informal Systems. Quint: An executable specification language based on the temporal logic of actions. https://quint.sh, 2021. Accessed: 2026-05-15.

7

8

Fast Tendermint

13 14 15

16 17 18 19

20

21 22 23 24 25 26

Informal Systems and Circle Internet Financial. Malachite: Flexible BFT consensus engine in rust. https://github.com/circlefin/malachite, 2024. Accessed: 2026-05-15. Quentin Kniep, Jakub Sliwinski, and Roger Wattenhofer. Alpenglow. https://www.anza. xyz/alpenglow-1-1, 2025. Petr Kuznetsov, Andrei Tonkikh, and Yan X Zhang. Revisiting optimal resilience of fast byzantine consensus. In Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing, PODC’21, page 343–353, 2021. doi:10.1145/3465084.3467924. Jae Kwon and Ethan Buchman. Cosmos: A network of distributed ledgers, 2019. White paper. URL: https://v1.cosmos.network/resources/whitepaper. Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7):558–565, 1978. doi:10.1145/359545.359563. Leslie Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley, 2002. Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4(3):382–401, 1982. doi:10.1145/ 357172.357176. Gordon Y. Liao, Rachel Mayer, Adrian Soghoian, Sanket Jain, and Erik Tierney. Arc: An open layer-1 blockchain purpose-built for stablecoin finance. https://www.arc.io/litepaper, 2025. Accessed: 2026-05-15. Jean-Philippe Martin and Lorenzo Alvisi. Fast byzantine consensus (FaB Paxos). In Proceedings of the International Conference on Dependable Systems and Networks, DSN ’05, 2005. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. White paper. URL: https://bitcoin.org/bitcoin.pdf. Fred B. Schneider. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Computing Surveys, 22(4):299–319, 1990. doi:10.1145/98163.98167. Victor Shoup, Jakub Sliwinski, and Yann Vonlanthen. Kudzu: Fast and Simple HighThroughput BFT, 2025. arXiv:2505.08771. Nibesh Shrestha, Aniket Kate, and Kartik Nayak. Hydrangea: Optimistic two-round partial synchrony. Cryptology ePrint Archive, 2025. URL: https://eprint.iacr.org/2025/1112. Preston Vander Vos, Alberto Sonnino, Giorgos Tsimos, Philipp Jovanovic, and Lefteris Kokoris-Kogias. Bluebottle: Fast and robust blockchains through subsystem specialization, 2025. arXiv:2511.15361.

Related documents

• Distributed Coherence Ledgers: a Theoretical Framework for Blockchain as a Recursive Structural Substrate#98811
• LivingArena: Do LLMs Know What Other LLMs Don't? Peer-Probing as Scalable Evaluation#924626
• LivingArena: Do LLMs Know What Other LLMs Don't? Peer-Probing as Scalable Evaluation#920394
• Cassandra: Consensus with Partial Progress via Robust Partitionable View Synchronization#343450
• Agora: Toward Autonomous Bug Detection in Production-Level Consensus Protocols with LLM Agents#241560