1. 超級賬本介紹

1.1 超級賬本簡介

    超級賬本是推動區塊鏈跨行業應用的開源專案的總稱，組織成員可以發起新的區塊鏈專案，加
入超級賬本專案中，但需要遵循超級賬本的生命周期，

    超級賬本的生命周期分為5個階段，分別為Proposal（提案）、lncubation（范訓）、Active
（活躍）、Deprecated（過時）、End of Life（結束），

    超級整本的整個生命周期的程序：成員發起新專案時，1）首先發起者撰寫草案，草案內容包括
實作的目標、開發程序、代碼維護等資訊；然后提交給技術指導委員會進行審核，該階段為提案階段；
技術指導委員會有三分之二以上代表通過后，則進入范訓階段；2）在范訓階段將對專案進行開發、
測驗，直到專案完成；3）專案參與者對該專案如果沒有疑問，專案將進入活躍階段；4）經過幾年時
間后，隨著技術的進步，該專案跟不上時代，將進入過時階段；5）最后被淘汰，整個生命周期結束，

1.2 超級賬本組織

    超級賬本組織分為技術指導委員會（TSC）、董事會（Governing Board）、作業人員
（LF Staffs）三個組織，

    1）技術指導委員會：主導社區的開發作業，下設多個作業組，每個作業組負責具體的專案開發；
    2）董事會：負責決策社區的所有事務，對社區成員負責；
    3）作業人員：為社區提供服務，

    Linux基金會通過票選機制，選舉出組織的技術指導委員會主席、董事會主席等關鍵領導角色，
同時公布了10名技術指導委員會成員，以及13名董事會成員，

1.3 超級賬本專案（重點介紹Fabric）

    超級賬本專案分框架類（包括：Hyperledger Fabric）和工具類兩類，

    Hyperledger Fabric：是最早加入超級賬本專案中的頂級專案，包括Fabric、Fabric CA、
Fabric SDK（包括Node.js、Go、Python和Java等語言）和Fabric-API等，其目標是區塊鏈的基礎
核心平臺，支持PBFT等新的共識機制，支持權限管理，

2. Fabric介紹

2.1 Fabric簡介

    Fabric是一個提供模塊化分布式賬本解決方案的框架，并具備保密性、可伸縮性、靈活性和可
擴展性等特性，Fabric具有可直接插拔啟用、相互獨立、功能不同的模塊，并能適應經濟社會中各
種錯綜復雜的場景，
    Fabric也是超級賬本中的一個區塊鏈專案，包含一個賬本，使用智能合約，并且是一個通過所
有參與者進行管理交易的系統，它與其他區塊鏈系統最大的不同是使用聯盟鏈，與允許未知身份的
參與者加入網路的公有鏈不同，Fabric通過成員資格服務提供者（Membership Service 
Provider，MSP）來登記所有成員，
    Fabric提供了建立通道（Channel）的功能，允許參與者為交易新建一個單獨的賬本，只有在同
一個通道中的參與者，才會擁有該通道中的賬本，而其他不在此通道中的參與者則看不到這個賬本，
這種通道隔絕技術帶來了更高的安全性，也是Fabric最主要的特點，

2.2 Fabric架構

2.2.1 總體架構

    Fabric總體架構分為網路層、核心層和介面層，核心層有成員服務（Membership 
Services）、區塊鏈服務（Blockchain Services）和鏈碼服務（Chaincode Services）3部
分；介面層通過介面及事件（APIs、Events、SDKs）呼叫身份（IDENTITY）、賬本（LEDGER）、
交易（TRANSACTIONS）、智能合約（SMARTCONTRACT）等資訊；網路層負責P2P網路的實作，保
證區塊鏈分布式存盤的一致性，

1）成員服務（Membership Services）：提供成員服務功能，包括注冊、登記、申請證書等功
能，考慮到商業應用對安全、隱私、監管、審計和性能的要求，節點、成員只有獲得證書才能加
入區塊鏈網路中，在1.0版本以后單獨由可插拔的Fabric CA組件處理，

2）區塊鏈服務（Blockchain Services）：負責分布式賬本（Distrbuted Ledger）的計算和
存盤、節點間的排序服務（Ordering Service）、背書驗證管理（Endorsement Validation）
以及賬本存盤方式（Ledger Storage）等功能的實作，是區塊鏈的核心組成部分，為區塊鏈的
主體功能提供了底層支撐，

3）鏈碼服務（Blockchain Services）：負責分布式賬本（Distrbuted Ledger）的計算和存
儲、節點間的排序服務（Ordering Service）、背書驗證管理（Endorsement Validation）
以及賬本存盤方式（Ledger Storage）等功能的實作，是區塊鏈的核心組成部分，為區塊鏈的
主體功能提供了底層支撐，

