基于哈希圖的建筑物聯(lián)網(wǎng)數(shù)據(jù)管理方法

王旭，申玉民，熊曉蕓*，李鵬，王金龍

（1.青島理工大學(xué)信息與控制工程學(xué)院，山東青島 266525；2.青島億聯(lián)信息科技股份有限公司，山東青島 266033）

0 引言

隨著物聯(lián)網(wǎng)Internet of Things（IoT）、云計算等技術(shù)的快速發(fā)展，智能建筑領(lǐng)域也開始引入物聯(lián)網(wǎng)的概念，基于物聯(lián)網(wǎng)技術(shù)的智能建筑管理系統(tǒng)（Intelligent Building Management System，IBMS）［1-2］應(yīng)運而生。智能建筑管理系統(tǒng)集成樓宇自控系統(tǒng)、消防系統(tǒng)、安防管理系統(tǒng)等子系統(tǒng)，將各子系統(tǒng)的物聯(lián)網(wǎng)數(shù)據(jù)進(jìn)行整合，為管理人員提供一個智能化的綜合管理平臺，便于全面掌握建筑內(nèi)設(shè)備的實時狀態(tài)、報警和故障情況；通過數(shù)據(jù)定期分析，了解各子系統(tǒng)設(shè)備運行狀況和能耗情況，為設(shè)備維護和節(jié)能優(yōu)化提供支持［3］。然而，現(xiàn)有IBMS將從各子系統(tǒng)采集的建筑物聯(lián)網(wǎng)數(shù)據(jù)存儲在集中式服務(wù)器或云上進(jìn)行管理，存在單點故障隱患，對中央服務(wù)器的攻擊可能會使整個網(wǎng)絡(luò)癱瘓；此外，數(shù)據(jù)的使用需要基于對第三方云的信任，數(shù)據(jù)存在被篡改的風(fēng)險，數(shù)據(jù)可靠性和可追溯性差［4］。

區(qū)塊鏈技術(shù)為解決IBMS 數(shù)據(jù)管理中存在的問題提供了新的思路［5］。區(qū)塊鏈的概念在中本聰?shù)谋忍貛虐灼?］中首次提出，它是一種由分布式節(jié)點共同維護的去信任和去中心化分布式賬本技術(shù)，數(shù)據(jù)一旦經(jīng)過區(qū)塊鏈節(jié)點的驗證上傳到區(qū)塊鏈后，將永久存儲并且不可被篡改。由于區(qū)塊鏈所具備的去信任、去中心化存儲、數(shù)據(jù)安全可靠等特性，將IBMS采集的建筑物聯(lián)網(wǎng)數(shù)據(jù)存儲在區(qū)塊鏈進(jìn)行管理，可以解決目前數(shù)據(jù)管理過程中存在的信任問題和數(shù)據(jù)安全問題。Huh等［7］將物聯(lián)網(wǎng)數(shù)據(jù)存儲在以太坊區(qū)塊鏈中，防止數(shù)據(jù)被篡改，同時也避免了將數(shù)據(jù)存到第三方云而產(chǎn)生的信任問題。Xu 等［8］將區(qū)塊鏈技術(shù)應(yīng)用到智能建筑管理中，將采集的設(shè)備數(shù)據(jù)上傳到區(qū)塊鏈，利用智能合約監(jiān)測建筑內(nèi)物聯(lián)網(wǎng)設(shè)備的實時運行狀態(tài)。程冠杰等［9］提出了一種基于區(qū)塊鏈與邊緣計算的物聯(lián)網(wǎng)數(shù)據(jù)管理方法，在不借助單一可信中心化機構(gòu)的前提下實現(xiàn)分布式的數(shù)據(jù)管理，并設(shè)計了一種內(nèi)置加密方案來保護數(shù)據(jù)的安全和隱私。

上述基于區(qū)塊鏈的研究工作雖然解決了物聯(lián)網(wǎng)數(shù)據(jù)管理過程中的數(shù)據(jù)安全性問題和信任問題，但仍面臨著許多挑戰(zhàn)，其中最核心的是區(qū)塊鏈的性能瓶頸問題。具體而言，上述研究中區(qū)塊鏈的吞吐量嚴(yán)重不足，響應(yīng)時延較長。例如，Shafagh 等［5］提出的物聯(lián)網(wǎng)數(shù)據(jù)存儲與共享方法建立在比特幣區(qū)塊鏈之上，最大吞吐量約為每秒處理7 條交易，平均響應(yīng)時間為10 min；Huh 等［7］的方案基于以太坊實現(xiàn)，以太坊中最大交易吞吐量限制為每秒處理20 條交易，平均響應(yīng)時間為12 s。Jiang 等［10］針對區(qū)塊鏈吞吐量問題，基于Fabric 和IOTA（Internet Of Things Application）設(shè)計了一個物聯(lián)網(wǎng)數(shù)據(jù)的跨鏈訪問方法，能夠?qū)崿F(xiàn)高效、安全的物聯(lián)網(wǎng)數(shù)據(jù)管理，但是該方法的性能仍然無法滿足建筑物聯(lián)網(wǎng)數(shù)據(jù)的高并發(fā)和低時延處理需求。

針對上述問題，本文提出了一種建筑物聯(lián)網(wǎng)數(shù)據(jù)管理方法。首先，為建筑物聯(lián)網(wǎng)場景設(shè)計了基于Hashgraph 的數(shù)據(jù)管理框架，將從IBMS 各子系統(tǒng)采集的建筑物聯(lián)網(wǎng)數(shù)據(jù)存儲在基于有向無環(huán)圖（Directed Acyclic Graph，DAG）的分布式賬本中進(jìn)行管理，實現(xiàn)數(shù)據(jù)的去中心化和去信任化存儲；隨后，利用DAG 的高并發(fā)特性和Hashgraph 的高效共識能力，解決現(xiàn)有區(qū)塊鏈研究面臨的性能瓶頸問題，減少交易時延，提高區(qū)塊鏈的吞吐量和存儲效率。

