Fabric v1.x Orderer全排序与区块切割规则

一、执行-排序-验证（Execute-Order-Validate）

Fabric采用的是先执行、后排序、最后验证的共识模型（Execute-Order-Validate），如下图所示：

首先由client提出交易，发给peer仿真执行，产生读写集并签名后返回给client，client会把签名的读写集（proposal response）打包发送给orderer，orderer会将所有从client接收的proposal response进行排序，并打包成区块，然后将区块发送给peer，最后由peer打开每个区块，并验证读写集的版本号和签名，满足条件便可将数据写入本地账本。peer还会给client发送event说明交易已经被提交到账本中了。以上就是Fabric交易的生命周期。

二、Orderer的全排序

Orderer的作用就是将Fabric网络中的交易进行全排序。Orderer是一个集群，将集群中每个节点接收到的所有交易进行全排序，然后通过一定的规则将交易打包成区块，如下图所示：

在Fabric中并不是所有人都可以参与排序的，由联盟里的核心企业运行orderer节点，因此只允许某几个组织参与排序工作。

Orderer全排序需要实现了以下需求：

2.1 产生相同的块（Produce identical blocks）

Orderer各个节点需要通过一致性算法产生完全相同的区块，这样各个peer节点接收的区块也将是完全相同，如下图所示，各个orderer产生的区块哈希都是一致的：

2.2 崩溃容错（Crash Fault Tolerance）

Orderer集群中某个节点停止服务后，剩下的节点依然能够完成排序功能，比如raft算法中只要超过半数的节点正常工作，就能完成正常的排序。

Orderer节点宕机后，被隔离的orderer节点可能还会继续运行，这时会产生网络分区（Network Partition），被隔离的orderer节点要能嗅探到自己被隔离了，拒绝产生新区块。

2.3 强一致性（Strong Consistency）

公链中的“Po”系列共识算法只能达成概率上的一致性，而Fabric则需要强一致性，已被提交的交易被回滚是不能被接受的，因此也不存在临时性分叉，每个区块都是确定性的（Finality）。

2.4 拜占庭容错（Byzantine Fault Tolerance）

拜占庭容错指的是一个节点不仅仅是停止服务，还可以作恶，提交一些恶意交易或拒绝响应别人的请求。Fabric1.4版本的Orderer本身是不支持拜占庭容错（BFT）的，仅支持崩溃容错（CFT），但是Fabric存在背书和验证的机制，整个Fabric是拜占庭容错（BFT）的，即使有一些攻击无法防范，使得无法出块，peer节点提交的交易不会写到账本里，但在Fabric里可以查看别的orderer的log，可以诊断出某个orderer在作恶，最然对网络造成了影响，但不会造成peer的数据丢失或篡改，因为没有peer的背书，交易永远不会被提交到账本中。

三、区块切割（Block Cutting）

Orderer将交易排序后，每个Orderer节点还需要进行区块切割，只要满足BatchSize和BatchTimeout其中一个条件就将产生区块。

3.1 BatchSize

• MaxMessageCount 一个区块的最大交易个数
• AbsoluteMaxBytes 限制单个交易大小
• PreferredMaxBytes 期待的区块大小

Orderer中一直在积累交易，当大小总额达到PreferredMaxBytes就可以出块，或者交易个数达到了MaxMessageCount同样可以出块。
但是最后一个交易bytes可能较大，不能保证总大小一定小于PreferredMaxBytes ，这时仍然是可以将交易包含进去出块的。单个交易的大小通过AbsoluteMaxBytes进行限制，超过该限制的交易会被拒绝掉。

3.2 BatchTimeout

• Timeout

区块可能一直达不到设置的大小，到了设置的“Timeout”时间后，只要有一个交易就会出块。