區(qū)塊鏈容錯(cuò)機(jī)制與算法研究

趙會(huì)群 任 杰

(北方工業(yè)大學(xué)信息學(xué)院 北京 100144)(北方工業(yè)大學(xué)大規(guī)模流數(shù)據(jù)集成與分析技術(shù)北京市重點(diǎn)實(shí)驗(yàn)室 北京 100144)

0 引 言

自從2008年Nakamoto[1]提出了比特幣這種可以在點(diǎn)對(duì)點(diǎn)的交易平臺(tái)使用的數(shù)字貨幣，其底層技術(shù)區(qū)塊鏈[2]引起了業(yè)界和政府的廣泛關(guān)注。區(qū)塊鏈技術(shù)[3]具有去中心化、不可篡改和數(shù)據(jù)本地化存儲(chǔ)等特性，為下一代互聯(lián)網(wǎng)技術(shù)包括匿名在線交易的數(shù)字資產(chǎn)提供基礎(chǔ)支持[4-5]。

超級(jí)賬本(Hyperledger)是Linux基金會(huì)的區(qū)塊鏈項(xiàng)目，致力于發(fā)展跨行業(yè)的商用區(qū)塊鏈平臺(tái)技術(shù)[6-7]。超級(jí)賬本項(xiàng)目自創(chuàng)立伊始便吸引了眾多行業(yè)的領(lǐng)頭羊，包括金融業(yè)、銀行、互聯(lián)網(wǎng)行業(yè)、運(yùn)輸業(yè)等。其旗下的Hyperledger Fabric子項(xiàng)目是以IBM早期捐獻(xiàn)出的Open Blockchain為主體搭建而成。Hyperledger Fabric是一個(gè)帶有可插入各種功能模塊結(jié)構(gòu)的區(qū)塊鏈實(shí)施方案，目標(biāo)就是打造成一個(gè)有全社會(huì)共同維護(hù)的開源超級(jí)賬本[8]。

對(duì)于Fabric區(qū)塊鏈而言，其結(jié)構(gòu)中存在兩大類節(jié)點(diǎn)：一類是peer節(jié)點(diǎn)，一個(gè)網(wǎng)絡(luò)實(shí)體，維護(hù)ledger并運(yùn)行Chaincode容器來對(duì)ledger執(zhí)行read-write操作；另一類是orderer節(jié)點(diǎn)，以先到先得的方式為網(wǎng)絡(luò)上所有的channel做交易排序，并將交易序列放入block[9]中。對(duì)于2019年7月開源的Fabric區(qū)塊鏈而言，其排序服務(wù)的模式共有kafka、solo和raft三種，其中kafka模式是orderer集群將交易信息發(fā)送給第三方kafka[10]服務(wù)，由其對(duì)交易進(jìn)行排序；solo模式為單點(diǎn)orderer支撐排序服務(wù)；raft模式為orderer集群通過共識(shí)機(jī)制選舉主orderer來進(jìn)行交易排序。然而在后兩種排序服務(wù)中，存在著一個(gè)問題，也就是本文所要解決的問題，同時(shí)也是Fabric區(qū)塊鏈其本身體系結(jié)構(gòu)存在的問題，即主orderer節(jié)點(diǎn)作為排序交易，并打包交易成為區(qū)塊的重要節(jié)點(diǎn)，一旦主orderer節(jié)點(diǎn)受到惡意攻擊或者自主宕機(jī)，其主orderer要負(fù)責(zé)排序的交易數(shù)據(jù)以及已完成打包但未及時(shí)發(fā)送出去的區(qū)塊都將丟失。雖然交易數(shù)據(jù)可以重新傳輸，但也造成了大量時(shí)間的耗費(fèi)，然而Fabric區(qū)塊鏈系統(tǒng)并沒有對(duì)于這樣的體系結(jié)構(gòu)問題作出相應(yīng)的保障措施。

