导航:首页 > 源码编译 > pbft共识算法原理

pbft共识算法原理

发布时间:2024-06-04 08:40:16

A. 区块链的共识机制

一、区块链共识机制的目标

区块链是什么?简单而言,区块链是一种去中心化的数据库,或可以叫作分布式账本(distributed ledger)。传统上所有的数据库都是中心化的,例如一间银行的账本就储存在银行的中心服务器里。中心化数据库的弊端是数据的安全及正确性全系于数据库运营方(即银行),因为任何能够访问中心化数据库的人(如银行职员或黑客)都可以破坏或修改其中的数据。


而区块链技术则容许数据库存放在全球成千上万的电脑上,每个人的账本通过点对点网络进行同步,网络中任何用户一旦增加一笔交易,交易信息将通过网络通知其他用户验证,记录到各自的账本中。区块链之所以得其名是因为它是由一个个包含交易信息的区块(block)从后向前有序链接起来的数据结构。


很多人对区块链的疑问是,如果每一个用户都拥有一个独立的账本,那么是否意味着可以在自己的账本上添加任意的交易信息,而成千上万个账本又如何保证记账的一致性? 解决记账一致性问题正是区块链共识机制的目标 。区块链共识机制旨在保证分布式系统里所有节点中的数据完全相同并且能够对某个提案(proposal)(例如是一项交易纪录)达成一致。然而分布式系统由于引入了多个节点,所以系统中会出现各种非常复杂的情况;随着节点数量的增加,节点失效或故障、节点之间的网络通信受到干扰甚至阻断等就变成了常见的问题,解决分布式系统中的各种边界条件和意外情况也增加了解决分布式一致性问题的难度。


区块链又可分为三种:


公有链:全世界任何人都可以随时进入系统中读取数据、发送可确认交易、竞争记账的区块链。公有链通常被认为是“完全去中心化“的,因为没有任何人或机构可以控制或篡改其中数据的读写。公有链一般会通过代币机制鼓励参与者竞争记账,来确保数据的安全性。


联盟链:联盟链是指有若干个机构共同参与管理的区块链。每个机构都运行着一个或多个节点,其中的数据只允许系统内不同的机构进行读写和发送交易,并且共同来记录交易数据。这类区块链被认为是“部分去中心化”。


私有链:指其写入权限是由某个组织和机构控制的区块链。参与节点的资格会被严格的限制,由于参与的节点是有限和可控的,因此私有链往往可以有极快的交易速度、更好的隐私保护、更低的交易成本、不容易被恶意攻击、并且能够做到身份认证等金融行业必须的要求。相比中心化数据库,私有链能够防止机构内单节点故意隐瞒或篡改数据。即使发生错误,也能够迅速发现来源,因此许多大型金融机构在目前更加倾向于使用私有链技术。

二、区块链共识机制的分类

解决分布式一致性问题的难度催生了数种共识机制,它们各有其优缺点,亦适用于不同的环境及问题。被众人常识的共识机制有:


l PoW(Proof of Work)工作量证明机制

l PoS(Proof of Stake)股权/权益证明机制

l DPoS(Delegated Proof of Stake)股份授权证明机制

l PBFT(Practical Byzantine Fault Tolerance)实用拜占庭容错算法

l DBFT(Delegated Byzantine Fault Tolerance)授权拜占庭容错算法

l SCP (Stellar Consensus Protocol ) 恒星共识协议

l RPCA(Ripple Protocol Consensus Algorithm)Ripple共识算法

l Pool验证池共识机制


(一)PoW(Proof of Work)工作量证明机制


1. 基本介绍


在该机制中,网络上的每一个节点都在使用SHA256哈希函数(hash function) 运算一个不断变化的区块头的哈希值 (hash sum)。 共识要求算出的值必须等于或小于某个给定的值。 在分布式网络中,所有的参与者都需要使用不同的随机数来持续计算该哈希值,直至达到目标为止。当一个节点的算出确切的值,其他所有的节点必须相互确认该值的正确性。之后新区块中的交易将被验证以防欺诈。


在比特币中,以上运算哈希值的节点被称作“矿工”,而PoW的过程被称为“挖矿”。挖矿是一个耗时的过程,所以也提出了相应的激励机制(例如向矿工授予一小部分比特币)。PoW的优点是完全的去中心化,其缺点是消耗大量算力造成了的资源浪费,达成共识的周期也比较长,共识效率低下,因此其不是很适合商业使用。



2. 加密货币的应用实例


比特币(Bitcoin) 及莱特币(Litecoin)。以太坊(Ethereum) 的前三个阶段(Frontier前沿、Homestead家园、Metropolis大都会)皆采用PoW机制,其第四个阶段 (Serenity宁静) 将采用权益证明机制。PoW适用于公有链。


PoW机制虽然已经成功证明了其长期稳定和相对公平,但在现有框架下,采用PoW的“挖矿”形式,将消耗大量的能源。其消耗的能源只是不停的去做SHA256的运算来保证工作量公平,并没有其他的存在意义。而目前BTC所能达到的交易效率为约5TPS(5笔/秒),以太坊目前受到单区块GAS总额的上限,所能达到的交易频率大约是25TPS,与平均千次每秒、峰值能达到万次每秒处理效率的VISA和MASTERCARD相差甚远。


3. 简图理解模式



(ps:其中A、B、C、D计算哈希值的过程即为“挖矿”,为了犒劳时间成本的付出,机制会以一定数量的比特币作为激励。)


(Ps:PoS模式下,你的“挖矿”收益正比于你的币龄(币的数量*天数),而与电脑的计算性能无关。我们可以认为任何具有概率性事件的累计都是工作量证明,如淘金。假设矿石含金量为p% 质量, 当你得到一定量黄金时,我们可以认为你一定挖掘了1/p 质量的矿石。而且得到的黄金数量越多,这个证明越可靠。)


(二)PoS(Proof of Stake)股权/权益证明机制


1.基本介绍


PoS要求人们证明货币数量的所有权,其相信拥有货币数量多的人攻击网络的可能性低。基于账户余额的选择是非常不公平的,因为单一最富有的人势必在网络中占主导地位,所以提出了许多解决方案。


在股权证明机制中,每当创建一个区块时,矿工需要创建一个称为“币权”的交易,这个交易会按照一定比例预先将一些币发给矿工。然后股权证明机制根据每个节点持有代币的比例和时间(币龄), 依据算法等比例地降低节点的挖矿难度,以加快节点寻找随机数的速度,缩短达成共识所需的时间。


