[SMR-1727] Map token L1

[Benjimmutable]

This is the first PR for bridge smart contracts that interface with the Axelar Network.

• Ticket: https://immutable.atlassian.net/browse/SMR-1727

Motivation

Before a token gets bridged, we want to establish a mapping of L1 Token Address => L2 Token Address on both Root Chain and Child Chain. To do this, we want to send a Map Token message.

• This pattern is taken from the Edge bridge contracts.
• This pattern is not necessary. You could likely still get away with using the Clones.predictDeterministicAddress function on every bridge operation, but then complexities are introduced in regards to determining if you need to deploy an ERC20 token to that address (i.e. on the first bridge), if the correct SC is deployed there, etc.
  • Therefore, I believe it to be better to just establish a clear mapping/deploy first and enjoy the guarantees that come with that.

Changes

This PR is only for the L1 message sending. L2 message receiving will be in a follow up PR.

The rough architecture currently will be as follows:

Justification for Adaptor

The underlying communication protocol may change. Using the adaptor pattern is a modular way that allows us to replace the underlying message passing logic without having to upgrade the bridge contract directly. It also allows us to decouple vendor-specific messaging logic from the bridge logic.

The Adaptor is not made to be upgradeable. This is because the only state it holds is config details (smart contract addresses), it only acts as a middleman message passer, and it is trivial to redeploy a new one and set the adaptor to the new contract.

Feel free to challenge this.

Also worth mentioning that any logic + data checks that are agnostic to the underlying message passing protocol should be done in the RootERC20Bridge contract, and anything specific to the Axelar message passing protocol should be in the Axelar adaptor.

Prior Art

I copied and took inspiration as much as possible from the Edge Root Bridge contract. The child chain message receiving will be inspired/copied from here.

Pausability

Pausing or anything similar is not introduced in this PR. Given that this is just a PoC I did not spend too much time thinking about this, but it will definitely be something that is scrutinised heavily, and is important to consider, in the near future.

Owner role

There is currently an Ownable2Step role. Again, given that this is just a PoC I did not spend too much time thinking about RBAC but ownership of this contract will definitely be something that is scrutinised heavily in the near future.

[drinkcoffee]

Sentence in description seemed to stop part way through: "This is because the only state it holds is"

[drinkcoffee]

@Benjimmutable , this PR is stale. Are you still actively working on this? Should this PR be abandoned?