Merge pull request #592 from ethereum/release-nitpicks

fix a couple of nitpicks before release

specs/core/0_beacon-chain.md

@@ -658,9 +658,10 @@ def get_previous_epoch(state: BeaconState) -> EpochNumber:
     Return the previous epoch of the given ``state``.
     If the current epoch is  ``GENESIS_EPOCH``, return ``GENESIS_EPOCH``.
     """
-    if slot_to_epoch(state.slot) > GENESIS_EPOCH:
-        return slot_to_epoch(state.slot) - 1
-    return slot_to_epoch(state.slot)
+    current_epoch = get_current_epoch(state)
+    if current_epoch == GENESIS_EPOCH:
+        return GENESIS_EPOCH
+    return current_epoch - 1
 ```
 
 ### `get_current_epoch`

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

@@ -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`.
 
-`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
-def get_next_epoch_committee_assignments(
+def get_next_epoch_committee_assignment(
         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.
-    Possible committee ``assignment`` is of the form (List[ValidatorIndex], ShardNumber, SlotNumber, bool).
+    Return the committee assignment in the next epoch for ``validator_index`` and ``registry_change``.
+    ``assignment`` returned is a tuple of the following form:
         * ``assignment[0]`` is the list of validators in the committee
         * ``assignment[1]`` is the shard to which the committee is assigned
         * ``assignment[2]`` is the slot at which the committee is assigned
@@ -359,8 +360,6 @@ def get_next_epoch_committee_assignments(
     current_epoch = get_current_epoch(state)
     next_epoch = current_epoch + 1
     next_epoch_start_slot = get_epoch_start_slot(next_epoch)
-    potential_assignments = []
-    for registry_change in [False, True]:
     for slot in range(next_epoch_start_slot, next_epoch_start_slot + EPOCH_LENGTH):
         crosslink_committees = get_crosslink_committees_at_slot(
             state,
@@ -373,19 +372,16 @@ def get_next_epoch_committee_assignments(
             if validator_index in committee[0]
         ]
         if len(selected_committees) > 0:
-                assignment = selected_committees[0]
-                assignment += (slot,)
+            validators = selected_committees[0][0]
+            shard = selected_committees[0][1]
             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)
-                break
-
-    return potential_assignments
+            assignment = (validators, shard, slot, is_proposer)
+            return assignment
 ```
 
-`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