退出约7,000个验证器：优化以太坊验证器退出的案例研究

2026年4月30日 发布在 节点运营商、 研究、 教育 分类下，作者 Lido Analytics

2025年12月，A41宣布其决定逐步停止验证者运营，作为这一退出过程的一部分，终止其作为 Lido Curated Node Operator (NO) 的参与。

尽管 A41 提前提供了合理的通知时间，但它要求于 2026 年 1 月 31 日前淘汰所有基础设施，因此 Lido Analytics 工作流的贡献者针对 A41 运营的 6,918 个验证者设计了一种退出策略，以在此过程中最大程度地减少质押奖励损失。

该策略结合了协调的自愿退出、批次执行以及考虑扫掠周期的时机安排，结果如下：

• 与约 78 ETH 的自然退出基线相比，奖励损失减少了 4.42 倍
• 通过分批执行方法，总奖励损失降至 17.64 ETH
• 平均扫掠等待时间从历史水平的 4.5 天缩短至约 0.8 天

以下案例研究介绍了该方法、关键假设、操作执行以及从此次退出中汲取的经验教训。

如何开始的

公告发布后不久，Lido 贡献者启动了治理流程以促进运营商的退出，期间 DAO 批准将 A41 的 targetValidatorsCount 参数设置为 0。

此参数设定了存入特定节点运营商的验证者数量目标值，而 0 则表示分配机制应引导退出请求指向由该 NO 运营的已存入验证者。

退出参数

在规划退出过程时，几个网络参数对于确定预期的退出时间线以及验证者提款相关的协议成本尤为重要：

• 以太坊网络 APR： 3.0%
• 验证者扫掠周期： 8.5 天
• 平均验证者扫掠时间： 4.5 天
• 最大退出流失限制： 每个 epoch 256 ETH
• 验证者队列长度：
  • 进入队列： ~9 天
  • 退出队列： ~19 天

如需复习上述术语，请参阅 Consensys 的 ETH 质押提款终极指南。

A41 验证者

公告发布时，A41 在 Curated Module 内运营着 6,918 个活跃验证者（占 Lido 存入验证者的 2.51%）。A41 的大部分验证者聚集在相似的索引范围内。

验证者索引的分布在制定退出策略中起着重要作用。索引决定了验证者何时有资格根据以太坊扫掠周期进行提款。在此周期内，区块链会扫掠整个验证者集（从索引 0 的验证者开始），并在每个 slot 中识别最多 16 个有资格进行部分或全额提款的验证者。在下一个 slot 中，过程会从上次停下的地方继续，顺序遍历整个以太坊验证者集。一旦到达最后一个验证者，周期便从头重新开始。

考虑到它们的索引分布，A41 验证者的很大一部分在周期中大约同一时间点进入扫掠管道，大约在第三天到第四天的过渡期，如下图所示。

退出建模与规划

为了确定在 A41 要求的退出时间线内最小化质押奖励损失的最高效退出策略，Lido Analytics 工作流的贡献者评估了可能的退出场景及其对执行时机和可能在此期间损失的奖励的影响。

自然退出容量

为了确定这些退出是否可能自然发生，贡献者分析了 Lido 历史提款数据，模拟了通过用户发起的提款合理预期能退出多少验证者。

基于截至 2025 年 12 月 1 日的历史数据及 1,000 次模拟。

基于 30 天历史数据和平均值，自然退出整个 A41 验证者集大约需要 80 天时间。然而，目标运营商退出日期 2026 年 1 月 31 日仅剩 52 天。

更长的历史数据集得出更高的预测值，但这些估计被认为代表性较低。

• 90 天数据：约 8,016 个验证者
• 360 天数据：约 12,281 个验证者

因此，很明显仅依赖自然退出不可能在规定时间内完成退出。此外，A41 验证者索引分布高度集中。

贡献者得出结论：按时完成退出需要自愿退出。挑战在于在保持操作可行性的同时，最小化对 Lido 协议的财务影响。

退出优化策略

一个基线场景假设所有 A41 验证者立即开始退出。这种方法可能会导致大部分退出在 1 月初完成。考虑到验证者扫掠时间，估计奖励损失总额约为 78 ETH，占每日协议奖励的 10.5%。

基于验证者索引分布和当前扫掠周期持续时间，Lido Analytics 贡献者模拟了 A41 验证者潜在退出窗口的范围：

