摘要:為解決在區塊鏈上進行數據存儲和共享過程中面臨的交易確認效率低以及存儲空間利用率低的問題，本文提出一種基于云平臺部署的區塊鏈組網方案以及與其適配的數據共享存儲方案。首先，通過對傳統的全連接區塊鏈組網進行分解和重構，形成一種基于子網的非全連接組網方案，將交易確認的范圍限定在有限的節點之內。

　　其次，通過將數據依次劃分為事務數據-敏感狀態數據-非敏感狀態數據3個層次進行管理，節點只保存與狀態轉移相關的事務數據以保障不可篡改性，狀態數據則在云平臺上實現不同程度的共享存儲，最大限度優化了存儲空間。實驗結果表明，該方案可為區塊鏈中可信數據的存儲和共享提供新的思路。

　　關鍵詞:云計算;區塊鏈;數據共享

　　0引言

　　近年來，區塊鏈成為了社會的熱點話題，它通過將點對點傳輸、分布式數據存儲、共識機制、加密算法等技術進行集成，具有不可篡改、可追溯、去中心化等特性，這些特性使得區塊鏈非常適合用于對可信數據進行存儲和共享。

　　目前關于區塊鏈數據存儲和共享機制的相關研究，主要面臨2個問題:1)交易確認效率問題。由于區塊鏈每次狀態的更新都需要得到全網多數節點的確認，形成共識，并向各節點廣播實現賬本的全網同步，因此網絡中參與的節點越多則交易確認的速度越慢。2)存儲空間利用率問題。由于區塊鏈具有不可篡改不可刪除的特性，因此存儲在區塊鏈上的數據只會隨時間不斷增長，長期下來對存儲空間的開銷極大。

　　通過引入云計算的相關理念，可以在一定程度上改善上述問題。區塊鏈與云計算結合，稱為區塊鏈即服務(BlockchainasaService，BaaS)[1]，它可以有效降低區塊鏈部署成本，用云計算快速搭建區塊鏈服務。2015年11月，微軟在Azure[2]云平臺里面提供BaaS服務，并于2016年8月正式對外開放。開發者可以在上面以最簡便、高效的方式創建區塊鏈環境。

　　IBM[3]也在2016年2月宣布推出區塊鏈服務平臺，幫助開發人員在IBM云上創建、部署、運行和監控區塊鏈應用程序。國內的阿里云[4]、騰訊云[5]等也相繼提供了BaaS服務。本文提出一種基于云平臺部署的區塊鏈組網方案以及與其適配的數據共享存儲方案，其主要有3個方面特點:1)引入了非全連接組網的思路，將交易確認的范圍限定在有限的節點之內。2)根據敏感程度對數據進行分層存儲，在保留不可篡改性的前提下，提高了存儲空間利用率。3)針對云計算環境下的部署進行設計，使得用戶可以通過云平臺快速地搭建區塊鏈服務，降低部署成本。

　　1相關工作

　　關于區塊鏈數據的存儲和共享機制，國內外有很多相關的研究，這些研究探討了在不同應用場景下如何在區塊鏈上存儲可信數據，一方面充分利用區塊鏈不可篡改的特性保證數據的安全性，另一方面還需要在保證隱私的前提下將存儲在鏈上的數據共享給具備訪問權限的用戶。文獻[6]研究了醫療數據的共享模型，采用改進的DPOS機制實現節點之間的共識，通過自定義的一套層級存儲結構，最后將所有數據Merkle根錨定到比特幣區塊鏈，實現真正的不可篡改和不可抵賴。

　　文獻[7]研究基于聯盟區塊鏈實現智能電網數據的存儲和共享，文中以數據采集基站作為區塊鏈的節點，對無線傳感網絡的數據進行采集、審計和存儲，進而在網絡節點中進行共享。數據的“記賬權”需要在預選的節點之間通過POW機制進行競爭獲取。文獻[8]研究了人文社科數據共享模型，使用HyperledgerFabric區塊鏈框架作為聯盟鏈的基礎，并對區塊的數據存儲方式進行了改進，用關系型數據庫的存儲方式替代傳統超級賬本的鍵值對數據存儲方式，以提升鏈上數據的查詢處理能力，提高人文社科數據共享平臺的溯源追蹤效率。

