超級賬本Fabric專案自誕生之日起就吸引了全球眾多企業的密切關注，已經先後釋出了兩個大的版本，0.6實驗版本（2016年9月）和1.0正式版本（2017年7月）。

目前，超級賬本Fabric架構上核心特性主要包括：

• 解耦了原子排序環節與其他複雜處理環節，消除了網路處理瓶頸，提高可擴充套件性；
• 解耦交易處理節點的邏輯角色為背書節點（Endorser）、確認節點（Committer），可以根據負載進行靈活部署；
• 加強了身份證書管理服務，作為單獨的Fabric CA專案，提供更多功能；
• 支援多通道特性，不同通道之間的資料彼此隔離，提高隔離安全性；
• 支援可拔插的架構，包括共識、許可權管理、加解密、賬本機制都模組，支援多種型別；
• 引入系統鏈碼來實現區塊鏈系統的處理，支援可程式設計和第三方實現。

超級賬本Fabric的整體架構如下圖所示。

Fabric整體架構

Fabric為應用提供了gRPC API，以及封裝API的SDK供應用呼叫。應用可以通過SDK訪問Fabric網路中的多種資源，包括賬本、交易、鏈碼、事件、許可權管理等。應用開發者只需要跟這些資源打交道即可，無需關心如何實現。其中，賬本是最核心的結構，記錄應用資訊，應用則通過發起交易來向賬本中記錄資料。交易執行的邏輯通過鏈碼來承載。整個網路執行中發生的事件可以被應用訪問，以觸發外部流程甚至其他系統。許可權管理則負責整個過程中的訪問控制。賬本和交易進一步地依賴核心的區塊鏈結構、資料庫、共識機制等技術；鏈碼則依賴容器、狀態機等技術；許可權管理利用了已有的PKI體系、數字證書、加解密演算法等諸多安全技術。底層由多個節點組成P2P網路，通過gRPC通道進行互動，利用Gossip協議進行同步。

層次化結構提高了架構的可擴充套件和可插拔性，方便開發者以模組為單位進行開發。

超級賬本Fabric根據交易過程中不同環節的功能，在邏輯上將節點角色解耦為Endorser和Committer，讓不同型別節點可以關注處理不同型別的工作負載。典型的交易處理過程如下圖所示。

示例交易處理過程

在整個交易過程中，各個元件的功能主要為：

• 客戶端（App）：客戶端應用使用SDK來跟Fabric網路打交道。首先，客戶端從CA獲取合法的身份證書來加入到網路內的應用通道。發起正式交易前，需要先構造交易提案（Proposal）提交給Endorser進行背書（通過EndorserClient提供的ProcessProposal(ctx context.Context, signedProp *pb.SignedProposal)(*pb.ProposalResponse,error)介面）；客戶端收集到足夠（背書策略決定）的背書支援後可以利用背書構造一個合法的交易請求，發給Orderer進行排序（通過BroadcastClient提供的Send(env *cb.Envelope)error介面）處理。客戶端還可以通過事件機制來監聽網路中訊息，來獲知交易是否被成功接收。命令列客戶端的主要實現程式碼在peer/chaincode目錄下。

• Endorser節點：主要提供ProcessProposal(ctx context.Context,signedProp *pb.SignedProposal)(*pb.ProposalResponse,error)方法（程式碼在core/endorser/endorser.go檔案）供客戶端呼叫，完成對交易提案的背書（目前主要是簽名）處理。收到來自客戶端的交易提案後，首先進行合法性和ACL許可權檢查，檢查通過則模擬執行交易，對交易導致的狀態變化（以讀寫集形式記錄，包括所讀狀態的鍵和版本，所寫狀態的鍵值）進行背書並返回結果給客戶端。注意網路中可以只有部分節點擔任Endorser角色。主要程式碼在core/endorser目錄下;

• Committer節點：負責維護區塊鏈和賬本結構（包括狀態DB、歷史DB、索引DB等）。該節點會定期地從Orderer獲取排序後的批量交易區塊結構，對這些交易進行落盤前的最終檢查（包括交易訊息結構、簽名完整性、是否重複、讀寫集合版本是否匹配等）。檢查通過後執行合法的交易，將結果寫入賬本，同時構造新的區塊，更新區塊中BlockMetadata[2]（TRANSACTIONS_FILTER）記錄交易是否合法等資訊。同一個物理節點可以僅作為Committer角色執行，也可以同時擔任Endorser和Committer這兩種角色。主要實現程式碼在core/committer目錄下;

