KeyFrame內部研究專用

Security Considerations when using Pull Oracles | 0xmonsoon (OpenZeppelin)

DeFi Security Summit - DSS·12月18日週三·22 min英文

三句話摘要

區塊鏈預言機的類型、集成方法與安全考量 拉取預言機雖降低預言機網路成本,但使用者需嚴格驗證時間戳遞增性和價格有效負載,方能避免時間戳混淆、同交易多價格攻擊等風險。 推送預言機的局限:由 Chronicle 和 Chainlink 等網路持續維護價格資料,基於價格偏差(如 5%)或時間間隔(如每小時)更新。安全性最高、集成最簡單,但因需不斷發送鏈上交易,成本高昂且難以支持多條鏈上的大量交易對。

重點整理

重點
  • 1

    推送預言機的局限:由 Chronicle 和 Chainlink 等網路持續維護價格資料,基於價格偏差(如 5%)或時間間隔(如每小時)更新。安全性最高、集成最簡單,但因需不斷發送鏈上交易,成本高昂且難以支持多條鏈上的大量交易對。

  • 2

    拉取預言機的二維分類:執行維度分為原子執行(價格和交易在同一筆交易內完成,如 Pyth、Redstone Pull)和延遲執行(交易先提交再由解析器帶價格,如 Chainlink 數據流、Redstone X);驗證維度分為外部驗證(由預言機智能合約驗證)和內部驗證(用戶合約繼承預言機庫自行驗證簽名)。

  • 3

    時間戳風險的關鍵性:拉取預言機更新頻率極高(每秒多次),價格時間戳可能超過區塊時間戳。若混淆時間戳(如假設價格時間戳≤區塊時間戳),或在同一區塊內回滾較舊時間戳(導致 DoS 攻擊),會導致邏輯錯誤或資金被竊取。

  • 4

    同交易多價格攻擊:攻擊者可在同一筆交易內使用多個時間戳的價格(只要大於上次更新時間戳),結合閃電貸放大利潤,特別威脅永續協議、期貨協議的原子鑄造銷毀機制。

實用技巧與重點

乾貨
  • 更新機制:推送預言機基於價格偏差阈值(約 5%)或時間阈值(如每小時)更新
  • 主要預言機
  • Pyth(外部驗證 + 原子執行)
  • Chainlink 數據流(外部驗證 + 延遲執行)
  • Redstone Pull(內部驗證 + 原子執行)
  • Redstone X(內部驗證 + 延遲執行)
  • Pyth 集成:呼叫 `updatePriceFeeds()`,發送原生代幣手續費;價格緩存 3-5 分鐘;推薦用 `getPriceNoOlderThan(priceId, seconds)` 函數
  • Chainlink 數據流集成:交易先送到 dApp 智能合約(發出事件),解析器在下一區塊帶價格呼叫驗證函數
  • Redstone 集成:繼承 Redstone 合約,呼叫 `getOracleNumber(priceFeedId)`;價格有效負載附加在調用數據末尾(汇編自動提取)
  • GMX 案例:使用 Chainlink 數據流的延遲執行模式防止前置交易
  • 安全規則
  • 驗證時間戳始終遞增(無重複或回退)
  • 同區塊內不回滾舊時間戳(防 DoS)
  • 內部驗證預言機須驗證簽名者權重達到閾值
  • 簽名者私鑰泄露後,不可變協議無法更新預言機
  • 多預言機兼容性:不同類型預言機需不同函數簽名,需為每資產建獨立合約,導致多次調用。解決方案是使用多重調用(Multicall)並加入身份驗證,如以太坊 Vault Connector
  • Compound V3 示例:使用 `from*()` 代理函數允許清算者在單次多重調用中更新價格並執行清算
  • 研究方向:OEV 預言機(圍繞預言機更新時的可提取價值)、ZK 預言機、混合預言機 2(推送+拉取混合)

結論

結論

拉取預言機雖降低預言機網路成本,但使用者需嚴格驗證時間戳遞增性和價格有效負載,方能避免時間戳混淆、同交易多價格攻擊等風險。

完整解析

詳細

區塊鏈本質上是隔離的計算環境,無法原生存取互聯網數據。若應用需支持股票市場鏡像、借貸市場定價或預測市場結算,必須透過預言機將外部數據導入。早期推送預言機由數據提供商(如 Chronicle 和 Chainlink)持續維護價格更新,根據價格偏差或時間間隔在鏈上發佈。這種方式安全性最高、集成最簡單——僅需呼叫預言機合約的特定函數即可讀取價格,但代價是運營成本極高,因為網路必須在每條支持的區塊鏈上不斷提交交易。

