乐观中继提议

乐观中继提案

目的

本文档介绍了乐观中继的概念，以配合 https://github.com/flashbots/mev-boost-relay/pull/285，这是一个小的 PR，它向 Flashbots 的 mev-boost-relay 添加了功能。虽然该 PR 深入探讨了如何 添加乐观功能，但本文档旨在在更广泛的 mev-boost 背景下以及现有的关于提议者-构建者分离 (PBS) 的以太坊文献中激发这种改变。

现在的 mev-boost

自从 Flashbots 引入 mev-boost 以来，它已成为关键基础设施。有许多优秀的数据来源可以证明这一点：

• https://www.mevboost.org/
• https://mevboost.pics/
• https://transparency.flashbots.net/

概要：>90% 的验证者正在使用 mev-boost 来外包区块构建。

Flashbots 团队继续与社区就软件的未来进行互动：

• https://collective.flashbots.net/t/toward-an-open-research-and-development-process-for-mev-boost/464
• https://collective.flashbots.net/t/mev-boost-development-philosophy/505
• https://collective.flashbots.net/t/development-next-steps-for-pbs-roundtable-at-devcon/438

部分讨论围绕社区如何继续迭代初始架构，以建立对协议中可以/应该 包含的内容的理解。

提议者-构建者分离 (PBS)

PBS 已经过广泛的研究。请参阅 https://notes.ethereum.org/@domothy/pbs_links 和 https://github.com/michaelneuder/mev-bibliography 获取文献链接，并参阅 https://barnabe.substack.com/p/pbs 获取当前研究领域的全面概述。

乐观中继：第一阶段

乐观中继是 Justin Drake 提出的一个想法，旨在帮助弥合研究与当前 mev-boost 软件之间的差距，目标是建立对 PBS 文献中提出的机制在实践中如何表现的理解。这旨在朝着理解什么（如果有的话）应该被纳入协议迈出一步。

mev-boost 和链上 PBS (IP-PBS) 之间的主要区别在于中继的存在。中继是区块构建者和提议者之间受信任的中介，而在 IP-PBS 中，其他验证者通过证明强制执行区块构建拍卖的规则。因此，乐观中继的第一阶段减少了中继在区块生产中的作用。

异步区块验证

第一阶段的关键思想是改变构建者的区块提交流程，使区块验证成为异步过程。当构建者向中继提交一个区块时，即使中继没有机会检查该区块是否有效，该出价也会立即有资格赢得拍卖。这允许构建者提交更多区块，更重要的是在 插槽 中稍后提交区块（因为他们不必等待区块被验证才能注册出价）。我们称之为“乐观”，因为中继在短期内假定该区块有效，同时将实际验证推迟到稍后的时间。构建者必须在中继处发布抵押品（或有担保人）才能利用对其区块的这种乐观处理，如果他们提交无效区块，他们将被“降级” 回到当前的 mev-boost 实现，其中每个区块在出价被认为合格之前都会被验证。至关重要的是，如果构建者提交一个最终赢得拍卖并被提议的无效区块，则错过其 插槽 的验证者将获得中标金额的退款。

构建者的角度

下图显示了常规 mev-boost 的区块构建流程： <img width="797" alt="Screen Shot 2023-02-09 at 2 41 14 PM" src="https://user-images.githubusercontent.com/24661810/217920211-1730f598-4542-495f-b910-b8ca87d77382.png">

在提议者在 插槽 开始时对中继调用 getHeader 之前，必须验证构建者的区块。在此图中，Δ 表示中继验证区块所需的时间。因此，构建者的提交必须在下一个 插槽 开始之前至少 Δ 到达，才能使出价有效。将其与乐观区块构建流程进行比较：

<img width="797" alt="Screen Shot 2023-02-09 at 2 53 41 PM" src="https://user-images.githubusercontent.com/24661810/217922756-6abe71fd-a7e6-49fa-850d-3741488f937e.png">