　　文獻[9]設計了BBDS系統，為儲存在云平臺中的共享醫療數據提供數據來源、審計和控制，主要解決了在無信任環境中醫療數據的共享問題。該設計采用智能合約和訪問控制機制來有效地跟蹤數據的行為，并在檢測到對數據的權限的違反時撤銷對違規實體的訪問。文獻[10]建立了一個基于HACCP(危害分析和關鍵控制點)、區塊鏈和物聯網的實時食品追蹤食品供應鏈可追溯系統，為所有供應鏈成員提供開放性的信息平臺。

　　供應鏈中的數據通過BigchainDB進行存儲，BigchainDB[11]是由TrentMcConaghy等人提出的一種高可擴容性的區塊鏈數據存儲架構，它繼承了分布式數據庫的特征:吞吐量和容量可根據節點數量線性擴展，提供全功能NoSQL查詢語言，具備較高的查詢效率和完善的權限控制機制。

　　文獻[12]提出了一種基于云計算的物流區塊鏈模型，通過結合區塊鏈共識機制及Hadoop分布式存儲技術，設計了CloudPBFT算法，其相比經典PBFT算法在吞吐量以及網絡延遲時間方面均有所提升。上述的相關工作均在不同程度上改善了交易確認效率和存儲空間利用率的問題，但也存在一定的局限性。從4個角度將本文方案與上述幾種研究成果進行對比評估。

　　本文方案在交易確認效率和存儲空間利用率上占優的原因在于:1)采用了非全連接的組網方案，狀態的更新不需要得到全網多數節點的確認即可達成共識，從而減少了網絡請求量。2)采用了基于云平臺的數據分級存儲的機制，一方面節點只需要保留少量能夠保障不可篡改性的事務數據，另一方面將可共享的狀態數據做進一步的壓縮存儲，達到了更高的空間利用率。

　　2基于云計算的區塊鏈組網設計

　　2.1當前主流的區塊鏈組網方案

　　在主流的區塊鏈架構里，設計者們都追求模型的泛化能力(generalizationability)，試圖在一個軟件層面的框架里，提出一種通用的方法，來解決分布式網絡的節點間的公共狀態的同步和更新問題，而這種方法通常稱為共識算法。當前主流的共識算法包括以數字貨幣為代表應用的公有鏈中使用的POW[13]、POS[14]和DPOS[15]算法，以及聯盟鏈中使用的PBFT[16]、RAFT[17]、Paxos[18]算法等。

　　共識算法的研究通常偏向理論化，其假設任意節點間完全連通且也有必要連通，另外，其假設節點間的信息交互是完全隨機的。全連接模型中，每次狀態的更新都需要得到所有成員的確認。在通常的客戶端-服務器模型中，如果某個節點需要更新N個狀態，其只需向服務器發送N次網絡請求即可;但在全連接網絡中，相應的節點每更新一個狀態，其均需向其他所有節點廣播一次網絡請求，總共的網絡請求量為N×(M-1)，其中，M為分布式網絡的節點總數。

　　當節點總數增加時，交易確認的效率不可避免地受到影響。基于這個考慮，本文將研究現實世界中不同實體間真實的連接關系，嘗試建立一個新的結構化模型，在網絡拓撲層面實現共識算法。

　　2.2一種非全連接的區塊鏈組網思路

　　2.2.1結構化模型

　　所有的算法模型都是模擬自然界或人類社會的行為的，而不論自然界還是人類社會的個體之間，很少有一個個體會和其他所有個體都有交互作用，即全連接模型是幾乎不存在的。通常的情況是，每個個體只與若干個個體有較為緊密的接觸，也就是說，實際的模型是一個由若干個稀疏圖組成的集合。

