Fabric架構演變之路

Hyperledger Fabric是目前主流的開源聯盟鏈產品之一，自2016年5月12日開闢程式碼倉庫之日起，已有快3年的時間了，產品趨於穩定，功能也越來越完善，正在適配不同業務場景下的需求。 縱觀Fabric的釋出歷程，在v0.6.1-preview版本至v1.0.0的版本遷移過程中架構發生了明顯的變化，在v1.0.0之後每個小版本中加入了一些新的feature，來支援不同的業務場景以及完善相應的功能。接下來從個人角度來談談Fabric架構變遷過程中的一點思考。

Fabric v0.6

v0.6版本的技術架構在整個發展過程中停留的時間較短，相對目前v1.x版本來說，不太穩定，適合做poc階段的測試。

下圖是Fabric v0.6版本的架構圖

在v0.6版本中，主要分為Membership、Consensus、Chaincode、Ledger、P2P、Event Stream等核心模組。

• Membership：負責簽發相應的E-cert、T-cert、TLS-cert等證照。
• Consensus：負責整個區塊鏈的共識，統一交易順序，保證區塊鏈的一致性。
• Chaincode：即鏈碼（Fabric中的智慧合約），用於執行區塊鏈網路中的交易。
• Ledger：用於儲存Transaction log以及交易中的Key-Value。
• P2P：基於Google的Grpc框架的底層網路通訊層。
• Event Stream：事件訂閱釋出組建，用於接收交易及區塊事件。

在Fabric v0.6中採用的共識演算法是PBFT演算法（Practical Byzantine Fault Tolerance）,可以在信任程度較低的場景下避免拜占庭問題。但是由於演算法本身特性限制，n>=3f+1，才能容忍一個拜占庭節點，因此在v0.6版本下，vp節點數量至少是4個。在v0.6版本中，節點角色分為VP(Validating Peer)、NVP(None validating Peer)以及用於簽發證照的Membership節點3種。當然Fabric從第一個版本v0.6.0-preview開始就採用基於docker的執行時環境，為部署減少了許多麻煩，遮蔽了作業系統的差異。當然最主要的一點也許是由於Chaincode的設計機制導致的，整套生產環境的鏈碼的部署和執行都是基於docker的，也許是出於docker穩定以及相對安全的執行環境的考量。Fabric的智慧合約設計理論上可以支援任何開發語言，只要實現了相應的介面。因為它是基於Peer節點和鏈碼容器的一個雙向通訊完成相應的互動的。

下圖是一張Fabric v0.6版本的網路拓撲圖

在這張圖中包含了VP和NVP 2種角色，NVP在這裡會分擔VP的部分工作，接收來自客戶端發過來的交易進行校驗同時將交易請求轉發至共識節點VP，由VP節點進行真正的共識，將交易寫入區塊。在這裡NVP可以分擔共識節點VP的處理交易的壓力，可以提升共識的效能。

下圖為Fabric v0.6的交易流程圖

應用程式需要先向Membership申請E-cert，通過E-cert去申請T-cert，由T-cert對應的私鑰進行簽名客戶端交易傳送至VP節點進行三階段共識，完成之後各個節點會通過Chaincode按順序執行區塊中的交易，並更新賬本。

小結

Fabric v0.6版本可能由於1.0架構重構的原因，沒有繼續維護推進，但是相對於1.0版本的架構來說，這種設計來說，區塊鏈角色相對對稱，相對於1.0-1.4版本來說，不存在中心化的Kafka的存在，在實際場景中擁有更合理對等的節點設計。

Fabric v1.x

Fabric在1.0版本的時候，架構進行了重構，相比於v0.6版本來說，有了顛覆性的變革，功能模組進行了結偶，具有了更好的可伸縮性、效能，進行了channel級別的安全隔離，共識演算法可插拔，具備了更高的可操作性，具備了更豐富的功能，給開發者更好的體驗，v0.6版本中的Membership也升級為了一個獨立的Fabric CA專案。

