圖十六：PBFT的網(wǎng)絡(luò)拓?fù)淠Ｐ?/p>

PBFT實(shí)現(xiàn)的分布式網(wǎng)絡(luò)需要滿足兩個(gè)條件：

• 每個(gè)節(jié)點(diǎn)具有相同的起始狀態(tài);
• 在相同的狀態(tài)下，同一操作產(chǎn)生的結(jié)果相同。

在一個(gè)PBFT算法實(shí)現(xiàn)的分布式網(wǎng)絡(luò)中，一組節(jié)點(diǎn)中選取一個(gè)節(jié)點(diǎn)作為主節(jié)點(diǎn)(Primary)，其它節(jié)點(diǎn)作為備份節(jié)點(diǎn)(Backup)。選取某個(gè)節(jié)點(diǎn)擔(dān)任主節(jié)點(diǎn)的事態(tài)稱為系統(tǒng)的一個(gè)視圖(View)。當(dāng)主節(jié)點(diǎn)故障時(shí)將重新選取主節(jié)點(diǎn)，主節(jié)點(diǎn)發(fā)生變化時(shí)視為系統(tǒng)的視圖發(fā)生了一次更新。假設(shè)在View1視圖下網(wǎng)絡(luò)對(duì)某條消息m的排序n達(dá)成一致，為Order⟨view1,m,n⟩，那么當(dāng)視圖更新后對(duì)m的排序仍然為Order⟨view2,m,n⟩，即視圖轉(zhuǎn)換前后消息排序不會(huì)發(fā)生改變。

3.PBFT的消息處理流程

圖十七：PBFT的消息處理流程

PBFT的消息處理流程大體上分為請(qǐng)求(Request)，預(yù)處理(Pre-prepare)，準(zhǔn)備(Prepare)，提交(Commit)，響應(yīng)(Reply)五個(gè)階段。我們通過一個(gè)四節(jié)點(diǎn)，一個(gè)客戶端的簡(jiǎn)單網(wǎng)絡(luò)模型來對(duì)PBFT的信息傳輸校驗(yàn)流程加以說明：

在該網(wǎng)絡(luò)模型中，Primary節(jié)點(diǎn)和Backup1，Backup2節(jié)點(diǎn)為正常節(jié)點(diǎn)，Backup3節(jié)點(diǎn)發(fā)生故障無法做出響應(yīng)，符合N>3F要求。

首先在Request階段，Client向Primary發(fā)出一條請(qǐng)求，消息格式為:

其中o 表示操作請(qǐng)求內(nèi)容，t表示當(dāng)前時(shí)間戳，c表示Client節(jié)點(diǎn)。

當(dāng)Primary收到該消息并驗(yàn)證后，進(jìn)入Pre-prepare階段，Primary給予消息m一個(gè)序號(hào)n，向Backup1，Backup2，Backup3廣播預(yù)處理消息，消息格式為： 其中v表示當(dāng)前的系統(tǒng)視圖，n為消息排序，m為消息內(nèi)容，d為消息m的哈希值。

當(dāng)Backup1，Backup2節(jié)點(diǎn)接收到Primary節(jié)點(diǎn)的消息后，首先會(huì)驗(yàn)證系統(tǒng)視圖是否發(fā)生了更新，消息簽名是否合法，排序n是否處于當(dāng)前視圖高低水位之間(為了保證n不出現(xiàn)極大極小值，同一視圖下系統(tǒng)會(huì)對(duì)n的取值域進(jìn)行限制，使n∈(h,H))，以及是否收到過其它排序?yàn)閚的消息(確保不同的消息不會(huì)獲得相同的排序)。驗(yàn)證通過后，進(jìn)入PREPARE階段，該節(jié)點(diǎn)會(huì)向其它節(jié)點(diǎn)(包括Primary節(jié)點(diǎn))發(fā)送一條準(zhǔn)備消息并將該消息存入本地日志中，消息格式為： 其中i表示當(dāng)前節(jié)點(diǎn)。

當(dāng)其他節(jié)點(diǎn)收到該消息后，會(huì)進(jìn)行如下校驗(yàn)并將該消息存入本地日志：

