-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[EFM] Invalid Service Events shortly after Epoch Commit #5631
Comments
Let us consider the following suggestion:
ThoughtsThere is a subtle detail in the proposed specification that we have to get correctly in order to not break consensus.To paraphrase, we are suggesting to use finality as a decision criterion on whether or not the Epoch State Machine accepts a service event leading to a changed leader selection for a future view range. General Rule:Finality cannot be used as an input for evolving the Protocol State. Generally, only information in the fork that is currently being extended can be used to determine the validity of a block. There are exceptions where using finality is safe, but those are generally very edge-casey. Reasoning:
Suggested change.Above, I argued that this part of the suggested rule would break consensus:
Lets discuss how we can modify this rule to work out:
|
Problem description
Currently, the
EpochStateMachine
, which orchestrates the Epoch Happy Path and Fallback, has this behaviour:ProcessUpdate
on the Epoch State Machine (including the broken Service Event).EpochStateMachine
realizes that this is the first block of the epoch, so it performs an epoch transition (👉 code).EpochStateMachine
will encounter anInvalidServiceEventError
here so it transitions to EFM.In my opinion, the consensus protocol has formally reached an irreconcilable state at this point. I think our current implementation would probably just stop producing blocks. Reasoning:
FallbackStateMachine
, we do not re-apply the epoch transition.I think a similar aspect has previously come up for the EFM recovery. Specifically, the EFM recovery cannot change the modus operandi for view ranges that the
FallbackStateMachine
has already committed.Suggestion of Problem Solution
FallbackStateMachine
will enact Epoch transitions that have previously been committed by the happy path protocol.HappyPathStateMachine
andFallbackStateMachine
differ is the way they add new view ranges beyond the already committed.The text was updated successfully, but these errors were encountered: