基于信誉的二阶段溯源区块链共识策略

汪 澍，许翀寰，汤中运

（1.浙江工商大学管理工程与电子商务学院，杭州310018；2.浙江工商大学工商管理学院，杭州310018；3.杭州电子科技大学计算机学院，杭州310018）

0 概述

传统溯源系统采用将溯源信息集中存放在单一节点上的中心化方案［1］，这会影响系统的安全性、透明度和互操作性［2］，而区块链技术的出现为溯源系统的构建提供了更可信、安全和高效的解决方案［3］。由于公有链中实体可随意加入或离开区块链网络，而参与溯源系统中代表各利益方的实体则受到约束，因此与比特币［4］等公有链不同，溯源系统更适合采用联盟链。溯源区块链包含来自生产、加工、运输、存储和消费等领域中兴趣各异的利益方［5］，这种复杂性对该联盟链的共识策略提出了拜占庭容错能力的要求。在区块链技术中，共识策略能够确保在部分节点失效的情况下整个区块链网络中的节点仍能达成一致。由于节点通常由不同利益方维护，所构成的共识网络具有显著的异构特性，因此溯源区块链的性能开销较大，受到内外部恶意攻击的安全风险高，其共识策略还需要保障系统的性能和安全性。然而，传统基于证明的共识策略主要应用在公有链场景下，伴随巨大的计算开销和性能瓶颈，导致它们不适用于联盟链场景下的溯源区块链。基于拜占庭容错状态机复制的策略（BFT）［6］可以在不引入额外开销的情况下使全体非故障节点最终都达成共识，其中实用拜占庭容错（PBFT）是联盟链场景下应用最广泛的共识策略。但是，由于PBFT 采用主节点（primary node）和多轮相互广播的方式，并且缺少故障节点排除机制［7］，导致其在溯源区块链场景下依然存在通信开销大、可靠性低、易受恶意攻击等问题。

本文提出一种基于信誉的二阶段溯源区块链共识策略RTsBFT。通过对溯源区块链进行分析，构建将共识节点分散在多个本地组中的系统模型，以模拟溯源系统多利益方、共识网络异构的特性。同时建立一个信誉模型，将信誉作为节点参与共识过程的凭据，并根据节点信誉来排除故障节点。在此基础上，将共识设计为一个包含代表选择和代表共识两个阶段的过程，实现异构网络通信。

1 背景知识

1.1 溯源区块链

区块链技术可以解决供应链系统中信任相关的问题［8］，溯源区块链能够通过信息获取、传输、分享等过程，为供应链生产、加工、仓储、销售等各环节提供可追溯性的可靠信息［9］。溯源区块链继承了区块链技术的众多特性，如提供一种安全可共享的去中心化数据库，为物品、数据、金融等资源的交易提供基于透明性和可追溯性的信任强化。随着射频识别（RFID）、近场通信（NFC）等技术的发展，溯源区块链被应用到众多领域［10］。溯源区块链可采用无权限（公有链）和有权限（联盟链、私有链）系统，但无权限系统在设计上允许任意实体随时加入和退出区块链系统，并且拥有任意的读写权限，因此需要花费巨大的代价来保障安全性，如采用资源浪费极为严重的基于证明的共识策略［11］。同时，无权限系统的事务吞吐量受其设计的限制，无法满足供应链溯源过程中的高频交易需求，而有权限系统则可以通过优化共识策略来实现性能的显著提升［12］，因此，共识策略设计对溯源区块链十分重要。

1.2 共识策略

