Introduction
The goal of this issue is to be a facilitator of the conversation over securing the relayer network. It will outline an approach proposed by me and @s1na and hopefully we can improve it.
Problem statement
An attacker can drain the capital ETH of the relayers in the relayers network by submitting one transaction to be relayed to multiple relayers.
An example of such attack would be, malicious attacker sending one and the same request for relayed execution of a transaction to multiple relayers. Normally all relayers will check the execution of this transaction and decide that this transaction will legitimately go through successfully.
However, only one of the relayers will successfully execute this relayed transaction, due to the nature of the blockchain and anti replay attack mechanisms, the other relayers will lose ETH due to the reverting of the already executed transaction.
Discussion
General overview
By nature, this problem is a synchronisation problem. In general, if all the relayers in the network are synchronised, they will be able to tell who is processing which transaction. Such synchronisation, in real time would be exponentially harder with each new relayer.
Approaching this problem from another angle we've reached the conclusion that this problem can be solved through ordering.
Ordering
Another way to solve the problem is to remove the chaos of every relayer executing transactions all the time. Instead we can allow for one relayer to relay transactions per block(The proposed mechanism of finding the relayer allowed to relay will be found in the following Proposed Solution section). This requires some additional capabilities of the relayers in addition to the plain relaying:
Gossiping received transactions
In order for the network to work as fast as possible, the relayers would need to gossip each other the relayed transactions they receive from the dapps. This will allow for the relayer of the next transactions to include these transactions in the next block ensuring high responsiveness.
Maintaining list of transactions to be executed
All relayers will need to be able to maintain list of transactions to include in the next block. In addition the relayers would need to watch for submitted relayed transactions, in order to guard against resubmitting transactions.
Proposed solution
The proposed solution is based on pseudo-random round robin way of choosing the next relayer. Randomness of the round robin will be ensured by the block-hash of the previous block. Although this can still be manipulated, it becomes very impractical for a miner to collude with relayer as the economical incentive of producing a block would generally much higher than the economical incentive of relaying transactions. Read more here #13.
In addition a staking smart contract needs to be created. This smart contract will have several important functions. Firstly, it will allow for relayers to register as such, via placing a stake. Secondly, this contract is going to be the verifier of which relayer is the current eligible relayer. The identity smart contracts would need to additionally poll this contract verifying the current msg.sender against the eligible relayer.
Possible improvements
There is a need to figure out a way to punish dishonest relayers that are withholding transactions (not gossiping) until it's their time to submit into a block.