在这里，构建者立即收到一条响应，表明他们的出价已激活，并且中继可能不会模拟该区块，直到 负载 已作为完整的 信标区块 发布。构建者有动力使用乐观中继，因为他们不再需要在区块提交期间支付 Δ 时间 延迟。MEV 是一场微小 利润 的游戏，速度对于成功的构建者至关重要。为了证明这一点，请考虑以下情况：

<img width="797" alt="Screen Shot 2023-02-09 at 3 36 18 PM" src="https://user-images.githubusercontent.com/24661810/217931229-2d79c7b2-4e2d-4a8e-89f5-0fe9be440923.png"> 在这种情况下，构建者知道他们的提交需要在 12-Δ 时间之前到达中继。在他们提交区块后，立即出现一个大的 MEV 机会。 他们可以尝试提交一个新的区块，该区块捕获更多的 MEV，因此有更高的机会赢得拍卖，但为时已晚，因为仿真将在 t=12 之前完成。直观地说，构建者在提交区块之前等待的时间越长，他们收听交易的时间就越长，因此他们的出价就越高。

提议者的角度

提议者的角度与 mev-boost 的现状几乎相同，只是略有变化，即他们不再保证他们签名的 头 对应于有效的区块。他们仍然在 插槽 开始时调用 getHeader 并签署他们收到的 头。对中继的信任假设保持不变。如果他们最终提议的区块结果无效，他们必须信任中继会赔偿他们损失的 插槽，这与信任中继验证区块是否包含与基本 mev-boost 案例中的出价金额相对应的付款相同。

安全考虑

在 https://github.com/michaelneuder/mev-boost-relay/pull/2 中提出了许多我们想要解决的问题。感谢 Chris Hager、Alex Stokes 和 Mateusz Morusiewicz 的初步反馈！

中继抵押

管理抵押以实现乐观处理的中继运营商应对管理这些资金所带来的额外法律和运营复杂性负责。一些方面认为这是一个重大问题。 我们为 Ultra Sound Relay 提出的解决方案是构建者-担保人的方法。中继充当中间人，以确定构建者 错误 何时导致 插槽 丢失，但预期的结果是一旦问题提交给构建者，他们将直接退还错过 插槽 的提议者。由于构建者的声誉远远超过错过的 插槽 的货币价值，我们预计绝大多数退款将以这种方式顺利处理。在构建者停止响应或决定扣留退款的特殊情况下，构建者-担保人将介入并退还提议者。违规构建者的担保人可能会移除该构建者的剩余 抵押品，因此该构建者将恢复为非乐观处理。此外，对于每个可退款的事件，我们计划公开发布一份事后分析，解释发生了什么。事后分析的格式将是：(a) 事件的时间线，(b) 涉及的构建者和提议者，(c) 导致 插槽 错过的出价，(d) 与出价相关的错误，(e) 退款详细信息。 此信息将提供中继运营的透明度，并允许我们监控常见的构建者故障模式。这种方法的另一个好处是 担保人可以是与中继本身分离的实体。例如，Ultra Sound Relay 愿意为其他较小中继的可信构建者充当担保人，以消除管理 抵押品 和退款的任何开销。为了引导此过程，Ultra Sound Relay 愿意为以下构建者充当 1 ETH 的担保人：

* builder0x69
* flashbots
* beaver
* bloxroute
* manta
* blocknative
* rsync
* eden
* eth-builder
* buildai
* payload
* nfactorial
* s[0-9].+
* lightspeed
* manifold
* Rick Astley

愿意与 Ultra Sound Relay 团队合作并展示高保真区块生产的新构建者可以添加到此列表中！

错过 插槽（活性攻击）

