一种基于共识机制的数字集群终端防失控方案研究

摘　要：

如何通过技术手段有效预防数字集群终端失控是数字集群通信系统规模化应用过程中亟需解决的安全保密技术之一。作为集群通信系统广泛应用的一种重要模式，直通模式具有无中心分布式组网的特点，故传统的方案无法有效实现直通模式下数字集群终端实时防失控。通过分析提出了直通模式下终端防失控面临的“谁来判定”及“如何判定”的核心问题，为解决上述问题，重新定义了区别于传统的失控概念，设计了判定规则，并借鉴了区块链中的实用拜占庭容错算法来设计可用于直通模式的数字集群终端防失控方案。

近年来，数字集群通信系统大规模应用于党、政、军等特殊用户和交通运输、能源、机场、港口等重大行业用户，在公共安全、政务专网、运输调度、应急通信等方面发挥重要的作用，由于其应用场景和用户性质的特殊性，系统的安全问题尤为重要。作为数字集群通信系统安全概念的一个重要分支，集群终端的防失控问题与系统运行安全息息相关。当前党、政、军等特殊用户装备使用的集群终端多为安全密码类装备，装备管控的等级较高，而手持式的集群终端具有体积小、使用率高、遗失风险大等特点，一旦装备丢失，将会给系统的使用安全带来威胁，也会给管理者带来管理压力以及给使用者带来使用负担，造成“慎用、怕用、不用”现象。因此，如何通过技术手段有效预防集群终端的失控或在失控后将系统安全的影响降到最低，是数字集群通信系统安全保密技术研究的重要课题之一。

01、现有工作及不足

1.1　集群终端防失控技术的现状

目前常见的数字集群终端防失控方案可以按照实施时间的不同划分为主动预防和被动响应两类。

1.1.1　主动预防

主动预防类方案实施于集群终端失控前，是指在正常使用过程中对集群终端状态进行实时监控，当依据预设策略规则判定有失控趋势时实施提前预警和处置的方法，常见的方案有电子围栏、蓝牙防丢器等。

（1）电子围栏。主流厂家的集群终端都内置卫星定位模块，具备地理信息系统（GeographicInformation System，GIS）坐标的感知和上传的能力，基于此，可由中心侧设备汇总集群终端的位置信息并对其进行实时监控，提前预警并自动处理集群终端的越界行为。

（2）蓝牙防丢器。采用可穿戴设备设计的蓝牙防丢器 [1]，须与集群终端配对使用，防丢器和集群终端彼此分开一定距离后预警或自动处理存储的敏感数据，用于防范集群终端掉落、遗失、被窃取等失控行为，此方案无须中心侧设备支撑，可由集群终端单独实现，但只对仅丢失主机或防丢器的情况有效。

1.1.2　被动响应

被动响应类方案是指集群终端失控后的防非法使用、防恶意破解，避免对系统后续的正常运行造成严重影响，常见的方案有终端安全防护、远程管控等。

（1）终端安全防护。终端安全防护的主要目的是增加集群终端失控后被冒用和破解的难度，降低信息泄露的风险。与传统在公网上工作的移动智能终端相比，集群终端在网络封闭性、协议专用性、软件可控性等方面存在差别，故两种终端对安全防护的侧重点存在较大差异。移动智能终端侧重于使用安全，而集群终端更侧重于防止被冒用以及失控后被分析破解，故多采用身份认证、安全存储、资源分割保护及本地应急销毁等措施。

（2）远程管控。为防止集群终端失控后被恶意冒用，可在集群终端失控时通过中心侧的管理类设备实现远程管理，如基于黑白名单的入网 / 密码鉴权、在线授启、遥毙 / 遥晕、远程销毁 / 更换密钥等。

被动响应方案大多是在失控后实施和发挥作用的补救措施，虽能从一定程度上将失控对系统运行安全造成的危害限制在较小范围内，但诸如失控上报、失控方案实施等过程需人工干预，人为因素会引起响应及时性差、反应速度慢等问题，对最终防失控效果造成影响，而主动预防方案能通过技术手段对失控行为进行“风险预判，主动响应”，防失控方式更加智能化，在实时性和最终风控效果上更有优势。

1.2　现有集群终端防失控技术的不足

集群终端防失控方案的设计和实施与集群通信系统的网络架构、设备配置及终端的工作运行方式密切相关，数字集群通信系统典型的工作模式可分为集群模式（Trunk Mode Operation，TMO）和直通模式（Direct Mode Operation，DMO）。