1 相關(guān)工作

1.1 建筑物聯(lián)網(wǎng)

隨著物聯(lián)網(wǎng)技術(shù)的快速發(fā)展，物聯(lián)網(wǎng)和建筑行業(yè)的結(jié)合逐漸成為一種趨勢［1］。建筑物聯(lián)網(wǎng)以互聯(lián)網(wǎng)為基礎(chǔ)，利用物聯(lián)網(wǎng)設(shè)備和云管理平臺，將用戶端延伸到建筑內(nèi)外各角落，以幫助用戶更加高效地對建筑進(jìn)行設(shè)備監(jiān)控、能源管理、安全分析等。當(dāng)前建筑物聯(lián)網(wǎng)中智能設(shè)備的密度較大，且需要實時監(jiān)控設(shè)備并及時進(jìn)行響應(yīng)，對建筑物聯(lián)網(wǎng)數(shù)據(jù)的高并發(fā)和低時延處理要求高；此外，集中式云的數(shù)據(jù)管理方式要求數(shù)據(jù)使用者對云服務(wù)提供商的信任，同時存在著數(shù)據(jù)安全問題［2］。

1.2 物聯(lián)網(wǎng)與區(qū)塊鏈的適用性研究

區(qū)塊鏈基于分布式賬本和共識機制實現(xiàn)了去信任和去中心化的數(shù)據(jù)存儲與共享［11］，被認(rèn)為是解決物聯(lián)網(wǎng)中信任問題和安全問題的新出路，各學(xué)者從不同的角度對區(qū)塊鏈技術(shù)在物聯(lián)網(wǎng)中的適用性進(jìn)行了研究。Chowdhury 等［12］從區(qū)塊鏈平臺角度入手，評價各區(qū)塊鏈平臺在不同物聯(lián)網(wǎng)場景的適用性，并提出了一個區(qū)塊鏈平臺評估框架，為給定物聯(lián)網(wǎng)應(yīng)用選擇合適的區(qū)塊鏈平臺提供了參考。從共識機制角度入手，Cao 等［13］將當(dāng)前主流的工作量證明（Proof of Work，PoW）、權(quán)益證明（Proof of Stack，PoS）共識機制與DAG 類共識Hashgraph、Tangle 進(jìn)行對比，闡述DAG 類共識在物聯(lián)網(wǎng)場景下的性能優(yōu)越性；田志宏等［14］對區(qū)塊鏈共識的分析進(jìn)一步具體化，將共識分為證明類、拜占庭類和DAG 類，從吞吐量、響應(yīng)時間、容錯性等方面分析它們在物聯(lián)網(wǎng)場景中的適應(yīng)度。上述研究對將區(qū)塊鏈技術(shù)應(yīng)用于建筑物聯(lián)網(wǎng)提供了重要的參考依據(jù)。

1.3 區(qū)塊鏈與建筑物聯(lián)網(wǎng)

由于區(qū)塊鏈所具備的去信任化、去中心化存儲等特性可以很好地解決數(shù)據(jù)管理過程中存在的信任問題和安全問題，近年來區(qū)塊鏈在建筑物聯(lián)網(wǎng)領(lǐng)域中的應(yīng)用日益增長。Xu等［8］將從建筑內(nèi)采集的傳感器數(shù)據(jù)存儲在區(qū)塊鏈中，通過應(yīng)用程序調(diào)用智能合約向用戶實時更新傳感器數(shù)據(jù)，利用區(qū)塊鏈實現(xiàn)了傳感器數(shù)據(jù)去中心化、去信任化存儲。Siountri等［15］提出一種建筑物聯(lián)網(wǎng)與區(qū)塊鏈相結(jié)合的系統(tǒng)架構(gòu)，采用云鏈協(xié)同的方式存儲物聯(lián)網(wǎng)設(shè)備數(shù)據(jù)，利用區(qū)塊鏈進(jìn)行數(shù)據(jù)審計并保證數(shù)據(jù)的安全可靠。

然而，上述研究忽略了區(qū)塊鏈固有的性能瓶頸問題，難以滿足建筑物聯(lián)網(wǎng)數(shù)據(jù)的高并發(fā)處理和低時延需求。具體而言，現(xiàn)有研究所采用的單鏈區(qū)塊鏈由于串行化寫入特性并發(fā)處理能力較低，如果直接通過增加區(qū)塊大小提升區(qū)塊鏈的吞吐量又會造成交易時延增大［16］。

1.4 基于DAG的Hashgraph

Hashgraph 是一個基于DAG 的無領(lǐng)導(dǎo)拜占庭容錯算法，它通過虛擬投票的方式，不需要節(jié)點間交換信息便能達(dá)成最終的共識［17-18］。作為一種DAG 類共識算法，Hashgraph 可以利用DAG 賬本先存儲后解決沖突的策略以及DAG 結(jié)構(gòu)的高并發(fā)處理優(yōu)勢解決現(xiàn)有單鏈區(qū)塊鏈因串行化限制帶來的算力資源浪費和性能瓶頸問題［16］。

Prashar 等［19］將物聯(lián)網(wǎng)技術(shù)與Hashgraph 結(jié)合，實現(xiàn)了一個基于Hashgraph 的車聯(lián)網(wǎng)車輛認(rèn)證和撤銷系統(tǒng)，消除了對中央機構(gòu)的依賴，實現(xiàn)了對車輛狀態(tài)的快速更新與重定位。Bansal 等［20］使用Hashgraph 替代單鏈區(qū)塊鏈，提出一種車輛到車輛（Vehicle-to-Vehicle，V2V）能源交易方法，解決了區(qū)塊鏈的可擴展性瓶頸問題，實現(xiàn)了快速高效的能源交易。上述研究為解決區(qū)塊鏈應(yīng)用在建筑物聯(lián)網(wǎng)數(shù)據(jù)管理中存在的性能問題提供了新思路。

