利用RPC对MEV中继进行解绑攻击

这篇文章揭露了一种针对 MEV relay 的新型解包攻击，该攻击已通过 Lighthouse 最新版本 (v4.1.0) 的更改得到缓解。

解包攻击因 2023 年 4 月 2 日发生的一起备受瞩目的漏洞利用事件而备受关注，该事件为攻击者带来了超过 2000 万美元的收益。在阅读本文之前，我们建议读者熟悉 Flashbots 的原始披露 以及 Francesco D'Amato 和 Mike Neuder 的文章。

攻击序列

与其他解包攻击一样，RPC 解包攻击依赖于区块提议者愿意含糊其辞并被罚没。只有当这样做带来的利润机会超过罚没惩罚（通常约为 1 ETH）时，这才是合理的。正如我们在第一次解包攻击中所看到的那样，抢先交易夹层交易提供了这样的机会。

攻击者需要有一个活跃的验证者被提名称为一个区块。攻击按如下步骤进行：

1. 攻击者从 MEV relay（例如 ultra sound）请求执行负载。他们使用负载标头创建一个有效的区块并对其进行签名。为简单起见，让 block0 既指附加了完整负载的区块，也指没有完整负载的区块。
2. 攻击者将签名的 block0 发布 到 relay。
3. relay 验证 block0，添加完整的执行负载并广播它。没有含糊其辞（尚未），并且该区块在所有方面都是合法的。
4. 攻击者创建一个含糊其辞的 block1，其中包含从刚刚暴露其负载主体的 block0 中提取的交易。攻击者使用夹层交易的解包来抢先交易夹层机器人，从而使 block1 为攻击者产生可观的利润。
5. 攻击者不在 gossip 上发布 block1，而是为它创建一个证明。此证明可以是常规证明，但最好是能够发布到网络上每个节点的聚合证明。
6. 攻击者将其针对 block1 的证明大量发布到许多 peer。这些 peer 不知道该证明引用的块，因此他们将开始尝试在共识层的 peer-to-peer RPC 上查找它（使用 BlocksByRoot）。
7. 攻击者迅速响应来自多个节点的 RPC 请求，将 block1 交到许多诚实的 peer 手中。
8. 当诚实的 peer 使用 on_block 将 block1 应用于分叉选择时，它将收到提议者奖励而不是 block0（假设它在 4 秒之前到达）。这是因为分叉选择将提议者奖励授予最后处理的区块，无论是否含糊其辞。这些 peer 现在会将 block1 视为 head。
9. 任何将 block1 视为 head 并且尚未证明（稍后会详细介绍）的验证者都将证明 block1。如果这些证明传递了足够的权重（>委员会权重的 50%），那么 block1 将击败 block0 并永久成为规范的。

攻击的关键是攻击者能够通过使用 RPC 绕过 gossip 重复项过滤器。一旦绕过此过滤器，他们就可以利用分叉选择的“最新区块获胜”行为，否则无法通过 gossip 到达该行为。

需要资源充足的攻击者

在某些方面，RPC 解包攻击不如 4 月 2 日执行的原始攻击那么严重。它需要几个巧合以及大量的基础设施投资。即：

• 在步骤 (5) 中，攻击者需要在与其提议相同的 slot 中有一个证明者，最好是一个聚合者。单个验证者被选为证明其自身区块的概率为 1/32。被选为聚合的概率大约为 1/32 * 16/274 ≈ 0.18%，假设委员会规模约为 274（560k 验证者/32/64），并且 TARGET_AGGREGATORS_PER_COMMITTEE=16。考虑到区块提议的频率较低，单独的验证者将等待很长时间才能像这样排列组合。攻击者需要拥有大量验证者才能有合理的成功几率。给定区块提议，在 n 个验证者中至少有一个聚合者的概率约为：

P(aggregator|proposer)=1−(1−(1/32×16/274))n 要超过 50% 的概率，攻击者将需要 n=380 个验证者。

• 在步骤 (6) 和 (7) 中，攻击者需要一个连接良好的信标节点集群，以便快速传播证明和区块。他们需要在 50% 的节点上的 4 秒提议者奖励截止日期之前处理 block1。

这些要求高于原始攻击的要求，但肯定并非遥不可及。尤其是具有讽刺意味的是，撰写本文时所需的 380 个验证者的成本约为 2250 万美元，非常接近攻击者在第一次攻击中提取的金额 😳。

