以太坊验证者退出过程 及 Pectra 硬分叉带来的变化

^对于一个相对加密原生的五岁小朋友…

作者 mike neuder 和 mallesh pai – 2025年3月17日 🍀🇮🇪☘️

非常感谢 Paul Harris、Mikhail Kalinin、Lucas Saldanha 和 Alex Stokes 的评论和讨论。

本文分为两个部分。

• 首先，我们澄清当前以太坊共识机制中验证者退出过程如何限制提现速率（以及限制速率的理由）。
• 其次，我们将解释即将到来的布拉格/ Electra 硬分叉将如何改变这一点（具体而言，基于EIPs 7002和7251）。

在随后的一篇文章中，我们将提出各种改进退出队列的方法，同时保持以太坊的安全特性。

相关工作：

• Validatorqueue.com: 提供当前验证者集的实时数据。
• Neuder、Pai 和 Resnick 关于权益证明区块链的退出队列优化: 形式化退出队列问题并研究潜在改进。
• EIP-7251: 增加验证者的MAX_EFFECTIVE_BALANCE的EIP。下面将详细讨论。
• EIP-7002: 允许执行层触发部分提现的EIP。下面将讨论。
• Beacon Chain Specs: 布拉格/ Electra 共识规范。
• EIP-7251中的验证者合并: 解释合并机制的细节。
• Electra 有效余额: EIP-7251的描述和实例。

第1节 – 当前退出是如何工作的

我们首先呈现当前的验证者退出流程，以帮助在即将到来的布拉格/ Electra 硬分叉下进行上下文化的变化。

1.1 – 术语

验证者退出 - 验证者退出是验证者表示离开共识集并回收其抵押的ETH的过程。验证者退出可以是自愿的或强制的（如果验证者被削权）。对于本文档，我们重点讨论自愿退出流程。

完全提现 - 完全提现是在验证者退出中发生的。32 ETH的全部本金和任何剩余的共识奖励被提现并发送到验证者定义的地址。

部分提现 - 部分提现是在不将验证者移出共识集的情况下从验证者中提取一些ETH。部分提现不允许验证者的余额低于32 ETH的最低阈值。到目前为止（布拉格/ Electra 之前），部分提现是自动的。

提现凭证 - 一个执行层地址（可以是EOA或合约），作为从共识层提取的ETH的目标地址（部分和完全提现都发送到相同的提现凭证）。

活跃 验证者 - 活跃 验证者是共识协议的一部分，预计将继续提议和证明区块。活跃 验证者获得共识奖励。

可削权的验证者 - 可削权的验证者拥有依舊受制于协议的标准削权规则的ETH，无论他们是活跃 的还是不活跃 的（不再在共识集合中）。

1.2 - 退出过程

我们描述截至2025年3月，以太坊协议如何处理退出和提现，直到布拉格/ Electra （缩写为Pectra）硬分叉。下图展示了自愿验证者退出的三个阶段。每个阶段详细介绍如下。

