RBFT：基于Raft 集群的拜占庭容錯共識機制

（桂林電子科技大學(xué)廣西無線寬帶通信與信號處理重點實驗室，廣西 桂林 541004）

1 引言

區(qū)塊鏈起源于比特幣[1]，其實質(zhì)是一個基于對等網(wǎng)絡(luò)（P2P,peer to peer）和密碼學(xué)的分布式數(shù)據(jù)庫，具有去中心化、不可篡改和公開透明等特點。應(yīng)用區(qū)塊鏈可解決信息不對稱問題，實現(xiàn)多個主體之間的協(xié)作信任與一致行動。

區(qū)塊鏈的核心技術(shù)包括共識機制、分布式存儲技術(shù)、密碼學(xué)和智能合約[2]。其中，共識機制著重解決分布式系統(tǒng)的一致性問題，旨在保證所有節(jié)點維護的數(shù)據(jù)副本的一致性，避免數(shù)據(jù)不統(tǒng)一和信息不對稱問題的發(fā)生。不同的場景對共識機制的擴展性、共識效率和隱私性有不同的需求[3-4]。現(xiàn)有的共識機制包括工作量證明（PoW,proof of work）[1]、權(quán)益證明（PoS,proof of stake）[5]、委托權(quán)益證明（DPoS,delegated proof of stake）[6]等概率一致性共識機制，實用拜占庭容錯（PBFT,practical Byzantine fault tolerance）[7]、Paxos[8]、Raft[9]等絕對一致性共識機制，以及多種混合共識機制，如DPoS+PBFT 混合的Tendermint[10]、迅雷鏈的DPoA（DPoA,delegated proof of ability）+PBFT 的同構(gòu)多鏈共識機制[11]等。

從去中心化的角度，可以將區(qū)塊鏈分為公有鏈、私有鏈和聯(lián)盟鏈。公有鏈的去中心化程度最高，任何節(jié)點都可加入，如比特幣[1]、以太坊[5]等。私有鏈的去中心化程度最低，一般由個人或某個小團體創(chuàng)建，僅使用區(qū)塊鏈技術(shù)進行記賬。聯(lián)盟鏈的去中心化程度介于公有鏈和私有鏈之間，一般由多個不同利益方的機構(gòu)組成，節(jié)點必須經(jīng)過聯(lián)盟鏈節(jié)點成員管理服務(wù)進行身份確認(rèn)和鑒權(quán)，獲得準(zhǔn)入證才可以加入聯(lián)盟鏈網(wǎng)絡(luò)[12]。聯(lián)盟鏈支持節(jié)點管理、可插拔的框架和模塊化的共識機制，因此在性能和隱私保護上比公有鏈更有優(yōu)勢，是區(qū)塊鏈落地的主要趨勢。

聯(lián)盟鏈在供應(yīng)鏈管理[13]、產(chǎn)品溯源[14]、智能制造[15]等領(lǐng)域有著廣闊的應(yīng)用前景。但要將聯(lián)盟鏈真正落地，迫切需要解決其擴展性差、安全性低和吞吐量小的問題。在節(jié)點數(shù)量上，實際商業(yè)應(yīng)用的節(jié)點規(guī)模在幾十到數(shù)百不等；在吞吐量上，諸如去中心化電商、車聯(lián)網(wǎng)等領(lǐng)域要求節(jié)點規(guī)模在萬級以上；在安全性方面，區(qū)塊鏈金融、數(shù)字資產(chǎn)等金融領(lǐng)域?qū)Π踩砸笙鄬^高。同時，為了保證用戶體驗，絕大多數(shù)的交易需要更低的時延。這些典型應(yīng)用場景的要求遠(yuǎn)超現(xiàn)有區(qū)塊鏈網(wǎng)絡(luò)在時延、吞吐量和拓展性等方面所能達到的性能。共識機制是區(qū)塊鏈的核心技術(shù)，決定了區(qū)塊鏈的吞吐量、安全性和拓展性等性能。因此，改進共識機制是解決這些問題的有效手段。

聯(lián)盟鏈的共識機制需要兼顧高效、安全與可拓展性，尤其是在大規(guī)模網(wǎng)絡(luò)環(huán)境下仍需保持高吞吐量和低時延。目前，已有的共識機制尚不能同時滿足這些需求，例如，公有鏈項目中常用的共識機制PoW效率太低，PoS/DPoS 以及類似算法瑞波協(xié)議[16]、Algorand 共識協(xié)議[17]等易導(dǎo)致“富豪統(tǒng)治”，且這些共識機制均依賴代幣，而很多聯(lián)盟鏈的實際應(yīng)用場景并不需要發(fā)行代幣。

