探索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或链下协处理器等替代设计方案的实现潜力。
