• 欢迎访问3777金沙娱场城在线官方网站
货物查询

全国咨询热线400-663-9099
3777金沙娱场城在线

基于并行验证的IBFT共识算法电商物流信息管理系统中的应用研究

字号:T|T
文章出处:作者:人气:-发表时间:2024-08-30 12:07:00

 

0 引言

随着电商经济的快速发展,社会对物流行业的依赖大幅增加。为了适应追求快速高效的新消费时代需求,许多物流货运公司纷纷引进更科学高效的区块链技术,来提升物流管理的效率[1]。其中共识算法作为区块链技术的最重要的部分之一,许多研究者都通过优化共识算法的方法,来提高区块链物流管理系统的性能[2]。例如陈佶将传统PBFT共识算法与DPOS算法相结合,提出一种基于DDPBFT算法的区块链模型,改进算法保留了传统PBFT的后半部分,在前半部分则采取DPSO算法来选举主节点,并通过排序算法排序,以改进网络的初始化过程与减少节点的视图切换,进而促进区块链系统的整体性能提升[3];叶进等针对分布式能源交易中共识效率低、资源开销大和交易时效率高等问题,则提出一种面向分布式电能交易的智简拜占庭容错算法,通过引入门限签名机制,将复杂的通信简单化,进而缩短共识时延[4]。以上研究虽然一定程度上提高了区块链物流管理系统的性能,但由于拜占庭算法在共识过程中需要逐个验证的特点,验证耗时仍然较长,且其中一个节点出现错误就可以影响整个系统的共识,不安全性较高。在以上研究基础上,引入并行验证策略对传统拜占庭共识进行改进,并结合IBFT共识算法,提出一种基于并行验证的改进IBFT共识算法,在保障安全性与容错率的前提下,优化共识过程的交易验证速度,进而提升系统效率。

1 相关技术

1.1基于并行验证的IBFT共识算法

伊斯坦布尔拜占庭容错(Istanbul Byzantine Fault Tolerant, IBFT)算法是启发于实用拜占庭容错(Practical Byzantine Fault Tolerance, PBFT)算法的一种修改共识算法[5]。相较于PBFT共识算法,IBFT具有更严格的验证机制与更先进的加密算法,安全性更高,且可以在更短的时间内达成共识,大幅提高了交易的确认速度[6]。然而与传统拜占庭共识算法相同,IBFT的验证过程同样是按照时间顺序进行,每个验证结束后下个验证才会开始,这大大增加了系统的验证时间。为了提高系统的吞吐量与执行效率,在IBFT中引入并行验证策略,对其进行改进。

1.1.1 并行验证策略

在区块链的共识过程中,当一个提议者被选中时,需要向其他验证者发送一个块提议,再由其他节点对收到的块提议进行验证,以确保其符合既定的规则与约束[7]。常规的拜占庭共识通常只能按照顺序一个一个对任务进行验证,并行验证策略则引入多线程的技术,通过在验证时添加线程,由每个线程负责执行不同的指令块,使节点可以同时验证多个任务[8]

基于并行验证策略的共识过程整体可以分为四个阶段:块提议、并行验证、块承诺和块提交[9]。由负责提出新块的节点,即提议者首先生成新块,并将块发送给其他节点;其他节点在收到来自提议者的新块时,通过多线程技术对其进行并行验证。当块验证通过且达成共识后,其他节点将承诺该区块成为区块链的新区块,并由提议者在区块链中添加新区块[10]。系统共识过程中,节点并行验证策略如图1所示:

图片

1并行验证过程

研究采用任务分解与同步线程实现高效的并行验证策略。其中任务分解是指将验证任务分解为三个独立的子任务,并通过单独的线程对每个子任务进行处理。通过任务分解,确保了每个子任务都能被并行执行,从而最大程度地提高了验证速度[11]。同步线程则是指在节点的信息验证通过进入共识的下一阶段,采用同步线程策略,通过条件变量来确保线程之间的安全通信与数据一致性,从而提高算法的性能。

1.1.2 并行验证详细方案

(1)并发验证逻辑实现

基于线程池并发结构实现并发验证逻辑。首先创建一个线程池,由线程池中的线程对任务进行管理。在节点收到块提议后,将验证任务分配给线程池里的线程,线程池的规模由系统资源和性能需求决定,每个线程需要独立处理不同的验证任务,任务包括查验提议者身份、检查新区块的序列号和轮次等等[12]

(2)数据结构类型定义

按照表1中的方法对数据结构和类型进行定义,以便系统在验证过程中对各个实体访问和操作[13]:

1并行验证方案中数据结构类型定义表

数据结构
储存管理信息

Validator
存储验证器的信息,包括节点的公钥、私钥、IP和地址

BlockProposal
储存块提议的信息,包括提议者、区块头、序列号和轮次

ConsensusState
储存验证器在共识过程中的状态信息,包括PRE-PREPARE(准备)、PREPARED(确认)和COMMITTED(提交)

