基于分組Raft機(jī)制的PBFT共識(shí)算法改進(jìn)方案設(shè)計(jì)

吳宇森 劉伊然 吳沅賽 史庭俊

（揚(yáng)州大學(xué)信息工程學(xué)院 江蘇省揚(yáng)州市 225127）

1 引言

十幾年前隨著比特幣[1]的誕生，區(qū)塊鏈和比特幣的概念被越來越多的人知曉。區(qū)塊鏈技術(shù)[2]本身也因其可溯源、不可篡改的特性而被廣泛研究。聯(lián)盟鏈[3]作為區(qū)塊鏈2.0 的產(chǎn)物，真正做到了讓區(qū)塊鏈和比特幣、以太幣這些虛擬貨幣脫鉤。聯(lián)盟鏈由多個(gè)組織、機(jī)構(gòu)參與其中，鏈上的數(shù)據(jù)無法被外部訪問且不可被篡改，數(shù)據(jù)的安全性得到了極大的保障。在銀行、醫(yī)療等領(lǐng)域有著很廣泛的應(yīng)用價(jià)值，而PBFT 作為聯(lián)盟鏈的核心共識(shí)算法，關(guān)系著整個(gè)聯(lián)盟鏈的效率和安全性[4]，但PBFT 算法本身仍存在隨著節(jié)點(diǎn)增加，性能明顯下降以及節(jié)點(diǎn)作惡得不到有效監(jiān)管等問題，因而對(duì)PBFT 算法的優(yōu)化顯然是必不可少的。

2 PBFT、Raft算法簡介及相關(guān)研究

2.1 Raft共識(shí)算法

Raft[5]共識(shí)算法存在節(jié)點(diǎn)活躍度不高，故障節(jié)點(diǎn)數(shù)量較多會(huì)影響共識(shí)效率的問題。若直接將分組Raft機(jī)制應(yīng)用于PBFT共識(shí)算法的優(yōu)化，會(huì)將Raft 算法本身存在的問題帶入到每個(gè)小組組內(nèi)，因而需使用RageRank[6]算法對(duì)Raft 算法進(jìn)行優(yōu)化，然后再使用優(yōu)化后的Raft 算法，采用分組機(jī)制應(yīng)用于PBFT 算法中，實(shí)現(xiàn)對(duì)PBFT 算法的優(yōu)化。

PageRank 算法最初是被用來衡量谷歌網(wǎng)頁的重要性。在該算法中，一個(gè)節(jié)點(diǎn)的PR 值是由所有指向它的節(jié)點(diǎn)的重要性通過多次遞歸算法得到的，最終得到的PR 值越高代表此節(jié)點(diǎn)的重要性越高，因而也可以理解為一個(gè)節(jié)點(diǎn)的重要性取決于所有指向它的節(jié)點(diǎn)的重要性。公式（1）中L(pj)是節(jié)點(diǎn)pj的出鏈總數(shù)，每個(gè)節(jié)點(diǎn)初始PR值為1/N，N 是節(jié)點(diǎn)總數(shù)，是有出鏈到節(jié)點(diǎn)pi的所有節(jié)點(diǎn)集合，t 為迭代輪數(shù)，α 為阻尼系數(shù)來解決孤立節(jié)點(diǎn)對(duì)PR 值分配時(shí)的負(fù)面，同時(shí)起到對(duì)PageRank 公式修正的作用，式（1）為PageRank 修正公式：

