檢測型的聯盟區塊鏈共識算法d-PBFT

*

（1.廣西大學計算機與電子信息學院，南寧 530004；2.廣西多媒體通信與網絡技術重點實驗室（廣西大學），南寧 530004；3.華南理工大學電子與信息學院，廣州 510641）

0 引言

在用戶的信息安全方面，為了保證用戶數據的完整性和隱私性，本文將區塊鏈技術應用到其中。區塊鏈是一個去中心化的分布式賬本數據庫［1］，其中去中心化是指區塊鏈中的任何決策都是經過所有人投票決定的，需要一個達成共識的過程；而分布式賬本表示每一個區塊鏈節點會有一份數據賬本用于存儲達成共識的結果，這是能保證用戶信息不會被篡改的關鍵所在。區塊鏈作為一個去中心化的技術，意味著區塊鏈中的分布式成員節點沒有一個中心化、統一化的首領來發號施令，成員節點只能彼此之間相互討論才能達成一致的結果，而這個討論的方法和過程就是由共識層中的共識算法來決定的［2］，這是分布式的區塊鏈保持信息中心和用戶的信息一致所要用到的關鍵技術。

目前，主流的區塊鏈應用平臺采用到了包括工作量證明（Proof of Work，PoW）、權益證明（Proof of Stack，PoS）、股份授權證明（Delegated Proof of Stake，DPoS）、Raft 共識和實用拜占庭（Practical Byzantine Fault Tolerance，PBFT）等共識算法。不同的共識算法具有不同的特點，大致上可以分為兩種類型：一種是BFT（Byzantine Fault Tolerance）類［3］共識算法，這類算法能容忍網絡中一定比例的拜占庭節點并達成共識，雖然網絡會更加安全但共識耗費的時間相對更長。例如文獻［4］使用了PoW 算法來作為比特幣網絡的共識算法，該算法要求區塊鏈節點計算隨機哈希散列數值來證明自己的工作量，并且該結果必須得到至少51%的全網節點認同才能達成最終的共識。文獻［5］提出了一種可擴展的拜占庭容錯（Scalable Byzantine Fault Tolerance，SBFT）算法，該算法能容忍小于1/3節點總數的拜占庭節點存在于網絡當中，并且選定了一個Leader 節點來統計區塊鏈節點對共識提案的通過票數，該機制可以減少區塊鏈節點間的通信開銷，因此可以進一步擴展節點的規模。另一類算法是崩潰容錯（Crash Fault Tolerance，CFT）算法［6］，這類共識算法能容忍網絡中的故障崩潰節點并達成共識，它雖然能幫助網絡快速達成共識但是需要運行在有身份認證機制的網絡中，且要保證節點都是誠實節點。文獻［7］提出了一種能容忍節點故障崩潰的經典共識算法，在沒有作惡節點的系統中這種算法能夠容忍不超過50%的節點宕機故障，提升了系統的可用性。文獻［8］提出了一種部分去中心化的共識算法，該算法中區塊鏈節點的地位并不是完全平等的，算法會在開始共識之前選舉出一個領導者，通過領導者來分發共識請求并收集投票從而大大地提升通信效率，但前提是推舉出來的領導者是可信任的。

綜上所述，共識算法中有的更注重共識安全，有的更側重于共識效率，本文選擇兼顧安全和效率的實用拜占庭容錯（Practical Byzantine Fault Tolerance，PBFT）算法加以改進，引入了節點監控和惡意節點隔離的能力，剔除了殘留在網絡中的拜占庭節點，消除了聯盟網絡中的隱患并持續維護網絡安全。

1 實用拜占庭容錯共識算法

1.1 實用拜占庭共識算法概述

拜占庭將軍問題（Byzantine Generals Problem），是Lamport 等［9］在1982 年提出用來解釋一致性問題的一個虛構模型。在現實的聯盟鏈系統中，從信息中心的節點中選舉出Leader 節點。通過先期的聯盟鏈會員資格審查，能保證加入到聯盟中的節點絕大部分都是誠實可靠的，但也不能完全確定其中就一定沒有“叛徒”，這些“叛徒”節點稱之為拜占庭節點，一旦它們被選舉成主節點就有可能會丟棄或更改用戶的隱私數據。