第一步，校驗(yàn)本地日志中是否存在消息m。

第二步，校驗(yàn)本地日志中是否存在m的PRE-PREPARE消息。

第三步，校驗(yàn)本地日志中是否存在至少2F個(gè)關(guān)于m的PREPARE消息。

若校驗(yàn)通過，則稱本節(jié)點(diǎn)對(duì)消息m達(dá)成了PREPARED狀態(tài)。此時(shí)該節(jié)點(diǎn)會(huì)向其它節(jié)點(diǎn)廣播，消息格式為：

當(dāng)其它節(jié)點(diǎn)收到該條COMMIT消息時(shí)，會(huì)進(jìn)行如下校驗(yàn)并將該消息存入本地日志：

第一步，檢驗(yàn)本節(jié)點(diǎn)是否對(duì)消息m達(dá)成PREPARED狀態(tài)。

第二步，校驗(yàn)本地日志中是否至少有2F條來自其它節(jié)點(diǎn)的關(guān)于m的COMMIT消息。

若校驗(yàn)通過，則說明對(duì)m的排序已經(jīng)達(dá)成了全局一致，此時(shí)稱該節(jié)點(diǎn)對(duì)消息m達(dá)成了COMMITTED-LOCAL(m,v,n,i)狀態(tài)，可以直接返回給Client，消息格式為： 其中r和t相同，用于時(shí)間校驗(yàn)，當(dāng)Client收到F+1個(gè)一致的REPLY消息時(shí)，共識(shí)流程結(jié)束。

圖十八：節(jié)點(diǎn)本地日志庫狀態(tài)轉(zhuǎn)移圖

為了更直觀地理解這一流程，我們作出每個(gè)節(jié)點(diǎn)本地日志庫的狀態(tài)轉(zhuǎn)移圖。其中藍(lán)色標(biāo)識(shí)的消息為節(jié)點(diǎn)自己產(chǎn)生，綠色標(biāo)識(shí)的消息來自其它節(jié)點(diǎn)。

首先Client發(fā)出REQUEST消息，該消息被保存在Primary的日志庫中。然后Primary發(fā)送PRE-PREPARE消息給Backup1，Backup2，Backup3。Backup1，Backup2分別在日志庫中保存該條PRE-PREPARE消息。然后向其它節(jié)點(diǎn)發(fā)送PREPARE消息。

Primary收到來自Backup1，Backup2的兩條PREPARE消息并保存在日志庫中。而Backup1，Backup2除了一條自己產(chǎn)生的PREPARE消息外，還收到一條其它節(jié)點(diǎn)的PREPARE消息。此時(shí)三個(gè)正常節(jié)點(diǎn)日志庫均滿足：

• 存在消息m的日志;
• 存在消息m的PRE-PREPARE日志;
• 存在消息m的2F個(gè)PREPARE日志。

此時(shí)三個(gè)節(jié)點(diǎn)均達(dá)成了關(guān)于m的PREPARED狀態(tài)，繼而向其它節(jié)點(diǎn)發(fā)送COMMIT消息。

由圖可見，三個(gè)正常節(jié)點(diǎn)除了自身產(chǎn)生的一條COMMIT消息外，均收到了2條來自其它節(jié)點(diǎn)的COMMIT消息，均達(dá)成COMMITTED狀態(tài)，返回REPLY消息給客戶端，完成共識(shí)流程。

4.PBFT的垃圾回收機(jī)制

PBFT算法對(duì)信息的階段性校驗(yàn)需要用到節(jié)點(diǎn)的日志庫，隨著信息的增加，日志庫中的冗余數(shù)據(jù)也會(huì)越來越多，因此PBFT會(huì)通過定期的垃圾回收來釋放內(nèi)存空間。PBFT的垃圾回收通過Checkpoint機(jī)制來完成。Checkpoint點(diǎn)的設(shè)置為某個(gè)常數(shù)K的整數(shù)倍。假設(shè)當(dāng)前消息排序值n取值的高低水位為h到H之間，當(dāng)被排序的消息數(shù)超過H時(shí)，節(jié)點(diǎn)便會(huì)發(fā)送CHECKPOINT消息，消息格式為：

