超級(jí)賬本Fabric的架構(gòu)與設(shè)計(jì)

超級(jí)賬本Fabric項(xiàng)目自誕生之日起就吸引了全球眾多企業(yè)的密切關(guān)注，已經(jīng)先后發(fā)布了兩個(gè)大的版本，0.6實(shí)驗(yàn)版本（2016年9月）和1.0正式版本（2017年7月）。

目前，超級(jí)賬本Fabric架構(gòu)上核心特性主要包括：

• 解耦了原子排序環(huán)節(jié)與其他復(fù)雜處理環(huán)節(jié)，消除了網(wǎng)絡(luò)處理瓶頸，提高可擴(kuò)展性；

• 解耦交易處理節(jié)點(diǎn)的邏輯角色為背書節(jié)點(diǎn)（Endorser）、確認(rèn)節(jié)點(diǎn)（Committer），可以根據(jù)負(fù)載進(jìn)行靈活部署；

• 加強(qiáng)了身份證書管理服務(wù)，作為單獨(dú)的Fabric CA項(xiàng)目，提供更多功能；

• 支持多通道特性，不同通道之間的數(shù)據(jù)彼此隔離，提高隔離安全性；

• 支持可拔插的架構(gòu)，包括共識(shí)、權(quán)限管理、加解密、賬本機(jī)制都模塊，支持多種類型；

• 引入系統(tǒng)鏈碼來實(shí)現(xiàn)區(qū)塊鏈系統(tǒng)的處理，支持可編程和第三方實(shí)現(xiàn)。

超級(jí)賬本Fabric的整體架構(gòu)如下圖所示。

Fabric整體架構(gòu)

Fabric為應(yīng)用提供了gRPC API，以及封裝API的SDK供應(yīng)用調(diào)用。應(yīng)用可以通過SDK訪問Fabric網(wǎng)絡(luò)中的多種資源，包括賬本、交易、鏈碼、事件、權(quán)限管理等。應(yīng)用開發(fā)者只需要跟這些資源打交道即可，無需關(guān)心如何實(shí)現(xiàn)。其中，賬本是最核心的結(jié)構(gòu)，記錄應(yīng)用信息，應(yīng)用則通過發(fā)起交易來向賬本中記錄數(shù)據(jù)。交易執(zhí)行的邏輯通過鏈碼來承載。整個(gè)網(wǎng)絡(luò)運(yùn)行中發(fā)生的事件可以被應(yīng)用訪問，以觸發(fā)外部流程甚至其他系統(tǒng)。權(quán)限管理則負(fù)責(zé)整個(gè)過程中的訪問控制。賬本和交易進(jìn)一步地依賴核心的區(qū)塊鏈結(jié)構(gòu)、數(shù)據(jù)庫、共識(shí)機(jī)制等技術(shù)；鏈碼則依賴容器、狀態(tài)機(jī)等技術(shù)；權(quán)限管理利用了已有的PKI體系、數(shù)字證書、加解密算法等諸多安全技術(shù)。底層由多個(gè)節(jié)點(diǎn)組成P2P網(wǎng)絡(luò)，通過gRPC通道進(jìn)行交互，利用Gossip協(xié)議進(jìn)行同步。

層次化結(jié)構(gòu)提高了架構(gòu)的可擴(kuò)展和可插拔性，方便開發(fā)者以模塊為單位進(jìn)行開發(fā)。

超級(jí)賬本Fabric根據(jù)交易過程中不同環(huán)節(jié)的功能，在邏輯上將節(jié)點(diǎn)角色解耦為Endorser和Committer，讓不同類型節(jié)點(diǎn)可以關(guān)注處理不同類型的工作負(fù)載。典型的交易處理過程如下圖所示。

示例交易處理過程

在整個(gè)交易過程中，各個(gè)組件的功能主要為：

• 客戶端（App）：客戶端應(yīng)用使用SDK來跟Fabric網(wǎng)絡(luò)打交道。首先，客戶端從CA獲取合法的身份證書來加入到網(wǎng)絡(luò)內(nèi)的應(yīng)用通道。發(fā)起正式交易前，需要先構(gòu)造交易提案（Proposal）提交給Endorser進(jìn)行背書（通過EndorserClient提供的ProcessProposal(ctx context.Context, signedProp *pb.SignedProposal)(*pb.ProposalResponse,error)接口）；客戶端收集到足夠（背書策略決定）的背書支持后可以利用背書構(gòu)造一個(gè)合法的交易請(qǐng)求，發(fā)給Orderer進(jìn)行排序（通過BroadcastClient提供的Send(env *cb.Envelope)error接口）處理?？蛻舳诉€可以通過事件機(jī)制來監(jiān)聽網(wǎng)絡(luò)中消息，來獲知交易是否被成功接收。命令行客戶端的主要實(shí)現(xiàn)代碼在peer/chaincode目錄下。

