S-Raft：一種增強(qiáng)拜占庭和崩潰容錯(cuò)的Raft算法

摘 要：傳統(tǒng)的Raft共識(shí)算法在私有鏈中因其簡潔和崩潰容錯(cuò)而得到廣泛應(yīng)用，但無法解決拜占庭節(jié)點(diǎn)惡意行為導(dǎo)致的諸多問題。在深入分析現(xiàn)有研究成果的基礎(chǔ)上，提出了一種基于Raft的增強(qiáng)拜占庭和崩潰容錯(cuò)的共識(shí)算法：S-Raft（Stability-Raft），以解決拜占庭節(jié)點(diǎn)在選舉中偽造身份、投票分裂以及非法替換領(lǐng)導(dǎo)者等核心問題。引入故障心跳日志機(jī)制，通過廣播故障信息阻止拜占庭節(jié)點(diǎn)獲得多數(shù)選票；實(shí)施選舉超時(shí)周期優(yōu)化策略，以應(yīng)對(duì)投票分裂問題；提出節(jié)點(diǎn)穩(wěn)定性評(píng)估算法，結(jié)合連續(xù)性懲罰和時(shí)間衰減因子，準(zhǔn)確評(píng)估節(jié)點(diǎn)穩(wěn)定性，減少因頻繁故障引發(fā)的通信冗余。實(shí)驗(yàn)結(jié)果顯示，與Raft和PBFT等算法相比，S-Raft算法在拜占庭容錯(cuò)能力上取得了顯著提升，同時(shí)保持了較高的吞吐量和較低的共識(shí)時(shí)延。因此，S-Raft算法具有良好的拜占庭和崩潰容錯(cuò)能力。

關(guān)鍵詞：Raft； PBFT； 共識(shí)算法； 區(qū)塊鏈； 拜占庭

中圖分類號(hào)：TP311"" 文獻(xiàn)標(biāo)志碼：A

文章編號(hào)：1001-3695（2025）03-005-0687-06

doi：10.19734/j.issn.1001-3695.2024.06.0245

S-Raft： enhanced Byzantine and crash tolerance Raft algorithm

Wang Zhuang1，2， Xu Cheng1，2， Dai Songyin1，2， Liu Hongzhe1，2， Li Xuewei1

（1.Beijing Key Laboratory of Information Service Engineering， Beijing Union University， Beijing 100101， China; 2.School of Robotics（School of Artificial Intelligence）， Beijing Union University， Beijing 100101， China）

Abstract：The traditional Raft consensus algorithm is widely used in private chains due to its simplicity and crash fault tolerance， but it cannot solve the problems caused by malicious behavior from Byzantine nodes. Based on the in-depth analysis of existing research results， this paper proposed an enhanced Byzantine and crash fault-tolerant consensus algorithm based on Raft， called S-Raft （Stability-Raft）， to solve the core problems such as forging identities， vote splitting， and illegal replacement of leaders in elections of Byzantine nodes. It introduced a faulty heartbeat log mechanism to prevent Byzantine nodes from obtaining majority votes by broadcasting fault information. It implemented an election timeout period optimization strategy to deal with vote splitting. It also proposed a node stability evaluation algorithm that combined continuity penalties and a time decay factor to accurately assess node stability and reduce communication redundancy caused by frequent failures. Experimental results show that， compared to Raft and PBFT， the S-Raft algorithm achieves significant improvements in Byzantine fault tolerance while maintaining high throughput and low consensus latency. Therefore， S-Raft demonstrates strong Byzantine and crash fault tolerance.

Key words：Raft; PBFT; consensus algorithm; blockchain; Byzantium

0 引言

中本聰發(fā)表的論文標(biāo)志著以區(qū)塊鏈［1］為底層技術(shù)的比特幣［2］系統(tǒng)的誕生。在隨后的十幾年，區(qū)塊鏈作為比特幣的底層核心技術(shù)不斷發(fā)展，衍生出了不同類型的區(qū)塊鏈，如以以太坊［3］、EOS［4］為代表的公鏈，以Hyperledger Fabric［5］、FISCO-BCOS［6］為代表的聯(lián)盟鏈［7］，以及私有鏈［8］等。共識(shí)算法［9］作為區(qū)塊鏈底層技術(shù)之一，對(duì)確保區(qū)塊鏈系統(tǒng)的安全、穩(wěn)定和高效發(fā)揮關(guān)鍵的作用。一些經(jīng)典的共識(shí)算法包括比特幣中使用的POW［10］共識(shí)算法、以太坊中使用的POS［11］共識(shí)算法等。Raft共識(shí)算法［12，13］因崩潰容錯(cuò)的特性在私有鏈中獲得了廣泛應(yīng)用，相比于Paxos［14］更加易于理解和實(shí)現(xiàn)，然而，它主要針對(duì)能夠容忍節(jié)點(diǎn)存在崩潰故障的場景，對(duì)于節(jié)點(diǎn)惡意行為導(dǎo)致的系統(tǒng)拜占庭［15］故障則無能為力。因此如何將Raft算法進(jìn)行改進(jìn)，增強(qiáng)其拜占庭節(jié)點(diǎn)容錯(cuò)能力是當(dāng)下研究的熱門話題。

將Raft算法移植到存在惡意節(jié)點(diǎn)的分布式系統(tǒng)中面臨的主要問題在于如何實(shí)現(xiàn)拜占庭容錯(cuò)。在增強(qiáng)拜占庭容錯(cuò)的共識(shí)算法研究方面，文獻(xiàn)［16］提出了哈希鏈迭代驗(yàn)證機(jī)制和基于門限加密的遺書機(jī)制，解決了拜占庭偽造日志的問題并確保了候選人節(jié)點(diǎn)拉取選票過程的合法性。文獻(xiàn)［17］允許節(jié)點(diǎn)主動(dòng)觸發(fā)新一輪選舉，當(dāng)它們監(jiān)測到當(dāng)前領(lǐng)導(dǎo)者存在性能問題時(shí)，通過優(yōu)先級(jí)隊(duì)列選擇新的領(lǐng)導(dǎo)者以替換，從而避免了因多個(gè)候選人同時(shí)分割選票導(dǎo)致的選舉時(shí)間延長問題；文獻(xiàn)［18］提出了一種基于區(qū)塊鏈的節(jié)能移動(dòng)邊緣計(jì)算系統(tǒng)，該系統(tǒng)將區(qū)塊鏈操作和資源優(yōu)化結(jié)合在一起，其中包含一種R-Raft共識(shí)機(jī)制，能夠?qū)崿F(xiàn)資源安全可靠的交易，該方案解決了移動(dòng)邊緣計(jì)算系統(tǒng)中由于信號(hào)衰減和小區(qū)間干擾導(dǎo)致業(yè)務(wù)對(duì)于邊緣用戶的可用性降低問題；文獻(xiàn)［19］使用LWLR算法預(yù)測節(jié)點(diǎn)故障時(shí)間，并通過改進(jìn)網(wǎng)絡(luò)分裂模型及引入新的領(lǐng)導(dǎo)選擇和轉(zhuǎn)移機(jī)制解決了因網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的效率與穩(wěn)定性問題；文獻(xiàn)［20］將零信任算法與Raft共識(shí)算法相結(jié)合，通過監(jiān)督節(jié)點(diǎn)、秘密共享、SM2簽名及NDN網(wǎng)絡(luò)改進(jìn)通信解決了投票偽造和惡意選舉問題，實(shí)現(xiàn)了拜占庭容錯(cuò)的特性。文獻(xiàn)［21］通過為聯(lián)盟鏈中的每個(gè)節(jié)點(diǎn)分配信用評(píng)分，并依據(jù)其行為表現(xiàn)動(dòng)態(tài)更新，以此為基礎(chǔ)選擇監(jiān)督節(jié)點(diǎn)參與領(lǐng)導(dǎo)選舉，從而有效抵御惡意攻擊。