2 建筑物聯(lián)網(wǎng)數(shù)據(jù)管理方法

針對IBMS 中的建筑物聯(lián)網(wǎng)數(shù)據(jù)管理問題，本文提出一種基于Hashgraph 的數(shù)據(jù)管理框架，將數(shù)據(jù)存儲在DAG 分布式賬本中，利用DAG 類共識機制Hashgraph 對賬本數(shù)據(jù)達(dá)成一致性，解決區(qū)塊鏈在IBMS 應(yīng)用中存在的存儲效率低、吞吐量不足問題。

2.1 框架

基于Hashgraph 的建筑物聯(lián)網(wǎng)數(shù)據(jù)管理框架如圖1 所示，主要角色包括：數(shù)據(jù)采集網(wǎng)關(guān)（Data Collection Gateway，DCG）、云服務(wù)器（Cloud Server，CS）、終端設(shè)備（Terminal Device，TD）。在該場景中，DCG 和CS 作為區(qū)塊鏈網(wǎng)絡(luò)中的節(jié)點，利用智能合約（Smart Contract，SC）響應(yīng)數(shù)據(jù)存儲、數(shù)據(jù)查詢和控制請求，并進(jìn)行數(shù)據(jù)同步與共識。各角色的具體分工如下：

圖1 建筑物聯(lián)網(wǎng)數(shù)據(jù)管理框架示意圖Fig.1 Schematic diagram of building internet of things data management framework

1）DCG：①對接IBMS 各子系統(tǒng)和物聯(lián)網(wǎng)設(shè)備，將采集的建筑物聯(lián)網(wǎng)數(shù)據(jù)（包括設(shè)備運行數(shù)據(jù)、設(shè)備狀態(tài)、故障報警信息等）存儲到本地分布式賬本（Local Distributed Ledger，LDL），并利用Hashgraph 進(jìn)行數(shù)據(jù)同步與共識；②定期對LDL 內(nèi)的物聯(lián)網(wǎng)數(shù)據(jù)進(jìn)行統(tǒng)計并將統(tǒng)計結(jié)果存儲到LDL；③接收經(jīng)CS 驗證通過的控制命令，根據(jù)命令對子系統(tǒng)中的物聯(lián)網(wǎng)設(shè)備進(jìn)行控制。

2）CS：接收TD 的數(shù)據(jù)查詢請求或控制請求，調(diào)用權(quán)限控制合約驗證用戶權(quán)限與合法性，驗證通過后將授權(quán)的請求數(shù)據(jù)返回給TD，或?qū)⑹跈?quán)的控制命令發(fā)送給相應(yīng)的DCG 執(zhí)行。

3）TD：①從CS 中獲取建筑物聯(lián)網(wǎng)數(shù)據(jù)和統(tǒng)計數(shù)據(jù)，基于這些數(shù)據(jù)為用戶提供設(shè)備運行監(jiān)測、數(shù)據(jù)統(tǒng)計分析等應(yīng)用服務(wù)；②接收用戶的設(shè)備控制請求，交由CS 進(jìn)行權(quán)限驗證。

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

在本文所提出的數(shù)據(jù)管理方法中，存儲的數(shù)據(jù)主要有三類：1）DCG 采集的建筑物聯(lián)網(wǎng)數(shù)據(jù)；2）DCG 對鏈上數(shù)據(jù)進(jìn)行統(tǒng)計分析得到的統(tǒng)計數(shù)據(jù)；3）用戶發(fā)起的設(shè)備控制請求中的控制流信息。

2.2.1 全局配置

為保障數(shù)據(jù)的傳輸安全與存儲安全，用戶、區(qū)塊鏈節(jié)點在加入?yún)^(qū)塊鏈網(wǎng)絡(luò)時，區(qū)塊鏈網(wǎng)絡(luò)會自動為其生成公私密鑰對，用于后續(xù)對數(shù)據(jù)的加密、解密以及數(shù)據(jù)的簽名、校驗。算法1 給出了公私密鑰生成算法的過程描述，該算法根據(jù)輸入的密鑰長度l0生成私鑰文件Fr與公鑰文件Fu。

算法1 公私密鑰生成算法。

2.2.2 建筑物聯(lián)網(wǎng)數(shù)據(jù)采集與存儲

建筑物聯(lián)網(wǎng)數(shù)據(jù)是IBMS 中最基礎(chǔ)的數(shù)據(jù)，報警管理、運行監(jiān)測等功能都依托于該類數(shù)據(jù)。通常，IBMS 各子系統(tǒng)部署有數(shù)百上千臺物聯(lián)網(wǎng)設(shè)備，包括監(jiān)控攝像機、門禁控制器、照明燈等，DCG 需要每隔數(shù)秒采集一次物聯(lián)網(wǎng)設(shè)備產(chǎn)生的數(shù)據(jù)并進(jìn)行存儲，而傳統(tǒng)單鏈區(qū)塊鏈吞吐量較低，在DCG 采集時間間隔內(nèi)設(shè)備產(chǎn)生的建筑物聯(lián)網(wǎng)數(shù)據(jù)難以全部存入?yún)^(qū)塊鏈并達(dá)成共識，造成數(shù)據(jù)堆積，影響系統(tǒng)的正常使用。

為此，在本文提出的數(shù)據(jù)管理方法中引入基于DAG 的Hashgraph 共識，提高數(shù)據(jù)的存儲和查詢效率，以滿足建筑物聯(lián)網(wǎng)數(shù)據(jù)的高頻率采集和存儲需求。DCG 數(shù)據(jù)采集與存儲流程如圖2 所示。

圖2 數(shù)據(jù)采集與存儲示意圖Fig.2 Schematic diagram of data collection and storage

