原文链接：https://developers.libra.org/docs/crates/consensus
译者：humyna
日期：2019.09.25
版权及转载声明：本文采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
共识组件支持使用LibraBFT共识协议的状态机复制。
共识协议允许一组验证器创建单个数据库的逻辑外观appearance。共识协议在验证器之间复制提交的交易，对当前数据库执行潜在的交易，然后就事务顺序和执行结果达成一致。因此，所有验证器都可以按照状态机复制范式为给定的版本号维护一个相同的数据库。Libra协议使用了Hotstuff共识协议的一种变体这是最新的一种拜占庭容错 (BFT) 共识协议, 称为LibraBFT。它提供了在Dwork，Lynch和Stockmeyer(DLS) 的论文（"Consensus in the Presence of Partial Synchrony"）中定义且在Castro和Liskov 所著论文"Practical Byzantine Fault Tolerance" (PBFT) 提及的部分同步模型的安全性（所有诚实的验证者都同意提交和执行）和活跃性（提交是持续产生的），以及Tendermint等最新的协议。在本文档中，我们从高层次描述 LibraBFT协议，并讨论如何组织代码。请参阅Libra区块链论文，了解更多关于LibraBFT如何适应Libra protocol的信息。有关LibraBFT的规范和证明的详细信息，请阅读完整的技术报告。
即使存在拜占庭错误，验证器之间也必须就数据库状态达成一致。拜占庭失败模型允许一些验证器在没有约束的情况下任意偏离协议，但计算受限的情况除外（因此无法打破加密假设）。拜占庭错误是最坏情况下的错误，验证器串通并恶意地试图破坏系统行为。一个能够容忍由恶意的或黑客控制验证器导致的拜占庭错误的共识协议也能减轻任意的硬件和软件故障。
LibraBFT假设一组3f+1的选票分布在一组可能是诚实的或拜占庭式的验证器中。当最多f票由拜占庭验证器控制时，LibraBFT仍然是安全的（可以防止双花和分叉之类的攻击），这也意味着至少2f+1票是诚实的。只要存在全局稳定时间（GST），从客户端提交的交易在诚实的验证者之间传递的的时间在最大网络延迟Δ内，LibraBFT保持活动状态（DLS中介绍的部分同步模型）。除了传统的保证之外，LibraBFT在验证器崩溃和重新启动时仍然保持安全——即使所有验证器同时重新启动。
在LibraBFT中，验证器接收来自客户端的交易，并通过共享的内存池协议彼此共享。 然后LibraBFT协议逐轮进行。在每一轮，一个验证器会扮演leader的角色，并提议一个交易区块，以扩展经过认证（见下面的法定人数证书）的块序列，这个块序列里包含先前完整的交易历史。验证器接收提议的块并检查其投票规则，以确定是否应该投票认证该块。这些简单的规则确保了LibraBFT的安全性，并且它们的实现可以被清晰地隔离和审计。如果验证器打算为该块投票，它会试探地执行块的交易，而不会产生外部影响。这将导致执行块所产生的数据库的身份验证器的计算，然后验证器把对块的签名投票和数据库验证者（authenticator）发送给leader。leader收集这些选票以形成一个法定人数证书，该证书为该块提供≥2f+1票的证据，并将法定人数证书广播给所有验证器。
当满足连续3-链提交规则，区块被提交。如果一个块在K轮有法定人数证明并被超过2个块确认，并且在其后2轮 k+1 和 k+2 也具有法定人数证明，则这个块会被提交。提交规则最终允许诚实的验证器提交块。 LibraBFT保证所有诚实的验证器最终都会提交块（并从它链接块序列）。 一旦块被提交确认，执行交易后的结果状态就会永久存储，并形成一个复制的数据库。
我们从性能、可靠性、安全性、易实现性以及验证器的操作开销等方面评估了几种基于BFT的协议。我们的目标是选择一个最初支持至少100个验证器的协议，并且能够随着时间的推移而发展，可以支持500-1000个验证器。我们选择HotStuff协议作为LibraBFT的基础有三个原因：（i）简单和模块化；（ii）方便集成具有执行器的共识的能力；以及（iii）在早期实验中有较好的效果。
HotStuff协议分解为安全模块（投票和提交规则）和存活模块（起搏器）。 这种解耦提供了独立开发和实验的能力，并在不同的模块上并行进行。 由于简单的投票和提交规则，协议安全性易于实现和验证。将集成执行作为共识的一部分是很简单的，这可以避免基于leader的协议中不确定性执行引起的分叉问题。 最后，我们早期的原型证实了HotStuff被独立测量的高吞吐量和低交易延迟。我们没有考虑基于工作量证明(PoW)的协议，例如 Bitcoin, 因为它们性能差和高能耗（以及环境）成本。
在LibraBFT中，为了更好地支持Libra生态系统的目标，我们以多种方式扩展和调整了核心HotStuff协议和实现。重要的是，我们重新设定了安全条件，并提供了安全、活跃度和乐观响应的扩展证明。我们还实现了一些额外的特性。首先，我们通过让验证器集体对块的结果状态而不仅仅是交易序列进行签名，使协议更能抵抗非确定性错误。 还允许客户端使用法定人数证书对读取数据库进行身份验证。 第二，我们设计了一个起搏器，它发出明确的超时，验证器依赖于其中的一个法定人数移动到下一轮-不需要同步时钟。 第三，我们打算设计一个不可预测的领导者选举机制，其中一轮的领导者由最新提交的块的提议者使用可验证的随机函数 VRF 确定。 这种机制限制了攻击者针对领导者发起有效拒绝服务攻击的时间窗口。 第四，我们使用聚合签名来保留签署仲裁证书的验证者的身份。 这使我们能够为有助于仲裁证书的验证人提供激励。 聚合签名也不需要复杂的 阈值密钥设置.
共识组件主要在 Actor 程序模块中实现 — 它不同的子组件( 使用tokio 框架用作任务运行)之间使用消息进行通信。actor模型的主要例外是(因为它是被几个子组件并行访问的)是共识数据结构 BlockStore ，它管理块、执行、仲裁证书和其他共享数据结构。共识组件中的主要子组件有： TODO
- TxnManager 是内存池组件的接口，支持拉取交易以及移除已提交的交易。 提议者使用来自内存池中的按需拉取交易来形成提议块。
- StateComputer 是访问执行组件的接口。 它可以执行块，提交块，并可以同步状态。
- BlockStore 维护提议块树，块执行，投票，仲裁证书和持久存储。 它负责维护这些数据结构组合的一致性，并且可以被其他子组件同时访问。
- EventProcessor 负责处理各个事件 (如, process_new_round, process_proposal, process_vote). 它为每个事件类型暴露异步处理函数和驱动协议。
- Pacemaker 负责共识协议的活跃性。 它由于超时证书或仲裁证书而改变轮次，并在它是当前轮次的提议者时提议块。
- SafetyRules 负责共识协议的安全。 它处理仲裁证书和账本信息以了解新的提交，并保证遵循两个投票规则 — 即使在重启的情况下（因为所有安全数据都持久保存到本地存储）。
所有共识消息都由其创建者签名，并由其接收者验证。消息验证发生在离网络层最近的地方，以避免无效或不必要的数据进入共识协议。
consensus
├── src
│ └── chained_bft # Implementation of the LibraBFT protocol
│ ├── block_storage # In-memory storage of blocks and related data structures
│ ├── consensus_types # Consensus data types (i.e. quorum certificates)
│ ├── consensusdb # Database interaction to persist consensus data for safety and liveness
│ ├── liveness # Pacemaker, proposer, and other liveness related code
│ ├── safety # Safety (voting) rules
│ └── test_utils # Mock implementations that are used for testing only
└── state_synchronizer # Synchronization between validators to catch up on committed state