再談預言機：Oracle如何重新定義智能合約？

而在本期專欄中，作者將詳細解釋

預言機是如何實現

「把現實世界中的數據以交易的形式記錄在區塊鏈上」

這一功能的？

「N3預言機有哪些問題亟需解決？」?

快來一起來看看吧??

制約區塊鏈發展的一個重要因素是落地，也就是把區塊鏈技術用於現實生活中。為此我們就需要不停地設想各種可能需要用到區塊鏈的場景，比如遊戲，比如發票，比如非同質化通證。可是這些場景依然很單薄，完全不能支持大家對區塊鏈技術的期望，更無法發揮區塊鏈技術的實力。就好像現在的5G技術，空有一身本領，到頭來大家只是用來做Speedtest。

但是為什么我們無法找到更多適合區塊鏈的場景呢？因為區塊鏈技術太封閉，為了安全，區塊鏈只信任自己鏈上的數據，不接受鏈外的數據流，比如UTXO全是鏈上的交易構造的，比如Neo Legacy裏的智能合約執行的時候只能通過少數接口獲取鏈上的數據。所以想跟區塊鏈打交道，那么你的場景裏就不能有對外界信息的依賴。但是現實世界中大多場景都需要大量的信息交互，你打开手機，哪有應用不需要聯網的。

• 比如訂票軟件，你需要實時的機票余票信息和價格信息。

• 比如交易軟件，你需要物價信息。

• 比如快遞軟件，你需要最新的物流信息。

很無奈，這些都沒辦法用區塊鏈去做。

因此，為了拓寬區塊鏈的應用場景，充分發揮區塊鏈的潛力，可以給區塊鏈投喂鏈外數據流的交互方式——預言機，應運而生。預言機就是一個可以把現實世界中的數據以交易的形式記錄在區塊鏈上的機制。熟悉計算機的小夥伴可以把預言機理解成一個現實世界和區塊鏈之間的巨大cache。由於現實世界的數據在語義上與區塊鏈是存在巨大的gap的，比如現實世界的數據可能會實時變化，可能有多個數據源，可能需要復雜的計算或者轉換，這些都無法在區塊鏈共識的過程中解決，否則不同的共識節點在驗證交易的時候可能獲取到的數據都不同，但是如果共識節點不從現實世界直接取數據，而是從“cache”裏取，那么就可以保證各個節點在驗證交易時輸入數據的一致性。因此需要在將數據寫入區塊鏈之前，有一個處理數據的過程，把數據處理成區塊鏈可以接受的形式，比如把實時數據取樣出一個當前的固定數據。

預言機的實現大致有三種，一種是中心化的第三方，第二種是可信的數據提供方，第三種則是去中心化的基於共識機制的預言機。在N3中則是因地制宜地使用了拓展性更好的去中心化預言機機制。

根據文檔，N3是指定一些預言機節點來對交易的數據請求結果進行共識，以此來避免可能存在的預言機僞造數據問題。流程是：用戶發起交易，在交易裏觸發智能合約裏的預言機請求，這個請求的本質其實是調用N3內置的原生預言機合約裏的request方法：

<summary>

創建 Oracle Request 請求數據

</summary>

<param name="url">訪問資源路徑,最大長度為 256 字節.</param>

<param name="filter">過濾器，用於在從數據源返回的結果中過濾出有用信息</param>

<param name="callback">回調函數方法名</param>

<param name="userData">用戶自定義數據</param>

<param name="gasForResponse">回調函數執行預付款</param> 

void Request(string url, string filter, string callback, object userData, long gasForResponse);

原生合約會根據參數構建一個請求，然後預言機節點根據請求來獲取數據，在預言機節點完成數據採集之後，會生成一個新的交易並在交易裏調用用戶合約裏的回調函數。所以觸發一次N3的預言機，將會有兩筆交易被寫入到區塊鏈裏，一筆是觸發預言機，另一筆是回調。這樣通過URL機制將數據源的選擇權交給合約开發者或者數據調用者，進而規避了預言機本身對數據源的信任問題，異步回調機制則解決了智能合約調用預言機延遲過大的話可能會Block掉共識過程的問題。

按照這個邏輯，理論上如果我們要觸發預言機，那么在調用預言機之後就應該會終止當前合約的執行，所以在一個合約方法裏寫在觸發預言機語句之後的代碼應該是不會執行的。不過這裏由於一些環境配置問題，我還沒辦法做驗證。

預言機雖然被定義為用來獲取數據的工具，但是其實預言機也可以用來做一些比較迷的操作。因為調用預言機這個過程，實質上跟異步調用別的合約沒有什么太大的區別，甚至N3裏就是把預言機內置為一個原生合約。這就意味着，我們可以把預言機作為一個智能合約的外掛接口，把一些原本應該寫入智能合約的邏輯寫入在合約之外。比如計算量非常大的任務，我們就可以把任務通過預言機發到鏈外，然後在鏈外執行再返回結果。再比如一些我們想隱藏起來的邏輯，比如隨機數生成算法，也可以通過預言機把這部分功能遷移到鏈外。

N3預言機系統現存問題

雖然N3原生的預言機系統很好很強大，依然有一些問題沒有能夠完美解決：

N3的預言機作為分布式系統，其處理變化頻率過快的數據比較麻煩。比如比特幣的價格，基本上是實時變化的，因此不同的預言機節點在獲取比特幣價格的時候，很可能不同的節點獲取到的價格就有零點零幾的不同，從而導致預言機共識失敗。雖然這也可以通過用戶優化數據格式在一定程度上解決。

預言機系統是一個異步回調系統，再加上存在共識過程，因此其獲取到的數據相較於觸發交易來說存在較大的延遲。比如你當前看着機票的價格很低，然後立即發送一筆交易到鏈上，你的交易立即得到的了執行，這卻並不意味着你能獲取到的價格就是交易執行時的價格，畢竟預言機的回調交易並不是和你的觸發交易同步發生的。

還有一個比較大的問題是數據源的可信程度，我們允許用戶通過預言機將鏈外的數據引入到鏈內，這在相當大的程度上將鏈外的不可信因素引入到了區塊鏈。以前攻擊區塊鏈就只能攻擊區塊鏈節點本身，這個過程由共識協議來保護。可是當我們引入了預言機後，攻擊區塊鏈的方式就變得多樣了，因為黑客可以通過攻擊合約裏指定的預言機數據源來將攻擊的影響輻射到區塊鏈裏。此外，不可靠的合約开發者也可能通過預言機機制在智能合約裏引入不可知的後門，畢竟通過預言機調用的部分功能並沒有寫入在區塊鏈裏，因此不可靠的开發者完全可以在神不知鬼不覺的情況下更改系統邏輯。

最後還有一個問題是數據的冗余。我在前文中提到預言機的功能類似於在區塊鏈和數據源之間加了一層數據緩存以保證數據的可信。可是實際上這個緩存只是我抽象出來便於大家理解的，實際上N3的預言機在處理數據的時候並不會像緩存那樣對數據進行保存以便於後續的請求。相反的，N3的預言機請求只跟用戶發起的觸發交易相關，用戶發起了多少筆觸發交易，就會有多少對應的預言機請求，即使在同一個區塊內有許許多多的交易都在請求同一個數據，這樣就難免導致預言機寫入大量的冗余到區塊鏈上。

以上。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。