为了保水并帮助减轻洪水, 通常, 需要在暴雨之前、之中和之后测量水深以确保水坝的安全性, 因此, 不断监测水库中的水位和天气状况对降低洪水灾害的危险至关重要^[1]. 但由于大坝周围环境的干扰, 大坝监控设备布置稀疏等原因, 导致大坝监测数据不可靠和不安全^[2], 因此制定一个可靠安全的大坝监控方案以确保数据的安全性和可靠性是十分有必要的.

近年来, 云计算和物联网^[3,4]的发展催生了一套新的智能服务和应用程序, 在这种情况下, 云和物联网在大坝监控中的结合使用将提供应对水挑战的新方法. 文献[5]研究了水力发电厂结构大坝安全监控系统, 该系统使用标准协议XMPP在安装在听诊仪器上的不同传感器之间提供通信服务. 文献[6]描述了在特定的大坝安全管理系统中应用物联网的可能性, 定义了一个新的数据采集模块, 用于与监控网络中的传感器通信. 文献[7]为了减少了人工干预大坝结构的施工和运营成本, 提出了智能水坝结构化系统, 将物联网、智能监控、云计算和控制技术智能地集成在一起, 以在整个生命周期内实施实时, 在线进行个人管理与分析, 并对其性能进行控制. 文献[8]提出了一种新颖的集成信息系统, 它结合了物联网(IoT)、云计算、地理信息学以及电子科学用于环境监测和评估. 文献[9]基于物联网和5G无线网络, 利用传感器数据构建尾矿坝多关键信息系统, 包括潜水线, 水库水位, 尾矿坝内部和外部变形等稳定性指标, 应用云平台基于实时监测数据预测潜水线的未来状态. 文献[10]分析了当前我国水库大坝安全管理存在的问题, 并以F大坝为例, 探讨了基于物联网技术与云技术的大坝安全管理系统的具体建构. 但以上这些工作没有提供全球大坝监测解决方案, 而且, 它们非常昂贵, 并且不提供可伸缩性和安全性.

本文提出了一种基于区块链(BC)^[11,12]技术并由传感器云和无人机云组成的系统架构, 包括: (1)一组传感器小云, 用于测量各种数据, 例如天气状况, 水质和水位以及大坝的结构状态; (2)由无人机提供商控制的一组无人机小云, 负责数据传输. BC技术可以解决与数据伪造和重播有关的潜在安全威胁, 保证数据完整性和数据不可伪造性. 其中, 传感器云的使用可以带来了许多益处, 包括解决方案的普遍性, 可伸缩性和可重用性. 而且, 小云可以服务于各种应用, 例如, 集成了一组用于测量气候条件的传感器的气象站可以同时用于设计应用程序和其他解决方案, 例如农业监测. 而使用UAV云进行数据传输, 可以有效解决面积大而基础设施较少、部署的传感器形成遥远且孤立的小云地区的数据传输问题.

1 系统架构 1.1 系统架构描述

本文设计的体系结构的目标是使DMC能够确保数据完整性, 数据支付的可追溯性以及行为人的报酬. 图1为系统架构图, 图2为系统流程图.

传感器云^[13]: 由散布在该区域并提供各种数据的一组传感器云组成. 每个小云与控制和配置传感器的WSN(气象站)代理进行交互. 每个小云均包含一组传感器和一个固定的收集点(CP), 具体包括: (1)一个或多个气象站, 这些气象站安装在农场的露天环境中; (2)一套水位和水质传感器, 用于测量物理和化学水参数; (3)一组用于监测大坝结构状态的传感器. 其中, 固定CP具有更多的计算和通信资源. 每个CP执行: (1)从小云收集和聚合传感器数据; (2)审计: 它验证是否从无人机提供商那里收到了发票中所有元组的付款.