Hyperledger Fabric是業(yè)界最先發(fā)展聯(lián)盟鏈的項目，其0.6preview 版本采用了PBFT 共識機制，1.0版本使用了效率更高的Kafka 集群共識機制[18]，最新的Fabric 2.0 使用了更靈活的Raft 共識機制，通常實測吞吐量在300～500 筆/秒（PBFT 數(shù)據(jù)，采用Raft 后有提升）。FISCO BCOS 聯(lián)盟鏈項目支持并行計算的PBFT 和標(biāo)準(zhǔn)Raft 這2 種模式，官方實測單鏈吞吐量可達1 000 筆/秒以上。Coco 聯(lián)盟鏈項目支持Paxos 共識協(xié)議，官方吞吐量是1 600 筆/秒。這些聯(lián)盟鏈的吞吐量雖然遠(yuǎn)高于比特幣、以太坊，但仍然無法滿足現(xiàn)有聯(lián)盟鏈實際應(yīng)用的需求。

在共識機制的改進方面，文獻[19]提出了一種基于K-medoids 的改進PBFT 共識機制，通過對大規(guī)模網(wǎng)絡(luò)節(jié)點的特征進行聚類和層次劃分，在1 000 個節(jié)點的模擬中，單次共識耗時縮短了20%；文獻[20]將PBFT 的三階段共識簡化為兩階段共識，從而減少了通信開銷，提高了共識效率；文獻[21]提出一種基于特征信任模型的優(yōu)化PBFT，提高了拜占庭容錯能力；文獻[22]通過建立信譽模型，根據(jù)信譽值賦予節(jié)點不同的話語權(quán)并在PBFT 機制中加入預(yù)提交階段來減少通信次數(shù)，提高了算法性能并可以有效防御女巫攻擊；文獻[23]基于Kademlia 協(xié)議優(yōu)化了Raft 的領(lǐng)導(dǎo)者選舉和共識機制，進一步提高了算法的領(lǐng)導(dǎo)者選舉速度和交易吞吐量。對PBFT 的改進并不能從根本上解決PBFT 的算法瓶頸，節(jié)點間兩兩通信機制導(dǎo)致其擴展性低，不適合大規(guī)模網(wǎng)絡(luò)。Raft 屬于強領(lǐng)導(dǎo)者型共識機制，即使在節(jié)點規(guī)模擴大的情況下仍能保持算法的高共識效率，但也因此不具備拜占庭容錯能力，僅適用于可信執(zhí)行環(huán)境的聯(lián)盟鏈。

本文的主要研究工作如下。

1) 針對聯(lián)盟鏈共識機制PBFT 在節(jié)點數(shù)量增多時共識效率下降的問題，結(jié)合Raft 共識思想提出了一種基于Raft 集群的拜占庭容錯共識機制——RBFT（Raft cluster Byzantine fault tolerance）。通過將網(wǎng)絡(luò)節(jié)點分組，組內(nèi)采用改進的Raft 共識機制，由Raft共識機制選舉出的領(lǐng)導(dǎo)者組成委員會，委員會采用PBFT 共識機制，大大降低了節(jié)點通信量，有效地提高了共識效率。同時，引入監(jiān)督節(jié)點使Raft 具有了拜占庭惡意行為容忍能力，提高了組內(nèi)共識的安全性。

2) 討論了RBFT 的節(jié)點分組策略和監(jiān)督節(jié)點的監(jiān)督策略，論證了RBFT 共識機制的一致性、安全性和靈活性。

3) 對RBFT 的通信開銷、共識時延、吞吐量和容錯性進行了仿真與實驗測試，以驗證其有效性和可靠性。

2 背景知識

2.1 PBFT 共識機制簡介

PBFT 機制由Castro 等[7]提出，目的是改進BFT的算法效率，構(gòu)建容忍拜占庭故障的高可用系統(tǒng)。它將算法的復(fù)雜度由指數(shù)級降低到多項式級，使算法能夠處理大量事務(wù)并且保證一定的效率。PBFT共識機制包含2 個重要的流程：三階段共識流程和視圖更換流程。

三階段共識流程用于對候選區(qū)塊形成共識，分為預(yù)準(zhǔn)備、準(zhǔn)備和提交3 個階段。預(yù)準(zhǔn)備階段消息由主節(jié)點廣播給副本節(jié)點，副本節(jié)點收到預(yù)準(zhǔn)備消息后會廣播準(zhǔn)備消息。當(dāng)某一節(jié)點收到不少于2f條來自不同節(jié)點的準(zhǔn)備消息時，該節(jié)點進入提交階段并廣播提交消息。同樣，當(dāng)節(jié)點收到的提交消息數(shù)不少于2f+1 時，該節(jié)點三階段共識完成，將區(qū)塊記入本地賬本。因此，PBFT 的通信復(fù)雜度為O(N2)，在不超過1/3的節(jié)點為拜占庭節(jié)點時仍能保持一致，即f≤(N-1)/3，其中，N為網(wǎng)絡(luò)總節(jié)點數(shù)。

