status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Add spacing

This commit is contained in:
Danny Ryan 2019-02-21 16:56:43 -07:00
parent 2bd6057c12
commit f28af3f72b
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
specs/validator/0_beacon-chain-validator.md
View File

@ -386,7 +386,9 @@ There are three possibilities for the shuffling at the next epoch:
Either (2) or (3) occurs if (1) fails. The choice between (2) and (3) is deterministic based upon `epochs_since_last_registry_update`.
`get_crosslink_committees_at_slot` is designed to be able to query slots in the next epoch. When querying slots in the next epoch there are two options -- with and without a `registry_change` -- which is the optional third parameter of the function. The `get_committee_assignment` helper can be used to get the potential crosslink committee assignments in the next epoch for a given `validator_index` and `registry_change`.
`get_committee_assignment` should be called at the start of each epoch to get the assignment for the next epoch (`current_epoch + 1`). A validator should always plan for assignments from both values of `registry_change` unless the validator can concretely eliminate one of the options. Planning for future assignments involves noting at which future slot one might have to attest and propose and also which shard one should begin syncing (in phase 1+).
Specifically, a validator should call both `get_committee_assignment(state, next_epoch, validator_index, registry_chang=True)` and `get_committee_assignment(state, next_epoch, validator_index, registry_change=False)` when checking for next epoch assignments.
## How to avoid slashing