一種面向Fabric區(qū)塊鏈應(yīng)用軟件的體系結(jié)構(gòu)演化算法

趙會群 張隆龍

摘? 要： 針對聯(lián)盟鏈Fabric中，orderer節(jié)點一旦發(fā)生異常，只能在下一個時間間隔繼續(xù)，而當(dāng)前時間間隔浪費的問題，本文對Fabric體系結(jié)構(gòu)進(jìn)行了演化，提出了一種新的思路，使得orderer節(jié)點產(chǎn)生異常后，系統(tǒng)可以在當(dāng)前間隔內(nèi)正常工作，不必等到下一個時間間隔。最后通過實驗對算法在吞吐量、資源利用率等性能指標(biāo)上進(jìn)行了對比分析，表明了Fabric軟件軟件體系結(jié)構(gòu)演化算法的有效性。

關(guān)鍵詞： 區(qū)塊鏈;Fabric聯(lián)盟鏈;體系結(jié)構(gòu)演化;容錯機制

中圖分類號： TP311 ???文獻(xiàn)標(biāo)識碼： A??? DOI：10.3969/j.issn.1003-6970.2020.07.001

本文著錄格式：趙會群，張隆龍. 一種面向Fabric區(qū)塊鏈應(yīng)用軟件的體系結(jié)構(gòu)演化算法[J]. 軟件，2020，41（07）：01-10+60

An Architecture Evolution Algorithm for Fabric Blockchain Application Software

ZHAO Hui-qun， ZHANG Long-long

（North China University of Technology， Information Institute， Beijing 100144， China）

【Abstract】： In order to solve this problem： at the alliance chain Fabric， if the orderer node has an exception， it can only continue at the next time interval and the current time interval is wasted， this paper proposes a new idea to evolve the fabric architecture， so that after the orderer node has an exception， the system can work normally in the current interval without waiting for the next time interval. Finally， the algorithm was compared and analyzed through experiments on performance indicators such as throughput and resource utilization， which showed the effectiveness of the evolutionary algorithm of the Fabric software architecture.

【Key words】： Blockchain; Fabric alliance chain; Architecture evolution; Fault tolerance mechanism

0? 引言

區(qū)塊鏈技術(shù)興起于2008年，化名為“中本聰”（Satoshi nakamoto）的學(xué)者發(fā)表了一篇奠基性論文《Bitcoin： a peer-to-peer electronic cash system》^[1]，具有去中心化、不可篡改和數(shù)據(jù)本地化存儲等特性。

區(qū)塊鏈技術(shù)的開源項目有很多，目前使用最廣泛的是超級賬本（Hyperledger）項目^[2]。該項目成立于2015年12月，由開源世界的旗艦組織Linux基金會牽頭成立。項目為透明、公開、去中心化的企業(yè)級分布式賬本技術(shù)提供開源參考實現(xiàn)，并推動區(qū)塊鏈和分布式賬本相關(guān)協(xié)議、規(guī)范和標(biāo)準(zhǔn)的發(fā)展^[3]。其中子項目Fabric最早由IBM和DAH發(fā)起，目標(biāo)是作為區(qū)塊鏈的基礎(chǔ)核心平臺，定位是面向企業(yè)的分布式賬本平臺，創(chuàng)新地引入了權(quán)限管理支持，是首個面向聯(lián)盟鏈場景的開源項目^[4]。

Fabric是一個開源的企業(yè)級許可分布式賬本技術(shù)平臺，相比于傳統(tǒng)的公有鏈，有著更好的性能^[5]，其最重要的特點就是可插拔性。沒有任何一個區(qū)塊鏈平臺能夠滿足所有需求，但是Fabric 可以通過配置來盡可能的滿足多樣化需求。

底層由peer節(jié)點和orderer節(jié)點組成了P2P網(wǎng)絡(luò)，通過Google開源的RPC框架-gRPC進(jìn)行交互，客戶端把用戶輸入的數(shù)據(jù)構(gòu)建成交易提案，發(fā)送給背書節(jié)點（背書策略指定的peer節(jié)點），背書節(jié)點模擬執(zhí)行交易后，將結(jié)果集返回給客戶端，客戶端根據(jù)結(jié)果集構(gòu)建交易，發(fā)送給orderer節(jié)點，在orderer節(jié)點中，對于收到的交易，進(jìn)行排序，打包生成塊后，返回給peer節(jié)點，peer節(jié)點驗證后，寫入本地帳本，并利用Gossip廣播協(xié)議同步數(shù)據(jù)。