共识策略由传统分布式系统中的一致性算法演化而来，一致性算法最初由PEASE 等［13］提出，考虑到分布式系统中可能存在故障节点，研究者又在共识策略中引入了拜占庭将军问题。1985年证明的FLP 不可能性定理指出，对于具有错误过程的异步系统的共识问题，没有有限时间的理论解决方案，只能探索可行的“工程解”［14］。因此，早期探索的共识策略几乎都是非拜占庭容错的。直到2008年比特币被提出，拜占庭容错共识策略才得到广泛关注，这类策略大致上可分为基于证明和基于投票两类。比特币区块链中采用一种基于证明的共识策略——工作量证明（Proof of Work，PoW）［15］。但是，PoW 是一种十分浪费算力的共识策略［16］，因此KING 提出了权益证明（Proof of Stake，PoS）［17］机制来改善PoW。自提出PoW 和PoS 之后，研究者在不同的应用场景下提出了一系列基于证明的共识策略，如改进原始PoW 和PoS 的策略、结合PoW 和PoS 优点的策略［18］等，这类机制要求共识节点提供某种凭据以竞争区块打包和上链并获得收益，这类共识策略将区块链视作有限状态机，对于给定的顺序输入，它们能保证分布式系统最终的一致性，代价是牺牲系统的吞吐量和延迟性能。同时，由于上述共识策略的设计主要考虑公有链场景，因此并不适用于溯源区块链的联盟链场景。在基于投票的共识策略的每轮共识中，共识节点“相互投票”，将得到超过半数节点投票的节点选为打包区块上链的节点。通常基于投票的共识协议在分布式一致性算法中更为常见，如Paxos和Raft［19］，当前应用最为广泛的基于投票的共识策略是实用拜占庭容错（PBFT）策略。

1.3 PBFT 策略

PBFT 是一种典型的BFT 状态机复制策略，其将分布式一致性算法的复杂性由指数时间级降低到多项式时间级。PBFT 采用了主节点（Primary Node）和视图转换（View Change）的概念，主节点负责对请求和共识过程进行排序，视图转换则用于选择新的主节点。PBFT 最多可容忍个故障节点（N为总节点数）。当前对PBFT 的研究主要集中在对其性能和安全性的改进方面，多数研究从降低通信开销的角度来改进PBFT 的性能［20］，如基于信誉的策略［21］和信誉监督的策略CSBFT［22］。在PBFT 安全性改进方面，则有提高运行环境和网络基础设施安全性、增加故障检测及配备冗余主节点［23］的方案。

溯源区块链吸引着众多利益方，共识策略需要满足联盟链对性能和安全性的需求［12］，溯源区块链的特性对共识策略的设计十分重要。

2 共识策略设计

不同于比特币的公有链，溯源区块链通常采用联盟链，涉及的各利益方均可执行业务功能和权限管理，并通过投资区块链节点、计算能力、带宽等，与其他利益方竞争话语权，这形成了溯源区块链多利益方和共识网络异构的特性，引起了性能和拜占庭容错的需求。针对上述需求，本文提出基于信誉的两阶段拜占庭容错共识策略RTsBFT，其主要包括系统建模、信誉建模及共识过程3 个部分，其中，共识过程分为代表选择阶段和代表共识阶段。

2.1 系统建模

将溯源区块链中的节点分为3 类，分别为事务节点、共识节点以及存储节点。为了模拟溯源区块链多利益方、共识网络异构的特性，共识节点被分为Sseg个本地组，在同一个本地组中的节点性能相近并通过高速本地网络相连。事务节点产生事务并向各本地组广播，组内共识节点在其自身的事务队列中缓存待处理的事务，共识节点验证事务并打包区块。在本地组信誉值最高的节点中，完成上述任务最快的节点被选为该组的代表节点。共识将由所有本地组的代表节点参与，结果将分别发送到存储节点和共识节点，以进行永久存储和信誉更新。溯源区块链系统模型如图1所示。

图1 溯源区块链系统模型Fig.1 Traceability blockchain system model

当事务到达本地组时，组内所有共识节点会在进入共识过程前与一个可靠的NTP 服务器同步时间。同一本地组中的每个共识节点都维护一个本地共识节点表LCNT=＜本地组标识，事务标识，节点标识，节点公钥，节点IP：端口对，节点信誉值，节点状态＞，整个系统中所有LCNT 的初始配置都相同。

2.2 信誉模型