• Orderer：僅負責排序。為網路中所有合法交易進行全域性排序，並將一批排序後的交易組合生成區塊結構。Orderer一般不需要跟賬本和交易內容直接打交道。主要實現程式碼在orderer目錄下。對外主要提供Broadcast(srv ab.AtomicBroadcast_BroadcastServer)error和Deliver(srv ab.AtomicBroadcast_DeliverServer)error兩個RPC方法（程式碼在orderer/server.go檔案）;

• CA：負責網路中所有證書的管理（分發、撤銷等），實現標準的PKI架構。主要程式碼在單獨的fabric-ca專案中。CA在簽發證書後，自身不參與到網路中的交易過程。

核心概念與元件

超級賬本Fabric採用了模組化功能設計，整體的功能模組結構如下圖所示。

Fabric核心元件

超級賬本Fabric面向不同的開發人員提供了不同層面的功能，自下而上可以分為三層：

• 網路層：面向系統管理人員。實現P2P網路，提供底層構建區塊鏈網路的基本能力，包括代表不同角色的節點和服務;
• 共識機制和許可權管理：面向聯盟和組織的管理人員。基於網路層的連通，實現共識機制和許可權管理，提供分散式賬本的基礎;
• 業務層：面向業務應用開發人員。基於分散式賬本，支援鏈碼、交易等跟業務相關的功能模組，提供更高一層的應用開發支援。

下面介紹網路層相關元件的功能和作用。

網路層相關元件

網路層通過軟、硬體裝置，實現了對分散式賬本結構的連通支援，包括節點、排序者、客戶端等參與角色，還包括成員身份管理、Gossip協議等支援元件。

節點（Peer）的概念最早來自P2P分散式網路，意味著在網路中擔任一定職能的服務或軟體。節點功能可能是對等一致的，也可能是分工合作的。在超級賬本Fabric網路中，Peer意味著在網路中負責接受交易請求、維護一致賬本的各個fabric-peer例項。這些例項可能執行在裸機、虛擬機器甚至容器中。節點之間彼此通過gRPC訊息進行通訊。按照功能角色劃分，Peer可以包括三種類型：

• Endorser（背書節點）：負責對來自客戶端的交易提案進行檢查和背書；
• Committer（確認節點）：負責檢查交易請求，執行交易並維護區塊鏈和賬本結構；
• Submitter（提交節點）：負責接收交易，轉發給排序者，目前未單獨出現。

這些角色是功能上的劃分，彼此並不相互排斥。一般情況下，網路中所有節點都具備Committer功能；部分節點具有Endorser功能；Submitter功能則往往整合在客戶端（SDK）進行實現。

Peer節點相關的主要資料結構包括PeerEndpoint和endorserClient。前者代表一個Peer節點在網路中的接入端點；後者實現EndorserClient介面，代表連線到Peer節點的客戶端控制代碼，提供對Endorser角色實現的ProcessProposal(ctx context.Context,signedProp *pb.SignedProposal)(*pb.ProposalResponse, error)方法的訪問。如下圖所示。

Peer節點相關資料結構

排序者（Orderer），或稱為排序節點，負責對所收到的交易在網路中進行全域性排序。Orderer主要提供了Broadcast(srv ab.AtomicBroadcast_BroadcastServer) error和Deliver(srv ab.AtomicBroadcast_DeliverServer) error兩個介面。前者代表客戶端將資料（交易）發給Orderer，後者代表從Orderer獲取到排序後構造的區塊結構。客戶端可以使用atomicBroadcastClient結構訪問這兩個介面。atomicBroadcastClient結構如下圖所示，維持了一個gRPC的雙向通道。

atomicBroadcastClient結構

Orderer可以支援多通道。不同通道之間彼此隔離，通道內交易相關資訊將僅發往加入到通道內的Peer（同樣基於gRPC訊息），從而提高隱私性和安全性。在目前的設計中，所有的交易資訊都會從Orderer經過，因此，Orderer節點在網路中必須處於可靠、可信的地位。

