fabric 共识模式深度解析

1 背景

当前大家对fabric的共识算法的观点，普遍都认为是kafka，而kafka是主从模式，所以不能防止作恶。针对这个观点，详细解析fabric的共识模式。

2 fabric共识

fabric共识模式采用的 Endorse+Kafka+Commit 的模式，这里我们简称EKC共识。此共识包含以下几个步骤：

1. 请求背书：
   客户端用自己的私钥对交易进行签名后，按照指定格式将交易和签名信息进行打包，然后将打包后的数据发给背书节点请求背书。

2. 验证背书：
   背书节点收到背书请求后，验证交易的签名是否正确并调用智能合约验证交易内容是否合法。验证通过的话，背书节点用自己的私钥对背书结果进行签名并按照指定格式打包，然后将打包后的数据发给客户端。

3. 提交交易：
   客户端收到背书结果后，验证背书结果的签名是否正确。验证通过后，对交易请求和背书结果签名并打包。然后，把打包后的数据发送给orderer节点提交交易。

4. 排序广播：
   orderer节点收到交易后，验证数据的客户端签名[bJ1] 是否正确。验证通过后，将交易发给kafka集群对应的topic。由于orderer中的对于每个通道都在kafka上监听对应的消息，因此，kafka将消息存放到对应topic上之后，会将消息广播给通道上的所有orderer。因为各个orderer的消息都是由kafka按照相同顺序发送的，因此，这个过程也实现了消息的排序。

5. 打包出块：
   orderer节点接收到从kafka推送的消息（kafka节点见同步消息不需要验证），当满足出块策略[bJ2] ：缓存交易个数达到区块最大交易数或者时间达到出快时间，则将交易进行打包、对数据签名，然后出块，并将区块分发给peer节点。

6. 验证记账：
   peer节点接收到区块后，验证交易是否有效即验证区块的交易是否满足背书策略以及区块中交易的读写集版本是否正确[bJ3] 。验证通过的话，执行此交易的内容更改状态数据库。验证失败的话，对此条交易不做任何处理。当区块中的交易全部处理完成后，将区块记录在本地数据库。

3 交互流程图

flow1.png

4 数据流程图

flow2.png