實用拜占庭容錯（PBFT）共識算法于1999 年由Castro等［10］提出，該算法可以容忍不超過1/3節點總數的拜占庭節點存在網絡之中，是一種解決拜占庭問題的實用方法，它的出現將BFT 指數級的復雜度降低到了多項式級別，讓人們得以在實際生產中使用它。

在PBFT共識算法模型中，節點分為主節點和備份節點兩種，主節點是輪流當選的，主節點的編號p由視圖編號對節點總數取模得到：

當主節點是誠實節點時，主節點協同備份節點完成預準備（pre-prepare）—準備（prepare）—提交（commit）的三階段協議；當主節點完成一次完整共識或是出現拜占庭錯誤的情況，則會引發備份節點發動視圖切換（view-change）協議重新推舉出新的主節點。

1.2 實用拜占庭算法的不足

相較于Raft共識只能容忍節點的故障崩潰，PBFT 共識算法可以很好地容忍拜占庭節點錯誤，能夠在很大程度上為聯盟網絡的隱私提供保護，但即便如此PBFT算法仍然有需要改進完善的地方。

首先，PBFT 共識算法本身是可以容忍不超過1/3 節點總數的惡意拜占庭節點［11］，但由于主節點的選取是輪詢得到，而算法本身缺乏對于節點狀態的判斷，因此很有可能會將拜占庭節點選為主節點。一旦拜占庭節點當選為主節點進行作惡，它可能會丟棄、篡改客戶端的提案，導致提案無法達成全網共識，直到被其他備份節點發現后執行視圖切換協議，這個過程需要重新選舉主節點并重新執行提案請求，會產生十分昂貴的開銷。

其次，PBFT共識可以容納一定數量的拜占庭節點在系統中而不影響剩余的誠實節點達成共識，但卻不會處理這些惡意節點，更不會懲罰這些作惡節點，這些拜占庭節點可以不停作惡而不用付出任何代價，如果放任不管的話這些拜占庭節點可能會形成一定的規模，一旦輪詢到它們擔任主節點就會大大地降低共識效率，因此PBFT 共識算法亟須一種懲罰手段。針對這些可改進的內容，本文提出了一種能夠監控節點狀態的檢測型實用拜占庭容錯（detection-Practical Byzantine Fault Tolerance，d-PBFT）算法，并詳細闡述了算法的共識流程。

2 改進PBFT共識算法

2.1 方案對比

針對PBFT實用拜占庭共識算法，已經有專家和學者對該算法進行了改進和完善，如文獻［12］提出了基于候補集合投票的改進PBFT 算法（Improved Practical Byzantine Fault Tolerance，IPBFT），算法優化了共識過程，減少了節點間的通信次數，但仍然會將拜占庭節點納入到候補集合中作為下一輪選舉的競選者，一旦網絡中潛藏的拜占庭節點形成了一定規模甚至會導致主節點頻繁切換。文獻［13］在PBFT 共識三階段之前引入了可驗證隨機函數（Verifiable Random Function，VRF）來進一步保證主節點選舉的隨機性，但隨著節點規模的增大VRF會導致系統性能下降得很快。

上述改進算法雖然巧妙，但仍會殘留拜占庭節點于網絡中。本文提出的d-PBFT 檢測型實用拜占庭共識算法會在共識開始前校驗主節點的節點狀態，避免拜占庭節點擔任主節點，減少無效的通信，同時會將這些惡意節點納入隔離區，追查來源并將其踢出網絡。

2.2 d-PBFT拜占庭容錯能力

在有嚴格會員準入機制的聯盟區塊鏈網絡中，不能排除仍然有第三方敵手將拜占庭節點偽裝成正常節點混入到聯盟網絡中，假設存在f個拜占庭節點，需要容忍這f個節點的惡意行為并且還要保證它們的行為不會對共識結果產生影響，這就需要給定一個恰當的節點總數n，使得惡意節點f不會成為網絡中的多數派。在確定節點總數n之前，首先需要明確這些惡意節點可能會產生的惡意行為，其中一個行為是不應答，即收到共識請求后不返回執行結果；另一個行為是錯誤應答，即返回一個錯誤的共識結果來欺騙網絡中的其他節點。

