HyperLedger Fabric 1.4 關鍵技術（6.4）

網易雲課堂視頻在線教學，地址：https://study.163.com/course/introduction/1209401942.htm

        本節介紹從最底層的帳本開始，逐一講解帳本的結構和存儲、智能合約的編寫和部署、通道的操做、節點的背書和提交、排序的共識和客戶端SDK的接口調用，與交易流程順序相反，由裏及表的說明Fabric最關鍵的技術，經過學習了這六種關鍵技術知識，能初步掌握Fabric的核心，瞭解Fabric運做原理。

6.3.1 賬本（Ledger）

       Fabric賬本（Ledger）是一系列有序和防篡改的狀態轉換的記錄，結構由一個區塊鏈構成，並將不可變的、有序的記錄存放在區塊中；同時包含一個狀態數據庫來記錄當前的狀態，帳本的當前狀態信息是鏈交易日誌中記錄過的全部鍵的最新值，因爲當前狀態表示的是通道已知的全部鍵的最新值，由此也被稱爲世界狀態。區塊鏈結構保存在本地的文件系統中；世界狀態由數據庫來維護，以鍵值對（k-v）的方式保存在數據庫，默認數據庫爲LevelDB，數據庫版本可替換爲KV類型的數據庫，如CouchDB等。

賬本結構圖以下：

 

圖：賬本結構圖

 

 區塊鏈(Blockchain）：

        區塊鏈（Blockchain）是基於本地文件系統，將區塊存儲於文件系統的硬盤中，每一個區塊中保存有區塊頭（Block header）、區塊數據（Block data）、區塊元數據（Block metadata），經過區塊頭中的前一個區塊的哈希值（Previous Block Hash）指向前一個區塊的當前哈希值（Current Block Hash），鏈接成區塊鏈。

上圖中區塊圖示說明：

B：Blockchain 區塊鏈

B1：Block 區塊

H3：Block header 區塊頭

D1：Block data 區塊數據

T5：Transaction 交易數據，保存在區塊數據中

M3：Block metadata區塊元數據

H1-H2：H2 is chained to H1 區塊2指向區塊1

 狀態數據庫（State Database）：

狀態數據庫是存儲全部在交易中出現的鍵值對的最新值，調用鏈碼執行交易能夠改變狀態數據，爲了高效的執行鏈碼調用，全部數據的最新值都被存放在狀態數據庫中；狀態數據庫被設計爲組件，能夠經過配置替換數據庫，目前有LevelDB和CouchDB兩種數據庫， LevelDB是默認的內置的數據庫。

LevelDB：適用於簡單的鏈值對k-v場景，LevelDB嵌入在peer進程中。

CouchDB：適用於支持豐富的查詢和數據類型的場景，應用系統做爲JSON文檔存儲時，CouchDB是一個特別合適的選擇，支持對chaincode數據進行豐富的查詢。

 帳本索引數據庫（Block index）：

區塊鏈保存到文件系統時，會在LevelDB 中存儲區塊交易對應的文件塊及其偏移，也就是將 LevelDB 做爲帳本數據庫的索引。文件形式的區塊存儲方式若是沒有快速定位的索引，那麼查詢區塊交易信息會很是的慢。

 歷史狀態數據庫（History index）

       歷史狀態數據庫用於查詢某個 key 的歷史修改記錄，歷史數據庫並不存儲 key 具體的值，而只記錄在某個區塊的某個交易裏，某 key 變更了一次，後續須要查詢的時候，根據變更歷史去查詢實際變更的值，雖然減小了數據的存儲，固然也增長了查詢邏輯的複雜度。

6.3.2 智能合約（Smart contract）

       智能合約又稱爲鏈碼，是在區塊鏈上運行的一段代碼，是應用系統與區塊鏈底層交互的中間件，經過智能合約能夠實現各類複雜的應用。

目前使用Go語言來開發智能合約之外，還可使用java、node.js開發，支持最好的仍是Go語言。

智能合約安裝在節點（Peer）上，運行在Docker容器中，經過gRPC與Peer進行數據交互，交互步驟以下：

 

圖：鏈碼與節點消息交互

 

1) 鏈碼（chaincode）調用 shim.Start()方法後，給節點（Peer）發送 ChaincodeMessage_REGISTER 消息嘗試進行註冊。客戶端鏈碼等待接收來自節點（Peer）的消息。此時鏈碼（chaincode）和節點（Peer）的狀態爲初始的created。

