Add skeleton for functionality and concurrency
This commit is contained in:
parent
17b61db40a
commit
9cb45eb7df
|
@ -8,4 +8,4 @@ Components:
|
||||||
* [Config](./config.md) - how to configure it
|
* [Config](./config.md) - how to configure it
|
||||||
* [External Messages](./messages.md) - The messages we accept over p2p and rpc interfaces
|
* [External Messages](./messages.md) - The messages we accept over p2p and rpc interfaces
|
||||||
* [Functionality](./functionality.md) - high-level description of the functionality it provides
|
* [Functionality](./functionality.md) - high-level description of the functionality it provides
|
||||||
* [Local Services](./services.md) - Interfaces with consensus and abci services
|
* [Concurrency Model](./concurrency.md) - What guarantees we provide, what locks we require.
|
||||||
|
|
|
@ -0,0 +1,8 @@
|
||||||
|
# Mempool Concurrency
|
||||||
|
|
||||||
|
Look at the concurrency model this uses...
|
||||||
|
|
||||||
|
* Receiving CheckTx
|
||||||
|
* Broadcasting new tx
|
||||||
|
* Interfaces with consensus engine, reap/update while checking
|
||||||
|
* Calling the ABCI app (ordering. callbacks. how proxy works alongside the blockchain proxy which actually writes blocks)
|
|
@ -0,0 +1,37 @@
|
||||||
|
# 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:
|
||||||
|
|
||||||
|
* External: get, check, and broadcast new transactions
|
||||||
|
* Internal: return valid transaction, update list after block commit
|
||||||
|
|
||||||
|
|
||||||
|
## External functionality
|
||||||
|
|
||||||
|
External functionality is exposed via network interfaces
|
||||||
|
to potentially untrusted actors.
|
||||||
|
|
||||||
|
* CheckTx - triggered via RPC or P2P
|
||||||
|
* Broadcast - gossip messages after a successful check
|
||||||
|
|
||||||
|
## Internal functionality
|
||||||
|
|
||||||
|
Internal functionality is exposed via method calls to other
|
||||||
|
code compiled into the tendermint binary.
|
||||||
|
|
||||||
|
* 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
|
||||||
|
|
||||||
|
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
|
Loading…
Reference in New Issue