> ## 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.

# 共识事件

如[此处](/zh/monad-arch/consensus/asynchronous-execution)所述，Monad 的共识和执行服务是解耦的，执行相对于共识是异步的：两者不必步调一致，可以处理不同的区块。此外，执行还可以对共识结果尚未确定的区块进行[推测执行](/zh/monad-arch/consensus/asynchronous-execution#speculative-execution)。

执行事件是在执行期间直接从 EVM 报告的"追踪"信息，因此它们以\_推测性\_方式报告实时数据：这些事件数据可能与最终未被确认的区块相关。

以推测性方式处理实时数据在[此页面](/zh/monad-arch/realtime-data/spec-realtime)中有详细讨论。文档该部分的"要点"是：如果您消费推测性实时数据，则需要了解[区块提交状态](/zh/monad-arch/consensus/block-states)以及您使用的实时数据协议如何传达区块状态的变化。

例如，对于 Monad WebSocket 扩展 feed，[本节](/zh/reference/json-rpc/overview#speculative-subscription-behavior)解释了如何为 `monadNewHeads` 订阅公布区块 ID 和提交状态。本文档页面解释如何通过执行事件实现这一点。

## 区块标签

如[此处](/zh/monad-arch/realtime-data/spec-realtime#block-numbers-and-block-ids)所述，在确认之前，必须通过唯一 ID 来标识区块。即便如此，通常还是有必要知道提议的区块编号，即使我们还不知道该区块是否会以该编号被提交。下面的结构 —— 称为"区块标签" —— 作为字段出现在几种执行事件负载类型中，用于同时传达区块 ID 和（提议的）区块编号。

```
struct monad_exec_block_tag
{
    monad_c_bytes32 id;    ///< Monad consensus unique ID for block
    uint64_t block_number; ///< Proposal is to become this block
};
```

## 四个共识事件

四种[区块提交状态](/zh/monad-arch/consensus/block-states)对应四种执行事件类型。这些类型的事件被发布，用于公告某个特定区块正在进入新的提交状态。

### 第一个共识事件：**`BLOCK_START`**（*proposed* 状态）

```c theme={null}
/// Event recorded at the start of block execution
struct monad_exec_block_start
{
    struct monad_exec_block_tag
        block_tag;                      ///< Execution is for this block
    uint64_t block_round;               ///< Round when block was proposed
    uint64_t epoch;                     ///< Epoch when block was proposed
    monad_c_bytes32 parent_eth_hash;    ///< Hash of Ethereum parent block
    monad_c_uint256_ne chain_id;        ///< Block chain we're associated with
    struct monad_c_eth_block_exec_input
        exec_input;                     ///< Ethereum execution inputs
};
```

EVM 记录的第一个事件是 `BLOCK_START` 事件，其事件负载包含一个 `block_tag` 字段，用于引入该区块的唯一 ID 以及一旦确认后它最终将拥有的区块编号。

几乎所有执行事件（交易日志、call frame、收据等）都发生在 `BLOCK_START` 和 `BLOCK_END` 事件之间。在当前实现中，区块执行从不流水线化，因此 `BLOCK_START` 和 `BLOCK_END` 之间的所有事件都属于单个区块，在当前区块结束之前不会再有另一个 `BLOCK_START`。

与列表中的其他事件不同，`BLOCK_START` 既是"共识事件"（意味着相关区块处于 proposed 状态），也是"EVM 事件"，因为关于该区块的执行信息正在向您提供。

列表中的其他事件不同。它们是"纯粹"的共识事件：它们告诉您在您已经看到区块的所有 EVM 事件之后，共识算法中提议区块发生了什么。

要了解此状态的含义，请参见[此处](/zh/monad-arch/realtime-data/spec-realtime#first-commit-state-proposed)。

<Note>
  没有理由说区块\_必须\_以 proposed 状态开始。如果执行落后于共识，则可能一个区块在共识算法中已经推进到更晚的状态。例如，假设共识已在某个区块上工作了一段时间，而当执行最终看到它时，共识可能已知它已经进展到 voted。

  然而在当前实现中，执行不会知道这一点。它隐式地将其执行的一切视为仅处于 proposed。仅当执行未落后时这才严格为真。
</Note>

### 第二个共识事件：**`BLOCK_QC`**（*voted* 状态）

```c theme={null}
/// Event recorded when a proposed block obtains a quorum certificate
struct monad_exec_block_qc
{
    struct monad_exec_block_tag
        block_tag;              ///< QC for proposal with this block
    uint64_t round;             ///< Round of proposal vote
    uint64_t epoch;             ///< Epoch of proposal vote
};
```

当带有给定标签的区块被投票时，会发布此类型的事件以公告此事。要了解看到此事件的全部含义，请参见[此处](/zh/monad-arch/realtime-data/spec-realtime#second-commit-state-voted)。

### 第三个共识事件：**`BLOCK_FINALIZED`**

```c theme={null}
/// Event recorded when consensus finalizes a block
typedef struct monad_exec_block_tag monad_exec_block_finalized;
```

finalized 事件负载不包含任何不在区块标签中的信息，因此负载就是被确认区块的标签。要了解看到此事件的全部含义，请参见[此处](/zh/monad-arch/realtime-data/spec-realtime#third-commit-state-finalized)。

### 第四个共识事件：**`BLOCK_VERIFIED`**

```c theme={null}
/// Event recorded when consensus verifies the state root of a finalized block
struct monad_exec_block_verified
{
    uint64_t block_number; ///< Number of verified block
};
```

共识算法为每个区块产生的最后一个事件称为 `BLOCK_VERIFIED`。这次，仅通过区块编号来标识区块就足够了。由于已验证的区块已经确认，它们是规范区块链的一部分，除非发生硬分叉否则无法回滚。因此，我们不再需要区块标签。

要了解看到此事件的全部含义，请参见[此处](/zh/monad-arch/realtime-data/spec-realtime#fourth-commit-state-verified)。