Raft 算法是由Paxos 算法優(yōu)化而來，Paxos 算法由于過于復(fù)雜，讓大多數(shù)人都很難真正去理解，于是有兩位研究者[7]通過對(duì)Paxos算法的深入研究，最終提出了更加容易理解，也更容易應(yīng)用到實(shí)際系統(tǒng)當(dāng)中的Raft 算法。該算法中有三個(gè)角色：領(lǐng)導(dǎo)者、跟隨者、候選者。領(lǐng)導(dǎo)者節(jié)點(diǎn)負(fù)責(zé)接收客戶端的請求和日志的同步管理，與跟隨者節(jié)點(diǎn)共識(shí)后，將請求結(jié)果反饋給客戶端，跟隨者節(jié)點(diǎn)負(fù)責(zé)響應(yīng)領(lǐng)導(dǎo)者節(jié)點(diǎn)的日志同步請求，候選者節(jié)點(diǎn)是由跟隨者節(jié)點(diǎn)在領(lǐng)導(dǎo)者節(jié)點(diǎn)宕機(jī)時(shí)轉(zhuǎn)變而來，參與新領(lǐng)導(dǎo)者的選舉，若獲得半數(shù)投票則成為新的領(lǐng)導(dǎo)者節(jié)點(diǎn)，若失敗則轉(zhuǎn)變回跟隨者節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)任一時(shí)刻都處于這三個(gè)狀態(tài)之一。Raft 算法為了保證復(fù)制日志的一致性，其具體流程如下：

Step1：領(lǐng)導(dǎo)者節(jié)點(diǎn)收到客戶端發(fā)來的請求。

Step2：領(lǐng)導(dǎo)者節(jié)點(diǎn)將收到的命令追加到本地日志，然后并發(fā)復(fù)制給其它跟隨者節(jié)點(diǎn)。

Step3：跟隨者節(jié)點(diǎn)將命令寫入到日志中，并反饋確認(rèn)復(fù)制給領(lǐng)導(dǎo)者節(jié)點(diǎn)。

Step4：領(lǐng)導(dǎo)者節(jié)點(diǎn)收到過半的反饋后，就會(huì)提交命令，并返回結(jié)果給客戶端。

Step5：最后領(lǐng)導(dǎo)者節(jié)點(diǎn)發(fā)送讓跟隨者節(jié)點(diǎn)提交命令的消息。

2.2 PBFT共識(shí)算法

PBFT 算法[8]在1999年被提出，用于解決拜占庭容錯(cuò)問題。但該算法存在節(jié)點(diǎn)活躍度不高，性能隨著節(jié)點(diǎn)增加而明顯降低，作惡節(jié)點(diǎn)無法被監(jiān)督并被及時(shí)踢出聯(lián)盟鏈等問題，于是筆者將采用分組Raft機(jī)制來優(yōu)化PBFT共識(shí)算法，將若干節(jié)點(diǎn)分為多個(gè)組，組內(nèi)采用基于PageRank 算法優(yōu)化的Raft 共識(shí)算法，組外依然保留PBFT共識(shí)算法。

PBFT 算法最大容錯(cuò)節(jié)點(diǎn)數(shù)量是（n-1）/3，可以理解為，如果惡意節(jié)點(diǎn)的數(shù)量為f，正常節(jié)點(diǎn)的數(shù)量至少是2f+1，才能讓系統(tǒng)正常運(yùn)轉(zhuǎn)。假設(shè)存在f 個(gè)惡意節(jié)點(diǎn)以及f 個(gè)故障節(jié)點(diǎn)這種極端情況，要保證系統(tǒng)依然有至少f+1 個(gè)正常節(jié)點(diǎn)能讓共識(shí)順利達(dá)成，因此節(jié)點(diǎn)總數(shù)至少為3f+1。

PBFT共識(shí)算法中包含三個(gè)角色，主節(jié)點(diǎn)，副本節(jié)點(diǎn)，客戶端。主要包含三個(gè)階段：預(yù)準(zhǔn)備階段、準(zhǔn)備階段、確認(rèn)階段，三個(gè)階段的流程如下：

Step1：預(yù)準(zhǔn)備階段：主節(jié)點(diǎn)收到客戶端發(fā)送來的請求后，驗(yàn)證其簽名是否正確，若不正確則丟棄，若為正確請求，按順序分配編號(hào)n，廣播<,m>消息給其它副本節(jié)點(diǎn)。

