Substrate: Potential issue with forked block and signature validity and transaction pool

[xlc]

Semi related to https://github.com/paritytech/substrate/issues/5112

We are observing another issue relates to txpool.

• We have an oracle server submitting 2 txs every 5 mins to a RPC node.
• Our testnet for some reason have ~10% fork rate.
• We observing the RPC node have few txs never get confirmed nor pruned.
• Oracle server failed to submit new txs to the RPC node because priority too low issue (duplicated nonce).
  
  
  
  • There is indeed unconfirmed tx in that RPC node with same nonce.
  
  
  • But it never get confirmed nor pruned, so our oracle server stops working
  
  

My theory of the cause (no evidence yet)

• When signing tx, the block hash of a previous block was included in signature payload
• The oracle server signed a tx using a forked block
• The forked block got reverted, and hence invalidate the tx
• Tx pool did not revalidate the signature after fork got reverted to prune them
• No more tx from the same account until we manually purge the txpool (by restarting it)

Can someone confirm if this is possible?

@jacogr If it is possible for polkadot.js to only use finalized block hash for signature payload generation?

[jacogr]

I have been delaying making that swap, but it is on the list. Actually have thad hat branch available for a while. Also is meant to deal with fallback detection, i.e. if finality stalls.

TL;DR Will get it in at some point when it is deemed "good enough".

[NikVolf]

To avoid some transactions stuck in queue you need update post https://github.com/paritytech/substrate/commit/4869840fb39ee38b1b1751333c8d5a5447f4ef6c

But this cannot cause any consensus/fork issues