RPFT:基于PoW的高效率共识算法

时间:2024-03-24 09:22:02 来源:网友投稿

钱 慧,郑朝晖,2,荣宝俊,王健翔

1(苏州大学 计算机科学与技术学院,江苏 苏州 215006) 2(苏州大学 江苏省网络空间安全工程实验室,江苏 苏州 215006)

2008年,中本聪在《比特币:一种P2P电子现金支付系统》[1]中,提出在交易中跳过银行这一中心机构,形成了全网节点基于工作量证明共识机制共同维护区块链来防止二次支付的P2P网络,区块链技术[2]由此进入大众视野.区块链技术是一种去中心化的分布式账本技术,是以数据库作为数据存储载体,以P2P网络作为通信载体,依赖密码学确定所有权和保障隐私,依赖分布式系统共识框架保障一致性,旨在构建价值交换系统的技术,可应用于分布式数据存储、点对点传输、共识机制、加密算法等计算机技术领域[3].比特币作为区块链技术的第一个应用实例,引发了社会各界的广泛关注[4-8].随着区块链技术的发展,区块链出现了很多分类,从去中心化的角度将其分为3类:公有链[9](public blockchain)、联盟链[10](consortium blockchain)和私有链[11](private blockchain).共识机制的设计是区块链技术的核心设计,良好的共识算法可以有效解决区块链的安全性、扩展性、能耗代价和性能效率等问题.不同场景区块链中对于共识机制的性能有不同需求,目前,共识算法根据区块链的类型分为3类:公共区块链共识、私有区块链共识和联盟区块链共识.

公有链是去中心化程度最高的,任何节点都可加入,每个人都可以参与到这个区块链中进行计算,而且任何人都可以下载获得完整区块链数据,如比特币、以太坊等.在公有链上运用的共识算法称之为公共区块链共识.目前公有链中常用的共识算法有PoW[1],PoS[12],DpoS[13]等.私有链的去中心化程度最低,只有被许可的节点才可以参与该区块链,一般由个人或某个小团体创建,仅使用区块链技术进行记账.目前应用的主流共识算法有Viewstamped Replication(VR)[14].联盟链的去中心化程度介于公有链和私有链之间,指由若干机构或组织共同参与管理的区块链.节点只有通过联盟链中节点成员管理服务进行身份确认、鉴权并获得批准后才可以加入该联盟链网络.联盟链的共识机制需要兼顾高效、安全与可扩展性,大规模网络环境中需保证高数据吞吐量和低共识时延.目前,联盟链中共识算法主要分为两类:一类是拜占庭容错共识算法,如实用拜占庭容错(Practice Byzantine Fault Tolerance,PBFT[15])等;另一种是非拜占庭容错共识算法,如Raft[16]等.

在共识机制改进方面,文献[17]2-hop区块链尝试将工作量证明和权益证明相结合,利用权益证明机制中的虚拟绿色资源来减少系统的资源消耗,提高系统的公平性、安全性和效率;文献[18]PoWas共识机制也是将工作量证明和权益证明相结合的实例,达到了减少计算资源消耗、获得记账权的节点分布更平衡和达成共识的时间更短的效果;文献[19]Algorand系统通过将拜占庭一致性协议和权益证明机制的结合,既解决了拜占庭一致性协议的扩展性和效率问题,同时避免了权益证明机制中的易分叉问题,提高了系统一致性和安全性;文献[20]基于Raft集群的拜占庭共识机制RBFT算法通过将PBFT和Raft算法相结合,使得新算法既具备拜占庭容错,又可以保证高共识效率.根据共识算法优点将不同共识算法结合弥补劣势,使得新共识算法更加健壮,提高了系统性能.