Step2：準(zhǔn)備階段：副本節(jié)點(diǎn)驗(yàn)證主節(jié)點(diǎn)發(fā)送的PRE-PERPARE消息，若為正確請求，則向其他節(jié)點(diǎn)廣播消息。

Step3：確認(rèn)階段：節(jié)點(diǎn)對(duì)收到的PREPARE 消息進(jìn)行驗(yàn)證，若非法則丟棄，收到2f+1 個(gè)（包含自己）通過驗(yàn)證的PREPARE 消息，則廣播給其它節(jié)點(diǎn)。PBFT共識(shí)算法流程圖如圖1所示。

圖1：PBFT共識(shí)算法流程圖

2.3 相關(guān)研究

近年來對(duì)區(qū)塊鏈共識(shí)機(jī)制的研究，主要集中在對(duì)PBFT共識(shí)算法的研究，黃冬艷等人[9]提出一種基于Raft 集群的拜占庭容錯(cuò)共識(shí)機(jī)制，組內(nèi)用Raft 算法共識(shí)，組外采用PBFT 算法共識(shí)，提升了共識(shí)效率，但是并沒有解決組內(nèi)成員積極性的問題。陳忠賢等人[10]提出一種基于通信時(shí)間分組的PBFT 算法改進(jìn)方案，基于最短通信時(shí)間進(jìn)行分組，先組內(nèi)共識(shí)再組外共識(shí)，提升了共識(shí)效率。陳子豪等人[11]提出一種基于K-medoids 的改進(jìn)PBFT共識(shí)機(jī)制，通過K-medoids 算法對(duì)節(jié)點(diǎn)進(jìn)行分組，先組內(nèi)共識(shí)再組外共識(shí)，提升了共識(shí)效率。但是這兩個(gè)方案仍然沒有解決節(jié)點(diǎn)作惡的問題。劉乃安等人[12]提出一種面向區(qū)塊鏈驗(yàn)證節(jié)點(diǎn)的聲譽(yù)證明共識(shí)機(jī)制，根據(jù)節(jié)點(diǎn)的歷史活躍度和信用情況分配聲譽(yù)值，提升了節(jié)點(diǎn)積極性，一定程度上抵制了節(jié)點(diǎn)作惡，但這個(gè)方案并沒有解決原始PBFT 算法中存在的通信次數(shù)過多而性能不高的問題。

目前對(duì)PBFT共識(shí)算法的研究往往存在積極性、安全性和性能三者不能同時(shí)兼得的問題，本文提出了一種GRBFT（Group Raft Byzantine Fault Tolerance）共識(shí)算法。首先對(duì)節(jié)點(diǎn)進(jìn)行分組，先組內(nèi)共識(shí)再組外共識(shí)，減少了通信次數(shù)，大幅提升性能，同時(shí)組內(nèi)采用基于PageRank 算法優(yōu)化的Raft 共識(shí)算法，解決了組內(nèi)積極性不高的問題，降低了組內(nèi)故障節(jié)點(diǎn)對(duì)共識(shí)效率的影響，然后引入一個(gè)排序節(jié)點(diǎn)，將客戶端的每個(gè)請求排序好發(fā)給所有組長節(jié)點(diǎn)，避免了過去單一主節(jié)點(diǎn)權(quán)利較大，一旦作惡帶來的影響較大的問題，最后每個(gè)小組的組內(nèi)引入監(jiān)傳節(jié)點(diǎn)，有效的抵制組員和組長作惡的問題，提升了系統(tǒng)的安全性。

3 GRBFT共識(shí)算法

