> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monad.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# 区块状态

> 区块生命周期

在 [MonadBFT](/zh/monad-arch/consensus/monad-bft) 中,区块会经历[三个状态](/zh/monad-arch/consensus/monad-bft#block-states-due-to-monadbft)。
此外,由于[异步执行](/zh/monad-arch/consensus/asynchronous-execution),区块的最终确认是一件与状态根验证相分离(且更早)的事情。由于这种架构,每个
Monad 区块可以视为处于四种状态之一。

请注意,区块的状态是从特定观察者(任何其他验证者或全节点)的角度而言的。当新消息到达时,它们使该观察者能够在本地推进区块的状态。
尽管状态是在本地定义的,但它们对应于网络其余部分最终将收敛到与该状态一致的结果的保证。

例如,如果一个节点将某个区块标记为 `Finalized`,那是因为该节点已收到消息,携带了足够的证据表明网络其余部分最终将在该区块高度确认该区块。

## 状态

Monad 区块处于以下四种状态之一:

1. `Proposed`
2. `Voted`
3. `Finalized`
4. `Verified`

<img src="https://mintcdn.com/monadfoundation-40611fb6/5Mt9_Scj9fq4fC68/static/img/monad-arch/consensus/asynchronous-execution/block_states.png?fit=max&auto=format&n=5Mt9_Scj9fq4fC68&q=85&s=133a4d6dad54a18a4dce5c2b5e081b28" width="400" style={{marginLeft: "auto", marginRight: "auto"}} data-path="static/img/monad-arch/consensus/asynchronous-execution/block_states.png" />

<p style={{textAlign: "center", fontSize: "0.875rem", opacity: 0.65, marginTop: "0.5rem", fontStyle: "italic"}}>基于最新<strong>提议</strong>区块 N 对历史区块的分类。</p>

### Proposed

该区块已由领导者提议但尚未被投票。

注意:如果执行没有落后于共识,节点可以对提议的区块进行[推测性执行](/zh/monad-arch/consensus/asynchronous-execution#speculative-execution)。

### Voted

我们已获得该区块的[法定人数证书 (QC)](/zh/monad-arch/consensus/monad-bft#quorum-certificate-qc),
表明它已获得超级多数验证者的肯定投票。(通常,
这是由于收到了该区块的子区块。)

在 MonadBFT 中,`Voted` 意味着该区块可以被[推测性最终确认](/zh/monad-arch/consensus/monad-bft#speculative-finality)。

### Finalized

我们已获得该区块的 QC-squared(即,我们拥有一个[QC](/zh/monad-arch/consensus/monad-bft#quorum-certificate-qc),它属于一个包含对原始区块 QC 的区块)。
这作为超级多数验证者已批准原始区块 QC 存在和有效性的证据。

由于 MonadBFT 的共识规则,这意味着该区块已被最终确认。

### Verified

一个包含[延迟默克尔根](/zh/monad-arch/consensus/asynchronous-execution#delayed-merkle-root)的区块已被最终确认,这意味着该区块的执行输出已被超级多数验证节点一致同意。

具体来说,最新的已验证区块将是
`latest_finalized_block - execution_delay`。

## 映射到 JSON-RPC 承诺级别

Monad 使用与以太坊不同的共识算法,但与
[Geth 客户端](https://geth.ethereum.org/docs/interacting-with-geth/rpc)定义的
[JSON-RPC](/zh/reference/json-rpc/overview) 编程接口 API 兼容。

Geth 通过 JSON-RPC 使用标签
`"latest"`、`"safe"` 和 `"finalized"` 公开传达关于区块的共识信息。以下是它们如何映射到 Monad 的区块状态:

| Geth RPC 状态   | ...对应的 Monad 区块状态 | 原因                                                                     |
| ------------- | ----------------- | ---------------------------------------------------------------------- |
| `"latest"`    | `Proposed`        | 两种状态都指最近观察到的区块,在共识最终确认结果之前                                             |
| `"safe"`      | `Voted`           | 在以太坊的 LMD-GHOST 算法中,"safe" 的含义类似于"极不可能被回滚,但理论上仍有可能";Monad 的 voted 含义类似 |
| `"finalized"` | `Finalized`       | 这在两条链上含义相同:除非硬分叉,否则不可回滚                                                |

<Note>
  Geth 认可另外两个区块标签,`"earliest"` 和 `"pending"`。这些不是共识状态。前者是创世区块的同义词,而后者由于 Monad 的[交易传播机制](/zh/monad-arch/consensus/local-mempool)不同而没有意义。
</Note>

## 实时数据与区块状态

Monad 提供了几个[实时区块链数据源](/zh/monad-arch/realtime-data/data-sources)。
为了提供尽可能快的服务,一些数据源会在您的节点得知最新区块时,立即报告该区块的区块链数据。

如上所示,您的节点所知的 *最新* 区块——处于 `Proposed` 状态的最新区块——可能是 *推测性执行* 的。因此,您可能会看到最终没有成为 Monad 区块链一部分的区块的数据,尽管这种情况非常罕见。
[本页](/zh/monad-arch/realtime-data/spec-realtime)深入介绍了区块状态推进的工作原理,以便您在消费实时数据时了解推测性执行和实时数据报告如何协同工作。

要查看这与真实数据源之间关系的具体示例,请参阅 [WebSocket 订阅](/zh/reference/json-rpc/overview#websocket-subscriptions) 中关于 [`monadNewHeads`](/zh/reference/json-rpc/overview#speculative-subscription-behavior) 的部分,它是[Geth `newHeads` 数据源](https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub)的扩展,包含了跟踪每个区块在共识中进展的额外数据。