中間使用通道技術(shù)（channel）進(jìn)行隔離，每個通道都是一個獨立的網(wǎng)絡(luò)，擁有自己的賬本（ledger）。賬本的底層是數(shù)據(jù)庫，fabric中采用goleveldb，對賬本的操作，追根溯源，還是對數(shù)據(jù)庫的操作。賬本記載了一系列交易，完成交易依賴于共識算法，交易會觸發(fā)事件。交易是由SDK發(fā)起的，其底層是應(yīng)用鏈碼（Application chaincode，簡稱ACC），除了ACC外，還有系統(tǒng)連碼（System chaincode，簡稱SCC），主要用來管理ACC，不管是ACC還是SCC，都是鏈碼（chaincode），都依賴于容器技術(shù)和狀態(tài)機（finite state machine，有限狀態(tài)機，簡稱FSM）技術(shù)。權(quán)限管理是獨立出來的，使用了PKI體系，由CA（Certificate Authority，即頒發(fā)數(shù)字證書的機構(gòu)）節(jié)點負(fù)責(zé)頒發(fā)證書，底層是fabric封裝好的MSP（Membership Service Provider）服務(wù)。

Fabric向上層應(yīng)用提供了gRPC API以及把API進(jìn)行封裝的SDK， 應(yīng)用可以通過SDK訪問賬本、處理交易、管理鏈碼、注冊事件、管理權(quán)限等多種資源。SDK的實現(xiàn)有多種，目前支持最完整的版本是Java和nodejs。整個框架的核心就是賬本，負(fù)責(zé)記錄框架上所有應(yīng)用的信息，而應(yīng)用通過SDK發(fā)起交易來向賬本記錄數(shù)據(jù)，交易執(zhí)行的邏輯通過ACC來承載。

Fabric中的orderer節(jié)點負(fù)責(zé)對交易排序、打包成塊，依照共識算法在一個時間間隔內(nèi)，選擇一個節(jié)點完成，該節(jié)點稱之為主節(jié)點，當(dāng)主節(jié)點因為異常停掉時，整個網(wǎng)絡(luò)就會停滯，節(jié)點之間會一直詢問，阻塞，直到該間隔結(jié)束，下一個間隔重新選擇主節(jié)點。當(dāng)網(wǎng)絡(luò)初步啟動，節(jié)點和交易較少時，F(xiàn)abric網(wǎng)絡(luò)處理迅速，選舉間隔極短，但是，當(dāng)節(jié)點數(shù)目和交易次數(shù)很多時，網(wǎng)絡(luò)處理變得緩慢，選舉間隔增加，每一次的阻塞時間都是很大的浪費。orderer節(jié)點選舉的主節(jié)點遭受異常壞掉，造成該間隔內(nèi)整個系統(tǒng)阻塞的問題，屬于容錯問題，F(xiàn)abric系統(tǒng)需要有一個支持主節(jié)點容錯的機制。

故本文在Fabric的基礎(chǔ)上，針對現(xiàn)階段系統(tǒng)不支持主節(jié)點容錯的問題，對Fabric系統(tǒng)架構(gòu)進(jìn)行演化，提出了一個支持主節(jié)點容錯的演化算法。

本文研究部分分為四部分：第一部分是引言，第二部分是相關(guān)工作;第三部分是算法設(shè)計;第四部分是實驗分析;第五部分是總結(jié)。

1 ?相關(guān)工作

中本聰?shù)牡旎哉撐?sup>[1]中，指出了區(qū)塊鏈的典型結(jié)構(gòu)，對關(guān)鍵術(shù)語交易、時間戳服務(wù)器、工作量證明、網(wǎng)絡(luò)、激勵、回收硬盤空間、簡化的支付確認(rèn)、價值的組合與分割、隱私進(jìn)行了詳細(xì)敘述，最后進(jìn)行計算，驗證了區(qū)塊鏈網(wǎng)絡(luò)的可行性。在這個設(shè)計中，巧妙地將節(jié)點容錯能力轉(zhuǎn)化為對于系統(tǒng)中算力的掌握程度，只要掌握的算力不超過系統(tǒng)總算力的50%，就不會系統(tǒng)造成影響。實質(zhì)上是依賴于共識算法-Pow算法，但是該算法耗費資源極高，節(jié)點是否異常需要有6個區(qū)塊上鏈才能確定，時間間隔長，不適用于一般系統(tǒng)^[6-7]。