4）介面及事件（APIs、Events、SDKs）：給第三方應用提供API方式進行呼叫，方便二次開發，
目前已提供Node.js和Java兩種語言介面；可以通過SDK或CLI方式進行安裝并測驗鏈碼，還可以
實作查詢交易狀態和資料等功能，同時通過Events監聽區塊鏈網路中發生的事件，方便第三方應
用系統呼叫和處理，

5）網路協議（Network Protocol）：實作P2P網路傳輸，使用gPRC和Gossip協議，

2.3 Fabric交易流程

    區塊鏈最主要的特性之一是去中心化，沒有中心機構的集中處理，又要達成資料的一致性，
就需要網路中全民參與管理，并以某種方法達成共識，所以區塊鏈的交易流程也就是共識的程序，
    
    在Fabric中，本由一個節點處理的程序，在邏輯上被分解為不同的角色，每個角色承擔不同
的功能，節點（Peer）分解為背書節點（Endorser Peer）和提交節點（Committer Peer），為了
達到處理的順序性，提煉出排序（Orderer）角色，
       
    Fabric應用于聯盟鏈的場景，在處理每一筆交易時，每個環節都需要對交易資訊進行權限校驗，

交易的詳細流程如下：
    1）應用程式客戶端通過SDK呼叫成員服務，進行注冊和登記，并獲取身份證書，
    
    2）應用程式客戶端通過SDK向區塊鏈網路發起一個交易提案（Proposal），交易提案把本次
交易要呼叫的合約標識、合約方法和引數資訊以及客戶端簽名等資訊發送給背書節點，
   
    3）背書節點收到交易提案后，驗證簽名并確定提交者是否有權執行操作，同時根據背書策略
模擬執行智能合約，并將結果及其各自的CA證書簽名回傳給應用程式客戶端，
       
    4）應用程式客戶端收到背書節點回傳的資訊后，判斷提案結果是否一致，以及是否參照指定
的背書策略執行，如果沒有足夠的背書，則中止處理；否則，應用程式客戶端把資料打包到一起，
組成一個交易并簽名，發送給排序角色，
    
    5）排序角色對接收到的交易進行共識排序，然后按照區塊生成策略，將一批交易打包到一起，
生成新的區塊，發送給提交節點，
    
    6）提交節點收到區塊后，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符
合當前區塊鏈的狀態，完成后將區塊追加到本地的區塊鏈，并修改世界狀態（所有鍵的最新值），

2.4 Fabric關鍵技術

Fabric的6種關鍵技術知識點：
    1）賬本的結構和存盤（賬本）
    2）智能合約的撰寫和部署（智能合約）
    3）通道的操作（通道）
    4）節點的背書和提交（節點）
    5）排序的共識（排序）
    6）客戶端SDK的介面呼叫（介面）

2.4.1 賬本

（1）區塊鏈

    區塊鏈（Blockchain）基于本地檔案系統，將區塊存盤于檔案系統的硬碟中，每個區塊中保存區塊
頭（Block Header）、區塊資料（Block Data）、區塊元資料（Block Metadata），通過區塊頭中前一個區塊的哈希值指向前一個區塊的當前哈希值，連接成區塊鏈，

（2）狀態資料庫

    狀態資料庫（State Database）存盤在交易中出現的所有鍵值對的最新值，呼叫鏈碼執行交易
可以改變狀態資料，為了高效地執行鏈碼呼叫，所有資料的最新值都被存放在狀態資料庫中；狀態數
據庫被設計為組件，可以通過配置替換資料庫，目前有LevelDB和CouchDB兩種資料庫，LevelDB是
默認的內置資料庫，

    LevelDB：適用于簡單的鍵值對場景，LevelDB嵌入在Peer行程中，

    CouchDB：適用于支持豐富的查詢和資料型別的場景，應用系統作為JSON檔案存盤時，CouchDB
是一個特別合適的選擇，支持對鏈碼資料進行豐富的查詢，

（3）賬本索引資料庫

    區塊鏈保存在檔案系統時，會在LevelDB中存盤區塊交易對應的檔案塊及其偏移，也就是將
LevelDB作為賬本索引（Block Index）資料庫，檔案形式的區塊存盤方式如果沒有快速定位的索
引，那么查詢區塊交易資訊會非常慢，

（4）歷史狀態資料庫

    歷史狀態（History Index）資料庫用于查詢某個鍵的歷史修改記錄，并不存盤鍵具體的值，
該值只記錄在某個區塊的某個交易里，當某鍵變動了一次，后續需要查詢的時候，則根據變動歷史
去查詢實際變動的值，這樣雖然減少了資料的存盤，但增加了查詢邏輯的復雜度，

2.4.2 智能合約

智能合約（Smart Contract）又稱為鏈碼，是在區塊鏈上運行的一段代碼，是應用系統與區塊鏈底層互動的中間件，通過智能合約，區塊鏈可以實作各種復雜的應用，