主要步驟如下：

1）通過調(diào)用廠商提供的數(shù)據(jù)采集接口，DCG 節(jié)點A（DCG_A）定期從IBMS 各子系統(tǒng)的智能設(shè)備處采集設(shè)備運行數(shù)據(jù)、設(shè)備狀態(tài)、故障報警信息等建筑物聯(lián)網(wǎng)數(shù)據(jù)；

2）DCG_A 調(diào)用SC 發(fā)起數(shù)據(jù)存儲請求，將采集的數(shù)據(jù)內(nèi)容加密后存儲到LDL；

3）DCG_A 將LDL 內(nèi)容廣播給其他DCG 節(jié)點和CS 節(jié)點，并利用Hashgraph 算法對LDL 內(nèi)的數(shù)據(jù)內(nèi)容達(dá)成共識（LDL的數(shù)據(jù)廣播和Hashgraph 共識過程將在2.3 節(jié)進(jìn)行詳細(xì)介紹）。

2.2.3 數(shù)據(jù)統(tǒng)計與存儲

IBMS 需要對各類設(shè)備的運行工況和用能情況進(jìn)行統(tǒng)計分析，例如統(tǒng)計各設(shè)備的月/年用電量、設(shè)備每周/月正常運行時長等。由于統(tǒng)計分析功能涉及的建筑物聯(lián)網(wǎng)數(shù)據(jù)量較多，如果將計算全部放在CS 后臺運行會降低統(tǒng)計和分析效率，終端用戶等待時間過長。為此，DCG 除了將采集的建筑物聯(lián)網(wǎng)數(shù)據(jù)存儲到LDL 外，還會定時獲取鏈上的建筑物聯(lián)網(wǎng)數(shù)據(jù)，對這些數(shù)據(jù)進(jìn)行局部統(tǒng)計計算并存儲到LDL。用戶執(zhí)行相關(guān)數(shù)據(jù)的統(tǒng)計分析功能時，CS 可以在LDL 存儲的局部統(tǒng)計結(jié)果基礎(chǔ)上進(jìn)一步計算，減少CS 后臺的計算時間。

DCG 數(shù)據(jù)統(tǒng)計與存儲流程如圖3 所示，假設(shè)DCG_A 的統(tǒng)計時間間隔為intervalT，統(tǒng)計過程如下：

圖3 DCG數(shù)據(jù)統(tǒng)計與存儲示意圖Fig.3 Schematic diagram of DCG data statistics and storage

1）DCG_A 開啟定時任務(wù)，每經(jīng)過intervalT觸發(fā)統(tǒng)計合約SCcount；

2）SCcount調(diào)用統(tǒng)計計算函數(shù)ExecuteStatistics（），根據(jù)統(tǒng)計類型type從LDL 中獲取各設(shè)備對應(yīng)數(shù)據(jù)進(jìn)行統(tǒng)計計算，生成局部統(tǒng)計結(jié)果，隨后SCcount將統(tǒng)計結(jié)果加密并存儲到LDL 中；

3）DCG_A 將LDL 新增的統(tǒng)計數(shù)據(jù)內(nèi)容傳播給其他DCG節(jié)點和CS 節(jié)點，各節(jié)點利用Hashgraph 算法對新增統(tǒng)計數(shù)據(jù)達(dá)成共識。

步驟2）中，ExecuteStatistics（）函數(shù)主要用于根據(jù)輸入的設(shè)備編號列表Dn、統(tǒng)計類型type、起始時間tstart、終止時間tend統(tǒng)計各設(shè)備在該時間段內(nèi)的運行數(shù)據(jù)，并輸出局部統(tǒng)計結(jié)果列表Rn。算法2 給出了該函數(shù)的過程描述。

算法2ExecuteStatistics（）函數(shù)。

2.3 Hashgraph共識

2.3.1 數(shù)據(jù)傳播與共識

Hashgraph 共識使用八卦傳播協(xié)議進(jìn)行數(shù)據(jù)傳播。即當(dāng)DCG_A 將數(shù)據(jù)存儲到LDL 后，DCG_A 隨機選取鄰近未同步數(shù)據(jù)的1 個DCG 或1 個CS 作為數(shù)據(jù)傳播對象，將數(shù)據(jù)傳播給該節(jié)點；隨后，該節(jié)點繼續(xù)隨機挑選數(shù)據(jù)傳播對象，重復(fù)上述步驟，并在本地通過虛擬投票對數(shù)據(jù)達(dá)成共識。為敘述方便，以2 個DCG 節(jié)點DCG_A、DCG_B 和1 個CS 節(jié)點CS_C 為例介紹Hashgraph 的數(shù)據(jù)傳播過程，并將本節(jié)和2.4 節(jié)涉及的數(shù)據(jù)統(tǒng)一描述為如表1 所示。

表1 形式化描述Tab.1 Formal description

圖4 展示了DCG_A、DCG_B 和CS_C 利用Hashgraph 網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳播的過程，數(shù)據(jù)以事件的形式進(jìn)行傳播（Ek包括E_TSk、E_TXLk、E_PLHk和E_POHk），其中節(jié)點初始事件內(nèi)E_PLH和E_POH均為0000。假設(shè)DCG_A、DCG_B 事件只包含一個DSTX，同時假設(shè)在該場景中，CS_C 只傳播事件以同步各節(jié)點LDL 內(nèi)容，本身不發(fā)起DSTX，其E_TXL為空。數(shù)據(jù)傳播具體過程如下：

圖4 數(shù)據(jù)傳播過程Fig.4 Process of data propagation

步驟1 DCG_A、DCG_B 將采集數(shù)據(jù)加密后存儲到LDL，并生成DSTXA、DSTXB，各節(jié)點分別構(gòu)造初始EA1、EB1、EC1并生成SigE_A1、SigE_B1、SigE_C1，其中EA1、EB1分別記錄著從DCG_A、DCG_B 產(chǎn)生的DSTXA、DSTXB。

