ERC677-to-ERC677 bridge on top of AMB

[akolotov]

In order to demonstrate AMB features let's implement ERC677-to-ERC677 bridge that uses AMB interfaces to transfer assets.

From contracts set point of view the architecture could be as following:

Token contract at Home
|
Token Management contract at Home
|
Bridge contract at Home
~~~~~
Bridge contract at Foreign
|
Token Management contract at Foreign
|
Token contract at Foreign

Where Token contract have the same meaning as on the existing erc20-to-erc20 bridge. Token Management is responsible for holding the tokens on the Foreign side and minting the tokens on the Home side, implementing the onTokenTransfer method and checking limits before the transfer. Bridge contract is the AMB contract.

The call flaw for transferring assets from the Foreign side to the Home side could be the following:

• the end user inokes transferAndCall of the token contract specifying the Token Management contract address as receiver of the tokens.
• the token contract runs onTokenTransfer of the Token Management contract
• the Token Management contract checks that the transaction is within the limits and executes requireToPassMessage on the Bridge contract
• the message is passed to the Bridge contract on the Home side by the oracle
• the Bridge contract on the Home side calls the Token Management contract
• the Token Management contract checks that the transaction is within the limits and mints the corresponding number of tokens as per the initial request

The opposite direction is similar but the Token Manager on the Home side burns tokens whereas the Token Manager on the Foreign side executes transfer to unlock the tokens.

It is important to have the check on the Token Management contract side to make sure that the requests to unlock/mint tokens come from the bridge contract.

Also it is necessary to have extra functionality to provide an example of ability to transfer ordinary ERC20 tokens through the bridge. For this the Token Management contract must have a special method (e.g. relayTokens) that could be used in the following flow:

• the end user inokes approve of the token contract specifying the Token Management contract address.
• the end user inokes relayTokens of the Token Management contract address with the amount of tokens which less or equal the amount from the previous item
• the Token Management contract checks that the transaction is within the limits, calls transferFrom of the token contract and executes requireToPassMessage on the Bridge contract.

[patitonar]

Here are two questions that came to my mind about the implementation:

the Token Management contract checks that the transaction is within the limits and mints the corresponding number of tokens as per the initial request

1- How should we proceed in the case of the transaction is above the execution limits? Should we add some mecanism similar to OverdrawManagement contract? The only issue I see is that in this case we don't have the reference transaction hash from the other side. Some possible solution and that could serve to other use cases is to expose the transaction hash reference in the AMB bridge similar as we do with messageSender parameter.

2- Should we add some mecanism to unlock tokens if for some reason the AMB does not procces a message? or processed it but the the execution failed (maybe because the gas limit specified was small)?

[akolotov]

@patitonar thanks for questions:

1. I tried to think of several approaches how we can avoid exposing the transaction hash and do not see any good way. So, let's implement a method similar to messageSender. Later, if we develop a synchronization of limits we can return back to this question - probably, we can think of more effective way.
2. No, we don't need to think about this scenario so far.

[akolotov]

@patitonar I think I have found an issue with the current approach: if a message call (to mint/unlock tokens) will be failed after confirmations by validators, tokens will be locked (or burnt) on another side of the bridge forever. It will lead to imbalance of the bridge. It is due to the fact that we agreed to not revert entire transaction appeared after validators confirmation.