超級賬本架構分析
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在簽發證書后,自身不參與到網絡中的交易過程。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%