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

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

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

v0.6版本的技術(shù)架構(gòu)在整個發(fā)展過程中停留的時間較短，相對目前v1.x版本來說，不太穩(wěn)定，適合做poc階段的測試。

下圖是Fabric v0.6版本的架構(gòu)圖

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

Membership：負(fù)責(zé)簽發(fā)相應(yīng)的E-cert、T-cert、TLS-cert等證書。

Consensus：負(fù)責(zé)整個區(qū)塊鏈的共識，統(tǒng)一交易順序，保證區(qū)塊鏈的一致性。

Chaincode：即鏈碼（Fabric中的智能合約），用于執(zhí)行區(qū)塊鏈網(wǎng)絡(luò)中的交易。

Ledger：用于存儲Transaction log以及交易中的Key-Value。

P2P：基于Google的Grpc框架的底層網(wǎng)絡(luò)通信層。

Event Stream：事件訂閱發(fā)布組建，用于接收交易及區(qū)塊事件。

在Fabric v0.6中采用的共識算法是PBFT算法（Practical Byzantine Fault Tolerance）,可以在信任程度較低的場景下避免拜占庭問題。但是由于算法本身特性限制，n>=3f+1，才能容忍一個拜占庭節(jié)點，因此在v0.6版本下，vp節(jié)點數(shù)量至少是4個。在v0.6版本中，節(jié)點角色分為VP(Validating Peer)、NVP(None validating Peer)以及用于簽發(fā)證書的Membership節(jié)點3種。當(dāng)然Fabric從第一個版本v0.6.0-preview開始就采用基于docker的運行時環(huán)境，為部署減少了許多麻煩，屏蔽了操作系統(tǒng)的差異。當(dāng)然最主要的一點也許是由于Chaincode的設(shè)計機制導(dǎo)致的，整套生產(chǎn)環(huán)境的鏈碼的部署和運行都是基于docker的，也許是出于docker穩(wěn)定以及相對安全的運行環(huán)境的考量。Fabric的智能合約設(shè)計理論上可以支持任何開發(fā)語言，只要實現(xiàn)了相應(yīng)的接口。因為它是基于Peer節(jié)點和鏈碼容器的一個雙向通信完成相應(yīng)的交互的。

下圖是一張F(tuán)abric v0.6版本的網(wǎng)絡(luò)拓?fù)鋱D

在這張圖中包含了VP和NVP 2種角色，NVP在這里會分擔(dān)VP的部分工作，接收來自客戶端發(fā)過來的交易進(jìn)行校驗同時將交易請求轉(zhuǎn)發(fā)至共識節(jié)點VP，由VP節(jié)點進(jìn)行真正的共識，將交易寫入?yún)^(qū)塊。在這里NVP可以分擔(dān)共識節(jié)點VP的處理交易的壓力，可以提升共識的性能。

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

應(yīng)用程序需要先向Membership申請E-cert，通過E-cert去申請T-cert，由T-cert對應(yīng)的私鑰進(jìn)行簽名客戶端交易發(fā)送至VP節(jié)點進(jìn)行三階段共識，完成之后各個節(jié)點會通過Chaincode按順序執(zhí)行區(qū)塊中的交易，并更新賬本。

Fabric v0.6版本可能由于1.0架構(gòu)重構(gòu)的原因，沒有繼續(xù)維護(hù)推進(jìn)，但是相對于1.0版本的架構(gòu)來說，這種設(shè)計來說，區(qū)塊鏈角色相對對稱，相對于1.0-1.4版本來說，不存在中心化的Kafka的存在，在實際場景中擁有更合理對等的節(jié)點設(shè)計。

Fabric在1.0版本的時候，架構(gòu)進(jìn)行了重構(gòu)，相比于v0.6版本來說，有了顛覆性的變革，功能模塊進(jìn)行了結(jié)偶，具有了更好的可伸縮性、性能，進(jìn)行了channel級別的安全隔離，共識算法可插拔，具備了更高的可操作性，具備了更豐富的功能，給開發(fā)者更好的體驗，v0.6版本中的Membership也升級為了一個獨立的Fabric CA項目。

Fabric v1.x版本中，對節(jié)點進(jìn)行了功能的拆分，明確了各個節(jié)點的指責(zé)，將背書的信任假設(shè)和排序的信任假設(shè)進(jìn)行了拆分。變動最大的地方在于，在共識流程中將交易的執(zhí)行進(jìn)行了提前，由Endorser節(jié)點進(jìn)行模擬執(zhí)行，并進(jìn)行背書，排序節(jié)點Orderer會對所有的交易進(jìn)行統(tǒng)一的打包排序，將其分發(fā)給Committer節(jié)點。這種設(shè)計的優(yōu)勢在于可以將前后無關(guān)聯(lián)的交易以及不同Channel中的交易進(jìn)行并行執(zhí)行，提高交易的執(zhí)行速度。在v0.6版本中是無法做到并行執(zhí)行的，0.6中是統(tǒng)一進(jìn)行排序打包，然后按序執(zhí)行交易，即使交易前后是無關(guān)的。下圖也很好地體現(xiàn)了Fabric v1.x中的一個網(wǎng)絡(luò)拓?fù)洹?br>

