ChainDesk：Fabric中的共識實現
作者：ChainDesk韓小東
目標
1.共識演算法的實現目的
2.共識演算法的分類
3.Hyperledger Fabric所使用的共識演算法
任務實現
7.1.1 概述
在區塊鏈網路中，不同的參與者發起的交易必須按照產生的順序被依次寫入到賬本中。交易如何在分散式場景下， 所有節點對同一個提案或值達成一致性，是區塊鏈技術中必須考慮並加以解決的一個問題。要實現這一目標，交易順序必須被正確的建立，並且必須包含對交易被篡改或者惡意提交交易的處理方法。
通常，共識演算法就是保證分散式系統一致性實現的解決方式，共識演算法是電腦科學中用於在分散式過程或系統之間實現對單個數據值的一致性的過程。共識演算法旨在實現涉及在網路中多個不可靠節點的可靠性。解決該問題（稱為共識問題）在分散式計算和多代理系統中非常重要。
7.1.2 共識演算法型別
7.1.2.1 共識屬性
共識演算法必須滿足兩個屬性，以保證節點之間的一致性， 這兩個屬性分別是：安全性和活躍性。
- 安全性：表示每個節點保證相同的輸入序列，並在每個節點上產生相同的輸出結果。當節點收到相同的一系列交易時，每個節點上將發生相同的狀態更改。該演算法必須與單個節點系統的執行結果相同。
- 活躍性：在通訊正常的情況下，每個非故障節點最終都能接收每個提交的交易。
7.1.2.2 共識演算法型別
共識演算法可以以不同的方式實現，一般有如下兩種型別：
1.基於彩票的演算法（Lottery-based Algorithms）
2.基於投票的方法（Voting-based Methods），包括冗餘的拜占庭容錯（Redundant Byzantine Fault Tolerance，RBFT）和 Paxos（基於訊息傳遞的一致性演算法）。每一種方法都針對不同的網路需求容錯模型。基於投票的演算法的優勢在於它們提供了低延遲的終結性。當大多數節點驗證事務或塊時，就存在共識和終結性發生。因為基於投票的演算法通常需要節點來對網路上的每個節點傳輸訊息，所以網路上存在的節點越多，達成共識的時間越長。這導致了可伸縮性之間的權衡和速度， 不能滿足高併發、快速交易（低延遲）的需求場景。
下表介紹了兩種共識演算法型別的比較：
區塊鏈技術QQ交流群：263270946 掌握更多技術乾貨，關注微信公眾號“ChainDesk”
因為區塊鏈中的業務需求會有所不同，所以 Hyperledger 社群研究幾種不同的一致性共識機制並進行實施以確保模組化實現。Hyperledger 團隊開發人員為了提高資源使用及時間效率， 在 Hyperledger 專案開發前做出評估，將區塊鏈業務指定在部分信任的網路環境中執行。所以，Hyperledger 網路環境中不支援匿名訪問者的標準工作共識證明方法（Pow共識演算法）。
目前，Hyperledger 中各框架專案所使用的共識演算法如下：
- Hyperledger Fabric 中使用了基於 Zookeeper（分散式服務框架）的 Apache Kafka（分散式訊息系統）。
- Hyperledger Indy 中使用了基於投票的方法 RBFT（Redundant Byzantine Fault Tolerance，冗餘拜占庭容錯演算法）。
- Hyperledger Iroha 中使用了一種基於投票的方法（Sumeragi）來達成共識故障容錯。
- Hyperledger Sawtooth 中使用了基於彩票的 PoET 演算法以拖延為代價實現共識。
7.1.3 Hyperledger Fabric中的共識實現
不同的 Hyperledger 框架可以選擇不同的方式實現共識。Hyperledger 區塊鏈框架業務通過執行兩個框架達成單獨的共識過程：
- Ordering of transactions （交易排序）
- Validating Transactions（交易驗證）
為了確保任何 Hyperledger 框架可以應用於任何的 Hyperledger 共識模組，通過邏輯分離這兩個共識實現過程。Hyperledger Fabric 網路中的共識被分解為三個階段：背書階段、排序階段和驗證階段。
- 背書階段：簽名必須由參與者的背書策略確定。
客戶端應用程式將交易請求打包成為交易提案（Proposal）後，根據背書策略（Endorse Policy）發達給指定的背書節點（Endorse Peer）。背書節點接收到交易提案後呼叫鏈碼（Chaincode）執行，但此執行過程是模擬執行，並不會將資料記錄到賬本中。執行完成後呼叫交易背書系統鏈碼（Endorsement System Chaincode，ESCC）對執行結果進行簽名，然後響應給客戶端應用程式。Ordering Service 可以以不同的方式實現：開發和測試階段可以使用集中式排序服務（中心化），針對不同網路的分散式協議節點故障模型。為了保證交易的機密性，Ordering Service 不能看到交易中的具體內容（不參與對交易內容的任何處理），也就是說，交易內容可以使用雜湊雜湊或加密方式去處理。
- 排序階段：接受提交的被認可的交易並進行排序，確保交易順序的一致性。
排序階段通過 Ordering 服務提供的介面接收到已經背書的交易，Ordering Service 根據共識演算法配置策略（根據指定的配置資訊中定義時間限制或指定允許的交易數量），確定交易的順序和交易數量。然後將交易打包到區塊中進行廣播。大多數時候，由於為了提高系統效率的原因，Ordering 服務將多個交易分組到一個區塊中，而不是將單個交易輸出成為一個區塊。
- 驗證階段：獲取有序事務塊並驗證其結果的正確性，包括檢查背書策略和重複提交攻擊。
Peer 節點接收到廣播的區塊後，進行儲存之前的最終檢查驗證，驗證通過後將該區塊儲存在區塊鏈中。為了校驗交易的正確性，共識的建立依賴於智慧合約層（Hyperledger Fabric 中的 Chaincode），智慧合約層定義了商業邏輯來如何驗證交易的有效性。智慧合約層根據特定的策略與約定來確認每一筆交易都是有效的。無效的交易會被拒絕，並在塊中剔除。潛在的校驗失敗主要分為以下兩種：
1.語法錯誤：包含以下幾種型別，比如無效輸入、未驗證的簽名、重複的交易等，這類交易應該被丟棄。
2.邏輯錯誤：此類錯誤更為複雜，應該需要定義策略決定是繼續處理還是終止執行。如，導致重複交易或版本控制的交易。如果策略需要，我們可能需要日誌記錄這些交易以進行審計。
Hyperledger Fabric 應用程式可以根據不同的交易背書、排序和驗證模型要求，實現支援對3個階段的可拔插共識服務，特別是 Ordering 服務 API 允許插入基於 BFT 的協議演算法。Orderer 節點通過gRPC服務提供兩個 API 介面：廣播（broadcase）和交付（deliver）。
broadcast（blob）：客戶端呼叫此函式在通道中廣播任意的訊息blob（客戶端向排序服務傳送交易請求）。在BFT中，給服務傳送一個請求時，又稱為 request(blob)。
deliver（seqno，prevhash，blob）：Ordering 服務呼叫此函式給 Peer 節點發送blob訊息，包含非負整數的序列號 seqno 和最近一次訊息的雜湊 prevhash 。換句話說，它是共識服務的輸出介面。deliver（）在釋出/訂閱系統中稱為notify（），在BFT系統中稱為commit（）。
注意共識服務客戶端（即 Peer 節點）只通過broadcast（）和deliver（）事件和服務進行互動。
在 Hyperledger Fabric 框架專案的正式版本中支援兩種共識演算法型別：
Solo：單節點共識，整個Fabric網路只有一個 Orderer 節點（Fabric網路預設）。主要用於測試模式。
Kafka：分散式訊息佇列，整個Fabric網路的共識由 Kafka 叢集實現（實際上Kafka實現了對於Hyperledger Fabric網路中所有的交易請求進行排序服務）。具體實現方式請參見下一節內容。
目前，Hyperledger 專案團隊正在開發其它 Ordering 共識外掛，包括BFT Smart，簡化拜占庭容錯演算法（Simplified Byzantine Fault Tolerance，SBFT），蜜獾拜占庭容錯演算法（Honey Badger of BFT）等。
FAQ
1.已經啟動了 Orderer 服務，然後想使用其它一致性演算法，如何實現？
在 Hyperledger Fabric 中不支援此種操作方式。
2.現在可以在 Hyperledger Fabric 中使用拜占庭容錯演算法 嗎？
不可以，目前在 Fabric 釋出的標準版本中只能使用 Solo 與 Kafka 實現共識，其它共識外掛處於開發狀態中，在哪個正式版本中釋出官方並沒有確定。
未經授權禁止轉載、改編，轉載請註明出處！
本文地址： https://www.chaindesk.cn/witbook/11/145
ChainDesk——全球區塊鏈技術生態超級社群
以區塊鏈技術為入口，搭建全球區塊鏈技術生態超級社群，社群將服務於公鏈生態建設、DAPP專案研發、技術諮詢、課程體系研發、區塊鏈書籍編寫，區塊鏈課程製作、講師培訓、區塊鏈職業教育、區塊鏈線上教育、去中心化技術評測一體化的區塊鏈技術超級社群。
免費·原創·專業·高效·系統