While reading the spec polkadot-host-spec_v0.1.1.pdf is not clear if the host should track multiple or just one GRANDPA Pause/Resume consensus message per fork until the target block is finalized/imported. Another related question is, should we consider the GRANDPA Pause/Resume messages in the next change rule where we return the effective_number to never vote on chains with a number higher than the earliest handoff block number?
Add a comment
|
1 Answer
GRANDPA Pause/Resume have not been implemented in the substrate client code, therefore I would hold on implementing those for now.
We need to track multiple pending Pause / Resume signals per-fork, like we do for standard changes. Otherwise if finality is halted and there's a pending Pause / Resume signal, a further one being issued would make it impossible to import such a block and halt block production as well. We might be able to get away with just refusing to import a block that triggers a Pause while there is still a pending one, but e.g. if the pause is being triggered by an automated process (governance), then this could lead to the death loop explained earlier. It's also important to make sure we don't enact a Resume (on block depth) before the corresponding Pause been enacted (on finality). In that case next_change should also consider the earliest pending Pause when voting to finalize.
(Edited my original response significantly in light of your comment.)
-
According to the spec the
Pauseshould be enacted on block finalization andResumeshould be enacted on block import. As thePauseis enacted on block finalization should we consider it in thenext_change? Commented May 23, 2022 at 14:01 -
Edited my response. I hadn't checked that the spec defined when to enact
Pause/Resume. EnactingPausemessages on finality makes sense but it also makes the tracking considerably more complex. Also keep in mind that I haven't given that much thought to this yet since I don't have any plans of implementing this for now.– AndréCommented May 23, 2022 at 14:42