Relayers coincidence transactions ordering solution/service?

[hackfisher]

Different relayers could send the same header/message relay at the same, this could cause duplicate calls, only one will success, others will fail, resulting waste of gas fee and extrinsic fees. This is a disincentive for relayers to participate in the network.

For substrate nodes(Darwinia etc.), we can use extrinsic validation in tx pool(before block inclusion) to filtering the txs, and only include one of them. (Related: darwinia-network/darwinia-common#669)

But for chains like ethereum, they do not support such customization of validation in tx_pool or block pre_validation. A solution to resolve this might be developing an ordering service for txs, relayers could first send txs to this service, and this ordering service will help order and filter, then redirect one to the target network nodes. This is practical now, but may have shortcomings of being centralized and censorship.

This could be decentralized using decentralized network later which requires much more engineering effort, thus decentralizing is low priority for now IMO.

[AurevoirXavier]

Yes, I think we can do a check-exist on bridger side.

If the bridger wants to submit the header as fast as possible without the checking to win the relay reward that they should take this risk (waste gas fee).

But if they are in the same block. This won't work.

[hackfisher]

Some related issue: paritytech/parity-bridges-common#978

[hackfisher]

1. If it uses Substrate, tx can be filtered in the transaction pool through SignedExtention (but the transaction is directly droped, there is no feedback), 2. sequencer service 3. Order Priority of Relayer Market can erase most of it.

Sequencer Node in Arbitrum for research reference:
https://tracer.finance/radar/arbitrum-in-under-10/ Section: Sequencer Mode