name changes in validator doc and phase 1 doc

This commit is contained in:
Danny Ryan 2019-02-14 16:02:01 -07:00
parent 81e8f53ab9
commit 375659dc6c
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
2 changed files with 17 additions and 17 deletions

View File

@ -47,8 +47,8 @@ def get_split_offset(list_size: int, chunks: int, index: int) -> int:
```python ```python
def get_shuffled_committee(state: BeaconState, def get_shuffled_committee(state: BeaconState,
shard: ShardNumber, shard: Shard,
committee_start_epoch: EpochNumber) -> List[ValidatorIndex]: committee_start_epoch: Epoch) -> List[ValidatorIndex]:
""" """
Return shuffled committee. Return shuffled committee.
""" """
@ -66,8 +66,8 @@ def get_shuffled_committee(state: BeaconState,
```python ```python
def get_persistent_committee(state: BeaconState, def get_persistent_committee(state: BeaconState,
shard: ShardNumber, shard: Shard,
epoch: EpochNumber) -> List[ValidatorIndex]: epoch: Epoch) -> List[ValidatorIndex]:
""" """
Return the persistent committee for the given ``shard`` at the given ``epoch``. Return the persistent committee for the given ``shard`` at the given ``epoch``.
""" """
@ -94,10 +94,10 @@ def get_persistent_committee(state: BeaconState,
```python ```python
def get_shard_proposer_index(state: BeaconState, def get_shard_proposer_index(state: BeaconState,
shard: ShardNumber, shard: Shard,
slot: SlotNumber) -> ValidatorIndex: slot: Slot) -> ValidatorIndex:
seed = hash( seed = hash(
state.current_epoch_seed + state.current_shuffling_seed +
int_to_bytes8(shard) + int_to_bytes8(shard) +
int_to_bytes8(slot) int_to_bytes8(slot)
) )
@ -177,8 +177,8 @@ A node should sign a crosslink only if the following conditions hold. **If a nod
First, the conditions must recursively apply to the crosslink referenced in `last_crosslink_root` for the same shard (unless `last_crosslink_root` equals zero, in which case we are at the genesis). First, the conditions must recursively apply to the crosslink referenced in `last_crosslink_root` for the same shard (unless `last_crosslink_root` equals zero, in which case we are at the genesis).
Second, we verify the `shard_chain_commitment`. Second, we verify the `shard_chain_commitment`.
* Let `start_slot = state.latest_crosslinks[shard].epoch * EPOCH_LENGTH + EPOCH_LENGTH - CROSSLINK_LOOKBACK`. * Let `start_slot = state.latest_crosslinks[shard].epoch * SLOTS_PER_EPOCH + SLOTS_PER_EPOCH - CROSSLINK_LOOKBACK`.
* Let `end_slot = attestation.data.slot - attestation.data.slot % EPOCH_LENGTH - CROSSLINK_LOOKBACK`. * Let `end_slot = attestation.data.slot - attestation.data.slot % SLOTS_PER_EPOCH - CROSSLINK_LOOKBACK`.
* Let `length = end_slot - start_slot`, `headers[0] .... headers[length-1]` be the serialized block headers in the canonical shard chain from the verifer's point of view (note that this implies that `headers` and `bodies` have been checked for validity). * Let `length = end_slot - start_slot`, `headers[0] .... headers[length-1]` be the serialized block headers in the canonical shard chain from the verifer's point of view (note that this implies that `headers` and `bodies` have been checked for validity).
* Let `bodies[0] ... bodies[length-1]` be the bodies of the blocks. * Let `bodies[0] ... bodies[length-1]` be the bodies of the blocks.
* Note: If there is a missing slot, then the header and body are the same as that of the block at the most recent slot that has a block. * Note: If there is a missing slot, then the header and body are the same as that of the block at the most recent slot that has a block.

View File

@ -34,7 +34,7 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
- [Attester slashings](#attester-slashings) - [Attester slashings](#attester-slashings)
- [Attestations](#attestations) - [Attestations](#attestations)
- [Deposits](#deposits) - [Deposits](#deposits)
- [Exits](#exits) - [Voluntary exits](#voluntary-exits)
- [Attestations](#attestations-1) - [Attestations](#attestations-1)
- [Attestation data](#attestation-data) - [Attestation data](#attestation-data)
- [Slot](#slot-1) - [Slot](#slot-1)
@ -118,7 +118,7 @@ Once a validator has been processed and added to the beacon state's `validator_r
### Activation ### Activation
In normal operation, the validator is quickly activated at which point the validator is added to the shuffling and begins validation after an additional `ENTRY_EXIT_DELAY` epochs (25.6 minutes). In normal operation, the validator is quickly activated at which point the validator is added to the shuffling and begins validation after an additional `ACTIVATION_EXIT_DELAY` epochs (25.6 minutes).
The function [`is_active_validator`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_active_validator) can be used to check if a validator is active during a given epoch. Usage is as follows: The function [`is_active_validator`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#is_active_validator) can be used to check if a validator is active during a given epoch. Usage is as follows:
@ -232,15 +232,15 @@ Up to `MAX_ATTESTATIONS` aggregate attestations can be included in the `block`.
Up to `MAX_DEPOSITS` [`Deposit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposit) objects can be included in the `block`. These deposits are constructed from the `Deposit` logs from the [Eth1.0 deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) and must be processed in sequential order. The deposits included in the `block` must satisfy the verification conditions found in [deposits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposits-1). Up to `MAX_DEPOSITS` [`Deposit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposit) objects can be included in the `block`. These deposits are constructed from the `Deposit` logs from the [Eth1.0 deposit contract](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#ethereum-10-deposit-contract) and must be processed in sequential order. The deposits included in the `block` must satisfy the verification conditions found in [deposits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#deposits-1).
##### Exits ##### Voluntary exits
Up to `MAX_EXITS` [`Exit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exit) objects can be included in the `block`. The exits must satisfy the verification conditions found in [exits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exits-1). Up to `MAX_VOLUNTARY_EXITS` [`VoluntaryExit`](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#voluntaryexit) objects can be included in the `block`. The exits must satisfy the verification conditions found in [exits processing](https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_beacon-chain.md#exits-1).
### Attestations ### Attestations
A validator is expected to create, sign, and broadcast an attestation during each epoch. The slot during which the validator performs this role is any slot at which `get_crosslink_committees_at_slot(state, slot)` contains a committee that contains `validator_index`. A validator is expected to create, sign, and broadcast an attestation during each epoch. The slot during which the validator performs this role is any slot at which `get_crosslink_committees_at_slot(state, slot)` contains a committee that contains `validator_index`.
A validator should create and broadcast the attestation halfway through the `slot` during which the validator is assigned -- that is `SLOT_DURATION * 0.5` seconds after the start of `slot`. A validator should create and broadcast the attestation halfway through the `slot` during which the validator is assigned -- that is `SECONDS_PER_SLOT * 0.5` seconds after the start of `slot`.
#### Attestation data #### Attestation data
@ -347,7 +347,7 @@ Either (2) or (3) occurs if (1) fails. The choice between (2) and (3) is determi
def get_next_epoch_committee_assignment( def get_next_epoch_committee_assignment(
state: BeaconState, state: BeaconState,
validator_index: ValidatorIndex, validator_index: ValidatorIndex,
registry_change: bool) -> Tuple[List[ValidatorIndex], ShardNumber, SlotNumber, bool]: registry_change: bool) -> Tuple[List[ValidatorIndex], Shard, Slot, bool]:
""" """
Return the committee assignment in the next epoch for ``validator_index`` and ``registry_change``. Return the committee assignment in the next epoch for ``validator_index`` and ``registry_change``.
``assignment`` returned is a tuple of the following form: ``assignment`` returned is a tuple of the following form:
@ -360,14 +360,14 @@ def get_next_epoch_committee_assignment(
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)
for slot in range(next_epoch_start_slot, next_epoch_start_slot + EPOCH_LENGTH): for slot in range(next_epoch_start_slot, next_epoch_start_slot + SLOTS_PER_EPOCH):
crosslink_committees = get_crosslink_committees_at_slot( crosslink_committees = get_crosslink_committees_at_slot(
state, state,
slot, slot,
registry_change=registry_change, registry_change=registry_change,
) )
selected_committees = [ selected_committees = [
committee # Tuple[List[ValidatorIndex], ShardNumber] committee # Tuple[List[ValidatorIndex], Shard]
for committee in crosslink_committees for committee in crosslink_committees
if validator_index in committee[0] if validator_index in committee[0]
] ]