Introduce an explicit delay for QUALITY phase

[masih]

Capturing what was discussed in 11-12-2024 standup. Below is a summary of an idea originally proposed by @Kubuxu:

The duration of QUALITY phase is directly governed by delta. This phase will await the maximum length of timeout (or proceeds if there is strong quorum for the proposal).

The QUALITY phase is also very important to the progress velocity of an instance: insufficiently propagated QUALITY messages will lead to PREPARE for base, and most likely additional rounds. This behaviour was observed repeatedly in mainnet testing, specially during bootstrap phase, which is less than ideal. Because in bootstrap phase there really is no chain forkiness: the entire network is trying to decide on chains that have far lower propability of reorg than chains at steady state.

We could just increase the delta to make sure enough time is given to QUALITY messages to propagate but larger delta would result in further increase of the time it takes for an instance to terminate affecting every phase. Further, it would specifically impact CONVERGE phase, because that phase also waits for the timeout to pass regardless.

So the proposal here is to introduce a dedicated timeout for QUALITY phase, at least in the dynamic manifest for testing purposes. If proven to be successful we then proceed to propose the changes in a FIP etc.

The rationale for having this dedicated timeout in QUALITY phase only instead of both CONVERGE and QUALITY is that if QUALITY messages are sufficiently propagated and we still hit CONVERGE, then the chances are the chain is too forky and we are better off finalising on base and starting a new instance with a fresh proposal than trying to finalise on a nonbase in the current instance. Therefore, the chances are a faster CONVERGE and the start of a fresh instance results in higher overall progress velocity compared to delaying CONVERGE.

Of course, we can test this thesis at scale by introducing delay for both QUALITY and CONVERGE.

[BigLep]

2024-12-18 standup notes:

• agreed it's more elegant if it it's a multiplier. We'll do a float multiplier.
• this will be exposed for passive testing (will be in the manifest)