timeout params [Tracking issue]

[melekes]

[Discussion]

Summary

timeout_propose = "3s"
timeout_propose_delta = "500ms"
timeout_prevote = "1s"
timeout_prevote_delta = "500ms"
timeout_precommit = "1s"
timeout_precommit_delta = "500ms"
timeout_commit = "1s"

skip_timeout_commit = false

When speaking about timeout parameters, there are multiple concerns.

1. We don't need that many parameters
2. App developers want consistency across validators, even though params may vary depending on validator's network topology and runtime
3. App developers want a way to set block intervals (think of it as if all validators set the same timeout_commit value).

Note there are other potential ways to align parameters in a network #1617.

Tasks

Beta Give feedback

1. Remove skip_timeout_commit in favor of setting timeout_commit to 0 #2891
   +0
   
2. Remove timeout_prevote & timeout_precommit in favor of calculating them from round_delta Remove BlockTimeIota and other Consensus Params from Config tendermint/tendermint#2920 (comment)
3. PBTS: Allow Application to Set BlockTimestamp #2655
   enhancement +1
4. consensus: investigate and define the relationship between timeouts #2547
   config consensus spec +3
   

So (1) will be solved by 1,2,3. (3) - by 4. (2) - by social consensus & external tools #1617

[sergio-mena]

These are my thoughts:

• Task 1. Fully agree
• Task 2. Makes sense in principle, although the relations pointed out in this comment are inequations, so they don't really tell you the value of some params in terms of others, but rather bounds (i.e., min or max values). I recently heard @cason say something along these lines.
  • Something I do see clearly here is that I don't see any practical reason not to merge timeout_prevote and timeout_precommit into one single value. As the events these timeouts relate to are vote reception (same number, similar size)
• Task 3. Fully agree with timeout_prevote_delta and timeout_precommit_delta (both relating to votes). Not 100% sure about timeout_propose_delta, as it has to do with a proposal and its block, which can be way bigger in size than votes.
• Task 4. Fully agree

[melekes]

@josef-widder @milosevic how feasible it is to actually calculate values of timeout_prevote (1s) & timeout_precommit (1s) from the round delta (500ms) - tendermint/tendermint#2920 (comment)? As @sergio-mena pointed out they define "min" values. But this is exactly what we're looking for! "min" values, which if validators fail to agree in round 0, get increased in round 1.

[melekes]

cc @ebuchman ^

[cason]

See #2547

[cason]

Something I do see clearly here is that I don't see any practical reason not to merge timeout_prevote and timeout_precommit into one single value. As the events these timeouts relate to are vote reception (same number, similar size)

They don't have similar sizes when we have vote extensions......

[cason]

So, jumping here later.

Timeouts should be based on the size of the messages they refer to.

timeout_propose is strictly dependent on the typical block size, it should be computed based on the maximum block size in a network. timeout_propose_delta is the correction for this value, when underestimated. This should also depend on the block size.

timeout_prevote is more an optimization than anything. It defines how much time we still wait, when failing to observe a 2/3+ quorum for the same value, for additional votes that might change our action (we may see a 2/3+ quorum if we wait a little longer). There is some important discussion regarding the removal of this timestamp, or at least ignoring it when we realize we can't get a 2/3+ quorum at all from the already received messages (typical case: 2/3+ prevotes for nil).

timeout_precommit is really relevant for liveness. It is not an optimization. Once we reach GST, i.e., the system respects the current timeouts, we need all correct validators to see a 2/3+ quorum of precommits in the case one correct validator has seen it. Without this, the system might incur in the hidden lock issue, which prevents progress.

Before vote extensions, there was no reason to consider that prevotes and precommits would have distinct latencies, as both are fixed-size messages. This changes with vote extensions.

[melekes]

• revert and deprecate feat(config)!: remove skip_timeout_commit (backport #2892) #2926 in v1
• deprecate timeout_commit on main