EIP-7251：提高验证者的最大有效余额

我经常谈论理性乐观——在2022年熊市的高峰期，我写了一整篇关于理性乐观与加密的交集的文章——并且我倾向于自我认同为“理性乐观者”。但是，不少人像Naval Ravikant和Andreessen Horowitz这样的专家不会告诉你，理性乐观有许多缺点。

成为理性乐观者不仅仅是着眼于解决问题；这还涉及到 (a) 承认在解决现有问题的过程中，你可能会创造出新的问题——这些问题只会在以后的某个时候显现出来，和 (b) 处理看到自己过去解决问题的行为导致当下另一个问题产生所带来的绝望。正如一场TED演讲所述，进步的艺术本质上就是创造新的问题来解决：

“进步并不意味着每个人的状况时刻都变得更好。这将是一个奇迹，而进步不是奇迹，而是问题的解决。问题是不可避免的，而解决方案会创造出新的必须相应解决的问题。” — 史蒂文·平克

这个半哲学的引言对于讨论“为极客而生”系列中的下一个以太坊改进提案（EIP）至关重要：EIP-7251。EIP-7251是对以太坊权益证明（Proof of Stake, PoS）共识协议的一个提议更改，这一变更将Beacon链上验证者的最大有效余额 (MAX_EFFECTIVE_BALANCE) 从32 ETH提高到2048 ETH。EIP-7251还引入了验证者合并功能，这将允许大型质押者通过将多个验证者的余额合并为一个验证者，从而运行更少的验证者。

虽然EIP-7251看似是一个简单的变化，但提高验证者的有效余额是对核心协议最重要的更改之一——可能与启用取款一样——自“合并”以来的变更之一。本文提供了对EIP-7251的粗略概述，包括实施该EIP的优点和潜在缺点，并提供足够的细节来帮助理解增加验证者 MAX_EFFECTIVE_BALANCE 的原因与方式。

让我们深入探讨！

为讨论设置舞台：以太坊共识中的宁静缺失

以太坊过渡到权益证明（前称“以太坊2.0”）最初被称为“宁静（Serenity）”升级（我不知道为什么选择“宁静”这个名字——但是许多人期望这次升级能解决以太坊的所有问题，所以这个名字似乎是合适的）。现在，我们获得的以太坊2.0（注意，我只是为了历史背景而使用“以太坊2.0”）并不是一些人想象中的以太坊2.0（即，达到类似Visa的规模，执行分片(sharding)，或者从EVM过渡到eWASM以实现更高效率），但它是可用的。

例如，目前单独质押者已占Beacon链验证者集的相当比例——回忆一下，降低运行验证者的门槛是转向权益证明的主要目标之一——而以太坊PoS保持了“抵抗第三次世界大战”的能力，尽管对于质押中心化方面有所担忧。虽然有一些粗糙之处，包括 关于LSD的一些问题（指的是流动质押，而非药物），但没有严重到足以阻止Beacon链作为经济安全的“绿色”去中心化结算层运行。

目前看来，以太坊的共识似乎没有问题，但问题隐藏在表面之下。

其中一个问题是拥有一个极大验证者集的负面二次效应（目前Beacon链上有超过1,000,000个活跃验证者）。

拥有许多验证者在理论上改善了以太坊的去中心化，尤其是如果将其与传统的权益证明协议进行比较，这些协议将共识的参与限制在100-200个“超级验证者”之内。但一个极大的验证者集会引发一些对网络健康和长期可持续性有影响的问题。不出所料，许多这些问题只有在以太坊验证者集在“合并”后的几个月内增加的过程中变得明显。

尽管以太坊的验证者集的增长是不可避免的，尤其是考虑到流动质押的普及，但庞大的验证者集在一定程度上是早期设计决策的结果（在技术圈被称为“技术债务”）。这说明了为什么我先从理性乐观的哲学讨论开始——以展示解决方案的生成如何导致复杂问题的产生，从而需要更复杂的解决方案。

在这里所说的设计决策是什么？将验证者的最大有效余额 (MAX_EFFECTIVE_BALANCE) 限制为32 ETH。接下来的部分我们将了解有效余额的含义，并探索将最大有效余额限于32 ETH如何促进了Beacon链上不断增长的验证者集。

理解以太坊中的MAX_EFFECTIVE_BALANCE

一个以太坊的验证者有两个余额：实际余额和有效余额。“实际余额”只是验证者的初始存款和奖励之和，减去任何罚款和取款。有效余额是从验证者的实际余额得出的，代表了“从协议的角度看，验证者所承担的最大风险金额。”我们可以进一步细分这个定义，以便更好地理解验证者的有效余额：

1. “验证者所承担的最大风险金额”是对权益证明核心原则的参考：经济安全是协议能力的函数，即能够对被视为对协议攻击的行动施加高成本——无论这些行动是故意的还是意外的——通过销毁在加入协议之前所抵押的部分或全部担保金。协议违反行为的一个例子是关于区块有效性的谎报（每个验证者“投票”一个区块，当有证据证明该区块包含有效交易时，预期验证者应该投票支持该区块）。这就是为什么像以太坊的Gasper这样的PoS协议被设计用验证者的余额来做决策，例如选择一个验证者提议一个新区块，计算奖励，以及针对明显背离协议规则的验证者进行惩罚。理论认为，拥有“更多风险”的验证者在不诚实行为下的诱因较少，因为不诚实行为的惩罚是动态的，并且会随着验证者所抵押的担保金的增加而增加。在Beacon链上下文中，验证者的有效余额决定了验证者在共识协议中的权重或影响力。例如，当投票支持一个区块的验证者的总质押量代表所有活跃验证者总质押量的超级多数（66%或更多）时，Beacon链的一个区块就会成为最终区块（即，不可逆转的）。要理解在Beacon链共识中如何以及在哪里使用验证者的有效余额，我鼓励阅读有效余额的经济方面。
2. “从协议的角度看”意味着Beacon链始终将每个验证者视为在协议中最多抵押32 ETH（最大有效余额）。任何超过最大有效余额的其他金额不被视为“处于风险中”，并且无法被抹除——也不会计入验证者因正常履行责任而获得的奖励——这使得它在协议的角度看是“无效的”。

一个验证者的实际余额在开始获得奖励并且没有被抹除时将出规定性地增加。但是，Beacon链在每个区块处都进行“清扫”，并自动将超过32 ETH的金额提取到验证者提取凭证中指定的执行层地址（有关提取凭证的详细讨论，请参见EIPs For Nerds #2: EIP-7002 (可执行层可触发的退出)）。并不是每个验证者都会立即收到部分奖励，但大多数估计表明，验证者每隔5-7天将获得部分奖励。

为什么最初将MAX_EFFECTIVE_BALANCE设为32 ETH？

32 ETH作为MAX_EFFECTIVE_BALANCE的数值是从原始分片路线图延续下来的特性。当时，愿景是将以太坊网络分成64个子网络（shards），每个子网络并行处理一组交易，而Beacon链作为网络的协调层。

在这种安排下：

• 每个在Beacon链上的活跃验证者被分配到一个委员会，该委员会负责为一个纪元中的32个插槽之一生成证明。为每个插槽提供证明的委员会被分成16个子委员会（即，Beacon委员会），目标是64个验证者和每个子委员会最多128个验证者。
• 每个子委员会将验证64个分片中的一个，并对来自分片提议者的区块进行证明。分片提议者在向Beacon链广播区块头之前，会聚合至少2/3子委员会验证者的证明。
• 在插槽的“主要”委员会中的验证者会通过检查区块头（描述为“交叉链接”）并确认子委员会中大多数（2/3）验证者签署区块的情况，来投票确认分片区块的有效性，这些签名对应于现有验证者的公钥。

以太坊早期分片设计的架构。

这种分片设计的一个担忧是，分片可能因为不诚实的验证者处于多数而受到攻击——控制了足够的委员会成员来证明分片交易的对手（例如，>2/3）有很高的概率让Beacon链确认无效的分片区块。因此，必须确保：

• 每个协议中的验证者都有相等概率出现于一个分片的委员会中。这使得攻击者难以预测其控制的验证者是否会最终出现在特定的分片委员会，从而降低恶意接管一个或多个分片的可能性。
• 验证者在共识协议中具有大致相同的权重或影响力。没有这一特性，攻击者仍有机会在子委员会中获得过大的影响力，因为这个协议使用的是证明 blocks 的验证者总权重（每个验证者质押的金额），而不是投票验证者数量（投票支持区块的验证者数量），来确定一个区块是否有资格进行最终确认。

问题 #1 的解决方案是设计一个可验证随机函数 (VRF)并将其用作信息化验证者分配委员会的随机源。下面是验证者随机分配的视觉描述：

(来源)

解决问题 #2 意味着限制每个验证者的有效余额——它代表了其在协议中的权重——为一个固定的32 ETH。如果MAX_EFFECTIVE_BALANCE是可变的，攻击者可以在委员会中控制2/3的质押量即可确认无效区块——即使该委员会中的2/3验证者是诚实的。相反，给每个验证者在委员会中相同的权重可以降低少数验证者对某个分片共识施加不成比例影响的可能性。

你可能还会注意到MAX_EFFECTIVE_BALANCE也是激活验证者所需的最低存款额（32 ETH）。这并非巧合。与原始提案的最低存款额为1500 ETH不同，较低的激活余额32 ETH提升了更多人运行Beacon链验证者的可能性，并确保对手控制2/3委员会的验证者的可能性微乎其微。最低委员会大小解释提供了对这一概念的正式解释，并有助于理解原始的子委员会安全设计。

为什么32 ETH的MAX_EFFECTIVE_BALANCE不再是必要的？

一旦Danksharding替代了原始分片路线图，子委员会变得多余。更重要的是，Beacon链的安全属性（例如，通过共识协议确认的交易有效性）不再依赖于假设每个子委员会中2/3的验证者是诚实的。

为什么会发生变化？

• 在执行分片模型中，每个分片预期运行EVM（以太坊虚拟机）的一个实例并处理状态转变。若控制了子委员会中大多数验证者的攻击者可能会进行恶意操作，比如通过确认无效状态转变窃取智能合约中的资金。
• 同样，原始数据分片设计（在Danksharding之前）也要求大多数验证者必须诚实。否则，恶意的分片提议者可能会进行数据隐瞒攻击——拒绝发布已发布到分片的数据块——并减少依赖以太坊获取数据可用性的Rollups的活动性和安全性。
• Danksharding已经取代了这两种分片设计，将多提议者模型替换为单提议者模型：在插槽期间，真正向Beacon链添加的区块只有一个，所有相关的验证者都对该区块进行投票。由于每个子委员会都在对同一组交易进行投票，因此攻击者需要控制在插槽中所有活跃验证者的超级多数才能发动成功的攻击（例如，确认一个无效的区块）。

