译自：官方文档翻译 https://developers.libra.org/docs/crates/consensus。 本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。
Libra 中文网同步翻译 http://www.libra-cn.top/document/info/?id=17
概述
共识协议通过多个验证器来创建逻辑模型，这个模型实质是个数据库。共识协议下被提交的交易首先会不断地复制到不同的验证器，然后执行交易，对于交易顺序和执行结果进行检查，看是否能根据事先约定好的达成一致。于是，在状态机复制副本之后，只要给出一个版本号，即可在所有的验证器中维护着同一个数据库。HotStuff 共识协议是在拜占庭容错（Byzantine fault，简称 BFT）基础上扩展的变体，而 LibraBFT 则是在 HotStuff 基础之上又进行调整和扩展的新变体。在 Dwork、Lynch 和 Stockmeyer（DLS）的论文《Consensus in the Presence of Partial Synchrony》中，介绍了在部分同步模型中也提供安全性（所有诚实的验证者会确认提案和执行）和存活性（可持续产生提案），这个共识在新协议 PBFT（如 Tendermint）中也使用了。在本文档中，我们从高层次来描述 LibraBFT 协议，并讨论代码的组成。请参阅这篇论文以了解 LibraBFT 如何配合 Libra 区块链。有关 LibraBFT 的规范和证明的详细信息，可以阅读完整的技术论文。
即使存在着拜占庭式故障，也必须在验证者之间达成一致的数据库状态，拜占庭故障模型允许一些验证器在没有约束的情况下随意偏离协议，不过依然会有计算限制（假设密码学是无法破解）。拜占庭故障最坏的情况是其中验证者串通并且试图恶意破坏系统一致性。拜占庭容错的共识协议，则能容忍由恶意或被黑客控制的验证器引起的问题，缓解相关的硬件和软件故障。
LibraBFT 假设，有一组 3f + 1 的投票分布在诚实的或者拜占庭式（恶意）的验证器中。不超过 f 票是由拜占庭验证器控制的话，LibraBFT 仍是安全的，即意味着至少有 2f+1 票是诚实的，能够阻止诸如双花（Double Spends ）和分叉（Forks）的攻击。只要存在全局稳定时间（GST），LibraBFT 就会保持在线，客户端可提交交易，所有消息都会在最大网络延迟 Δ 内于诚实验证器的范围内得到传递（在 DLS 论文中有介绍）。除了传统的保障外，LibraBFT 在验证器崩溃和重启时仍保持安全——即使所有验证器同时重启。
LibraBFT 简介
LibraBFT 协议中，客户端发送交易，验证器接收该交易，并通过内存池协议将其共享给其他验证器。接着 LibraBFT 协议处理一系列的回合（rounds）。每一回合之中，那个验证器就扮演领导者的角色，让包含多个交易的那个区块，扩展成为一系列多个已通过认证的区块（下文会介绍仲裁证书 Quorum Certificate），我们称为“提案（Proposes）”，这时区块就会包含了之前完整的交易历史。某个验证器接收到了已提案的区块，为了确定是否通过该区块，验证器会根据投票规则来确定是否投票。虽是简单的规则，但也足够保障好 LibraBFT 的安全性。并且它们的实现可以被清晰地分离和审计。如果验证器打算为该区块投票，它会以推测方式（speculatively）执行区块的交易，而不会产生外部影响。区块的执行结果，如果与数据库认证器（Authenticator）计算结果相一致的话，验证器就会把已投票的区块以及数据库认证器一起发送到领导者中。领导者收集这些投票以形成仲裁证书（Quorum Certificate），为该区块提供 ≥2f+ 1投票的证据，并把仲裁证书广播给所有的验证器。
当连续三次满足了提交规则（Commit Rules），区块将会得到确认提交，即如果这个区块（假设为 k 回合的区块）具有仲裁证书证明且在其后的 2 个回合，即 k+1 和 k+2 也具有仲裁证书的话，那么第 k 轮的区块则得到确认。提交规则最终允许诚实的验证器能够提交区块。LibraBFT 保证所有诚实的验证器最终都会提交区块（并且延长之前链接的块序列）。一旦区块被提交确认，交易的结果状态就会永久存储，形成一个复制的数据库。
HotStuff 之优点
有几种基于 BFT 共识协议，我们都进行了多方面的评估，包括性能、可靠性、安全性、健壮性、简易性以及验证器的开销等等。我们初期的目标是至少支持一百个验证器，并逐渐可以支持到 500 到 1000 个验证器。之所以选择 HotStuff 协议，原因是：1、比较简单和支持模块化；2、易于集成共识；3、在早期实验中性能表现良好。
HotStuff 协议大体分为两部分，安全模块（关于投票和提交规则）和存活模块（Liveness，即“起搏器 Pacemaker”）。实质上那是一种解耦，划分了开发和实验两套可独立运行的环境，那样就可以同时进行。由于投票和提交规则比较简单，使得协议的安全性实现起来也比较简单和易于验证。领导协议下的非确定性执行，通常会产生分叉的问题，有鉴于此，我们很容易想到用集成执行来作为共识机制的一部分，那样就避免了产生分叉的问题。最后我们的早期原型也确认了 HotStuff 能满足较高的吞吐量和较低的交易延迟（独立的检测）、因为性能不好和电力消耗实在太大，我们没有考虑如比特币基于工作量证明（proof-of-work）那样的算法。
扩展和修改 HotStuff
为了更好地支持 Libra 生态系统，我们在 HotStuff 协议的基础上多次进行修改调整和扩展。其中关键的是，我们重新定义了安全条件，并提供了安全、存活度和更高响应度的扩展证明。我们还实现了一些附加功能：
- 首先，让验证器对区块的结果状态（不仅仅是交易的序列）进行集体签名，从而得使协议更能抵抗非确定性错误。另外当读取的数据库时候，还允许客户端使用仲裁证书来验证。
- 其次，我们提出起搏器（Pacemaker）的概念，通过它来触发精确的超时，验证器依靠仲裁人数来进入下一轮——不需要同步时钟。
- 第三，我们打算设计一个不可预测的领导者选举机制，当前轮次的领导者由最后提交区块的提议者通过可验证的随机函数 VRF 来确定。这种机制可以限制攻击者针对领导者发起的 DDos 攻击。
- 第四，我们使用聚合签名（Aggregate Signatures）来保留验证者的身份，验证者负责签署仲裁证书。目的是可以让验证者获得报酬来作为激励。聚合签名也不需要太复杂的密钥阈值设置。
实现细节
共识组件基本上依照 Actor 编程模型来实现，tokio 框架作为任务的运行时，两个子组件之间透过消息来通讯。不同的子组件并行访问 actor 模型，这是 actor 模型的不同之处。另外，共识机制实现的数据结构，我们称为 BlockStore，其作用是管理区块、执行、仲裁证书（Quorum Certificates）及其他共享的数据结构。共识组件中的主要子组件是：
- TxnManager 内存池组件的接口，该接口支持交易的拉取以及移除。提议者使用来自内存池中的按需拉取交易来形成提议块。
- StateComputer 访问执行组件的接口。它可以执行区块、提交区块和同步状态。
- StateComputer 维护着提议块树，块执行，投票，仲裁证书和持久存储。它负责维护这些数据结构组合的一致性，并且可以由其他子组件同时访问。
- EventProcessor 负责处理各个事件（例如 process_new_round, process_proposal, process_vote）。它公开了每个事件的异步处理函数和驱动着协议。
- Pacemaker 起搏器，负责共识协议的活跃性。有时候认证会超时，或者仲裁认证出问题，或者提议者阻止了提议，那么 Pacemaker 就会改变轮次。
- SafetyRules 负责共识协议的安全性。它处理仲裁证书和分类信息以了解新的提交，并保证遵循两个投票规则——即使在重启的情况下（因为所有安全数据都持久化保存到本地存储）。
创建者对共识消息进行签名，然后接受者负责验证。为了避免无效或者不需要的数据进入共识协议，我们在网络层就进行了消息验证。
所有共识消息都由其创建者签名，并由其接收者验证。消息验证发生在离网络层最近的地方，以避免无效或不必要的数据进入协商一致协议。
目录结构
consensus
├── src
│ └── chained_bft # LibraBFT 协议的实现
│ ├── block_storage # 区块内存存储以及相关数据结构
│ ├── consensus_types # 共识机制的数据类型（例如 Quorum 证书）
│ ├── consensusdb # 保持共识数据的安全性和活跃性的数据库交互
│ ├── liveness # 起搏器（Pacemarker），提议者（Proposer）和其他与活动相关的代码
│ ├── safety # 安全（投票）规则
│ └── test_utils # 测试用的假数据
└── state_synchronizer # 捕捉提交状态时，不同验证器之间的同步