客户端多样性的好处

值得庆幸的是，有一些力量在与攻击者作斗争，包括客户端多样性。

在步骤 (6) 中，我掩盖了共识客户端处理未知区块证明方式的差异。不同客户端的行为如下所示，其中 🔴 表示启用攻击的行为，🟢 表示缓解攻击的行为。

• 🔴 Lighthouse：立即查找丢失的区块（所有版本）并将其应用于分叉选择（在 v4.1.0 之前）。
• 🟢 Prysm：仅每 4 秒查找一次未知区块。攻击者的 block1 永远没有资格获得提议者奖励，因为它会在 slot 开始 4 秒后才会被查找。
• 🔴 Teku：与 Lighthouse 相同。
• 🔴 Nimbus：与 Lighthouse 相同。
• 🟢 Lodestar：不（尚未）使用 RPC 查找证明引用的未知区块。

鉴于 Prysm 约占网络的 35%，这为攻击者达到将 block1 作为规范所需的 50% 证明权重提供了实质性障碍。

还有另一种特定于客户端的行为有所帮助——发送证明的时间点。这取决于所使用的验证者客户端：

• 🔴 Lighthouse VC：在 4 秒时证明，如果信标节点已将其作为 head，则将证明 block1。
• 🟠 Prysm VC：默认情况下与 Lighthouse VC 相同，但可以配置为证明第一个到达的区块。
• 🟢 Teku VC：证明第一个到达并成为 head 的区块，将证明 block0 而不是攻击者的区块。
• 🟠 Nimbus VC：证明第一个到达的区块，当在单个进程中运行 BN 和 VC 时。在拆分模式（单独的 VC）下，像 Lighthouse 一样在 4 秒时证明。
• 🟢 Lodestar VC：与 Teku 相同，但发布前有延迟。
• 🟢 Vouch：与 Teku 相同。

如果我们假设大多数运行 Teku BN 的用户也运行 Teku VC（或 Vouch），那么这将是另外 10-17% 的验证者不支持攻击者的区块。乐观地看，与 Prysm 和其他 Vouch 验证者一起，这 >50% 的验证者集，并且可能足以使攻击非常困难，如果不是不可能的话。

规范含糊不清

即使我们认为在当前的客户端组成下攻击不太可能，但修复潜在的问题并提供更强的保证仍然是有益的。

从某种意义上说，攻击利用了当前共识规范中的两个含糊不清之处：

1. 未知区块证明的处理未标准化

来自证明的 P2P gossip 条件:

[IGNORE] 投票的区块 (aggregate.data.beacon_block_root) 已被看到（通过 gossip 和非 gossip 来源）（客户端可以对聚合进行排队以在检索到区块后进行处理）。

这句话中的_"MAY"_意味着所有客户端实现的现有行为都符合规范。这可以说是件好事，因为它让客户端可以自由选择适合他们的架构，并围绕该架构进行优化。

虽然可以通过指定导入 RPC 区块的规则来修补 RPC 解包漏洞（稍后会详细介绍），但这些规则感觉非常临时且随意。因此，我们认为在规范中强制执行这样的修复过于规范。

2. 分叉选择中对含糊不清的处理宽松

在我们看来，更有趣的含糊不清之处在于分叉选择中对含糊不清的处理。如攻击序列的步骤 (8) 中所述，攻击者的区块能够覆盖来自 slot 的原始提议，因为它到达得较晚。on_block 的相关部分如下所示：

## 如果区块及时，则添加提议者分数提升
if get_current_slot(store) == block.slot and is_before_attesting_interval:
    store.proposer_boost_root = hash_tree_root(block)

只要区块来自当前 slot 并在证明间隔（4 秒）之前到达，它就有资格获得提升。没有检查同一 slot 的现有区块是否已经具有提升，也没有任何机制可以将提升奖励给多个区块。

在这种情况下，规范对于几个含糊不清的区块中的哪个成为 head 有些矛盾。从网络健康的角度来看，这并不重要，只要恶意提议者被罚没（他们会的）。只有在考虑下游效应时，才希望“选择一个获胜者”，即选择 relay 的区块而不是攻击者的区块。