需要澄清的是，插槽中的验证者仍然被划分为子委员会；然而，将验证者分配到子委员会的唯一好处是提高在Beacon链上聚合证言的效率。作为背景说明，合法的区块必须通过拥有的有效质押量的超级多数（>= ⅔）代表一个插槽委员会的合格验证者签名；假设所有验证者的最大有效余额均为32 ETH，提议者需要获得66%的插槽委员会验证者签名。

在子委员会引入了聚合器，每个子委员会将有16个聚合器，以降低提议者和验证者的带宽要求：

• 一个聚合器收集从子委员会分配的验证者处获得的区块证明（签名），并使用BLS签名聚合算法创建聚合签名。来自子委员会的聚合器将聚合证明发送给提议者，而提议者选择“最佳”的聚合证明（“最佳”意味着“拥有最多签名的聚合证明”）。
• 好处：提议者不必聚合赋予插槽的数万名验证者的签名（以太坊链目前有800,000多个验证者，因此在一个32个插槽的纪元中，每个插槽将有约25,000名验证者进行验证）。此外，插槽委员会中的验证者仅需验证64个聚合签名，而无需在最终确认一个区块之前验证数千个区块的签名。

在子委员会中必须有一个诚实聚合器，因为验证者只有在其证明被包含在区块中时，才能影响Beacon链共识机制。一个不诚实的聚合器可能会通过拒绝向提议者广播聚合证明或排除一组验证者的证明来操纵分叉选择规则。然而，如果子委员会中的16个聚合器中至少有一个诚实而不存在审查行为，子委员会中的诚实验证者便可以影响Beacon链的分叉选择机制。

发现子委员会可以在诚实小多数（1-of-N）假设下运作暗示着将 MAX_EFFECTIVE_BALANCE 设置为32 ETH的常量已不再必要。我们可以在“没有损坏就不修复”的精神下不去动它的最大有效余额，但是限制验证者的 MaxEB会产生新问题，而这些新问题在以太坊的质押吸引力不断增加的情况下进一步恶化。

为什么今天把MAX_EFFECTIVE_BALANCE限制在32 ETH是个问题？

想象一下你正在经营一个质押服务，并承诺对质押的ETH提供令人惊艳的年利率（APR）。为了履行你的承诺并从中获利，你需要从验证中赚取足够的奖励来偿还承诺的收益并覆盖运营成本。然而，Beacon链将每个验证者的最大有效余额限制在32 ETH，并自动安排每一个额外的wei进行提取；更重要的是，即使你的验证者的余额在提取清扫之前达到了33 ETH，额外的1 ETH也处于无效状态，并不会计入奖励的计算中。

幸运的是，有一个简单的解决办法：你可以将多个验证者的过剩余额合并，以资助一个新的32 ETH验证者并开始获得新的奖励。重复此过程（赚取奖励→提取奖励→将奖励合并至32 ETH→激活新验证者）可以复利应用质押奖励，确保你能让质押者满意，支付税款并保持盈利。你甚至可以通过在同一台机器上运行多个验证者来增加经济规模中的收益（一个“验证者”只是一个通过公钥-私钥对标识的计算机进程）。

“这不是财务建议。”

乍一看，这似乎是一个为机构质押服务或质押池而设的好商业模式。但不需要天才就能看出问题所在：一个大型质押池被迫启动多个验证者，以最大化盈利，即使同一个实体操控这些验证者。最后一部分强调了网络对验证者的看法与现实世界对验证者的看法之间的区别：

• 网络将每个验证者视为一个独立实体：验证者在存款合约中存款后进入入队列（存款消息用独特ID进行索引）；一旦激活，验证者发送的证明必须与其他验证者发送的证明分开处理。此外，两个验证者的余额不能在协议内合并；两个验证者都必须退出之后，它们的质押才能合并并用于资助一个新的验证者。（这两个验证者的累积余额必须低于32 ETH的 MAX_EFFECTIVE_BALANCE，这样新的验证者才能为每单位ETH的质押获得奖励。）
• 在现实场景中，多个验证者的资金可能来自相同地址，也可能分享相同的提取凭证。此外，在网络中广播的消息（包括证明和自愿退出）可能来自控制多个验证者签名密钥的同一实体。类似地，两个验证者的存款消息可能来自同一操作员，该操作员只是将现有验证者的奖励集中到一起来激活新的验证者（所有验证者在同一台机器上运行）。

例如，目前最大的质押池（Lido）控制着超过275,000个验证者，且有40多个节点操作员。看到验证者与节点操作员之间的不成比率，不需要天才就能看出“Lido的275,000个验证者”可以更准确地描述为“Lido的6,875个验证者”（假设每个操作员控制相等数量的验证者，且所有验证者都运行在同一台机器上）。但是Beacon链依然将Lido视为拥有275,000个验证者，这是某些人描述为“人工去中心化”的情况。

Beacon链上的人工去中心化面临不同的挑战：

• 问题 #1：同一（逻辑）实体处理共识消息所消耗的计算资源更多，正如之前所提及的，存款和证明必须按每个验证者维度逐一处理。这增加了p2p层的负担，而这些冗余消息的广播使得共识节点同步链变得困难。
• 问题 #2：出于最大化收益，质押服务和质押池必须运行多个验证者而导致开销增加。将现有验证者的奖励合并至一个新验证者的过程也非常繁琐——一个新验证者必须在入队列中等待变动时间（这可能长达一个月或更久），具体取决于当前队列的容量。

虽然问题 #2并不严格是协议开发者的关注点，但问题 #1却对以太坊共识的健康和稳定性有负面影响。

• 较高的带宽需求可能会使个人质押变得不具吸引力，因为硬件升级的额外成本。因此，这带来了束缚，以太坊链的设计（如32 ETH作为最低质押金额）本应防止这种状况。
• 客户端开发者可能不得不实施优化以应对增加的带宽和内存需求，这增加了频繁的代码重写和更新中出现错误的风险。目前，共识相关的数据，如存款、验证者公钥和证明存储在Beacon链状态中，并且共识客户端必须将此状态保留在内存中，以计算有效的状态转变。
• 在最坏的情况下，多个验证者可能无法及时处理共识消息，以跟上其他链的进展，从而暂时脱离网络。这可能导致Beacon链无法最终确认区块，特别是当剩余验证者集合未达到66%需质押门槛以上以证明一个区块从而达成以太坊定义的最终确认时，如SMD-GHOST算法所定义的。

这些并不是理论上的担忧，近期的一些事件暴露了大型验证者集的缺点：

• 以太坊最终性上的级联网络效应讨论了发生在2023年7月22日的两个不最终确认事件，在这两个事件中，投票验证者的数量降低到66%以下。根本原因是一个bug导致共识客户端在处理有效但过时的证明时消耗了计算资源，从而阻碍验证者处理更新的证明。在这种情况下，有效但过时的证明的数量可能加剧了这一问题。如果证明的数量较低，理论上，客户端可以更快地回弹至网络虽然未能以与当前纪元的证明频率一致的速度进行处理。
• 在Devconnect 2023 演讲中，Mike Neuder(以太坊基金会的研究员和EIP-7251的作者之一)讨论了开发者们在协调2.1百万验证者的测试网时的经历——该链由于无法让共识客户端处理来自验证者的高数量证明而无法长时间最终确认。将这一发现置于背景中，Beacon链已经接近900,000名验证者并且鉴于当前存款数量，很可能在未来几年内达到200万个验证者。
• 此外，实验对使用最先进的聚合方案（如Horn）时可以高效聚合的BLS签名数量设置了上限。这对以太坊路线图上未来的升级，如单插槽最终性和原生提议-建造者分离（ePBS），具有影响，因为这些方案依赖于在短时间窗口内广播并批准一定数量的证明（例如，单插槽最终性需要在一个插槽的12秒时间段内聚合和验证超过超级多数的签名（66%以上））。

EIP-7251作为减少以太坊验证者集的解决方案

提出的对Beacon链无限制验证者集问题的解决方案包括：

• 调整验证者经济学（例如，减少奖励）。由于质押池可以通过合并旧验证者的奖励激活更多新验证者，减少验证者的奖励可以减缓在Beacon链上激活新验证者的速度。
• 限制随时可以活跃的验证者数量。一旦验证者集达到容量，就会激活一个机制以限制活跃验证者数量的增长，并保持验证者集在执行新的安全机制与最终性类型上运作所需的水平。

这两种方法都涉及具有重大后果的激进变化：

方法#1需要对质押收益进行重大变更，可能对质押生态系统产生广泛的二次效应。方法#2在验证者集达到预设限制之后将产生权衡：“旧验证者保持”（OVS）机制会冒着确立一定验证者集群的风险——尽管短暂；“新验证者保持”（NVS）机制会引入一个MEV拍卖，因为验证者在后MEV的世界中会竞争进入Beacon链（甚至旧有验证者也可能被激励与新进入者竞争），在MEV收入大于验证者收益的情况下。

但是，还有一个简单易行的方法可以有效地收缩以太坊的验证者集。这个解决方案在EIP-7251中提出，并源自一个简单的观察：通过允许由同一实体运营的多个验证者合并为单个验证者，我们可以减少Beacon链上的人工去中心化。

思考一下一个假设的节点操作员在运行四个验证者：根据当前的Beacon链规范，每个验证者必须分别签署区块，从而膨胀验证者集，因为同一个人掌控四个验证者。EIP-7251提议一种验证者合并机制，使节点操作员将四个32 ETH验证者合并为一个总质押额为128 ETH的验证者。

从操作员的角度来看，这很有意义，因为他们只需为现在控制的一个验证者签署一个消息；从网络的角度来看，一个96 ETH的验证者可以被视为一个验证者（而不是四个32 ETH的验证者），这减少了共识协议需要处理的证明数量。重要的是，它并没有改变协议的任何内容——验证者仍然会根据抵押金额进行惩罚和 reward（例如，96 ETH的验证者与72 ETH的验证者的惩罚方式不同）——并保持现有的经济安全保证。

