remove registry_change options from shuffling functions

specs/core/0_beacon-chain.md

@@ -891,13 +891,9 @@ def get_current_epoch_committee_count(state: BeaconState) -> int:
 
 ```python
 def get_crosslink_committees_at_slot(state: BeaconState,
-                                     slot: Slot,
+                                     slot: Slot) -> List[Tuple[List[ValidatorIndex], Shard]]:
-                                     registry_change: bool=False) -> List[Tuple[List[ValidatorIndex], Shard]]:
     """
     Return the list of ``(committee, shard)`` tuples for the ``slot``.
-
-    Note: There are two possible shufflings for crosslink committees for a
-    ``slot`` in the next epoch -- with and without a `registry_change`
     """
     epoch = slot_to_epoch(slot)
     current_epoch = get_current_epoch(state)
@@ -2339,7 +2335,7 @@ def process_attestation(state: BeaconState, attestation: Attestation) -> None:
     # Check target epoch, source epoch, and source root
     target_epoch = slot_to_epoch(attestation.data.slot)
     assert (target_epoch, attestation.data.source_epoch, attestation.data.source_root) in {
-        (get_current_epoch(state), state.current_justified_epoch, state.current_justified_root), 
+        (get_current_epoch(state), state.current_justified_epoch, state.current_justified_root),
         (get_previous_epoch(state), state.previous_justified_epoch, state.previous_justified_root),
     }
 

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

@@ -331,16 +331,15 @@ signed_attestation_data = bls_sign(
 
 ## Validator assignments
 
-A validator can get the current and previous epoch committee assignments using the following helper via `get_committee_assignment(state, epoch, validator_index)` where `previous_epoch <= epoch <= current_epoch`.
+A validator can get the current, previous, and next epoch committee assignments using the following helper via `get_committee_assignment(state, epoch, validator_index)` where `previous_epoch <= epoch <= next_epoch`.
 
 ```python
 def get_committee_assignment(
         state: BeaconState,
         epoch: Epoch,
-        validator_index: ValidatorIndex,
+        validator_index: ValidatorIndex) -> Tuple[List[ValidatorIndex], Shard, Slot]:
-        registry_change: bool=False) -> Tuple[List[ValidatorIndex], Shard, Slot]:
     """
-    Return the committee assignment in the ``epoch`` for ``validator_index`` and ``registry_change``.
+    Return the committee assignment in the ``epoch`` for ``validator_index``.
     ``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
@@ -355,7 +354,6 @@ def get_committee_assignment(
         crosslink_committees = get_crosslink_committees_at_slot(
             state,
             slot,
-            registry_change=registry_change,
         )
         selected_committees = [
             committee  # Tuple[List[ValidatorIndex], Shard]
@@ -389,18 +387,9 @@ _Note_: If a validator is assigned to the 0th slot of an epoch, the validator mu
 
 The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahead on the validator's upcoming committee assignments for attesting dictated by the shuffling and slot. Note that this lookahead does not apply to proposing which must checked during the epoch in question.
 
-There are three possibilities for the shuffling at the next epoch:
+`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 plan for future assignments which involves noting at which future slot one will have to attest and also which shard one should begin syncing (in phase 1+).
-1. The shuffling changes due to a "validator registry change".
-2. The shuffling changes due to `epochs_since_last_registry_update` being an exact power of 2 greater than 1.
-3. The shuffling remains the same (i.e. the validator is in the same shard committee).
 
-Either (2) or (3) occurs if (1) fails. The choice between (2) and (3) is deterministic based upon `epochs_since_last_registry_update`.
+Specifically, a validator should call `get_committee_assignment(state, next_epoch, validator_index)` when checking for next epoch assignments.
-
-When querying for assignments in the next epoch there are two options -- with and without a `registry_change` -- which is the optional fourth parameter of the `get_committee_assignment`.
-
-`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 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_change=True)` and `get_committee_assignment(state, next_epoch, validator_index, registry_change=False)` when checking for next epoch assignments.
 
 ## How to avoid slashing
 

tests/phase0/block_processing/test_process_attestation.py

@@ -43,7 +43,6 @@ def run_attestation_processing(state, attestation, valid=True):
     else:
         assert len(post_state.previous_epoch_attestations) == len(state.previous_epoch_attestations) + 1
 
-
     return state, post_state