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

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

概述

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

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

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

LibraBFT概述

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

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

HotStuff范例的優(yōu)點(diǎn)

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

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

HotStuff擴(kuò)展和修改

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

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

共識組件主要在Actor編程模型中實(shí)現(xiàn) - 即，它使用消息傳遞在不同子組件之間進(jìn)行通信，其中tokio框架用作任務(wù)運(yùn)行時(shí)。actor模型的主要例外（因?yàn)樗蓭讉€(gè)子組件并行訪問）是共識數(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)組合的一致性，并且可以由其他子組件同時(shí)訪問。
• EventProcessor負(fù)責(zé)處理各個(gè)事件（例如，process_new_round，process_proposal，process_vote）。它公開了每種事件類型的異步處理函數(shù)并驅(qū)動(dòng)協(xié)議。
• Pacemaker負(fù)責(zé)共識協(xié)議的活躍性。它由于超時(shí)證書或仲裁證書而改變輪次，并在它是當(dāng)前輪次的提議者時(shí)提出阻止。
• SafetyRules負(fù)責(zé)共識協(xié)議的安全性。它處理仲裁證書和LedgerInfo以了解新提交并保證遵循兩個(gè)投票規(guī)則 - 即使在重新啟動(dòng)的情況下（因?yàn)樗邪踩珨?shù)據(jù)都持久保存到本地存儲）。

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