与PoW相比,PoS可以节省更多的能源,更有效率。但是由于挖矿成本接近于0,因此可能会遭受攻击。且PoS在本质上仍然需要网络中的节点进行挖矿运算,所以它同样难以应用于商业领域。



2.数字货币的应用实例


PoS机制下较为成熟的数字货币是点点币(Peercoin)和未来币(NXT),相比于PoW,PoS机制节省了能源,引入了" 币天 "这个概念来参与随机运算。PoS机制能够让更多的持币人参与到记账这个工作中去,而不需要额外购买设备(矿机、显卡等)。每个单位代币的运算能力与其持有的时间长成正相关,即持有人持有的代币数量越多、时间越长,其所能签署、生产下一个区块的概率越大。一旦其签署了下一个区块,持币人持有的币天即清零,重新进入新的循环。


PoS适用于公有链。


3.区块签署人的产生方式


在PoS机制下,因为区块的签署人由随机产生,则一些持币人会长期、大额持有代币以获得更大概率地产生区块,尽可能多的去清零他的"币天"。因此整个网络中的流通代币会减少,从而不利于代币在链上的流通,价格也更容易受到波动。由于可能会存在少量大户持有整个网络中大多数代币的情况,整个网络有可能会随着运行时间的增长而越来越趋向于中心化。相对于PoW而言,PoS机制下作恶的成本很低,因此对于分叉或是双重支付的攻击,需要更多的机制来保证共识。稳定情况下,每秒大约能产生12笔交易,但因为网络延迟及共识问题,需要约60秒才能完整广播共识区块。长期来看,生成区块(即清零"币天")的速度远低于网络传播和广播的速度,因此在PoS机制下需要对生成区块进行"限速",来保证主网的稳定运行。


4.简图理解模式




(PS:拥有越多“股份”权益的人越容易获取账权。是指获得多少货币,取决于你挖矿贡献的工作量,电脑性能越好,分给你的矿就会越多。)


(在纯POS体系中,如NXT,没有挖矿过程,初始的股权分配已经固定,之后只是股权在交易者之中流转,非常类似于现实世界的股票。)


(三)DPoS(Delegated Proof of Stake)股份授权证明机制


1.基本介绍


由于PoS的种种弊端,由此比特股首创的权益代表证明机制 DPoS(Delegated Proof of Stake)应运而生。DPoS 机制中的核心的要素是选举,每个系统原生代币的持有者在区块链里面都可以参与选举,所持有的代币余额即为投票权重。通过投票,股东可以选举出理事会成员,也可以就关系平台发展方向的议题表明态度,这一切构成了社区自治的基础。股东除了自己投票参与选举外,还可以通过将自己的选举票数授权给自己信任的其它账户来代表自己投票。


具体来说, DPoS由比特股(Bitshares)项目组发明。股权拥有着选举他们的代表来进行区块的生成和验证。DPoS类似于现代企业董事会制度,比特股系统将代币持有者称为股东,由股东投票选出101名代表, 然后由这些代表负责生成和验证区块。 持币者若想称为一名代表,需先用自己的公钥去区块链注册,获得一个长度为32位的特有身份标识符,股东可以对这个标识符以交易的形式进行投票,得票数前101位被选为代表。

代表们轮流产生区块,收益(交易手续费)平分。DPoS的优点在于大幅减少了参与区块验证和记账的节点数量,从而缩短了共识验证所需要的时间,大幅提高了交易效率。从某种角度来说,DPoS可以理解为多中心系统,兼具去中心化和中心化优势。优点:大幅缩小参与验证和记账节点的数量,可以达到秒级的共识验证。缺点:投票积极性不高,绝大部分代币持有者未参与投票;另整个共识机制还是依赖于代币,很多商业应用是不需要代币存在的。


DPoS机制要求在产生下一个区块之前,必须验证上一个区块已经被受信任节点所签署。相比于PoS的" 全民挖矿 ",DPoS则是利用类似" 代表大会 "的制度来直接选取可信任节点,由这些可信任节点(即见证人)来代替其他持币人行使权力,见证人节点要求长期在线,从而解决了因为PoS签署区块人不是经常在线而可能导致的产块延误等一系列问题。 DPoS机制通常能达到万次每秒的交易速度,在网络延迟低的情况下可以达到十万秒级别,非常适合企业级的应用。 因为公信宝数据交易所对于数据交易频率要求高,更要求长期稳定性,因此DPoS是非常不错的选择。



2. 股份授权证明机制下的机构与系统


理事会是区块链网络的权力机构,理事会的人选由系统股东(即持币人)选举产生,理事会成员有权发起议案和对议案进行投票表决。


理事会的重要职责之一是根据需要调整系统的可变参数,这些参数包括:


l 费用相关:各种交易类型的费率。

l 授权相关:对接入网络的第三方平台收费及补贴相关参数。

l 区块生产相关:区块生产间隔时间,区块奖励。

l 身份审核相关:审核验证异常机构账户的信息情况。

l 同时,关系到理事会利益的事项将不通过理事会设定。


在Finchain系统中,见证人负责收集网络运行时广播出来的各种交易并打包到区块中,其工作类似于比特币网络中的矿工,在采用 PoW(工作量证明)的比特币网络中,由一种获奖概率取决于哈希算力的抽彩票方式来决定哪个矿工节点产生下一个区块。而在采用 DPoS 机制的金融链网络中,通过理事会投票决定见证人的数量,由持币人投票来决定见证人人选。入选的活跃见证人按顺序打包交易并生产区块,在每一轮区块生产之后,见证人会在随机洗牌决定新的顺序后进入下一轮的区块生产。


3. DPoS的应用实例


比特股(bitshares) 采用DPoS。DPoS主要适用于联盟链。


4.简图理解模式





(四)PBFT(Practical Byzantine Fault Tolerance)实用拜占庭容错算法


1. 基本介绍


PBFT是一种基于严格数学证明的算法,需要经过三个阶段的信息交互和局部共识来达成最终的一致输出。三个阶段分别为预备 (pre-prepare)、准备 (prepare)、落实 (commit)。PBFT算法证明系统中只要有2/3比例以上的正常节点,就能保证最终一定可以输出一致的共识结果。换言之,在使用PBFT算法的系统中,至多可以容忍不超过系统全部节点数量1/3的失效节点 (包括有意误导、故意破坏系统、超时、重复发送消息、伪造签名等的节点,又称为”拜占庭”节点)。



2. PBFT的应用实例


着名联盟链Hyperledger Fabric v0.6采用的是PBFT,v1.0又推出PBFT的改进版本SBFT。PBFT主要适用于私有链和联盟链。


3. 简图理解模式




