基于哈希图的建筑物联网数据管理方法

王旭，申玉民，熊晓芸*，李鹏，王金龙

（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（n²），而本文方法使用的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 平台对本文方法进行了仿真测试。仿真结果表明，本文方法相较于对比方法具有更好的并发处理能力和更快的响应速度，符合建筑物联网场景的实际使用需求。然而，本文方法对于访问控制权限的划分粒度较粗，可能会出现越权访问数据、过度授权等情况，下一步的工作将对访问控制权限进行更细粒度的划分，以加强对数据隐私保护的力度。