下圖是Fabric v1.x版本的架構(gòu)圖

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

Fabric CA：負(fù)責(zé)維護(hù)整個Fabric網(wǎng)絡(luò)中的證書，主要包括簽發(fā)、吊銷、續(xù)簽證書等操作。

Endorser：負(fù)責(zé)對客戶端發(fā)過來的交易提案進(jìn)行背書。

Comitter：負(fù)責(zé)對區(qū)塊進(jìn)行有效性校驗并將區(qū)塊寫入賬本。

Orderer：負(fù)責(zé)對所有的交易進(jìn)行全局唯一的排序打包工作。

Application：用于發(fā)送交易提案，收集響應(yīng)，封裝交易發(fā)送至Orderer排序服務(wù)節(jié)點。

在1.0及以后的版本中，客戶端應(yīng)用會先向Fabric CA申請用戶所需要的Fabric中的準(zhǔn)入證書，用于簽名提案以及交易，然后由客戶端（Application）端生成一個提案（Proposal）(一般應(yīng)用程序會借助于目前Fabric提供的一系列SDK生成Proposal)發(fā)送至背書節(jié)點進(jìn)行模擬執(zhí)行并進(jìn)行背書，背書節(jié)點Endorser會進(jìn)行相應(yīng)的校驗，然后將提案交由對應(yīng)的鏈碼Chaincode進(jìn)行模擬執(zhí)行，之后背書節(jié)點Endorser會對執(zhí)行結(jié)果進(jìn)行背書,將背書的Response返回至客戶端程序Application，隨之，客戶端程收集到符合背書策略的提案響應(yīng)（Proposal Response）之后，將其封裝成一個交易Transaction，調(diào)用排序節(jié)點Orderer的Broadcast接口，進(jìn)行發(fā)送交易至Orderer，在v1.0-v1.4版本中，生產(chǎn)環(huán)境只有基于分布式消息隊列Kafka的排序打包方式，Orderer作為生產(chǎn)者將交易統(tǒng)一發(fā)送至每個通道Channel對應(yīng)的Topic的Partition當(dāng)中進(jìn)行全局統(tǒng)一地排序，同時每個排序節(jié)點基于同樣的切塊規(guī)則從Kafka中將區(qū)塊切下推送Deliver至與之連接的Leader Peer（在網(wǎng)絡(luò)環(huán)境良好的情況下，每個組織只有一個leader），Leader Peer收到區(qū)塊后，會將區(qū)塊通過Gossip協(xié)議廣播至組織內(nèi)其余節(jié)點。每個Committer在收到區(qū)塊之后會對區(qū)塊進(jìn)行校驗，包括簽名、背書策略以及讀寫集的校驗，在校驗無誤的情況下進(jìn)行commit，提交到賬本，同時更新世界狀態(tài)，同時訂閱了相應(yīng)事件的應(yīng)用程序會收到來自Event Hub的消息通知。

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

此外，在v1.0之后，F(xiàn)abric強調(diào)了組織的概念，在Peer節(jié)點的層級上，每個組織需要配置一個或者多個Anchor Peer節(jié)點，來代表組織在整個區(qū)塊鏈網(wǎng)絡(luò)啟始之處與別的組織交換節(jié)點信息，使得每個節(jié)點都能夠掌握整個網(wǎng)絡(luò)的節(jié)點信息。

同時，在v1.0之后，F(xiàn)abric加入了多通道技術(shù)（Muti-channel），使得一個Fabric網(wǎng)絡(luò)中能夠運行多個賬本，每個通道間的邏輯相互隔離不受影響，如下圖所示，每種顏色的線條代表一個邏輯上的通道，每個Peer節(jié)點可以加入不同的通道，每個通道都擁有獨立的賬本、世界狀態(tài)、鏈碼以及Kafka中的Topic，通道間消息是隔離的，互不影響的。

在Fabricv1.x中，多通道技術(shù)是用于在業(yè)務(wù)邏輯層面做的一個全局的，用于隔離不同業(yè)務(wù)的通道，使得不同業(yè)務(wù)的交易存儲在不同的通道對應(yīng)的節(jié)點中，通道技術(shù)的實現(xiàn)主要在Orderer中實現(xiàn)，Orderer對來自不同通道的交易做區(qū)分，同時在Peer節(jié)點中會采用MSP對不同通道的消息做校驗，用于判斷消息是否屬于某個通道，通過Orderer以及Peer相結(jié)合，形成一個邏輯上的通道技術(shù)。