基于 2025 年 12 月 8 日至 10 日进行的计算。

由于验证者提款过程依赖于验证者扫掠周期，时机不佳的退出可能会显著增加验证者等待扫掠的时间，导致不必要的奖励损失。因此，关键优化目标是最小化每个验证者的可提款 epoch 和扫掠 epoch 之间的时间。在上面的图表中，这可以通过将预期提款时间（蓝色条）与验证者扫掠（橙色）对齐、最小化它们之间的延迟差距来体现。

模拟结果显示，如果能以预定义的时间触发退出：

• 极高精度将导致约 35 ETH 的奖励损失总额
• 0.5 天容忍度——约 45 ETH

然而，单独执行约 7,000 个精确定时的退出需要大量人工干预且操作效率低下。为解决此问题，贡献者提议以协调批次执行自愿退出。

批次退出设计

批次方法引入了几项操作参数，以平衡精度、安全性和操作简便性。

• 在请求退出与预期提款资格窗口之间引入了 60–225 个 epoch（约 6–24 小时）的安全间隙。该缓冲应能缓解潜在风险，包括其他人发起的大规模并行退出、部分提款以及扫掠周期预测中的微小误差。
• 还引入了每日最大批次大小 1,800 个验证者，这对应于以太坊每日可退出的最大验证者数量。

退出调度工具

为实现此批次方法，Analytics 贡献者建议部署一个脚本，用于确定自愿退出的最佳时机。调度逻辑整合了多个实时网络参数，包括：

1. 当前 epoch
2. 扫掠指针的当前位置
3. 验证者退出队列的大小

此外，贡献者引入了 0.5 天（12 小时）的扫掠接受水平。该参数使得当验证者的可提款 epoch 与扫掠 epoch 之间的预计时间低于扫掠接受阈值时，能够识别出需要退出的验证者。这应能将预计退出奖励损失减少约 8.6 ETH。

基于这些，脚本会生成针对特定节点运营商的退出分配顺序。经过审查和调整后，结果可以导出为最终分组文件，使 NO 能够在整个过程中持续监控验证者行为的同时请求退出。

退出超过 200,000 ETH

A41 实现了自己的脚本来调用批次自愿退出。该脚本在定义的退出窗口内手动触发。在执行所有批次的退出之前，使用了一个测试批次来验证该方法。

测试批次

第一个批次包含 181 个验证者，作为测试运行退出，以确认工作流和工具按预期行为。它有意包含了索引高度分散的验证者，因为分割它们会增加操作复杂性而不提高效率。

退出脚本成功处理了非顺序的验证者集；实际奖励损失为 2.23 ETH。

协调批次执行

在测试批次成功后，又规划了四个批次进行退出。操作工作流结构如下：

1. Lido Analytics 贡献者定义并共享所有验证者批次的详细信息，包括执行顺序和大致目标时间线。
2. 在执行前约 24 小时，贡献者与 A41 确认每个即将到来的批次的启动。
3. A41 在约 12 小时的退出窗口内触发退出脚本，使退出与预测的最佳时机对齐。

批次 #2

第二个批次包含 1,792 个验证者，在测试一天后执行。

Analytics 贡献者预测，如果在预测的 epoch 窗口内触发退出，平均扫掠等待时间应约为 226.8 个 epoch。执行后，实际扫掠时间为 244 个 epoch，显示了模型与实际网络条件之间的强一致性。

批次 #3

第三个批次包含 1,708 个验证者，计划在 1 月中旬进行。建模估计奖励损失为 2.78 ETH。

批次 #4

第四个批次是最大的，包含 1,800 个验证者。预测扫掠时间为 215 个 epoch，实际为 211 个 epoch，由此产生的奖励损失总计 4.37 ETH。

一个场景建议在批次 #4 中退出所有剩余验证者（3,237 个）。然而，模拟显示这样做会导致约 8.16 ETH 的奖励损失。

批次 #5

相反，剩余验证者被分为批次 #4 和 #5，使退出与扫掠周期更紧密对齐。这将最终批次的奖励损失减少到 3.15 ETH。

批次结果概览

所有批次的结果汇总于下表。

\* 一个测试批次，包含索引高度分散的验证者。