• Endorser節(jié)點(diǎn)：主要提供ProcessProposal(ctx context.Context,signedProp *pb.SignedProposal)(*pb.ProposalResponse,error)方法（代碼在core/endorser/endorser.go文件）供客戶端調(diào)用，完成對(duì)交易提案的背書（目前主要是簽名）處理。收到來自客戶端的交易提案后，首先進(jìn)行合法性和ACL權(quán)限檢查，檢查通過則模擬運(yùn)行交易，對(duì)交易導(dǎo)致的狀態(tài)變化（以讀寫集形式記錄，包括所讀狀態(tài)的鍵和版本，所寫狀態(tài)的鍵值）進(jìn)行背書并返回結(jié)果給客戶端。注意網(wǎng)絡(luò)中可以只有部分節(jié)點(diǎn)擔(dān)任Endorser角色。主要代碼在core/endorser目錄下;

• Committer節(jié)點(diǎn)：負(fù)責(zé)維護(hù)區(qū)塊鏈和賬本結(jié)構(gòu)（包括狀態(tài)DB、歷史DB、索引DB等）。該節(jié)點(diǎn)會(huì)定期地從Orderer獲取排序后的批量交易區(qū)塊結(jié)構(gòu)，對(duì)這些交易進(jìn)行落盤前的最終檢查（包括交易消息結(jié)構(gòu)、簽名完整性、是否重復(fù)、讀寫集合版本是否匹配等）。檢查通過后執(zhí)行合法的交易，將結(jié)果寫入賬本，同時(shí)構(gòu)造新的區(qū)塊，更新區(qū)塊中BlockMetadata[2]（TRANSACTIONS_FILTER）記錄交易是否合法等信息。同一個(gè)物理節(jié)點(diǎn)可以僅作為Committer角色運(yùn)行，也可以同時(shí)擔(dān)任Endorser和Committer這兩種角色。主要實(shí)現(xiàn)代碼在core/committer目錄下;

• Orderer：僅負(fù)責(zé)排序。為網(wǎng)絡(luò)中所有合法交易進(jìn)行全局排序，并將一批排序后的交易組合生成區(qū)塊結(jié)構(gòu)。Orderer一般不需要跟賬本和交易內(nèi)容直接打交道。主要實(shí)現(xiàn)代碼在orderer目錄下。對(duì)外主要提供Broadcast(srv ab.AtomicBroadcast_BroadcastServer)error和Deliver(srv ab.AtomicBroadcast_DeliverServer)error兩個(gè)RPC方法（代碼在orderer/server.go文件）;

• CA：負(fù)責(zé)網(wǎng)絡(luò)中所有證書的管理（分發(fā)、撤銷等），實(shí)現(xiàn)標(biāo)準(zhǔn)的PKI架構(gòu)。主要代碼在單獨(dú)的fabric-ca項(xiàng)目中。CA在簽發(fā)證書后，自身不參與到網(wǎng)絡(luò)中的交易過程。

核心概念與組件

超級(jí)賬本Fabric采用了模塊化功能設(shè)計(jì)，整體的功能模塊結(jié)構(gòu)如下圖所示。

Fabric核心組件

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

• 網(wǎng)絡(luò)層：面向系統(tǒng)管理人員。實(shí)現(xiàn)P2P網(wǎng)絡(luò)，提供底層構(gòu)建區(qū)塊鏈網(wǎng)絡(luò)的基本能力，包括代表不同角色的節(jié)點(diǎn)和服務(wù);

• 共識(shí)機(jī)制和權(quán)限管理：面向聯(lián)盟和組織的管理人員?；诰W(wǎng)絡(luò)層的連通，實(shí)現(xiàn)共識(shí)機(jī)制和權(quán)限管理，提供分布式賬本的基礎(chǔ);

• 業(yè)務(wù)層：面向業(yè)務(wù)應(yīng)用開發(fā)人員?；诜植际劫~本，支持鏈碼、交易等跟業(yè)務(wù)相關(guān)的功能模塊，提供更高一層的應(yīng)用開發(fā)支持。

下面介紹網(wǎng)絡(luò)層相關(guān)組件的功能和作用。

網(wǎng)絡(luò)層相關(guān)組件

網(wǎng)絡(luò)層通過軟、硬件設(shè)備，實(shí)現(xiàn)了對(duì)分布式賬本結(jié)構(gòu)的連通支持，包括節(jié)點(diǎn)、排序者、客戶端等參與角色，還包括成員身份管理、Gossip協(xié)議等支持組件。

