feat: align LocationToAccountId derivation

[mustermeiszer]

In order to allow other chains to have consistent "remote" accounts in other chains, it is needed that all chains in the ecosystem derive accounts in the XCM logic in the same way.

See https://forum.polkadot.network/t/multichain-friendly-account-abstraction/1298/23

This PR aligns all runtimes of system-parachains to have that derivation. It is debatable whether this derivation should also go into the relay-chain runtimes.

[mustermeiszer]

The formatting changes are due to running rustfmt on the changed files. Not sure, but it seems they are not formatted according to this repos fmt rule in the first place, or my formatter is doing something odly.

Nevermind, ran it with +nightly --all

[mustermeiszer]

Ping @KiChjang

[KiChjang]

Why wouldn't you want to do this on relay chain runtimes?

[mustermeiszer]

Why wouldn't you want to do this on relay chain runtimes?

I would like to have that on the relay too. Just thought, this would give more backslash.

[mustermeiszer]

@KiChjang what is needed to get this closed and when could we expect this to be live in the networks?

[KiChjang]

I'm only a rank 2 member, so I can't actually approve and merge PRs that touch runtime files. According to the rules set here, you'll want to grab the attention of 4 members with a rank of 3 or higher to approve and merge this.

[mustermeiszer]

cc @gavofyork

[mustermeiszer]

cc @xlc @bkchr @rphmeier @shawntabrizi

[rphmeier]

@mustermeiszer thanks for the ping.

It looks like this is attempting to solve a similar problem to https://github.com/polkadot-fellows/RFCs/pull/34/files which has just been redrafted by @arrudagates . I'm not deep into the details of XCM but at an initial review they seem orthogonal. Let's discuss, but in case RFC 34 is conflicting and more suitable here, we should look to get that approved and then apply here rather than merging this change in the meantime and then changing it.

[mustermeiszer]

Thanks for the info and message @rphmeier and sorry that it took me 10 days to answer. Takes more focus and time than I always expect when trying to understand what actually is happening underneath in XCM.

I asked my questions in the RFC polkadot-fellows/RFCs#34 (comment). Nevertheless, as we have already deployed the previous supported approach, we kind of have already decided to not support that. I do not really see a way to support both approaches in the ecosystem and we are looked IIUC.

As you said, they seem orthogonal.

[mustermeiszer]

@rphmeier rfc polkadot-fellows/RFCs#34 (comment) seems to be stalling a bit. What would be your proposed way forward here?

Kusama Asset-Hub already has the proposed derivation scheme in production (see), of course arguing for my own case here. ^^

In general, we need clarity about the derivation scheme in the ecosystem, this would help us a lot ensuring higher security for large token transfers as we can act all the time from our own parachain, customizing the behaviour we want there.

[mustermeiszer]

Sorry for pinging again. I would really appreciate a convo on this. Our assumption at Centrifuge was that this PR made by @gavofyork would be the way forward to have a general purpose account derivation scheme in xcm, so that parachain users can have safe native-like accounts on all other chains in the ecosystem.

It would be really beneficial to have the same derivation on the system parachains so that we can start building logic for that. Given that Kusama Asset-Hub already supports the here proposed derivation I would argue having the same derivation in the other chains makes sense.

[acatangiu]

AFAICT this PR is a non-controversial subset of polkadot-fellows/RFCs#34. Changes themselves are correct and not doing anything controversial.

Review rules have recently changed.
@mustermeiszer you should rebase, get latest main and rules.
@KiChjang your review should also count afterwards, you might need to submit it again though.

[mustermeiszer]

@acatangiu thanks for the feedback and comment! PR is rebased now.

[mustermeiszer]

@rphmeier according to the rfc statement, there seems to be no conflict between the rfc and this pr.

Under these circumstances do you agree with the approvals here? I would like to merge this, so we can move forward and implement using this derivation.

[mustermeiszer]

Rebased and ready to go in: @sorpaas @KiChjang @xlc @acatangiu @shaunxw @rphmeier @gavofyork

[bkchr]

/merge

[fellowship-merge-bot]

Enabled auto-merge in Pull Request

Available commands

• /merge: Enables auto-merge for Pull Request
• /merge cancel: Cancels auto-merge for Pull Request
• /merge help: Shows this menu

For more information see the documentation