Bridged ERC20 Upgradability Proposal

[mfornet]

There is an automatic mechanism to move NEP141 Tokens from NEAR to Aurora as ERC20. Currently we are using an almost vanilla implementation of ERC20 tokens that doesn't support upgradeability. There are several motivations for having this contracts upgradeable, like implementing new features or fixing bugs:

• Allow more robust exit to NEAR/Ethereum: Refund user when ExitToNear promise fails #311
• Automatic metadata bridging (no admin key required)
• Custom implementations for ERC20

Having each of this contracts upgradable is a must. But still using one of the standard approaches for upgradeability has some difficulties. If ERC20 are going to be updated, then each of the currently deployed tokens must be updated in a separate transaction, which can be slow and tedious. On this regard we can use the following approach:

There are 3 types of contracts:

• Front ERC20
• Router
• Implementation

Front ERC20 will be the front contract to be used to interact with a token. Its address won't change. It will ask the Router for the Implementation contract to be used.

Router will respond with the current Implementation. It contains the functions:

• function get_implementation_address() view returns (address).
• function set_implementation_address(address implementation). This function can only be called by the owner of the contract.

Implementation contains the code to be executed for the ERC20 tokens.

When we need to upgrade all ERC20 contracts, the new implementation is deployed, and the router is updated to point to this new implementation. This way the amount of changes per upgrade is O(1), doesn't depend on the amount of tokens currently deployed.

Note: Beware that nested delegatecall in Ethereum can be tricky. Though they are not completely required in this approach.

Custom implementations

With this design, we can have custom implementations per token approved by aurora. In this case the function in the router get_implementation_address may inspect the the msg.sender and look into a dictionary to see if there is a custom implementation for this ERC20.

If we decide to proceed this way, it would be useful to have a function in the router get_default_implementation_address as well that doesn't depend on the msg.sender, so this function can be used by the custom implementation contract in case it only needs to reimplement some of the functions.

Open questions

1. This is only a high level proposal of the upgradability path, but it is still open to select low level details of the upgradability pattern (i.e regarding storage, initialisation, etc...) See some previous research here: hackmd.

2. While initiating this discussion, current bridge ERC20 doesn't expose any way to upgrade them. How should we proceed. I see two options:

• Deploy the new contract on the old address.
• Deploy the new binaries on different address; move all balances from one to the other; update the erc20-nep141 mapping.

[mfornet]

Here is a gist with how this three contracts would interact within each other:
https://gist.github.com/mfornet/5dbb67cba05e0cffd7e3a923b43a17ea