袁勇、王飛躍^[8]以比特幣為例，說明了區(qū)塊鏈的基礎(chǔ)架構(gòu)模型，由數(shù)據(jù)層、網(wǎng)絡(luò)層、共識層、激勵層、合約層和應(yīng)用層組成：

數(shù)據(jù)層：封裝了底層數(shù)據(jù)區(qū)塊以及相關(guān)的數(shù)據(jù)加密和時間戳等技術(shù);

網(wǎng)絡(luò)層：包括分布式組網(wǎng)機制、數(shù)據(jù)傳播機制和數(shù)據(jù)驗證機制等;

共識層：主要封裝網(wǎng)絡(luò)節(jié)點的各類共識算法;

激勵層：將經(jīng)濟(jì)因素集成到區(qū)塊鏈技術(shù)體系中來，主要包括經(jīng)濟(jì)激勵的發(fā)行機制和分配機制等;

合約層：主要封裝各類腳本、算法和智能合約，是區(qū)塊鏈可編程特性的基礎(chǔ);

應(yīng)用層：封裝了區(qū)塊鏈的各種應(yīng)用場景和? 案例。

邵奇峰、金澈清等^[9]結(jié)合了比特幣、以太坊、fabric等區(qū)塊鏈平臺，提出了另外一種相似但更為簡潔的區(qū)塊鏈架構(gòu)模型，整體上可劃分為網(wǎng)絡(luò)層、共識層、數(shù)據(jù)層、智能合約層和應(yīng)用層五個層次，其中不同之處在于數(shù)據(jù)層，這種結(jié)構(gòu)中的數(shù)據(jù)層包括數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)模型和區(qū)塊存儲，激勵層并入共識層中。在論述區(qū)塊鏈劣勢時，提及了區(qū)塊鏈吞吐量、事務(wù)和并發(fā)處理、查詢統(tǒng)計、訪問控制以及可擴展性問題，沒有提及容錯方面。

徐曉冰、戚梟宏等^[10]把區(qū)塊鏈技術(shù)應(yīng)用到物聯(lián)網(wǎng)上，部署智能合約為設(shè)備管理操作提供接口，把物聯(lián)網(wǎng)設(shè)備獨立于區(qū)塊鏈網(wǎng)絡(luò)之外，進(jìn)而實現(xiàn)網(wǎng)絡(luò)的可伸縮性。后續(xù)之中還改進(jìn)了PBFT算法，使之更有效率地替換拜占庭節(jié)點，實驗驗證了其有效性，但是容錯功能依然是作為共識算法的一部分，沒有改進(jìn)。

甘俊、李強等^[11]針對拜占庭容錯共識算法的靜態(tài)網(wǎng)絡(luò)結(jié)構(gòu)和主節(jié)點選取隨意，通信開銷較大的問題，進(jìn)行改進(jìn)，使節(jié)點可以動態(tài)地加入或退出，并且以最長鏈為選舉原則進(jìn)行選舉，對選舉出來的節(jié)點增加了可信度和吞吐量，降低了時延，提高了安全性。該算法檢測出節(jié)點異常后，迅速結(jié)束當(dāng)前周期，開啟新一輪選舉，降低了節(jié)點切換時間，但是沒有支持主節(jié)點容錯功能。

蔡維德、郁蓮等^[12]詳述了北航鏈，提出了賬戶區(qū)塊鏈模型和交易區(qū)塊鏈模型，滿足通信量巨大、快速響應(yīng)、賬戶信息隱私等需要，并且可擴展性高，但是這個鏈的重點在于提高建塊速度、并行計算、節(jié)省算力方面，強調(diào)區(qū)塊鏈應(yīng)用系統(tǒng)的開發(fā)，沒有關(guān)注主節(jié)點容錯。

朱立、俞歡等^[13]提出了新的高性能聯(lián)盟區(qū)塊鏈技術(shù)，通過業(yè)務(wù)邏輯與共識分離、存儲優(yōu)化和數(shù)字簽名驗證優(yōu)化等手段來提高聯(lián)盟鏈系統(tǒng)的交易性能，并且驗證了有效性。在此架構(gòu)之中共識算法分離了出來，但是依然沒有擺脫容錯功能，整個系統(tǒng)還是依賴于共識算法進(jìn)行處理。

