-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Finality testing #989
Finality testing #989
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic looks good to me!
Two possible refactoring approaches:
-
Moving the assertions of changed finalized_epoch to
check_finality
. For example:def check_finality(state, prev_state, current_justified_changed, previous_justified_changed, finalized_is_current_justified, finalized_is_previous_justified): ... if finalized_is_current_justified: assert state.finalized_epoch == prev_state.current_justified_epoch assert state.finalized_root == prev_state.current_justified_root elif finalized_is_previous_justified: assert state.finalized_epoch == prev_state.previous_justified_epoch assert state.finalized_root == prev_state.previous_justified_root else: assert state.finalized_epoch == prev_state.finalized_epoch assert state.finalized_root == prev_state.finalized_root
-
As Decouple justification and finalization processing #925 decouples some justification and finalization, we can use
old_previous_justified_epoch
andold_current_justified_epoch
incheck_finality
for improving readability when comparing with the spec.
Add tests to explicitly test each of the 4 finality rules.
These are pretty heavy wrt timing but very important tests.
Note, built off of #988 so merge in #988 before review