同時，PBFT 通過視圖更換流程替換失效的主節(jié)點以保證共識服務(wù)的持續(xù)進行，給算法提供活性。當(dāng)副本節(jié)點認(rèn)為當(dāng)前主節(jié)點無法在給定時間內(nèi)完成共識或收到f+1 個視圖切換消息時，進入視圖更換，切換主節(jié)點進入下一個視圖，開始新一輪的三階段共識流程。

2.2 Raft 共識機制簡介

Raft機制是由Ongaro等[9]提出的一種分布式共識機制，目標(biāo)是實現(xiàn)賬本復(fù)制的一致性。Raft 將一致性算法分解成2 個關(guān)鍵的模塊：領(lǐng)導(dǎo)者選舉和日志復(fù)制。

在Raft 中，節(jié)點有3 種可能的狀態(tài)：跟隨者、候選者和領(lǐng)導(dǎo)者。在任一時刻，每個節(jié)點都處于這3 種狀態(tài)中的一種。Raft 機制將時間劃分為若干個任意長度的時間段，每個時間段稱之為一個任期。任期的編號是連續(xù)遞增的整數(shù)。每個任期開始于一次領(lǐng)導(dǎo)者選舉。所有節(jié)點的初始狀態(tài)都是跟隨者，如果跟隨者沒能感知到領(lǐng)導(dǎo)者的存在，那么跟隨者就跳轉(zhuǎn)為候選者。候選者將會發(fā)起投票，要求其他節(jié)點選擇自己為領(lǐng)導(dǎo)者。其他節(jié)點將會回應(yīng)候選者的請求。如果候選者獲得多數(shù)節(jié)點贊同票，那么它就成為領(lǐng)導(dǎo)者。這個過程稱為領(lǐng)導(dǎo)者選舉。正常情況下，網(wǎng)絡(luò)中僅有一個領(lǐng)導(dǎo)者，其余節(jié)點均為跟隨者。領(lǐng)導(dǎo)者通過周期性地向跟隨者發(fā)送心跳包以維持其領(lǐng)導(dǎo)地位。所有經(jīng)過驗證的交易在該任期內(nèi)都由領(lǐng)導(dǎo)者打包生成區(qū)塊。在收到超過半數(shù)節(jié)點回復(fù)后，領(lǐng)導(dǎo)者發(fā)送確認(rèn)信息給跟隨者，并將該區(qū)塊作為賬本上的下一個區(qū)塊。跟隨者收到領(lǐng)導(dǎo)者的確認(rèn)信息后，將該區(qū)塊作為本地賬本上的下一個區(qū)塊。這個過程稱為賬本復(fù)制。

Raft 是一種強領(lǐng)導(dǎo)者算法，領(lǐng)導(dǎo)者選舉是該共識協(xié)議的重要組成部分。在基于Raft 的區(qū)塊鏈系統(tǒng)中，數(shù)據(jù)僅能從領(lǐng)導(dǎo)者到其他服務(wù)器單向流動，因而架構(gòu)簡單且易于理解。Raft 具有線性的復(fù)雜度，因而共識效率很高。在容錯性方面，Raft可以容忍不超過50%的停機故障，但不具備拜占庭容錯能力。

3 RBFT 共識機制

為了提供一種具備高擴展性、高安全性、低時延高吞吐量的共識算法，本文結(jié)合PBFT 的拜占庭容錯安全性與Raft 高共識效率的優(yōu)點，提出一種基于Raft 集群的拜占庭容錯共識機制——RBFT。RBFT 共識機制流程如圖1 所示。

圖1 RBFT 共識機制流程

RBFT 共識機制采用分片的思想將區(qū)塊鏈網(wǎng)絡(luò)節(jié)點進行分組，各分組內(nèi)采用Raft 機制共識并選出領(lǐng)導(dǎo)者組建委員會，委員會內(nèi)部采用PBFT 機制進行共識。RBFT 同時引入監(jiān)督節(jié)點，解決Raft 共識不能對抗拜占庭惡意行為的問題，從而保證共識機制的安全性。

3.1 節(jié)點的分組策略

所提共識機制需要進行網(wǎng)絡(luò)分片，根據(jù)RBFT算法的兩級共識機制，PBFT 共識需要滿足分組數(shù)k≥ 4，每個組內(nèi)的Raft 共識需要滿足節(jié)點數(shù)m≥ 3。此外，監(jiān)督節(jié)點需要同時分配到多個組內(nèi)以實現(xiàn)監(jiān)督功能。現(xiàn)有的網(wǎng)絡(luò)分片包括基于協(xié)議分片[24]和基于地理位置分片[25]。