部分方案將Raft算法的高共識(shí)效率與PBFT［22］算法的拜占庭容錯(cuò)特性結(jié)合。文獻(xiàn)［23］提出一種高效且容錯(cuò)的物聯(lián)網(wǎng)區(qū)塊鏈共識(shí)轉(zhuǎn)換機(jī)制，即可檢測RAFT和雙層并行BFT算法，滿足了增量物聯(lián)網(wǎng)數(shù)據(jù)共享對(duì)共識(shí)機(jī)制的高效性和拜占庭式容錯(cuò)的雙重要求。文獻(xiàn)［24］通過結(jié)合K-medoids聚類算法和改進(jìn)的Raft算法，并保留PBFT算法進(jìn)行跨分片共識(shí)，解決了PBFT在聯(lián)盟鏈中的擴(kuò)展性和通信開銷問題。

綜上所述，Raft算法被提出后廣泛應(yīng)用于私有鏈場景，但作為一種僅實(shí)現(xiàn)崩潰容錯(cuò)的共識(shí)算法，仍然存在一些問題使其不能應(yīng)用到更加復(fù)雜的網(wǎng)絡(luò)場景中。需要解決的問題包括：a）拜占庭節(jié)點(diǎn)可以通過偽造的candidate身份廣播請(qǐng)求選票日志來騙取其他節(jié)點(diǎn)選票，從而替換leader節(jié)點(diǎn)，因此需要一種機(jī)制用于防止拜占庭節(jié)點(diǎn)獲得大多數(shù)選票。b）隨著網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)量的增加，出現(xiàn)兩個(gè)或多個(gè)follower節(jié)點(diǎn)變成candidate節(jié)點(diǎn)并同時(shí)請(qǐng)求選票的可能性會(huì)變大，即產(chǎn)生投票分裂的概率會(huì)增大，因此需要一種優(yōu)化策略用于降低投票分裂的發(fā)生的概率。c）頻繁的節(jié)點(diǎn)故障會(huì)將增加冗余通信并降低系統(tǒng)性能，因此需要提出一種算法用于降低拜占庭節(jié)點(diǎn)在多任期頻繁作惡以及崩潰節(jié)點(diǎn)對(duì)系統(tǒng)運(yùn)行造成的干擾。

針對(duì)上述問題，本文提出一種增強(qiáng)拜占庭和崩潰容錯(cuò)的共識(shí)算法——S-Raft。

1 相關(guān)知識(shí)

1.1 PBFT算法

實(shí)用拜占庭容錯(cuò)（PBFT）算法是一種經(jīng)典的共識(shí)機(jī)制，能夠處理拜占庭故障，即節(jié)點(diǎn)可能發(fā)送任意消息或行為異常。如圖1所示，PBFT算法分為預(yù)準(zhǔn)備（pre-prepare）、準(zhǔn)備（prepare）和提交（commit）三個(gè)階段。在預(yù)準(zhǔn)備階段，主節(jié)點(diǎn)提議一個(gè)新的事務(wù)，并向所有備份節(jié)點(diǎn)廣播預(yù)準(zhǔn)備消息。備份節(jié)點(diǎn)收到預(yù)準(zhǔn)備消息后，進(jìn)入準(zhǔn)備階段，確認(rèn)消息并廣播自己的準(zhǔn)備響應(yīng)。一旦主節(jié)點(diǎn)收集到足夠多的準(zhǔn)備響應(yīng)，便進(jìn)入提交階段，發(fā)送提交消息通知所有備份節(jié)點(diǎn)，備份節(jié)點(diǎn)在本地執(zhí)行事務(wù)并響應(yīng)確認(rèn)。整個(gè)過程確保了即使存在少數(shù)惡意節(jié)點(diǎn)，系統(tǒng)也能達(dá)成一致。PBFT算法在網(wǎng)絡(luò)中存在一定比例的拜占庭節(jié)點(diǎn)時(shí)仍可達(dá)成共識(shí)，但在集群規(guī)模較大時(shí)通信復(fù)雜度較高，整體通信復(fù)雜度為O（n2）［25］。

1.2 Raft算法

Raft算法是一種實(shí)現(xiàn)崩潰容錯(cuò)的共識(shí)算法，相較于PBFT，Raft算法將系統(tǒng)狀態(tài)清晰地劃分為領(lǐng)導(dǎo)選舉、日志復(fù)制和心跳維持三個(gè)階段。在Raft集群中，系統(tǒng)中節(jié)點(diǎn)分為領(lǐng)導(dǎo)者（leader）、候選者（candidate）和跟隨者（follower）三種角色，各節(jié)點(diǎn)通過遠(yuǎn)程過程調(diào)用協(xié)議（remote procedure call protocol，RPC）互相通信。Raft算法存在任期的概念，任期用連續(xù)的整數(shù)編號(hào)，任期值在每次開啟新的選舉階段后增加。一個(gè)任期共分兩個(gè)階段，分別是選舉階段和領(lǐng)導(dǎo)階段。任期的變更過程如圖2所示。

Raft算法的工作流程如圖3所示，在領(lǐng)導(dǎo)階段，由leader節(jié)點(diǎn)管理全網(wǎng)follower節(jié)點(diǎn)，在follower節(jié)點(diǎn)中存在選舉超時(shí)機(jī)制，leader節(jié)點(diǎn)每隔一段時(shí)間發(fā)送一次空白R(shí)PC日志，此日志稱作“心跳”。follower節(jié)點(diǎn)中設(shè)定一個(gè)選舉超時(shí)計(jì)時(shí)器，在收到心跳日志后，重置計(jì)時(shí)器，如果計(jì)時(shí)過程中沒有收到心跳日志，則在選舉超時(shí)計(jì)時(shí)器結(jié)束時(shí)follower節(jié)點(diǎn)變更為candidate節(jié)點(diǎn)，之后開始新任期的選舉階段，發(fā)起拉取選票請(qǐng)求至全網(wǎng)，若獲得大多數(shù)節(jié)點(diǎn)的選票則成為新的leader節(jié)點(diǎn)，若在選舉計(jì)時(shí)周期內(nèi)，沒有獲得足夠選票，則重啟選舉過程。Raft算法在正常領(lǐng)導(dǎo)階段的通信復(fù)雜度為O（n），僅在選舉和日志復(fù)制時(shí)涉及少量交互，但Raft算法不支持拜占庭容錯(cuò)，這在對(duì)安全性要求較高的場景中是急需解決的難題。

