探索DeFi協議預言機實施的設計空間和挑战

2024-02-02 19:02:14

原文作者：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 秒之內：

圖 2 ：使用 Pyth 的搶先交易示例流程

一個直觀的想法是簡單地降低期效檢查閾值，但較低的閾值可能會導致無法預測區塊時間的網絡回復，從而影響用戶體驗。由於 Pyth 的喂價依賴於橋接，因此需要足夠的緩衝來 a) 為蟲洞守護者（Wormhole guardians）提供證明價格的時間，b) 允許目標鏈處理交易並將其納入區塊。下一節將詳細介紹這些權衡。

平倉

平倉是任何涉及槓杆的協議的核心部分，而喂價更新的粒度，於決定平倉效率舉足輕重。

以基於閾值的推送式預言機來說，當現貨價格達到閾值但不符合預言機喂價預設的參數時，價格更新的粒度（或粒度不足）會導致錯失平倉機會。這以市場低效率的形式帶來了負外部效應。

當平倉發生，應用程序通常會支付部分平倉抵押品，有時還會向發動平倉的用戶提供獎勵。例如， 2002 年 Aave 僅在主網上就支付了 3, 790 萬美元的平倉獎勵 7 。這明顯過度補償了第三方，並且為用戶帶來不佳的操作。此外，當存在可提取價值時，隨之出現的 Gas Wars (Gas 競拍行為)會導致價值從應用程序中流失，從而流向 MEV 供應鏈。

設計空間和考量

考慮到上述問題，下文將討論基於推送式、拉取式和替代設計的各種實施方案，各自於解決上述問題的有效性及當中的取舍；取舍的形式可以是附加的中心化和信任前設，又或是不佳的用戶體驗。

預言機專用的訂單流競價（Order Flow Auctions，OFA）

訂單流競價 OFA 已成為消除 MEV 產生的負外部效應一種解決方案。廣義上，OFA 是一種通用的第三方競價服務，用戶可以向其發送訂單（交易或意圖），而提取 MEV 的搜索者則可以競價獲得對其訂單運行策略的獨家權利。很大部分的競價收益會退還給用戶，以補償他們在這些訂單中創造的價值。近來 OFA 的採用率激增，超過 10% 以太坊交易都於私人渠道（私人 RPC/OFAs）進行（圖 3），相信尚會進一步催化增長。

圖 3 ：合並後的每日私人以太坊交易數量。來源：Blocknative

在預言機更新中，實施通用 OFA 的問題在於預言機無法了解基於標准規則的更新，是否會產生任何 OEV，如果不會，則會在預言機向競價中發送交易時帶來額外延遲。另一方面，精簡 OEV，和將延遲減至最低的最簡單方法是將所有預言機訂單流提供予單一主導搜索者。但這顯然會帶來極大集中化風險，可能會助長尋租行為以及審查，並導致低用戶體驗。

圖 4 ：一般 OFA 與預言機專用的 OFA

不包含現有基於規則更新的預言機專用 OFA 的價格更新仍於公共內存池進行。這讓預言機的價格更新，以及隨之產生的任何可提取價值，都得以保留在應用層中。作為副產品，它還允許搜索者請求數據源更新，而無需預言機節點承擔更頻繁更新的額外成本，從而提高了數據的粒度。

預言機專用 OFA 是平倉的理想選擇，因為它能帶來更細粒度的價格更新，最大限度地將資本返還給被平倉的借款人，減少支付給平倉人的協議獎勵，並在協議中保留從投標人處提取的價值，以便重新分配給用戶。它們還在一定程度上 - 盡管並不完全- 解決了搶先交易和套利問題。在完全競爭（perfect competition）和首價密封投標競價(first price sealed bid auction)流程下，競價的結果，應是接近執行機會 8 的區塊空間成本、由搶先交易 OEV 數據饋送中，所提取的價值，以及因喂價更新的價格粒度增加，而減少所產生的套利機會。

目前，要實施預言機專用的 OFA，要么需要加入第三方競價服務（如 OEV-Share），又或構建一個競價服務作為應用程序的一部分。受 Flashbots 的啓發，API 3 利用 OEV 中繼器(OEV relay) （圖 5）作為於設計上執行 DoS 保護服務的 API 來進行競價。該中繼器負責收集來自預言機的元交易、整理和聚合搜索者的出價，並以無信任方式重新分配收益，而無需控制出價。當搜索者中標時，更新數據源只能依靠將出價金額轉移到協議擁有的代理合約，然後代理合約會用中繼器提供的籤名數據更新價格源。

圖 5 ：API 3 的 OEV 中繼器