文獻[24]提出了一種基于ELASTICO 協(xié)議的網(wǎng)絡(luò)分片機制。節(jié)點根據(jù)自身IP 地址、公鑰以及一個隨機數(shù)進行Hash 運算，將所得的Hash 值作為自己所在網(wǎng)絡(luò)分片在區(qū)塊鏈系統(tǒng)中的身份，Hash 值的后若干位代表了節(jié)點所在的分片ID。區(qū)塊鏈系統(tǒng)中的交易會并發(fā)地分配到各個分片中并行處理。

文獻[25]提出了一種區(qū)塊鏈系統(tǒng)，該系統(tǒng)使用基于地理位置的分片機制。根據(jù)節(jié)點所處的地理位置范圍，將范圍內(nèi)的節(jié)點劃分到一個分組內(nèi)。

基于ELASTICO 協(xié)議的分片機制中，Hash 的運算結(jié)果的隨機性較大，容易導(dǎo)致分片不均；基于地理位置的分片機制中，人為的干預(yù)性較大，但是這2 種分片機制都不能實現(xiàn)監(jiān)督節(jié)點的分配。本文引入一致性Hash 算法[26]的設(shè)計思想，利用一致性Hash 算法平衡、分散、單調(diào)的特點，提出一種適用于RBFT 的節(jié)點分組算法，如算法1 所示。

算法1RBFT 節(jié)點分組算法

根據(jù)組內(nèi)節(jié)點數(shù)m≥3 及每個組內(nèi)至少含一個監(jiān)督節(jié)點的條件，確定分組是否合理，若是，轉(zhuǎn)至步驟5)；若否，轉(zhuǎn)至步驟2)

5) 分組完畢

一致性Hash 計算的結(jié)果是一個uint32 類型的大整數(shù)，結(jié)果同樣具有Hash 的抗碰撞性，根據(jù)結(jié)果可將節(jié)點映射的Hash 值分布在0～232的圓上。一致性Hash 的平衡分散性能夠保證計算的結(jié)果盡可能地呈均勻分布，并使每個組內(nèi)的領(lǐng)導(dǎo)者負(fù)載均衡，解決分片不均的問題。此外，其單調(diào)性降低了節(jié)點的加入和退出對分組的影響。

采用一致性Hash 算法的分組策略如圖2 所示。設(shè)每r組分配一個監(jiān)督節(jié)點，監(jiān)督節(jié)點的數(shù)量滿足

圖2 采用一致性Hash 算法的分組策略

如圖2 所示，假設(shè)分組數(shù)為4，每三組分配一個監(jiān)督節(jié)點，則s≥2 。根據(jù)算法1，按順時針進行分配，監(jiān)督節(jié)點1 被同時分配到組A、組B和組D 中，監(jiān)督節(jié)點2 被同時分組到組A、組C和組D 中。

當(dāng)分組數(shù)較少時，容易因為分片不夠均勻而造成數(shù)據(jù)傾斜問題，即部分分片中承載了大多數(shù)節(jié)點，導(dǎo)致負(fù)載失衡。一致性Hash 的理想結(jié)果是如果分組ID 有K個，承載的節(jié)點的Hash 值有N個，那么每個分組應(yīng)該承載N/K個。RBFT 中的分組算法引入了一致性Hash 算法虛擬節(jié)點的概念，對實際分組設(shè)置多個虛擬分組來擴大分組數(shù)，使分組更均勻。

根據(jù)算法1 得到RBFT 共識機制的分組結(jié)果，分別如圖3 和表1 所示。

圖3 區(qū)塊鏈網(wǎng)絡(luò)節(jié)點實體構(gòu)成

表1 分組結(jié)果

3.2 監(jiān)督節(jié)點的監(jiān)督策略

監(jiān)督節(jié)點的存在是對Raft 安全性的一大改進。監(jiān)督節(jié)點的加入使Raft 具備了抵抗拜占庭惡意節(jié)點的能力。

在Raft 共識機制中，如果領(lǐng)導(dǎo)者作惡，向組內(nèi)跟隨者下發(fā)惡意信息，則會破壞共識的一致性。如圖3 所示，假設(shè)每三組分配一個監(jiān)督節(jié)點，根據(jù)分組數(shù)不同，每個組內(nèi)可能有一個或多個監(jiān)督節(jié)點。監(jiān)督節(jié)點負(fù)責(zé)監(jiān)督組內(nèi)的領(lǐng)導(dǎo)者，因此監(jiān)督節(jié)點不參與領(lǐng)導(dǎo)者選舉，只作為跟隨者參與組內(nèi)Raft 共識。同時，監(jiān)督節(jié)點需要保證匿名性以防領(lǐng)導(dǎo)者進行針對性的欺詐。