Fabric區(qū)塊鏈的這種體系結(jié)構(gòu)問題，屬于容錯(cuò)問題。容錯(cuò)是指如何保證在出現(xiàn)錯(cuò)誤時(shí)系統(tǒng)仍可以提供正常服務(wù)[11]，通常是以犧牲系統(tǒng)一定的資源(包括時(shí)間、存儲(chǔ)、計(jì)算等)為代價(jià)[12]。容錯(cuò)問題可以通過容錯(cuò)技術(shù)[13]來解決，容錯(cuò)技術(shù)對(duì)于系統(tǒng)而言是重要的可靠性保障手段[14]，容錯(cuò)技術(shù)主要包含三個(gè)內(nèi)容：故障診斷技術(shù)、故障屏蔽技術(shù)、動(dòng)態(tài)冗余技術(shù)[15]。將容錯(cuò)技術(shù)應(yīng)用到Fabric區(qū)塊鏈中仍然存在著一些挑戰(zhàn)。首先，在區(qū)塊鏈領(lǐng)域中目前還沒有容錯(cuò)技術(shù)的使用；其次，在一般的含有容錯(cuò)技術(shù)的系統(tǒng)中故障診斷[16]的作用都只是利用心跳機(jī)制[17-18]檢測節(jié)點(diǎn)是否存活，缺少檢測節(jié)點(diǎn)是否遭受惡意攻擊的機(jī)制。

本文針對(duì)Fabric區(qū)塊鏈的容錯(cuò)問題，設(shè)計(jì)了備用orderer節(jié)點(diǎn)對(duì)主orderer節(jié)點(diǎn)實(shí)時(shí)檢測并備份恢復(fù)其業(yè)務(wù)的容錯(cuò)算法。在原Fabric 區(qū)塊鏈系統(tǒng)的基礎(chǔ)之上增加了可靠性機(jī)制，力爭使原系統(tǒng)在可靠性方面得到增強(qiáng)。

1 相關(guān)工作

目前還未有區(qū)塊鏈領(lǐng)域的容錯(cuò)機(jī)制，因此本文的相關(guān)工作主要選取的是容錯(cuò)機(jī)制在其他領(lǐng)域的應(yīng)用。

趙鎮(zhèn)輝等[18]對(duì)CLAIMS這個(gè)內(nèi)存數(shù)據(jù)系統(tǒng)引入了容錯(cuò)機(jī)制，并提出了Fail-fast、Fail-over，以及Fail-back三種算法，即Fail-fast算法實(shí)現(xiàn)系統(tǒng)中快速發(fā)現(xiàn)故障節(jié)點(diǎn)并標(biāo)記，F(xiàn)ail-over算法則是在標(biāo)記故障節(jié)點(diǎn)之后，實(shí)現(xiàn)對(duì)受影響任務(wù)的重啟，而Fail-back算法則是實(shí)現(xiàn)對(duì)故障節(jié)點(diǎn)中內(nèi)存狀態(tài)的恢復(fù)。對(duì)于CLAIMS系統(tǒng)的容錯(cuò)機(jī)制，測試故障節(jié)點(diǎn)只是通過簡單的心跳機(jī)制來完成，并未對(duì)其有惡意攻擊的測試方案。

Nagarajan等[19]設(shè)計(jì)一種名為Screwdriver的異常檢測工具，主要的作用就是在系統(tǒng)被注入如高CPU、高內(nèi)存利用率，磁盤已滿和網(wǎng)絡(luò)占用率高等故障之后，可以通過異常檢測模塊發(fā)現(xiàn)錯(cuò)誤，之后利用通知服務(wù)模塊生成測試報(bào)告。Screwdriver工具并未對(duì)故障模塊有恢復(fù)保障機(jī)制，而只是測試異常。

孔超等[20]對(duì)Bigtable、HBase、Dynamo、Cassandra，以及PNUTS五個(gè)典型的NoSQL系統(tǒng)的容錯(cuò)機(jī)制及其實(shí)現(xiàn)進(jìn)行分析與對(duì)比，使用的故障檢測都只是單純的心跳機(jī)制，并且在節(jié)點(diǎn)發(fā)生故障的時(shí)候，也是通過冗余的資源完成故障恢復(fù)，使系統(tǒng)具備容忍故障的能力[21]，即一個(gè)master節(jié)點(diǎn)，三個(gè)副本節(jié)點(diǎn)來進(jìn)行備份。同樣，在此故障檢測中并未含有惡意攻擊的測試流程。