2014年,Ongaro和Ousterhout提出了Raft一致性共识算法[16],用来管理日志复制一致性的算法,比Paxos更容易实现和理解但同样高效,相当于Multi-Paxos[21].本文以Raft共识算法为研究对象,发现其在领导者选举过程中,随着追随者节点数量的增加,造成能投票的追随者节点数量增加,限制了选举速度.在极端情况下,由于分裂投票,将会有多轮选举[22],影响集群的工作效率.因此在出现分裂投票情况时,采取额外的措施正确高效的选举出领导者变得至关重要.

本文的主要研究工作如下:

1)针对Raft共识算法服务器节点数量增加领导者节点选举速度下降的问题,结合PoW共识算法提出了一种高效率共识算法—RPFT算法.领导者通过广播发送PoW难题,跟随者节点解题,从而选出下一任期的领导者,即副领导节点(Deputy leader),提高了领导者节点选举速度以及安全性.

2)针对Raft共识算法投票选举中存在的投票分裂而造成选举效率低下的问题,引入等待时间选举模型,避免因投票分裂致使多轮投票,提高Raft领导者节点选举速度.

3)结合Raft投票选举,PoW共识算法和等待时间选举模型,提出了一种新的领导者节点选举算法.

4)对RPFT和Raft算法在共识时延、选举速度和吞吐量进行对比实验测试,已验证RPFT算法有效性和可靠性.

2.1 Raft算法简介

Raft共识算法中需要两个角色,领导者和跟随者,领导者负责传达客户端指令,而跟随者负责执行领导者的命令.而这两个角色的转换需要一个中间角色来过渡,因此Raft系统中节点有3种状态:领导者、候选者、跟随者,3种状态的转换过程如图1所示.推动系统循环往复运行的是时间元素,通过设置任期和超时机制防止系统陷入僵局.Raft共识算法主要分为3个相对独立的子问题:领导者节点选举、日志复制和安全性保证.

图1 服务器状态转移模型Fig.1 Server states transition model

领导者节点选举:领导者节点选举是指候选者节点通过给集群中所有服务器节点发送投票请求获取选票.该过程是通过使用心跳和随机超时机制触发的,随机超时短的高任期候选者节点可以优先获取选票,当该候选者节点获得半数以上服务器节点的肯定选票后,成为领导者节点,完成从候选者状态到领导者状态的转移.

日志复制:日志复制就是共识,保证了Raft算法集群内服务器节点日志一致性.领导者节点接受来自客户端的命令请求,将该条日志命令添加至本地日志并广播转发添加该条日志命令的请求.当领导者节点收到大多数跟随者节点添加日志成功的回应消息时,即向客户端返回共识成功的信息.

安全性保证:Raft一致性共识算法安全性主要体现在:选举安全、日志匹配、领导者完整性和状态机安全.

2.2 PoW算法简介

工作量证明是用于实现可验证的计算任务,包括证明者和验证者两个角色.证明者需要向验证者提供证据,证明自己在一段时间内完成了特定数量的计算任务.比特币是最早使用工作量证明机制选择出块节点.

在比特币系统中,比特币节点通过不断地哈希计算寻找满足条件的随机数值,使得随机数值拼接上前一个区块的哈希值在进行哈希计算所得到的哈希值前n位为零,n的大小等于难度值的大小,如定义1所示.采用工作量证明机制保证系统中所有节点对一个确认交易集合达成最终一致.

定义1.(比特币工作量证明难题)给定全网统一的难度值D、区块数据blockData,寻找满足条件的随机数值Nonce,使得通过哈希计算得到的区块哈希blockHash低于目标难度值D:

blockHash=Hash(blockData,Nonce)≪D/×

MERGEFOEMAT

(1)

由于哈希算法具备的输入敏感和抗碰撞特点,比特币节点需要不断的调整哈希计算的输入值(随机数值Nonce、区块数据blockData)以寻找满足条件的Nonce值.因此,每个比特币节点完成工作量证明难题从而成为出块节点的概率由它可用的计算机资源决定,可用计算资源可被视为一种身份验证,即使攻击者通过伪造创建大量公钥地址也无法提升自己完成工作量证明的效率,从而增加成为出块节点的速度.这样,工作量证明机制有效抵御了分布式系统中的女巫攻击[23]问题.