溯源区块链作为一种联盟链，比公有链更加可靠和安全，无需应用基于证明的共识策略以及增加额外的开销。但是，内部利益方和外部对手的恶意行为导致共识节点不能始终被视为值得信赖，从而需要考虑共识策略的拜占庭容错性。因此，本文建立一种信誉模型，以监督共识节点的行为，识别并排除有缺陷或恶意的故障节点，避免其影响共识过程。在该模型中，共识节点花费一定数量的自身信誉对共识过程中的提案进行签名，当代表共识阶段最终达成共识时，对共识提案签名的代表节点对应的本地组，可取回其在该轮共识中花费的信誉，这些本地组被标记为获胜组，其代表被标记为获胜代表，其他本地组及其代表分别被标记为失败组（gfailk∈Gfail）和失败代表。所有签名了共识提案的节点均将取回其本轮花费的信誉，获胜组中签名共识提案的节点还将获得额外的信誉奖励，未签名共识提案的节点将受到信誉惩罚。

2.2.1 代表选择阶段的信誉变化

在系统初始化时，所有共识节点的信誉被设置为相同，对于共识节点，其初始信誉ri=rini。令L(X)表示X中的元素个数，则某一本地组中节点的个数为表示中所有节点在本轮共识中花费的信誉，其计算如下：

其中，wsep是共识节点签名一个提案花费的信誉值，Trep是节点参与共识过程所需保有的最小信誉值。若ri≤Trep，则将被视作出现故障的拜占庭节点，无法签名任何新的提案，随后从本地组中移除或被新节点代替。在代表共识阶段前，共识节点的信誉ri的变化如下：

2.2.2 代表共识阶段的信誉变化

来自失败组的信誉首先平均分配给各获胜组，然后在每个获胜组内进行分配，RRWD是给的信誉奖励，其由从失败组以及花费的信誉中分配而来的信誉共同构成，的信誉则维持本轮花费信誉后的值不变。

对于一个失败组，其组内共有3 类节点，分别是失败代表本身、未签名共识提案的节点以及签名共识提案的节点，分别用rf、ru和rs表示这3 类节点的信誉，则其变化分别如式（5）～式（7）所示：

若失败组中有节点签名了共识提案，则它们应该被视作比同组中其他未签名共识提案的节点更可靠，失败代表应该为这些节点的信誉损失负责，并从它们的信誉值中减去这些节点花费的信誉，以补偿这些节点的信誉损失，其他节点则不会得到任何形式的信誉补偿。

2.3 共识过程

基于PBFT 策略中的主节点在共识过程中发挥着重要作用，但存在引入拜占庭节点作为主节点的风险，从而对系统性能造成影响。RTsBFT 采用代表节点机制，每个代表节点仅对其本地组负责，一个代表节点的错误不会影响到整个共识网络。对于一个有Sseg个本地组的共识网络，只要该系统中还有个正常代表节点，RTsBFT 就可保证该系统的正常运作。整个共识过程在本地组内和组间分别进行，故可将共识过程分为代表选择和代表共识两个阶段。

2.3.1 代表选择阶段

在代表选择阶段，事务被共识节点接收，并产生代表节点。RTsBFT 中采用固定区块大小的方法来生成区块，当共识节点收到用于生成新区块的最后一个事务时，它与NTP 服务器同步时钟，并对区块进行验证、摘要和签名。当完成上述工作且未收到来自其他节点的代表声名信息Mrep时，节点向本地组内广播包含自身节点id、完成签名时间、区块头、区块id 的代表声名信息Mrep={Nid,Tsign,Hblock,Bid}。若在发出自身Mrep前接收到其他节点Mrep的节点，则切换自身状态为INHIBITED，并不再发出Mrep。所有节点将接收到的Mrep按照信息对应的签名完成时间和LCNT 中的信誉值进行排序，从最高信誉值的节点中选出完成时间最早的节点作为代表节点。所有信誉高于Trep的节点对自身提案签名，并根据信誉模型更新LCNT 中节点的信誉，将信誉高于Trep的节点状态标记为FUNCTION，其他节点被标记为MALFUNCTION，它们被禁止参与下一轮共识。代表节点在签名自身提案后，将与提案信息一起发送给其他本地组。代表选择阶段可分为Broadcast、Claim、Preprepare 3 个流程，如图2所示。