劉添添[22]對(duì)移動(dòng)Agent系統(tǒng)提出了一種基于消息機(jī)制和日志記錄的容錯(cuò)協(xié)議，即利用了容錯(cuò)技術(shù)中的冗余技術(shù)，實(shí)現(xiàn)了一個(gè)Backup agent對(duì)Agent進(jìn)行故障檢測及故障恢復(fù)。但此容錯(cuò)機(jī)制只是對(duì)于主節(jié)點(diǎn)進(jìn)行故障檢測和數(shù)據(jù)備份，一旦主節(jié)點(diǎn)故障，并沒有及時(shí)的服務(wù)恢復(fù)機(jī)制。

段澤源[23]對(duì)大數(shù)據(jù)流式處理系統(tǒng)的容錯(cuò)機(jī)制做了研究，其系統(tǒng)主要依靠Zookeeper這種較成熟的分布式系統(tǒng)協(xié)調(diào)系統(tǒng)利用心跳機(jī)制對(duì)節(jié)點(diǎn)運(yùn)行狀態(tài)進(jìn)行檢測，之后使用定期同步節(jié)點(diǎn)信息到數(shù)據(jù)庫的方式冗余節(jié)點(diǎn)信息，以便在節(jié)點(diǎn)失效重啟時(shí)恢復(fù)節(jié)點(diǎn)數(shù)據(jù)。此容錯(cuò)機(jī)制的設(shè)計(jì)不足與文獻(xiàn)[18]一樣，都是缺乏惡意攻擊的測試手段。

李軍國[24]對(duì)基于軟件體系結(jié)構(gòu)的容錯(cuò)機(jī)制動(dòng)態(tài)配置技術(shù)做了深入研究，其中的錯(cuò)誤檢測模塊就劃分多類，有心跳探測、異常捕獲、接受性測試等，恢復(fù)模塊也有多種，如定向器、狀態(tài)重置器，以及分發(fā)器和收集器等，其整個(gè)容錯(cuò)模塊的調(diào)用則是通過一個(gè)容錯(cuò)管理服務(wù)。該文將這種可動(dòng)態(tài)調(diào)整的容錯(cuò)機(jī)制應(yīng)用到了北京大學(xué)的反射式JEE應(yīng)用服務(wù)器PKUAS中。這種動(dòng)態(tài)調(diào)整的容錯(cuò)機(jī)制的確考慮到了多種故障問題的容錯(cuò)機(jī)制調(diào)整策略，但其并未將其容錯(cuò)機(jī)制應(yīng)用到區(qū)塊鏈系統(tǒng)中。

本文設(shè)計(jì)的容錯(cuò)機(jī)制不僅讓其首次應(yīng)用到Fabric區(qū)塊鏈系統(tǒng)中，而且在其主節(jié)點(diǎn)故障檢測模塊中，在傳統(tǒng)的心跳探測之上添加了惡意攻擊的測試，為主節(jié)點(diǎn)增加了一道保障，并可以通過測試結(jié)果快速判斷出主節(jié)點(diǎn)是否故障，若主節(jié)點(diǎn)故障之后會(huì)立即進(jìn)入服務(wù)恢復(fù)模塊，啟動(dòng)備用節(jié)點(diǎn)恢復(fù)主節(jié)點(diǎn)丟失的數(shù)據(jù)，繼續(xù)保證系統(tǒng)正常運(yùn)作。

2 算法研究

本文在Fabric中為負(fù)責(zé)排序服務(wù)的orderer，增加了備用orderer，讓備用orderer主動(dòng)監(jiān)聽主orderer的運(yùn)行狀態(tài)，并發(fā)送一些對(duì)應(yīng)的特征測試用例，通過監(jiān)聽狀態(tài)以及這些特征測試結(jié)果，從而判斷出主orderer是否宕機(jī)或者被惡意攻擊。

算法1安全可靠性測試算法

輸入：主orderer的IP。

輸出：主orderer的運(yùn)行狀態(tài)。

主orderer端：

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

2. REPEAT

3. IF 接收到連接請求 THEN

4. 建立連接;

5. IFreceiveMessage==特征測試用例THEN

6.Send(特征測試結(jié)果);

7.Sleep(t1);

8. ELSE

9. 等待備用節(jié)點(diǎn)連接；

備用orderer端：

1. 獲取主orderer IP;

2. REPEAT

3. IF 連接成功 THEN

4.Send(特征測試用例);

5.Receive(特征測試結(jié)果);

6. IF(測試結(jié)果==惡意攻擊特征) THEN

