DR-BFT：动态边缘计算中的数据完整性共识

DR‐BFT：一种用于动态边缘计算系统中基于区块链的多层数据完整性框架 的共识算法

摘要

边缘计算作为分布式计算架构的一部分，已成为一种日益流行的范式。它通过在靠近数据的网络边缘而非云端存储和处理来自终端设备的数据，扩展了云的能力。数据完整性在边缘计算中是一个重要问题。作为一种有前景的数据完整性解决方案，区块链能够有效保护边缘计算系统中的数据。然而，大多数现有的共识算法无法满足动态网络中边缘计算的需求，因为在该环境中节点可能动态地加入或离开区块链网络。本文提出一种基于区块链的双层框架，以实现边缘计算中的数据完整性，并设计了一种新型的动态随机拜占庭容错（ DR‐BFT）共识算法。DR‐BFT由三个子算法组成：字符串共识、数据正确性验证和二元共识。字符串共识旨在对终端设备或边缘服务器的数据达成共识，该子算法基于一致性机制，并借鉴了阶段国王协议的部分思想。如果字符串共识因“提前终止”而失败，则每个节点将从一个随机主节点处获取一个值，并执行数据正确性验证子算法。随后，系统通过二元共识子算法对数据达成共识，该子算法是Ben‐Or和Michael随机共识的一种变体。我们还提出了一种改进的法定人数方法，以应对争用以及动态节点离开/加入的情况。我们对 DR‐BFT在共识正确性、安全性和系统开销方面进行了分析。DR‐BFT满足一致性、有效性和终止性。我们通过模拟实验进行了验证，结果表明，所提出的DR‐BFT共识算法能够有效提升动态边缘计算环境下的性能，包括降低通信开销和共识延迟。

1. 引言

随着智能终端设备（例如智能家居设备、传感器、移动电话等）的指数级增长，由于网络延迟和带宽的限制，云计算正变得难以满足虚拟现实（VR）等终端的需求。作为一种新的计算范式，边缘计算是实现高质量服务的有效解决方案。通过边缘计算，终端设备将数据处理和存储任务卸载到物理位置上靠近终端设备的边缘服务器，从而实现实时数据处理并减轻数据中心的负载。

数据完整性在边缘计算中是一个具有挑战性的问题。在基于私有设备或公共设备的边缘计算中，网络环境和设备彼此之间并不完全信任对方，且数据可能属于多个所有者。由于数据被分割成许多部分并存储在不同的存储位置，因此在边缘计算系统中难以保证数据完整性，这使得数据包容易丢失或存储错误的数据。此外，存储在边缘服务器上的数据可能会被未授权用户或攻击者篡改或滥用，从而导致数据泄露和其他隐私问题[1]。

一些研究人员认为边缘计算是云计算的扩展，因此提出了一些与云计算中类似的安全方案。在云环境中，数据完整性保护的方法主要基于第三方审计员，而数据存储的审计方法大多为基于密码学的方法，如基于MAC的方法、基于RSA的方法和基于BLS的方法[2]。然而，边缘服务器无法像云服务器那样得到充分保护，甚至可能由不同的运营商维护。此外，由于边缘服务器的不可靠性，边缘计算可能面临单点故障问题，而云计算则不会。

摆脱了这一问题。因此，云计算中使用的解决方案无法直接应用于边缘计算。区块链被认为是数据完整性保护的潜在解决方案之一。区块链的特性，即分布式冗余存储、不可篡改性、去中心化等，使其能够有效解决不可否认性和单点故障问题[3,4]。杨等人介绍了在边缘计算中采用区块链的一些研究挑战[3]。已有研究探讨了如何利用区块链提供数据存储完整性[5–8]。然而，大多数现有工作假设区块链底层是一个理想的P2P网络，其中网络不会发生故障且所有正常节点始终在线。

共识是区块链的必要条件。常用的共识算法包括工作量证明（ PoW）、委托权益证明（DPoS）、实用拜占庭容错（PBFT）、权威证明（PoA）[9,10],认证证明（PoAh）[11],幸运证明[12],等。PoW和DPoS均需要发行代币，且PoW需要消耗大量的计算和通信资源。PoA主要有两种实现方式，即Aura[9]和Clique[10]。PoA在存在拜占庭节点的情况下以牺牲一致性来换取可用性，这在必须保证交易完整性的场景中是不可接受的[13]。对于PoAh而言，如果广播的已验证区块因某些原因被修改，PoAh信息可能会丢失或被篡改，从而破坏区块链的一致性。PBFT是许可区块链中最流行的共识算法。然而，PBFT面临以下挑战，导致其无法适应具有动态底层网络的边缘计算环境。

(1) 终端设备和边缘服务器并非始终在线，且节点具有动态性，节点会频繁地加入或离开区块链网络，导致部分设备可能与网络断开连接[14]。动态网络使得区块链节点接收到的数据不完整甚至不正确。此外，PBFT在每轮共识过程中都会选择一个领导者，如果领导者离线，将触发视图切换，从而带来较大的网络通信开销。因此，PBFT在动态网络中的性能通常不理想。然而，大多数使用PBFT的研究均假设节点长时间保持在线，且网络拓扑结构是静态的，未考虑节点的离开和加入操作。

(2) 如果每个节点或大多数节点具有不同的初始值，PBFT无法达成共识。例如，如果每个节点接收到不同的交易，则没有节点会同意领导节点的值，它们将提议进行视图切换，并继续拒绝新领导节点的后续值。

在边缘计算中，终端设备和边缘服务器在物理空间上较为接近，因此可能同时被控制或遭到破坏。即使由同一边缘服务器服务的所有终端设备同时被控制，我们也需要确保区块链的历史记录仍然无法被篡改，并且链下用户能够验证区块链中的数据。

总之，区块链的分布式特性使其适用于边缘计算系统中的数据完整性保护。然而，动态加入/离开的节点使得大多数现有共识算法失效。本文采用区块链为具有动态底层网络的边缘计算系统提供数据完整性。本文的主要贡献如下：

对于终端设备和边缘服务器动态加入和离开的边缘计算系统，我们引入了一种基于区块链的双层框架以保护数据完整性。该框架由两层组成，其中下层包含多个私有链，上层为联盟链。每个边缘服务器为一定数量的终端设备提供服务。每个服务器及其所服务的终端设备构成一个私有链，而所有边缘服务器则构成联盟链。

