基于哈希圖的建筑物聯網數據管理方法

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

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

0 引言

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

區塊鏈技術為解決IBMS 數據管理中存在的問題提供了新的思路［5］。區塊鏈的概念在中本聰的比特幣白皮書［6］中首次提出，它是一種由分布式節點共同維護的去信任和去中心化分布式賬本技術，數據一旦經過區塊鏈節點的驗證上傳到區塊鏈后，將永久存儲并且不可被篡改。由于區塊鏈所具備的去信任、去中心化存儲、數據安全可靠等特性，將IBMS采集的建筑物聯網數據存儲在區塊鏈進行管理，可以解決目前數據管理過程中存在的信任問題和數據安全問題。Huh等［7］將物聯網數據存儲在以太坊區塊鏈中，防止數據被篡改，同時也避免了將數據存到第三方云而產生的信任問題。Xu 等［8］將區塊鏈技術應用到智能建筑管理中，將采集的設備數據上傳到區塊鏈，利用智能合約監測建筑內物聯網設備的實時運行狀態。程冠杰等［9］提出了一種基于區塊鏈與邊緣計算的物聯網數據管理方法，在不借助單一可信中心化機構的前提下實現分布式的數據管理，并設計了一種內置加密方案來保護數據的安全和隱私。

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

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

1 相關工作

1.1 建筑物聯網

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

1.2 物聯網與區塊鏈的適用性研究

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

1.3 區塊鏈與建筑物聯網

由于區塊鏈所具備的去信任化、去中心化存儲等特性可以很好地解決數據管理過程中存在的信任問題和安全問題，近年來區塊鏈在建筑物聯網領域中的應用日益增長。Xu等［8］將從建筑內采集的傳感器數據存儲在區塊鏈中，通過應用程序調用智能合約向用戶實時更新傳感器數據，利用區塊鏈實現了傳感器數據去中心化、去信任化存儲。Siountri等［15］提出一種建筑物聯網與區塊鏈相結合的系統架構，采用云鏈協同的方式存儲物聯網設備數據，利用區塊鏈進行數據審計并保證數據的安全可靠。

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

1.4 基于DAG的Hashgraph

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

Prashar 等［19］將物聯網技術與Hashgraph 結合，實現了一個基于Hashgraph 的車聯網車輛認證和撤銷系統，消除了對中央機構的依賴，實現了對車輛狀態的快速更新與重定位。Bansal 等［20］使用Hashgraph 替代單鏈區塊鏈，提出一種車輛到車輛（Vehicle-to-Vehicle，V2V）能源交易方法，解決了區塊鏈的可擴展性瓶頸問題，實現了快速高效的能源交易。上述研究為解決區塊鏈應用在建筑物聯網數據管理中存在的性能問題提供了新思路。

2 建筑物聯網數據管理方法

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

2.1 框架

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

圖1 建筑物聯網數據管理框架示意圖Fig.1 Schematic diagram of building internet of things data management framework

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

2）CS：接收TD 的數據查詢請求或控制請求，調用權限控制合約驗證用戶權限與合法性，驗證通過后將授權的請求數據返回給TD，或將授權的控制命令發送給相應的DCG 執行。

3）TD：①從CS 中獲取建筑物聯網數據和統計數據，基于這些數據為用戶提供設備運行監測、數據統計分析等應用服務；②接收用戶的設備控制請求，交由CS 進行權限驗證。

2.2 數據存儲流程

在本文所提出的數據管理方法中，存儲的數據主要有三類：1）DCG 采集的建筑物聯網數據；2）DCG 對鏈上數據進行統計分析得到的統計數據；3）用戶發起的設備控制請求中的控制流信息。

2.2.1 全局配置

為保障數據的傳輸安全與存儲安全，用戶、區塊鏈節點在加入區塊鏈網絡時，區塊鏈網絡會自動為其生成公私密鑰對，用于后續對數據的加密、解密以及數據的簽名、校驗。算法1 給出了公私密鑰生成算法的過程描述，該算法根據輸入的密鑰長度l0生成私鑰文件Fr與公鑰文件Fu。

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

2.2.2 建筑物聯網數據采集與存儲

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

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

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

主要步驟如下：

1）通過調用廠商提供的數據采集接口，DCG 節點A（DCG_A）定期從IBMS 各子系統的智能設備處采集設備運行數據、設備狀態、故障報警信息等建筑物聯網數據；

2）DCG_A 調用SC 發起數據存儲請求，將采集的數據內容加密后存儲到LDL；

3）DCG_A 將LDL 內容廣播給其他DCG 節點和CS 節點，并利用Hashgraph 算法對LDL 內的數據內容達成共識（LDL的數據廣播和Hashgraph 共識過程將在2.3 節進行詳細介紹）。

2.2.3 數據統計與存儲

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

DCG 數據統計與存儲流程如圖3 所示，假設DCG_A 的統計時間間隔為intervalT，統計過程如下：

圖3 DCG數據統計與存儲示意圖Fig.3 Schematic diagram of DCG data statistics and storage

1）DCG_A 開啟定時任務，每經過intervalT觸發統計合約SCcount；

2）SCcount調用統計計算函數ExecuteStatistics（），根據統計類型type從LDL 中獲取各設備對應數據進行統計計算，生成局部統計結果，隨后SCcount將統計結果加密并存儲到LDL 中；

3）DCG_A 將LDL 新增的統計數據內容傳播給其他DCG節點和CS 節點，各節點利用Hashgraph 算法對新增統計數據達成共識。

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

算法2ExecuteStatistics（）函數。

