Issue# 1 - Spam relayers to drain their funds.
Let’s say a user generates a tx request and sends it to all relays at the same time.
Only 1 relayer will be able to successfully execute the transaction, the rest will be reverted because canRelay will be false for them. Hence, the relayers will lose their own funds.
Is there a way for relayers to make sure they are not duplicating requests?
Issue#2 - Rogue relayer.
Let’s say a relayer wants to censor some smart contracts by accepting their transactions, returning the txHash and right after making a different tx with the same nonce to break the positive user experience for a particular dapp.
How can smart contract owners make sure they won’t be censored from relayers?
3 Likes
Issue 2 is covered by the penalization mechanism: any account can submit proof of dishonest relayer behavior to RelayHub (in this case, two transactions with the same nonce), and be rewarded with half of the relayer’s stake. The other half is burnt, so even if the malicious relayer attempts to penalize itself, it will still lose half of this amount (at least 0.5 Eth).
Issue 1 is more complex, since penalizing end users is not feasible. We have a couple ideas to tackle this, ranging from relayer cooperation to recipients having to subscribe to a relayer’s service with a small fee, but they are not finalized yet. Ideas are welcome!
1 Like
Issue#2. Can you provide some technical ways to observe all requests from relayers to catch issue#2. I assume it’s some kind of fisherman’s node.
Issue#1 - probably there has to be some place where relays can submit their current pending jobs and others can verify if they are submitting the same job.
Relayers can introduce a random delay (1-2 seconds) to check again the central pool of job requests before actually submitting the tx.
OR after actual submission, the relayer can check again if any other relayer is processing the same job, if it is, he should take new job request and try to overwrite the same nonce with higher gas price. There is still risk that tx will be mined at the time of operation.
Also a relayer should not take any new jobs until his pending pool is empty within 10mm gas limit.
1 Like
Yes, looking at the mempool might be enough, but in case that fails, the easiest way to make sure none goes uncaught is to have the client post all relayed transactions somewhere, since it will always have the information required to penalize a party that attempts to harm it.
Correct, that is pretty much what I have in mind. The issue is that, given that system is running, each individual relayer has no incentive to keep participating (you don't need to be honest about which transactions you're relaying yourself, you just need for everyone else to be honest).
There are ways to tackle this, such as e.g. requiring that every relayer post X amount of transactions every Y hours for them to be allowed in this system, but we haven't yet thought them through.
It is also possible that a solution to this is related to the need to post relayed transactions somewhere to solve issue 2.
1 Like
so, where is fisherman’s node to catch bad validators? how can I run it?
1 Like
Hi @rstormsf,
I assume that there isn’t yet code for a fisherman to catch bad validators.
Though @nventuro can correct me if I am wrong.