文章目錄
- 一、執行-排序-驗證（Execute-Order-Validate）
- 二、Orderer的全排序
-
- 2.1 産生相同的塊（Produce identical blocks）
- 2.2 崩潰容錯（Crash Fault Tolerance）
- 2.3 強一緻性（Strong Consistency）
- 2.4 拜占庭容錯（Byzantine Fault Tolerance）
- 三、區塊切割（Block Cutting）
-
- 3.1 BatchSize
- 3.2 BatchTimeout
一、執行-排序-驗證（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”時間後，隻要有一個交易就會出塊。