mirror of
https://github.com/fluencelabs/tendermint
synced 2025-04-25 23:02:16 +00:00
d6e2fb453d
* docs: explain create_empty_blocks configurations Closes #3307 * Vagrantfile: install nodejs for docs * update docs instructions npm install does not make sense since there's no packages.json file * explain broadcast_tx_* tx format Closes #536 * docs: explain how transaction ordering works Closes #2904 * bring in consensus parameters explained * example for create_empty_blocks_interval * bring in explanation from https://github.com/tendermint/tendermint/issues/2487#issuecomment-424899799 * link to formatting instead of duplicating info
42 lines
898 B
Markdown
42 lines
898 B
Markdown
# Mempool
|
|
|
|
## Transaction ordering
|
|
|
|
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.
|
|
|
|
valA:
|
|
- tx1
|
|
- tx2
|
|
- tx3
|
|
|
|
If the transactions are split up across different nodes, there's no way to
|
|
ensure they are processed in the expected order.
|
|
|
|
valA:
|
|
- tx1
|
|
- tx2
|
|
|
|
valB:
|
|
- tx3
|
|
|
|
If valB is the proposer, the order might be:
|
|
|
|
- tx3
|
|
- tx1
|
|
- tx2
|
|
|
|
If valA is the proposer, the order might be:
|
|
|
|
- tx1
|
|
- tx2
|
|
- tx3
|
|
|
|
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 tx3, then tx1, it can reject tx3 and then
|
|
accept tx1. The sender can then retry sending tx3, which should probably be
|
|
rejected until the node has seen tx2.
|