精通以太坊

第 11 章預言機

第 11 章

預言機

約 21 分鐘閱讀 · 8 個小節

本章討論預言機(oracle),也就是能為以太坊智能合約提供外部資料來源的系統。oracle 一詞源自希臘神話,指的是能與眾神溝通、預見未來景象的人。在區塊鏈的語境中,預言機是一種能回答以太坊外部問題的系統。理想上,預言機是免信任的系統:它依循去中心化的原則運作,所以不需要被信任。

11.1. 為什麼需要預言機

以太坊平台的一個關鍵組成是 EVM:在共識規則的約束下,它能在去中心化網路中的任何節點上執行程式、更新以太坊的狀態。為了維持共識,EVM 的執行必須完全是確定性的,而且只能依據以太坊狀態與已簽署交易這個共享的脈絡。這帶來兩個特別重要的後果:第一,EVM 與智能合約無法取得任何內在的隨機性來源;第二,外在的資料只能透過交易所攜帶的資料(data payload)帶進來。

我們進一步拆解這兩個後果。要理解為什麼 EVM 不能有真正的隨機函數來為智能合約提供隨機性,可以想想執行這種函數之後,達成共識的嘗試會受到什麼影響:節點 A 執行這個指令後,代表智能合約在它的儲存空間中存入 3;而執行同一個智能合約的節點 B,存入的卻是 7。於是,儘管在同樣的脈絡中執行了完全相同的程式碼,節點 A 與 B 對結果狀態應該是什麼,卻得出了不同的結論。事實上,每次對這個智能合約求值,都可能得到不同的結果狀態。如此一來,這個由世界各地大量獨立運作的節點組成的網路,永遠無法對結果狀態應該是什麼達成去中心化的共識。實際上,情況很快就會比這個例子糟糕得多,因為包括以太幣(ether)轉帳在內的連鎖效應會以指數方式累積。

請注意,偽隨機函數,例如密碼學上安全的雜湊函數(它是確定性的,因此可以成為、而且確實是 EVM 的一部分),對許多應用來說並不足夠。以一個模擬擲硬幣來決定賭注派彩的賭博遊戲為例,它需要隨機產生正面或反面:區塊提議者可以參與這個遊戲,並且只在自己會贏的區塊中納入自己的交易,藉此取得優勢。那麼,我們要如何繞過這個問題?所有節點都能就已簽署交易的內容達成一致,因此外在的資訊,包括隨機性來源、價格資訊、天氣預報等等,可以作為送進網路的交易的資料部分帶進來。然而,這些資料根本無法信任,因為它們來自無法驗證的來源。這樣一來,我們只是把問題往後推而已。我們用預言機來嘗試解決這些問題,本章接下來會詳細討論。

11.2. 預言機的使用案例與範例

理想上,預言機提供一種免信任(或至少接近免信任)的方式,把外在的資訊(也就是「真實世界」或鏈下的資訊),例如足球比賽的結果、黃金的價格或真正的隨機數,帶上以太坊平台供智能合約使用。它們也可以用來把資料安全地直接傳給去中心化應用(DApp)的前端。因此,預言機可以視為一種在鏈下世界與智能合約之間搭起橋梁的機制。它們大多用來在不同的區塊鏈之間傳遞資訊,例如代幣價格。

讓智能合約能依據真實世界的事件與資料來執行契約關係,大幅擴展了它們的應用範圍。然而,這也可能為以太坊的安全模型帶來外部風險。想像一個在某人過世時分配資產的「智能遺囑」合約。這是智能合約領域經常討論的例子,也凸顯了受信任預言機的風險。如果這種合約所控制的遺產金額夠高,對預言機發動駭客攻擊[28]、在所有者過世前就觸發資產分配的誘因就非常大。

請注意,有些預言機提供的資料專屬於某個特定的私有資料來源,例如學歷證書或政府核發的身分證件。這類資料的來源(例如大學或政府部門)是完全受信任的,而資料的真實性是主觀的(真假只取決於來源的權威)。因此,這類資料無法以免信任的方式提供(也就是不信任某個來源就無法取得),因為並不存在可以獨立驗證的客觀事實。儘管如此,我們仍把這些資料來源納入「預言機」的定義,因為它們同樣為智能合約提供了資料的橋梁。它們提供的資料通常是認證(attestation)的形式,例如護照或成就紀錄。認證未來將是區塊鏈平台成功的一大關鍵,尤其是在驗證身分或聲譽這類相關議題上,因此探討區塊鏈平台如何提供這些服務非常重要。