節(jié)點(diǎn)（Peer）的概念最早來自P2P分布式網(wǎng)絡(luò)，意味著在網(wǎng)絡(luò)中擔(dān)任一定職能的服務(wù)或軟件。節(jié)點(diǎn)功能可能是對(duì)等一致的，也可能是分工合作的。在超級(jí)賬本Fabric網(wǎng)絡(luò)中，Peer意味著在網(wǎng)絡(luò)中負(fù)責(zé)接受交易請(qǐng)求、維護(hù)一致賬本的各個(gè)fabric-peer實(shí)例。這些實(shí)例可能運(yùn)行在裸機(jī)、虛擬機(jī)甚至容器中。節(jié)點(diǎn)之間彼此通過gRPC消息進(jìn)行通信。按照功能角色劃分，Peer可以包括三種類型：

• Endorser（背書節(jié)點(diǎn)）：負(fù)責(zé)對(duì)來自客戶端的交易提案進(jìn)行檢查和背書；

• Committer（確認(rèn)節(jié)點(diǎn)）：負(fù)責(zé)檢查交易請(qǐng)求，執(zhí)行交易并維護(hù)區(qū)塊鏈和賬本結(jié)構(gòu)；

• Submitter（提交節(jié)點(diǎn)）：負(fù)責(zé)接收交易，轉(zhuǎn)發(fā)給排序者，目前未單獨(dú)出現(xiàn)。

這些角色是功能上的劃分，彼此并不相互排斥。一般情況下，網(wǎng)絡(luò)中所有節(jié)點(diǎn)都具備Committer功能；部分節(jié)點(diǎn)具有Endorser功能；Submitter功能則往往集成在客戶端（SDK）進(jìn)行實(shí)現(xiàn)。

Peer節(jié)點(diǎn)相關(guān)的主要數(shù)據(jù)結(jié)構(gòu)包括PeerEndpoint和endorserClient。前者代表一個(gè)Peer節(jié)點(diǎn)在網(wǎng)絡(luò)中的接入端點(diǎn)；后者實(shí)現(xiàn)EndorserClient接口，代表連接到Peer節(jié)點(diǎn)的客戶端句柄，提供對(duì)Endorser角色實(shí)現(xiàn)的ProcessProposal(ctx context.Context,signedProp *pb.SignedProposal)(*pb.ProposalResponse, error)方法的訪問。如下圖所示。

Peer節(jié)點(diǎn)相關(guān)數(shù)據(jù)結(jié)構(gòu)

排序者（Orderer），或稱為排序節(jié)點(diǎn)，負(fù)責(zé)對(duì)所收到的交易在網(wǎng)絡(luò)中進(jìn)行全局排序。Orderer主要提供了Broadcast(srv ab.AtomicBroadcast_BroadcastServer) error和Deliver(srv ab.AtomicBroadcast_DeliverServer) error兩個(gè)接口。前者代表客戶端將數(shù)據(jù)（交易）發(fā)給Orderer，后者代表從Orderer獲取到排序后構(gòu)造的區(qū)塊結(jié)構(gòu)?？蛻舳丝梢允褂胊tomicBroadcastClient結(jié)構(gòu)訪問這兩個(gè)接口。atomicBroadcastClient結(jié)構(gòu)如下圖所示，維持了一個(gè)gRPC的雙向通道。

atomicBroadcastClient結(jié)構(gòu)

Orderer可以支持多通道。不同通道之間彼此隔離，通道內(nèi)交易相關(guān)信息將僅發(fā)往加入到通道內(nèi)的Peer（同樣基于gRPC消息），從而提高隱私性和安全性。在目前的設(shè)計(jì)中，所有的交易信息都會(huì)從Orderer經(jīng)過，因此，Orderer節(jié)點(diǎn)在網(wǎng)絡(luò)中必須處于可靠、可信的地位。

從功能上看，Orderer的目的是對(duì)網(wǎng)絡(luò)中的交易分配全局唯一的序號(hào)，實(shí)際上并不需要交易相關(guān)的具體數(shù)據(jù)內(nèi)容。因此為了進(jìn)一步提高隱私性，發(fā)往Orderer的可以不是完整的交易數(shù)據(jù)，而是部分信息，比如交易加密處理后的結(jié)果，或者僅僅是交易的Hash值、Id信息等。這些改進(jìn)設(shè)計(jì)會(huì)降低對(duì)Orderer節(jié)點(diǎn)可靠性和安全性的需求。社區(qū)目前也已經(jīng)有了一些類似的設(shè)計(jì)討論（參考FAB-1151：Side DB-Private Channel Data）。

客戶端是用戶和應(yīng)用跟區(qū)塊鏈網(wǎng)絡(luò)打交道的橋梁。客戶端主要包括兩大職能：

• 操作Fabric網(wǎng)絡(luò)：包括更新網(wǎng)絡(luò)配置、啟停節(jié)點(diǎn)等；

