在以太坊的共识规则里，有一条容易被忽略的裂缝：协议一边规定由被 slash（罚没）的验证者产出的区块会被节点直接拒绝，一边又在出块者的抽签算法里保留了这个人当选的资格。两份规则各自成立，拼在一起就成了一个纯粹的浪费——被点名的验证者明明还挂着一个提案权，轮到它的那次出块却注定作废。EIP-6988 针对的就是这个矛盾，它要求抽签时把已被罚没的验证者排除在外。
矛盾是怎么形成的
按信标链规范（phase0）的定义，区块头验证函数会检查提案者身份：如果这个位置的提案者处于被 slash 状态，整个区块被判无效。但同一份规范里的提案者抽签函数并不做这个检查，它只按有效余额权重从验证者集合里取随机数。于是当某个验证者在临近时段被罚没时，接下来的排班里可能仍然轮得到它。节点照常等着，时间照常流逝，直到下一个验证者接手，中间那一格就是无人认领的空区块。
为什么平时看不见
单次罚没摊在八千多个时隙构成的纪元里，撞上被点名的概率很低，对主网的漏提案率影响微乎其微。真正要紧的是相关联罚没：同一台机器的配置错误、同一个客户端的同一个缺陷、同一家托管商的同一批机器，都可能让成千上万个验证者同时被 slash。提案顺序与验证者编号相关，一旦一批人同时出局，接下来若干个纪元里会有同等比例的提案被白白浪费。提案被浪费不只是少一笔小费：包含列表、同步委员会聚合等依附在区块里的职责也要顺延，网络的整体节奏被拖慢。
修法和它的代价
草案把提案者抽签函数改成会查看被 slash 状态的版本，对正在处理区块内的即时罚没也做了相应处理，让函数在任何时点返回的提案者索引都能真正出块。改动看似只是过滤一个条件，但它改变了提案者选举的确定性规则，属于向后不兼容的共识变更，必须随硬分叉激活。规范文本还配了正反两组测试：被 slash 的验证者不应被选为提案者，但它在同步委员会与证明包含上被点名的场景仍应获得奖励——修复只堵住选举，不取消其他职责的报酬。
现状与边界
这份提案创建于 2023 年 5 月，状态长期停留在 Stagnant（停滞），以 EIP 官网当前标签为准。它没有消失的原因很现实：同类问题可以用客户端在本地对排班做变通规避，而硬分叉名额永远优先留给路线图上更紧急的项目。读这类提案时值得记住的规律是：共识层的漏洞修复哪怕正确，也要和所有议题排队竞争带宽。
快速问答
问：被 slash 的人会被立刻从验证者集合里删除吗？ 答：不会。罚没触发后余额被逐步清算，退出要经过队列，期间它的名字在状态里仍然存在，这正是抽签函数可能选到它的时间窗口。 问：漏掉一次出块算事故吗？ 答：不算罚则意义上的事故，不扣款，只是那次提案的收益和职责落空，代价由全网络分摊。 问：这个提案和罚没机制本身有什么关系？ 答：不改变任何罚则的判定与金额，只改变抽签时是否把已被罚没者视为合格候选人。
一条判断线
读共识协议时，凡是出现”验证规则”与”选举规则”两套代码的地方，都值得问一句：两份规则对同一个对象的判断一致吗？协议的一半漏洞来自这种两不管地带。
风险提示：本文仅为协议机制科普，不构成任何投资建议；参与质押前请自行评估罚没风险与运维能力。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。