在此前提條件下，當一個客戶端提出共識請求后，若網絡節點正常則本應該收到n條消息，但由于拜占庭節點不應答的原因，因此只收到了n-f條應答消息，為了讓應答的消息占據大多數就必須有n-f＞f成立，所以節點總數n必須大于2f。另一方面，即便有f個節點沒有應答客戶端，但也可能是其他誠實節點暫時掉線了，即在應答的n-f條消息中可能存在著錯誤應答的拜占庭節點，為了確保系統的安全性需要考慮到最壞的因素即當前不應答的節點全是由誠實節點意外掉線導致的，因此最壞情況下n-f條消息中還包含著f條來自拜占庭節點的錯誤消息。為了保證誠實節點的消息數為大多數，n-f條應答消息還需要細分為n-f-f條誠實應答消息和f條錯誤應答消息，所以可以得出n-f-f＞f即n＞3f。所以為了容忍f個拜占庭節點，網絡中的節點總數n至少為n=3f+1。

綜上所述，只要聯盟網絡中的拜占庭節點數f≤這些拜占庭節點就無法左右系統達成一致的共識結果。然而隨著時間的增長，假設每經過一段Δt時間后，系統內就會新增一個拜占庭節點，如果這些拜占庭節點沒有得到及時的處理，不僅會降低系統的性能，還有可能造成f＞進而威脅聯盟網絡安全，因此本文提出了節點狀態監測和隔離懲罰的機制，可以在經過m輪共識后及時匯報節點的狀態，以便剔除網絡中的拜占庭節點。改進后的效果如圖1所示。

圖1 d-PBFT算法的拜占庭容錯能力Fig.1 Byzantine fault tolerance performance of d-PBFT algorithm

2.3 新增節點狀態監測

與公有區塊鏈中節點匿名加入網絡不同，聯盟區塊鏈有嚴格的會員準入機制，無論是企業還是個人加入聯盟鏈都會受到身份資格的審查，并且從可信度、安全和性能三個方面考慮，聯盟鏈中參與共識的節點都是由組建聯盟的信息中心和企業提供，個人用戶的節點只參與健康提案的發起和結果校驗。因此，本文考慮為這些參與共識的節點新增節點狀態的屬性，與此同時每一個參與共識的節點都需要維護一份節點狀態信息表如表1所示。

表1 節點狀態Tab.1 Node states

在本文的聯盟區塊鏈中，用戶節點可能有很多，但真正參與共識的節點都是來自聯盟中的信息中心和企業，并且由于原PBFT算法本身通信開銷和性能的因素，參與共識的節點數目通常不會超過100 個，因而維護這樣一張表不會給每個節點造成額外的負擔。

在系統首次運行時，每個共識節點的表中都不會記錄任何節點及其狀態。在執行三階段共識協議之前，先檢查主節點在節點狀態表中的狀態，如果沒有在表中找到該主節點，就先驗證該節點的簽名，簽名通過則添加該節點到表中。開始執行共識協議后，每完成（或終止）一輪共識，參與共識的備份節點才會為當前視圖的主節點打上標記如圖2所示。

圖2 節點標記過程Fig.2 Process of node marking

如果一輪共識是按照三階段協議的預準備-準備-提交的流程正常運轉，那么在結束的時候其他備份節點就應當為主節點打上normal 標記。如果在執行共識期間，主節點長時間沒有響應直到超出預分配時間還未完成共識，由于無法判斷該主節點是意外掉線還是故意不分發共識提案，此時其他備份節點應當標記主節點狀態為unstable，之后發起視圖切換view-change 協議推舉新的主節點重新完成共識。帶有unstable標記的節點如果連續兩次擔任主節點都超時，就會被其他節點標記為malicious 節點；但unstable 節點如果在下一次擔任主節點時順利完成共識，那么仍然可以恢復成normal節點。在一輪共識中，有備份節點發現了主節點有任意作惡行為，如偽造簽名、分配錯誤的提案序號、篡改提案信息等，應當即刻發起視圖切換view-change 協議，如果view-change 被全網一致通過則標記主節點為malicious節點。

