適用于物聯網數據共享的區塊鏈節點存儲優化方案*

陳鵬閣，柏粉花，張 弛，江年旗

（1.昆明理工大學 信息工程與自動化學院，云南 昆明 650500；2.昆明理工大學 云南省計算機技術應用重點實驗室，云南 昆明 650500）

0 引言

近些年來，物聯網作為通信行業的核心領域發展十分迅速，它具有巨大的技術、社會和經濟意義[1]。與此同時，數據共享已經發展成為物聯網的核心應用之一，收集于物聯網的數據經過有效的處理后可以用于服務許多不同類型的應用。傳統的物聯網數據共享多依托基于云的第三方進行，用戶將從各類物聯網設備收集到的數據上傳到第三方的云，并與其他利益相關者進行數據共享[2]。在這種共享機制下，用戶以及物聯網設備都必須信任第三方服務提供商，可能還需要支付額外的服務費用。此外，這種集中式的數據共享方式還需要在第三方服務提供商、物聯網設備以及用戶之間建立協議，這些協議大多是靜態的，需要花費大量的時間和管理才能建立，大大降低了數據共享的效率。因此，傳統的集中式數據共享機制難以擴展，不能滿足未來物聯網數據共享的需求[3]。

近年來隨著區塊鏈的發展，眾多國家政府、企業和研究機構開始關注并重視這一新興的信息技術[4]。在我國“十四五”規劃綱要中，區塊鏈被列為七大數字經濟重點產業之一，并且目前已經被應用于數字資產交易、物流管理、智慧城市和物聯網等諸多領域，助力實體經濟轉型升級[5]。其中，區塊鏈和物聯網共同具備的分布式特性使它們能夠有效地結合在一起[6,7]，在物聯網數據共享場景中，應用區塊鏈技術，可以將相應的共享交易通過部署在區塊鏈上的智能合約自動管理，不需要手動驗證支付和預定義。與依托第三方的集中式業務場景相比，基于區塊鏈的物聯網數據共享可以有效地提高用戶信任度，降低運行成本，提高共享效率。

然而，隨著時間的推移，區塊鏈賬本所需的存儲空間在不斷增加，以比特幣系統為例，其每年的存儲開銷在50 GB 以上，經過10 年以上的運行，其存儲開銷已經十分龐大，這個問題在資源有限的物聯網中顯得更加突出，愈來愈大的存儲開銷已經成為物聯網設備加入數據共享的阻礙。

研究人員對區塊鏈的存儲優化問題已經進行了許多研究，其中對于鏈上存儲優化方案來說，中本聰最早提出了簡單支付驗證（Simplified Payment Verification，SPV）輕節點方案[8]，它允許存儲資源不足的節點只存儲區塊頭即可，這類節點就被稱為輕節點。后續，又陸續出現了一些存儲方案，這些都可以歸結為類輕節點方案，其中比較著名的方案有Jidar[9]方案和CUB[10]方案。Jidar 方案允許節點只存儲自己感興趣的交易事務和Merkle 根，而CUB 方案引入信任單元，使一個單元的節點共同維護一份完整的區塊鏈數據副本。這些方案都能夠在一定程度上減少區塊鏈節點的存儲開銷，但是對于基于區塊鏈的物聯網數據共享場景來說，這些研究方案存在以下不足：

（1）SPV 方案雖然要求網絡內必須存在存儲完整區塊鏈賬本的全節點，但是輕節點數量過多的話，會出現賬本只由少部分全節點維護的情況，這與區塊鏈的“去中心化”理念并不相符。類輕節點方案雖然由區塊鏈中的所有節點共同維護區塊鏈賬本，但是缺乏存儲完整區塊鏈數據的全節點。在物聯網數據共享場景中，對交易數據的驗證和溯源是非常必要的，所以其網絡中必須存在存儲完整區塊鏈賬本的節點以方便驗證。

（2）現有的區塊鏈節點存儲優化方案絕大多數是對經過共識并且出塊的區塊進行處理，即只是從區塊鏈技術架構的網絡層進行改進，并不涉及區塊鏈的共識機制[11]，步驟繁瑣，效率不高。

