EigenPod 的最新升级 MOOCOW：大规模优化运营 - CO整合与提款

_MOOCOW_: 大规模优化操作 - 合并和提款

:::success 最新链接： * 核心合约 PR: [eigenlayer-contracts/1425](https://github.com/Layr-Labs/eigenlayer-contracts/pull/1425) * CLI PR: [eigenpod-proofs-generation/177](https://github.com/Layr-Labs/eigenpod-proofs-generation/pull/177) :::


*MOOCOW* 是最新的 EigenPod 升级，即将来到你附近的 pod！*MOOCOW* 增强了 *PEPE*，利用新的 Pectra 功能，完全主导了原生 restaker 的 gas 成本。

对于拥有多个验证器的原生 ETH restaker 来说，通过验证器合并，此升级带来了高达 64 倍的证明大小和成本降低。

64 倍？我的老天!

你没看错。举个例子，看看 [Renzo 的一个 EigenPod](https://etherscan.io/address/0xDD0212d0da33a2235d1952dA390a0A18EAcc7af5)。这个 pod 有 1775 个验证器，代表着 56,800 ETH 的 TVL。当 Renzo 想要对其验证器进行检查点操作，以处理验证器退出/累积的信标链奖励时，这需要 24 笔交易 和 约 9900 万的总 gas 消耗。

<!-- 根据 Renzo 的说法，这需要花费 0.05 ETH - 0.5 ETH 才能运行 (取决于网络拥塞情况)。由于定期检查点是 LRTs 用于管理流动性约束的重要工具，他们并不总是能推迟检查点 -->

使用 *MOOCOW*，Renzo 可以将所有 1775 个验证器合并 到只有 28 个。处理 28 个验证器 的检查点只需要 2 笔交易，以及微不足道的 约 180 万的总 gas 消耗。

MOOCOW 是如何工作的？

*MOOCOW* 为 EigenPod 添加了对 Pectra 中包含的两个新 EIP 的支持：

\ [EIP-7251](https://learnblockchain.cn/docs/eips/EIPS/eip-7251#constants) 启用了 验证器合并，允许多个 32 ETH 的验证器合并成一个最多 2048 ETH 的验证器 \ [EIP-7002](https://learnblockchain.cn/docs/eips/EIPS/eip-7002) 启用了 执行层可触发的提款，允许 pod 的所有者直接从他们的 pod 管理他们的验证器（无论是完全退出他们的验证器，还是提取他们累积的信标链余额）

*MOOCOW* 与现有的 EigenPod 接口和 *PEPE* 检查点证明系统向后兼容。此升级 向 EigenPod 添加了两个新的状态变更方法，并且 不更改任何现有的方法 ABI。当前与 EigenPod 的链上和链下集成可以继续正常运行，无需更改，这意味着 此升级是完全可选的。

此外，*MOOCOW* 被设计为与原生 ETH 燃烧和/或重新分配的最终实现 完全向前兼容 - 正如 *PEPE* 被设计为与 *MOOCOW* 向前兼容一样。

请注意，虽然 *MOOCOW* 对于大多数 restaker 来说是向前迈出的一大步，但它并没有为拥有单验证器 pod 的 restaker 提供实质性的好处。

什么时候 MOOCOW？

智能合约

*状态：* \ 设计：完成！ \ 实现：完成！ \ 文档和测试：完成！ \ 审计：6/23 - 6/30

CLI

*状态：* \* 实现：完成！

前端

*不需要任何更改。*

---

技术细节

如何使用这些方法

*(更多详细信息和文档可以在 `IEigenPod.sol` 中找到；本节概述了一些常见的混淆点以及一个高级流程的示例。)*

预部署费用：

`requestConsolidation` 和 `requestWithdrawal` 都是 `payable`，接受“请求费用”。这是 Pectra 中引入的一个新概念：必须向两个预部署合约发送费用以及任何请求。这意味着在调用 `EigenPod.requestConsolidation` 和 `EigenPod.requestWithdrawal` 时，你必须提供足够的费用作为 `msg.value`。

新的接口公开了这些 getter：`IEigenPod.getConsolidationRequestFee()` 和 `IEigenPod.getWithdrawalRequestFee()` 返回 当前区块 的 _一个请求_ 的费用。要发送的正确金额是 `fee * requests.length`，即 将返回值乘以你打算发送的请求数。

请注意，根据网络处理的请求数量，此费用可能会在每个区块结束时增加或减少。我们建议高估发送的费用，因为在将所有请求发送到预部署合约后，任何多余的费用都将发送回 `msg.sender`。

最大合并示例：

假设你的 EigenPod 有 1000 个验证器，并且你想使用 `EigenPod.requestConsolidation` 将它们最大程度地合并。你之前没有进行任何合并，因此所有验证器都具有 0x01 提款凭证。最大限度地合并你的验证器涉及将所有验证器以 64 个为一组进行合并 (因为 `64 * 32 == 2048`，这是 0x02 验证器新的最大有效余额)。这意味着你将把 1000 个验证器合并为 16 个 (`div_ceil(1000, 64) == 16`)。

首先，确定你的目标验证器。

合并需要一个 _源_ 和一个 _目标_。合并完成后，目标将收到源的余额。我们选择 16 个验证器作为合并的 _目标_。请注意，每个目标验证器都必须具有指向我们 pod 的已验证的提款凭证。

其次，为你的目标验证器启动 *切换请求*。

为了使验证器成为合并的 _目标_，它必须具有 0x02 提款凭证。为了实现这一点，我们使用 16 个请求 (每个选定的目标一个) 调用 `requestConsolidation`，其中每个 `request.srcPubkey == request.targetPubkey`。这将作为“切换请求”处理，并将更新我们的每个 16 个验证器以具有 0x02 凭证。

接下来，将剩余的源验证器合并到每个目标。

将剩余的 984 个验证器分成 64 个一组，将每组 64 个验证器分配给一个选定的 _目标_ 验证器，然后调用 `requestConsolidation`，其中 `request.srcPubkey` 等于源验证器的公钥，而 `request.targetPubkey` 等于选定的 _目标_ 验证器的公钥。

最后，监视信标链，并在所有合并完成后进行检查点。

信标链每个区块处理 2 个合并请求，每个 epoch 处理总共 64 个请求。考虑到来自其他 pod/验证器的合并请求，可能需要几个 epoch 才能完成你请求的合并。

当它们完成后，你可以启动并完成一个检查点以更新你的 pod 的记账。检查点完成后，你应该看到你的 `activeValidatorCount` 从 1000 下降到只有 16 个，因为 pod 将每个合并的 _源_ 验证器视为已完全退出信标链。你的 16 个 *目标* 验证器应该具有来自你 _源_ 的合并余额。

---

关于信标链行为的说明

合并和提款请求都只是请求。根据信标链的处理和验证，它们可能根本无法完成。从 EigenPod 的角度来看，请求的状态完全不透明；EigenPod 继续依赖检查点来更新 pod 的状态。

请求的生命周期有三个阶段： 1. EigenPod 启动请求并将其发送到预部署合约。在每个区块的末尾，最多从预部署合约中取消队列 16 个提款请求和最多 2 个合并请求，并将它们作为“执行请求”包含在 [相关的信标区块](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#beaconblockbody) 中。 2. 在区块处理期间，信标链执行多个验证操作以确定每个请求是否有效。如果请求无效，则跳过该请求。如果请求有效： \ 从 [process_withdrawal_request](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-process_withdrawal_request) 中，“完全退出”请求立即启动验证器退出，类似于当前自愿退出的工作方式。“部分退出”请求附加到 `state.pending_partial_withdrawals` (见步骤 3) \ 从 [process_consolidation_request](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md#new-process_consolidation_request) 中，“切换请求”会立即完成，将验证器的凭证切换到 0x02。所有其他请求都添加到 `state.pending_consolidations` (见步骤 3) 3. 在 epoch 处理期间，将完成在该 epoch 期间创建的任何挂起的部分提款/合并。

*请注意*，信标链最终负责验证请求。如果请求被认为是无效的并被跳过，则 EigenPod 不会收到“通知”。这取决于链下系统来查看这一点，并确定是否应该通过 pod 重新提交请求。

---

限制：跨 pod 合并

我们有一些 restaker 管理着多个单验证器 EigenPod，他们希望使用 EIP-7521 将他们的验证器合并到一个 EigenPod 中。

*MOOCOW* 将不支持这些情况下的跨 pod 合并。尽管此行为已通过 EIP-7521 启用，但新的 `EigenPod.requestConsolidation` 方法将要求合并的目标验证器在同一 pod 中处于活动状态。

尽管我们希望支持跨 pod 合并，但在实践中，我们的系统会将其视为 staker 之间的“股份/资产转移”，而不是我们的协议支持的基本 staker 操作之一 (存款/取款/(取消)委托)。

我们探索了一些选择，但最终认为复杂性不值得，特别是当有问题的 restaker 能够通过退出 EigenLayer 并重新存入到目标 pod 中的 0x02 验证器来自己复制该行为时。

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