原文：https://github.com/libra/libra/blob/7c5de4d161e096648dba8ac54328d1568ae2d2e3/consensus/README.md

Libra 區(qū)塊鏈采用了基于 LibraBFT 共識協(xié)議的 BFT 機(jī)制來實現(xiàn)所有驗證者節(jié)點就將要執(zhí)行的交易及其執(zhí)行順序達(dá) 成一致。這種方法可以在網(wǎng)絡(luò)中建立信任，因為即使某些驗證者節(jié)點(最多三分之一的網(wǎng)絡(luò))被破壞或發(fā)生故障，BFT 共識協(xié)議的設(shè)計也能夠確保網(wǎng)絡(luò)正常運(yùn)行。與其他一些區(qū)塊鏈中使用的“工作量證明”機(jī)制相比，這類共識協(xié)議還可 實現(xiàn)高交易處理量、低延遲和更高能效的共識方法。

概述

共識協(xié)議允許一組驗證器創(chuàng)建單個數(shù)據(jù)庫的邏輯外觀。共識協(xié)議在驗證器之間復(fù)制提交的事務(wù)，針對當(dāng)前數(shù)據(jù)庫執(zhí)行潛在事務(wù)，然后同意對事務(wù)排序和執(zhí)行執(zhí)行的約束性承諾。因此，所有驗證器都可以在狀態(tài)機(jī)復(fù)制范例之后為給定版本號維護(hù)相同的數(shù)據(jù)庫。Libra Blockchain使用HotStuff共識協(xié)議的變體，最近的Byzantine容錯（BFT））共識協(xié)議，稱為LibraBFT。它在Dwork，Lynch和Stockmeyer（DLS）的論文“部分同步存在中的共識”中定義的部分同步模型中提供安全性（所有誠實的驗證者同意提交和執(zhí)行）和活躍性（持續(xù)產(chǎn)生提交）和用于PBFT以及較新的協(xié)議，如Tendermint。在本文檔中，我們提供了LibraBFT協(xié)議的高級描述，并討論了代碼的組織方式。請參閱此處以了解LibraBFT如何適應(yīng)Libra Blockchain。有關(guān)LibraBFT的規(guī)格和證明的詳細(xì)信息，請閱讀完整的技術(shù)報告。

即使存在拜占庭故障，也必須在驗證器之間達(dá)成關(guān)于數(shù)據(jù)庫狀態(tài)的協(xié)議。拜占庭故障模型允許一些驗證器在沒有約束的情況下隨意偏離協(xié)議，但計算限制除外（因此無法破解加密假設(shè)）。拜占庭故障是最壞情況的錯誤，其中驗證者串通并且惡意行為以試圖破壞系統(tǒng)行為。容忍由惡意或被黑客驗證器引起的拜占庭故障的共識協(xié)議也可以減輕任意硬件和軟件故障。

LibraBFT假設(shè)在一組可能是誠實或拜占庭的驗證器中分配一組3f + 1票。LibraBFT保持安全，防止雙重花費和分叉等攻擊，當(dāng)最多f票由拜占庭驗證員控制時 - 也暗示至少2f + 1票是誠實的。只要存在全局穩(wěn)定時間（GST），LibraBFT仍然在線，從客戶端進(jìn)行交易，之后誠實驗證器之間的所有消息都會在最大網(wǎng)絡(luò)延遲內(nèi)傳遞給其他誠實的驗證器（這是部分同步）在DLS中引入的模型）。除了傳統(tǒng)的保證之外，LibraBFT在驗證器崩潰和重啟時保持安全 - 即使所有驗證器同時重啟。

LibraBFT概述

在LibraBFT中，驗證器從客戶端接收事務(wù)并通過共享的mempool協(xié)議彼此共享。然后LibraBFT協(xié)議以一系列輪次進(jìn)行。在每一輪中，驗證者扮演領(lǐng)導(dǎo)者的角色，并提出一個交易塊，以擴(kuò)展包含完整先前交易歷史的經(jīng)過認(rèn)證的塊序列（請參閱下面的法定人數(shù)證書）。驗證器接收建議的塊并檢查其投票規(guī)則以確定它是否應(yīng)該投票認(rèn)證該塊。這些簡單的規(guī)則確保了LibraBFT的安全性 - 并且可以清晰地分離和審核它們的實施。如果驗證器打算投票給這個塊，它會以推測方式執(zhí)行塊的事務(wù)，而不會產(chǎn)生外部影響。這導(dǎo)致計算由塊執(zhí)行產(chǎn)生的數(shù)據(jù)庫的驗證器。驗證器然后將該塊和數(shù)據(jù)庫驗證器的簽名投票發(fā)送給領(lǐng)導(dǎo)者。領(lǐng)導(dǎo)者收集這些投票以形成法定人數(shù)證書，為該區(qū)塊提供 2f + 1票的證據(jù)，并將法定人數(shù)證書廣播給所有驗證人。