預言機可能提供的資料還有以下這些例子:

  • 來自物理來源(例如量子或熱過程)的隨機數或熵(例如在樂透智能合約中公平地選出得獎者)

  • 與自然災害連動的參數式觸發條件(例如觸發巨災債券智能合約,像是地震債券所依據的芮氏規模測量值)

  • 匯率資料(例如讓加密貨幣準確地與法定貨幣掛鉤)

  • 資本市場資料(例如為一籃代幣化資產或證券定價)

  • 基準參考資料(例如把利率納入智能金融衍生品)

  • 靜態或準靜態資料(例如證券識別碼、國家代號、貨幣代號等)

  • 用於事件觸發、以精確時間測量為依據的時間與時距資料

  • 天氣資料(例如依據天氣預報計算保險費)

  • 用於預測市場結算的政治事件

  • 用於預測市場結算與夢幻運動合約的體育賽事

  • 地理位置資料(例如用於供應鏈追蹤)

  • 保險合約的損害核實

  • 為了互通功能而在其他區塊鏈上發生的事件

  • 以太幣的市場價格(例如用於以法定貨幣計價的 gas 價格預言機)

  • 航班統計資料(例如團體或社團合購機票時使用)

在接下來的幾節中,我們會探討預言機的幾種實作方式,包括基本的預言機模式、計算預言機、去中心化預言機,以及用 Solidity 實作的預言機客戶端。[29]

11.3. 預言機的設計模式

依照定義,所有預言機都提供幾項關鍵功能,包括能夠:

  • 從鏈下來源收集資料

  • 透過已簽署的訊息把資料傳送上鏈

  • 讓資料可供取用

資料一旦在智能合約中可供取用,其他智能合約就能透過訊息呼叫,呼叫預言機智能合約的 retrieve 函式來存取它;以太坊節點或具備網路功能的客戶端也可以直接存取。

設定預言機的三種主要方式可以分為即時讀取(immediate-read)、發布—訂閱(publish-subscribe)與請求—回應(request-response)。

11.3.1. 即時讀取(Immediate-Read)

我們從最簡單的預言機類型開始。即時讀取預言機提供的資料只用於當下的決定,例如「ethereumbook.info 的地址是什麼?」或「這個人滿 18 歲了嗎?」,如圖 11-1 所示。

即時讀取預言機
圖 11-1. 即時讀取預言機

想查詢這類資料的人,往往採取「即用即查」的方式:需要資訊時才查詢,之後可能再也不會查了。這類預言機的例子包括保存組織相關資料或由組織核發資料的預言機,例如學歷證書、國際電話區碼、機構會員資格、機場代號、自主身分(self-sovereign ID)等等。

這類預言機把資料一次存進它的合約儲存空間,其他任何智能合約都能透過對預言機合約發出的請求呼叫來查詢。資料也可能會更新。預言機儲存空間中的資料,也能讓具備區塊鏈功能(也就是連接以太坊客戶端)的應用程式直接查詢,不必大費周章地發出交易、支付 gas 成本。商店要檢查想購買酒類的顧客年齡時,就可以這樣使用預言機。對原本可能必須架設並維護伺服器來回應這類資料請求的組織或公司來說,這類預言機很有吸引力。

請注意,預言機儲存的資料很可能不是它所提供的原始資料,例如出於效率或隱私的考量。一所大學可能會為歷屆學生的學歷證書架設一個預言機。然而,儲存證書的完整內容(修過的課程與取得的成績可能長達好幾頁)會太過頭;只要儲存證書的雜湊值就夠了。同樣地,政府可能想把公民身分證件放上以太坊平台,而其中的細節顯然必須保密。這時,同樣可以把資料雜湊(更謹慎的做法是放進加了鹽值(salt)的默克爾樹),只在智能合約的儲存空間中存放根雜湊值,這是組織這類服務的一種有效率的方式。

11.3.2. 發布—訂閱(Publish-Subscribe)

下一種設定是發布—訂閱:預言機實際上為預期會變動(可能既規律又頻繁)的資料提供一種廣播服務,由鏈上的智能合約輪詢,或由鏈下的常駐程式(daemon)監看是否有更新,如圖 11-2 所示。

發布—訂閱預言機
圖 11-2. 發布—訂閱預言機
備註

也可以不用鏈下的常駐程式。預言機可以保存更新的時間戳記,在資料被讀取時把它傳給智能合約。這樣一來,智能合約就知道資料最後一次更新的時間,可以自行選擇是否使用。