GRBFT共識(shí)算法分為組外共識(shí)和組內(nèi)共識(shí)兩個(gè)部分，先組內(nèi)共識(shí)，再由各組組長帶著組內(nèi)共識(shí)結(jié)果參與組外共識(shí)。首先將所有節(jié)點(diǎn)，分為K 個(gè)組，每個(gè)組內(nèi)包含N 個(gè)成員。組內(nèi)采用基于PageRank 優(yōu)化的Raft 共識(shí)算法，組內(nèi)成員N ≥3。參與組外共識(shí)的節(jié)點(diǎn)為每個(gè)小組組內(nèi)選出的組長，組外共識(shí)采用PBFT 的共識(shí)算法，PBFT 算法中由于總節(jié)點(diǎn)數(shù)m 對(duì)惡意節(jié)點(diǎn)數(shù)f 要滿足m ≥3f+1 的關(guān)系，組外成員K ≥4。

3.1 組內(nèi)共識(shí)

3.1.1 組內(nèi)共識(shí)方案

組內(nèi)使用PageRank 算法對(duì)Raft 共識(shí)算法進(jìn)行優(yōu)化，每個(gè)節(jié)點(diǎn)初始PR 值為1/N，N 為節(jié)點(diǎn)個(gè)數(shù)，在一個(gè)周期時(shí)間T 內(nèi)，根據(jù)組內(nèi)節(jié)點(diǎn)不同的歷史活躍度，通過PageRank 算法多次迭代，等結(jié)果收斂后分配節(jié)點(diǎn)對(duì)應(yīng)的新的PR 值。領(lǐng)導(dǎo)者節(jié)點(diǎn)與跟隨者節(jié)點(diǎn)交互期間，每個(gè)跟隨者節(jié)點(diǎn)回應(yīng)領(lǐng)導(dǎo)者節(jié)點(diǎn)時(shí)會(huì)附帶自身PR 值，領(lǐng)導(dǎo)者節(jié)點(diǎn)收到過半的PR 值便能達(dá)成共識(shí)，并將該方案作為組內(nèi)共識(shí)方案。由于Raft 算法本身無法抵制作惡節(jié)點(diǎn)，筆者將在后續(xù)引入組內(nèi)監(jiān)傳節(jié)點(diǎn)。該方案讓更活躍的節(jié)點(diǎn)擁有更高的PR 值，同時(shí)提高共識(shí)效率，并且比起組內(nèi)依然實(shí)行PBFT 算法，Raft 算法擁有更低的時(shí)間復(fù)雜度，即使組內(nèi)成員增加，效率也不會(huì)大幅下降。

3.1.2 采用PageRank 修正公式來優(yōu)化

考慮到組內(nèi)存在孤立節(jié)點(diǎn)的可能性，因而采用PageRank 修正公式，筆者將該公式矩陣化表達(dá)，來便于代碼的實(shí)現(xiàn)，首先構(gòu)建一個(gè)矩陣M，矩陣其中的任意元素Mij代表節(jié)點(diǎn)pj指向節(jié)點(diǎn)pi的概率，其分子weightij為節(jié)點(diǎn)pj向pi發(fā)送請求或回應(yīng)的總次數(shù)，分母L(pj)為節(jié)點(diǎn)pj給所有其它節(jié)點(diǎn)發(fā)送信息的總數(shù)，式（2）為元素Mij的公式：

再構(gòu)建一個(gè)列向量Vt，里面存放第t-1 輪迭代后每個(gè)節(jié)點(diǎn)的PR值PR(pi)，V1中每個(gè)節(jié)點(diǎn)初始PR 值為1/N，式（3）為Vt的公式：

多次迭代，直到最終收斂，迭代停止，并得到最終迭代結(jié)果Vt+1，每個(gè)節(jié)點(diǎn)最終PR 值PR(pi)存放在里面，其中N 為總節(jié)點(diǎn)數(shù)，α 為阻尼系數(shù)，用來解決出鏈為零的孤立節(jié)點(diǎn)問題，式（4）為Vt+1的公式：

由于組長與所有其它組員交互，因而其PR 值PR(pi)組長會(huì)過高，為了避免過于中心化的情況，需要對(duì)組長的PR 值進(jìn)行修正，將其自身的PR 值降低為原始PR 值的倍，降低組長作惡的影響，式（5）為修正公式：

