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