當(dāng)某個(gè)節(jié)點(diǎn)收到2F+1條CHECKPOINT消息后，便會(huì)將高低水位重新置為n∈(H,H+K)，并刪除排序值小于H的消息日志，釋放內(nèi)存空間。

5.PBFT的視圖更新機(jī)制

因?yàn)镻BFT通過主節(jié)點(diǎn)完成對(duì)消息的排序，因此就存在主節(jié)點(diǎn)故障的風(fēng)險(xiǎn)。對(duì)此PBFT設(shè)計(jì)了一套對(duì)應(yīng)的視圖更新機(jī)制來保證主節(jié)點(diǎn)故障的情況下整個(gè)系統(tǒng)的可用性。

當(dāng)某個(gè)節(jié)點(diǎn)i監(jiān)測(cè)到主節(jié)點(diǎn)響應(yīng)超時(shí)，便進(jìn)入視圖更新流程，并發(fā)送一條VIEWCHANGE消息，消息格式為：

其中n為最近一個(gè)Checkpoint的序號(hào)，C為對(duì)應(yīng)的2F+1個(gè)CHECKPOINT消息集合。P為一個(gè)達(dá)成PREPARED狀態(tài)的消息集合：

Pm表示序號(hào)大于n且達(dá)成PREPARED狀態(tài)的消息m的至少1個(gè)PRE-PREPARE消息和至少2F個(gè)PREPARE消息的集合(也就是使消息m達(dá)成PREPARED狀態(tài)的所有預(yù)處理消息和準(zhǔn)備消息的總集)。

當(dāng)新的主節(jié)點(diǎn)Primaryv+1收到2F個(gè)有效的VIEWCHANGE消息后，會(huì)廣播一條新視圖消息，消息格式為：

其中V是Primaryv+1收到的所有VIEWCHANGE消息的集合，O為以新視圖構(gòu)造的PRE-PREPARE消息的集合，至此視圖更新流程結(jié)束。這一機(jī)制有效確保了系統(tǒng)在視圖更新前后達(dá)成PREPARED狀態(tài)的消息排序不變。

四、Hyperledger Fabric的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)與共識(shí)機(jī)制

Hyperledger Fabric使用PBFT作為其共識(shí)算法的底層實(shí)現(xiàn)。對(duì)于分布式系統(tǒng)而言，數(shù)據(jù)一致性策略可分為強(qiáng)一致性策略和最終一致性策略。所謂強(qiáng)一致性策略是指系統(tǒng)能夠?qū)崿F(xiàn)在極端條件下的數(shù)據(jù)一致性，其涉及到復(fù)雜的數(shù)據(jù)交互，且對(duì)系統(tǒng)壓力較大，并不適合商業(yè)級(jí)數(shù)據(jù)存儲(chǔ)。因此Hyperledger Fabric采用了最終一致性策略，所謂最終一致性是指系統(tǒng)可以容忍在短時(shí)間內(nèi)不同節(jié)點(diǎn)數(shù)據(jù)不一致的情形，整個(gè)區(qū)塊鏈網(wǎng)絡(luò)只需要保證在一定時(shí)間周期內(nèi)達(dá)成一致即可。

圖十九：Hyperledger Fabric的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

如圖所示，Hyperledger Fabric采用多中心的網(wǎng)絡(luò)架構(gòu)模式，由獨(dú)立的排序節(jié)點(diǎn)對(duì)來自不同終端的交易請(qǐng)求進(jìn)行規(guī)整處理，封裝成區(qū)塊后再下發(fā)到整個(gè)區(qū)塊鏈網(wǎng)絡(luò)。

Hyperledger Fabric網(wǎng)絡(luò)下主要有四種類型的節(jié)點(diǎn)：

