去中心化金融應用是以太坊生態系統中新生且快速增長的一個門類，但其中的關鍵部分 —— 資訊輸入機制（Oracle，舊譯 “資訊輸入機制”）—— 已經吸引了大家的注意力。如果缺乏資訊輸入機制，去中心化金融應用就只能獲得鏈上資料、對現實應用場景的適應性也會大大受限。可能很多人也都知道，現在許多專案都已經在使用鏈外資訊輸入機制了，但大家對資訊輸入機制的使用和相關安全措施卻缺乏瞭解。新專案越來越多、現有專案也在重新構建以滿足更高的安全性，希望本文可以成為資訊輸入機制使用方式的最佳實踐參考。我們不會過多地討論資訊輸入機制的最佳設計原則和安全模型，只討論如果你在以太坊上構建應用，該如何使用資訊輸入機制。如果你也希望自己開發的應用能實現安全性，抗審查性和去中心化，以下是為你在構建以太坊智慧合約時候提供的一些建議：建議 1：資訊輸入機制設計和互動必須是你的協議中優先考慮項資訊輸入機制的最簡單形式就是中心化的輸入機制，就是由你（專案建立者）來輸入價格資訊，你可以看到很多協議在啟動時都是這樣做的，並且僅僅使用一個簡單的多重簽名來保障安全性。這些協議自稱選擇 “漸進式去中心化” 的路線（我們對這個說法很有意見），宣稱他們未來會切換到一個去中心化的資訊輸入機制。如果只是想參加駭客松，那沒啥問題，但是在專案開始的時候因為中心化的資訊輸入機制效能比任何去中心化的資訊輸入機制都要高就依賴它，那做一個新專案未免太容易了。如果你的假設是準確的數值總能即時提交到鏈上，你在系統的容量和使用者體驗上的設計決策會截然不同。踐行這種漸進式去中心化理念的專案現在處於一種尷尬的境地，即使用者希望獲得某種體驗，但他們的產品在現有的去中心化技術棧上根本無法安全地工作。他們被迫透過在中心化的多重簽名中加入多個參與方來假裝去中心化，或者他們抱著順著路踢著易拉罐子的心態，祈禱著公鏈可擴充套件性的不可能三角問題能夠幸運地順利解決。這裡的重點是，除非從一開始設計協議時就考慮加入去中心化的資訊輸入機制，否則去中心化的資訊輸入機制是很難更新到已存在的協議中的。建議 2：不要相信你的資訊輸入機制總能快速響應以太坊依然是一個新生事物，儘管常常幾秒鐘就能出一個區塊，但在轉賬比較頻繁的時期，交易得到確認可能需要很長時間。如果你還記得區塊鏈遊戲 “迷戀貓” 導致的區塊鏈堵塞事件，以及最近的 “黑色星期四” 導致轉賬費用暴漲事件，這時候使用者都不得不支付令人難以置信的高額轉賬礦工費才能讓他們的交易順利確認。即使你認為協議的使用者在經濟上有動力支付這些費用，你真的希望他們被迫支付這些費用嗎？除了網路堵塞問題，開發人員還應該考慮以太坊崩潰的極端情況。區塊鏈網路不太可能長期中斷，但是短時間中斷是有可能的，因此必須考慮到在缺乏最終確定性的鏈上與鏈下（常常是）快速的資訊輸入機制互動會造成的影響。我們總是希望協議能夠保持正常和及時執行，但有時候這是做不到的，比如協議需要執行幾分鐘才能夠確認最終性，那你的資訊輸入機制可能就無法輸入資訊了。這並不是說所有為資訊輸入機制設計時間框架的方案都不可取，針對資訊輸入機制設計一個務實的執行間隔是很好的，但是一個穩定的去中心化金融協議應該為這些突發的極端情況做好預備。其中之一是：建議 3：假設你的資訊輸入機制可能被破壞不要在你的資訊輸入機制中假設最終確定性。許多協議都犯了讓資訊輸入機制更新來推動某些操作的錯誤（例如，一個衍生品合約僅當資訊輸入機制更新的時候才能完成結算）。這是一個錯誤。你應該有一個標準的操作程式，以防止資訊輸入機制出現錯誤的情況，即使我們希望這種情況永遠不會出現。回顧一下，資訊輸入機制可能出現兩種錯誤：· 你的資訊輸入機制提交了一個錯誤的值。· 你的資訊輸入機制宕機了並且不往鏈上推送資訊第一種問題，舉個例子，如果你使用的是中心化的價格資訊輸入機制，而價格提供方意外地將價格乘以10000，你肯定不想以這個值結算，甚至資訊輸入機制本身也會刪除這個值（在 Tellor 資訊輸入機制中這會引發爭執並被取消），但問題仍然存在 —— 你要等多久才能對資料進行驗證？這最終取決於你的協議的穩定性，因為有些智慧合約可能比其他合約需要一個 更慢/更健壯 的檢查機制和確認機制。這種機制的一個很好的例子是 Maker 協議，資訊輸入機制傳入的資訊要延後一個小時才會生效。但我們需要仔細思考，也不要認為這一定是對的。第二種破壞資訊輸入機制機制的方式顯得更加迂迴。一個例子就是中心化資訊輸入機制丟失了私鑰導致不能更新合約，那這時候你的衍生品智慧合約會怎麼樣？另外一個影響資訊輸入機制活性的事情是，資訊提供者不願意從速提供資訊。假設以太坊網路堵塞，每筆交易的礦工費是 20 美元，而你的資訊輸入機制只提供每筆 1 美元的交易手續費，那麼智慧合約可能要花費幾個小時才能更新，回到建議 2 的角度看，你可能需要對此做好準備，但您也應該知道您的資訊提供商是否有能力單方面控制此延遲。在 Tellor 資訊輸入機制中，我們透過 POW 的競爭方式讓資料上鍊，因此其活性是得到了激勵機制的保證的。一些更為中心化的資訊輸入機制則沒有這樣的保證，資訊輸入機制提供者可以容忍延遲交易，甚至可以根據賄賂或自己的立場對資料進行審查。當一個資訊輸入機制涉嫌腐敗或者涉及中心化審查，我們有很多應對辦法（當然我們希望最好別用到），包括：· 停止合約執行並等待資訊輸入機制反饋正確的數值· 轉向使用 另一個/後備的 資訊輸入機制· 利用多個資訊輸入機制· 返還所有資金/用預設數值完成結算我們指的資訊輸入機制的後備和安全性主要強調的是協議層面，後備選項在每種情況下應該怎麼使用很難用一個統一的正規化來表達，但要確保各方完全沒有動力各自採取這些後備選項，後備機制的目的是保障網路安全，而不是為惡意攻擊提供另一條路徑。建議 4：知道破壞資訊輸入機制的成本無論你承不承認，攻擊者總有辦法破壞資訊輸入機制，只是成本不同罷了。有些時候這個成本是購買聲譽或者買票的成本，有些時候是專案所發行的代幣市值的一部分，或許更多的情況是腐化資訊提供者的成本或對相關參與方審查的成本（例如傳統的中心化模式）。無論破壞資訊輸入機制的成本實際是多高，或者即使破壞資訊輸入機制的代價不是一成不變的，你都應該對你的協議的安全性有一個大致的瞭解。對於希望有朝一日會持有數百萬甚至數十億美元資金的專案來說，拿市值只有幾百萬美元的 token 來給資訊輸入機制的安全性背書，或者拿某些團體的聲譽來背書，都是很大的風險。知道破壞資訊輸入機制的成本可以讓協議開發者明白要多少安全措施才可以保證系統的穩定，使用一個資訊輸入機制也許無法保證智慧合約資產的安全性，但是使用多個資訊輸入機制或者採取一些後備方案，將會使得對合約的攻擊成本大大提高。目前，已經有人開始提交一份以太坊升級提議（EIP2362），這份提案透過標準化價格和資料流資訊來讓新的協議能夠簡單快速地整合多個資訊輸入機制到他們的合約中。總結一下
你應該知道你的協議最終的安全性來自哪裡，如果你將價格資訊保安性外包給一個資訊提供者，那麼請了解他們在什麼情況下會出問題，並相應地採取對策。如果你給自己的協議設計了終極治理機制，請確保這個機制能保護整個系統的公正性和去中心化。以太坊是一個了不起的生態系統，在它上面建立了很多最頂級的專案，同時資訊輸入機制也得到了應有的關注。我們可以在去中心化網路上建立一個有意義的系統，只需我們誠實地面對目前的技術限制，靈活地處理遇到的極端情況，並有決心建立真正去中心化的應用程式。
原文連結:
https://medium.com/tellor/best-practices-for-oracle-users-on-ethereum-1ad9e2a43c3b
作者: Tellor Core
翻譯&校對: 陳亮&阿劍
