proposer: QBFT round timeout based off of slot start time

[iurii-ssv]

QBFT round timeouts are set in RoundTimeout func and are different for every duty type.

For proposer-duty round 1 deadlines (times out) at 2s after QBFT instance start, while for committee-duty round 1 times out at 2s after slot start. This is an important difference because anchoring the deadline at duty start can be problematic for 2 reasons:

• different Operators end up with the different deadline times, and that can even lead to QBFT being unable to change round (round 1 -> round 2, for example)
• for proposer-duty it typically takes 1s-1.5s to perform RANDAO + Fetch-Block steps before the corresponding runner it starts QBFT instance, this results in the deadline for round 1 being set to 3s-3.5s and given that Ethereum block needs to be proposed and spread out through most of the network in under 4s that leaves almost no time for round 2 (and block-propagation) in case it is needed

Thus it would be better if we could allocate the 4s time-chunk after slot start the proposer-duty has at its disposal fairly between round 1 and round 2 by basing round timeout value off of slot start time. Since proposer-duty can realistically do 1 round-change at most we don't need to worry about implementing complex calculations for round 3 and beyond. I suggest we set round 1 timeout at 2.5s after slot start:

• it typically takes 1s-1.5s to perform RANDAO + Fetch-Block steps
• that leaves 1s-1.5s for QBFT round 1
• and in case we go into QBFT round 2 we have up to 1.5s to complete it (note, we should complete it well before 4s mark to have enough time to also complete QBFT post-consensus phase where the block gets signed and after that we need to broadcast signed block into Ethereum network)

Another idea would be to set round 1 timeout at 2.8s after slot start to "favor" round 1 and accommodate more aggressive ProposerDelay values.

IMPORTANT to note, we might want to classify this change as "fork" (it will not work very well with the SSV nodes of older versions in the same cluster due to round-timeouts targeting different times - 2s since slot start vs 2s since QBFT instance start)

Prior mentions/discussions of this feature can be found here:

• the original implementation PR description seems to imply that for "proposer" we didn't intend to change the behavior to be deterministic - Deterministic Round Timeout #1120
• also, the concern for "proposer" role specifically was raised during SIP discussion but probably was just left to deal with later
• and it seems the "proposer" duty is excluded as well from the ssv-spec repo PR that hasn't been merged btw

See also:

• a writeup on MEV considerations
• further proposer-duty improvements to consider in the future
• notes on how Anchor goes about it

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.

[iurii-ssv]

Just a note for future (once there is an agreement on this change) the MEV_CONSIDERAITONS.md doc needs to be adjusted accordingly:

• currently it assumes round 1 for proposer-duty times out at 2s into the slot
• rename MEVBoostRelayTimeout to BlockFetchTime and adjust the text that mentions it accordingly

[iurii-ssv]

Notes:

• whatever round 1 timeout value (eg. 2.5s) we choose for proposer duty, we need to verify it makes sense with the supported soft-timeout & proposer-delay values as was implemented in Proposal: only soft timeout and wait. use 1.8s default and allow flag to change. #2639
• (out of the scope of this issues, but is still a relevant consideration) once proposer-runner: QBFT liveness choked by Beacon node #1825 is resolved, we should consider implementing hard-timeout as well (and if we do, we probably would want to use exact deadlines instead of imprecise timeouts) at least for those QBFT participants who are not leading either of round 1, round 2

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.