3.1.3 組內(nèi)引入監(jiān)傳節(jié)點(diǎn)

基于PageRank 算法優(yōu)化的Raft 共識(shí)算法雖然可以通過降低故障節(jié)點(diǎn)或者不活躍節(jié)點(diǎn)的PR 值來減少它們對(duì)共識(shí)效率的影響，但對(duì)于該組組長與組員的作惡不能起到很好的抵制作用，因而需要在每個(gè)小組里增加一個(gè)絕對(duì)公正的監(jiān)傳節(jié)點(diǎn)，讓組長和組員間通過監(jiān)傳節(jié)點(diǎn)當(dāng)中間人傳遞彼此的信息，由于監(jiān)傳節(jié)點(diǎn)不參與共識(shí)投票，只是作為信息傳遞的中轉(zhuǎn)站，可以做到公正，還可以通過驗(yàn)證組員和組長發(fā)送的信息，來找出作惡節(jié)點(diǎn)，并發(fā)起投票踢出。

組長會(huì)一直給監(jiān)傳節(jié)點(diǎn)發(fā)送自己的心跳，表明自己沒有宕機(jī)，監(jiān)傳節(jié)點(diǎn)如果能收到組長的心跳，也會(huì)給組員發(fā)送自己的心跳，如果監(jiān)傳節(jié)點(diǎn)接收不到組長的心跳，將發(fā)起換屆選舉，組內(nèi)將選出新的組長，新的組長由當(dāng)前PR 值最高的組員擔(dān)任。

由于監(jiān)傳節(jié)點(diǎn)為了保證公正，不參與共識(shí)投票且不擁有PR 值，所以在計(jì)算PR 值時(shí)，忽略監(jiān)傳節(jié)點(diǎn)的存在，組長與組員通過監(jiān)傳節(jié)點(diǎn)來通信分配到的PR 值等同于組長與組員直接通信分配得到的PR 值。監(jiān)傳節(jié)點(diǎn)每隔一個(gè)周期時(shí)間T，就會(huì)根據(jù)組員和組長過去的表現(xiàn)，通過PageRank 算法給組長和組員分配新的PR 值，并對(duì)組長PR 值進(jìn)行修正。每個(gè)成員初試PR 值均為1/N，N 為組員成員數(shù)量，包含組長，不包含監(jiān)傳節(jié)點(diǎn)。組內(nèi)共識(shí)流程圖如圖2所示。

圖2：組內(nèi)共識(shí)流程圖

若監(jiān)傳節(jié)點(diǎn)發(fā)現(xiàn)組長作惡，將向所有組員發(fā)起，其中evidence 為判定組長作惡的證據(jù)，n 為作惡消息的編號(hào)，組員會(huì)驗(yàn)證收到的消息，消息驗(yàn)證無誤后，投票給監(jiān)傳節(jié)點(diǎn)，監(jiān)傳節(jié)點(diǎn)若收到組員過半投票，則踢出該組組長，并且將該組長的PR 值，根據(jù)每個(gè)組員PR 值占所有組員PR 值的比例分配給每個(gè)組員，并由此時(shí)PR 值最高的組員擔(dān)任組長。

如圖3所示，若監(jiān)傳節(jié)點(diǎn)發(fā)現(xiàn)組員作惡，將向組長和其它組員發(fā)起，其中evidence 為判定組員作惡的證據(jù)，n 為作惡消息的編號(hào)，組員和組長對(duì)該消息進(jìn)行驗(yàn)證，消息驗(yàn)證無誤后，投票給監(jiān)傳節(jié)點(diǎn)，監(jiān)傳節(jié)點(diǎn)若收到過半投票，則踢出該組員，并且將該組員的PR 值，根據(jù)每個(gè)成員PR 值占該組非作惡成員總PR 值的比重，來分配給每個(gè)組員。

