-
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
Simplify/optimize process_registry_updates
#4081
Conversation
Looks good! |
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.
LGTM!
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.
LGTM
# Activate all eligible validators | ||
# [Modified in Electra:EIP7251] | ||
activation_epoch = compute_activation_exit_epoch(get_current_epoch(state)) | ||
for validator in state.validators: | ||
if is_eligible_for_activation(state, validator): |
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.
these three if
s could also be elif
s couldn't they, as they are mutually exclusive?
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.
Hmm yes they are mutually exclusive. Making those elif conditions is a good idea.
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.
I've made a PR for this:
No substantial changes in v1.5.0-beta.1, this PR just updates the tests. The optimisation described in this PR is already implemented in our single-pass epoch processing: - ethereum/consensus-specs#4081
When reviewing Prysm's implementation of
process_registry_updates
I noticed that they were processing registry changes in a single loop, rather than two like the spec does. After evaluating it, I came to the conclusion that it is safe. Since this is a simplification and an optimization that clients should implement, it would be best to include it in the specifications.These operations can be done in the same loop because they do not impact each other. For example, if a validator is added to the activation queue (
validator.activation_eligibility_epoch = current_epoch + 1
) it will not be eligible for activation untilvalidator.activation_eligibility_epoch
is finalized, which is not this epoch.consensus-specs/specs/phase0/beacon-chain.md
Lines 699 to 708 in da17461
This PR makes the following changes:
get_current_epoch(state)
withcurrent_epoch
.