图2 代表选择阶段的共识过程Fig.2 Consensus process of representative selection stage

代表选择阶段的详细步骤如下：

步骤1进入Broadcast 流程，用于生成新区块Bb的最后一个事务被广播到本地组中。

步骤2中的共识节点验证，若验证错误，则回滚事务；若验证通过，则：

1）与NTP 服务器同步时钟。

3）对区块进行摘要和签名。

4）生成Bb的区块头Hblock。

5）构造代表声名信息Mrep。

步骤3进入Claim 流程，若节点未完成步骤1和步骤2 且收到其他节点Mrep，则将状态标记为INHIBITED；若完成步骤1 和步骤2 且未收到其他节点Mrep，则进行信誉检查：

1）若其信誉低于Trep或其状态为INHIBITED，则不进行任何操作。

2）若其信誉高于Trep且状态为FUNCTION，则广播其Mrep。

步骤4进入Preprepare 流程，在Tout时长后进行代表节点排序：

1）从LCNT 中检查发送过Mrep节点的信誉。

2）根据信誉对上述节点进行排序。

3）仅当多个节点信誉值相同时对其按照Tsign进行排序。

4）将排序在第1 位的节点状态标记为REPRESENT，选其作为代表节点。

步骤5代表节点根据信誉模型计算并向其他本地组发送提案和，所有节点根据信誉模型更新LCNT，将信誉值低于Trep的节点状态标记为MALFUNCTION。

2.3.2 代表共识阶段

与PBFT 不同，RTsBFT 中提案信息只会被本地组的代表节点接收，因此，共识过程会被限定在所有代表节点中进行。代表节点发送含有本地组id、代表节点信息、提案（含区块头）、本组等内容的消息。代表节点收到后，对内容进行验证，根据中的提案与自身提案是否相同，将该消息标记为MATCH或MISMATCH，当MATCH 消息的数量超过时，达成共识，相应提案为共识提案，并向所有代表节点提交该提案。签名共识提案的代表节点将提案相应的区块提交给存储节点，并同时开始反馈流程，共识提案被广播到各本地组，节点根据信誉模型更新信誉。代表共识阶段包含Prepare、Commit、Store&Feedback 这3 个流程，如图3所示。

图3 代表共识阶段的共识过程Fig.3 Consensus process of representative consensus stage

代表共识阶段的详细步骤如下：

步骤1所有代表节点向其他本地组广播，并由各本地组代表节点接收。

步骤2进入Prepare 流程，所有代表节点验证收到的，若消息中的提案与本节点提案一致，则将其存入MATCH 栈中；否则，存入MISMATCH栈中。

步骤3进入Commit 流程，收到MATCH 消息多于的节点，根据INFOrep中其他代表节点的信息将共识提案提交给其他代表节点。

步骤4进入Store & Feedback 流程，获胜代表节点将提案对应的区块发送给存储节点，并将共识提案广播给所有本地组，在各本地组内节点更新信誉值。

2.4 正确性分析

溯源区块链中的拜占庭节点不可靠，可能会通过恶意行为来阻碍共识的达成，RTsBFT 用信誉模型和二阶段过程设计识别这些节点，以避免拜占庭故障节点成为代表节点，从而保障共识过程的安全性。

引理1在本地组中，正确节点的信誉始终高于故障节点的信誉。

证明令Φ＞0 为初始信誉值，则在初始时对∀nodei,Crep=Frep=Φ，其中，Crep和Frep分别为正确节点和故障节点的信誉。令签名提案信誉花费为Δ＞0，信誉奖励为δ＞0，信誉惩罚为θ＞0，则有：

综上所述，Crep＞Frep，即正确节点的信誉始终高于故障节点的信誉，因此，可以避免故障节点成为代表节点。

引理2只要代表节点中的故障节点不超过个，RTsBFT 可保证运行于本文系统模型上的溯源区块链的安全性。

