乐观中继提议

乐观中继提议

目的

本文档介绍了乐观中继的概念，以配合 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/

tl;dr; >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。

乐观中继：第 1 阶段

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

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

异步区块验证

第 1 阶段的关键思想是更改构建者区块提交流程，以使区块验证成为异步过程。 当构建者向中继提交区块时，该投标立即有资格赢得拍卖，即使中继没有机会检查该区块是否有效。 这允许构建者提交更多区块，更重要的是，在插槽中稍后提交区块（因为他们不必等待区块被验证才能注册投标）。 我们称之为“乐观”，因为中继在短期内假设该区块有效，同时将实际验证推迟到稍后的时间。 构建者必须在中继处发布抵押品（或有担保人）才能利用对其区块的这种乐观处理，如果他们提交无效区块，他们将被“降级”回当前的 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 中，我们 使用乐观区块的 WaitGroup。 一旦我们知道该插槽的所有区块都已处理完毕，我们就会检查降级表以查找获胜区块。 如果它在那里，那么我们就知道已向提议者传递了一个无效区块，因此需要退款。 这会触发降级表上的更新， 我们在其中插入 SignedBeaconBlock 和 SignedValidatorRegistration，以确保所有相关数据都位于一个位置。 这种新设计在 https://github.com/flashbots/mev-boost-relay/pull/285 中介绍。

有效载荷过大错误

我们发现许多区块返回了 Payload too large 错误。 经过调查，我们意识到区块提交给 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 的事实，从而允许后面的区块捕获更多 MEV，从而增加其投标规模。

Justin Drake 的常见问题解答

乐观中继是否模拟区块？

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

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

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

构建者是否会受到激励来生成无效区块？

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

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

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

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

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