用于合并的 Flashbots 架构 MEV-Boost 及其实现计划

来源 | ethresear.ch

本文档概述了用于区块构建者/区块提议者分离 (PBS) 的、基于信任的市场设计，它将与即将到来的以太坊合并分叉兼容。正如在这些 Flashbots POS 提案 里所详述的，这个基于信任的解决方案与当前 Flashbots 竞拍设计 (其修改由以太坊核心开发者提出，使得个人质押者可以参与且不会对以太坊共识引入变更) 最为相似。这个解决方案旨在为无需许可的 PBS 设计搭建桥梁。关于 PBS 设计，我们强烈建议可以纳入合并后的清理分叉，以提高区块构建者的去中心化水平。

术语

• 共识层客户端 (consensus client)：负责以太坊权益证明共识的客户端
• 执行层客户端 (execution client)：负责以太坊虚拟机执行的客户端
• 执行负载 (execution payload)：包含未被签名的执行负载的完整内容的消息，这个消息会被添加到一个信标区块中
• 中间件 (middleware)：在共识层客户端和执行层客户端中间的一个新软件，它与中继相连
• 提议者 (proposer)：对进入网络的信标区块进行签名和提交的一方，通常被称为验证者
• 用户：发送交易的普通以太坊用户
• 搜索者：高阶以太坊用户，专门寻找 MEV 机会和发送交易捆这样的高级交易类型
• 构建者 (builder)：专门用从用户和搜索者接收到的交易构建以太坊执行负载的一方 (搜索者和用户信任其会公平打包)
• 中继 (relay)：专门从事 DoS 保护和网络连接的一方，它们验证和路由执行负载给区块提议者 (构建者信任其会进行公平的路由，提议者信任其路由的负载具有区块有效性、准确性和数据可用性)
• 第三方托管 (escrow)：负责为提议的执行负载提供冗余的数据可用性的一方 (中继信任其提供的数据隐私性)

架构

Flashbots 竞拍 ( Flashbots Auction) 架构允许验证者将区块构建外包给一个第三方区块构建者网络。虽然验证者能够打包任何的负载到链上，我们相信当验证者的工作只限于选出给他们支付最多 ETH 的负载时，网络的去中心化和验证者收益才能最大化。

在 PoS 以太坊，flashbots 区块构建过程包括以下步骤：

1. 用户和搜索者通过公共的 p2p 交易池或直接的通道发送交易给区块构建者
2. 构建者用这些验证者提供的交易和头部参数构建执行负载。构建者可以直接把验证者的 feeRecipient 地址设为该负载的 coinbase 地址，或构建者可以设置自己的地址并在负载里打包一笔转账到 feeRecipient 的交易。
3. 中继从构建者接收执行负载，验证负载的有效性，并计算负载的数值 (即支付给 feeRecipient 的 ETH 数额)。
4. 第三方托管从中继接收完整的执行负载，以提供数据可用性。
5. 验证者从中继接收执行负载头 (从交易内容里抽取出来的执行负载) 。中继必须在每个执行头部附上一个负载数值的标示。验证者挑选价值最高的头部，对负载签名，然后返回给中继，经由第三方托管广播到网络。

请注意，一个实体可以在这个系统中扮演多种角色。这些角色被分别标识，因为它们都适合于某种程度的专门化。在短期内，应该有多个独立的中继。在未来，一个在共识水平的去信任 PBS 设计将会移除对中继和第三方托管的需求。

在验证者方面，这个架构利用了一个独立的中间件，它在共识层客户端和执行层客户端之间。这个中间件处理与中继的通信、用于选择最有价值的负载的利润转换逻辑，以及在中继断开连接时转为使用本地执行层客户端的回退机制。使用一个中间件而不是对共识层客户端的直接修改使得我们可以独立维护各个组件，并可以在对 engine api 带来最小改动的情况下实现跨客户端的兼容性。

需要注意的是，中继只应用于在区块构建时接收负载——中继不应该用于履行执行层客户端的其他职能，而且在没有可用中继时，验证者应该总是回退到本地负载构建。

由于执行负载头并不包含交易内容，验证者抢跑的风险就消除了。这个设计使得个人质押者可以参与到 Flashbots MEV 提取中，从而减少经济中心化的激励。但是，这个设计还要求验证者信任中继能过滤掉无效的负载，准确地报告负载的数值，并当执行负载头被签名时揭示交易内容。引入第三方托管是为了通过在多个提供商间复制交易内容，以提高数据可用性。 总结：

• 验证者信任中继提供的数据可用性、负载有效性和负载数值的准确性
• 用户和搜索者信任构建者、中继和第三方托管的抢跑保护
• 由于是中间件，可以最小化对共识层客户端的修改
• 在中继和验证者之间的往返通信，增加了区块提议的延迟

讨论点

客户端修改

Flashbots 将继续使用形式规范，并将支持客户端实现团队为合并添加 MEV 兼容性。

当前的设计要求对共识层客户端接口做出以下修改：

• 使验证者能够对执行负载头 (而不是整个执行负载) 签名并打包到信标区块
• 使得验证者能够使用用于认证目的的质押密钥对有前缀的消息进行签名
• 使得共识层客户端能够路由一个已签名的信标区块回到中间件，而不是试图发送到网络里
• 使得共识层客户端能够在中间件出现问题时回退到一个本地或远程的执行层客户端

目前不需要执行层客户端的修改。

恶意的中继

这种设计最重要的安全机制是让所有验证者能够识别一个中继是否变成恶意的。

让我们假设更糟糕的情况：有一个单一的中继与 100% 的验证者相连。中继开始提议无效区块，并谎报负载的数值，以让验证者总是选择它们。