7. 主orderer被惡意攻擊,MasterOrdererStatus=“Attack”;

8. UNTIL !MasterOrdererStatus;

9. ELSE

10. 主orderer 工作正常;

11. ELSE

12. 停止等待t2，嘗試連接;

13. IF 連接失敗 THEN

14. 主orderer宕機(jī)，MasterOrdererStatus=“Down”;

15. UNTIL!MasterOrdererStatus;

通過安全可靠性測試算法，備用orderer可以獲取主orderer的運(yùn)行狀態(tài)，一旦判斷出主orderer故障，那么備用orderer就要對(duì)其進(jìn)行業(yè)務(wù)數(shù)據(jù)方面的恢復(fù)，后面的算法就是針對(duì)其做的可靠性保障，將其分為數(shù)據(jù)同步備份算法和服務(wù)恢復(fù)算法。

算法2數(shù)據(jù)同步備份算法

輸入：主orderer的業(yè)務(wù)數(shù)據(jù)。

輸出：備份主orderer業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)庫。

主orderer端：

1. REPEAT

2. IF 緩存消息數(shù)量>MaxMessagesCountTHEN

//數(shù)量大于設(shè)置值

3. IF 產(chǎn)生新的消息隊(duì)列 THEN

4.TimeBatch:=time.Now();

5.Send(batch,TimeBatch);

//發(fā)送消息隊(duì)列給備用orderer

6. IF 產(chǎn)生新的區(qū)塊 THEN

7.TimeBlock:=time.Now();

8.Send(block,TimeBlock);

//發(fā)送區(qū)塊給備用orderer

9. IF 消息處理時(shí)間>BatchTimeOutTHEN

//處理時(shí)間大于設(shè)置值

10. IF 產(chǎn)生新的消息隊(duì)列 THEN

11.TimeBatch:=time.Now();

12.Send(batch,TimeBatch);

13. IF 產(chǎn)生新的區(qū)塊 THEN

14.TimeBlock:=time.Now();

15.Send(batch,TimeBlock);

備用orderer端：

1. REPEAT

2. IFReceive(batch,TimeBatch)==trueTHEN

3.envelope:=toByte(batch);

4.envelopeDB(TimeBatch,Msg);

//levelDB數(shù)據(jù)庫，主鍵:TimeBatch值:envelope

5. IFReceive(block,TimeBlock)==trueTHEN

6.block:=toByte(block);

7.blockDB(TimeBlock,block);

//levelDB數(shù)據(jù)庫，主鍵:TimeBlock，值:block

8. IFMasterOrdererStatus!=null THEN

9.TimeEnd:=time.Now();

10. IFMasterOrdererStatus==“Down” THEN

11.TimeKey:=TimeEnd-t1-t2;

//t1、t2分別為算法1的休眠時(shí)間和等待時(shí)間

12. ELSE

13.TimeKey:=TimeEnd-t1;

14. UNTIL !MasterOrdererStatus;

算法3服務(wù)恢復(fù)算法(數(shù)據(jù)庫遍歷查找)

輸入：主orderer故障指令，數(shù)據(jù)庫查找時(shí)間TimeKey。

輸出：需要還原的備份數(shù)據(jù)。

備用orderer端：

1.ID:=SelectNewOrdererID();

//共識(shí)算法外接函數(shù)，從多個(gè)備用orderer中選新主orderer

2.SendTakeOverCmd(ID);

//將新主ID，發(fā)送服務(wù)接管函數(shù)，建立與peer之間的通信

3.db:=OpenFile(“DB”);

//打開DB數(shù)據(jù)庫即envelopeDB 或blockDB數(shù)據(jù)庫

4.dbiter:=db.NewIterator;

//建立數(shù)據(jù)庫迭代器

5.i:=0;

6. REPEAT

7. IFdbiter.key>=TimeKeyTHEN

8.Copy(tmpStruct[i].key,dbiter.key);

//將備份數(shù)據(jù)暫存結(jié)構(gòu)體數(shù)組中

9.Copy(tmpStruct[i].value,dbiter.value);

10.i++;

11. UNTILdbiter.next==null

12. 將tmpStrcut數(shù)據(jù)發(fā)送給peer；

算法4服務(wù)恢復(fù)算法(建立B樹索引查找)