Sara Saberi、Mahtab Kouhizadeh等^[14]將區(qū)塊鏈技術(shù)用于解決一些全球供應(yīng)鏈管理的問題。全球的供應(yīng)鏈系統(tǒng)和區(qū)塊鏈系統(tǒng)在結(jié)構(gòu)上具有相似之處，都是分布式，現(xiàn)在的供應(yīng)鏈管理嚴(yán)重依賴一些大型組織，具有集中式的特點。文章中提出把區(qū)塊鏈技術(shù)應(yīng)用在供應(yīng)鏈管理中，使得供應(yīng)鏈不在集中于某幾個組織，具有更好的健壯性。文章指出在基礎(chǔ)的區(qū)塊鏈系統(tǒng)之上，更好的管理還得依靠智能合約，通過對其的嚴(yán)格審查，來確保安全。

關(guān)于區(qū)塊鏈的研究較少，大部分重點在于區(qū)塊鏈結(jié)構(gòu)，把支持主節(jié)點容錯放在了共識算法中，少部分對共識算法進(jìn)行了改進(jìn)。本文提出的支持主節(jié)點容錯的orderer節(jié)點演化算法獨立于共識模塊，當(dāng)主節(jié)點異常時，在當(dāng)前周期內(nèi)直接支持容錯，保證系統(tǒng)正常工作。

2 ?算法研究

2.1 ?需求分析

在Fabric系統(tǒng)結(jié)構(gòu)中，數(shù)據(jù)傳輸過程如圖2。

（1）客戶端根據(jù)用戶輸入的數(shù)據(jù)、需要調(diào)用的chaincode函數(shù)和參數(shù)、時間戳和客戶端的簽名等信息，構(gòu)建交易提案，依據(jù)設(shè)定好的背書策略發(fā)送給指定的Endorser節(jié)點;

（2）Endorser節(jié)點收到提案后，首先校驗簽名，保證合法性，然后進(jìn)行背書操作，即根據(jù)提案中的信息，基于當(dāng)前賬本狀態(tài)，調(diào)用chaincode函數(shù)模擬執(zhí)行交易，生成結(jié)果并簽名，發(fā)送給客戶端。注意，此時只是模擬執(zhí)行，并沒有更改當(dāng)前的賬本狀態(tài);

（3）客戶端收到回復(fù)后，驗證結(jié)果的簽名是否屬于給定的背書節(jié)點，保證合法性。然后，對模擬執(zhí)行的結(jié)果進(jìn)行校驗，若有多個回復(fù)信息，檢查是否一致。檢查通過后，對背書結(jié)果進(jìn)行簽名，生成交易（transaction），發(fā)送給主orderer節(jié)點;

（4）主orderer節(jié)點是orderer節(jié)點列表依照Raft共識選舉出來的，在收到客戶端發(fā)送的交易后，首先會校驗簽名，保證合法性，然后對交易按照指定規(guī)則排序，并且打包生成塊，然后對生成的區(qū)塊簽名，之后發(fā)送給peer節(jié)點;

（5）peer節(jié)點中的Leader角色，負(fù)責(zé)與orderer節(jié)點通信，在收到區(qū)塊后，會廣播給組織內(nèi)其余的peer節(jié)點，也就是Commit節(jié)點，在驗證通過后，會真正的執(zhí)行交易，更新本地的數(shù)據(jù)庫。

由上述過程中，可看出，主orderer節(jié)點在起到了至關(guān)重要的作用，需要對主orderer節(jié)點進(jìn)行容錯處理，但是在fabric系統(tǒng)中沒有，因此對fabric系統(tǒng)中orderer節(jié)點的結(jié)構(gòu)進(jìn)行演化，確保在主orderer節(jié)點產(chǎn)生異常的情況下，系統(tǒng)仍然可以正常工作。

相比于圖3，把orderer節(jié)點分為兩部分，新拿出的一部分作為備份orderer節(jié)點列表，時刻進(jìn)行維護(hù)，按順序選取第一個節(jié)點作為備份orderer節(jié)點，時刻備份著主orderer節(jié)點的數(shù)據(jù)。當(dāng)主orderer節(jié)

點異常時，備份orderer節(jié)點可以立即接管主orderer節(jié)點的業(yè)務(wù)，維護(hù)系統(tǒng)的正常運行。

2.2 ?演化模型

