Fabric v1.x Orderer的共识算法

Fabric Orderer的共识算法是可插拔的，包括Solo、Kafka、Raft，其中Raft算法是在Fabric v1.4版本中新增的，未来还将加入BFT算法。本文会对已实现的3个共识算法进行剖析。

一、Solo

Solo算法中只有一个orderer节点，用于开发阶段的实验。一个Orderer节点不存在共识的问题，该节点接收所有来自客户端的交易，然后将其排序并产生区块，如下图所示：

二、Kafka

所有的orderer都会连接kafka集群，而orderer之间并没有直接的连接，如下图所示：

所有trasaction的排序依赖于kafka，kafka的partition里面的数据均是按时间进行排序的，因此可以帮助Orderer集群进行排序。

那么基于kafka排序，是如何做到orderer集群上的所有节点都产生相同区块的？

• 以交易数量分割区块是容易的，对任意的OSN来说，都会得到相同的区块。
• 但是基于时间分割区块，各个节点的时间是有偏差的，所以需要各个节点间明确的协调信号。

基于时间分割区块的分析如下：
1、一个channel对应kafka中的一个topic，topic里面使用单partition；
2、每个OSN在分割区块之前都向Partition发出消息（是时候分割区块X啦 TTC-X），直到接收到任意TTC-X消息进行分割区块，不一定是自己发出的TTC-X消息，而是第一个TTC-X，其他的TTC-X会被忽略；
3、每个OSN在本地保存每个channel的区块文件。Delivery请求现在只需要顺序地读取本地ledger，没有冗余数据，也没有lookup表。OSN只需要保存最后读取的偏移量，这样在重联之后就可以知道从哪里开始重新消费Kafka的消息；
4、OSN返回的delivery响应包含orderer的签名。

kafka共识的整体框架：
kafka共识的整体框架图如下，OSN0和OSN2从client接收交易，然后发送到kafka集群，kafka将3个交易进行排序，然后发送到所有OSN，OSN根据出块规则将交易打包成区块，然后将区块发送给peer节点。

config sequence机制：
如果修改配置让某一类transaction不再接收，设定其为非法交易。这时需要提交一个config交易，要经过kafka共识，但是config交易和普通交易是被异步发送给kafka集群的，所以不能保证config交易赶在非法的普通交易之前被共识。
从kafka接收到config交易后，要对刚才异步过程中的普通交易进行重新校验，过滤掉非法交易，防止漏判，所以需要用到config sequence机制。
所有transaction都有基于是config的sequence，当修改了config，sequence就会增加1，当收到transaction，发现不是基于最新的sequence，这些transaction就需要重新验证，并且重新发送给kafka进行共识，以防在新config下本应是非法的交易被提交到账本里。

三、Raft

Fabric orderer的Raft共识基于Etcd/raft库，进一步封装实现了出块逻辑。

使用Raft取代kafka共识的原因：

• Raft共识与kafka并没有本质的区别，但是不再需要依赖Kafka/Zookeeper了，kafka共识最少需要部署4个kafka节点和3个zookeeper节点，架构不够简洁，另外kafka的运维本身也比较复杂。实现Raft共识极大地简化了运维工作。
• 基于Kafka共识，使得orderer之间没有通信，做raft就会实现orderer的通讯层，以后做BFT这也是必须的，为以后新共识算法做基础，通讯层的实现也使得共识模块的可插拔更加可用

Raft共识的实现：

• 每个channel都会运行自己的Raft实例，任何一个channel都是在所有orderer的子集里进行运行，比如某个channel只有三个组织需要参与共识，那么可以只把这三个组织的orderer加入到该channel里，不需要其他orderer参与通讯；
• 所有的orderers都必须属于system channel，否则新创建一个user channel，如果一个orderer不在system channel里，就没法拿到带有“New channel”transaction的block，也就没法知道有新的channel被创建，下图中展现了system channel中各个orderer节点的通讯关系；
• orderer节点间通过TLS cert进行身份识别，配置channel时，会定义这个channel里会有哪些orderer节点，所以需要TLS cert来实现身份认证。

Fabric v1.4.2开发了Kafka迁移到Raft的工具（kafka开发工作较少，所以之前用的kafka，将来会主推Raft，直到BFT出来为止）

四、总结

• Kafka对transaction进行共识：
  把transaction发送给kafka，从kafka获取的是全排序后的transacton，然后由orderer节点自己切割区块。
• Raft则是对block进行共识：
  follower拿到transaction后转发给leader，先由leader打包成块，然后把区块发送给follower进行共识。这与大部分区块链项目一致。