上图显示了一个简化的PBFT的协议通信模式,其中C为客户端,0 – 3表示服务节点,其中0为主节点,3为故障节点。整个协议的基本过程如下:


(1) 客户端发送请求,激活主节点的服务操作;

(2) 当主节点接收请求后,启动三阶段的协议以向各从节点广播请求;

(a) 序号分配阶段,主节点给请求赋值一个序号n,广播序号分配消息和客户端的请求消息m,并将构造pre-prepare消息给各从节点;

(b) 交互阶段,从节点接收pre-prepare消息,向其他服务节点广播prepare消息;

(c) 序号确认阶段,各节点对视图内的请求和次序进行验证后,广播commit消息,执行收到的客户端的请求并给客户端响应。

(3) 客户端等待来自不同节点的响应,若有m+1个响应相同,则该响应即为运算的结果;



(五)DBFT(Delegated Byzantine Fault Tolerance)授权拜占庭容错算法


1. 基本介绍


DBFT建基于PBFT的基础上,在这个机制当中,存在两种参与者,一种是专业记账的“超级节点”,一种是系统当中不参与记账的普通用户。普通用户基于持有权益的比例来投票选出超级节点,当需要通过一项共识(记账)时,在这些超级节点中随机推选出一名发言人拟定方案,然后由其他超级节点根据拜占庭容错算法(见上文),即少数服从多数的原则进行表态。如果超过2/3的超级节点表示同意发言人方案,则共识达成。这个提案就成为最终发布的区块,并且该区块是不可逆的,所有里面的交易都是百分之百确认的。如果在一定时间内还未达成一致的提案,或者发现有非法交易的话,可以由其他超级节点重新发起提案,重复投票过程,直至达成共识。



2. DBFT的应用实例


国内加密货币及区块链平台NEO是 DBFT算法的研发者及采用者。


3. 简图理解模式




假设系统中只有四个由普通用户投票选出的超级节点,当需要通过一项共识时,系统就会从代表中随机选出一名发言人拟定方案。发言人会将拟好的方案交给每位代表,每位代表先判断发言人的计算结果与它们自身纪录的是否一致,再与其它代表商讨验证计算结果是否正确。如果2/3的代表一致表示发言人方案的计算结果是正确的,那么方案就此通过。


如果只有不到2/3的代表达成共识,将随机选出一名新的发言人,再重复上述流程。这个体系旨在保护系统不受无法行使职能的领袖影响。


上图假设全体节点都是诚实的,达成100%共识,将对方案A(区块)进行验证。



鉴于发言人是随机选出的一名代表,因此他可能会不诚实或出现故障。上图假设发言人给3名代表中的2名发送了恶意信息(方案B),同时给1名代表发送了正确信息(方案A)。


在这种情况下该恶意信息(方案B)无法通过。中间与右边的代表自身的计算结果与发言人发送的不一致,因此就不能验证发言人拟定的方案,导致2人拒绝通过方案。左边的代表因接收了正确信息,与自身的计算结果相符,因此能确认方案,继而成功完成1次验证。但本方案仍无法通过,因为不足2/3的代表达成共识。接着将随机选出一名新发言人,重新开始共识流程。




上图假设发言人是诚实的,但其中1名代表出现了异常;右边的代表向其他代表发送了不正确的信息(B)。


在这种情况下发言人拟定的正确信息(A)依然可以获得验证,因为左边与中间诚实的代表都可以验证由诚实的发言人拟定的方案,达成2/3的共识。代表也可以判断到底是发言人向右边的节点说谎还是右边的节点不诚实。


(六)SCP (Stellar Consensus Protocol ) 恒星共识协议


1. 基本介绍


SCP 是 Stellar (一种基于互联网的去中心化全球支付协议) 研发及使用的共识算法,其建基于联邦拜占庭协议 (Federated Byzantine Agreement) 。传统的非联邦拜占庭协议(如上文的PBFT和DBFT)虽然确保可以通过分布式的方法达成共识,并达到拜占庭容错 (至多可以容忍不超过系统全部节点数量1/3的失效节点),它是一个中心化的系统 — 网络中节点的数量和身份必须提前知晓且验证过。而联邦拜占庭协议的不同之处在于它能够去中心化的同时,又可以做到拜占庭容错。


[…]


(七)RPCA(Ripple Protocol Consensus Algorithm)Ripple共识算法


1. 基本介绍


RPCA是Ripple(一种基于互联网的开源支付协议,可以实现去中心化的货币兑换、支付与清算功能)研发及使用的共识算法。在 Ripple 的网络中,交易由客户端(应用)发起,经过追踪节点(tracking node)或验证节点(validating node)把交易广播到整个网络中。追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外,还能够通过共识协议,在账本中增加新的账本实例数据。


Ripple 的共识达成发生在验证节点之间,每个验证节点都预先配置了一份可信任节点名单,称为 UNL(Unique Node List)。在名单上的节点可对交易达成进行投票。共识过程如下:


(1) 每个验证节点会不断收到从网络发送过来的交易,通过与本地账本数据验证后,不合法的交易直接丢弃,合法的交易将汇总成交易候选集(candidate set)。交易候选集里面还包括之前共识过程无法确认而遗留下来的交易。

(2) 每个验证节点把自己的交易候选集作为提案发送给其他验证节点。

(3) 验证节点在收到其他节点发来的提案后,如果不是来自UNL上的节点,则忽略该提案;如果是来自UNL上的节点,就会对比提案中的交易和本地的交易候选集,如果有相同的交易,该交易就获得一票。在一定时间内,当交易获得超过50%的票数时,则该交易进入下一轮。没有超过50%的交易,将留待下一次共识过程去确认。

(4) 验证节点把超过50%票数的交易作为提案发给其他节点,同时提高所需票数的阈值到60%,重复步骤(3)、步骤(4),直到阈值达到80%。

(5) 验证节点把经过80%UNL节点确认的交易正式写入本地的账本数据中,称为最后关闭账本(last closed ledger),即账本最后(最新)的状态。


在Ripple的共识算法中,参与投票节点的身份是事先知道的,因此,算法的效率比PoW等匿名共识算法要高效,交易的确认时间只需几秒钟。这点也决定了该共识算法只适合于联盟链或私有链。Ripple共识算法的拜占庭容错(BFT)能力为(n-1)/5,即可以容忍整个网络中20%的节点出现拜占庭错误而不影响正确的共识。



2. 简图理解模式


共识过程节点交互示意图:



共识算法流程:



(八)POOL验证池共识机制