（1）TMO 模式。如图 1 所示，TMO 模式以集群基站（含配套的中心侧设备）为中心组成星型网络，中心侧配置基站和管理类设备（调度台、网管设备、密钥管理系统等），实现基站无线覆盖范围内的点对点、点对多的广播式业务通信，多用于固定区域范围内的调度通信场景。

图 1　TMO 模式组网架构

（2）DMO 模式。如图 2 所示，DMO 模式由相互为对等关系的集群终端组成无中心的网状通信网，可不依赖基站，即可基于集群终端实现点对点、点对多的广播式业务通信，多用小型任务分队外出任务时，非固定区域内的移动中通信场景。

图 2　DMO 模式组网架构

分析集群终端在两种工作模式下组网工作时的防失控方案，TMO 模式的星型网络架构及设备配置情况具备支撑现有的各种防失控方案实施的条件，可综合应用于各种常见的主动或被动措施，有效满足在固定区域内的集群终端防失控需求；因 DMO 模式的无中心网络架构不具备配置可信的中心侧设备来实现监控和管控的条件，故无法实施如电子围栏、远程管控等效果较好的方案，目前只能采用诸如终端安全防护、蓝牙防丢器等方案，终端安全防护措施虽能降低终端意外丢失造成的系统安全风险，但仅靠被动防御的方式来控制系统风险的效果是有限的，蓝牙防丢器虽能实时监控、主动预警并自动处理，但也只在仅丢失主机或防丢器的情况下发挥作用，对于集群终端整机被恶意窃取、抢夺等情况无法提供有效防护。

由此可见，现有的防失控方案虽能在一定程度上降低集群终端在 DMO 模式下以无中心组网工作时的失控风险以及失控后带来的安全威胁，但如何实现更有效的针对集群终端整机的实时监控以及失控后自动响应、快速处理的主动预防类防失控技术，有待进一步的研究和完善，本文研究的内容正是设计一种适用于此场景下的实时防失控方案。

02、方案设计

2.1　DMO 模式下集群终端实时防失控的解决思路

要实现 DMO 模式下集群终端的实时防失控，必须解决两个问题：一是如何判定，指任务分队在无固定区域范围内的整体移过程中，分队内各集群终端位置动态变化，基于什么规则来快速、合理地判定某终端是否失控或有失控的趋势；二是谁来判定，指所有集群终端关系对等，无全网公认的可信中心，此时谁负责判定某集群终端已“失控”才能保证判定结果的可信和权威性问题。

解决以上问题的关键思路是在某一个时间段内，以 DMO 模式工作的任务分队中所有的集群终端自动的基于“某种策略”，对某台集群终端当前处于“失控”的状态达成一致共识并共同判定，而非单独由某一可信的中心设备或人来完成判定。作为区块链的核心技术之一，共识机制所实现的“去中心化状态下达成一致共识”正是解决上述关键问题的一种可行方法，故本文借鉴区块链的共识机制来设计 DMO 模式下的防失控方案。

2.2　判定规则的设计

2.2.1　“失控”的定义

传统意义的失控是以使用者或管理者为中心，将其完全失去对物体本身的操作控制能力的状态定义为失控。与传统的失控概念不同，本方案以无中心组网工作的任务分队中所有的集群终端为整体，将某台集群终端（个体）有脱离任务分队（整体）趋势的“异常状态”定义为“失控”。此时，“失控”的集群终端虽仍有可能存在于任务分队所覆盖的区域内，但与任务分队中“大部分”集群终端的相对距离已超过可容忍的门限距离，随着“失控”的集群终端继续脱离任务分队，彼此间直线距离将超过与分队中“大部分”集群终端的通信极限，最终失去联系。上述的定义中有几个关键点需进一步明确。

（1）“大部分”的定义。假设任务分队内集群终端总数为 ，  本方案将除失控的集群终端外剩余的一半定义为“大部分”，即。（2）相对距离（Relative Distance，RD）。RD 是指集群终端之间通过双方 GIS 坐标计算得到的直线距离，全网集群终端的 GIS 坐标由集群系统采用私有协议定期更新。（3）门限距离（Distance of Threshold，DT）。DT 是判定集群终端是否“失控”的阈值，其数值与通信极限距离、全网 GIS 坐标单次更新周期和集群终端移动速度相关。对于手持式集群终端而言，因发射功率低、天线架高受限，陆地上典型通信极限距离约为 3 千米。当集群系统以排级编制规模（30 人）组网时，目前实测的全网 GIS 坐标单次更新周期约为 120 秒，在此期间，手持式集群终端可移动约 0.5 千米（按人奔跑速度 15 千米 / 小时估算），故本方案将 DT 值定义为常量 2.5 千米。