• Client節(jié)點(diǎn)(客戶端節(jié)點(diǎn))，這一節(jié)點(diǎn)主要用于提供應(yīng)用訪問區(qū)塊鏈網(wǎng)絡(luò)的入口，負(fù)責(zé)系統(tǒng)與區(qū)塊鏈之間的數(shù)據(jù)交互。
• Peer節(jié)點(diǎn)，包含了Anchor節(jié)點(diǎn)(錨節(jié)點(diǎn))，Endorser節(jié)點(diǎn)(背書節(jié)點(diǎn))和Committer節(jié)點(diǎn)(記賬節(jié)點(diǎn))。其中錨節(jié)點(diǎn)每個(gè)組織中至多只有一個(gè)，負(fù)責(zé)和其他組織以及order節(jié)點(diǎn)交互，組織網(wǎng)絡(luò)中的非錨節(jié)點(diǎn)不直接參與和外部網(wǎng)絡(luò)的信息交換。背書節(jié)點(diǎn)負(fù)責(zé)模擬執(zhí)行來自用戶的交易請(qǐng)求，并對(duì)請(qǐng)求進(jìn)行驗(yàn)證和簽名。記賬節(jié)點(diǎn)負(fù)責(zé)保存區(qū)塊鏈信息，更新世界狀態(tài)等。需要強(qiáng)調(diào)的是這三種角色之間并非互斥關(guān)系，一個(gè)Peer節(jié)點(diǎn)可能同時(shí)兼有背書節(jié)點(diǎn)，記賬節(jié)點(diǎn)等多種角色，而且所有的Peer節(jié)點(diǎn)都是記賬節(jié)點(diǎn)。
• Order節(jié)點(diǎn)，共識(shí)機(jī)制的核心節(jié)點(diǎn)，負(fù)責(zé)對(duì)來自用戶的交易請(qǐng)求進(jìn)行排序，打包成區(qū)塊后分發(fā)給其它組織的錨節(jié)點(diǎn)。
• CA節(jié)點(diǎn)(鑒權(quán)節(jié)點(diǎn))，非必要節(jié)點(diǎn)，主要負(fù)責(zé)證書的頒發(fā)，身份驗(yàn)證及用戶鑒權(quán)等。也可通過第三方證書鑒權(quán)機(jī)構(gòu)實(shí)現(xiàn)。

就Hyperledger Fabric的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)而言，其并不同于如比特幣，以太坊等常見公鏈的網(wǎng)狀拓?fù)浣Y(jié)構(gòu)，而是更接近于具備一定層級(jí)關(guān)系的樹狀拓?fù)浣Y(jié)構(gòu)(就此而言，Hyperledger Fabric并非是一個(gè)去中心網(wǎng)絡(luò)，而是一個(gè)多中心網(wǎng)絡(luò))。

不同的組織分屬于不同的網(wǎng)域，每個(gè)組織結(jié)構(gòu)下只暴露一個(gè)錨節(jié)點(diǎn)作為與其它組織交互的接口。這一設(shè)計(jì)主要是出于部分企業(yè)的數(shù)據(jù)安全性考慮。很多企業(yè)核心數(shù)據(jù)往往不便于直接暴露在公網(wǎng)中，內(nèi)外網(wǎng)隔離的設(shè)計(jì)可以充分確保敏感數(shù)據(jù)的安全性。

除了不同的組織外，區(qū)塊鏈網(wǎng)絡(luò)中還存在由Order節(jié)點(diǎn)組成的排序網(wǎng)絡(luò)，Order節(jié)點(diǎn)有Solo和Kafka兩種運(yùn)行模式。Solo模式由單個(gè)Order節(jié)點(diǎn)提供排序服務(wù)，往往只是用于網(wǎng)絡(luò)測(cè)試和節(jié)點(diǎn)數(shù)較少的場(chǎng)景。商業(yè)應(yīng)用中一般采用Kafka模式，Order節(jié)點(diǎn)將接收到的交易請(qǐng)求發(fā)送給Kafka集群，由Kafka集群排序后再返回給Order節(jié)點(diǎn)，這一設(shè)計(jì)大大提升了Order集群的排序分發(fā)效率。

圖二十：Hyperledger Fabric的多通道排序機(jī)制