2.4 追查懲罰機制

假設聯盟中共有n個節點參與共識，那么在n輪共識過后，所有的節點都輪詢擔任過主節點，每一個參與共識的節點都會維護一張完整的節點狀態表，如果聯盟中的節點十分誠實，那么大部分節點的評級都應該是normal，可能會有少部分節點為unstable，這表明聯盟的網絡狀態十分健康。現實中的區塊鏈網絡可能會存在拜占庭節點，由于聯盟系統有嚴格的身份準入機制，這些拜占庭節點的數量很難超過共識節點總數的1/3，因此它們作為備份節點出現時對共識過程的影響不大，它們產生的惡意結果會在共識過程中被舍棄掉［14］，如果這些拜占庭節點作為主節點出現在共識系統中即便無法篡改用戶數據，但仍然會帶來較大的性能和惡意超時的影響。因此，在這些拜占庭節點擔任過一次主節點后，它的作惡行為會讓它在其他誠實節點的節點狀態表中被打上malicious 標記，當這些拜占庭節點再一次競選主節點時，可以通過malicious 標記直接把這些拜占庭節點排除掉，不給它們作惡機會，同時避免浪費不必要的共識糾錯時間。

同時本文還為unstable 節點和malicious 節點設立了一個“隔離區”，隔離區隸屬于共識模塊，如果節點曾經被標記過unstable狀態，則會被隔離區記錄unstable次數，次數累計較多的節點會被視作故障老化的節點最終被移除網絡。如果節點被打上malicious 標記，則會立即被收納到隔離區中，每經歷m輪共識后（m視聯盟的實際需求而定）系統就發起一次針對隔離區的系統共識，系統管理員就可以通過隔離區中記錄的節點信息追查和處理這些拜占庭節點的所屬組織。

2.5 d-PBFT算法共識流程

d-PBFT共識算法敵手模型為n=3f+1，其中n代表參與共識的總節點數，f為拜占庭節點數且f≤整個共識網絡中的節點都統稱為replica復制節點，因為原PBFT算法就是基于狀態機復制原理的算法［15］。replica 節點又可以細分為一個Primary 主節點和眾多的Backup 備份節點，主節點是根據replica 節點的編號依次輪詢到的，主節點和備份節點都會運行在一個稱之為視圖view 的地方，每個主節點都會對應一個視圖，如果主節點被更換了那就需要運行視圖切換協議，圖3 展示的是一個主節點在一個任期內運行d-PBFT 共識算法達成共識的流程。

圖3 d-PBFT三階段協議Fig.3 d-PBFT three-stage agreement

d-PBFT 算法沿用了PBFT 共識算法的三階段協議，而d-PBFT算法新增的檢測主節點狀態、標識主節點狀態和隔離拜占庭節點的過程都夾雜在pre-prepare、prepare 和commit 過程之中，當主節點有任何超時和作弊的行為都會被其他備份節點標記下來。圖3 反映的是成功達成共識需要經歷的5 個步驟：

1）請求（request）步驟。首先，用戶通過網絡客戶端client向聯盟中的主節點Primary 發送提案請求其中提案內容表示為m，發送方表示為c用來表明客戶端身份，該提案的時間戳表示為t。這個階段就是用戶向聯盟提交需要共識的提案信息，該消息會被客戶端簽名，然后再進入共識的核心流程。

2）預準備（pre-prepare）步驟。在視圖view 上，主節點會校驗發送方的身份，然后將提案內容m編上序號并為它生成摘要，然后將它們一并打包分發給網絡中的備份節點，消息內容為其中：v記錄的是運行共識所在視圖的編號，n表示主節點為提案m設定的序號，d則是提案生成的哈希摘要，p表示為主節點的節點編號。

如果主節點直到超時還未將預準備消息發送出去，其他的備份節點會將該編號的主節點標記為unstable 狀態，若已經是unstable 狀態的節點連續兩次擔任主節點都發生了超時，該節點就會被拉黑為malicious節點，之后其他節點就不會再選取該節點作為主節點了；但如果標記為unstable 的節點在下一次擔任主節點時恢復正常，那么它的節點狀態仍然可以恢復為normal狀態。