RBFT 在Raft 共識時加入了簽名驗證環(huán)節(jié)。領(lǐng)導(dǎo)者下發(fā)日志同步消息給跟隨者時，需要對消息進行簽名。監(jiān)督節(jié)點在收到不同領(lǐng)導(dǎo)者的日志消息后，需要對簽名進行驗證并比對內(nèi)容，從而判斷領(lǐng)導(dǎo)者是否為拜占庭惡意節(jié)點。

監(jiān)督節(jié)點監(jiān)督領(lǐng)導(dǎo)者的策略如圖4 所示，分為取證、舉證和驗證3 個階段。

圖4 監(jiān)督節(jié)點監(jiān)督領(lǐng)導(dǎo)者的策略

1) 取證階段。進行Raft 組內(nèi)共識時，監(jiān)督節(jié)點可以同時監(jiān)聽3 個分組內(nèi)的領(lǐng)導(dǎo)者（記賬人）下發(fā)至跟隨者的記賬信息，在驗證節(jié)點簽名后對領(lǐng)導(dǎo)者下發(fā)的信息進行甄別，當(dāng)發(fā)現(xiàn)一個領(lǐng)導(dǎo)者下發(fā)的信息與其他領(lǐng)導(dǎo)者不同時，則可以判定其為惡意節(jié)點。根據(jù)節(jié)點簽名鎖定節(jié)點身份，進行取證。

2) 舉證階段。對惡意節(jié)點取證完成后，監(jiān)督節(jié)點打包一個舉證消息

3) 驗證階段。成員管理服務(wù)根據(jù)舉證內(nèi)容，判斷被舉證的惡意節(jié)點的公鑰等信息并驗證舉證的合法性，對是否罷免惡意節(jié)點的領(lǐng)導(dǎo)者身份做出判決。

3.3 RBFT 共識流程

主記賬人將若干條收聽到的客戶端請求信息打包成一個區(qū)塊后進行共識，共識流程如算法2 和圖5 所示。

算法2RBFT 共識流程

1) PBFT-Stage:A client sends a request

2) The primary broadcasts

3) Replica broadcasts

4) Replica counts the number of Prepare messages and denotes it as Count1，if Count1 ≥2f,broadcasts

5) Replica counts Commit messages and denotes it as Count 2，if Count2 ≥2f+1,enters Raft-Stage//副節(jié)點判斷提交階段是否完成，進入Raft 共識階段

6) Raft-Stage:The leader broadcasts

7) Followers reply AppendLog Prepared messages to leader//跟隨者節(jié)點接收消息并反饋

8) The leader counts the number of AppendLog Prepared messages received and denotes it as Count,if,commit Log//領(lǐng)導(dǎo)者節(jié)點根據(jù)消息反饋結(jié)果，判斷是否達成共識并提交日志

9) Reply client//共識完成，回復(fù)客戶端

算法2 中，V表示當(dāng)前視圖的編號，N表示當(dāng)前請求的編號，M表示消息的內(nèi)容，D(M)表示消息的摘要，i表示節(jié)點的編號，f表示拜占庭節(jié)點個數(shù)。

4 RBFT 的一致性、安全性與活性

根據(jù)FLP（Fischer-Lynch-Patterson）[27]和CAP（consistency-availability-partition tolerance）理論[28]，異步模型系統(tǒng)中不存在一個可以使系統(tǒng)取得強一致性的確定性共識機制。一個分布式系統(tǒng)最多只能同時滿足一致性、可用性和分區(qū)容忍性三項中的兩項。這里的一致性指強一致性，是系統(tǒng)成功操作返回后所有節(jié)點在同一時刻的數(shù)據(jù)完全一致。大多數(shù)情況下要遵循 BASE（basically available-soft state-eventual consistency）理論[29]弱化一致性，但要采取適當(dāng)?shù)姆绞竭_到最終一致性，即所有副本在經(jīng)過一定時間后，最終能夠達成一致的狀態(tài)。

RBFT 共識機制基于PBFT 和Raft 構(gòu)建，其一致性、安全性和活性繼承了PBFT 和Raft 原有的優(yōu)良特性，并通過監(jiān)督機制和分組增強了安全性和活性。

圖5 共識流程

4.1 一致性

