Monad 中的交易生命周期

​

交易提交

交易的生命周期从用户准备一笔已签名的交易并将其提交到 RPC 节点开始。 交易通常由应用前端准备,然后呈递给用户的钱包进行签名。大多数钱包会进行 eth_estimateGas RPC 调用以填充此交易的 gas 上限,尽管用户也可以在其钱包中覆盖此值。用户通常也被要求为交易选择一个 gas 价格,即每单位 gas 的 NativeToken 数量。 用户在其钱包中批准签名后,已签名的交易通过 eth_sendTransaction 或 eth_sendRawTransaction API 调用提交到 RPC 节点。

​

Mempool 传播

如本地 Mempool所述: RPC 节点执行有效性检查:

• 签名验证
• nonce 不太低
• gas 上限低于交易 gas 上限

然后将待处理交易转发给接下来的 N 个领导者。 这些领导者中的每一个在将待处理交易添加到其本地 mempool 之前都会复制这些有效性检查。 如果该交易未被那些领导者提议的任何区块包含,RPC 节点将重复此过程,发送给接下来的 N 个领导者。此过程最多重复 K 次。

​

区块包含

只有当进一步的动态检查通过时,待处理交易才会被包含在区块中:

• 账户余额足以支付 gas(考虑到预留余额规则)
• nonce 是连续的
• 支付有效的每 gas 基础费用
• 区块中有空间,并且领导者选择包含此交易

​

区块传播

区块通过网络传播,如 MonadBFT 中所讨论的,使用 RaptorCast 消息传递协议进行来自领导者的出站消息。 在 MonadBFT 下,区块从 Proposed 阶段推进到 Voted 阶段(1 个区块后),然后到 Finalized 阶段(2 个区块后)。 一旦区块被 Finalized,该交易就在区块链的历史中正式”发生”了。由于其顺序被确定,其真值(即它是成功还是失败,以及执行后立即的结果)也就确定了。

​

本地执行

一旦节点收到一个区块,它就开始执行该区块中的交易。出于效率原因,交易以乐观并行方式执行,但就像交易是串行执行的一样,因为结果总是按原始顺序提交。

​

查询结果

用户可以通过在任何 RPC 节点上调用 eth_getTransactionByHash 或 eth_getTransactionReceipt 来查询交易的结果。RPC 节点将在节点上本地执行完成后立即返回。