证明Nc和Nf分别表示正确代表节点和故障代表节点的个数。由可得，Nc≥2Nf+1。当故障节点均匀分布于所有本地组时，根据引理1，故障节点无法成为代表节点，Nf=0，故障节点提案不会进入prepare 流程，因此，不会对最终共识的安全性产生影响。当故障节点非均匀分布时，最坏情况下个本地组中全部节点均为故障节点，根据引理1，此时Nc≥2Nf+1 依然成立，RTsBFT 在节点共识阶段并没有放宽PBFT 中的限制，而PBFT 已被证明在该条件下可以保证系统的安全性［24］。因此，RTsBFT 均可保证运行于本文系统模型上溯源区块链的安全性。

3 性能评估

本文构建一个模拟溯源区块链特性的原型系统，并在相同条件下运行RTsBFT、PBFT 和CSBFT，以验证本文RTsBFT 模型的性能。

3.1 原型系统构建

本文构建一个简单的联盟链原型系统，包含一个事务模块和一个共识模块，原型系统架构如图4所示。事务模块生成事务，并将事务通过组间链路广播至共识模块的本地组内，该模块生成的事务大小一致（256 B），以确保达到RTsBFT 设计中固定区块大小的要求。共识模块通过分别运行这些共识策略来监测其性能。为了模拟溯源区块链的共识节点分布于受不同利益方管理的异构网络的特性，将同一本地组内的节点用高速本地链路连接，各本地组间则通过相对低速的组间链路连接。整个原型系统的共识模块由10台多核计算机组成（Intel Core i5-9500，32 GB 内存），每台计算机作为一个本地组宿主，在其上运行整个本地组的节点。组间链路由一个1 000 Mb/s 的交换网络实现，高速本地链路则由Hypervisor 的system bus 实现。

图4 原型系统架构Fig.4 Prototype system architecture

3.2 评估指标

溯源区块链的特点对共识策略的性能和安全性提出了更高的要求。本文通过吞吐量、延迟和故障节点率3 个指标［25］来评估共识策略的性能和安全性。

1）吞吐量：衡量共识策略在给定时间内处理的事务数量，用每秒事务处理量（Transaction Per Second，TPS）来表示，TPS 越高，系统性能越好。

2）延迟：从一个区块被生成到它的共识过程完成所需要的时间，由新生成区块的时刻Tgen到共识达成的时刻Tcon的时间差表示，Delay=Tcon-Tgen，延迟越低表示系统性能越高。

3）故障节点率：当前共识网络中故障节点的数量与总节点数量的比值，故障节点率反映当前区块链系统共识策略的安全性和可靠性，该指标越低，系统安全性和可靠性越高。

由于RTsBFT 采用固定区块大小的策略，区块生成时间不可控，因此可以考察区块大小对系统性能的影响。同时，节点数量决定共识网络的复杂性，本文将在不同区块大小和节点数量情况下对比RTsBFT、PBFT 和CSBFT 的吞吐量、延迟以及故障节点率。

3.3 吞吐量和延迟对比

本文分别设计0.5 KB、1.0 KB、2.0 KB、4.0 KB和8.0 KB 这5 个不同的区块大小，原型系统配置为5 个本地组宿主，每宿主运行10 个节点。评估指标取运行中某一段20 s 时间内的平均值，结果如图5所示。从图5 可以看出，在相同区块大小下，RTsBFT 的吞吐量总是高于PBFT 和CSBFT，延迟低于PBFT。随着区块大小的增加，所有共识策略的吞吐量均有下降，延迟均有升高，说明区块大小会影响共识策略的性能。

图5 不同区块大小下吞吐量和延迟的对比Fig.5 Comparison of throughput and latency under different block sizes

将原型系统分别配置为运行35 个、70 个、105 个和140 个节点，这些节点以两种方式分别分配到5 个（每宿主运行7 个、14 个、21 个和28 个节点）和7 个（每宿主运行5 个、10 个、15 个和20 个节点）本地组宿主上。区块大小配置为1 KB，评估指标也取运行中某一段20 s 时间内的平均值，结果如图6所示。从图6 可以看出，在不同节点数量和分组方式下，RTsBFT 的吞吐量均高于PBFT 和CSBFT，延迟均低于PBFT 和CSBFT，节点数量的增加降低了共识策略的吞吐量，但PBFT 和CSBFT 的吞吐量下降更为显著，同时，节点数量的增加提高了共识策略的延迟，但PBFT 和CSBFT 的延迟提高幅度更大。

