Fair proposer selection probability

specs/core/0_beacon-chain.md

@@ -1061,20 +1061,26 @@ def generate_seed(state: BeaconState,
 
 ```python
 def get_beacon_proposer_index(state: BeaconState,
-                              slot: Slot,
-                              registry_change: bool=False) -> ValidatorIndex:
+                              slot: Slot) -> ValidatorIndex:
     """
     Return the beacon proposer index for the ``slot``.
+    Due to proposer selection being based upon the validator balances during
+    the epoch in question, this can only be run for the current epoch.
     """
-    epoch = slot_to_epoch(slot)
     current_epoch = get_current_epoch(state)
-    previous_epoch = get_previous_epoch(state)
-    next_epoch = current_epoch + 1
-
-    assert previous_epoch <= epoch <= next_epoch
-
-    first_committee, _ = get_crosslink_committees_at_slot(state, slot, registry_change)[0]
-    return first_committee[epoch % len(first_committee)]
+    assert slot_to_epoch(slot) == current_epoch
+
+    first_committee, _ = get_crosslink_committees_at_slot(state, slot)[0]
+    i = 0
+    while True:
+        rand_byte = hash(
+            generate_seed(state, current_epoch) +
+            int_to_bytes8(i // 32)
+        )[i % 32]
+        candidate = first_committee[(current_epoch + i) % len(first_committee)]
+        if get_effective_balance(state, candidate) * 256 > MAX_DEPOSIT_AMOUNT * rand_byte:
+            return candidate
+        i += 1
 ```
 
 ### `verify_merkle_branch`

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

@@ -338,15 +338,13 @@ def get_committee_assignment(
         state: BeaconState,
         epoch: Epoch,
         validator_index: ValidatorIndex,
-        registry_change: bool=False) -> Tuple[List[ValidatorIndex], Shard, Slot, bool]:
+        registry_change: bool=False) -> Tuple[List[ValidatorIndex], Shard, Slot]:
     """
     Return the committee assignment in the ``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
-        * ``assignment[3]`` is a bool signalling if the validator is expected to propose
-            a beacon block at the assigned slot.
     """
     previous_epoch = get_previous_epoch(state)
     next_epoch = get_current_epoch(state) + 1
@@ -367,15 +365,29 @@ def get_committee_assignment(
         if len(selected_committees) > 0:
             validators = selected_committees[0][0]
             shard = selected_committees[0][1]
-            is_proposer = validator_index == get_beacon_proposer_index(state, slot, registry_change=registry_change)
 
-            assignment = (validators, shard, slot, is_proposer)
+            assignment = (validators, shard, slot)
             return assignment
 ```
 
+A validator can use the following function to see if they are supposed to propose during their assigned committee slot. This function can only be run during the epoch of the slot in question and can not reliably be used to predict an epoch in advance.
+
+```python
+def is_proposer_at_slot(state: BeaconState,
+                        slot: Slot,
+                        validator_index: ValidatorIndex) -> bool:
+    current_epoch = get_current_epoch(state)
+    assert slot_to_epoch(slot) == current_epoch
+
+    return get_beacon_proposer_index(state, slot) == validator_index
+```
+
+_Note_: If a validator is assigned to the 0th slot of an epoch, the validator must run an empty slot transition from the previous epoch into the 0th slot of the epoch to be able to check if they are a proposer at that slot.
+
+
 ### Lookahead
 
-The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahead on the validator's upcoming assignments of proposing and attesting dictated by the shuffling and slot.
+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:
 1. The shuffling changes due to a "validator registry change".
@@ -386,7 +398,7 @@ Either (2) or (3) occurs if (1) fails. The choice between (2) and (3) is determi
 
 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 propose and also which shard one should begin syncing (in phase 1+).
+`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.