Concurrent relayers protocol: finality submissions

[svyatonik]

#2486 (comment)

Let's extract this part from #2486, because it could/need to be implemented in parallel with #2486.

So the problem is that if we'll introduce relayers coordination protocol (e.g. using priorities) BUT will keep our refund-batch-transactions approach (where we refund relayer, which has submitted valid finality proofs + messages transactions), we'll face the issue where bridge throughput is dropped to 1 lane per BH block. Because relayers may (and will - both honest and malicious) submit batch transactions AND of those transactions only one will be mined - all others will be dropped, because they contain obsolete finality proofs.

The solution that I've initially proposed in #2486 is to move finality relay functionality to collators - they'll submit finality proofs using BH inherents. This looks ideal at first glance, but it may take a while + I feel that there are some undiscovered caveats. So we need a backup plan that we may implement even before adding finality inherents (read: in v2).

So this issue is about designing this backup solution + implementing it. The most straightforward way imo is to remove refund support for batch transactions AND allow 1 free finality submission (be it GRANDPA, parachain or BEEFY) for every N BH blocks (where N may be one). So it is kinda inherent, but anyone could submit it. We need to think of resolving concurrency issue here too, though - because relayers will be submitting the same transactions every Nth block, which is not good. Maybe we shall select one relayer from registered set and force him to submit finality proof? Need some more thinking

[svyatonik]

The most straightforward way imo is to remove refund support for batch transactions AND allow 1 free finality submission (be it GRANDPA, parachain or BEEFY) for every N BH blocks (where N may be one). So it is kinda inherent, but anyone could submit it. We need to think of resolving concurrency issue here too, though - because relayers will be submitting the same transactions every Nth block, which is not good. Maybe we shall select one relayer from registered set and force him to submit finality proof? Need some more thinking

This is exactly what have been implemented in #2871 - we now have a standalone relayers with free submissions of every Nth header. So idea is that anyone may submit (relay/parachain) finality for free with some period and for messages we'll need relayers coordination protocol.