Merge pull request #592 from ethereum/release-nitpicks
fix a couple of nitpicks before release
This commit is contained in:
commit
4a2416add7
|
@ -658,9 +658,10 @@ def get_previous_epoch(state: BeaconState) -> EpochNumber:
|
||||||
Return the previous epoch of the given ``state``.
|
Return the previous epoch of the given ``state``.
|
||||||
If the current epoch is ``GENESIS_EPOCH``, return ``GENESIS_EPOCH``.
|
If the current epoch is ``GENESIS_EPOCH``, return ``GENESIS_EPOCH``.
|
||||||
"""
|
"""
|
||||||
if slot_to_epoch(state.slot) > GENESIS_EPOCH:
|
current_epoch = get_current_epoch(state)
|
||||||
return slot_to_epoch(state.slot) - 1
|
if current_epoch == GENESIS_EPOCH:
|
||||||
return slot_to_epoch(state.slot)
|
return GENESIS_EPOCH
|
||||||
|
return current_epoch - 1
|
||||||
```
|
```
|
||||||
|
|
||||||
### `get_current_epoch`
|
### `get_current_epoch`
|
||||||
|
|
|
@ -341,15 +341,16 @@ 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`.
|
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 following helper can be used to get the potential crosslink committees in the next epoch for a given `validator_index`. This function returns a list of 2 shard committee tuples.
|
`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 following helper can be used to get the potential crosslink committee assignments in the next epoch for a given `validator_index` and `registry_change`.
|
||||||
|
|
||||||
```python
|
```python
|
||||||
def get_next_epoch_committee_assignments(
|
def get_next_epoch_committee_assignment(
|
||||||
state: BeaconState,
|
state: BeaconState,
|
||||||
validator_index: ValidatorIndex) -> List[Tuple[List[ValidatorIndex], ShardNumber, SlotNumber, bool]]:
|
validator_index: ValidatorIndex,
|
||||||
|
registry_change: bool) -> Tuple[List[ValidatorIndex], ShardNumber, SlotNumber, bool]:
|
||||||
"""
|
"""
|
||||||
Return a list of the two possible committee assignments for ``validator_index`` at the next epoch.
|
Return the committee assignment in the next epoch for ``validator_index`` and ``registry_change``.
|
||||||
Possible committee ``assignment`` is of the form (List[ValidatorIndex], ShardNumber, SlotNumber, bool).
|
``assignment`` returned is a tuple of the following form:
|
||||||
* ``assignment[0]`` is the list of validators in the committee
|
* ``assignment[0]`` is the list of validators in the committee
|
||||||
* ``assignment[1]`` is the shard to which the committee is assigned
|
* ``assignment[1]`` is the shard to which the committee is assigned
|
||||||
* ``assignment[2]`` is the slot at which the committee is assigned
|
* ``assignment[2]`` is the slot at which the committee is assigned
|
||||||
|
@ -359,33 +360,28 @@ def get_next_epoch_committee_assignments(
|
||||||
current_epoch = get_current_epoch(state)
|
current_epoch = get_current_epoch(state)
|
||||||
next_epoch = current_epoch + 1
|
next_epoch = current_epoch + 1
|
||||||
next_epoch_start_slot = get_epoch_start_slot(next_epoch)
|
next_epoch_start_slot = get_epoch_start_slot(next_epoch)
|
||||||
potential_assignments = []
|
for slot in range(next_epoch_start_slot, next_epoch_start_slot + EPOCH_LENGTH):
|
||||||
for registry_change in [False, True]:
|
crosslink_committees = get_crosslink_committees_at_slot(
|
||||||
for slot in range(next_epoch_start_slot, next_epoch_start_slot + EPOCH_LENGTH):
|
state,
|
||||||
crosslink_committees = get_crosslink_committees_at_slot(
|
slot,
|
||||||
state,
|
registry_change=registry_change,
|
||||||
slot,
|
)
|
||||||
registry_change=registry_change,
|
selected_committees = [
|
||||||
)
|
committee # Tuple[List[ValidatorIndex], ShardNumber]
|
||||||
selected_committees = [
|
for committee in crosslink_committees
|
||||||
committee # Tuple[List[ValidatorIndex], ShardNumber]
|
if validator_index in committee[0]
|
||||||
for committee in crosslink_committees
|
]
|
||||||
if validator_index in committee[0]
|
if len(selected_committees) > 0:
|
||||||
]
|
validators = selected_committees[0][0]
|
||||||
if len(selected_committees) > 0:
|
shard = selected_committees[0][1]
|
||||||
assignment = selected_committees[0]
|
first_committee_at_slot = crosslink_committees[0][0] # List[ValidatorIndex]
|
||||||
assignment += (slot,)
|
is_proposer = first_committee_at_slot[slot % len(first_committee_at_slot)] == validator_index
|
||||||
first_committee_at_slot = crosslink_committees[0][0] # List[ValidatorIndex]
|
|
||||||
is_proposer = first_committee_at_slot[slot % len(first_committee_at_slot)] == validator_index
|
|
||||||
assignment += (is_proposer,)
|
|
||||||
|
|
||||||
potential_assignments.append(assignment)
|
assignment = (validators, shard, slot, is_proposer)
|
||||||
break
|
return assignment
|
||||||
|
|
||||||
return potential_assignments
|
|
||||||
```
|
```
|
||||||
|
|
||||||
`get_next_epoch_committee_assignments` should be called at the beginning of each epoch to plan for the next epoch. A validator should always plan for both values of `registry_change` as a possibility unless the validator can concretely eliminate one of the options. Planning for a future shuffling involves noting at which slot one might have to attest and propose and also which shard one should begin syncing (in phase 1+).
|
`get_next_epoch_committee_assignment` should be called at the start of each epoch to get the assignment for the next epoch (slots during `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+).
|
||||||
|
|
||||||
## How to avoid slashing
|
## How to avoid slashing
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue