蘇芮,裘炅
(杭州電子科技大學計算機學院,杭州 310000)
近幾年來,各大高校的消防管理體系在多元化地發展中,逐漸凸顯了兩方面的問題:消防部門與部門之間、二級單位與子組織之間弱信任問題;消防各部門之間沒有形成數據的互聯、互通,導致消防數據孤立、不可靠。這些問題導致校園各部門消防數據不可信,火災預測數據不準確,對火災的應對決策起不到關鍵作用,從而發生了多起高校宿舍、實驗室等的校園火災,給學校人員和財產造成嚴重損失[1]。而私有區塊鏈技術[2]運用數據加密、時間戳、分布式共識等為校園消防管理提供了安全、可追溯、不可篡改、自動執行的運算平臺,解決了校園消防中突出的信任和數據互通互信問題,而傳統消防管理模式很難實現[3]。目前區塊鏈技術在其他領域中也得到了廣泛的應用,如,張亞嬌等人研究了基于私有區塊鏈的醫療數據安全存儲模型,并驗證和評估了該模型,很好地解決了傳統醫療個人與醫院之間數據信任和安全的問題[4];陳志東等人研究了基于私有區塊鏈的眾籌業務,在數據安全和公信方面得到極大加強,目前已經在實際應用[5]。由此可以看出私有區塊鏈技術可以很好地解決校園消防中存在的弱信任和消防數據不可靠問題。
本文設計的校園消防管理模型,主要是解決校園消防部門間的弱信任和數據不可信問題。通過使用私有區塊鏈技術,將校園消防數據區塊向各個消防部門節點公開,各節點之間通過共識機制,保證消防數據的及時更新和透明性,提高了部門之間信任度和數據的可信度,校園消防管理模型架構圖如圖1所示。
基于私有區塊鏈技術的校園消防管理系統是一個去中心化的分布式系統,而私有區塊鏈最緊要的問題是消防部門節點間的共識問題,也就是消防各部門節點之間的如何達成相同協議,增強消防各部門之間的信任關系。本文針對校園消防的應用,提出基于PBFT[6]的校園消防管理共識機制,并對該共識機制做了改進,以減少了共識算法中的計算量和檢查點校驗,減少了通訊資源開銷,加快區塊校驗速度并保證消防數據的高度一致性。
本文是基于私有區塊鏈的校園消防系統,其場景情況如下:
(1)有M個消防部門節點,分別為{M1,M2,M3,M4,M5,M6,…,Mm},各部門節點相互獨立。部門節點之間去中心化,在系統運行中,消防部門節點不存在動態添加和退出的情況。
(2)消防部門節點之間建立連接采用以太坊提供的校驗方式,認為該校驗是安全的,并且惡節點不能冒充其他節點連接到網絡中。
(3)當消防部門節點斷開連接時,系統會嘗試重新連接該節點,但超過超時時間仍沒連接成功,本文認為該消防部門節點發生錯誤,即為錯誤節點。

圖1 校園消防管理模型架構圖
在私有區塊鏈中,消防數據以區塊的形式提交并永久記錄到區塊鏈中。本文采用以太坊交易校驗協議,自身節點先校驗消防數據的有效性后,將消防數據寫入區塊中,并發送區塊,該區塊中的消防數據經過全網其他消防部門節點校驗通過,并添加到區塊鏈中則認為消防數據被執行。消防數據區塊生成流程如圖2所示。相關定義如下:
(1)timespan(時間間隔):當消防數據列表為空時,各消防部門節點監聽區塊鏈中最新消防數據區塊(LatesetBlock)的時間戳與系統的時間間隔。
(2)△t:消防數據區塊從生成到達成共識并添加到區塊鏈的最長時間,這個時間中包含信息傳輸過程會造成網絡延遲。
(3)LatestBlock:當前消防數據區塊鏈中最新添加成功的消防數據區塊。
(4)開始生成消防數據區塊判定條件:當前生成的消防數據區塊為空、或當前消防數據區塊正要添加的區塊號不大于LatestBlock區塊、或提交新的消防數據。
(5)上一消防數據區塊添加成功判定條件:節點監聽區塊鏈中的timespan,當timespan超過△t會生成一個空的消防數據區塊并添加到區塊鏈中,timespan需要滿足timespan>△t,這樣可以保證在生成空區塊時,所有交易已經在全網達成一致。