RPFT共识算法在Raft算法3种状态的基础上添加“副领导”状态,作为领导者节点的备用节点,当节点宕机下线时,副领导者节点直接成为领导者节点,集群稳定运行.RPFT共识算法4种状态转换图如图2所示.

图2 RPFT算法状态转换图Fig.2 RPFT algorithm state transition diagram

RPFT共识算法的集群中始终只有一个领导者节点,是唯一和客户端通信的服务器节点,负责接收来自客户端的请求,并将该请求转发给跟随者,执行一致性操作.领导者除了定时给跟随者发送心跳保持集群稳定运行外,还需要在系统无副领导者时定时广播PoW难题,确定副领导者.

3.1 RPFT算法原理

3.1.1 等待时间选举模型

RPFT共识算法引入虚拟绿色资源等待时间的概念,所谓等待时间,即该服务器节点距离上一次当选为领导者节点间隔的任期差值.为了防止等待时间无限大,规定当服务器节点当选为领导者节点时,置等待时间为零,剩余服务器节点更新等待时间值.

本文根据Raft算法领导者选举过程的特性定义等待时间选举模型分为3个阶段:

第1阶段.投票分裂时,判断候选者节点收到的选票数votecount:votecount超过集群中全部服务器节点数的一半进入第2阶段,否则退出当前任期领导者选举,改变状态成为跟随者,失去本任期竞争领导者的资格;

第2阶段.比较候选者节点收到选票的赞成票数votegranted和反对票数votedfused的大小:若votegranted大于等于votedfused,进入第3阶段;否则改变状态成为跟随者,失去本任期内竞争领导者的资格;

第3阶段.若候选者节点收到大多数节点的选票,证明该候选者节点在集群中通信正常,且该候选者节点收到的选票中赞成票占大部分,则可证明该候选者节点的日志是比较新的,有成为领导者的资格,进入候选队列.等待选举超时后,候选者节点在候选队列里广播竞争领导者节点的请求,等待其他候选者节点的认可.即遍历比较候选队列里所有候选者节点的等待时间,选出最大等待时间的候选者节点成为领导者节点,选举成功.如果存在两个候选者节点等待时间相等,则选取日志索引更大的候选者节点.

本文规定当某一候选者节点成为领导者节点时,其等待时间清空为0,避免造成等待时间无限大的情况,同时更新其他服务器节点的等待时间.

3.1.2 候选队列

在领导者选举之投票选举过程中产生投票分裂的候选者节点,基于等待时间选举模型第1和第2阶段,筛选出的候选者节点进入候选队列,等待选举超时后,在候选队列中发送Leader_Request请求消息,通过所有候选者节点共识选出等待时间最大的候选者节点成为领导者节点,领导者节点选举完成.

算法描述:算法1描述了基于等待时间选举模型,候选者节点在候选队列中发送Leader_Request请求选出领导者.

算法1. Candidate_Queue

输入:Candidate_Queue

输出:Leader

timeChan=true

//在候选者队列中广播成为领导者的请求,等待其他候选者节点的认可

for!timeChando

ifreciveResponse()!=truethen

//队列中存在等待时间更大的候选者节点

server.State=follower

Candidate_Queue.Delete(server)

Returnnull

endif

server.State=leader

server.Wait=0

returnserver

endfor

3.1.3 副领导者选举

与Raft共识算法相比,RPFT算法系统中服务器节点有4种状态:跟随者、候选者、副领导者和领导者.副领导者是首个完成领导者广播的PoW难题的跟随者.在选举超时内未收到领导者的心跳消息,副领导者认为系统中无领导者,直接转换状态成为领导者,系统重新服务.

副领导者选举执行步骤是:

1.领导者正常工作时在无副领导者条件下会定时不断广播PoW难题消息,跟随者节点收到PoW难题解题,并在完成PoW难题时回复领导者.