Pool验证池共识机制是基于传统的分布式一致性算法(Paxos和Raft)的基础上开发的机制。Paxos算法是1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。过去, Paxos一直是分布式协议的标准,但是Paxos难于理解,更难以实现。Raft则是在2013年发布的一个比Paxos简单又能实现Paxos所解决问题的一致性算法。Paxos和Raft达成共识的过程皆如同选举一样,参选者需要说服大多数选民(服务器)投票给他,一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。而Pool验证池共识机制即是在这两种成熟的分布式一致性算法的基础上,辅之以数据验证的机制。






B. 区块链 --- 共识算法

PoW算法是一种防止分布式服务资源被滥用、拒绝服务攻击的机制。它要求节点进行适量消耗时间和资源的复杂运算,并且其运算结果能被其他节点快速验算,以耗用时间、能源做担保,以确保服务与资源被真正的需求所使用。

PoW算法中最基本的技术原理是使用哈希算法。假设求哈希值Hash(r),若原始数据为r(raw),则运算结果为R(Result)。

R = Hash(r)

哈希函数Hash()的特性是,对于任意输入值r,得出结果R,并且无法从R反推回r。当输入的原始数据r变动1比特时,其结果R值完全改变。在比特币的PoW算法中,引入算法难度d和随机值n,得到以下公式:

Rd = Hash(r+n)

该公式要求在填入随机值n的情况下,计算结果Rd的前d字节必须为0。由于哈希函数结果的未知性,每个矿工都要做大量运算之后,才能得出正确结果,而算出结果广播给全网之后,其他节点只需要进行一次哈希运算即可校验。PoW算法就是采用这种方式让计算消耗资源,而校验仅需一次。

 

PoS算法要求节点验证者必须质押一定的资金才有挖矿打包资格,并且区域链系统在选定打包节点时使用随机的方式,当节点质押的资金越多时,其被选定打包区块的概率越大。

POS模式下,每个币每天产生1币龄,比如你持有100个币,总共持有了30天,那么,此时你的币龄就为3000。这个时候,如果你验证了一个POS区块,你的币龄就会被清空为0,同时从区块中获得相对应的数字货币利息。

节点通过PoS算法出块的过程如下:普通的节点要成为出块节点,首先要进行资产的质押,当轮到自己出块时,打包区块,然后向全网广播,其他验证节点将会校验区块的合法性。

 

DPoS算法和PoS算法相似,也采用股份和权益质押。

但不同的是,DPoS算法采用委托质押的方式,类似于用全民选举代表的方式选出N个超级节点记账出块。

选民把自己的选票投给某个节点,如果某个节点当选记账节点,那么该记账节点往往在获取出块奖励后,可以采用任意方式来回报自己的选民。

这N个记账节点将轮流出块,并且节点之间相互监督,如果其作恶,那么会被扣除质押金。

通过信任少量的诚信节点,可以去除区块签名过程中不必要的步骤,提高了交易的速度。
 

拜占庭问题:

拜占庭是古代东罗马帝国的首都,为了防御在每块封地都驻扎一支由单个将军带领的军队,将军之间只能靠信差传递消息。在战争时,所有将军必须达成共识,决定是否共同开战。

但是,在军队内可能有叛徒,这些人将影响将军们达成共识。拜占庭将军问题是指在已知有将军是叛徒的情况下,剩余的将军如何达成一致决策的问题。

BFT:

BFT即拜占庭容错,拜占庭容错技术是一类分布式计算领域的容错技术。拜占庭假设是对现实世界的模型化,由于硬件错误、网络拥塞或中断以及遭到恶意攻击等原因,计算机和网络可能出现不可预料的行为。拜占庭容错技术被设计用来处理这些异常行为,并满足所要解决的问题的规范要求。

拜占庭容错系统

发生故障的节点被称为 拜占庭节点 ,而正常的节点即为 非拜占庭节点

假设分布式系统拥有n台节点,并假设整个系统拜占庭节点不超过m台(n ≥ 3m + 1),拜占庭容错系统需要满足如下两个条件:

另外,拜占庭容错系统需要达成如下两个指标:

PBFT即实用拜占庭容错算法,解决了原始拜占庭容错算法效率不高的问题,算法的时间复杂度是O(n^2),使得在实际系统应用中可以解决拜占庭容错问题
 

PBFT是一种状态机副本复制算法,所有的副本在一个视图(view)轮换的过程中操作,主节点通过视图编号以及节点数集合来确定,即:主节点 p = v mod |R|。v:视图编号,|R|节点个数,p:主节点编号。

PBFT算法的共识过程如下:客户端(Client)发起消息请求(request),并广播转发至每一个副本节点(Replica),由其中一个主节点(Leader)发起提案消息pre-prepare,并广播。其他节点获取原始消息,在校验完成后发送prepare消息。每个节点收到2f+1个prepare消息,即认为已经准备完毕,并发送commit消息。当节点收到2f+1个commit消息,客户端收到f+1个相同的reply消息时,说明客户端发起的请求已经达成全网共识。

具体流程如下

客户端c向主节点p发送<REQUEST, o, t, c>请求。o: 请求的具体操作,t: 请求时客户端追加的时间戳,c:客户端标识。REQUEST: 包含消息内容m,以及消息摘要d(m)。客户端对请求进行签名。

主节点收到客户端的请求,需要进行以下交验:

a. 客户端请求消息签名是否正确。

非法请求丢弃。正确请求,分配一个编号n,编号n主要用于对客户端的请求进行排序。然后广播一条<<PRE-PREPARE, v, n, d>, m>消息给其他副本节点。v:视图编号,d客户端消息摘要,m消息内容。<PRE-PREPARE, v, n, d>进行主节点签名。n是要在某一个范围区间内的[h, H],具体原因参见 垃圾回收 章节。

副本节点i收到主节点的PRE-PREPARE消息,需要进行以下交验:

a. 主节点PRE-PREPARE消息签名是否正确。

b. 当前副本节点是否已经收到了一条在同一v下并且编号也是n,但是签名不同的PRE-PREPARE信息。

c. d与m的摘要是否一致。

d. n是否在区间[h, H]内。

非法请求丢弃。正确请求,副本节点i向其他节点包括主节点发送一条<PREPARE, v, n, d, i>消息, v, n, d, m与上述PRE-PREPARE消息内容相同,i是当前副本节点编号。<PREPARE, v, n, d, i>进行副本节点i的签名。记录PRE-PREPARE和PREPARE消息到log中,用于View Change过程中恢复未完成的请求操作。

主节点和副本节点收到PREPARE消息,需要进行以下交验:

a. 副本节点PREPARE消息签名是否正确。

b. 当前副本节点是否已经收到了同一视图v下的n。

c. n是否在区间[h, H]内。

