探索 MEV：OEV 解决方案的设计方法与挑战
2024-10-04 20:51
本文大部分素材取自“Exploring the Design Space and Challenges for Oracle Implementations in DeFi Protocols”，在此基础上有大量改动摘要：预言机在 DeFi 生态中一直扮演着不可或缺的角色，由于智能合约只能访问链上数据，无法直接从链外获取信息，需要预言机充当媒介，将链下的数据引入链上，智能合约才能基于链下数据进行自动化交易处理。大多数 DeFi 协议依赖于预言机喂价来处理衍生品合约、清算不良资产等。目前 DeFi 生态内的资金体量超过 800 亿美元，其中大部分与预言机有着某种关联。然而，传统预言机在价格更新方面具有迟滞性，这衍生出了一种预言机专项的 MEV：OEV。OEV 的常见场景包括预言机抢跑交易、套利以及清算获利等，现在有越来越多方案被提出用于减轻 OEV 的负面影响。本文将介绍现有的各种 OEV 解决方案，分别讨论其优劣之处，并提出两种新思路，对它们的价值观、待解决问题与限制因素进行阐述。为了便于大家理解本文的主要内容，我们先对推送式预言机和拉取式预言机进行简要科普。推送式预言机指的是，预言机主动将数据发送到链上智能合约中，如 Chainlink 就以推送式为主；拉取式预言机则由 DApp 主动请求数据，预言机收到请求后再提供数据。这两种模式的差异在于，推送式预言机的数据实效性较强，适用于对实时数据较为敏感的场景，但这种模式下预言机要频繁的向链上提交数据，会消耗更多的 gas。拉取式预言机更灵活，只在 DApp 需要数据时才提供新数据，这样做消耗的 gas 较少，但数据有迟滞性。由于 Defi 平台需要预言机提供喂价数据，如果喂价更新具有迟滞性，则可能被套利机器人捕获 MEV，这种依赖于预言机而形成的 MEV 被称为 OEV。与 OEV 相关的主要获利场景包括抢跑交易、套利和清算等，在接下来的讨论中，我们将概述由 OEV 引发的各种获益场景，并探讨不同的 OEV 解决方案，以及其优劣。根据实践中观测到的结果，OEV 有三种主要实现途径：1. 抢跑交易。比如以太坊网络中的 MEV Searcher 会实时监控待上链的交易数据，寻找 MEV 机会。预言机更新喂价要向链上提交数据，这些数据上链前会堆积在交易池中，Searcher 会监控这些 Pending 交易，预知链上资产即将发生的价格波动，在价格更新前抢先埋伏一些买卖单。很多衍生品平台曾遭受抢跑交易带来的负面影响，比如 GMX 因频繁遭遇抢跑交易，利润减少 10%，直到协议更新，GMX 将接入的预言机交由 KeeperDAO 进行统一调度，OEV 捕获的问题才得以缓解。后面我们会对 GMX 采用的解决方案进行简单解释。2. 套利：利用预言机数据更新的延迟在不同市场间进行无风险套利。举例来说，某链上衍生品平台的资产价格更新有 10 秒延迟，如果币安的 ETH 现货价格突然上涨，而链上的 ETH 价格没有及时变化，套利机器人可以立刻在链上开做多合约，等 Chainlink 喂价更新后再把仓位平掉，以此获利。上面的案例简化了实际情况，但它说明了价格更新延迟会产生的套利机会，套利者可以从 Defi 平台处捕获 OEV，当然这些被捕获的 OEV 最终会导致 LP 的损失（羊毛出在羊身上）。预言机抢跑交易和套利现象，在衍生品协议中通常称为"有害的交易流 (toxic flow)"，因为这些交易背后存在着信息不对称，套利者可以捕获无风险利润，但会损害 Defi 协议中 LP/ 流动性提供者的利益。自 2018 年以来，Synthetix 等老牌 DeFi 协议一直受到此类 OEV 攻击的困扰，并尝试了很多方法以减轻其负面影响。后面我们会对此类应对措施进行简要解释。3. 清算：对于借贷协议而言，如果资产价格更新延迟，对于部分反应快的清算人而言有利可图，捕捉不及时的价格更新导致的低效清算，获取额外收益。这些行为会削弱市场效率，并对 Defi 平台的公平性产生负面影响。清算组件在任何涉及杠杆的 DeFi 协议中都是核心，而喂价更新的粒度在清算效率上起着关键作用。如果推送式预言机是阈值性的，也就是价格变更达到一定幅度才更新喂价，就可能影响到清算过程。假设链下 ETH 价格下跌，某借贷协议上的仓位已达到清算线，但价格波动率不满足预言机更新喂价的阈值，所以预言机没更新数据，此时就会影响到清算工作的执行，这可能进一步引发负面影响。举一个简单的例子，某抵押品头寸由于价格紧急下跌面临清算，但由于预言机更新数据不及时，链上价格还未变动。在这个窗口期，Searcher 提前发送清算交易请求并支付较高的 Gas，获得优先上链打包的优势。当链上价格更新后，Searcher 直接成为清算人并获利，同时由于价格更新的迟滞，原抵押品持有者来不及补仓，遭受了额外损失。通常 DeFi 协议会把部分清算抵押品作为奖励，送给清算人，Aave 等大型 DeFi 协议在 2022 年仅在以太坊上就分发了超过 3800 万美元的清算激励，这不仅过度补偿了第三方清算人，也对用户造成了伤害。此外，gas 战会将 MEV 捕获机会从有 MEV 效应的地方扩散到整个 MEV 供应链上。其中，抢跑攻击和套利行为中捕获的 OEV 会损害 DeFi 流动性提供者的利益；而清算中捕获的 OEV，对于借款人来说，在清算过程中损失相当的资金， 对于贷款人，预言机报价存在延迟导致收到抵押品价值低于预期。总而言之，无论以何种方式捕获的 OEV，都会对市场上其他人造成损失，最后只有 OEV 捕获者自己受益，这对 DeFi 的公平性和 UX 产生了负面影响。下面我们将在前述背景下讨论推送式、拉取式和其他模式的预言机，以及当前市场上存在的，建立于其上的 OEV 解决方案，并分析其有效性，深入探讨这些方案为解决 OEV 问题做出的取舍，包括增加中心化程度或信任假设，或是牺牲 UX 等。前面我们提到过拉取式预言机，它的特征是需要由 Dapp 向预言机主动请求数据。Pyth 作为拉取式预言机的代表，优势之一是可以利用 Solana 架构的高 TPS 与低延时，创建 Pythnet 网络对数据进行收集、聚合和分发。在 Pythnet 上发布者每 300ms 就会更新一次价格信息，有需要的 DApp 可以通过 API 查询最新的数据，将其发布到链上。这里需要说明，发布者每 300ms 更新一次价格信息，这听起来像是推送式预言机的逻辑。但是，Pyth 的逻辑是“推送式更新，拉取式查询”，即尽管数据是通过推送式更新的方式进入 Pythnet，但链上应用或其他区块链网络可以通过 Pyth API 或跨链桥 Wormhole 的消息传递层来“拉取”最新的数据。但只使用拉取式预言机并不能完全解决抢跑和套利，用户仍可以选择满足特定条件的价格进行交易，导致“对手选择”问题。具体到预言机的场景中，由于预言机更新价格存在延迟，Searcher 可以通过监控链上价格更新的时间差，主动选择一个对自己有利的时间节点进行交易，该时间节点的价格往往是过期但未来得及更新的非准确价格。这种行为导致了市场价格的不公平，使得 searcher 能够利用信息不对称获取无风险利润，但损害了其他市场参与者的利益。也就是说，在拉取式预言机中，价格延迟导致的套利攻击仍然存在。在 Pyth 的文档中，提出了通过“staleness check”来防止这种攻击。“Staleness check” 是一种用于确保在交易中使用的数据或价格信息即时性的机制。具体来说，staleness check 会验证所使用的价格数据是否在一个合理的时间窗口内生成，以防止交易者利用过时的价格信息进行交易，从而减少套利和不公平的交易行为。但具体实施中，确定最佳时间阈值是一个很难的事情。我们可以重新看一下之前的例子来理解 staleness check，假设永续合约交易所使用 Pyth 的 ETH/USD 价格源，并设定了 20 秒的 staleness check 阈值，这意味着 Pyth 价格的时间戳与执行下游交易的区块时间戳只能有 20 秒的时间差。如果超出了这个时间范围，价格将被视为过时，无法使用。这种设计旨在防止利用过期价格进行套利。缩短 staleness check 的时间阈值看起来是一个不错的解决方案，但这样可能导致在区块时间不确定的网络上出现交易回滚，从而影响用户体验。Pyth 的价格源依赖跨链桥，仍用 Wormhole 举例，其 Guardian 节点被称为“Wormhole Keeper”，预言机必须有足够的缓冲时间来让 Wormhole Keeper 确认价格，并让目标链处理交易并将其记录在区块中。为应对 MEV 带来的负面影响，一种新的解决方案——预言机专属订单流拍卖（OFA）逐渐兴起，效果十分显著。OFA 是一种通用的第三方拍卖服务，允许预言机将最新的喂价信息盖上签名，发送至链下拍卖平台，由别人代替自己把喂价信息提交到链上。这类更新喂价的操作一旦上链，就会导致 MEV 机会出现，所以 MEV Searcher 会监听预言机提交到拍卖平台的喂价信息，充分利用这里面的机会。Searcher 往往会愿意竞拍，申请代替预言机把喂价消息推送到链上，然后 Searcher 趁此机会构造 MEV 交易，让自己成为从中获利最大者。当然，Searcher 要参与竞拍才行，竞拍过程中他会付出一些资金，这些资金会由拍卖平台分发给预言机或更多人，这就相当于把 MEV 玩家的获利分发一部分给别人，以此缓解 OEV 问题。所有待定交易流都会被路由到一个私有的 OFA 交易池，而不是直接发送到链上。为保证公平，该交易池保持私密，仅供拍卖参与者访问。交易池就是 OFA 进行拍卖的平台，Searcher 在这里参与竞拍，获得执行订单的权利。竞拍的价格基于预期从订单中可提取的价值，包括交易类型、当前 gas 价格和预期的 MEV 利润等因素。胜出的 Searcher 支付竞拍金额，获得交易执行权，他出于利己，会用能提取最大 MEV 的方式安排交易，并将交易提交到链上。该步骤是 OFA 的核心，Searcher 为了获得 MEV 机会，会付出额外的竞拍金额，该笔金额将存入智能合约中，并按照一定比例分配，补偿给协议和用户在 OFA 中损失的价值。从数据来看，OFA 对 MEV 和 OEV 问题的缓解非常显著，此类方案的采用率呈现快速上升的趋势，目前已有超过 10% 的以太坊交易通过私有渠道（包括私有 RPC 和 OFA）来进行。可以预见，OFA 在未来的发展潜力很大。但在实现通用的 OFA 方案时存在一个问题，即预言机无法预见更新是否会产生 OEV，而如果没有产生 OEV，OFA 将引入额外的延迟，因为预言机需要进行额外操作，将交易发送至拍卖平台中。另一方面，优化 OEV 并减少延迟还有一个最简单的办法，就是将所有预言机订单流都交给一个主导的 searcher，但这样做显然会带来显著的中心化风险，变相鼓励租金提取、审查制度，最终使用户的体验被损害。
OFA 通过拍卖价格更新不包括已有的基于规则的更新，后者更新仍然通过公共内存池。这样的机制确保了预言机价格更新，以及随之产生的任何额外收益都能保留在应用层内。与此同时，这种机制也提升了数据的颗粒度，允许 searcher 请求数据源更新，而不必让预言机节点承担更频繁更新的额外成本。OFA 在清算过程中效果尤为理想，因为它能够提供更精细的价格更新，最大化地返还给被被清算的质押者的资本，减少协议支付给清算人的奖励，并剔除竞拍清算人的额外收益以回馈给用户。然而，OFA 虽在一定程度上解决了抢跑交易和套利，但仍留有一些问题尚未解决。在完全竞争和一价密封拍卖的情景下，拍卖应使得从抢跑交易中的额外收益接近于执行本次 MEV 操作所需的区块空间成本，同时，价格更新的颗粒度增加也会减少套利机会的产生。目前，要实现预言机专属的 OFA，可以选择与第三方拍卖服务（如 OEV-Share）集成，或直接将拍卖服务作为 DeFi 应用，让其自行搭建。API3 使用基于 Flashbots 概念的 OEV 中继器作为 API，在进行拍卖时提供 DoS 保护服务。中继器负责收集来自预言机的元交易，筛选并聚合 searcher 的竞标，并在无信任的环境下分配收益。竞标获胜者需将竞标金额转移到协议控制的代理合约，之后中继器提供的签名数据会更新价格源。另一种选择是协议不依赖中介，直接构建属于自己的原生拍卖服务，以捕获并剥离所有从 OEV 中提取的额外收益。BBOX 项目计划将拍卖嵌入其清算机制中，以捕获 OEV 并将其返还给应用和用户。通过这种方式，协议能够更好地进行价值分配，并减少对第三方服务的依赖，进而增强系统的自主性，并提高用户的收益。在 Web3 早期，通过预言机驱动的永续合约交易所为应对 OEV 问题，提出了一种运行中心化 Keeper（专门用于交易的节点或实体）网络的想法，核心思想是从中心化交易所等第三方来源汇总价格，并使用 Chainlink 数据馈送作为备用。这种模式由 GMX v1 推广，并在许多后续分支中得到应用。其主要价值在于通过单一运营者管理的 Keeper 网络，完全防止了抢跑问题。当然，这种方法存在明显的中心化风险。中心化的 Keeper 系统可以决定执行价格，而不进行价格来源的验证。GMX v1 中的 Keeper 并非链上透明机制，而是由其团队地址在中心化服务器上运行的程序，无法验证执行价格的真实性和来源。对于 OEV 的提取，搜索者会通过监控内存池内的“预言机数据更新指令”，通过 MEV 基础设施，将预言机数据的更新交易指令，与自己发起的交易指令捆绑在一起，最终执行以获取收益。当然，对于套利和清算交易，OEV Searcher 只需要监控链上价格与链下价格的偏差，最终通过 MEV 基础设施，确保自己发起的交易先上链执行即可。无论搜索者使用哪种流程，我们可以看到 OEV 的收益被分配给了 MEV 基础设施和 OEV 的搜索者，而“被捕获” OEV 价值的协议，并没有获取其应有的收益。（根据某些数据，OEV 问题此前曾导致 GMX 平台的利润被抽走差不多 10%）为了解决这个问题，贡献了大量 OEV 价值、身为链上衍生品交易平台的 GMX 采用了一种简单的方式：让自己指定的一些人来捕获 OEV 价值，然后把这些 OEV 价值尽可能返还给 GMX 平台。对此，GMX 引入了 Rook 和白名单。简单来说，GMX 的预言机更新通过 Rook 执行，而 Rook 会基于目前的市场情况，进行 OEV 的提取操作以获取市场内的 OEV。这些 OEV 的 80% 会被返换给 GMX 协议。总结下来就是，GMX 通过白名单，赋予 Rook 们更新预言机的权利，通过 Rook 提取 OEV 以避免被其他搜索者提取 OEV，同时将 OEV 的 80% 返还给 GMX 系统。这个套路其实有点简单粗暴。针对上述单一运营商 Keeper 网络所引发的中心化风险，可以引入第三方服务提供商来构建更为去中心化的自动化网络，代表性的产品是 Chainlink Automation。Chainlink Automation 与 Chainlink 的新型拉取式、低延迟预言机服务 Chainlink Data Streams 搭配使用，在 2023 年底宣布进入封闭测试，但其已在 GMX v2 投入了实际应用。我们可以参考 GMX v2 系统的逻辑，探究如何将 Chainlink Data Streams 设计融入到是实际的 DeFi 应用中。从整体来看，Chainlink Data Streams 由三个主要组件构成：数据 DON、自动化 DON 和链上验证合约。数据 DON 是一个链下数据网络，其进行数据维护与聚合的架构类似于 Pythnet。自动化 DON 则是由与数据 DON 相同的节点运营者维护的 Keeper 网络，用于将数据 DON 中的价格拉取至链上。最后，链上验证合约用于确保链下签名的正确性。
上图展示了调用开放交易功能的流程，其中自动化 DON 负责从数据 DON 获取价格并更新链上存储。目前，只有白名单用户有直接查询数据 DON 的权限，因此协议可以选择将维护任务交给自动化 DON 处理，或自行运行 Keeper。然而，产品随着开发周期的推进，预计将逐步转变为无许可结构。在安全层面，依赖自动化 DON 与单独使用数据 DON 的信任假设相同，这相对于单一 Keeper 的设计是非常明显的进步。然而，将价格更新的权利交给自动化 DON，也意味着 OEV 将专属于 Keeper 网络中的节点，这种信任假设类似于以太坊对于 Lido 节点运营商的态度。Lido 的节点运营商往往是具有较大社会声誉的机构，它们占据着以太坊质押市场的较大份额，以太坊利用社会共识的掣肘，防止 Lido 串通为卡特尔，形成垄断效应。去中心化永续合约交易所 Synthetix v2 中引入了 Pyth 价格数据用于结算合约，这是一个非常大的改进。用户的订单可以在 Chainlink 或 Pyth 的价格中二选其一，只要价格偏差未超过预定阈值且时间戳通过 staleness check。然而，单纯改为拉取式预言机并不能解决所有 OEV 的相关问题。为了应对抢跑交易，许多 DeFi 协议引入了“last look”定价机制，这种延迟订单将用户的市场订单分为两个部分：1.用户提交开立市场订单的“intent”到链上，附带订单参数如大小、杠杆、抵押品和滑点容忍度，同时支付额外的 keeper 费用。2.keeper 接收订单，请求最新的 Pyth 价格数据，并在交易中调用 Synthetix 执行合约。合约检查预定义的参数，若全部通过，则订单执行，链上价格存储更新，头寸开启。keeper 领取用户支付的费用以补偿其使用的 gas 费和网络维护成本。这种方式避免了对用户不利的价格被提交到链上，有效地解决了协议中的抢跑和套利问题。然而，这种设计在用户体验上做出了一定取舍：执行此类市场订单需要通过两笔交易完成，用户除了要支付 gas 费外，还要支付更新预言机链上存储的费用。此前，更新预言机链上存储的费用是固定的 2 美元，但最近改为基于 Optimism gas 预言机 + 溢价的动态费用，根据 Layer2 的活跃状况而变化。总之，这种方案在提高流动性提供者利润的同时，牺牲了交易者一定的用户体验。随着延迟订单为用户引入额外的费用，且这些费用与 L2 的 DA 费用成比例增加，有人构思了一种作为替代品的的订单结算模型，称为“乐观结算”，旨在降低用户成本，同时保持去中心化和协议安全性。顾名思义，乐观结算机制允许交易者以原子方式执行市场交易，系统乐观地接受所有价格，并提供一个时间窗口，让 searcher 提交证明以揭示订单是否存在作恶意图。本文将概述这一想法的几个迭代版本、在此过程中展示其思考过程，并简述该思路仍待解决的问题。最初设想的是用户在开启市价单时，通过 parsePriceFeedUpdates 提交价格，然后允许用户或任何第三方提交结算交易，使用价格数据完成交易确认。在结算时，如果两个价格之间存在负向差异，该差异将作为滑点作用于用户的盈亏。这种方法的优势在于降低了用户的成本负担并减轻了抢跑交易的风险。然而，该方法同时也引入了两步结算过程，这是我们在 Synthetix 延迟结算模型中发现的一个缺点。额外的结算交易在大多数情况下可能是多余的，尤其是在下单和结算期间波动不超过系统定义的抢跑阈值时更加显著。另一种规避上述问题的解决方案是允许系统乐观地接受订单，然后开放一个无需许可的挑战期。在此期间，任何人都可以提交证据证明价格时间戳和区块时间戳之间的价格偏差，存在可盈利的抢跑机会。乐观机制通过引入挑战期，有效地减少了系统中潜在的套利行为，并增加了交易过程的透明度和公正性。1. 用户以当前市场价格创建市价订单，并将此价格以及嵌入的 Pyth 价格数据一起作为订单创建交易发送。3. 订单确认上链后，会有一个挑战期，期间 Searcher 可以提交交易者有作恶意图的证明。此证明需包含交易者使用过去价格意图套利的证据。如果系统接受了该证明，价差将作为滑点应用于交易者的执行价格，原本的 OEV 收益将作为奖励给予 Keeper。这种乐观模式有两个优点：首先，它降低了用户的成本负担，用户只需在同一笔交易中支付订单创建和预言机更新的 gas 费，无需额外交易结算费用。其次，它抑制了抢跑交易，并在确保健康的 keeper 网络下，通过经济激励机制来提交系统被抢跑的证明，从而保护了流动性池的完整性。这种思路固然有较大潜力，但若想落地，仍然存在一些需要解决的开放性问题：定义‘对手选择’问题：即系统如何区分因网络延迟提交过期价格的用户与故意利用延迟套利的用户。一种初步思路是在 staleness check 的时间内（如 15 秒）测量波动率，如果波动率超过净执行费用，则该订单可能被标记为潜在套利行为。设置合适的挑战期：考虑到作恶订单流的开放时间可能很短，keeper 应有一个合理的时间窗口来挑战价格。虽然批量验证可能更省 Gas，但订单流的不可预测性导致难以保证所有价格数据都能及时验证或挑战。Keeper 的经济激励：提交验证的 Gas 成本不低，为了保证 Keeper 对系统产生积极的作用，提交验证的奖励必须大于提交成本。然而，订单规模的不同可能使这一假设未必在所有情况下都成立。是否需要为平仓订单建立类似的机制？如果需要的话，可能会对用户体验造成哪些影响？确保用户不受“不合理”滑点的影响：在市场闪崩的情况下，订单创建与链上确认之间可能出现巨大的价格差异，需要某种止损措施或熔断机制。这里我们考虑使用 Pyth 提供的 EMA 价格来确保价格源稳定性。另一个值得探索的方向是 ZK 协处理器的使用。这些处理器旨在链下处理复杂计算，并能够访问链上状态，同时提供证明，确保计算结果可以在无许可的情况下验证。像 Axiom 这样的项目允许合约查询历史区块链数据，在链下执行计算，并提交 ZK 证明，确保结果是基于有效链上数据正确计算的。协处理器使建立一个基于多个 DeFi 原生流动性来源（如 Uniswap+Curve）的抗操纵自定义 TWAP 预言机成为了可能。与传统预言机相比，ZK 协处理器将扩大可安全提供给 dApp 的数据范围。当前传统预言机主要提供最新的资产价格数据（如 Pyth 提供的 EMA 价格）。通过 ZK 协处理器，应用程序可以引入更多基于历史区块链数据的业务逻辑，用以提高协议安全性或增强用户体验。然而，ZK 协处理器仍处于开发的早期阶段，会面临一些瓶颈，例如：仅限于区块链数据，无法解决与非 Web3 应用程序安全通信的需求。一种新的思路认为，DeFi 中的预言机依赖问题，可以通过设计一种从根本上去除外部价格数据需求的原语来解决，近期也出现了利用各种 AMM LP 代币作为定价工具的设计。这基于一个核心理念：在恒定函数做市商中，LP 头寸代表了交易池中两种资产的预设权重，交易遵循一个自动定价公式（如 xy=k）。通过使用 LP 代币，协议能够直接获取通常需要预言机才能提供的信息，从而催生了无需预言机的解决方案。这类方案减轻了 DeFi 协议对预言机的依赖，一些项目正在沿着这一方向构建应用。价格数据仍然是当今许多去中心化应用的核心组件，通过预言机保护的总资产价值还在不断增加，这也进一步证明了预言机在市场中的重要性。本文旨在引起人们对当前预言机额外收益（OEV）所造成相关风险的关注，并探讨了推送式、拉取式以及使用 AMM LPs 或链下协处理器等替代设计方案的实现潜力。
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
