FISCO BCOS的PBFT共识算法流程详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了FISCO BCOS的PBFT共识算法流程详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

原文： https://fisco-bcos-doc.readthedocs.io/zh_CN/latest/docs/design/consensus/pbft.html

PBFT模块主要包括PrepareReq、SignReq、CommitReq和ViewChangeReq四种共识消息：

PrepareReqPacket: 包含区块的请求包，由leader产生并向所有Replica节点广播，Replica节点收到Prepare包后，验证PrepareReq签名、执行区块并缓存区块执行结果，达到防止拜占庭节点作恶、保证区块执行结果的最终确定性的目的；
SignReqPacket: 带有区块执行结果的签名请求，由收到Prepare包并执行完区块的共识节点产生，SignReq请求带有执行后区块的hash以及该hash的签名，分别记为SignReq.block_hash和SignReq.sig，节点将SignReq广播到所有其他共识节点后，其他节点对SignReq(即区块执行结果)进行共识；
CommitReqPacket: 用于确认区块执行结果的提交请求，由收集满(2f+1)个block_hash相同且来自不同节点SignReq请求的节点产生，CommitReq被广播给所有其他共识节点，其他节点收集满(2f+1)个block_hash相同、来自不同节点的CommitReq后，将本地节点缓存的最新区块上链；
ViewChangeReqPacket: 视图切换请求，当leader无法提供正常服务(如网络连接不正常、服务器宕机等)时, 其他共识节点会主动触发视图切换，ViewChangeReq中带有该节点即将切换到的视图(记为toView，为当前视图加一)，某节点收集满(2*f+1)个视图等于toView、来自不同节点的ViewChangeReq后，会将当前视图切换为toView。

视图切换（viewchange）：

pbft共识过程,区块链,共识算法,区块链,PBFT,FISCO BCOS

系统架构：

pbft共识过程,区块链,共识算法,区块链,PBFT,FISCO BCOS

三阶段共识：

pbft共识过程,区块链,共识算法,区块链,PBFT,FISCO BCOS

PBFT各个阶段的具体流程：
pbft共识过程,区块链,共识算法,区块链,PBFT,FISCO BCOS

共识节点收到Prepare包后，进入pre-prepare阶段，此阶段的主要工作流程包括：

Prepare包合法性判断：主要判断是否是重复的Prepare包、Prepare请求中包含的区块父哈希是否是当前节点最高块哈希(防止分叉)、Prepare请求中包含区块的块高是否等于最高块高加一；
缓存合法的Prepare包: 若Prepare请求合法，则将其缓存到本地，用于过滤重复的Prepare请求；
空块判断：若Prepare请求包含的区块中交易数目是0，则触发空块视图切换，将当前视图加一，并向所有其他节点广播视图切换请求；
执行区块并缓存区块执行结果: 若Prepare请求包含的区块中交易数目大于0，则调用BlockVerifier区块执行器执行区块，并缓存执行后的区块；
产生并广播签名包：基于执行后的区块哈希，产生并广播签名包，表明本节点已经完成区块执行和验证。

共识节点收到签名包后，进入Prepare阶段，此阶段的主要工作流程包括：

签名包合法性判断：主要判断签名包的哈希与pre-prepare阶段缓存的执行后的区块哈希相同，若不相同，则继续判断该请求是否属于未来块签名请求(产生未来块的原因是本节点处理性能低于其他节点，还在进行上一轮共识，判断未来块的条件是：签名包的height字段大于本地最高块高加一)，若请求也非未来块，则是非法的签名请求，节点直接拒绝该签名请求；
缓存合法的签名包：节点会缓存合法的签名包；
判断pre-prepare阶段缓存的区块对应的签名包缓存是否达到2f+1，若收集满签名包，广播Commit包：若pre-prepare阶段缓存的区块哈希对应的签名包数目超过2f+1，则说明大多数节点均执行了该区块，并且执行结果一致，说明本节点已经达到可以提交区块的状态，开始广播Commit包；
若收集满签名包，备份pre-prepare阶段缓存的Prepare包落盘：为了防止Commit阶段区块未提交到数据库之前超过2*f+1个节点宕机，这些节点启动后重新出块，导致区块链分叉(剩余的节点最新区块与这些节点最高区块不同)，还需要备份pre-prepare阶段缓存的Prepare包到数据库，节点重启后，优先处理备份的Prepare包。

共识节点收到Commit包后，进入Commit阶段，此阶段工作流程包括：

Commit包合法性判断：主要判断Commit包的哈希与pre-prepare阶段缓存的执行后的区块哈希相同，若不相同，则继续判断该请求是否属于未来块Commit请求(产生未来块的原因是本节点处理性能低于其他节点，还在进行上一轮共识，判断未来块的条件是：Commit的height字段大于本地最高块高加一)，若请求也非未来块，则是非法的Commit请求，节点直接拒绝该请求；
缓存合法的Commit包：节点缓存合法的Commit包；
判断pre-prepare阶段缓存的区块对应的Commit包缓存是否达到2f+1，若收集满Commit包，则将新区块落盘：若pre-prepare阶段缓存的区块哈希对应的Commit请求数目超过2f+1，则说明大多数节点达到了可提交该区块状态，且执行结果一致，则调用BlockChain模块将pre-prepare阶段缓存的区块写入数据库；

当PBFT三阶段共识超时或节点收到空块时，PBFTEngine会试图切换到更高的视图(将要切换到的视图toView加一)，并触发ViewChange处理流程；节点收到ViewChange包时，也会触发ViewChange处理流程：

判断ViewChange包是否有效: 有效的ViewChange请求中带有的块高值必须不小于当前节点最高块高，视图必须大于当前节点视图；
缓存有效ViewChange包：防止相同的ViewChange请求被处理多次，也作为判断节点是否可以切换视图的统计依据；
收集ViewChange包：若收到的ViewChange包中附带的view等于本节点的即将切换到的视图toView且本节点收集满2*f+1来自不同节点view等于toView的ViewChange包，则说明超过三分之二的节点要切换到toView视图，切换当前视图到toView。

在prepare阶段和commit阶段，需要收集超过2f+1个消息，是否包含本身的消息？例如4个节点，有1个节点是拜占庭，那么最多只能收集3个消息（包含节点本身的1条）
pre-prepare阶段为什么需要判断空块？不能有空块？
收到“未来块”会如何处理？
关于消息转发流程优化，如何在起始阶段判断需要转发的节点数量？文章来源地址https://www.toymoban.com/news/detail-786782.html