RBFT 通過PBFT 機制保證了共識一致性，通過Raft 協(xié)議的AppendEntry RPC 機制保障了最終一致性。在RBFT 兩級共識階段，委員會共識遵從PBFT 共識協(xié)議來保證算法的一致性，在容錯范圍f≤(k-1)/3內(nèi)可以保證PBFT 階段正常共識。組內(nèi)共識遵從 Raft 共識協(xié)議，當(dāng)故障節(jié)點數(shù)f≤(m-1)/2時，Raft 共識階段也可以順利進行。

節(jié)點從故障到恢復(fù)后作為Raft 的跟隨者角色存在，從領(lǐng)導(dǎo)者處更新自己的日志列表來保持一致。如圖6 所示，S1為一個Raft 集群的領(lǐng)導(dǎo)者，節(jié)點擁有與其他集群一致的日志，S1和S3擁有完備的日志列表，S2和S5可能處在日志的復(fù)制階段，S4可能是宕機節(jié)點。當(dāng)宕機節(jié)點從宕機狀態(tài)恢復(fù)后，會從領(lǐng)導(dǎo)者處進行日志同步，從而保證最終所有節(jié)點的日志的一致性。

4.2 安全性

RBFT 共識的第一階段通過PBFT 的共識特性[7]保證了安全。預(yù)準(zhǔn)備、準(zhǔn)備和提交的三階段消息必須在同一個視圖內(nèi)完成，且完成的時間必須小于節(jié)點需要通過超時觸發(fā)視圖切換的時間，所有的消息均遵從PBFT 共識協(xié)議的摘要、序列號和簽名驗證等步驟。

RBFT 共識的第二階段的安全性由監(jiān)督節(jié)點的監(jiān)督功能來保證。根據(jù)3.2 節(jié)監(jiān)督節(jié)點的監(jiān)督策略可知，監(jiān)督節(jié)點的監(jiān)督行為使組內(nèi)共識具備了對抗拜占庭惡意行為的能力，增強了RBFT 共識第二階段的安全性。Raft 組內(nèi)普通節(jié)點需要收到領(lǐng)導(dǎo)者提交的消息且收到成員管理服務(wù)對消息結(jié)果驗證為真時，才可提交日志信息上鏈；若為假（監(jiān)督節(jié)點發(fā)現(xiàn)有領(lǐng)導(dǎo)者作惡，領(lǐng)導(dǎo)者身份被罷免），則需等待下一任期同步新領(lǐng)導(dǎo)者的日志，防止惡意信息上鏈保證安全性。

對于監(jiān)督節(jié)點本身，RBFT 設(shè)計了3 種機制保證安全性。①增加分組內(nèi)監(jiān)督節(jié)點的占比。對于網(wǎng)絡(luò)環(huán)境較差或者安全可靠性低的場景，需要適當(dāng)增加分組內(nèi)監(jiān)督節(jié)點的占比來提高安全性。當(dāng)組內(nèi)部分監(jiān)督節(jié)點受攻擊或者宕機時，可以由其他監(jiān)督節(jié)點執(zhí)行監(jiān)督職責(zé)。② 監(jiān)督節(jié)點重選。監(jiān)督節(jié)點定期向成員管理服務(wù)發(fā)送監(jiān)管狀態(tài)信息

4.3 活性

RBFT 算法的活性由PBFT 階段的視圖切換和Raft 階段的領(lǐng)導(dǎo)者選舉等提供。在PBFT 階段，記賬節(jié)點通過p=vmodk來確定主節(jié)點，視圖編號v從0 開始遞增。當(dāng)副本記賬節(jié)點的計時器超時或者收到一組f+1個有效視圖切換消息時，意味著當(dāng)前視圖的主節(jié)點已無法完成共識，副本必須進入下一個視圖重新進行共識服務(wù)。

此外，在RBFT 算法中，委員會成員是各分組的領(lǐng)導(dǎo)者通過Raft 的領(lǐng)導(dǎo)者選舉產(chǎn)生的。當(dāng)委員會成員宕機時，其對應(yīng)分組內(nèi)的跟隨者節(jié)點接收不到領(lǐng)導(dǎo)者的心跳檢測而觸發(fā)領(lǐng)導(dǎo)者重選流程，由新領(lǐng)導(dǎo)者替換失效的委員會成員。因此，RBFT 算法增強了委員會PBFT 共識階段的節(jié)點宕機故障恢復(fù)能力，增強了算法的活性。

Raft 的領(lǐng)導(dǎo)者選舉和心跳檢測機制使副本節(jié)點在接收日志超時或者當(dāng)前任期領(lǐng)導(dǎo)者宕機時開啟一個新的任期并重新選舉領(lǐng)導(dǎo)者對外提供服務(wù)，維持了RBFT 算法組內(nèi)共識的活性。

圖6 Raft 共識日志狀態(tài)的一致性

5 仿真與實驗分析