无人机云: 由一组无人机小云组成, 并与无人机代理进行交互. 无人机云可以通过添加更多无人机提供商来提供可伸缩性, 并且可以为许多应用程序提供服务. 每个小云均由提供商控制, 并由一组基站(BS), 一组维护中心和一组无人机(例如四旋翼飞机)组成. 无人机从CP收集数据并将其传输给提供商. 无人机作用有: (1)接收和存储请求: 它从DMC接收请求, 然后将其存储以供以后验证; (2)选择将要处理请求的无人机提供商; (3)发票的产生: 它创建一个发票, 其中包含与给定请求有关的锚定到BC的元组列表, 然后将其发送给DMC以接收付款; (4)审计: 它验证是否收到发送给DMC的元组列表的付款; (5)无人机供应商付款: 从DMC收到付款并核实无人机供应商的发票后, 代理将继续向提供商付款. 无人机提供商: (1)选择将请求服务的候选无人机; (2)无人机路径规划: 它发出命令以调整无人机的飞行运动; (3)数据传递: 它将无人机收集的数据(相关的大坝监测服务)传递给DMC和BC; (4)审计: 它验证是否从无人机代理那里收到了发票中所包含的元组的付款; (5)付款: 在收到代理的付款并核实从CP收到的发票后, 它开始向CP支付.

大坝监控中心(DMC)负责: (1)请求发送和数据接收: 它将数据收集请求发送到UAV代理, 并从UAV提供商接收收集的感测数据; (2)审计: 它验证是否收到了从无人机代理收到的发票中包含的所有元组; (3)向无人机代理付款: 在验证收到的发票, 验证数据并执行审计功能之后, DMC继续向无人机代理付款.

1.2 系统要求

为了有效地在地面传感器和DMC之间传输数据, 设计的方案必须得到数据保护并面向云, 并且必须确保参与者的支付, 具体需要满足以下要求:

可扩展性: 在大型且基础设施较差的区域(例如水坝站点), 通过采用云概念, 可以通过增加设备数量或添加更多资源来确保扩展能力. 传感器云可以增加同一云中传感器的数量, 可以添加更多CP或更多资源. 此外, 通过增加更多的UAV提供商、UAV和更多的资源也可提升扩展性, 且这种增加不会影响请求处理和数据传递.

身份验证: 为了确保数据真实可靠且防止数据被篡改, DMC需要对数据来源进行身份验证, 这可以通过按原点对数据对象进行签名登记来完成. 此外, 为了确保请求来源是可信的, CP需要验证请求来源, 这可以通过DMC, UAV代理和UAV提供商签署请求来完成.

完整性: 为了保护请求、数据和声音的完整性, 可以对数据进行签名、哈希处理, 然后将处理后的数据上传到BC. 数据完整性由块挖掘过程中使用的共识机制(即永久证明)保证, 通过定期向BC网络请求BC收据, DMC可以随时验证数据完整性. 请求的完整性和不可伪造性可以通过将数字附加到已签名的请求中来提供, 区块链网络区通过检查发票中是否包含请求编号, 验证元组列表以及验证是否已支付此请求来提供发票的完整性和不可伪造性.

跟踪数据支付: 本文所设计的系统中, 无人机代理负责从DMC接收请求, 而无人机提供商则负责从CP收集数据并将其传递到DMC. 若要保证系统的有效性, 则要将无人机云完成的数据支付任务可靠地追溯到其来源, 并应该跟踪每个操作. UAV代理应验证与给定请求相关的数据是否已正确发送到DMC. UAV提供商应跟踪UAV收集的数据是否来自真实的CP. CP应验证: (1)收集的数据是否已支付给无人机提供商; (2)这些数据是否已经很好地固定在了基站; (3)这些数据是否被发送到DMC.

付款: 为保证支付的可靠性, 付款仅在数据和发票验证之后执行. 例如, DMC可以在验证真实性, 数据完整性, 总请求持续时间和发票付款后, 继续向UAV代理付款. 付款金额取决于元组中包含的度量数量. 为了支付这些实体, 应使用支付系统, 该系统应利用存储在BC中的数据. 因此, 支付系统应依赖于BC技术, 例如比特币网络.