　　在實際的網絡拓撲結構中，圖與圖之間是沒有任何聯系的，它們之間沒有數據交互。因此，在不同圖之間沒有必要存儲其他圖的內部數據，這是在網絡結構層面實現共識的第一個步驟。在每一個圖的內部，節點間的數據交互關系可以歸結為2種基本模型，分別為單一的主從關系和互為主從關系。其中箭頭所指向的節點稱為“父節點”，箭頭發出的節點稱為“子節點”。在單一主從關系模型中，每一次對賬本的“寫”請求只從父節點發出，子節點只負責對父節點的請求進行校驗。

　　當然，最終能否對賬本進行合法的寫操作，由父子節點共同決定。供應鏈是典型的以單一主從關系為主的結構，數據基本上是單向流動的，比如交易只能由供應商發起，由客戶進行確認。在互為主從關系模型中，每個節點都可以隨機發起寫請求，不存在明顯的隸屬關系。微信這類即時通信工具屬于典型的互為主從關系模型，通信雙方都可以隨時對賬本(聊天記錄)進行“追加寫”操作。

　　嚴格來講，互為主從關系模型也可以分解為2個獨立的單一主從關系模型。是否有必要再進一步細分，可以根據網絡的規模和節點間交易的相關程度來決定。一般來說，網絡規模越大、交易的相關程度越低，越需要細分。

　　在人類社會的經濟活動中，單一主從關系模型是主流，即生產關系是比較穩固的，改變的頻率較小。隨著節點數的增多，以互為主從關系模型為基本組件的結構，在實際事務中將會越來越少。當遇到一個實際問題時，需要分析節點間的邏輯關系，確定具體的實施方案。基本的實施方案主要有2種:1)混合使用2種基本模型進行建模;2)將事務全部分解成單一主從關系進行最終的合成建模。本文的研究將以后一種方案為主。

　　2.2.2模型的分解和重構

　　根據上節的分析，本文將基于單一主從關系模型對現實的經濟活動進行分解，形成一系列較小的結構，并按照一定的順序將這些結構重新組合，從而達到將網絡結構清晰化、交易流程有序化的目的。本文的最終目標是將整個網絡的數據流進行分類處理，而數據流動的方向是通過“邊”來表示的，即需要將原來網絡(簡稱“原圖”)中的“單向邊”進行重新整理。

　　因此，基于原圖進行重構的新圖必須囊括原圖的所有邊(每條雙向邊需拆分成2條單向邊)。首先將原圖的長路徑截短，并將所有指向同一個節點的邊歸為同一類，從而形成一個個基本的單層結構，可將其稱為“原子樹”，寓意為不再細分的樹。

　　一種可行的做法是，依次掃描原圖，找出所有父節點(即存在若干箭頭指向的節點)，并以各個父節點為基礎對原圖進行劃分。然后依次找出每個父節點的子節點，并最終形成若干棵原子樹。其中節點1、2、3是原子樹的父節點，各棵子樹間通過“信使節點”連通，即節點2和3。顯然地，能成為信使節點的節點必須同時鄰接至少一條“入邊”和“出邊”。

　　2.2.3組網方案設計

　　每一棵原子樹中的每一個節點都在共同維護著樹內的數據流，這些數據流有比較大的關聯性，因此，可將原子樹內的交互數據全部寫在同一個分布式賬本里，原子樹內的節點共同組成了一個區塊鏈網絡，本文將其稱為子網。每個子網需包含如下幾個基本角色:1)授權認證節點。即CA，主要采用數字證書機制對網絡中成員身份進行管理。2)普通節點。發起交易或對交易進行簽名背書。