從功能上看，Orderer的目的是對網路中的交易分配全域性唯一的序號，實際上並不需要交易相關的具體資料內容。因此為了進一步提高隱私性，發往Orderer的可以不是完整的交易資料，而是部分資訊，比如交易加密處理後的結果，或者僅僅是交易的Hash值、Id資訊等。這些改進設計會降低對Orderer節點可靠性和安全性的需求。社群目前也已經有了一些類似的設計討論（參考FAB-1151：Side DB-Private Channel Data）。

客戶端是使用者和應用跟區塊鏈網路打交道的橋樑。客戶端主要包括兩大職能：

• 操作Fabric網路：包括更新網路配置、啟停節點等；
• 操作執行在網路中的鏈碼：包括安裝、例項化、發起交易呼叫鏈碼等。

這些操作需要跟Peer節點和Orderer節點打交道。特別是鏈碼例項化、交易等涉及到共識的操作，需要跟Orderer互動，因此，客戶端往往也需要具備Submitter的能力。網路中的Peer和Orderer等節點則對應提供了gRPC遠端服務訪問介面，供客戶端進行呼叫。目前，除了基於命令列的客戶端之外，超級賬本Fabric已經擁有了多種語言的SDK。這些SDK封裝了對底層gRPC介面的呼叫，可以提供更完善的客戶端和開發支援，包括Node.Js、Python、Java、Go等多種實現。

CA節點（Fabric-CA）負責對Fabric網路中的成員身份進行管理。Fabric網路目前採用數字證書機制來實現對身份的鑑別和許可權控制，CA節點則實現了PKI服務，主要負責對身份證書進行管理，包括生成、撤銷等。需要注意的是，CA節點可以提前簽發身份證書，傳送給對應的成員實體，這些實體在部署證書後即可訪問網路中的各項資源。後續訪問過程中，實體無須再次向CA節點進行請求。因此，CA節點的處理過程跟網路中交易的處理過程是完全解耦開的，不會造成效能瓶頸。

Fabric網路中的節點之間通過Gossip協議來進行狀態同步和資料分發。Gossip協議是P2P領域的常見協議，用於進行網路內多個節點之間的資料分發或資訊交換。由於其設計簡單，容易實現，同時容錯性比較高，而被廣泛應用到了許多分散式系統，例如Cassandra採用它來實現叢集失敗檢測和負載均衡。Gossip協議的基本思想十分簡單，資料傳送方從網路中隨機選取若干節點，將資料傳送過去；接收方重複這一過程（往往只選擇傳送方之外節點進行傳播）。這一過程持續下去，網路中所有節點最終（時間複雜度為節點總個數的對數）都會達到一致。資料傳輸的方向可以是傳送方傳送或獲取方拉取。

在Fabric網路中，節點會定期地利用Gossip協議傳送它看到的賬本的最新的資料，並對傳送訊息進行簽名認證。通過使用該協議，主要實現如下功能：

• 通道內成員的探測：新加入通道的節點可以獲知其他節點的資訊，併發送Alive資訊宣佈線上；離線節點經過一段時間後可以被其他節點感知。
• 節點之間同步資料：多個節點之間彼此同步資料，保持一致性。另外，Leader節點從Orderer拉取區塊資料後，也可以通過Gossip傳播給通道內其他、節點。
  推薦閱讀：

本文節選自圖書《區塊鏈原理、設計與應用》，已獲機械工業出版社 華章IT授權。

作者介紹：
楊保華，博士，畢業於清華大學。超級賬本（Hyperledger）大中華區技術工作組主席，IBM大中華區Blockchain技術社群首席顧問，資深研究員。曾主持多個大規模系統平臺的架構設計和研發實施，是區塊鏈、雲端計算、大資料等技術的早期研究者和實踐者。他熱愛開源技術，曾貢獻OpenStack、OpenDaylight等開源專案，是超級賬本Fabric專案核心設計和開發者，也是Cello和Fabric-SDK-Py專案的發起人。個人主頁為https://yeasy.github.com。