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

# Monad 中的交易生命周期

## 交易提交

交易的生命周期从用户准备一笔已签名的交易并将其提交到 RPC 节点开始。

交易通常由应用前端准备,然后呈递给用户的钱包进行签名。大多数钱包会进行 `eth_estimateGas` RPC 调用以填充此交易的 gas **上限**,尽管用户也可以在其钱包中覆盖此值。用户通常也被要求为交易选择一个 gas **价格**,即每单位 gas 的 NativeToken 数量。

用户在其钱包中批准签名后,已签名的交易通过 `eth_sendTransaction` 或 `eth_sendRawTransaction` API 调用提交到 RPC 节点。

## Mempool 传播

如[本地 Mempool](/zh/monad-arch/consensus/local-mempool)所述:

RPC 节点执行有效性检查:

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

然后将待处理交易转发给接下来的 `N` 个领导者。

这些领导者中的每一个在将待处理交易添加到其本地 mempool 之前都会复制这些有效性检查。

如果该交易未被那些领导者提议的任何区块包含,RPC 节点将重复此过程,发送给接下来的 `N` 个领导者。此过程最多重复 `K` 次。

## 区块包含

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

* 账户余额足以支付 gas(考虑到[预留余额规则](/zh/developer-essentials/reserve-balance))
* nonce 是连续的
* 支付有效的[每 gas 基础费用](/zh/developer-essentials/gas-pricing#eip-1559-compatibility)
* 区块中有空间,并且领导者选择包含此交易

## 区块传播

区块通过网络传播,如 [MonadBFT](/zh/monad-arch/consensus/monad-bft) 中所讨论的,使用 [RaptorCast](/zh/monad-arch/consensus/raptorcast) 消息传递协议进行来自领导者的出站消息。

在 MonadBFT 下,区块从 Proposed 阶段推进到 Voted 阶段(1 个区块后),然后到 Finalized 阶段(2 个区块后)。

一旦区块被 Finalized,该交易就在区块链的历史中正式"发生"了。由于其顺序被确定,其真值(即它是成功还是失败,以及执行后立即的结果)也就确定了。

## 本地执行

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

## 查询结果

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