針對上述問題，本文面向基于區塊鏈的物聯網數據高共享場景，提出一種區塊鏈節點存儲優化方案，該方案結合物聯網數據共享場景業務需求，利用基于域的區塊鏈存儲模型，引入部分重復（Fractional Repetition，FR）碼，對實用拜占庭容錯[12]（Practical Byzantine Fault Tolerance，PBFT）算法進行改進，在保證共識效率的前提下，在共識過程中對區塊鏈賬本進行優化存儲，大幅降低節點的存儲開銷。

1 方案設計

1.1 部分重復碼

由于本文在改進共識算法時引入了部分重復碼的概念，所以在此對其進行介紹。

部分重復碼[13]的概念由Rouayheb 等人在極大距離可分（Maximum Distance Separable，MDS）碼的基礎上提出，可以實現非編碼的精確修復，簡單來說，就是當系統中的某節點失效時，它可以從其他節點下載編碼數據片段存儲到替換節點，而不需要額外的計算，適合資源有限的物聯網場景。

FR 碼的外部采用MDS 碼，內部采用重復碼，其編碼過程可以描述為，首先，原始數據被分成j個數據片段后，經MDS(m,j)編碼，生成大小相同的m個編碼數據片段；其次，將m個編碼數據片段復制γ倍，分散放置到系統中的n個存儲節點中，每個節點存儲p個編碼數據片段；最后，經過該編碼操作即可得到FR(n,p,γ)碼，滿足公式：

式中：r=m-j（m>j）為校驗片段。FR碼具備MDS特性，即從m個片段中任取j個即可解碼獲得完整數據。

以FR(4,3,2)碼為例，其構造過程如圖1 所示。當FR 碼的重復率γ=2 時，多采用MacWilliams 提出的基于正則圖的FR 構造法，4 個角落代表4 個節點，與之連線上對應的數字即表示在此次構造中，節點被分配得到的編碼片段。正則圖構造法是最簡單，也是用得最多的一種FR 碼構造方式。當重復率γ>2 時，就要選擇其他的構造方法，具體參考文獻[14]和文獻[15]。

圖1 基于正則圖的FR(4,3,2)構造

1.2 存儲模型

為了降低節點的存儲開銷，同時滿足基于區塊鏈的物聯網數據共享場景中交易驗證、交易溯源等業務需求，本文提出基于域的區塊鏈存儲模型，如圖2 所示。

在該存儲模型中，節點類型被分為主節點、值班節點和普通節點。網絡被劃分成了n個域，每個域中的節點類型包含1 個值班節點和k-1 個普通節點，此時域的大小記為k。在這個存儲模型中，由主節點充當編碼器，在共識過程中對上鏈交易數據進行編碼，將編碼片段廣播給各個值班節點和普通節點。值班節點和普通節點負責對上鏈數據進行共識，共識結束后，值班節點存儲完整區塊鏈數據和編碼片段，普通節點只存儲區塊頭和編碼片段。

在這個存儲模型中，絕大多數的節點類型均為存儲少量數據的普通節點，可以大幅降低該區塊鏈系統的存儲開銷。同時，存在值班節點存儲完整數據和編碼片段，可以提供交易驗證和數據恢復的服務。此外，該存儲模型中的區塊鏈賬本由所有節點共同維護，符合區塊鏈“去中心化”的思想。

1.3 PBFT 改進

區塊鏈的類型可以根據其適用場景分為公有鏈、私有鏈和聯盟鏈3 種。公有鏈即比特幣、以太坊等項目所采用的區塊鏈，這類區塊鏈不需要權限，任何人均可進入，去中心化程度最高，但是吞吐量低，并不適用于商業場景。私有鏈則一般用于組織或企業內部，開放程度低，也不適用于商業場景。聯盟鏈的開放程度介于二者之間，多采用PBFT 和其改進算法等快速共識算法，具有較高的吞吐量，所以受到各種商業場景的青睞。本文面向物聯網數據共享場景，引入FR 碼對PBFT 算法進行修改，降低節點的存儲開銷。