　　3)排序節點。對收到的合法交易在網絡中進行全局排序，并打包成區塊。4)全節點。對區塊進行合法性驗證并維護整個賬本。另外，經過授權的外部節點或客戶端可以獲得對賬本的部分或全部數據的訪問權。由上文可以看出，每新建一個子網，都需要為其分配全節點和排序節點，而由于在云計算環境下，可以非常靈活地分配虛擬機資源并通過腳本實現自動化部署，因此該組網方案在云計算環境下可以達到最高的運作效率。但需要說明的是，在非云計算環境下，組網方案依然是可行的。

　　其中較粗的箭頭表示不同的模塊之間的信息交互，較細的箭頭指示的是模塊內的信息傳遞過程。實線表示該交互過程是主要的，虛線表示該交互過程處于次要地位。

　　3基于云計算的區塊鏈數據存儲機制

　　3.1數據存儲架構設計

　　本文中數據存儲架構的思路來源于HyperledgerFabric[19]項目，這是由IBM牽頭發起的一個代表性的聯盟鏈項目。在Fabric中，賬本是一系列有序的、不可篡改的狀態轉移記錄日志。狀態轉移是鏈碼(chaincode)執行(交易)的結果，每個交易都是通過增刪改操作提交一系列鍵值對到賬本[20]。一系列有序的交易被打包成塊，這樣就將賬本串聯成了區塊鏈。同時，一個狀態數據庫維護賬本當前的狀態，因此也被叫做世界狀態。賬本狀態數據庫實際上存儲的是所有曾經在交易中出現的鍵值對的最新值。

　　調用鏈碼執行交易可以改變狀態數據，為了高效地執行鏈碼調用，所有數據的最新值都被存放在狀態數據庫中。就邏輯上來說，狀態數據庫僅僅是有序交易日志的快照，因此在任何時候都可以根據交易日志重新生成。本文基于這種思想，結合云計算的特性進行了一定的拓展，形成了一種基于云計算的區塊鏈數據存儲機制。該機制將需要存儲的數據拆分為事務數據和狀態數據這2個部分。

　　事務數據即包含與狀態轉移相關的關鍵內容，目的是為了保障整個網絡的保序性和不可篡改性，通過區塊鏈結構進行存儲，一個區塊中應包含如下字段:1)交易詳情。指示在相關節點間實際發生的業務。2)交易的生成者標識。指示該交易是由哪個節點生成的，即生成者的完整簽名。3)交易的驗證者標識。交易的接收方確認交易詳情和其生成者標識是合法的，對交易進行最終的簽名。4)前一區塊的唯一標識。指示當前區塊數據是追加在哪一個區塊后面的，該標識通常是前一區塊序列化后的哈希值。

　　5)區塊號。指示當前區塊是全局的第幾個區塊。6)當前區塊的唯一標識。當前區塊序列化后的哈希值。7)區塊類型。指示當前區塊的種類，比如普通區塊或者創世區塊。狀態數據與上文提到的世界狀態概念相似，為整個子網的全局狀態。Fabric中提供了LevelDB或CouchDB這2種方案供選擇，然而這2種數據庫能支持的查詢方式較少，不能很好地滿足商業級應用復雜的查詢需求。

　　事實上，可以認為只要能通過事務數據來保障賬本的不可篡改，狀態數據完全可以通過其他性能更好的數據庫來存儲。考慮到實際應用中，用戶對于數據的加密級別會有不同的要求，因此狀態數據中又可以分為僅限子網內部成員可見的敏感數據，以及可以與外界共享的非敏感數據。

　　節點A和節點B組成了子網1，節點B和節點C組成了子網2。其中節點B同時存儲了2個子網的事務數據。2個子網分別配備有全節點集群，用于存儲子網中的敏感數據，這部分數據由子網內的節點共享，而對于各個子網的非敏感數據，可以在全網數據共享服務器集群存儲。本文方案中的狀態數據均通過部署在云服務器上的HBase數據庫進行存儲。

