共识算法¶
FISCO BCOS多群组架构中，不同群组可运行不同的共识算法，组与组之间的共识互不影响。FISCO BCOS目前支持PBFT、 Raft和rPBFT3种共识算法。
- PBFT：BFT类共识算法，可容忍不超过三分之一的故障节点和作恶节点，可达到最终一致性。
- Raft：CFT类算法, 可容忍一半故障节点，不能防止节点作恶，可达到一致性。
- rPBFT：旨在保留BFT类共识算法高性能、高吞吐量、高一致性、安全性的同时，尽量减少节点规模对共识算法的影响。
可以从以下四方面验证共识算法相关特性：
交易类型¶
系统类交易（诸如权限、CNS、节点管理、群组管理等系统类操作）、业务侧交易（应用侧为实现某种功能编写的合约等交易）均能共识。
3种共识算法¶
PBFT¶
PBFT可以在少数节点作恶(如伪造消息)场景中达成共识，它采用签名、签名验证、哈希等密码学算法确保消息传递过程中的防篡改性、防伪造性、不可抵赖性。
（1）配置文件相关配置测试。
（2）leader节点：
- 实时压测、交易池内堆积的历史交易，各个共识节点轮流作为leader节点。
- 多个客户端同时发送交易到同一群组内的相同/不同直连节点，各个共识节点轮流作为leader。
- 观察节点不参与打包，会同步区块，观察/游离节点不影响共识节点轮流作为leader。
- 频繁入网、退网，该节点断断续续作为leader。
- 网络单向连通，各节点轮流作为leader。
- 部分节点网络不通但非网络孤岛，如4节点环境，D节点仅跟A节点网络连通，各节点轮流作为leader。
- 某共识节点异常，剩余正常节点中，其中一个节点被轮询2次作为leader节点。
（3）签名、落盘：
- 正常共识，各类存储模式，落盘成功。
- 超过1000ms新区块打包交易数仍为0，空块不落盘。
- 未收集到2f+1个SignMsg。
- 未收集到2f+1个CommitMsg。
（4）视图共识：
- 无业务进来时，空块不落盘，触发视图切换。
- 新节点入网、老节点退网入网，触发视图切换。
- 因网络问题，其他节点在规定时间内未收到某节点打包的区块，触发视图切换。
- leader节点故障（如进程停止、服务器宕掉、退网、正在数据同步等），触发视图切换，产生新的leader。
Raft¶
在Raft算法中，每个网络节点只能如下三种身份之一：
- Leader：负责与外界交互，由Follower节点选举而来，在每一次共识过程中有且仅有一个Leader节点，由Leader全权负责从交易池中取出交易、打包交易组成区块并将区块上链。
- Follower：以Leader节点为准进行同步，并在Leader节点失效时选出新的Leader节点。
- Candidate：是Follower节点在竞选Leader时拥有的临时身份。
（1）配置文件相关配置测试，如[consensus].broadcast_prepare_by_tree等。
（2）压测时，leader节点正常，一直由该节点作为leader，其他节点以leader为准进行同步。
（3）客户端连接leader节点，交易正常处理。
（4）客户端连接非leader节点，节点收到客户端交易后转发给其他节点，交易正常处理。
（5）停止leader节点，选举产生新leader。
（6）leader进程暂停，选举产生新leader。
（7）leader节点网络孤岛，选举产生新leader。
（8）新节点入网、旧节点退网等操作，选举产生新leader。
（9）选举leader时，先到先得（即先收到majority投票的节点，赢得选举，成为新leader，可通过网络延迟模拟）。
rPBFT¶
rPBFT算法类似于部分节点范围内的PBFT算法，每轮共识流程仅选取若干个节点（epoch_sealer_num参数控制）执行PBFT共识流程出块，并根据区块高度（epoch_block_num参数控制）周期性地替换共识节点、保障系统安全。包括共识节点、验证节点两种节点类型。
（1）配置文件相关参数测试。
（2）epoch_sealer_num = 节点总数
每个周期内所有节点均参与共识，无需进行共识节点替换。日志中会有类似No need to rotateWorkingSealer for all the sealers are working sealers,workingSealerNum=7,pendingSealerNum=0信息。
（3）epoch_sealer_num < 节点总数
- epoch_sealer_num个共识节点轮流出块。
- 每出epoch_block_num个块后，替换一个共识节点。可在日志种搜索rotateWorkingSealer,number= 查看是否根据epoch_block_num参数周期性替换共识节点。
- 根据calNodeRotatingInfo、remove workingSealer、insert workingSealer日志查看具体替换的节点是否符合对应替换算法的逻辑。
- 根据updateConsensusNodeList关键字查看替换后的共识节点列表。
（4）epoch_sealer_num小于节点总数时，控制台getSealerList的返回结果包括链上所有的共识节点，不仅仅是epoch_sealer_num范围内的。
（5）周期性替换共识节点时，不会校验即将加入共识列表的验证节点是否异常，直接根据替换算法移除一个节点、加入一个节点。
（6）若验证节点部分异常，替换时加入了异常的验证节点到共识列表，链上如果满足3f+1原则，能正常处理交易，反之不满足，链会异常。
（7）共识节点替换时，观察节点、游离节点不会被加入到共识列表中去。
（8）观察节点、游离节点被成功addSealer后，能被替换到共识列表中去。
（9）压测过程中，频繁入网、退网操作。
（10）rPBFT算法下，新节点入网、观察节点、故障节点恢复后，对应节点的数据能成功同步。
容错¶
不同共识算法容错的节点个数不相同，若因故障节点过多导致链异常，当恢复部分节点满足容错规则后，链应能自动恢复。
PBFT¶
在一个由(3f+1)个节点构成的系统中，只要有(2f+1)个非恶意节点正常工作，该系统就能达成一致性。
- 3节点环境，1个节点异常，链异常
- 4节点环境，若1个节点异常，链能正常工作。若2个节点异常，链异常
- 7节点环境，若2个节点异常，链能正常工作。若3个节点异常，链异常
- 拜占庭容错
Raft¶
在一个由f个节点构成的系统中有(f+1)/2（向上取整）个节点正常工作的情况下的系统的一致性。
- 3节点环境，若1个节点异常，链正常。若2个节点异常，链异常
- 4节点环境，若1个节点异常，链能正常工作。若2个节点异常，链异常
- 5节点环境，若2个节点异常，链能正常工作。若3个节点异常，链异常
- 7节点环境，若3个节点异常，链能正常工作。若4个节点异常，链异常
rPBFT¶
同PBFT算法容错原则，区别是rPBFT算法仅针对epoch_sealer_num范围内的节点。
多群组混合共识算法¶
多群组架构中，各个群组的共识算法互不干扰（各群组既可以采用相同共识算法，又可以采用不同共识算法）。