3）準備（prepare）步驟。當所有的備份節點Backup接收到主節點發來的消息后，選取其中一個備份節點b1來進行說明，首先b1通過主節點的編號p在自己記錄的節點狀態表中查詢主節點的狀態，如果主節點是malicious 狀態的，那么備份節點b1就直接發起視圖切換協議請求更換新的主節點；如果主節點是normal 狀態或unstable 狀態，則準備廣播消息給除b1以外的其他節點，其中i代表的是備份節點b1的編號。

4）提交（commit）步驟。其他節點接收到來自b1備份節點的prepare 消息，同理b1也會接收到其他備份節點發過來的prepare消息。首先，b1會檢查消息的簽名是否正確，其他節點prepare消息的視圖編號是否和主節點pre-prepare消息發送的視圖編號一致等。當有至少2f個來自其他備份節點的prepare 信息能和主節點的pre-prepare 信息核對一致時，此時的b1備份節點就可以廣播消息給其他節點，D（m）是b1對于提案m的可驗證簽名。

同理，如果b1備份節點廣播的prepare 消息正常的話，也會收到其他備份節點返回的commit 消息，當commit 消息達到至少2f+1條時表明全網已經達成共識。但在達成共識前，如果主節點被發現有任何作弊的行為，會引發備份節點發起視圖切換協議，并把該編號的主節點記錄為malicious節點，之后會把它移交到隔離區等待聯盟管理員處理。

5）應答（reply）步驟。進入到reply 步驟意味著核心的共識過程已經結束，接下來就是所有的節點將消息返還給客戶端，其中的r代表節點執行的結果，由于該網絡只能容忍f個拜占庭節點，因此當客戶端收到至少2f+1 個reply 消息即表明該返回結果確實已經達成了全網的共識認證。

2.6 視圖切換流程

當備份節點感知到當前主節點p有異常行為如超時、作弊行為時，備份節點會發起視圖切換協議并發送消息廣播給全網，其中，v+1表示新的視圖編號，n表示最近checkpoint 消息檢查點的編號用于檢驗最新的消息log，C表示已經驗證過的2f+1 個checkpoint 消息集合，P表示因超時導致未完成的pre-prepare消息和prepare消息的集合。

當網絡中有至少2f+1個節點發起視圖切換協議，網絡就會開始重新選舉節點p+1 作為主節點，所在的視圖view 也會從v變更為視圖v+1。之后，新的主節點p+1 將會發送消息廣播給全網節點，其中，V表示備份節點發出的有效的view-change 消息集合，O表示重新發起上一輪未完成的pre-prepare 消息的集合。備份節點接收到new-view 消息后，比對其中有效的view-change消息集合，確認無誤后正式加入到新節點的視圖v+1 中并完成上一輪未完成的pre-prepare消息。

3 改進PBFT算法測試評估

本文提出了一種改進PBFT 的d-PBFT 共識算法，之后需要對該算法進行測試評估，并在無拜占庭節點和有拜占庭節點的情況下分別對其表現進行評估，以驗證該算法在聯盟網絡中的實用性。

3.1 測試環境

本測試評估將會在實驗室電腦上進行，本次測試使用4臺實驗室電腦配置如表2所示。

表2 網絡節點配置Tab.2 Network node configuration

本文的測試將會對比PoW、Raft、PBFT 和d-PBFT 四種共識算法在無拜占庭節點情況下和有拜占庭節點情況下的吞吐量和時延，該測試不會運行在某一個特定的區塊鏈平臺，而是使用go語言實現［16］并部署在4臺實驗室電腦中。

在本章需要測試共識算法在同一環境下的性能，因此采用一個輕量級的開源測試框架wrk，它是一款基于HTTP 協議的測試工具，能夠利用異步事件驅動框架給予系統很大的并發量。由于wrk 框架是一個輕量級框架，默認支持GET 方式發起請求，而本文的客戶端節點需要提交聯盟用戶的信息和數據，因此需要借助lua 腳本啟用POST 方式向其他節點發送請求。

