fluencelabs/tendermint
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint synced 2025-04-25 06:42:16 +00:00
Code Issues Projects Releases Wiki Activity
tendermint/docs/tendermint-core/mempool.md
Anton Kaliaev d6e2fb453d
update docs (#3349) 
* 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
2019-02-28 11:31:59 +04:00

898 B
Raw Permalink Blame History

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.