圖2 消防數據區塊生成流程圖
消防管理區塊鏈系統的共識機制中,采用一致性協議和區塊校驗分離的策略,來縮短系統網絡中各部門節點達成共識的時間,以加快消防數據區塊添加速度,且保證區塊鏈中即使出現壞部門節點,仍能保證消防管理區塊鏈系統去中心化可信的運行。
一致性協議通信模式如圖3所示,一致性協議包含五個階段:請求(request)、序號分配(pre-prepare)、交互(prepare)、序號確認(commit)、響應(reply)。消防管理共識機制系統采用兩兩交互的方式在服務器中達成一致之后再執行客戶端的請求。消防管理共識機制的一致性協議通信模型中,C:客戶端節點,即消防數據提交節點;N0~N3:消防管理系統網絡中其他部門節點;N0:消防管理系統中的主節點;N3:消防管理系統網絡中存在的故障消防部門節點。

圖3 消防管理共識機制通信協議模型
當主節點中滿足生成消防數據區塊條件時,主節點接收新生成消防數據區塊的請求,啟動序號分配階段、交互階段、序號確認階段的協議,并向各消防部門節點廣播發送請求;
序號分配階段:主節點給請求賦值一個序列號n,向網絡中廣播序號分配消息和客戶端的請求消息m,并將構造pre-prepare消息發送給網絡中其他消防部門節點;
交互階段:從節點接收pre-prepare消息,向其他部門節點廣播prepare消息;
序號確認階段:當發現該信息通過了2m個消防部門節點反饋并同意某一條證書時,即該消防數據區塊信息通過了一個Quorum的同意,那么對于這條證書該部門節點進入Commit的狀態,并向其他部門節點發送Commit消息客戶端等待來自不同消防部門節點的響應,若有2m+1(包括自身)個響應相同,則認為該消防數據區塊的信息在消防管理系統中達成共識,并嘗試將該消防數據區塊添加到系統區塊鏈中。
通過以上這種提交方式,實現了發送的區塊信息達成一致,以圖為例考慮到當N3節點發生拜占庭錯誤,由于另外兩個是安全的消防部門節點,因此仍可以滿足2m+1個消防部門節點通過驗證,安全的消防部門節點之間可以保證消防數據區塊的一致性,正確的區塊會成功添加到區塊鏈,并觸發下一個區塊的生成,循環執行該過程。
消防數據區塊的校驗過程主要針對區塊頭部信息進行校驗,本文結合以太坊中區塊結構進行區塊校驗,消防數據區塊校驗是整個區塊鏈校驗的核心內容,區塊校驗流程如圖4所示。

圖4 校驗流程圖
針對校園消防的特殊性,校園消防系統需要提供高效的查詢服務,以滿足對消防設備、消防水壓、消防報警的歷史查詢。本文研究設計了一種樹狀結構的區塊鏈來加速查詢,結合了Patricia樹和Merkle樹[7]的特點,形成消防管理MPT(Merkle Patricia Tree)鏈,可以保證分布式數據索引的一致性和查詢結果的正確性。Patricia[8]樹的更新并不需要花費太多的計算資源,只需要修改葉節點即可。
消防管理MPT鏈包括四種不同類型節點的樹結構,節點結構如圖5所示。根節點的結構由兩部分組成:分支指針和值。分支指針講指針指向分支節點,值中存儲消防管理MPT鏈的Merkle根,當創建區塊時,存儲在塊頭中的值將被改變。分支節點是一個列表,以十六進制編碼格式的HolderID作為搜索關鍵字,所有的分支節點都有16個用于存儲子指針的鍵值。當搜索路徑到達這個分支節點時,秘鑰的索引號表示搜索碼的值。分支節點的value字段以分支節點為根時,存儲Merkle樹的Merkle根值。

圖5 不同類型節點的樹結構
本文通過建立消防管理MPT鏈,以holderID為索引關鍵字加速查詢。如圖6中的消防管理PM鏈結構,數據交易指針存儲在葉子節點的tx指針中,當使用holderID進行查詢時,MPT逐個讀取holderID,并匹配從根開始到葉子節點或者擴展節點的holderID。其中圖6使用灰色來表示搜索路徑,通過使用holderID,并顯示tx指針指向區塊鏈中的事務。另外MPT鏈的最新Merkle根也存儲在最新區塊的塊頭中,圖6中用虛線表示了這種關系。

