探索DeFi协议预言机实施的设计空间挑战

原文作者：Adrian Chow

Jonathan Yuen 和 Wintersoldier 贡献

• 预言机（Oracle）于保障 DeFi 协议的锁定价值不可或缺，DeFi 的 500 亿美元总锁仓量当中，有 330 亿由预言机保障。

• 然而，预言机喂价更新时本质上的时间延迟，导致最大可提取价值（MEV, Maximal Extractable Value）一个子类型的价值提取，这被称为预言机可提取价值（OEV, Oracle Extractable Value）； OEV 包括了预言机抢先交易(frontrunning)、套利(arbitrage)和低效平仓(inefficient liquidations)。

• 目前有越来越多的设计实施方案可防止或减轻 OEV 的负面流失，每种设计都有其独特的取舍权衡。本文讨论现有设计的选择及其权衡，以及提出了两个新构思、其价值主张、未决问题以及发展瓶颈。

预言机（Oracle）可说是当今 DeFi 最重要的基础设施之一。它们是大多数 DeFi 协议不可或缺的部分，这些协议依靠喂价来结算衍生品合约、平仓抵押不足的持仓等。目前，预言机保障了 330 亿美元的价值，占链上总锁仓量 500 亿美元的至少三分之二 1 。然而，对于应用程序开发人员来说，加入预言机会带来明显的设计权衡和问题，这源于抢先交易(frontrunning)、套利(arbitrage)和低效平仓(inefficient liquidations)等的价值流失。本文将这种价值流失分类为预言机可提取价值(Oracle Extractable Value, OEV)，从应用程序的角度概述了其关键问题， 并试图在行业研究的基础上，说明在 DeFi 协议中安全可靠地加入预言机的关键考量。

本节假定读者对预言机功能，以及对推送式(push-based)和拉取式(pull-based)预言机的区别有基本了解。个别预言机的喂价可能不同。有关概述、分类和定义，请参阅附录。

大多数使用预言机喂价的应用程序只需要读取价格：运行自己定价模式的去中心化交易所使用预言机喂价作为参考价格；为超额抵押贷款仓位存入抵押品，只需要预言机读取价格，以确定如借款价值比平仓价格等初始参数；撇除长尾资产等定价更新过于不频繁的极端情况，基本上在考虑设计系统时，预言机更新喂价的延迟并不重要。因此，预言机最重要的考量是 - 评估价格贡献者的准确性，以及预言机提供者的去中心化性能。

但如果喂价更新的延迟 是重要考虑因素，则应更为注意预言机如何与应用程序交互。通常在这种情况下，此类延迟会导致价值提取机会，即抢先交易、套利和平仓。这种 MEV 的子类型被称为 OE V2。在讨论各种实施方案及其权衡之前，我们将概述 OEV 的各种形式。

Pyth 的价值主张之一是，使用 Solana 架构的 Pythnet ，发布者可每 300 毫秒 5 向网络推送一次价格更新，从而维持低延迟喂价。因此，当应用程序通过 Pyth 的应用程序接口(API)查询价格时，可以检索最新价格、将其更新到目标链的链上存储、并在一次交易中执行应用程序逻辑中的任何下游操作。

如以上所述，应用程序能够直接查询 Pythnet 的最新价格更新、更新链上存储、并在一次交易中完成所有相关逻辑，这不就有效地解决了抢先交易和套利问题？

也不尽如此 - Pyth 的更新，赋予了用户选择在交易中使用哪些价格的能力，这可能会导致逆向选择（adversarial selection)（毒流的另一种修辞）。虽然链上存储价格必须随时间推移，但用户仍可选择任何满足这些限制条件的价格 - 意味着套利仍然存在，因为它允许搜索者在使用过去的价格之前看到未来的价格。 Pyth 的文档 6 建议，防范这种攻击媒介的一个简单方法是加入期效检查（staleness check），以确保价格够近期- 但是，更新交易数据于下一个区块中必须有一定的缓冲时间，我们该如何确定最佳时间阈值？

让我们以永续合约去中心化交易所 xyz 为例进行分析，而今次他们使用的是 Pyth ETH/USD 喂价，期效检查时间为 20 秒，这意味着 Pyth 价格的时间戳，必须处于执行下游交易的区块时间戳的 20 秒之内：

平仓是任何涉及杠杆的协议的核心部分，而喂价更新的粒度，于决定平仓效率举足轻重。

