monadNewHeads 订阅公布区块 ID 和提交状态。本文档页面解释如何通过执行事件实现这一点。
区块标签
如此处所述,在确认之前,必须通过唯一 ID 来标识区块。即便如此,通常还是有必要知道提议的区块编号,即使我们还不知道该区块是否会以该编号被提交。下面的结构 —— 称为”区块标签” —— 作为字段出现在几种执行事件负载类型中,用于同时传达区块 ID 和(提议的)区块编号。四个共识事件
四种区块提交状态对应四种执行事件类型。这些类型的事件被发布,用于公告某个特定区块正在进入新的提交状态。第一个共识事件:BLOCK_START(proposed 状态)
BLOCK_START 事件,其事件负载包含一个 block_tag 字段,用于引入该区块的唯一 ID 以及一旦确认后它最终将拥有的区块编号。
几乎所有执行事件(交易日志、call frame、收据等)都发生在 BLOCK_START 和 BLOCK_END 事件之间。在当前实现中,区块执行从不流水线化,因此 BLOCK_START 和 BLOCK_END 之间的所有事件都属于单个区块,在当前区块结束之前不会再有另一个 BLOCK_START。
与列表中的其他事件不同,BLOCK_START 既是”共识事件”(意味着相关区块处于 proposed 状态),也是”EVM 事件”,因为关于该区块的执行信息正在向您提供。
列表中的其他事件不同。它们是”纯粹”的共识事件:它们告诉您在您已经看到区块的所有 EVM 事件之后,共识算法中提议区块发生了什么。
要了解此状态的含义,请参见此处。
没有理由说区块_必须_以 proposed 状态开始。如果执行落后于共识,则可能一个区块在共识算法中已经推进到更晚的状态。例如,假设共识已在某个区块上工作了一段时间,而当执行最终看到它时,共识可能已知它已经进展到 voted。然而在当前实现中,执行不会知道这一点。它隐式地将其执行的一切视为仅处于 proposed。仅当执行未落后时这才严格为真。
第二个共识事件:BLOCK_QC(voted 状态)
第三个共识事件:BLOCK_FINALIZED
第四个共识事件:BLOCK_VERIFIED
BLOCK_VERIFIED。这次,仅通过区块编号来标识区块就足够了。由于已验证的区块已经确认,它们是规范区块链的一部分,除非发生硬分叉否则无法回滚。因此,我们不再需要区块标签。
要了解看到此事件的全部含义,请参见此处。