我们提出了一种共识算法Dynamic-Random Byzantine Fault Tolerance Consensus（DR‐BFT），该算法包含字符串共识、数据正确性验证和二元共识三个子算法。字符串共识旨在就终端设备或边缘服务器的数据达成共识，其基于一致性，并借鉴了阶段国王协议[15]的一些思想。如果字符串共识未能提前终止，则每个节点将在数据经过数据正确性验证子算法验证后提出数据。随后，系统通过二元共识子算法对数据达成共识，该子算法是 Ben‐Or和Michael的随机共识的一种变体。我们还提出了一种改进的法定人数方法，以应对争用以及动态节点的离开和加入。所提出的共识算法DR‐BFT保证了一致性、有效性和终止性。DR‐BFT还可适应动态网络，并具有较低的系统开销。

我们通过仿真进行实验。实验结果表明，所提出的共识DR‐BFT能够通过降低系统开销和共识延迟有效提升系统性能。

本文其余部分组织如下。在第2节中，我们介绍相关工作。在第3节中，我们提出所提议框架的详细结构。共识机制在第4节中提出。我们在第5节和第6节中分别进行分析和评估。最后，我们在第7节中给出结论。

2. 相关工作

2.1. 云计算中的数据完整性

在云计算中的数据完整性方面已开展了大量研究，所提出的方法主要基于第三方审计。已提出许多数据审计协议，如批量公审协议[16],、可证明恢复协议[17],、远程检查协议[18],、数据持有证明[19],、基于MAC的方法[20],、基于RSA的同态方法[21], 等。

随着区块链的发展，一些研究采用区块链来保护云计算中的数据完整性。刘等人提出了一种用于云存储的基于区块链的数据完整性服务框架[22]。加埃塔尼等人通过具体案例研究分析了云计算中数据完整性的需求，并设计了一种面向云计算的基于区块链的数据库[23]。朱等人通过引入信任授权节点设计了一种基于区块链的云数据管理系统，其中区块链用于存储文档变更记录，而信任授权机构（TA）则审查已更改的文档以确定其有效性，而不依赖于其他用户的意见[24]。李等人提出了一种框架，该框架利用区块链存储用户对数据的操作，并通过行为审计保护云环境中的数据完整性[25]。

总之，云计算中的数据完整性已受到广泛关注。这些方法包括基于密码学的检查方案、第三方审计方法以及基于区块链的解决方案。然而，与云计算不同的是，边缘计算中的边缘服务器可能由不同的服务提供商运营，且网络环境和设备不具备彼此完全信任。在边缘计算系统中，数据被分割成多个部分并存储在不同的存储位置，这使得数据包容易丢失或存储错误的数据。此外，存储在边缘服务器上的数据可能会被未授权用户或攻击者修改或滥用，从而导致数据泄露和其他隐私问题。因此，云计算中使用的数据完整性解决方案无法直接应用于边缘计算。

2.2. 边缘计算中的数据完整性

边缘计算中的数据也面临完整性威胁。尽管边缘计算在为终端用户提供服务的方式上与云计算相似，但在保护数据完整性方面，边缘计算面临不同于云计算的挑战。易等人指出，在雾计算中，用户数据被外包，用户对数据的控制权交由雾节点，这引入了相同的安全威胁；然而，由于外包数据可能丢失或被篡改，因此难以保证数据完整性[26]。防止外包数据威胁的审计解决方案主要依赖于第三方审计员（TPA）的审计机制。然而，这类方法并不总能取得令人满意的性能。萨吉尔等人指出，在移动物联网等动态环境中，基于TPA的框架的可靠性远未达到令人满意的程度[27]。此外，除了面临与云计算类似的数据外包问题外，边缘计算系统还存在自身特有的安全问题。杨等人指出，尽管外包数据的隐私问题是边缘计算中的主要问题，但由于服务迁移以及大量终端节点之间的交互，边缘计算的安全性面临明显挑战[3]。童等人认为，以往保护远程数据完整性的方法可能不适用于边缘计算，并提出了一种新的完整性验证方案[28]。

一些研究人员采用区块链来解决边缘计算中的数据完整性问题。汗等人研究了物联网(IoT)中的各级安全问题，并提出了潜在的基于区块链的方法：身份验证和数据授权方案[29]。杨等人研究了保障数据完整性的潜在解决方案，例如基于以太坊的框架和基于IPFS的链下完整性服务[30]。卡利斯等人提出了一种将区块链应用于边缘计算的数据验证方法，该方法使用信任证明共识；区块链与实际数据分别存储，并利用区块链中的哈希值来验证数据完整性[5]。岳等人提出了一种利用区块链和默克尔树进行P2P数据存储验证的方法，并提出了一种采样验证方法以降低验证成本[6]。任等人提出了一种基于区块链的边缘计算数据存储框架，采用再生编码和存储优化技术[8]。周等人提出了一种阈值安全多方计算(TSMPC)协议，并设计了一种基于TSMPC的区块链物联网系统[31]。

一些研究采用区块链来提供边缘计算中的数据完整性，因为区块链和边缘计算都具有分布式特性。大多数现有工作假设区块链底层是一个理想的P2P网络，其中网络不会发生故障，且所有正常节点始终保持在线。然而，在采用区块链支持边缘计算系统中数据完整性的过程中，很少有研究同时关注终端设备与边缘节点之间的动态特性和层次关系。

2.3. 共识算法

共识算法，也称为分布式共识协议，是一种在网络中每个节点上实施并遵守的网络规则。自Lamport等人[32]的奠基性工作以来，大量研究针对共识问题进行了探讨，以解决复杂任务并满足不同的网络拓扑需求等。这些问题主要集中在不同的输入和输出域（例如二值或多值）、不同的故障模型（例如崩溃或拜占庭故障）、不同的通信网络（例如完全P2P图和不完整图）。为应对这些问题，已提出了多种算法。容错共识算法包括三类：崩溃容错共识、拜占庭容错（ BFT）共识和比特币相关共识。

最著名的两种崩溃容错共识算法是Paxos[33]和Raft[34]。Paxos由Lamport提出，许多应用实现了Paxos，例如ZooKeeper[35]，该技术后来被广泛应用于HBase等存储系统中。On-garo和 Ousterhout提出了共识算法Raft，旨在简化Paxos的理解难度和实现复杂性，Raft迅速获得 popularity，如今已被广泛使用。

通过拜占庭容错（BFT），该系统如同存在一个中央服务器，使用状态机复制来接收并响应用户的请求。最著名的BFT共识是 Castro和Liskov提出的实用拜占庭容错（PBFT）[36]。由于PBFT开销高且吞吐量低，因此提出了一些其他共识算法，例如基于法定人数的解决方案Q/U[37]和HQ[38]，其中客户端直接与副本通信。基于法定人数的解决方案以降低容错数量为代价减少了共识延迟。例如，PBFT需要3f+1个副本，而基于法定人数的解决方案需要5f+1 个副本，其中f为故障副本的最大数量[39]。Zyzzyva在无故障情况下提高了系统性能，但即使单个节点崩溃也会显著降低性能。因此，当系统中存在故障节点时，Zyzzyva运行缓慢[40]。

