Bridging ERC20 tokens inside the EVM

[mfornet]

The token-connector allows to transfer ERC20 tokens from Ethereum to Near, and deal with them on Near as NEP141 tokens. We also want to allow sending this tokens inside the EVM as ERC20 tokens, to be used by contracts that are running in this context.

Let's discuss here how we should proceed in this case.

[mfornet]

Design

Create a special account in near (evm.bridge.near), and one account inside the EVM (token-factory). Both accounts are aware of each other and allow making "atomic" transfers between them. Their behavior will be the same as the lockers we are using to make transfers between Ethereum and Near (https://github.com/near/rainbow-token-connector/).

Technical details.

• token-factory has the ability to deploy a new erc20 token in the evm, that will match its erc20 in ethereum counterpart. Since it is not possible to keep the same addresses, it should also contain a mapping between them. This method can be invoked by any user.
• When the function mint is called in a bridged token with target evm.bridge.near, a proof of this event can be used to mint the exact amount of tokens on the relevant erc20 address inside the EVM. The receiver of the tokens will be the same address that initiated the transfer in ethereum (*)
• There is a similar burn function inside each of the deployed tokens inside the EVM that can be used to unlock these tokens on evm.bridge.near. Once tokens are unlocked they can be either sent back through the bridge to Ethereum, or they can be transferred internally as NEP-141.

Pro

• There is no changes to the bridge, the current connector, or the EVM
• evm.bridge.near works as a natural proxy holding the NEP-141 tokens, in case we want to move the tokens arbitrarily between the three environments (Ethereum, Near, EVM on Near)

Cons

• There is an additional tx required when tokens are begin transferred from Ethereum to the EVM.
• We need to maintain the history of all tx inside the EVM contract too, in order to avoid double mints.

(*) We can expand the logic when tokens are minted inside the EVM, to allow the original sender, change the receiver, by signing an optional field with the new receiver.

[alexauroradev]

Alternative design

There're no additional contracts that connect EVM and NEAR Native runtimes. EVM is a holder of NEP-141 tokens, issuance of tokens in the EVM is completely dependant on the EVM contract

Tech details:
EVM contract implements the ft_on_transfer() interface, which literally mean that EVM can receive NEP-141s. This method requires a message with EVM address -- a recipient of NEP-141 token. This method recalculates deterministically EVM address of NEP-141 token and works directly with the EVM storage to change the amounts in the corresponding ERC-20 contract storage.
In order to withdraw bridged tokens from EVM, a user should sign an EIP-712 message, following the withdrawal protocol (st least this data should be signed: ERC20 address, amount, recipient, relaying fee). This EIP-712 message gets wrapped into valid NEAR transactions and is passed to a withdrawERC20() method of EVM contract. This method checks the signature of the message, gets the info from it and, working directly with the state of the EVM, changes the balance.
In order to schedule a transfer over the bridge to EVM, a user on Ethereum should use as a recipient the following structure: aurora:<recipientAddress>, which would be translated by the connector into ft_transfer_call() to aurora contract with a message equals to
In order to unify the withdrawals (if we allow for bridging NEAR-native NEP-141 tokens), EVM contract should call ft_transfer() or ft_transfer_call() depending on the recipient string structure. This automatically means that we should interchange withdraw method of bridged tokens into ft_on_transfer(), which would allow token contract to receive itself.

Pros:

• There're no changes to the bridge, besides the addition of a backwards compatible protocol for destination
• The approach can be extended to interaction with other contracts besides Aurora: other instances of EVM, or DeFi applications in NEAR native runtime
• There're no additional transactions on NEAR side
• The approach independent of the origin of the NEP-141 (native or bridged)
• No need to duplicate history of depositing transactions

[abacabadabacaba]

Some thoughts:

• It seems better to have addresses derived deterministically than having to maintain a mapping. In EVM, there is a CREATE2 opcode that can be used to create contracts at deterministic addresses.
• Having a separate contract that is treated specially by the EVM contract is worse than having the same functionality in the EVM contract itself.
• We probably want to support all NEP-141 tokens in the EVM, not just bridged ERC-20 tokens.
• For the user's convenience, we may want to have a special function in the Ethereum token locker that sends the token to the EVM. This function should accept the destination address (inside the EVM) as an address value, not as a string. For now, we may implement it as an additional type of event (specific to this function). We may later replace it with a generic mechanism to specify the message value.