在企業(yè)應(yīng)用場(chǎng)景中可能存在一個(gè)區(qū)塊鏈網(wǎng)絡(luò)需要承接多種業(yè)務(wù)的情形，因此Hyperledger Fabric采用了多通道設(shè)計(jì)。所謂通道指的是一個(gè)封閉的業(yè)務(wù)群，一個(gè)Hyperledger Fabric網(wǎng)絡(luò)中可能存在多個(gè)業(yè)務(wù)群處理不同的業(yè)務(wù)，彼此之間在邏輯和物理上均相互隔離。有幾個(gè)業(yè)務(wù)群就會(huì)存在幾條不同的區(qū)塊鏈，每個(gè)節(jié)點(diǎn)都只會(huì)保存自己加入的通道的區(qū)塊鏈數(shù)據(jù)，進(jìn)而杜絕了多業(yè)務(wù)交叉場(chǎng)景下數(shù)據(jù)外泄的風(fēng)險(xiǎn)。而排序節(jié)點(diǎn)也會(huì)根據(jù)通道的不同將交易請(qǐng)求分發(fā)給不同的Kafka隊(duì)列，實(shí)現(xiàn)業(yè)務(wù)間的鏈級(jí)隔離。

Hyperledger Fabric網(wǎng)絡(luò)中一個(gè)完整的交易流程為：

客戶端首先提交交易提案發(fā)送給背書節(jié)點(diǎn)(至少兩個(gè)，具體可在背書策略中設(shè)置，用戶可指定要使用的背書節(jié)點(diǎn))，背書節(jié)點(diǎn)收到交易提案后啟動(dòng)鏈碼(運(yùn)行在一個(gè)隔離的安全容器中，無法被人為干預(yù))模擬交易(僅僅是模擬，并不會(huì)更新到區(qū)塊鏈網(wǎng)絡(luò)中)。鑒權(quán)驗(yàn)證通過后背書節(jié)點(diǎn)會(huì)添加數(shù)字簽名并返回給客戶端(理論上多個(gè)背書節(jié)點(diǎn)返回的執(zhí)行結(jié)果應(yīng)當(dāng)一致)?？蛻舳藢⒑灻蟮慕灰渍?qǐng)求發(fā)送給Order節(jié)點(diǎn)，Order節(jié)點(diǎn)進(jìn)行排序后打包成區(qū)塊分發(fā)給各組織錨節(jié)點(diǎn)。錨節(jié)點(diǎn)分發(fā)給組織內(nèi)記賬節(jié)點(diǎn)，記賬節(jié)點(diǎn)驗(yàn)證完成后將最新的區(qū)塊添加到本地區(qū)塊鏈中，并更新世界狀態(tài)。

五、智能合約

圖二十一：發(fā)起交易和智能合約調(diào)用流程

智能合約(鏈碼)是Hyperledger Fabric用于應(yīng)用和區(qū)塊鏈網(wǎng)絡(luò)之間交互的媒介。鏈碼部署在獨(dú)立且隔離的Docker容器中，無法被外界干預(yù)和篡改，通過gRPC與背書節(jié)點(diǎn)通信。背書節(jié)點(diǎn)將交易請(qǐng)求發(fā)送給鏈碼容器后，鏈碼容器返回給背書節(jié)點(diǎn)該筆交易的執(zhí)行結(jié)果。

智能合約類似于應(yīng)用系統(tǒng)中的對(duì)外接口，而交易就是對(duì)接口的一次調(diào)用。鏈碼中對(duì)外接口只提供兩個(gè)方法，Init方法和Invoke方法。Init方法只會(huì)在區(qū)塊鏈網(wǎng)絡(luò)啟動(dòng)時(shí)在任意一個(gè)節(jié)點(diǎn)執(zhí)行一次，Invoke方法則用于應(yīng)用和區(qū)塊鏈網(wǎng)絡(luò)之間具體的交互。

鏈碼存在五個(gè)生命周期，打包(鏈碼的編譯)，安裝(上傳到背書節(jié)點(diǎn))，實(shí)例化(執(zhí)行Init方法)，升級(jí)(鏈碼中的功能拓展和Bug修復(fù))，交互(應(yīng)用調(diào)用)。