2.2.2　判定规则

综 上 所 述， 当 集 群 终 端 以 DMO 模 式 组网工作时，假定任务分队内集群终端总数为，若出现某集群终端与任务分队中超过个集群终端的相对距离 RD > 2.5 千米的情况，则判定该集群终端已失控。

2.3　共识机制的选择

共识机制最初诞生于分布式系统，是区块链中各参与节点针对某一状态达成一致性的策略方法，经多年发展已形成不同体系的多种共识算法，可分为区块链共识和经典分布式共识两大类，区块链共识算法常用于非授权网络（如公有链）中，主流的有工作量证明（Proof of Work，PoW）、股份权益证明（Proof of Stock，PoS）、股份授权证明（Delegated Proof of Stake，DPoS）等；经典分布式共识算法常用于授权网络（如私有链、联盟链等许可链）中，主要有 Paxos 算法、Raft 算法和实用拜占庭容错算法（PracticalByzantine Fault Tolerance，PBFT）等。

共识机制的合理选择需要结合集群终端的工作特点，通过对当前主流共识算法的分析可知：PoW 通过比拼算力获得记账权的方式，不适合算力受限的便携式集群终端；PoS 通过币龄、持币量等让少数节点获得领导人记账权的方式，不适合相互关系完全对等的集群终端；DPoS 通过投票选出少数见证人获得代表记账权的方式不适合此场景，原因如下：一是投票过程需大量实时信息交互，不适合信道资源有限、半双工通信的集群系统；二是判定“失控”必须所有终端知悉彼此真实的相对距离，不能通过少数“见证人”代表；三是 Paxos 算法和 Raft 算法虽然对节点宕机、通信数据丢失等问题的容错能力较强，但无法解决拜占庭问题，不适合基于开放式无线信道通信，或面临假冒终端恶意发布虚假消息的集群系统。

PBFT 算法采用广播的方式实现副本复制的运转模式，对算力的依赖程度较低，优点是吞吐量高、交易确认时间短、容错能力强，缺点是总节点数量需固定且提前知悉。而 DMO 模式工作的集群终端采用广播的方式通信、总数量相对固定等特点恰好与 PBFT 算法相契合，故 PBFT 算法更适合应用于集群终端 DMO 模式下防丢失方案中。

2.4　PBFT 算法及适应性改进

拜 占 庭 将 军 问 题 最 早 由 Leslie Lamport、Robert Shostak 等人 [2] 于 1982 年发表的论文 The Byzantine Generals Problem 提出，论文采用反证法证明了当将军总数大于3 f ，背叛者为 f 或者更少时，忠诚的将军可以达成命令上的一致。在分布式系统中常存在与拜占庭将军面临的相似情况：有正常节点（忠诚将军），有故障节点，也有拜占庭节点（叛变将军），系统的正常运行需要拜占庭容错（Byzantine Fault Tolerance，BFT）算法在正常节点间形成对某一状态的共识，其中，由 Miguel Castro 和 Barbara Liskov 于 1999年提出 PBFT 算法是目前应用较广的算法 ，它是一种状态机复制（State Machine Replication，SMR）算法，通过大多数诚实节点的正确消息过滤掉来自恶意节点的消息，能够容忍不超过 f个失效或恶意节点攻击。

如图 3 所示，PBFT 算法流程主要分为 4 个步骤，以 f =1，节点数 N 取最小值 4 为例，下图中 C 是客户端，节点 1 为共识节点中的主节点（primary），节点 2、节点 3、节点 4 为共识节点中的备份节点（backup），其中节点 4 为拜占庭节点或故障节点，表现是对其他节点的请求无响应。

图 3　PBFT 算法流程

（1）客户端 C 发送请求给主节点 1。（2）主节点 1 广播请求给所有节点，所有节点执行核心的 3 个阶段共识流程。（3）所有节点处理完 3 个阶段流程后，返回 Reply 消息给 C。（4）C 收到来自 f +1个节点的相同消息后，代表共识完成。

算法的 3 个阶段共识流程分别是 Pre-Prepare阶段、Prepare 阶段和 Commit 阶段。

