MEV-Share：不断演变的MEV再分配机制

关键要点

• MEV-Share 是一种旨在将 MEV 收入分配给 MEV 管道中的用户的协议。

• 除了用户、搜索者和构建者之外，还出现了一个名为 Matchmaker 的新实体。Matchmaker 负责传输交易、创建最终捆绑包和保护用户交易等任务。

• MEV-Share 仍然存在局限性，包括过度依赖 Matchmaker 以及 MEV 奖励的结构性问题。

1. 简介

今年 2 月，一种用于重新分配最大可提取价值 (MEV) 的新设计 MEV-Share 首次在 Flashbots 论坛上推出，并在 3 月 ETH Denver 的 MEV 赛道中进行了介绍。为了更容易理解 MEV-Share，本文将介绍 MEV-Share 与其前身 MEV-Boost 相比的关键特性，并展示其高级别的工作原理。我还将讨论 MEV-Share 的一些限制，并简要分享我对它们的看法。本文需要一些 MEV-Boost 的先验知识。

2. 什么是 MEV-Share？

在以太坊网络上 MEV 的创建和重新分配中，涉及到许多不同的参与者。用户创建交易，搜索者将这些交易与他们自己的 MEV 交易组合成一个捆绑包。一旦捆绑包交付给构建者，它会将捆绑包和其他交易组合成一个完整的区块，并将其发送给提议者。

MEV-Boost 和 MEV-Share 可以理解为定义这些不同参与者之间交互的协议，其目标是在他们之间公平地分配 MEV。虽然 MEV-Boost 侧重于提议者和构建者之间的关系，以防止他们从事恶意行为，但 MEV-Share 在搜索者和用户之间的关系中添加了逻辑。MEV-Share 不是一个独立于 MEV-Boost 的协议，而是试图将 MEV-Boost 提升到一个新的水平。

MEV-Share 的主要特点是在用户之间重新分配 MEV。在最初的 MEV-boost 设计中，当搜索者使用他们的交易创建 MEV 交易时，用户不会直接获得奖励。在 MEV-Share 中，其想法是将部分 MEV 收入返还给用户。

例如，假设用户在 Uniswap 上创建一个交易，将大量 ETH 兑换为 USDC，这导致 DEX 之间 ETH-USDC 池中的价格差异，搜索者看到这一点并在用户的兑换交易之后立即捆绑一个套利交易，从而获得 1 ETH 的利润。在 MEV-Boost 中，如果搜索者向构建者出价，并且搜索者和构建者获得 1 ETH 的利润，那么在 MEV-Share 中，这 1 ETH 中的 0.8 ETH 将分配回给用户（给用户 80% 只是一个例子）。这背后的想法是，用户是决定区块链生态系统使用的人，只有他们的交易才能产生 MEV，因此奖励和保护他们将使网络更加活跃。

3. 工作原理

MEV-Share 除了用户、搜索者和构建者之外，还引入了一个名为 Matchmaker 的新实体。Matchmaker 是一个受信任的实体，预计不会从事恶意行为，并且负责在用户、搜索者和构建者之间转发交易、创建最终捆绑包和保护用户交易。它们之间的交互通常按以下顺序进行。

3.1 用户 → Matchmaker → 搜索者

用户将其交易发送给 Matchmaker，然后 Matchmaker 仅与搜索者共享有关用户交易的部分信息。例如，如下面的 json 所示，Matchmaker 不是透露交易的全部内容，而是仅选择并发送交易调用 Uniswap V3 合约并交易 ETH 和 USDC 代币的信息。

用户可以通过指定自己的隐私首选项来指定在交易中共享哪些信息。只向搜索者显示交易的一小部分的原因是为了保护用户的交易。如果搜索者拥有关于交易的所有信息，他们可以单独将捆绑包传递给构建者或提议者，从而绕过 MEV-Share。通过将此捆绑包放入一个区块中，搜索者不必为提取的 MEV 向用户付款。因此，使用用户公开可用的交易提取 MEV 的过程与当前 MEV-Boost 中的过程相同。

3.2 搜索者 → Matchmaker

[情况 1] 当搜索者准确知道用户的交易时。

搜索者从他们从公共内存池获得的完整交易和从 Matcmaker 获得的部分交易中创建可提取的 MEV 交易，并将它们发送回 Matchmaker。如果你从完整的交易中创建一个 MEV，你应该能够创建一个准确的 MEV 捆绑包并将其发送给 Matchmaker。（你也可以直接将其发送给构建者。）

以下面的 json 数据为例，用户的特定交易“0xhash”之后是 MEV 交易“0xf145bh0t5”，这是搜索者自己的创建，它被捆绑在“txs”字段中并发送给 Matchmaker。

[情况 2] 搜索者不知道用户的交易

但是，正如前面提到的，搜索者无法访问用户的所有交易。因此，当搜索者创建一个 MEV 捆绑包时，他们必须要求 Matchmaker 在用户中找到满足其特定标准的交易。由于它不知道用户的交易，因此在创建捆绑包时，它只能通过清空用户的交易来传递部分捆绑包（部分捆绑包）。