2.3 Hashgraph共識

2.3.1 數據傳播與共識

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

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

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

圖4 數據傳播過程Fig.4 Process of data propagation

步驟1 DCG_A、DCG_B 將采集數據加密后存儲到LDL，并生成DSTXA、DSTXB，各節點分別構造初始EA1、EB1、EC1并生成SigE_A1、SigE_B1、SigE_C1，其中EA1、EB1分別記錄著從DCG_A、DCG_B 產生的DSTXA、DSTXB。

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

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

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

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

因為每個節點的本地HG記錄著全網發生的事件歷史，節點可以根據本地HG的狀態模擬投票過程，整個投票過程在本地以“虛擬投票”形式進行并對LDL 數據達成共識。“虛擬投票”過程無需與其他節點交換投票和確認信息，也無需額外的通信代價，能夠減少共識所需時間，提高共識效率。

2.3.2 共識對比分析

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

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

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

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

在準確性角度上，PBFT 等算法通過相互交換投票達成共識，以保證共識結果準確性。而Hashgraph 將共識過程轉變為本地“虛擬投票”形式，本地HG被劃分為不同的輪次，只有在2/3 以上節點收到當前輪次的首個事件后，才會轉入下一輪次；節點在第i+2 輪次利用本地HG對第i輪次的事件進行共識，其共識準確性取決于記錄在本地HG的各節點歷史事件狀態的一致性程度。而由于誠實節點彼此間會正確傳遞歷史事件狀態，發現惡意節點并取消惡意節點在“虛擬投票”階段的投票權，因此誠實節點本地HG記錄的各節點的歷史事件狀態會趨于一致，從而為共識的準確性提供保證。

2.4 數據權限控制關鍵步驟

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

圖5 權限控制過程Fig.5 Process of access control

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

步驟2 CS_C 接收到數據，驗證其中HCR和SigH_CR的正確性，隨后調用MCC。MCC 首先在內部調用AJC，AJC 將CR內的UIIUser_O、Opt_Type與存儲在區塊鏈上的P_Table進行匹配，驗證用戶權限并將驗證結果Validres返回給MCC，MCC 將CR、HCR、SigH_CR、Validres及其他相關信息結合生成CRrecord，存儲到LDL 中。

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

步驟4 DCG_B 驗證HCR、SigH_CR正確性，驗證通過后解析CR，執行Device_C控制相應設備的運行狀態。

在步驟2 中，AJC 負責解析CR，將CR中的UIIUser_O、Opt_Type與P_Table中的實體e、權限集合R進行匹配，判斷User_O 是否擁有對Opt_Type中對應設備或設備組的操作權限，算法3 給出了AJC 合約的過程描述。

算法3 AJC 合約。

輸入控制請求信息CR。

輸出權限驗證結果Validres。

3 仿真驗證與分析

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

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

3.1 仿真環境

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

表3 軟件環境配置Tab.3 Software environment configuration

3.2 性能評估

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

3.2.1 吞吐量測試

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

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

3.2.2 數據存儲時延

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

其中：tcontract表示執行數據存儲相關智能合約所需時間；τconsensus表示數據存儲交易在節點間傳播并達成共識所需時間。

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

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

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

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

3.2.3 控制時延

控制時延是指從用戶發出設備控制請求到DCG 執行控制命令所需的時間，用來衡量本文方法對設備控制請求的響應速度。控制時延τcontrol可以表示為：

其中：tjudge表示執行MCC、AJC 兩個合約進行權限判斷所需時間；texecute表示DCG 執行控制命令所需時間；τbroad表示控制命令信息在網絡中傳輸所需時間。

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

表5 權限表信息（部分）Tab.5 Information of access table（part）

使用Caliper 工具發起對門禁設備的控制請求，以模擬用戶請求通過門禁的操作，測試在不同節點規模下本文方法響應控制請求所需的平均時間并與現有方法進行比較。其中，控制請求涉及的內容包括用戶身份標識、操作類型、操作命令、操作對象、發起時間等，每條控制請求在區塊鏈上占用的實際存儲空間約為1.2 KB。測試結果如圖8 所示，由于控制請求的響應時間主要取決于權限表規模與τstorage，因此當權限表規模固定時，控制時延隨網絡規模擴大而變化的趨勢與存儲時延一致。同時，在32 節點規模下，本文方法的控制時延為4.92 s，小于邊緣計算方法的6.53 s 和跨鏈方法的10.39 s 控制時延，且符合《出入口控制系統工程設計規范》中“現場事件信息經非公共網絡傳輸到出入口管理中心的響應時間應不大于5 s”的規定［21］，滿足該場景的實際使用需求。

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

3.2.4 尖峰沖擊與穩定性測試

對本文提出的數據管理方法進行尖峰沖擊測試與穩定性測試，以驗證本文方法在32 節點規模下的可用性。

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

在穩定性測試環節，因硬件條件的限制，將數據存儲交易的發送速率設為170 TPS，以模擬上述IBMS 項目90%設備正常啟動運轉的環境，并進行為期5 d 的低負載運行測試。經測試，基于本文方法所實現的系統原型可以穩定運行，滿足《智能建筑工程質量驗收規范》中“試運行應連續進行120 h”的要求［23］。平穩運行120 h 后，節點內賬本數據所占硬盤存儲空間約為46.3 GB。

3.3 數據隱私性與安全性分析

針對建筑物聯網場景對數據隱私保護與數據安全性的需求，從數據隱私性和安全性角度對本文提出的數據管理方法進行分析。

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

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

4 結語

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