【共識專欄】HotStuff共識-ODAILY_ARE

——前言——

我們已經了解到分布式系統一般通過狀態復制機原理來實現一致性。其核心思想是系統中所有副本運行著相同的狀態機，只要所有副本都以相同的初識狀態開始，并基于相同的初識狀態執行一組相同順序的操作，那么所有的狀態最終會收斂一致，即整個系統對外表現出一致性。而確定這一組相同順序的操作需要系統達成共識，進一步說即所有誠實節點對執行順序達成共識，這便是著名的拜占庭將軍問題。

拜占庭類共識算法的理論安全保證，即n>3f，n為總的節點數量，f為惡意節點數量。一個拜占庭共識算法需要保證兩個性質：

安全性：所有誠實節點都認為某一時刻系統狀態為s

活性：所有誠實節點最終能確定s為系統狀態

其中s是一個抽象的概念，可以理解為系統內存在一個變量S，這個變量S的取值為系統狀態，系統內節點接收一系列關于S的操作指令，某時刻就S的取值進行共識，所有誠實節點確定變量S=s則滿足安全性，所有誠實節點對變量S的取值必須做出決定且終止則滿足活性。

以往，在分布式系統的研究中，拜占庭類共識往往都伴隨著較高的通信復雜度，對網絡造成的消耗極大，系統規模不易擴大。如經典的PBFT算法，其達成共識需要經過三個階段，PRE-PREPARE階段主節點將請求消息發送給其他節點，其他節點對該消息驗證過后，各自發送prepare消息給其他節點，這個階段產生了n^2條消息。為了保證跨視圖上的一致性，節點在收到至少quorum的prepare消息后再發送commit消息給其他節點。當節點最終收到至少quorum的commit消息時，再最終對該請求進行提交。而網絡異常節點超時觸發視圖切換時，則需要o(n^3)的通信復雜度

理解PBFT中每個階段的工作是HotStuff的基礎，PBFT中每個階段都目標都是為保證安全性和活性。

假設系統某時刻收到指令S'=S+1，主節點將這條指令S'=S+1發送給非主節點，因為是拜占庭問題，誠實節點不確定自己收到的是否和其他誠實節點一致，節點之間需要進行一次相互通信，確定自己和其他誠實節點收到的消息一致，每個節點發送prepare消息給其他所有節點，之后若收到quorum個數量的prepare消息，且通過驗證，達成第一輪共識。此時，似乎可以確定了誠實節點收到的消息一致。但是這里隱含條件是，達到共識的節點只是在自己的視角看到：我收到并驗證了quorum個一致的消息。但其他節點不一定和自己一樣收到quorum個prepare消息達成共識，如果此時進行提交，出現了網絡故障，提交了的節點知道已經達成共識，只要等網絡恢復，這條指令一定會被整個系統提交。但其他節點可能由于網絡故障還未達成共識，他們無法確定一直等下去能否提交。為了讓系統保持活性，進行視圖切換，此時新的主節點需要確定是在S'還是S的基礎上執行新的指令。如果沒有發現部分節點已經提交了該指令，且對另一條指令S''=S+2進行了共識并提交，系統對變量S的取值產生了不一致。因此，在此時提交有安全性的問題。

A股收盤：深證區塊鏈50指數下跌1.12%:金色財經消息，A股收盤，上證指數報3197.82點，收盤下跌0.37%，深證成指報10972.96點，收盤下跌0.34%，深證區塊鏈50指數報3206.66點，收盤下跌1.12%。區塊鏈板塊收盤下跌1.07%，數字貨幣板塊收盤下跌1.13%。[2023/7/18 11:02:11]