Message
储存验证器之间传递信息,包括发送者、消息类型、数据和接收者

(3)消息处理

按照表2中的方法实现共识过程中的消息处理与启动定时器:

2消息处理与定时器逻辑实现方法表

消息处理方法
任务

handle Message()
负责处理接收到的消息。在节点收到提议时启动定时器,并根据接收的消息类型选择对应的验证方法

generate Response Message()
在节点完成验证后,根据验证结果生成响应消息,包括消息名称、序列号、当前轮次、请求内容

handle Round Change()
在节点轮超时的情形下,广播带有currentRound+1的ROUNDCHANGE消息

(4)验证方法

按照表3中的验证方法,实现各种验证任务的执行:

3并行验证方法实现表

验证方法
任务

verify Proposer()
验证提议者是否属于验证器集,以确定块提议来源的有效性

verify Sequence and Round()
验证块提议的轮次与序列号是否与验证器的状态匹配

verify Block Header()
验证区块头的签名、散列及其他属性,例如提议者和验证区的签名、固定数字的有效差异值和表示IBFT区块的数字的有效散列

1.2基于并行验证共识的物流管理模型

基于并行验证的IBFT共识算法构建物流管理模型。在这个物流管理模型中,区块链节点主要由生产商、原材料供应商、消费者和其他市场参与者构成[14]。具体流程如图2所示:

其中验证节点的选举和调整通过既定规则和投票机制实现[13]。直到网络中超过2/3的验证节点达成共识,该区块将被视为通过验证,并添加至区块链中。在公式过程中,由于IBFT公式算法强制将2/3的验证节点通过请求作为达成共识的前提条件,避免了其中某个恶意节点对共识结果造成影响,从而为整个系统的安全运行提供保障。

随着交易市场的扩大和参与者的增多,基于并行验证的改进IBFT算法还可以根据实际需求调节验证节点的数量,为算法提供良好的可扩展性[14]。并且共识的设计也使得物流管理模型在升级和更新时更为便利。算法可以通过调整共识参数、优化共识过程或引入新的验证节点选举规则,不断提升自己,以适应不断变化的物流交易市场。

图片

2基于区块链的物流管理流程

2 实验验证

2.1实验环境

本次实验基于Quorum区块链平台搭建,使用Hyperledger Caliper区块链评估框架作为基准测试工具,Docker为部署工具,并在Ubuntu18.01操作系统上运行。系统配置i5-9600K中央处理器,服务器内存为20 GB,硬盘储存为100 GB。

Hyperledger Caliper区块链评估框架通过使用一些预定义用途来衡量区块链网络的性能,它针对待检测的系统生成工具负载并实时监控其响应,然后结合事务吞吐量、事务延迟等评估网络性能的重要指标,生成该网络的性能评估报告。仿真选择8个节点的大小的验证器集,在无恶意节点的前提下,对不同提交、事务量与不同大小事务的提交下的并行验证的IBFT共识算法测试。为了进一步了解算法优越性,将所提算法的测试结果与Raft经典共识算法和未改进的IBFT算法的结果进行比较[15]

2.2实验参数

测试系统使用基于P2P网络的去中心化结构,节点之间允许并通过异步消息传递的方式进行通信。通信包括PRE-PREPARE、PREPARE、COMMIT、ROUNDCHANGE四种消息类型,其中PRE-PREPARE代表提议者将块提议广播给所有验证者;PREPARE代表验证者在验证块提议后,将消息转发给其他验证者,表明自己已进入“确认共识”状态;COMMIT代表验证者在收到足够数目的来自其他验证者的“确认共识”消息后,将此消息转发给其他验证者,表明自身已进入“提交共识”状态。ROUNDCHANGE代表验证者在超时后,将此消息发送给其他验证者,表示进入下一轮。

2.3评估指标

采用区块链系统关键指标事务吞吐量(Transactions Per Second, TPS)与事务延迟(Latency, L)作为所提改进共识算法的衡量指标。其中事务吞吐量是指以时间单位合并的事务总量,在区块链系统中定义为区块链网络每秒成功处理的事务数;事务延迟也叫共识时延,指事务合并所需要的时间,在区块链系统中定义为事务提交之间的时间间隔,以及区块链网络中每个正确节点上结果可用的时间点。事务吞吐量与事务时延的计算公式如式(1)(2)所示:

ΤΡS=Τtj-ti(1)L=ts-tu(2)" role="presentation" style="margin: 0px; padding: 0px; border: 0px; outline: 0px; background: transparent; display: inline; line-height: normal; font-size: 15.66px; word-spacing: normal; overflow-wrap: normal; text-wrap: nowrap; float: none; direction: ltr; max-width: none; max-height: none; min-width: 0px; min-height: 0px; position: relative;">???=???-??(1)?=??-??(2)

式中,T表示完成的事务数量;titj分别表示第一个事务进入系统的时间与最后一个事务被处理完成的时间。tuts分别代表共识过程开始和达成的时间。

2.4实验结果