本節(jié)將從通信開銷、共識時延、吞吐量和容錯性4 個方面對比RBFT 與其他主流算法的表現(xiàn)，以此論證RBFT 的有效性和可靠性。

5.1 仿真方案與實驗設(shè)置

測試平臺硬件采用了 8 核/48 GB 的Intel(R)Core(TM) i7-9700 的服務(wù)主機，通過配置多臺虛擬機加端口映射的方式來模擬多節(jié)點環(huán)境，映射方式如表2 所示。測試平臺軟件的開發(fā)環(huán)境為LinuxMint19.3/Golang1.14。

表2 映射方式

1) 通信開銷

PBFT 共識機制需要兩兩節(jié)點進行通信，通信量為O(N2)（其中N為節(jié)點數(shù)量）。Raft 共識機制的通信量為O(N)，通過網(wǎng)絡(luò)分片，RBFT 相比于PBFT共識機制，通信量由O(N2)下降到O(N/k)+O(k2)。

仿真設(shè)定一次共識過程中的消息內(nèi)容m=256 bit，消息摘要d=128 bit，回復(fù)客戶端的信息大小r=80 bit，Raft 共識過程的心跳包大小h=64 bit。

2) 共識時延

算法的共識時延定義為從客戶端發(fā)起請求到該請求被確認(rèn)并上鏈所需的時間。取連續(xù)測量30 次結(jié)果的平均值作為算法的共識時延，分別記錄相同網(wǎng)絡(luò)規(guī)模下所提算法RBFT 和對比算法PBFT、Raft 的數(shù)據(jù)。

3) 吞吐量（TPS,transaction per second）

系統(tǒng)的吞吐量定義為系統(tǒng)每秒鐘處理的事務(wù)量。在區(qū)塊鏈系統(tǒng)中，吞吐量表現(xiàn)為交易數(shù)量M與處理對應(yīng)交易時間t的比值，即

每個節(jié)點都可以監(jiān)聽來自客戶端的請求，因此需要為每個節(jié)點綁定一個客戶端程序。客戶端每隔50 ms 發(fā)起一次請求，每秒并發(fā)度為20N。所有的請求最后由主節(jié)點收集打包負(fù)責(zé)出塊，采用BoltDB 數(shù)據(jù)庫[30]實現(xiàn)對區(qū)塊數(shù)據(jù)的持久化存儲，來記錄每個塊包含的交易量M及塊共識的時間t。出塊間隔設(shè)定為10 s，取系統(tǒng)運行5 min 后數(shù)據(jù)庫中穩(wěn)定的10 組數(shù)據(jù)的平均值作為該次測試的系統(tǒng)吞吐量。

4) 容錯性

令f1、f2為大于0 的整數(shù)，Raft 組內(nèi)的節(jié)點數(shù)m≥2f1+1，分組數(shù)k≥3f2+1。每r組分配一個監(jiān)督節(jié)點（r≥ 2），假設(shè)每組的節(jié)點數(shù)目相同，則總的節(jié)點數(shù)N滿足

其中，

PBFT 共識階段的最大容錯為(k-1)/3，Raft階段的最大容錯為(m-1)/2。在監(jiān)督節(jié)點的參與下，RBFT 的最大容錯為

仿真中設(shè)定每三組分配一個監(jiān)督節(jié)點（即r=3），并假設(shè)所有分組中包含的節(jié)點數(shù)目一致。

5.2 通信開銷

圖7 為RBFT 共識機制與經(jīng)典PBFT 共識機制的通信開銷比較。從圖7 可以看出，RBFT 共識機制的通信開銷遠(yuǎn)小于區(qū)塊鏈網(wǎng)絡(luò)全網(wǎng)采用PBFT 共識機制的通信開銷，如當(dāng)網(wǎng)絡(luò)節(jié)點數(shù)量為117 時，經(jīng)典PBFT 共識機制的通信開銷為63.51 ×10 bit，RBFT 共識機制的通信開銷為44.06 ×10 bit，通信開銷降低了98.8%，且隨著網(wǎng)絡(luò)節(jié)點的增多，RBFT比PBFT 節(jié)省的通信開銷越大。

圖7 RBFT 與經(jīng)典PBFT 共識機制的通信開銷比較

5.3 共識時延