　　Hbase[21]是一種分布式、面向列的開源數據庫。該技術來源于Chang所撰寫的BigTable[22]論文，是一種面向海量非結構化數據的高性能存儲方案。HBase支持基于Snappy[23]算法的壓縮存儲功能，可以最大程度節省存儲空間。同時，由于節點擁有與狀態變更記錄直接相關的事務數據的所有權，因此依然能夠有效地防止狀態數據被篡改的情況。

　　3.2典型流程分析

　　3.2.1子網組建流程

　　步驟1所有類型的節點加入網絡前，都需向CA申請相應的證書。步驟2當一個節點想創建一個子網時，其先從CA處獲取相應成員的證書、IP、權限等，并根據IP向其他節點發起組網請求。步驟3組網規則(比如全部節點同意)通過后，由發起初始請求的節點生成經過簽名的創世區塊，并為子網分配排序節點和全節點。

　　3.2.2數據存儲流程

　　步驟1子網內的任意節點生成一條交易/記錄的前提是已經向CA申請了相應的證書以證明其身份。步驟2子網內的節點發起的交易，根據該交易涉及的子網內的成員的數量，需要相應的節點對該交易都進行簽名。比如，節點A發起涉及A、B、C的交易，那么該交易必須含有A、B、C的全部簽名才是合法的，此時不能離線交易，如果該交易僅僅涉及A自身，該交易可離線進行。

　　步驟3收集所有的簽名后，節點A將帶有序號(指示當前是全局的第幾個交易)的該交易發往排序節點，排序節點通過共識/容錯算法，返回接受或者拒絕的響應。步驟4如果排序節點接受該交易，那么將該交易進行簽名并與交易內容的哈希一起廣播至所有節點，此時相當于所有節點同步新增一條事務數據。步驟5與上一步驟同時，排序服務器會將交易分為敏感數據與非敏感數據2種類型，敏感數據提交至子網的全節點服務器存儲，非敏感數據提交至全網數據共享服務器存儲。

　　3.2.3數據查詢流程

　　步驟1節點通過客戶端發起查詢請求，節點所屬的節點首先驗證客戶端的身份和權限。步驟2如驗證通過，分別向全網數據共享服務器和子網全節點服務器發起查詢。步驟3步驟2中的2類服務分別返回請求的敏感及非敏感數據字段信息，節點服務器將其組合后，取哈希值與自身存儲的事務數據進行校驗。步驟4節點將數據返回給客戶端。

　　4實驗與分析

　　4.1實驗數據

　　本文所提出的非全連接組網方案為模擬人類社會行為所設計，因此在使用現實存在的數據模型進行實驗時可以達到最佳的效果。供應鏈是區塊鏈技術當前較為熱門的應用場景，同時也是一種典型的以單一主從關系為主的結構。在供應鏈上，數據基本上是單向流動的，交易由供應商發貨，由客戶進行確認。

　　筆者所在機構在本文基金項目資助下在廣州市多個肉菜批發市場及農貿菜市場對基于區塊鏈的農產品溯源模式進行了一系列的探索，形成了一套包括至少3個層級，100個節點的供應鏈基礎數據模型，代表了從上游供應商-運輸方-批發商-零售商的相互關系。

　　供應鏈基礎數據模型中，每個上游節點可以看做是一個子網的父節點，其下游即為子節點，同時下游本身如果與更下游進行交易，則其自身又可以成為父節點。通過非全連接模型，就可以將一條龐大的供應鏈拆分成一個個子網，下文中將基于該模型進行測試和分析。

　　上文提到的農產品供應鏈溯源應用中，數據主要存儲在以下5個表中:1)Product。當前節點的主營產品信息，包括產品名稱、產地、價格等，這部分數據加密存儲在子網全節點服務器中。2)Customer。當前節點的客戶信息，包括客戶名稱、聯系電話、身份證號、營業許可等，這部分數據加密存儲在子網全節點服務器中。3)Supplier。當前節點的供應商信息，包括供應商名稱、聯系電話、營業許可、經營范圍、地址等，這部分數據加密存儲在子網全節點服務器中。

