之前，我們寫了一篇文章介紹了“區塊鏈技術為不同種類數據帶去的價值”，即區塊鏈在保障不同數據的來源、不可變性以及真實性方面的能力。本文，我們會繼續解答另一個常常被大家（有意）忽視的問題：數據如何同區塊鏈交互。就像其他眾多系統一樣，區塊鏈技術也正經歷著“垃圾輸入，垃圾輸出”（GIGO）的痛。

向區塊鏈撒謊

之前發布的關于數據的文章中，我們發現對于那些非區塊鏈本地生成且非公開可獲取的數據，區塊鏈系統并不能確保其真實性，而不幸的是，全球絕大多數都是這類數據。因此，如果某人（某設備）提交欺詐性數據到區塊鏈上，我們根本無法確定其真實性，結果就是你不停地提交假數據到區塊鏈歷史。于是，你讓垃圾上了鏈，區塊鏈再還你垃圾。

據悉，如今忽略這個問題的應用比比皆是，通常它們會再附加一些技術層確保數據正確性，這里是幾個案例：

去中心化數據市場：用代幣激勵企業掛牌出售數據——你怎么知道你買的數據是真實的？

隱私保護查詢：這項服務通過一種零知識范圍證明來計算銀行高凈值人士數量，這樣你就可以收獲一個數字而銀行不用提交任何客戶數據——那么你怎么確認銀行沒有偽造整個客戶數據庫？

對于公開可獲取的數據，你可以設計一個游戲，讓有資金風險的玩家向其他玩家的數據真實性發起挑戰，就像Chainlink設計的那樣。但正如我們之前所說的，世界上絕大多數數據并非公開可獲取。

那該怎么辦？關鍵是要在源頭確保數據安全。

確保數據來源安全

如果我們沒有從源頭獲得數據，而是通過第三方或中間商獲取，那么在不信任這個中介的情況下，這個數據的真實性也就不再可信。越多中介參與的數據管理，越是不得不信，但如果中介數量多到一定程度，這個數據就有可能是由隨機數生成器生成的了。

所以，我們的目標就是盡可能從靠近源頭的地方獲得數據。例如：

與其從零售商的數據庫獲得銷售數據，不如從銷售點硬件入手；

與其在網站上訂閱天氣預報，不如關注采集數據的天氣傳感器；

與其查看橋梁運營企業的PDF報告，不如從橋體上安裝的攝像頭和傳感器獲得原始數據等。

但是如何從源頭確保數據安全呢？由于世界上大部分數據都是由設備產生或捕捉，我們這里也可以把這個問題描述為如何保護設備生成的數據。現在，我們面臨著三個潛在的失敗點：

身份：你如何知曉正在生成數據的是什么設備？是你預想的溫度感應器嗎？還是作惡者的隨機數生成器？

處理和傳輸：即使數據來源真實可確定，你又從何得知這個數據沒有被更改、損壞或在設備的處理和傳輸過程中被直接替換掉（比如從傳感器傳輸到通信模塊）？

數字/模擬接口：就算身份、處理以及傳輸途徑都安全，那你又要如何預防有人通過接入假的輸入信號源來物理更換設備采集數據的渠道？

下面我們來一一解決這些問題。

一個實用的方法

身份：

為了確保生成數據的設備身份受到保護，我們可以在設備上嵌入一組公私鑰，讓公鑰知曉并且現場檢查實際設備的輸出，通過這種切實可行的手段確保硬件的身份沒有問題?！斎唬@是相對簡單的一步。

棘手的部分是，你如何確保這個身份不是偷來的或者只對設備可知？這里可以采用一種叫做“安全元素”（Secure Element， SE）的硬件模塊，它能夠在芯片上生成公私鑰對，并且高度防篡改。通常情況下，這個安全模塊只做一件事：簽署消息。——這是一個提供身份證明的好方法。如果你持有過信用卡，或者用過現代智能手機，那么你已經享受到了這個安全元素的好處。

處理和傳輸：

為了保護數據處理與傳輸邏輯的安全，我們采用了一個帶有安全啟動程序（SB）的微控制器（MCU）。你可以把這里的微控制器想象成一臺超級簡單的計算機。

SB確保只有擁有正確私鑰的實體能夠加載應用程序到MCU中。而這個應用程序的邏輯和相關的校驗能夠提前共享給利益相關方（或者直接開源），這樣就可以在加載后對其進行驗證。

接下來更關鍵的是，在應用程序經過了全面的測試后，我們需要禁用應用程序和MCU上所有的修改功能。這一點是為了確保從現在起該應用程序的邏輯徹底不可更改，就算是制造商也無法再做改動。

這個方案也存在一些明顯的缺點，比如之后應用程序就不能再更新了。但是相比之下，我們獲得了真正的設備獨立性（結合SE）而不再受外部干擾，并且具有了完美的確定性與不可更改性足以讓我們信賴。

數字/模擬接口

這方面的問題比較難，不能通過數據采集與中繼設備上嵌入的硬件來解決。通常必須設計出創新機制來確保接口不被中斷，但這一點還要看每個應用程序的情況。下面我們來舉個例子。

假設你有一臺冷藏車，服務于某冷鏈物流公司，日常工作是為當地的超市配送新鮮的魚。為了保鮮，魚必須保存在一定溫度范圍內。如果溫度過高，魚就會變質；而溫度過低，魚的口感和肉質就會變差。為了確認物流公司遵守了合同約定的溫度范圍，超市會在卡車上安裝一個溫度傳感器。

但是，如果卡車司機為了節省電費而調高制冷裝置的溫度，然后把傳感器拿走放到車前的一個冷卻器里怎么辦？傳感器根本不會知道自己被挪動了，只是繼續收集、報告那個恒定在合同約定的溫度范圍里的數據。也就是說，傳感器被騙了。

減輕這種風險的一個方法就是把傳感器也做成硬件接到制冷裝置中，這樣就幾乎不可能被移動了。不過，這種對策仍舊可以通過某種方式避開，比如在傳感器周圍纏一袋冰，而卡車其他部位依舊比合同規定的溫度高。

另一個可能更好的方案（也更貴一點）是給每包魚的包裝上貼個防篡改的密封條，并且在每個包裝上配置一個溫度傳感器。這樣一來，如果司機想要拆開溫度傳感器，他就不得不撕開封條，這樣就很容易被發現是違背了合約的關鍵條款。

就像前面提到的，解決數字/模擬接口的問題需要大量的創造力，且解決方案需要“具體問題具體分析”。