在以太坊上使用信息輸入機制的最佳實踐

編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自

以太坊愛好者（ID：ethfans）

編者按：本文來自

以太坊愛好者（ID：ethfans）

編者按：本文來自

以太坊愛好者（ID：ethfans）

二級標題

去中心化金融應用是以太坊生態系統中新生且快速增長的一個門類，但其中的關鍵部分—— 信息輸入機制（Oracle，舊譯“信息輸入機制”）—— 已經吸引了大家的注意力。如果缺乏信息輸入機制，去中心化金融應用就只能獲得鏈上數據、對現實應用場景的適應性也會大大受限。可能很多人也都知道，現在許多項目都已經在使用鏈外信息輸入機制了，但大家對信息輸入機制的使用和相關安全措施卻缺乏了解。新項目越來越多、現有項目也在重新構建以滿足更高的安全性，希望本文可以成為信息輸入機制使用方式的最佳實踐參考。我們不會過多地討論信息輸入機制的最佳設計原則和安全模型，只討論如果你在以太坊上構建應用，該如何使用信息輸入機制。如果你也希望自己開發的應用能實現安全性，抗審查性和去中心化，以下是為你在構建以太坊智能合約時候提供的一些建議：

建議1：信息輸入機制設計和交互必須是你的協議中優先考慮項

信息輸入機制的最簡單形式就是中心化的輸入機制，就是由你（項目建立者）來輸入價格信息，你可以看到很多協議在啟動時都是這樣做的，並且僅僅使用一個簡單的多重簽名來保障安全性。這些協議自稱選擇“漸進式去中心化” 的路線（我們對這個說法很有意見），宣稱他們未來會切換到一個去中心化的信息輸入機制。如果只是想參加黑客松，那沒啥問題，但是在項目開始的時候因為中心化的信息輸入機制性能比任何去中心化的信息輸入機制都要高就依賴它，那做一個新項目未免太容易了。如果你的假設是準確的數值總能即時提交到鏈上，你在系統的容量和用戶體驗上的設計決策會截然不同。

二級標題

• 踐行這種漸進式去中心化理念的項目現在處於一種尷尬的境地，即用戶希望獲得某種體驗，但他們的產品在現有的去中心化技術棧上根本無法安全地工作。他們被迫通過在中心化的多重簽名中加入多個參與方來假裝去中心化，或者他們抱著順著路踢著易拉罐子的心態，祈禱著公鏈可擴展性的不可能三角問題能夠幸運地順利解決。這裡的重點是，除非從一開始設計協議時就考慮加入去中心化的信息輸入機制，否則去中心化的信息輸入機制是很難更新到已存在的協議中的。

• 建議2：不要相信你的信息輸入機制總能快速響應

二級標題

以太坊依然是一個新生事物，儘管常常幾秒鐘就能出一個區塊，但在轉賬比較頻繁的時期，交易得到確認可能需要很長時間。如果你還記得區塊鏈遊戲“迷戀貓” 導致的區塊鏈堵塞事件，以及最近的“黑色星期四” 導致轉賬費用暴漲事件，這時候用戶都不得不支付令人難以置信的高額轉賬礦工費才能讓他們的交易順利確認。即使你認為協議的用戶在經濟上有動力支付這些費用，你真的希望他們被迫支付這些費用嗎？

除了網絡堵塞問題，開發人員還應該考慮以太坊崩潰的極端情況。區塊鍊網絡不太可能長期中斷，但是短時間中斷是有可能的，因此必須考慮到在缺乏最終確定性的鏈上與鏈下（常常是）快速的信息輸入機制交互會造成的影響。我們總是希望協議能夠保持正常和及時運行，但有時候這是做不到的，比如協議需要運行幾分鐘才能夠確認最終性，那你的信息輸入機制可能就無法輸入信息了。這並不是說所有為信息輸入機制設計時間框架的方案都不可取，針對信息輸入機制設計一個務實的運行間隔是很好的，但是一個穩定的去中心化金融協議應該為這些突發的極端情況做好預備。其中之一是：

二級標題

• 建議3：假設你的信息輸入機制可能被破壞

• 不要在你的信息輸入機制中假設最終確定性。許多協議都犯了讓信息輸入機制更新來推動某些操作的錯誤（例如，一個衍生品合約僅當信息輸入機制更新的時候才能完成結算）。這是一個錯誤。你應該有一個標準的操作程序，以防止信息輸入機制出現錯誤的情況，即使我們希望這種情況永遠不會出現。

• 回顧一下，信息輸入機制可能出現兩種錯誤：

• 你的信息輸入機制提交了一個錯誤的值。

第一種問題，舉個例子，如果你使用的是中心化的價格信息輸入機制，而價格提供方意外地將價格乘以10000，你肯定不想以這個值結算，甚至信息輸入機製本身也會刪除這個值（在Tellor 信息輸入機制中這會引發爭執並被取消），但問題仍然存在—— 你要等多久才能對數據進行驗證？

這最終取決於你的協議的穩定性，因為有些智能合約可能比其他合約需要一個更慢/更健壯的檢查機制和確認機制。這種機制的一個很好的例子是Maker 協議，信息輸入機制傳入的信息要延後一個小時才會生效。但我們需要仔細思考，也不要認為這一定是對的。

第二種破壞信息輸入機制機制的方式顯得更加迂迴。一個例子就是中心化信息輸入機制丟失了私鑰導致不能更新合約，那這時候你的衍生品智能合約會怎麼樣？另外一個影響信息輸入機制活性的事情是，信息提供者不願意從速提供信息。假設以太坊網絡堵塞，每筆交易的礦工費是20 美元，而你的信息輸入機制只提供每筆1 美元的交易手續費，那麼智能合約可能要花費幾個小時才能更新，回到建議2 的角度看，你可能需要對此做好準備，但您也應該知道您的信息提供商是否有能力單方面控制此延遲。在Tellor 信息輸入機制中，我們通過POW 的競爭方式讓數據上鍊，因此其活性是得到了激勵機制的保證的。一些更為中心化的信息輸入機制則沒有這樣的保證，信息輸入機制提供者可以容忍延遲交易，甚至可以根據賄賂或自己的立場對數據進行審查。

利用多個信息輸入機制

總結一下

二級標題