　　4)Purchase。當前節點的進貨記錄，包括進貨單號、交易日期、進貨明細(包含商品、批次、數量、價格等)、供貨商、總價、運輸物流單等。其中日期、商品、數量等在不暴露節點身份的前提下并非敏感數據，因此可以存儲在全網數據共享服務器中，其余信息加密存儲在子網全節點服務器。5)Sale。當前節點的銷售記錄，包括銷售單號、交易日期、銷售明細(包含商品、批次、數量、價格等)、客戶、總價、運輸物流單等。其中日期、商品、數量等在不暴露節點身份的前提下并非敏感數據，因此可以存儲在全網數據共享服務器中，其余信息加密存儲在子網全節點服務器。

　　4.2實驗環境

　　本文全部應用均基于云平臺進行部署，根據子網的組建情況動態分配排序服務器和數據庫服務器。

　　4.3實驗結果

　　為了驗證本文所提出方案的可行性，下面分別對比了使用全連接組網方案以及本文的非全連接組網方案在不同節點數量情況下的吞吐量，以及使用經典的區塊鏈數據存儲方案以及本文提出的3級數據共享存儲方案的存儲空間效率情況。

　　4.3.1吞吐量對比

　　將供應鏈基礎數據模型中的100個節點進行拆分，分別測試不同節點數量使用全連接組網方案以及非全連接組網方案的吞吐量情況。全連接組網方案在節點數較少的情況下吞吐量較高，但是隨著節點數增加吞吐量會大幅下降，其原因在于，全連接模型中，相應的節點每更新一個狀態，均需向其他所有節點廣播一次網絡請求，總共的網絡請求量為N×(M-1)，其中，M為分布式網絡的節點總數，因此節點數量越多，交易確認的時間越長，吞吐量也就越低。

　　而非全連接組網方案由于將一個大的全連接網絡拆分成了不同的子網，并且交易只需要得到相關方的確認而非所有節點的確認，因此在節點數增多時，其吞吐量的下降趨勢并不明顯。在100個節點的情況下，非全連接組網吞吐量達到了全連接組網的8.8倍。

　　5結束語

　　本文針對在云計算環境下的部署區塊鏈的方案進行了一定的優化，提出一種新的區塊鏈組網機制，提高了網絡的整體吞吐量;同時通過引入基于云計算的數據共享存儲，最大限度優化了存儲空間。后續將在本文理論基礎上繼續深入研究，方向包括:不同數據共享模型應用在區塊鏈數據存儲時的存儲空間、查詢延時、吞吐量的對比;各種意外狀況下(節點離線、惡意節點攻擊、分叉等)該模型的抗風險能力等。

　　參考文獻:

　　[1]SAMANIEGOM，DETERSR.BlockchainasaServiceforIoT[C]

　　[2]Microsoft.AzureBlockchainSolutionArchitecture[EB/OL].[2019-07-15].

　　[3]IBM.TheIBMBlockchainPlatform[EB/OL].[2019-07-15].

　　[4]阿里巴巴.阿里云區塊鏈服務[EB/OL].[2019-07-15].

　　[5]騰訊.騰訊云區塊鏈服務[EB/OL].[2019-07-15].

　　[6]薛騰飛，傅群超，王樅，等.基于區塊鏈的醫療數據共享模型研究[J].自動化學報，2017，43(9):1555-1562.

　　[7]吳振銓，梁宇輝，康嘉文，等.基于聯盟區塊鏈的智能電網數據安全存儲與共享系統[J].計算機應用，2017，37(10):2742-2747.

　　[8]谷俊，許鑫.人文社科數據共享模型的設計與實現———以聯盟鏈技術為例[J].情報學報，2019，38(4):354-367.

　　區塊鏈組網方案投稿刊物：自動化學報(月刊)創刊于1963年，是由中國自動化學會、中國科學院自動化研究所共同主辦的高級學術期刊。刊載自動化科學與技術領域的高水平理論性和應用性的科研成果。