第二章 文獻探討
第二節 Hyperledger
三、 Fabric
(五) Cello:提供區塊鏈平台的部署和運行時管理功能。使用 Cello，管理員可 以輕鬆部署和管理多條區塊鏈。
(六) Indy:提供基於分布式帳本技術的身分管理機制。
(七) Composer:提供面向 Chaincode 開發的高級語言支持，自動生成 Chaincode 等。
(八) Burrow: 提供以太坊虛擬機的支持，實現支持高效交易的帶權限區塊鏈 平台。
三、 Fabric
(一) Fabric 項目簡介
Fabric 是最早加入到 Hyperledger 項目中的頂級項目，Fabric 由 IBM、
DAH 等企業於 2015 年底提交到社區。Github 連結為
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
絡處理瓶頸，提高可擴展性，並將 Peer 節點功能分化成 Endorser 及 Committer，可以根據電腦效能、負載進行靈活部署。
加強了身分認證管理服務，單獨的 Fabric CA 項目，提供實名制的 PKI(Public Key Infrastructure)認證，負責 Fabric 網絡內所有實體的身分及證 書管理，用戶通過 Client 端從 Fabric CA Server 端獲取合法的證書文件後，
即可參與到網絡中發起交易。
圖 4 PKI、PKC 比較示意圖
(資料來源:杜宏毅 Blockchain 的前世今生與未來)
實現 multiple Channel 機制，不同 Channel 之間的資訊彼此隔離，用戶 只能看到自己有參與的交易的資訊，達成商業化的需求。
支持可插拔(pluggable)的架構，包括共識、權限管理、加解密等模組。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5 Channel 示意圖
(資料來源:本研究繪製，參考:
http://www.gooread.com/article/20120676648/)
Chaincode，是 Fabric 中十分關鍵的概念，區分為 Application Chaincode 及 System Chaincode，Application Chaincode 運行在單獨的容器中，用戶通 過編寫 Application Chaincode，對 Ledger 中的狀態進行操作；System Chaincode 嵌入在系統內，提供對系統進行配置、管理。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(三) Fabric 架構
圖 6 Fabric 架構圖 (資料來源:本研究繪製，參考:
https://read01.com/zh-tw/AJxmMKm.html#.WrCcC-huZPb)
Fabric 為應用提供了 gRPC API，以及封裝 API 的 SDK 供調用。應用可 以通過 SDK 訪問 Fabric 網絡中的多種資源，包括 Ledger、Transaction(交易)、
Chaincode、Event(事件)、CA(權限管理)等。其中，Ledger 是最核心的結構，
記錄應用訊息，應用則通過發起交易來向 Ledger 中記錄數據。交易執行的 邏輯通過 Chaincode 來實現。整個網絡運行中發生的事件可以被應用訪問，
以觸發外部流程甚至其他系統。權限管理則負責整個過程中的訪問控制。
Ledger 和 Transaction 進一步地依賴核心的區塊鏈結構、資料庫、共識機制 等技術；Chaincode 則依賴 Container(容器)、World State(狀態機)等技術；
CA(權限管理)利用了已有的 PKI 體系、數字證書、加解密算法等諸多安全 技術。底層由多個節點組成 P2P 網絡，通過 gRPC 通道進行交互，利用 Gossip 協議進行同步。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
(四) 交易流程
圖 7 Fabric 交易流程 (資料來源:本研究繪製，參考:
https://read01.com/zh-tw/AJxmMKm.html#.WrCcC-huZPb)
Fabric 根據交易過程中不同環節的功能，在邏輯上將節點角色解耦為 Endorser 和 Committer，讓不同類型節點可以關注處理不同類型的工作負載。
客戶端應用(App)使用 SDK 跟 Fabric 網絡溝通，首先(第 0 步)客戶端從 CA 獲取合法的身分證書來加入網絡的應用通道，(第 1 步)發送交易提案 (Transaction proposal)給 Endorser 進行背書，(第二步)Endorser 進行合法性和 ACL(Access Control List)權限檢查，檢查通過後則模擬進行交易，對交易導 致的狀態變化以讀寫集型式紀錄，進行背書並返回結果給客戶端，(第 3 步)
‧
給 Orders，(第 4 步)Orders 透過交易 Timestamp 對合法交易進行全局排序，並將一批排序後的交易組合生成 Block 結構。(第 5 步)Orders 將生成的 Block 交給 Committer，Committer 進行最終檢查(簽名完整性、是否重複、讀寫集 版本是否匹配等)，檢查通過後執行合法的交易，將結果寫進 Ledger，並同 書)、Ordering(排序)及 Validation(驗證)都屬於共識機制的一環。
背書是指背書節點對收到來自客戶端的請求(proposal)按照 endorsement policy 進行檢查，以決策是否通過、添加數字簽章，endorsement policy 通常 是指 proposal 需要獲得一定條件的背書才被認為是合法的，例如某些特定身 分成員的同意；某個組織中超過一定數目的成員支持。
排序是對一段時間內的一批交易達成一個網絡內全局一致的排序。採用 可插拔的架構目前有測試用的 solo 模式以及 Kafka 模式。
驗證是對排序後的一批交易進行提交到帳本之前最終檢查的過程。包括 檢查交易結構完整性、背書簽名是否符合 endorsement policy 等。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
接下來說明 Kafka 在 Fabric 網絡當中的運行模式:
Kafka 是一個分布是高可用消息佇列，可以有序的管理訊息並在多個副本間 保證數據一致性。Kafka 集群的狀態由 zookeeper(ZK)管理，選舉 leader 節點。[12]
一個共識集群由多個 Orderer 節點(OSN)和一個 Kafka 集群組成，Orderer 之 間不直接通訊，他們僅僅和 Kafka 集群通訊，在 Orderer 的實現裡，Channel 在 Kafka 是以 topic 的形式隔離，Orderer 服務從 kafka 集群裡獲取相對應 topic(kafka 的分區，用於在佇列裡隔離出多個數據域)的數據，以保證交易數據有序。每個 Orderer 內部，針對每個通道都會建立與 Kafka 集群對應 topic 的生產者與消費 者，生產者將 Orderer 節點收到的交易發送到 Kafka 集群進行排序，在生產的同 時，消費者也同步消費排序後的交易，如下圖:
圖 8 Kafka 共識機制
(資料來源: https://www.jianshu.com/p/f1a671be69a4)
如何劃定哪個交易屬於哪個區塊呢?Fabric 經由兩個條件決定，區塊交 易量和區塊時間間隔，當配置達到域值時，無論是否達到時間間隔，都會觸
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
發節塊操作；另一方面，如果觸發了配置的時間間隔域值時，只要有交易就 會觸發節塊操作，也就是說 Fabric 中不會有空區塊。結塊操作是由 Orderer 節點中的 Kafka 生產者發送一條 TTC-X(Time to cut block x)消息到 Kafka 集 群，當任意 Orderer 節點的 Kafka 消費者接收到任意節點發出的 TTC-X 消息 時，都會將之前收到的交易打包節塊，保存到 Orderer 本地，之後再發送到 各 Peer 節點，如下圖:
圖 9 共識結塊機制
(資料來源: https://www.jianshu.com/p/f1a671be69a4)