d. d是否和当前已收到PRE-PPREPARE中的d相同

非法请求丢弃。如果副本节点i收到了2f+1个验证通过的PREPARE消息,则向其他节点包括主节点发送一条<COMMIT, v, n, d, i>消息,v, n, d, i与上述PREPARE消息内容相同。<COMMIT, v, n, d, i>进行副本节点i的签名。记录COMMIT消息到日志中,用于View Change过程中恢复未完成的请求操作。记录其他副本节点发送的PREPARE消息到log中。

主节点和副本节点收到COMMIT消息,需要进行以下交验:

a. 副本节点COMMIT消息签名是否正确。

b. 当前副本节点是否已经收到了同一视图v下的n。

c. d与m的摘要是否一致。

d. n是否在区间[h, H]内。

非法请求丢弃。如果副本节点i收到了2f+1个验证通过的COMMIT消息,说明当前网络中的大部分节点已经达成共识,运行客户端的请求操作o,并返回<REPLY, v, t, c, i, r>给客户端,r:是请求操作结果,客户端如果收到f+1个相同的REPLY消息,说明客户端发起的请求已经达成全网共识,否则客户端需要判断是否重新发送请求给主节点。记录其他副本节点发送的COMMIT消息到log中。
 

如果主节点作恶,它可能会给不同的请求编上相同的序号,或者不去分配序号,或者让相邻的序号不连续。备份节点应当有职责来主动检查这些序号的合法性。

如果主节点掉线或者作恶不广播客户端的请求,客户端设置超时机制,超时的话,向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线,发起View Change协议。

View Change协议

副本节点向其他节点广播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的编号, C 2f+1验证过的CheckPoint消息集合, P 是当前副本节点未完成的请求的PRE-PREPARE和PREPARE消息集合。

当主节点p = v + 1 mod |R|收到 2f 个有效的VIEW-CHANGE消息后,向其他节点广播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主节点重新发起的未经完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的选取规则:

副本节点收到主节点的NEW-VIEW消息,验证有效性,有效的话,进入v+1状态,并且开始 O 中的PRE-PREPARE消息处理流程。
 

在上述算法流程中,为了确保在View Change的过程中,能够恢复先前的请求,每一个副本节点都记录一些消息到本地的log中,当执行请求后副本节点需要把之前该请求的记录消息清除掉。

最简单的做法是在Reply消息后,再执行一次当前状态的共识同步,这样做的成本比较高,因此可以在执行完多条请求K(例如:100条)后执行一次状态同步。这个状态同步消息就是CheckPoint消息。

副本节点i发送<CheckPoint, n, d, i>给其他节点,n是当前节点所保留的最后一个视图请求编号,d是对当前状态的一个摘要,该CheckPoint消息记录到log中。如果副本节点i收到了2f+1个验证过的CheckPoint消息,则清除先前日志中的消息,并以n作为当前一个stable checkpoint。

这是理想情况,实际上当副本节点i向其他节点发出CheckPoint消息后,其他节点还没有完成K条请求,所以不会立即对i的请求作出响应,它还会按照自己的节奏,向前行进,但此时发出的CheckPoint并未形成stable。

为了防止i的处理请求过快,设置一个上文提到的 高低水位区间[h, H] 来解决这个问题。低水位h等于上一个stable checkpoint的编号,高水位H = h + L,其中L是我们指定的数值,等于checkpoint周期处理请求数K的整数倍,可以设置为L = 2K。当副本节点i处理请求超过高水位H时,此时就会停止脚步,等待stable checkpoint发生变化,再继续前进。
 

在区块链场景中,一般适合于对强一致性有要求的私有链和联盟链场景。例如,在IBM主导的区块链超级账本项目中,PBFT是一个可选的共识协议。在Hyperledger的Fabric项目中,共识模块被设计成可插拔的模块,支持像PBFT、Raft等共识算法。
 

 

Raft基于领导者驱动的共识模型,其中将选举一位杰出的领导者(Leader),而该Leader将完全负责管理集群,Leader负责管理Raft集群的所有节点之间的复制日志。
 

下图中,将在启动过程中选择集群的Leader(S1),并为来自客户端的所有命令/请求提供服务。 Raft集群中的所有节点都维护一个分布式日志(复制日志)以存储和提交由客户端发出的命令(日志条目)。 Leader接受来自客户端的日志条目,并在Raft集群中的所有关注者(S2,S3,S4,S5)之间复制它们。

在Raft集群中,需要满足最少数量的节点才能提供预期的级别共识保证, 这也称为法定人数。 在Raft集群中执行操作所需的最少投票数为 (N / 2 +1) ,其中N是组中成员总数,即 投票至少超过一半 ,这也就是为什么集群节点通常为奇数的原因。 因此,在上面的示例中,我们至少需要3个节点才能具有共识保证。

如果法定仲裁节点由于任何原因不可用,也就是投票没有超过半数,则此次协商没有达成一致,并且无法提交新日志。

 

数据存储:Tidb/TiKV

日志:阿里巴巴的 DLedger

服务发现:Consul& etcd

集群调度:HashiCorp Nomad
 

只能容纳故障节点(CFT),不容纳作恶节点

顺序投票,只能串行apply,因此高并发场景下性能差
 

Raft通过解决围绕Leader选举的三个主要子问题,管理分布式日志和算法的安全性功能来解决分布式共识问题。

当我们启动一个新的Raft集群或某个领导者不可用时,将通过集群中所有成员节点之间协商来选举一个新的领导者。 因此,在给定的实例中,Raft集群的节点可以处于以下任何状态: 追随者(Follower),候选人(Candidate)或领导者(Leader)。

系统刚开始启动的时候,所有节点都是follower,在一段时间内如果它们没有收到Leader的心跳信号,follower就会转化为Candidate;

如果某个Candidate节点收到大多数节点的票,则这个Candidate就可以转化为Leader,其余的Candidate节点都会回到Follower状态;

一旦一个Leader发现系统中存在一个Leader节点比自己拥有更高的任期(Term),它就会转换为Follower。

Raft使用基于心跳的RPC机制来检测何时开始新的选举。 在正常期间, Leader 会定期向所有可用的 Follower 发送心跳消息(实际中可能把日志和心跳一起发过去)。 因此,其他节点以 Follower 状态启动,只要它从当前 Leader 那里收到周期性的心跳,就一直保持在 Follower 状态。

Follower 达到其超时时间时,它将通过以下方式启动选举程序:

根据 Candidate 从集群中其他节点收到的响应,可以得出选举的三个结果。

共识算法的实现一般是基于复制状态机(Replicated state machines),何为 复制状态机