比特币中的共识算法是工作量证明（PoW），所有无故障的矿工最终都将拥有相同的区块链，因此PoW是一种弱一致性算法。为了解决PoW的高成本问题，提出了权益证明（PoS）和委托权益证明（DPoS）。在PoS/DPoS中，矿工不需要求解计算难题，而是根据其在系统中的资产来确定矿工身份。上述所有比特币相关共识算法都需要在系统中发行代币，因此无法应用于动态边缘计算环境。

总之，Paxos 和 Raft 效率较高，但仅能容忍崩溃故障；比特币相关共识算法满足弱一致性，但确认延迟过高，且需要发行代币；拜占庭容错共识算法（如 PBFT 及其变体）适用于静态环境，在动态系统中表现不佳，且通信开销对终端设备而言过大。本文提出一种基于双层区块链的框架以提供数据完整性，并提出一种新型的动态随机拜占庭容错共识算法 DR‐BFT，该算法可支持资源受限且动态在线/离线的终端设备。

3. 数据完整性保护框架

在本节中，我们介绍了一种基于区块链的边缘计算数据完整性保护框架和区块结构。符号和表示法列于表 1。

表 1 符号表

符号	含义
i	节点 i
u	服务器 u
di	节点i生成的数据
di,u	节点i生成并存储在边缘服务器u中的数据
dl i	末端节点i生成并本地存储的数据
TiM	节点i生成的Merkle树
B	存储每个边缘服务器发送的Merkle树哈希值的缓冲区由每个边缘服务器发送
Ba	存储所有已接受Merkle树的缓冲区
轮次i	当前步骤的第ith轮次

3.1. 数据完整性保护框架概述

我们提出一个如图1所示的双层框架。该框架分为终端设备层和边缘服务器层。终端设备层由智能手机、传感器、智能家居设备、工业控制设备等终端设备组成。终端设备产生数据，并将部分数据上传至边缘服务器。边缘服务器为终端设备提供存储与计算服务。每个边缘服务器u及其所服务的终端设备共同维护一条私有链。边缘链位于边缘服务器层进行维护。边缘链是一个联盟链，每个边缘服务器都是联盟链中的一个节点。每个边缘服务器同时参与联盟链和私有链。私有链与边缘链（联盟链）在边缘服务器处相交：每个边缘服务器为部分终端设备提供服务，参与私有链的运行，同时也是边缘链中的一个节点。私有链并行处理数据，提高了系统的吞吐量。边缘服务器定期上传在私有链中处理结果的汇总信息，并在边缘链中生成区块。即使某个边缘服务器恶意行为，也无法篡改私有链中的数据，原始数据仍然可追溯。

3.2. 私有链中的区块结构

我们使用如图2所示的区块结构。每个区块分为三层：区块头、默克尔树和区块体。区块头位于第一层，包含区块高度、时间戳、默克尔根等信息。第二层的默克尔树由树节点组成，这些树节点是可选的；即某些终端设备不存储完整的树；它们可能仅存储树的一部分，即可以证明其数据存在的路径，甚至不存储树的任何部分。区块体位于第三层，包含完整数据，这些数据也是可选的；也就是说，区块体可能仅包含部分完整数据。每条数据在默克尔树中都有一个对应的叶节点，而该叶节点是该数据的哈希值。分层区块结构可以帮助边缘服务器和终端设备减少需要存储的数据量，同时不丧失数据验证能力，因为每个节点可能只需要存储部分数据。该节点保留默克尔树的一条路径或根，可用于区块验证。

3.3. 边缘链中的区块结构

每个边缘服务器同时参与边缘区块链和私有区块链。边缘链中的区块遵循私有链中的分层区块结构。然而，边缘链的第三层与私有链中的不同。图3 展示了存储在边缘服务器中的区块。联盟链中每个区块的每棵叶节点由一个数据包构成。每个数据包由来自各私有链在特定时间间隔 [Ts1, Ts1,Ts2]内收集的区块组成，这些区块由每个边缘服务器收集。边缘服务器使用在时间间隔 [Ts1,Ts2]内从私有链收集的区块生成默克尔树。区块内的默克尔树构成一个数据包，该数据包被哈希为一个摘要，该摘要被视为联盟链区块中的叶节点。

3.4. 框架中的数据存储

我们有三种存储需求：边缘服务器中的边缘链数据存储、终端设备中存储的私有链数据，以及边缘服务器中存储的私有链数据。我们从存储位置的角度介绍数据存储。

3.4.1. 终端设备中的数据存储

终端设备中存储着两种类型的数据。一种是由终端设备上传并存储在边缘服务器中的数据，另一种是本地存储在终端设备中的数据。对于前者，终端设备只需存储数据的哈希值，完整数据由边缘服务器存储。对于后者，生成数据的终端设备需要存储数据本身，并将数据的哈希值广播到其他节点，而边缘服务器则存储这些哈希值。对于默克尔树，终端设备只需存储能够证明其拥有数据的路径，如图4中的蓝色实线所示。对于非终端设备自身上传的数据，只需在区块中存储最高层的树节点，以证明数据的存在性，如图4中的黑色虚线所示。通过这种方式，终端设备可以在保持验证区块能力的同时节省存储空间。

3.4.2. 边缘服务器中的数据存储

两种类型的数据被存储在边缘服务器上：存储由终端设备上传的完整数据以及存储在终端设备中的数据的哈希。边缘服务器中的存储结构与终端设备中的类似，但边缘服务器需要存储默克尔树中的所有节点，以便在终端设备中的Merkle树丢失时提供备份。存储在边缘服务器中的完整数据可以是明文或密文，具体取决于应用需求。

3.5. 数据处理和广播

每个节点在由边缘服务器组成的联盟链以及由边缘服务器和多个终端设备组成的私有链中，都拥有一个公钥和一个私钥，用于对数据、消息等进行签名。在以下两种情况下，节点需要更新密钥：密钥泄露，或节点生成了一对新的公钥/私钥。每个边缘服务器在不同的情况下持有不同的密钥链。网络中的每个节点都可以获取公钥，而私钥则由节点自身秘密持有。由于节点在分布式P2P网络中相互连接，每条消息在广播到其他节点之前都必须进行加密。

