Add experimental GMP Precompile [Moonbase only]

[notlesh]

Overiew

This PR adds a precompile designed to work with GMP ("General Message Passing") protocols such that a user can perform a single interaction with such a protocol in order to bridge tokens across Moonbeam to other parachains via XCM.

                                                          +------------+
                                                          |  Polkadot  |
                                                          |            |
                                                          |            |
                                                          |            |
                                                          +------------+
                                                                ^
                                                                |
   +------------+                        +------------+         |         +------------+
   |  Non-Polka |                        |  Moonbeam  |                   | Other Para |
   |   chain    | ---> GMP protocol ---> |            | -----> XCM -----> |            |
   |            |                        | * GMP      |                   |            |
   |            |                        |  precompile|                   |            |
   +------------+                        +------------+                   +------------+

In the above diagram, a user on a non-Polkadot related chain could use an existing GMP protocol to interact with any XCM-connected chain of Moonbeam with a single interaction. They do so by:

1. Specifying Moonbeam as the target chain and the GMP precompile as the target account
2. Providing a payload which tells the GMP precompile what the next destination is

The result is that the existing GMP protocol will deliver tokens/messages to the GMP precompile which will forward them via XCM to some other para/relay chain.

Initial work

This first push provides a sketch of how things might work with Wormhole's "Contract Controlled Transfers," and is meant for early testing on moonbase.

Specifically, it provides a single function which can be called to complete an inbound Wormhole bridge transfer. There are a lot of parameters which govern how a Wormhole bridge transfer can occur, and this aims to support only one of them. This case is handled in the Test local Wormhole ts test written by @crystalin (thanks!)

Current restrictions

The current release really only supports a "happy path."

• transferred token must be a foreign chain (its token_chain must not be "our" chain)
• a Wormhole-wrapped version of the transferred token will be used (both on Moonbeam and XCM destination chains)
  • this wrapper ERC20 will need to be registered with the bridge contract
  • the destination XCM chain will need to accept this token as well
• any errors result in a revert, which leaves tokens trapped
• there is no fee mechanism supported; no one is compensated for EVM or XCM fees, nor are they incentivized to relay any messages between networks

Future Work

Some of the larger features planned for the future:

• Fee mechanism (to compensate for EVM/XCM fees and to incentivize relayers)
• XCM calls (as opposed to simple token transfers)
• Improved events and error handling
• Multiple protocols

TODO

• More tests
• Ensure xtokens events are emitted (or some other XCM-send related events)
• Gas accounting
• Support configuration of contract addresses
• Code clean up

[librelois]

I made a first pass on the rust part only, I don't see any security issue, but the current design seems to me very inefficient.

I suggest to replace xtokens by sending directly an XCM message with the following content:

Xcm(vec![
  ReserveAssetDeposited(MultiAssets::from(vec![asset, feeAsset])),
  ClearOrigin,
  BuyExecution {
    fees: feeAsset,
    weight_limit: WeightLimit::Unlimited
  },
  DepositAssets {
    assets: AllCounted(2),
    beneficiary: recipient,
  }
])

[girazoki]

Even if the VAA is generic, we expect it to have some shape related to xtokens. Maybe we can specify it here?

[notlesh]

I'm not sure what you mean. Are you referring to the way a user specifies what XCM interaction (e.g. target MultiLocation for xtokens)? That would be defined in types.rs with VersionedUserAction, which does need some better documentation at some point...

[girazoki]

@librelois the approach of sending the message would only work with local tokens (ERC20s or local assets or the native token), at least with the message you proposed. I am not sure if xc20s is a use case we want to support here.

If we are clear on the fact that we are only sending local tokens, then the approach suggested by @librelois would be more efficient. We just transfer the ERC20 directly to the sovereign account, then send the aforementioned message. Note this is a bit riskier, as you bypass the limits imposed by the xcm-executor when sending messages. I would like to have a very good reason to do this, e.g., the efficiency gain being significant.

That being said, I dont think this change implies any change in the interface, so we could very well merge the PR as is as a first iteration

[librelois]

@girazoki from my understanding, the current GMP implemenation already deal only with local ERC20 assets, more precisely wrapped assets created by wormhole. And I think that all future GMP protocols will only deal with local ERC20.

[notlesh]

@girazoki from my understanding, the current GMP implemenation already deal only with local ERC20 assets, more precisely wrapped assets created by wormhole. And I think that all future GMP protocols will only deal with local ERC20.

I think this is a good hunch, but I'd rather not limit us to that just yet. It's also possible that we might want to automatically unwrap certain tokens before sending them (much better for fungibility than having yet-another-wrapped-token).

Also, there are other cases (such as transferring GLMR, not supported in this PR) that wouldn't involve a strict ERC20 impl.

That being said, I dont think this change implies any change in the interface, so we could very well merge the PR as is as a first iteration

Agreed -- this is something we can follow up on. I think we need a better understanding of the use cases we want to support as well as the other protocols before doing so.