輸入：主orderer故障指令，數(shù)據(jù)庫查找時(shí)間TimeKey。

輸出：需要還原的備份數(shù)據(jù)。

備用orderer端：

1.ID:=SelectNewOrdererID();

2.SendTakeOverCmd(ID);

3.db:=OpenFile(“DB”);

4.dbiter:=db.NewIterator;

5.BTree:=newBT(M);

//構(gòu)建一個(gè)空的B樹, 定義B樹的階數(shù)為M

6. REPEAT

//構(gòu)建B樹索引

7.Flag:=BTree.Search(dbiter.key);

//查找此key是否已經(jīng)存在B樹中

8. IFFlag==falseTHEN

9.BTree.Insert(dbiter.key);

//將key值插入索引

10. ELSE

11. CONTINUE;

12. UNTILdbiter.next==null

13.i:=0;

14. REPEAT

15. REPEAT

16. UNTILi>BTree.num

//i小于結(jié)點(diǎn)內(nèi)關(guān)鍵字的個(gè)數(shù)

17. IFTimeKey

18.Copy(tmpStruct[i].key,BTree.data[i].key);

19.Copy(tmpStruct[i].value,BTree.data[i].value);

20.i++;

21.BTree=BTree.child[i];

22. UNTILBTree==null

23. 將tmpStrcut數(shù)據(jù)發(fā)送給peer；

對(duì)于服務(wù)恢復(fù)算法，首先是從兩個(gè)備份數(shù)據(jù)庫中分別獲取數(shù)據(jù)，由于數(shù)據(jù)庫的主鍵存儲(chǔ)是用時(shí)間戳來存儲(chǔ)的，所以本文設(shè)計(jì)從TimeEnd-t1-t2(t1、t2來自算法1)時(shí)刻開始獲取數(shù)據(jù)，將數(shù)據(jù)暫存在結(jié)構(gòu)體數(shù)組中。在與peer建立連接之后，對(duì)于區(qū)塊數(shù)據(jù)便將其直接發(fā)送給peer，但是對(duì)于消息序列數(shù)據(jù)需要調(diào)用orderer的CreatNextBlock()函數(shù)，打包成區(qū)塊，再發(fā)送給peer。所以本文針對(duì)時(shí)間戳查找做了兩種服務(wù)恢復(fù)算法，一種是數(shù)據(jù)庫遍歷查找服務(wù)恢復(fù)，另一種是為數(shù)據(jù)庫建立B樹索引查找服務(wù)恢復(fù)。

3 實(shí) 驗(yàn)

3.1 實(shí)驗(yàn)環(huán)境

本文實(shí)驗(yàn)的硬件環(huán)境是一臺(tái)操作系統(tǒng)為Linux并配置有8 GB內(nèi)存、3.40 GHz CPU的電腦；軟件環(huán)境是基于Fabric1.0版本，在官方給出的examples/e2e_cli案例基礎(chǔ)之上，進(jìn)行二次開發(fā)，并且e2e_cli使用的共識(shí)模式solo，在原先的2個(gè)peer組織即4個(gè)peer節(jié)點(diǎn)，1個(gè)orderer組織即1個(gè)orderer節(jié)點(diǎn)基礎(chǔ)之上增加到4個(gè)orderer節(jié)點(diǎn)以及7個(gè)peer節(jié)點(diǎn)，指定其中主orderer和備用orderer。

3.2 實(shí)驗(yàn)數(shù)據(jù)

本實(shí)驗(yàn)所需要的數(shù)據(jù)主要是peer之間的交易信息，利用peer之間進(jìn)行頻繁的轉(zhuǎn)賬操作，生成交易信息，從而提交到主orderer節(jié)點(diǎn)，為備用orderer的備份提供數(shù)據(jù)。

本文選取的數(shù)據(jù)集來源于國泰安數(shù)據(jù)中心[25]，數(shù)據(jù)集如表1所示。

表1 中航地產(chǎn)證券的交易數(shù)據(jù)(部分)

本文使用的均為證券交易數(shù)據(jù)，共用了10組數(shù)據(jù)集，即十家企業(yè)證券在2009年至2010年的交易數(shù)據(jù)，每組數(shù)據(jù)集的數(shù)據(jù)量的大小如表2所示。

表2 數(shù)據(jù)集的數(shù)據(jù)量大小