2.验证:当领导者收到跟随者节点完成回复时,首先验证该跟随者节点任期和日志是否与自己一致,如果是一致并且副领导者为空,则执行3);否则认为该跟随者节点不符合要求,状态不变.

3.设置通过验证的跟随者节点成为副领导者,并广播告知其他节点副领导者身份并告知剩余服务器节点停止解题.

副领导者选举中,通过领导者认证,保证副领导者既是硬件最好的,又保证节点状态是最新的,防止恶意节点通过提高自己的算力选举成为副领导者,威胁系统安全.

3.2 优化的领导者节点选举

在RPFT共识算法中,当领导者宕机时,跟随者以及副领导者节点在一段称之为选举超时的时间内未收到领导者节点的心跳,则认为当前任期内集群中无领导者节点,自发进行领导者节点的选举.首先集群中的跟随者节点检查集群中是否有副领导者节点,若有,则重置定时器,继续等待;否则通过超时机制以投票选举的方式竞争选举领导者,如果在一轮任期内成功选出领导者,则结束当前领导者选举;若当集群中存在两个及以上候选者节点,造成投票分裂的局面时,进入等待时间选举模型阶段,在本任期内选举出领导者,大大提高选举速度,缩短了全网达成共识的时间.若集群中存在副领导者节点,选举超时后,自行改变状态成为领导者,广播心跳和PoW难题,集群稳定.RPFT领导者选举流程图如图3所示.

图3 RPFT算法领导者选举流程图Fig.3 RPFT algorithm leader election flow chart

RPFT共识算法通过结合PoW共识机制,选出副领导者节点,在意识到领导者宕机后,立即上线,几乎无选举时延,大大提高了选举速度.同时由于PoW共识算法的特性,解决了集群中的女巫攻击问题.由于每个节点都有一个等待时间值,当跟随者节点计算pow难题出现分叉时,分析节点的等待时间,选出等待时间最大的跟随者节点成为副领导者节点,解决了PoW共识中的分叉问题.RPFT共识算法通过清空等待时间,解决了原算法领导者集中的缺陷,它较原算法更为公平,它维护了进入网络时间较长、日志始终最新但未当选为领导者的节点.

3.2.1 总体设计

RPFT共识算法领导者节点选举执行步骤是:

1)服务器节点状态是跟随者,正常工作通信.

2)领导者节点瘫痪,跟随者节点未收到领导者节点的心跳消息,选举超时,检查是否存在副领导者节点:如果存在副领导者节点,则重置定时器,副领导节点置为空,跳转3);如果不存在副领导者节点,改变状态成为候选者,任期加1,给自己投肯定票,启动选举定时器并广播投票请求,跳转4).

3)副领导者存在,选举超时后,跳转6).

4)征集选票.如果候选者节点收到比自己更高任期候选者节点的投票请求或者收到被告知已经有其他服务器当选领导者的消息时,则跳转1).如果收到肯定选票数超过集群中全部服务器节点数的一半,则跳转6).

5)等待时间选举模型阶段:投票分裂,等待选举定时器超时后,进入等待时间选举模型阶段:如果候选者节点等待时间不是最大,等待时间加1,更改状态为跟随者,跳转1).如果候选者节点等待时间最大,将等待时间清零,更改状态为领导者,跳转6).

6)成为领导者节点,广播空白心跳告知其他服务器节点,同时广播PoW难题.

3.2.2 详细设计

