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

Libra 区块链采用了基于 LibraBFT 共识协议的 BFT 机制来实现所有验证者节点就将要执行的交易及其执行顺序达 成一致。这种方法可以在网络中建立信任，因为即使某些验证者节点(最多三分之一的网络)被破坏或发生故障，BFT 共识协议的设计也能够确保网络正常运行。与其他一些区块链中使用的“工作量证明”机制相比，这类共识协议还可 实现高交易处理量、低延迟和更高能效的共识方法。

概述

共识协议允许一组验证器创建单个数据库的逻辑外观。共识协议在验证器之间复制提交的事务，针对当前数据库执行潜在事务，然后同意对事务排序和执行执行的约束性承诺。因此，所有验证器都可以在状态机复制范例之后为给定版本号维护相同的数据库。Libra Blockchain使用HotStuff共识协议的变体，最近的Byzantine容错（BFT））共识协议，称为LibraBFT。它在Dwork，Lynch和Stockmeyer（DLS）的论文“部分同步存在中的共识”中定义的部分同步模型中提供安全性（所有诚实的验证者同意提交和执行）和活跃性（持续产生提交）和用于PBFT以及较新的协议，如Tendermint。在本文档中，我们提供了LibraBFT协议的高级描述，并讨论了代码的组织方式。请参阅此处以了解LibraBFT如何适应Libra Blockchain。有关LibraBFT的规格和证明的详细信息，请阅读完整的技术报告。

即使存在拜占庭故障，也必须在验证器之间达成关于数据库状态的协议。拜占庭故障模型允许一些验证器在没有约束的情况下随意偏离协议，但计算限制除外（因此无法破解加密假设）。拜占庭故障是最坏情况的错误，其中验证者串通并且恶意行为以试图破坏系统行为。容忍由恶意或被黑客验证器引起的拜占庭故障的共识协议也可以减轻任意硬件和软件故障。

LibraBFT假设在一组可能是诚实或拜占庭的验证器中分配一组3f + 1票。LibraBFT保持安全，防止双重花费和分叉等攻击，当最多f票由拜占庭验证员控制时 - 也暗示至少2f + 1票是诚实的。只要存在全局稳定时间（GST），LibraBFT仍然在线，从客户端进行交易，之后诚实验证器之间的所有消息都会在最大网络延迟内传递给其他诚实的验证器（这是部分同步）在DLS中引入的模型）。除了传统的保证之外，LibraBFT在验证器崩溃和重启时保持安全 - 即使所有验证器同时重启。

LibraBFT概述

在LibraBFT中，验证器从客户端接收事务并通过共享的mempool协议彼此共享。然后LibraBFT协议以一系列轮次进行。在每一轮中，验证者扮演领导者的角色，并提出一个交易块，以扩展包含完整先前交易历史的经过认证的块序列（请参阅下面的法定人数证书）。验证器接收建议的块并检查其投票规则以确定它是否应该投票认证该块。这些简单的规则确保了LibraBFT的安全性 - 并且可以清晰地分离和审核它们的实施。如果验证器打算投票给这个块，它会以推测方式执行块的事务，而不会产生外部影响。这导致计算由块执行产生的数据库的验证器。验证器然后将该块和数据库验证器的签名投票发送给领导者。领导者收集这些投票以形成法定人数证书，为该区块提供 2f + 1票的证据，并将法定人数证书广播给所有验证人。

当满足连续的3链提交规则时，将提交块。如果它具有仲裁证书并且在轮次k + 1和k + 2处由另外两个块和仲裁证书确认，则提交第k轮的块。提交规则最终允许诚实的验证器提交块。LibraBFT保证所有诚实的验证器最终都会提交块（以及从它链接的块序列）。一旦提交了一系列块，就可以保持执行其事务所产生的状态并形成一个复制的数据库。

HotStuff范例的优点

我们根据性能，可靠性，安全性，稳健实施的简易性以及验证器的操作开销评估了几种基于BFT的协议。我们的目标是选择最初支持至少100个验证器的协议，并且能够随着时间的推移而发展以支持500-1,000个验证器。选择HotStuff协议作为LibraBFT的基础有三个原因：（i）简单性和模块性; （ii）容易将共识与执行结合起来的能力; （iii）在早期实验中表现良好。

HotStuff协议分解为安全模块（投票和提交规则）和活跃。这种解耦提供了独立开发和实验以及并行地在不同模块上进行实验的能力。由于简单的投票和提交规则，协议安全性易于实现和验证。将执行作为共识的一部分进行集成是很简单的，以避免因基于领导的协议中的非确定性执行而产生问题。最后，我们的早期原型确认了在HotStuff中独立测量的高吞吐量和低事务延迟。我们没有考虑基于工作量的协议，例如比特币，因为它们性能差，能源（和环境）成本高。

HotStuff扩展和修改

在LibraBFT中，为了更好地支持Libra生态系统的目标，我们以多种方式扩展和调整核心HotStuff协议和实现。重要的是，我们重新制定安全条件，并提供安全，活跃和乐观响应的扩展证据。我们还实现了许多其他功能。首先，我们通过让验证器共同签署块的结果状态而不仅仅是事务序列，使协议更能抵抗非确定性错误。这还允许客户端使用仲裁证书来验证数据库中的读取。其次，我们设计了一个发出明确超时的活跃，验证器依靠法定人数来进入下一轮 - 不需要同步时钟。第三，VRF。这种机制限制了攻击者可以针对领导者发起有效的拒绝服务攻击的时间窗口。第四，我们使用聚合签名来保留签署仲裁证书的验证者的身份。这使我们能够为有助于仲裁证书的验证人提供激励。聚合签名也不需要复杂的阈值密钥设置。

实现细节

共识组件主要在Actor编程模型中实现 - 即，它使用消息传递在不同子组件之间进行通信，其中tokio框架用作任务运行时。actor模型的主要例外（因为它由几个子组件并行访问）是共识数据结构BlockStore，它管理块，执行，仲裁证书和其他共享数据结构。共识组件中的主要子组件是：

• TxnManager是mempool组件的接口，支持提取事务以及删除已提交的事务。提议者使用来自mempool的按需拉取事务来形成提议块。
• StateComputer是用于访问执行组件的接口。它可以执行块，提交块，并可以同步状态。
• BlockStore维护提议块树，块执行，投票，仲裁证书和持久存储。它负责维护这些数据结构组合的一致性，并且可以由其他子组件同时访问。
• EventProcessor负责处理各个事件（例如，process_new_round，process_proposal，process_vote）。它公开了每种事件类型的异步处理函数并驱动协议。
• Pacemaker负责共识协议的活跃性。它由于超时证书或仲裁证书而改变轮次，并在它是当前轮次的提议者时提出阻止。
• SafetyRules负责共识协议的安全性。它处理仲裁证书和LedgerInfo以了解新提交并保证遵循两个投票规则 - 即使在重新启动的情况下（因为所有安全数据都持久保存到本地存储）。

所有共识信息均由其创建者签署并由其接收者进行验证。消息验证最接近网络层，以避免无效或不必要的数据进入共识协议。