Introduce Tinkernet multisig XCM configs to Kintsugi

[arrudagates]

This PR adds the XCM configs necessary to allow Tinkernet multisigs to transact on Kintsugi.

Tinkernet multisigs have the following MultiLocation pattern:

MultiLocation {
    parents: _, // ancestry depends on the point of reference. 0 if from parent, 1 if from sibling.
    interior: Junctions::X3(
        Junction::Parachain(2125), // Tinkernet ParaId in Kusama/Rococo.
        Junction::PalletInstance(71), // Pallet INV4, from which the multisigs originate.
        Junction::GeneralIndex(_) // Index from which the multisig account is derived.
    )
}

The following are the configs added by this PR to give the multisigs accounts and origins in Kintsugi:

In Barrier

WithComputedOrigin<
  AllowTopLevelPaidExecutionFrom<invarch_xcm_builder::TinkernetMultisigMultiLocation>,
  UniversalLocation,
  ConstU32<8>,
>,

This is a barrier from the official xcm-builder crate that computes descended origins and by using AllowTopLevelPaidExecution<TinkernetMultisigMultiLocation>> within it allows for our multisig XCM messages to pass through. This is added outside of the Transactless set of barriers, as the goal is to allow these multisigs to transact within the runtime (when properly paying for the transaction fee).

In LocationToAccountId

invarch_xcm_builder::TinkernetMultisigAsAccountId<AccountId>,

This MultiLocation converter derives an AccountId for locations matching the one described above, it does so by using the same exact derivation function used in Tinkernet, this is important to make sure the multisigs maintain the same address across all chains, providing the best UX possible. Because this derivation happens in Kintsugi, it means the whole process is trustless and removes any possibility of account impersonation!

In XcmOriginToTransactDispatchOrigin

invarch_xcm_builder::DeriveOriginFromTinkernetMultisig<RuntimeOrigin>,

Same as explained above, except here we need to derive the AccountId and wrap it with a RawOrigin::Signed origin so this account can use the Transact XCM instruction and thus call extrinsics in the Kintsugi runtime's pallets.

[gregdhill]

I'm reluctant to introduce another third-party dependency, @arrudagates is there anyway to accomplish what you want without adding InvArch-XCM-Builder?

[arrudagates]

I'm reluctant to introduce another third-party dependency, @arrudagates is there anyway to accomplish what you want without adding InvArch-XCM-Builder?

Yes, these are very simple MultiLocation to AccountId and MultiLocation to Origin converters, they can be directly added to the runtime in less than 100 lines.

I'll proceed that way if you prefer, just let me know where you would rather the configs live, if at a specific primitives crate, a specific file/module in the runtime, or directly in the xcm_config.rs file.

[gregdhill]

I think xcm_config.rs is fine, if you make that change we can review.

[arrudagates]

I think xcm_config.rs is fine, if you make that change we can review.

Done! Please let me know if you have any suggestions for changes.

[arrudagates]

Hey @gregdhill, any update on this?