企業(yè)用戶可以根據(jù)自身業(yè)務(wù)場(chǎng)景編寫不同功能的智能合約來實(shí)現(xiàn)應(yīng)用和區(qū)塊鏈網(wǎng)絡(luò)之間的數(shù)據(jù)交互。

六、Hyperledger Fabric的業(yè)務(wù)應(yīng)用

Hyperledger Fabric是一套專門為機(jī)構(gòu)和企業(yè)設(shè)計(jì)的通用型業(yè)務(wù)方案。其相比于區(qū)塊鏈1.0和2.0，可以靈活的根據(jù)用戶業(yè)務(wù)進(jìn)行定制。而模塊化和插件式的服務(wù)模式也大大降低了用戶的組網(wǎng)成本。非常適用于金融，支付等高敏感性業(yè)務(wù)場(chǎng)景。而Hyperledger Fabric底層的鍵值對(duì)存儲(chǔ)結(jié)構(gòu)也具有很強(qiáng)的擴(kuò)展性。傳統(tǒng)數(shù)據(jù)庫能夠存儲(chǔ)的數(shù)據(jù)，理論上Hyperledger Fabric都可以存儲(chǔ)。其多通道設(shè)計(jì)可以實(shí)現(xiàn)物理級(jí)別的業(yè)務(wù)解耦，多種業(yè)務(wù)都可以無干擾地掛載在同一區(qū)塊鏈網(wǎng)絡(luò)下。實(shí)現(xiàn)資源復(fù)用的同時(shí)又避免了機(jī)構(gòu)之間業(yè)務(wù)交叉產(chǎn)生的數(shù)據(jù)外泄風(fēng)險(xiǎn)。

Hyperledger Fabric的另一大優(yōu)勢(shì)在于用戶可以根據(jù)自身業(yè)務(wù)編寫智能合約，定制應(yīng)用系統(tǒng)和區(qū)塊鏈網(wǎng)絡(luò)的數(shù)據(jù)交互模式。這就為復(fù)雜業(yè)務(wù)場(chǎng)景和區(qū)塊鏈技術(shù)的縫合提供了便利，使得“區(qū)塊鏈+”得以真正進(jìn)入企業(yè)級(jí)應(yīng)用之中。

結(jié)語

區(qū)塊鏈技術(shù)問世以來，十?dāng)?shù)年間歷經(jīng)三次迭代，其間或譽(yù)或諑，不絕于耳。唯有撥開籠罩在區(qū)塊鏈上的那層神秘面紗，深究其技術(shù)原理，方能得見其真容。單純作為一種技術(shù)而言，區(qū)塊鏈本身是價(jià)值無涉的。工具能釋放出怎樣的社會(huì)價(jià)值，終究取決于其使用者。我們也許驚嘆于設(shè)計(jì)者的曠世奇思，但絕無必要為其賦予太多超脫于技術(shù)之外的神秘色彩。區(qū)塊鏈也許是通往未來的一個(gè)入口，但任何技術(shù)奇點(diǎn)的引爆都并非來自于某個(gè)單點(diǎn)技術(shù)突破，而是醞釀?dòng)诤穹e薄發(fā)的逐步嬗變。勤懇與踏實(shí)才是推動(dòng)社會(huì)進(jìn)步的最終驅(qū)力，在技術(shù)瞬息萬變，發(fā)展一日千里的當(dāng)下，我們更當(dāng)持守此心。

參考文獻(xiàn)

[1] Satoshi Nakamoto: Bitcoin:A Peer-to-Peer Electronic Cash System[EB/OL]

[2] Castro,Miguel,Barbara Liskov: Practical Byzantine fault tolerance.OSDI.Vol.99.1999

[3] Kwon,Jae: Tendermint:Consensus without mining.Draft v.0.6,fall(2014)

作者簡(jiǎn)介：

王翔，畢業(yè)于安徽大學(xué)2018屆電子信息工程專業(yè)，現(xiàn)就職于某知名世界五百強(qiáng)互聯(lián)網(wǎng)企業(yè)。致力于服務(wù)端系統(tǒng)的架構(gòu)設(shè)計(jì)，多活部署，性能優(yōu)化，業(yè)務(wù)開發(fā)等工作。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】