Lib.rs

id: consensus title: Consensus custom_edit_url: https://github.com/aptos-labs/aptos-core/edit/main/consensus/README.md

共识组件支持使用AptosBFT共识协议进行状态机复制。

概述

共识协议允许一组验证者创建单个数据库的逻辑外观。共识协议在验证者之间复制提交的交易，对当前数据库执行潜在的交易，然后就交易的顺序和结果的执行达成具有约束力的承诺。因此，所有验证者都可以根据《状态机复制范式》维护一个给定版本的相同数据库。Aptos 协议使用 HotStuff 共识协议 的变体，这是一种最近的拜占庭容错 (BFT) 共识协议，称为 AptosBFT。它提供了在论文《DLS》中定义的局部同步模型中的安全性（所有诚实的验证者都同意提交和执行）和活跃性（持续产生提交）。此外，它还提供了与Castro和Liskov在论文《"实用拜占庭容错" (PBFT)》中提到的以及更新的协议，如Tendermint等。在本文档中，我们介绍了AptosBFT协议的高级描述，并讨论了代码的组织方式。有关AptosBFT规范和证明的详细信息，请参阅完整的技术报告。

即使在存在拜占庭错误的情况下，验证者之间也必须就数据库状态达成一致。拜占庭故障模型允许一些验证者不受约束地任意偏离协议，除了计算上有限制（因此不能破坏密码学假设）。拜占庭故障是最坏的情况错误，其中验证者串通并恶意行为以试图破坏系统行为。能够容忍由恶意或被黑客攻击的验证者引起的拜占庭错误的共识协议也可以减轻任意的硬件和软件故障。

AptosBFT假定一组3f+1票分散在可能诚实或拜占庭的验证者集。当最多f票受拜占庭验证者控制时，AptosBFT保持安全性，防止双重支出和分叉攻击，这还意味着至少有2f+1票是诚实的。只要存在全局稳定时间（GST），AptosBFT就保持活跃，即使在验证者崩溃并重新启动的情况下，它也可以提交来自客户端的交易，在此之后，所有诚实验证者之间的消息都在最大网络延迟$\Delta$内被传递给其他诚实验证者（这是在《DLS》中引入的局部同步模型）。除了传统的保证外，AptosBFT还保持了验证者在崩溃和重新启动时的安全性——即使所有验证者同时重新启动。

AptosBFT概述

在AptosBFT中，验证者从客户端接收交易并通过共享内存池协议将它们与其他验证者共享。然后AptosBFT协议按一系列回合进行。在每一轮中，一个验证者扮演领导者的角色，提出一个交易块以扩展一个经过认证的块序列（见下文所述的法定证书），其中包含完整的先前交易历史。验证者接收提议的块并检查其投票规则，以确定是否应该对该块进行认证投票。这些简单的规则确保了AptosBFT的安全性——它们的实现可以干净地分离和审计。如果验证者打算对该块进行投票，它将投机性地执行该块的交易，而不产生外部影响。这导致计算从执行该块得到的数据库认证器。然后验证者将签署的投票和数据库认证器发送给领导者。领导者收集这些投票以形成法定证书，该证书提供了至少2f+1票对该块的证据，并将法定证书广播给所有验证者。

当满足连续3链提交规则时，区块会被提交。在第k轮的区块如果拥有法定人数证书，并且在第k+1轮和k+2轮被两个更多区块和法定人数证书确认，则该区块在第k轮被提交。提交规则最终允许诚实验证者提交一个区块。AptosBFT保证所有诚实验证者最终会提交该区块（以及从它链接的后续序列的区块）。一旦一系列区块被提交，执行这些交易产生状态就可以持久化，形成一个复制数据库。

HotStuff范式的优势

我们评估了几个基于BFT的协议，根据性能、可靠性、安全性、实现稳健性以及验证者的操作开销等维度。我们的目标是选择一个协议，最初至少支持100个验证者，并且能够随着时间的发展支持500-1000个验证者。我们选择HotStuff协议作为AptosBFT的基础有三个原因：（i）简单性和模块化；（ii）能够轻松地将共识与执行集成；（iii）早期实验中显示出的有希望的性能。

HotStuff协议分解为安全（投票和提交规则）和活性（round_state）模块。这种解耦允许我们并行开发和实验不同的模块。由于投票和提交规则简单，协议的安全性容易实现和验证。将执行集成到共识中作为一部分，可以避免由基于领导者的协议中非确定性执行引起的分叉问题。最后，我们的早期原型在HotStuff中独立测量的高吞吐量和低事务延迟得到了证实。我们没有考虑基于工作量证明的协议，如Bitcoin，因为它们性能差且能耗（以及环境）成本高。

HotStuff的扩展和修改

在AptosBFT中，为了更好地支持生态系统的目标，我们在几个方面扩展和适应了核心HotStuff协议和实现。重要的是，我们重新定义了安全性条件，并提供了扩展的安全性、活性和乐观响应的证明。我们还实现了一系列额外的功能。首先，我们通过让验证者共同签署区块的结果而不是仅仅签署事务序列，使协议更能抵抗非确定性错误。这也允许客户端使用法定人数证书来验证数据库的读取。其次，我们设计了一个round_state，它会发出显式的超时，验证者依靠这些超时中的多数来进入下一轮——而无需同步时钟。第三，我们打算设计一个不可预测的领导者选举机制，其中该轮的领导者由最新提交的区块的提议者使用可验证随机函数VRF确定。这种机制限制了对手可以对领导者发起有效拒绝服务攻击的时间窗口。第四，我们使用聚合签名来保护签署法定人数证书的验证者身份。这允许我们向对法定人数证书做出贡献的验证者提供激励。聚合签名也不需要复杂的门限密钥设置。

实现细节

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

• 交易管理器是连接到内存池组件的接口，支持拉取交易以及移除已提交的交易。提议者通过从内存池按需拉取交易来形成提议块。
• 状态计算机是访问执行组件的接口。它可以执行区块、提交区块，并可以同步状态。
• 区块存储维护提议块的树结构、区块执行、投票、法定多数证书和持久存储。它负责维护这些数据结构的组合一致性，并可由其他子组件并发访问。
• 轮次管理器负责处理单个事件（例如，处理新轮次、处理提议、处理投票）。它暴露了每个事件类型的异步处理函数并驱动协议。
• 轮次状态负责共识协议的活跃性。它因超时证书或法定多数证书而改变轮次，并在当前轮次为提议者时提出区块。
• 安全规则负责共识协议的安全性。它处理法定多数证书和LedgerInfo以了解新的提交，并确保遵循两个投票规则——即使在重启的情况下（因为所有安全数据都持久化到本地存储）。

所有共识消息都由其创建者签名并由其接收者验证。消息验证发生在网络层附近，以避免无效或不必要的数据进入共识协议。

这个模块是如何组织的？

consensus
├── src
│   ├── block_storage          # In-memory storage of blocks and related data structures
│   ├── consensusdb            # Database interaction to persist consensus data for safety and liveness
│   ├── liveness               # RoundState, proposer, and other liveness related code
│   └── test_utils             # Mock implementations that are used for testing only
├── consensus-types            # Consensus data types (i.e. quorum certificates)
└── safety-rules               # Safety (voting) rules