在以太坊上跑过节点或写过发交易脚本的人大多熟悉这样的设定：交易在内存池里按出价高低排队，出价高的先被打包。换到 CometBFT 的世界，规则反过来了——这里的内存池默认按到达顺序排队，谁先来谁先被递给提案者，出价本身不是排队依据。这个差异不是实现偷懒，而是 CometBFT 分层哲学的直接后果：排序逻辑被交给应用，共识层只负责把合法交易可靠地送到提案者面前。
合法性由应用说了算：CheckTx 这道门
CometBFT 把自己定义成”为区块链应用做状态机复制”的引擎，交易长什么样、什么条件算合法，引擎一概不管，全部交给应用层通过 ABCI 接口回答。一笔新交易到达节点后，节点先调用应用的 CheckTx 方法：余额够不够、nonce 对不对、签名与费是否满足应用自定的最低要求，都由应用判断。通过才进池，不通过直接拒收，Gossip 转发交易时同样先过这道门，于是坏交易很难在网络里扩散。换句话说，以太坊节点里”执行层规则+本地策略”混合完成的把关，在这里被收拢成一个清晰的应用函数。
区块提交之后：更新与复查
这套”引擎不管交易含义”的分工有直接后果：同一个共识引擎可以承载规则完全不同的链，只要换上不同的应用。有的链在 CheckTx 里实现最小费用门槛，相当于把以太坊的费用市场外包给应用自己设计；有的链干脆不收费用，用其他资源计量方式限制 spam。换句话说，在 Cosmos 系里”给钱就能插队”不是共识性质，而是某条链的应用选择，逐条链看它们的参数文档才作数。
先进先出的队列还要处理一个现实问题：池里的交易是按旧状态判断合法的，而每个新区块都会改变状态。两笔依赖同一余额的交易可能先后入池，先后都通过 CheckTx，但打包时第二笔已经花不动了。CometBFT 的机制是两个动作配合：出块提交后，节点把被纳入交易的记录从池里删掉；随后按配置对剩余交易跑一轮复查，用新状态重新调用 CheckTx，如今不再合法的条目被清出。被清出的交易并没有消失，它还可以被重新广播、在状态允许时重新入池，只是要重新排队。
还有一个容易被忽略的细节：交易进入候选池后，网络传播走的是”洪水式”路线——新交易一进池就发给所有连接的对等点，对等点再各自转发，一笔交易像水一样漫过全网。实验性配置允许只向部分对等点广播，也可以整体关掉广播改为直连提案者提交。这两种模式在以太坊上对应”公共内存池与私有通道”的路线之争，在这里则是节点运维的一个开关。
排队的边界：提案者的自由与参数的闸门
需要区分两件事：池子把交易递给提案者时按到达顺序，但最终一个区块装哪些交易、以什么顺序装，由提案环节决定——应用与提案者可以按自身策略选择或重排，共识协议只保证提出来的区块在全网按同一顺序执行。这一点与以太坊”提案者事实上自由挑选、但市场以费用为轴”的格局方向一致，只是 CometBFT 把默认值定成了时间而非价格。节点侧还有一组容量闸门：flood 池在入口同时核对条目数上限、池的总字节上限与单笔交易字节上限，另有一个 LRU 缓存专门识别重复送达的旧交易，超限即拒。文档还直白地建议：想让几笔交易保持先后顺序，唯一的办法是把它们发给同一个节点，散到不同节点后顺序就交给运气了。对用户而言，这套设计的体感差别很直接：在按费用排序的链上，加急靠抬价；在这里，广播的及时性与节点连通性比出价更能决定你的交易何时出现在候选列表里，而拥堵时最先撞墙的是体积超限的交易而不是出价偏低的交易。（风险提示：本文仅为共识层机制说明，不构成任何投资建议或加速交易的支付建议。）
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。