以基于阈值的推送式预言机来说，当现货价格达到阈值但不符合预言机喂价预设的参数时，价格更新的粒度（或粒度不足）会导致错失平仓机会。这以市场低效率的形式带来了负外部效应。

当平仓发生，应用程序通常会支付部分平仓抵押品，有时还会向发动平仓的用户提供奖励。例如， 2002 年 Aave 仅在主网上就支付了 3, 790 万美元的平仓奖励 7 。这明显过度补偿了第三方，并且为用户带来不佳的操作 。此外，当存在可提取价值时，随之出现的 Gas Wars (Gas 竞拍行为)会导致价值从应用程序中流失，从而流向 MEV 供应链。

不包含现有基于规则更新的预言机专用 OFA 的价格更新仍於公共内存池进行。这让预言机的价格更新，以及随之产生的任何可提取价值，都得以保留在应用层中。作为副产品，它还允许搜索者请求数据源更新，而无需预言机节点承担更频繁更新的额外成本，从而提高了数据的粒度。

预言机专用 OFA 是平仓的理想选择，因为它能带来更细粒度的价格更新，最大限度地将资本返还给被平仓的借款人，减少支付给平仓人的协议奖励，并在协议中保留从投标人处提取的价值，以便重新分配给用户。它们还在一定程度上 - 尽管并不完全- 解决了抢先交易和套利问题。在完全竞争（perfect competition）和首价密封投标竞价(first price sealed bid auction)流程下，竞价的结果，应是接近执行机会 8 的区块空间成本、由抢先交易 OEV 数据馈送中，所提取的价值，以及因喂价更新的价格粒度增加，而减少所产生的套利机会。

目前，要实施预言机专用的 OFA，要么需要加入第三方竞价服务（如 OEV-Share），又或构建一个竞价服务作为应用程序的一部分。受 Flashbots 的启发，API 3 利用 OEV 中继器(OEV relay) （图 5）作为于设计上执行 DoS 保护服务的 API 来进行竞价。该中继器负责收集来自预言机的元交易、整理和聚合搜索者的出价，并以无信任方式重新分配收益，而无需控制出价。当搜索者中标时，更新数据源只能依靠将出价金额转移到协议拥有的代理合约，然后代理合约会用中继器提供的签名数据更新价格源。

源于第一波永续合约去中心化交易所打击 OEV 的一个早期想法，是运行一个集中式 Keeper 网络(守门人网络)，聚合从第三方来源（如中心化交易所）收到的价格，然后利用类似 Chainlink 的数据馈送作为应变方案或断路器。这种模式在 GMX v1 10 及其后续的许多分叉中都得到了推广，其主要价值主张在于，由于 Keeper 网络由单一运营商运行，因此可以绝对防止抢先交易。

虽然这解决了上述许多问题，但明显地有中心化顾虑。中心化的 Keeper 系统，可以于未适当验证定价来源和聚合方法之下决定执行价格。在 GMX v1 的案例中，Keeper 并不是一个链上或透明的机制，而是于中心化服务器上运行团队地址签署的程序。 Keeper 的核心作用不仅是执行订单，而且是根据自己的预设定义 "决定 "交易价格，无法验证所使用的执行价格的真实性或来源。

解决上述由单一操作员的 Keeper 网络所带来的中心化风险，是利用第三方服务提供商建立一个更加去中心化的自动化网络。 Chainlink Automation 就是这样一个产品，它与 Chainlink Data Streams - 即是一个全新的拉取式、低延迟预言机 - 共同提供这项服务。该产品最近刚刚发布，目前还处于闭门测试阶段，但 GMX v2 11 目前已经在使用该产品，它可以作为采用这种设计的系统的参考。

从高层次来看，Chainlink 数据流由三个主要部分组成：数据 DON（去中心化的预言机网络）、自动化 DON 和链上验证合约 12 。数据 DON 是一个链下数据网络，其架构类似于 Pythnet 维护和聚合数据的架构。自动化 DON 是由数据 DON 的相同节点操作员保护的守护者网络，用于从链上数据 DON 提取价格。最后，验证器合约用于验证链下签名是否正确。

上图展示了调用开放交易功能的交易流程，其中自动化 DON 负责从数据 DON 获取价格并更新链上存储。目前，直接查询数据 DON 的端点仅限于白名单用户，因此协议可以选择将 Keeper 维护工作卸载给自动化 DON(Automation DON)，或运行自己的 Keeper。但随着产品开发生命周期的推移，预计这将逐步转变为无权限结构。