领导者节点选举过程,RPFT算法将投票选举过程转化为PoW难题提前解题、投票选举和等待时间选举模型结合的过程,如果集群中存在解题成功的副领导者节点,那么该节点在选举超时内未收到领导者节点的心跳,即会立即转换状态成为新任期的领导者节点;如果集群中不存在副领导者节点,集群服务器节点通过投票结合等待时间选举模型的方式选举出新的领导者节点.这种选举方式保证了选举的安全性和公平性,副领导者节点是通过求解当前领导者节点广播的PoW难题产生的,以服务器节点的算力为主要资源,保证了节点的硬件要求,节点不易宕机.若领导者节点宕机时未有节点成功求解PoW难题,则采用Raft原有的投票选举的方式.若投票选举存在投票分裂,结合等待时间选举模型,既提高了选举速度,又保证节点之间的公平性.算法2主要描述了投票选举过程,算法3描述了等待时间选举模型的过程,算法4描述了领导者选举过程.

领导者节点选举过程最重要的是在最短的时间内保证选出的领导者节点正确、高可靠,是通过通过提前求解PoW难题和等待时间选举模型来实现的.

算法2.Leader Election_VoteRequest

输入:Leader Crash,No Deputy leader

输出:New leader,votecount, votegranted, votedfused

timeChan = True //重新设置选举超时

server.State = Candidater;server.Term ++;server.Vote ← server.Name;votecount++

sendVoteRequest() // 广播投票请求

timeChan ← null

forvotegranted <= μ/2 &¬ timeChando

//μ是集群中所有服务器节点的数量

ifreceiveHeatbeat() != null &&receiveVoteRequest().Term >= server.Termthen

server.State = Follower;return null

elseifreciveVote() != nullthen

votecount++ //选票数递增加1

ifreciveVoteResponse().Value = Truethen

votegranted++ //肯定选票数递增加1

ifvotegranted>μ/2then

server.Wait = 0;server.State = Leader;returnserver

endif

elsethen

votedfused++ //反对选票数递增加1

endif

endif

endfor

算法3.Leader Election_Waitting time election model

输入:votecount, votegranted, votedfused

输出:New leader

ifvotecount<= μ/2then

server.State = Follower;returnnull

elseifvotegranted

server.State = Follower;returnnull

elsethen

Candidate_Queue← server // Candidate_Queue为候选队列

timeChan=true //重置选举定时器

for!timeChando//等待定时器超时

continue

Candidate_Queue

endif

endif

算法4.Leader election

输入:Leader Crash

输出:New leader

ifdeputy_leader!=nullthen

returndeputy_leader

elsethen

server=LeaderElection_VoteRequest

ifserver=nullthen

server=LeaderElection_Waittingtimeelectionmodel

returnserver

RPFT算法作为改进的Raft共识算法,以Raft共识算法的安全性和活性要求为鉴分析了算法的安全性和活性.

4.1 安全性分析

安全性指的是所有坏的事情不会发生.Raft共识算法的安全性保证主要体现在:领导者节点选举的安全性、领导者节点只允许附加不允许删除和修改、领导者节点完整性、日志匹配以及状态机安全.

4.1.1 领导者节点选举的安全性

性质1.副领导者节点唯一且正确.

在选举副领导时,领导者节点广播的难题中包含自身当前任期和提交的最后一条内容,包含索引号和内容PowRequest.跟随者节点收到PowRequest消息时,首先分析自身任期和日志是否匹配,如果匹配失败,则无法解题,并反馈给领导者PowRequestResponse,先更新自身与领导者节点达成共识再解题;如果匹配成功,则会计算PoW难题.若有两个节点同时完成PoW难题,则根据等待时间,选举等待时间最大的跟随者成为副领导者;若等待时间相同,则选择日志索引号最大的跟随者,保证集群中只有一个领导者特性.

选出副领导后,为了防止副领导者节点因丢包或者网络延迟产生网络分区,领导者在日志复制过程中,既要大多数节点达成共识也要保证副领导者节点达成共识,集群才可达成共识,以此保证副领导者节点通信正常以及正确性.

性质2.等待时间选举模型选出的领导者唯一且正确.

证明:设系统有M个正确节点、f个拜占庭节点(M≥3f+1),节点总数为N.在领导者选举过程中,如果候选者节点收到votegranted≥2f+1选票时,该候选者得到集群中大多数节点的认可,则成为领导者,选举安全.若产生投票分裂,则进入等待时间选举模型.如果节点收集选票数量votecount<2f+1,则该节点通信不正常,不适合成为领导者,改变状态成为跟随者.