2 区块链技术 2.1 使用区块链保护系统

本文将BC技术用作响应系统要求的潜在解决方案, BC可被视为分布式和公共分类帐, 本文使用混合BC网络^[14], 即使用公共比特币BC来支付操作, 使用私有BC来存储数据并确保其完整性和可追溯性^[15].

大坝和无人机提供商的结合起到共识节点的作用, 要加入BC网络, 实体应具有从证书颁发机构获得的证书, 且实体之间的所有交互都存储在BC中. 对于数据事务, 将从CP收集的每个数据都视为一个对象, 并由UAV提供商将其散列和锚定到BC网络中. 数据锚定带来许多好处: (1)通过哈希函数和共识机制提供了数据完整性和防篡改功能; (2)数据以分布式方式永久存储, 以确保稳定性, 可用性和弹性. (3) BC使生成任何上载数据的收据成为可能.

UAV提供商执行以下操作: (1)将散列数据发布到BC网络: 将接收到的元组进行哈希处理, 然后将处理后的数据发布到BC. BC将为每个哈希元组提供一个标识, 并将这些标识发送给UAV提供商. 上传每个数据元组将有助于以后验证数据完整性, 并提供使UAV提供商的任务可追溯的指纹. (2)储存BC网络给定的元组身份: 从BC网络接收到元组的身份后, UAV提供商会将其存储在DMC、UAV代理和CP可以访问的安全平台中. 平台为每个请求号存储元组的数量, 它们的相应CP以及从BC网络接收到的元组的标识.

CP通过确保UAV收集的每个元组是否已支付给其提供商和BC来跟踪UAV提供商的支付任务. 每个CP将访问UAV提供商的平台, 以验证元组号是否已更改, 以及是否具有BC给出的身份.

UAV代理通过访问由UAV提供商创建的平台来跟踪UAV提供商的支付任务, 以提取与给定请求相关的元组, 然后验证每个元组是否具有来自BC网络的相应标识.

为了提供数据完整性保护和验证, DMC在从UAV提供商的平台接收到元组的身份后, 要求为每个元组提供BC收据. 通过将数据库中计算的哈希值与生成的BC收据中的目标哈希值进行比较, 可以验证每个元组.

2.2 区块链上的数据操作

为了体现应用区块链的大坝数据传输的安全性和可靠性, 下面将详细介绍数据如何在BC上生成、传输和验证.

(1)请求生成和传递

DMC请求可以定期生成, 也可以在事件发生时生成, 请求时间可以根据实际水质进行调整. DMC向UAV(无人机)代理发送一个请求, 包括一个随机请求号、请求的最大持续时间、安全时间戳和请求位置:

$\begin{split} {{Re}} {q_{\rm DMC}} = & (nu{m_{req}},\max - duratio{n_{req}}, \\ & tim{e_{\rm DMC}},locatio{n_{req}}) \\ \end{split} $

(1)

这个请求用DMC的私钥签名并发送给UAV代理:

${{Re}} q_{\rm DMC_{signed}} = ({{Re}} {q_{\rm DMC}},sig_{req_{\rm DMC}}), $

其中, $sig_{req_{\rm DMC}} = S_{SK_{\rm DMC}}({{Re}} {q_{\rm DMC}})$ , S是签名算法(非对称加密), $SK_{\rm DMC}$ 是DMC的私钥. 无人机代理通过验证请求中包含的数字签名来验证DMC的真实性, 它验证 $tim{e_{\rm DMC}}$ 是否包含在请求中, 并将其与其时钟时间进行比较. 然后, 无人机代理选择一个候选的UAV提供商并命令它处理这个请求:

${{Re}} q_{\rm Br} = ({{Re}} q_{\rm DMC_{Signed}},Cert_{\rm Br},Time_{\rm Br})$

(2)

其中, $Cert_{\rm Br}$ 是它的证书, $Time_{\rm Br}$ 是它的安全时间戳. 发送给UAV提供商的请求是:

