以太坊提案者选择机制在 Electra 更新前后的变化

同样可参考 Lin Oshitani 的 "Preconf Lookahead and MaxEB"。

Pre-electra

• 每个Slot，提议者是基于 BeaconState 计算出来的（见 get_beacon_proposer_index）。
• 关键的函数调用是 compute_proposer_index。在 EIP-7251 之前，候选提议者是通过将其有效余额与随机采样的字节（一个整数，random_byte=[0,255]）进行比较来选择的，条件如下：

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

• 这确保了余额低于 32 ETH 的验证者被选中的概率较低（例如，一个 16 ETH 的验证者被选中的次数只有 32 ETH 的验证者的一半，因为在 random_byte<128 的情况下，16⋅255≥32⋅random_byte）。注意，对于 32 ETH 的验证者，if 语句总是成立，且该验证者从未被跳过。

Post-electra

• 在 Electra 中，compute_proposer_index （因为 EIP-7251）发生了变化。随机字节现在是 16 位（random_byte=[0,65535]），MAX_EFFECTIVE_BALANCE_ELECTRA 是 2048 ETH。因此，提议者通过验证者索引循环并检查以下条件：

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

• 这与之前类似，但现在验证者需要全额 2048 ETH 的余额才能确保条件成立。对于 "正常" 的 32 ETH 验证者，这一条件仅在概率 1/64 下成立，因为在 random_byte<1024 的情况下，32⋅65535≥2048⋅random_byte。这是预期的行为，因为 2048 ETH 的验证者应该比 32 ETH 的验证者更频繁地被选中，64 倍。

Electra 对预测的影响

正如 Lin 的文档 中提到的，epoch N-2 的 RANDAO 被用作 epoch N 中提议者选择的输入（见 get_seed）。因此，在 epoch N-1 期间（当 epoch N-2 RANDAO 确定后）预测 epoch N 的提议者应该是可行的。然而，在 epoch 边界，有效余额（仍然以 1 ETH 为增量）现在更可能通过奖励累积（对于余额大于 32 ETH 的复利验证者）、合并和存款而变化（见 process epoch）。这有什么重要性？想象以下场景：

• 在 epoch N-1：

  • 一个验证者的余额为 32 ETH，并且被选为 epoch N 中某个Slot的候选提议者。
  • 设

  random_byte=2000。

  • 因此

  32⋅65535≱2048⋅2000，结果他们未被选为提议者。

  • 在 epoch N-1 结束时，向验证者的余额存入 32 ETH。

• 在 epoch N：

  • 该验证者现在的余额为 64 ETH。
  • random_byte=2000 仍然相同。
  • 现在

  64⋅65535≥2048⋅2000，因此他们 被选中 作为提议者。

在 electra 之前，有效余额的变化可能通过多种方式发生（例如，由于不活跃验证者余额减少或全额提取的发生）。在 electra 之后，有效余额变化的方式显著增加，导致更难预测的领导计划。

• 原文链接： hackmd.io/@mikeneuder/et...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～