Relay Monitor 设计文档

感谢 @metachris, @bertcmiller 和 @thegostep 对此设计的有益讨论

导言

本文档假定读者了解 mev-boost 的总体架构。

你需要熟悉 builder-specs：https://github.com/ethereum/builder-specs

以下是一些相关的图表，均来自 github 上的 flashbots/mev-boost 仓库：

高层架构

构建者 API 流程

内容

在最初版本的 mev-boost（https://boost.flashbots.net）中，存在一个受信任的角色，它将提议者与构建者连接起来，称为 relay（中继）。

中继有一系列职责，包括验证构建者是否提供符合提议者偏好的良好区块（例如，区块的 gas 限制），并促进拍卖，以便提议者可以有效地分配区块空间。

虽然这个角色是受信任的，但它是无需许可的，因此任何人都可以运行中继，并且由提议者配置 "relay mux（中继多路复用）" 软件（例如 https://github.com/flashbots/mev-boost），并选择中继来连接到他们感兴趣的构建者，以便在每次拍卖期间合作。

为了减轻拜占庭中继可能滥用此角色，flashbots 提出了 "relay monitor（中继监控器）"：https://github.com/flashbots/mev-boost/issues/142

本文档将该 issue 中的想法提炼为具体的规范。

设计

中继监控器 (RM) 使用公开可用的数据来形成对其所监控的中继集合的 behavior（行为） 和 performance（性能） 的视图。这包括中继多路复用器的 "opt-in（选择加入）" 设置，该设置将每个提议者对网络的看法转发给 RM。这样做极大地提高了中继监控器理解中继（以及提议者）对每个提议所做事情的能力。

behavior（行为） 是指中继为确保以太坊协议的安全性和活跃性而必须承担的一系列责任。mev-boost 生态系统的用户承担中继和/或构建者未能履行这些责任的风险，RM 的一个重要作用是确保中继履行其部分要求。

performance（性能） 是指与中继在系统环境中工作情况相关的延迟和吞吐量等指标。

故障类型

行为故障

首先，我们描述 RM 监视的故障类型，以及 RM 为每个中继使用并从每个提议者接收的相应数据。mev-boost 流程的高层结构是一个 commit-reveal（提交-揭示）方案，首先提供一组 bids（竞标），这些竞标提交给给定的 payload（payload）（API 序列图中的 getHeader），然后提议者通过签署包含竞标中提交的数据的区块，以具有约束力的方式选择一个 bid。然后，中继应发布相应的 payload（payload）（序列图中的 getPayload）。

请注意，没有任何东西可以阻止中继在 API 的一次调用中提供一个 bid，而在随后的调用中提供另一个（可能更有价值的）bid。这使得监控过程复杂化，因为除非提议者共享，否则 RM 不会知道提议者有什么看法。此故障 - "auction integrity（拍卖完整性）" - 为了完整起见而列出，但应被视为要检测的 "advanced（高级）" 故障类别，并且如果有疑问，仅应在假设中继具有最佳意图的情况下分配故障。

我们现在可以查看 commit-reveal 方案的每个阶段可能出现的故障：

竞标故障

• malformed bid（格式错误的竞标）
  • 中继产生一些在语法上无效的 bid（例如，不完整的 execution payload header（执行 payload 标头））或具有无效签名
  • requires（需要）：来自中继的 bid
• consensus-invalid bid（共识无效的竞标）
  • 中继产生的 bid 相对于共识逻辑无效，例如，execution payload（执行 payload）中的区块 number 错误（注意：RM 应对非规范分叉上的竞标保持容忍）
  • requires（需要）：来自中继的 bid
• payment-invalid bid（支付无效的竞标）
  • 如果此 bid 的 payload（payload）包含在链上，则该 bid 中声明的支付与最终交付给提议者的价值不匹配
  • requires（需要）：来自中继的 bid AND（并且） 下一步中的完整 payload（payload）
• valid bid, but nonconforming（有效的竞标，但不符合）
  • 该 bid 在满足先前条件的情况下有效，但不反映给定提议者的最新验证者偏好
  • requires（需要）：来自中继的 bid，来自提议者的最新偏好
• auction integrity: non-discriminatory（拍卖完整性：非歧视性）
  • 中继不歧视竞标者
  • requires（需要）：来自中继的 bid(s)，提议者看到的 bid(s)
• auction integrity: market competition（拍卖完整性：市场竞争）
  • 这个来自 @thegostep
  • 中继在给定的时间段内不会偏离其同行
  • requires（需要）：一段时间内来自中继的 bid(s)

