原文:《MEV: The Next Five Years》by James Prestwich

编译:aididiaojp.eth,Foresight News

最近我写了一篇名为《以太坊MEV:第一个五年回顾》,作为今天这篇文章的前传。

看到 MEV 过去一年的发展,我对它将在加密生态系统中扮演重要角色而充满希望。MEV 迄今为止的故事是关于 MEV 的专业化,这篇文章也是关于专业化对 MEV 未来意味着什么。

MEV 市场中的三种角色

在熊市期间,市场将会出现一些协调性的措施来推动其他生态系统中的 MEV 供应链的发展,如 Solana、Cosmos、Near 等。从我们的立场来看,搜索者 - 构建者 - 提议者 SBP 结构似乎将在所有这些生态系统中复制,并且专业化在复杂的市场中获胜。SBP 结构将继续占主导地位,因为简单的边界允许每个角色在不与其他角色协调的情况下专门化。目前很难看到在当前格局中形成其他市场结构的可能。

然而,一些费用市场与以太坊的完全不同,例如Penumbra由于批量拍卖和阈值加密交易,SBP 市场结构不会形成。还有 Osmosis 团队已经在 MEV 对抗机制上花费了大量研究时间,但目前尚不清楚 MEV 市场结构在这些链上会是什么样子,至少暂时无法形成成熟的 MEV 供应链。

MEV 市场与协议费用市场目前处于一种紧张状态,价值在向最高价格拍卖倾斜。如果通过将费用市场分为 MEV 和异常 MEV 去尝试缓解这种紧张状态,正常的费用市场将被走向 SBP 结构,它们能够产生足够的可访问 MEV 来使软件开发变得有价值,异常费用市场可能会看到一个独特的 MEV 供应链。

以太坊MEV:解读最新趋势,展望下一个五年

来源链接

争论的死灰复燃

我们曾经就 MEV 在道德或法律上是否属于盗窃进行了精彩的辩论。牛市时大家都在忙于 MEV 获取,很多事情都被市场的热度掩饰下来了。目前链上金融活动已经有所缓和,我预计将看到对 MEV 获取的「道德回归」。推特上也将重新播放一些旧剧集,粉丝们也将就谁应得到 MEV 展开一些激烈的辩论。但是搜索者不会在意,MEV 获取将继续。

MEV-Aware 硬分叉

MEV 费用市场将转向第一价格拍卖。核心开发人员已经在协议设计方面考虑了 MEV。从我与几个生态系统的互动来看,核心开发人员倾向于两个阵营。

核心开发者的第一阵营设计了提高 MEV 获取成本的机制。这些看起来像批量拍卖、阈值加密、预先共识等。他们希望这些机制可以使 MEV 的提取成本变高。如果提取需要在面临潜在惩罚的情况下与验证者勾结,它可能根本无法完成。然而这些机制增加了用户交互和协议激励的成本和复杂性。目前具体机制设计尚未达成广泛共识。

另一组协议开发人员采用了一种方法,来制定优雅的机制和建设更文明的区块链,并专注于价值流逝最小化、缓解 MEV 对协议本身的影响和保障参与者的公平分配。也就是这三个问题:首先如何最大限度地减少 MEV 对协议用户的影响?第二,如何减轻 MEV 对协议本身的影响?第三,你如何确保协议获得 MEV 的公平分配?

以 EIP-1559 为例,虽然它不是明确的 MEV EIP,但它考虑了这三个问题。EIP-1559 通过允许区块空间扩展和用户费用随基本费用浮动,最大限度地减少了费用激增对用户的影响。它通过调节区块容量、GAS 使用量和基本费用之间的关系,减轻了费用飙升对协议的影响。最后,它通过增加基本费用比例参与价值获取。

以太坊MEV:解读最新趋势,展望下一个五年

来源链接

像 EIP-1559 这样复杂的机制很难被广泛使用,它们并不是真正合适的解决方案。我认为开发者会追随 EIP-1559 的脚步,以降低提议者的佣金为目标。MEV 的影子费用市场有利于提议者和 MEV 构建者,而损害了所有其他用户。与 EIP-1559 之前的费用一样,MEV 区块生产和包容动态创造了一个根本上不公平的市场。为此,我希望我们能看到一个类似 1559 的机制专门针对改善构建者和提议者之间的关系。

不管是提议者还是无用的投机者,他们的收入应该被扼杀,我对未来的预测非常简单:在未来 5 年内,我们将在不同的生态系统中看到多个硬分叉,这些硬分叉明确针对特定链的 MEV 市场。它们可以针对 MEV 提取成本或 MEV 利润分成。理想情况下,我们将看到 MEV 供应链与 L1 的紧密集成。

垂直整合

关于提议者、构建者和搜索者之间的垂直整合市场上已经产生了很多争论。基本思想是提议者可能会保留一名内部构建者,以获取构建者收入,或者构建者可能会优先考虑特定的搜索者。垂直整合可能会挤压较小的业务,并导致由少数主要构建者主导的市场。