在背書和提交校驗階段，F(xiàn)abric提出了2個系統(tǒng)鏈碼，ESCC和VSCC：

ESCC：用于為鏈碼執(zhí)行結(jié)果進(jìn)行背書。

VSCC：用于對接收到的區(qū)塊中的交易進(jìn)行校驗。

在存儲方面，v1.0也進(jìn)行了優(yōu)化，存儲的設(shè)計分為2個部分，一個部分是區(qū)塊的存儲，采用的是File System即傳統(tǒng)的文件系統(tǒng)，這里設(shè)計成采用文件存儲的原因在于：區(qū)塊鏈中的區(qū)塊是不斷向后追加的，即不斷append的，不存在隨機寫的情況，如果采用Key-Value數(shù)據(jù)庫可能會存在數(shù)據(jù)壓縮或者相關(guān)的索引算法的消耗，在這種場景下，F(xiàn)ile System會優(yōu)于K-V數(shù)據(jù)庫，因此不管是Orderer還是Peer，對于區(qū)塊存儲部分，均采用File System進(jìn)行存儲，對于Block的索引，則采用Level DB進(jìn)行存儲維護(hù)，會根據(jù)BlockHash、BlockNumber、TxId等作為Key進(jìn)行存儲，而Value則是區(qū)塊或者交易所在的Segment號+offset(偏移)，用于快速根據(jù)Key來定位所需要的區(qū)塊或者交易。

此外，對于世界狀態(tài)的存儲，這里指State DB，在v1.0以后可以用Level DB或者Couch DB進(jìn)行存儲，根據(jù)存儲的數(shù)據(jù)的復(fù)雜程度，以及鏈碼的業(yè)務(wù)邏輯可以選擇不同的數(shù)據(jù)庫，比如需要針對Json數(shù)據(jù)進(jìn)行索引則可以采用Couch DB來進(jìn)行存儲，如果是普通的Key-Value則可以采用Level DB進(jìn)行存儲。

下圖是Fabric v1.0以后的存儲的設(shè)計圖。

Fabric v1.0之后的CA，從Fabric v0.6到v1.0，F(xiàn)abric CA是從Membership這個模塊所衍生出來的，承擔(dān)整個Fabric網(wǎng)絡(luò)數(shù)字證書的簽發(fā)、續(xù)簽以及吊銷等工作，作為一個獨立的服務(wù)存在。同時Fabric CA支持多級CA，以保證根CA的絕對安全，同時存儲部分也是可插拔的，可以選擇MySQL、LDAP、Postgres等，可以采用HA Proxy做負(fù)載均衡。

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

Fabric CA的CRL

區(qū)塊以及交易的事件推送

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

Node.js Chaincode鏈碼的支持

Chaincode API新增了creator identity

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

Fabric v1.2開始有了比較大的feature開始出現(xiàn)：

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

Service Discovery：服務(wù)發(fā)現(xiàn)這個特性，使得客戶端擁有了更多的靈活性和可操作性，可以動態(tài)感知整個Fabric網(wǎng)絡(luò)的變化。

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

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

基于Identity Mixer的MSP Implementation：基于零知識證明實現(xiàn)的身份的匿名和不可鏈接，這個feature替代了v0.6版本中的T-cert。

key-level endorsement policies：更細(xì)粒度的背書策略，細(xì)化到具體的key-value，更加靈活，不僅限于一個鏈碼程序作背書。

新增Java Chaincode：至此，v1.3之后支持了Go、Node.js、Java 三種Chaincode，為開發(fā)者提供了更多的選擇。

Peer channel-based event services：Channel級別的事件訂閱機制，早在v1.1版本中已經(jīng)亮相了，在v1.3版本中正式發(fā)布，至此，舊的Event Hub正式宣告棄用。

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

可操作性和可維護(hù)性的提升：

開放日志級別設(shè)置的接口

開放節(jié)點健康狀態(tài)的檢查接口

開放節(jié)點數(shù)據(jù)指標(biāo)的收集接口

改進(jìn)了Node SDK的編程模型，簡化開發(fā)者的代碼復(fù)雜度，使得SDK更加易用

Private Data的增強：

對于后續(xù)添加的允許訪問節(jié)點能夠獲取之前的隱私數(shù)據(jù)

添加客戶端層面的隱私數(shù)據(jù)的權(quán)限控制，不需要添加鏈碼邏輯

對于Fabric的架構(gòu)變遷，從v0.6版本到v1.0版本有了相對較大的變動，而v1.0--->v1.4之間，也收集了來自業(yè)界的不少需求，進(jìn)行了完善，增加了許多實用的功能，目前v1.4版本后續(xù)的小迭代會對目前存在的bug進(jìn)行fix，而新的大feature則會在未來的v2.0版本中發(fā)布，敬請期待吧！

歡迎關(guān)注我的公眾號：AwesomeBlockchain，獲取更多技術(shù)文章！