github.com/ari-anchor/sei-tendermint@v0.0.0-20230519144642-dc826b7b56bb/docs/tendermint-core/mempool/README.md (about)

     1  ---
     2  order: 1
     3  parent:
     4    title: Mempool
     5    order: 2
     6  ---
     7  
     8  The mempool is a in memory pool of potentially valid transactions,
     9  both to broadcast to other nodes, as well as to provide to the
    10  consensus reactor when it is selected as the block proposer.
    11  
    12  There are two sides to the mempool state:
    13  
    14  - External: get, check, and broadcast new transactions
    15  - Internal: return valid transaction, update list after block commit
    16  
    17  ## External functionality
    18  
    19  External functionality is exposed via network interfaces
    20  to potentially untrusted actors.
    21  
    22  - CheckTx - triggered via RPC or P2P
    23  - Broadcast - gossip messages after a successful check
    24  
    25  ## Internal functionality
    26  
    27  Internal functionality is exposed via method calls to other
    28  code compiled into the tendermint binary.
    29  
    30  - ReapMaxBytesMaxGas - get txs to propose in the next block. Guarantees that the
    31      size of the txs is less than MaxBytes, and gas is less than MaxGas
    32  - Update - remove tx that were included in last block
    33  - ABCI.CheckTx - call ABCI app to validate the tx
    34  
    35  What does it provide the consensus reactor?
    36  What guarantees does it need from the ABCI app?
    37  (talk about interleaving processes in concurrency)
    38  
    39  ## Optimizations
    40  
    41  The implementation within this library also implements a tx cache.
    42  This is so that signatures don't have to be reverified if the tx has
    43  already been seen before.
    44  However, we only store valid txs in the cache, not invalid ones.
    45  This is because invalid txs could become good later.
    46  Txs that are included in a block aren't removed from the cache,
    47  as they still may be getting received over the p2p network.
    48  These txs are stored in the cache by their hash, to mitigate memory concerns.
    49  
    50  Applications should implement replay protection, read [Replay
    51  Protection](https://github.com/tendermint/tendermint/blob/8cdaa7f515a9d366bbc9f0aff2a263a1a6392ead/docs/app-dev/app-development.md#replay-protection) for more information.
    52  
    53  ## Configuration
    54  
    55  The mempool has various configurable paramet
    56  
    57  Sending incorrectly encoded data or data exceeding `maxMsgSize` will result
    58  in stopping the peer.
    59  
    60  `maxMsgSize` equals `MaxBatchBytes` (10MB) + 4 (proto overhead).
    61  `MaxBatchBytes` is a mempool config parameter -> defined locally. The reactor
    62  sends transactions to the connected peers in batches. The maximum size of one
    63  batch is `MaxBatchBytes`.
    64  
    65  The mempool will not send a tx back to any peer which it received it from.
    66  
    67  The reactor assigns an `uint16` number for each peer and maintains a map from
    68  p2p.ID to `uint16`. Each mempool transaction carries a list of all the senders
    69  (`[]uint16`). The list is updated every time mempool receives a transaction it
    70  is already seen. `uint16` assumes that a node will never have over 65535 active
    71  peers (0 is reserved for unknown source - e.g. RPC).