3.2 測試結果

3.2.1 共識算法TPS測試

本文在無拜占庭節點和有拜占庭節點的兩種情況下分別對d-PBFT 算法進行了吞吐量測試并與PoW、Raft 和PBFT 算法進行對比，測試結果如圖4所示。

圖4 是網絡中無拜占庭節點的情況下測得的共識算法吞吐量，在區塊鏈中吞吐量（Transactions Per Seconds，TPS）的計算方式為：

實驗中，對共識算法進行了30次測試，由圖4可知在無拜占庭節點的情況下部分去中心化的Raft 算法吞吐量最高，完全由Leader 節點分發客戶端請求，Follower 節點只驗證Leader節點信息內容，卻不會在Follower 之間判斷Leader 節點是否是拜占庭節點。吞吐量排在并列第二的分別是PBFT 和改進d-PBFT 算法，Backup 節點不僅會驗證Primary 節點的信息內容，還會在Backup 節點間綜合判斷Primary 節點是否是拜占庭節點，因此為了保證聯盟網絡更加安全而犧牲了部分吞吐量。最后，吞吐量最差的是PoW 共識算法，這個算法是完全去中心化的算法，網絡中設定的難度越難產生新的區塊就越困難。

圖4 無拜占庭節點下的吞吐量測試Fig.4 TPS test in non-Byzantine case

受實驗室設備的限制，本文僅向網絡加入了一個拜占庭節點并測試共識算法的TPS，測試結果如圖5所示。

設定節點超時時間為10 s，在這一輪測試中針對部分去中心化的算法Raft、PBFT 和d-PBFT，讓4 個節點輪流擔任主節點，拜占庭節點也會輪值到主節點，完全去中心化的PoW算法中節點地位平等而沒有主節點機制。由圖5 可知，當拜占庭節點輪值到主節點時，Raft 算法完全沒有任何防范能力在圖像中用“×”來表示，并且拜占庭主節點不會被揪出而是一直擔任著主節點，此時整個網絡傳遞的都是拜占庭節點的消息。而在PBFT 算法中，每當拜占庭節點輪值成為主節點時，其他的備份節點會有效地識別出來，但也意味著在這一輪共識中節點都忙于檢測主節點存在的問題，導致無法再傳輸用戶信息。基于PBFT 改進的d-PBFT 共識算法在第一輪也體現了同樣的特征，但不同的是在第一次發現了拜占庭節點之后，當再次遇到拜占庭節點時d-PBFT 會拒絕它輪值為主節點，使得相同時間內與PBFT 算法相比區塊生成量提升了26.1%。PoW 算法則是完全去中心化的共識算法，只要不是超過51%的節點發起攻擊［17］，PoW算法都能夠正常運行。

圖5 拜占庭節點下吞吐量測試Fig.5 TPS test in Byzantine case

3.2.2 共識算法時延測試

在共識算法的時延測試中，同樣采用無拜占庭節點和拜占庭節點兩種情景進行測試，設定在共識網絡中的超時時間為10 s，如果節點在10 s 后無任何響應共識會被取消。共識算法的時延計算公式為：

本文在主節點為非拜占庭節點和拜占庭節點的情境下分別測試了30 次，測試了用戶數據寫入區塊鏈并達成共識的時延，對30次測試取平均值求得結果如圖6所示。

圖6 非拜占庭和拜占庭情況下的共識時延Fig.6 Consensus delays in non-Byzantine and Byzantine cases

