交易进了节点之后：CometBFT 的 flood 与 nop 两种内存池

交易池是节点里的候客厅

在一套 CometBFT 体系的链上，你广播一笔交易，它不会立刻变成区块的一部分。节点先把它放进一个内存结构：mempool，直译就是”内存池”。官方文档把它的角色说得很直白——存放尚未被提交交易的数据结构，相当于一间候客厅。谁有资格被提议者打包进下一个区块，第一步就是看这笔交易能不能进池、会不会被中继出去。排查”交易发不出去""广播报错”这类问题，多数时候第一站就是这间候客厅。

CometBFT 主分支的文档目前把候客厅分成两种布局：flood 与 nop，通过 mempool.type 配置选择。两者的差别不是大小，而是”谁负责收客”。

flood：链式队列、全量广播与四道门

示意图：小球沿发光带列队流向板面、旁侧光带空无，两种候客厅的抽象对比（图片由本地 SDXL 生成，非产品界面或精确数据图）

flood 的名字来自它的传播方式：新交易一进池，节点就把它转发给所有连接的 peers，peer 再转发给它们的 peers，像水一样漫过全网，因此叫”洪泛”。存储结构则是一条并发链表，按到达顺序排队。

一笔新交易要过四道检查才能进池：先看容量还有没有位置，对应 size 和 max_txs_bytes 两个上限；再看它单笔是不是太大，对应 max_tx_bytes；然后用一个 LRU 缓存（cache_size 调节）判断它是否已经见过，见过的直接丢弃；全部通过，才调用 ABCI 应用的 CheckTxAsync 做业务合法性校验。想让广播收敛一些也有开关：两个实验配置可以限制转发给多少 peers，broadcast 选项甚至可以完全关掉转发。每提交一个区块后，默认会把池里所有未提交交易重新过一遍 CheckTxAsync，这个复查可以用 recheck 关闭。

容量、费用与去重都在门口发生

四道门里没有一道与手续费有关：flood 池本身不设费率门槛，交易”够不够贵”是 CheckTx 里应用自己的规则。这意味着同一个交易池参数配置下，换一套应用就可能换一套准入标准。也意味着当交易被默默丢弃时，先要区分三种情形：容量满、单笔超限、或 LRU 认定重复。重复提交在故障排查里特别容易误判——你重发的内容与第一次完全一致时，节点大概率直接把它当作见过的交易收下又丢掉，不会有任何报错回给你。

排序不是交易池的责任

flood 池里唯一的顺序就是到达顺序。官方文档给了一个很直观的例子：如果发送者希望 tx1 先于 tx2 执行，唯一可靠的办法是把两笔都发给同一个节点；一旦分散到不同节点，下一轮提议者是谁都可能不同，顺序就说了不算。另一道保险写在交易本身里——带上序号、nonce 这类内部值，让应用在收到乱序交易时拒掉靠前的那笔，发送方再重试。换句话说，排序保证是应用层的责任，不是池子的。

nop：把候客厅整体交给应用

nop 即 no operation，是”我自己建候客厅”模式。选了 nop，交易不被存储、也不经 P2P 网络转发；通过 BroadcastTxSync、BroadcastTxAsync、BroadcastTxCommit 提交交易永远返回错误；共识层无从知道有没有交易可打包，所以节点总会出块，有时是空块——此时禁止把 consensus.create_empty_blocks 设为 false。交易的存储、传播、以及打包进区块的选择，全部由 ABCI 应用在 PrepareProposal 里自己负责。适合自带私有订单流或独立内存池的应用链。