${{Re}} q_{\rm Br_{Signed}} = ({{Re}} q_{\rm Br},sig_{req_{\rm Br}})$

(3)

其中, $sig_{req_{\rm Br}} = S_{\rm SK_{Br}}({{Re}} q_{\rm Br})$ , $SK_{\rm Br}$ 是无人机代理的私钥. 提供商验证无人机代理的真实性, 它从网络中选择一架无人机, 命令它飞越请求的位置. 然后, 提供商验证 $Time_{\rm Br}$ 并将其与其时钟时间进行比较, 并通过添加它的时钟时间和证书构建了下面的请求:

${Req_{\rm Pr}} = ({Req_{\rm Br_{Signed}}},Cert_{\rm Pr} ,Time_{\rm Pr} )$

(4)

最后, 提供商将请求发送到无人机:

$ Req_{\rm Pr_{Signed}} = (Req_{\rm Pr} ,sig_{req_{\rm Pr}} ) $

(5)

其中, $sig_{req_{\rm Pr}} = S_{\rm SK_{Pr}} ({{Re}} q_{\rm Pr} )$ 是提供商的私钥, UAV (无人机)验证接收请求的真实性.

(2) 数据报告

收到请求后, 每个CP都会注册请求的最后时间戳, 在验证了UAV提供商的真实性之后, 它将汇总的数据发送到UAV, 然后, UAV使用DMC的公钥加密其数据. 事实上, UAV是在登记阶段发送给CPs的, 这个数据条目可以构造为一个元组, 其中包含元组编号、加密数据(使用公钥加密)、度量值的数目、请求编号、请求的最大持续时间、证书和安全时间戳:

$\begin{split} Tupl{e_{{\rm{CP}}i}} = &(nu{m_{\rm tuple}},Dat{a_{{\rm CP}i_{\rm encrypted}}},nu{m_{\rm measures}},\\ &nu{m_{\rm req}},cer{t_{{\rm CP}i}},cer{t_{\rm Br}},cer{t_{\Pr }},Tim{e_{{\rm CP}i}},\\ &Tim{e_{\rm DMC}},Tim{e_{\rm Br}},Tim{e_{\Pr }},Locatio{n_{{\rm CP}i}},\\ &\max - Duratio{n_{\rm req}}) \end{split}$

(6)

然后用CP的私钥签署每个元组:

$Tuple_{{\rm CP}i_{\rm signed}} = \{ Tuple_{{\rm CP}i},sig_{{\rm TupleCP}i}\} $

(7)

其中, $Tuple_{{\rm CP}i_{\rm signed}} = \{ Tuple_{{\rm CP}i},sig_{{\rm TupleCP}i}\}$ . UAV从CP接收所有元组, 然后将它们转发给UAV提供商, UAV提供商将构造一个连接元组块 $Block = < Tuple_{\rm CP1_{signed}},\cdots, Tuple_{{\rm{CP}}n_{\rm{signed}}},Tuple_{\rm quad_{signed}} >$ 然后将其发送到DMC, 其中 $Tuple_{\rm quad_{signed}}$ 与无人机收集的数据相关. 在每个接收到元组之后, DMC向UAV提供商发送确认(ACK).

(3)将数据发布到BC网络

在向DMC发送数据之后, UAV提供商散列元组, 构造一个由连接的散列元组组成的块

$\begin{split} Block_{hash} =& < hash(Tuple_{\rm CP1_{sig}}),\cdots, \\ & hash(Tuple_{{\rm CP}n_{\rm sig}}),hash(Tuple_{\rm quad_{sig}}) > \end{split} $

(8)

