XDM: Message submission checks to avoid validating duplicate XDM

[vedhavyas]

This PR aims to eliminate

• validating the same XDM that is already validated and submitted to txpool
  • This will elimanate tx_pool low priority error since there is already an XDM in the txpool
• validating of stale XDM.
  • This elimates the InvalidTransaction(201) but not trying to add the xdm to txpool since such XDM already executed in the canonical chain.

Code contributor checklist:

• I have read, understood and followed contributing guide

[teor2345]

I don’t have enough context to approve, but it looks reasonable to me.

[NingLin-P]

This will elimanate tx_pool low priority error since there is already an XDM in the txpool

The error is because even though the XDM is the same the content of the XDM is changing as it is constructed at different blocks (the MMR proof is changing), so the tx pool is unable to use the hash of tx to easily detect duplicate tx. FP has a similar issue and I have opened paritytech/polkadot-sdk#3705 as a general solution.

validating the same XDM that is already validated and submitted to txpool
validating of stale XDM

These checks seem server as a short-circuit to front run some checks before submitting XDM to tx pool to do a complete check, it does eliminate the error log but not much cost as these checks also come with their own cost. Would be great to have optimization on the sender side to stop relaying stale XDM at the first place.

[vedhavyas]

The error is because even though the XDM is the same the content of the XDM is changing as it is constructed at different blocks (the MMR proof is changing), so the tx pool is unable to use the hash of tx to easily detect duplicate tx. FP has a similar issue and I have opened paritytech/polkadot-sdk#3705 as a general solution.

Not necessarily true. All operators are able to publish the XDM at the same time for the same block. So Proof is same and so does the txHash. This is something I have verified over the tests and txpool rejecting the transactions due to already exisiting XDM validated and in ready state.

It does eliminate the error log but not much cost as these checks also come with their own cost.

I'm not able to follow completely here. I'm not worried about the costs here as they are pretty much unwrappers and this process is dedicated to just XDM and Channel updates. Should not an issue IMHO.

Would be great to have optimization on the sender side to stop relaying stale XDM at the first place.

This is something I have thought but I would like to test the first set of changes before adding similar checks in the sender side.

[NingLin-P]

All operators are able to publish the XDM at the same time for the same block. So Proof is same and so does the txHash.

Then I'm more confused:

• IIUC, tx_pool low priority is for tx with different content but the same tag (e.g. same nonce), for the exact same tx the tx pool should output something like ... already import
• If the change is targeting existing ready XDM in the tx pool, then it seems useless as the tx pool already has the same check that also serves as a lightweight short-circuit, why do we need this change? just to eliminate an error log from the tx pool?

I'm not able to follow completely here. I'm not worried about the costs here as they are pretty much unwrappers and this process is dedicated to just XDM and Channel updates. Should not an issue IMHO.

I didn't mean it is an issue, just comparing the cost of having this front check with letting the tx pool do the complete check.

[vedhavyas]

IIUC, tx_pool low priority is for tx with different content but the same tag (e.g. same nonce), for the exact same tx the tx pool should output something like ... already import

Ohh sorry for confusion.
You are right, Its because of the same tag.
Transaction hashes are indeed different

I didn't mean it is an issue, just comparing the cost of having this front check with letting the tx pool do the complete check.

This will be a low cost since txpool validate unsigned will be higher and will be blocking operation for txpool to accept other transactions