①若候选者节点为拜占庭节点:如果节点收集选票数量votecount≥2f+1,则进入第2阶段,因为系统拜占庭节点数量为f,所以votegranted≤f,即votedfused≥f+1,所以votedfused>votegranted,该候选者退出当前领导者节点竞争,成为跟随者.所以拜占庭节点不会成为领导者节点,领导者选举安全.

综上所述,选出的领导者节点必然是唯一的且是正确节点,领导者选举安全,证毕.

在Raft算法系统中,领导者节点通过定时广播发送心跳的形式以证明领导者节点正常在线.当领导者节点宕机时,跟随者节点因为在一段被称之为选举超时的时间内未收到领导者节点心跳而认为领导者节点不在线触发投票选举.优先触发投票选举的候选者节点在系统中广播发送投票请求消息.此消息包含该节点的当前任期和当前日志索引号,从而保证选举过程的安全性.然而,RPFT算法领导者节点选举的安全性,提出了采用结合PoW共识机制、投票和等待时间选举模型的方式,由性质1、性质2可知选举出的领导者唯一且正确,防止不诚实节点当选为领导者节点.

4.1.2 领导者节点安全性

领导者节点的安全性分为领导者节点完整性和领导者节点只允许添加不允许删除修改日志.由性质1可知RPFT算法保证了副领导者节点处于安全状态,从而保证所有当选的领导者节点都是安全的.由性质2和Raft投票选举可知选举出的领导者是安全的.通过领导者节点选举机制和日志复制过程确保提交到区块链的日志必须出现在领导者节点中,并且交易一旦提交就会永久存储在区块链中.这确保RPFT算法领导者节点完整性以及领导者节点只允许添加不允许删除修改日志的属性.

4.1.3 日志匹配

RPFT算法基于Raft算法的日志结构和共识过程,并在此基础上提出了保证副领导者节点处于通信正常的状态,保证了集群共识以及副领导者节点的正确性,具体可见性质1、性质2.

4.1.4 状态机安全

RPFT算法延用了Raft算法状态机提交至少需要1/2节点同意的前提,为了保证选举出领导者是安全的,在Raft提交前提下添加需要副领导者节点同意的条件,并且将提交状态机过程转换为领导者节点向区块链写入交易的过程.

4.2 活性分析

活性指的是所有好的事情都会发生.Raft算法的活跃性体现在随机选举超时T的设立,即T∈[150ms,300ms]并满足T远大于Tbroadcast,避免了因为消息延迟导致的不必要的领导者节点切换,同时又可以让系统在有限的时间内产生领导者节点,保证系统的正常运行.RPFT共识算法遵循了Raft中选举超时T的建议,如果在该时间段内领导者节点无响应,跟随者节点首先判断集群中是否有副领导者节点,如果存在,即重置定时器等待副领导者节点成为领导者,发送心跳;否则系统采取投票选举方式选举领导者节点,若存在投票分裂问题,再进入等待时间选举模型选举出领导者.

RPFT算法结合PoW算法、投票选举和等待时间选举模型使副本节点在当前任期领导者宕机时开启一个新的任期并快速选举领导者节点对外服务,维持了RPFT算法的活性.

本节将从共识时延、数据吞吐量、选举速度和稳定性4个方面对比RPFT与Raft算法,以此证明RPFT的高可靠性和高效率.

5.1 算法实现

为了实现简单,按照文献[16]中所述,将Raft分成3个独立的部分:领导者选举、日志复制和安全性保证.首先使用Go语言实现了Raft共识算法,然后基于等待时间的概念在Raft算法的投票选举基础上改进并结合等待时间选举模型得到了优化的投票选举过程,最后结合PoW共识机制,提出新的领导者选举过程.实验开启多台虚拟机模拟共识过程,记录共识时延、领导者选举速度、数据吞吐量等关键数据,完成了对比实验.通过实验对比发现,RPFT算法实现了快选举、低时延、高数据吞吐量.