改進過的PBFT 算法包含主節點、值班節點和普通節點3 種節點類型，經請求（Request）、預準備（Pre-prepare）、準備（Prepare）、提交（Commit）、回復（Reply）5個步驟達成共識。具體步驟描述如下：

（1）Request：由客戶端或其他節點向主節點發送請求消息，t為時間戳，z為請求上鏈數據。

（2）Pre-prepare：主節點對z進行MDS(m,j)編碼，生成m個編碼片段zf，之后，向網絡中的其他節點發送預準備消息<zfs>，v為視圖編號，l為該請求交易的編號，d為z的摘要，zfs 為編碼片段。此處，主節點以構造FR 碼的方式向其他節點廣播預備消息。不同的是，傳統FR 碼要求n個節點中的每個節點獲得p個編碼片段，而在此要求主節點以域為單位向n個域發送編碼片段，每個域中的k個節點獲得相同j個編碼片段，其中包括p個固定編碼片段和q個任意其他編碼片段，以保證這些節點能夠順利解碼獲得數據進行共識。

（3）Prepare：收到預準備消息的普通節點和值班節點利用j個編碼數據片段進行解碼獲得完整上鏈數據，之后驗證預備消息的合法性，驗證通過后向其他節點廣播準備消息。i為該節點的序號。當該節點在收到至少2f（f為PBFT算法能夠容忍的作惡節點數量）個其他節點的驗證通過消息時，代表Prepare 階段完成。

（4）Commit：節點廣播確認消息，當節點收到2f+1 個來自不同節點的確認消息時，證明該條請求被通過，執行請求內容并寫入日志。若該節點為值班節點，則存儲和，即完整的區塊信息，包括區塊頭和區塊體，以及在本輪共識中的編碼數據片段；若該節點為普通節點，則存儲，即區塊頭和p個FR碼要求的固定編碼片段。

（5）Reply：每個節點向客戶端或請求發起者，單獨發送回復消息，0 為執行結果。

2 實驗與分析

2.1 性能測試與分析

本文使用JAVA 語言搭建了一個區塊鏈系統實驗平臺，系統的底層技術包括分布式數據存儲、Spring 框架、gRPC 通信機制等。為了減少網絡問題對本實驗的影響，實驗平臺部署在OpenStack 云平臺中，部署多臺配置相同的虛擬機作為區塊鏈網絡節點，數據庫和Redis 分別運行在docker 環境中，具體物理配置如表1 所示。

表1 節點物理配置

2.1.1 FR 碼的編碼解碼速度測試

在本次測試中，FR 碼的外部MDS 編碼采用RS 碼，這是一種已經被廣泛運用于存儲系統中的經典MDS 碼。區塊大小被設置為1.12 MB，其大小與主流區塊鏈系統的區塊大小類似。實驗測試了在不同情況編碼參數下采用FR 碼對區塊數據進行編碼和解碼的速度，結果如圖3 和圖4 所示，其中橫坐標代表參數j，縱坐標代表編碼速度與解碼速度。

圖3 FR 碼編碼速度

圖4 FR 碼解碼速度

從實驗結果可以發現，FR 碼的編碼速度和解碼速度是相當快的，在r=2 時，FR 碼的編碼速度能達到2 200 MB/s，解碼速度最低也在200 MB/s 左右，對于一個1 MB 左右的區塊來說，解碼和編碼都在毫秒間完成。由此可以得出結論，FR 碼的性能優越，這不僅有利于FR 碼存儲系統的維護，也說明編碼解碼過程并不會拖慢PBFT 的共識進程。

2.1.2 PBFT 的TPS 測試

實驗通過測試共識算法每秒鐘能夠處理的事務（Transaction Per Second，TPS）來評估共識算法的性能，定義TPS 的計算式為：

式中：?t為一個區塊的生成時間；trans_number為一個區塊內包含的交易數目。

