What is Timeout Commit and Why is it useful?

[adizere]

Context

This question originally applied to malachite-simulator (code ref). But since it also applies more generally to the design of timeouts in the core library (not Quint specs), answering it here.

Question

Why is it that Commit timeout specifically times out instantly? (code ref)

Answer

Background

The Malachite implementation of Tendermint comprises 3 timeouts (timeoutPropose, timeoutPrevote and timeoutPrecommit as in the whitepaper) plus 1 extra timeout.

The extra timeout is Commit. This timeout is optional (not necessary strictly for Tendermint), and does not appear in the whitepaper.

Usefulness

It's unclear if this timeout will be needed in Starknet sequencer. We had discussed about it with the Starkware team a long while ago, before starting Malachite implementation. I recall we decided to add it in Malachite because it is an easy lift and it proved useful historically in other Tendermint-based apps from our experience.

The way timeout Commit is usually employed is to implement an "extra waiting time" once a validator gathered a certificate and reached a decision for a given height i.e., 2f+1 matching precommits. Specifically, once a validator has locally gathered the certificate for a decision at height H, it can (as in the whitepaper) simply move on to the next height H+1. In proof of stake systems, however, the exact composition of the 2f+1 precommits in the certificate is very important: Only those validators that have a precommit among the 2f+1 will receive rewards for having voted and participated in consensus. The other validators -- potentially f of them, because Tendermint works in the n=3f+1 model -- may never a reward because their precommit votes may not be in the initial set of 2f+1 gathered votes.

By design, a validator should not wait for more than 2f+1 because the other f may never arrive (may be faulty). However, the validator could wait for a small predefined window of time -- the timeout Commit parameter -- to give the chance for the late f validators to broadcast their precommit vote and to arrive at the other nodes in the network, thus being included in a certificate for height H (which will have >2f+1 precommits). Again, this window of waiting is optional, and useful for proof of stake systems where rewards are based on precommit counting, roughly speaking.

Why is the timeout triggering instantly in the malachite-simulator prototype code?

Briefly, because we want the system to be responsive. In other words, we use a timeout Commit = 0. (code ref). In that prototype, we don't care about gathering more stake or precommits from validators. We want to proceed as fast as possible.

Side note on responsiveness

This timeout was a big source of confusion, and led some people to think that Tendermint is not a responsive BFT consensus protocol. This is false: Tendermint is a responsive BFT consensus algorithm.

Employing the timeout Commit to a non-zero value will lead the consensus protocol, however, to employ a fixed timeout on the critical path of block building, which does make such a configuration non-responsive. This configuration is not even specified in the whitepaper, but is possible and sometimes useful, accepting the tradeoff that the deployment would not be responsive.

[cason]

An important remark here that in CometBFT the timeoutCommit starts when a block is ready to be delivered to the application, namely when it gets 2f + 1 voting-power equivalent Precommits, and expires when the block is (hopefully) already processed by the application and the next height is started.

So, we indeed collect extra Precommits for a already decided block, but the block is delivered to the application once it is decided. The Precommits for block H, both the required 2f + 1 and the extra ones received during this timeout, are then included in the successive block H+1, not delivered to the application together with block H.

For this reason, if processing a block takes X time, on average, and timeoutCommit is set to X, there is no actual delay in most cases. The point is that while the application is processing the block, the consensus layer collect extra Precommits.

[adizere]

I was not aware of that optimization, thank you for the extra context Daniel, super helpful!