在原來的Fabric結(jié)構(gòu)中，orderer節(jié)點與peer節(jié)點關(guān)系如下（假設(shè)此時主orderer節(jié)點已經(jīng)收到客戶端發(fā)來的交易信息，為了簡潔，用戶、客戶端、背書節(jié)點和提交節(jié)點略去）：

主orderer節(jié)點收到客戶端發(fā)來的交易，對交易進(jìn)行校驗、排序，然后按照一定規(guī)則打包成塊，發(fā)送給leader peer節(jié)點。此時的系統(tǒng)架構(gòu)上，不具備容錯能力。

依照前面分析，在圖3-2的基礎(chǔ)上，添加了備份orderer節(jié)點來完成容錯。備份orderer節(jié)點需要知道主orderer的狀態(tài)，來及時的進(jìn)行接管服務(wù)。本文參照觀察者模式^[15]，完成消息傳遞機制。

將主orderer節(jié)點作為被觀察者，備份orderer節(jié)點和leader peer節(jié)點作為觀察者，主orderer節(jié)點通過attach方法和detach方法來注冊、刪除具體觀察者，具體觀察者對象存儲在主orderer節(jié)點的concreteObservers字段中。主orderer節(jié)點就可以調(diào)用繼承的notify方法，在此方法中通過存儲的觀察者對象來調(diào)用它們自身的update方法，繼而完成對觀察者的通知。同時，主orderer節(jié)點需要把區(qū)塊發(fā)送給leader peer節(jié)點，也可以通過此機制來完成，使得兩者之間的耦合性降低。

備份orderer節(jié)點收到主orderer節(jié)點異常信息后，會啟動接管服務(wù)，利用備份好的數(shù)據(jù)，恢復(fù)主orderer節(jié)點的服務(wù)，去除Observer接口的方法，新添加Subject接口的方法，此時原來的備份orderer節(jié)點就變成了新的主orderer節(jié)點，在當(dāng)前的時間間隔內(nèi)繼續(xù)工作;原來的主orderer節(jié)點會進(jìn)入檢測列表中，檢測正常，就會進(jìn)入備份orderer節(jié)點列表;此時備份orderer節(jié)點列表中的第一個orderer節(jié)點，會自動成為新的備份orderer節(jié)點。

2.3 ?算法設(shè)計

在調(diào)整后的結(jié)構(gòu)中，相對于被觀察者leader peer節(jié)點和備份orderer節(jié)點來說，其收到的消息是主orderer節(jié)點推送過來的，是被動接受的。這一般適用于主orderer節(jié)點在工作過程中陷入阻塞狀態(tài)，阻塞時間大于waitTime（等待時間）時，來通知備份orderer節(jié)點和leader peer節(jié)點。

算法1：異常感知算法（被動）

輸入：backupIP——備份orderer節(jié)點的IP地址

輸出：異常狀態(tài)信息

主orderer節(jié)點端：

1. backupOrderer=getOrderer（backupIP）? // 得到備份orderer節(jié)點對象

2. attach（backupOrderer）????????? // 注冊觀察者，存入觀察者列表中

3. IF 進(jìn)入阻塞狀態(tài) && 阻塞時間 > waitTime THEN

4. ??notify（異常狀態(tài)信息）??? // 通知觀察者

5. END

備份orderer節(jié)點端：

1. exceptionInfo=update（）????????????????? // 主orderer節(jié)點端的notify方法，本質(zhì)上就是調(diào)用觀察者自身的update方法進(jìn)行通知

2. print（exceptionInfo）

leader peer節(jié)點端：

1. exceptionInfo=update（）

2. print（exceptionInfo）

觀察者模式是典型的被動感知，有其局限性，當(dāng)主orderer節(jié)點斷網(wǎng)時，就無法向觀察者備份orderer節(jié)點和leader peer節(jié)點推送消息，即備份orderer節(jié)點無法被動感知。此時就需要備份orderer節(jié)點主動感知主orderer節(jié)點異常的算法。

算法2：異常感知算法（主動）

輸入：主orderer節(jié)點的IP地址

輸出：主orderer節(jié)點異常信息

主orderer端：

1. 讀取本地IP，監(jiān)聽本地端口

2. WHILE

3.??? IF 收到連接請求 THEN

4.??????? 建立連接

5.??????? Send（狀態(tài)信息）

6.??? END

備份orderer端和leader peer節(jié)點端：

