摘要：在中采用的共識算法是算法可以在信任程度較低的場景下避免拜占庭問題。但是由于算法本身特性限制，，才能容忍一個拜占庭節點，因此在版本下，節點數量至少是個。

作者: TopJohn
原文連接：https://www.xuanzhangjiong.to...

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

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在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 CA的CRL

區塊以及交易的事件推送

增加了所有組建間的雙向TLS通信

Node.js Chaincode鏈碼的支持

Chaincode API新增了creator identity

性能相對v1.0有了明顯的提升

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

Private Data Collections：這個特性不得不說在隱私保護上解決了不少項目的痛點，也減少了許多項目為了隱私保護在業務層做的復雜設計。

Service Discovery：服務發現這個特性，使得客戶端擁有了更多的靈活性和可操作性，可以動態感知整個Fabric網絡的變化。

Pluggable endorsement and validation：可插拔的背書及校驗機制，采用了Go Plugin機制來實現，避免了之前需要重新編譯源代碼的操作，提升了靈活性。

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是一個里程碑式的版本，是首個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，獲取更多技術文章！