我认为这种恐惧有点言过其实。协议随机选择提议者,搜索和构建市场会竞争激烈。提议者(在市场上拥有所有权力)之间的横向合作似乎更令人担忧。提议者之间的价格固定安排可以通过利益相关者激活的软分叉来执行。协议可能必须成为提议者信任破坏者,以防止有害的 PBS 市场影响用户体验。更糟糕的是只要串通的提议者有相邻的插槽就可以提取多块 MEV,这可能会对区块链的最终确定产生不稳定的影响。

垂直整合在特殊情况下肯定会发生。一定量的 MEV 是由 bundles 之间的相互作用产生的。构建者有权访问此交叉 bundles MEV,并且可能会集成一个内部专门的搜索者。可能还存在其他特殊情况让搜索者、构建者和提议者之间更紧密、更可信的关系在经济上变得可行的。

MEV-Aware 应用程序设计

这就像是作弊,因为它已经开始发生了。例如CowSwap团队已经在推出 MEV-Aware 应用程序了。MEV 最小化将在一段时间内成为讨论的重心,因为我们需要作出权衡。这里的研究是由单一的核心问题驱动的:为了去除 MEV,我们必须放弃什么?

虽然协议的设计空间非常有限,实际上也很难达成共识协议。但应用程序有大量选项可以实现 MEV 最小化。有效的方法要取决于应用程序,我们将看到不适用于借贷协议的 DEX 最小化机制(如批量处理)。新的研究将推动每个 dApp 垂直领域的一些变化。然而,新的 MEV 最小化模型需要与现有应用程序的势头相抗衡。目前还不确定哪些 dApp 会看到用户广泛采用抗 MEV 设计,哪些 dApp 会接受当前水平的 MEV 生成。

然而,我们不会止步于设计协议来最小化 MEV。相反,MEV 将成为应用程序设计中的一种工具,应用程序设计人员将选择何时以及如何生成 MEV。我们将提出独特的框架来决定何时可以接受 MEV,以及一套用于调整系统产生的 MEV 数量的标准技巧。

显式 MEV

MEV-Aware 应用程序设计的必然扩展是 co-opting MEV,并将其用作工具。出乎所有人意料的是 MEV 供应链提供了正常交易无法访问的保证,即 MEV 交易永远不会恢复,构建者不会在无利可图的链上浪费区块空间。MEV 交易确认更快,搜索者将该 MEV 转换为影子费用,从而赋予交易更高的优先级。应用程序将开始有意使用 MEV 来访问这些功能,我称之为「显式 MEV 」。

显式 MEV 能够赋予应用程序一定的超能力。它允许用户选择放弃 EIP- 1559 小费,并且仍然可以快速确认他们的交易。应用程序可以有意释放 MEV 机会,并将其与关键系统操作相结合。例如,我们可以将 0.1 ETH MEV 添加到 oracle 更新中。这个 MEV 机会在搜索者之间创造了一场竞赛,第一个确认交易的搜索者获得该 MEV。在 PBS MEV 之前,这将导致优先 Gas 拍卖,这对参与的搜索者来说可能是非常昂贵的。然而,现代 MEV 供应链消除了输掉这场比赛的成本,搜索者知道恢复交易将被构建者删除。

MEV-aware 设计的逻辑结论是 MEV-inclusive 设计。应用程序将显式创建 MEV,他们会将 MEV 融入他们的设计中,并用它来购买区块空间市场中的特权位置。显式 MEV 交易将有效地取代高价值用例的标准交易。

MevWeth

显式 MEV 需要两件事:

首先需要创建标准。为了避免昂贵的 Gas,所有显式 MEV 都应该使用相同的链上状态,无论创建它的合约是什么。这使得 MEV 可以在许多交易中建立联系,而不会大幅增加复杂性。搜索者需要一种简单的方法来了解应用程序是否正在创建显式 MEV。搜索者应该能够寻找特定的、可预测的状态变化。他们不必扫描大量合约来检测显式 MEV。如果每个合约都管理自己的显式 MEV,则搜索者无法在不进行大量状态查找和更改的情况下获取它。一个单一特定的合约应该能够管理显式 MEV。

第二,单独的会计制度,显式 MEV 应以 ETH 计价。因为搜索者承担了 Gas 价格风险,所以他们的付款应该在 Gas 资产中,这样就极大地简化了一切。然而这对产生显式 MEV 的合约提出了新的要求:合约必须跟踪他们可以在 MEV 上花费多少 ETH。DEX 如果不小心将用户 ETH 花在显式 MEV 上将是灾难性的。因此任何使用显式 MEV 和 ETH 的合约都必须保持 MEV-able ETH 和非 MEV-able ETH 的平衡。

所以我们需要一个创建 MEV 的标准以及一个 MEV 的会计系统。非常清晰、明显、直观的解决方案结合了这些需求,我们可以轻松构建一个系统来跟踪 MEV-able ETH 的用户余额。我们确切地知道如何构建接受 ETH 并为用户持有的合约,并实现跟踪和管理显式 MEV 功能也是轻而易举的。

我们可以称之为「MEV Wrapped ETH」或 MevWeth。

该代码可能看起来像是带有显式 MEV 管理接口的 WETH10 的扩展,它可能托管在 github 上,并且可能已经部署在主网上。

