Speeding up token connector

[alexauroradev]

There's an idea how one can speed up the NEAR->Ethereum transfer for tokens. Here's the principal scheme for this:

• We introduce a way to specify in withdrawal transaction a fee for the fast withdrawal. This either can be done by implementing additional withdraw_fast(amount, recipient, fee) method OR by enforcing a protocol for recipient -- if it consists of 20 bytes, then this is a normal withdrawal, otherwise, first 20 bytes is a recipient, next 32 bytes is a fee.
• A locker contract implements an additional method finalise_fast_withdraw(receipt_hash, erc20, amount, recipient, fee). This method does three things:
  • erc20.transfer_from(msg.sender, amount - fee)
  • erc20.send(recipient, amount - fee)
  • receipts.add({receipt_hash, erc20, amount, recipient, fee, msg.sender})
• A lockers' method unlock is modified in a way that it checks whether the submitted proof contains a receipt hash that was already submitted through finalise_fast_withdraw. In case the data from the receipt corresponds to the data stored during the execution of finalise_fast_withdraw, the payout is done not to the recipient, but to the caller of finalise_fast_withdraw.

This enables the following flow:

• A user, that wants to do the fast withdraw, specifies the fee in the bridged tokens for enabling fast withdraw procedure.
• In case the fee is appropriate for 3rd party, it submits to the connector the finalise_fast_withdraw transaction and transfers tokens to the user.
• At the moment when the bridge synced, a 3rd party is able to finish the transfer and get bridged tokens together with the fee.

Note: this allows not only for the 1 Ethereum block transfers to Ethereum, but also allows for 1 user interaction transfers.

This approach might remove the urgent need of the realistic bridge.

[mfornet]

I like this idea a lot and support the plan.

Some small problems I see:

• It requires liquidity from the users that will be providing fast finality. This is more problematic with "exotic" tokens or very large amounts.
• The tx to finalise a transfer is quite expensive (in terms of gas), so fee should be established according to that. In case of gas price fluctuation user providing fast finality might found themselves in a situation where they can't make the last call without loosing money.

[alexauroradev]

Agree on the problems.

First problem we either ignore, providing the fast withdraw feature only for the most popular assets, OR try to solve with more advanced schemes, when 3rd party can collect the fee in different currency. This will require the fact that other user is having the other currency bridged. The implementation is possible since factory is owning all the bridged tokens. This method will require additional tx on NEAR side for fee collection.

Second problem, again, we either ignore for now (leaving the space for 3rd parties to establish fees structure) OR alternatively, we can make use of gas & Ethereum price oracles (plus, perhaps, introducing the limit on the fee). In this case, the user will need to trust the oracle.
Alternatively, the second problem can be mitigated with composing withdrawals. Say, if there're multiple withdrawals of the same currency you would like to finalise, there's a more efficient method for this. I expect these 3rd parties to be established businesses which operate lot's of liquidity and having many fast withdrawals in the pipeline, so there's no need for them to finalise every withdrawal, but rather do one finalisation a day.

I suggest to start the simplest solution, leaving both problems open.

[ilblackdragon]

How about fee handling happens separately on NEAR.

Meaning you keep the interface of withdrawal on NEAR side the same as right now.
Then user calls separate connector contract finalize_escrow with the fee (can be in any token at this point) which locks this fee.
On Ethereum side similar to what you described, anyone can call finalise_fast_withdraw(receipt_hash, erc20, amount, recipient, callers_near_account) with appropriate amount of the erc20 token. This sends erc20 token to the recipient and records msg.sender as new recipient when the block finalizes. This also issues an event FastWithdrawal(msg.sender, callers_near_account).
Now, the fast finalizing user just calls finalize_escrow.get_paid(<fast_withdraw_event_hash>) which checks that indeed such hash of an even exists and unlocks the fee to the callers_near_account. If no one finalized, fee releases back to the user after ~16 hours.