這一類的模式類似 RSS 訂閱、WebSub 之類的機制:預言機收到新資訊而更新,並以一個旗標通知自認為「已訂閱」的對象有新資料可用。有興趣的一方必須輪詢預言機,檢查最新資訊是否有變,或是監聽預言機合約的更新、在更新發生時採取行動。例子包括價格資料源(price feed)、天氣資訊、經濟或社會統計資料、交通資料等等。

在網頁伺服器的世界裡,輪詢非常沒有效率,但在區塊鏈平台的點對點(P2P)環境中並非如此。以太坊客戶端必須跟上所有的狀態變化,包括合約儲存空間的變化,因此輪詢資料變化只是對一個已同步客戶端的本地呼叫。以太坊的事件日誌讓應用程式特別容易留意預言機的更新,所以這種模式在某些方面甚至可以視為一種「推播」服務。

11.3.3. 請求—回應(Request-Response)

請求—回應這一類最複雜:資料空間太過龐大、無法存放在智能合約中,而使用者每次預期只需要整個資料集的一小部分,如圖 11-3 所示。對提供資料的企業來說,這也是一種適用的模式。

請求—回應預言機
圖 11-3. 請求—回應預言機

實務上,這種預言機可以實作成一套系統,由鏈上的智能合約,以及用來監看請求、擷取並回傳資料的鏈下基礎設施組成。去中心化應用請求資料,通常是一個包含好幾個步驟的非同步過程。在這個模式中,首先由一個外部擁有帳戶(EOA)與去中心化應用進行交易,進而與預言機智能合約中定義的某個函式互動。這個函式向預言機發起請求,相關的引數會詳細說明所請求的資料,另外還可能附上回呼函式與排程參數等補充資訊。這筆交易通過驗證之後,就可以觀察到這個預言機請求:它可能是預言機合約發出的 EVM 事件,也可能是一次狀態變化。接著就能取出這些引數,用來實際查詢鏈下的資料來源。預言機也可能要求支付處理請求的費用、回呼所需的 gas 費用,以及存取所請求資料的權限。最後,產生的資料由預言機的所有者簽署,證實這份資料在特定時間點的有效性,再透過一筆交易交付給發出請求的去中心化應用;交付的方式可以是直接送達,也可以經由預言機合約,如圖 11-3 所示。視排程參數而定,預言機可能還會定期廣播更多交易來更新資料(例如每日收盤的價格資訊)。

請求—回應預言機的步驟可以歸納如下:

  1. 接收來自 DApp 的查詢。

  2. 解析查詢。

  3. 確認已提供付款與資料存取權限。

  4. 從鏈下來源擷取相關資料(必要時加以加密)。

  5. 簽署包含這些資料的交易。

  6. 把交易廣播到網路上。

  7. 安排之後所需的其他交易,例如通知之類。

此外還有各式各樣的其他做法;例如,可以直接向一個 EOA 請求資料、由它直接回傳,省去預言機智能合約。同樣地,請求與回應也可以發給一個具備物聯網功能的硬體感測器,並由它回傳。因此,預言機可以是人、軟體或硬體。

這裡描述的請求—回應模式常見於主從式架構。雖然這是一種實用的訊息傳遞模式,讓應用程式能進行雙向對話,但在某些情況下可能並不合適。例如,一個需要從預言機取得利率的智能債券,在請求—回應[30] 模式下可能必須每天請求一次資料,才能確保利率永遠正確。由於利率不常變動,這裡採用發布—訂閱模式可能更合適,尤其是考慮到以太坊有限的頻寬。

發布—訂閱這種模式中,發布者(在這裡就是預言機)不直接把訊息傳給接收者,而是把發布的訊息分成不同的類別。訂閱者可以表明對一個或多個類別有興趣,只取得自己感興趣的訊息。在這種模式下,預言機可以在利率每次變動時,把它寫進自己的內部儲存空間。多個已訂閱的 DApp 只要從預言機合約讀取即可,從而減少對網路頻寬的影響,同時把儲存成本降到最低。

在廣播或群播模式中,預言機會把所有訊息發布到一個頻道上,訂閱的合約則以各種訂閱方式監聽這個頻道。例如,預言機可能把訊息發布到一個加密貨幣匯率頻道。如果某個訂閱的智能合約需要時間序列,比如用來計算移動平均,它可以請求頻道的完整內容;另一個合約可能只需要最新的匯率來計算現貨價格。當預言機不需要知道訂閱合約的身分時,就適合採用廣播模式。