简单来说: 相同的初识状态 + 相同的输入 = 相同的结束状态 。不同节点要以相同且确定性的函数来处理输入,而不要引入一下不确定的值,比如本地时间等。使用replicated log是一个很不错的注意,log具有持久化、保序的特点,是大多数分布式系统的基石。

有了Leader之后,客户端所有并发的请求可以在Leader这边形成一个有序的日志(状态)序列,以此来表示这些请求的先后处理顺序。Leader然后将自己的日志序列发送Follower,保持整个系统的全局一致性。注意并不是强一致性,而是 最终一致性

日志由有序编号(log index)的日志条目组成。每个日志条目包含它被创建时的任期号(term),和日志中包含的数据组成,日志包含的数据可以为任何类型,从简单类型到区块链的区块。每个日志条目可以用[ term, index, data]序列对表示,其中term表示任期, index表示索引号,data表示日志数据。

Leader 尝试在集群中的大多数节点上执行复制命令。 如果复制成功,则将命令提交给集群,并将响应发送回客户端。类似两阶段提交(2PC),不过与2PC的区别在于,leader只需要超过一半节点同意(处于工作状态)即可。

leader follower 都可能crash,那么 follower 维护的日志与 leader 相比可能出现以下情况

当出现了leader与follower不一致的情况,leader强制follower复制自己的log, Leader会从后往前试 ,每次AppendEntries失败后尝试前一个日志条目(递减nextIndex值), 直到成功找到每个Follower的日志一致位置点(基于上述的两条保证),然后向后逐条覆盖Followers在该位置之后的条目 。所以丢失的或者多出来的条目可能会持续多个任期。
 

要求候选人的日志至少与其他节点一样最新。如果不是,则跟随者节点将不投票给候选者。

意味着每个提交的条目都必须存在于这些服务器中的至少一个中。如果候选人的日志至少与该多数日志中的其他日志一样最新,则它将保存所有已提交的条目,避免了日志回滚事件的发生。

即任一任期内最多一个leader被选出。这一点非常重要,在一个复制集中任何时刻只能有一个leader。系统中同时有多余一个leader,被称之为脑裂(brain split),这是非常严重的问题,会导致数据的覆盖丢失。在raft中,两点保证了这个属性:

因此, 某一任期内一定只有一个leader
 

当集群中节点的状态发生变化(集群配置发生变化)时,系统容易受到系统故障。 因此,为防止这种情况,Raft使用了一种称为两阶段的方法来更改集群成员身份。 因此,在这种方法中,集群在实现新的成员身份配置之前首先更改为中间状态(称为联合共识)。 联合共识使系统即使在配置之间进行转换时也可用于响应客户端请求,它的主要目的是提升分布式系统的可用性。

C. 常见的共识算法介绍

在异步系统中,需要主机之间进行状态复制,以保证每个主机达成一致的状态共识。而在异步系统中,主机之间可能出现故障,因此需要在默认不可靠的异步网络中定义容错协议,以确保各个主机达到安全可靠的状态共识。

共识算法其实就是一组规则,设置一组条件,筛选出具有代表性的节点。在区块链系统中,存在很多这样的筛选方案,如在公有链中的POW、Pos、DPOS等,而在不需要货币体系的许可链或私有链中,绝对信任的节点、高效的需求是公有链共识算法不能提供的,对于这样的区块链,传统的一致性共识算法成为首选,如PBFT、PAXOS、RAFT等。

目录

一、BFT(拜占庭容错技术)

二、PBFT(实用拜占庭容错算法)

三、PAXOS

四、Raft

五、POW(工作量证明)

六、POS(权益证明)

七、DPOS(委任权益证明)

八、Ripple

拜占庭弄错技术是一类分布式计算领域的容错技术。拜占庭假设是由于硬件错误、网络拥塞或中断以及遭到恶意攻击的原因,计算机和网络出现不可预测的行为。拜占庭容错用来处理这种异常行为,并满足所要解决问题的规范。

拜占庭容错系统是一个拥有n台节点的系统,整个系统对于每一个请求,满足以下条件:

1)所有非拜占庭节点使用相同的输入信息,产生同样的结果;

2)如果输入的信息正确,那么所有非拜占庭节点必须接收这个信息,并计算相应的结果。

拜占庭系统普遍采用的假设条件包括:

1)拜占庭节点的行为可以是任意的,拜占庭节点之间可以共谋;

2)节点之间的错误是不相关的;

3)节点之间通过异步网络连接,网络中的消息可能丢失、乱序并延时到达,但大部分协议假设消息在有限的时间里能传达到目的地;

4)服务器之间传递的信息,第三方可以嗅探到,但是不能篡改、伪造信息的内容和验证信息的完整性。

拜占庭容错由于其理论上的可行性而缺乏实用性,另外还需要额外的时钟同步机制支持,算法的复杂度也是随节点的增加而指数级增加。

实用拜占庭容错降低了拜占庭协议的运行复杂度,从指数级别降低到多项式级别。

PBFT是一种状态机副本复制算法,即服务作为状态机进行建模,状态机在分布式系统的不同节点进行副本复制。PBFT要求共同维护一个状态。需要运行三类基本协议,包括一致性协议、检查点协议和视图更换协议。

一致性协议。一致性协议至少包含若干个阶段:请求(request)、序号分配(pre-prepare)和响应(reply),可能包含相互交互(prepare),序号确认(commit)等阶段。

PBFT通信模式中,每个客户端的请求需要经过5个阶段。由于客户端不能从服务器端获得任何服务器运行状态的信息,PBFT中主节点是否发生错误只能由服务器监测。如果服务器在一段时间内都不能完成客户端的请求,则会触发视图更换协议。

整个协议的基本过程如下:

1)客户端发送请求,激活主节点的服务操作。

2)当主节点接收请求后,启动三阶段的协议以向各从节点广播请求。

[2.1]序号分配阶段,主节点给请求赋值一个序列号n,广播序号分配消息和客户端的请求消息m,并将构造PRE-PREPARE消息给各从节点;

[2.2]交互阶段,从节点接收PRE-PREPARE消息,向其他服务节点广播PREPARE消息;

[2.3]序号确认阶段,各节点对视图内的请求和次序进行验证后,广播COMMIT消息,执行收到的客户端的请求并给客户端以响应。

3)客户端等待来自不同节点的响应,若有m+1个响应相同,则该响应即为运算的结果。

PBFT一般适合有对强一致性有要求的私有链和联盟链,例如,在IBM主导的区块链超级账本项目中,PBFT是一个可选的共识协议。在Hyperledger的Fabric项目中,共识模块被设计成可插拔的模块,支持像PBFT、Raft等共识算法。