2) 節點（Peer）在收到來自鏈碼容器的 ChaincodeMessage_REGISTER 消息後，會註冊到本地的一個handle結構，返回 ChaincodeMessage_REGISTERED 消息給鏈碼容器。而且更新狀態爲 established ，而後會自動發出 ChaincodeMessage_READY 消息給鏈碼（chaincode），而且更新狀態爲ready。

3) 鏈碼（chaincode）在收到 ChaincodeMessage_REGISTERED 消息以後，先不進行任何的操做，完成註冊步驟。更新狀態爲 established 。在收到 ChaincodeMessage_READY 消息以後再更新狀態爲 ready 。

4) 節點（Peer）發出 ChaincodeMessage_INIT 消息給鏈碼容器，對鏈碼進行初始化。

5) 鏈碼容器收到 ChaincodeMessage_INIT 消息以後，調用用戶代碼 Init()方法進行初始化，成功以後，返回 ChaincodeMessage_COMPLETED 消息。到此，鏈碼容器能夠被調用了。

6) 鏈碼（chaincode）被調用的時候，節點（Peer）發出 ChaincodeMessage_TRANSACTION 消息給鏈碼。

7) 鏈碼在收到 ChaincodeMessage_TRANSACTION 消息以後，會調用 Invoke()方法，根據Invoke方法中用戶的邏輯，能夠發送以下的消息給節點（Peer）：

ChaincodeMessage_GET_HISTORY_FOR_KEY

ChaincodeMessage_GET_QUERY_RESULT

ChaincodeMessage_GET_STATE

ChaincodeMessage_GET_STATE_BY_RANGE

ChaincodeMessage_QUERY_STATE_CLOSE

ChaincodeMessage_QUERY_STATE_NEXT

ChaincodeMessage_INVOKE_CHAINCODE

8)節點（Peer）在收到這些消息以後，會進行相應的處理，並回復 ChaincodeMessage_RESPONSE 消息。最後，鏈碼（chaincode）會回覆調用完成的消息 ChaincodeMessage_COMPLETE至節點（Peer）。

9) 上述消息交互過程完成後，節點（Peer）和鏈碼（chaincode）會按期相互發送 ChaincodeMessage_KEEPALIVE 消息給對方，以確保彼此是在線狀態。

6.3.3 通道（Channel）

通道是兩個節點（Peer）或多個節點之間信息通訊的私有空間，在通道內的交易的數據與通道外隔絕，保證通道內數據的安全。在網絡上的交易都要在某個通道（Channel）上執行，參互交易的每一個成員都須要進行身份驗證和受權，才能在通道（Channel）上進行處理。

Fabric是多通道設計，系統能夠建立多條通道，某個節點（Peer）能夠加入到不一樣的通道中，在每一個通道中有自身的創世區塊和實例化智能合約（Smart contract）。

每一個通道都有屬於本身的錨節點，經過錨節點能夠與其它通道進行信息交互，但自己通道內的帳本不會經過一個通道傳到另外一個通道上，通道對帳本是分離的。

通道結構圖：

 

 

圖：通道結構圖

 

上圖中通道圖示說明：

N：Blockchain Network區塊鏈網絡

C：Channel 通道

P：Peer 節點

S：Chaincode 鏈碼

L：Ledger 帳本

A：Application 客戶端

PA-C：Principal PA（e.g. A，P1）communicaties via channel C 客戶端A與節點P（Peer）經過通道C（channel）進行通訊。

H1-H2：H2 is chained to H1 區塊2指向區塊1

6.3.4 節點（Peer）

       節點（Peer）是區塊鏈的交易處理和帳本維護的主體，主要負責參與共識過程和經過執行鏈碼（chaincode）實現對帳本的讀寫操做。節點（Peer）根據功能不一樣分爲背書節點（Endorser peer）和提交節點（Committer peer）；根據通信不一樣分爲錨節點（Anchor peer）和主節點（Leading peer）。

       背書節點（Endorser peer）：背書節點（Endorser peer）負責對交易根據事先設定策略進行簽名背書，背書節點（Endorser peer）根據鏈碼在實例化的時候設置背書策略，指定哪些節點用於背書。當客戶端向節點發起交易背書時，該Peer節點才雎有背書功能，其它時間只是普通的記帳節點。

       記帳節點（Committer peer）：記帳節點（Committer）負責維護狀態數據和帳本的副本。

       錨節點（Anchor peer）：錨節點（Anchor peer）是隨通道（Channel）存在，是能被其它通道發現的的節點（peer），每一個通道（channel）上有一個或多個錨節點（Anchor peer）。

      主節點（Leading peer）：主節點（Leading peer）負責與排序（Orderer）通訊，把共識後的區塊傳輸到其餘節點。