11.4. 資料認證

假設 DApp 所查詢的資料來源既具權威性又值得信任(這可不是個小假設),仍然有一個懸而未決的問題:既然預言機與請求—回應機制可能由不同的實體營運,我們要如何信任這個機制?資料在傳輸途中遭到竄改的可能性確實存在,因此鏈下的方法能夠證實回傳資料的完整性至關重要。資料認證的兩種常見做法是 真實性證明(authenticity proof)與可信執行環境(trusted execution environment,TEE)。

真實性證明仰賴密碼學上的保證,確保資料從來源到區塊鏈的途中沒有被更改。這類證明把信任的依據從傳輸機制轉移到一個可驗證的認證方(attestor)身上,例如資料提供者、安全的第三方,甚至是一個去中心化的節點網路。智能合約在鏈上驗證密碼學簽章或零知識認證,就能確認收到的資訊確實來自正確的權威來源、沒有遭到竄改,而且往往不需要原始資料來源實作特殊的簽署邏輯。

備註

Chainlink VRF 就是一個實際的例子,它是 Chainlink 的可驗證隨機函數(VRF)服務。我們可以在 Chainlink 的文件中讀到:「對於每一個請求,Chainlink VRF 都會產生一個或多個隨機值,以及說明這些值如何決定的密碼學證明。這個證明會先在鏈上發布並通過驗證,任何使用它的應用程式才能使用。」所以 Chainlink VRF 能夠證明它是如何產生隨機值的,而這其實就是一種真實性證明。

Chainlink VRF 的運作方式是:已部署的智能合約向 Chainlink 預言機網路請求一個隨機數,並提供一個預言機無法預測的提示值。每個預言機用自己的私鑰在鏈下產生一個隨機數,再把結果與對應的密碼學證明發布到鏈上。智能合約可以用該預言機的公鑰與原本的提示值,驗證這個隨機輸出沒有遭到操縱。由於證明完全在鏈上驗證,攻擊者無法在不破壞密碼學檢查的情況下竄改結果。如果某個節點遭到入侵或失去回應,它的故障會被記錄在鏈上,最終它會被排除,不能再提供隨機數。

TEE 利用專門的硬體安全隔離區(enclave)來保護程式碼與資料並為其提供證明,藉此強化這些保證。當一項計算在這種安全隔離區內執行時,CPU 會確保外部的行程無法干擾它,也看不到底層的資料,從而同時維護完整性與機密性。接著,安全隔離區可以提供經過數位簽章的認證(也就是一份證明),證實某一段以密碼學雜湊值識別的程式碼,正在這個安全環境中執行。這讓智能合約能更有把握:任何外部資料或計算在抵達鏈上之前,都沒有遭到惡意更改。安全隔離區也能提供隱私功能,因為敏感的輸入可以在安全隔離區內加密並處理,完全不會洩漏給外界。

在許多現代的預言機網路中,可以結合這些方法來進一步強化資料認證。有些網路仰賴由獨立節點組成的去中心化集合,從不同來源擷取並驗證資料,再就正確的結果達成共識。由於節點有誘因保持誠實,而且往往以經濟上的擔保來約束,這種多營運者系統大幅降低了單一不良行為者破壞資料源(data feed)的風險。另一些網路則採用先進的密碼學協議,在不暴露底層細節的情況下證明資料取自某個特定的端點,從而減少對完全中心化的驗證方的依賴。某些網路營運者也會部署硬體安全隔離區來執行擷取資料的邏輯,確保即使主機環境遭到入侵,最終提交到區塊鏈的結果仍然不會被更改,而且可以獨立驗證。

無論具體的實作方式為何,最大的挑戰都是確保任何擷取並傳進 DApp 的資料都精確且可信。真實性證明提供一種穩健的方式,能追蹤並驗證資料是從哪裡、以什麼方式取得的;TEE 則提供一種以硬體為後盾的手段,保護收集與轉送鏈下資訊的整個過程。

警告

由於 TEE 相對較新,它們大多還沒經過充分的檢驗,可能含有許多尚未發現的漏洞,未來很可能會被發現新的漏洞利用手法而遭到攻破。

11.5. 計算預言機

到目前為止,我們只在請求與交付資料的脈絡下討論預言機。然而,預言機也可以用來執行任意的計算;考量到以太坊固有的區塊 gas 上限與相對昂貴的計算成本,這項功能特別有用。計算預言機不只是轉送查詢的結果,還可以對一組輸入執行計算,回傳一個在鏈上可能無法計算的結果。例如,你可以用計算預言機執行一項計算量很大的迴歸計算,用來估計某個債券合約的收益。