3.3 實(shí)驗(yàn)場景

首先利用實(shí)驗(yàn)數(shù)據(jù)模擬peer之間的正常轉(zhuǎn)賬場景，其中peer1作為購買證券的客戶，peer2作為一家證券企業(yè)，通過cli工具執(zhí)行兩個(gè)peer之間的轉(zhuǎn)賬函數(shù)。以表1中每一行的交易金額作為每一次執(zhí)行的轉(zhuǎn)賬金額，從而為主orderer產(chǎn)生需要排序、打包的交易數(shù)據(jù)，同時(shí)也會(huì)讓備用orderer的備份功能運(yùn)轉(zhuǎn)起來，從而為備用orderer恢復(fù)主orderer業(yè)務(wù)做好鋪墊。

其次是對(duì)主orderer的惡意攻擊的場景模擬，主要是Linux系統(tǒng)中最常見的兩種病毒攻擊。

第一種模擬主orderer受到Ramen蠕蟲[26]攻擊，即讓主orderer滿足如下要求：

(1) 存在/usr/src/.poop目錄。

(2) 存在/sbin/asp文件。

(3) 本地端口27374被打開。

第二種模擬主orderer被Rootkit病毒[27]攻擊，即讓主orderer滿足如下要求：

(1) 網(wǎng)絡(luò)占用率達(dá)到90%以上。

(2) CPU占用率達(dá)到100%。

在這種制造故障的情形下，可以觀察備用orderer能否正常運(yùn)轉(zhuǎn)業(yè)務(wù)恢復(fù)。

3.4 實(shí)驗(yàn)過程

在Fabric網(wǎng)絡(luò)啟動(dòng)成功之后，實(shí)驗(yàn)過程分為以下8步。

步驟1查看備用orderer與主orderer的日志來確定它們之間是否建立連接、是否開始檢測，對(duì)于測試算法中需要的特征測試用例，依據(jù)需要針對(duì)的惡意攻擊特征去生成。本實(shí)驗(yàn)?zāi)M的惡意攻擊手段是Ramen蠕蟲和Rootkit病毒，因此測試用例的生成就要依據(jù)實(shí)驗(yàn)場景中說明的兩種病毒的特征去生成。

步驟2將peer組織中的節(jié)點(diǎn)和主orderer以及備用orderer加入同一通道，之后就是進(jìn)行chaincode安裝以及實(shí)例化，目的是制定peer之間正常交易的規(guī)則，之后就是實(shí)現(xiàn)peer之間的轉(zhuǎn)賬操作，為主orderer提供交易數(shù)據(jù)。

步驟3通過查看主orderer的實(shí)時(shí)日志，可以知道其已經(jīng)接收到這些交易數(shù)據(jù)，并且已經(jīng)通過接收時(shí)間的先后生成了消息序列，那么查看備份節(jié)點(diǎn)實(shí)時(shí)日志，是否同步備份好這些消息序列，可以通過打印envelopeDB和blockDB數(shù)據(jù)庫的數(shù)據(jù)量來確定是否同步備份好主orderer的數(shù)據(jù)。

步驟4利用3.3節(jié)的病毒模擬注入，同時(shí)在算法1中t1=3 s之后，備用orderer立刻檢測出主orderer受到惡意攻擊，并記錄TimeEnd。

步驟5備用orderer立刻停止對(duì)主orderer的檢測，使用外接函數(shù)SelectNewOrdererID()獲取新主orderer的ID，然后將此ID傳入SendTakeOverCmd()函數(shù)，使用此函數(shù)建立與peer之間的通信，從而替換舊主orderer。

步驟6新主orderer中的服務(wù)恢復(fù)算法立刻使用TimeEnd-t1的時(shí)間作為還原數(shù)據(jù)的TimeKey，如果是主orderer自主宕機(jī)之后，就需要再減去t2。對(duì)于兩個(gè)服務(wù)恢復(fù)算法，需要比較其恢復(fù)時(shí)間，因此執(zhí)行步驟7、步驟8并對(duì)比其兩種恢復(fù)時(shí)間。

