-
Notifications
You must be signed in to change notification settings - Fork 996
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
validator status cleanup #280
Conversation
actually still have a couple of cleanups to do and will handle merge conflict @JustinDrake. I'll ping for review |
okay, now this is ready for review @JustinDrake @hwwhww |
specs/core/0_beacon-chain.md
Outdated
@@ -998,6 +1011,10 @@ def integer_squareroot(n: int) -> int: | |||
return x | |||
``` | |||
|
|||
#### `BLSVerify` | |||
|
|||
`BLSVerify` is a function for verifying a BLS12-381 signature, defined in the [BLS12-381 spec](https://github.com/ethereum/eth2.0-specs/blob/master/specs/bls_verify.md). |
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.
Ah, I thought BLS Verification
spec is "Boneh-Lynn-Shacham signatures verification" because it's not talking about the details of the curve, no?
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.
Well that doc is doing a BLS signature verification for a specific BLS12-381 curve
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.
renamed spec ref to "BLS Verification spec"
Activate the validator with the given ``index``. | ||
Note that this function mutates ``state``. | ||
""" | ||
if validator.status != PENDING_ACTIVATION: |
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.
need some proof-reading here - validator does not yet exist ;)
validator.status = ACTIVE | ||
validator.latest_status_change_slot = state.slot | ||
state.validator_registry_delta_chain_tip = get_new_validator_registry_delta_chain_tip( | ||
validator_registry_delta_chain_tip=validator_registry_delta_chain_tip, |
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.
likewise - where's the chain tip coming from?
addresses #274 and #268
process_deposit
and normal activation to better reuse code and ensure that thevalidator_registry_delta_chain
is builtupdate_validator_status
exit_validator
is no longer used for changingACTIVE
->ACTIVE_PENDING_EXIT
exit_validator
only removes validator frompersistent_committees
and updatesvalidator_registry_delta_chain
if not previously already exitedNot addressed but worth noting here:
process_deposit
that said deposits from 1.0 should be processed in order as they were submit in the 1.0 chain, but there is no mechanism in "per-slot - deposits" to ensure this validity when processing a block. This needs to be considered more and handled in another PR. theDeposit
object might need asource
field (to distinguish 1.0 vs 2.0 deposits) and theBeaconState
might need to remember the last deposit hash processed from the 1.0 chain.