圖3：監(jiān)傳節(jié)點(diǎn)踢出作惡節(jié)點(diǎn)流程

3.2 組外共識(shí)

3.2.1 排序節(jié)點(diǎn)的引入

引入一個(gè)公正的排序節(jié)點(diǎn)，僅負(fù)責(zé)驗(yàn)證客戶端請求簽名是否正確和對(duì)客戶端發(fā)來的請求進(jìn)行編號(hào)排序。由于其不參與共識(shí)投票，主要負(fù)責(zé)請求的排序，因而可以做到公正。排序節(jié)點(diǎn)將客戶端發(fā)來的請求排序好發(fā)給組長節(jié)點(diǎn)。

3.2.2 組長的選取

由于每個(gè)小組內(nèi)遵循的是Raft 共識(shí)算法，初次組長的選取遵循Raft 領(lǐng)導(dǎo)節(jié)點(diǎn)選取機(jī)制，后續(xù)若監(jiān)傳節(jié)點(diǎn)發(fā)現(xiàn)組長宕機(jī)或作惡，將由組員里當(dāng)前PR 值最高的組員擔(dān)任新的組長。

3.2.3 組外共識(shí)方案

如圖4所示，組長間的共識(shí)遵循PBFT共識(shí)算法。首先組長們會(huì)將排序節(jié)點(diǎn)發(fā)來的請求通過監(jiān)傳節(jié)點(diǎn)發(fā)給組員，組員們會(huì)對(duì)請求回應(yīng)并在回應(yīng)中附帶自身當(dāng)前PR 值的數(shù)值，每個(gè)組員的回應(yīng)會(huì)先傳給監(jiān)傳節(jié)點(diǎn)，監(jiān)傳節(jié)點(diǎn)收到的有效返回的信息中包含的PR 值的累計(jì)數(shù)值加上組長的PR 值過半后，便會(huì)把收到的結(jié)果反饋給組長，組長驗(yàn)證無誤后，會(huì)按照PBFT共識(shí)算法的流程，先進(jìn)入準(zhǔn)備階段，廣播PREPARE 消息，收到2f+1 個(gè)組長(包含自己)發(fā)送來的PREPARE 消息，則進(jìn)入確認(rèn)階段，廣播COMMIT 消息，收到2f+1 個(gè)組長(包含自己)發(fā)送來的COMMIT 消息，則發(fā)送REPLY給客戶端，并發(fā)送數(shù)據(jù)提交給組內(nèi)監(jiān)傳節(jié)點(diǎn)，客戶端收到f+1 個(gè)REPLY，則共識(shí)達(dá)成。

圖4：組外共識(shí)流程

3.3 GRBFT共識(shí)算法的流程

Step1：客戶端給排序節(jié)點(diǎn)發(fā)送請求。

Step2：排序節(jié)點(diǎn)驗(yàn)證簽名無誤后，給請求分配編號(hào)n，廣播<,m>消息給所有組長節(jié)點(diǎn)。

Step3：組長節(jié)點(diǎn)對(duì)排序節(jié)點(diǎn)發(fā)送的PRE-PERPARE 消息進(jìn)行驗(yàn)證，若為正確請求，則廣播消息給監(jiān)傳節(jié)點(diǎn)。

Step4：監(jiān)傳節(jié)點(diǎn)將消息轉(zhuǎn)發(fā)給組員，讓組員進(jìn)行復(fù)制，組員們會(huì)將對(duì)請求的回應(yīng)發(fā)送給監(jiān)傳節(jié)點(diǎn)，并在回應(yīng)中附帶自身當(dāng)前PR 值的數(shù)值。

Step5：監(jiān)傳節(jié)點(diǎn)收到的有效返回的信息中包含的PR 值的累計(jì)數(shù)值加上組長的PR 值過半后，便會(huì)把收到的結(jié)果反饋給組長。