为了模拟领导者下线或者网络分区,本文使用了一个随机模型,以轮为单位,利用随机机制随机选取集群中一个服务器手动断开通信,一轮结束后再恢复通信.

5.2 领导者节点选举时间

针对Raft共识算法中领导者节点选举过程存在投票分裂而造成选举时间长,系统效率低问题,RPFT算法结合PoW共识机制、Raft投票选举和等待时间选举模型优化领导者选举过程.实验测试了节点数为9时的领导者节点平均选举时间,取实验100次结果如图4所示.

图4 领导者节点选举时间点线图Fig.4 Leader node election timeline

从图4点线图可以看出Raft共识算法领导者节点平均选举时间波动较大,低至200ms,高至2000ms,甚至有时候会接近4000ms,选举时间过长.而RPFT算法选举时间稳定,系统中存在副领导者节点时,平均选举时间保持在[150ms,300ms]之间,选举时间短;系统中不存在副领导节点时,不存在投票分裂时平均选举时间保持在[150ms,300ms]之间,存在投票分裂时,结合等待时间选举模型,平均选举时间保持在[300ms,400ms]之间.通过实验对比可知,相较Raft共识算法,RPFT算法大大提高了领导者节点选举速度.

为了评估RPFT共识算法的稳定性,分别开启不同数量的虚拟机模拟不同节点数的集群,记录两种算法领导者节点选举所需平均任期,实验结果如图5所示.

图5 领导者节点选举平均任期Fig.5 Average term of leader node election

从图5点线图可以看出Raft共识算法随着系统服务器节点数量的增加,系统领导者节点选举所需的平均时间也随之增加.而RPFT共识算法即使系统服务器节点数增加,选举所需的任期仍然是1,相比Raft共识算法其领导者选举算法更加稳定.

5.3 共识时延

共识时延指的是客户端从提交数据请求到收到请求回复的时间.RPFT算法延用了Raft算法日志复制过程,领导者接收客户端发送的数据请求,并单向广播给跟随者节点,在相同的网络环境下,两种算法的共识时延差不多相等.经过多次实验,分别记录了RPFT和Raft算法在节点数为9时的共识时延对比柱状图以及随着节点数增加,两种算法的平均时延对比柱状图,如图6(a)所示.

5.4 数据吞吐量

系统的数据吞吐量定义为系统每秒钟处理的事务量.在区块链系统中,数据吞吐量表现为交易数据量M与对应的交易时间T的比值,即:

(2)

数据吞吐量是衡量区块链共识算法效率的一种重要因素.根据图6(a)设置客户端发送请求的间隔为TConsensus,客户端每隔TConsensus发起一次请求命令,交易量为M,记录时间为T1,当领导者节点收到半数以上跟随者节点的正反馈后,返回共识时间为T2.TPS=M/时间间隔,时间间隔为T2-T1.启用一个虚拟机作为客户端,负责向服务器节点广播交易数据;启用多个虚拟机作为服务器节点,包括领导者节点和跟随者节点,即共识节点,负责对客户端发送的交易数据进行共识和提交上链.

若在日志共识的过程中领导者节点宕机,则客户端需要重新发送交易数据,因此客户端需要设置合理的定时器,在长时间未收到领导者节点的回复时,应重新发送交易数据.定时器的时间TTimeout设置为图6(a)领导者未宕机的情况下的共识时延.TConsensus定义为领导者正常工作时的共识时间,TElection定义为领导者节点的选举时间,所以交易时间T定义为:

(3)

由于TTimeout与TConsensus相等,所以由公式(3)可得到公式(4):

(4)