步驟2 DCG_A 隨機選擇1 個節(jié)點DCG_B 作為八卦對象，向其傳播EA1，DCG_B 接收到EA1后，驗證SigE_A1，驗證通過后將E_TXLA1中DSTXA記錄的數(shù)據(jù)存儲到LDL，隨后DCG_B 將EA1與EB1合并構(gòu)造EB2（包含新產(chǎn)生的DSTXB），生成SigE_B2后將EA1、EB2更新到HGB。

步驟3 DCG_B 隨機選擇1 個節(jié)點CS_C 作為八卦對象，向其傳播EB1，CS_C 在接收到EB1后執(zhí)行相同的操作，將E_TXLB1中DSTXB記錄的數(shù)據(jù)存到LDL，生成EC2并計算SigE_C2，隨后更新HGC。

步驟4 DCG_B 隨機選擇1 個節(jié)點DCG_A 作為八卦對象，在向DCG_A 傳播EB2之前通過查看HGB發(fā)現(xiàn)DCG_A 不含有EB1，于是在八卦本地最新事件EB2時將EB1也發(fā)送給DCG_A。DCG_A 驗證SigE_B1、SigE_B2后將E_TXLB1、E_TXLB2內(nèi)DSTXB記錄的數(shù)據(jù)存到LDL，構(gòu)造EA2，計算SigE_A2并更新HGA。

DCG_A、DCG_B 和CS_C 按步驟1～4 進(jìn)行數(shù)據(jù)傳播。由于Hashgraph 是異步共識算法，因此不能保證HGA、HGB、HGC具有相同的狀態(tài)。但是，隨時間線推移，HGA、HGB、HGC各副本在過去某個確定時間的狀態(tài)會達(dá)成一致，最終所有節(jié)點的LDL 也都會存儲相同的數(shù)據(jù)內(nèi)容。

因為每個節(jié)點的本地HG記錄著全網(wǎng)發(fā)生的事件歷史，節(jié)點可以根據(jù)本地HG的狀態(tài)模擬投票過程，整個投票過程在本地以“虛擬投票”形式進(jìn)行并對LDL 數(shù)據(jù)達(dá)成共識?！疤摂M投票”過程無需與其他節(jié)點交換投票和確認(rèn)信息，也無需額外的通信代價，能夠減少共識所需時間，提高共識效率。

2.3.2 共識對比分析

本節(jié)從通信代價、容錯性、準(zhǔn)確性角度將Hashgraph 與拜占庭容錯（Practical Byzantine Fault Tolerance，PBFT）、Tendermint 等共識算法進(jìn)行對比分析。共識對比分析結(jié)果如表2 所示。

表2 共識算法對比Tab.2 Comparison of consensus algorithms

在通信代價角度上，與本文采用的Hashgraph 相比，PBFT、Tendermint 等雖然也屬于拜占庭類算法，但是節(jié)點間需要進(jìn)行多個階段的投票信息交換，只有2/3 以上驗證節(jié)點投票同意才能進(jìn)入下一階段。如表2 所示，假設(shè)網(wǎng)絡(luò)中負(fù)責(zé)驗證區(qū)塊的節(jié)點數(shù)為n，PBFT 和Tendermint 在共識投票過程的通信代價均為O（n2），而本文方法使用的Hashgraph 共識采用本地“虛擬投票”方式，無需額外通信。

在容錯性角度上，Hashgraph 與上述兩個算法對惡意節(jié)點容錯能力如表2 所示，均只能容忍不超過1/3 的惡意節(jié)點。當(dāng)惡意節(jié)點發(fā)起“雙花”攻擊時，PBFT、Tendermint 等算法通過交換投票發(fā)現(xiàn)惡意節(jié)點，而Hashgraph 算法利用本地HG中記錄的事件歷史發(fā)現(xiàn)惡意節(jié)點及“雙花”交易。例如，DCG_A 在同一高度生成分叉事件EA3、EA4，在數(shù)據(jù)傳播和“虛擬投票”過程中，其他節(jié)點會從本地HG中發(fā)現(xiàn)DCG_A 產(chǎn)生的分叉事件，并將EA3、EA4在LDL 中對應(yīng)的數(shù)據(jù)內(nèi)容標(biāo)記為無效。

在準(zhǔn)確性角度上，PBFT 等算法通過相互交換投票達(dá)成共識，以保證共識結(jié)果準(zhǔn)確性。而Hashgraph 將共識過程轉(zhuǎn)變?yōu)楸镜亍疤摂M投票”形式，本地HG被劃分為不同的輪次，只有在2/3 以上節(jié)點收到當(dāng)前輪次的首個事件后，才會轉(zhuǎn)入下一輪次；節(jié)點在第i+2 輪次利用本地HG對第i輪次的事件進(jìn)行共識，其共識準(zhǔn)確性取決于記錄在本地HG的各節(jié)點歷史事件狀態(tài)的一致性程度。而由于誠實節(jié)點彼此間會正確傳遞歷史事件狀態(tài)，發(fā)現(xiàn)惡意節(jié)點并取消惡意節(jié)點在“虛擬投票”階段的投票權(quán)，因此誠實節(jié)點本地HG記錄的各節(jié)點的歷史事件狀態(tài)會趨于一致，從而為共識的準(zhǔn)確性提供保證。

2.4 數(shù)據(jù)權(quán)限控制關(guān)鍵步驟