如果再進行一個階段的共識，在達成PREPARE共識之后，各自再發送一個commit消息，各自節點等待接受并驗證quorum個commit消息之后再提交。會遇到同樣的問題，達成COMMIT共識的節點提交了，他們知道如果網絡正常，系統遲早都會提交，但是其他未達成COMMIT共識的節點不確定最后能否提交。網絡發生故障后新視圖中的主節點如果沒有發現已經提交了的節點，依然會造成不一致。這里的矛盾是我們為了活性需要切換視圖繼續共識；為了安全性還要確保新視圖開始共識前S的取值一致，已經提交了的指令在新視圖中也一定需要被提交。而在PBFT中采用視圖切換時向其他節點發送消息證明自己S的狀態的方法，即發送自己最新的S的一條pre-prepare消息和對應的quorum條prepare消息。視圖切換時，新主節點共識前就能判斷S'=S+1是否需要提交。

如果沒有任何一個節點就S'=S+1達成PREPARE階段共識，則不會繼續對S'=S+1進行提交。

如果存在一個節點對達成了S'=S+1達成了PREPARE階段共識，則不可能對一條沖突的指令S''=S+2達成共識并提交，

按照這種規則安全性和活性就得到了保證，而這種方法帶來的復雜度卻是o(n^3)。因此該算法依然不能夠運用在大規模的網絡當中。尹茂帆等人提出的HotStuff共識算法具有線性視圖變更的特性，解決了經典的PBFT甚至BFT類共識的瓶頸，主節點的切換無需增加其他協議和代價，系統仍能對外工作表現一致性，使得共識流程通信復雜度降低至o(n)。

——HotStuff基本概念——

了解hotstuff算法需要介紹幾個與共識流程相關的概念：

1）門限簽名：一個門限簽名方案指由n個成員組成的簽名群體，所有成員共同擁有一個公共密鑰，每個成員擁有各自的私鑰。只要收集到k個成員的簽名，且生成一個完整的簽名，該簽名可以通過公鑰進行驗證。

31310ETH從未知錢包轉移到Coinbase:金色財經報道，據Whale Alert監測，北京時間今日上午11:20，31310ETH (價值約51,627,020美元) 從未知錢包轉移到Coinbase。[2023/6/15 21:38:22]

2）證書：主節點收到至少quorum個節點對用一個提案的投票消息后，利用門限簽名將其合成一個QC，這個QC可以理解為門限簽名生成的完整簽名，表示對該次提案達成一次共識。

3）視圖：視圖是共識的基本單元，一個視圖至多達成一次共識，并且單調遞增，每個視圖逐漸輪換推進共識。

4）共識狀態樹：每個共識區塊可以看做是一個樹節點，每個樹節點內包含對應的提案內容和相對應的QC，每個樹節點包含一個父親樹節點的哈希，形成一棵樹狀結構，主節點基于本地最長的分支生成新的樹節點。落后節點根據其他節點的最長分支上的最新樹節點來同步中間缺失的樹節點。

——HotStuff共識流程——

HotStuff的核心圍繞著三輪共識投票展開，原論文中提出了三種形式：簡易版HotStuff，鏈狀HotStuff，事件驅動的HotStuff。接下來將通過對比PBFT中每個階段共識的過程來理解HotStuff算法。

▲BasicHotstuff

BasicHotStuff是共識的基本過程。其中，視圖以單調遞增的方式不斷切換。每個視圖內都有一個唯一的主節點負責提案、收集和轉發消息并生成QC，整個過程包括4個階段：準備階段、預提交階段、提交階段、決定階段，主節點提交某個分支，在PREPARE、PRE-COMMIT、COMMIT三個階段收集quorum個共識節點帶簽名的投票消息，利用門限簽名合成一個QC，然后廣播給其他節點。

HotStuff結合門限簽名可以將之前互相廣播共識消息的方式，轉為由主節點處理、合并轉發，通信復雜度可以降低到o(n)，簡而言之就是HotStuff用門限簽名+兩輪通信達到了PBFT一輪通信的共識效果。

對比PBFT算法，共識開啟于主節點將請求附帶在pre-prepare中發送給其他節點，主節點即履行完了該輪共識的職責，接下來和其他節點一樣。整個共識過程包括一個廣播提案階段，兩個共識階段。

