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
Proposes to extend an optimistic node definition with the following condition:
If fork choice state of a node ended up without viable branches in a block tree because blocks from every such branch were transitioned from NOT_VALIDATED to INVALIDATED
The motivation of this change is to prevent different and potentially dangerous behaviours handling this situation. For instance, CL implementation may revert its justified checkpoint in the store back to the previous one which is prone to surround voting. By stating that node must stay optimistic in this case we protect from such cases.
This exact statement attempts to discern the optimistic sync nature of no viable branch state from any other ways in which a node may come to the same state. In cases when a node comes to a state without viable branches in a way that is not related to optimistic sync, a node should not be an optimistic node.
CL removes 31 and 0: C'' from its block tree leaving store.justified_checkpoint == C' and no branch satisfying it. In this case get_head returns C'.root as per the spec making honest validators propose atop and attest to C'.root instead of [24: VALID] (or a descendant of this block).
This PR suggest to keep a node optimistic if it came into this state via optimistic sync (as in the above scenario).
Alternatively, we may keep a node syncing (not optimistically) if it came into this state despite of a way the node did it. The idea is to prevent such a node from serving its validator client until it either recovers automatically by pulling the other viable chain from the network and switching to it or does the same after restart.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposes to extend an optimistic node definition with the following condition:
NOT_VALIDATEDtoINVALIDATEDThe motivation of this change is to prevent different and potentially dangerous behaviours handling this situation. For instance, CL implementation may revert its justified checkpoint in the store back to the previous one which is prone to surround voting. By stating that node must stay optimistic in this case we protect from such cases.
This exact statement attempts to discern the optimistic sync nature of no viable branch state from any other ways in which a node may come to the same state. In cases when a node comes to a state without viable branches in a way that is not related to optimistic sync, a node should not be an optimistic node.
cc @paulhauner @potuz @ajsutton