Multichain friendly account abstraction

The ForeignChainAliasAccount has been deprecated, however this is an API deprecation, not a deprecation of the overall strategy or account ID derivations. As the comments in the new PR point out, as well as the deprecation notice itself, the exact same behaviour can be introduced into your runtime by using the new “descriptions” system: specifically HashedDescription<AccountId, LegacyDescribeForeignChainAccount>:

The advantage with using the descriptions system is that is it modular and extensible. It allows any locations to be eventually standardised and folded in securely. For now we have just added PalletInstance, but others can follow. It can also be composed in order to allow hierarchical patterns to be used.

There is the potential for overlap in foreign chain account ID aliases; if we are to have an ecosystem-wide foreign account ID derivation system, then my preference would be to move over to a pure HashedDescription<AccountId, DescribeFamily<DescribeAllTerminal>> definition.

However, if there is already substantial ecosystem take up of the ForeignChainAliasAccount encoding in production chains and a desire to have the same encoding for the same relations ecosystem-wide, then we could also arrive at a slightly dirtier but backwards compatible HashedDescription<AccountId, (LegacyDescribeForeignChainAccount, DescribeFamily<DescribeAllTerminal>)>. I defaulted to the cleaner variant on Asset Hub since a) it’s not clear to me that a single ecosystem-wide foreign-chain account derivation path is necessarily a sensible thing to enter into right now; and b) it’s not clear that there is production usage of ForeignChainAliasAccount anyway.

2 Likes