1. 讀取主orderer的IP地址

2. WHILE

3.??? 向主orderer節(jié)點發(fā)送連接請求

4.??? IF 連接成功 THEN

5.??????? Receive（狀態(tài)信息）

6.??? ELSE

7.??????? print（主orderer節(jié)點異常）

8.??? END

9.??? sleep（intervalTime）

假設(shè)此時主orderer節(jié)點產(chǎn)生異常，已經(jīng)無法正常工作，備份orderer節(jié)點已收到異常信息，準(zhǔn)備接管其業(yè)務(wù)。

圖7是用一個正常工作的狀態(tài)，此時主orderer節(jié)點產(chǎn)生異常，備份orderer節(jié)點通過算法1被動感知或者算法2主動感知，得到其無法正常工作的消息，就會啟動自身的數(shù)據(jù)恢復(fù)服務(wù)和接管服務(wù)，代替主orderer節(jié)點工作，同時從備份orderer節(jié)點列表中，取出首位的備份orderer節(jié)點，進(jìn)行數(shù)據(jù)備份服務(wù)。

算法3：orderer節(jié)點演化算法

輸入狀態(tài)：主orderer節(jié)點異常，無法工作

輸出狀態(tài)：備份orderer節(jié)點接管主orderer節(jié)點業(yè)務(wù)，正常工作

備份orderer端：

1. data=updateData（）?????? // 把數(shù)據(jù)從本地備份中恢復(fù)

2. Tx=receiveTx（data[sender]） // 通過備份的交易發(fā)送方，啟動接收交易服務(wù)，接受新的交易

3. getService（data[Tx]/Tx）??????? // 對備份中的交易和收到的新交易進(jìn)行排序，打包成塊

4. sendBlock（data[receiver]）???? // 通過備份的區(qū)塊接收方，啟動發(fā)送區(qū)塊服務(wù)，把生成的區(qū)塊發(fā)送給指定的接收方

5. 監(jiān)聽本地端口

6. WHILE

7. ??? IF 收到連接請求 THEN

8. ???????????? 建立連接

9.?????????????? Receive（新的備份orderer節(jié)點已經(jīng)準(zhǔn)備好）

10.???????????? attach（新的備份orderer節(jié)點）??????? // 注冊新的觀察者，必須確保新的備份orderer節(jié)點已經(jīng)準(zhǔn)備好

11. ?????????? WHILE

12.????????????????????? sendData（data）???????? // 循環(huán)發(fā)送數(shù)據(jù)，以便備份

13. ?????????? END? // 若產(chǎn)生異常，跳出循環(huán)

14.??? END

在備份orderer節(jié)點列表中，選擇當(dāng)前第一個節(jié)點，成為新的備份orderer節(jié)點。

新的備份orderer節(jié)點端：

1. 向現(xiàn)在的主orderer節(jié)點（原備份orderer節(jié)點）發(fā)送請求

2. IF 建立連接 THEN

3.????? Send（備份節(jié)點已經(jīng)就緒）

4.????? WHILE

5. ???????????? data=Receice（data）? // 循環(huán)接收當(dāng)前主orderer節(jié)點發(fā)來的數(shù)據(jù)

6.? ?????????? saveData（data）???????? ??? // 保存

7.?? ??????? END ??????? // 若產(chǎn)生異常，跳出循環(huán)

8. END

備份節(jié)點接管之后，原來的主orderer節(jié)點有可能恢復(fù)正常，不能直接廢棄，此時備份orderer作為主orderer，要測試原來的orderer信息，如果正常，就放入后備orderer列表，等待使用。

算法4：orderer節(jié)點管理算法

輸入：主orderer的IP地址

輸出：備份orderer節(jié)點列表

主orderer端：

1. 監(jiān)聽本地端口

2. WHILE

3.??? IF 收到連接請求 THEN

4.??????? 建立連接

5.??????? Send（狀態(tài)信息）

6.??? END

備份orderer端：

1. 讀取主orderer的IP地址

2. WHILE

3.??? 向主orderer發(fā)送連接請求

4.??? IF 建立連接 THEN

5.??????? Receive（狀態(tài)信息）

6.?????? ?IF 狀態(tài)良好 THEN

7.??????????? backupOrderers.add（主orderer節(jié)點）

8.??????? END

9.??? END

10.? ?IF 共識節(jié)點數(shù)量<3 THEN // 共識算法至少得需要3個節(jié)點