借貸協議Solend將推出無許可借貸市場，允許用戶創建任何代幣的借貸池:8月18日消息，據外媒報道，Solana頭部借貸協議將推出無許可借貸市場，允許任何擁有100SLND（約70美元費用）的用戶創建任何代幣的借貸池。

據悉，Solend擁有21個列入白名單的貸款池，為Solana生態提供了4.71億美元的可借代幣，這些白名單的借貸池由Solend團隊審查。無許可借貸市場旨在幫助項目“引導”其原生代幣的借貸市場，幫助有影響力的人通過推廣使用自己的資產池來“從他們的追隨者中獲利”，甚至支持他們僅靠聲譽創建“無擔保”信貸額度。（CoinDesk）[2022/8/18 12:33:21]

PREPARE階段：

主節點：1）根據收到的quorum條New-View消息，該消息中包含了發送方的狀態樹中高度最高的prepareQC，主節點在收到的prepareQC中計算出高度最高的QC，記為highQC；

2）根據這個highQC的節點所指向的分支，打包區塊創建新的樹節點，其父節點為highQC指向的節點；

3）將生成的提案附帶在prepare消息中發送給其他從節點，且當前提案包含highQC。

從節點：1）收到該prepare消息之后，對prepare中的信息進行驗證，包括qc中簽名的合法性；是否當前視圖的提案；

2）prepare消息中的節點是否擴展自lockedQC的分支或者prepare消息中的highQC的視圖號大于lockedQC；

3）生成prepare-vote消息并附帶一個簽名發送給主節點。

PRE-COMMIT階段：

主節點收到quorum個當前提案的prepare-vote消息時，通過聚合quorum個部分簽名得到prepareQC；然后主節點廣播pre-commit消息附帶聚合得到的prepareQC。

從節點：其他節點收到pre-commit消息，驗證之后，發送pre-commitvote消息給主節點。

??注意此時，在主節點發送的pre-commit中的prepareQC就表明了prepare消息中的提案消息，所有節點投票成功達成了共識，這一時刻與PBFT中PREPARE階段達成共識類似。

Web3身份網絡Quadrata宣布主網上線:7月26日消息，Web3身份網絡Quadrata宣布在以太坊上啟動主網。Quadrata Passport允許用戶證明其“humanity”和KYC/AML狀態，目標是擴大鏈上可訪問的服務范圍。據悉，Quadrata將為用戶提供去中心化身份（DID），并為去中心化應用程序提供合規基礎設施。

此前7月12日消息，Quadrata完成750萬美元種子輪融資，Dragonfly Capital領投，Franklin Templeton、Abra、GSR Ventures、Orange DAO、Fellows Fund、GreatPoint Ventures、August Capital等參投。（Business Wire）[2022/7/26 2:38:59]

Commit階段：

主節點：與pre-commit階段類似。1）主節點先收集quorum個pre-commitvote消息，然后聚合出這一階段的pre-commitQC，附帶在commit消息中發送給其他節點。2）設置本地lockedQC為pre-commitQC。

從節點：收到commit消息時，消息驗證通過同樣更新本地的lockedQC為commit消息中的pre-commitQC，對其簽名并生成commitvote并發送給主節點

??注意此時，主節點發送的commit消息附帶的pre-commitQC即與PBFT中的第二輪COMMIT階段共識類似，其中PBFT中該階段共識表明了節點對的第一階段達成共識這件事的共識，即確保了至少quorum個節點已經完成PREPARE階段，在發生視圖切換時，有足夠多的節點能夠證明對該提案達成了PREPARE共識，在新視圖中提案內容需要被提交。

DECIDE階段：

主節點：1）收集到quorum個commitvote消息時，聚合得到commitQC，并且附帶在decide消息中發送給其他節點；

2）當其他節點收到decide消息時，其中commitQC指向的提案中的交易就會被執行；

3）之后增加視圖號viewnumber，開啟下一輪共識，根據prepareQC構造New-View消息。

從節點：驗證消息后執行decide消息中commitQC指向的樹節點的交易。