在有些分布式场景下,其假设条件不需要考虑拜占庭故障,而只是处理一般的死机故障。在这种情况下,采用Paxos等协议会更加高效。。PAXOS是一种基于消息传递且具有高度容错特性的一致性算法。

PAXOS中有三类角色Proposer、Acceptor及Learner,主要交互过程在Proposer和Acceptor之间。算法流程分为两个阶段:

phase 1

a) proposer向网络内超过半数的acceptor发送prepare消息

b) acceptor正常情况下回复promise消息

phase 2

a) 在有足够多acceptor回复promise消息时,proposer发送accept消息

b) 正常情况下acceptor回复accepted消息

流程图如图所示:

PAXOS协议用于微信PaxosStore中,每分钟调用Paxos协议过程数十亿次量级。

Paxos是Lamport设计的保持分布式系统一致性的协议。但由于Paxos非常复杂,比较难以理解,因此后来出现了各种不同的实现和变种。Raft是由Stanford提出的一种更易理解的一致性算法,意在取代目前广为使用的Paxos算法。

Raft最初是一个用于管理复制日志的共识算法,它是在非拜占庭故障下达成共识的强一致协议。Raft实现共识过程如下:首先选举一个leader,leader从客户端接收记账请求、完成记账操作、生成区块,并复制到其他记账节点。leader有完全的管理记账权利,例如,leader能够决定是否接受新的交易记录项而无需考虑其他的记账节点,leader可能失效或与其他节点失去联系,这时,重新选出新的leader。

在Raft中,每个节点会处于以下三种状态中的一种:

(1)follower:所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态;

(2)candidate:会向其他结点“拉选票”,如果得到大部分的票则成为leader。这个过程就叫做Leader选举(Leader Election);

(3)leader:所有对系统的修改都会先经过leader。每个修改都会写一条日志(log entry)。leader收到修改请求后的过程如下:此过程叫做日志复制(Log Replication)

1)复制日志到所有follower结点

2)大部分结点响应时才提交日志

3)通知所有follower结点日志已提交

4)所有follower也提交日志

5)现在整个系统处于一致的状态

Raft阶段主要分为两个,首先是leader选举过程,然后在选举出来的leader基础上进行正常操作,比如日志复制、记账等。

(1)leader选举

当follower在选举时间内未收到leader的消息,则转换为candidate状态。在Raft系统中:

1)任何一个服务器都可以成为候选者candidate,只要它向其他服务器follower发出选举自己的请求。

2)如果其他服务器同意了,发出OK。如果在这个过程中,有一个follower宕机,没有收到请求选举的要求,此时候选者可以自己选自己,只要达到N/2+1的大多数票,候选人还是可以成为leader的。

3)这样这个候选者就成为了leader领导人,它可以向选民也就是follower发出指令,比如进行记账。

4)以后通过心跳消息进行记账的通知。

5)一旦这个leader崩溃了,那么follower中有一个成为候选者,并发出邀票选举。

6)follower同意后,其成为leader,继续承担记账等指导工作。

(2)日志复制

记账步骤如下所示:

1)假设leader已经选出,这时客户端发出增加一个日志的要求;

2)leader要求follower遵从他的指令,将这个新的日志内容追加到各自日志中;

3)大多数follower服务器将交易记录写入账本后,确认追加成功,发出确认成功信息;

4)在下一个心跳消息中,leader会通知所有follower更新确认的项目。

对于每个新的交易记录,重复上述过程。

在这一过程中,若发生网络通信故障,使得leader不能访问大多数follower了,那么leader只能正常更新它能访问的那些follower服务器。而大多数的服务器follower因为没有了leader,他们将重新选举一个候选者作为leader,然后这个leader作为代表与外界打交道,如果外界要求其添加新的交易记录,这个新的leader就按上述步骤通知大多数follower。当网络通信恢复,原先的leader就变成follower,在失联阶段,这个老leader的任何更新都不能算确认,必须全部回滚,接收新的leader的新的更新。

在去中心账本系统中,每个加入这个系统的节点都要保存一份完整的账本,但每个节点却不能同时记账,因为节点处于不同的环境,接收不同的信息,如果同时记账,必然导致账本的不一致。因此通过同时来决定那个节点拥有记账权。

在比特币系统中,大约每10分钟进行一轮算力竞赛,竞赛的胜利者,就获得一次记账的权力,并向其他节点同步新增账本信息。

PoW系统的主要特征是计算的不对称性。工作端要做一定难度的工作才能得出一个结果,而验证方却很容易通过结果来检查工作端是不是做了相应的工作。该工作量的要求是,在某个字符串后面连接一个称为nonce的整数值串,对连接后的字符串进行SHA256哈希运算,如果得到的哈希结果(以十六进制的形式表示)是以若干个0开头的,则验证通过。

比特币网络中任何一个节点,如果想生成一个新的区块并写入区块链,必须解出比特币网络出的PoW问题。关键的3个要素是 工作量证明函数、区块及难度值 。工作量证明函数是这道题的计算方法,区块决定了这道题的输入数据,难度值决定了这道题所需要的计算量。

(1)工作量证明函数就是<u style="box-sizing: border-box;"> SHA256 </u>

比特币的区块由区块头及该区块所包含的交易列表组成。拥有80字节固定长度的区块头,就是用于比特币工作量证明的输入字符串。

(2)难度的调整是在每个完整节点中独立自动发生的。每2016个区块,所有节点都会按统一的公式自动调整难度。如果区块产生的速率比10分钟快则增加难度,比10分钟慢则降低难度。

公式可以总结为:新难度值=旧难度值×(过去2016个区块花费时长/20160分钟)

工作量证明需要有一个目标值。比特币工作量证明的目标值(Target)的计算公式:目标值=最大目标值/难度值

其中最大目标值为一个恒定值:

目标值的大小与难度值成反比。比特币工作量证明的达成就是矿工计算出来的 区块哈希值必须小于目标值

(3)PoW能否解决拜占庭将军问题

比特币的PoW共识算法是一种概率性的拜占庭协议(Probabilistic BA)

当不诚实的算力小于网络总算力的50%时,同时挖矿难度比较高(在大约10分钟出一个区块情况下)比特币网络达到一致性的概念会随确认区块的数目增多而呈指数型增加。但当不诚实算力具一定规模,甚至不用接近50%的时候,比特币的共识算法并不能保证正确性,也就是,不能保证大多数的区块由诚实节点来提供。

比特币的共识算法不适合于私有链和联盟链。其原因首先是它是一个最终一致性共识算法,不是一个强一致性共识算法。第二个原因是其共识效率低。