ACK也是散列的, 无人机提供商将元组和ACK都上传到BC中, 因此散列元组和ACK都将存储在数据存储中, 这可以通过层级来实现, 因为它提供了一个向BC上传和发布数据的平台. 执行中, 每个元组都将被散列, 然后与其他元组一起存储在BC网络中的一个事务中, 并最终转换为默克尔树节点, 根节点将锚定在遵循Chainpoint 3.0协议的BC事务中, 该协议为每个元组提供时间戳证明. 每个被散列化的元组都有一个标识, 用于检索BC收据(即验证交易的证据), UAV提供商检索哈希元组的身份, 然后, 提供商将哈希元组存储在一个可由DMC访问的安全平台上, 以便进行完整性验证, 平台为每个请求存储: 序列号、元组数、它们的CP以及散列元组的标识, 并由无人机代理和CPs对无人机供应商的支付任务进行验证.

(4)由DMC进行数据验证

在每个接收到的元组块之后, DMC验证安全时间戳, 它计算请求支付的持续时间和数据报告的持续时间, 然后计算总的请求持续时间, 即延迟时间之和, 并将其与最大持续时间进行比较. 如果总请求持续时间超过最大持续时间, 则DMC不验证接收到的数据, 反之, DMC验证接收到的数据并访问无人机供应商的安全平台, 以提取元组的身份. 为了验证每个元组, DMC向BC发送一个请求并等待BC收据, 每个元组将通过比较计算得到的散列和生成的BC收据中的目标哈希值来验证. 此外, DMC必须验证BC收据的格式和内容, 并且必须确认一个元组的摩尔根存储在BC中.

(5)发票的生成和验证

发票生成: 3个参与者负责生成发票: ① 无人机代理: 对于每个请求, 它检索所有相应的元组, 生成发票, 并将其发送给DMC, 以便日后支付; ② 无人机供应商: 它准备发票, 并将其发送给无人机代理, 以便日后支付; ③ CP: 每个CP生成发票, 并将其发送给无人机供应商, 以便日后支付. 每张发票包含号码、元组列表、寄件人的比特币地址以及准确的BTC值, 支付的数量取决于度量值的数量和一个块中包含的元组的数量, 因此, 可以将支付的数量计算为固定价格之和, 以及块中包含的所有元组的度量值数乘以每个单位数据的价格.

发票核对: 3个行为体(即DMC、UAV代理和UAV提供商)负责发票核对. 在收到发票后, DMC验证发票中的元组列表和数据库中为给定请求存储的元组列表, UAV代理通过比较包含在发票中的元组和从BC检索到的元组来验证每个发票, 以及UAV提供商通过比较包含在发票中的元组和存储在其平台中的元组来验证每个发票.

(6)付款

发票确认后, 付款人将开始付款. 比特币是一种加密货币系统, 吸引了大量感兴趣的用户, 为了在收款人和付款人之间进行比特币转账, 双方都必须有钱包. 本文使用BIP3支付协议, 它代表了商家和客户之间的通信协议.

在验证请求持续时间, 每个收到的元组和每个收到的BC收据确认之后, DMC继续支付UAV代理的款项. UAV代理在收到DMC的付款后就向无人机提供商支付任务的费用. 无人机供应商在收到无人机代理的付款后, 向CPs支付传感任务的费用. 支付是通过比特币交易实现的, 每个支付人在执行付款并从收款人收到应收款项后, 在BC网络中登记给定请求的最后一次付款时间, 以避免为同一请求号码支付两次付款.

(7)攻击检测

本文设计的系统侦测到的可能攻击包括:

① 数据和请求伪造: 无人机供应商可能通过注入非法数据和准备未经授权的付款来伪造数据, 这可通过BC网络检测到. 执行中, UAV提供商可以伪造数据, 而不是发送UAV收集的数据, 但由于本文设计通过证书和数字签名的验证对数据进行了身份验证, 因此不会发生这种攻击. 此外, 由UAV代理实现的请求伪造可以被CP检测到, 因为每个请求必须包含DMC的请求号和安全时间戳, 因此数据的真实性可以得到很好的保证.