11. ??????????????????? orderer= backupOrderers.remove（）

12. ??????????????????? normalOrderers.add（orderer）

13.? ??????? END

14.???? sleep（intervalTime）

3 ?實驗分析

3.1 ?實驗數(shù)據(jù)

本實驗所用到的數(shù)據(jù)是英特集團(tuán)的2018年和2019年的交易數(shù)據(jù)，股票代碼：000411，數(shù)據(jù)來自于網(wǎng)易財經(jīng)。

在2018年和2019年中，共有488天進(jìn)行過股票交易。實驗中，建立兩個賬戶，一個是英特集團(tuán)賬戶，初始金額為2018/1/2的流通市值，即418226.9萬元，另一個賬戶代表股民，初始金額設(shè)定為10000萬元，每次進(jìn)行兩筆交易，分別代表資金流入和資金流出，執(zhí)行488次，代表488天的交易，合計976筆交易。

3.2 ?實驗環(huán)境

實驗基于官方測試樣例fabric-samples/first- network，對其進(jìn)行了修改，由5個orderer節(jié)點和3個peer節(jié)點構(gòu)成，5個orderer節(jié)點中，其中3個orderer節(jié)點要通過Raft共識進(jìn)行選舉，2個orderer節(jié)點作為備份orderer節(jié)點列表;3個peer節(jié)點中，指定peer0擔(dān)任leader角色，負(fù)責(zé)與orderer組織通信，3個peer節(jié)點都擔(dān)任Endorser角色和Commit角色，負(fù)責(zé)背書和寫入?yún)^(qū)塊。

3.3 ?實驗分析

仿造主orderer節(jié)點陷入阻塞狀態(tài)，備份orderer節(jié)點被動感知異常的情況下，對應(yīng)用演化算法前? 后系統(tǒng)的業(yè)務(wù)吞吐量、資源利用率和延遲，進(jìn)行了分析。

3.3.1? 業(yè)務(wù)吞吐量

在吞吐量方面，fabric中對于讀和寫的處理效率是不同的，讀的效率要高于寫的效率，因此對讀寫分開進(jìn)行測試。

由圖10可看出，隨著吞吐量的增加，讀操作和寫操作都出現(xiàn)了失敗案例，這是fabric本身的性能瓶頸。讀操作的TPS在500左右，寫操作的TPS在300左右，在這兩個界限之下，可保證交易的有效性。

相比于演化前的吞吐量，演化后的系統(tǒng)在讀操作上的TPS提高到520上下，寫操作的TPS提高到310上下。整體上，在吞吐量指標(biāo)上，有了3%-4%的提升。

3.3.2? 資源利用率

通過自動化腳本對應(yīng)用演化算法前后的數(shù)據(jù)進(jìn)行采集，主要采集CPU和硬盤的使用數(shù)據(jù)，其中讀寫操作的比例是2∶1，CPU采用百分比，硬盤采用萬分比，結(jié)果如圖12。

由圖中可看出，在CPU的利用率上，當(dāng)交易次數(shù)較少時，采用演化算法的系統(tǒng)使用的CPU資源要少一些，隨著交易次數(shù)的增加，無論是否采用演化算法，CPU的利用率都會達(dá)到100%，陷入瓶頸;在硬盤的利用率上，采用演化算法的系統(tǒng)比原系統(tǒng)使用的硬盤資源少，而且隨著交易數(shù)量的增加，會越來越明顯。

3.3.3? 延遲

在fabric系統(tǒng)中，主orderer節(jié)點作用是對收到的交易進(jìn)行排序、打包，當(dāng)收到的交易數(shù)量大于主orderer節(jié)點的處理能力時，多余的交易會進(jìn)行排隊等待，繼而會造成延遲。實驗測量交易的平均等待時間，結(jié)果如圖13。

由圖中可看出，隨著交易次數(shù)的增加，平均每個交易的延遲會顯著降低，說明了演化算法中，orderer節(jié)點替換的時間要小于Raft共識重新選舉的時間。

3.4.4? 小結(jié)

應(yīng)用演化算法的fabric系統(tǒng)，最主要的突破是降低了延遲。采用備份orderer節(jié)點接管主orderer節(jié)點的業(yè)務(wù)，是有效的，其花費的時間開銷小于共識算法重新選舉的時間開銷。

