Skip to main content
此处所述,Monad 的共识和执行服务是解耦的,执行相对于共识是异步的:两者不必步调一致,可以处理不同的区块。此外,执行还可以对共识结果尚未确定的区块进行推测执行 执行事件是在执行期间直接从 EVM 报告的”追踪”信息,因此它们以_推测性_方式报告实时数据:这些事件数据可能与最终未被确认的区块相关。 以推测性方式处理实时数据在此页面中有详细讨论。文档该部分的”要点”是:如果您消费推测性实时数据,则需要了解区块提交状态以及您使用的实时数据协议如何传达区块状态的变化。 例如,对于 Monad WebSocket 扩展 feed,本节解释了如何为 monadNewHeads 订阅公布区块 ID 和提交状态。本文档页面解释如何通过执行事件实现这一点。

区块标签

此处所述,在确认之前,必须通过唯一 ID 来标识区块。即便如此,通常还是有必要知道提议的区块编号,即使我们还不知道该区块是否会以该编号被提交。下面的结构 —— 称为”区块标签” —— 作为字段出现在几种执行事件负载类型中,用于同时传达区块 ID 和(提议的)区块编号。

四个共识事件

四种区块提交状态对应四种执行事件类型。这些类型的事件被发布,用于公告某个特定区块正在进入新的提交状态。

第一个共识事件:BLOCK_STARTproposed 状态)

EVM 记录的第一个事件是 BLOCK_START 事件,其事件负载包含一个 block_tag 字段,用于引入该区块的唯一 ID 以及一旦确认后它最终将拥有的区块编号。 几乎所有执行事件(交易日志、call frame、收据等)都发生在 BLOCK_STARTBLOCK_END 事件之间。在当前实现中,区块执行从不流水线化,因此 BLOCK_STARTBLOCK_END 之间的所有事件都属于单个区块,在当前区块结束之前不会再有另一个 BLOCK_START 与列表中的其他事件不同,BLOCK_START 既是”共识事件”(意味着相关区块处于 proposed 状态),也是”EVM 事件”,因为关于该区块的执行信息正在向您提供。 列表中的其他事件不同。它们是”纯粹”的共识事件:它们告诉您在您已经看到区块的所有 EVM 事件之后,共识算法中提议区块发生了什么。 要了解此状态的含义,请参见此处
没有理由说区块_必须_以 proposed 状态开始。如果执行落后于共识,则可能一个区块在共识算法中已经推进到更晚的状态。例如,假设共识已在某个区块上工作了一段时间,而当执行最终看到它时,共识可能已知它已经进展到 voted。然而在当前实现中,执行不会知道这一点。它隐式地将其执行的一切视为仅处于 proposed。仅当执行未落后时这才严格为真。

第二个共识事件:BLOCK_QCvoted 状态)

当带有给定标签的区块被投票时,会发布此类型的事件以公告此事。要了解看到此事件的全部含义,请参见此处

第三个共识事件:BLOCK_FINALIZED

finalized 事件负载不包含任何不在区块标签中的信息,因此负载就是被确认区块的标签。要了解看到此事件的全部含义,请参见此处

第四个共识事件:BLOCK_VERIFIED

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