用戶使用TD 向CS 發(fā)出查詢或控制請求時，CS 需要調(diào)用SC 判斷用戶權(quán)限，防止出現(xiàn)過度授權(quán)、越權(quán)訪問等情況。以用戶O（User_O）發(fā)起的設(shè)備控制請求為例介紹數(shù)據(jù)權(quán)限控制的關(guān)鍵步驟，如圖5 所示。其中，權(quán)限控制過程由主控制合約（Main Control Contract，MCC）與權(quán)限判斷合約（Access Judgement Contract，AJC）共同管理，MCC 負(fù)責(zé)管理全局的訪問控制，AJC 負(fù)責(zé)對用戶的請求合法性進(jìn)行檢查，判斷用戶是否有相應(yīng)操作的權(quán)限，具體流程如下：

圖5 權(quán)限控制過程Fig.5 Process of access control

步驟1 User_O 通過TD 向DCG_B 管理的設(shè)備發(fā)出設(shè)備控制請求，TD 將UIIUser_O、Opt_Type與Device_C組裝成CR，計算HCR并生成SigH_CR，隨后將CR、HCR、SigH_CR發(fā)送給CS_C。

步驟2 CS_C 接收到數(shù)據(jù)，驗證其中HCR和SigH_CR的正確性，隨后調(diào)用MCC。MCC 首先在內(nèi)部調(diào)用AJC，AJC 將CR內(nèi)的UIIUser_O、Opt_Type與存儲在區(qū)塊鏈上的P_Table進(jìn)行匹配，驗證用戶權(quán)限并將驗證結(jié)果Validres返回給MCC，MCC 將CR、HCR、SigH_CR、Validres及其他相關(guān)信息結(jié)合生成CRrecord，存儲到LDL 中。

步驟3 MCC 對Validres進(jìn)行判斷，如果為False 表示驗證不通過，拒絕User_O 的控制請求并返回相應(yīng)提示，流程結(jié)束；反之則表示驗證通過，MCC 將CR、HCR、SigH_CR發(fā)送給DCG_B。

步驟4 DCG_B 驗證HCR、SigH_CR正確性，驗證通過后解析CR，執(zhí)行Device_C控制相應(yīng)設(shè)備的運行狀態(tài)。

在步驟2 中，AJC 負(fù)責(zé)解析CR，將CR中的UIIUser_O、Opt_Type與P_Table中的實體e、權(quán)限集合R進(jìn)行匹配，判斷User_O 是否擁有對Opt_Type中對應(yīng)設(shè)備或設(shè)備組的操作權(quán)限，算法3 給出了AJC 合約的過程描述。

算法3 AJC 合約。

輸入控制請求信息CR。

輸出權(quán)限驗證結(jié)果Validres。

3 仿真驗證與分析

本章通過搭建多機仿真環(huán)境對本文提出的數(shù)據(jù)管理方法進(jìn)行性能測試與評估，并從數(shù)據(jù)的隱私性、安全性角度對本文方法進(jìn)行分析。

為測試本文方法在高并發(fā)建筑物聯(lián)網(wǎng)數(shù)據(jù)處理場景下的性能，選擇交易吞吐量、數(shù)據(jù)存儲時延和控制時延作為測試指標(biāo)，使用性能測試工具Hyperledger Caliper 測試上述三個指標(biāo)在不同節(jié)點規(guī)模下的變化趨勢。其中交易吞吐量用來衡量單位時間內(nèi)處理大量建筑物聯(lián)網(wǎng)數(shù)據(jù)存儲交易的效率，數(shù)據(jù)存儲時延用來衡量高并發(fā)情況下處理單個建筑物聯(lián)網(wǎng)數(shù)據(jù)存儲請求的效率，控制時延用來衡量控制請求的響應(yīng)與執(zhí)行效率。圍繞上述三個指標(biāo)與現(xiàn)有方法進(jìn)行比較，對仿真結(jié)果進(jìn)行分析討論，并對本文方法進(jìn)行尖峰沖擊測試與穩(wěn)定性測試，以說明本文方法在建筑物聯(lián)網(wǎng)場景下的可用性。

3.1 仿真環(huán)境

考慮到聯(lián)盟鏈的適用范圍和建筑物聯(lián)網(wǎng)場景的特點（多機構(gòu)共同維護，用戶相對固定且準(zhǔn)入控制嚴(yán)格），本文基于Hyperledger Fabric 聯(lián)盟鏈平臺部署仿真環(huán)境，并采用中型規(guī)格的虛擬機（4 GB 內(nèi)存，2 核CPU，100 GB 硬盤空間）和樹莓派4B（2 GB 內(nèi)存，4 核Broadcom 處理器，64 GB 硬盤空間）作為仿真設(shè)備，虛擬機和樹莓派的軟件環(huán)境如表3 所示。

表3 軟件環(huán)境配置Tab.3 Software environment configuration

3.2 性能評估

針對建筑物聯(lián)網(wǎng)數(shù)據(jù)高并發(fā)處理場景，本節(jié)圍繞吞吐量、數(shù)據(jù)存儲時延、控制時延三個測試指標(biāo)，將本文方法與程冠杰等［9］和Jiang 等［10］提出的數(shù)據(jù)管理方法進(jìn)行比較，并在最后對本文方法進(jìn)行尖峰沖擊測試與穩(wěn)定性測試。上述兩種方法采用與本文方法相同的硬件條件，其中，程冠杰等［9］引入邊緣計算解決區(qū)塊鏈的可擴展性瓶頸問題，Jiang 等［10］利用跨鏈方法應(yīng)對區(qū)塊鏈在物聯(lián)網(wǎng)應(yīng)用中面臨的性能瓶頸挑戰(zhàn)，它們代表了現(xiàn)有區(qū)塊鏈研究在物聯(lián)網(wǎng)數(shù)據(jù)管理上的兩個重要研究方向。將本文方法與上述兩個方法進(jìn)行比較，有較強的可參考性。

3.2.1 吞吐量測試