目前支持使用Go、Java或Node.js語言來開發智能合約，支持最好的還是Go語言，

智能合約安裝在Peer上，運行在Docker容器中，通過gRPC與Peer進行資料互動，互動步驟（鏈碼與節點訊息互動）如下圖：

（1）智能合約呼叫shim.Start()方法后，給Peer發送ChaincodeMessage_REGISTER訊息并嘗試進行注冊，此時，智能合約和Peer的狀態為初識的created，

（2）Peer在收到來自智能合約的ChaincodeMessage_REGISTER訊息后，會注冊到本地的一個handle結構中，回傳ChaincodeMessage_REGISTER訊息給智能合約，并且更新狀態為established，然后會自動發出ChaincodeMessage_READY訊息給智能合約，并且更新狀態為ready，

（3）智能合約在收到ChaincodeMessage_REGISTER訊息之后，先不進行任何操作，只完成注冊步驟，并更新狀態為established，在收到ChaincodeMessage_READY訊息之后再更新狀態為ready，

（4）Peer發送ChaincodeMessage_INIT訊息給智能合約，對智能合約進行初始化，

（5）智能合約收到ChaincodeMessage_INIT訊息之后，呼叫用戶代碼Init()方法進行初始化，成功之后，回傳ChaincodeMessage_COMPLETED訊息，到此，智能合約就可以被呼叫了，

（6）智能合約被呼叫的時候，Peer發送ChaincodeMessage_TRANSACTION訊息給鏈碼，

（7）智能合約在收到ChaincodeMessage_TRANSACTION訊息之后，會呼叫Invoke()方法，根據Invoke()方法中用戶的邏輯，可以發送如下訊息給Peer，

（8）Peer在收到這些訊息之后，會做相應處理，并回復ChaincodeMessage_RESPONSE訊息，最后，智能合約會回復呼叫完成的訊息ChaincodeMessage_COMPLETE至Peer，

（9）上述訊息互動程序完成后，Peer和智能合約會定期給對方發送ChaincodeMessage_KEEPALIVE訊息，以確保彼此是在線狀態，

2.4.3 通道

通道（Channel）是兩個Peer或多個Peer之間訊息通信的私有空間，在通道內交易的資料與通道外隔絕，保證通道內資料的安全，在網路上的交易都要在某個通道上執行，參與交易的每個成員都通過身份驗證和授權，才能在通道上進行處理，

Fabric是多通道設計，系統可以創建多條通道，一個Peer可以加入不同的通道中，在每個通道中有自身的創世區塊和實體化智能合約，

每個通道都有屬于自己的錨節點，通過錨節點可以與其他通道進行資訊互動，但本身通道內的賬本不會通過一個通道傳到另一個通道上，通道對于賬本是分離的，

如下為通道結構圖：

通道結構圖的說明：

N：Blockchain Network（區塊鏈網路）

C：Channel（通道）

P：Peer（節點）

S：Chaincode（鏈碼）

L：Ledger（賬本）

A：Application（客戶端）

PA-C：Principal PA communicates via channel C（客戶端A與節點P通過通道C進行通信）

2.4.4 節點

節點（Peer）是區塊鏈交易處理和賬本維護的主體，主要負責參與共識程序和通過執行鏈碼實作對賬本的讀寫操作，Peer根據功能不同分為背書節點（Endorser Peer）和提交節點（Committer Peer）；根據通信不同分為錨節點（Anchor Peer）和主節點（Leading Peer），

背書節點：負責根據事先設定策略對交易進行簽名背書，在鏈碼實體化的時候設定背書策略，指定哪些節點用于背書，當客戶端向節點發起交易背書時，該節點才能有背書功能，否則只是普通的記賬節點，

提交節點：負責維護狀態資料和賬本的副本，

錨節點：錨節點是隨通道存在的，是能被其他通道發現的節點，每個通道上有一個或多個錨節點，

主節點：負責與Orderer通信，把共識后的區塊傳輸到其他節點，

應用程式與節點互動流程如下：

（1）connect to peer：應用程式成功連接到Peer后，呼叫鏈碼向Peer進行提案，

（2）invoke chaincode(proposal)：應用程式提交提案給Peer，執行智能合約，Peer根據提案資訊呼叫鏈碼，

① peer invokes chaincode with proposal：Peer根據提案呼叫智能合約，

② chaincode generates query or update proposal response：智能合約進行查詢或更新操作，同時回傳提案結果，

（3）proposal response：鏈碼進行查詢和更新，然后將提案結果回傳給應用程式，

（4）request that transaction is ordered：應用程式將交易資訊發送給Orderer，

① transactions sent to peers in blocks：Orderer把含有交易資訊的區塊發送給其他Peer，

② peer updates ledger using transction blocks：Peer把交易區塊更新到賬本中，

