为什么会选用Kafka
共识机制要求能够满足两种范围的容错：
- 崩溃故障容错（Crash Fault-Tolerance,CFT）:在区块链网络中存在网络延时或者故障的情况下，能够保障交易的最终一致性。
- 拜占庭容错（Byzantine Fault-Tolerance,BFT）：在区块链网络中存在部分恶意节点提交或者篡改求情的情况下，能够保障有效的交易的最终一致性。
基于上面的要求，一般有这样两类共识算法：
-
POW、POS
先记账再共识，交易会形成大概率的一致性共识。 -
BFT、Paxos、ZAB
先共识再记账，交易会形成绝对一致的共识，但是这种算法的缺点是需要更长的时间形成共识，不能满足高吞吐量和低延迟的场景要求（个人猜测：为什么Fabric现在也没有使用PBFT也就是效率问题吧。另外Zookeeper使用zab也导致了其性能是有限的。）
我认为Fabric转而求其次使用Kafka，也是相对其核心功能和先前BFT低下效率的一种妥协。尽管Kafka是基于Zookeeper的，但是Kafka只是使用Zk的共识机制来管理集群节点，所以效率上是没有问题的。而严格意义上来说，Kafka并不是共识机制，只是一种发布与订阅的消息系统，其核心功能就是保障消息的有序和最终一致性。
共识过程需要提供以下核心功能：
- 交易有序：能够确保所有节点提交和执行交易的顺序一致性，这才能保证执行结果的一致性和全局状态的一致性。
- 交易有效：能够根据背书及共识策略保障区块中的交易有效。
- 交易验证：能够利用智能合约的接口，验证交易的有效性和提交顺序。
fabric1.0与0.6相比改动较大，解决了不少痛点问题：
- 动态增加节点功能
- 分链结构，容易实现spv
- 策略管理（过滤器）机制，增加权限控制。
- 提高高可用性，增加kafka集群。
- 支持合约升级，有利于后期维护。
- 将ca功能拆分，ca证书分发的过程可以单独处理。
- 模块分割，结构清晰，各模块分工明确。
Hyperledger Fabric 1.0共识机制
再次解释这张图：
- 交易背书
应用程序根据背书策略的要求选择Endorse节点，给这些节点发送需要执行的交易提案（Proposal）。Endorse节点调用链码（Chaincode）执行这些交易提案，交易过程是模拟执行的。模拟执行完成后，交易背书系统链码ESCC对模拟执行的结果进行签名背书。 - 交易排序
Orderer节点接受已经签名背书的交易，确定交易的顺序和数量，将排好序的交易打包到区块中，通过Leader节点广播给Committer节点进行验证。 - 交易验证
Committer节点接收并验证区块里包含的交易的有效性：包括背书策略验证和双花检测。交易背书和交易验证都由链码来实现。