在該輪測試中，正常主節點的共識時延用斜線柱狀圖表示，拜占庭節點擔任主節點的共識時延用空白柱狀圖表示。由于PoW 算法是完全分布式的共識算法，并且需要各個節點在一定難度下競爭區塊，因此耗費的時間最長，平均耗時超過30 s，但是拜占庭節點只要不超過節點總數的51%就對整個網絡影響有限。部分去中心化的Raft共識算法在無拜占庭節點的情景下表現優秀，能夠維持在0.5 s 左右的延時，但前提條件是網絡沒有將拜占庭節點選為主節點，一旦主節點被拜占庭節點攻占整個網絡將會處于混亂狀態，共識的內容和時長將被拜占庭節點掌控直到超時。PBFT 算法和d-PBFT 算法在正常情況下達成共識的時間也非常迅速，兩種算法都沒有超過1 s，同時這兩種算法相較Raft 算法更加安全，在PBFT 算法中當拜占庭節點擔任主節點時，只要拜占庭節點數目不超過節點總數的1/3，被篡改的信息是會被其他備份節點發現并修正的，但拜占庭主節點仍然可以令共識超時，從而對用戶的通信造成影響；而d-PBFT 算法在第一次拜占庭節點擔任主節點時也會受到類似的影響，但在下一輪輪詢中網絡中的節點不會再支持拜占庭節點擔任主節點，這將有效地避免拜占庭節點對網絡的時延產生干擾。

3.2.3 共識安全性

上述實驗分別在正常情況和拜占庭錯誤兩種情況下進行的，除PoW算法沒有主節點以外，Raft算法、PBFT算法d-PBFT算法的主節點都由拜占庭節點擔任。在吞吐量測試的同時記錄了共識結果，心率傳感器客戶端發起心率數值為65 bpm 的共識錄入請求，共識算法分別在正常情況和拜占庭錯誤的情況下返回共識結果如表3所示。

針對共識結果的返回情況可知在主節點發生拜占庭錯誤的情況下，Raft算法直接返回了錯誤的信息，其安全性無法保障；而PBFT 算法在此情況下并沒有及時地返回共識結果，它總是會進入到了自我糾錯的視圖切換階段，即使最終能返回正確的共識結果，但視圖切換的過程會產生額外的開銷；僅有PoW 算法和d-PBFT 算法能及時返回正確的共識結果。首先PoW 算法的安全性非常高，作為完全去中心化的算法它總是能返回正確的共識結果；然后d-PBFT 算法的安全性排在第二，它被拜占庭節點“欺騙”過一次之后就會將它標記起來，之后會直接拒絕它成為主節點來降低拜占庭節點的影響，從而提高共識的安全性。

表3 共識結果對比Tab.3 Consensus result comparison

3.3 結果分析

本文對提出的改進算法d-PBFT 共識算法進行了對比測試，對比的算法包括完全去中心化的PoW 算法、部分去中心化的Raft算法和PBFT算法，測試的項目包括共識算法的吞吐量和達成共識的時延，綜合分析了d-PBFT 算法相較于這些主流算法的獨特優勢。在吞吐量方面，雖然d-PBFT 算法不如Raft 算法但卻能檢測出網絡中的拜占庭節點，從而更能保障聯盟網絡用戶數據的安全性，而在有拜占庭節點的網絡中d-PBFT 算法又比PBFT 算法更能排除拜占庭節點的干擾，進而在吞吐量上得到一定的提升。在共識時延方面，d-PBFT 算法遙遙領先完全去中心化的PoW 算法，并且能和另外兩個部分去中心化的算法持平，而在拜占庭節點的威脅下Raft 算法束手無策，PBFT算法會在拜占庭節點擔任主節點時受到不小的干擾，而d-PBFT 算法在拜占庭節點的干擾下仍具有較好的表現。所以，d-PBFT 共識算法能夠兼顧信息安全、吞吐量和共識時延三方面需求，十分適合應用到聯盟區塊鏈當中［18］。

4 結語

本文在PBFT 算法的理論基礎上提出了d-PBFT 共識算法，在該算法中新增了節點狀態的監測和惡意節點的隔離機制，使得算法不僅能容忍拜占庭惡意節點還能捕獲到拜占庭節點，隔離并禁止將它們選為主節點，以此來降低它們在聯盟網絡中的影響。實驗結果表明，當聯盟網絡中存在拜占庭節點的情況下，該算法能降低拜占庭節點的干擾，提升共識結果的生成量。此外該算法仍然存在值得改進的地方，雖然該算法能標識并隔離拜占庭節點，但刪除信息中心的共識節點需要重啟聯盟網絡，下一步要優化聯盟網絡動態增刪共識節點的能力。