2 S-Raft算法設(shè)計(jì)方案

2.1 leader節(jié)點(diǎn)故障心跳機(jī)制

2.1.1 拜占庭節(jié)點(diǎn)參與選舉問題

在區(qū)塊鏈網(wǎng)絡(luò)中，存在兩種類型的故障節(jié)點(diǎn)，分別是拜占庭節(jié)點(diǎn)和崩潰節(jié)點(diǎn)。在Raft任期的領(lǐng)導(dǎo)階段，若在follower節(jié)點(diǎn)中存在拜占庭節(jié)點(diǎn)，則拜占庭節(jié)點(diǎn)會(huì)通過拒絕響應(yīng)心跳日志改變自身狀態(tài)從而干擾系統(tǒng)進(jìn)程。拜占庭節(jié)點(diǎn)通過拒絕響應(yīng)leader節(jié)點(diǎn)發(fā)送的心跳日志，使得自身選舉計(jì)時(shí)器超時(shí)，此時(shí)節(jié)點(diǎn)會(huì)變成candidate節(jié)點(diǎn)，增加任期并拉取選票。這在后續(xù)會(huì)產(chǎn)生兩種問題：a）leader節(jié)點(diǎn)向拜占庭節(jié)點(diǎn)發(fā)送心跳日志后，如果發(fā)現(xiàn)該節(jié)點(diǎn)任期比自身任期大，leader節(jié)點(diǎn)會(huì)將任期同步到最大任期值并且立即恢復(fù)成follower節(jié)點(diǎn)；b）如果拜占庭節(jié)點(diǎn)在成為candidate節(jié)點(diǎn)后向leader節(jié)點(diǎn)拉取選票，在滿足RequestVote RPC規(guī)則后，則可以獲得leader節(jié)點(diǎn)的選票，隨后leader節(jié)點(diǎn)變成follower節(jié)點(diǎn)。

RequestVote RPC規(guī)則包含兩點(diǎn)：a）被請(qǐng)求的節(jié)點(diǎn)沒有向其他節(jié)點(diǎn)投票;b）candidate節(jié)點(diǎn)日志和被請(qǐng)求的節(jié)點(diǎn)日志一樣新。RequestVote RPC中包含有關(guān)candidate節(jié)點(diǎn)日志的信息，candidate節(jié)點(diǎn)和被請(qǐng)求的節(jié)點(diǎn)通過比較日志中最后一個(gè)條目的索引和任期來確定兩個(gè)日志中誰是最新的，如果兩節(jié)點(diǎn)最新條目一致，則滿足規(guī)則b）。若兩條規(guī)則都滿足，被請(qǐng)求的節(jié)點(diǎn)會(huì)向candidate節(jié)點(diǎn)投票。

2.1.2 故障心跳機(jī)制

為防止出現(xiàn)上述問題，本文提出了故障心跳機(jī)制。leader節(jié)點(diǎn)在領(lǐng)導(dǎo)階段持續(xù)廣播心跳日志，在等待心跳響應(yīng)周期（見2.2節(jié)）內(nèi)沒有收到某節(jié)點(diǎn)的響應(yīng)RPC，則將此節(jié)點(diǎn)判定為故障節(jié)點(diǎn)。使leader節(jié)點(diǎn)自身任期+1，并向除故障節(jié)點(diǎn)外的其余節(jié)點(diǎn)廣播故障心跳日志，節(jié)點(diǎn)在接收到日志后同步至賬本。故障心跳日志不再是空白的AppendEntries RPC日志，在其中存儲(chǔ)著一段包含故障節(jié)點(diǎn)地址和任期的信息，并向客戶端提交故障節(jié)點(diǎn)信息，使客戶端及時(shí)接收系統(tǒng)節(jié)點(diǎn)的狀態(tài)變化。

在正常節(jié)點(diǎn)接收到故障心跳日志后，其日志中比故障節(jié)點(diǎn)多出一個(gè)故障心跳條目，因此故障節(jié)點(diǎn)無法滿足RequestVote RPC規(guī)則，即故障節(jié)點(diǎn)的最新日志條目索引沒有follower節(jié)點(diǎn)的最新日志條目索引大。即使故障節(jié)點(diǎn)成為candidate節(jié)點(diǎn)，在廣播RequestVote RPC后仍然無法獲得其余節(jié)點(diǎn)選票。因此，拜占庭參與選舉產(chǎn)生的兩種問題得以解決。以下是故障心跳機(jī)制的部分執(zhí)行過程。

算法1 故障心跳機(jī)制

輸入：節(jié)點(diǎn)列表nodes。

輸出：故障心跳日志faulty_heartbeat_log。

a）for node in nodes：

b） if node_status==\"follower\"：

c）" response=node.send（AppendEntries（heartbeat））

//節(jié)點(diǎn)是否響應(yīng)心跳

d）" if response is None：

e）"" node_status=\"temporary_fault\" //故障節(jié)點(diǎn)

f）"" leader_node.increment_term（） //增加任期

g）""" for node in nodes：

h）"""" if node_status ！=\"temporary_fault\"：

