全面解读MEV-Boost工作原理及Ethereum分叉选择规则

原文标题：《Time, slots, and the ordering of events in Ethereum Proof-of-Stake》

原文作者：Georgios Konstantopoulos, Mike Neuder

原文编译：Kxp，BlockBeats

引言

4 月 2 日，恶意的 Ethereum 网络参与者利用 MEV-Boost 中继中的漏洞从一个 MEV 搜索者那里窃取了 2000 万美元（请参阅 Flashbots 的报告）。接下来几天，开发者通过发布五个补丁来解决这个漏洞。这些补丁，加上网络延迟和验证器策略，导致 Ethereum 网络在 4 月 6 日出现了短暂的波动。重组区块对网络健康会产生不利影响，因为它们减缓了区块的生产速率并降低了结算保障（settlement assurances）。

在这篇文章中，由于搜索者受到攻击且网络暂时不稳定，我们探讨了 MEV-Boost 与共识之间的相互作用，分析了 Ethereum 的权益证明机制的微妙之处，并列举了一些可能的前进路径。

MEV-Boost 及其重要性

MEV-Boost 是由 Flashbots 和社区设计的一个协议，旨在减轻最大可提取价值（MEV）对 Ethereum 网络的负面影响。

MEV-Boost 中有 3 个参与者：

1. 中继——相互信任的拍卖者，连接出块者和区块构建者

2. 构建者——构建区块的复杂实体，以最大化自己和出块者的 MEV

3. 出块者——Ethereum 的权益证明验证者

每个区块的大致事件序列是：

1. 构建者通过从用户、搜索者或其他（私人或公共）订单流接收交易创建一个区块

2. 构建者将该区块提交给中继

3. 中继验证块的有效性并计算它向出块者支付的金额

4. 中继向当前 slot 的出块者发送空白标题和支付值

5. 出块者评估他们收到的所有出价，并签署与最高付款相关联的空白标题

6. 出块者将此已签名标题发送回中继

7. 中继使用它们的原生信标节点发布区块，并将其返回给出块者。奖励通过区块内的交易和区块奖励分配给建设者和提议者。

中继是一个受信任的第三方，促进出块者公平交换区块空间和构建者用于 MEV 提取的交易排序。中继通过保护构建者免受 MEV 偷窃，避免出块者复制构建者交易以取走 MEV 而不分配给发现它的搜索者/构建者来保护构建者。中继通过确认构建者区块的有效性、代表出块者处理每个 slot 上的数百个区块以及确保出块者支付的准确性来保护出块者。

MEV-Boost 是关键的协议基础设施，因为它使所有出块者都能够民主地访问 MEV，而无需与构建者或搜索者建立信任关系，这有助于 Ethereum 的长期去中心化。

Ethereum 的分叉选择规则与 MEV-Boost

在探讨攻击和响应之前，我们先来看看 Ethereum 的权益证明机制和相关的分叉选择规则。分叉选择规则允许网络就链头达成共识，《Ethereum 合并后的重组》这篇文章中对其做出了定义：

「分叉选择规则是一个由客户端评估的函数，它用已看到的区块和其他消息作为输入，并向客户端输出「规范链」。分叉选择规则十分重要，因为可能有多个有效的链可供选择（例如，如果同时发布具有相同父块的两个竞争块）。」

分叉选择规则也与时间相关，这对出块有重大影响。

slot 和 sub-slot 周期

在 Ethereum 的权益证明机制中，时间被分割为每 12 秒为一组的 slot。权益证明算法随机分配验证者在该 slot 内提出块的许可证；这个验证者被称为出块者。在同一 slot 内，其他验证者被分配为根据其本地视图应用分叉选择规则来为链头进行验证（投票）的任务。这 12 秒的 slot 被细分为三个阶段，每个阶段消耗 4 秒。

在 slot 中发生的事件如下所示，其中 t= 0 表示 slot 的开始。

在 slot 期间，最关键的时刻是在 t= 4 时的认证截止时间。如果认证验证者在认证截止时间前没有看到区块，他们将会投票给链上先前被接受的头部（根据分叉选择规则）。一个区块被提出的时间越早，它就有更多的时间传播，从而积累更多的认证（因为更多的验证者在认证截止时间前看到它）。

