github.com/KYVENetwork/cometbft/v38@v38.0.3/docs/core/mempool.md (about)

     1  ---
     2  order: 12
     3  ---
     4  
     5  # Mempool
     6  
     7  A mempool (a contraction of memory and pool) is a node’s data structure for
     8  storing information on uncommitted transactions. It acts as a sort of waiting
     9  room for transactions that have not yet been committed.
    10  
    11  CometBFT currently supports two types of mempools: `flood` and `nop`.
    12  
    13  ## 1. Flood
    14  
    15  The `flood` mempool stores transactions in a concurrent linked list. When a new
    16  transaction is received, it first checks if there's a space for it (`size` and
    17  `max_txs_bytes` config options) and that it's not too big (`max_tx_bytes` config
    18  option). Then, it checks if this transaction has already been seen before by using
    19  an LRU cache (`cache_size` regulates the cache's size). If all checks pass and
    20  the transaction is not in the cache (meaning it's new), the ABCI
    21  [`CheckTxAsync`][1] method is called. The ABCI application validates the
    22  transaction using its own rules.
    23  
    24  If the transaction is deemed valid by the ABCI application, it's added to the linked list.
    25  
    26  The mempool's name (`flood`) comes from the dissemination mechanism. When a new
    27  transaction is added to the linked list, the mempool sends it to all connected
    28  peers. Peers themselves gossip this transaction to their peers and so on. One
    29  can say that each transaction "floods" the network, hence the name `flood`.
    30  
    31  Note there are experimental config options
    32  `experimental_max_gossip_connections_to_persistent_peers` and
    33  `experimental_max_gossip_connections_to_non_persistent_peers` to limit the
    34  number of peers a transaction is broadcasted to. Also, you can turn off
    35  broadcasting with `broadcast` config option.
    36  
    37  After each committed block, CometBFT rechecks all uncommitted transactions (can
    38  be disabled with the `recheck` config option) by repeatedly calling the ABCI
    39  `CheckTxAsync`.
    40  
    41  ### Transaction ordering
    42  
    43  Currently, there's no ordering of transactions other than the order they've
    44  arrived (via RPC or from other nodes).
    45  
    46  So the only way to specify the order is to send them to a single node.
    47  
    48  valA:
    49  
    50  - `tx1`
    51  - `tx2`
    52  - `tx3`
    53  
    54  If the transactions are split up across different nodes, there's no way to
    55  ensure they are processed in the expected order.
    56  
    57  valA:
    58  
    59  - `tx1`
    60  - `tx2`
    61  
    62  valB:
    63  
    64  - `tx3`
    65  
    66  If valB is the proposer, the order might be:
    67  
    68  - `tx3`
    69  - `tx1`
    70  - `tx2`
    71  
    72  If valA is the proposer, the order might be:
    73  
    74  - `tx1`
    75  - `tx2`
    76  - `tx3`
    77  
    78  That said, if the transactions contain some internal value, like an
    79  order/nonce/sequence number, the application can reject transactions that are
    80  out of order. So if a node receives `tx3`, then `tx1`, it can reject `tx3` and then
    81  accept `tx1`. The sender can then retry sending `tx3`, which should probably be
    82  rejected until the node has seen `tx2`.
    83  
    84  ## 2. Nop
    85  
    86  `nop` (short for no operation) mempool is used when the ABCI application developer wants to
    87  build their own mempool. When `type = "nop"`, transactions are not stored anywhere
    88  and are not gossiped to other peers using the P2P network.
    89  
    90  Submitting a transaction via the existing RPC methods (`BroadcastTxSync`,
    91  `BroadcastTxAsync`, and `BroadcastTxCommit`) will always result in an error.
    92  
    93  Because there's no way for the consensus to know if transactions are available
    94  to be committed, the node will always create blocks, which can be empty
    95  sometimes. Using `consensus.create_empty_blocks=false` is prohibited in such
    96  cases.
    97  
    98  The ABCI application becomes responsible for storing, disseminating, and
    99  proposing transactions using [`PrepareProposal`][2]. The concrete design is up
   100  to the ABCI application developers.
   101  
   102  [1]: ../../spec/abci/abci++_methods.md#checktx
   103  [2]: ../../spec/abci/abci++_methods.md#prepareproposal