--- title: 'Tendermint: Byzantine Fault-Tolerant Consensus' url: https://www.emergentmind.com/topics/tendermint type: topic --- # Tendermint: Byzantine Fault-Tolerant Consensus Searching arXiv for recent and foundational Tendermint papers to ground the article. Tendermint is a Byzantine fault-tolerant consensus protocol and consensus engine for blockchain-style state machine replication. In the literature it is treated as a permissioned BFT protocol, best described as a variant of PBFT, structurally close to PBFT but with deterministic leader rotation, a common-case messaging pattern related to Bracha’s Byzantine reliable broadcast, and deterministic finality under eventual synchrony with the standard threshold \(f < n/3\) [1707.01873]. Subsequent work formalized its protocol logic, analyzed liveness pathologies and their fixes, and later established machine-checked safety and universally composable termination results, making Tendermint a central reference point in the theory and engineering of blockchain BFT consensus [1809.09858][2510.01097]. ## 1. Position in the Byzantine consensus landscape Tendermint belongs to the classical BFT family: it is leader-based, voting-based, and intended for settings with identified validators. In the survey literature it is grouped with permissioned blockchain systems and characterized as a concrete, implemented instance of a “classical” Byzantine fault-tolerant blockchain consensus protocol [1707.01873]. It is therefore distinct from crash-only protocols such as Raft-based deployments, and also from probabilistic or hash-power-based protocols in the Nakamoto family, which do not provide deterministic finality under the same assumptions [1707.01873]. A recurring architectural feature is the separation between the network/consensus layer and the application/state-machine layer. In one line of work, Tendermint Core is presented as a general-purpose BFT consensus and networking engine that can be coupled, through ABCI, with arbitrary deterministic state machines, including relational DBMS backends [2210.04484]. This suggests that Tendermint is not merely a blockchain “protocol” in the narrow sense, but also a reusable replication substrate for deterministic applications that require agreement on an ordered stream of transactions. The literature also places Tendermint in a broader comparative taxonomy. HotStuff treats it as a blockchain-era BFT protocol with a simple rotating leader and a Two-Chain commit rule, while later protocol proposals use it either as a baseline for comparison or as a component to be embedded under higher-level constructions [1803.05069][1903.01589]. In this comparative role, Tendermint is frequently the representative of deterministic-finality, partially synchronous, \(n=3f+1\) BFT consensus. ## 2. Protocol structure and state-transition logic At a high level, Tendermint runs one consensus instance per block height. Clients gossip transactions to validator nodes, validators locally construct candidate blocks from gossiped transactions, and the protocol orders those blocks through proposer election and quorum voting [1707.01873]. This differs from PBFT’s original client-to-all-replicas request pattern, and it is coupled to an external validity condition: the protocol is parameterized by a deterministic predicate \(V(\cdot)\), and validators vote only for blocks that satisfy locally checkable validity, including transaction receipt and validation [1707.01873]. The protocol is commonly described through the round-based sequence propose \(\rightarrow\) prevote \(\rightarrow\) precommit \(\rightarrow\) commit, with one proposer per round and a commit condition requiring at least two-thirds of voting power in both prevote and precommit [2410.16720]. Another formal presentation decomposes each epoch into PRE-PROPOSE, PROPOSE, and VOTE rounds, with local variables \(lockedValue_i\), \(lockedEpoch_i\), \(validValue_i\), and \(validEpoch_i\) carrying safety-critical information across epochs [1809.09858]. These presentations are closely related: both emphasize that safety depends on locking and that liveness depends on how new proposals interact with previously locked values. The most distinctive feature relative to PBFT is rotating leadership. Rather than retaining a primary until an explicit view-change protocol is triggered, Tendermint deterministically rotates the leader after every block or round, inspired by the Spinning protocol, and embeds aspects of view change into the common path [1707.01873]. If a validator does not receive a valid proposal before its timeout expires, it does not switch to a separate protocol instance; instead it continues in the voting pattern and may vote for `nil`, which allows progress without waiting indefinitely on a faulty proposer [1707.01873]. Locking is central. Once a validator observes the relevant quorum support for a block, it locks that block and restricts future votes accordingly. Formal analyses describe the key invariants in terms of `lockedValue`, `lockedRound`, `validValue`, and `validRound`, or their epoch-indexed analogues [1809.09858]. This mechanism is what prevents conflicting blocks at the same height from both gathering commit support from correct validators. ## 3. System model, thresholds, and correctness guarantees Tendermint is analyzed in the eventually synchronous, or partially synchronous, model of Dwork, Lynch, and Stockmeyer. Before a Global Stabilization Time, message delays may be arbitrary; after that point, delays are bounded by an unknown but fixed constant. Safety must hold in all executions, while liveness is guaranteed only after stabilization [1707.01873][2510.01097]. The standard resilience threshold is the classical BFT bound \[ f < \frac{n}{3}, \qquad n \ge 3f+1. \] Quorum sizes are correspondingly \(2f+1\), and the underlying correctness arguments rely on Byzantine quorum intersection: any two quorums intersect in at least one correct validator [1707.01873][1803.05069]. The survey literature summarizes Tendermint’s resilience as follows [1707.01873]: | Property | Crash faults | Byzantine faults | |---|---:|---:| | Safety | \(t < n/3\) | \(f < n/3\) | | Liveness | \(t < n/3\) | \(f < n/3\) | Under these assumptions, the protocol provides agreement, integrity, total order, and deterministic finality. Agreement means that if a correct validator commits a block at height \(h\), then every correct validator that commits at height \(h\) eventually commits the same block; in blockchain terms, correct validators do not end up on permanent forks [1707.01873]. Integrity and total order follow from the combination of external validity, reliable broadcast structure, and quorum intersection [1707.01873]. A later UC treatment sharpens the liveness statement under strategic message-delay attacks. In that model, Tendermint is shown to UC-realize an ideal functionality with bounded termination latency \[ T^\ast = \mathrm{GST} + O(f^2\Delta), \] provided that at most \(f e\) [1809.09858]. Second, validity propagation via `validValue` and `validEpoch` ensures that once some value has accumulated the relevant prevote support, future proposers continue to re-propose it until consensus converges [1809.09858]. Third, timeout growth is essential: if `timeoutPrevote` and related timers do not increase, eventual synchrony is not enough to guarantee progress [1809.09858]. HotStuff recasts these issues in a unifying framework. There Tendermint appears as a Two-Chain protocol that shares PBFT-style safety rules but does not achieve optimistic responsiveness. In that interpretation, Tendermint and Casper require a mandatory \(\Delta\) delay before each leader proposal, because otherwise a simple two-phase protocol can livelock when leaders do not learn about higher locks in time [1803.05069]. The contrast with HotStuff is structural: HotStuff adds an extra phase to preserve simple leader replacement while regaining responsiveness; Tendermint preserves the two-phase structure and pays for it with delay-based liveness [1803.05069]. Later formal methods work strengthened the picture. Tendermint is cited as one of the few complex consensus protocols whose safety has been formally verified, using IVy and quorum-intersection-based inductive invariants [2403.16637]. A separate line of work factors view synchronization into an explicit abstraction and shows that the resulting synchronizer is strong enough to guarantee liveness for Tendermint in the partially synchronous model, while also yielding protocol-specific latency bounds [2008.04167]. Together, these results move Tendermint from an initially promising PBFT variant with an undocumented liveness fix toward a protocol with machine-checked safety and composable termination analysis. ## 5. Implementations, systems integration, and application domains Tendermint has been used as a consensus and replication layer under several distinct system architectures. One recurring pattern is the separation of dissemination from execution. In a “relational blockchain” design, Tendermint Core orders transactions and drives a deterministic state machine implemented by PostgreSQL or MySQL through ABCI callbacks such as `BeginBlock`, `DeliverTx`, `Commit`, and `Query` [2210.04484]. There the cost of Tendermint becomes measurable relative to the underlying DBMS: synchronous use can impose very large overheads on lightweight workloads, whereas asynchronous operation and batching reduce the overhead to a small constant factor on heavier workloads such as TPC-C [2210.04484]. This suggests that Tendermint’s practicality depends strongly on how the application drives the consensus engine. Another architectural role appears in BigchainDB-based systems. In a cyber-physical healthcare stack, Tendermint sits under BigchainDB as the consensus engine, while IPFS stores large encrypted medical files and MongoDB supplies local persistence [2307.13603]. The paper presents Tendermint as the component responsible for BFT consensus, fast finality, immutable ordering of EHR asset transactions, and block-level replication. The same source also contains an instructive misconception: it claims the architecture “can recover the data if \(2/3\) of nodes are failed,” a statement that does not align with formal Tendermint BFT theory, which requires at least two-thirds honest voting power and tolerates up to roughly one-third Byzantine validators [2307.13603]. The discrepancy highlights a common confusion between replicated data availability and consensus fault tolerance. Tendermint is also used as a modular subprotocol. Albatross invokes Tendermint only for macro blocks at the end of each batch, using it as a periodic deterministic-finality gadget, validator-set update mechanism, and synchronization backbone, while micro blocks are produced by a speculative PoS layer [1903.01589]. NodeOP builds a dedicated Layer 2 chain whose consensus is Tendermint BFT, with every general node operator also acting as a Tendermint validator and with task allocation and incentives optimized by an agent-based model layered above the chain [2410.16720]. In wireless settings, ReduceCatch adapts Tendermint to ad hoc LoRa-based networks; the paper distinguishes a Tendermint1 variant using N-to-N vote patterns and a Tendermint2 variant using N-to-1 plus 1-to-N communication, with the latter typically better suited to wireless contention patterns [2412.05512]. A recent example aimed directly at inclusion and ordering power is AMP, which places a multi-proposer dissemination layer on top of Tendermint. There, validators no longer maintain a mempool; instead, external proposers broadcast payloads to all validators, validators attest to payload identifiers through vote extensions, and Tendermint decides commit certificates from which the payload set for the next block is derived [2605.23677]. This design is explicitly motivated by bounded inclusion guarantees and by reducing unilateral control of block assembly. ## 6. Comparative interpretation, fairness, and continuing research significance Comparative protocol theory has repeatedly used Tendermint as a reference point. HotStuff places it alongside Casper as a Two-Chain protocol with a simple rotating leader and mandatory delay, and presents HotStuff as preserving the attractive leader simplicity while avoiding the non-responsive liveness regime [1803.05069]. Morpheus, by contrast, treats Tendermint as the archetypal “standard” BFT SMR protocol against which a morphing blockchain/DAG protocol should be measured: in that account, Tendermint is competitive in low-throughput settings but “does not perform well during high-throughput” compared with modern DAG-based designs [2502.08465]. Both comparisons reinforce the same structural point: Tendermint occupies the classical deterministic-finality corner of the design space, with strong safety, clear quorums, and moderate communication complexity, but without the responsiveness or amortized throughput properties later protocols pursue. Fairness has emerged as a separate axis on which Tendermint does not automatically provide strong guarantees. The analysis of Tendermint-core blockchains proves that there exists an eventual fair rewarding mechanism if and only if the system is eventual synchronous, and it also shows that the original Tendermint rewarding is not fair, whereas a modified protocol with modulable timeouts can be eventually fair [1805.08429]. A different simulation-based study places Tendermint as the ordering service inside Hyperledger Fabric and shows that, even while preserving safety and liveness, network delay attacks and Byzantine proposer behavior can violate client-fairness and several order-fairness properties [2403.14342]. These results make explicit that BFT safety and liveness do not imply fairness of transaction inclusion or ordering. Tendermint’s continuing importance therefore lies in a combination of roles. It is a practical BFT engine for deterministic state machine replication, a canonical benchmark for later partially synchronous protocols, a target of increasingly strong formal verification techniques, and a substrate on which higher-level systems experiment with validator management, multi-proposer dissemination, application-specific execution, and fairness-aware ordering [2210.04484][2510.01097]. The literature consistently presents it as a protocol whose core assumptions are classical—identified validators, \(n \ge 3f+1\), eventual synchrony, quorum intersection—but whose influence extends well beyond the original blockchain setting. Source: https://www.emergentmind.com/topics/tendermint