Step6：監(jiān)傳節(jié)點(diǎn)每隔一段周期時(shí)間T，就會(huì)根據(jù)組員和組長過去的表現(xiàn)，通過PageRank 算法給組長和組員分配新的PR 值，并對(duì)組長PR 值進(jìn)行修正。

Step7：組長對(duì)監(jiān)傳節(jié)點(diǎn)發(fā)來的消息進(jìn)行驗(yàn)證，驗(yàn)證無誤后，便進(jìn)入準(zhǔn)備階段，廣播給其它組長節(jié)點(diǎn)。

Step8：組長們會(huì)對(duì)收到的PREPARE 消息進(jìn)行驗(yàn)證，若非法則丟棄，收到2f+1 個(gè)（包含自己）通過驗(yàn)證的PREPARE 消息，則向其他組長節(jié)點(diǎn)廣播。

Step9：組長們會(huì)對(duì)收到的COMMIT 消息進(jìn)行驗(yàn)證，若非法則丟棄，收到2f+1 個(gè)（包含自己）通過驗(yàn)證的COMMIT 消息，則發(fā)送REPLY 給客戶端，并發(fā)送數(shù)據(jù)提交給組內(nèi)監(jiān)傳節(jié)點(diǎn)，監(jiān)傳節(jié)點(diǎn)發(fā)送數(shù)據(jù)提交給每個(gè)組員。

Step10：客戶端收到f+1 個(gè)組長發(fā)來的REPLY 信息，則共識(shí)達(dá)成。

4 實(shí)驗(yàn)與分析

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

實(shí)驗(yàn)環(huán)境選用的宿主機(jī)系統(tǒng)為Window10，處理器為AMD R5 2600，宿主機(jī)內(nèi)存為16g，測試平臺(tái)軟件的開發(fā)環(huán)境為ubuntu20.04/Golang1.16。

4.2 最大可容忍惡意節(jié)點(diǎn)數(shù)比較

筆者通過比較兩個(gè)算法最大可容忍惡意節(jié)點(diǎn)數(shù)來區(qū)分哪一個(gè)算法擁有更好的安全性，可以容忍更多的惡意節(jié)點(diǎn)，首先筆者設(shè)GRBFT 算法中每個(gè)組的節(jié)點(diǎn)數(shù)均為5，然后模擬實(shí)驗(yàn)，觀察兩個(gè)算法，在隨著節(jié)點(diǎn)數(shù)量的增加下，最大可容忍惡意節(jié)點(diǎn)數(shù)的變化情況，實(shí)驗(yàn)結(jié)果如圖5所示。

圖5：兩個(gè)算法最大可容忍惡意節(jié)點(diǎn)數(shù)對(duì)比

從圖5 中筆者可以看出隨著節(jié)點(diǎn)數(shù)量的增加，GRBFT 算法比起PBFT 算法總是可以容忍更多的惡意節(jié)點(diǎn)數(shù)，因而GRBFT 算法有著更好的安全性。

4.3 吞吐量比較

吞吐量指系統(tǒng)每秒鐘處理的事務(wù)的數(shù)量，吞吐量越高代表著系統(tǒng)單位時(shí)間能處理的事務(wù)就越多，性能就越好。

吞吐量可以很好的反應(yīng)一個(gè)系統(tǒng)的性能，用來衡量兩個(gè)算法對(duì)系統(tǒng)的影響是非常合適的，筆者在不同節(jié)點(diǎn)數(shù)下都會(huì)進(jìn)行10 次模擬實(shí)驗(yàn)，把10 次實(shí)驗(yàn)中的平均值作為該節(jié)點(diǎn)數(shù)下的吞吐量，實(shí)驗(yàn)結(jié)果如圖6所示。

圖6：PBFT 與GRBFT 吞吐量比對(duì)圖

從圖6 中可以看出，GRBFT 算法比起PBFT 算法，在不同節(jié)點(diǎn)數(shù)量下，均擁有更高的吞吐量，且隨著節(jié)點(diǎn)數(shù)量的增加，PBFT算法的吞吐量已經(jīng)下降到1000 以下，而GRBFT 算法依然能保持著較高的吞吐量，因而GRBFT 算法有著更好的吞吐性能。

