Add simple fee mechanism to GMP precompile

[notlesh]

What does it do?

Adds a very simple fee mechanism to the GMP precompile. Replaces the much more complicated fee system introduced in #2324.

The added fee mechanism comes in the form of a new VersionedUserAction::V2 which is the same as the previous but includes a fee: U256 field. The fee is paid to the caller of the precompile, which is intended to be the txn sender, but doesn't have to be.

⚠️ Breaking Changes ⚠️

• All changes are backwards compatible (so not really breaking...?)
• Adds a new VersionedUserAction variant (V2) which supports a fee
• The old V1 variant continues to work as it did

Design

The fee is specified in the payload itself. The fee is arbitrary from the protocol's perspective; no one enforces any particular minimum fee. If a fee is too low (or 0) then it is likely that no one will want to relay this message for the user. However, the user is free to relay it for themselves in any case.

I expect relayers who wish to collect fees will have some set minimum they are willing to accept as payment, and anything under this they will not participate as a relay for.

Likewise, I expect dapp UIs to guide users on what an acceptable fee might be, similar to the way wallets do so today.

TODO:

• Merge master
• Merge test refactor in this PR with that done in 🧪 dev-test migration to Moonwall #2 #2375

[github-actions]

Coverage generated "Mon Aug 28 18:11:43 UTC 2023":
https://d3ifz9vhxc2wtb.cloudfront.net/pulls/2428/html/index.html

Master coverage: 87.39%
Pull coverage:

[librelois]

I suggest to add a fee_beneficiary field in this V2, it's more flexible.
On useful use case if it's the relayer operator want to receive it's reward on a cold wallet, but it can probably be useful in other cases too.

[notlesh]

I suggest to add a fee_beneficiary field in this V2, it's more flexible. On useful use case if it's the relayer operator want to receive it's reward on a cold wallet, but it can probably be useful in other cases too.

Hmmm, that makes sense to let the relayer control the fee beneficiary, but that would be outside the scope of the payload.

Actors:
user: the one bridging something, which includes creating the payload
guardians: the ones signing the VAA + payload
relayer: the one paying for destination-chain (Moonbeam) fees and submitting txn/VAA/payload

So your suggestion makes sense, but doesn't fit in the payload -- I think we would need to make a separate extrinsic (something obnoxious like wormholeTransferERC20WithFeeBeneficiary) in order to accommodate this.

[librelois]

think we would need to make a separate extrinsic (something obnoxious like wormholeTransferERC20WithFeeBeneficiary) in order to accommodate this.

Ok I see, I think it should not be an extrinsic, but just a precompile selector that take the inner evm call as a parameter

[notlesh]

Ok I see, I think it should not be an extrinsic, but just a precompile selector that take the inner evm call as a parameter

Sorry, to be clear, there is no extrinsic here (there is no pallet and so no pallet calls). You're right, it would be a different precompile function callable from SC.

[albertov19]

I know this got merged, but would it make sense to set a maximum in the fee? This could be controlled via governance or something. Just thinking that building the payload is quite complex and the user could be tricked into a fee that for him would be extremely difficult to verify when signing the tx. So capping it to an arbitrary value could be helpful to avoid any misusage of this feature.

WDYT? Sorry that I'm just providing feature right now 😞

[notlesh]

I know this got merged, but would it make sense to set a maximum in the fee? This could be controlled via governance or something. Just thinking that building the payload is quite complex and the user could be tricked into a fee that for him would be extremely difficult to verify when signing the tx. So capping it to an arbitrary value could be helpful to avoid any misusage of this feature.

WDYT? Sorry that I'm just providing feature right now 😞

Hmmm, I can see why it might be helpful, but it would be a bit tricky. For example, should the maximum be enforced when the message is created or when it's processed through the precompile? (The latter is the only one that seems feasible to me, but isn't a good UX).

A feature like this would come with a perf hit, and would be complicated by the fact that the fee would need to be per-asset.

Also, a note on tricking a user: if someone can trick a user like this, they could do far worse than make them specify a high fee -- more likely they'd get away with stealing their funds by changing the amount and recipient :)

[albertov19]

Also, a note on tricking a user: if someone can trick a user like this, they could do far worse than make them specify a high fee -- more likely they'd get away with stealing their funds by changing the amount and recipient :)

Yeah agreed actually this is a great point, at the end of the day you are already trusting the dApp front-end etc and so on because verifying what you are signing is never straightforward.