Allows to separate the fee payment into any other asset potentially (or NEAR and ETH to start, which would just increase the user's visible tx fee). Also allows anyone to actually call finalize vs user needing to predetermine who will fast finalize at the sending time. And if no one finalized (no liquidity) - then it will just be automatic finalized in the normal way, as there is no change the default flow.

[alexauroradev]

Sounds good to me, nice approach. I like how this structure decouples the fee payment and the actual transfer. And also this approach makes the liquidity of 3rd party more liquid: instead of waiting for 16 hours for to get back the tokens and the fee, 3rd party will get its' reward in less than 10 minutes (however on the other side of the bridge) -- nice feature.

Also, I believe, this idea may be extended to make the finalisation fee not flat (this was an additional unclear point to me in my previous architecture, since the fee was determined and payed in different environments).
Let's consider the following scenario:

1. A user would like to do the transfer from NEAR to Ethereum.
2. He also specifies the additional fee for the fast withdrawal.
3. Now 3rd party can finalise the transfer in any moment in time from the beginning of the transfer till just the moment of the relaying of the next NEAR block header + 4h. Important: the longer the 3rd party is waiting, the lower is the period of borrowing its funds. In the extreme scenario the fast finalisation may be done at the moment of the ability to finalise the transfer normally, which means that 3rd party can earn the whole fee momentarily, without any risk.

Obviously, this is not the behaviour that is expected. Partly this can be mitigated by the open market for the fast withdrawals. But not fully. I feel that we need to provide some additional handles for the user to influence the withdrawal period:

1. finalise_escrow contract should provide the interface for the user to increase the fee (finalise_withdraw.speed_up(nep141, additional_fee)). This is something natural to the Ethereum blockchain and is widely used in the periods of high volatility of the gas price. Finalisation transaction is happening on the Ethereum, so the 3rd party need to pay gas fees for the finalise_fast_withdraw, which may lead to changes in the profitability of this service.
2. finalise_escrow may establish additional logic for the fee that is paid to the 3rd party depending on the time when the finalisation is happening. Say, the following may be implemented:
   1. If finalise_escrow.get_paid() is called not longer than X min after the finalise_escrow.set_reward(), then the fee is paid fully.
   2. If finalise_escrow.get_paid() is called between X min and Y min after the finalise_escrow.set_reward(), then the fee is decreased according to linear / exponential / other predetermined parameterized law.
   3. If finalise_escrow.get_paid() is called longer than Y min after the finalise_escrow.set_reward(), the fee payout is equal to 0.

These two features will protect the user from the unpredictability of Ethereum blockchain fees and excess payments for the bad quality service.

[mfornet]

We can also skip all together the transfer from NEAR to Ethereum using the bridge, and let the liquidity provider get the fee and the tokens on NEAR side, while providing liquidity on Ethereum side.

This can work similar to hashed timelock contracts in the following way.

There is a contract X on NEAR with methods:

def lock(amount: u64, fee: u64, eth_receipient: EthAddress, locked_time: u64) -> hash:
    Lock amount + fee tokens from sender into contract X for locked_time NEAR blocks
    Compute unique hash (*)
    Store information in the contract

def unlock(hash):
    If hash is in memory and more than locked_time NEAR blocks have passed since locked_event
    send all locked tokens to the originator of this transaction.
    Remove information associated with hash from storage

def claim(hash, proof):
    If the proof is a valid (checked against bridge prover), then
    amount + fee is sent to account calling this function.
    Remove information associated with hash from storage

And contract Y on Ethereum with method:

def finish_transfer(amount, eth_receipient, hash, near_receipient):
    Check hash hasn't been used before, and stores it in memory.
    Send amount to eth_receipient
    Emit event FinishTransaction(hash, near_receipient)

Transferring tokens works in the following way:

1. A calls X.lock(amount, fee, eth(A), locked_time).
2. B calls Y.finish_transfer(amount, eth(A), hash, near(B)).
3. B calls X.claim(hash, proof)

Pros:

• User A can get its tokens as fast as possible.
• Liquidity on NEAR side doesn't decrease.
• Anyone can provide liquidity (even A).
• Fees can be customized to incentivize LP to provide liquidity
• Any assets on NEAR can be traded by different assets on Ethereum (**)
• Bridge proof verification is not required on Ethereum side (which is most expensive step).

Cons:

• If no LP finalize the transfer, tokens will be locked potentially for long time.
• If eth2near relayer has a down time LP risks their assets, since step 3 (X.claim) will fail.
  On the other side, LP can run the relayer by itself, or verify the relayer is up to date/healthy before finishing the transfer (step 2).

Notes

1. (*) H is computed as H = hash(amount, eth_recipient, locked_time, sender_id, sender_nonce)
   (amount, eth_receipient) is to verify on ethereum side that the amount which is being sent is correct
   locked_time is for special applications (like Passive LP described below).
   (sender_id, sender_nonce) is to guarantee uniqueness of the transaction. sender_nonce is increased by 1 for every lock tx.

   Uniqueness of the tx is relevant, to avoid two different LP finalizing the tx simultaneously. In this case, tx after the first one should fail.

2. There can be two functions in contract X that allows to increase fee and to increase locked_period

3. (**) The lock function, instead of having (amount, fee) can have (inputs, outputs).
   inputs List[(NEP141, amount)]: List of FT tokens on NEAR and amount.
   outputs List[(ERC20, amount)]: List of FT tokens on Ethereum and amount.

   The lock transaction succeeds only if all the tokens listed in inputs are transferred to contract X. Fee must be included in inputs.
   Finalize transfer on contract Y will work if LP sends all the tokens listed on outputs.

   The advantage of this is that:

   • there is a unified interface for all transfers (no need to have on chain mapping between NEP-141 and ERC20).
   • fee can be paid in any currency
   • nETH, nWETH, in NEAR can be converted into wETH on Ethereum in a single transfer.
   • In general there is no limit to the types of tokens that can be swapped, and is up to the LP to accept or not a transfer.

4. locked_time should be long enough to give enough margin to let:

   • tx to be picked by LP
   • submit tx on Ethereum
   • wait until it is considered final
   • wait until this finality block can be proved using the rainbow bridge

Passive LP

NOTE: This will not work as described automatically, but still this can work with a service running off-chain that verify and signs tx.

There can be a passive LP system where a user that wants to provide liquidity puts their funds in a contract Z in Ethereum with the following methods:

def provide_liquidity(amount): ...

def remove_liquidity(amount): ...

def finish_transfer(*args):
    validate(args)

    Y.finish_transfer(*args)

In this case, B puts their assets on this contract. Anyone can call finish_transfer, and will get tokens on Ethereum immediately (as long as these tokens are available). It is responsibility for B to be monitoring all calls to this method, and claim tokens on NEAR side. Details of the contract needs to be decided, but if there is a single user operating this, it is straightforward.

This approach has the benefit that user A sending tokens from NEAR to Ethereum can do it instantaneously and doesn't depend on an off-chain service (3rd party) to finalise the transaction. In this case fees can be lower, since gas on Ethereum is paid by A rather than by B.

[alexauroradev]

@mfornet great suggestion.

I really like the fact that your model doesn't imply the actual transfer over the Rainbow bridge from NEAR to Ethereum. In the previous version the risk of the LP was inability to use the liquidity during the time of the NEAR->Ethereum transfer (say, 4-16h). In your version, the risk of the LP is that he exchanges the liquidity on Ethereum into liquidity on NEAR; so this is the bridge risk. Later, he can remove this risk by moving the liquidity back to Ethereum, however there's an option to immediately use the liquidity in NEAR DeFi.

Aslo, I believe it's quite important that we're not forcing users to pay NEAR->Ethereum finalisation fee (330k Eth Gas).

Passive LP approach will also give an opportunity to share the prizes (fees) among the LP. This is model is similar to mining pools vs. individual miners. Also, this would simplify the implementation of LP incentive mechanisms.

I would like to note that this approach is similar to pervious in the implied setup: Ethereum->NEAR transfers are fast; NEAR->Ethereum are slow. The fast NEAR->Ethereum transfer will take time approximately the same as Ethereum->NEAR.

Also, the idea of finalisation fee being not flat is also applicable to this approach

[alexauroradev]

Just for the sake of documenting stuff.
Passive LPs won't work. Though automatic finalisation of the fast transfers still may be done with the 3rd party running the service.