被稱為 ZK 協同處理器(ZK coprocessor)的 Lagrange 與 Brevis,讓智能合約能在鏈下執行繁重的計算,同時仍能確保在鏈上驗證。以 Brevis 為例,它讓 DApp 能請求複雜的任務或歷史資料,而不必預先產生零知識證明(zero-knowledge proof)。網路會「樂觀地」發布結果,假設它們是正確的。結果在鏈上發布之後,會有一段挑戰期(challenge window),任何人都可以在這段期間提出異議。如果結果受到挑戰,提議者就必須產生完整的零知識證明來驗證結果。如果沒有提出證明,或是證明顯示最初的結果不正確,挑戰者會獲得獎勵,提交錯誤結果的一方則會受到懲罰。如果沒有人提出挑戰,結果就會被接受為有效,這大幅減少了所需的零知識證明數量,也降低了成本。

11.6. 去中心化預言機

雖然中心化的資料預言機或計算預言機足以應付許多應用,但它們是以太坊網路中的單點故障。為了確保資料可用性(data availability),並建立一個由各自獨立的資料提供者組成、搭配鏈上資料聚合系統的網路,已經有人圍繞去中心化預言機的概念提出了多種方案。

Chainlink 提出了一種去中心化預言機網路,由三個關鍵的智能合約(信譽合約、訂單撮合合約與聚合合約),以及一個鏈下的資料提供者登記處組成。信譽合約用來追蹤資料提供者的表現,其中的分數則用來填入鏈下的登記處。訂單撮合合約利用信譽合約,從各個預言機的投標中做出選擇,接著敲定一份服務水準協議,內容包括查詢參數與所需的預言機數量。這表示購買者不需要直接與個別的預言機交易。聚合合約收集多個預言機的回應(以承諾—揭示機制(commit-reveal scheme)提交),計算出查詢的最終集體結果,最後再把結果回饋給信譽合約。

這種去中心化做法的主要挑戰之一,是如何制定聚合函數。Chainlink 提議計算加權後的回應,讓每個預言機的回應都能回報一個有效性分數。在這裡偵測無效的分數並不簡單,因為它所依據的前提是:離群的資料點(以偏離同儕回應的程度來衡量)是不正確的。依據某個預言機回應在所有回應分布中的位置來計算有效性分數,可能會讓正確的答案比平均的答案受到更多懲罰。因此,Chainlink 提供一組標準的聚合合約,但也允許指定自訂的聚合合約。

一個相關的概念是 SchellingCoin 協議。在這個協議中,多個參與者回報數值,並取中位數作為「正確」答案。回報者必須提供一筆押金,這筆押金會重新分配給較接近中位數的數值,因而提供誘因,讓參與者回報與其他人相近的數值。一個共同的數值,也就是 謝林點(Schelling point),是回應者可能視為自然而明顯、可以據以協調的目標,預期會接近實際的數值。

11.7. 跨鏈訊息協議

許多應用經常需要在多條鏈之間傳輸資料、進行互動,而每條鏈都有自己的社群治理、共識規則與代幣標準。跨鏈協議已經成為促進區塊鏈之間通訊的關鍵工具,讓智能合約與去中心化應用能取用更廣泛的服務、流動性與資料。預言機把外部資訊橋接進單一區塊鏈,跨鏈協議則把這個概念延伸到連接整個生態系。

理解跨鏈協議的一種方式,是把它們視為連接區塊鏈的專門「通訊層」。這些協議不只是用來匯入外部資料,還能促進鏈與鏈之間的資訊傳遞。

在熱門的跨鏈專案中,LayerZero 提供了一個在區塊鏈之間進行輕量級訊息傳遞的框架。它專注於訊息的「傳輸」與「驗證」,目標是提供一個更有效率、更有彈性的互通層。LayerZero 的設計圍繞著兩個關鍵的鏈下實體:預言機(Oracle)與中繼者(Relayer),兩者合作驗證跨鏈交易,如圖 11-4 所示。

LayerZero 的跨鏈架構
圖 11-4. LayerZero 的跨鏈架構