i）""""" node.append_to_log（faulty_heartbeat_log）

//向正常節(jié)點(diǎn)廣播故障心跳

2.1.3 節(jié)點(diǎn)身份判定機(jī)制

考慮到未在規(guī)定時(shí)間內(nèi)響應(yīng)心跳日志的節(jié)點(diǎn)，可能是因網(wǎng)絡(luò)、設(shè)備故障導(dǎo)致臨時(shí)通信中斷的崩潰節(jié)點(diǎn)。若判定為故障節(jié)點(diǎn)，即便同一任期內(nèi)恢復(fù)正常工作，仍然不能正常參與選舉。因此提出了節(jié)點(diǎn)身份判定機(jī)制，實(shí)現(xiàn)對(duì)崩潰節(jié)點(diǎn)的容錯(cuò)。

假設(shè)故障心跳機(jī)制被觸發(fā)，在leader節(jié)點(diǎn)向除故障節(jié)點(diǎn)外的正常節(jié)點(diǎn)廣播故障心跳日志后，若在一個(gè)選舉計(jì)時(shí)周期內(nèi)其余正常節(jié)點(diǎn)中至少一個(gè)節(jié)點(diǎn)收到了來自故障節(jié)點(diǎn)的RequestVote RPC，則leader節(jié)點(diǎn)將其判定為拜占庭節(jié)點(diǎn)，在當(dāng)前任期內(nèi)將其從提交日志的節(jié)點(diǎn)列表中刪除，不再發(fā)送AppendEntries RPC，拜占庭節(jié)點(diǎn)在當(dāng)前任期將不能更新日志和任期。相反，若在一個(gè)選舉超時(shí)周期內(nèi)其余正常節(jié)點(diǎn)均未收到來自故障節(jié)點(diǎn)的RequestVote RPC，則leader節(jié)點(diǎn)將其判定為崩潰節(jié)點(diǎn)，無限次地發(fā)送心跳日志RPC，直到節(jié)點(diǎn)恢復(fù)通信，返回響應(yīng)日志，leader節(jié)點(diǎn)將崩潰節(jié)點(diǎn)任期和日志更新統(tǒng)一。節(jié)點(diǎn)身份判定機(jī)制描述如算法2所示。

算法2 節(jié)點(diǎn)身份判定機(jī)制

輸入：故障節(jié)點(diǎn)faulty_node， election_timeout。

輸出：故障節(jié)點(diǎn)狀態(tài)faulty_node-status。

a）start_time=time（）

b）while time（）-start_timelt;election_timeout：

c） votes_received=True if faulty_node.request_node else False

//節(jié)點(diǎn)收到選票請(qǐng)求

d） if votes_received：

e）" faulty_node_status=“Byzantine”

f） else：

g）" faulty_node_status=“Crash”

h）end while

故障心跳日志機(jī)制的工作流程如圖4所示，故障心跳日志機(jī)制有效解決了因拜占庭節(jié)點(diǎn)參與選舉產(chǎn)生的兩種關(guān)鍵問題，節(jié)點(diǎn)身份判定機(jī)制改善了故障心跳機(jī)制存在的問題，實(shí)現(xiàn)了崩潰節(jié)點(diǎn)的容錯(cuò)。

2.2 選舉超時(shí)周期優(yōu)化策略

2.2.1 選舉計(jì)時(shí)與心跳間隔的時(shí)間沖突問題

選舉超時(shí)周期在一定時(shí)間范圍（150～300 ms）內(nèi)隨機(jī)獲得。因?yàn)檫x舉超時(shí)周期是隨機(jī)分配的，節(jié)點(diǎn)通信延遲時(shí)可能出現(xiàn)響應(yīng)上一次心跳日志到節(jié)點(diǎn)成功接收下一次心跳日志的時(shí)間間隔大于選舉超時(shí)周期，造成選舉超時(shí)。為避免上述情況發(fā)生，心跳日志廣播的時(shí)間間隔要小于選舉超時(shí)周期。

節(jié)點(diǎn)之間可能因?yàn)榫W(wǎng)絡(luò)擁堵、硬件設(shè)備不足等原因?qū)е氯罩緜鬏敃r(shí)間較長，通過隨機(jī)值獲得選舉超時(shí)周期可能會(huì)導(dǎo)致節(jié)點(diǎn)超時(shí)。系統(tǒng)需要滿足下述的不等式要求，Raft才能夠維持穩(wěn)定的任期過程：

BroadCastTimelt;ElectionTimeoutlt;MTBF

（1）

在這個(gè)不等式中，BroadCastTime是服務(wù)器與集群中的每個(gè)服務(wù)器并行發(fā)送RPC并接收其響應(yīng)所花費(fèi)的平均時(shí)間；ElectionTimeout是選舉超時(shí)周期；MTBF是單個(gè)服務(wù)器兩次故障之間的平均時(shí)間。由于每個(gè)節(jié)點(diǎn)服務(wù)器傳輸線路網(wǎng)絡(luò)狀況各不相同，物理距離和硬件設(shè)備狀態(tài)也會(huì)對(duì)傳輸速率產(chǎn)生影響，所以使用單一的BroadCastTime值作為統(tǒng)一衡量指標(biāo)會(huì)產(chǎn)生時(shí)間計(jì)算誤差以影響系統(tǒng)正常運(yùn)行。

2.2.2 選舉超時(shí)周期的動(dòng)態(tài)調(diào)整策略

引入心跳日志廣播間隔（heartbeat time，HT）和等待心跳響應(yīng)周期（response heartbeat time，RHT）指標(biāo)，HT是指leader節(jié)點(diǎn)與集群中每個(gè)follower節(jié)點(diǎn)多次發(fā)送RPC并接收其響應(yīng)所花費(fèi)的平均時(shí)間，每個(gè)節(jié)點(diǎn)的HT值獨(dú)立計(jì)算。RHT是指leader節(jié)點(diǎn)與集群中每個(gè)follower節(jié)點(diǎn)多次發(fā)送RPC并接收其響應(yīng)所花費(fèi)的最大值。為了使follower節(jié)點(diǎn)能夠及時(shí)接收到心跳日志，取多次BroadCastTime計(jì)算結(jié)果的平均值作為將心跳日志發(fā)送間隔。

HT=∑ni=1BroadCastTimein

（2）

為了增加對(duì)故障節(jié)點(diǎn)的容錯(cuò)，應(yīng)盡量將等待時(shí)長拉長，因此leader節(jié)點(diǎn)RHT設(shè)置為取多次BroadCastTime計(jì)算結(jié)果的最大值。leader節(jié)點(diǎn)廣播心跳日志后，在一次RHT內(nèi)未收到某一節(jié)點(diǎn)響應(yīng)，故障心跳機(jī)制會(huì)將其判定為故障節(jié)點(diǎn)。

為保證任期的領(lǐng)導(dǎo)階段系統(tǒng)穩(wěn)定運(yùn)行，ElectionTimeout取值應(yīng)比HT大一個(gè)數(shù)量級(jí)。而將ElectionTimeout設(shè)置為固定值，容易在選舉階段產(chǎn)生多個(gè)candidate節(jié)點(diǎn)，分裂選票，影響系統(tǒng)運(yùn)行效率。因此，使用受限隨機(jī)值設(shè)定ElectionTimeout，使分裂選票的概率控制到最小。為了同時(shí)滿足兩個(gè)條件，ElectionTimeout隨機(jī)生成值設(shè)置為RHT的5～10倍。

ElectionTimeout=RHT×（5+p）

（3）

其中：p是一個(gè)隨機(jī)變量，滿足均勻分布條件，即 p～U（0，5）。這意味著p的取值為0～5，ElectionTimeout等于RHT的5～10倍的某個(gè)隨機(jī)值。

2.3 節(jié)點(diǎn)穩(wěn)定性評(píng)估算法

即便在身份判定機(jī)制的保護(hù)下，拜占庭節(jié)點(diǎn)仍可能通過在后續(xù)任期偽裝成正常節(jié)點(diǎn)身份贏得選舉。為防止這種問題的發(fā)生，本文設(shè)計(jì)一種基于歷史拜占庭次數(shù)和崩潰次數(shù)的節(jié)點(diǎn)穩(wěn)定性評(píng)估算法，并引入了時(shí)間衰減因子和連續(xù)性懲罰權(quán)重來更精細(xì)地衡量節(jié)點(diǎn)的穩(wěn)定性，杜絕拜占庭節(jié)點(diǎn)異常替換leader節(jié)點(diǎn)。在每一輪新任期開始時(shí)進(jìn)行評(píng)估，評(píng)估結(jié)果低于一定閾值時(shí)，節(jié)點(diǎn)將不能參與下一任期的選舉。

2.3.1 連續(xù)性懲罰權(quán)重

拜占庭節(jié)點(diǎn)一旦成為leader節(jié)點(diǎn)會(huì)使系統(tǒng)癱瘓，而崩潰節(jié)點(diǎn)在恢復(fù)正常后成為leader節(jié)點(diǎn)，即使再次宕機(jī)也會(huì)觸發(fā)選舉超時(shí)機(jī)制，重新進(jìn)行選舉，不會(huì)對(duì)系統(tǒng)進(jìn)程產(chǎn)生影響。因此應(yīng)分別考慮節(jié)點(diǎn)拜占庭行為和崩潰行為的懲罰權(quán)重，同一任期內(nèi)相同次數(shù)的拜占庭行為的懲罰權(quán)重值應(yīng)大于崩潰行為。

計(jì)算單一任期內(nèi)拜占庭懲罰權(quán)重的公式：

Wbi=tanh（bi）=ebi-e-biebi+e-bi

（4）

其中：bi是該任期的拜占庭行為次數(shù)；Wbi是第i個(gè)任期的拜占庭懲罰權(quán)重，i∈N0。

計(jì)算單一任期內(nèi)崩潰行為的懲罰權(quán)重的公式：

Wci=1-e-ci2

（5）

其中：ci是該任期的拜占庭行為次數(shù)，ci≥0，系數(shù)在1/2處取值，可以減少單次節(jié)點(diǎn)故障對(duì)懲罰權(quán)重的影響，節(jié)點(diǎn)在任期內(nèi)崩潰6次以上，懲罰權(quán)重的才接近極限值。

2.3.2 時(shí)間衰減因子

假設(shè)某節(jié)點(diǎn)在歷史任期中存在故障行為記錄，但后續(xù)每個(gè)任期都沒有發(fā)生故障。若不考慮時(shí)間維度的影響，則在每個(gè)任期內(nèi)的穩(wěn)定性評(píng)估結(jié)果都是恒定的，如果節(jié)點(diǎn)在歷史任期中的評(píng)估結(jié)果未通過，則該節(jié)點(diǎn)在后續(xù)每個(gè)任期中都無法參加選舉，這顯然是不合理的。

因此算法引入了時(shí)間衰減因子，節(jié)點(diǎn)最后一次拜占庭行為和崩潰行為發(fā)生的任期距離當(dāng)前任期越遠(yuǎn)，時(shí)間衰減因子越小，節(jié)點(diǎn)行為對(duì)當(dāng)前任期中的評(píng)估結(jié)果的影響越小。時(shí)間衰減因子計(jì)算公式如下：

=e-（t0-tj-1）2

（6）

其中：為時(shí)間衰減因子；t0為當(dāng)前任期值，tj為歷史記錄中該節(jié)點(diǎn)最后一次拜占庭或崩潰行為的任期值，tj∈T，T={t1，t2，…，tj，…，t0}，T為歷史任期值的集合，T∈Z。

2.3.3 節(jié)點(diǎn)穩(wěn)定性評(píng)估

結(jié)合上述的連續(xù)性懲罰權(quán)重和時(shí)間衰減因子，得出節(jié)點(diǎn)穩(wěn)定性評(píng)估公式如下：

R=1-（Wb+Wc）=

1-（∑Tti∈TWbit0+∑Tti∈TWcit0）e-（t0-tj-1）2=

1-（∑Tti∈Tebi-e-biebi+e-bit0+∑Tti∈T（1-e-ci2）t0）e-（t0-tj-1）2

（7）

其中：R為節(jié)點(diǎn)穩(wěn)定性評(píng)估值。

計(jì)算穩(wěn)定性評(píng)估指標(biāo)的步驟：a）根據(jù)節(jié)點(diǎn)在i任期的拜占庭行為次數(shù)bi和崩潰行為次數(shù)ci，計(jì)算出在i任期對(duì)應(yīng)的拜占庭懲罰權(quán)重Wbi和崩潰行為懲罰權(quán)重Wci。b）計(jì)算該節(jié)點(diǎn)每個(gè)任期對(duì)應(yīng)行為的懲罰權(quán)重并求平均值后相加，得到該節(jié)點(diǎn)基于歷史故障行為的最終懲罰權(quán)重。c）加入時(shí)間維度考量，將計(jì)算得出的結(jié)果乘以時(shí)間衰減因子。d）最后計(jì)算出該節(jié)點(diǎn)在當(dāng)前任期中的穩(wěn)定性評(píng)估結(jié)果R。

在每個(gè)任期開始時(shí)，新leader節(jié)點(diǎn)將對(duì)全網(wǎng)節(jié)點(diǎn)進(jìn)行穩(wěn)定性評(píng)估，當(dāng)節(jié)點(diǎn)評(píng)估結(jié)果低于一定閾值時(shí)，將無法參加下一任期的選舉。leader節(jié)點(diǎn)在網(wǎng)絡(luò)節(jié)點(diǎn)發(fā)生拜占庭或崩潰行為時(shí)，將行為記錄到當(dāng)前任期最高索引的日志條目中，并且每次發(fā)生故障行為時(shí)，將本次行為與當(dāng)前任期的歷史行為次數(shù)進(jìn)行累加后再次記錄。當(dāng)前任期結(jié)束時(shí)，賬本中對(duì)應(yīng)的最高索引的日志條目中包含著每個(gè)故障節(jié)點(diǎn)歷史行為總次數(shù)。當(dāng)leader節(jié)點(diǎn)對(duì)全網(wǎng)節(jié)點(diǎn)進(jìn)行評(píng)估時(shí)，會(huì)查詢歷屆任期最高索引的日志條目，獲得每個(gè)任期全網(wǎng)節(jié)點(diǎn)歷史行為記錄進(jìn)行計(jì)算。對(duì)于評(píng)估未通過的節(jié)點(diǎn)，在當(dāng)前任期內(nèi)會(huì)將其排除在提交日志的節(jié)點(diǎn)列表中，即節(jié)點(diǎn)將不能參與當(dāng)前任期內(nèi)的共識(shí)，這樣在下一任期的選舉中，不穩(wěn)定的節(jié)點(diǎn)由于沒有上一任期的日志，在拉取選票時(shí)會(huì)被拒絕，所以無法成為leader節(jié)點(diǎn)。

3 安全性分析

S-Raft算法在對(duì)抗拜占庭節(jié)點(diǎn)攻擊以及保證系統(tǒng)安全穩(wěn)定運(yùn)行方面需要滿足以下幾個(gè)要求：a）leader節(jié)點(diǎn)在正常領(lǐng)導(dǎo)階段的任期值不能小于網(wǎng)絡(luò)中的其他節(jié)點(diǎn)；b）確保選舉超時(shí)周期大于leader節(jié)點(diǎn)發(fā)送心跳日志的時(shí)間間隔；c）leader節(jié)點(diǎn)不會(huì)被拜占庭節(jié)點(diǎn)惡意替換。

3.1 節(jié)點(diǎn)選舉安全性分析

拜占庭節(jié)點(diǎn)需要選舉超時(shí)才能成為candidate節(jié)點(diǎn)，在故障心跳日志機(jī)制中，等待心跳響應(yīng)周期為多次BroadCastTime計(jì)算結(jié)果的最大值，而在選舉超時(shí)周期優(yōu)化策略中，選舉超時(shí)周期被設(shè)定為5～10個(gè)RHT值的隨機(jī)值，遠(yuǎn)大于等待心跳響應(yīng)周期。在超過RHT后仍未收到響應(yīng)，會(huì)觸發(fā)故障心跳機(jī)制，在拜占庭節(jié)點(diǎn)廣播RequestVote RPC前增大leader節(jié)點(diǎn)任期，避免了拜占庭節(jié)點(diǎn)異常替換leader節(jié)點(diǎn)的問題。

3.2 通信復(fù)雜度分析

Raft算法只支持崩潰節(jié)點(diǎn)存在，并不具備對(duì)抗拜占庭節(jié)點(diǎn)的能力。而S-Raft算法實(shí)現(xiàn)對(duì)拜占庭節(jié)點(diǎn)的容錯(cuò)，允許拜占庭節(jié)點(diǎn)的存在。目前主流的PBFT算法同樣可以處理拜占庭故障，因此S-Raft主要和PBFT算法進(jìn)行對(duì)比。

假設(shè)n為集群中的節(jié)點(diǎn)總數(shù)，Raft算法整體通信復(fù)雜度為O（n）。S-Raft算法中每出現(xiàn)一個(gè)故障節(jié)點(diǎn)，故障心跳機(jī)制觸發(fā)一次，每次工作的通信次數(shù)為n-2次。節(jié)點(diǎn)穩(wěn)定性評(píng)估算法使得不穩(wěn)定節(jié)點(diǎn)不能參與共識(shí)，因此大大降低了單個(gè)任期多個(gè)故障節(jié)點(diǎn)同時(shí)出現(xiàn)的概率。計(jì)算節(jié)點(diǎn)穩(wěn)定性評(píng)估結(jié)果時(shí)，只須leader節(jié)點(diǎn)查詢本地賬本中最高索引的日志條目，無須向其他節(jié)點(diǎn)發(fā)送廣播，因此，S-Raft算法的通信復(fù)雜度為O（n）。PBFT設(shè)計(jì)用于拜占庭容錯(cuò)，算法整體通信復(fù)雜度為O（n2），這表明隨著節(jié)點(diǎn)數(shù)量增加，通信開銷迅速增大。綜上所述，S-Raft算法在通信效率上優(yōu)于PBFT。

4 仿真實(shí)驗(yàn)

本文基于Hyperledger Fabric框架構(gòu)建了區(qū)塊鏈網(wǎng)絡(luò)，采用Golang語言實(shí)現(xiàn)了S-Raft算法。本文實(shí)驗(yàn)場景采用單通道設(shè)計(jì)，包含兩個(gè)組織，每個(gè)組織包含若干個(gè)對(duì)等節(jié)點(diǎn)，具體節(jié)點(diǎn)數(shù)量根據(jù)不同場景需求進(jìn)行調(diào)整。實(shí)驗(yàn)環(huán)境配置如表1所示。

4.1 故障心跳日志機(jī)制性能測試

本節(jié)中對(duì)故障心跳機(jī)制進(jìn)行性能測試，即可控拜占庭節(jié)點(diǎn)偽造candidate身份并拉取選票后，網(wǎng)絡(luò)節(jié)點(diǎn)任期增加的數(shù)量，故障心跳日志的數(shù)量以及拜占庭節(jié)點(diǎn)獲得的選票數(shù)量。實(shí)驗(yàn)將其中一個(gè)節(jié)點(diǎn)設(shè)置為可控的拜占庭節(jié)點(diǎn)，在系統(tǒng)選出leader節(jié)點(diǎn)后開展實(shí)驗(yàn)?？蛻舳斯潭òl(fā)送500份日志到leader節(jié)點(diǎn)，分別在Raft和S-Raft集群中進(jìn)行實(shí)驗(yàn)，節(jié)點(diǎn)數(shù)量設(shè)置為20個(gè)，在多次測試后取結(jié)果平均值，實(shí)驗(yàn)結(jié)果如表2所示。

實(shí)驗(yàn)結(jié)果表明，所有正常節(jié)點(diǎn)均收到故障心跳日志且任期增加，拜占庭節(jié)點(diǎn)因此未獲得選票，Raft算法則不能阻止拜占庭獲得選票。

設(shè)置系統(tǒng)中存在5個(gè)故障節(jié)點(diǎn)，其中3個(gè)節(jié)點(diǎn)先后存在拜占庭行為，2個(gè)節(jié)點(diǎn)先后存在崩潰行為，測試在其余條件不變時(shí)，故障心跳日志機(jī)制對(duì)拜占庭容錯(cuò)的能力。實(shí)驗(yàn)結(jié)果如表3所示。

實(shí)驗(yàn)表明，S-Raft正確判斷了拜占庭節(jié)點(diǎn)數(shù)量，成功增加任期并阻止拜占庭節(jié)點(diǎn)競選。Raft算法則完全不能阻止拜占庭節(jié)點(diǎn)競選成功。

4.2 節(jié)點(diǎn)穩(wěn)定性評(píng)估算法性能測試

本節(jié)對(duì)節(jié)點(diǎn)穩(wěn)定性評(píng)估算法的評(píng)估指標(biāo)進(jìn)行性能測試，引入定量可控的拜占庭節(jié)點(diǎn)和崩潰節(jié)點(diǎn)，測試評(píng)估指標(biāo)分別在連續(xù)性懲罰權(quán)重和時(shí)間衰減因子影響下的變化。

評(píng)價(jià)指標(biāo)R的閾值設(shè)定值如表4所示。

為了在不考慮時(shí)間維度影響因素的前提下更有效地測量連續(xù)性懲罰權(quán)重的變化和對(duì)節(jié)點(diǎn)穩(wěn)定性評(píng)估算法結(jié)果的影響，本文采用控制變量的方式，將節(jié)點(diǎn)單任期內(nèi)拜占庭行為次數(shù)和崩潰行為次數(shù)設(shè)置為不同取值。當(dāng)系統(tǒng)第二任期開始時(shí)，第一次對(duì)網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行評(píng)估。假設(shè)某節(jié)點(diǎn)在第一任期中的拜占庭行為次數(shù)表示為b1，崩潰行為次數(shù)表示為c1，令S為一列表，其中包含若干有序?qū)Γ╞1，c1），S=［（0，1），（1，0），（1，1），（2，0），（0，2）］，S中的元素表示為S［i］，i∈（1，2，…，n）。

本次實(shí)驗(yàn)測試不同的b1和c1取值對(duì)連續(xù)性懲罰權(quán)重和節(jié)點(diǎn)穩(wěn)定性評(píng)估算法的影響，實(shí)驗(yàn)評(píng)估指標(biāo)R在第二任期開始后計(jì)算得出，實(shí)驗(yàn)結(jié)果如圖5所示。

排除時(shí)間衰減因子的影響，即時(shí)間衰減因子值為1。節(jié)點(diǎn)在第一任期僅出現(xiàn)一次崩潰行為，將無法參與第二任期的的選舉；節(jié)點(diǎn)僅出現(xiàn)一次拜占庭行為，將無法參與第二任期的選舉和交易；節(jié)點(diǎn)出現(xiàn)兩次故障行為時(shí)，評(píng)估指標(biāo)均低于0.6，將無法參與第二任期的選舉和交易，其中發(fā)生一次拜占庭行為和一次崩潰行為的節(jié)點(diǎn)評(píng)估值最低。因此，連續(xù)性懲罰權(quán)重保證了故障行為會(huì)根據(jù)不同類型采取不同力度的懲罰措施，有效提高了對(duì)故障節(jié)點(diǎn)的容錯(cuò)能力。

加入時(shí)間維度影響后，即節(jié)點(diǎn)最后一次發(fā)生故障的任期不變，當(dāng)前任期不斷增大的情況下對(duì)評(píng)估結(jié)果R的影響。實(shí)驗(yàn)結(jié)果如圖6所示。

實(shí)驗(yàn)結(jié)果表明，僅出現(xiàn)一次崩潰行為的節(jié)點(diǎn)（0，1）在經(jīng)歷兩個(gè)任期沒有故障后，可以恢復(fù)正常參與選舉。僅出現(xiàn)一次拜占庭行為的節(jié)點(diǎn)（1，0）則需要經(jīng)歷三個(gè)任期才能夠恢復(fù)參與選舉。單個(gè)任期內(nèi)分別發(fā)生一次拜占庭和崩潰行為（1，1）的節(jié)點(diǎn)和兩次出現(xiàn)拜占庭行為的節(jié)點(diǎn)（2，0）在經(jīng)歷四個(gè)沒有發(fā)生故障的任期內(nèi)仍不能參加選舉。這表明節(jié)點(diǎn)穩(wěn)定性評(píng)估算法一方面降低了因拜占庭節(jié)點(diǎn)頻繁參與選舉導(dǎo)致的多次啟動(dòng)故障心跳機(jī)制從而產(chǎn)生的通信問題，減輕了節(jié)點(diǎn)通信開銷，提高系統(tǒng)的吞吐量。另一方面降低了故障節(jié)點(diǎn)對(duì)共識(shí)過程的影響，提高對(duì)leader節(jié)點(diǎn)的反竄改能力，從而提高系統(tǒng)整體的魯棒性和安全性。

4.3 性能測試

吞吐量是指在單位時(shí)間內(nèi)完成交易的數(shù)量，一般用TPS（transaction per second）表示，是共識(shí)算法性能對(duì)比中一個(gè)重要指標(biāo)，TPS可由式（8）表示：

TPS=TransactionΔtΔt

（8）

其中：Δt為出塊時(shí)間，Transaction為出塊時(shí)間內(nèi)處理的交易量。

實(shí)驗(yàn)中設(shè)置節(jié)點(diǎn)數(shù)量由10個(gè)增加到35個(gè)，步長為5，在不同節(jié)點(diǎn)數(shù)下重復(fù)進(jìn)行20次測試，每輪測試的交易量設(shè)置為1 000，最終取多次測試的平均值作為不同節(jié)點(diǎn)數(shù)量下吞吐量的實(shí)驗(yàn)結(jié)果。將PBFT、Raft、S-Raft和VSSB-Raft算法［20］進(jìn)行實(shí)驗(yàn)對(duì)比，實(shí)驗(yàn)結(jié)果如圖7所示。

由圖7可知，四種算法的吞吐量隨著節(jié)點(diǎn)數(shù)量的增加逐漸遞減，S-Raft算法的吞吐量整體大于VSSB-Raft算法和PBFT算法，與Raft算法相近。S-Raft只有在單任期內(nèi)出現(xiàn)多個(gè)拜占庭節(jié)點(diǎn)的極端情況下會(huì)降低整體TPS，在之后的多個(gè)任期內(nèi)拜占庭節(jié)點(diǎn)將無法進(jìn)行交易活動(dòng)，系統(tǒng)性能也會(huì)與Raft算法保持一致。因此，S-Raft算法與其他算法相比具有較好的吞吐量表現(xiàn)。

共識(shí)時(shí)延是衡量算法性能的重要指標(biāo)，指客戶端發(fā)起請(qǐng)求到區(qū)塊被確認(rèn)上鏈所需的時(shí)間。共識(shí)時(shí)延的計(jì)算公式為

DelayTime=Timereply-Timereq

（9）

其中：Timereq表示客戶端發(fā)起共識(shí)請(qǐng)求的時(shí)刻，Timereply表示客戶端收到足夠的PBFT回復(fù)消息的時(shí)刻。

取多次實(shí)驗(yàn)數(shù)據(jù)的平均值作為共識(shí)時(shí)延，并與VSSB-Raft算法、PBFT算法、Raft算法進(jìn)行對(duì)比。算法的共識(shí)時(shí)延對(duì)比測試結(jié)果如圖8所示。

四種算法的共識(shí)時(shí)延隨著節(jié)點(diǎn)數(shù)量的增加而逐漸增大。VSSB-Raft算法和PBFT算法在節(jié)點(diǎn)數(shù)量超過20個(gè)之后，共識(shí)時(shí)延的增長曲線變得陡峭，增長較為迅速。S-Raft算法的共識(shí)時(shí)延與Raft相近，在節(jié)點(diǎn)數(shù)量為35時(shí)，共識(shí)時(shí)延仍保持在0.5 s以下。因此，S-Raft算法在集群規(guī)模增大時(shí)，依舊能保持低共識(shí)時(shí)延。

5 結(jié)束語

本文針對(duì)Raft算法存在的拜占庭容錯(cuò)缺陷，設(shè)計(jì)并實(shí)現(xiàn)了一種新的共識(shí)機(jī)制——S-Raft，旨在提高系統(tǒng)在拜占庭網(wǎng)絡(luò)中的適用性。S-Raft算法通過引入故障心跳日志、選舉超時(shí)周期優(yōu)化策略和節(jié)點(diǎn)穩(wěn)定性評(píng)估算法，有效地解決了拜占庭節(jié)點(diǎn)對(duì)選舉過程的干擾、投票分裂問題以及領(lǐng)導(dǎo)者的非法替換。實(shí)驗(yàn)結(jié)果證明，S-Raft算法在保持低延遲的同時(shí)，增強(qiáng)了系統(tǒng)的拜占庭容錯(cuò)能力和穩(wěn)定性。本文方案還有很多可以改進(jìn)之處，例如節(jié)點(diǎn)穩(wěn)定性評(píng)估算法可以通過構(gòu)建信譽(yù)系統(tǒng)為節(jié)點(diǎn)打分，用以輔助算法評(píng)估。

參考文獻(xiàn)：

［1］Heo J W， Ramachandran G S， Dorri A， et al. Blockchain data storage optimisations： a comprehensive survey［J］. ACM Computing Surveys， 2024， 56（7）：1-27.

［2］Rajabi S， Roozkhosh P， Farimani N M. MLP-based learnable window size for bitcoin price prediction［J］. Applied Soft Computing， 2022， 129： 109584.

［3］Chen Huashan， Pendleton M， Njilla L， et al. A survey on ethereum systems security： Vulnerabilities， attacks， and defenses［J］. ACM Computing Surveys， 2020， 53（3）： 1-43.

［4］Zheng Weilin， Zheng Zibin， Dai Hongning， et al. XBlock-EOS： Extracting and exploring blockchain data from EOSIO［J］. Information Processing amp; Management， 2021，58（3）： 102477.

［5］Fu Xiang， Ma Haoliang， Ding Bo， et al. Subtraction of Hyperledger Fabric： a blockchain-based lightweight storage mechanism for digital evidences［J］. Journal of Systems Architecture， 2024，153： 103182.

［6］Li Huizhong， Chen Yujie， Shi Xiang， et al. FISCO-BCOS： an enterprise-grade permissioned blockchain system with high-performance［C］//Proc of International Conference for High Performance Computing， Networking， Storage and Analysis. New York： ACM Press， 2023： 1-17.

［7］蔡曉晴， 鄧堯， 張亮， 等. 區(qū)塊鏈原理及其核心技術(shù)［J］. 計(jì)算機(jī)學(xué)報(bào)， 2021， 44（1）： 84-131. （Cai Xiaoqing， Deng Yao， Zhang Liang， et al. Principle and core technology of blockchain［J］. Journal of Computer Science， 2021， 44（1）： 84-131.）

［8］Assaqty M I S， Gao Ying， Hu Xiping， et al. Private-blockchain-based industrial IoT for material and product tracking in smart manufacturing［J］. IEEE Network， 2020， 34（5）： 91-97.

［9］Fu Xiang， Wang Huaimin， Shi Peichang. A survey of blockchain consensus algorithms： mechanism， design and applications［J］. Science China Information Sciences， 2021， 64： 1-15.

［10］Shi Long， Wang Taotao， Li Jun， et al. Pooling is not favorable： decentralize mining power of PoW blockchain using age-of-work［J］. IEEE Trans on Cloud Computing， 2023， 11（3）： 2756-2769.

［11］Ge Lina， Wang Jie， Zhang Guifen. Survey of consensus algorithms for proof of stake in blockchain［J］. Security and Communication Networks， 2022， 2022（1）： 2812526.

［12］Jahedi A， Luz M， Rivinius M， et al. MS-RAFT+： high resolution multi-scale RAFT［J］. International Journal of Computer Vision， 2024， 132（5）： 1835-1856.

［13］Zhang Yiguo， Wang Wei， Shi Feiyang. Reputation-based Raft-Poa layered consensus protocol converging UAV network［J］. Computer Networks， 2024， 240： 110170.

［14］Mao Chunyu， Golab W， Wong B. Antipaxos： Taking interactive consistency to the next level［J］. Journal of Parallel and Distributed Computing， 2024， 187： 104839.

［15］Zhang Gengrui， Pan Fei， Mao Yunhao， et al. Reaching consensus in the byzantine empire： a comprehensive review of BFT consensus algorithms［J］. ACM Computing Surveys， 2024， 56（5）： 1-41.

［16］李淑芝， 鄒懿杰， 鄧小鴻， 等. RB-Raft： 一種抗拜占庭節(jié)點(diǎn)的Raft共識(shí)算法［J］. 計(jì)算機(jī)應(yīng)用研究， 2022， 39（9）： 2591-2596. （Li Shuzhi， Zou Yijie， Deng Xiaohong， et al. RB-Raft： Raft consensus Algorithm against Byzantine Nodes［J］. Application Research of Computers， 2022， 39（9）： 2591-2596.）

［17］Du Zhiqiang， Qu Zhi， Fu Yanfang， et al. Multi-strategy-based leader election mechanism for the Raft algorithm［J］. Concurrency and Computation： Practice and Experience， 2023， 35（22）： e7734.

［18］Qin Langtian， Lu Hancheng， Chen Yuang， et al. Energy-efficient blockchain-enabled user-centric mobile edge computing［J］. IEEE Trans on Cognitive Communications and Networking， 2024： 1-1.

［19］Gu Ruowen， Huang Dongyan. A leadership Transfer Algorithm for the Raft［C］//Proc of CCF China Blockchain Conference. Singapore： Springer Nature Singapore， 2022： 13-30.

［20］Tian Siben， Bai Fenhua， Shen Tao， et al. VSSB-Raft： a secure and efficient zero trust consensus algorithm for blockchain［J］. ACM Trans on Sensor Networks， 2024， 20（2）： 1-22.

［21］翟社平， 聶浩楠， 陸嫻婧， 等. CS-Raft： 適用于聯(lián)盟鏈的拜占庭容錯(cuò)共識(shí)算法［J］. 計(jì)算機(jī)應(yīng)用研究， 2024， 41（4）： 995-1000. （Zhai Sheping， Nie Haonan， Lu Xianjing， et al. CS-Raft： Byzantine fault-tolerant consensus algorithm for consortium blockchain［J］. Application Research of Computers， 2024， 41（4）： 995-1000.）

［22］Li Wenyu， Feng Chenglin， Zhang Lei， et al. A scalable multi-layer PBFT consensus for blockchain［J］. IEEE Trans on Parallel and Distributed Systems， 2020，32（5）： 1146-1160.

［23］Fu Jintian， Zhang Lupeng， Wang Leixin， et al. BCT： an efficient and fault tolerance blockchain consensus transform mechanism for IoT［J］. IEEE Internet of Things Journal， 2021， 10（14）： 12055-12065.

［24］王謹(jǐn)東， 李強(qiáng). 基于Raft算法改進(jìn)的實(shí)用拜占庭容錯(cuò)共識(shí)算法［J］. 計(jì)算機(jī)應(yīng)用， 2023， 43（1）： 122-129. （Wang JinDong， Li Qiang. Improved practical Byzantine fault-tolerant consensus algorithm based on raft algorithm［J］. Computer Applications， 2023， 43（1）： 122-129.）

［25］Zhang Lei， Xu Hao， Onireti O， et al. How much communication resource is needed to run a wireless blockchain network？［J］. IEEE Network， 2021， 36（1）： 128-135.