但是实施以太坊上的验证者合并面临一些障碍：

• 当前的MAX_EFFECTIVE_BALANCE = 32 ETH是硬编码在Beacon链协议中，并且需要改变才能使验证者合并成为现实。具体来说，MAX_EFFECTIVE_BALANCE必须增加足够的倍数（k），以降低Beacon链上验证者数量的合并。
• 目前没有机制可以在协议内对验证者（验证者#1）的余额进行标记，使其应当添加到另一个验证者（验证者#2）的余额。验证者#1必须退出Beacon链，然后才可以通过“补充”将来自验证者#1取款的资金增加到验证者#2的余额。这在用户体验方面并不理想，因为想要合并两个或更多验证者的质押操作员必须让这些验证者退出，并合并他们的质押以资助一个新的验证者。

EIP-7251（恰当命名为EIP-7251: 增加MAX_EFFECTIVE_BALANCE）修改了Beacon链的规范，并引入了一系列实施和激励合并验证者所需的变更。在下一部分中，我们将深入了解这些变更，然后讨论实施EIP-7251的优缺点，尤其是增加验证者 MAX_EFFECTIVE_BALANCE 的提议。

EIP-7251概述：增加MAX_EFFECTIVE_BALANCE

EIP-7251引入了一个对核心共识协议的重大改变：将MAX_EFFECTIVE_BALANCE从32 ETH增加到2048 ETH（其中k=64），同时将MIN_ACTIVATION_BALANCE定义为32 ETH。这消除了验证者合并的最大障碍，且无疑也是通过验证者合并来收缩以太坊验证者集的重要组成部分。

此外，为了不降低现有的安全机制或增加个人质押者和质押服务的操作费用和风险，还有其他在实施验证者合并时所需的特性。因此，EIP-7251——与该EIP的名称暗示的相反——不仅增加了验证者的最大有效余额。我们将在后续对这些更改进行详细讨论：

注意：这只是对EIP-7251提出的更改的粗略概述，而不是对（当前）规范的深入解释。对于更详细的概述，我鼓励阅读草案规范和由EIP-7251作者编写的常见问题文档。

增加MAX_EFFECTIVE_BALANCE并创建MIN_ACTIVATION_BALANCE

EIP-7251将MAX_EFFECTIVE_BALANCE从当前的32 ETH更新为2048 ETH，但它没有改变验证者加入Beacon链所需质押的最低金额。这似乎是自相矛盾的（或不可能的），因为验证者的激活资格目前是通过检查is eligible_for_activation_queue()与MAX_EFFECTIVE_BALANCE在Beacon链处理时进行检查。

EIP-7251通过引入新常量MIN_ACTIVATION_BALANCE（设置为32 ETH）来解决这一矛盾，其表示激活新验证者所需的最低有效余额，并修改is_eligible_for_activation_queue以检查MIN_ACTIVATION_BALANCE而非MAX_EFFECTIVE_BALANCE。这确保了即使在新的MAX_EFFECTIVE_BALANCE值下，个人质押者仍然可以继续质押32 ETH，并保持Beacon链的经济去中心化。

一个重要的注意事项：EIP-7251已与其他标准集成。验证者将更新由EIP-7685引入的新0x02复利提取凭证。将具有32 ETH的MIN_ACTIVATION_BALANCE，并定期获得部分奖励。

引入新的复利提取凭证（0x02）与EIP-7685结构配合使用

EIP-7251引入了新的复利提取凭证（0x02），以补充EIP-7685请求结构的使用。“复利提取”的命名反映了验证者可以通过切换到0x02凭证复利收益。由于奖励计算是根据有效余额的比例进行扩展的，因此累计更高有效余额（直到MAX_EFFECTIVE_BALANCE限制）而非从32 ETH的最低激活余额中提取过剩余额，可以随时间推移增加验证者的收益。

COMPOUNDING_WITHDRAWAL_PREFIX = Bytes1('0x02')
MIN_ACTIVATION_BALANCE = Gwei(2**5 * 10**9) (32 ETH)
MAX_EFFECTIVE_BALANCE = Gwei(2**11 * 10**9) (2048 ETH)

复利提取前缀由（现在修订过的）is_partially_withdrawable_validator函数检查，该函数确定验证者是否有资格进行自动部分提取。如果验证者具有0x02凭证，则get_validator_excess_balance()函数获取验证者的余额，而is_eligible_for_activation_queue()函数检验验证者的余额相应MIN_ACTIVATION_BALANCE并返回任何过剩的金额作为部分提取量。请注意MaxEB可以是2048 ETH或根据验证者的偏好定义为任何低于2048 ETH的值（稍后会对此功能进行更多介绍）。

如果验证者具有0x01提取凭证，get_validator_excess_balance将会比较验证者的有效余额与MIN_ACTIVATION_BALANCE并反馈任何优先权作为部分提取金额。这个措施保留了自动部分提取正在进行中的功能，并且对继续质押32 ETH的质押操作员在奖励涂抹工作流程上进行了最低干扰。

def get_validator_excess_balance(validator: Validator, balance: Gwei) -> Gwei:
    // 获取验证者的过多余额以进行部分退出
    if has_compounding_withdrawal_credential(validator) and balance > MAX_EFFECTIVE_BALANCE:
        return balance - MAX_EFFECTIVE_BALANCE
    elif has_eth1_withdrawal_credential(validator) and balance > MIN_ACTIVATION_BALANCE:
        return balance - MIN_ACTIVATION_BALANCE
    return Gwei(0)

注意：关于如何从 0x01 提取凭证迁移回 0x02 复利提取凭证的细节仍比较少——验证者可能能够在协议中进行一次性的改动（类似于0x0 → 0x01轮换），或者需要先提取资金再进入具有新的提取凭证。等核心开发者就这一决定达成共识后，我会更新这篇文章。

协议内的验证者索引合并

EIP-7251引入了一种新的合并操作，可以在不要求两个验证者退出Beacon链的情况下，将两个验证者合并为一个有效验证者。合并操作会将源验证者的余额转移给目标验证者，并由源验证者的签名密钥签署。

以下是EIP-7251规范中关于合并操作的结构示范：

class ConsolidationRequest(object): 
    source_address = Bytes20 
    source_pubkey = Bytes48 
    target_pubkey = Bytes48

这项变更减少了希望在无须经历繁琐退出整个活跃集及合并所提取的资金，以激活新的验证者的个人质押者和质押池的操作负担。合并操作由源验证者提交，并像任何其他Beacon链操作（例如，存款与自愿退出)在一个纪元中进行处理。我们随后会对此合并操作进行更详细的解释。

回顾：自愿验证者退出是如何作用的？

自愿退出 Beacon Chain 验证者的工作流程。 (source)

EIP-7251 的协议内合并操作使用了现有自愿退出操作的元素，因此在解释协议内合并之前，了解自愿退出的工作原理是有帮助的。以下是自愿退出程序的粗略概要：

1. 验证者签署一个 VoluntaryExit 对象并通过点对点网络广播，以便将其纳入 Beacon 块。在处理 Beacon 块时，会调用 initiate_validator_exit 函数，并在 BeaconState 中设置即将退出验证者的 exit_epoch 和 withdrawable_epoch。

成功表明离开活跃验证者集合的意图后，即将退出的验证者被放置在退出队列（exit_queue）中。验证者在完全退出 Beacon Chain 之前在退出队列中等待的时间取决于换血限制和待处理验证者退出的数量。我们将在本文稍后的部分讨论换血限制的规范，并查看它如何影响验证者退出（在现状下及在启用 EIP-7251 时）。

验证者在等待离开退出队列的同时，预计继续执行共识职责（如验证区块和参与委员会）。此延迟由 exit_epoch 定义：即即将退出的验证者变得不活跃并可停止执行 Beacon Chain 职责的时代。请注意，验证者在等待退出队列期间仍在赚取奖励。

1. 当验证者在 exit_epoch 后停止验证/提议时，他们在达到 withdrawable_epoch 之前无法提取抵押的 ETH。可提取的时代是通过将 MIN_VALIDATOR_WITHDRAWABILITY_DELAY 加到 exit_epoch 来计算的：最小验证者可提取延迟设置为 256 个时代的常量（大约 27 小时），因此即将退出的验证者在完全退出 Beacon Chain 之前必须等待持续时间为 exit_epoch + MIN_VALIDATOR_WITHDRAWABILITY_DELAY。

在可提取的时代开始时，验证者的余额被转移到提取凭据中指定的执行层地址。请注意，验证者在退出时代后不再赚取奖励，但在提取被在可提取的时代处理之前，仍可能因过去的违规行为被削减。

实施最小延迟 27 小时提供了足够的时间来检测协议违规行为，并防止有故障的验证者在不受罚的情况下退出抵押。

以下图形展示了自愿退出操作的时间线：

(source)

协议内验证者合并是如何工作的？

EIP-7251 在希望与另一个验证者合并的验证者的自愿退出操作的机制上进行了轻微修改。下面的图形描述了协议内合并两个验证者的过程：

我们将确定一些术语：

• source: 希望将其有效余额分配给目标验证者的验证者。
• target: 积累源验证者余额的验证者。
• Consolidation: 源验证者和目标验证者签署的对象，以表示希望在不退出协议的情况下合并其余额的意图。

以下是合并过程的概要：

1. 与常规的 VoluntaryExit 消息一样，签署的合并对象必须通过点对点网络广播并被包含在 Beacon 块中，以启动将源验证者的余额转移到目标验证者的过程。在包含签署的 Consolidation 对象的 Beacon 块处理期间，会调用 initiate_validator_exit 函数，并为源验证者触发自愿退出。

当调用 initiate_validator_exit 时，源验证者的退出时代和可提取时代在 Beacon 状态中被设置。在块处理期间，还会调用 insert_pending_consolidation 以将源和目标验证者的 pending_consolidation 插入 Beacon 状态。

1. 在源验证者等待退出队列期间，它必须继续执行 Beacon Chain 职责，直到可提取的时代。但是，不是将验证者的余额发送到提取地址，而是将其分配给目标验证者，并增加后者的有效余额。

资金转移发生在时代处理期间（process_epoch → process_pending_consolidation）。在这一步，调用 apply_pending_consolidation 来将源验证者的余额转移到目标验证者的余额，并完成合并过程。