圖6 MPT鏈結構
本文的實驗主要對消防管理共識機制和消防管理MPT鏈進行驗證,實驗主要從吞吐量,網絡延遲和區塊創建速度的角度討論區塊生成達成共識的速度、區塊儲結構的查詢效率,而評估的指標是每秒消防數據區塊成功添加的次數(TPS)。區塊鏈中創建塊的時候,網絡的延遲是一個非常重要的因素,而Decker和Wattenhofer[9]提出的測量研究解決了這個問題。本文以他們的實驗數據作為理論估計,我們選擇的塊大小為200kb,并為共識過程設置時間閾值,塊的時間閾值為20s。
本文使用的實驗數據是來自某高校的消防數據。我們比較消防數據區塊的創建時間和區塊添加成功的吞吐量。圖7顯示了吞吐量,它可以達到每秒300個。圖8表示塊的創建時間,根據實驗數據,我們可以看到實體可以承受的事務延遲大約是10秒。毫無疑問,消防管理共識機制和消防管理MPT鏈可以加快節點共識和歷史數據查詢的速度。消防管理MPT鏈同時可以加速區塊的驗證,消防數據區塊的驗證過程需要驗證Merkle根的正確性,中間值可以重復使用。通過上述實驗結果,可以得出本文提出的校園消防共識機制和消防管理MPT鏈可以應用于基于私有區塊鏈的校園消防管理系統中,它不僅能夠滿足延遲和吞吐量的要求,而且支持毫秒查詢時間,提供更便捷,高效的校園消防服務。
隨著互聯網的高速發展,校園消防局限于中心化數據庫、不可擴展、不可互相監管以及中心數據庫數據可隨意更改的系統越來越難以處理當前越來越多樣化的校園消防數據。區塊鏈技術在去中心化、不可篡改、可追溯、可擴展趨勢的發展過程中得到了廣泛關注[10]。它作為一個大規模的協作工具,將對校園消防數據的存儲產生深遠影響。本文中分析和研究了基于私有區塊鏈技術的校園消防管理模型,解決了傳統系統中存在的部門與部門之間若信任的問題、數據缺乏透明化和可信度,無法和學校其他相關部門互聯互通互信、相互監督的問題,對于未來的消防事業的發展和研究具有一定的借鑒意義。區塊鏈技術在解決傳統問題的同時,自身也有一些問題需要解決[11]。首先,智能合約程序的表達范圍有限,并不能像自然語言合約那樣制定嚴格的約束,將阻礙其發展。最后,區塊鏈所造成的過度的資源消耗、高度數據冗余形成性能瓶頸。區塊鏈技術仍處在發展階段,還未形成一定的產業標準,需要學業界產業界的進一步推動。

圖7 吞吐量

圖8 區塊的創建時間
參考文獻:
[1]朱彤,傅貴,張蘇.高校火災事故行為原因分析及預防[J].工業安全與環保,2014,40(3):33-35.
[2]Castro M,Liskov B.Practical Byzantine Fault Tolerance[C].Proc of OSDL Berkeley,USENIX Association,1999:173-186
[3]袁勇,王飛躍.區塊鏈技術發展現狀與展望[J].自動化學報,2016,42(4):481-494.DOI:10.16383/j.aas.2016.c160158.
[4]張亞嬌,王樅.區塊鏈技術在醫療數據安全存儲中的應用[J],2016.
[5]陳志東,董愛強,孫赫,等.基于眾籌業務的私有區塊鏈研究[J].信息安全研究,2017,3(3):227-236.
[6]Platania M,Obenshain D,Tantillo T,et al.On Choosing Server-or Client-Side Solutions for BFT[J].Acm Computing Surveys,2016,48(4):1-30.
[7]Merkle R C,Protoools for Public Key Cryptosystems[C].Proc of IEEE Symp on Security&Privacy.Los Alamitos,CA;IEEE Computer Society,1980:122-122.
[8]Xu Y,Zhao S,Kong L,et al.ECBC:A High Performance Educational Certificate Blockchain with Efficient Query[M].Theoretical As-pects of Computing-ICTAC 2017,2017.
[9]Decker,C.,Wattenhofer,R.:Information propagation in the Bitcoin network.In:13th IEEEInternational Conference on Peer-to-Peer Computing(P2P),Trento,Italy,September 2013
[10]Zhao He,Li Xiao-Feng,Zhan Li-Kui,Wu Zhong-Cheng.Data Integrity Protection Method for Microorganism Sam-pling Robots Based on Blockchain Technology.Journal of Huazhong University of Science and Technology(Natural Science Edition),2015,43(Z1):216-219
[11]蔣潤祥,魏長江.區塊鏈的應用進展與價值探討[J].甘肅金融,2016,(2):19-21.DOI:103969/j.jssn.1009-4512.2016.02.003