Xcm to be able to use distinct origins based on different calls

[girazoki]

We are facing a current limitation in Moonbeam with the xcm-executor. We want to be able to execute the Transact instruction with our pallets but we are encountering a problem with pallet-ethereum from Frontier. This pallet requires a specific origin (not the regular RawOrigin::Signed).

The xcm-executor currently converts a MultiLocation to a dispatch Origin in https://github.com/paritytech/polkadot/blob/016dc7297101710db0483ab6ef199e244dff711d/xcm/xcm-executor/src/lib.rs#L343 through the ConvertOrigin trait, but it does not take into account the call being made and therefore it is not possible for us to append a customized origin in the case of pallet-ethereum.

We have a few ideas to solve this:

• Allows to customize how calls are dispatched from XCM polkadot#5657. This allows us to control how the dispatchable is dispatched, and therefore we can append the desired origin based on the call made.
• Another possibility is to add the call to the ConvertOrigin::convert_origin.
• We tried circumventing this by using custom filters in our custom CheckedExtrinsic and our custom Applyable frait implementation but this does not work with pallet-proxy or pallet-multisig, since both of them clear the filters before dispatching.

Any ideas besides those already commented? Thanks in advance!

[crystalin]

Maybe having an "authorization-based" mechanism attached to the origin could also be used for a safe check (considering some pallets are resetting the origin) but that would require some heavy rework I think.

@bkchr what do you think overall?

[bkchr]

• Allows to customize how calls are dispatched from XCM paritytech/polkadot#5657. This allows us to control how the dispatchable is dispatched, and therefore we can append the desired origin based on the call made.

This looks like a reasonable approach to me.

CC @gavofyork @KiChjang

[KiChjang]

paritytech/polkadot#5657 is merged, so this issue can be considered fixed. Closing.