1. 合并操作通过检查源和目标验证者是否具有相同的提取地址来进行认证。确认源验证者和目标验证者具有相同的提取地址是确定两个验证者是否由同一实体控制的一种简单方式。这样，我们就可以知道所有方都批准了合并操作，并且没有人强行在未授权的情况下转移验证者的余额。

如果我们仅依赖于验证者签名密钥的签名来验证合并操作，可能会出现这种特殊情况（无效合并操作）。例如，攻击者可以破解签名密钥，并签署一个恶意的 ConsolidationRequest 对象，将验证者的余额转移到攻击者的目标验证者。

然而，要求成对合并中的验证者共享相同的提取凭据会为不重用提取凭据或将验证者映射到多个提取地址（而不是单个提取地址）的质押池和质押公司造成问题。例如，控制两个 32 ETH 验证者的质押池需要退出两个验证者，并使用新的 64 ETH 验证者重新进入 Beacon Chain。

一种替代方案是通过 ConsolidationRequest 消息对源和目标验证者的提取密钥进行签名验证。由于提取密钥对抵押的 ETH 拥有最终所有权，因此来自任何一个验证者提取密钥的签名提供了我们批准合并所需的证据——即使源和目标验证者具有不同的提取凭据。

但这要求在 Beacon Chain 上实现验证执行层签名的机制（共识层使用 BLS12-381 曲线，而执行层使用 Secp256k1 曲线），或者引入一种机制，使合并操作可以在执行层上进行验证（类似于在 EL 上处理的 EIP-7002 提取）。这两种方法都会引入额外的复杂性，正如一些人所描述的，已经“触及了协议的许多部分”。

合并操作规范的这一部分有可能发生变化，特别是像 RocketPool 这样的庞大质押池（使用超过 1000 个存款地址资助由节点操作员控制的验证者）在当前设计下可能发现合并困难。如果发生这种情况，我会更新此文档以反映规范的变化。

当验证者合并时，削减是如何工作的？

协议内合并并未改变削减过程的内容。与 VoluntaryExit 一样，源验证者在达到指定的可提取时代之前，仍然可以对其原始余额（初始的 effective_balance）进行削减。目标验证者也可以因为其初始的 effective_balance 而被削减——至少在我们达到源验证者的 withdrawable_epoch 之前。

此时，源验证者的余额会转移到目标验证者手中，后者将负责两个验证者的合并余额。如果目标验证者在源验证者的提取时代中（合并余额之后）犯下可削减的过错，它将在合并后根据其 effective_balance 按比例被削减。

下面是一幅图，描述了合并期间削减是如何归属的：

(source)

允许验证者为 MAX_EFFECTIVE_BALANCE 设置自定义上限

一旦一个验证者的余额超过 MAX_EFFECTIVE_BALANCE，其提取到提取地址的通过系统级操作将自动执行，不需要验证者主动发起交易。值得注意的是，部分提取扫荡为质押者提供了一种无Gas费用的机制，便于从共识层“提取”奖励，并为质押者提供了一种可靠的收入来源，以帮助覆盖运营成本（以及其他用途）。

将 MAX_EFFECTIVE_BALANCE 从 32 ETH 增加到 2048 ETH 可能会导致部分提取扫荡的延迟，尤其是对于独立质押者和质押池，他们可能无法立即达到 2048 ETH 的上限（你可以想象独立质押者累计足够的奖励，达到 2048 ETH 的余额需要多长时间）。为了确保增加 MAX_EFFECTIVE_BALANCE 不会对质押者产生负面影响，EIP-7251 提出了一个新特性，允许验证者为 MAX_EFFECTIVE_BALANCE 设置自定义值，并控制部分提取何时启用。

为澄清起见，迁移到 0x02 复利提取凭据的验证者的默认最大有效余额仍然是 2048 ETH。然而，0x02 验证者可以为 MAX_EFFECTIVE_BALANCE 设置一个低于 2048 ETH 的自定义值，该值可以让 Beacon Chain（修改后的）is_partially_withdrawable_validator 函数检查，以确定验证者是否应进行部分提取扫荡。

一个有用（尽管可能不准确）的心理模型是将 0x02 验证者视为在后 EIP-7251 世界中有两种类型的最大有效余额（MaxEB）——一个常量 MaxEB 和一个变化的 MaxEB —确定部分提取发生的时机：

• 在常量 MaxEB 的 2048 ETH 之后进行部分提取是那些通过更改为 0x02 凭据并未指定为最大有效余额的默认行为的验证者所期望的行为。
• 对于 0x02 验证者，在变量 MaxEB 的情况下进行部分提取发生在有效余额跨越验证者设定的 MAX_EFFECTIVE_BALANCE 的值时。EIP-7251 允许验证者为变量 MaxEB 设置任何值，只要所选值不超过 2048 ETH。

允许最大有效余额的可变量限制确保了质押者仍可以继续依赖于无Gas费用的自动提取（“提取”），作为收入来源。这还使得对独立质押者和更倾向于提取而非在 EIP-7251 下以部分提取验证余额为替代的质押服务的吸引力增加。

添加执行层部分提取

EIP-7002 引入了执行层提取的概念：质押者可以通过向执行层上的“验证者提取请求合约”发送一个提取交易（该交易以验证者的提取凭据签名）来从 Beacon Chain 提取其验证者。提取消息将添加到队列中，执行负载 的 Beacon 块会从此队列中消耗多个提取请求，最多到 MAX_EXITS_PER_BLOCK 的值（16）。你可以阅读 EIPs for NERDS #3: EIP-7002 (执行层可触发的提取) 以获得对执行层触发的提取的全面概述，特别是了解它们与在共识层上触发的自愿提取的比较。

EIP-7002 当前设计支持全量验证者提取，类似于由验证者签名密钥签署的 VoluntaryExit：执行层提取触发将验证者的余额提取到提取地址。然而，EIP-7251 的作者提出了对 EIP-7002 的扩展，使得质押者可以通过在执行层发送交易来触发部分提取验证者的余额。通过此特性，0x02 验证者可以提取超过 MIN_ACTIVATION_BALANCE（32 ETH）的任意金额，而无需等待部分提取扫荡激活。

这是另一个努力，以缓解将 MAX_EFFECTIVE_BALANCE 增加对质押者的影响，同时减少采用 EIP-7251 的障碍。要了解为何这很重要，请考虑现状：在 32 ETH 处的自动扫荡提供了稳定的流动性，并使质押池能定期为质押者支付奖励。相比之下，随着最大有效余额更新至 EIP-7251 的常量 2048 ETH，自动扫荡将在增加最大有效余额的验证者中较少发生。

EIP-7251 的可变 MaxEB 特性缓解了这一问题，但并未完全解决。如果一个 0x02 验证者将自定义最大有效余额设置为 128 ETH，并在 MAX_EFFECTIVE_BALANCE 穿越 128 ETH 时进行部分提取。那么，假设同一验证者的有效余额由于某种原因从 128 ETH 降至 80 ETH（例如，因为宕机被削减）——该验证者需至少再次积累 48-49 ETH 才能重新符合部分提取的资格。

从需要足够流动性以维持盈利的质押者或质押池的角度来看，这可能会更好。通过提取凭据允许质押者部分提取余额——使用 EIP-7002 提供的执行层与共识层之间的传递消息机制——解决了这个问题。验证者现在可以在不退出的情况下，依赖具体要求来从 validator_effective_balance 中提取任意金额：

• 提取者（由提取凭据识别）为执行层上的提取交易支付所需的Gas费用。目前的估计将部分 EL 提取的成本定为 50,000 Gas（包括 21,000 Gas的固定 base_fee）。
• 剩余余额高于 EJECTION_BALANCE（16 ETH）；任何余额低于 16 ETH 的验证者将被自动放入退出队列并强制退出。

我们可以通过考虑上述示例中的一个拥有可变 MaxEB 的 128 ETH 的验证者来展示执行层部分提取的价值。验证者不必等到 80 ETH 增加到 128 ETH 后再提取，而可以选择从现有的 80 ETH 中提取（只要其余额没有低于所需的退出平衡），通过从执行层触发提取操作。

可能会出现的一个问题是：“如果验证者开始移动大量的抵押，那将对以太坊的（经济）安全意味着什么？”这是一个合理的担忧，特别是如果我们考虑到坏行为者利用快速在共识层和执行层之间转移大量资金的自由。然而，还有一个更少理论的问题：以太坊共识协议的特定安全属性取决于假设在特定时间窗口内，退出协议的抵押数量不能超过定义阈值。

没有用于限制验证者抵押部分提取撤回的机制，实施 EIP-7251 可能会破坏某些对以太坊共识协议安全至关重要的不变性。幸运的是，EIP-7251 的作者考虑到了这个特殊情况，并建议对限制 Beacon Chain 上的撤回及存款机制进行修改——我们将在下节讨论此特性。

使用基于权重的速率限制进行退出和存款队列

具有拜占庭容错（BFT）的权益证明协议，如果对手行为——如最终确定两个冲突块——会导致协议削减 ⅓ n 的验证者抵押（其中 n 是总激活赛注），则具有可追溯的安全性。因为完成块需要 ⅔ n 的抵押，所以在时代 n 的高度出现两个冲突块意味着至少 ⅓ 的激活抵押必须对不同块 b 和 b' 双重投票。

在权益证明协议中检测安全失败。 (source)

签名与每个验证者的公钥在加密上关联，因此诚实一方可以证明在该时代中哪些验证者进行了双重签名。但是，为了让权益证明协议削减违规的验证者，超大多数（⅔ n）验证者必须在下一个时代 e+1 中最终确定一个包含双重签名证据的 b+1 块。这意味着攻击者不得控制 ⅔ n（或更多）的总激活抵押，否则它可以选择最终确定不包含告密者证据的不同块。

因此，安全性依赖于假设在时代 n 和 n+1 之间，总的激活抵押不能改变超过 ⅓ n—否则，一名对手可能将其对总抵押 n 的份额从 ⅓ n 增加到 ⅔ * n。这就是为何像 Gasper 这样的 PoS 协议需要在时代转换期间限制抵押流入和流出；重要的是，限制参数必须仔细选择，因为它们决定共识协议提供的经济安全性水平。

请注意，速率限制机制不关心在时代中加入或退出的验证者数量，而是关注验证者权重（即抵押量）在时代 n 和 n+1 的边界变化。这一细节的重要性将在我们讨论 EIP-7251 提议的速率限制机制的变化时显现出来。

