A mempool (a contraction of memory and pool) is a node’s data structure for storing information on uncommitted transactions. It acts as a sort of waiting room for transactions that have not yet been committed.
CometBFT currently supports two types of mempools:
flood mempool stores transactions in a concurrent linked list. When a new
transaction is received, it first checks if there’s a space for it (
max_txs_bytes config options) and that it’s not too big (
option). Then, it checks if this transaction has already been seen before by using
an LRU cache (
cache_size regulates the cache’s size). If all checks pass and
the transaction is not in the cache (meaning it’s new), the ABCI
CheckTxAsync method is called. The ABCI application validates the
transaction using its own rules.
If the transaction is deemed valid by the ABCI application, it’s added to the linked list.
The mempool’s name (
flood) comes from the dissemination mechanism. When a new
transaction is added to the linked list, the mempool sends it to all connected
peers. Peers themselves gossip this transaction to their peers and so on. One
can say that each transaction “floods” the network, hence the name
Note there are experimental config options
experimental_max_gossip_connections_to_non_persistent_peers to limit the
number of peers a transaction is broadcasted to. Also, you can turn off
broadcast config option.
After each committed block, CometBFT rechecks all uncommitted transactions (can
be disabled with the
recheck config option) by repeatedly calling the ABCI
Currently, there’s no ordering of transactions other than the order they’ve arrived (via RPC or from other nodes).
So the only way to specify the order is to send them to a single node.
If the transactions are split up across different nodes, there’s no way to ensure they are processed in the expected order.
If valB is the proposer, the order might be:
If valA is the proposer, the order might be:
That said, if the transactions contain some internal value, like an
order/nonce/sequence number, the application can reject transactions that are
out of order. So if a node receives
tx1, it can reject
tx3 and then
tx1. The sender can then retry sending
tx3, which should probably be
rejected until the node has seen
nop (short for no operation) mempool is used when the ABCI application developer wants to
build their own mempool. When
type = "nop", transactions are not stored anywhere
and are not gossiped to other peers using the P2P network.
Submitting a transaction via the existing RPC methods (
BroadcastTxCommit) will always result in an error.
Because there’s no way for the consensus to know if transactions are available
to be committed, the node will always create blocks, which can be empty
consensus.create_empty_blocks=false is prohibited in such
The ABCI application becomes responsible for storing, disseminating, and
proposing transactions using
PrepareProposal. The concrete design is up
to the ABCI application developers.