该提案增加了错过 插槽 的风险，但只是略有增加。因为中继不验证区块，所以提议者最终可能会签署一个错误的 头。提议者无法通过签署有效的区块来纠正这种情况，因为签署两个相同高度的区块是一种 惩罚 条件。但是，我们实施它是为了在手动干预之前，每个乐观构建者最多只会错过一个 插槽。默认情况下，所有构建者都被视为非乐观的，并且发布 抵押品 的过程是手动的。如果该构建者最终提交了一个错误的区块，则将错过一个 插槽，我们将手动调查故障，启动退款，并与构建者沟通。只有当我们高度确信我们了解了出错的原因以及为什么它不会再次发生时，我们才会允许构建者重新发布 抵押品 并再次访问乐观处理。此外，我们只乐观地处理其价值低于构建者发布的 抵押品 的区块。构建者可以自由地提交具有超过其 抵押品 的巨大 MEV 的区块，我们只会同步验证这些出价，因为它们无法支付退款金额。最后，我们有逐步推出此更改的好处。通过从 Ultra Sound Relay 开始，我们可以不断监控由此更改导致的错过 插槽 的数量。如果我们确定它超过了我们感到舒适的程度，我们可以简单地将其关闭。

勾结

考虑提议者和构建者是同一个恶意 行动者 的情况。构建者可以提交一个具有无效区块的大额出价，以确保他们通过中继赢得拍卖。这将导致提出无效区块，并且中继会计系统记录提议者欠一笔大额退款。 但是，出价是由同一构建者抵押的，因此即使我们发出退款，资金也来自同一 行动者，因此该 行动者 没有获得任何额外的利润。唯一的缺点是中继团队必须手动发出退款，但我们预计这种情况很少发生，并且 通过仅让受信任的构建者加入，我们可以最大限度地减少这种辛苦。此外，提议者除了跳过他们的 插槽 之外什么也没做，他们可以通过首先关闭他们的机器来做到这一点。

激励兼容性

构建者有动力诚实地使用乐观中继，因为它严格增加了他们能够产生的 MEV 数量。提交无效的出价会导致他们失去 抵押品，这不是一个理性的选择。

提议者有动力使用乐观中继，因为它增加了针对其 插槽 的出价规模。更大的出价意味着为提议者自己提取了更多的价值。

中继仍然是一个充当 托管 机制的中立方，但不会收到任何 奖励。

道德风险

更微妙的论点是，此项更改引入了道德风险。错过的 插槽 会影响整个链，虽然我们承认可能会有一些额外的错过 插槽，但我们计划以保守的方式处理此项更改。通过最初只允许 白名单 上的受信任构建者，我们确保不会出现大量错过 插槽（再次，每次手动干预每个构建者只有一个）。我们将积极收集围绕提出的任何无效区块的数据，并与构建者合作以了解导致无效区块提交的原因。公开的事后分析将提高透明度，并允许社区围绕整个项目进行反馈和参与。构建者 强烈鼓励避免提交无效区块，因此如果出现问题，他们会想知道他们的区块出了什么问题。

从 Goerli 的经验

重复模拟的脆弱性

在我们的第一个实现中，我们模拟了赢得拍卖的乐观区块两次：（1）在由区块提交触发的异步调用中（2）在 getPayload 中检查 获胜区块是否有效。虽然这在理论上是可行的，但我们发现模拟同一个区块两次非常脆弱，因为来自并行区块提交之间 竞争 的许多错误 条件出现了。因此，我们重构了乐观中继，使其只模拟每个区块一次。在 getPayload 中，我们使用乐观区块的 等待组。一旦我们知道该 插槽 的所有区块都已处理完毕，我们就会检查 降级 表中是否有获胜区块。 如果它在那里，那么我们知道一个无效区块已传递给提议者，因此有必要进行退款。这将触发 降级 表上的更新 我们在其中插入 SignedBeaconBlock 和 SignedValidatorRegistration，以确保所有相关数据都位于一个位置。 此新设计在 https://github.com/flashbots/mev-boost-relay/pull/285 中进行了介绍。

负载 太大错误

