在过去的几天里，mev-boost 在社区中成为了热门讨论话题。我们希望借此机会强调并教育支持 mev-boost 作为合并准备就绪的 PBS 解决方案的设计和信任假设。
首先，重要的是要注意，有关新的问题或信任假设被发现的报告实际上是错误的。本文讨论的所有内容都是 mev-boost 已知的属性，并且在最初的 mev-boost 研究帖子 中进行了讨论。每个问题都有已知且被接受的缓解办法，这些缓解办法正在共识客户端中实施。合并和 mev-boost 的启动进度都在按计划进行。你可以在 mev-boost 登陆页面 boost.flashbots.net 中关注每个共识客户端和节点运营商的准备情况。
话虽如此，让我们深入了解 mev-boost 的设计、信任假设及其选择原因，以及我们如何减轻对以太坊的活跃性风险。
区块扣留攻击
为了让你了解情况，mev-boost 是一种中间件，验证者可以使用它将其区块构造外包给一个区块构建者市场。在构建者和验证者之间，有 “中继” 负责促进双方之间的顺利交易。中继保护构建者，以防泄露有关区块的任何信息给验证者，并确保即使是小型验证者也可以参与构建者市场。与此同时，中继保护验证者，避免接收无效的区块、过高的出价或完全缺失的区块。（稍后在“ 为什么选择这种设计？”中会进一步讨论）
中继可以连接到一个或多个构建者，我们预计将存在这两种情况。连接多个构建者的中继将聚合他们的出价（有趣的是，在之前的版本中，我们称之为构建者聚合器或构建者池）。中继可以看到所有由构建者提交的区块，以确认其有效性以及他们支付给验证者的金额。然后，中继只将最高的有效出价提交给验证者以进行签名。
在验证者可以接收来自中继的任何出价之前，他们需要 设置 mev-boost 并将中继添加到其 mev-boost 配置中。实际上，mev-boost 只是一个中继聚合器或本地中继的中继。它将提供来自所有中继的胜出出价给验证者。验证者可以连接到少数中继，将所有构建者聚合，并且许多验证者可能会这样做。其他验证者可能会连接到多个中继。
如果 mev-boost 的配置中没有中继，或所有中继都离线，那么信标节点（BN）将始终回落到根据公共内存池构造区块。因此，我们知道风险并不是所有中继都下线。那么，风险是什么呢？就是：
- 整个网络连接到同一中继（不一定是独占的），并且
- 该中继是出价最高的中继，因此其区块被验证者选择，并且
- 中继发送区块头进行签名（= 它没有离线），但在收到验证者签名后，不向网络发布最终的区块。
在这种情况下，同一中继会不断向验证者建议区块，而这些验证者会继续签名它们，但不会发布任何区块。结果就是一系列空动作。网络不构建区块通常被称为 活跃性问题。（这不同于 DDOS 攻击，因为受影响的节点仍会履行其所有其他网络职责，比如发布证明、传播消息等。）
这种故障可能通过错误或恶意中继发生。在错误的情况下，我们希望中继能够意识到自己的问题并快速解决，或完全下线。因此，更相关的情况是防范恶意中继发起故意的 扣留攻击。
重要的是要强调，扣留攻击 可以立即使整个网络出现 活跃性问题。这是因为恶意中继可能会对其出价撒谎，以保证它始终被所有与其注册的验证者选择。例如，想象一个恶意中继给出一个人为设置的、比诚实中继更高的出价。
这种攻击对于中继来说是无成本的，因为它从未发布区块并支付给验证者，而所有受影响的验证者都错过了自己的提案时机。
重要的是，我们并不关心有 10% 的网络连接到一个故障中继，只担心当一个故障中继如此受欢迎，以至于为网络创造系统性风险。借用一句名言，如果 10% 的验证者错过他们的时机，那是他们的问题。如果 100% 的验证者错过他们的时机，那就是以太坊的问题。
映射解决方案空间
那么，假设一个受欢迎的中继在扣留区块；系统如何恢复？从基本原理来看，当发生以下 任 其中一个步骤时，系统恢复：
- 验证者将故障中继从其 mev-boost 配置中移除（或完全关闭 mev-boost），或
- 其他中继开始竞标超过故障中继，或
- 故障中继完全下线，或
- 故障中继重新开始发布区块
查看对抗故障中继的“防御措施”，显而易见情况 3-4 在故障中继的控制之下，情况 2 在其他中继的控制之下。但是作为验证者，我们只对能够让我们在意识到某个中继故障后移除它的解决方案感兴趣。
在这个解决方案空间中，有两类：本地解决方案和 全局解决方案。本地解决方案是最简单的——验证者（或他们的 mev-boost）可以跟踪中继最近的表现。如果一个中继误报了支付或没有发布区块，验证者可以自动将其移除。但是，这种解决方案存在 局部信息 的问题。该解决方案能保护单个验证者免受故障中继的影响，但下一个验证者并不知道该故障中继。对于 Coinbase、Lido、Binance、Kraken 等大公司而言，本地解决方案可能已足够，因为它们控制了大量验证者，他们的“本地”在某种程度上已是网络的“全局”——但这对小型验证者并没有帮助。这些验证者需要了解 其他验证者的插槽 上中继的表现。
看起来我们需要一个 全局解决方案。在全局解决方案中，验证者查看网络的全局历史，而不仅仅是他们自己的，以消除中继。社区正在构建两个全局解决方案以应对合并。
第一个是由可信第三方运营的 中继监测器。该监测器监控中继的全球性能，可以向验证者发送类似“现在移除中继 x”的消息。因此，如果任何中继表现不佳，所有连接到中继监测器的验证者都将更新其配置。这个方法是否有新的风险？我们从之前提到的知识点回忆到，空的 mev-boost 配置意味着验证者会回落到本地区块生产。因此，中继监测器只能暂时从验证者的配置中移除中继，而不能添加任何新的中继，或导致验证者错过任何插槽。
第二种解决方案，由 Alex Stokes 提出的，是 电路断路器。它的工作方式类似于中继监测器，但不依赖于第三方服务。电路断路器是信标节点的一部分。它查看网络的本地状态，如果节点看到连着错过 y 个插槽，则会与构建者网络断开连接，回落到本地构造区块。有关于 x 的选取的微妙之处，因为太小的数字可能会允许大验证者故意错过插槽，从而触发电路断路器，影响到整个网络并关闭他们的 mev-boost。太大的数字则可能会导致连续错过多个插槽。
以上及进一步的、尚不成熟的解决方案正在 GitHub 问题中讨论。最终，内嵌 PBS 将完全消除中继，但这还需要几年的时间。
为什么选择这种设计？
由于 mev-boost 中使用的承诺-揭示方案，中继在中标后可能会未能发布区块。这一攻击向量从一开始就被知晓且是一个经过审慎考虑的选择。我们为什么选择它？
选择的替代方案将是继续 Flashbots 在我们称之为 “阶段一 PBS” 的设计。在阶段一 PBS 中，区块构建者将完整区块发送给验证者，并且验证者必须打开一个对 DOS 敏感的 RPC 与区块构建者交互。
阶段一设计的优点在于，验证者可以随时查看区块，以验证区块的有效性以及它支付给验证者的金额。如果没有构建者及时发送区块，验证者可以回归本地构造区块，并且不会有错过插槽的风险。
但是，缺点在于，区块构建者需要信任验证者不会从他们那里盗取 MEV，而验证者则需要信任区块构建者不会对他们发起 DoS 攻击。遗憾的是，后果是只有受信任的验证者和构建者才能参与 PBS 市场。
因此，尽管旧设计在抵御区块扣留攻击方面具有良好的属性，但它会完全切断单独质押者的 MEV 提取。经过与以太坊社区及其他关键利益相关者的公开讨论，这一成本被认为过高，因此我们选择了一种能够包含它们的设计。
总结
我希望这篇文章能帮助你理清 mev-boost 的信任假设，为什么这些假设会被选择，以及将实施哪些缓解措施以避免对以太坊的活跃性风险。中继监测器将在合并时准备就绪。电路断路器正在开发中，一些共识客户端已经实现了它们。结合验证者保持良好的中继使用习惯（仅使用受信任的中继，直到实施进一步的缓解措施，为他们的插槽设置停机监控），我认为我们在合并方面处于一个良好的位置。
参考文献