表1给出了集群服务器节点数量为9时,随机选取10组两种算法选举领导者所需的时间.由公式(4)、表1和图6(a)可以得到集群服务器节点数目为9时,当领导者在未宕机和宕机情况下处理交易,单条数据的交易时间以及领导者节点选举时间占共识总时间的比重如图6(b)、图6(c)所示.

在相同实验环境下,进行多次实验,由图6可以对比看出,当领导者节点瘫痪时,客户端发送交易请求,系统处理单条数据的交易时间明显增加,而且在本次共识中,领导者选举时间占整个共识很大的比重,明显延长共识时延.并且,由于RPFT算法领导者选举速度快,共识时间明显小于Raft算法.例如处理单条数据,领导者节点一直在线时,两种算法的共识时延都在50ms左右,当存在领导者瘫痪时,Raft算法共识时延是2000ms,有时甚至高达8000ms,达到千秒级,而RPFT算法共识时延是200ms~500ms,百秒级,处理单条数据的交易时间明显快于Raft算法.

本文实验通过设置不同的难度值进行PoW解题时得到的解题时间如表2所示,结合表2中PoW解题时间以及Raft选举超时时间,选取PoW的难度值为10.图6(d)是系统中节点数为9时,两种算法数据吞吐量对比图,从图6(d)可以看出,即使PoW计算难题会带来额外的开销,但是由于选举速度快,RPFT算法的吞吐量仍高于Raft算法.

从图6(b)、图6(c)单条数据交易时间的对比柱状图可以得到,领导者选举时间越短,交易时间越短,系统TPS越高,从图6(d)明显看出RPFT算法数据吞吐量更高,所以RPFT算法数据吞吐量明显比Raft算法高.

表1 选举时间表Table 1 Electoral timetable

表2 PoW共识算法解题时间表Table 2 PoW consensus algorithm problem solving time table

LD_RAFT:Leader down Raft,领导者随机断开,Raft集群的共识时间.LD_RPFT:Leader down RPFT,领导者随机断开,RPFT集群的共识时间.LND_RAFT:Lader not down Raft, 领导者一直未宕机,Raft集群的共识时间.LND_ RPFT:Lader not down RPFT,领导者一直未宕机,RPFT集群的共识时间.E/T:表示选举时间占整个共识时间的比重.

图6 数据吞吐量对比实验图Fig.6 Experimental diagram of data throughput comparison

本文选取Raft共识算法作为研究对象,通过结合PoW共识算法,利用PoW共识算法集中算力和抗女巫攻击的优点,选举出高质量硬件的诚实节点,优化了Raft共识算法的领导者节点选举过程.RPFT算法改善了Raft共识算法领导者节点选举的分裂投票问题,从而有效地提升了领导者节点的选举速度,进而提升了算法的数据吞吐量和可拓展性.但是本文仍存在一些问题,如无法实现节点的动态加入等.

猜你喜欢候选者跟随者等待时间——国外课堂互动等待时间研究的现状与启示">给学生适宜的等待时间
——国外课堂互动等待时间研究的现状与启示中小学教师培训(2022年6期)2023-01-11我能猜到你心里的数字小学生学习指导(爆笑校园)(2020年5期)2020-11-25用肉眼看到的最远的星星是什么?中外文摘(2018年1期)2018-11-21最满意的答案黄河黄土黄种人(2017年10期)2017-10-26由城市台的“跟随者”到县域“三农”媒体的 “领导者”中国广播(2017年9期)2017-09-30—— 瓮福集团PPA项目成为搅动市场的“鲶鱼”">从“跟随者”到“引领者”
—— 瓮福集团PPA项目成为搅动市场的“鲶鱼”当代贵州(2017年24期)2017-06-15跟随者诗潮(2017年5期)2017-06-01意大利:反腐败没有等待时间公民与法治(2016年2期)2016-05-17顾客等待心理的十条原则视野(2015年14期)2015-07-28顾客等待心理的十条原则读者(2015年12期)2015-06-19

推荐访问:共识 算法 RPFT