You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a block containing a finalizer_set change proposal becomes final, we shouldn't switch to the new finalizer_set immediately, as different finalizers may receive the message at different time, and therefore not use the same finalizer_set.
So when a block containing a finalizer_set change proposal becomes final, the new finalizer_set should be pending until the next new_view message, allowing all finalizers to use the same finalizer_set in the new view.
The text was updated successfully, but these errors were encountered:
Actually I think this should be delayed until another QC before switching finalizer sets. I think this is essential to maintain safety of the protocol despite finalizer set transitions.
EDIT: Actually waiting for another QC is not generally sufficient. We may need to wait for another 3-chain before it is safe to switch over to the new finality set.
We have an implementation of finalizer policy changes that works okay even if it is a little conservative. The proper algorithm can come later and is tracked in a new issue: AntelopeIO/spring#89.
When a block containing a
finalizer_set
change proposal becomes final, we shouldn't switch to the new finalizer_set immediately, as different finalizers may receive the message at different time, and therefore not use the same finalizer_set.So when a block containing a
finalizer_set
change proposal becomes final, the new finalizer_set should bepending
until the nextnew_view
message, allowing all finalizers to use the samefinalizer_set
in the new view.The text was updated successfully, but these errors were encountered: