探索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 协议中安全可靠地加入预言机的关键考量。

预言机可提取价值 (OEV)

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

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

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

套利

预言机抢先交易和套利在衍生品协议中被俗称为”毒流”（toxic flow ），因为这些交易是在信息不对称的情况下进行的，往往以牺性流动性提供者的成本获取无风险利润。 Synthetix 等 OG DeFi 协议自 2018 年来一直在应对这一问题，并随着时间的推移尝试了各种解决方案，以减轻这些负面外部性。

让我们以简单的例子说明；永续合约去中心化交易所 xyz 在 ETH/USD 市场上使用 Chainlink 预言机，例子以 ETH/USD 喂价说明 ：

图 1 ：使用 Chainlink 预言机套利示例

虽然上面为过于简化的示例，没有考虑滑点、费用或资金等因素，但它说明了偏差阈值的角色导致价格粒度不足，从中所带来的机会。搜索者可以根据 Chainlink 的链上存储，监控现货市场价格更新的延迟，并从流动性提供者(Liquidity Provider, LP) 提取零风险价值。

抢先交易

抢先交易与套利类似，是另一种价值提取形式，搜索者监控内存池的预言机更新，并在其提交链上之前，抢先运行实际市场价格。这样，搜索者就有时间在预言机更新前出价交易，以有利于自己交易方向的价格成交。

GMX 等这种永续合约去中心化交易所一直都是毒性抢先交易的受害者；于 GMX 所有预言机通过 KeeperDAO 协调协议更新前，约 10% 的协议利润已于抢先交易流失 4 。

如果我们只采用拉取式模型？

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

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

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

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