> ## 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.
# 本地 Mempool
> 每个节点本地的 mempool
## 概要
大多数区块链使用带有点对点 gossip 的全局 mempool 来传播交易。出于以下几个原因,这种方法不适合高性能的分布式共识:
1. 它很慢,因为交易到达领导者可能涉及许多跳数,增加了被包含的时间。
2. 它浪费带宽,因为 gossip 协议涉及许多重传。
3. 它忽略了领导者调度,而领导者调度通常提前已知。
在 Monad 中,没有全局 mempool;相反,每个验证者维护一个本地 mempool,而 RPC 节点将交易转发给接下来的几个领导者,以便包含到它们的本地 mempool 中。这在带宽使用上更为高效,并允许交易更快地被包含。
## 背景
Mempool 是待处理交易的集合。许多区块链网络使用全局 mempool 设计,通过点对点 gossip 协议使网络中所有节点的 mempool 状态大致保持一致。全局 mempool 设计的主要动机是:无论谁是领导者,他们都能访问相同的待处理交易集,以便包含在下一个区块中。
全局 mempool 对低吞吐量网络是有效的,因为网络带宽通常不是瓶颈。然而,在每秒数千笔交易的情况下,gossip 协议(尤其是每个节点上所需的重传)很容易消耗整个网络带宽预算。此外,全局 mempool 是浪费的,因为领导者调度通常已经提前知晓。
## Monad 中的交易生命周期
Monad 中没有全局 mempool。验证者维护本地 mempool;RPC 节点将交易转发给即将上任的领导者,以确保这些交易可用于包含。
更准确地说,交易流程如下:
1. 交易被提交到某个节点的 RPC 进程(通常是全节点非验证者节点)。我们将这个节点称为该交易的 **"所有者节点"**,因为它承担与用户传达状态的责任。
2. RPC 进程对交易执行一些静态检查。
3. RPC 进程将交易传递给共识进程。
4. 共识进程根据 MonadDb 中的本地状态执行静态检查和动态检查,如检查发送方的账户余额和 nonce。
5. 如果交易有效,共识进程将该交易转发给 `N` 个即将上任的领导者验证者节点。目前,`N` 在 Monad 测试网和主网中设置为 3。
6. 这 `N` 个验证者中的每一个在将有效交易插入其本地 mempool 之前执行相同的检查。
7. 当轮到某位领导者创建提案时,它从本地 mempool 中选择交易。
8. 交易的所有者节点在后续区块中监视该交易。如果在接下来的 `N` 个区块中没有看到该交易,它将重新发送给接下来的 `N` 个领导者。它总共重复这一行为 `K` 次。目前,`K` 在 Monad 测试网和主网中设置为 3。
选择这种交易流程的行为,是为了在减少被包含时间的同时,尽量减少消息数量。
从 RPC 到领导者的交易路径(通过本地 mempool)。
## 本地 mempool 逐出
出于以下原因,交易会从验证者的本地 mempool 中逐出:
1. 每当验证者最终确认一个区块时,该区块中交易的任何副本都会从本地 mempool 中被剪除。
2. 验证者会定期检查 mempool 中每笔交易的有效性,并逐出无效交易(例如 nonce 过低、账户余额不足)。
3. 如果本地 mempool 的大小达到软性上限,较旧的交易将被逐出。