Tx pool: strict mode

[velzevur]

The tx pool does some checks for transactions and accepts ones that could be valid soon - ex. it does not check if the origin has enough tokens to spend and etc. The tx pool actively rejects txs with obvious issues - nonce is already used, insufficient fee, wrong signatures and etc.

This results in tx pool accumulating some transactions that are not valid at the moment (and could become eventually valid).

Applying them results in errors:

 {error,no_matching_oracle_query},
 {error,tx_nonce_too_high_for_account},
 {error,illegal_vm_version},
 {error,name_does_not_exist},
...

Provide optional strict mode for the transaction pool: if the node is a miner one and if tries applying a transaction and it fails (not enough tokens, nonce too high...) - kick the transaction out of the pool on the X attempt, where X could be specified for each error independently. This is different by the current GC behaviour as a transaction can be tried and can fail many times until it matures for GC. Since a transaction can be marked as tried once a generation, this means we still provide a transaction at least X generations of attempts to become valid before we kick it out.

This will provide us with better granularity for kicking out invalid txs. For example a transaction that comes with the wrong vm_version is not likely to become valid anytime soon, so no reason for keeping it. A tx_nonce_too_high_for_account might be worth keeping for longer and so on.

[nikita-fuchs]

This is highly welcome. Except for things related to oracles, I predict that absolutely no transaction will ever really "become valid". This pattern leaves more doors for attacks open than bringing any benefits. The common pattern should be: If it's not valid now and maybe a tiny amount of micro blocks, it should be kicked (with the exemption of oracle related stuff as stated before).

[marc0olo]

should we keep a tx with an invalid (or yet unknown) vm_version in the tx pool at all? for everything else I welcome this flexibility.

just for me to understand the behavior better:

• what happens if my node GCs a transaction? can it be synced and included in the tx pool again after some time? or will it only be synced again if a leader actually includes it in a microblock?

[velzevur]

what happens if my node GCs a transaction? can it be synced and included in the tx pool again after some time? or will it only be synced again if a leader actually includes it in a microblock?

If someone broadcasts it again, the node will accept a GCed tx. Currently nodes do not broadcast hanging in poll txs but we plan on adding a feature "broadcast again this particular transaction". If you restart your node, on startup it will ask its peers for all txs in their pool and can consume it again; if the tx is being included in a micro block - the node will accept it of course :)