在权益证明协议中实施安全性属性。 (source)

根据 EIP-7251 的验证者换血限制

当前，Beacon Chain 的换血限制（即每个时代可以进行的最大验证者激活和退出次数）由 get_validator_churn_limit 函数决定。get_validator_churn_limit 受两个参数影响：MIN_PER_EPOCH_CHURN_LIMIT = 4 和 CHURN_LIMIT_QUOTIENT = 65,536 (2**16)。

第一个参数 MIN_PER_EPOCH_CHURN_LIMIT 表示每个时代至少可以有四个验证者的进出；第二个参数 CHURN_LIMIT_QUOTIENT 更为关键，并通过将其设置为活跃验证者集合的 1/65536（大约 0.0015%）限制每个时代的最大验证者换血，前提是至少有四个验证者处于激活状态。

然而，随着 EIP-7251 实施可变最大有效余额，当前的 get_validator_churn_limit 函数参数在 Gasper 的可追溯安全属性下将变得不足。这是为什么？现有的速率限制机制旨在限制进入和退出活跃验证者集的验证者数量，而不是进入和退出活跃集合的权重。

我们现在之所以能够容忍这一点，是因为将 MAX_EFFECTIVE_BALANCE 设置为常量 32 ETH（也是验证者的最低激活余额）引入了验证者权重与验证者数量之间的粗略相关性。例如，Beacon Chain 验证者的 1/65536（截至撰写时为 897,892 个验证者）约为 13 个验证者——因为每个验证者的最大有效余额最高为 32 ETH，这转化为在当前换血限制规则下每个时代大约流动 438 ETH（13 个验证者 * 32 ETH）。计算 438 ETH 占总抵押（截至撰写时为 28,732,281 ETH）的百分比大约为 0.0015%，即 1/65536——这与 CHURN_LIMIT_QUOTIENT 的值具有相应的关系。

但是，将常量 maxEB 增加到 2048 ETH，并引入可以高于最低激活余额 32 ETH 的可变 maxEB，会破坏这一不变性：

• 假设我们使用以前每个时代 13 个验证者的换血限制，并假设在一个 н 时代中计划退出的所有验证者的 MaxEB 为 2048 ETH。那么每个时代将有 13 个验证者退勤，每个时代将等于 26,624 ETH 的抵押离开激活集合（13 * 2048 = 26624）。
• 将 26,624 ETH 计算为总抵押（截至撰写时为 28,732,281 ETH）的百分比将为 0.0092% 或大约 1/1000 的抵押——这大约是当前换血限制 1/65536 的 64 倍。为了使这一点清楚，针对 2048 ETH 的每个验证者退出 ⅓ x n（33%）的总抵押只需花费 356 个时代（大约 37 小时），而相同的情况，在每个验证者以 32 ETH 的退出换血限制下退出 33% 的活跃抵押需要 21,647 个时代（96 天）。

为了保持换血限制的不变性，EIP-7251 修改了 get_validator_churn_limit，通过考虑所有活跃验证者的余额（总权重）来替代单单考虑活跃验证者的数量。get_validator_churn 现在是一个 Gwei 值，而不是一个 uint64 值，MIN_PER_EPOCH_CHURN_LIMIT 函数用于设定一个时代的最大验证者换血时，使用总活跃余额（即活跃验证者的合计抵押）作为输入，而不是 active_validator_indices（活跃验证者的总数），如下所示：