1. 阶段1：退出队列：当一个验证者发起自愿退出时，协议基于速率限制的FIFO退出队列计算exit_epoch（验证者正式从活跃 共识集合中移除的时间）。如果队列为空，退出可以在未来最多五个epoch内发生（见 compute_activation_exit_epoch），但如果队列中有许多待处理的退出，那么即将退出的验证者可能需要等待。“流动性”限制的计算用于确定给定epoch中可以退出的验证者数量为 max(8,⌊# validators/216⌋)（见 get_validator_activation_churn_limit）；截至2025年3月，这对应于⌊1,051,723/216⌋=每个epoch 16个退出（例如，如果队列中有160个验证者，一个新排队的验证者将在10个epochs后退出，大约一个小时）。在此阶段，退出的验证者仍然是活跃 的（参与共识）并且是可削权的（负有权责）。
2. 阶段2：提现能力延迟：一旦验证者的exit_epoch已经过去，将使用256个epochs（27小时）的固定延迟（见 MIN_VALIDATOR_WITHDRAWABILITY_DELAY）来计算他们的withdrawable_epoch（此时验证者不再可削权）。这个固定延迟是一个安全缓冲，以提供充足的时间让协议在链上包含任何削权证明，即使退出队列为空。在此期间，验证者不再活跃 （以防他们在提现之前立即犯下削权违规），但在任何之前的签名下仍然可削权。
3. 阶段3：验证者清算：一旦验证者的withdrawable_epoch过去，他们不再可削权，其ETH准备发送到其提现凭证中指定的地址。这些完全提现与部分提现以顺序方式处理（见 get_expected_withdrawals，这显著增加了它们的延迟。所有提现通过依次遍历按验证者索引进行处理。截至今天，所有验证者的余额超过32 ETH的都会为他们自动创建一笔部分提现。[1] 因为这个验证者“清算”每个区块只能处理16笔提现（见 MAX_WITHDRAWALS_PER_PAYLOAD），因此这意味着循环处理整个验证者集需要9.1天[2]（因此完全提现的平均额外延迟为4.55天）。

退出系统的最小时间是27小时（如果退出队列为空并且验证者索引与清算准确对齐）。如果验证者没有战略性地安排他们的退出请求，即使退出队列为空，提现大约需要5.7天才能完全清除。

1.3 – 附注：为什么需要退出队列？

退出队列确保由验证者集完成的交易的经济安全。如果一个恶意的验证者可以在没有任何延迟的情况下立即退出该集合，那么他们可能会试图通过发布一个区块而隐瞒一个冲突区块来执行双重消费攻击，在使他们的抵押退出协议后再释放那个冲突区块。在这种情况下，削权机制将无法持有这个恶意验证者的责任，可能会存在两个互相冲突的完成交易（如果攻击者持有 1/3的总抵押并成功将 2/3的诚实多数分开）。

观察: 经济安全随着时间的推移而下降！ 动态验证者集的质押出现的一个奇怪现象是，一笔完成交易的经济安全会随着时间的推移而下降。一旦一笔交易被完成，

1/3的验证者集合将会在检测到冲突的完成区块时可削权。不过，随着时间的推移，某些在两个冲突区块上双签名的验证者可能会退出系统。退出并提现其ETH的验证者不再可削权；因此，1/3的抵押并未完全追究责任。以太坊通过指定一个“弱主观性期”来认识到这一点，以限制在固定时间内可以退出的验证者集的比例。当然，随着时间的推移，一个原建议链更不容易重组（因为“分叉选择”规则规定投票最多的链被视为原建议链），即使其最终确定性的原始经济安全性正在下降，我们仍然对最终交易给予更高的结算保证。

CHURN_LIMIT_QUOTIENT=216的选择是基于粗略的启发式方法，即应该约花费一个月时间让10%的抵押退出[3]（或者等价于三个月时间退出1/3的抵押）。我们可以将这个看作“一笔完成交易的经济安全在一个月内下降至多为10%”。

重申一下：无论任何提现率，交易的经济安全随着时间的推移而下降！这一（稍显反直觉的）事实意味着协议必须在更快的验证者退出（更方便）和更慢的验证者退出（提供更好的可靠安全保证）之间做出权衡。有关该主题的更多背景信息和相关工作，请参见 “优化退出队列”。

第2节 – Pectra硬分叉中的变化

简而言之：变化很小。

1. 退出队列（上面的阶段1）被限制为每个epoch最多256 ETH（相当于8个32 ETH的验证者）。
2. 验证者合并（详见下面定义）根据总抵押的ETH进行限速；在一百万个32 ETH的验证者时（即我们大约现在所处的状态），每个epoch可以处理232 ETH的合并。
3. 待处理的执行层（缩写为EL）触发的部分提现在每个区块中处理，在增加验证者清算（上面的阶段3）之前处理。这些EL部分提现作为退出队列流动性的一部分被限速。
4. 验证者可以选择退出验证者清算（上面的阶段3），而是选择通过将他们的共识奖励再投资到他们的验证者余额中来使他们的抵押复利。验证者通过更新其提现凭证，以具有0x02前缀向协议发出信号。"合成提现许可证" 的这个选择可能缩短清算持续时间，因为触发的自动部分提现会更少。

上面第1和第2点在2.2中详细说明；第3和第4点在2.3中扩展。

2.1 – 新术语

增加MAX_EFFECTIVE_BALANCE（MaxEB） - Pectra硬分叉包括EIP-7251，允许验证者的余额在范围[32,2048] ETH内（而不是严格限制为32 ETH）。查看“一个适度的提议”以获取该EIP的动机更多信息。

合并 - EIP-7251还允许控制多个验证者的实体直接合并其余额（而不是对此类验证者中的一些触发验证者退出，然后在其他验证者中存入）（参见“EIP-7251中的验证者合并”获取此流程的文档）。这避免了验证者的ETH长期处于不活跃 状态，并不盈利的潜在低效。

执行层触发的退出/部分提现 - EIP-7002允许验证者直接从执行层触发退出/部分提现。一个验证者具有两种身份 - 一个用于共识任务的验证密钥和一个指定提现发送地址的提现凭证。[4] 到目前为止，只有验证密钥可以通过发送共识层信息触发退出。通过该EIP，两者撤回和退出都可以由提现凭证中指定的EOA或合约触发。

复利验证者凭证 - 以前，验证者的限制为正好32 ETH。在验证者清算（上面阶段3）期间，所有获得的共识奖励自动提现到用户指定的提现凭证中。随着EIP-7251的推进，验证者拥有更高余额的能力，现在可以选择将其标记为“复利”（见 switch_to_compounding_validator），这意味着在验证者清算期间其余额不会被自动删除。只有在验证者的有效余额达到新的最大2048 ETH时，自动部分提现才会启动。

2.2 – 退出队列流动性限制的变化

之前，每个验证者都有恰好32 ETH，流动性限制（即验证者集合的变化速率）以“验证者数量”为单位（例如，每个epoch16个验证者退出）表达。由于现在的验证者具有异构的余额，因此这不再可行。因此，流动性的计算必须以ETH作为单位 - 见 get_balance_churn_limit，它将限制定义为

⌊ETH抵押/216⌋。在一百万32 ETH的验证者时，

⌊32,000,000/216⌋=每个epoch 488 ETH可以循环出。此可流动的ETH分为两个部分。

1. 退出 - 自愿退出可以通过共识层或执行层触发。这些退出最多可以消费256 ETH的总流动限制（见 MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT）。
2. 合并 - 合并提供一种协议内功能，通过不完全退出共识机制来合并多个验证者。这旨在减少摩擦，使大型质押池能够将许多32 ETH的验证者合并成较少的具有更高余额的验证者。合并在每个epoch内会消耗部分总流动的ETH。特别地，它们消耗任何来自get_balance_churn_limit的余额，这些余额没有被退出占用（见 get_consolidation_churn_limit）。在上述百万验证者的例子中，我们最多有

488−256=每个epoch 232 ETH由于合并而被消耗。

附注: 为什么需要对合并进行速率限制？ 考虑以下情形：验证者A 和 验证者B各有2000 ETH。让验证者B合并到验证者A。现在，验证者A拥有4000 ETH，超过新的MAX_EFFECTIVE_BALANCE的2048 ETH。验证者清算检测到这一点并作为自动部分提现移除1952 ETH。这些部分提现不受限（历史上，该抵押处于不活跃 状态）；因此，1952 ETH恰好绕过了退出队列。在综合段流动性的限速过程中，这是必要的，以保护负责的安全性。

附注: 整并是一种临时解决方案。 在稳定状态下，质押池没有理由将ETH存入新验证者，随后再合并到另一验证者。相反，他们会直接存入余额超过32 ETH的现有验证者中。协议内部的合并机制只是一种权宜之计，用于加速减少验证者集合的流程（以验证者数量进行计量）。在将来移除该合并机制，可能会减少技术债务并简化规范。

2.3 – 验证者清算变化

目前，任何余额超过32 ETH的验证者都会在验证者清算（上面阶段3）时自动提现。这些自动提现与全额提现在同一队列中处理，通过线性地遍历验证者索引并检查每个验证者是否能够完全或部分提现。请记住，目前每个区块有16次提现（见 MAX_WITHDRAWALS_PER_PAYLOAD）。在Pectra中，未自动的部分提现可以通过从验证者提现凭证发送执行层请求来启动。每个区块最多可以处理八笔EL部分提现（见 MAX_PENDING_PARTIALS_PER_WITHDRAWALS_SWEEP，而剩下的八笔提现则通过验证者清算（无论是自动部分还全面提现）（见 get_expected_withdrawals）来填补。

请注意，上述措施不会减慢验证者清算，因为每个验证者可以有EL或自动部分提现，但不能同时有。验证者可以选择继续采用超过32 ETH的默认硬上限进行自动提现，或者通过更新为“复利”提现凭证，停止自动提现。他们选择之间的选项是：

1. 继续进行超过32 ETH的自动提现 - 保持今天的行为。
2. 选择复利奖励 - 允许验证者将奖励重新投资到其验证者有效余额中，并增加其超过32 ETH的抵押。自动部分提现将仅在验证者余额达到2048 ETH后恢复。

复利凭证与退出程序相关，因为它们可能会改变验证者清算的持续时间。如果许多验证者切换到复利提现凭证，他们将有效地选择退出验证者清算（上面阶段3）（验证者会被跳过，直到他们达到2048 ETH）并因此不算计算每个区块处理的最大16次提现。

–

感谢你的阅读 ❦

1. 这稍微不准确；如果验证者没有指定提现凭证，他们在清算时会被跳过。由于这极少数验证者（自2023年4月Capella以来没有选择接受任何提现），我们在本文背景下忽略此问题。↩︎

2. 每个slot 16 个 ⟹每分钟80个 ⟹每小时4800个 ⟹每天115,200个。以1,053,742个验证者计算，我们得出 ≈9.1天。↩︎

3. 以 1,053,742个验证者为例，我们的流动限制为 每个epoch 16个退出。

每天225个epoch ⟹每天3600个退出 ⟹每30天108,000个退出。 然后 108,000/1,053,742≈0.10。↩︎

4. 在机构质押/质押即服务的情况下，提供本金的实体（或其保管人）持有提现凭证，而服务提供者只持有验证密钥（用于签署共识消息）。在这种安排中，持有提现凭证的主体无法独立选择退出并开始提现流程，从而导致了一些不安全的变通方式，例如预签名退出。随着退出可以直接从执行层触发，这些变通方式将不再是必须的。↩︎

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