扩展知识: 一致性

严格一致性,是在系统不发生任何故障,而且所有节点之间的通信无需任何时间这种理想的条件下,才能达到。这个时候整个系统就等价于一台机器了。在现实中,是不可能达到的。

强一致性,当分布式系统中更新操作完成之后,任何多个进程或线程,访问系统都会获得最新的值。

弱一致性,是指系统并不保证后续进程或线程的访问都会返回最新的更新的值。系统在数据成功写入之后,不承诺立即可以读到最新写入的值,也不会具体承诺多久读到。但是会尽可能保证在某个时间级别(秒级)之后。可以让数据达到一致性状态。

最终一致性是弱一致性的特定形式。系统保证在没有后续更新的前提下,系统最终返回上一次更新操作的值。也就是说,如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。

在股权证明PoS模式下,有一个名词叫币龄,每个币每天产生1币龄,比如你持有100个币,总共持有了30天,那么,此时你的币龄就为3000,这个时候,如果你发现了一个PoS区块,你的币龄就会被清空为0。你每被清空365币龄,你将会从区块中获得0.05个币的利息(假定利息可理解为年利率5%),那么在这个案例中,利息 = 3000 * 5% / 365 = 0.41个币,这下就很有意思了,持币有利息。

点点币(Peercoin)是首先采用权益证明的货币。,点点币的权益证明机制结合了随机化与币龄的概念,未使用至少30天的币可以参与竞争下一区块,越久和越大的币集有更大的可能去签名下一区块。一旦币的权益被用于签名一个区块,则币龄将清为零,这样必须等待至少30日才能签署另一区块。

PoS机制虽然考虑到了PoW的不足,但依据权益结余来选择,会导致首富账户的权力更大,有可能支配记账权。股份授权证明机制(Delegated Proof of Stake,DPoS)的出现正是基于解决PoW机制和PoS机制的这类不足。

比特股(Bitshare)是一类采用DPoS机制的密码货币。它的原理是,让每一个持有比特股的人进行投票,由此产生101位代表 , 我们可以将其理解为101个超级节点或者矿池,而这101个超级节点彼此的权利是完全相等的。如果代表不能履行他们的职责(当轮到他们时,没能生成区块),他们会被除名,网络会选出新的超级节点来取代他们。

比特股引入了见证人这个概念,见证人可以生成区块,每一个持有比特股的人都可以投票选举见证人。得到总同意票数中的前N个(N通常定义为101)候选者可以当选为见证人,当选见证人的个数(N)需满足:至少一半的参与投票者相信N已经充分地去中心化。

见证人的候选名单每个维护周期(1天)更新一次。见证人然后随机排列,每个见证人按序有2秒的权限时间生成区块,若见证人在给定的时间片不能生成区块,区块生成权限交给下一个时间片对应的见证人。

比特股还设计了另外一类竞选,代表竞选。选出的代表拥有提出改变网络参数的特权,包括交易费用、区块大小、见证人费用和区块区间。若大多数代表同意所提出的改变,持股人有两周的审查期,这期间可以罢免代表并废止所提出的改变。这一设计确保代表技术上没有直接修改参数的权利以及所有的网络参数的改变最终需得到持股人的同意。

Ripple(瑞波)是一种基于互联网的开源支付协议,在Ripple的网络中,交易由客户端(应用)发起,经过追踪节点(tracking node)或验证节点(validating node)把交易广播到整个网络中。

追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外,还能够通过共识协议,在账本中增加新的账本实例数据。

Ripple的共识达成发生在验证节点之间,每个验证节点都预先配置了一份可信任节点名单,称为UNL(Unique Node List)。在名单上的节点可对交易达成进行投票。每隔几秒,Ripple网络将进行如下共识过程:

1)每个验证节点会不断收到从网络发送过来的交易,通过与本地账本数据验证后,不合法的交易直接丢弃,合法的交易将汇总成交易候选集(candidate set)。交易候选集里面还包括之前共识过程无法确认而遗留下来的交易。

2)每个验证节点把自己的交易候选集作为提案发送给其他验证节点。

3)验证节点在收到其他节点发来的提案后,如果不是来自UNL上的节点,则忽略该提案;如果是来自UNL上的节点,就会对比提案中的交易和本地的交易候选集,如果有相同的交易,该交易就获得一票。在一定时间内,当交易获得超过50%的票数时,则该交易进入下一轮。没有超过50%的交易,将留待下一次共识过程去确认。

4)验证节点把超过50%票数的交易作为提案发给其他节点,同时提高所需票数的阈值到60%,重复步骤3)、步骤4),直到阈值达到80%。

5)验证节点把经过80%UNL节点确认的交易正式写入本地的账本数据中,称为最后关闭账本(Last Closed Ledger),即账本最后(最新)的状态。

在Ripple的共识算法中,参与投票节点的身份是事先知道的。该共识算法只适合于权限链(Permissioned chain)的场景。Ripple共识算法的拜占庭容错(BFT)能力为(n-1)/5,即可以容忍整个网络中20%的节点出现拜占庭错误而不影响正确的共识。

在区块链网络中,由于应用场景的不同,所设计的目标各异,不同的区块链系统采用了不同的共识算法。一般来说,在私有链和联盟链情况下,对一致性、正确性有很强的要求。一般来说要采用强一致性的共识算法。而在公有链情况下,对一致性和正确性通常没法做到百分之百,通常采用最终一致性(Eventual Consistency)的共识算法。

共识算法的选择与应用场景高度相关,可信环境使用paxos 或者raft,带许可的联盟可使用pbft ,非许可链可以是pow,pos,ripple共识等,根据对手方信任度分级,自由选择共识机制。

阅读全文

与pbft共识算法原理相关的资料

热点内容
pdf转换成word免费版在线转换 浏览:462
荒废了三年还能做程序员吗 浏览:656
阿里云内网vpn服务器 浏览:101
l命令第一个点对第二个点对不上 浏览:829
oracle导出表命令 浏览:909
怎么写域名加密 浏览:1003
手机文件压缩出错 浏览:522
如何登录毒app 浏览:836
汽车中控台加密 浏览:862
海南农村信用社app如何开通短信 浏览:809
phpdns缓存 浏览:415
ipad腾讯视频app如何播放本地视频 浏览:990
虾米服务器关闭如何找到以前的歌 浏览:18
php自动建站 浏览:475
命令与征服3游侠网 浏览:970
腾讯云买哪个地区服务器 浏览:250
香港哪里有app卖内地零食 浏览:684
编译内核找不到工具链 浏览:453
java常见模式 浏览:504
典欣空调压缩机 浏览:426