為降低成本,拉取預言機將責任轉移給用戶:用戶從預言機服務器獲取價格,與交易打包送上鏈,智能合約驗證有效性。這樣預言機網路無需承擔交易成本,能支持更多鏈和交易對。拉取預言機可沿兩個維度分類。首先是執行模式:原子執行讓價格和交易在同一筆交易內完成(如借貸時同時提交所有資產價格並借款),適合無抵押場景;延遲執行先記錄交易意圖(發出事件),任何人作為解析器在下一區塊提交價格,幫助防止前置交易,GMX 廣泛採用此模式。其次是驗證方式:外部驗證由預言機網路智能合約驗證簽名;內部驗證則用戶合約繼承預言機庫,自行驗證簽名是否達到閾值。

然而拉取預言機帶來新的安全問題。首先是時間戳風險:因為拉取預言機可每秒更新多次,價格時間戳可能大於區塊時間戳。若應用假設時間戳總是小於等於區塊時間戳,或在同一區塊內回滾舊時間戳以強制更新,會導致邏輯錯誤或使用者遭遇拒絕服務攻擊。其次是同交易多價格攻擊:攻擊者可在同一筆交易內使用多個時間戳的價格(只要每個時間戳大於前一次更新),結合閃電貸放大風險。例如永續協議允許原子鑄造銷毀代幣時,攻擊者可用不同價格點開平倉多個頭寸以竊取部分資金。此外,採用內部驗證的預言機無法在簽名者私鑰泄露後無損更新,因為驗證邏輯寫死在合約內;而不可變協議更是無法升級。最後,混用不同預言機類型會導致兼容性問題,因為每種預言機需不同的呼叫方式,導致應用需為每項資產建獨立合約,用戶必須透過多重調用同時更新價格和執行操作。解決方案如 Oiler 使用以太坊 Vault Connector(帶身份驗證的多重調用),或 Compound V3 利用代理函數讓清算者代表用戶執行所有操作。

關鍵時刻

Pipeline v2

帶時間戳的重點,會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。

事實查核

Pipeline v2

說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。

更多「Web3 安全」的內容

IF YOU OWN XRP YOU NEED TO SEE THIS PRICE MANIPULATION! ⚠️
8 min
Web3 安全英文8月14日

IF YOU OWN XRP YOU NEED TO SEE THIS PRICE MANIPULATION! ⚠️

Zach Humphries

  • 機構支撐的積極意義:價格操縱常被視為負面,但Ripple掌握大量XRP供應與escrow,在熊市期間提高價格下限,實際上替零售投資者鎖定了低風險的積累區間,這不是剝削而是市場穩定機制。
  • 歷史模式驗證:2024年7月至11月XRP在50美分附近橫盤整理,低點觸及42美分(wick),高點65美分;隨後11月5日至12月5日單月上漲456%,年底到2025年初累計漲幅534%,這個歷史周期正在1美元價位重演。
  • 比特幣聯動邏輯:講者在4-5月就預測「如果比特幣跌至60k以下,XRP會跌至1美元或更低」,此預測精準應驗,反映出熊市中兩者的明確連動關係。
Minimmit, Multimmit and the New Consensus Frontier with Patrick O'Grady
72 min
Web3 安全英文PODCAST8月5日

Minimmit, Multimmit and the New Consensus Frontier with Patrick O'Grady

Zero Knowledge

  • 反向 Linux 架構:Commonware 刻意暴露棧各層級控制,讓開發者自訂執行環境、共識機制、密碼學實現,而非像 Cosmos SDK 只允許應用層以上定制。2-3 個月能組裝一條定製鏈,代價是額外深度但回報是長期維護成本降低及效能優化彈性。
  • 容錯假設的典範轉移:Alpine Glow(Solana 2025)實現單輪投票定終的關鍵是將容錯預算分離為獨立的 Byzantine 和 Crash 容限。傳統系統把 33% 當一個整體預算;新模型允許 20% 惡意加 20% 崩潰,打破了 PBFT 理論界線,釋放單輪設計空間。
  • Minimet 與 Multimet 的遞進:Minimet 是 5F+1 設定下的乾淨構造,實現更短視圖延遲;Multimet(剛發布)進一步允許並行 mini-commits 且驗證者可推翻領導者審查,使用者交易在全球分布式網路達到 200-300 毫秒端到端定終。
Private Information Retrieval (PIR) with Alex Hoover
64 min
Web3 安全英文PODCAST7月29日

Private Information Retrieval (PIR) with Alex Hoover

Zero Knowledge

  • PIR 保護的是訪問模式,不是資料本身
  • PIR 與加密不同,它關注的是隱藏「客戶端查詢了什麼」,而非「資料是否加密」。在公開資料庫(如區塊鏈)上,客戶端可以在不洩露查詢對象給伺服器的情況下檢索特定條目,解決了輕量級客戶端的隱私和防審查問題。
  • 客戶端預處理方案是突破瓶頸的關鍵