超級賬本：基本架構及運作機制

最新 05-03

區塊鏈大致可分為公有鏈（典型代表為比特幣和以太坊）和聯盟鏈（私有鏈）。聯盟鏈是現有中心化商業團體聯盟之間（或團體內部）進行商業活動的手段和渠道。

HyperledgerFabric是由IBM 牽頭髮起的一個代表性的聯盟鏈項目，於 15 年底移交給Linux 基金會維護，成為開源項目。Hyperledger 基金會的成員包括IBM，Intel，思科等。

Fabric 架構演變

Fabric 的架構目前經歷了兩個版本的演進，最初的 0.6 版本只能被用來做商業驗證，無法被應用於真實場景中。主要原因就是結構簡單，基本所有的功能都集中在 peer 節點，在擴展性、安全性和隔離性方面有著天然的不足，如圖1所示。在後來推出的 1.0 正式版中，將 peer 節點的功能進行分拆，把共識服務從 peer 節點剝離，獨立為 Orderer 節點提供可插拔共識服務。更為重要的一個變化就是加入了多通道（multi-channel）功能，可實現多業務隔離，因此在 0.6 版本的基礎上有了質的飛躍。

圖1 Fabric v0.6 架構

概念術語

Auditability（審計性）：在一定許可權和許可下，可以對鏈上的交易進行審計和檢查。

Certificate Authority（CA）：負責身份許可權管理，又叫 MemberService 或 Identity Service。

Chaincode（鏈碼）：區塊鏈上的應用代碼，擴展自「智能合約」的概念，支持Go、Node.js 等編程語言，運行在隔離的容器環境中（Docker）。

Orderer（排序節點）：Fabric 1.0 架構中的共識服務角色，可以對交易進行排序，批量打包，生成區塊，發給Peer節點。一個區塊鏈網路中有多個Orderer節點，它們共同提供排序服務。排序服務可以通過不同的方式實現，從一個中心化的服務（被用於開發和測試，如Solo）,到分散式協議（如Kafka）。

Endorser（背書節點）：Fabric 1.0 架構中的一類 peer 節點角色，負責檢驗某個交易是否合法，是否願意為之簽名背書。

Committer（提交節點）：Fabric 1.0 架構中的另一類peer 節點角色，負責對 orderer 排序後的交易進行檢查，選擇合法的交易執行並寫入存儲。

Enrollment Certificate Authority（ECA，註冊 CA）：負責成員身份相關證書管理的 CA。

Transaction Certificate Authority（TCA，交易 CA）：負責維護交易相關證書管理的 CA。

World State（世界狀態）：一個鍵值（K-V）資料庫，用於存放鏈碼（Chaincode）執行過程中涉及到的狀態變數。

Fabric v1.0 架構

Fabric v1.0 的架構如圖2所示。

圖2 Fabric v1.0 架構

Fabric聯盟鏈中有兩種類型的節點：Peer節點和Orderer節點。Chaincode部署在Peer節點上，它對賬本進行讀寫操作。一個Peer節點可以充當多種角色，如背書者endorser,提交者committer。一個區塊鏈網路中會有多個Peer節點。

Orderer提供了通向客戶端和Peer節點的共享通信通道。提供了包含交易的消息廣播服務（broadcast和deliver）。客戶端可以通過這個通道向所有的節點廣播（broadcast）消息。通道可以向連接到該通道的節點投遞(deliver)消息。

Orderer服務支持多通道（multi-channel）。客戶端和Peer節點可以連接到一個給定的通道，並通過給定的通道發送和接收消息。多通道使得給定的peer集合接收包含相關交易的區塊，從而與其他交易完全隔離，實現數據隔離和保密。如圖3所示，peer 1, peer 2和peerN訂閱紅色通道，共同維護紅色賬本; peer 1和peer N訂閱藍色通道並維護藍色賬本; peer 2和peer 訂閱黑色通道上，共同維護黑色賬本。

圖3 多通道

鏈碼（Chaincode）

鏈碼可以認為是 Fabric 提供的智能合約，是上層應用與底層區塊鏈平台交互的媒介。

所有的鏈碼都繼承兩個介面，init和 invoke。init 介面用於初始化合約，在整個鏈碼的生命周期里，該介面僅僅執行一次。invoke 介面是編寫業務邏輯的唯一入口，雖然只有一個入口，但是可以根據參數傳遞的不同自由區分不同業務邏輯。合約介面能獲得數據分為三類：合約輸入參數；與狀態資料庫和歷史資料庫交互（區塊鏈底層可以看做一個鍵值對資料庫，合約就是對資料庫中鍵值的增刪改查）；與其他合約的交互。