payload 故障

• malformed payload（格式错误的 payload（payload））
  • 中继返回的 execution payload（执行 payload）在语法上无效（例如，缺少区块号）或与接受的 bid 中的 execution payload header（执行 payload 标头）不匹配
  • requires（需要）：来自中继的 payload（payload），来自提议者的已签名 blinded beacon block（盲化信标区块）
• consensus-invalid payload（共识无效的 payload（payload））
  • 假设先决条件成立，如果 execution payload（执行 payload）包含相对于共识逻辑无效的交易，则会发生此故障
  • requires（需要）：来自中继的 payload（payload），来自提议者的已签名 blinded beacon block（盲化信标区块）
• unavailable payload（不可用的 payload（payload））
  • 中继承诺通过在前一步骤中生成 bid 来提供某些 payload（payload），但无法提供此 payload（payload）
  • 注意：如果相应的区块最终出现在规范链中（甚至被孤立），则不应将其计入中继的错误，或者可能作为不同的子错误，“已发布但未能提供 payload（payload）”
  • requires（需要）：来自中继的 payload（payload），来自提议者的已签名 blinded beacon block（盲化信标区块）

性能故障/指标

考虑到其对网络安全的核心作用，我建议在任何性能监控之前实施行为监控。

TODO（待办事项）：更详细地充实这些内容

一些需要注意的指标：

• 中继延迟
• 中继错误率（包括运行时间、HTTP 错误率）
• 对获取原始请求/秒数不感兴趣，但欢迎听到其他意见

中继监控器功能集

目标：中继故障的索引集合

我们可以简单地从为每个中继观察到的上述故障数量制表开始。下游使用者可以使用故障数据来评估中继风险，或形成 "reputation（声誉）" 分数等。

这意味着中继监控器会维护一个按 "chain coordinate（链坐标）" 排序并按中继（公钥）索引的故障类型映射。

例如：

{
    "0xdeadbeefcafe": { // 中继公钥
        "malformed-bid": [\
            (slot, parent-hash, proposer-pubkey)\
            , (slot1, parent-hash1, proposer-pubkey1)\
        ], // 故障列表以及它们发生的 'when（时间）'，按故障类型组织
        ..., // 此处的其他故障
        "unavailable-payload": [], // 未观察到此中继的可用性故障
    }
}

注意：此 schema 只是一个示例，用于说明，很可能会发生变化

关于可审计性的题外话

中继监控器还需要持久化所有提取的事件，以便可以根据需要重新导出对中继性能的任何给定评估。请注意，输入数据使用作者的签名进行身份验证（例如，BuilderBid 上的 signature），并且这与规范链一起将能够验证任何 RM 输出的真实性。如果存在某种服务来捕获所有区块数据（即使是规范链之外的数据），你也可以独立验证任何中继监控器提出的任何声明。

如何处理故障

每种故障类型的要求都会产生一个依赖关系图，该图建议 RM 具有以下高级功能，这些功能组织为一系列并发的、长时间运行的 "tasks（任务）"：

0. 提议者偏好聚合

任何中继多路复用器软件都应在执行对任何连接的中继的例行调用时，将 SignedValidatorRegistration 的副本发送给任何连接的中继监控器。

RM 按公钥存储这些偏好（并且需要一个验证者索引映射）。

requires（需要）：更改 mev-boost 软件以将验证者偏好以及中继上传到已配置的中继监控器

并查看下面关于它是用户可配置的说明

1. 竞标检查

对于共识链的每个 slot 和执行链的每个 head，中继监控器从每个中继提取该链上计划的提议者的出价。

RM 可以验证该 bid 没有以下故障：

• 格式错误的竞标
• 共识无效的竞标
• 有效的竞标，但不符合

应存储 bids，并按中继公钥和执行区块哈希编制索引，以供以后分析

2. payload 检查

此处有一个选项，具体取决于提议者希望与中继监控器共享多少数据：他们可以将 SignedBlindedBeaconBlock 和 SignedBuilderBid（我们将其称为 "bid acceptance data（竞标接受数据）"）在调用 relay(s) 的 getPayload 时一起调用中继监控器。请注意，提议者可能出于隐私原因或避免将数据发送到其他端点的资源开销而希望跳过此步骤。