吞吐量是衡量并發(fā)處理能力的重要指標(biāo)，本文用每秒交易數(shù)（Transaction Per Second，TPS）表示，在區(qū)塊鏈中指的是系統(tǒng)每秒能處理的交易數(shù)量。在仿真測試中，使用Caliper工具，設(shè)置單位時間內(nèi)發(fā)送1 500 筆數(shù)據(jù)存儲交易，測試在不同節(jié)點規(guī)模下本文方法的吞吐量并與現(xiàn)有方法進(jìn)行比較。其中，每筆交易包含一條給排水設(shè)備產(chǎn)生的實時監(jiān)測數(shù)據(jù)，涉及的數(shù)據(jù)內(nèi)容包括設(shè)備編號、設(shè)備名稱、部署位置、監(jiān)測值、監(jiān)測時間等，每筆交易在區(qū)塊鏈上占用的實際存儲空間約為0.9 KB。測試結(jié)果如圖6 所示，本文方法的吞吐量在網(wǎng)絡(luò)規(guī)模為16 個節(jié)點時達(dá)到最大值，最大吞吐量為1 189.1 TPS，之后吞吐量隨網(wǎng)絡(luò)規(guī)模的擴大略有下降。本文方法的吞吐量性能約是邊緣計算和跨鏈方法的6 倍和3 倍。

圖6 不同節(jié)點規(guī)模下的吞吐量比較Fig.6 Throughput comparison under different scales of nodes

3.2.2 數(shù)據(jù)存儲時延

數(shù)據(jù)存儲時延是指從數(shù)據(jù)存儲交易發(fā)起到各節(jié)點對交易達(dá)成共識所需要的時間，用來衡量本文數(shù)據(jù)管理方法中共識算法的運行效率，數(shù)據(jù)存儲時延越低，表明達(dá)成共識的速度越快。數(shù)據(jù)存儲時延τstorage可以表示為：

其中：tcontract表示執(zhí)行數(shù)據(jù)存儲相關(guān)智能合約所需時間；τconsensus表示數(shù)據(jù)存儲交易在節(jié)點間傳播并達(dá)成共識所需時間。

利用Caliper 工具測試在不同節(jié)點規(guī)模下本文方法處理單筆數(shù)據(jù)存儲交易所需平均時間，并與現(xiàn)有方法進(jìn)行比較。其中，每筆交易包含由50 條給排水實時監(jiān)測數(shù)據(jù)構(gòu)成的數(shù)據(jù)列表，以模擬邊緣網(wǎng)關(guān)定時采集給排水?dāng)?shù)據(jù)并上鏈存儲的過程。給排水實時監(jiān)測數(shù)據(jù)涉及的內(nèi)容與3.2.1 節(jié)所述一致，每筆交易在區(qū)塊鏈上占用的存儲空間為34.7 KB。測試結(jié)果如圖7 所示，本文方法的數(shù)據(jù)存儲效率明顯優(yōu)于跨鏈方法，在節(jié)點數(shù)量較少時與邊緣計算方法的存儲時延相差不大；而隨著節(jié)點數(shù)量增加，本文方法的存儲效率逐漸與邊緣計算方法拉開差距，優(yōu)勢更加明顯。

圖7 不同節(jié)點規(guī)模下的平均存儲時延對比Fig.7 Comparison of average storage delay under different scales of nodes

考慮到實際建筑物聯(lián)網(wǎng)場景對邊緣網(wǎng)關(guān)和云服務(wù)器數(shù)量的需求，選擇32 個節(jié)點模擬中型網(wǎng)絡(luò)規(guī)模，討論本文方法的可用性。在此規(guī)模下本文方法的吞吐量為1 063.1 TPS，數(shù)據(jù)存儲時延為4.57 s。表4 展示了青島市某物聯(lián)網(wǎng)企業(yè)提供的IBMS 項目數(shù)據(jù)采樣頻率，在設(shè)備全部啟動并正常運轉(zhuǎn)的情況下，項目總采樣頻率約為每秒189.8 條，本文方法的交易吞吐量能夠滿足該場景下對數(shù)據(jù)的并發(fā)處理需求。此外，本文方法4.57 s 的數(shù)據(jù)存儲時延低于數(shù)據(jù)采樣間隔，可以在采樣間隔內(nèi)完成采樣數(shù)據(jù)的存儲，避免數(shù)據(jù)堆積問題，滿足該建筑物聯(lián)網(wǎng)場景下對數(shù)據(jù)存儲的響應(yīng)時間需求。

表4 IBMS項目數(shù)據(jù)采樣頻率與數(shù)量Tab.4 Data-sampling frequencies and numbers of IBMS projects

3.2.3 控制時延

控制時延是指從用戶發(fā)出設(shè)備控制請求到DCG 執(zhí)行控制命令所需的時間，用來衡量本文方法對設(shè)備控制請求的響應(yīng)速度?？刂茣r延τcontrol可以表示為：

其中：tjudge表示執(zhí)行MCC、AJC 兩個合約進(jìn)行權(quán)限判斷所需時間；texecute表示DCG 執(zhí)行控制命令所需時間；τbroad表示控制命令信息在網(wǎng)絡(luò)中傳輸所需時間。

對全局權(quán)限表進(jìn)行設(shè)置，權(quán)限表信息如表5 所示，表內(nèi)共有10 000 條權(quán)限信息，用于模擬中型園區(qū)的用戶規(guī)模，權(quán)限信息包含實體、權(quán)限、注冊時間和過期時間屬性。權(quán)限屬性由兩個集合S和C組成，集合S用于記錄實體可以查詢哪類數(shù)據(jù)，其中BAS、FAS 和SMS 分別表示對樓控、消防和安保子系統(tǒng)內(nèi)數(shù)據(jù)的查詢權(quán)限；集合C用于記錄實體可以對哪些設(shè)備或設(shè)備組進(jìn)行控制，其中EG01表示對01 號門禁設(shè)備的控制權(quán)限（即允許該用戶通過01 號門禁）。

表5 權(quán)限表信息（部分）Tab.5 Information of access table（part）