从网络健康的角度来看，区块发布的最佳时间是 t= 0 （根据规范规定）。然而，由于区块价值随着时间单调递增，出块者有动机推迟其区块的发布，以便更多的 MEV 积累。有关详细信息，请参见  Timing games in Proof-of-Stake  和本讨论 。

以前，出块者可以在认证截止时间后（甚至接近 slot 的结束）发布区块，只要下一个验证者在建立其后续 slot 的区块之前观察到该区块即可。这是由于子区块继承父区块的权重，分叉选择规则在叶节点终止。因此，推迟区块发布没有任何副作用。为了帮助将理性行为（推迟区块发布）转向诚实行为（按时发布），实施了「诚实重组」（honest reorg）。

出块者奖励机制和诚实重组

两个新的概念被引入到共识客户端中，对认证截止时间有关键的影响。

1. 出块者奖励机制——旨在通过授予出块者等同于 40% 全部认证权重的分叉选择「奖励」来尽量减少重组平衡攻击。重要的是，这个奖励仅持续整个 slot。

2. 诚实重组——利用出块者加速，允许诚实的出块者强制重组认证权重低于 20% 的区块。这已经在 Lighthouse 和 Prysm 中实现（从 v 4.0 - Capella 发布版开始）。这个改变是可选的，因为它是出块者作出的决策，不影响认证验证者的行为。因此，我们不用将其同时应用于所有客户端，它也没有与任何特定的硬分叉相关联。

需要注意的是，在一些特殊情况下会避免使用诚实重组：

1. 在 epoch 边界区块期间 

2. 如果链没有最终确定 

3. 如果链头不是重组前 slot 的头部

情况 3 确保诚实重组只会从链中删除一个区块，这起到了断路器的作用，使得链能够在极端网络延迟期间继续生成块。这也反映了提案者对网络的看法的信心降低了，因为他们无法确定其提议增强的块是否将被视为规范。

下图展示了如何改变诚实行为以实施重组策略。

在这种情况下，让 b 1 代表一个迟到的块。由于延迟，b 1 只有第 n 个 slot 的 19% 的证明权重。剩余的 81% 的证明权重分配给父块 HEAD，因为许多证明者没有在证明截止期之前看到 b 1 。

如果没有诚实的重组，第 n  1 个 slot 的提案者会将 b 1 视为链的头并构建子块 b 2 。提案者没有努力重组 b 1 ，尽管它只有 19% 的证明权重。在第 n  1 个 slot，b 2 具有提案者的增强，假设它按时交付，b 2 将通过积累该 slot 的大多数证明成为规范。

有了诚实的重组，情况大不相同。现在，第 n  1 个 slot 的提案者看到 b 1 的 19% 证明权重低于重组阈值，因此他们建立一个以 HEAD 为父块的块，并强制重组 b 1 。当我们到达第 n  1 个 slot 的证明截止期时，诚实的证明者将比较 b 1 （19% ）与 b 2 （来自提案者增强的 40% ）的相对权重。所有客户端都实现提案者增强，因此 b 2 将被视为链的头，并将积累第 n  1 个 slot 的证明。

针对解绑攻击的中继和信标节点修复 

在 4 月 2 日的 unbundling 攻击中，提案者利用中继漏洞向中继发送了一个无效的签名头。在接下来的几天里，中继和核心开发团队发布了许多软件补丁，以减轻重复攻击的风险。五个主要更改如下：

中继更改： 检查数据库中已知的恶意提案者（仅由超声波中继在生产中使用，并已被删除）。 检查中继是否已将完整块传递到 P2P 网络中的某个 slot。 在块发布之前引入 0-500 ms 范围内的均匀随机延迟（已从所有中继中删除）。

信标节点更改（仅适用于中继信标节点）： 在广播之前验证信标块。 在发布区块之前检查网络是否存在错误确认。 这些更改的结合导致了共识不稳定性，这一问题加剧了由于大部分验证者现在使用上述诚实重组策略而产生的影响。