當(dāng)滿足連續(xù)的3鏈提交規(guī)則時，將提交塊。如果它具有仲裁證書并且在輪次k + 1和k + 2處由另外兩個塊和仲裁證書確認(rèn)，則提交第k輪的塊。提交規(guī)則最終允許誠實的驗證器提交塊。LibraBFT保證所有誠實的驗證器最終都會提交塊（以及從它鏈接的塊序列）。一旦提交了一系列塊，就可以保持執(zhí)行其事務(wù)所產(chǎn)生的狀態(tài)并形成一個復(fù)制的數(shù)據(jù)庫。

HotStuff范例的優(yōu)點

我們根據(jù)性能，可靠性，安全性，穩(wěn)健實施的簡易性以及驗證器的操作開銷評估了幾種基于BFT的協(xié)議。我們的目標(biāo)是選擇最初支持至少100個驗證器的協(xié)議，并且能夠隨著時間的推移而發(fā)展以支持500-1,000個驗證器。選擇HotStuff協(xié)議作為LibraBFT的基礎(chǔ)有三個原因：（i）簡單性和模塊性; （ii）容易將共識與執(zhí)行結(jié)合起來的能力; （iii）在早期實驗中表現(xiàn)良好。

HotStuff協(xié)議分解為安全模塊（投票和提交規(guī)則）和活躍。這種解耦提供了獨立開發(fā)和實驗以及并行地在不同模塊上進(jìn)行實驗的能力。由于簡單的投票和提交規(guī)則，協(xié)議安全性易于實現(xiàn)和驗證。將執(zhí)行作為共識的一部分進(jìn)行集成是很簡單的，以避免因基于領(lǐng)導(dǎo)的協(xié)議中的非確定性執(zhí)行而產(chǎn)生問題。最后，我們的早期原型確認(rèn)了在HotStuff中獨立測量的高吞吐量和低事務(wù)延遲。我們沒有考慮基于工作量的協(xié)議，例如比特幣，因為它們性能差，能源（和環(huán)境）成本高。

HotStuff擴(kuò)展和修改

在LibraBFT中，為了更好地支持Libra生態(tài)系統(tǒng)的目標(biāo)，我們以多種方式擴(kuò)展和調(diào)整核心HotStuff協(xié)議和實現(xiàn)。重要的是，我們重新制定安全條件，并提供安全，活躍和樂觀響應(yīng)的擴(kuò)展證據(jù)。我們還實現(xiàn)了許多其他功能。首先，我們通過讓驗證器共同簽署塊的結(jié)果狀態(tài)而不僅僅是事務(wù)序列，使協(xié)議更能抵抗非確定性錯誤。這還允許客戶端使用仲裁證書來驗證數(shù)據(jù)庫中的讀取。其次，我們設(shè)計了一個發(fā)出明確超時的活躍，驗證器依靠法定人數(shù)來進(jìn)入下一輪 - 不需要同步時鐘。第三，VRF。這種機(jī)制限制了攻擊者可以針對領(lǐng)導(dǎo)者發(fā)起有效的拒絕服務(wù)攻擊的時間窗口。第四，我們使用聚合簽名來保留簽署仲裁證書的驗證者的身份。這使我們能夠為有助于仲裁證書的驗證人提供激勵。聚合簽名也不需要復(fù)雜的閾值密鑰設(shè)置。

實現(xiàn)細(xì)節(jié)

共識組件主要在Actor編程模型中實現(xiàn) - 即，它使用消息傳遞在不同子組件之間進(jìn)行通信，其中tokio框架用作任務(wù)運(yùn)行時。actor模型的主要例外（因為它由幾個子組件并行訪問）是共識數(shù)據(jù)結(jié)構(gòu)BlockStore，它管理塊，執(zhí)行，仲裁證書和其他共享數(shù)據(jù)結(jié)構(gòu)。共識組件中的主要子組件是：

• TxnManager是mempool組件的接口，支持提取事務(wù)以及刪除已提交的事務(wù)。提議者使用來自mempool的按需拉取事務(wù)來形成提議塊。
• StateComputer是用于訪問執(zhí)行組件的接口。它可以執(zhí)行塊，提交塊，并可以同步狀態(tài)。
• BlockStore維護(hù)提議塊樹，塊執(zhí)行，投票，仲裁證書和持久存儲。它負(fù)責(zé)維護(hù)這些數(shù)據(jù)結(jié)構(gòu)組合的一致性，并且可以由其他子組件同時訪問。
• EventProcessor負(fù)責(zé)處理各個事件（例如，process_new_round，process_proposal，process_vote）。它公開了每種事件類型的異步處理函數(shù)并驅(qū)動協(xié)議。
• Pacemaker負(fù)責(zé)共識協(xié)議的活躍性。它由于超時證書或仲裁證書而改變輪次，并在它是當(dāng)前輪次的提議者時提出阻止。
• SafetyRules負(fù)責(zé)共識協(xié)議的安全性。它處理仲裁證書和LedgerInfo以了解新提交并保證遵循兩個投票規(guī)則 - 即使在重新啟動的情況下（因為所有安全數(shù)據(jù)都持久保存到本地存儲）。

所有共識信息均由其創(chuàng)建者簽署并由其接收者進(jìn)行驗證。消息驗證最接近網(wǎng)絡(luò)層，以避免無效或不必要的數(shù)據(jù)進(jìn)入共識協(xié)議。