协调过程在预期时间范围内产生了可预测且分布均匀的验证者退出模式。

通过将验证者退出与扫掠指针和退出队列条件对齐，Lido 贡献者与 A41 团队共同实现了奖励泄漏的大幅减少。关键结果：

• 成本降低：与估计的 78 ETH 自然退出基线相比，计划退出策略将奖励损失减少了大约 4.42 倍。
• 效率提升：通过分批执行方法，实际实现的扫掠奖励损失 降至 17.64 ETH，显著优于最初为“精确”退出建模的 35–45 ETH 范围。
• 时间优化：平均扫掠等待时间从历史水平的 4.5 天减少到大约 0.8 天。

• 各批次间的一致性。每批次的平均奖励损失约为 3.53 ETH，显示了与批次大小无关的持续高效性。

以太坊队列时间影响

规划大规模退出时的一个基本挑战是以太坊验证者队列的不可预测性。虽然历史数据可以提供有用的模式，但队列条件可能会迅速变化，因此这是一个无法确定预测的动态参数。

尽管 Lido 贡献者使用历史队列模式进行了大量分析，但在 A41 退出过程中，以太坊的状况以难以预料的方式演变。

在退出计划设计时，退出队列大约为 18.64 天。到实际执行时，队列已减少到不足一天，从而可以更准确地预测何时应发起自愿退出。

然而，激活队列却朝着相反方向演变。当第一个测试批次退出时，激活队列已增加到 18.88 天。随着退出过程的展开，激活队列继续显著扩大，平均激活队列时间达到约 42.8 天，之后验证者才能重新激活。

图表基于 validatorqueue.com 数据，由 beaconcha.in 提供。

对优化收益的影响

协调退出策略将平均扫掠等待时间从约 4.5 天减少到 0.8 天，大幅提高了提款效率。然而，这最终被激活队列的意外增长所抵消。

这一结果凸显了一个重要教训：

即使高度优化的验证者退出策略，也仍然受到网络层级参数更广泛动态的影响。

尽管如此，协调退出过程仍然显著减少了提款期间放弃的奖励。

进一步的影响

实际退出结果证明了自然退出与计划退出策略在放弃的质押奖励方面存在重大差异。虽然所使用的方法是针对特定节点运营商情况和网络条件定制的，但其基本原则具有广泛适用性，可用于：

• 管理大型验证者集的协议；
• 专业质押提供商；
• 机构或大规模质押者；
• 协调验证者轮换或整合的 NO。

下表展示了在预定义 epoch 中自然退出行为与精确定时退出之间的估计差异。

例如：

• 自然退出 10,000 ETH 将导致约 3.45 ETH 的奖励损失，而精确定时的退出可将此减少 23 倍。
• 在 50,000 ETH 时，差异增加到约节省 16.5 ETH。
• 在 100,000 ETH 时，通过优化的退出时机，可能损失的奖励中 95.56% 可被保留。

当验证者数量规模达到数十万 ETH 时——如 A41 退出案例所示——这些效率收益变得更加显著。

值得分享的经验

A41 退出案例提供了几个操作见解：

1. 退出时机很重要

验证者退出不是瞬间事件。退出请求、扫掠和提款处理之间的时机可能会显著影响在此过程中放弃的奖励数量。

2. 验证者索引分布影响退出

了解索引分布有助于规划批次调度和退出顺序，以使验证者退出与扫掠和提款周期更好地对齐。

3. 批次操作提高了运营效率

对于大量验证者，尝试单独触发退出可能不具有成本效益。基于批次的退出策略允许在扫掠周期对齐与操作简便性之间取得平衡。

4. 数据驱动的协调可改善结果

此退出案例说明了结合以太坊历史数据分析和持续监控的价值，以便在最小化奖励损失的同时，与网络动态保持紧密对齐。

5. 网络队列仍然不可预测

验证者队列是一个动态网络变量。规划应始终包含监控和灵活性，包括应对意外延迟的缓冲，而不是仅依赖静态预测。

结语

协调退出约 7,000 个验证者证明，与自然流程相比，仔细建模、批次调度和实时协调显著减少了奖励损失，同时保持了可预测的验证者操作。

随着以太坊质押规模的不断扩大，类似方法可能越来越适用于验证者生命周期管理，包括验证者轮换、基础设施迁移、自然提款和大规模退出。

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