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

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

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

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

下圖是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é)整個(gè)區(qū)塊鏈的共識(shí)，統(tǒng)一交易順序，保證區(qū)塊鏈的一致性。

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

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

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

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

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

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

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

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

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

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

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

Fabric v1.x版本中，對(duì)節(jié)點(diǎn)進(jìn)行了功能的拆分，明確了各個(gè)節(jié)點(diǎn)的指責(zé)，將背書的信任假設(shè)和排序的信任假設(shè)進(jìn)行了拆分。變動(dòng)最大的地方在于，在共識(shí)流程中將交易的執(zhí)行進(jìn)行了提前，由Endorser節(jié)點(diǎn)進(jìn)行模擬執(zhí)行，并進(jìn)行背書，排序節(jié)點(diǎn)Orderer會(huì)對(duì)所有的交易進(jìn)行統(tǒng)一的打包排序，將其分發(fā)給Committer節(jié)點(diǎn)。這種設(shè)計(jì)的優(yōu)勢(shì)在于可以將前后無關(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中的一個(gè)網(wǎng)絡(luò)拓?fù)洹?br>

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

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

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

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

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

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

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

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

下圖是一個(gè)Fabric v1.x的簡(jiǎn)化版本的交易流程。

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

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

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

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

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

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

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

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

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

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

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

Fabric CA的CRL

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

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

Node.js Chaincode鏈碼的支持

Chaincode API新增了creator identity

性能相對(duì)v1.0有了明顯的提升

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Private Data的增強(qiáng)：

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

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

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

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