我们发现许多区块返回 **负载** 太大 的错误。经过调查，我们意识到将区块提交到 prio-load-balancer 的 负载 的最大大小太小了。此 PR 将最大大小更新为 2MB：https://github.com/flashbots/prio-load-balancer/commit/d4d171c3fcda4e4ca49075031efa44065c4f9a5a。

性能分析

由于乐观中继主要涉及改进区块提交流程的性能，以允许构建者在 插槽 的稍后时间提交区块，因此我们 从 Goerli 中继收集了性能数据。下表包含提交区块流程的三个阶段的微秒数分布的各种 百分位数：

<img width="797" alt="Screen Shot 2023-02-09 at 3 36 18 PM" src="https://user-images.githubusercontent.com/24661810/219968582-e26f93ff-a7ed-4a12-ab4c-835094a4b48b.png">

中间阶段 simulation_duration 是 v1 乐观中继通过从 快速 路径中删除区块的模拟来消除的。第一阶段 decode_duration 是区块提交流程的整体运行时的另一大组成部分。此阶段是通过网络接收 负载 的过程。使用 8 MB/s 的连接，我们有 8 KB/ms。 中位数 解码 时间为 ~80ms，这意味着 640KB 的区块。这似乎是一个合理的估计。此外，网络 延迟 的 方差 很高。 下图显示了 解码 时间和 负载 大小之间的相关性。我们按构建者 公钥 为数据点着色。显然，两者之间存在正相关关系，并且不同的构建者具有不同的网络连接，这也显示在数据中。

<img width="797" alt="Screen Shot 2023-02-09 at 3 36 18 PM" src="https://user-images.githubusercontent.com/24661810/219968993-b2cb260e-25af-4cf1-9cd6-ad8f05289719.png">

我们还收集了关于一个 插槽 过程中构建者出价的数据。下图显示了 10 个不同构建者的 插槽 5771427 的出价价值作为时间的函数：

<img width="797" alt="Screen Shot 2023-02-09 at 3 36 18 PM" src="https://user-images.githubusercontent.com/24661810/218236401-cf5b4052-8e32-4871-99a9-c746156a23d6.png">

更广泛地说，我们可以观察到获胜区块到达中继的时间在 插槽 持续时间内的 概率分布。 <img width="797" alt="Screen Shot 2023-02-09 at 3 36 18 PM" src="https://user-images.githubusercontent.com/24661810/219969192-c52275b4-48fa-4db1-90fd-b88c4c7ca637.png">

显然，插槽 中后面的秒数具有更高的包含获胜出价的概率。这直接源于在 插槽 期间会发生更多的 MEV，从而允许后面的区块捕获更多并因此增加其出价规模。

Justin Drake 的常见问题

乐观中继会模拟区块吗？

是的，乐观中继会模拟所有可能已转发给提议者的区块。模拟只是发生在 延迟 关键路径之外。

乐观中继会导致大量错过 插槽 吗？

假设没有中继 错误，最坏的情况是每个 抵押 的构建者错过一个 插槽（在重新激活之前）。信标链 旨在处理错过 插槽 的情况。

构建者是否有动力生成无效区块？

无效获胜区块的构建者会遭受经济损失。此外，单个无效区块将禁用构建者的乐观中继，在重新激活之前会产生 延迟 劣势。

你对乐观中继运营商有什么建议？

我们对乐观中继运营商有以下几点建议：

• 警报 – 为 降级 设置自动警报（例如，电子邮件或电话）
• 退款 – 及时（例如，在 24 小时内）将出价金额加上 信标链 惩罚 和错过的 奖励 转给提议者费用接收人
• 最大 抵押品** – 限制每个构建者的最大 抵押品** 金额（例如，10 ETH），以保持公平的竞争环境
• 调查 – 手动调查 降级，并要求构建者在重新激活乐观中继之前修复区块构建 错误
• 冷静期 – 在重新激活乐观中继之前，实施 降级 后的冷静期（例如，24 小时）
• 惩罚 – 考虑每次 降级 的固定 惩罚（例如，0.1 ETH），尤其是对于重复 降级

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