步驟7在兩種沒有索引的數(shù)據(jù)庫envelopeDB和blockDB中查找，遇到key值比TimeKey大的數(shù)據(jù)，就存儲(chǔ)起來，并且記錄此方法的開始時(shí)間和結(jié)束時(shí)間，計(jì)算總的運(yùn)行時(shí)間，最后將需要還原的envelope數(shù)據(jù)劃分為區(qū)塊之后傳遞給peer，而需要還原的block則直接發(fā)送給peer。

步驟8通過建立B樹索引的數(shù)據(jù)庫來還原數(shù)據(jù)，計(jì)算此方法的運(yùn)行時(shí)間。

3.5 實(shí)驗(yàn)結(jié)果

利用10組數(shù)據(jù)集進(jìn)行了10組實(shí)驗(yàn)，每一組數(shù)據(jù)進(jìn)行一組實(shí)驗(yàn)，以下所有數(shù)據(jù)圖中每組的接管反應(yīng)時(shí)間、恢復(fù)數(shù)據(jù)量、數(shù)據(jù)庫查找時(shí)間均為此組數(shù)據(jù)集多次重復(fù)實(shí)驗(yàn)的均值，模擬了病毒攻擊，并統(tǒng)計(jì)了備用orderer接管主orderer業(yè)務(wù)的反應(yīng)時(shí)間，反應(yīng)時(shí)間基本在4 s左右，如圖1所示。

圖1 備用orderer的接管反應(yīng)時(shí)間

統(tǒng)計(jì)了實(shí)驗(yàn)中數(shù)據(jù)恢復(fù)的數(shù)據(jù)量，如圖2所示。

圖2 恢復(fù)的數(shù)據(jù)量

可以看出，不同的數(shù)據(jù)集恢復(fù)的數(shù)據(jù)量大小會(huì)有所差異，主要是因?yàn)閿?shù)據(jù)量的恢復(fù)取決于主orderer故障期間接收到的數(shù)據(jù)量。

統(tǒng)計(jì)了區(qū)塊和消息序列數(shù)據(jù)庫使用遍歷查找的服務(wù)恢復(fù)算法所用的時(shí)間，如圖3所示。

圖3 數(shù)據(jù)庫遍歷查找恢復(fù)時(shí)間

圖3刻畫了在數(shù)據(jù)庫中遍歷查找備份數(shù)據(jù)所消耗的時(shí)間，可以看出數(shù)據(jù)集2、4、9普遍低一些，這是因?yàn)檫@三個(gè)數(shù)據(jù)集數(shù)據(jù)量較少導(dǎo)致數(shù)據(jù)庫中備份數(shù)據(jù)較少。

與圖3使用遍歷查找算法對(duì)應(yīng)的是使用B樹索引查找的服務(wù)恢復(fù)算法，其恢復(fù)過程所用的時(shí)間如圖4所示。

圖4 數(shù)據(jù)庫B樹索引查找恢復(fù)時(shí)間

同樣地，圖4刻畫了在建立B樹索引的數(shù)據(jù)庫找備份數(shù)據(jù)所消耗的時(shí)間，并且普遍低于圖3的遍歷查找時(shí)間消耗，這也說明了服務(wù)恢復(fù)算法中建立B樹索引查找還是較優(yōu)的。

4 結(jié) 語

本文為Fabric區(qū)塊鏈增加了容錯(cuò)機(jī)制，并且在利用心跳機(jī)制的診斷方法之上增加了惡意攻擊的測試算法，進(jìn)一步完善了故障診斷技術(shù)，更加保障了主orderer的安全可靠性。當(dāng)主orderer遇到故障之后造成主orderer未及時(shí)傳輸出去的交易數(shù)據(jù)丟失的問題，以及無法繼續(xù)負(fù)責(zé)交易數(shù)據(jù)的排序及打包成區(qū)塊的工作，做了相應(yīng)的備用orderer恢復(fù)主orderer的保障機(jī)制。通過實(shí)驗(yàn)，本文算法的可用性得到了初步的驗(yàn)證。

由于本文提出的容錯(cuò)機(jī)制是首次在區(qū)塊鏈中嘗試，所以仍存在一些技術(shù)難題，如：主orderer故障之后peer對(duì)于orderer的連接還未及時(shí)切換到新主orderer上，仍繼續(xù)會(huì)向舊主orderer發(fā)送數(shù)據(jù)，怎么來保證這一段時(shí)間內(nèi)數(shù)據(jù)的不丟失將是今后繼續(xù)研究的方向。