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

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

　　關鍵詞:云計算;區(qū)塊鏈;數(shù)據(jù)共享

　　0引言

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

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

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

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

　　1相關工作

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

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

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

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

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

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

　　2基于云計算的區(qū)塊鏈組網(wǎng)設計

　　2.1當前主流的區(qū)塊鏈組網(wǎng)方案

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

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

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

　　2.2一種非全連接的區(qū)塊鏈組網(wǎng)思路

　　2.2.1結構化模型

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

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

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

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

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

　　2.2.2模型的分解和重構

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

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

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

　　2.2.3組網(wǎng)方案設計

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

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

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

　　3基于云計算的區(qū)塊鏈數(shù)據(jù)存儲機制

　　3.1數(shù)據(jù)存儲架構設計

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

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

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

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

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

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

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

　　3.2典型流程分析

　　3.2.1子網(wǎng)組建流程

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

　　3.2.2數(shù)據(jù)存儲流程

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

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

　　3.2.3數(shù)據(jù)查詢流程

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

　　4實驗與分析

　　4.1實驗數(shù)據(jù)

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

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

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

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

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

　　4.2實驗環(huán)境

　　本文全部應用均基于云平臺進行部署，根據(jù)子網(wǎng)的組建情況動態(tài)分配排序服務器和數(shù)據(jù)庫服務器。

　　4.3實驗結果

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

　　4.3.1吞吐量對比

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

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

　　5結束語

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

　　參考文獻:

　　[1]SAMANIEGOM，DETERSR.BlockchainasaServiceforIoT[C]

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

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

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

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

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

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

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

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