Skip to main content
在 MonadBFT 中,区块会经历三个状态。 此外,由于异步执行,区块的最终确认是一件与状态根验证相分离(且更早)的事情。由于这种架构,每个 Monad 区块可以视为处于四种状态之一。 请注意,区块的状态是从特定观察者(任何其他验证者或全节点)的角度而言的。当新消息到达时,它们使该观察者能够在本地推进区块的状态。 尽管状态是在本地定义的,但它们对应于网络其余部分最终将收敛到与该状态一致的结果的保证。 例如,如果一个节点将某个区块标记为 Finalized,那是因为该节点已收到消息,携带了足够的证据表明网络其余部分最终将在该区块高度确认该区块。

​
状态

Monad 区块处于以下四种状态之一:
  1. Proposed
  2. Voted
  3. Finalized
  4. Verified

基于最新提议区块 N 对历史区块的分类。

​
Proposed

该区块已由领导者提议但尚未被投票。 注意:如果执行没有落后于共识,节点可以对提议的区块进行推测性执行。

​
Voted

我们已获得该区块的法定人数证书 (QC), 表明它已获得超级多数验证者的肯定投票。(通常, 这是由于收到了该区块的子区块。) 在 MonadBFT 中,Voted 意味着该区块可以被推测性最终确认。

​
Finalized

我们已获得该区块的 QC-squared(即,我们拥有一个QC,它属于一个包含对原始区块 QC 的区块)。 这作为超级多数验证者已批准原始区块 QC 存在和有效性的证据。 由于 MonadBFT 的共识规则,这意味着该区块已被最终确认。

​
Verified

一个包含延迟默克尔根的区块已被最终确认,这意味着该区块的执行输出已被超级多数验证节点一致同意。 具体来说,最新的已验证区块将是 latest_finalized_block - execution_delay。

​
映射到 JSON-RPC 承诺级别

Monad 使用与以太坊不同的共识算法,但与 Geth 客户端定义的 JSON-RPC 编程接口 API 兼容。 Geth 通过 JSON-RPC 使用标签 "latest"、"safe" 和 "finalized" 公开传达关于区块的共识信息。以下是它们如何映射到 Monad 的区块状态:
Geth 认可另外两个区块标签,"earliest" 和 "pending"。这些不是共识状态。前者是创世区块的同义词,而后者由于 Monad 的交易传播机制不同而没有意义。

​
实时数据与区块状态

Monad 提供了几个实时区块链数据源。 为了提供尽可能快的服务,一些数据源会在您的节点得知最新区块时,立即报告该区块的区块链数据。 如上所示,您的节点所知的 最新 区块——处于 Proposed 状态的最新区块——可能是 推测性执行 的。因此,您可能会看到最终没有成为 Monad 区块链一部分的区块的数据,尽管这种情况非常罕见。 本页深入介绍了区块状态推进的工作原理,以便您在消费实时数据时了解推测性执行和实时数据报告如何协同工作。 要查看这与真实数据源之间关系的具体示例,请参阅 WebSocket 订阅 中关于 monadNewHeads 的部分,它是Geth newHeads 数据源的扩展,包含了跟踪每个区块在共识中进展的额外数据。