如果 RM 从未收到提议者的竞标接受数据，他们仍然可以监视规范链以获取任何到达的区块，并查看他们是否具有一些匹配的竞标（使用链上区块中的执行区块哈希），如果需要，可以使用 value 来打破僵局。这降低了 RM 的整体准确性，但支持较小的 staker（与资源充足的池相比），因此我认为这是一个值得支持的用例。

如果 RM 收到了竞标接受数据，则可以在调用适当的中继以获取相应的 execution payload 之后完成剩余的验证：

• 支付无效的竞标
• 格式错误的 payload
• 共识无效的 payload
• 不可用的 payload

奖励：如果 RM 与以太坊网络的其他部分建立了良好的对等连接，则它可以传播完整的 SignedBeaconBlock。

requires（需要）：允许将中继监控器数据收集配置为可配置的（如果在默认情况下以及将其发送给谁/不发送给谁，则下游 convo）

requires（需要）：mev-boost 软件随同从 relay(s) 调用以获取 execution payload 一起将 bid 和已签名区块发送到 RM。

3. 拍卖检查

本节暂时保持不透明，并且对这种类型故障的检测将被视为某些未来工作范围的一部分。

这将归结为确保对于观察到的数据集，提议者看到的内容与中继提供的内容之间没有不一致之处。

评级 API

在运行上述数据收集和故障处理的同时，RM 会像上面给出的示例一样，持续计算每个中继的 "scorecard（记分卡）"。此 "rating（评级）" API 可以在调用者通过此 API 请求时，在任何时间点提供此 "scorecard（记分卡）" 的当前快照。

此数据的主要使用者是中继多路复用器软件，该软件可以使用它来制定有关使用哪些中继的策略决策。

requires（需要）：mev-boost 软件应能够为一组中继监控器调用 "rating（评级）" API，并处理生成的数据

问：如何处理多个中继监控器 - 只是将它们全部合并在一起（？）

问：指出我们希望如何处理 "relay monitor（中继监控器）" 欺诈 - 首先，让我们假设 RM 是受信任的，甚至比中继更受信任

我建议在任何中继多路复用器软件中都内置 "default profile（默认配置文件）"，该配置文件编码了一种给定的策略，以防止最有害的故障。但这可能会成为 mev-boost 软件的可配置部分。

默认配置文件

默认故障检测算法是：

如果在过去的 N 个 slot 中，中继出现任何类型的 M 个故障，则中继多路复用器应在接下来的 2**N 个 slot 中停止使用该中继

注意：确切的配置文件尚待讨论，因此，如果你看到更好的东西，请告诉我！

requires（需要）：mev-boost 软件应每 epoch 调用一次 rating API，并将故障数据处理为任何附加中继的策略决策

requires（需要）：mev-boost 软件需要知道 epoch 何时开始，或者至少知道 epoch 的持续时间（如果不是在 epoch 开始时，则可以在 epoch 中的某个时刻进行查询）

问：我们可以改进为在任何提议之前进行调用，但是这样 mev-boost 需要比目前拥有的更多的关于链的上下文 - 我们对此有何看法？

关于稳健性的题外话

客户端软件中存在后备路径，因此我们可以安全地将这些策略决策限定到中继多路复用器软件，并且上游客户端软件将在网络安全性和活跃性方面发挥作用。

例如，中继多路复用器软件可能会根据最近的故障暂时识别给定提议没有中继，在这种情况下，提议者软件将使用本地路径构建区块，而不是通过 mev-boost 生态系统启用的远程路径。

附加说明/未决问题

• 如何确保每个人都对中继具有相同的配置？
  • 例如，如果我具有相同的 pubkey 但具有不同的中继端点，并且它们提供不同的数据？

基本原理/讨论

提议者可以滥用监控系统吗？

• 提议者可以为诚实的 bid 创建无效的信标区块
  • 这也可能被检测到并发布

还希望看到提议者的看法，并且如果需要，可以为不良提议者建立声誉，但这绝对不在目前的范围内

为什么使用 "simple scorecard（简单记分卡）" 来传达声誉？

从简单的东西开始更容易，并将一些工作推给使用者。

公开聚合指标比聚合然后对中继声誉发表看法更中立

隐私问题

中继监控器的这种设计，尤其是 mev-boost 软件将有关验证者的信息上传到 RM 的部分，对验证者的隐私保护得不是很好。我认为这种权衡因将数据发送到 RM 的 opt-in（选择加入）性质而得到缓解，并且考虑到其解决的风险的严重性是合适的。此功能的未来迭代可以开始合并会模糊信息流的构造，以支持更好的隐私。

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