Ethereum proposer lookahead

See also "Preconf Lookahead and MaxEB" by Lin Oshitani.

Pre-electra

• Each slot, the proposer is calculated based on the BeaconState (see get_beacon_proposer_index).
• The key function call is compute_proposer_index. Before EIP-7251, a candidate proposer selected based on their effective balance by comparing their effective balance with a randomly sampled byte (which is an integer,
  $\text{random\_byte}=[0,255]$) using the following condition:

if effective_balance * MAX_RANDOM_BYTE >= MAX_EFFECTIVE_BALANCE * random_byte:
    return candidate_index

• This ensures that a validator with a <32 ETH balance is selected with a lower probability (e.g., a 16 ETH validator is only selected half as often as a 32 ETH validator because
  $16\cdot 255\ge 32\cdot \text{random\_byte}$ if
  $\text{random\_byte}<128$). Note that with a 32 ETH validator, the if statement is always satisfied, and the validator is never skipped.

Post-electra

• compute_proposer_index is changed in Electra (because of EIP-7251). The random byte is now 16 bits (
  $\text{random\_byte}=[0,65535]$) and MAX_EFFECTIVE_BALANCE_ELECTRA is 2048 ETH. Thus, the proposer loops through validator indices and checks the following condition:

if effective_balance * MAX_RANDOM_VALUE >= MAX_EFFECTIVE_BALANCE_ELECTRA * random_value:
    return candidate_index

• This is similar to before, but now a validator needs the full 2048 ETH balance to ensure the condition is true. For the "normal" 32 ETH validator, this condition is only true with probability 1/64 because
  $32\cdot 65535\ge 2048\cdot \text{random\_byte}$ if
  $\text{random\_byte}<1024$. This is the desired behavior because a 2048 ETH validator should be selected 64 times more often than a 32 ETH validator.

How electra impacts the lookahead

As mentioned in Lin's doc, the epoch N-2 RANDAO is used as input to the proposer selection in epoch N (see get_seed). As such, during epoch N-1 (once the epoch N-2 RANDAO is fixed) predicting the proposers for epoch N should be feasible. However, at epoch boundaries, effective balances (which are still in 1 ETH increments) are now more likely to change through reward accrual (for compounding validators with >32 ETH balances), consolidations, and deposits (see process epoch). Why does this matter? Imagine the following scenario:

• During epoch N-1:
  • A validator has a balance of 32 ETH and is selected as a candidate proposer for a slot in epoch N.
  • Let
    $\text{random\_byte}=2000$.
  • Thus
    $32\cdot 65535\ngeqq 2048\cdot 2000$ and they are not selected as the proposer.
  • A deposit adding 32 ETH to the validator's balance occurs at the end of epoch N-1.
• During epoch N:
  • The validator now has a balance of 64 ETH.
  • $\text{random\_byte}=2000$ still.
  • Now
    $64\cdot 65535\ge 2048\cdot 2000$ and they are selected as the proposer.

Before electra, effective balance changes could still occur in many ways (e.g., due to an inactive validator balance decreasing or a full withdrawal taking place). After electra, there are simply more ways the effective balance can change, leading to a more difficult-to-predict leader schedule.