延遲降低后，單位時間內(nèi)的交易吞吐量就會提高，但是本質(zhì)上吞吐量取決于fabric系統(tǒng)內(nèi)部的運算復(fù)雜度，交易的等待時間并不是決定性因素，因此系統(tǒng)吞吐量提高的幅度不大。

共識算法的選舉過程，需要進(jìn)行安全校驗，即加解密操作，需要CPU運算;而orderer節(jié)點演化算法要求備份orderer節(jié)點恢復(fù)交易數(shù)據(jù)，對交易排序、打包，需要磁盤讀寫，因此，當(dāng)交易次數(shù)少的時候，應(yīng)用演化算法的系統(tǒng)需要的CPU資源就會降低。隨著交易次數(shù)的增加，限于硬件環(huán)境，CPU資源耗盡，進(jìn)入瓶頸。

對于硬盤資源，延遲的降低，使得等待處理的交易減少，進(jìn)而降低了這部分交易的存儲，同時也減少了日志信息。

4 ?結(jié)論

本文通過對fabric架構(gòu)中的orderer節(jié)點進(jìn)行演化，把orderer節(jié)點分出一部分，作為備份orderer節(jié)點，解決了主orderer節(jié)點異常問題。實驗表明，該算法能有效地降低延遲，進(jìn)而提高fabric的運行效率。

參考文獻(xiàn)

1. Satoshi Nakamoto. Bitcoin： a peer-to-peer electronic cash system[OL]， available： https：//bitcoin.org/bitcoin.pdf， 2008.
2. Hyperledger Chinese document[OL]. https：//hyperledgercn. github.io/hyperledgerDocs.
3. 楊保華， 陳昌. 區(qū)塊鏈原理、設(shè)計與應(yīng)用[M]. 北京： 機械工業(yè)出版社， 2017. 8.

1. 張增駿， 董寧， 朱軒彤， 等. 深度探索區(qū)塊鏈： Hyperledger技術(shù)與應(yīng)用[M]. 北京： 機械工業(yè)出版社， 2018. 1.
2. 朱立， 俞歡， 詹士瀟， 等. 高性能聯(lián)盟區(qū)塊鏈技術(shù)研究[J]. 軟件學(xué)報， 2019， 30（6）： 1577-1593.
3. 葉聰聰， 李國強， 蔡鴻明， 等. 區(qū)塊鏈的安全檢測模型[J]. 軟件學(xué)報， 2018， 29（05）： 1348-1359.
4. Mauro C， Kumar E S， Chhagan L， et al. A Survey on Security and Privacy Issues of Bitcoin[J]. IEEE Communications Surveys & Tutorials， 2018： 1-1.
5. 袁勇， 王飛躍. 區(qū)塊鏈技術(shù)發(fā)展現(xiàn)狀與展望[J]. 自動化學(xué)報， 2016， 42（4）： 481?494.
6. 邵奇峰， 金澈清， 張召等. 區(qū)塊鏈技術(shù)：架構(gòu)及進(jìn)展[J]. 計算機學(xué)報. 2018（5）， 5（41）： 969-988.
7. 徐曉冰， 戚梟宏， 王建平， 等. 基于區(qū)塊鏈的物聯(lián)網(wǎng)可伸縮管理機制[J]. 計算機應(yīng)用研究. 2019（6）.
8. 甘俊， 李強， 陳子豪， 等. 區(qū)塊鏈實用拜占庭容錯共識算法的改進(jìn)[J]. 計算機應(yīng)用， 2019， 39（07）： 2148-2155.
9. 蔡維德， 郁蓮， 王榮， 等. 基于區(qū)塊鏈的應(yīng)用系統(tǒng)開發(fā)方法研究[J]. 軟件學(xué)報， 2017， 28（6）： 1474-1487.
10. 朱立， 俞歡， 詹士瀟， 等. 高性能聯(lián)盟區(qū)塊鏈技術(shù)研究[J]. 軟件學(xué)報， 2019， 30（6）： 1577-1593.
11. Sara Saberi， Mahtab Kouhizadeh， Joseph Sarkis & Lejia Shen. Blockchain technology and its relationships to sustainable supply chain management[J]， International Journal of Production Research， 2019.
12. Erich Gamma， Richard Helm， Ralph Johnson， John Vlissides. 設(shè)計模式： 可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M]. 李英軍， 馬曉星， 蔡敏等譯. 北京： 機械工業(yè)出版社， 2007. 1.