github.com/okex/exchain@v1.8.0/libs/tendermint/docs/tendermint-core/mempool.md (about)

     1  ---
     2  order: 10
     3  ---
     4  
     5  # Mempool
     6  
     7  ## Transaction ordering
     8  
     9  Currently, there's no ordering of transactions other than the order they've
    10  arrived (via RPC or from other nodes).
    11  
    12  So the only way to specify the order is to send them to a single node.
    13  
    14  valA:
    15    - tx1
    16    - tx2
    17    - tx3
    18  
    19  If the transactions are split up across different nodes, there's no way to
    20  ensure they are processed in the expected order.
    21  
    22  valA:
    23    - tx1
    24    - tx2
    25  
    26  valB:
    27    - tx3
    28  
    29  If valB is the proposer, the order might be:
    30  
    31    - tx3
    32    - tx1
    33    - tx2
    34  
    35  If valA is the proposer, the order might be:
    36  
    37    - tx1
    38    - tx2
    39    - tx3
    40  
    41  That said, if the transactions contain some internal value, like an
    42  order/nonce/sequence number, the application can reject transactions that are
    43  out of order. So if a node receives tx3, then tx1, it can reject tx3 and then
    44  accept tx1. The sender can then retry sending tx3, which should probably be
    45  rejected until the node has seen tx2.