hyperledger fabric各类节点及其故障分析

1.Client节点

client代表由最终用户操作的实体，它必须连接到某一个peer节点或者orderer节点上与区块链网络通信。客户端向endorser提交交易提案，当收集到足够背书后，向排序服务广播交易，进行排序，生成区块。但是该节点的故障不会影响区块链网络的正常运行。

2.CA节点

CA节点是hyperledger 1.0的证书颁发机构，由服务器（fabric-ca-service）和客户端组件（fabric-ca-client）组成。CA节点接收客户端的注册申请，返回注册密码用于用户登入，以便获取身份证书，在区块链网络上所有的操作都会验证用户的身份。因此该节点的故障只会影响到用户的注册申请。

3.Orderer节点

orderer负责接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给peer节点。排序服务可以采用集中式服务（solo，不适合实际生产环境），也可以采用分布式协议（目前正是发布的版本只支持Apache Kafka集群，只能实现崩溃故障容错）。BFT（拜占庭容错）的排序服务会在1.x周期内发布。我们也可以为fabric写一个共识实现，一个共识插件需要实现consensus package中定义的Consenter和Chain接口，我们可以来研究已经针对这些接口构建的plugin（solo和kafka）为自己提供线索。

我们分析下现有的基于kafka的排序服务安全性。

首先不用担心排序服务里插入数据带来的安全问题，因为最终记账还需要经过多重检查，比如消息类型的检查和签名验证、记账节点对背书策略的验证和交易内容的验证。但是其他的恶意节点攻击的问题还是无法避免的，比如拒绝服务（丢掉交易）。

kafka集群至少要四个节点，可以保证在1一个节点宕机后还能继续提交交易和排序，并且创建新的通道。zookeeper节点数选择3、5、7都可以。奇数个节点可以避免脑裂，1个节点会存在单点问题，7个以上就太多了。

值得一提的是，官方的example的在kafka集群和orderer之间都是没有安全传输的，切不可直接投入生产环境。我们可以通过使用openssl为kafka集群生成秘钥，增加orderer和kafka的配置以使用基于TLS的安全传输。

4.Peer节点

首先所有的peer节点都是committer（记账节点），而又有可能担任的角色有endorser（背书节点）、Leader（主节点）、Anchor（锚节点）。

Committer

记账节点使用基于Gossip的p2p数据分发，节点会定期跟其他节点交换信息。如果在这个过程中有节点发生故障，则会从存活的节点中删除这个节点的信息。对于故障节点，还会定时检查是否已经恢复，恢复存活的节点会更新到存活节点列表中。如果有新加入的节点，也能通过节点信息的交换获取到，添加到存活列表中，广播给其他节点。由于超级账本采用基于反熵的状态同步，每个节点周期性的和邻居节点交换保存的数据，然后对比本地数据和邻居节点所保存的数据，检查是否有缺失或者过期的数据，然后更新本地节点的数据为最新的数据，因此故障的节点重新连接到网络时会自动恢复数据。这些都能通过Gossip协议学习到，自动调整网络的拓扑结构，适应网络节点的变化，保证整个网络正常运行。并且协议能正确工作的概率不会因为错误数超过f（可靠的广播协议中存在一个f，错误数超过这个值就会出现异常，协议的可靠性等于不超过f个错误的概率）时就快速地降低。（优雅降级）

Leader

主节点连接到排序服务，负责把接受到的批量区块转发给其他节点。因此主节点与排序服务的稳定连接至关重要。可以强制设置为主节点，也可以动态选举产生。主节点选举的用处是，判断在相同的组织中哪个节点可以作为代表连接排序服务。选举过程在Gossip层实现，一个节点启动的时候它先等网络稳定再开始参与主节点选举，一次主节点选举的有效时间是10s。这样可以有效避免强制设置主节点出现的发生故障无法分发区块的问题。

Endorser

背书节点为动态的角色与具体的chaincode绑定，背书节点的故障对网络的影响取决于chaincode对应的背书策略，例如背书策略指定只要3个组织其中的2个组织的成员完成背书，该交易就是有效的，那么只有一个组织的成员节点出现故障对交易完成没有影响。

Anchor

锚节点是在一个channel上可以被所有其他peer发现的peer，channel上的每个成员都有一个anchor Peer(或多个anchor peer 来防止单点故障)，允许属于不同成员的peer发现channel上的所有现有peer。锚节点的配置文件可以通过configtxgen工具生成。