图6 不同节点数量下吞吐量和延迟的对比Fig.6 Comparison of throughput and latency under different numbers of nodes

在相同区块大小和相同节点数量这两种情况下，RTsBFT 在吞吐量和延迟上的性能表现均优于PBFT 和CSBFT。尽管随着区块大小的增加和节点数量的增加，各策略性能均有一定程度的下降，但RTsBFT 下降得更少。因此，RTsBFT 具有更高的性能，且在系统复杂性增加的情况下能够更好地控制性能下降。研究表明，通信复杂性对共识策略的性能有重要影响［26］，在RTsBFT 的设计中，本地组内的通信发生在代表选择阶段，组间通信只发生在代表共识阶段，同时共识的核心过程仅在少数代表节点中发生，降低了节点间通信开销，特别是组间节点的通信开销。而在两阶段的共识过程中，不需要向所有节点广播区块并等待它们的响应，这与引入的信誉模型一起简化了共识过程，同时避免了故障节点带来的额外开销，降低了共识过程的复杂性。在不同的节点分组方式中，RTsBFT 的延迟差异几乎是恒定的，而PBFT 和CSBFT 在不同节点分组下的延迟差异随着节点数量的增加而提高，这也证明对通信开销的控制给RTsBFT 带来了性能提升。

3.4 性能与安全性随时间的变化情况

故障节点引入了拜占庭错误，本文对比2 个共识策略在开始运行20 s 内的吞吐量、延迟和故障节点率的变化情况。原型系统配置为在5 个本地组宿主上运行50 个共识节点，区块大小为1 KB，初始故障节点为12 个。该过程中3 个共识策略的吞吐量和延迟随时间变化的统计信息如表1所示，变化趋势如图7所示。

表1 3个共识策略吞吐量和延迟随时间变化的统计信息Table 1 Statistics of the throughput and latency of three consensus strategies over time

图7 吞吐量和延迟随时间的变化情况Fig.7 The change of throughput and latency with time

从表1 和图7 可以看出，RTsBFT 的吞吐量随时间变化的均值高于另两个策略，延迟低于另两个策略，且RTsBFT 的吞吐量和延迟随时间变化的波动比另两个策略平缓。

3 个共识策略故障节点率随时间的变化趋势如图8所示，可以看出，PBFT 的故障节点率保持在24%左右，而RTsBFT 几乎在前5 s 就将所有故障节点排除在外，CSBFT 大约在10 s 完成故障节点的排除。RTsBFT 具有排除故障节点的能力，因此相比PBFT，其具有更好的安全性和可靠性，相比CSBFT 的故障节点排除能力更强。RTsBFT 在性能和安全性波动上的优势来自于其设计中的信誉模型所带来的排除拜占庭故障节点的能力，故障节点会加重系统的负载，从而对系统性能和安全性产生不利影响。RTsBFT 能消除故障节点恶意行为对共识过程的影响，减少共识过程中需要通信的节点数量，从而提高系统性能和安全性。而CSBFT 在没有摆脱PBFT 主节点和视图转换弊端的情况下引入信誉模型，虽然具备一定的故障节点排除能力，但增加了大量额外开销［21］，因此，其性能较PBFT 差。

图8 故障节点率随时间的变化情况Fig.8 The change of failure node rate with time

4 结束语

本文提出一种基于信誉的二阶段溯源区块链共识策略RTsBFT，在多利益方、共识网络异构的联盟链场景下实现对溯源区块链性能和安全性的提升。通过建立溯源区块链系统模型与信誉模型及设计二阶段共识过程，使得RTsBFT 具有排除拜占庭故障节点的能力并降低节点通信开销。实验结果表明，在不同区块大小和节点数量的情况下，RTsBFT 的吞吐量、延迟和故障节点率均优于PBFT 和CSBFT 策略。下一步将对RTsBFT 中的信誉模型进行优化，使其适用于更多类型的联盟链系统模型架构。