應用程序與節點交互圖：

 

圖：客戶端與節點交互

上圖中通道圖示說明：

N：Blockchain Network區塊鏈網絡

A：Application 應用程序

P：Peer 節點

S：Chaincode 鏈碼

L：Ledger 帳本

O：Orderer 排序

交互流程：

1）應用程序成功鏈接到節點（Peer）後,調用鏈碼向節點（Peer）進行提案；

2）節點（Peer）根據提案信息調用鏈碼；

3）鏈碼進行查詢和更新，而後返回提案信息給應用程序；

4）應用程序發送交易信息給排序（Orderer）;

5）排序（Orderer）把含有交易信息的區塊發送給節點（Peer）; 

6）節點（Peer）把交易區塊更新到帳本中，最終完成處理；

6.3.5 排序（Orderer）

       排序（Orderer）指對區塊鏈網絡中不一樣通道產生的交易進行排序，並廣播給節點（Peer）。排序（Orderer）是以可插拔組件的方式實現，目前分爲SOLO和Kafka兩種類型。

       SOLO：僅有一個Orderer服務節點負責接收交易信息進行排序，是最簡單的排序算法，通常用於測試環境。

       Kafka：是由Apache軟件基金會開發的一個開源流處理平臺，一種高吞吐量的分佈式發佈訂閱消息系統，它能夠處理消費者規模的網站中的全部動做流數據，能夠配置多個排序節點集羣方式，以便使用在生成環境。Hyperledger Fabric利用kafka的高吞吐、低延時的特性，對交易信息進行排序處理，實如今集羣內部支持節點故障容錯。

       正式環境中須要使用Kafka搭建，保證數據可靠性和安全性，如下介紹基於Kafka集羣和ZooKeeper集羣的排序服務的原理。

1.Kafka處理概述

Kafka處理流程示意圖：

 

圖：Kafka處理流程示意圖

說明：

排序（Orderer）節點（Ordering Service Node）簡稱爲OSN，Orderer集羣鏈接到Kafka集羣和Zookeeper集羣，利用Kafka的共識功能，實現網絡中交易的排序和生成區塊的任務。

當排序（Orderer）節點經過RPC廣播（Broadcast）接收到從節點（Peer）來的交易數據時，先判斷髮送交易的客戶端是否有權限處理該通道（Channel）數據，若是有權限，排序（Orderer）節點會把交易保存到Kafka的分區（partition）中,每一個通道（Channel）對應Kafka中的單獨的單分區（partition）的類別中（topic）。

排序（Orderer）節點使用該分區（partition），將接收到交易分組寫入到本地區塊中，並加入到本地的區塊鏈中，最後經過RPC傳輸（Deliver）給須要接收的客戶端。

2. Kafka集羣和ZooKeeper集羣的節點數量規定

kafka集羣節點的最小值爲4，是故障容錯所須要的最小數值。四個kafka結點能夠允許一個節點崩潰後，全部的通道（Channel）還能夠繼續讀寫且建立通道。

 zookeeper能夠爲3,5或7。它必須是一個奇數來避免分裂(split-brain)情景，同時選擇大於1是爲了不單點故障,超過7個ZooKeeper節點是多餘的。

3. 排序（Orderer）操做步驟

       1）在網絡的創世塊中寫入Kafka相關的信息

       在生成創世區塊時，須要在configtx.yaml文件中配置Kafka相關的信息，如Orderer.OrdererType設置爲kafka、Orderer.Kafka.Brokers設置Kafka集羣中的節點IP地址和端口；

       2）設置區塊最大容量

       區塊最大容量在configtx.yaml文件中設置Orderer.AbsoluteMaxBytes項的值，以字節爲位置，不包括區塊頭信息大小。

      3）建立創世區塊

       使用 configtxgen 工具，根據步驟1和2中配置生成創世區塊。

      4） 配置Kafka集羣

          設置unclean.leader.election.enable爲false；

         設置min.insync.replicas爲M（數字），數據提交時會寫入至少M個副本，值的範圍爲1<M<N（N爲default.replication.factor值）；

          設置default.replication.factor爲N（數字），N表示在Kafka節點上每一個channel都保存N個副本的數據；值的範圍爲1<K（K爲Kafak集羣數量）；

          設置message.max.bytes值，message.max.bytes應該嚴格小於socket.request.max.bytes的值，socket.request.max.bytes的值默認被設置爲100MB；

          設置replica.fetch.max.bytes值，每一個通道獲取的消息的字節數；

          設置log.retention.ms爲-1，關閉基於時間的日誌保留方式。

      5） 全部排序（Orderer）節點都指向創世區塊

      在 orderer.yaml 文件中配置 General.GenesisFile參數， 讓排序（Orderer）節點指向步驟3中所建立的初始區塊。

      6）調整輪詢間隔和超時時間

     在orderer.yaml 文件中配置Kafka.Retry參數， 調整 metadata/producer/consumer 請求的頻率以及socket的超時時間。

      7） 設置排序節點和 Kafka 集羣間爲SSL 通信

     在orderer.yaml文件中配置Kafka.TLS參數，肯定是否經過TLS（安全傳輸層協議）進行通訊。

     8） 集羣啓動順序

     先啓動ZooKeeper 集羣,而後啓動 Kafka 集羣,最後啓動排序（Orderer）節點。