另外，協議也可以放棄中間人，建立自己的競價服務，獲取從 OEV 的所有提取價值。BBOX 就是一個即將推出的協議，它希望將競價嵌入其平倉機制，以獲取 OEV，並將其返還給應用程序及其用戶 9 。

運行中央節點或 Keeper

源於第一波永續合約去中心化交易所打擊 OEV 的一個早期想法，是運行一個集中式 Keeper 網絡(守門人網絡)，聚合從第三方來源（如中心化交易所）收到的價格，然後利用類似 Chainlink 的數據饋送作為應變方案或斷路器。這種模式在 GMX v1 10 及其後續的許多分叉中都得到了推廣，其主要價值主張在於，由於 Keeper 網絡由單一運營商運行，因此可以絕對防止搶先交易。

雖然這解決了上述許多問題，但明顯地有中心化顧慮。中心化的 Keeper 系統，可以於未適當驗證定價來源和聚合方法之下決定執行價格。在 GMX v1 的案例中，Keeper 並不是一個鏈上或透明的機制，而是於中心化服務器上運行團隊地址籤署的程序。 Keeper 的核心作用不僅是執行訂單，而且是根據自己的預設定義 "決定 "交易價格，無法驗證所使用的執行價格的真實性或來源。

自動化的 Keeper 網絡和 Chainlink 數據流

解決上述由單一操作員的 Keeper 網絡所帶來的中心化風險，是利用第三方服務提供商建立一個更加去中心化的自動化網絡。 Chainlink Automation 就是這樣一個產品，它與 Chainlink Data Streams - 即是一個全新的拉取式、低延遲預言機 - 共同提供這項服務。該產品最近剛剛發布，目前還處於閉門測試階段，但 GMX v2 11 目前已經在使用該產品，它可以作為採用這種設計的系統的參考。

從高層次來看，Chainlink 數據流由三個主要部分組成：數據 DON（去中心化的預言機網絡）、自動化 DON 和鏈上驗證合約 12 。數據 DON 是一個鏈下數據網絡，其架構類似於 Pythnet 維護和聚合數據的架構。自動化 DON 是由數據 DON 的相同節點操作員保護的守護者網絡，用於從鏈上數據 DON 提取價格。最後，驗證器合約用於驗證鏈下籤名是否正確。

圖 6 ：Chainlink 數據流架構

上圖展示了調用开放交易功能的交易流程，其中自動化 DON 負責從數據 DON 獲取價格並更新鏈上存儲。目前，直接查詢數據 DON 的端點僅限於白名單用戶，因此協議可以選擇將 Keeper 維護工作卸載給自動化 DON(Automation DON)，或運行自己的 Keeper。但隨着產品开發生命周期的推移，預計這將逐步轉變為無權限結構。

在安全層面上，依賴自動化 DON 的信任假設，與單獨使用數據 DON 的信任假設相同，這是對單一 Keeper 設計的重大改進。不過，如果將喂價更新權交給自動化 DON，那么價值提取的機會就只能留給 Keeper 網絡中的節點。這反過來又意味着，該協議將信任鏈克節點運營商（主要是機構）維護其社會聲譽，不搶先用戶進行操作，這類似於信任 Lido Node 節點運營商因要維護其聲譽，不會因其市場份額大，而壟斷區塊空間

拉取式：延遲結算

Synthetix perps v2 中最大的變化之一，是為永續合約結算 13 引入了 Pyth 喂價。這使得訂單可以以 Chainlink 或 Pyth 價格結算，前提是它們的偏差不超過預定義的閾值，並且時間戳通過了期效檢查。然而，如上所述，僅僅改用基於拉取式預言機並不能解決所有協議的 OEV 相關問題。要解決搶先交易，可以延遲訂單的形式引入 "最後查看 "定價機制，在實踐中，這將用戶的市場訂單分為兩個部分：

1. 交易 #1 ：在鏈上提交开立市場訂單的 "意向"，並提供標准訂單參數，如大小、槓杆、抵押品和滑點容忍度。同時還需支付額外的 Keeper 費用，用於獎勵 Keeper 執行交易 #2 。

2. 交易 #2 ：Keeper 接收在交易 #1 中提交的訂單，要求最新的 Pyth 喂價，並在一次交易中調用 Synthetix 執行合約。合約會檢查預定義的參數，如時效和滑價，如果都通過，訂單就會被執行，鏈上價格存儲會被更新，倉位將建立。 Keeper 收取費用，補償使用和維護網絡的所用到的 gas。