在私有链中，终端设备的数据可能以两种方式存储：存储在边缘服务器中，以及本地存储在终端设备中。在数据处理过程中，对于由终端节点i生成并需存储在边缘服务器u中的数据di,u，终端节点i将di,u连同终端节点i的签名Sigi⟨di,u⟩一起上传至边缘服务器u，使用安全哈希算法生成数据di,u的哈希值Hash(di,u)，本地存储该哈希值，并对该哈希值进行签名得到Sigi⟨Hash(di,u)⟩，然后将Hash(di,u)及其签名Sigi⟨Hash(di,u)⟩发送给其他终端节点。终端节点接收到Hash(di,u)后，使用发送方的公钥验证签名Sigi⟨Hash(di,u)⟩。对于本地存储在终端节点i中的数据dl i，它生成dl i的哈希值Hash(dl i)，对 Hash(dl i)进行签名得到Sigi⟨Hash(dl i)⟩，然后将哈希值Hash(dl i)及其签名Sigi⟨Hash(dl i)⟩发送给该私有链中的其他节点（包括其他终端节点和边缘服务器）。节点在接收到Hash(dl i)和Sigi⟨Hash(dl i)⟩后，使用发送方的公钥验证该签名。所有被接受的数据都将存储在集合B中。

联盟链中的数据处理和广播与私有链类似，只是联盟链中只有一种类型的数据。每个节点i将收集在一段时间内在私有链中生成的已排序的区块头集合Blockheads。Blockheads中的每一项都是一个 Blockhead，我们依次使用安全哈希算法（如SHA256）生成集合 Blockheads中每个Blockhead的哈希值，并将每个 Blockhead的哈希值存储在集合 BhHash中。然后我们生成默克尔树 TM i，计算哈希值得到 Hash(TM i)，并对该哈希值进行签名，得到 Sigi ⟨Hash(TM i)⟩。节点i向其他节点广播 Sigi ⟨Hash(TM i)⟩和 TM i。一旦某个节点接收到这些消息，该节点便使用相同的哈希算法计算 TM i的哈希值，并验证 Hash(TM i) 的签名。如果签名有效，则该节点比较这两个哈希值是否相同。如果相同，则 TM i将被接受，并作为第3层中的一个数据块存入 图2；否则，TM i是错误的，因此被忽略。所有被接受的默克尔树数据将被存储在集合Ba中。

4. 共识算法DR‐BFT

在本节中，我们首先详细阐述如何解决动态节点离开/加入以及动态系统可能引发的冲突问题。随后，我们提出了共识算法 DR‐BFT，该算法由三个子算法组成：字符串共识、二元共识和数据正确性验证。

在PBFT及其变体中存在一个领导节点，当检测到该领导节点恶意行为时需要更换，这会减慢共识过程。DR‐BFT算法的核心思想是在私有链或边缘链中大多数（至少2/3）节点在线并在区块生成间隔内接收到相同消息的情况下，通过如算法1所示的字符串共识，无需领导者即可对代表所有消息的哈希值达成共识。如果达成共识，算法1将在第24行终止，即DR‐BFT实现了提前终止。这样，即使恶意节点成为领导者或领导者离线，共识算法也不会变慢。如果大多数终端节点未任意行为，但其接收的消息不同，则算法1选择一个随机主节点，该节点将广播其数据。与PBFT的领导者不同，该随机主节点不收集或排序其他任何节点的消息，仅在单个共识轮次中广播其值一次。随后，DR‐BFT通过算法3调用数据验证过程，以验证广播的数据是否有效。如果数据有效，则运行如算法4所示的二元共识，对已验证的数据达成共识并保证系统一致性。在网络中传输的消息为哈希值，以便在资源受限的终端设备运行共识时减少通信开销。边缘链通过如算法2所示的字符串共识达成共识，共识值为完整Merkle树。

4.1. 动态节点离开/加入与冲突解决

边缘计算可能在大规模环境中运行，该环境包含数千个终端设备，如传感器和智能设备。我们面临一些会导致动态性和争用的问题：第一，节点可能会临时或永久地加入或离开系统，因此应考虑动态网络。第二，在密钥设置和更新过程中，某些节点可能获得新密钥，而其他节点可能获得过时密钥，从而导致冲突。此外，还可能存在其他导致冲突的操作。第三，某些组通信需要消息按正确顺序传递。

例如，节点A将其密钥k0更新为k1,，然后将密钥k1更新为k2。然而，这些更新消息并未按顺序到达所有其他节点，部分消息甚至丢失，导致不同节点获取到不同的密钥。当另一个节点B上线并请求系统中每个节点的密钥时，节点B将无法识别节点A的当前密钥。在这种情况下，将发生系统错误，甚至可能被某些拜占庭节点用作攻击手段。

我们采用一种基于法定人数的方法来解决上述问题。法定人数的能力在[41]中进行了介绍。一些共识算法[37,38,42]也应用法定人数系统来解决此类问题以及[41]中提到的其他问题。然而，大多数法定人数系统要求所有副本（节点）必须可用，因此无法支持动态系统。我们提出了一种改进的法定人数方法，以应对节点的动态离开和加入，借鉴了动态路径法定人数系统[43]的思想。

4.1.1. 竞争解决