在測試中，區塊鏈系統采用原始PBFT 算法和基于FR(4,3,2)碼的改進的PBFT 算法對來自Redis緩存數據庫的模擬測試數據進行共識。測試數據是模擬物聯網數據共享的交易數據，設置為20個普通非空字段。測試結果均在共識結束后，由統一計算交易數目和共識時間得出。單個區塊的trans_number被設置為2 000，此時區塊大小約為1.12 MB。實驗對連續20 輪共識的時間進行測試和分析，結果如圖5 所示，其中橫坐標代表共識輪次，縱坐標代表TPS。

從圖5 中可以看出，改進過的PBFT 算法的TPS較原始PBFT 算法并未出現下降的情況，這是因為在測試中發現，PBFT 算法的共識過程用時在數秒內，而FR 碼的編碼解碼過程用時在毫秒級別。由此可以分析得出，在PBFT 算法中引入FR 碼，對區塊鏈賬本進行優化存儲的方案具有可行性。

圖5 PBFT 和改進后的PBFT 的TPS 對比

2.2 容錯性分析

在FR 碼中，當失效節點或者離線節點的數量小于等于γ-1 時，FR 碼能夠進行非編碼修復，但一旦失效節點或離線節點的數量達到甚至超過γ，即某編碼數據片段的所有副本全部丟失，該存儲系統就丟失了非編碼修復的特性。本文通過分析本方案中FR碼的非編碼修復失敗率來評估它的容錯性，容錯性與非編碼修復失敗率成反比，即非編碼修復失敗率越低，該編碼的容錯性就越高。

雖然聯盟鏈嚴格控制節點的出入，但是節點的錯誤離線行為是不可控的，本文用作為FR 碼的非編碼修復失敗率，那么在域大小為k的情況下（不考慮值班節點），本方案中FR 碼非編碼修復失敗率表示為F k。本文分析了在不同參數下，傳統FR 碼與本方案中FR 碼的非編碼修復失敗率，結果如表2 所示。

表2 不同參數下的FR 碼的非編碼修復率

從表2 可以看出，本方案的非編碼修復失敗率遠小于傳統FR 碼，且隨著k增大呈指數級下降，因此可以得出結論，本存儲優化方案相較于傳統FR 碼具有更高的容錯性。

2.3 存儲開銷分析

為了更加直觀地評估本存儲優化方案的效果，本文在節點相同的條件下，將本方案與CUB 方案的存儲開銷減少率和數據丟失率進行對比（不考慮值班節點，r=2，k=4）。本方案的存儲開銷減少率即為1-p/j，而數據丟失率即為非編碼修復失敗率。對比結果如圖6 所示。

圖6 本方案與CUB 方案效果對比

從圖6 中可以看出，采用FR 碼的本方案與CUB 方案均大幅降低了節點的存儲開銷。此外，CUB 方案的存儲開銷減少率一直維持在0.9 以上，而本方案的存儲開銷減少率隨著節點數量從0.667不斷攀升至0.867，這是因為在本次對比中，域的大小k被固定為4，隨著節點的數量增加，本方案中的域數量n在不斷增加，節點的存儲開銷逐漸下降。因此可以得出結論，在節點數量比較少的情況下，CUB 的存儲效率優于本方案，但是隨著節點數量增加，這個優勢會逐漸縮短甚至消失，從而凸顯了本方案的一個優勢，即可以根據實際應用場景調節參數以調整節點的存儲成本。同時，從圖6 中還可以看出，本方案的數據丟失率明顯優于CUB方案，可以提高數據的可靠性。此外，本方案的存儲過程在共識過程中完成，相較于CUB，在共識結束之后處理效率更高。

3 結語

本文提出了一種適用于物聯網數據共享場景的區塊倆存儲優化方案，該方案給出了一種適用于物聯網數據共享的存儲模型，引入FR 碼的概念對PBFT 算法進行修改，在共識過程中完成區塊鏈賬本的存儲優化。仿真結果表明，本方案在保證算法的共識效率和編碼方案的容錯性的前提下，大幅降低了節點的存儲開銷，為基于區塊鏈的物聯網數據共享場景下的存儲優化提供了一種新思路。