4.4 共識(shí)時(shí)延比較

共識(shí)時(shí)延指請求從客戶端發(fā)出到最終全網(wǎng)共識(shí)所需的時(shí)間，共識(shí)時(shí)延越小代表著消息被全網(wǎng)共識(shí)所需時(shí)間越短，同時(shí)也代表著性能越優(yōu)異，共識(shí)時(shí)延用來評(píng)估兩個(gè)算法對(duì)系統(tǒng)處理消息的快慢非常的合適，在不同節(jié)點(diǎn)數(shù)下筆者通過10 次模擬實(shí)驗(yàn)，將平均值作為不同節(jié)點(diǎn)數(shù)下的共識(shí)時(shí)延數(shù)值，實(shí)驗(yàn)結(jié)果如圖7所示。

圖7：PBFT 與GRBFT共識(shí)時(shí)延比對(duì)圖

從圖7 中可以看出，GRBFT 算法比起PBFT 算法，擁有更低的共識(shí)時(shí)延，且隨著節(jié)點(diǎn)增加，GRBFT 算法的共識(shí)時(shí)延增長的幅度也比PBFT 算法小很多，既代表著有著更快的對(duì)請求消息的處理速度，也能反應(yīng)出GRBFT 算法有著更好的性能，比起PBFT 算法可以更好的提升聯(lián)盟鏈的共識(shí)效率。

5 結(jié)束語

本文針對(duì)實(shí)用拜占庭容錯(cuò)算法（PBFT）中存在節(jié)點(diǎn)活躍度不高，節(jié)點(diǎn)數(shù)量增加，通信次數(shù)過多導(dǎo)致的效率低下，作惡節(jié)點(diǎn)無法被監(jiān)督并被及時(shí)踢出聯(lián)盟鏈的問題進(jìn)行了研究，提出了GRBFT 算法。將PBFT 原本的全員互相共識(shí)，改為了組內(nèi)共識(shí)和組外共識(shí)，組內(nèi)采用基于PageRank 算法的Raft 共識(shí)算法，根據(jù)組內(nèi)成員不同的活躍度，給予不同的PR 值，將收到超過半數(shù)節(jié)點(diǎn)同意算達(dá)成共識(shí)，改為收到超過半數(shù)的PR 值便算共識(shí)達(dá)成，有效降低了故障節(jié)點(diǎn)對(duì)共識(shí)效率的影響，并在每個(gè)組內(nèi)增加了監(jiān)傳節(jié)點(diǎn)，作為組長和組員傳遞信息的中間人，在當(dāng)中間人幫它們傳遞信息的同時(shí)，也監(jiān)督著該組組長和組員是否作惡，對(duì)于作惡的節(jié)點(diǎn)，取證并發(fā)起投票踢出，組外新增了排序節(jié)點(diǎn)取代主節(jié)點(diǎn)給所有組長們發(fā)送PRE-PERPARE消息，一定程度上防范了主節(jié)點(diǎn)作惡，組長們代表著組內(nèi)的意見實(shí)行PBFT共識(shí)算法。通過模擬實(shí)驗(yàn)，筆者發(fā)現(xiàn)GRBFT 算法比起PBFT 算法最大可容忍更多的惡意節(jié)點(diǎn)，擁有更高的吞吐量以及更低的共識(shí)時(shí)延，并且在隨著節(jié)點(diǎn)數(shù)增加的同時(shí)，依然保持著較高的性能。監(jiān)督節(jié)點(diǎn)與排序節(jié)點(diǎn)的引入，一定程度上也提升了系統(tǒng)的安全性。未來也依然會(huì)對(duì)共識(shí)優(yōu)化做進(jìn)一步的研究，努力去做到能在保證性能不降低的同時(shí)，安全性進(jìn)一步提高。