探索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 餵價說明:

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

圖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 秒之內:

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

圖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),相信尚會進一步催化成長。

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

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

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

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

圖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 來進行競價。此中繼器負責收集來自預言機的元交易、整理和聚合搜尋者的出價,並以無信任方式重新分配收益,而無需控制出價。當搜尋者得標時,更新資料來源只能依靠將出價金額轉移到協議擁有的代理合約,然後代理合約合約用中繼器提供的簽章資料更新價格來源。

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

圖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 提取價格。最後,驗證器合約用於驗證鏈下簽章是否正確。

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

圖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 費用成比例),經過集思廣益,我們再擬出了另一種訂單結算模式,稱之為積極結算,這種模式有可能降低用戶的成本,同時維護去中心化以及協議的安全性。顧名思義,這種機制允許交易者以Atom方式執行市場交易,系統會積極地接受所有價格,並為搜尋者提供一個窗口,讓他們提交證據,證明惡意下達的訂單。本節概述了這構思的不同版本、我們的思考過程以及仍未解決的問題。

我們最初的想法是建立一種機制,讓用戶在開立市場訂單時透過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(11月14日)

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

3.Synthetix 上的 Frontrunning: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 清算資料 https://dune.com/queries/3247324

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

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 價格來源就會更新。

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

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

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

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

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

上圖描述了Pyth 餵食價格的架構: 當需要更新鏈上價格時,用戶可以透過Pyth API 請求更新,Pythnet 上經過驗證的價格會被發送到Wormhole 合約,Wormhole 合約會觀察並創建和發送一個處名的VAA,該VAA 可以在任何部署了Pyth 合約的區塊鏈上進行驗證。



Total
0
Shares
Related Posts