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

从 RPC 到领导者的交易路径(通过本地 mempool)。
本地 mempool 逐出
出于以下原因,交易会从验证者的本地 mempool 中逐出:- 每当验证者最终确认一个区块时,该区块中交易的任何副本都会从本地 mempool 中被剪除。
- 验证者会定期检查 mempool 中每笔交易的有效性,并逐出无效交易(例如 nonce 过低、账户余额不足)。
- 如果本地 mempool 的大小达到软性上限,较旧的交易将被逐出。