Fabric 1.0交易流程

Fabric上的交易（transction）交易分兩種：部署交易和調用交易。

部署交易：把Chaincode部署到peer節點上並準備好被調用，當一個部署交易成功執行時，Chaincode就被部署到peer節點上。

調用交易：客戶端應用程序通過Fabric提供的API調用先前已部署好的某個chaincode中的函數執行交易，並相應地讀取和寫入K-V資料庫，返回成功或者失敗。

圖4 交易流程

（1）客戶端構造交易提案

客戶端應用程序利用任意SDK構造交易提案propose。該提案是一個調用智能合約功能函數的請求，用來確認哪些數據可以讀取或寫入賬本。客戶端把交易提案發送給一個或多個Peer節點，交易提案中包含本次交易要調用的合約標識、合約方法和參數信息以及客戶端簽名等。

（2）背書節點（Endorser）模擬執行交易

背書節點endorser收到交易提案後，驗證簽名並確定提交者是否有權執行操作。背書節點將交易提案的參數作為輸入，在當前狀態K-V資料庫上執行交易，生成包含執行返回值、讀操作集合和寫操作集合的交易結果（此時不會更新賬本），這些值的集合、背書節點的簽名和背書結果（YES / NO）作為提案的結果返回給客戶端SDK，SDK解析這些信息判斷是否應用於後續的交易。

（3）客戶端把交易發送到共識服務節點（Orderers）

應用程序（SDK）驗證背書節點簽名，並比較各節點返回的提案結果，判斷提案結果是否一致以及是否參照指定的背書策略執行。客戶端收到各個背書節點的應答後，打包到一起組成一個交易並簽名，發送給Orderers。

（4）共識排序，生成新區塊，提交交易

Orderers對接收到的交易進行共識排序，然後按照區塊生成策略，將一批交易打包到一起，生成新的區塊，調用deliver API投遞消息，發送給提交節點（Committer）。Committer收到區塊後，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區塊鏈的狀態，完成後將區塊追加到本地的區塊鏈，並修改K-V狀態資料庫。

補充說明

超級賬本V1.0將執行鏈碼（chaincode，即智能合約）的節點（這些節點稱作peers）與決定出塊順序（即consensus）的節點（這些節點稱作orderers）相分離。每個peer維護分散式賬本的一個copy，orderers則僅提供共識排序服務，而不必維護賬本的copy。

clients首先要將交易提交給peers的一個子集（稱為背書者，endorsers）執行chaincode。必須有足夠多（sufficient）的endorsers背書一致後（比如N個endorsers必須有K個一致），clients才將更新後的狀態以及背書籤名等提交給orderers。orderers通過共識協議輸出block的排序。最後，所有的peers再對背書進行驗證（主要是驗證交易狀態的更新的確已經得到足夠多的endorsers背書）。從而：（1）鏈碼的執行可以在共識排序前完成（好處是peers的多個子集可以並行處理多筆交易，提高效率）；（2）不需要所有的peers都執行所有的鏈碼（不同鏈碼可以指定不同的endorsers，從而允許平行執行；作為對比，公有鏈比如以太坊，交易是串列執行sequentialexecution的）。

clients判斷提案結果是否一致主要是為了消除非確定性的影響（eliminate the effects of non-determinism）。這主要是因為交易的執行可能因為種種原因而分叉，如果client發現大多數endorsers的執行結果不一致時，它就會認為該交易的結果是非確定性的，這筆交易也就作廢了。

Fabric的優勢

Fabric採用模塊化架構把交易處理劃分為3個階段：通過Chaincode進行分散式業務邏輯處理和協商（endorsers）；交易排序(orderders)；交易的驗證和提交(committers)。這樣劃分帶來的好處：不同的階段由不同的節點（角色endorsers, orderders, committers）參與，不需要全網的節點都參與。網路的性能和擴展性得到優化。Peer節點和Orderder節點可以獨立擴展，並可以動態增加。此外，Fabric提供可插拔架構，其共識機制和加密演算法均是可插拔的，可以根據實際情況選擇替換。

參考:

2.HyperledgerFabric 架構設計整理 https://www.jianshu.com/p/ac3362c97eaa

3.http://www.infoq.com/cn/articles/hyperledger-fabric-architecture-trap

4.https://github.com/hyperledger/fabric

作者簡介