Relaying fee specification in the locking transaction (eth-connector)

[alexauroradev]

Current implementation of the Ethereum-side connector includes the locking transaction with a fee parameter. This parameter represents the fee in ETH to be payed to the relayer, which will eventually (after the sync of the Ethereum light client) submit the fininalization transaction on the NEAR side and complete the transfer. This approach has pros and cons.

Pros:

1. A user without NEAR account is able to transfer ETH. This is a must have feature for the ETH connector.
2. A user interaction with connector is focused and is within a single transaction -- a very familiar operation for web2 world

Cons:

1. We're mixing up the logic of connector and gasless transactions in NEAR.
2. Specified ETH fees might not be acceptable once the time is come for the finalisation transaction.

We need to make a decision on the approach.

[alexauroradev]

My personal view is that pros are outweighing cons. A single transaction interaction is just what we need, just because we for sure don't want make user to wait until the transfer is completed. 7 min transfer Ethereum -> NEAR is still OK, but the transfer back of up to 17h is a disaster. No-one wants to check the FE to send additional transaction.

Second con on the ETH fees will be the problem until we build something like OpenGSN for the relayers. This is an overcomplicated approach at the moment. We can think of the transaction submission process like:

• A user asks the relayer what fee will be OK for it
• Relayer answers, creating an implicit contract for this transaction
• User puts this fee into the locking transaction

In this model Relayer need to account for the risks of exchange rate change. In case there're multiple relayers (competition), a user would choose the one which behaves correctly and work with it. Plus, user transactions are public and any relayer can finalise the transfer.

Mixing up logic is a very valid point, but I believe for now this simple solution is OK, and later we should update it with more appropriate option.

[mfornet]

Specified ETH fees might not be acceptable once the time is come for the finalisation transaction.

This might be an issue in both directions:

1. If the fee specified is too low, no relayer will accept the transaction, so it should require an additional signature to submit a new transaction on EVM. If this happens the UX will be worse since now user is paying fees at two different places, so it needs to take this into account.

2. The fee specified may be too high. This can be the case since the relayer will only apply the transaction on the EVM (NEAR) side after ~7 min, and ethereum price could have increased. To this end, the best would be to determine the fee in the same way for every users that is submitting to the EVM paying with ETH, and to do it at submission time (not 7 minutes earlier). (It can be argued that the fee was paid when tx was signed and not ~7min later, but it is not fair, because if the ETH price decrease considerably after ~7min relayer will not relay the transaction due to insufficient fee).

[mfornet]

Another point, (not necessarily bad for the user transferring ETH), is that several relayers will compete to relay a transaction but only one can get it in the end. So basically the relayer submitting the tx has no guarantee that it will collect the fee, but it will spend some NEAR for paying gas anyway.

[alexauroradev]

Discussed over the phone with @mfornet . General points:

1. Agreed on the approach
2. There should be developed an additional transaction to increase the fee on NEAR-side (through EIP-712 message signed in Metamask). This will cover the risk of the ETH<>$NEAR exchange rate fluctuations.
3. Idea: relayers can provide some premium services to the users and it would be good to allow for the pay-as-you-go type of service, which ultimately results in higher gas fees. The protocol should protect the user <> relayer relationship from 3rd parties relaying the same high-fee transaction. Similar protocol can be used for protection against front-running attacks for the vulnerable EVM contracts in future (see Ethereum is a dark forest).