所提算法和對比算法的共識時延實測結(jié)果如圖8 所示。從圖8 可以看出，隨著節(jié)點數(shù)量的增加，共識時延逐漸增大。其中，PBFT 算法增長最快，Raft 最慢。對于RBFT 而言，同樣是增加網(wǎng)絡(luò)節(jié)點數(shù)，保持組內(nèi)節(jié)點數(shù)不變而增加分組數(shù)相比保持分組數(shù)不變而增加組內(nèi)節(jié)點數(shù)，會引起更高的共識時延，如圖8 中RBFT（組內(nèi)節(jié)點數(shù)：10）和RBFT（分組數(shù)：4）所示。這是因為增加分組數(shù)實質(zhì)上是擴大了委員會的規(guī)模，增加了PBFT 階段的共識耗時，所以增加分組數(shù)對共識時延的影響更大。但在同樣節(jié)點規(guī)模下，RBFT 的時延仍遠(yuǎn)小于PBFT。從圖8 還可以看出，PBFT 的時延隨節(jié)點規(guī)模的增大急劇增加，而RBFT 的時延增速則較緩。因此，RBFT在節(jié)點規(guī)模擴大時仍能保證高共識效率。

圖8 所提算法和對比算法的共識時延實測結(jié)果

5.4 吞吐量

RBFT 與PBFT 的吞吐量測試結(jié)果如圖9 所示。共識效率是影響TPS 的主要因素，共識效率越高，交易處理能力越強。此外，節(jié)點并發(fā)度是影響TPS的另一因素，節(jié)點并發(fā)度越高，交易量越大。但區(qū)塊體積增大，對帶寬的要求更高（實驗時采用虛擬機模擬環(huán)境，并未達到帶寬上限，可等效為無窮大）。影響TPS 的因素還包括各節(jié)點對并發(fā)數(shù)據(jù)的處理能力、對數(shù)據(jù)庫的I/O 讀寫能力等。

圖9 RBFT 與PBFT 的吞吐量測試結(jié)果

從圖9 可以看出，隨著節(jié)點數(shù)量的增加，節(jié)點并發(fā)度增加，但由于PBFT 在節(jié)點增加時共識效率降低，交易處理耗時更長，吞吐量降低。對于RBFT，節(jié)點被分為四組，當(dāng)增加組內(nèi)節(jié)點數(shù)時，由5.3 節(jié)可知，算法共識效率影響較小，節(jié)點并發(fā)度是影響TPS 的主要因素。隨著節(jié)點數(shù)量的增大，TPS 逐漸增大。當(dāng)固定組內(nèi)節(jié)點數(shù)增加分組數(shù)時，共識效率成為影響TPS 的主要因素。隨著分組數(shù)的增加，TPS 逐漸下降。但在同等網(wǎng)絡(luò)規(guī)模情況下，RBFT 的TPS 約為經(jīng)典PBFT 的300%～400%。因此，RBFT 更適用于對TPS 要求更高的聯(lián)盟鏈應(yīng)用場景。

5.5 容錯性

監(jiān)督節(jié)點的數(shù)量不會影響RBFT 的共識效率與TPS，這是因為監(jiān)督節(jié)點本身位于多個組內(nèi)，在參與共識過程中的通信是獨立的，監(jiān)督節(jié)點本身的通信強度增加，但是共識算法整體的通信強度不變。在容錯性上，一個監(jiān)督節(jié)點出錯相當(dāng)于包含該監(jiān)督節(jié)點的分組都有一個節(jié)點出錯，RBFT 算法的最大容錯由式(5)給出。RBFT 共識機制與經(jīng)典PBFT 共識機制、Raft 共識機制的最大容錯性能對比如圖10所示。

由圖10 可以看出，RBFT 具有比PBFT 和Raft更高的容錯性。如當(dāng)網(wǎng)絡(luò)被分為四組，每三組分配一個監(jiān)督節(jié)點時（相當(dāng)于圖3(b)分組方式2），則N=8。單獨采用PBFT 的最大容錯為2，采用Raft 的最大容錯為3，而采用RBFT 的最大容錯為4（相當(dāng)于三組共識，每組2 個節(jié)點，三組共用一個監(jiān)督節(jié)點的極限情況）。隨著網(wǎng)絡(luò)節(jié)點規(guī)模的擴大，RBFT 容錯性增加。因此，RBFT 具有高安全性。

圖10 RBFT 共識機制與經(jīng)典PBFT 共識機制、Raft 共識機制的最大容錯性能對比

6 結(jié)束語

本文提出了一種基于Raft 集群的拜占庭容錯共識機制——RBFT。所提共識機制很好地融合了Raft 共識效率高和PBFT 拜占庭容錯性好的特點。測試結(jié)果表明，該共識機制具有通信開銷小、時延低、吞吐量高、容錯性強、可擴展性高的優(yōu)勢，適用于大規(guī)模節(jié)點網(wǎng)絡(luò)，能有效突破制約當(dāng)前聯(lián)盟鏈落地的性能瓶頸，有助于推動聯(lián)盟鏈的發(fā)展。未來研究可以結(jié)合跨鏈技術(shù)，進一步解決聯(lián)盟鏈單鏈的擴展性低、隱私隔離性差的問題。