Fabric v1.x版本中，對節點進行了功能的拆分，明確了各個節點的指責，將背書的信任假設和排序的信任假設進行了拆分。變動最大的地方在於，在共識流程中將交易的執行進行了提前，由Endorser節點進行模擬執行，並進行背書，排序節點Orderer會對所有的交易進行統一的打包排序，將其分發給Committer節點。這種設計的優勢在於可以將前後無關聯的交易以及不同Channel中的交易進行並行執行，提高交易的執行速度。在v0.6版本中是無法做到並行執行的，0.6中是統一進行排序打包，然後按序執行交易，即使交易前後是無關的。下圖也很好地體現了Fabric v1.x中的一個網路拓撲。

下圖是Fabric v1.x版本的架構圖

在v1.x版本中，主要分為Fabric CA、Endorser、Committer、Orderer、Application等角色。

• Fabric CA：負責維護整個Fabric網路中的證照，主要包括簽發、吊銷、續簽證照等操作。
• Endorser：負責對客戶端發過來的交易提案進行背書。
• Comitter：負責對區塊進行有效性校驗並將區塊寫入賬本。
• Orderer：負責對所有的交易進行全域性唯一的排序打包工作。
• Application：用於傳送交易提案，收集響應，封裝交易傳送至Orderer排序服務節點。

在1.0及以後的版本中，客戶端應用會先向Fabric CA申請使用者所需要的Fabric中的准入證照，用於簽名提案以及交易，然後由客戶端（Application）端生成一個提案（Proposal）(一般應用程式會藉助於目前Fabric提供的一系列SDK生成Proposal)傳送至背書節點進行模擬執行並進行背書，背書節點Endorser會進行相應的校驗，然後將提案交由對應的鏈碼Chaincode進行模擬執行，之後背書節點Endorser會對執行結果進行背書,將背書的Response返回至客戶端程式Application，隨之，客戶端程收集到符合背書策略的提案響應（Proposal Response）之後，將其封裝成一個交易Transaction，呼叫排序節點Orderer的Broadcast介面，進行傳送交易至Orderer，在v1.0-v1.4版本中，生產環境只有基於分散式訊息佇列Kafka的排序打包方式，Orderer作為生產者將交易統一傳送至每個通道Channel對應的Topic的Partition當中進行全域性統一地排序，同時每個排序節點基於同樣的切塊規則從Kafka中將區塊切下推送Deliver至與之連線的Leader Peer（在網路環境良好的情況下，每個組織只有一個leader），Leader Peer收到區塊後，會將區塊通過Gossip協議廣播至組織內其餘節點。每個Committer在收到區塊之後會對區塊進行校驗，包括簽名、背書策略以及讀寫集的校驗，在校驗無誤的情況下進行commit，提交到賬本，同時更新世界狀態，同時訂閱了相應事件的應用程式會收到來自Event Hub的訊息通知。

下圖是一個Fabric v1.x的簡化版本的交易流程。

此外，在v1.0之後，Fabric強調了組織的概念，在Peer節點的層級上，每個組織需要配置一個或者多個Anchor Peer節點，來代表組織在整個區塊鏈網路啟始之處與別的組織交換節點資訊，使得每個節點都能夠掌握整個網路的節點資訊。

同時，在v1.0之後，Fabric加入了多通道技術（Muti-channel），使得一個Fabric網路中能夠執行多個賬本，每個通道間的邏輯相互隔離不受影響，如下圖所示，每種顏色的線條代表一個邏輯上的通道，每個Peer節點可以加入不同的通道，每個通道都擁有獨立的賬本、世界狀態、鏈碼以及Kafka中的Topic，通道間訊息是隔離的，互不影響的。

在Fabricv1.x中，多通道技術是用於在業務邏輯層面做的一個全域性的，用於隔離不同業務的通道，使得不同業務的交易儲存在不同的通道對應的節點中，通道技術的實現主要在Orderer中實現，Orderer對來自不同通道的交易做區分，同時在Peer節點中會採用MSP對不同通道的訊息做校驗，用於判斷訊息是否屬於某個通道，通過Orderer以及Peer相結合，形成一個邏輯上的通道技術。

在背書和提交校驗階段，Fabric提出了2個系統鏈碼，ESCC和VSCC：

• ESCC：用於為鏈碼執行結果進行背書。
• VSCC：用於對接收到的區塊中的交易進行校驗。