意外的后果 

上述的五项更改都在中继块发布的热路径中引入了延迟，这增加了中继块在确认截止时间之后广播的概率。下图显示了这五项检查的顺序以及引入的延迟如何导致区块发布超过确认截止时间。

在实施这些检查之前，大量滞后于 t = 0 （例如 t = 3 ）的已签名头部通常不会产生问题。由于中继的开销非常低，因此它将在 t = 4 之前发布区块，而无需等待确认截止时间。

然而，由于这五个修补程序的延迟引入，中继现在可能部分负责迟延广播。让我们看看下面的假设性区块发布过程。

中继在 t = 3 时从出块者处接收到已签名头部。到了 t = 4 ，中继仍在执行检查，因此广播将在确认截止时间之后进行。在这种情况下，出块者发送的延迟已签名头部和中继引入的一些额外延迟的结合导致了未能在确认截止时间之前广播。如果没有诚实的重组，这些区块很可能已经进入链上。如图 2 所示，接下来 slot 的诚实出块者不会因为这些区块迟到而故意进行重组。然而，如果错过了确认截止时间，则这些区块将被下一个出块者重组。

因此，在攻击后的几天中，分叉块的数量急剧增加。

Metrika 的两周数据显示，在最坏的情况下，一小时内可能会有 13 个区块（4.3 ％）被重新组织，这是正常情况的约 5 倍。随着中继器推出各种更改，分叉块的数量急剧增加变得明显。感谢中继操作员和核心开发人员的伟大社区努力，一旦了解到影响，许多更改被撤回，网络恢复到了健康状态。

截至今天，最有用的更改是信标节点块验证和发出之前的抵赖检查。恶意的出块者不能再通过向中继发送无效头部并确保中继信标节点在发布之前不看到抵赖块来执行攻击。尽管如此，中继仍然面临着 MEV-Boost 和 ePBS 中提出的更一般的抵赖攻击。

下一步行动

在这篇文章中，我们强调了 MEV-Boost 的工作原理以及它对 Ethereum 共识的关键性。我们还对与时间有关的 Ethereum 分叉选择规则中的一些较少知道的方面进行了详细分析。通过使用「解绑」攻击和开发人员的反应作为案例研究，我们强调了分叉选择规则与时间有关的方面的潜在脆弱性以及其对网络稳定性的影响。

考虑到这一点，研究界应该评估什么是「可接受」的重新组织次数，并考虑抵赖攻击的更一般曝光情况，以确定是否应该实施缓解措施。

此外，目前正在积极探索多个未来方向：

1. 实施头锁机制，以保护 MEV-boost 免受等价错误攻击。这还需要更改共识客户端软件并可能需要规范更改以扩展证明提交期限。

2. 增加 MEV-Boost 软件的漏洞赏金计划的数量和传播力度。

3. 扩展模拟软件以探索 sub-slot 定时如何影响网络稳定性，这可以用于评估如何调整证明提交期限以减少重组。

4. 优化中继上的区块发布路径以减少不必要的延迟——这已经在探索当中。

5. 承认 MEV-boost 是核心协议功能，并将其纳入共识客户端，即「enshrined-PBS (ePBS)」。两个 slot 的 ePBS 容易受到明显的攻击，因此实施「头锁机制」仍然是一种选择。

6. 通过围绕延迟和认证截止时间的问题加入更多的 hive 和/或 spec 测试。

7. 通过构建中继规范的其他实现，鼓励中继客户端的多样性。

8. 考虑调整对于明显攻击的惩罚，但要记住即使进行完整的 32 个 ETH 的惩罚，也可能无法阻止在极大的 MEV 机会存在时的恶意行为。

9. 重新审视 sub- slot 计时，并考虑调整区块传播阶段（例如，将认证截止时间从 t= 4 调整到 t= 6 ）。

总的来说，我们对 MEV 和 mev-boost 生态的再次兴起感到兴奋。通过解绑攻击和缓解措施，我们已经了解了延迟，MEV-boost 和共识机制之间的关键关系；我们希望协议能够继续加强以应对这种情况。

原文链接

标签：ETH MEV 分叉 工作