Fabric架構演變之路

做者: TopJohn
原文鏈接： https://www.xuanzhangjiong.to...

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，獲取更多技術文章！