Merge pull request #630 from ethereum/validator-name-changes

name changes in validator doc and phase 1 doc

specs/core/1_shard-data-chains.md

@@ -47,8 +47,8 @@ def get_split_offset(list_size: int, chunks: int, index: int) -> int:
 
 ```python
 def get_shuffled_committee(state: BeaconState,
-                           shard: ShardNumber,
-                           committee_start_epoch: EpochNumber) -> List[ValidatorIndex]:
+                           shard: Shard,
+                           committee_start_epoch: Epoch) -> List[ValidatorIndex]:
     """
     Return shuffled committee.
     """
@@ -66,8 +66,8 @@ def get_shuffled_committee(state: BeaconState,
 
 ```python
 def get_persistent_committee(state: BeaconState,
-                             shard: ShardNumber,
-                             epoch: EpochNumber) -> List[ValidatorIndex]:
+                             shard: Shard,
+                             epoch: Epoch) -> List[ValidatorIndex]:
     """
     Return the persistent committee for the given ``shard`` at the given ``epoch``.
     """
@@ -94,10 +94,10 @@ def get_persistent_committee(state: BeaconState,
 
 ```python
 def get_shard_proposer_index(state: BeaconState,
-                             shard: ShardNumber,
-                             slot: SlotNumber) -> ValidatorIndex:
+                             shard: Shard,
+                             slot: Slot) -> ValidatorIndex:
     seed = hash(
-        state.current_epoch_seed +
+        state.current_shuffling_seed +
         int_to_bytes8(shard) +
         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).
 
 Second, we verify the `shard_chain_commitment`.
-* Let `start_slot = state.latest_crosslinks[shard].epoch * EPOCH_LENGTH + EPOCH_LENGTH - CROSSLINK_LOOKBACK`.
-* Let `end_slot = attestation.data.slot - attestation.data.slot % 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 % 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 `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.

specs/validator/0_beacon-chain-validator.md

@@ -34,7 +34,7 @@ __NOTICE__: This document is a work-in-progress for researchers and implementers
                 - [Attester slashings](#attester-slashings)
                 - [Attestations](#attestations)
                 - [Deposits](#deposits)
-                - [Exits](#exits)
+                - [Voluntary exits](#voluntary-exits)
         - [Attestations](#attestations-1)
             - [Attestation data](#attestation-data)
                 - [Slot](#slot-1)
@@ -118,7 +118,7 @@ Once a validator has been processed and added to the beacon state's `validator_r
 
 ### 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:
 
@@ -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).
 
-##### 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
 
 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
 
@@ -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(
         state: BeaconState,
         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``.
     ``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)
     next_epoch = current_epoch + 1
     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(
             state,
             slot,
             registry_change=registry_change,
         )
         selected_committees = [
-            committee  # Tuple[List[ValidatorIndex], ShardNumber]
+            committee  # Tuple[List[ValidatorIndex], Shard]
             for committee in crosslink_committees
             if validator_index in committee[0]
         ]