[AHM] opt-in custom account migration mapping - useful for migrating derived accounts

[acatangiu]

There is already a discussion for recovering derived accounts that don't derive to the same value on Relay and AH, and thus cannot be automatically/correctly migrated.

This is proposing a complementary mechanism where "origins" (any type of account) on the Relay chain can explicitly opt-in to register a target account on AH to be used during the migration.

e.g. Entity X controls RX multisig or proxy account on Relay chain. They want those funds to be automatically migrated to AHX account on AH during AHM.
Anytime before the migration they call an ensure_signed() extrinsic on Relay and provide the desired AHX target account.

Before migration they can keep using RX, and after migration they switch to using AHX without having to coordinate and move funds themselves pre-migration, or to recover the account on AH post-migration.

This would be especially useful in the case of Parachain SAs holding DOT reserves. A parachain's SA on Relay is derived using different seed than their SA on AH, therefore the end AccountId32 bytes don't match. So the reserves will not be automatically migrated (or they will but to the wrong account on AH and then they have to recover through #526).

For parachains it's also difficult for them to migrate the funds themselves before the migration, or to recover after the migration because of multiple reasons:

• challenge to time gov proposals across multiple chains
• introduces windows where stuff might not work (e.g. if para offers liquid staking of DOT, it needs to keep their DOT reserve on the same chain as staking)
• UIs coordination becomes complicated if different chains switch at different times

Using the mechanism described here, parachains can "preregister" their migration target any time before the migration and AHM takes care of coordination and consistency.

[bkchr]

This would be especially useful in the case of Parachain SAs holding DOT reserves. A parachain's SA on Relay is derived using different seed than their SA on AH, therefore the end AccountId32 bytes don't match. So the reserves will not be automatically migrated (or they will but to the wrong account on AH and then they have to recover through #526).

Especially for Parachain SAs we know them, can calculate the new SA address on AH and do the migration automatically. I don't get why we want to have done this manually.

[acatangiu]

Especially for Parachain SAs we know them, can calculate the new SA address on AH and do the migration automatically. I don't get why we want to have done this manually.

Radical trustlessness "we don't touch your funds" 😆 - but yeah, I agree for known/registered parachains' SAs we should just auto-map and migrate them to AH without them having to take any explicit action.

The explicit registration mechanism can still be used for any type of other derived account or even proxies?

[xlc]

The number of ways to derive account is known so it should be possible to simply ensure each of them can be correctly mapped on AH.

[acatangiu]

The number of ways to derive account is known so it should be possible to simply ensure each of them can be correctly mapped on AH.

Yes, but the "source"s of the accounts are infinite and by just looking at accounts you cannot tell if they're derived or signed.

A user (signed account) on a parachain, or a SmartContract on some parachain might have some funds in their SA on the Relay Chain.
Derivation is a one-way function. There is no way for us to know that that account is actually a derivation of { parents: 0, X2(Parachain(bla), AccountId(Dave)) } or some SC or some PalletIndex or etc.

But that user or SC could register for the correct migration using the mechanism described by this issue - not guaranteeing that anybody actually will register 🙈

[xlc]

What I meant is we can preserve the same derivation mechanism on AH. So if a key can access an address on relay, we allow it to access the same address on AH

[acatangiu]

That would be ideal, but how?

For example, XCM locations are derived using DescribeFamily which produces different derivations on Relay vs AH for same universal location (non-relative location).

It is a "legacy" problem when someone originally decided to differentiate between "child" and "sibling" locations - which IMO should've never been done.

But the reality is that the same account on Acala has different derivation for its SA on Relay "parent" vs other "sibling" parachains (including AH).

we can preserve the same derivation mechanism on AH

and we can't change existing derivation mechanism on AH (to match Relay one) as it will break existing SAs mapping

[xlc]

one way is add a new hint to determine the derivative format and parachain can set such hint if they want to use the relay account
parachain still need to make changes but that’s minimal and they have to change the message destination from relay to AH anyway

[bkchr]

Or we could introduce a permissionless migration function. Basically it only allows to migrate from Relay to AH. Then we can write some script that does the migration on chain. For the parachain accounts I would still do the on chain migration, as we know all of them.

[acatangiu]

Or we could introduce a permissionless migration function. Basically it only allows to migrate from Relay to AH. Then we can write some script that does the migration on chain.

I don't understand this. How is it permissionless, how do you enforce this permissionless fn only touches stuff the caller owns?

For the parachain accounts I would still do the on chain migration, as we know all of them.

Definitely! there is full consensus on this.

one way is add a new hint to determine the derivative format and parachain can set such hint if they want to use the relay account
parachain still need to make changes but that’s minimal and they have to change the message destination from relay to AH anyway

Adds complexity forever since we'll have to support this hack/workaround forever.
I'm also against perpetuating these inconsistent derivations even further. After AHM (long-term), we get rid of Relay chain accounts and on parachains everyone derives the same way, so finally we'll have more consistency.