StarkWare將對StarkNet進行狀態重置，以使StarkNet系統盡可能精簡和安全:7月7日消息，零知識證明研發機構StarkWare表示，將對StarkNet進行狀態重置，以從StarkNet操作系統和協議中消除所有多余的代碼和流程，使StarkNet系統盡可能精簡和安全。

StarkWare稱，“預計會在2022年第四季度發布FSR（最終狀態重置）。現有的StarkNet Alpha將根據需要運行。同時將部署一個新的更精簡的StarkNet Alpha版本，這個版本將以新的狀態重新開始，這意味著在新的實例中，所有合約和賬戶都需要重新部署，資產需要從舊的StarkNet Alpha遷移過去。”[2022/7/7 1:58:46]

nextViewinterrupt階段：在共識中任何其他階段發生了超時事件，發送新視圖的new-view消息，都會直接開啟下一輪新的共識。

??注意，HotStuff中一筆交易從開始到提交進行了三輪共識，第三輪共識的加入，克服了經典兩階段范式的共識算法擴展的瓶頸。PBFT中為了保證系統在遇到惡意節點時能繼續工作，需要進行視圖切換，而新視圖中為了確定上一個視圖中的區塊是否達成共識，需要在view-change消息中附帶自己收集到的quorum個prepare消息和相對應的一個pre-prepare消息作為證明，然后每個節點廣播view-change消息請求視圖切換，此時廣播的消息復雜度o(n^2)，消息的量級為o(n)，因此視圖切換的復雜度為o(n^3)。安全性和活性讓PBFT需要o(n^3)的通信復雜度，對于網絡的負載極大，限制了其向大規模網絡的擴展。而HotStuff中如果我們對某一區塊達成了兩輪共識，在更換主節點時便能確定，主節點只需要基于最新的兩輪共識節點產生新節點是安全的。換句話說，只需要根據區塊自身的狀態就可以確定是否在新的視圖中基于該區塊打包塊新區塊，降低了在視圖切換時候的通信復雜度。

▲ChainedHotStuff

可以發現在BasicHotStuff中的各個階段流程都高度的相似，HotStuff的作者便提出了ChainedHotStuff來簡化BasicHotStuff的消息類型，并允許BasicHotStuff的各個階段以流水線方式進行處理交易。

ChainedHotStuff的流程如圖：

從圖中可以看出，每個階段都會切換視圖，因此每個提案都有自己的視圖。節點對于不同的提案來說處在不同的視圖上，PREPARE階段的投票被當前視圖的主節點合成QC，并轉發給下一個視圖的主節點，即下一視圖在進行PREAPRE階段的同時，也在進行上一個視圖的PRE-COMMIT階段。每個階段具有類似的結構，視圖v+1的PREPARE階段可以看作是視圖v的PRE-COMMIT階段。視圖v+2的的PREPARE階段看作是視圖v+1的PRE-COMMIT階段和視圖v的COMMIT階段。v1中的cmd1將在視圖v1，v2，v3中分別進行PREPARE、PRE-COMMIT、COMMIT階段，在v4中就進行提交。cmd2以此類推。每個階段的cmd提案產生將會附帶上一階段投票產生的QC。經過流水線簡化版本的HotStuff工作過程如下：

主節點：1）等待NEW-VIEW消息，發出自己的提案；

2）等待其他節點進行投票；

3）向下一個主節點發送NEW-VIEW消息。

從節點：1）等待主節點的提案消息；

2）檢查提案中的QC，更新本地highQC，lockedQC，發送投票；

3）向下一個主節點發出NEW-VIEW消息。

▲Event-drivenHotStuff

從ChainedHotStuff到Event-drivenHotStuff，實現原論文中將整個協議的安全性和活性解耦開，活性成為單獨的pacemaker模塊。pacemaker模塊保證了在全局穩定時間之后的活性。提供兩個功能：

選擇、校驗每個視圖的主節點。

幫助主節點生成提案。