② 数据和请求回放: CP可能会尝试向候选无人机发送旧数据. 本设计中, DMC可以通过每个元组中包含的时间戳和请求号来验证数据, 同时由于元组存储在BC网络中, 因此, DMC可以检测到这些旧数据已经存在于BC网络中. 此外, 由于CP注册了每个请求的最后时间戳, 因此可以检测到请求回放.

③ 伪造发票: 这种攻击可通过接收不是真实来源产生的发票来实现. 这可由发票接收者检测到, 3个发票接收者(DMC、UAV代理和UAV提供商)接受到发票信息后, 通过比较核对来排除伪造的发票. 此外, 发票和请求号码存储在接收方的数据库中, 以便于进行发票验证. 另外, 即使DMC没有接收数据, CPs也可以生成发票, UAV提供商在从DMC为每个接收到的元组接收ACK时检测到这种攻击, 因此, CP只有在接收到ACK之后才支付.

④ 双重付款: 可以通过收到相同的发票, 从而为相同的请求号码支付两次. 这可由支付者检测到, 因为每个发票包含发票和请求号码. 此外, 对于每个请求, 付款人在BC网络中登记最后一次付款时间, 因此, 付款人可以随时核实发票上的要求编号是否已经付款.

⑤ 拒绝支付: 例如, 即使在收到发票后, DMC也可以拒绝支付给无人机代理. 这可通过在接收到每个元组之后, DMC向UAV提供商发送一个ACK检测到, 发送的ACK与元组一起上传到BC网络中, 因此, DMC不能拒绝付款.

3 仿真结果与分析 3.1 系统工作性能分析

在这一部分, 本文旨在分析所提出的工作的性能. 本文考虑了边长长度为L=1.5 km的正方形监测区, 并将整个区域划分为边长长度为l=0.5 km的正方形分区网格, 在每个传感器采集数据的子区域中心都有一个CP.

假设所有的无人机都遵循同样的轨迹. 在接收到无人机供应商的请求后, 候选无人机会检查一组CP, 然后将收集到的数据转发给无人机供应商. 假定无人机对指挥中心的重访时间为常数, 模拟中使用的参数总结在表1中.

为了所提出的模型, 本文计算数据传递延迟比率, 并在对应于数据交互生成时间的每个时隙上, 利用均匀随机分布来设置事件发生概率(警报生成), 警报的大小定义为:

$Si{\textit{z}}e_{\rm alerts} = \sum\limits_{i = 1}^{{{(L/l)}^2}} {L_H + Nb_{\rm alerts}(i) \times L_{\rm pay}} $

(9)

其中, $L_{\rm pay}$ 是传感器数据包有效载荷的长度, $L_H$ 是CP的聚合包的头的长度; $Nb_{\rm alerts}$ 是警报的数量.

支付延迟等于:

$\begin{split} {D_{\rm delivery}} =& {T_{\rm Cr}} + {T_{\rm Cl{\rm{\& Des}}}} + {T_W} + {T_{\rm Pr \& tr BS \to DMC }} \\ &+ {T_{\rm col}} + {T_{{\rm{tr}}\;{\rm{to}}\;{\rm{BS}}}}, \end{split}$

(10)

其中, $T_{\rm Cr} = ({L^2} - {l^2})/(l \times S_{\rm Cr})$ 是行驶的总距离, 除以巡航速度( $S_{\rm Cr}$ ), $T_{\rm Cl{{\& Des}}} = {\rm{2}} \times {\left(\dfrac{{{L}}}{{{l}}}\right)^{\rm{2}}} \times {T_{\rm CCl}}$ 是爬升和下降的总数乘以爬升和下降所花费的时间( $T_{\rm CCl}$ ) , $T_{\rm Pr\& trBS\;\to\;DMC}$ 是处理收集的数据所需的时间和从BS到DMC的传输时间的总和, 它等于BC网络的处理时间, 并假设为是常数, $T_W$ 是从传感器产生数据到无人机到达的等待时间, $T_{\rm Col} = Si{\textit{z}}e_{\rm alerts}/Rate_{\rm reception}$ 是UAV从所有CP收集聚合包所需的时间, $T_{\rm tr\;to\;{{ BS}}} = {{Size_{\rm alerts}/}}{{Rate_{\rm transmisson}}}$ 是UAV从CP向BS传输数据所需的时间.