return max(MIN_PER_EPOCH_CHURN_LIMIT * MIN_ACTIVATION_BALANCE, get_total_active_balance(state) // CHURN_LIMIT_QUOTIENT)

换血限制乘以总的活跃抵押，以确定可在一个时代内进入或离开的最大权重。

EIP-7251 还修改了退出和激活队列，以使用基于权重的速率限制，并且更改了 validator_exit_epoch 和 validator_activation_epoch 的计算——这分别表示验证者退出和激活的时代。首先，它引入了一个新的值 activation_validator_balance，跟踪当前激活队列最顶端验证者的余额，并修改 exit_queue_churn（现在以Gwei 计）以跟踪当前时代即将退出的验证者的余额。它还创建了两个值 exit_balance_to_consume 和 activation_balance_to_consume ，以考虑即将加入或退出的验证者的抵押超过每个时代换血限制的情况。

我们将很快看到基于权重的速率限制如何在激活队列和退出队列中工作：

根据 EIP-7251 的验证者激活

验证者在 Beacon Chain 的时代转换工作流程中的 process_registry_updates 阶段中被激活。activation_balance_to_consume 的当前值取决于时代换血限制（per_epoch_churn_limit）、激活验证者余额 (activation_validator_balance) 和之前被激活的验证者的有效余额。我们可以利用之前例子的细节来理解这一概念：

• 当前时代的换血限制为 438 ETH，而激活队列最前面验证者的有效余额为 200 ETH。意味着 activation_validator_balance 为 200 ETH，当前时代的 activation_balance_to_consume 为 238 ETH（activation_balance_to_consume= per_epoch_churn_limit-activation_validator_balance）。
• 队列中的下一个验证者有效余额为 100 ETH，低于 activation_balance_to_consume（238 ETH）。我们在该时代安排第二个验证者激活，并减少 activation_balance_to_consume，使该时代的剩余值为 138 ETH。现在 activation_validator_balance 为 300 ETH。
• 第三个排队的验证者的有效余额为 250 ETH，它在该时代无法被激活，因为 validator_effective_balance（250 ETH）超过了当前时代的 activation_balance_to_consume 阈值（138 ETH）。 由此推断，激活第三个验证者将违反每个时代换血限制的不变性，因为 validator_effective_balance + activation_validator_balance = 550 ETH，已超过每个时代的换血限制 438 ETH。
• 我们从 validator_effective_balance 中减去该时代的 activation_balance_to_consume，将剩余的验证者余额转存至下一个时代。时代 n + 1 的 activation_validator_balance 设置为 112 ETH，以反映来自时代 n 的剩余验证者余额所带来的换血影响。
• 要获取时代 n + 1 的 activation_balance_to_consume，我们从 per_epoch_churn_limit 中减去 activation_validator_balance，得到326 ETH。第三个验证者未处理的有效余额（112 ETH）低于该时代的换血限制（438 ETH），因此我们可以安排该验证者在时代 n +1 中激活。

根据 EIP-7251 的验证者退出

EIP-7251 修改了 initiate_validator_exit() 函数，以在计算 exit_queue_epoch（即验证者可以退出并完全提现的时代）之前考虑验证者的权重。此外，exit_queue_churn 被修改以累积当前时代即将退出的验证者的余额，exit_balance_to_consume 跟踪退出队列首位验证者的余额。

def initiate_validator_exit(state: BeaconState, index: ValidatorIndex) -> None: ...
    # 计算退出队列时代
    exit_epochs = [v.exit_epoch for v in state.validators if v.exit_epoch != FAR_FUTURE_EPOCH]
    exit_queue_epoch = max(exit_epochs)
    exit_balance_to_consume = validator.effective_balance
    per_epoch_churn_limit = get_validator_churn_limit(state)

    if state.exit_queue_churn + exit_balance_to_consume <= per_epoch_churn_limit:
        state.exit_queue_churn += exit_balance_to_consume
    else:
        # 退出余额转入随后的时代
        exit_balance_to_consume -= (per_epoch_churn_limit - state.exit_queue_churn)
        exit_queue_epoch += 1
        while exit_balance_to_consume >= per_epoch_churn_limit:
            exit_balance_to_consume -= per_epoch_churn_limit
            exit_queue_epoch += Epoch(1)

    state.exit_queue_churn = exit_balance_to_consume  # 设置验证者退出时代和可提取时代
    validator.exit_epoch = exit_queue_epoch
    validator.withdrawable_epoch = Epoch(validator.exit_epoch + MIN_VALIDATOR_WITHDRAWABILITY_DELAY)

将这些细节结合在一起，提供了一个后 EIP 7251 的退出（完全提现）是如何进行的全景：

1. 当验证者发起退出时，initiate_validator_exit 函数检查 validator_effective_balance 是否在当前时代的 per_epoch_churn_limit 阈限内。如果余额在限制之内，则 exit_queue_churn 将增加，验证者的退出队列时代设置为当前时代。
2. 如果验证者有效余额大于 per_epoch_churn_limit，我们通过减少 validator_effective_balance 以调用下一个时代的 exit_balance_to_consume。在下一个时代中，我们检查 exit_balance_to_consume（即来自上一时代的未处理余额）是否低于 per_epoch_churn_limit；如果是，则将验证者的退出队列时代设置为该时代。
3. 如果 exit_balance_to_consume 仍超过每个时代换血限制，我们不断增加 exit_queue_epoch 并减少退出余额，直到 per_epoch_churn_limit 大于 exit_balance_to_consume。此时，可以处理验证者的余额以在当前时代退出，而不会违反每个时代换血限制所造成的限制。

我们可以通过使用与激活相似的示例来理解这一概念：

• 时代换血限制为 438 ETH，下一个退出队列中的验证者的 maxEB 为 2048 ETH；exit_balance_to_consume 高于时代换血限制，因此验证者无法在当前 n 时代退出。我们毫无疑问会在 n 时代中将 per_epoch_churn_limit 从 exit_balance_to_consume 中减去，以获取 n + 1 时代的 exit_balance_to_consume。
• 在 n + 1 时代，exit_balance_to_consume（1172 ETH）仍超过 per_epoch_churn_limit。我们再次减少 exit_balance_to_consume 直到达到时代换血限制。当我们达到 n + 3 时代时，从 exit_balance_to_consume （现在为 296 ETH）中监测到该额度不再高于每个时代的换血限制，即为该验证者的退出队列时代。
• 在 n + 3 时代，将 exit_queue_churn 设置为 296 ETH，以反映在该时代内处理验证者的有效余额（即 exit_balance_to_consume 的余下金额）所造成的换血。

通过 EIP-7251 提出对激活和退出队列的变化，确保大型验证者可以在多个时代内进行完整退出或激活。更重要的是，计算退出和激活的时代使验证者能够以可变的激活余额 和有效余额方式进行，不会违反每个时代限额 1/65536 的限制，确保不会使 Beacon Chain 的活跃集受到过度影响。

根据 EIP-7251 的部分存款和提取

到目前为止，我们已经讨论了 EIP-7251 如何解决在验证者退出和加入 Beacon Chain 过程中可变激活和有效余额的问题，并实施措施以维持 Gasper 的经济安全属性。但它如何处理部分存款和提取，因为随着 MAX_EFFECTIVE_BALANCE 增加到 2048 ETH 及可变 maxEB 特性的实现，验证者可能有更多的 ETH 进行部分提取？

如同退出或加入中大额质押者一样，通过部分提取和存款进入协议中的大量抵押流动（亦称为“验证者补充”）可能会造成问题。为了背景说明：部分存款跳过激活队列，限于每个区块的 MAX_DEPOSITS = 16，高于验证者激活的限制。

在现状下这不是一个问题：如果攻击者可以通过补充将超过 ⅓ * n 的抵押引入协议，则它必定以前损失了相同数量的抵押。请记住，所有验证者必须存入至少 32 ETH 作为担保，且最大有效余额不得超过 32 ETH。

为说明这一点：想象 Beacon Chain 的微型版本，有九个验证者和 288 ETH 的总抵押（每个 32 ETH 的验证者）： ⅔ 的验证者是诚实的，⅓ 的验证者受对抗者控制，这意味着总共活跃抵押 192 ETH 是诚实的，96 ETH 是对抗的。假设攻击者希望在一个时代中将其余额增加超过总激活抵押的 ⅓（96 ETH），在这种情况下，它控制的三个验证者当前的余额必须为 0 ETH，并且通过协议削减，验证者的余额可以下降到 0 ETH。

不过，保持最小激活余额为 32 ETH 并增加最大有效余额改变了这种动态。以先前的例子为例，假设攻击者可以为每个验证者存款 56 ETH，从而将对抗者的总抵押增加到 264 ETH，活跃的总抵押增加到 392 ETH；如果其余的验证者未进行补款，对抗者此时控制的抵押将超过 ⅔，并且能够阻止大规模削减事件。

EIP-7251 要求部分存款必须经过激活队列，并通过前面介绍的基于权重的速率限制机制对补款进行限制，以防止这种特殊情况。这就防止了一名攻击者利用余额补款来规避激活队列，并确保换血维持在 get_validator_churn_limit 定义的限制范围内。但这意味着不增加 MAX_EFFECTIVE_BALANCE 的验证者在余额补款上将会经历可变的延迟（取决于激活队列的拥堵程度）。

一种替代方案是将部分存款上限设定在 32 ETH，这样 0x02 验证者便只能通过补款提高有效余额至 MIN_ACTIVATION_BALANCE，这将保留部分存款的原有行为，且可能消除了限额。这还使那些不采纳 EIP-7251 的验证者可以继续通过补款，快速补充余额并避免因有效余额下降造成损失（理解验证者有效余额 详细说明了有效余额与验证者奖励变化之间的联系）。

然而，限制补款至 32 ETH 将对那些增加 MaxEB 的验证者产生更大影响，如果其因削减或处罚事件而减少。验证者在典型情况下退出前无法通过补款来提升有效余额。

根据 EIP-7251 进行的部分执行层提取将遵循与使用验证者签名密钥触发的总提取相同的基于权重的速率限制模式。为了提供背景信息，从验证者提取凭据触发的完整退出在默认情况下是受到速率限制的：由执行层触发的提取请求将被添加到 Beacon Chain 的 withdrawal_request_queue 中，并以与 VoluntaryExit 消息相同的方式处理。根据 EIP 7002 风格的部分退出也将经过 withdrawal_request_queue，因此在 EIP-7251 下限制部分提取是相对简单的。

修改初始削减罚金和相关罚金

初始削减罚金（由 slash_validator() 函数施加）是施加在执行可削减过失的验证者余额上第一项减少，并与验证者的有效余额成线性比例。例如，具有有效余额 32 ETH 的验证者将面临 1/32 或 1 ETH 的初始罚金。

初始削减罚金是 Beacon Chain 削减机制的一部分，但在 EIP-7251 的背景下，这无疑是最重要的。以说明为例，具有有效余额 2048 ETH 的验证者，将作为初始削减罚金损失 64 ETH（1/32 * 2048 = 64）。这增加了对有效余额较高的大型验证者的风险——这又使我们处于一个困难的境地，因为 EIP-7251 主要旨在鼓励质押池运行更大型的验证者。

当前解决此问题的提议是修改 slash_validator 以施加一个常量减少（1 ETH），或以次线性缩放——而不是成线性——情理上与验证者的有效余额成正比。首个提案确保每个验证者在首次减削时损失确切的 1 ETH；然而，这可以说在险模块中并不那么可行，以此将惩罚更具威逼性，以阻止可削减行为，当较初的 1/32 减削函数（例如，2048 验证者损失と32 ETH 验证者相同的数额）。

相比之下，初始削减罚金的次线性缩放确保了拥有更大余额的验证者受到的惩罚仍然具有比例保障，而不至于增加承担大额度余额的防御者面临的风险。来自 Mike Neuder 等人的削减罚金分析 显示了可以选择不同的初始削减罚金的次线性缩放值，以权衡经济安全与鼓励验证者参与协议有利于行为，如验证者合并。# 切割分析文档

切割分析文档还解决了另一个问题：根据当前的切割规则，具有较大有效余额的验证者可能会遭受更高的相关性惩罚。升级以太坊时，有关相关性惩罚的更多信息可以参考 相关性惩罚——与此同时，你可以将相关性惩罚视为一种威慑措施，以阻止验证者参与对协议的协调攻击（如果某个验证者被切割，并且在相同时间段内有多个验证者因相似的违规行为被切割，则在验证者的提取周期之前会施加相关性惩罚）。

相关性惩罚对于确保协议能够因如最终确认两个冲突区块等违规行为而销毁 ⅓ 的活跃总抵押金至关重要。例如，相关性惩罚的设计使得如果 ⅓ 的验证者因相同的违规行为可被切割，则整个验证者的余额可能被切割（effective_balance 是相关性惩罚函数的输入之一），这在当前的状态下是合理的，因为每个验证者的最大有效余额为 32 ETH。

一旦实施了 EIP-7251，假设每个验证者的最大有效余额为 32 ETH 的假设将失效，验证者的有效余额将增加。但真正的担忧在于 effective_balance 是相关性惩罚函数的输入之一，这使得合并的具有较大有效余额的验证者在大规模切割场景中面临不成比例的高相关性惩罚风险。

为缓解这个问题，EIP-7251 提出了将相关性惩罚的缩放从线性改为二次缩放，以与验证者的 effective_balance 成比例。切割惩罚分析的 “相关性惩罚”部分 显示，二次缩放的相关性惩罚保持了具体的安全保障，特别是在 ⅓ 可切割的场景中，但降低了对单个更高有效余额验证者的风险。

总而言之，EIP-7251 并没有完全改变切割惩罚以单纯 favorecer 大型验证者——一个抵押额更高的验证者在被切割时的损失仍然会大于一个抵押额小的验证者。这是任何具有重大经济安全性的权益证明 (Proof of Stake) 协议的预期行为，或者任何“你投入多少就能得到多少”的安排（风险越高 = 奖励越高）。但是，调整处罚适用系统达成了以下目标：

• 将切割的密码经济学与新现实（更高的有效余额）对齐
• 降低切割风险至大型验证者可以承受的水平，并增加更多验证者选择合并抵押的可能性

为什么 EIP-7251？增加 MAX_EFFECTIVE_BALANCE 的理由

实现 EIP-7251 的大部分好处从先前部分的讨论中显而易见。但是，对于验证者对网络和抵押者增加 MAX_EFFECTIVE_BALANCE 的净收益进行概括可能会有所帮助，尤其是如果你跳过了学习“作为单一抵押者/抵押服务运营商对我有什么好处？”这一部分。

减少共识层负担

Aditya Asgaonkar 的 Removing Unnecessary Stress from Ethereum’s P2P Network 帖子提供了一个很好的概述（从协议开发者的角度来看，大量验证者对 Beacon Chain 的 P2P 网络层所造成的负担）。例如，大量验证者集会增加广播和在网络上传播的消息数量以及在每个周期中必须聚合和验证的证明数量。这些因素相结合可能会增加验证者节点的计算和带宽需求，损害网络性能，并最终损害去中心化。

同样，Dapplion 的 Beacon Node Load as a Function of Validator Set Size 帖子提供了客户端开发者视角下的庞大验证者集问题，这有助于讨论网络性能和去中心化的交集：

• 正如文档中所述， 共识客户端必须将 Beacon 状态的某些部分（例如，存款消息和验证者公钥）保持在工作内存中，以便共识客户端处理区块。验证者集的增加与 Beacon 状态的大小增加相关（例如，更多的验证者 = 更高的 validator_pubkey 的 BeaconState 指纹）。
• 工作内存并非设计用于存储大量数据——这与磁盘存储不同，因此为了与同伴保持同步，投资性能优秀的固态驱动器（SSDs）变得更加必要。但 SSD的成本并不便宜（相较于普通硬盘驱动器或 HDD），这增加了运行验证者的开销，并减少了参与以太坊共识的动力，尤其是对于在家抵押者。

虽然我们已经看到不同的提案旨在减少验证者集的规模（例如，验证者集上限 和 验证者集轮换），但是 EIP-7251 目前是唯一一个在不需要对以太坊的技术基础设施或抵押经济学进行大规模更改的情况下减少验证者的提案。我们可以通过 使用五个最大抵押池的数字 来看到实施 EIP-7251 将带来多大收益：

• Lido：290,000 验证者（31.68%）
• Coinbase：137,000 验证者（14.94%）
• Figment：38,000 验证者（4.1%）
• Binance：33,000 验证者（3.6%）
• RocketPool：27,000 验证者（2.9%）

如果名单中的每个抵押服务将多个验证者合并为具有 2048 ETH 最大有效余额的单个验证者，则结果将是：

• Lido：141 验证者
• Coinbase：66 验证者
• Figment：18 验证者
• Binance：16 验证者
• RocketPool：13 验证者

鉴于这些抵押池合计控制 525,000 个验证者，大规模整合将如前述计算所示，对总的验证者集产生明显的收缩效果。这是简单的算术，因为它假设每个验证者恰好拥有 32 ETH，但仍足以显示验证者整合对减少 Beacon Chain 验证者集的实际影响。

此外，由于切割风险的增加，抵押运营商不太可能立即开始运行有效余额在 2048 ETH 范围内的验证者；更现实的假设是，抵押池将以较小的整合开始（例如，将 32 ETH 验证者合并为 64 ETH 或 128 ETH 验证者）。这就是为什么 分布式验证者技术（DVT）需要进行充分测试，以便部署在生产抵押环境中；通过 DVT，大型验证者可以在多台机器上运行，以增加容错性，加快停机后恢复的速度，并将客户端错误与机器故障的影响限制在单个节点。

解锁未来升级

正如在引言部分所解释的，以太坊路线图上至关重要的升级——特别是单槽最终性 (SSF) 和嵌入式提案者-建设者分离 (ePBS)——只能在验证者集减小或至少保持在合理范围内的情况下实施（例如，请参阅 Vitalik 最近的关于在 SSF 世界中坚持 8192 签名的论点）。EIP-7251 提出了对以太坊验证者集收缩的最小干扰解决方案，有效消除了启动单槽最终性、提案者-建设者分隔（proposer-builder separation）以及其他以“低验证者集”作为依赖项的升级的障碍。

EIP-7251 的一个略微相关的好处是减少对于加速研发工作以应对庞大验证者集挑战的压力（这些挑战大多数伴随着不同的第二次后果，正如过去的讨论所示）。这最小化了对更剧烈更改的需求，例如，在未来的 EIP-7514—— proposing to reduce the validator churn rate——并确保核心开发人员可以花时间在协议的其他方面工作。

使单一抵押具有竞争力

乍一看，EIP-7251 看起来像是让大型抵押运营商生活更轻松的尝试，但增加最大有效余额的提案还有更多内容。例如，由于复利奖励的可用性和能够以灵活的大小抵押 ETH 的机会，单一抵押者也受益于 EIP-7251。这两个特性对于使单一抵押变得有吸引力并增强 Beacon Chain 上的经济去中心化至关重要。

请把事情放入上下文：拥有一个 32 ETH 验证者的单一抵押者需要几年才能获得 32 ETH 的奖励，以激活另一个验证者。相反，拥有多个 32 ETH 验证者的抵押池可以通过合并现有验证者的奖励更快地激活新的验证者。这样，“抵押池”处于有利地位，因为它可以从新激活的验证者那里获得更多奖励。

随着 EIP-7251 的实施，迁移到 0x02 凭证的单一验证者可以重新抵押奖励（与 EigenLayer 的重新抵押模型不同）并通过拥有更高有效余额来获得更高的奖励。这模拟了抵押池采用的复利过程，正如我之前所述，并表明，采用 EIP-7251 对单一抵押者以及大型抵押服务都是理想的。

减少大型抵押池的运营开销

今天的抵押服务运营商正在单个机器上运行从 1,000 到 10,000 个验证者（或更多），这在物流视角下可能会造成问题。由于最大化抵押 ETH 的投资回报 (ROI) 是运行多个验证者的主要原因，EIP-7251 确保抵押池通过在协议中合并验证者余额来继续盈利地运行更少的验证者。

能够设置验证者最大有效余额的可变上限还减少了激活新验证者的必要性，因为在达到 MAX_EFFECTIVE_BALANCE 阈值和自动部分提取开始之前，奖励可以积累和复利更长时间。潜在的好处是，节点操作员可以管理更少的验证者密钥，并减少密钥管理的复杂性。

实施 EIP-7251 有没有缺陷？

对大型验证者增加切割惩罚风险

具有较高有效余额的验证者所承担的切割风险无疑是反对实施 EIP-7251 的最大论点。有人甚至可能会认为，拥有较大可切割余额的验证者的风险大于合并验证者所带来的净收益，尤其是如果初始惩罚和相关性惩罚的线性缩放特性保持不变的情况下。

尽管如此，我将饰演反对派，并提出一些反论点：

• EIP-7251 提议对切割机制（例如，改变初始/相关惩罚的缩放特性）进行修改，如 切割惩罚分析文档 中所述。如果这些提案得到实施，能够显著降低大型验证者的风险概况。
• 在最低所需抵押高于 32 ETH 的世界中——假设是 1500 ETH 根据最初的提案——抵押池仍然会运营，但对验证者切割的经济风险进行推理的启发式方法不同。对每个验证者 320 ETH 的风险对冲比对每个验证者 32 ETH 的风险对冲更复杂，但仍然可能。

“最大有效余额不得超过 32 ETH”的规范自 Beacon Chain 开始以来就一直存在，影响了权益证明协议多年的研发。因此，更改这一点将对选择采用 EIP-7251 的协议产生深远的影响（我强调“选择”以反映 EIP-7251 的选择性特征）。但是，协议设计者能够提出新的经济和技术设计，以考虑在 EIP-7251 下较高的验证者余额是很有可能的。

为了说明这一点，对 Lido 社区抵押模块的风险评估——这个 CSM 将允许 Lido 的节点运营商集进行无许可进入——目前建议的运营商债务为 4 ETH 的安全保证，但带有附加条件：建议的债务量可能会根据像 EIP-7251 这样的提案的实施而变化。由于验证者余额可能超过 32 ETH，提高对验证者节点操作员在无信任抵押池中的债务要求是合乎逻辑的。

同样重要的是，决定采用 32 ETH 抵押规模的原因与显著降低抵押池风险的原因截然不同。也许 32 ETH 的抵押规模以及较低的潜在净损失风险是运营以太坊抵押服务的吸引力之一（我并不是专家）；尽管如此，抵押池的风险大多是与确保网络安全、健康和稳定的目标无关的考虑。

对自动复利抵押奖励的监管担忧

反对实施 EIP-7251 的另一个论点是，将自动复利验证者奖励引入核心协议可能会引起监管机构的关注，特别是如果这意味着 ETH 是一种利息收益性证券。以下是对 Ethresear.ch 上相关评论 的摘录（对 增加 MAX_EFFECTIVE_BALANCE：一项适度提案 的回应）：

“如果一个验证者因验证而获得付款，这就是并且看起来像是一种服务支付。普通人理解这一点。监管机构也理解这一点。如果一个验证者因验证第二件事而获得第二次付款……同样的事情……那就看起来像是服务支付。让我们再用复利重写这一点。第一次，一个验证者因验证而收到付款。服务支付。那么，第二次，验证者会因验证而获得付款……以及因他们投入到系统中的资金而额外获得的奖励（即从第一个服务中获得的付款）。那是什么？那就是利息。普通人会称之为利息。监管机构也会这样称呼。” William Entriken (u/fulldecent)

总结这段评论中的观点：

• 当前，验证者被视为服务提供者。作为运行节点软件和保护网络的回报，验证者受到协议方支付的 ETH 奖励作为补偿——这是最简单意义的“服务支付”。
• 改变验证者奖励模型，以便验证者因拥有更高余额而获得更多的奖励，可能被看作是根据验证者愿意将资金留在系统中而加权支付（例如，类似于银行为了让你把更多资金存入储蓄账户而支付利息）。

我并不是经济学专家，因此，我将将这个方面的（对监管的潜在影响）解决的细节留给财政政策专家。理想情况下，我们应该提前考虑这个边缘案例，避免让监管机构有借口将以太币归类为证券，并对以太坊的基础层进行严格监管。尽管我没有正式经济政策学位，我将为这一论点提供我的见解：

自动复利的验证者奖励是一种增加最大有效余额的副作用，而非主要理由。例如，一个将更新至最大有效余额 2048 ETH 的验证者，本质上将与今天的 32 ETH 验证者相同——这两者都根据其余额从协议中获得奖励和惩罚。为了提供背景，验证者的最低余额（EJECTION_BALANCE）在被剔除出协议之前最高可降至 16 ETH。

如果你的验证者余额为 17 ETH，则可以逐渐增加奖励——只要你没有被切割——直到达到 32 ETH 上限并提取部分奖励。这是一种复利形式，因为根据设计，每次你的验证者余额增加时，协议会增加为你提供的证词奖励。 “从 17 ETH 增加到 32 ETH”的复利在监管机构的眼中可能和“从 32 ETH 增加到 2048 ETH”看起来不同，但如果认为将 ETH 视为证券的唯一原因仅仅是因为 EIP-7251 只是扩展协议的现有属性，那么我们需要与监管机构重新展开对话。

此外，如果一名监管者真的认为，自动复利为注册的抵押服务如 Coinbase 所做，是一种“投资”，他可以简单地要求，抵押者根据获得奖励的金额及何时复利，支付可变税收。这个解决方案可能更难以实施，但认同于将 ETH 的分类重写为商品的“拿锤子的人”的方法可能更好。

增加抵押协议的开发压力

正如我所提到的，32 ETH 的抵押规模已经成为长时间抵押的一个特性，因此许多协议决策都基于这一特性。更改最大允许抵押规模将要求抵押协议重新思考不同的经济和技术组成部分，并可能在短期内增加研发压力。此外，想要固化并使关键组件不可升级的抵押协议将不得不推迟时间表，以考虑 EIP-7251 引入的变化。

例如，RocketPool 在 Atlas 升级中 最近切换到 8 ETH 债务（最初为 16/32 ETH ETH 债务）。如果实施 EIP-7251，合理假设 RocketPool 开发人员和社区将需要重新开启理想债务规模的讨论，以提高安全性每当最大有效余额增加时。注意：这不仅对于 RocketPool 打算要求节点操作者具备财务投入游戏的任何抵押服务都适用。

增加 MAX_EFFECTIVE_BALANCE 对提案者选择的影响

可能出现的另一个问题是，maxEB 变化对提案者选择的影响。直观上，EIP-7251 似乎会通过偏袒有效余额较高的验证者来使机构抵押者和抵押池受益，从而让单一抵押者更加难以竞争。

然而，正像任何直觉一样，假设提高验证者的最大有效余额将不成比例地更有利于大型抵押者这一看法并不是百分之百正确的。 EIP-7521 不引入关于如何选择提案者的任何假设或规则，因为提案者选择已经受到了验证者有效余额与 MAX_EFFECTIVE_BALANCE 比例的影响。

我们可以将作为提案者被选择的过程分为两个阶段：

• 从随机打乱的验证者索引列表中被选中。
• 通过提案者资格检查

Beacon Chain 使用“交换或不交换”的洗牌算法对候选提案者的选择进行随机化。请记住，Beacon Chain 的一个要求是确保对手无法预测其控制的某个验证者是否会被选为某槽的提案者。洗牌算法是随机化选择新提案者过程中的关键部分。

“交换或不交换”的洗牌在其他地方有 广泛描述，但我们主要关心的是过程的第二部分——提案者合格性检查——并将重点放在这个方面。提案者根据以下规范进行选择：

def compute_proposer_index(state: BeaconState, indices: Sequence[ValidatorIndex], seed: Bytes32) -> ValidatorIndex:
    """ 从 'indices' 返回由有效余额抽取的随机索引。"""
    assert len(indices) > 0
    MAX_RANDOM_BYTE = 2**8 - 1
    i = uint64(0)
    total = uint64(len(indices))
    while True:
        candidate_index = indices[compute_shuffled_index(i % total, total, seed)]
        random_byte = hash(seed + uint_to_bytes(uint64(i // 32)))[i % 32]
        effective_balance = state.validators[candidate_index].effective_balance
        if effective_balance * MAX_RANDOM_BYTE >= MAX_EFFECTIVE_BALANCE * random_byte:
            return candidate_index
        i += 1

上述规范中发生的最重要的事情是，我们遍历打乱的索引列表并运行提案者资格检查，以选择下一个槽的提案者。如果验证者不满足条件，我们会移动到列表中的下一个索引并再次运行资格检查，直到找到符合要求的验证者。

要检查验证者是否有资格担任提案者，我们将验证者的有效余额(effective_balance)与选择的随机值 r(MAX_RANDOM_BYTE) 进行比较，比较结果是否符合将 MAX_EFFECTIVE_BALANCE 与 MAX_RANDOM_BYTE 相乘的计算。如果两个结果相等（即 effective_balance * MAX_RANDOM_BYTE 和 MAX_EFFECTIVE_BALANCE * MAX_RANDOM_BYTE 相等），则将该验证者选定为提案者。

我们可以通过一些示例分析验证者在现状下被选为提案者的概率，并查看实施 EIP-7251 是否改变了任何东西。随后的分析采用了来自 Proposer selection with increased MaxEB (EIP-7251) 的公式，展现了增强的 MAX_EFFECTIVE_BALANCE 与提案者选择之间的关系：

1. 假设我们有两个验证者——一个有效余额为 28 ETH，另一个为 32 ETH——而（假设生成的）随机字节 r 为 255。乘以 32（最大有效余额）和 255（随机值r）给我们的结果是 8160。如果一个验证者的 validator.effective_balance * MAX_RANDOM_BYTE ≥ 8160，则该验证者可被选中提案。
2. 如果验证者 A 出现在洗牌后的索引列表中，我们计算它作为提案者被选择的几率为 255 28 / 32 255 = 7140 / 8160 = 0.875。我们也可以计算验证者 B 被选择的几率为 255 32 / 32 255 = 8160 / 8160 = 1。

我们观察到，有效余额为 28 ETH 的验证者 A 有 0.875（87.5%）的概率被选为提案者，而验证者 B 则有 1.0（100%）的概率被选中。考虑到验证者提议的概率已经基于 effective_balance 与 MAX_EFFECTIVE_BALANCE 的比率加权，因此，增加验证者有效余额或变量不会改变提案者的选择。

“但将所有验证者限制在相同有效余额，难道不是意味着大验证者和小验证者有相等的机会被选择提议区块吗？”

如果每个验证者都是由不同的实体控管的，那么是的，限制 MAX_EFFECTIVE_BALANCE 为 32 ETH 将会平衡竞争。更具体地说，当所有验证者的有效余额相同且为 32 ETH 时，每个活动验证者都有相同的概率通过提案者资格检查，有 100% 的机会提案下一个区块，如果它在候选索引列表中排在第一位。

但是我们注意到，很多验证者实际上是由同一个实体控制的，这自然会使提案者的选择更有利于将 32 ETH 资金分配到多个验证者的巨型抵押者。例如，假设我们的系统里面有七张红色的卡片和三张蓝色的卡片，那么随机抽取一张红色卡片的概率就是 7/10 或 0.70（70% 的概率），而抽取一张蓝色卡片的概率就是 3/10 或 0.30。我们不深入讨论数学问题，但可以期待在每次迭代中抽取的概率将更加偏向红色卡片（当牌组中恰好剩下三张红色卡片和三张蓝色卡片时概率才会相等）。

我们可以将相同的逻辑应用于提案者选择：假设我们的验证者集合中有五个 32 ETH 验证者——四个由大型抵押者控制，剩下的一个由单一抵押者操作。大型抵押者在随机洗牌的验证者索引列表中出现的概率为 4/5（0.9 或 90%），而且一旦被选中，他有 1.0（100%）的机会成为提案者。与此同时，单一抵押者出现在随机洗牌的验证者索引列表中的概率是 1/5，而如果他在洗牌列表中排第一，则有 1.0（100%）的机会成为提案者。

这个计算显示，单一抵押者获得选择为提案者的机会，在 MaxEB 从 32 ETH 提高至 2048 ETH 后并不会显著减少。我们可以用之前实例的数字来说明：

1. 大型抵押者决定将自己所有四个（32 ETH）的验证者整合为一个（128 ETH）的验证者，现在我们只有 两个验证者（一个 128 ETH 的验证者和一个 32 ETH 的验证者）。此时的 MAX_EFFECTIVE_BALANCE 变为 2048 ETH，而最后一个示例的 MAX_RANDOM_BYTE 仍然是 r = 255。如果要被选为提案者，该验证者的有效余额和随机值 r 的乘积必须等于 MAX_EFFECTIVE_BALANCE * MAX_RANDOM_BYTE(522240)。

对于验证者 A，被选中提案的概率可以计算为：128 255 / 2048 255 = 32640 / 522240 = 0.06（6% 的概率）。对于验证者 B，被选中提案的概率可以计算为 32 255 / 2048 255 = 8160 / 522240 = 0.15（1.5% 的概率）。

我们立刻注意到，两个验证者成为提案者的选中概率均低于以前的状态；这是 MAX_EFFECTIVE_BALANCE 从 32 ETH 增加到 2048 ETH 的效果。尽管 EIP-7251 没有改变提案者选择的内容，但确实增加了计算新的 proposer_index（选择验证者提议区块）所需的时间。

在 MAX_EFFECTIVE_BALANCE 为 2048 ETH 的情况下，我们需要执行更多的迭代，以找到满足被选择条件的验证者。例如，上一个示例表明，一个 128 ETH 验证者有 6% 的概率被选为提案者，而一个 32 ETH 验证者有 1.56% 的概率被选中提案者。

在这种情况下，我们需要逐渐调整随机字节 r，直到一个验证者的有效余额与 MAX_RANDOM_BYTE 的乘积，等于 MAX_EFFECTIVE_BALANCE 和 MAX_RANDOM_BYTE 的乘积。这被描述为“尝试并增加”的程序。具体的过程在其他地方有 描述，但主要需要知道的是（a）使用计数器值 i 来（伪随机地）生成随机字节（b）如果我们在洗牌列表的末尾而未选择到验证者担任提案者职务，则 g 数值增加，增加了生成的随机字节 r。

在我们的示例中，r 需要增加到 4080，以便一个验证者（128 ETH 的验证者）拥有 100% 的机会担任提案者职务：

• 用 r 为 4080 的当前计算验证者 A 被选中为提案者的概率为：128 4080 / 2048 4088 = 522240 / 522240 = 1.0（100% 的概率）。
• 用 r 为 4080 的当前计算验证者 B 被选中为提案者的概率为：128 4080 / 2048 4088 = 130560 / 522240 = 0.25（25% 的概率）。

32 ETH 和 128 ETH 验证者分别被选为提案者的概率差异看起来可能开始令人担忧（100% >>>>> 25%）。然而，如果我们认为每个 32 ETH 验证者在这个场景中有 25% 的概率被选为提案，理解大型抵押者控制四个 32 ETH 验证者，具有 100% 的提案概率（25 * 4 = 100）是有道理的。

换句话说，抵押资金的整合并没有对提案者选择产生极大的影响。唯一改变的是控制存款的验证者的累计有效余额与该抵押者被选为提案区块的概率之间的关系是显而易见的。

与其想象，（更准确地说）假装单一抵押者持有的 32 ETH 和大型抵押者在四个验证者中分散的 128 ETH 拥有同等的概率被选为提案者，倒不如更此次需求将高概率分配给大型抵押者获得下一个提案。

请注意，如果大型抵押者保持四个 32 ETH 验证者未合并，则他仍然有 100% 的提案几率。小型抵押者只有在从洗牌的索引列表中首次被选中时才有 100% 的提案机率，而我们知道这发生的概率为 1/5 或 20%。

这同样是一条更合理的理由，去选择合并验证者而不是将资金分散到较小的验证者中：

• 这对网络有好处，因为提案者的选择发生得更快。更高的有效余额意味着计算下一个 slots 的 proposer_index 所需的迭代更少。
• 这对于大型抵押者有利，因为被选为提案者的概率集中在一名合并的验证者中。合并后的验证者也能获得更多的抵押奖励，因为执行共识职责（例如，提案）的奖励会随着有效余额增加。

EIP-7251 和以太坊权益证明的未来

设计像以太坊的 Beacon Chain 这样的功能性和安全性的权益证明共识协议是困难的。这意味着在有限的信息下做出决定，并 留出一个退路，以考虑估算和风险估计可能不足以为应对现实突发事件做好准备的可能性。

这就是为什么我从合理乐观的思考开始：以太坊的旅程可能是这个理性乐观者可以开展建设并一起解决出现的问题的最佳示例。EIP-7251 是一个简单而有效的解决方案，旨在解决即使是诺查丹玛斯（如果他是核心开发者）也无法预见的问题：一个极大的验证者集的技术挑战。

如果有关该提案的争论是任何参考社区必须解决许多问题才能使 EIP-7251 广泛采用并实现 EIP 价值的内涵。与此同时，你可以在 Ethresear.ch 和 The Fellowship of Ethereum Magicians 关注 EIP-7251 的讨论。Mike Neuder 的 EIP-7251: 相关工作 是撰写本文的优秀研究材料，推荐给任何想了解 EIP-7251 不同方面的人。

和往常一样，我邀请你考虑将这篇文章分享给那些可能发现它有用和信息丰富的人。如果你喜欢阅读，还可以订阅 2077 Research，以获取更多关于以太坊 EIP 生态系统中提案的研究。你还可以与我在 Twitter 上联系 @eawosikaa。

• 原文链接： research.2077.xyz/eip-72...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～