• 操作運(yùn)行在網(wǎng)絡(luò)中的鏈碼：包括安裝、實(shí)例化、發(fā)起交易調(diào)用鏈碼等。

這些操作需要跟Peer節(jié)點(diǎn)和Orderer節(jié)點(diǎn)打交道。特別是鏈碼實(shí)例化、交易等涉及到共識(shí)的操作，需要跟Orderer交互，因此，客戶端往往也需要具備Submitter的能力。網(wǎng)絡(luò)中的Peer和Orderer等節(jié)點(diǎn)則對(duì)應(yīng)提供了gRPC遠(yuǎn)程服務(wù)訪問接口，供客戶端進(jìn)行調(diào)用。目前，除了基于命令行的客戶端之外，超級(jí)賬本Fabric已經(jīng)擁有了多種語言的SDK。這些SDK封裝了對(duì)底層gRPC接口的調(diào)用，可以提供更完善的客戶端和開發(fā)支持，包括Node.Js、Python、Java、Go等多種實(shí)現(xiàn)。

CA節(jié)點(diǎn)（Fabric-CA）負(fù)責(zé)對(duì)Fabric網(wǎng)絡(luò)中的成員身份進(jìn)行管理。Fabric網(wǎng)絡(luò)目前采用數(shù)字證書機(jī)制來實(shí)現(xiàn)對(duì)身份的鑒別和權(quán)限控制，CA節(jié)點(diǎn)則實(shí)現(xiàn)了PKI服務(wù)，主要負(fù)責(zé)對(duì)身份證書進(jìn)行管理，包括生成、撤銷等。需要注意的是，CA節(jié)點(diǎn)可以提前簽發(fā)身份證書，發(fā)送給對(duì)應(yīng)的成員實(shí)體，這些實(shí)體在部署證書后即可訪問網(wǎng)絡(luò)中的各項(xiàng)資源。后續(xù)訪問過程中，實(shí)體無須再次向CA節(jié)點(diǎn)進(jìn)行請(qǐng)求。因此，CA節(jié)點(diǎn)的處理過程跟網(wǎng)絡(luò)中交易的處理過程是完全解耦開的，不會(huì)造成性能瓶頸。

Fabric網(wǎng)絡(luò)中的節(jié)點(diǎn)之間通過Gossip協(xié)議來進(jìn)行狀態(tài)同步和數(shù)據(jù)分發(fā)。Gossip協(xié)議是P2P領(lǐng)域的常見協(xié)議，用于進(jìn)行網(wǎng)絡(luò)內(nèi)多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)分發(fā)或信息交換。由于其設(shè)計(jì)簡單，容易實(shí)現(xiàn)，同時(shí)容錯(cuò)性比較高，而被廣泛應(yīng)用到了許多分布式系統(tǒng)，例如Cassandra采用它來實(shí)現(xiàn)集群失敗檢測和負(fù)載均衡。Gossip協(xié)議的基本思想十分簡單，數(shù)據(jù)發(fā)送方從網(wǎng)絡(luò)中隨機(jī)選取若干節(jié)點(diǎn)，將數(shù)據(jù)發(fā)送過去；接收方重復(fù)這一過程（往往只選擇發(fā)送方之外節(jié)點(diǎn)進(jìn)行傳播）。這一過程持續(xù)下去，網(wǎng)絡(luò)中所有節(jié)點(diǎn)最終（時(shí)間復(fù)雜度為節(jié)點(diǎn)總個(gè)數(shù)的對(duì)數(shù)）都會(huì)達(dá)到一致。數(shù)據(jù)傳輸?shù)姆较蚩梢允前l(fā)送方發(fā)送或獲取方拉取。

在Fabric網(wǎng)絡(luò)中，節(jié)點(diǎn)會(huì)定期地利用Gossip協(xié)議發(fā)送它看到的賬本的最新的數(shù)據(jù)，并對(duì)發(fā)送消息進(jìn)行簽名認(rèn)證。通過使用該協(xié)議，主要實(shí)現(xiàn)如下功能：

• 通道內(nèi)成員的探測：新加入通道的節(jié)點(diǎn)可以獲知其他節(jié)點(diǎn)的信息，并發(fā)送Alive信息宣布在線；離線節(jié)點(diǎn)經(jīng)過一段時(shí)間后可以被其他節(jié)點(diǎn)感知。

• 節(jié)點(diǎn)之間同步數(shù)據(jù)：多個(gè)節(jié)點(diǎn)之間彼此同步數(shù)據(jù)，保持一致性。另外，Leader節(jié)點(diǎn)從Orderer拉取區(qū)塊數(shù)據(jù)后，也可以通過Gossip傳播給通道內(nèi)其他、節(jié)點(diǎn)。