支付延迟率定义为:

$Ratio_{D_{\rm delivery}} = D_{\rm delivery}/T_{\rm flight}$

(11)

其中, $T_{\rm flight} = T_{\rm Cr} + T_{\rm Cl{{\& Des}}}$ 为无人机巡航、爬升、下降所花费的时间.

本文所提出系统的工作性能仿真结果如图3, 本文针对事件发生概率从0.1到0.8的变化模拟了支付延迟比率, 从图中可看出延迟比随着生成事件概率的增加而增加. 因为, 当增加事件概率时, 生成警报的机会就会增加, 因此数据大小也会增加. 因此, 收集时间和传输到BS的时间都增加了. 同时还可观察到, 由于警报数量的大量增加, 延迟比首先迅速增加(在概率值0.1和0.2之间), 然后由于警报数量的缓慢增加而缓慢增加.

图4针对从120 s到360 s的重新访问时间评估了数据传递延迟比. 从图中可以观察到, 随着重访时间的增加, 支付延迟率会随之增加. 因为增加的重访时间越多, 数据大小的增加就越大, 因此收集时间和到BS的传输时间都会增加. 而且, 传感器的等待时间也会随着重访时间的增加而增加.

图5中模拟了警报生成的时间相对于支付延迟率的变化, 从20 s到60 s不等. 从图中可以观察到, 延迟比率随着警报间隔时间的增加而减小. 因为增加警报生成的时间越多, 生成的数据就越少, 传递延迟也就越少. 同时还可观察到, 由于警报数量的大量减少, 支付延迟比率首先迅速降低(在20 s和30 s之间), 然后由于警报数量的缓慢减少而缓慢下降.

3.2 系统优势比较

下面为了体现本文设计系统的优势, 将本文中的基于区块链的物联网大坝监测系统与普通的未应用区块链的大坝监测系统进行比较.

为了体现系统的安全性和可靠性, 本文从支付成果率着手分析比较. 定义支付成功率为:

$ {\text{支付成功率}}\rm{=}\frac{CP{\text{收到的支付次数}}}{CP{\text{发出的数据次数}}}$

(12)

若CP收到的支付次数等于CP发出的支付次数, 则意味着CP每发出一次数据, 都得到了相应的付款, 数据在传递过程中处于安全状态. 若CP收到的支付次数大于CP发出的支付次数, 则意味着在数据传输过程中存在着虚假支付、数据被盗取的问题. 图6为支付次数为1000次(包括虚假支付次数)时的支付成功率比较图.

从图6可以看出, 在支付次数为1000次时, 随着虚假支付次数的增多, 普通的未应用区块链的大坝监测系统的支付成功率不断降低, 因为其没有确保数据安全的审计与验证. 而本系统的支付成功率一直维持在0.9左右, 因为虽然虚假支付次数增加了, 但是因为经过多层的审计与验证, 可以排除虚假支付, 从而提高支付成功率.

4 结束语

本文提出了一种基于区块链的由传感器云和无人机云组成的系统架构, 以用于监控大坝和确保数据的安全性与可靠性. 其中, 一组传感器小云可提供各种数据, 例如天气状况, 水质和水位以及大坝的结构状态, UAV云可从传感器收集数据以及将数据传递到DMC, 而BC技术确保了分布式的长期安全性, 该技术提供了身份验证, 数据存储和完整性以及UAV云数据支付的可追溯性, 有效的保证了大坝监测数据来源的可靠性, 数据传输的安全性以及预防潜在的数据攻击. 最后本文通过评估数据传递延迟率来评估工作绩效, 仿真结果表明, 所设计系统的延迟率所设计系统的延迟率与生成事件概率、重访时间成正相关, 与警报间隔时间成负相关, 且具有更高的支付成功率.