這種實施方式不會讓用戶有機會逆向選擇在鏈上提交的價格，從而有效地解決了協議的搶先交易和套利機會。不過，這種設計的折衷就是用戶體驗：執行這個市場訂單需要兩個交易過程，用戶需要為 Keeper 的操作補償 gas，同時分擔更新預言機鏈上存儲的的成本。之前是 2 sUSD 的固定費用，最近則改為基於 Optimism gas oracle + 溢價的動態費用，溢價將根據二層網絡（layer 2）活動而變化。無論如何，這可視為犧牲交易者的用戶體驗以提高 LP 盈利能力的一種解決方案。

拉取式：積極結算 (Optimistic settlement)

由於延遲訂單會給用戶帶來額外的網絡費用（和二層網絡的 DA 費用成比例），經過集思廣益，我們再擬出了另一種訂單結算模式，稱之為"積極結算"，這種模式有可能降低用戶的成本，同時維護去中心化以及協議的安全性。顧名思義，這種機制允許交易者以原子方式執行市場交易，系統會積極地接受所有價格，並為搜索者提供一個窗口，讓他們提交證據，證明惡意下達的訂單。本節概述了這構思的不同版本、我們的思考過程以及仍未解決的問題。

我們最初的想法是建立一種機制，讓用戶在开立市場訂單時通過 parsePriceFeedUpdates 提交價格，然後允許用戶或任何第三方使用喂價數據提交結算交易，並在交易確認時以該價格完成交易。結算時，兩個價格之間的任何負差都將作為滑點計入用戶的損益表。這種方法的優點包括減輕用戶的成本負擔，和降低搶先交易的風險。用戶不必再負擔獎勵守們人的溢價，而且由於在提交訂單時不知道結算價格，搶先交易的風險仍可控。不過，這仍引入了兩步的結算流程，而這正是我們在 Synthetix 的延遲結算模式中發現的缺點之一。在大多數情況下，如果下單和結算期間的波動性，不超過系統界定的可盈利搶先交易閾值，那額外的結算交易可能就是多余的。

規避上述問題的另一種解決方案是，允許系統積極地接受訂單，然後开放一個無權限的質疑期，在該期間可以提交證據，證明價格時間戳和區塊時間戳之間的價格偏差允許進行有利可圖搶先交易。

具體操作如下：

1. 用戶根據當前市場價格創建訂單。然後，他們連同嵌入的 pyth 喂價字節數據傳送價格﹐作為訂單創建交易。

2. 智能合約會主動驗證並存儲這些信息。

3. 在鏈上確認訂單後，會有一個質疑期，搜索者可以提交逆向選擇證明。該證明將證實交易者使用了過時的喂價數據，意圖在系統中套利。如果系統接受了證明，差值將作為滑點應用到交易者的執行價格中，多余的價值將作為獎勵給予 Keeper。

4. 質疑期結束後，系統認為所有價格均有效。

這種模式有兩個優點：減輕了用戶的成本負擔，用戶只需在同一筆交易中為訂單創建和預言機更新支付 gas 費用，而不需要額外的結算交易。它還能阻止搶先交易，保護流動池的完整性，確保有一個健康的 Keeper 網絡，有經濟獎勵措施向系統提交證明，證明其搶先。

然而，在將這一想法付諸實踐之前，還有一些問題有待解決：

● 定義 "逆向選擇"：系統如何區分因網絡延遲而提交過期價格的用戶，以及故意套利的用戶？一個初步的想法可以是，測量期效檢查時段（例如 15 秒）內的波動性，如果波動性超過淨執行費，該訂單就會被標記為一個潛在利用。

● 設置適當的質疑期：考慮到有毒訂單流可能只开放很短的時間，什么是適當的時間窗口供 Keeper 質疑價格？批量證明可能會更符合成本效益，但鑑於訂單流在一段時間內的不可預測性，很難確定批量證明的時間，以確保所有價格信息都得到證明或有充足的時間受到質疑。

● 對 Keeper 的經濟獎勵：要使提交證明對受到經濟激勵的保存者來說是合理的，提交獲勝證明的相關獎勵必須大於提交證明的相關 gas 成本。由於訂單規模不同，這一假設可能無法保證。

● 是否需要為關閉訂單建立類似的機制？如果要的話，會怎樣降低了用戶體驗？

● 確保 “不合理” 的滑點不會落到用戶身上：在閃崩情況下，訂單創建和鏈上確認之間可能會出現非常大的價格差異。可能需要某種後備或斷路器，可以考慮使用 Pyth 的 EMA 價格，以確保使用前的喂價穩定性。

ZK 輔助處理器（ZK Co-processors）- 另一種形式的數據消耗