这类似于编译器设计中的 未定义行为，其中规范中的差距与实现细节相结合可能会导致令人惊讶且有时会造成损害的结果。

修复分叉选择

我们认为修改分叉选择规范可能是有益的，以便只有在给定 slot 中处理的第一个区块才有资格获得提议者提升。首选第一个区块是很直观的，与积极的证明策略一致，并且可以最终修复 RPC 解包漏洞。解包将减少到传播竞赛，目前的想法表明这是我们所能期望的最好的结果。

对规范的单行更改将是：

## 如果区块及时，则添加提议者分数提升
if store.proposer_boost_root == Root() and get_current_slot(store) == block.slot and is_before_attesting_interval:
    store.proposer_boost_root = hash_tree_root(block)

我们计划通过此更改向共识规范打开一个 pull request，以便可以对其进行讨论，并可能在没有硬分叉的情况下推出（有待进一步分析）。

或者，可以通过 Francesco 和 Mike 的文章 中描述的headlock 协议来缓解攻击以及其他解包攻击。还有关于减少含糊不清区块的权重的讨论，以便重新组织它们并确保跳过该 slot。

临时缓解措施

修改分叉选择是一个微妙的过程，我们不希望仓促进行。因此，在 4 月 6 日发现漏洞后的几天里，我们设计了一种基于 RPC 区块处理的临时缓解措施，并在 Lighthouse 中实现了它。

缓解措施改变了下载后 RPC 区块的处理方式。Lighthouse 首先检查以下两个附加条件，而不是立即应用它们：

• 区块是否按时到达（在 4 秒的截止日期之前）？
• 是否已经在 gossip 上看到同一 slot 的区块？

如果这两个问题的答案都是是，那么 Lighthouse 会对该区块进行排队并在 4 秒后重新处理它。这确保了通过 RPC 到达的含糊不清的区块永远不会获得提议者提升。

我们与其他易受攻击的客户端（Teku 和 Nimbus）讨论了这个补丁，并共同决定不值得在 Lighthouse 之外实现它。首先，因为修补 Lighthouse 已经覆盖了很大一部分验证器集（约 35%）。其次，因为一些验证者客户端已经缓解了该漏洞。我们希望 Teku 和 Nimbus 将通过更全面的分叉选择修复进行修补。与此同时，他们的当前行为不会对任一客户端或 MEV relay/搜索器的用户构成风险。

时间线

• 4 月 2 日：主网上首次利用解包漏洞。
• 4 月 6 日：Michael Sproul 在与 Prysm 的 Potuz 讨论中发现了 RPC 解包漏洞。
• 4 月 7 日：向 Flashbots 和 ultra sound relay 披露 RPC 解包，让他们知道它的存在，但无法在 relay 级别进行修补。
• 4 月 12 日：在 Lighthouse 中实现第一个补丁：sigp/lighthouse#4179。成立了一个跨客户端工作组，讨论将补丁应用于 Teku、Nimbus 和 Lodestar。
• 4 月 14 日：Paul Hauner 对第一个补丁进行修复：sigp/lighthouse#4192。
• 4 月 19 日：Paul 的进一步修复，以防止无限期地重新排队 RPC 区块：sigp/lighthouse#4208。
• 4 月 20 日：发布 Lighthouse v4.1.0，其中包括缓解措施。
• 5 月 1 日：联系大型权益池，并鼓励更新到 Lighthouse v4.1.0。
• 5 月 10 日：根据区块涂鸦观察到大多数 Lighthouse 验证者已更新到 v4.1.0。网络不再被认为是易受攻击的。
• 5 月 11 日：负责任的信息披露。

结论

我们已经披露了一种解包攻击的变体，该攻击利用了通过 RPC 接收的含糊不清的区块的处理。此漏洞已在 Prysm、Teku 和最新版本的 Lighthouse 中得到缓解，并且不再可在主网上利用。

我们计划通过对分叉选择进行微小更改来寻求更全面的缓解措施，希望可以在 Deneb 之前推出。

感谢 Potuz、Mike Neuder、DappLion、Jimmy Chen 和 Paul Hauner 审查此帖子，以及 Jim McDonald 提供有关 Vouch 行为的建议。感谢 Age Manning 提供有关通过 RPC 执行攻击的可能性以及其他客户端团队的及时关注的建议。

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