一、前言
目的：在fisco-bcos（v2.8.0）环境下，测试黑名单对节点共识的影响。
部署搭建四节点的链，并部署console：
https://fisco-bcos-documentation.readthedocs.io/zh_CN/release-2.8.0/docs/installation.html
getPeers获取某节点所连接的p2p连接列表。
getSealerList获取共识节点列表。
CA黑名单介绍：
配置CA黑名单：
二、测试过程
通过console每次连接一个节点nodeX，依次通过该nodeX节点的黑名单功能逐个添加其他某个节点，达到逐个断开p2p网络连接的目的，直到节点nodeX在console上无法发送交易，再切换到下一个节点。
具体地，以下过程将从node0开始，console只连node0，逐渐在node0的黑名单中逐个配置node3、node2、node1，node0的黑名单配置到node1时，node0彻底与其他节点彼此断开p2p连接；这时console不再连接node0，而手动切换到node1，对node1节点的黑名单做重复的操作，直到最终console连接每个节点都无法形成共识，无法发送交易。
四节点环境下，
- 最开始，不配任何黑名单。console连到node0，可以成功发交易；所有节点日志均持续打印“
[CONSENSUS][SEALER]++++++++++++++++ Generating seal on,blkNum=28”共识日志；getPeers结果是3个；sealerList是node0-node3。 - 接下来，给node0黑名单中配node3，重启node0。console连到node0，可以成功发交易；所有节点日志均持续打印共识日志；getPeers结果是2个；sealerList是node0-node3。
- 接着，继续给node0黑名单中再配node2，重启node0。console连到node0，可以成功发交易；所有节点日志均持续打印共识日志；getPeers结果是1个；sealerList是node0-node3。
- 继续，给node0黑名单中再配node1，重启node0。（1）console连到node0，发交易超时；node0不再打印共识日志，其他节点接着打印之前的共识日志；getPeers结果是空；sealerList是node0-node3。（2）console连到node1，可以成功发交易。
- 继续，给node1黑名单中再配node2，重启node1。console连到node1，可以成功发交易；node1-node3均持续打印共识日志；getPeers结果是1个；sealerList是node0-node3。
- 继续，给node1黑名单中再配node3，重启node1。（1）console连到node1，发交易超时；所有节点均不再打印共识日志；getPeers结果是空；sealerList仍是node0-node3。（2）console连到node2，发交易超时。此时不满足pbft共识要求，整体共识故障。
初步结论：
- 根据上面步骤初步分析，黑名单控制的p2p连接，不影响getSealerList的结果（除非主动调用consensus指令），但可能会影响整体共识条件，最终导致共识不可用。
- 4挂1时，正常运行的三个节点之间，不一定需要两两互联（如上面第5幅图），也可以成功发交易。
- 当最终的节点p2p连接环境，不满足pbft共识条件，则整体集群共识挂掉。
三、PBFT
PBFT（Practical Byzantine Fault Tolerance）实用的拜占庭容错系统。
相比拜占庭容错，运行复杂度从指数级降低到了多项式级别，使拜占庭协议在分布式系统中应用成为可能。
PBFT适合需要节点准入机制的私有链或联盟链，不适合公有链，因为PBFT不能防止女巫攻击。女巫攻击大概是一个恶意用户可以创建足够多的账户，比如达到51%的意思，来影响全局的共识。
PBFT中，总节点数为3f+1时，有效节点数要不小于2f+1，才可以形成共识。也就是说，允许出错的节点数最多为f。比如，像上面四节点的例子，3f+1=4，计算出容错数f=1，那么p2p网络中允许断开连接的节点数最多为1个，正常节点数不能少于2f+1=3个。所以第6幅图中仅剩2个节点有p2p连接，是无论如何也不能够形成共识的。
. ...- . .-. -.-- - .... .. -. --. .-- .. .-.. .-.. -... . --- -.-