（5）ledger update event：應用程式接收賬本更新事件，Orderer把含有交易資訊的區塊發送給Peer，

2.4.5 排序

排序（Orderer）指對區塊鏈網路中不同通道產生的交易進行排序，并廣播給Peer，Orderer是以可插拔組件的方式實作的，目前分為Solo和Kafka兩種型別，

Solo：僅有一個Orderer服務節點負責接收交易資訊并進行排序，是最簡單的排序演算法，一般用于測驗環境，

Kafka：是一種高吞吐量的分布式發布訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料，可以配置多個排序節點集群方式，以便使用在生產環境中，Hyperledger Fabric利用Kafka高吞吐、低延時的特性，對交易資訊進行排序處理，實作集群內部支持節點故障容錯，

注意：正式環境中需要使用Kafka搭建，保證資料可靠性和安全性，以下介紹基于Kafka集群和Zookeeper集群的排序服務的原理，

（1）Kafka處理流程如下圖：

① 排序服務（OSN）1已存在交易1（TX1），并發送到Kafka集群中，

② 客戶端（Client）通過Brocadcast（gRPC廣播）介面提交交易2（TX2）到排序服務（OSN）1中，隨后發送到Kafka集群中，

③ 客戶端（Client）通過Brocadcast介面提交交易3（TX3）到排序服務（OSN）0中，隨后發送到Kafka集群中，

④ Kafka集群根據交易提交的時間，按序號3~5（No.3至No.5）依次保存三筆交易，

⑤ 客戶端（Client）通過（gRPC分發）Deliver介面發送分發請求，從排序服務（OSN）2中獲取保存交易1、2、3的區塊4（Block4），至此示例流程結束，

（2）Kafka集群和Zookeeper集群的節點數量規定

① Kafka集群節點的最小值為4，是故障容錯需要的最小數值，4個Kafka節點使得1個節點崩潰后，所有的通道還可以繼續讀寫且創建通道，

② ZooKeeper可以為3、5或7，它必須是一個奇數以避免分裂（Split-brain）情景，同時選擇大于1是為了避免單節點故障，超過7個ZooKeeper節點則是多余的，

（3）排序操作步驟：

① 在網路的創世區塊中寫入Kafka的相關資訊

在生成創世區塊時，需要在configtx.yaml檔案中配置Kafka的相關資訊，如Orderer.OrdererType設定為kafka，Orderer.Kafka.Brokers設定為Kafka集群中的節點IP地址和埠，

② 設定區塊最大容量

設定區塊最大容量是在configtx.yaml檔案中設定Orderer.AbsoluteMaxBytes項的值，以位元組為位置，不包括區塊頭資訊大小，

③ 創建創世區塊

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

④ 配置Kafka集群

1）設定unclean.leader.election.enable為false；

2）設定min.insync.replicas為M（數字），資料提交時會寫入至少M個副本，值的范圍為1

3）設定default.replication.factor為N（數字），表示在Kafka節點上每個通道都保存N個副本的資料，值的范圍為1

4）設定message.max.bytes值，message.max.bytes值應該嚴格小于socket.request.max.bytes的值，socket.request.max.bytes的值默認被設定為100MB；

5）設定replica.fetch.max.bytes值，為每個通道獲取訊息的最大位元組數，

6）設定log.retention.ms值為-1，關倍訓于時間的日志保留方式，

⑤ 所有排序節點都指向創世區塊

在orderer.yaml檔案中配置General.GenesisFile引數，讓排序節點指向步驟（3）中創建的初始區塊，

⑥ 調整輪詢間隔和超時時間

在orderer.yaml檔案中配置Kafka.Retry引數，調整metadata/producer/consumer請求的頻率以及Socket的超時時間，

⑦ 設定排序節點和Kafka集群間為SSL 通信

在orderer.yaml檔案中配置Kafka.TLS引數，確定是否通過TLS（安全傳輸層協議）進行通信，

⑧ 集群啟動順序

先啟動ZooKeeper集群，然后啟動Kafka集群，最后啟動排序節點，

2.4.6 介面

Fabric提供呼叫賬本、智能合約、通道、節點、排序等介面（SDK），方便第三方應用程式的開發，大大地擴展了Fabric的應用場景，

Hyperledger Fabric提供了許多SDK來支持各種編程語言，目前正式發布了Node.js和Java兩種版本的SDK，

Fabric SDK可以為開發人員提供撰寫應用程式的多種操作區塊鏈網路的方式，應用程式可以部署或執行智能合約、監聽網路中產生的事件、接收塊資訊、把交易存盤到賬本等，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/395200.html

標籤：區塊鏈

上一篇：魚池連接礦池失敗問題解決辦法

下一篇：【5. Zookeeper 高級知識點】

【Hyperledger Fabric】學習筆記2——超級賬本介紹

目錄