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.
Okay, thanks for the explanation. In that case, I think it’s better to switch directly to this new system. On the Moonbeam side, it’s not too late yet, as we hadn’t yet pushed ForeignChainAliasAccount into production, but we were very close to doing so.
I don’t think so, I have checked the code base of some parachains (Acala, Darwinia2, Bifrost, HydraDX), and it seems that most parachains haven’t yet authorized a foreign account ID derivation system (except for sovereign accounts).
It seems to me that there is a desire to standardize this to facilitate the development of eco-system’s dapps and libs used by the eco-system’s dapps.
Moreover, the problem is that once a foreign account derivation path is in production, it’s very difficult to change, because account funds can be held or frozen in many pallets, and such a complex migration can be an unfeasible challenge for parachains with very large storage like moonbeam.
I agree, standardizing this needed. Ideally in a way that is extensible but we absolutely need a way to for a parachain to control multiple accounts on another parachain.
We will implement this according to the new standard proposed by @gavofyork - however I do think we should make sure we use compatible converters across the whole ecosystem. It will become extremely tedious for any tools like wallets, block explorers etc. otherwise.
This will allow other parachain users to have. a dedicated remotely controlled account on Centrifuge. As this does not bear any danger for the receiving parachain I think it would make sense to standardize this derivation.
The main reason is that it would make it much simpler for integrations to reason about the derived accounts on all chains and further enable more use-cases to interact with other parachains without switching networks.
At best especially the system parachains would provide the same derivation. This currently is not the case. Both AssetHub and BridgeHub currently have an insufficient configuration for this (on Polakdot). AssetHub allows no external derived accounts, while BridgeHub only allows for other chains pallets to have a derived account.
The suggestions you have made, such as including XCM transactions for a pure proxy between chains or using a standardized approach such as decentralized identifiers (DIDs) to ensure interoperability and consistency between chains, are valid considerations. These proposals address the challenges of managing credentials and identifiers in a multi-chain environment. However, there is an increasing need to buy proxies for yourself and beyond. Implementing cross-chain functionality for tools such as pure proxies will indeed improve the usability and security of the Polkadot network. It will allow users to seamlessly interact with their accounts across multiple parachains without the risk of losing assets in cross-chain transactions.
