寫在前言
前之前，我們寫了一篇文章介紹了“區塊鏈技術為不同種類資料帶去的價值”，即區塊鏈在保障不同資料的來源、不可變性以及真實性方面的能力。本文，我們會繼續解答另一個常常被大家（有意）忽視的問題：資料如何同區塊鏈互動。就像其他眾多系統一樣，區塊鏈技術也正經歷著“垃圾輸入，垃圾輸出”（GIGO）的痛。
向區塊鏈撒謊
之前釋出的關於資料的文章中，我們發現對於那些非區塊鏈本地生成且非公開可獲取的資料，區塊鏈系統並不能確保其真實性，而不幸的是，全球絕大多數都是這類資料。因此，如果某人（某裝置）提交欺詐性資料到區塊鏈上，我們根本無法確定其真實性，結果就是你不停地提交假資料到區塊鏈歷史。於是，你讓垃圾上了鏈，區塊鏈再還你垃圾。
據悉，如今忽略這個問題的應用比比皆是，通常它們會再附加一些技術層確保資料正確性，這裡是幾個案例：
去中心化資料市場：用代幣激勵企業掛牌出售資料——你怎麼知道你買的資料是真實的？
隱私保護查詢：這項服務透過一種零知識範圍證明來計算銀行高淨值人士數量，這樣你就可以收穫一個數字而銀行不用提交任何客戶資料——那麼你怎麼確認銀行沒有偽造整個客戶資料庫？
對於公開可獲取的資料，你可以設計一個遊戲，讓有資金風險的玩家向其他玩家的資料真實性發起挑戰，就像Chainlink設計的那樣。但正如我們之前所說的，世界上絕大多數資料並非公開可獲取。
那該怎麼辦？關鍵是要在源頭確保資料安全。
確保資料來源安全
如果我們沒有從源頭獲得資料，而是透過第三方或中間商獲取，那麼在不信任這個中介的情況下，這個資料的真實性也就不再可信。越多中介參與的資料管理，越是不得不信，但如果中介數量多到一定程度，這個資料就有可能是由隨機數生成器生成的了。
所以，我們的目標就是儘可能從靠近源頭的地方獲得資料。例如：
與其從零售商的資料庫獲得銷售資料，不如從銷售點硬體入手；
與其在網站上訂閱天氣預報，不如關注採集資料的天氣感測器；
與其檢視橋樑運營企業的PDF報告，不如從橋體上安裝的攝像頭和感測器獲得原始資料等。
但是如何從源頭確保資料安全呢？由於世界上大部分資料都是由裝置產生或捕捉，我們這裡也可以把這個問題描述為如何保護裝置生成的資料。現在，我們面臨著三個潛在的失敗點：
身份：你如何知曉正在生成資料的是什麼裝置？是你預想的溫度感應器嗎？還是作惡者的隨機數生成器？
處理和傳輸：即使資料來源真實可確定，你又從何得知這個資料沒有被更改、損壞或在裝置的處理和傳輸過程中被直接替換掉（比如從感測器傳輸到通訊模組）？
數字/模擬介面：就算身份、處理以及傳輸途徑都安全，那你又要如何預防有人透過接入假的輸入訊號源來物理更換裝置採集資料的渠道？
下面我們來一一解決這些問題。
一個實用的方法
身份：
為了確保生成資料的裝置身份受到保護，我們可以在裝置上嵌入一組公私鑰，讓公鑰知曉並且現場檢查實際裝置的輸出，透過這種切實可行的手段確保硬體的身份沒有問題。——當然，這是相對簡單的一步。
棘手的部分是，你如何確保這個身份不是偷來的或者只對裝置可知？這裡可以採用一種叫做“安全元素”(Secure Element, SE)的硬體模組，它能夠在晶片上生成公私鑰對，並且高度防篡改。通常情況下，這個安全模組只做一件事：簽署訊息。——這是一個提供身份證明的好方法。如果你持有過信用卡，或者用過現代智慧手機，那麼你已經享受到了這個安全元素的好處。
處理和傳輸：
為了保護資料處理與傳輸邏輯的安全，我們採用了一個帶有安全啟動程式（SB）的微控制器（MCU）。你可以把這裡的微控制器想象成一臺超級簡單的計算機。
SB確保只有擁有正確私鑰的實體能夠載入應用程式到MCU中。而這個應用程式的邏輯和相關的校驗能夠提前共享給利益相關方（或者直接開源），這樣就可以在載入後對其進行驗證。
接下來更關鍵的是，在應用程式經過了全面的測試後，我們需要禁用應用程式和MCU上所有的修改功能。這一點是為了確保從現在起該應用程式的邏輯徹底不可更改，就算是製造商也無法再做改動。
這個方案也存在一些明顯的缺點，比如之後應用程式就不能再更新了。但是相比之下，我們獲得了真正的裝置獨立性（結合SE）而不再受外部干擾，並且具有了完美的確定性與不可更改性足以讓我們信賴。
數字/模擬介面
這方面的問題比較難，不能透過資料採集與中繼裝置上嵌入的硬體來解決。通常必須設計出創新機制來確保介面不被中斷，但這一點還要看每個應用程式的情況。下面我們來舉個例子。
假設你有一臺冷藏車，服務於某冷鏈物流公司，日常工作是為當地的超市配送新鮮的魚。為了保鮮，魚必須儲存在一定溫度範圍內。如果溫度過高，魚就會變質；而溫度過低，魚的口感和肉質就會變差。為了確認物流公司遵守了合同約定的溫度範圍，超市會在卡車上安裝一個溫度感測器。
但是，如果卡車司機為了節省電費而調高製冷裝置的溫度，然後把感測器拿走放到車前的一個冷卻器裡怎麼辦？感測器根本不會知道自己被挪動了，只是繼續收集、報告那個恆定在合同約定的溫度範圍裡的資料。也就是說，感測器被騙了。
減輕這種風險的一個方法就是把感測器也做成硬體接到製冷裝置中，這樣就幾乎不可能被移動了。不過，這種對策仍舊可以透過某種方式避開，比如在感測器周圍纏一袋冰，而卡車其他部位依舊比合同規定的溫度高。
另一個可能更好的方案（也更貴一點）是給每包魚的包裝上貼個防篡改的密封條，並且在每個包裝上配置一個溫度感測器。這樣一來，如果司機想要拆開溫度感測器，他就不得不撕開封條，這樣就很容易被發現是違背了合約的關鍵條款。
就像前面提到的，解決數字/模擬介面的問題需要大量的創造力，且解決方案需要“具體問題具體分析”。