（1）Pre-Prepare 阶段。主节点将客户端 C的请求分配消息序号，并向所有节点广播 PrePrepare 消息。（2）Prepare 阶 段。节 点 收 到 Pre-Prepare消息后，对消息的内容进行验证，若验证通过，则向所有其他节点广播 Prepare 消息。（3）Commit 阶段。在一定时间范围内，一个节点如果收到 2 f 个不同节点（包括节点自身）的 Prepare 消息并验证通过，则代表 Prepare 阶段已经完成，流程进入 Commit 阶段，节点广播Commit 消息。当一个节点收到条 Commit消息后（包括节点本身），代表大多数节点已经进入 Commit 阶段，这一阶段已经达成共识，可以返回 Reply 消息给客户端 C。

PBFT 算法的设计初衷是解决在信道可信、允许拜占庭错误的情况下实现诚实节点共识的问题，将其直接应用于无线集群移动通信系统中会存在以下问题。

（1）核心共识过程消息传递次数多，信道资源消耗大。PBFT 的共识过程消息传递次数与节点数量的平方成正比，完成单节点共识需要经过次传递，失控判定的前提是对所有终端GIS 坐标都达成共识，即需要 N 次独立共识过程，通过串行方式完成需要经过次传递。集群系统采用半双工方式通信，通信时独占信道，节点数 N 的增加必然会带来极大的信道资源消耗，这对资源受限的集群系统是不可接受的。（2）集群系统无法保证主节点选举和视图切换过程中必要的话权。PBFT 算法的主节点选举与视图切换策略相关，即，其中，p 为主节点号；v 为视图编号；R 为节点个数。视图由备份节点主动发起，切换过程需要备份节点和新主节点多频次的主动消息交互，集群系统的通信机制决定了发送视图切换所需的消息交互过程需竞争话权，系统无法提供实时话权保证。

为降低上述问题造成的影响，更好地设计集群终端防失控方案，可在不降低共识性能的基础上结合通信系统的特点对其进行如下适应性改进。

（1）取消客户端，仅保留主节点和备份节点角色。因任意一个集群终端都具备将共识数据全网广播发起共识的能力，无需通过主节点转发广播，故可取消客户端角色，仅保留主节点和备份节点角色，算法流程只保留核心的 3 个阶段共识。（2）简化 3 个阶段共识过程。终端失控的判定规则实施的前提是所有终端知悉其余终端的 GIS坐标并达成共识，经 Pre-Prepare 阶段和 Prepare阶段后，全网所有终端均具备了判定任一终端是否失控的条件。此外，后续的 Commit 阶段是对Prepare 阶段的一种“确认”，是为防止某些节点在 Prepare 阶段之后发生视图切换导致的不一致性，而本方案将改进主节点选举和视图切换策略，不存在此隐患，故将原本的三段式过程简化掉 Commit 阶段，以减少一次信息传播，降低对通信资源的需求，更好地满足在集群系统中使用。（3）消息传递引入流水线机制。为降低集群终端位置动态变化对判定结果带来的影响，必须高效完成所有终端 GIS 坐标形成共识的过程，本方案借鉴计算机流水线机制，将不同终端原本按顺序处理的 Pre-Prepare 和 Prepare 消息，通过消息重叠的方式集合成单条消息，减少大量信息传播次数，极大地提高共识效率。（4）改进主节点选举和视图切换策略。PBFT 算法的主节点选举和视图切换的目的是维持共识系统的可用性，因集群系统存在发起呼叫需话权抢占且通信独占信道的特点，故本方案将主节点选举和视图切换策略规定为在一个发送时间片内，获取话权的终端自动成为主节点。

03、具体方案

3.1　方案主要流程

为防止集群终端位置动态变化对共识过程及判定结果带来的影响，同时又能保证监控的实时性，本方案为周期性实施方案，在每个判定周期内执行以下流程。

