Libra白皮書中關于共識機制的描述

Libra區塊鏈采用了基于LibraBFT共識協議的BFT機制來實現所有驗證者節點就將要執行的交易及其執行順序達成一致。這種方法可以在網絡中建立信任，因為即使某些驗證者節點（最多三分之一的網絡）被破壞或發生故障，BFT共識協議的設計也能夠確保網絡正常運行。與其他一些區塊鏈中使用的“工作量證明”機制相比，這類共識協議還可實現高交易處理量、低延遲和更高能效的共識方法。

1. libra共識簡介

Libra的共識采用的是LibraBFT共識，是一個為Libra設計的魯棒的高效的狀態復制系統。它基于一種新型的BFT共識算法，HotStuff（BFT Consensus in Lens of Blockchain），在擴展性和一致性上達到了較高的水平。LibraBFT 在HotStuff的基礎上引入顯示的活躍機制并提供了具體的延時分析。LibraBFT在3f+1個驗證節點之間收集投票，這些驗證者可能是誠實的節點也可能是拜占庭節點。在網絡中有2f+1個誠實節點的前提下，Libra能夠抵御f個驗證節點的雙花攻擊和分叉攻擊。LibraBFT在一個有全局統一時間（GST），并且網絡最大延時（ΔT）可控的 Partial Synchrony的網絡中是有效的。并且，LibraBFT在所有驗證節點都重啟的情況下，也能夠保證網絡的一致性。

Libra白皮書指出，其將以許可型區塊鏈的方式起步。未來為了確保Libra的真正開放，始終以符合用戶最佳利益的方式運作，Facebook的最終目標是讓Libra網絡成為“非許可型網絡”，但是其目前的挑戰在于，他們目前還沒有成熟的解決方案可以通過非許可型網絡，提供支持全球數十億人和交易所需的規模、穩定性和安全性。從“許可型”網絡過渡到“非許可型”網絡，共識層面還需要做非常大的改進。

2. HotStuff算法

2.1 HotStuff算法特點

HotStuff 是一個三階段的BFT算法，允許一個新的leader簡單地選擇一個最新的的QC（Quorum certification）。它引入了一個第二階段，允許副本在投票后在不需要請求leader請求的基礎上改變他的決策。這一改進大大降低了復雜度，同時也降低了leader替換的復雜度。最后，由于長期委任所有的狀態，這樣HotStuff非常容易通過事件機制的方式實現，適合leader經常切換的場景。HotStuff主要有以下幾個特性：

? 線性的視圖切換：在GST后，對于一個誠實的leader，一旦被指定，會發給n個驗證者來收集簽名，以推動共識的決定；

? 樂觀的響應：在GST后，對于一個誠實的leader，一旦被指定，只需要等最早的 n-f 個驗證者返回消息就可以發起有效的提案，包括leader替換；

? 支持頻繁切主：HotStuff還有一個特點是新leader的推動協議達成共識的成本不高于當前領導者的成本，所以其適用于leader切換的協議；

? 決策簡單：HotStuff中副本只有兩種消息類型和一個簡單的規則來決定是否要接受一個提案，其通過投票和提交規則來達成一致性，通過Pacemaker來保證可用性，并且各階段的算法復雜度低；

? 閾值簽名：HotStuff使用閾值簽名的方式來收集簽名，使得簽名的驗證會更為簡單；

2.2 HotStuff算法流程

2.2.1 Basic HotStuff

Basic HotStuff 協議是HotStuff的基本過程，他在一系列的視圖中切換，視圖以單調遞增編號方式切換。在每個視圖內，有一個唯一的達成共識的leader。每個副本在起本地數據結構中會記錄所有請求的tree，tree的每個葉子節點是一個已經提出的提案。一個給定節點的分支是該節點到達樹根的所有路徑。按照HotStuff協議，隨著視圖的增長，分支會被提交。Leader需要像（n-f）個驗證者采用閾值簽名的方式收集簽名，收集簽名的過程主要包括3個階段，PREPARE、PRE-COMMIT和COMMIT階段，整個算法包括5個階段，PREPARE、PRE-COMMIT、COMMIT、DECIDE和FINALLY階段，如下圖所示：

1. PREPARE階段：該階段，leader發起一個high的提案（highQC），組成消息，消息內容 m = MSG（PREPARE， curProposal，highQC），并廣播給所有的驗證節點；驗證節點在收到時上述提案消息后會進行投票，如果m的node超過本地已經判決過的node是則會投票，并返回消息給leader，m‘ = voteMSG（PREPARE，n.node，⊥）。

2. PRE-COMMIT階段：該階段，當Leader收到（n-f）個驗證節點的PREPARE階段的投票信息后，會發起一個 PREPARE的提案（prepareQC），組成消息，消息內容為 m = MSG（COMMIT， ⊥，prepareQC），并廣播給所有的驗證節點；驗證節點在收到上述提案消息后會進行投票，并返回消息給leader，m’ = voteMSG（PRE-COMMIT，m.justify.node，⊥）。

3. COMMIT階段：該階段，當Leader收到（n-f）個驗證節點的PRE-COMMIT階段的投票信息后，會發起一個 PRE-COMMIT的提案（precommitQC），組成消息，消息內容為 m = MSG（COMMIT， ⊥，precommitQC），并廣播給所有的驗證節點；驗證節點在收到上述提案消息后會進行投票，并返回消息給leader，m‘ = voteMSG（COMMIT，m.justify.node，⊥）。

4. DECIDE階段：該階段，當Leader收到（n-f）個驗證節點 COMMIT 的投票后，會生成一個COMMIT的提案（commitQC），組成消息，消息內容為 m = MSG（DECIDE，⊥，commitQC），并廣播給所有的驗證者；驗證者在收到該消息后，會執行命令，并返回給客戶端。

5. FINALLY階段：如果系統進入下一個View，各個副本會發送一個消息給下一個View的leader，消息內容為 m = MSG（NEW-VIEW，⊥，prepareQC）。

2.2.2 Chained HotStuff

上圖中可以看出來Basic HotStuff的各個phase中的流程都非常相似，作者又提出了一種Chained HotStuff來優化和簡化Basic HotStuff。改進的點主要是改變每個PREPARE節點的View。這將大大降低通信消息的數量，并且可以對決策進行管道處理。Chained HotStuff的流程如下所示：

上述Figure1可以看出一個節點可以同時處于不同的View，通過鏈式的結構，一個提案在經過3個塊后能夠達成共識。其內部有一個狀態轉換器，通過genericQC實現提案的自動切換。其主要算法流程如下所示：

3. LibraBft改進

Libra 為了更好地適應其生態，對HotStuff進行了相應的優化，主要有5點：

1.首要的是Libra定義了安全的條件，提供了安全性、活性和樂觀響應的擴展證明；

2.第二點：Libra 通過讓驗證器集體對區塊的狀態而不是事務的順序進行簽名，使得協議會更加魯棒。同時還允許客戶端使用QC驗證從數據庫里讀出的數據。

3.第三點：Libra 設計了一個Pacemaker 來發出顯示的超時信號，驗證者通過他發出的提案自動進入下一個視圖，而不需要一個同步的時鐘；

4.第四點：Libra 希望讓礦工變得不可預測，它最新提交的區塊信息為種子生成一個可驗證的隨機數VRF，成為下一個礦工；

5.第五點：Libra 使用聚合簽名的方式保留QC中驗證者的身份，以提高驗簽效率，同時為這些驗證者提供獎勵。