Prevent Relayer Race Conditions

[evan-gray]

Overview

If the deliver endpoint of the contract remains purely permissionless, relayers may race to compete for the reward but waste gas on a revert since only one can win. This disincentivizes parties to participate in relaying since they can lose more gas by attempting relays on average than they stand to gain on successes. In the short term, this could be solved by the sender designating a relayer to receive the reward - that way only one party has an incentive to relay the transaction.

It is important to note that the relaying mechanism remains trustless - this designation is purely for the service of delivery.

Current Behavior

Any party that relays receives the designated reward

Proposed Behavior

Send

Add a field for the designated relayer wallet address (32 bytes, for future compatibility).

Relayer

Relayers should only attempt delivery of messages which they are designated (unless they are feeling generous).

Deliver

Only pay out the reward if msg.sender == designated address or, optionally, if a new boolean parameter for payAnyway is set. This allows a relaying party to operate multiple hot wallets but gain rewards to a cold wallet, for example. Alternatively, if a user or protocol had to redeem a batch themselves, they could set this to false so the relayer is not rewarded.

Open Questions

What happens to rewards that were not paid out?

Considered Solutions

I feel the provided solution is a relatively easy solution which better aligns incentives for relayers despite removing competition for a given batch.

Auction

Future blocks could be auctioned off so that a relayer could stake some tokens in order to potentially gain rewards for a given block. The issue becomes that a single malicious actor could bid for all blocks and never relay messages because there is no trustless mechanism in place to prove that a batch should have been relayed in a given block and slash the stake.

Designated Block / Time

Consider that a future block or time limit could be specified on the delivery instruction before incentives can change. It is both difficult to know exactly how long in the future a VAA may be produced (dependent upon finality, chain up time, network latency and congestion) and relies upon the submitter putting an adequate future time or the contract to have access to an accurate oracle. Ultimately, this is unlikely to help the incentives more than the strong reputation of a designated relayer.

Future Considerations

Additional Bounty

Perhaps a modification of resend/redeliver, allow for an additional bounty to be posted if the reward has not been redeemed in a given number of blocks. Requiring the delay should prevent a caller from causing the same type of race we are trying to prevent. This additional bounty could be represented by an additional VAA that references the original delivery instruction and could be submitted in addition to that batch to claim an additional (if the same designee) or alternative reward.