In this article we discuss the responsiveness property of consensus algorithms. We first explain what this property is and why it is important. Then, we explain why Tendermint is (optimistically) responsive.
Tendermint is one of the most widely used Byzantine fault-tolerant (BFT) consensus algorithms. It is currently implemented and maintained as part of the CometBFT engine. CometBFT is deployed in production in tens of app-chains in the Cosmos ecosystem, and has also found adoption in various other architectures (e.g. as a sequencer in Astria, as a data publication layer in Celestia, or as part of an L2 stack in Polygon).
Despite widespread use, there is some nuance and unclarity whether Tendermint algorithm is responsive. In this article our goal is simply to clarify that Tendermint is (optimistically) responsive.
The term responsiveness was primarily used to differentiate between responsive consensus protocols and non-responsive protocols (see Thunderella). For the former, the latency of these protocols depends on actual network delays. For the latter, latency depends on conservative time bounds. Conservative time bounds are usually considerably higher than actual network delays since they must account for worst-case delays. Consequently, non-responsive protocols tend to be slower than responsive protocols. For this reason, for example, Starknet considers responsiveness a relatively important property, and Espresso Systems has recently chosen their consensus protocol based on this property.
The most widely used BFT consensus protocols (Tendermint, HotStuff) work in a leader-based partially synchronous model. What does this mean? In these protocols, one validator, elected as leader, proposes the next block. The other validators vote to agree on this proposal. If the network is timely and the leader is honest, validators can reach a decision on the next block responsively.
However, the leader can be faulty, or the network may behave asynchronously. These protocols rely on a timeout to detect such behaviour and change the leader. The timeout values are usually conservative. An aggressive value can prevent progress, and may even render honest leaders seem faulty. Consequently, we can see that in the presence of faulty leaders (which includes situations of network asynchrony), these protocols cannot be responsive. This is why they are usually referred to as optimistically responsive: Their responsiveness is constrained by some optimistic conditions. This property was first formulated by HotStuff paper and later revisited in HotStuff-2. In this article, as is common in the distributed computing literature, we assume optimistic conditions when we talk about responsiveness.
The Tendermint consensus algorithm builds a blockchain by running one instance of consensus for each height of the blockchain. Inside each consensus instance, nodes proceed in rounds where each round has a dedicated leader. The leader proposes a block and validators engage in two all-to-all voting phases to agree on a block. Consequently, if the leader is honest and the network is synchronous, the decision is reached in only three network delays. Moreover, when a node decides in a round, it immediately starts with the next consensus instance (i.e., agreeing on the block for the next height).
On the other hand, if validators cannot reach a decision in the current round, due to faulty leader or network asynchrony, they move to the next round. Specifically, they change the leader and attempt again to build a block for this height. To ensure that eventually there will be a round with a decision, validators must wait for a timeout before moving to the next round. As a result, transitions between rounds are not responsive.
Given the above, we draw the observation that Tendermint is responsive in how it transitions from one consensus instance to another. The transition from one round to another, however, is not responsive. As a result, in scenarios when the network is synchronous, and leaders are honest, Tendermint acts responsively since validators reach a decision on a block in the first round of an instance.
Importantly, some evidence from live networks (see this brief empirical data from Osmosis for a recent example) suggests that this is the case nearly always (in more than 99% of the instances decision was reached in the first round). Furthermore, this is the case Espresso Systems mostly cares about and the one captured by the latest optimistic responsiveness property introduced by HotStuff-2.
Consequently, we conclude that, under optimistic conditions, Tendermint is a responsive consensus protocol.
In this post, we have discussed the responsiveness property of BFT consensus protocols. We explained what this property is and why it is important. Lastly, we have shown that the Tendermint consensus algorithm is (optimistically) responsive.
We are grateful for generous feedback on earlier versions of this essay to Dahlia Malkhi (UCSB); Fernando Pedone (USI); Jovan Komatovic (EPFL); Adi Seredinschi and Zarko Milosevic (Informal Systems).
CometBFT: Implementation of Tendermint consensus algorithm: https://github.com/cometbft/cometbft/
Yin et al., HotStuff: https://arxiv.org/pdf/1803.05069.pdf
Malkhi & Nayak, HotStuff-2: https://eprint.iacr.org/2023/397.pdf
Pass & Shi, Thunderella: https://eprint.iacr.org/2017/913.pdf
Buchman et al., Tendermint: https://arxiv.org/pdf/1807.04938.pdf