另一個值得探索的方向是使用 ZK 輔助處理器，這種輔助處理器旨在獲取鏈上狀態以於鏈下進行復雜計算，並與此同時提供計算執行方式的證明；這種方式可無權限地驗證。 Axiom 等項目使合約能夠查詢歷史區塊鏈數據，在鏈下執行計算，並提交 ZK 證明，證明計算結果是根據有效的鏈上數據正確計算得出的。輔助處理器开啓了一種可能性，利用多個 DeFi 原生流動性來源（如 Uniswap + Curve）的歷史價格構建具有操縱彈性的自定義 TWAP 預言機。

與目前只能獲得最新資產價格數據的傳統預言機相比，ZK 輔助處理器將擴大以安全方式提供給 dApp 的數據範圍（Pyth 確實提供了 EMA 價格，供开發人員用作最新價格的參考檢查）。這樣，應用程序就可以引入更多與歷史區塊鏈數據協同工作的業務邏輯，以提高協議安全性或增強用戶體驗。

不過，ZK 輔助處理器仍處於开發初期，當中仍存在一些瓶頸，例如：

● 在輔助處理器環境下，大量區塊鏈數據的獲取和計算可能需要較長的證明時間

● 僅提供區塊鏈數據，無法解決與非 Web3 應用程序安全通信的需求

無預言機解決方案 – DeFi 的未來？

解決這一問題的另一種思路是，通過從頭开始設計一個基元，消除對外部喂價的需求，從而

解決 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）的寶貴意見、反饋和審查。

1. https://defillama.com/oracles ( 14 Nov)

2. OEV Litepaper https://drive.google.com/file/d/ 1 wuSWSI 8 WY 9 ChChu 2 hvRgByJSyQlv_ 8 SO /edit

3.Frontrunning on Synthetix: A History by Kain Warwick https://blog.synthetix.io/frontrunning-synthetix-a-history/

4. https://snapshot.org/#/rook.eth/proposal/0x523ea386c3e42c71e18e1f4a143533201083655dc04e6f1a99f1f0b340523c58

5. https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand

6. https://docs.pyth.network/documentation/solana-price-feeds/best-practices#latency

7.Aave liquidation figures https://dune.com/queries/3247324

8. https://drive.google.com/file/d/ 1 wuSWSI 8 WY 9 ChChu 2 hvRgByJSyQlv_ 8 SO /edit

9. https://twitter.com/bboexchange/status/1726801832784318563

10. https://gmx-io.notion.site/gmx-io/GMX-Technical-Overview-47fc5ed832e243afb9e97e8a4a036353

11. https://gmxio.substack.com/p/gmx-v2-powered-by-chainlink-data

12. https://docs.chain.link/data-streams

13. https://sips.synthetix.io/sips/sip-281/

附錄

定義：推送式與拉取式預言機

推送式預言機器於在 P2P 網絡中維持鏈下價格，以及維持根據預先定義的鏈上節點更新價格。以 Chainlink 為例，價格更新基於兩個觸發參數：偏離閾值（偏差閾值）和心跳（心跳）。只要鏈下價格偏離最新鏈上價格 0.5% ，或者心跳計時器 1 小時計時為零，下面的以太坊 ETH/USD 價格源就會更新。

在這種情況下，預言機運營商必須為每次價格更新支付交易費用，也是於成本和可擴展性之間的取舍。增加價格源的數量，支持額外的區塊鏈，或者增加更頻繁的更新，都會產生額外的交易成本。因此，具有更高觸發參數的長尾資產，無可避免地具有可靠度低的價格源。下面以 CRV/USD 為例說明這一點- 為了使新的價格能夠在鏈上更新，需要 1% 的偏離閾值，心跳為 24 小時，這意味着如果價格在 24 小時內未偏離超過 1 ％，那么每 24 小時只會有一個新的價格更新。直觀而言，長尾資產的價格源缺乏細致度，將不可避免地導致應用程序在為這些資產創建市場時需要考慮額外的風險因素，這解釋了為什么絕大多數 DeFi 活動仍圍繞着流動性最強、最大市值的代幣而發生。

相比之下，拉取式預言機允許按需求將價格拉到鏈上。Pyth 是當今最突出的例子，它在鏈下傳輸價格更新，對每次更新進行籤名，以便任何人都能驗證其真實性，並在 Pythnet 上維護聚合價格，Pythnet 是基於 Solana 代碼的私有區塊鏈。當需要更新時，數據通過 Wormhole 傳輸，在 Pythnet 上進行驗證後，就可以無需權限地拉取到鏈上。