作者：Pika，Sui公鏈大使，DePIN研究員
編輯：Faust，極客web3
導語：儘管DePIN賽道在當下十分火熱，但DePIN相關的物聯網設備要大規模接入區塊鏈，仍有技術上的障礙。一般而言，若要將物聯網硬體連接到區塊鏈中，要經歷以下三個關鍵階段：
1. 硬體設備的可信任運作；
2. 收集驗證並提供資料；
3. 將資料分發到不同應用程式。
這三個階段中存在著不同的攻擊場景與反製手段，需要引入各種機制設計。本文從專案工作流程與協議設計的角度，回顧分析了物聯網設備從可信產生數據，驗證儲存數據，透過運算產生證明，和向區塊鏈rollup數據的整個流程。如果你是DePIN賽道的創業者，希望本文可以在方法論和技術設計上對你的專案發展有所幫助。
下文中，我們以空氣品質檢測的場景為例，結合IoTeX、DePHY、peaq這三個DePIN基礎設施進行分析，向大家闡明DePIN基礎設施是如何運作的。此類基礎設施平台可對接物聯網設備與區塊鏈/Web3設施，幫助專案方快速啟動DePIN應用程式專案。
硬體設備的可信任運行
硬體設備的可信任，包括設備身分的信任與程式執行可驗證無篡改的信任。
DePIN的基礎工作模式
在大多數DePIN專案的激勵方案裡，硬體設備的運作者會對外提供服務，以此為籌碼向激勵系統索取獎勵，例如在Helium中，網路熱點設備透過提供訊號覆蓋，來獲取HNT獎勵。但在從系統中獲取激勵前，DePIN設備需要先出示證據，證明自己的確按要求付出了一定「努力」。
這類用來證明自己在現實世界中提供了某一類服務、進行了某些活動的證明，被稱為物理工作證明(Proof of Physical Work, PoPW)。在DePIN計畫的協議設計中，物理工作證明佔有舉足輕重的地位，相應的也存在各種攻擊場景與對應的反製手段。
DePIN專案要依賴區塊鏈完成激勵分發與代幣分配。類似於傳統公鏈中的公私鑰體系，DePIN設備的身份核驗流程中，也需要使用公私鑰，私鑰用於生成和簽署“物理工作證明”，公鑰則被外界用於驗證上述證明，或作為硬體設備的身份標籤(Device ID)。
除此之外，直接用設備的鏈上地址接收代幣激勵並不方便，因此DePIN項目方往往在鏈上部署一個智能合約，合約中記錄著不同設備持有人的鏈上帳戶地址，類似於資料庫中一對一或多對一的關係。這種方式下，鏈下實體設備應收到的代幣獎勵，可以直接打到設備持有人的鏈上帳戶。
女巫攻擊
絕大多數提供激勵機制的平台，都會遇到“女巫攻擊”，就是說有人可能操控大量的帳號或設備，或是產生不同的身份證明，偽裝成多個人，拿多份獎勵。以我們前面提到的空氣品質檢測為例，提供此服務的設備越多，系統分發出去的獎勵就越多。有人可以透過技術手段，快速產生多份空氣檢測數據以及對應的設備簽名，製造大量的物理工作證明來獲利，這會使DePIN項目的代幣陷入高通脹，所以要製止此類作弊行為。
所謂的反女巫，如果不採用KYC等破壞隱私性的方法，最常見的措施就是POW和POS，在比特幣協議中，礦工要付出大量的算力資源，才能獲得挖礦獎勵，POS公鏈則直接讓網路參與者質押大量的資產。
在DePIN領域中，反女巫可以歸結為“抬高物理工作證明的生成成本”，由於物理工作證明的生成，依賴於有效的設備身份信息（私鑰），所以只要抬高身份信息的獲得成本，就可以防止某些低成本產生大量工作證明的作弊行為。
針對上述目標，一個相對有效的方案是，讓DePIN設備生產商壟斷身份資訊的生成權限，對設備進行客製化處理，為每個設備輸入唯一的身份標籤。這就好比，由公安局統一記錄全體公民的身份信息，只有在公安局數據庫裡可查的人，才有資格領取政府補貼。
在生產環節，DePIN設備廠商會使用程式在足夠長的時間裡產生根密鑰，然後隨機選擇根密鑰使用eFuse技術寫入到晶片中。這裡要科普下，eFuse（可程式電子熔斷器）是在積體電路中儲存資訊的電子技術，所輸入的資訊通常無法被竄改或擦除，具有較強的安全保障。
在這種生產流程下，設備持有者和生產商都無法獲知設備的私鑰，以及根密鑰。硬體設備可以在TEE的隔離環境中，從根密鑰匯出並使用工作金鑰，包含簽署資訊用的私鑰，和交由外界驗證設備身分的公鑰。 TEE環境外的人或程式都無法感知到金鑰的細節。
在上述模式下，如果你想取得代幣激勵，你必須向專屬廠商購買設備。女巫攻擊者若想繞過設備廠商，低成本產生大量的工作證明，就需要破解廠商的安全系統，將自己產生密鑰的公鑰註冊到網路授權設備中去，女巫攻擊者很難以低成本發起攻擊，除非設備生產廠商監守自盜。
而一旦人們發現設備廠商有作惡的可疑跡象，可以透過社會共識的方式對DePIN設備生產廠商進行曝光，這往往會使得DePIN專案本身連帶遭殃。但多數情況下，設備廠商作為DePIN網路協議的核心受益方，大多沒有作惡動機，因為讓網路協議井然有序運轉的話，賣礦機賺的錢會比DePIN挖礦賺的錢多，所以他們更多會傾向於不作惡。
如果硬體設備不是由中心化生產商統一供應的，那麼當任一台設備連接到DePIN網路時，系統要先確認該設備具有協議要求的特性。例如，系統會檢查這些新加入的設備，有沒有專屬的硬體模組，沒有這類模組的設備往往無法通過認證。而要讓設備擁有上述硬體模組，要花一定的資金，這就抬高了女巫攻擊的成本，進而達到反女巫的目的。在這種情況下，還是正常運作設備而非製造女巫攻擊更為明智和穩健。
資料篡改攻擊
讓我們腦洞一下，如果某台設備收集到的空氣品質檢測數據，其波動性越強，系統就認為數據更有價值，並為此提供更多獎勵，那麼任何設備都有充足的動機偽造數據，讓其故意表現出高波動性。即便是由中心化廠商做身份認證的設備，也可以在數據計算過程中“夾帶私貨”，對收集到的原始數據進行改寫。
該如何保證DePIN設備是誠實可信的，沒有對收集到的數據進行肆意修改？這需要用到可信任韌體(Trusted Firmware)技術，其中較為出名的是TEE(Trusted Execution Environment), 還有SPE(Secure Processing Environment).。這些硬體層面的技術，可以保障資料在設備上依照事先驗證過的程序來執行，計算過程中沒有「夾帶私貨」。
這裡簡單介紹下，TEE(可信任執行環境)通常是在處理器或處理器核心中實現的，用於保護敏感數據，執行敏感操作。 TEE提供了一個受信任的執行環境，其中的程式碼和資料能夠受到硬體層級的安全保障，以防止惡意軟體、惡意攻擊或未經授權的存取。例如, Leger, Keystone這些硬體錢包都有使用到TEE技術。
大多數現代晶片都支援TEE，尤其是針對行動裝置、物聯網設備和雲端服務的晶片。通常情況下，高效能處理器、安全晶片、智慧型手機SoC（系統級晶片）和雲端伺服器晶片都會整合TEE技術，因為這些硬體涉及的應用場景，往往對安全性有較高的追求。
但是，不是所有的硬體都支援可信任韌體，一些較低端的微控制器、感測器晶片和客製化的嵌入式晶片可能缺乏對TEE的支援。對於這些低成本晶片，可以透過探針攻擊等手段去獲取晶片內留存的身份訊息，進而偽造設備身分和行為。例如，攻擊獲取到晶片上保存的私鑰數據，然後使用私鑰對篡改或偽造的數據進行簽名，偽裝成設備自身運行生成的數據。
但探針攻擊依賴專門設備和精確的操作、數據分析流程，攻擊成本過高，遠高於從市場直接取得這類低成本晶片的成本。相較於透過探針攻擊等手段破解偽造低端設備的身份資訊來獲利，攻擊者會更願意直接購買更多台低成本的設備。
資料來源攻擊場景
前面提到的TEE可以保證硬體設備如實的生成數據結果，只能證明數據在輸入到設備內部後，沒有被惡意的處理，但無法確保數據在進行計算處理前，其輸入源頭可信，這其實類似預言機協議面對的難題。
例如，某台空氣品質檢測儀，被放置在了排廢氣的工廠附近，但有人在夜裡用密閉的玻璃罐把空氣品質檢測儀罩起來，那麼這台空氣檢測儀所獲得的數據必定不真實。但上述攻擊場景往往無利可圖，攻擊者大多時候沒必要這麼做，因為是費力不討好。對於DePIN網路協定而言，只要設備滿足誠實可信的運算過程，付出了滿足激勵協議所要求的工作量，理論上就該獲得獎勵。
方案介紹
- IoTeX
IoTeX提供了W3bStream開發工具，將物聯網設備接入區塊鏈和Web3當中。在W3bStream物聯網端的SDK中, 包含了通訊和訊息傳遞、身分和憑證服務以及密碼學服務等基本元件。
W3bStream的IoT SDK 對加密功能的開發非常完善，包含多種加密演算法的實現，例如PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, Root of Trust 等模組。
有了這些模組，可以在各種硬體設備上，用安全或欠安全的方式去對設備產生的資料進行簽名，並透過網路傳遞到後續資料層供驗證。
- DePHY
DePHY在物聯網端提供了DID(Device ID)認證服務。 DID由生產商鑄造，每個設備都有且僅有一個對應的DID。 DID的元資料可以自訂，可以包含設備序號、型號、保固資訊等等。
對於支援TEE的硬體設備，最開始由生產商產生金鑰對，使用eFuse將金鑰寫入晶片中，而DePHY的DID服務，可以幫助生產商根據設備公鑰來產生DID. 而生產商產生的私鑰除了寫入物聯網設備，就只有生產商持有。
由於可信任韌體可以實現安全可靠的訊息簽章與硬體端私鑰保密，如果人們發現網路中存在作弊產生裝置私鑰的行為，基本上可以認為是裝置生產商在作惡，就可以溯源到對應的生產商身上，實現信任溯源。
DePHY的用戶在買進設備後，可以取得設備的啟動訊息，再呼叫鏈上的啟動合約，將硬體設備的DID與自己的鏈上位址關聯綁定，進而接取到DePHY網路協定中。物聯網設備經過DID設定流程後，就可以實現使用者與設備之間的資料雙向流動。
當使用者透過鏈上帳戶向設備發送控制指令時，流程如下：
1. 確認使用者擁有存取控制權限。由於設備的存取控制權限以metadata 的形式寫在DID 上，可以透過檢查DID來確認權限；
2. 允許使用者和裝置開通私密通道建立聯接來支援使用者控制設備。 DePHY relayer 除了NoStr relay 外，還包含peer-to-peer 的網路節點，可以支援點對點通道，由網路裡的其他節點幫忙中繼流量。可以支援用戶在鏈下即時控制設備。
當物聯網設備向區塊鏈發送資料時，後續資料層會從DID上讀取設備的許可狀態，只有透過註冊被許可的設備才能上傳資料。例如被生產商註冊過的設備。
這個DID服務另一項有趣的功能在於提供了物聯網設備的功能特性(trait)認證。這項認證可以識別出物聯網硬體設備是否具有某些特定功能，達到足以參與特定區塊鏈網路的激勵活動的資格。例如一台WiFi發射器，透過辨識到具有LoRaWAN的功能(trait)，可以認為具有提供無線網路連線的作用，也就可以參與到Helium網路中。類似的，還有GPS trait, TEE trait等。
在拓展服務方面，DePHY的DID也支持參與質押，連結可程式錢包等，方便參與鏈上活動。
- peaq
peaq的方案比較奇特，它的方案分為三個等級，分別是源自設備的認證、模式識別校驗、基於預言機的認證。
1.源自設備的認證。 peaq同樣提供了產生金鑰對，在裝置上使用私鑰簽署訊息，將裝置位址peaq ID 綁定使用者位址等功能函數。但是，在他們的開源程式碼中卻找不到可信韌體的功能實作。 peaq簡單的使用私鑰對設備資訊進行簽署的認證方式，並不能保證設備的誠信運作和資料未經篡改。 peaq比較像是樂觀Rollup，預設裝置不會作惡，然後在後續階段去驗證資料的可信狀況。
2.模式識別校驗。第二個方案是結合機器學習、模式辨識。透過學習之前的資料得到模型，當新的資料輸入時，與先前的模型做比較，判別是否可信。但統計模型其實只能辨識出異常數據，無法判斷物聯網設備是否誠實運作。
例如，城市A中的某台空氣品質檢測儀放置在了地下室，收集產生的數據與其他空氣品質檢測儀都不一樣，但不代表數據偽造，設備仍在誠實運作。另一方面，只要收益夠大，駭客也願意使用GAN等方法，產生機器學習難以鑑別的數據，尤其是判別模型公開共享的情況下。
3.基於預言機的認證。第三個方案是他們會挑選一些更受信任的資料來源作為預言機，與其它DePIN設備收集上來的資料進行比較驗證。例如，專案方在城市A部署了一台精確的空氣品質檢測儀，其他空氣品質檢測儀收集的數據如果偏差太大，就被認為不可信。
這種方式一方面引入區塊鏈並依賴權威，另一方面，也可能因為預言機資料來源的取樣偏差，而使得整個網路資料採樣都出現偏差。
就目前的資料來看，peaq的基礎設施，在物聯網端無法保證設備和資料的可信任。 （註：筆者查閱了peaq的官網、開發文件、Github倉庫，以及一份僅有的2018年白皮書草稿。即使向開發團隊發送郵件，也未能在發稿前得到更多補充說明資料）
數據的產生與發布（DA）
DePIN工作流程中第二個階段主要是收集、驗證物聯網設備傳遞過來的數據，保存起來向後續階段提供數據，要確保數據能完整無誤、可被還原的發送給特定接收方，這被稱為資料可用性層(DA層)。
物聯網設備往往透過HTTP, MQTT等協議，將資料和簽章認證等資訊廣播出去。而DePIN基礎設施的資料層在接收到設備端的資訊時，需要驗證資料的可信度，把通過驗證的資料匯集起來。
這裡介紹下，MQTT(MQ Telemetry Transport)是一種輕量級的、開放的、基於發布/訂閱模式的訊息傳輸協議，旨在用於連接受限的設備，如感測器和嵌入式系統，在低在頻寬和不穩定網路環境下進行通信，非常適合物聯網(IoT)應用程式。
在驗證物聯網設備訊息的環節，將包含設備可信任執行的認證和訊息的認證。
設備可信任執行的認證可以結合TEE.。 TEE透過將資料收集程式碼隔離在裝置的受保護區域中，確保了資料的安全收集。
另一種方式是零知識證明，這種方法使得設備能夠證明其資料收集的準確性，同時又不洩漏底層資料的細節。這種方案因設備而異，對於性能強大的設備，可以在本地生成ZKP，對於受限的設備，則可以進行遠端生成。
在認證了設備的信任之後，使用DID去驗證訊息簽名，就可以確定訊息是由該設備產生。
方案介紹
- IoTeX
在W3bStream中，分為可信任資料收集、驗證，資料清洗，資料儲存這三個部分。
- 可信資料的收集、驗證使用了TEE和零知識證明的方法。
- 資料清洗是指將來自不同類型裝置上傳的資料格式統一化、標準化，以便於儲存和處理。
- 資料儲存環節，讓不同應用項目透過配置儲存適配器來選擇不同的儲存系統。
在目前的W3bStream實作中，不同的物聯網設備可以直接把資料傳送給W3bStream的服務終端，也可以先把資料通過伺服器收集後，再傳送給W3bStream的伺服器終端。
在接收到傳入的資料時，W3bStream會像一個中心分發調度器那樣，將傳入的資料分發給不同的程序去處理，而W3bStream生態內的DePIN項目，會在W3bStream上申請註冊, 並定義事件觸發邏輯(Event Strategy)和處理程序(Applet).
每部物聯網設備都會有設備帳號(device account), 歸屬於一個而且也只能有一個W3bStream上的項目。因此，當物聯網設備的消息傳遞到W3bStream服務連接埠時，可以先根據註冊綁定訊息，重定向到某個項目，並驗證資料的可信性。
至於前面提到的事件觸發邏輯，可以定義從HTTP API終端、MQTT話題接收到的數據信息，以及檢測到區塊鏈上的事件記錄，檢測到區塊鏈高度等可以被觸發的事件(Event triggers )類型，並且綁定對應的處理程序去處理。
處理程序(Applet)中定義了一個或多個執行函數，被編譯成了WASM格式。資料的清洗和格式整理就可以透過Applet去執行。處理之後的資料被存放到由專案定義的key-value資料庫中。
- DePHY
DePHY專案採用了更為去中心化的方式來處理和提供數據，他們稱之為DePHY訊息網路(DePHY Message network).
DePHY訊息網路由無許可的DePHY中繼節點(relayer)組成。物聯網設備可以透過任一DePHY中繼節點的RPC連接埠將資料傳入，傳入的資料會先呼叫中間件，並結合DID去驗證資料可信任。
透過信任驗證的資料需要在不同的中繼節點之間同步，形成共識。 DePHY訊息網採用了NoStr協定來實現。 NoStr原本的用途是用來建構去中心化的社群媒體，還記得之前有人用NoStr代替Twitter而大火麼，用在DePIN資料的同步中居然也巧妙的合適。
在DePHY網路中，每台物聯網裝置儲存的資料片段，都可以被組織成一棵Merkle樹，節點間會彼此同步這棵Merkle樹的root，以及整棵樹的tree雜湊。當某位Relayer得到上述Merkle Root和Tree雜湊後，可以快速定位還缺少哪些數據，方便從其他Relayer中取得補齊。這種方法能異常有效率地達成共識確認(Finalize)。
DePHY訊息網路的節點運作是Permissionless的，任何人都可以質押資產並運行DePHY網路節點。節點越多，網路的安全性越高，可訪問性越強。 DePHY節點可以透過zk條件付款(Zero-Knowledge Contingent Payments)的方式，獲得獎勵。也就是說，有資料索引需求的應用，在向DePHY中繼節點請求資料時，根據可否檢索資料的ZK證明，來決定向中繼節點支付多少費用。
同時，任何人都可以接取DePHY網路來監聽、讀取資料。專案方營運的節點可以設定過濾規則，只儲存與自己專案相關的DePIN設備資料。由於沉澱了原始數據，DePHY訊息網路可以作為後續其他任務的資料可用層。
DePHY協定會要求中繼節點在運作時至少把接收到的資料在本地儲存一段時間，再把冷資料要轉存到Arweave 這個永久性的儲存平台上。如果全部資料當作熱資料去處理，最終會抬高節點的儲存成本，進而提高全節點運作門檻，使得一般人難以運作全節點。
透過冷熱資料分類處理的設計，DePHY能大幅降低訊息網路中全節點的運作成本，更能應付海量的物聯網資料。
- peaq
前面的兩種方案都是把資料的收集儲存放在鏈下去執行，然後Rollup到區塊鏈上去。這是因為物聯網應用產生的資料量本身極大，同時又有通訊延遲的要求。如果在區塊鏈上去直接去執行DePIN交易，資料處理能力有限且儲存成本很高。
單是等待節點共識就帶來不可忍耐的延時問題。 peaq卻另闢蹊徑，自己搭建了一條公鏈，直接承載和執行這些計算和交易。它是基於Substrate開發的，當主網實際上線後，承載的DePIN設備增多，將會因為peaq的性能瓶頸，最終無法承載那麼大量的計算和交易請求。
由於peaq沒有可信任韌體的功能，基本上無法有效驗證資料的可信。在資料儲存方面，peaq直接在開發文件中介紹如何給基於substrate的區塊連結入IPFS分散式儲存。
將數據分發到不同應用
DePIN工作流程中的第三階段，是根據區塊鏈應用的需求，將資料可用層的資料抽取出來，透過執行運算或零知識證明，把執行結果有效率地同步到區塊鏈上。
方案介紹
- IoTeX
W3bStream把這一階段稱為資料證明聚合(Data Proof Aggregation)。這部分網路由許多聚合器節點(Aggregator Nodes)組成一個計算資源池(computing resource pool), 給所有的DePIN專案共享呼叫。
每個聚合節點會在區塊鏈上記錄自己的工作狀態，是忙碌還是空閒。當有DePIN專案的運算需求過來時，根據鏈上的狀態監控(monitor)選擇空閒的聚合器節點去處理。
被選中的聚合器節點，會先從儲存層檢索需要的資料；然後根據DePIN專案的需求對這些資料做運算，並且產生運算結果的證明；最後把證明結果發送到區塊鏈上給智能合約去驗證。完成工作流程之後，聚合器節點重新回到空閒狀態。
而聚合器節點在產生證明時，會用到分層聚合電路(layered aggregation circuit)。分層聚合電路包含四個部分：
- 資料壓縮電路：類似Merkle樹，驗證所有收集的資料都來自特定的Merkle樹根。
- 簽章批次驗證電路：批次驗證來自裝置的資料的有效性，每個資料都與一個簽章相關聯。
- DePIN計算電路：證明DePIN設備按照特定計算邏輯正確執行了一些指令，例如在醫療健康項目中驗證步數，或在太陽能發電廠中驗證產生的能量。
- 證明聚合電路：將所有證明聚合成單一的證明，以供Layer1智能合約最終驗證。
資料證明聚合對於確保DePIN專案中計算的完整性和可驗證性至關重要，為驗證鏈下計算和資料處理提供了可靠且高效的方法。
IoTeX的收益環節也主要在這一階段，用戶可以透過質押IOTX代幣，運行聚合器節點。越多聚合器的參與，也就能帶來更多的運算處理能力，形成算力充足的運算層。
- DePHY
在資料分發層面，DePHY提供了協處理器來監聽DePHY 訊息網路的finalized 訊息，進行狀態遷移(State change)後，將資料打包壓縮並提交到區塊鏈。
狀態遷移是用於處理訊息的類別智能合約的函數，由不同DePIN項目方定制，還包括zkVM或TEE的計算打包資料處理方案。這部分由DePHY團隊向DePIN專案方提供專案鷹架(Scaffold)來開發和部署，具有很高的自由度。
除了DePHY提供的co-processor, DePIN專案方也可以根據專案腳手架將DA層的資料連接到其他基礎設施的運算層，實現上鍊。
綜合分析
儘管DePIN賽道火熱，物聯網設備要大規模接入區塊鏈，仍有技術上的障礙。本文從技術實現的角度，回顧分析了物聯網設備從可信任產生數據，驗證儲存數據，透過運算產生證明和向區塊鏈rollup數據的整個流程，從而支援將物聯網設備整合到Web3應用中。如果你是DePIN賽道的創業者，也希望本文可以在方法論和技術設計上能對專案發展有所幫助。
在選擇分析的三個DePIN基礎設施中，peaq仍然像六年前網路上的評論一樣，is just hype. DePHY 和IoTeX 都選擇了鏈下收集物聯網設備數據，然後rollup到鏈上的工作模式，能夠在低時延、保證設備資料可信賴的條件下，將物聯網設備資料接取到區塊鏈。
DePHY 和IoTeX 又各有側重，DePHY的DID包含了硬體功能trait的驗證，雙向資料傳輸等特點，DePHY訊息網路更注重於去中心化的資料可用層，更多是作為低耦合的功能模組與DePIN專案結合；IoTeX的開發完整度很高，有完整的開發工作流程，更著重於給不同事件綁定處理程序，偏向計算層。 DePIN專案方可依實際需求，選擇不同的技術方案去組合。
參考資料
https://www.trustedfirmware.org/
https://www.digikey.com/en/blog/three-features-every-secure-microcontroller-needs
https://medium.com/@colbyserpa/nostr-2-0-layer-2-off-chain-data-storage-b7d299078c60
https://transparency.dev/
https://github.com/Sovereign-Labs/sovereign-sdk
https://github.com/nostr-protocol/nips
https://iotex.io/blog/w3bstream/
https://w3bstream.com/#sdks
https://docs.w3bstream.com/sending-data-to-w3bstream/introduction-1/technical-framework
https://dephy.io/
https://docs.peaq.network/
https://docs.peaq.network/docs/learn/dePIN-functions/machine-data-verification/machine-data-verification-intro
https://depinhub.io/
https://tehranipoor.ece.ufl.edu/wp-content/uploads/2021/07/2017-DT-Probe.pdf
https://multicoin.capital/2022/04/05/proof-of-physical-work/