預言機獨立查詢交易的證明或區塊頭,而中繼者則傳遞證明本身。可以由使用者自行設定一組預言機與中繼者,讓信任去中心化。如果預言機與中繼者提供相同的資料,LayerZero 在目標鏈上的智能合約就會接受這則訊息為有效。這讓開發者能打造複雜的互通解決方案,而不必依賴單一的跨鏈橋供應商或中心化實體。

另一個知名專案 Wormhole,最初是為了讓資產主要能在 Solana 與以太坊之間轉移而誕生的,後來擴展到其他網路,例如幣安智能鏈(Binance Smart Chain,BSC)、Hyperliquid 與 Avalanche。Wormhole 的做法建立在一個由守護者(guardian)組成的網路上:這些守護者監看單一鏈上的事件,並簽署訊息來證實這些事件。一旦有足夠的守護者簽署,這份認證就被視為有效,對應的事件(例如一筆代幣轉帳)便能在目標鏈上獲得承認,如圖 11-5 所示。這套機制不只能用於代幣跨鏈,還能處理更複雜的任務,例如跨鏈治理提案與非同質化代幣(NFT)的轉移。Wormhole 藉由結合多個守護者的安全性,試圖降低單點故障的風險;不過,這也需要謹慎地挑選並維護守護者集合。

Wormhole 的跨鏈架構
圖 11-5. Wormhole 的跨鏈架構

Chainlink 的 Cross-Chain Interoperability Protocol(CCIP)建立在該組織既有的預言機網路之上,為區塊鏈之間安全的訊息傳遞與代幣轉移提供一個通用的框架。它的重點在於達到高度的信任最小化,仰賴去中心化預言機來驗證不同網路上的事件。CCIP 可以在來源鏈上鎖定或銷毀代幣,再在目標鏈上鑄造或解鎖代幣,讓 DApp 能把功能延伸到多個生態系。CCIP 重複利用 Chainlink 為去中心化資料源與可驗證隨機性所開發的穩健基礎設施,為已經依賴這些服務的專案提供一條擴展到跨鏈營運的自然途徑。

備註

Circle 的 Cross-Chain Transfer Protocol(CCTP)也值得一提。它的運作方式與 CCIP 類似,但主要用途是在不同的鏈之間轉移 USDC。Chainlink 已經把 CCTP 整合進 CCIP。

除了這些協議之外,還有越來越多的互通層與跨鏈橋解決方案可供選擇,各自填補略有不同的利基。例如,Polkadot 與 Cosmos 等專案從一開始就以跨鏈能力為基礎打造,利用平行鏈(parachain)與樞紐鏈(hub)等設計,促進資產與資料的順暢交換。Cosmos 的 Inter-Blockchain Communication(IBC)協議採用客戶端驗證,每條相連的鏈都會儲存其他鏈的「輕客戶端」。Polkadot 則透過 Relay Chain 中一組共享的驗證者來保障各條平行鏈的安全,把每條平行鏈的交易綁進統一的共識之中。這些架構以可擴展性與安全性為優先,但也各自帶來學習門檻,對習慣類以太坊環境的開發者來說尤其如此。

11.8. 結論

如你所見,跨鏈協議與預言機把外部資訊帶進合約的執行,為智能合約提供了不可或缺的功能。當然,預言機也因此帶來重大的風險:如果它們是受信任的來源,而且可能遭到入侵,就可能連帶破壞它們所供應資料的智能合約的執行。在考慮使用預言機時,你通常應該非常謹慎地看待它的信任模型。如果你假定預言機可以依賴,你的智能合約就可能容易受到潛在錯誤輸入的影響。不過,只要仔細思考過安全假設,預言機就能非常有幫助。

去中心化預言機可以解決其中一些疑慮,為以太坊智能合約提供免信任的外部資料。謹慎選擇,你就能開始探索預言機在以太坊與「真實世界」之間搭起的橋梁。

我們也看到了跨鏈協議如何作為以太坊與其他生態系之間的橋梁:它們承襲了預言機的許多潛力與風險,同時把使用案例與功能的範圍擴展得更廣。

註腳

  1. 這也可能指收買中心化預言機的人類操作者。 ↩
  2. 譯註:本章第二版並沒有介紹以 Solidity 實作預言機客戶端的小節;本章其餘各節只涵蓋設計模式、資料認證、計算預言機、去中心化預言機與跨鏈訊息協議。這段介紹沿用自第一版,第一版的預言機一章才有「Solidity 中的預言機客戶端介面」一節。 ↩
  3. 由於這種非同步性,發出請求的 DApp 或合約必須設計成能處理延遲的回應,不能期待在同一筆交易中立即取得資料。 ↩