目录
一、概述
Fabric中提供了Orderer排序节点，作为区块链网络的一种共识机制，提供对交易进行排序的服务。目前，Fabric已发布的版本中提供了一种基于崩溃容错（Crash Fault-Tolerant, CFT）等排序机制。这种机制是通过Kafka实现的，后续版本中会提供基于Raft共识的排序机制。本文不具体关注Orderer的实现机制，而是从整体了解一下Fabric的共识流程。
在讨论Fabric的共识流程前，首先需要对Fabric的交易流程有一定的了解。Fabric中简化的交易流程如下图所示：
具体的描述可以参考Fabric官方文档： Peers
在Fabric中，交易可以分为两类，一类是查询交易，用于账本查询，不更新账本数据；另一类是更新交易，用于修改账本中的数据。很显然，查询交易只需要单个Peer参与即可，不需要进行排序共识的，而更新交易（下文简称交易）需要通常需要多个Peer参与（同一Channel中），在这种情况下，排序共识就会起到作用。
二、共识流程
交易的共识包括3个阶段的处理：提议阶段、打包阶段和验证阶段，下面结合交易流程，分别介绍各个阶段。
（一）提议阶段
提议阶段我们可以理解为背书阶段，这一阶段可以分为三个步骤，如下：
1. 用户通过Application（封装了Fabric SDK的客户端应用程序）构造出交易提议，交易提议中包含欲执行的Chaincode和函数名，背书节点列表（与具体的Chaincode背书策略有关，包含在同一个Channel中）等数据，并将交易提议发送至相应的Peer。
2. 各背书节点接收到交易提议后，首先进行一些检查和签名的验证，然后独立地模拟执行指定的Chaincode函数（不将执行结果写入本地账本），生成一个提议结果，并对结果进行背书，即在结果中添加数字签名并利用私钥对结果进行签名。
3. 将提议结果返回至Application。
当Application收集到足够多的提议结果后，提议阶段完成。
（二）打包阶段
打包阶段也就是对交易进行排序的阶段，Orderer节点在这个阶段中起着至关重要的作用，过程如下：
1. Orderer接收到来自于多个Application的交易提议结果
2. 对每个Application提交的交易进行排序，这里值得注意的是排序的规则不是按照Orderer接收到交易的时间，而是按照交易的时间进行排序
3. 将交易分批打包进区块中，形成一个统一的共识结果，这种机制保证了Fabric不会出现账本的分叉
4. 当等待足够时间或区块满足大小后，Orderer将打包好的区块发送给特定Channel中的所有Peer
（三）验证阶段
Channel中的节点在接收到Orderer广播的区块后，每个节点都按照相同的方式独立处理接收到的区块，保证账本的一致性，步骤如下：
1. 通过VSCC检查交易是否满足背书策略。
2. 检查账本当前状态是否与提议结果生成时一致。
3. 通过检查的成功交易将被更新到账本中。
4. 构造Event消息，向注册了事件监听的Application通知Event消息。
三、小结
至此，一个交易的三个阶段就走完了，通过这三个阶段共同组成了Fabric的共识流程，并提供了一致性的保障，值得注意的是Fabric中是通过Channel来进行数据隔离的，因此所谓的一致性也是基于Channel考量的。
本文中没有深入的讨论Orderer排序的细节，这些细节Fabric在 A Kafka-based Ordering Service for fabric 一文中进行了详细的介绍，后续在一起深入学习吧。