（1）准备共识消息。全网所有集群终端及时获取并更新自身的 GIS 坐标，然后基于自身的 GIS 坐标信息和更新时间准备共识消息。（2）广播 / 接收共识消息。各终端争抢话权，将争抢话权成功的集群终端记为终端 X ，终端X 即成为当前的共识主节点，向全网广播共识消息；若已经完成本轮共识消息广播，则只接收共识消息。（3）接收验证共识消息。其他终端接收到终端 X 的共识消息后，验证其合法性、完整性和新鲜性。（4）判定自身 GIS 坐标是否达成共识。验证通过后，其他终端基于共识消息更新自身的全网节点位置关系表 GIS-table，然后判断自身GIS 坐标是否已达成全网共识，若达成共识，则进入步（5），否则直接进入步骤（6）。（5）判断自身是否失控。其他终端基于自身的 GIS-table 判断自身是否失控，若已失控，则自动执行主动防失控操作，然后停止密码服务；若未失控，则直接进入步骤（6）。（6）判断其余终端是否失控。其他终端基于自身的 GIS-table 判断是否有自身之外的终端失控，若失控，则执行相关防护措施（如将终端 X 列入呼叫黑名单），然后返回步骤（2）；若未失控，则直接返回步骤（2）。本方案的周期以全网首先完成 GIS 坐标获取 / 更新的时间为起始点，周期时长T 与终端总数 n 成正相关，公式为， t 为单次信息交互时间， n 和t 可用菜单方式预写至终端。

3.2　集群终端本地处理流程

基于上一节周期性判定其他终端和自身是否失控的主要流程设计，在每一台集群终端中具体的实现方式如图 4 所示。

图 4　集群终端本地处理流程

3.3　具体实施示例

为更充分地描述本方案，下面从集群系统的角度，结合实施示例和时序图对方案做进一步详细说明，首先假设如下情况：

（1）全网由总数为 n = 5 的手持式集群终端组成，故按 PBFT 算法中节点总数 n 与能容忍的拜占庭节点个数 f 的关系，可知 f =1。（2）设单次信息交互时间t = 2s ，故每个终端按周期 来计算下次更新 GIS 坐标的时间。（3）终端 A 在T0 时刻已失控（与终端 B、终端 C、终端 E 的 RD 值大于 2.5 千米），终端E 为拜占庭节点，不工作或不响应任何消息。（4）所有终端在 T0 时刻之前开始陆续开机，终端 A 全网最早完成 GIS 坐标获取（T0′ 时刻），终端 B 和终端 C 分别在 T0′′ 时刻和 T0′′′时刻完成 GIS 坐标获取。（5）终端 A ～终端 D 分别在T1，T 2 ，T3，T 4 时刻获得话权。

实施示例的防失控时序如图 5 所示。

图 5　实施示例的防失控时序

（1） T1 时刻，终端 A 向全网广播发送消

息，其中为终端 A 的身份，消息 m 是任务分队内所有终端的 GIS 坐标信息，包括终端 ID、GIS 坐标值和GIS 坐标更新时间，t1为消息 m 的发送时间戳，为使用认证加密方式加密的消息 m ，为对密文消息 m 的签名。

消息 m 的内容字段如表 1 所示，含 3 个部分信息：一是终端 A 作为主节点，向全网广播的 Pre-Prepare 消息（自身的坐标信息及其更新时间）；二是终端 A 同时作为备份节点需复制转发的 Pre-Prepare 消息，即其他终端共识消息中携带的所有 GIS 坐标信息（ GISX 及其更新时间）；三是本轮判定周期初始时间（所有GIS 坐标更新时间中的最小值）。

表 1　T1 时刻终端 A 发送消息 m

消息 m 发送完成后，终端 A 将共识计数器（Number of Consensus Nodes，NCN）置为 0，用于统计后续正确反馈 Prepare 消息的节点数。

（2）T1～T 2 时刻，其他终端接收到终端A 的共识消息后执行以下操作（以终端 B 为例）。

①基于时间戳 t1 验证共识消息的新鲜性，若验证通过，则验证签名，若签名验证通过，则验证合法性和解密获得消息 m 明文；若验证不通过 / 解密失败，则退出接收处理。

②基于 T0′ 判定收到的 是否为终端 A的最新坐标，若是最新坐标，则更新本地维护的大小为的 GIS-table，其内容字段定义如表 2 所示。

表 2　GIS-table 内容字段定义

注：指终端 X 和Y 的相对距离；是与终端 X 的相对距离大于 2.5 千米的终端个数。

③判定消息 m 中 终 端 B 的 GIS 坐 标 信 息是否与自身上一次发送的相同，若相同，则将个数加 1。

④比较  与 2 的 大 小， 若，则代表自身已完成共识，下一步判断与 2 的 大 小， 若，则代表自身已失控，执行主动防失控操作。

⑤分别比较与 2 的大小，若大于或等于 2，则判定该终端已失控并执行相关防护措施。

