Closed mergify[bot] closed 5 days ago
[!IMPORTANT]
Review skipped
Bot user detected.
To trigger a single review, invoke the
@coderabbitai review
command.You can disable this status message by setting the
reviews.review_status
tofalse
in the CodeRabbit configuration file.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Problem
Network experiences a ~5sec block time when a proposer is offline/severely lagging behind. This is due to the current software default,
TimeoutPropose = 3s
, which means that when a proposer is unavailable, we spend 3s waiting for the proposal + 0.5s for round 0 prevote/precommit, so ~3.5s more than an average block.This software default of 3s was not conscious, and could've been updated along when
timeout_commit
was reduced to 500ms.See attached block dump during a period when 2 small validators went offline, and 4% of the blocks have elevated >5sec blocks. As a result, average block time is much higher than median block time during this period:
Median block time: 1.1144995 seconds Average block time: 1.35415654 seconds
Solution
Add a software override for TimeoutPropose to 1.5s. This should be way more than enough for a block where proposer is present. More aggressive value (e.g. 1s) is also possible and can be done in future upgrades.
This should reduce p98 (by ~30%) as well as average block time.
Requires a coordinated upgrade to maintain synchrony among validators (technically, not
state-breaking
butconsensus-breaking
)Author/Reviewer Checklist
state-breaking
label.indexer-postgres-breaking
label.PrepareProposal
orProcessProposal
, manually add the labelproposal-breaking
.feature:[feature-name]
.backport/[branch-name]
.refactor
,chore
,bug
.Summary by CodeRabbit
timeout_propose
consensus parameter, enhancing control over proposal timeouts.This is an automatic backport of pull request #1751 done by Mergify.