6.3.6 接口（SDK）

       Fabric SDK提供調用帳本（Ledger）、智能合約（Smart contract）、通道（Channel）、節點（Peer）、排序（Orderer）等接口，方便用第三方應用程序的開發，大大擴展了Fabric的應用場景。

       Hyperledger Fabric提供了許多SDK來支持各類編程語言，目前正式發佈了Node.js和Java兩種版本的SDK。未來還會發布Python、Go、REST版本的SDK，還在測階段。

       Fabric SDK應該能夠爲開發人員提供編寫應用程序的多種操做區塊鏈網絡的方式。應用程序能夠部署/執行chaincode，監聽網絡中產生的事件，接收塊信息，把交易存儲到帳本中等。

接口模塊以下：

1) Package: Hyperledger Fabric Client

模塊	等級	功能
Client	0	主要的入口模塊。它必須容許用戶建立須要的任何對象來執行全部支持的操做，例如直接鏈接網絡，chaincode部署，交易執行，多種查詢。另外，基於編碼規範和廣泛的社區練習，每一種語言的實現也能決定是否添加方便的方法，如sendTransaction(chain, tx)
Chain	1	一個鏈表明一些節點特別造成的一個網絡，啓動一個共識的通道，在通道中交易能夠被獨立的處理。一個網絡可能有一個或多個鏈。鏈上的節點維護一個單獨的帳本包含交易在鏈上派發，包括成員關係的任何配置。全部的交易都是在鏈上發送，一個應用可能操做多個鏈。
Peer	2	表明網絡上的計算節點。節點的角色有背書節點和提交節點，它們都在維護着帳本。應用可能鏈接到必定數量的可用的節點
Orderer	2	相似節點，不一樣的是它表明排序服務的終端，多是一個單獨的節點（開發時本地安裝）或者一個網絡排序者的代理節點。基於區塊鏈網絡的fabric會有一個由多個排序者節點組成的單獨的排序服務。應用能夠選擇信任特定的排序者，或者一部分排序者，或者設置代理去給排序者節點廣播交易。
User	2	表明在網絡上交易的用戶。用戶實例能夠基於登記證書被初始化。證書能夠從成員服務或者外部CA獲取。理論上，這種用戶也能表明網絡上的節點成員。然而，這與應用程序無關（這更像是網絡管理方面的問題），因此在這個設計中沒有開放。
Proposal	3	登記的用戶能夠向節點列表提出交易提案來背書交易。一旦接收到背書響應，應用程序能夠決定是否已經獲取背書籤名，是否須要執行提交交易到共識服務。這是關於提案原始的GRPC消息的包裝類，它提供了便利的建立方法。
ProposalResponse	3	提案調用背書節點的響應，打包背書結果（是或否），簽名，等等。這是關於提案響應原始的GRPC消息包裝類，它提供了便利的方法來利用它本身的內容（背書，簽名，等等）。
Transaction	3	登記用戶收集了背書以後能夠提交交易。交易請求包含背書籤名和MVCC+post-image，而且使用排序服務API。交易有兩種類型：部署和執行。這是交易有關原始GRPC消息的包裝類，它提供了便利的建立方法。
CryptoSuite	3	加密模塊打包了數字簽名算法，非對稱加密的密鑰對，對稱加密的密鑰消息，安全的hash和MAC。

2)   Package: Member Service

模塊	等級	功能
MemberService	0	這是fabric可選模塊的客戶端，成員服務。本模塊的主要功能是從成員服務獲取用戶登記證書。另外，這個模塊自己或它的擴展類也應該能在fabric默認的成員服務的實現中提供可用的額外的功能，如用戶註冊功能。