在安全层面上，依赖自动化 DON 的信任假设，与单独使用数据 DON 的信任假设相同，这是对单一 Keeper 设计的重大改进。不过，如果将喂价更新权交给自动化 DON，那么价值提取的机会就只能留给 Keeper 网络中的节点。这反过来又意味着，该协议将信任链克节点运营商（主要是机构）维护其社会声誉，不抢先用户进行操作，这类似于信任 Lido Node 节点运营商因要维护其声誉，不会因其市场份额大，而垄断区块空间

这种实施方式不会让用户有机会逆向选择在链上提交的价格，从而有效地解决了协议的抢先交易和套利机会。不过，这种设计的折衷就是用户体验：执行这个市场订单需要两个交易过程，用户需要为 Keeper 的操作补偿 gas，同时分担更新预言机链上存储的的成本。之前是 2 sUSD 的固定费用，最近则改为基于 Optimism gas oracle 溢价的动态费用，溢价将根据二层网络（layer 2）活动而变化。无论如何，这可视为牺牲交易者的用户体验以提高 LP 盈利能力的一种解决方案。

我们最初的想法是建立一种机制，让用户在开立市场订单时通过 parsePriceFeedUpdates 提交价格，然后允许用户或任何第三方使用喂价数据提交结算交易，并在交易确认时以该价格完成交易。结算时，两个价格之间的任何负差都将作为滑点计入用户的损益表。这种方法的优点包括减轻用户的成本负担，和降低抢先交易的风险。用户不必再负担奖励守们人的溢价，而且由于在提交订单时不知道结算价格，抢先交易的风险仍可控。不过，这仍引入了两步的结算流程，而这正是我们在 Synthetix 的延迟结算模式中发现的缺点之一。在大多数情况下，如果下单和结算期间的波动性，不超过系统界定的可盈利抢先交易阈值，那额外的结算交易可能就是多余的。

规避上述问题的另一种解决方案是，允许系统积极地接受订单，然后开放一个无权限的质疑期，在该期间可以提交证据，证明价格时间戳和区块时间戳之间的价格偏差允许进行有利可图抢先交易。

具体操作如下：

这种模式有两个优点：减轻了用户的成本负担，用户只需在同一笔交易中为订单创建和预言机更新支付 gas 费用，而不需要额外的结算交易。它还能阻止抢先交易，保护流動池的完整性，确保有一个健康的 Keeper 网络，有经济奖励措施向系统提交证明，证明其抢先。

然而，在将这一想法付诸实践之前，还有一些问题有待解决：

另一个值得探索的方向是使用 ZK 辅助处理器，这种辅助处理器旨在获取链上状态以于链下进行复杂计算，并与此同时提供计算执行方式的证明；这种方式可无权限地验证。 Axiom 等项目使合约能够查询历史区块链数据，在链下执行计算，并提交 ZK 证明，证明计算结果是根据有效的链上数据正确计算得出的。辅助处理器开启了一种可能性，利用多个 DeFi 原生流动性来源（如 Uniswap Curve）的历史价格构建具有操纵弹性的自定义 TWAP 预言机。

与目前只能获得最新资产价格数据的传统预言机相比，ZK 辅助处理器将扩大以安全方式提供给 dApp 的数据范围（Pyth 确实提供了 EMA 价格，供开发人员用作最新价格的参考检查）。这样，应用程序就可以引入更多与历史区块链数据协同工作的业务逻辑，以提高协议安全性或增强用户体验。

不过，ZK 辅助处理器仍处于开发初期，当中仍存在一些瓶颈，例如：

解决这一问题的另一种思路是，通过从头开始设计一个基元，消除对外部喂价的需求，从而

解决 DeFi 对预言机依赖性。这一领域的最新发展是利用各种 AMM LP 代币作为定价手段，其核心理念是恒定函数做市商的 LP 仓位是代表两种资产预设权重的代币，并有这两种代币的自动定价公式（即 xy=k）。通过利用 LP 代币（作为抵押品、贷款基础，或在最近的使用案例中，将 v3 LP 仓位移动到不同的刻度点），该协议可以获取通常需要从预言机所获取的信息。由此，新一波趋势 - 免于所述挑战的无预言机方案都得以实现。建基于此方向的应用实例包括：