使用Caliper 工具發(fā)起對門禁設(shè)備的控制請求，以模擬用戶請求通過門禁的操作，測試在不同節(jié)點規(guī)模下本文方法響應(yīng)控制請求所需的平均時間并與現(xiàn)有方法進(jìn)行比較。其中，控制請求涉及的內(nèi)容包括用戶身份標(biāo)識、操作類型、操作命令、操作對象、發(fā)起時間等，每條控制請求在區(qū)塊鏈上占用的實際存儲空間約為1.2 KB。測試結(jié)果如圖8 所示，由于控制請求的響應(yīng)時間主要取決于權(quán)限表規(guī)模與τstorage，因此當(dāng)權(quán)限表規(guī)模固定時，控制時延隨網(wǎng)絡(luò)規(guī)模擴大而變化的趨勢與存儲時延一致。同時，在32 節(jié)點規(guī)模下，本文方法的控制時延為4.92 s，小于邊緣計算方法的6.53 s 和跨鏈方法的10.39 s 控制時延，且符合《出入口控制系統(tǒng)工程設(shè)計規(guī)范》中“現(xiàn)場事件信息經(jīng)非公共網(wǎng)絡(luò)傳輸?shù)匠鋈肟诠芾碇行牡捻憫?yīng)時間應(yīng)不大于5 s”的規(guī)定［21］，滿足該場景的實際使用需求。

圖8 不同節(jié)點規(guī)模下的平均控制時延對比Fig.8 Comparison of average control delay under different scales of nodes

3.2.4 尖峰沖擊與穩(wěn)定性測試

對本文提出的數(shù)據(jù)管理方法進(jìn)行尖峰沖擊測試與穩(wěn)定性測試，以驗證本文方法在32 節(jié)點規(guī)模下的可用性。

根據(jù)中國信通院對尖峰沖擊測試的規(guī)則要求［22］，將數(shù)據(jù)存儲交易的發(fā)送速率設(shè)置為2 200 TPS（實際吞吐量的2 倍），測得本文方法在此環(huán)境下的交易成功率為87.4%，符合信通院對尖峰沖擊測試“上鏈成功率大于75%”的要求。

在穩(wěn)定性測試環(huán)節(jié)，因硬件條件的限制，將數(shù)據(jù)存儲交易的發(fā)送速率設(shè)為170 TPS，以模擬上述IBMS 項目90%設(shè)備正常啟動運轉(zhuǎn)的環(huán)境，并進(jìn)行為期5 d 的低負(fù)載運行測試。經(jīng)測試，基于本文方法所實現(xiàn)的系統(tǒng)原型可以穩(wěn)定運行，滿足《智能建筑工程質(zhì)量驗收規(guī)范》中“試運行應(yīng)連續(xù)進(jìn)行120 h”的要求［23］。平穩(wěn)運行120 h 后，節(jié)點內(nèi)賬本數(shù)據(jù)所占硬盤存儲空間約為46.3 GB。

3.3 數(shù)據(jù)隱私性與安全性分析

針對建筑物聯(lián)網(wǎng)場景對數(shù)據(jù)隱私保護與數(shù)據(jù)安全性的需求，從數(shù)據(jù)隱私性和安全性角度對本文提出的數(shù)據(jù)管理方法進(jìn)行分析。

在建筑物聯(lián)網(wǎng)場景下，停車場管理系統(tǒng)、安保系統(tǒng)等IBMS 子系統(tǒng)涉及用戶敏感數(shù)據(jù)，需要防范數(shù)據(jù)泄露事件發(fā)生。為此，本文使用數(shù)據(jù)加密方式對敏感數(shù)據(jù)進(jìn)行加密，并設(shè)計MCC、AJC 兩個權(quán)限控制合約對數(shù)據(jù)的訪問權(quán)限進(jìn)行控制，實現(xiàn)了基于訪問控制的隱私保護，避免敏感數(shù)據(jù)泄露給未經(jīng)許可的用戶。

從數(shù)據(jù)安全性角度考慮，除了需要保證數(shù)據(jù)機密性之外，還應(yīng)確保數(shù)據(jù)的完整性，避免數(shù)據(jù)丟失、數(shù)據(jù)篡改等問題的發(fā)生。本文方法將區(qū)塊鏈技術(shù)融入到建筑物聯(lián)網(wǎng)數(shù)據(jù)管理過程中，利用區(qū)塊鏈的多方共識、分布式存儲特性，可以避免鏈上數(shù)據(jù)被篡改以及因單點故障引發(fā)的數(shù)據(jù)丟失問題。

4 結(jié)語

現(xiàn)有區(qū)塊鏈研究的系統(tǒng)性能無法滿足建筑物聯(lián)網(wǎng)場景的實際使用需求。為此，本文提出了一種基于Hashgraph 的建筑物聯(lián)網(wǎng)數(shù)據(jù)管理方法：采用具備高并發(fā)特性的DAG 結(jié)構(gòu)進(jìn)行數(shù)據(jù)存儲與共識，提高區(qū)塊鏈系統(tǒng)的并發(fā)處理能力和數(shù)據(jù)存儲效率；設(shè)計智能合約實現(xiàn)對訪問權(quán)限的控制；最后，基于Hyperledger Fabric 平臺對本文方法進(jìn)行了仿真測試。仿真結(jié)果表明，本文方法相較于對比方法具有更好的并發(fā)處理能力和更快的響應(yīng)速度，符合建筑物聯(lián)網(wǎng)場景的實際使用需求。然而，本文方法對于訪問控制權(quán)限的劃分粒度較粗，可能會出現(xiàn)越權(quán)訪問數(shù)據(jù)、過度授權(quán)等情況，下一步的工作將對訪問控制權(quán)限進(jìn)行更細(xì)粒度的劃分，以加強對數(shù)據(jù)隱私保護的力度。