在儲存方面，v1.0也進行了優化，儲存的設計分為2個部分，一個部分是區塊的儲存，採用的是File System即傳統的檔案系統，這裡設計成採用檔案儲存的原因在於：區塊鏈中的區塊是不斷向後追加的，即不斷append的，不存在隨機寫的情況，如果採用Key-Value資料庫可能會存在資料壓縮或者相關的索引演算法的消耗，在這種場景下，File System會優於K-V資料庫，因此不管是Orderer還是Peer，對於區塊儲存部分，均採用File System進行儲存，對於Block的索引，則採用Level DB進行儲存維護，會根據BlockHash、BlockNumber、TxId等作為Key進行儲存，而Value則是區塊或者交易所在的Segment號+offset(偏移)，用於快速根據Key來定位所需要的區塊或者交易。

此外，對於世界狀態的儲存，這裡指State DB，在v1.0以後可以用Level DB或者Couch DB進行儲存，根據儲存的資料的複雜程度，以及鏈碼的業務邏輯可以選擇不同的資料庫，比如需要針對Json資料進行索引則可以採用Couch DB來進行儲存，如果是普通的Key-Value則可以採用Level DB進行儲存。

下圖是Fabric v1.0以後的儲存的設計圖。

Fabric v1.0之後的CA，從Fabric v0.6到v1.0，Fabric CA是從Membership這個模組所衍生出來的，承擔整個Fabric網路數字證照的簽發、續簽以及吊銷等工作，作為一個獨立的服務存在。同時Fabric CA支援多級CA，以保證根CA的絕對安全，同時儲存部分也是可插拔的，可以選擇MySQL、LDAP、Postgres等，可以採用HA Proxy做負載均衡。

Fabric v1.1

Fabric v1.1版本主要的新特性包括：

• Fabric CA的CRL
• 區塊以及交易的事件推送
• 增加了所有組建間的雙向TLS通訊
• Node.js Chaincode鏈碼的支援
• Chaincode API新增了creator identity
• 效能相對v1.0有了明顯的提升

Fabric v1.2

Fabric v1.2開始有了比較大的feature開始出現：

• Private Data Collections：這個特性不得不說在隱私保護上解決了不少專案的痛點，也減少了許多專案為了隱私保護在業務層做的複雜設計。
• Service Discovery：服務發現這個特性，使得客戶端擁有了更多的靈活性和可操作性，可以動態感知整個Fabric網路的變化。
• Pluggable endorsement and validation：可插拔的背書及校驗機制，採用了Go Plugin機制來實現，避免了之前需要重新編譯原始碼的操作，提升了靈活性。

Fabric v1.3

Fabric v1.3中，同樣增加了十分有用的feature：

• 基於Identity Mixer的MSP Implementation：基於零知識證明實現的身份的匿名和不可連結，這個feature替代了v0.6版本中的T-cert。
• key-level endorsement policies：更細粒度的背書策略，細化到具體的key-value，更加靈活，不僅限於一個鏈碼程式作背書。
• 新增Java Chaincode：至此，v1.3之後支援了Go、Node.js、Java 三種Chaincode，為開發者提供了更多的選擇。
• Peer channel-based event services：Channel級別的事件訂閱機制，早在v1.1版本中已經亮相了，在v1.3版本中正式釋出，至此，舊的Event Hub正式宣告棄用。

Fabric v1.4

Fabric v1.4是一個里程碑式的版本，是首個LTS的版本（Long Term Support的版本）：

• 可操作性和可維護性的提升：
  • 開放日誌級別設定的介面
  • 開放節點健康狀態的檢查介面
  • 開放節點資料指標的收集介面
• 改進了Node SDK的程式設計模型，簡化開發者的程式碼複雜度，使得SDK更加易用
• Private Data的增強：
  • 對於後續新增的允許訪問節點能夠獲取之前的隱私資料
  • 新增客戶端層面的隱私資料的許可權控制，不需要新增鏈碼邏輯

總結

對於Fabric的架構變遷，從v0.6版本到v1.0版本有了相對較大的變動，而v1.0--->v1.4之間，也收集了來自業界的不少需求，進行了完善，增加了許多實用的功能，目前v1.4版本後續的小迭代會對目前存在的bug進行fix，而新的大feature則會在未來的v2.0版本中釋出，敬請期待吧！

歡迎關注我的公眾號:AwesomeBlockchain，獲取更多技術文章！