以下是搜索者发送给 Matchmaker 的 json 数据示例。捆绑包的前缀为“”，这意味着如果你有满足以下条件的交易，请将其放在此位置。“Hints”字段中的数据是搜索者正在寻找的内容。当用户的交易执行时，与合约“0x7a25”和“0xd14b”交互并生成事件日志“0x41000”的交易应该进入“”字段。

3.3 Matchmaker → 构建者

Matchmaker 获取搜索者的部分捆绑包，并搜索符合搜索者条件的交易。然后，它创建一个捆绑包并设置一个有效性条件，以便用户可以获得交易的部分奖励。Matchmaker 最终指定用户应收到的奖励。

在下面的示例中，有效性条件要求构建者向名为 0xprivsender 的用户发送 1 ETH。假设构建者也是一个受信任的实体，它将向用户发送 1 ETH。通过此过程，当用户的交易插入捆绑包并创建 MEV 时，用户可以获得补偿，这是 MEV-Share 的主要目的。

4. 局限性和批评

MEV-Share 是一个相对较新的概念，实际的 实现 仍处于早期阶段。在 Flashbot 对 MEV-Share 的介绍的进一步讨论部分中，它提到了许多其他需要考虑和改进的领域。在本文中，我将回顾我认为 MEV-Share 最大的局限性，并解释为什么我仍然对其适用性持怀疑态度。

4.1 很少提及匹配

正如我们在演练中所看到的，Matchmaker 应该为用户找到符合搜索者提供的 Hints 的交易，但是关于匹配实际如何发生的细节非常少。

首先，搜索者需要创建一个 MEV 捆绑包，并向 Matchmaker 提交为其创建的捆绑包的出价。但是，如果搜索者仅拥有关于用户交易的部分信息，则很难创建完整的捆绑包。此外，搜索者不想赔钱，因此其出价将会保守。有人担心，允许搜索者创建和提交部分捆绑包实际上可能会增加搜索者的复杂性和不确定性。

要求 Matchmaker 查找满足特定条件的交易也可能会降低整体效率。这是因为，在 MEV-boost 中，搜索者创建了整个捆绑包，而在 MEV-Share 中，搜索者请求具有特定条件的交易，并且 Matchmaker 必须逐个搜索满足所有搜索者条件的交易。我们需要考虑我们是否正在创建一个名为 Matchmaker 的受信任实体来隐藏用户交易，并将所有工作都留给这个无所不知的 Matchmaker。

4.2 过度依赖 Matchmaker

Matchmaker 在接收来自用户的所有交易并向搜索者提供一个子集、查找满足搜索者要求的交易、完成捆绑包并将其交付给构建者方面发挥着重要作用。除了保护用户交易的角色外，它几乎继承了 MEV-Boost 中搜索者的角色，因此需要高计算能力。

在 MEV-Boost 中，存在少量称为构建者的中心化实体，创建另一个名为 Matchmaker 的中心化实体可能会因中心化而引入另一个攻击媒介。即使我们排除 Matchmaker 可能具有恶意的可能性，它仍然可能容易受到 DoS 攻击，并且文章中稍后提出的解决方案似乎不是很完整。

有两种方法可以解决此问题：一种是向搜索者收取提交捆绑包的费用，另一种是管理搜索者的声誉。前一种选择将为协议增加另一层复杂性，使其对搜索者的参与吸引力降低，并且还需要考虑提交费用。后者似乎是最现实的，但它也增加了 Matchmaker 的运营复杂性，并且存在单个搜索者通过多个节点发出请求的 Sybil 攻击的风险。

最初的 Matchmaker 将由 Flashbots 提供支持，并且有关于未来去中心化 Matchmaker 的讨论，但没有说明具体是什么样。

4.3 用户 MEV 补偿方法的结构性问题

Matchmaker 指定一个有效性条件，这使得构建者将一部分 MEV 返还给用户。这里的一个问题是 Matchmaker 对应该奖励哪个用户不明确。如果 MEV 捆绑包中的用户交易来自单个用户，并且我们知道搜索者是谁，那么 MEV 的分配相对简单，但情况并非总是如此。对于具有多个用户的捆绑包，也很难确定应该奖励哪个用户以及奖励多少。

最大的问题是很难判断搜索者何时假装成另一个用户并将自己的交易包含在捆绑包中。如果用户交易产生的 MEV 非常大，那么搜索者的策略将是在捆绑包中包含尽可能多的他们假装成用户的交易，以便利用奖励，从而拿走部分奖励。Matchmaker 发现并禁止这种情况似乎不现实。

5. 结论

在本文中，我们研究了作为 MEV-Boost 之后的下一步推出的 MEV-Share 协议，并讨论了当前设计的局限性。它具有重要意义，因为它是首次尝试将 MEV 奖励直接返还给用户。然而，在现实中，Matchmaker 的过度信任结构和 MEV 重新分配方法的困难仍然被认为是主要的局限性。MEV-Share 是否会提出解决这些问题的可行方案，以及该协议在未来是否会变得更加先进，还有待观察。

感谢 Kate 为本文设计图形。

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