基于Quorum平台分别对基于所提IBFT算法的能源交易系统在标准化工作负载下与高并发情况下的性能表现进行综合评价,并将评价结果分别与基于Raft共识协议与基于未改进IBFT共识协议的能源交易系统的评价结果进行比较。

2.4.1 事务吞吐量

设置发送事务大小为2 kB,对系统在交易发送率在600、1 200、1 800和2 400情况下,事务吞吐量的变化进行观察。经多次测试,三种共识算法的不同交易发送率下的平均事务吞吐量如图3所示:

图片

3不同交易发送率下系统事务吞吐量结果比较

如图3所示,随着交易发送率的增加,三种共识算法的平均事务吞吐量都呈现上升趋势。三种算法中,表现最差的是原始IBFT共识算法,虽然吞吐量随着交易发送率增加而增加,但在三种算法中始终最低,对事物的处理有限。而所提算法虽然一开始略低于Raft共识算法,当交易发送率超过1 600 Tx/s后,开始出现反超。综合来看,所提算法相较于原始IBFT共识算法与Raft共识算法能够更有效地处理大量事务,共识性能更加优越。

设置固定交易发送率为1 600 Tx/s, 对系统在发送事务大小分别为5 kB、12 kB和50 kB情况下,事务吞吐量的变化进行观察。经多次测试,三种共识算法在不同发送事务大小下的平均事务吞吐量如图4所示:

图片

4不同发送事务大小下系统事务吞吐量结果比较

如图4所示,随着发送事务大小增加,三种共识算法的平均事务吞吐量都呈现下降趋势,且都逐渐趋于同一水平。三种算法中,所提算法在发送较小事务时,较Raft共识算法平均事务吞吐量略高,远远好于未改进的IBFT算法,性能表现在三种算法中最佳。综上,说明所提基于并行验证的IBFT共识方法有效提高了原始IBFT算法的性能,在处理不同大小事务时都具有较好的性能表现,综合性能最优。

2.4.2 事务延迟

设置发送事务大小为2 kB,对系统在交易发送率在600、1 200、1 800和2 400情况下,事务延迟的性能变化进行观察。经多组测试,三种共识算法在不同交易发送率下平均事务延迟情况如图5所示:

图片

5不同事务发送率下事务延迟结果比较

如图5所示,相较于原始IBFT共识算法,所提算法在处理不同发送率下的事务,速度有了明显提升,平均事务延迟耗时更短,处理效率更高。但是与Raft共识算法比较,所提改进算法的事务延迟时间仍然略高,这可能与Raft共识中的非完全去中心化机制有关,它使算法在事务延迟性能在一定程度上比拜占庭共识机制更具优势。综上,所提算法使系统在整体共识过程的速度上得到了优化,但相较于Raft算法仍有提升空间。

设置固定事务输入率为1 600 Tx/s, 对系统在发送事务大小分别为5 kB、12 kB和50 kB情况下,事务延迟性能的变化进行观察。经多次测试,三种共识算法在不同发送事务大小下的平均事务延时如图6所示:

图片

6不同发送事务大小下系统延迟结果比较

如图6所示,随着发送事务大小的增加,三种共识算法的事务延迟都呈现上升趋势。当系统处理事务大小为50 kB时,所提算法在平均事务延迟上的速度最快,相较于未改进的IBFT共识算法与Raft共识算法时延性能更优越,表明所提算法在处理较大事务时完成效率更高。

3 结论

综上,提出一种基于并行验证的改进IBFT共识算法,算法在传统拜占庭基础上引入共识策略,并结合IBFT算法,保障共识过程的快速性、安全性和高容错率。测试结果表明,事务吞吐量指标上,在固定发送事务大小为2 kB的情况下,随着交易发送率的增加,所提算法的事务吞吐量也在不断提高,在交易发送率到达1 600Tx/s后时反超Raft共识算法,远远高于未改进IBFT共识算法;在固定交易发送率为1 600 Tx/s的情况下,随着事务大小的增加共识算法的平均事务吞吐量都呈下降趋势并逐渐趋同,而所提算法在发送较小事务时,略高于Raft共识算法,在三种比较共识算法中最佳。事务延迟指标上,所提算法相较于原始IBFT算法在处理不同发送率下的事务中,效率有了明显提升,虽然略低于Raft共识算法,但是结果相近,说明算法具有较好的共识效率;随着发送事务大小的增加,共识算法下的系统在处理事务上都有了更长的延迟时间。当处理事务大小为50 kB时,所提算法在事务上的平均处理速度最快。综上,所提算法在处理较大事务上具有更快的事务吞吐量与完成效率,总体性能最佳,满足基于区块链的物流管理系统高性能要求。但是通过与Raft共识算法的比较可以发现,算法在事务处理效率上还有进一步的提升空间,并且并行验证方法在更大规模与更复杂网络中的性能表现尚未得到验证。因此,下一步研究将针对以上问题,在维持拜占庭共识容错能力的条件下,对所提算法进行更高效的优化,以满足更多物流场景下的应用需求。