​
CometBFT 规范

这是 CometBFT 的一份 Markdown 规范。 它定义了基础数据结构、这些结构如何被验证， 以及它们如何通过网络进行通信。 如果你发现该规范与代码之间存在差异， 且 GitHub 上没有与之关联的 issue 或 pull request， 请通过我们的漏洞赏金计划提交！

​
目录

​
数据结构

​
共识协议

​
P2P 与网络协议

  • 基础 P2P 层：在经过身份认证和加密的 TCP 连接上复用各个协议（“reactor”）
  • 对等节点交换（PEX）：传播已知的对等节点地址，使节点能够彼此发现
  • 区块同步：传播区块，使节点能够快速追赶进度
  • 共识：传播投票和区块分片，使新区块能够被提交
  • 内存池：传播交易，使其被打包进区块
  • 证据：发送无效证据将导致该对等节点被停止

​
RPC

  • RPC 规范：CometBFT 远程过程调用接口的规范。

​
软件

  • ABCI：关于应用程序与共识引擎通过 ABCI 进行交互的详细说明
  • 预写日志：关于共识引擎如何保存数据并从崩溃故障中恢复的详细说明

​
概述

CometBFT 通过由哈希链接起来的交易批次，提供拜占庭容错的状态机复制。 这类交易批次称为“区块”。 因此，CometBFT 定义了一条“区块链”。 CometBFT 中的每个区块都有一个唯一索引，即其高度。 区块链中的高度是单调递增的。 每个区块都由一组已知的、带权重的验证者提交。 该验证者集合中的成员及其权重可能会随时间变化。 只要验证者集合总权重中恶意或故障的部分少于 1/3， CometBFT 就能保证区块链的安全性与活性。 在 CometBFT 中，一次提交是由当前验证者集合总权重中超过 2/3 的成员所签名的一组消息。 验证者轮流提出区块并对其投票。 一旦收到足够多的投票，该区块就会被视为已提交。 这些投票会作为前一个区块已被提交的证明，被包含在_下一个_区块中。 它们不能被包含在当前区块中，因为当前区块在那时已经创建完成。 一旦区块被提交，它就可以针对某个应用程序执行。 应用程序会为区块中的每笔交易返回结果。 应用程序还可以返回对验证者集合的变更， 以及其最新状态的密码学摘要。 CometBFT 的设计目标之一，是能够高效地验证并认证区块链的最新状态。 为实现这一点，它会在区块“头部”中嵌入对某些信息的密码学承诺。 这些信息包括区块内容（例如交易）、 提交该区块的验证者集合，以及应用程序返回的各种结果。 不过需要注意，区块执行只会在区块提交_之后_发生。 因此，应用程序结果只能被包含在_下一个_区块中。 还需要注意，像交易结果和验证者集合这类信息从不会直接包含在区块中， 其中只包含它们的密码学摘要（Merkle 根）。 因此，验证一个区块需要额外的数据结构来存储这些信息。 我们将其称为 State。 区块验证还需要访问前一个区块。

​
CometBFT Spec

This is a markdown specification of CometBFT. It defines the base data structures, how they are validated, and how they are communicated over the network. If you find discrepancies between the spec and the code that do not have an associated issue or pull request on github, please submit them to our bug bounty!

​
Contents

​
Data Structures

​
Consensus Protocol

​
P2P and Network Protocols

  • The Base P2P Layer: multiplex the protocols (“reactors”) on authenticated and encrypted TCP connections
  • Peer Exchange (PEX): gossip known peer addresses so peers can find each other
  • Block Sync: gossip blocks so peers can catch up quickly
  • Consensus: gossip votes and block parts so new blocks can be committed
  • Mempool: gossip transactions so they get included in blocks
  • Evidence: sending invalid evidence will stop the peer

​
RPC

  • RPC SPEC: Specification of the CometBFT remote procedure call interface.

​
Software

  • ABCI: Details about interactions between the application and consensus engine over ABCI
  • Write-Ahead Log: Details about how the consensus engine preserves data and recovers from crash failures

​
Overview

CometBFT provides Byzantine Fault Tolerant State Machine Replication using hash-linked batches of transactions. Such transaction batches are called “blocks”. Hence, CometBFT defines a “blockchain”. Each block in CometBFT has a unique index - its Height. Heights in the blockchain are monotonic. Each block is committed by a known set of weighted Validators. Membership and weighting within this validator set may change over time. CometBFT guarantees the safety and liveness of the blockchain as long as less than 1/3 of the total weight of the Validator set is malicious or faulty. A commit in CometBFT is a set of signed messages from more than 2/3 of the total weight of the current Validator set. Validators take turns proposing blocks and voting on them. Once enough votes are received, the block is considered committed. These votes are included in the next block as proof that the previous block was committed - they cannot be included in the current block, as that block has already been created. Once a block is committed, it can be executed against an application. The application returns results for each of the transactions in the block. The application can also return changes to be made to the validator set, as well as a cryptographic digest of its latest state. CometBFT is designed to enable efficient verification and authentication of the latest state of the blockchain. To achieve this, it embeds cryptographic commitments to certain information in the block “header”. This information includes the contents of the block (eg. the transactions), the validator set committing the block, as well as the various results returned by the application. Note, however, that block execution only occurs after a block is committed. Thus, application results can only be included in the next block. Also note that information like the transaction results and the validator set are never directly included in the block - only their cryptographic digests (Merkle roots) are. Hence, verification of a block requires a separate data structure to store this information. We call this the State. Block verification also requires access to the previous block.