Panoptic 正构建永久、无预言机的期权协议，所利用的是 Uniswap v3 集中流动性仓位。由于当现货价格超过 LP 仓位的上限范围时，集中流动性仓位会 100% 转换成基础资产，因此流动性提供者的回报与认沽期权的卖家回报非常相似。因此，期权市场的运作是流动性提供者存入 LP 资产或仓位，期权买方和卖方借入流动性并将其移入或移出范围，从而产生动态的期权回报。由于贷款是以 LP 仓位计价，因此结算时不需要预言机。

Infinity Pools 正在利用 Uniswap v3 的集中流动性仓位，建立一个无平仓、无预言机的杠杆交易平台。 Uniswap v3 的流动性提供者可以借出他们的 LP 代币，交易者存入一些抵押品，借用 LP 代币并赎回其定向交易的相关资产。赎回时的贷款将以资产基础或报价资产计价，具体取决于赎回时的价格，并可直接通过检查 Uniswap 上的 LP 组成计算，消除了对预言机的依赖。

Timeswap 正在建立一个固定期限、无平仓、无预言机的借贷平台。它是一个由贷方、借方和流动性提供者组成的三方市场。与传统借贷市场不同，它采用的是 "时间基础 " （“time-based”）的清算，而不是"价格基础"（price-based）的平仓。在去中心化交易所，流动性提供者被自动设定为总是向卖方买入，向买方卖出；而在 Timeswap 中，流动性提供者总是向借方贷款，向贷方借款，在市场中扮演类似的角色。他们还负责承担贷款违约责任，并优先获得被没收的抵押品作为补偿。

定价数据仍然是许多去中心化应用的重要部分，而随着时间的推移，预言机所获得的总价值也在不断增加，进一步肯定其产品与市场的契合度(p 产品市场契合度）。本文旨在让读者得悉并概述我们目前面临的 OEV 相关挑战，以及基于推送式、拉取式和使用 AMM 流动性提供者或链下辅助处理器的其他设计，其实施方案中的设计空间。

我们很高兴看到充满活力的开发者期望解决这些棘手的设计难题。如果您也在这领域开展颠覆性的项目，我们很乐意听取您的意见！

参考文献和致谢

感谢 Jonathan Yuen 和 Wintersoldier 的贡献和对谈，为本文贡献良多。

感谢 Erik Lie、Richard Yuen（Hailstone）、Marc、Mario Bernardi、Anirudh Suresh（Pyth）、Ugur Mersin（API 3 DAO）和 Mimi（Timeswap）的宝贵意见、反馈和审查。

?

附录

定义： 推送式与拉取式预言机

推送式预言机器于在 P2P 网络中维持链下价格，以及维持根据预先定义的链上节点更新价格。以 Chainlink 为例，价格更新基于两个触发参数：偏离阈值（偏差阈值）和心跳（心跳）。只要链下价格偏离最新链上价格 0.5% ，或者心跳计时器 1 小时计时为零，下面的以太坊 ETH/USD 价格源就会更新。

在这种情况下，预言机运营商必须为每次价格更新支付交易费用，也是于成本和可扩展性之间的取舍。增加价格源的数量，支持额外的区块链，或者增加更频繁的更新，都会产生额外的交易成本。因此，具有更高触发参数的长尾资产，无可避免地具有可靠度低的价格源。下面以 CRV/USD 为例说明这一点- 为了使新的价格能够在链上更新，需要 1% 的偏离阈值，心跳为 24 小时，这意味着如果价格在 24 小时内未偏离超过 1 ％，那么每 24 小时只会有一个新的价格更新。直观而言，长尾资产的价格源缺乏细致度，将不可避免地导致应用程序在为这些资产创建市场时需要考虑额外的风险因素，这解释了为什么绝大多数 DeFi 活动仍围绕着流动性最强、最大市值的代币而发生。

相比之下，拉取式预言机允许按需求将价格拉到链上。Pyth 是当今最突出的例子，它在链下传输价格更新，对每次更新进行签名，以便任何人都能验证其真实性，并在 Pythnet 上维护聚合价格，Pythnet 是基于 Solana 代码的私有区块链。当需要更新时，数据通过 Wormhole 传输，在 Pythnet 上进行验证后，就可以无需权限地拉取到链上。

上图描述了 Pyth 喂价的架构： 当需要更新链上价格时，用户可以通过 Pyth API 请求更新，Pythnet 上经过验证的价格会被发送到 Wormhole 合约，Wormhole 合约会观察并创建和发送一个处名的 VAA，该 VAA 可以在任何部署了 Pyth 合约的区块链上进行验证。

免责声明：本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况，及遵守所在国家和地区的相关法律法规。