MevWeth 是一个 ERC20,它为以下方面提供了一个标准:

  • 通过 addMev() 系列函数创建 MEV
  • 通过 getMev() 系列检索 MEV
  • 通过 Mevitize.sol 基础合约将显式 MEV 创建添加到合约

 

负 MEV

显式 MEV 不能与创建它的交易分开。显式 MEV 在交易中加入隐式 MEV。它们一起被用来补贴更快的确认(以及现代 MEV 供应链的所有其他好处)。然而,某些类别交易已经有很多 MEV。清算、DEX 交易等已经产生足够的 MEV 以获得优先确认,而无需任何明确的价值创造。将任何显式 MEV 添加到总体中都会为访问 MEV 供应链支付过高的费用。

无论如何,这些交易成本过于高昂。Uniswap 用户不会坐下来计算他们交易的 MEV 创建范围,他们不会将其与「优先费用市场清算 MEV」的某些概念进行比较。还没有人将 MEV 视为优先费用,即使他们这样做了,也没有有效的方法让他们收回该价值。而负 MEV 可以改变这一切。

负 MEV 是低于零的显式 MEV。具有负 MEV 的链上操作需要通过 MevWeth 支付 MEV。如果没有事先付款,则操作无法完成。了解 MEV 供应链中现有的权力关系非常重要,用户和应用程序创造了被提取的价值,但尚未参与提取供应链。提议者向其他供应链参与者收取租金,负 MEV 是承认提议者最终无法控制此过程,而提议者依赖于用户和应用程序创造的价值。

通过指定负 MEV,用户或协议可以重新捕获由有价值操作创建的 MEV。我们可以从提议者手中夺取 MEV,并将其还给创造该价值的人。负 MEV 提供了一种简单直接的方式来在 MEV 供应链中发挥作用。使用负 MEV,用户成为价值提取过程的参与者,而不是它的目标。

例如,Uniswap 用户可能会通过缩小交易的滑点范围来抵御 MEV。然而,这通常会使交易变得更糟或不太可能完成。负 MEV 提供了一种带外方式,可以在不改变交易本身的情况下改善交易结果。用户可以在交易中附加少量的负 MEV,而不是缩小滑点范围。这通过与搜索者的交互有效地提供了费用回扣。用户得到更好的结果。交易本身不受影响。交易与支付给用户的原子耦合允许用户明确分享最终由用户创造的价值。

负 MEV 将改变协议如何控制对清算等高 MEV 流程的访问,也将改变用户执行 DEX 交易等高 MEV 操作的方式。

MevWallet

MevWallet是一种智能合约钱包,允许用户将显式 MEV 附加到交易中。它遵循非常标准的 EIP-712 元交易标准,并允许用户指定提示他们的交易。一旦交易被签署,任何人都可以广播它。MevWallet 将验证交易细节并执行一些基本条件,然后执行交易。与任何智能合约钱包一样,交易从钱包执行,而不是从任何 EOA。msg.sender 是钱包,tx.origin 是搜索器。

交易执行后,MevWallet 计算 Gas 使用量并添加小费,如果结果是肯定的,它会补偿 MevWeth 中的搜索者。如果结果是否定的,它会从 MevWeth 中检索一些存储的 MEV。你可以支付负交易费,如果交易产生足够的 MEV 来完全抵消执行,用户可以获得报酬。通过要求对他们生产的 MEV 进行补偿,用户可以重新获得他们原本会通过 MEV 供应链放弃给区块提议者的价值。

MevWallet 交易支持时间锁和截止日期,以及基于随机数的重复支付保护。这种组合允许基于时间的复杂费用调整。例如随着时间的推移,一笔交易可能会产生更多的显式 MEV,直到它被确认。这将在搜索者之间创建荷兰式拍卖,确保交易以市场上可用的最低价格得到确认。许多其他有趣的费用将自动扶梯模型可以在没有链上开销的情况下实现。因为费用拍卖发生在搜索者之间,并且回滚交易确认,所以无论 Gas 拍卖变得多么复杂,用户和搜索者都不会承担额外的 Gas 成本。

MevWallet 在TypeScript和Rust中有代码库,可以通过最小代理工厂部署新的 MevWallets 。该代码已获得许可并可在 GitHub 上获取。MevWallet 目前缺少的主要是一种让搜索者看到交易的方法。我仍然在寻找最好的方法来做到这一点。我考虑过一个简单的 CRUD API 和一个专门的内存池,但我不确定这是一个长期可行的解决方案。

MEV 的未来五年

我期待并希望 MEV 的未来五年与第一年一样令人惊讶。随着 MEV 研究走出青春期并进入成熟期,我们应该欢迎它将出现在我们的应用程序设计。我们应该寻找它的优势,并让它为我们的应用程序和协议做出贡献。MEV 不是盗窃,也不是要打败的敌人,它是我们实践过程中不可或缺的一部分。

MEV 的故事现在属于利润空间,这使得它可以预测。利润率孕育稳定性和可靠性,通过市场规范赚的钱越多,规范的粘性就越大。未来五年的故事将巩固现有的、稳定的供应链,并利用它来构建以前不存在的系统。