2026/9/16 21:41:53
FEATURED · 精选文章 
EIP-8045 深度解读从提案者选举中排除被罚没Slashed验证者提升信标链韧性【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文围绕以太坊共识层核心提案 EIP-8045Exclude slashed validators from proposing展开系统讲解其问题背景、规范改动、设计取舍、安全考量与测试要点。它修改信标链的提案者选举过程在计算提案者索引时将已被罚没slashed的验证者从候选池中剔除从而在发生大规模罚没事件后避免大量区块槽位slot被浪费显著提升网络韧性与服务质量。读完本文你将掌握get_beacon_proposer_indices的具体改动方式、它与前置提案 EIP-7917确定性提案者前瞻的协作关系以及该改动为何不会破坏选举的随机性与公平性。一、提案背景被罚没验证者为何会成为幽灵提案者1.1 问题的根源状态转换与选举规则之间的矛盾在以太坊信标链Beacon Chain中验证者因作恶或故障而被罚没slashed后其质押 ETH 会被部分销毁且其区块提案权受到限制。EIP-8045 明确指出当前存在一个矛盾状态转换函数state transition function在process_block中会检查区块提案者是否已被罚没被罚没验证者产出的区块会被判定为无效但现有的提案者选举逻辑在计算get_beacon_proposer_indices时仍然会把所有活跃验证者active validators纳入候选池其中就包含已被罚没的验证者。其结果就是当一名被罚没的验证者被选中为提案者时它既无法产出有效区块产出即无效又占用了该槽位的提案权最终造成槽位空转missed slot。EIP-6988Elected block proposer has not been slashed在仓库中同样记录了这一矛盾指出compute_proposer_index允许被罚没验证者被选举而区块头有效性检查又拒绝其区块二者冲突导致提案被跳过。1.2 大规模罚没场景下的灾难放大单个槽位空转影响有限但问题在**大规模罚没事件mass slashing**后被急剧放大一次大规模罚没后会有大量验证者同时处于已被罚没但尚未退出exit的中间状态而退出需要等待队列与延迟该状态可能持续相当长的时间在此期间这些被罚没验证者依然以较高概率被随机选为提案者导致连续大量槽位空转链性能长时间劣化如果大规模罚没还伴随着一般的网络扰动攻击或故障场景常见这些空转槽位会显著拖延网络恢复过程。EIP-8045 的动机正是通过把被罚没验证者从选举候选池中过滤掉把选中被罚没者→必然空槽的浪费降到零从而让网络在罚没风暴中仍能维持正常出块节奏。二、规范改动一行过滤从活跃验证者到活跃且未罚没验证者2.1 修改目标函数EIP-8045 对共识规范consensus specs中的get_beacon_proposer_indices函数进行修改使其从考虑所有活跃验证者变为仅考虑所有活跃且未罚没的验证者def get_beacon_proposer_indices( state: BeaconState, epoch: Epoch ) - Vector[ValidatorIndex, SLOTS_PER_EPOCH]: Return the proposer indices for the given epoch. # Modified to exclude slashed validators indices [i for i in get_active_validator_indices(state, epoch) if not state.validators[i].slashed] seed get_seed(state, epoch, DOMAIN_BEACON_PROPOSER) return compute_proposer_indices(state, epoch, seed, indices)与修改前的版本见 EIPS/eip-7917.md对比唯一的实质变化在候选列表的构造行修改前indices get_active_validator_indices(state, epoch)修改后indices [i for i in get_active_validator_indices(state, epoch) if not state.validators[i].slashed]。其余逻辑get_seed计算 RANDAO 种子、compute_proposer_indices逐槽位洗牌保持不变。函数返回类型仍为Vector[ValidatorIndex, SLOTS_PER_EPOCH]即每个 epoch 固定产出 32 个槽位的提案者索引。2.2 与 EIP-7917 的协作确定性提案者前瞻理解该改动为何代价极低需要引入其前置依赖EIP-7917Deterministic proposer lookahead状态为 Final。EIP-7917 在BeaconState中新增proposer_lookahead字段在每个 epoch 开始时预先计算并存储未来MIN_SEED_LOOKAHEAD 1个 epoch 的确定性提案者序列class BeaconState: ... proposer_lookahead: Vector[ValidatorIndex, (MIN_SEED_LOOKAHEAD 1) * SLOTS_PER_EPOCH]proposer_lookahead[0]是当前 epoch 第一位提案者的验证者索引proposer_lookahead[SLOTS_PER_EPOCH 4]是下一 epoch 第五位提案者的索引在 epoch 边界process_proposer_lookahead会平移已有序列并调用get_beacon_proposer_indices计算最后一段新序列。由于proposer_lookahead在 epoch 开始时一次性写入 Beacon 状态并固定下来之后在链上处理任何罚没slashing都不会再改变已公布的前瞻序列。这正是 EIP-8045 安全性的关键前提详见第四节此前若在选举中排除被罚没验证者任何在链上被处理的罚没都会让整个未来提案者序列完全改变破坏前瞻窗口内的确定性而有了 EIP-7917 的存储式前瞻这种担忧不复存在。三、设计取舍为什么选择先过滤再洗牌EIP-8045 的 Rationale 部分对比了两种可行的过滤时机设计做法特点前置过滤本提案采用在候选池构造阶段就剔除被罚没验证者再执行洗牌计算改动最小、语义最直观候选池天然只含活跃且未罚没验证者后置过滤备选方案仍以全部活跃验证者为候选池执行洗牌仅在被选中后再剔除被罚没者并重新挑选与前置过滤的最终选择结果不完全相同但达到同样目标从活跃且未罚没集合中进行余额加权选择两种设计的复杂度都很低但 EIP-8045 选择了前置过滤理由如下语义清晰候选池定义与目标直接对应读者与实现者都不易误解无需处理选中后再拒绝的边界逻辑后置过滤需要在洗牌循环中处理抽中被罚没者→跳过重抽的控制流而前置过滤天然规避了这一分支两种方案都能保证目标即最终结果等价于对活跃且未罚没验证者集合做余额加权的随机选择只是具体索引序列不同因为候选池长度的改变会改变洗牌的概率分布。四、向后兼容性与安全考量4.1 向后兼容必须随网络升级激活EIP-8045 修改的是共识规则本身属于**向后不兼容backwards-incompatible**的改动。若部分客户端实现了过滤、部分未实现各节点会对同一 epoch 计算出不同的提案者序列导致分叉。因此该 EIP 明确规定This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade.即必须以计划内网络升级scheduled network upgrade即硬分叉的方式统一激活不能通过客户端软升级零散部署。4.2 为何此前不排除历史稳定性的考量EIP-8045 坦承被罚没验证者历史上仍被允许参与选举并非疏忽而是一个刻意的稳定性设计在引入 EIP-7917 之前任何在链上被处理的罚没都会导致未来提案者序列完全改变即使在前瞻窗口内也不稳定这会破坏依赖提案者可预测性的基础设施如基于预确认协议 based preconfirmation protocols因此让被罚没验证者继续占用注定空转的槽位反而是维持选举机制稳定性的代价EIP-7917 激活后提案者序列被预先存储于 Beacon 状态后续处理的罚没不再影响已固定的前瞻这个历史顾虑被彻底消除排除被罚没验证者才变得安全可行。4.3 对选举分布的影响随机性与公平性不变该改动不会影响未罚没验证者之间的选举随机性与公平性选举算法本身RANDAO 种子 余额加权洗牌没有任何变化唯一区别是被罚没验证者从候选池中被移除对于剩余候选者而言每个验证者被选中的概率分布仍由其余额与总活跃余额决定相对公平性完全保留。4.4 大规模罚没场景纯收益在大规模罚没事件中该改动对网络韧性resilience与服务质量QoS是纯粹的正向收益改动前大量被罚没验证者被选中为提案者 → 大量槽位空转 → 链性能劣化、恢复变慢改动后只有未罚没验证者会被选中 → 网络照常出块运转即使罚没与网络扰动同时发生恢复过程也不再被空转槽位拖累。五、测试要点三条必须验证的行为EIP-8045 的 Test Cases 部分给出三类必须覆盖的测试与 EIPS/eip-7917.md 引入的proposer_lookahead机制强相关被罚没验证者不被选为提案者构造包含被罚没验证者的状态断言get_beacon_proposer_indices的返回序列中不出现任何slashed True的索引——这是本 EIP 的核心行为契约存在被罚没验证者时仍能生成完整的前瞻序列即使候选池中混有被罚没者且其数量足以影响洗牌proposer_lookahead仍须产出长度完整的序列不得因过滤而出现缺槽或序列缩短罚没不影响既有的前瞻序列由于 EIP-7917 将proposer_lookahead预先存储于 Beacon 状态测试需确认在序列生成之后发生的罚没处理不会篡改已固定的前瞻结果——这验证了本 EIP 与 EIP-7917 组合后的确定性保证。仓库中与罚没/提案者相关的既有测试可作参考例如 EIP-6988 提到的test_slashed_validator_not_elected_for_proposal与test_slashed_validator_elected_for_proposal两类对偶用例见 EIPS/eip-6988.md前者验证排除、后者验证排除前的旧行为恰好构成 EIP-8045 测试设计的镜像参照。六、总结EIP-8045 是一个小改动、大收益的共识层提案仅在get_beacon_proposer_indices的候选池构造处增加一行if not state.validators[i].slashed过滤就消除了被罚没验证者占用提案权必然导致的槽位空转。它的成立高度依赖 EIP-7917 的确定性提案者前瞻——正是由于提案者序列被提前固化进 Beacon 状态排除被罚没验证者才不会破坏前瞻的确定性。该改动不影响选举的随机性与公平性在大规模罚没场景下对网络韧性与服务质量是纯粹增益但作为共识规则的向后不兼容修改必须随计划内网络升级统一激活。说明本文围绕 EIPS/eip-8045.md 撰写规范代码与安全论证均直接取自该 EIP 原文并交叉引用了其依赖的 EIPS/eip-7917.md 与同主题的 EIPS/eip-6988.md。版权声明见仓库根目录 LICENSE.mdCC0。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-8045 深度解读：从提案者选举中排除被罚没（Slashed）验证者，提升信标链韧性
EIP-8045 深度解读从提案者选举中排除被罚没Slashed验证者提升信标链韧性【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs本文围绕以太坊共识层核心提案 EIP-8045Exclude slashed validators from proposing展开系统讲解其问题背景、规范改动、设计取舍、安全考量与测试要点。它修改信标链的提案者选举过程在计算提案者索引时将已被罚没slashed的验证者从候选池中剔除从而在发生大规模罚没事件后避免大量区块槽位slot被浪费显著提升网络韧性与服务质量。读完本文你将掌握get_beacon_proposer_indices的具体改动方式、它与前置提案 EIP-7917确定性提案者前瞻的协作关系以及该改动为何不会破坏选举的随机性与公平性。一、提案背景被罚没验证者为何会成为幽灵提案者1.1 问题的根源状态转换与选举规则之间的矛盾在以太坊信标链Beacon Chain中验证者因作恶或故障而被罚没slashed后其质押 ETH 会被部分销毁且其区块提案权受到限制。EIP-8045 明确指出当前存在一个矛盾状态转换函数state transition function在process_block中会检查区块提案者是否已被罚没被罚没验证者产出的区块会被判定为无效但现有的提案者选举逻辑在计算get_beacon_proposer_indices时仍然会把所有活跃验证者active validators纳入候选池其中就包含已被罚没的验证者。其结果就是当一名被罚没的验证者被选中为提案者时它既无法产出有效区块产出即无效又占用了该槽位的提案权最终造成槽位空转missed slot。EIP-6988Elected block proposer has not been slashed在仓库中同样记录了这一矛盾指出compute_proposer_index允许被罚没验证者被选举而区块头有效性检查又拒绝其区块二者冲突导致提案被跳过。1.2 大规模罚没场景下的灾难放大单个槽位空转影响有限但问题在**大规模罚没事件mass slashing**后被急剧放大一次大规模罚没后会有大量验证者同时处于已被罚没但尚未退出exit的中间状态而退出需要等待队列与延迟该状态可能持续相当长的时间在此期间这些被罚没验证者依然以较高概率被随机选为提案者导致连续大量槽位空转链性能长时间劣化如果大规模罚没还伴随着一般的网络扰动攻击或故障场景常见这些空转槽位会显著拖延网络恢复过程。EIP-8045 的动机正是通过把被罚没验证者从选举候选池中过滤掉把选中被罚没者→必然空槽的浪费降到零从而让网络在罚没风暴中仍能维持正常出块节奏。二、规范改动一行过滤从活跃验证者到活跃且未罚没验证者2.1 修改目标函数EIP-8045 对共识规范consensus specs中的get_beacon_proposer_indices函数进行修改使其从考虑所有活跃验证者变为仅考虑所有活跃且未罚没的验证者def get_beacon_proposer_indices( state: BeaconState, epoch: Epoch ) - Vector[ValidatorIndex, SLOTS_PER_EPOCH]: Return the proposer indices for the given epoch. # Modified to exclude slashed validators indices [i for i in get_active_validator_indices(state, epoch) if not state.validators[i].slashed] seed get_seed(state, epoch, DOMAIN_BEACON_PROPOSER) return compute_proposer_indices(state, epoch, seed, indices)与修改前的版本见 EIPS/eip-7917.md对比唯一的实质变化在候选列表的构造行修改前indices get_active_validator_indices(state, epoch)修改后indices [i for i in get_active_validator_indices(state, epoch) if not state.validators[i].slashed]。其余逻辑get_seed计算 RANDAO 种子、compute_proposer_indices逐槽位洗牌保持不变。函数返回类型仍为Vector[ValidatorIndex, SLOTS_PER_EPOCH]即每个 epoch 固定产出 32 个槽位的提案者索引。2.2 与 EIP-7917 的协作确定性提案者前瞻理解该改动为何代价极低需要引入其前置依赖EIP-7917Deterministic proposer lookahead状态为 Final。EIP-7917 在BeaconState中新增proposer_lookahead字段在每个 epoch 开始时预先计算并存储未来MIN_SEED_LOOKAHEAD 1个 epoch 的确定性提案者序列class BeaconState: ... proposer_lookahead: Vector[ValidatorIndex, (MIN_SEED_LOOKAHEAD 1) * SLOTS_PER_EPOCH]proposer_lookahead[0]是当前 epoch 第一位提案者的验证者索引proposer_lookahead[SLOTS_PER_EPOCH 4]是下一 epoch 第五位提案者的索引在 epoch 边界process_proposer_lookahead会平移已有序列并调用get_beacon_proposer_indices计算最后一段新序列。由于proposer_lookahead在 epoch 开始时一次性写入 Beacon 状态并固定下来之后在链上处理任何罚没slashing都不会再改变已公布的前瞻序列。这正是 EIP-8045 安全性的关键前提详见第四节此前若在选举中排除被罚没验证者任何在链上被处理的罚没都会让整个未来提案者序列完全改变破坏前瞻窗口内的确定性而有了 EIP-7917 的存储式前瞻这种担忧不复存在。三、设计取舍为什么选择先过滤再洗牌EIP-8045 的 Rationale 部分对比了两种可行的过滤时机设计做法特点前置过滤本提案采用在候选池构造阶段就剔除被罚没验证者再执行洗牌计算改动最小、语义最直观候选池天然只含活跃且未罚没验证者后置过滤备选方案仍以全部活跃验证者为候选池执行洗牌仅在被选中后再剔除被罚没者并重新挑选与前置过滤的最终选择结果不完全相同但达到同样目标从活跃且未罚没集合中进行余额加权选择两种设计的复杂度都很低但 EIP-8045 选择了前置过滤理由如下语义清晰候选池定义与目标直接对应读者与实现者都不易误解无需处理选中后再拒绝的边界逻辑后置过滤需要在洗牌循环中处理抽中被罚没者→跳过重抽的控制流而前置过滤天然规避了这一分支两种方案都能保证目标即最终结果等价于对活跃且未罚没验证者集合做余额加权的随机选择只是具体索引序列不同因为候选池长度的改变会改变洗牌的概率分布。四、向后兼容性与安全考量4.1 向后兼容必须随网络升级激活EIP-8045 修改的是共识规则本身属于**向后不兼容backwards-incompatible**的改动。若部分客户端实现了过滤、部分未实现各节点会对同一 epoch 计算出不同的提案者序列导致分叉。因此该 EIP 明确规定This EIP introduces a backwards-incompatible change to the consensus rules and MUST be activated as part of a scheduled network upgrade.即必须以计划内网络升级scheduled network upgrade即硬分叉的方式统一激活不能通过客户端软升级零散部署。4.2 为何此前不排除历史稳定性的考量EIP-8045 坦承被罚没验证者历史上仍被允许参与选举并非疏忽而是一个刻意的稳定性设计在引入 EIP-7917 之前任何在链上被处理的罚没都会导致未来提案者序列完全改变即使在前瞻窗口内也不稳定这会破坏依赖提案者可预测性的基础设施如基于预确认协议 based preconfirmation protocols因此让被罚没验证者继续占用注定空转的槽位反而是维持选举机制稳定性的代价EIP-7917 激活后提案者序列被预先存储于 Beacon 状态后续处理的罚没不再影响已固定的前瞻这个历史顾虑被彻底消除排除被罚没验证者才变得安全可行。4.3 对选举分布的影响随机性与公平性不变该改动不会影响未罚没验证者之间的选举随机性与公平性选举算法本身RANDAO 种子 余额加权洗牌没有任何变化唯一区别是被罚没验证者从候选池中被移除对于剩余候选者而言每个验证者被选中的概率分布仍由其余额与总活跃余额决定相对公平性完全保留。4.4 大规模罚没场景纯收益在大规模罚没事件中该改动对网络韧性resilience与服务质量QoS是纯粹的正向收益改动前大量被罚没验证者被选中为提案者 → 大量槽位空转 → 链性能劣化、恢复变慢改动后只有未罚没验证者会被选中 → 网络照常出块运转即使罚没与网络扰动同时发生恢复过程也不再被空转槽位拖累。五、测试要点三条必须验证的行为EIP-8045 的 Test Cases 部分给出三类必须覆盖的测试与 EIPS/eip-7917.md 引入的proposer_lookahead机制强相关被罚没验证者不被选为提案者构造包含被罚没验证者的状态断言get_beacon_proposer_indices的返回序列中不出现任何slashed True的索引——这是本 EIP 的核心行为契约存在被罚没验证者时仍能生成完整的前瞻序列即使候选池中混有被罚没者且其数量足以影响洗牌proposer_lookahead仍须产出长度完整的序列不得因过滤而出现缺槽或序列缩短罚没不影响既有的前瞻序列由于 EIP-7917 将proposer_lookahead预先存储于 Beacon 状态测试需确认在序列生成之后发生的罚没处理不会篡改已固定的前瞻结果——这验证了本 EIP 与 EIP-7917 组合后的确定性保证。仓库中与罚没/提案者相关的既有测试可作参考例如 EIP-6988 提到的test_slashed_validator_not_elected_for_proposal与test_slashed_validator_elected_for_proposal两类对偶用例见 EIPS/eip-6988.md前者验证排除、后者验证排除前的旧行为恰好构成 EIP-8045 测试设计的镜像参照。六、总结EIP-8045 是一个小改动、大收益的共识层提案仅在get_beacon_proposer_indices的候选池构造处增加一行if not state.validators[i].slashed过滤就消除了被罚没验证者占用提案权必然导致的槽位空转。它的成立高度依赖 EIP-7917 的确定性提案者前瞻——正是由于提案者序列被提前固化进 Beacon 状态排除被罚没验证者才不会破坏前瞻的确定性。该改动不影响选举的随机性与公平性在大规模罚没场景下对网络韧性与服务质量是纯粹增益但作为共识规则的向后不兼容修改必须随计划内网络升级统一激活。说明本文围绕 EIPS/eip-8045.md 撰写规范代码与安全论证均直接取自该 EIP 原文并交叉引用了其依赖的 EIPS/eip-7917.md 与同主题的 EIPS/eip-6988.md。版权声明见仓库根目录 LICENSE.mdCC0。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
![ET 框架通用测试用例包（cn.etetet.test）：从 [Test] 自动发现到 Console 批量执行的完整测试体系](http://pic.xiahunao.cn/yaotu/ET 框架通用测试用例包（cn.etetet.test）：从 [Test] 自动发现到 Console 批量执行的完整测试体系)
