2018-01-04 19:08:03 +01:00
|
|
|
# Mempool Functionality
|
|
|
|
|
|
|
|
The mempool maintains a list of potentially valid transactions,
|
|
|
|
both to broadcast to other nodes, as well as to provide to the
|
|
|
|
consensus reactor when it is selected as the block proposer.
|
|
|
|
|
|
|
|
There are two sides to the mempool state:
|
|
|
|
|
2018-08-27 15:33:46 +08:00
|
|
|
- External: get, check, and broadcast new transactions
|
|
|
|
- Internal: return valid transaction, update list after block commit
|
2018-01-04 19:08:03 +01:00
|
|
|
|
|
|
|
## External functionality
|
|
|
|
|
|
|
|
External functionality is exposed via network interfaces
|
|
|
|
to potentially untrusted actors.
|
|
|
|
|
2018-08-27 15:33:46 +08:00
|
|
|
- CheckTx - triggered via RPC or P2P
|
|
|
|
- Broadcast - gossip messages after a successful check
|
2018-01-04 19:08:03 +01:00
|
|
|
|
|
|
|
## Internal functionality
|
|
|
|
|
|
|
|
Internal functionality is exposed via method calls to other
|
|
|
|
code compiled into the tendermint binary.
|
|
|
|
|
2018-08-27 15:33:46 +08:00
|
|
|
- Reap - get tx to propose in next block
|
|
|
|
- Update - remove tx that were included in last block
|
|
|
|
- ABCI.CheckTx - call ABCI app to validate the tx
|
2018-01-04 19:08:03 +01:00
|
|
|
|
|
|
|
What does it provide the consensus reactor?
|
|
|
|
What guarantees does it need from the ABCI app?
|
|
|
|
(talk about interleaving processes in concurrency)
|
|
|
|
|
|
|
|
## Optimizations
|
|
|
|
|
|
|
|
Talk about the LRU cache to make sure we don't process any
|
|
|
|
tx that we have seen before
|