MaxEB (EIP-7251) 下的非活跃性泄漏

信标链被设计为在超过 1/3 的验证者永久失效时自动恢复最终性（通常被称为在 第三次世界大战 中幸存）。失效的验证者会被 泄漏 以减少其在活跃权益中的份额并恢复最终性。为了再次达到最终性，需要满足以下不等式：

participating_stake / active_stake > 66%

假设 participating_stake 是恒定的（没有新的存款），它需要通过以下方式减少 active_stake：

1. 强制驱逐未参与的权益（驱逐条件）
2. 减少活跃的未参与验证者的余额（失效 泄漏）

为了使 1) 能够被形式化，我们必须设置一个常量 EJECTION_BALANCE，如果验证者的余额低于该值，则该验证者将被驱逐。1) 的问题在于驱逐必须通过退出队列。但是，如果超过 1/3 的验证者需要被驱逐，退出队列将需要数月才能清空。因此，在实践中，2) 占据主导地位以恢复最终性。因此，大多数验证者将会 泄漏 到超过驱逐余额，这取决于永久离线的权益份额。

逐个 epoch 的失效 泄漏 时间线

由 EJECTION_BALANCE 决定的驱逐条件可能会被误解为验证者余额的下限。然而，在失效 泄漏 期间，大多数验证者将会 泄漏 到远低于 EJECTION_BALANCE。让我们逐步运行一个示例来说明它。

注意：下面的图表是使用实现了 Bellatrix 规范的 Jupyter Notebook 创建的，该规范具有更快的配置变量。 有关详细数字，请参阅下一节，该节运行完整的失效 泄漏 模拟。

以下图表跟踪了在 50% 的验证者突然离线的情况下，失效 泄漏 期间的三个关键变量。

• 🟥 余额：实线：离线验证者的平均值。面积：所有值的范围
• 🟦 失效得分：实线：离线验证者的平均值，面积：所有值的范围
• 🟩 活跃验证者的比例

如果最终性延迟超过 4 个 epoch，离线验证者的失效得分将开始随时间线性增加。失效余额惩罚与失效得分成正比，因此余额随时间呈 ~ 二次递减。

最终，失效验证者的余额达到 EJECTION_BALANCE，这些验证者会被立即驱逐。请注意，这是一个完美的例子，其中所有验证者都以相同的余额开始。在实际场景中，驱逐之间会存在一些偏移。此外，验证者可能会尽快尝试自愿退出，从而使退出更加错开。但是，由于此操作不会显着改变结果，因此目前将其省略。

尽管所有验证者都被立即驱逐，但退出队列强制执行每个单位时间的恒定退出率。队列开始处的验证者首先退出，余额接近 EJECTION_BALANCE。但是，其余的继续保持活跃和离线，从而增加其失效惩罚并 泄漏 余额。

最终，由于 泄漏，参与权益的份额达到 2/3，并且网络达到最终性。仍在活动的验证者的失效得分以更高的速率降低，但需要一段时间才能达到 0。在此期间，尚未退出的验证者会继续 泄漏。

结果是激励大家争先恐后地退出，因为能够抢先退出队列的验证者将遭受最少的惩罚。但是，大多数离线验证者的余额最终将远低于 EJECTION_BALANCE。

最终性后的持续 泄漏 是根据设计进行的。如果网络在达到 2/3 参与度时停止 泄漏，则它将面临再次回到非最终性的风险。这种 泄漏 "惯性" 使我们能够超调到更高的参与度状态。

EJECTION_BALANCE 的作用是什么？

EJECTION_BALANCE 调节验证者在失效 泄漏 期间开始被放入驱逐队列的时间。更快或更慢的驱逐是否会显着影响最终性恢复和限制验证者损失？

上一节显示了失效 泄漏 的一个示例性案例。但是，要获得 100 万个索引的网络的准确数字，Python 规范太慢了。每次运行在中等硬件上需要 10-30 分钟。为了更快地迭代，我将简化的 Bellatrix 规范翻译成一种更快的语言，并使用不同的设置计算了关键指标（源代码）。

为了估计 EJECTION_BALANCE 常数的影响，运行了一个新的模拟来计算两个主要变量作为非活动验证者百分比的函数：

• 失效 泄漏 停止 - 这是失效 泄漏 停止之前的时间（以天为单位）
• 总余额销毁 - 在模拟结束时销毁的网络范围内的总余额，定义为所有活动验证者的最大失效得分为 0 时。

该模拟使用 Bellatrix 常数、1e6 初始活动索引以及所有验证者的 32 ETH 的相等初始余额。结果如下所示

源代码和列表结果

除了不切实际的高值之外，EJECTION_BALANCE 对我们的两个主要变量没有显着影响。在大多数验证者的初始余额为 32 ETH 的模拟场景中（今天的主网），当前驱逐条件（EJECTION_BALANCE = 16 ETH）与根本没有驱逐条件（EJECTION_BALANCE = 0 ETH）的影响是最小的。

MaxEB (EIP-7251) 下的驱逐条件

EIP-7251：增加 MAX_EFFECTIVE_BALANCE，从而扩展了验证者可以拥有的可能的活动余额的范围。自从创世以来，信标链一直以所有验证者为目标，使其活动余额范围在 16 ( EJECTION_BALANCE) 和 32 ETH ( MAX_EFFECTIVE_BALANCE) 之间。

正如我们之前看到的，EJECTION_BALANCE 对最终性恢复没有意义上的贡献。那么，它最初为什么要添加呢？信标链依赖于验证者具有足够统一的余额，以确保委员会是多数诚实的。由于委员会的选择不是基于余额的，因此 16 ETH 的下限确保随机选择的索引以非常高的概率是多数诚实的。

使用 EIP-7251，活动余额范围扩展到 16 ( EJECTION_BALANCE) 和 2048 ETH ( MAX_EFFECTIVE_BALANCE_EIP7251) 之间

让我们探讨一下这种扩展范围的影响：

它会影响最终性恢复吗？

不会，正如我们在上面看到的，降低驱逐余额不会显着影响恢复时间。增加活动余额的上限在概念上等同于降低下限，即降低驱逐余额：

它会增加非最终性期间 泄漏 的余额吗？

在非最终性期间，平均 泄漏 的余额不是驱逐余额的函数，因此 泄漏 的余额百分比将与今天大致相同。有关确切数字，请参阅上一节。

它会增加最终性期间驱逐离线验证者的时间吗？

是的，使用 EIP-7251，及时最终性期间的离线验证者理论上可能会损失更多余额。但是，失效惩罚非常小，即使从 32ETH 开始，验证者也需要数十年才能达到 EJECTION_BALANCE。

等待 30 或 50 年才能被驱逐是一个次优选择。相反，永久离线的验证者（例如由于密钥丢失）应使用 EIP-7002（执行层可触发的退出）退出验证者，并且遭受的损失远少于等待任何安全的 EJECTION_BALANCE 值。如果长期离线的验证者成为一个全网络范围内的问题，则有充足的时间（数年）来设计和交付解决方案。

总结

是否应修改驱逐机制以适应 EIP-7251？

我们已经确定：

1. EJECTION_BALANCE 对最终性恢复没有意义上的贡献
2. EJECTION_BALANCE 对于清理永久离线的验证者没有用
3. 使用 MaxEB，网络可以处理大范围的活动余额

因此，我们应该什么都不做。将参数保留在 EJECTION_BALANCE = 16，交付 EIP-7002，并提高客户端多样性，以便权益质押者不必担心失效 泄漏。

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