所提出的法定人数方法中的法定人数结构与[43],中相同，该方法用连续域方块[0, 1） ×[0, 1） ∈ R2替代整个网格。该域被分解为类似单元的小部分，称为单元，每个单元包含一个节点。将方块分解为单元的过程通过维诺图分解实现，如图5(a)所示。

当节点加入或离开系统时，需要更新法定人数结构，分解方式将如图5(b)所示发生变化。本文中的加入和离开操作与[43]中的不同。节点i加入系统的过程如下：

(1) 每个节点包括节点 i从[0, 1) ×[0, 1)中的最大单元格中随机地选择一个点(x,y)作为位置。

(2) 找到其单元格包含 (x,y) 的节点，并查找该节点邻居的信息。

(3) 每个节点都运行相同的维诺图分解算法。

节点离开操作与节点加入操作类似。当一个节点离开系统时，会通知其他节点，这些节点将重新分配该单元的区域。如果该节点在通知其他节点之前就失去了与系统的连接，其他节点将在发送消息时检测到连接丢失，并随后重新分配该区域。

基于法定人数结构，法定人数集合由[43]中的两条相交线定义：一条水平线和一条垂直线。在动态网络中，如果每个节点的加入或离开行为都能被其他节点知晓，则该方法是可行的。然而，在动态环境中，设备可能会在没有任何预兆和迹象的情况下失去连接。因此，法定人数集合可能变得不完整，导致两个法定人数集合无法相交。我们改进了法定人数集合的选择方法，以确保当法定人数集合中的某些节点离线时，任意两个法定人数仍然能够相交。图6 展示了法定人数集合中一个节点离线时的情况。两条红色点划线相交，被红色点划线穿过的单元将被选为法定人数集合。每个包含红色大圆点并具有绿色实粗边的单元即为被选作法定人数集合的单元。具有黑色点线边且内部包含红色三角形的单元是离线节点的单元。内部含有红色小方点的单元表示围绕离线节点但最初未被选入法定人数集合的节点。其余单元则不包含在法定人数集合中。

一旦客户端发送可能引起争用的请求，客户端需要选择一个法定人数来发送其请求。选择过程如下：

• 步骤1：客户端随机选择一条垂直线和一条水平线，并选中被这些线穿过的单元（节点）。

• 步骤2：如果客户端成功收集到法定人数的响应，则请求过程终止。否则，某些节点可能离线或无法接收消息，客户端将进入步骤3。

• 步骤3：客户端向Vironoidiagram中围绕离线节点的节点请求该离线节点的信息，例如识别编号、先前位置等。然后客户端将本应发送给离线节点的请求发送给周围的节点，如图6所示。

• 步骤4：如果客户端收集到了所有被请求节点的响应，则该过程终止。否则，客户端返回步骤3并重新执行。

通过这种方式，法定人数系统可确保任意两个法定人数集仍然相交，即使存在离线或无法接收请求的节点。因此，争用可通过法定人数解决。

4.1.2. 动态节点离开/加入

After leaving th系统，t he nod 会暂时处于“盲期”，需要重新加入系统才能“看到新世界”。在“盲期”期间，系统的状态可能已经发生变化。对于需要加入或重新加入系统的节点，都需要更新到最新的状态并达成共识。

新加入或重新加入的节点需要获得边缘链节点和私有链的双重许可。一旦该节点被授权，它需要加入法定人数，且每个其他节点都需要重新分配图以添加这个新加入的节点。在该节点监听消息完成一个完整的共识轮次后，该节点将能够确认当前系统中的最新区块，并参与下一轮共识，从而跟上整个系统进程。

4.2. 字符串共识

字符串共识基于一致性（与PBFT[36]和Zyzzyva[40]相同），并借鉴了Berman 等人[15]提出的阶段国王协议的一些思想。字符串共识具有以下特性：如果至少有n −f个正确节点具有相同的输入字符串值，则所有正确节点将立即就该值达成共识；如果至少有n −f个节点是正确的，但它们的输入值不相同，则这些节点将就某个正确节点的值达成一致（即该节点在字符串共识中行为并非任意），但字符串共识不保证该值是有效的。在后一种情况下，DR‐BFT 使用数据正确性验证和二元共识来达成共识并保证有效性。字符串共识最多可容忍f个故障节点，因此在区块链中总共需要 3f+ 1个节点。

算法1是运行在由终端设备维护的私有链上的基于一致性的字符串共识算法。我们

算法1：字符串共识（终端设备）（f <n/3） 输入：Ts1, Ts2,B 输出：xr,{DataProc}, np, 早停 1 keep ⇐false; 2 早停 ⇐ true; 3 按时间排序(B);4{DataProc}⇐从B中提取 Ts1到Ts2之间的数据; 5 树节点 ⇐哈希({DataProc}); 6 Merkle根 ⇐由树节点生成的默克尔树的根; 7 xr ⇐ Merkle根; 8 for 轮次i ⇐ 1到 f + 1 do 9 广播值(xr); 10 if 接收到值(y) 至少 n −f 次 then 11 keep⇐ true; 12 广播提议(y); 13 else 14 keep⇐ false; 15 if 接收到提议(z) 至少 f + 1次 then 16 keep⇐ true; 17 xr ⇐z; 18 else 19 keep ⇐ false; 20 if keep ⇐true then 21 if xr=Merkle根 then22 {B}={B} −{DataProc}; 23 np⇐完成; 24 return xr; 25 else 26 np ⇐ v验证; 27 return xr;// 该行仅执行一次 28 早停 ≡ false; 29 for 节点i（由CSRGN随机选择的随机主节点）do 30 if 节点i之前未被选中过 then 31 w⇐(节点i的xr); 32 节点i广播值(w); 33 break ; 34 if 接收到提议(xr) 少于 n ⇐ f 次 then 35 xr ⇐ w;

假设其处于同步网络下，且大多数情况下可以实现提前终止。算法1 的最终决策值是默克尔树根。每个节点根据接收到的消息进行决策，所有节点最终就同一个字符串值达成一致。对于输入值，Ts1和Ts2是时间戳，集合B是用于存储接收消息中数据的缓冲区。对于输出数据，xr是决策值，集合DataProc是B的处理后的缓冲区。

当参与共识的节点确定共识决策值时，np处于 done状态意味着该节点生成了与决策值相同的默克尔树，然后该节点认为决策值是正确的。np处于 verify状态意味着该节点无法生成与决策值所表示的相同的默克尔树；即该节点拥有的数据集合B与决策值的所有者不同。每个节点需要确保数据的有效性，并且在验证数据后（如果适用），每个节点需要找出哪些本地数据未被决策确认（例如，数据不在决策的Merkle树中）。

算法2： 字符串共识（边缘服务器） (f<n/3) 输入: Merkle树 输出: χ 1按时间排序(默克尔树集合); 2 Merkle树 ⇐从完整的默克尔树生成的 树节点; 3 xr ⇐Merkle树; 4对于 轮次i ⇐ 1到 f + 1执行 5 广播值(xr); 6 如果 接收到值(y) 至少 n −f 次 那么 7 广播提议(y); 8 如果 至少 f + 1 次接收到提议(z) 则 9 xr ⇐z; 10 如果 keep=真&&xr= Merkle树 那么 11 χ ⇐Merkle树; 12 返回 χ; 13 for节点i是随机选出的随机主节点 由 CSPRNG do 14 如果 节点i 之前未被选中 则 15 w⇐（xr的节点i）； 16 节点 i广播 值(w)； 17 break ; 18 如果 收到的 propose(xr) 少于 n −f 次 则 19 xr ⇐ w; 20 χ ⇐ xr;

算法1迭代运行，迭代/轮次的数量最多为 f+ 1。在第一轮中，如果有超过 2 3 n个节点是正确的，则该算法将在一轮内完成， DataProc中的数据将从缓冲区B中清除。如果只有少数节点持有相同的输入值，或者在极端情况下每个节点持有的值都不同（这可能是由于网络故障导致的），则这些节点最终将决定来自某个未向不同节点发送不同值的节点的值（例如，当将其视为随机主节点时，该节点未表现出拜占庭行为）。然而，此节点的初始值可能是非法的或与其他节点不同，因此每个节点自身设置np（下一过程），它将成为算法 3的输入。early是用于指示共识是否实现提前终止的标签。如果 early为真，则不会触发算法 3和算法 4。

边缘服务器中联盟链的字符串共识算法如算法2所示，其中共识值为完整的Merkle树。算法2可保证每个边缘服务器获得完整的决策值。算法2与算法1类似，但存在以下差异：

• 集合B是用于存储每个边缘服务器发送的Merkle树的缓冲区。

• 算法 2的最终决策值是完整Merkle树。

4.3. 数据正确性验证

共识值是终端设备中的默克尔树根，因此每个节点都需要在本地验证共识值，以确保默克尔树的有效性。我们提出了一种数据正确性验证算法，如算法3所示，该算法用于np在算法1中某个节点执行 erify操作时。每个节点i验证默克尔树内的数据，以确保决策的有效性。节点i请求xr的拥有者提供默克尔树T M。如果节点i在该时间期间没有其自身上传的数据

算法3: 数据正确性验证 输入: xr, np 输出： 决策 ∈{0, 1}，{DataProc} 该节点是节点 i 1如果 np= done则 2 goto第14行； // 针对每个节点 3请求xr ’s 所有者，用于默克尔树 TM； 4如果 节点i在该时间内没有自己的上传的数据 TM的then 5 使用树节点计算树根root 6 如果root!=xr则 7 决策 ⇐ 0; 8 返回; 9 对于 k =1到 K (K ≥ 3) 的默克尔树节点 执行 10 随机地选择一个树节点； 11 如果签名或哈希验证失败 则 12 决策 ⇐ 0; 13 返回; 14否则 15 foreach 叶节点 ∈ TM do 16 验证叶节点中的签名 17 如果 签名验证失败则 18 决策 ⇐ 0; 19 返回; 20 如果 叶节点中的数据属于节点i 则 21 从节点 i 的 {DataProc} 中删除数据 22决策 ⇐ 1;

对于TM，节点i选择一个随机的树节点来验证签名。该节点验证默克尔树TM中每个叶节点的签名。如果在签名验证过程中有任何签名验证失败，则数据正确性验证失败。

4.4. 二元共识

算法4是所提出的基于随机化的二元共识算法，它是Ben‐Or和 Michael的随机共识[44]的一个变体。每个节点如果在上一轮未做出决策，则会随机选择一个值，且每个节点最终将做出1或0的决策。在算法4中， −表示“任意值”。每个节点有三种可能状态：0、1和 e，其中e表示发送方尚未做出决策，而0和1分别表示决策为假或真。在此算法中，如果有超过一半的节点是正确的（并且它们的消息也到达了目的地），则决策将在第16行立即做出。如果一个节点未收到 n 3 +1相同的消息，但至少收到了一个值，它将把自己的 v值i更改为该值。当一个节点多次接收到0和1后，它将把 v值i更改为重复次数更多的那个值。如果未接收到任何值，或者0和1的重复次数相同，则该节点将在第21行随机选择一个值。二元共识算法满足期望时间为 O(2 n )的终止性。

算法4： 二元共识 (f<n/3) 输入: Own值 ∈{0, 1} 输出:决策 ∈{0, 1} // 该节点是节点 i 1 v值i ⇐OwnValue; 2轮次i ⇐ 1; 3阶段1： 4广播 消息(轮次i,1, valuei); 5等待直到（至少接收到有效的 消息(轮次i,1,−) n−f时间); 6阶段2： 7如果 val 在接收到的内容中至少重复 n/2+ 1次 消息(轮次i, 1,−)则 8 广播 Message(轮次i,2, val); 9否则 10 如果 0 和 1 都恰好重复 n/2次 则 11 goto第21行; 12 else 13 广播 消息(轮次i,2,e); 14等待 直到 消息(轮次i,2,−) 被接收超过 2n/3时间; 15如果 val 在接收到的中重复超过 n/3次 消息(轮次i, 2,−)则 16 decide决策 ⇐ val; 17 广播消息(轮次i+1,1,决策); 18如果 至少收到一条 消息(轮次i,2, val)，则 19 valuei ⇐ val; 20否则 21 valuei ⇐值，该值以50%的概率从{0,1}中选取； 22轮次i ⇐轮次i+ 1; 23转到 阶段1；

4.5. 私有和边缘链中的共识

在介绍了三个子算法之后，我们引入了该框架中的共识机制。终端设备和边缘服务器中的共识机制是不同的。

4.5.1. 终端设备的私有链中的共识

步骤1：私有链中的每个节点处理并广播数据，并获取集合 B。

步骤2：每个节点周期性地启动字符串共识算法（算法1），并在给定周期[Ts1,Ts2]内获得输出。

步骤3：如果np在算法 1中完成，则算法1 的输出 xr被立即接受为最终共识决策，无需进入步骤4。如果 早 为假，每个具有xr的节点启动数据正确性验证算法（算法3），并获得输出值 决策。

步骤4：每个节点通过将决策赋值为OwnValue来启动二元共识算法（算法4）。如果二元共识值为1，决策被接受为最终共识决策χ，并且每个节点i重新广播其{DataProc}，即区块链未确认的数据集合；否则，xr被拒绝，所有节点回滚到步骤1之前的状态，重新广播Ts1和 Ts2,之间的数据，并再次启动共识过程。

4.5.2. 边缘服务器的联盟链中的共识

步骤1：联盟链中的每个节点处理并广播数据，并获得集合Ba。

步骤2：每个节点周期性地启动字符串共识算法（算法 2），并在给定周期 [Ts1 ,Ts2] 内获得输出。

步骤3：对于每个节点，如果共识算法中确定的MerkleTree与本地生成的默克尔树相同，则该节点直接接受MerkleTree ；否则，该节点接受MerkleTree，检查是否存在未被区块链确认的本地数据，并根据广播机制重新广播该数据。

步骤4：每个节点根据共识值生成新区块。

我们给出了多个示例来展示这些子算法的工作方式。

示例1。 假设终端节点i在时间间隔Ts1和Ts2内接收到10条消息{ ms1,ms2, . . . , ms10}，此时网络状况良好，每条消息均能及时到达目的地。因此，私有链中的每个节点都持有ms1, ms2, . . . , ms10，并使用这10条消息计算出相同的Merkle根。在这种情况下，私有链中每个节点至少会接收到n − f value(y)，并且每个节点将广播提议(y)（x = y = z = MerkleRoot），并将keep设置为true。因此，每个节点都将找到xr= MerkleRoot，并立即以np = done 和early = true的状态终止，而无需调用数据正确性验证和二元共识。共识完成后，这10条消息{ms1, ms2, . . . , ms10}被打包进区块。

示例1 介绍了在私有链中每个节点都良好且网络无故障的情况。接下来，我们介绍发生一些故障的情况。

示例 2。 假设一些节点（少于f个节点）在Ts1和Ts2期间离线后又重新上线。这些节点可能会收到不同的消息，因为部分消息丢失了。然而，算法1第 10 行和第15行中对相同的消息数量的要求仍可满足。因此，可以实现提前终止，并触发数据正确性验证和二元共识。

我们将正常节点定义为在共识过程中遵循共识算法的节点；即，该节点既未崩溃也不是拜占庭节点。如果一个随机主节点在算法1中期望地运行，则称其为正确的随机主节点；否则，称其为错误主节点。若一个正确主节点的广播值（即算法Merkle根在算法1中的值）能够通过算法3验证，则该正确主节点为有效主节点。当接收到第3行的 Merkle树请求后，若一个正常主节点向大多数节点发送了相同且有效的默克尔树，则该正常主节点为有效主节点。3。

示例 3。 假设有 10 条消息 {ms11,ms12,. .. , ms20} 在 Ts1 和 Ts2 期间发生。然而，网络故障导致部分消息未能到达目的地；同时，一些节点离线和上线，未能接收到某些消息。因此，不同的节点可能拥有不同的消息集合，甚至可能出现没有任意两个节点具有相同的消息集合，尽管拥有不同消息的节点并非全部为恶意节点。在这种情况下，在算法1的第 10 行，没有任何值 y 重复出现 n−f 次，且没有任何正常节点在第15行广播 propose(z)。字符串共识将进入第 28 行，并选择一个随机主节点 i，该节点可能是：(1) 一个有效主节点，(2) 一个错误主节点，或 (3) 一个正确主节点但不是有效主节点。在情况 (1) 和 (3) 中，每个正常节点会将其 Merkle根 xr 更改为节点 i 的广播值 w，并在算法1的第 35 行以 w 作为决策值终止。随后 DR‐BFT 执行数据正确性验证算法。在情况 (2) 中，节点 i 可能向不同节点广播不同的值。如果它向 n− f 个节点广播相同的值，则共识过程将在下一轮转至示例 2。如果它向不同节点广播不同的值，并且至少没有 n− f 个节点从节点 i 接收到相同的值，则共识过程将返回示例 3 的开始。最终，所有正常节点将选择一个正确主节点，并在算法1的第 35 行以其默克尔根 w 终止。

5. 共识 DR‐BFT 分析

在本节中，我们将从共识有效性、抗攻击能力、系统开销等方面对所提出的DR‐BFT共识进行分析。

5.1. 共识正确性证明

我们假设系统中拜占庭节点的数量为f< 3n ，其中n为节点总数。

5.1.1. 字符串共识正确性证明

正常节点不会表现出拜占庭行为，但也不能保证其初始值是有效值。

引理1
如果一个正常节点提议 val，则每个正常节点都提议 val。

证明。假设一个正常节点提议 val，另一个正常节点提议 val′。注意，一个正常节点只有在至少收到某值 n −f 次后才会提议该值。因此，这两个正常节点必须分别从正常节点处至少收到了 val或 val′ 共 n − 2f 次（最多 f 个拜占庭节点可以向一个节点发送 val，同时向另一个节点发送 val′ ）。于是，系统中将有 2(n −2f)+ f = 2 n −3f 个节点（每个节点的消息仅被接受一次）。然而，由于 f < n 3，可得 2n − 3f > n，这与系统中节点总数为 n 相矛盾。 □

引理2
如果所有良好节点在任意轮次中具有相同值，它们将不会更改该值。

证明。 如果所有正常节点以相同的初始值开始，则所有正常节点将在算法 1 的第12行提出该值，并且所有正常节点将至少收到 n −f个提案。在收到这些消息后，所有正常节点将keep该值，并且永远不会将其更改为领导者的值。 □

引理3。
经过一轮具有良好的随机主节点后，所有正常节点将不再改变其值。

证明. 如果随机主节点是一个正常节点，并且所有正常节点都将其值更改为该随机主节点的值，则所有正常节点将具有相同值。根据 Lemma2，该值将不再被更改。如果某个正常节点未将其值更改为随机主节点的值，则该节点必须已收到某一值至少 n−f次。因此，至少有 n−2f个正常节点广播了该值，每个正常节点至少收到该值 n−2 f次。由于 f< n 3且 n−2f>f，所有正常节点会将其值设置为该提议值。根据Lemma 1，仅有一个值可能被提议超过 f次。结合 Lemma2，该值将不再被更改。 □

引理4。
如果正常节点持有不同值，它们最终将决定采用来自某一正常节点的相同值。

证明. 假设所有正常节点持有不同的值。根据Lemma3，经过一轮包含良好随机主节点的轮次后，所有正常节点将更改为该良好随机主节点的值，并且不再改变，因为该良好随机主节点本身也是一个正常节点。引理得证。 □

引理5。
每个正常节点最终决定相同的值。

证明。 如果所有正常节点具有相同的初始值，它们将决定该值，并在算法1的第24行终止。f个正常节点持有相同初始值时，其他正常节点将更改为该值，并在第27行终止在算法 1中。如果所有正常节点持有不同值，它们也将决定相同值，并最终通过引理4终止。 □

定理1. 终端设备执行的字符串共识算法（如算法1所示）满足一致性、全同有效性、有效性和终止性。

证明. 当所有正常节点以相同初始值开始时，它们达成一致（由引理2），或者在经历一个包含良好随机主节点的轮次后，它们会就同一值达成一致（由引理4）。全同有效性和有效性分别由引理2 和引理4保证。结合引理5，该算法最终终止。 □

关于算法1的说明：算法1不能保证决策值是有效的（来自正常节点），该有效性问题通过数据正确性验证算法3和二元共识算法4解决。

定理2. 边缘服务器运行的字符串共识，如算法2所示，满足一致性、全同有效性、有效性和终止性。

证明. 算法2的过程与算法1的过程基本相似。因此，这两个算法的证明基本相同，我们省略算法2的证明。 □

5.1.2. 二元共识正确性证明

引理6.
每个正常节点将在相同的轮次i(≥ 1) 中提出相同的值，在二元共识算法4中。

证明. 假设两个正常节点 gn和 gn′分别提出0和1。即，gn至少收到0 2n+ 1次，且 gn′至少收到1 n 2+ 1次。我们可以得出至少有2(2n+ 1) = n+ 2个节点，这与系统中仅有 n个节点的事实相矛盾。引理得证。 □

引理7
在二元共识算法4中，如果一个正常节点在轮次i决定了一个决策值 decision，则没有其他正常节点在轮次′ i>轮次i决定decision′ ≠ decision。

证明。 如果一个正常节点 gn 决策一个值 decision，则节点 gn必须已收到 (n −f) 个有效的 消息(roundi, 2,−)，其中包括 n 3 消息(roundi, 2, decision)。在此轮次中，另一个正常节点 gn ′可能有两种情况：

(1) 节点 gn ′也接收 消息(轮次i, 2,决策 ′ ) 共 n 3 次，并在 轮次′ 决定 决策i。根据 引理6，决策′ =决策。

(2) 节点 gn ′收到的有效消息少于 n − f 个。由于节点 gn 收到决策消息，gn ′将至少接收到多数 Message(roundi,2,decision)，并且 gn ′会将其val 设置为 decision。在下一轮 roundi+ 1 中，对于 gn ′ 存在两种情况：(a) 所有接收到的消息具有相同值 decision； (b) 否则。如果发生情况(a)，显然 gn ′将决定与其他所有节点相同的值。对于情况(b)，一个故障节点可能发送此类消息；然而，这与至少重复了 n−f 次的 Message(roundi,2,decision) 相矛盾，因此拜占庭值不会被接受。因此，无论发生情况(a)还是情况(b)，所有正常节点都不会决定另一个值。也就是说，在轮次 round′ i >roundi 中，没有正常节点会决定 decision′ ≠decision。 □

引理8 如果某些节点决定值，则该值是某些节点的初始值。

证明。 假设存在矛盾，即某个节点 p在某一轮次中决定了一个值val，但最初没有任何节点拥有该值，则所有节点初始时都拥有另一个值 val′。因此，所有节点将在阶段1广播val′，且至少会收到 n/2 val′，于是每个节点将在阶段2广播 val′ ，并最终决定 val′，这与引理7矛盾。 □

引理 9 算法4中所示的二元共识满足终止性，即在最坏情况下所有节点在期望的 O(2n)轮次内终止。

证明。 如果每个正常节点具有相同的输入值，则所有节点将在两轮内决定该值。在引理7中，我们证明了如果一个节点决定了某个值，则所有其他正常节点不晚于下一轮也将决定相同值。假设没有节点在开始时接收到多数（n/2+1）的消息（轮次i,1, 0）或消息（轮次i,1,1）。在最坏情况下，每个节点随机选择0或1，在一轮中（第3行到第21行）所有节点选择相同值的概率至少为 1/2n。因此，期望轮数被O(2n)所限制。 □

引理10
每个正常节点最终在算法4中决定相同的值。

证明。 在 引理7中，我们证明了如果一个正常节点决定了一个值，则所有其他正常节点不迟于下一轮也会决定相同的值。如果存在一条消息(轮次i,2,−) 被重复不少于 n−f次，则至少有一个节点将终止。因此，我们只需证明，如果在第15行没有收到足够的消息，系统仍然能够决定一个值。注意，如果没有做出决策，每个节点将随机选择一个值，并且根据引理 9算法最终会终止。假设拜占庭节点向其他节点广播带有不同值的错误决策。当拜占庭节点广播0和1并使其重复相同次数时，正常节点将转入算法4的第18行来决定一个值。当拜占庭节点在阶段2以不同次数广播0和1时，必然存在一个值被重复至少n −f次，所有正常节点将根据引理7决定该值。因此，在任何情况下，每个正常节点最终都会决定相同的值。 □

定理 3 算法4中所示的二元共识满足一致性、有效性和终止性。

证明。 一致性由引理7 和 10保证，有效性由 引理8保证，终止性由引理9 和引理10保证。 □

5.2. 共识算法DR-BFT的安全性分析

共识算法的目标之一是确保所有正常节点就仅由正常节点推导出的决策值达成一致。共识算法面临可能影响一致性甚至导致整个系统崩溃的威胁。我们使用攻击树来分析可能导致系统崩溃的威胁和攻击路径，同时还分析了针对终端设备中共识的攻击。边缘服务器中的共识比终端设备中的共识更简单，因此我们省略了对边缘服务器中共识的分析。

我们构建了一个攻击树，用于说明针对破坏共识的攻击路径，如 图7所示。与门表示仅当父节点的所有子节点均为真时，该父节点才为真。或门表示只要任意一个子节点为真，则父节点即为真。具有实线框的节点和具有实线的路径表示可能发生的攻击或威胁，而具有虚线框的节点和具有虚线的路径则表示不可能发生。

在路径 1→2→3→4中，节点3不可能出现，因为二元共识保证了一致性。在路径 1→2→5→6中，算法4中不可能没有任何节点终止，因为它保证了终止性。路径 1→2→9→10→11也是不可能的，因为在一轮中每个节点的消息只会被接收（接受）一次，不可能同时有超过一半的节点接收到0且超过一半的节点接收到1；此外，算法4 实现了一致性，每个节点都将决定相同的值。路径 1→2→12也被算法1的正确性所阻止。因此，系统一致性得到保证。

攻击该系统的另一种方式是在不破坏一致性的前提下添加错误数据。如果并非所有正常节点（至少2n 3+1）持有相同的初始值，则此路径 1→20→23→24→25是可能的。算法1仅能保证每个节点就某个随机节点的值达成共识，但不能保证该值是有效的。因此，定理 1无法保证共识值来自非拜占庭节点。然而，无效数据将无法通过数据正确性验证，并且在算法4中会被其他节点进一步拒绝。因此，节点21不可能被攻破，从而该路径在节点20处终止。

在攻击路径 1→29→30→31 中，如果节点 29 的终止性被破坏，例如每次共识值都来自拜占庭节点，则共识也将受到攻击，这要求共识过程始终回滚。然而，这种情况是不可能的，因为系统中最多存在 f 个拜占庭节点，而节点 31 能够阻止此类攻击。

根据上述分析，我们的共识算法DR‐BFT能够抵抗潜在的攻击，使系统安全可靠。

6. 性能评估

在本节中，我们将所提出的共识算法DR‐BFT与原始的PBFT （一种流行的共识算法）以及最先进的BFT‐SMaRt[45]（一种状态机复制共识算法，以PBFT为核心）进行性能对比评估。

6.1. 仿真设置与模拟器介绍

我们在一台配备Intel Core i5 9400F@2.90 GHz CPU和16 GB 内存的双系统PC（Ubuntu 18.04和Windows 10）上实现了概念验证原型模拟器。该模拟器使用C++语言和Qt GUI框架开发。模拟器 GUI包含多个窗口和组件，如图8所示。控制面板位于顶部，包含8个按钮和2个滑块。这些按钮用于