Accept only 1 valid fraud proof per ER into tx pool

[dariolina]

Per @NingLin-P :
In case of an invalid ER with many invalid fields, a malicious operator can spam the network to some extent because the malicious operator can produce multiple valid fraud proofs (FP) for one bad ER, and all the fraud proofs will need to be validated and will be accepted by the farmer's tx pool. When constructing the block only the first FP is included in block and the rest will be discarded from the tx pool, other farmers who receive this block will also discard all the FP, so the malicious operator can spam the farmer's tx pool with lower cost.
This can be fixed by utilizing the provides tag mechanism from the substrate tx pool, where fraud proof provides a tag of a hash of the target bad ER, the tx pool will only accept one tx with the same tag, so only the first arrived FP will be accepted and the other won't enter the tx pool.

TODO:

• Reject fraud proof with lower priority before it is validated.
  • Blocker Export api from the transaction pool to query ready transaction by tag paritytech/polkadot-sdk#3705

[dariolina]

@NingLin-P is it possible to identify in tx pool the relative order of ERs and keep only one per branch? Example, if I got in my mempool a FP for ER at height n but I also receive a FP for its parent n-1 I only need to include n-1 in a block and then n will also be pruned and slashed.

[NingLin-P]

is it possible to identify in tx pool the relative order of ERs and keep only one per branch?

Good point! it is possible by:

• Instead of using the hash of ER as tag, use the domain ID as tag so the tx pool only contains one FP for a given domain at a time
• Instead of always using TransactionPriority::MAX for FP, use TransactionPriority::MAX - n where n is the height of the ER that the FP is targetting, so FP that targetting older ER has higher priority

Example, if I got in my mempool a FP for ER at height n but I also receive a FP for its parent n-1 I only need to include n-1 in a block and then n will also be pruned and slashed.

With the above changes, when the FP for n-1 comes, the FP for n will be removed from tx pool since both FPs provide the same stage and the FP for n-1 has a higher priority, but the ER at n will also be pruned and slashed as it is a descendant of the ER at n-1.

But this doesn't fix everything though, the attacker can still submit FP one by one, i.e. only after the FP for n is included in the block then submit the FP for n-1.

[dariolina]

Yes, it also doesn't fix the verification time for reverse-order FPs. However, in cases when the chain is congested, this helps as it can reduce the number of FPs that need to go through consensus blocks.