換而言之，在如此低的視圖切換代價下，pacemaker中可以采用任何合適的節點輪換機制，以及任何提案生成策略。

Event-drivenHotstuff與其他版本原理還是核心的三階段共識，區別只是工程實現上的便利，具體可見論文偽代碼

——HotStuff之改進優化-NoxBFT——

活性機制優化

活性機制是共識能夠持續推進的關鍵。在原HotStuff論文中活性機制使用了一個全局一致的超時時間確定了視圖超時。在NoxBFT中，我們設計了更靈活的機制應對網絡環境的不穩定。

具體：每個節點進入新的視圖后，根據配置等待超時時間，如果本視圖未超時，則定時器時長不變。若超時，則不斷廣播TimeoutMsg，直到收到quorum個TimeoutMsg進入下一視圖，此時定時器置為配置時間k倍，連續超時n次則置超時器為k^n倍。以此類推，這樣避免在網絡不穩定時頻繁切換視圖。

交易緩存池

在區塊鏈的應用中，為避免交易丟失，我們設計了交易緩存池緩存客戶端交易。共識模塊主動拉取交易進行打包。交易池也可以減輕共識工作量，進行交易去重，我們通過交易內容hash標識交易，將已經執行的交易寫入布隆過濾器，防止雙花攻擊，提升共識算法的穩定性。

快速恢復機制

不穩定的網絡環境可能使共識節點丟失共識消息，導致節點落后。在HotStuff原論文中，作者將此部分具體實現留給了開發者。我們實現了工程可用的同步算法，讓落后共識節點恢復定序功能，分為兩步：

1）節點落后較多，直接向其他節點拉取區塊執行恢復到最新檢查點。

2）檢查點之后的共識進度落后，向其他節點拉取最新的CommitQC快速恢復共識進度。

為提高效率，我們采取并行向不同節點拉取區塊的機制，可以靈活配置并行度。并行拉取的區塊先進行持久化再有序執行，同時記錄各個節點拉取效率的分數，以便下次高效選取目標節點進行同步。整個過程可以以最快的速度拉取所有丟失的交易，減少整個過程的等待時間。

聚合簽名

NoxBFT中實現并改進了Ed25519聚合簽名算法。一方面通過編譯預先計算的數據加速；另一方面，我們實現了大數類型專用的加速Ed25519的計算過程，壓縮大數的存儲。最終Ed25519算法要比官方快2.5倍，簽名算法也實現了更高的性能。

總結

在BFT類的共識研究中，安全性的要求需要在視圖切換時，主節點確保自己是基于最新的系統狀態工作的，視圖切換與系統狀態的共識產生了o(n^3)的通信復雜度。而HotStuff通過增加一輪共識來解決，再結合門限簽名降低了通信復雜度。不僅如此，流水線的工作方式，讓算法變得足夠簡潔優雅，這與raft的工作方式相似，采取了先上鏈再共識，通過三輪共識之后再執行。這種鏈式的結構，不再區分每個階段通信的意義，靈活的主節點更換的機制，在節點更換時不需要通信來確定最新共識的狀態，對安全性與活性進行隔離，投票保證了安全性，pacemaker保證了其在網絡異步時的活性。

作者簡介

程泰寧

趣鏈科技基礎平臺部共識算法研究小組

參考文獻

SchneiderFB.Thestatemachineapproach:Atutorial.SpringerNewYork,1990.

LamportL,ShostakR,PeaseM.TheByzantineGeneralsProblem.ACMTransactionsonProgrammingLanguagesandSystems,1982,4(3).

CastroM,LiskovB.PracticalByzantinefaulttolerance.OSDI.1999,99(1999):173-186.

YinM,MalkhiD,ReiterMK,etal.HotStuff:BFTConsensusintheLensofBlockchain.2018.

ShoupV.PracticalThresholdSignatures//InternationalConferenceonTheory&ApplicationofCryptographicTechniques.Springer-Verlag,2000.

Tags：PREAREMMIOMMiExpress TokenMAREOMMI幣Decentralized Community Investment Protocol

UNI