（3）T 2 时刻，终端 B 执行步骤（1）的操作；T 2 ～T3时刻，终端 A、终端 C、终端 D 执行步骤（2）的操作。

（4）T3时刻，终端 C 执行步骤（1）的操作，消息 m 内容如表 3 所示。

表 3　T3时刻终端 C 发送的消息 m

（5） T3 ～ T 4 时刻，终端 A、终端 B、终端 D 完成步骤（2）的操作后，全网所有终端的GIS-table 内容如表 4 所示。

表 4　T3～T 4 时刻更新后终端中的 GIS-table 内容

终端 A 基于判定自身已完成共识，然后基于表中判断自身已失控，开始执行主动防失控操作后停止提供密码服务。

而对于终端 B、终端 C 和终端 D，因，，故均判定自身未达成全网共识，然后基于 将终端 A 判定为失控节点并执行相关防护操作，至此全网对终端 A的失控状态达成一致共识。

（6）T5时刻，除拜占庭节点（终端 E）外的其余终端都已经在本轮判定周期中完成了一次共识消息的广播，而第 1 轮判定周期尚未结束，故此时没有终端广播共识消息。

（7） T6 时刻，第 1 轮判定周期结束，全网终端重新开始新一轮 GIS 坐标更新并在T7 时刻开始执行步骤（1）操作，启动新一周期的实时监控。

3.4　小结

由 以 上 实 施 示 例 可 知， 本 方 案 具 备 判 定DMO 模式下集群终端是否失控并自动实施防失控操作的能力，而在实际应用过程中对失控判定的有效性与共识机制能否正确运行，都和集群终端位置的准确性密切相关。

信道可靠性是影响 PBFT 共识机制正确运行的重要因素，如果信道不能保证可靠，那么拜占庭问题无解 [3]。集群通信系统采用无线信道传输消息，存在的信道不可靠主要表现在以下两个方面：一是因突发干扰或地形阻挡导致偶发性的消息丢失；二是开放的无线信道面临消息被重放、被欺骗等攻击的可能。针对偶发性的消息丢失的情况，本方案在本轮判定周期中将其作为拜占庭错误来处理，只要拜占庭错误终端的个数不超过个容错门限，都能正确判定，即使在某个判定周期内因消息丢失、节点过多导致无法正确判定，本方案采用周期性判定的模式也能保证通信恢复后即能正确完成判定。针对消息传输时被攻击的情况，本方案采用时间戳、密码技术等方式实现信息的防重放、机密性、完整性和可认证性，防止信息截获后被伪造、篡改。

集群终端位置信息采用卫星定位模块获得，理论上不存在准确性问题，但在实际应用中会存在各集群终端在本轮判定周期中位置动态变化的情况，而判定失控的基础是每轮判定开始阶段（如图 5 中第 1 轮的T0 ～T1阶段）集群终端所处的 GIS 坐标，这就导致若失控发生在本轮后续共识判定过程（如图 5 中第 1 轮的T1～T6 阶段）中，则本轮判定结果无法及时反映已失控终端的状态，需滞后到下一轮才能正确判定。为降低判定滞后带来的影响，可以从优化话权获取机制、精简共识载荷、优化终端内部处理流程等方面着手，提升判定执行效率。此外，本方案存在随着终端总数 n 的增加执行效率下降的缺陷，故在实际应用中更适合数量低于 30 的班排级编制规模组网时使用。

4　结　语

随着数字集群系统在国家重大行业、特殊用户及重要场合的大规模化应用，终端防丢失技术已成为集群系统安全保密技术的重点研究方向之一，本文通过分析常见的集群终端防失控方案，得到当前集群终端在 DMO 模式下工作时缺乏有效的实时防失控技术的结论，并提出实现此场景下的终端防失控需要解决的核心问题。本文借鉴了区块链共识机制中的 PBFT 算法，结合集群系统的工作特点对 PBFT 算法进行了适应性改进，在此基础上设计了数字集群终端DMO 模式下的防失控方案并通过典型实施示例验证了方案的可行性和有效性。该方案为 DMO模式组网工作的数字集群终端提供了一种新的防失控思路和解决方法，但因 SMR 类算法复制转发带来的固有效率缺陷，导致应用过程中需控制终端总量，限制了本方案的应用成效。未来跟随区块链技术的发展，将会出现效率更高、开销更小、容错能力更强同时适合集群通信特点的共识算法，可将其应用于本方案中以提升判定效率，逐步解决终端总量受控的问题，从而扩展本方案的应用范围。