在这种情况下，一个天真的中间件实现可以导致区块链停止运行，因为验证者不再提议有效区块。

中继有三种方式提议坏的负载：

1. 无效的负载：违反一些共识规则的负载
2. 不准确的数值：提议的负载数值与执行后声称的不一致
3. 缺失的数据：负载主体永远不被中继揭示

为了缓解这种情况，必须能够 1) 在发送给验证者之前，在多方间提前验证负载，或 2) 在一个中继已经提议了一个坏的负载并自动回退到一个安全的替代客户端时，让网络里的所有验证者都可以识别出该中继。最重要的是，这种安全机制必须在面对互相敌对的中继时是强韧的。

中间件和中继间的通信

在中间件和中继间之间的通信有多个选择：推式 vs 拉式，直接 vs p2p。

必须注意确保满足以下要求，以选择最佳实现：

1. 它必须保护验证者隐私，不把验证者密钥与 IP 地址联系起来
2. 它必须有尽可能低的延迟
3. 它在对抗恶意中继/验证者是必须是强韧的

错失 slot 的风险

如果区块提议者未能即时广播以收集足够多的证明，就会出现错失 slot 的情况。在这种情况下，区块提议者不会收到该区块的基本奖励 (在质押了 1000 万个 ETH 的情况下大约是 0.025 个 ETH )，交易和 MEV 奖励也不会有。由于这个架构要求在向证明者广播前发送已经签名的负载头回去中继/第三方托管，因此了解什么是可接受的错失 slot 比率以及如何在正常的网络运行条件下将其最小化将是非常重要的。

负载头参数

为了产生有效区块，构建者和中继必须了解执行负载头的所有属性。尽早提供区块构建所需的所有输入是符合验证者的利益的。这使得构建者能够最大限度地提高准确性和计算可用时间，以找到一个最佳的区块构建。

除了 coinbase ，所有的头部属性都可以由构建者根据他们看到的网络状态得出。由中间件来过滤建立在不正确状态上的负载。

验证者认证与 feeRecipient 地址

验证者需要与构建者和中继沟通他们希望用作 feeRecipient 的地址。这个地址对于准确度量被提议的负载数值是必要的。由于 feeRecipient 可以是任何地址，验证者必须在公布时自行认证。

目前还没有让验证者对他们的 feeRecipient 进行认证和发布的方法。最好的方法是是添加一个签名域，让验证者可以安全地用他们的质押私钥对任意消息进行签名。

部分区块 vs 完整区块

这个规范弃用了在构建者和区块提议者之间通信的 “Flashbots Bundles”，转而使用代表一个区块的完整排序和内容的执行负载。尽管 bundle (交易捆) 为打包交易到区块头提供了一个高效的竞拍机制，但它对于所有排序偏好的表达力还不是很足够。特别是，交易捆竞拍不适用于大型交易或抢跑保护的用例。转为使用完整区块提议意味着对排序的全部偏好都可以得到表达。

用于优先处理的频带外贿赂与 MEV 均匀分配/烧毁

有些验证者可能会接受频带外的贿赂，以优先处理某些负载或试图通过证明贿赂来进行时间盗贼攻击 (time bandit attack) 。理论上，共识可以强制要求给区块提议者支付最多 ETH 的区块构建者构建的区块被打包，且把手续费分摊或烧毁，尽管这个机制超出了这个提案的讨论范围，且需要进一步的研究。

去中心化

正如上文提到的架构，中继是受信任会提供抢跑和 DoS 攻击保护的。尽管这个系统允许有多个中继无需许可地互相竞争，可能的情况是只有少数几个成功的中继。我们强烈建议核心开发者在清理分叉上考虑纳入无需许可的设计，以减少中继信任要求，并提高网络的去中心化水平。

客户端优化

尽管不推荐，但只依赖第三方区块构建者进行区块构建的验证者可以运行一个精简版的执行层客户端，它删除了交易池和区块构建逻辑，所以降低了客户端对硬件和带宽的要求。

mev-boost 的实现计划

来源 | github.com/flashbots

一项允许以太坊共识层客户端把区块构建外包给执行层客户端以外的第三方区块构建者的服务。请看上文的高层次架构和 docs/specification.md 了解其规范和实现细节。

v0.2 请求流：

实现计划

共识层客户端变更的总结可以在这里找到。

Version 1.0 （下一步，里程碑 2，合并）

安全、认证和声誉

• mev-boost 从共识层客户端请求认证 feeRecipient 的消息，并在 p2p 网络定时 gossip
• 添加模块，用硬性的或统计黑名单验证之前的中继负载的有效性和准确性
• 添加模块，用于订阅第三方中继监测服务

所需的客户端修改

• 当发生中间件崩溃时，共识层客户端必须能够绕过中间件，连上一个本地或远程的执行层客户端
• 共识层客户端必须实现提议 promises

版本 2.0 - 隐私 (可选)

添加 p2p 通信机制，以避免验证者去匿名化

• mev-boost gossips 通过 p2p 对区块+初始负载头部签名

所需的客户端修改

• 共识层客户端必须实现新的 Gossipsub Topics

Version 3.0 - 配置 (可选)

添加可选配置到提供替代保证

• 考虑添加直接的 relay_forkchoiceUpdatedV1 调用到中继，用于同步状态
• 考虑直接返回完整负载到验证者作为优化

• 考虑添加支付的默克尔证明，把验证要求转移到中继

  ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ETH中文站。若需长期转载，请联系eth@ecn.co进行授权。

本文首发于：https://news.ethereum.cn/Technology/mev-boost-merge-ready-flashbots-architecture