You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's imagine a simple scenario where a sibling parachain of AssetHub wants to create/register an asset on AssetHub's foreign assets instance, which uses xcm::v3::Location as the AssetId:
impl pallet_assets::Config<ForeignAssetsInstance> for Runtime {
type AssetId = xcm::v3::Location;
type AssetIdParameter = xcm::v3::Location;
This means that the sibling needs to construct an XCM Transact with an encoded call that uses xcm::v3::Location:
Now, let's imagine we upgrade AssetHub to use xcm::v4::Location. At this point, the sibling parachain could encounter problems if it doesn't upgrade at the same time as AssetHub. And also upgrading at the "same" time is not 100%, because there could be some (e.g. HRMP) messages on the way. The real issue could arise if the new XCM version used by AssetHub has encoding/decoding that is incompatible with the older version. Essentially, AssetHub would be unable to decode the Transact's encoded call and would discard the messages.
Solution
I suggest changing pallet_assets:
- type AssetIdParameter: Parameter + From<Self::AssetId> + Into<Self::AssetId>
+ type AssetIdParameter: Parameter + TryFrom<Self::AssetId> + TryInto<Self::AssetId>
This could escalate to enable setting up the runtime like this:
impl pallet_assets::Config<ForeignAssetsInstance> for Runtime {
...
type AssetId = xcm::v3::Location;
type AssetIdParameter = VersionedLocation;
...
AssetIdParameter is used for extrinsic parameters. Therefore, if it were VersionedLocation, external users, such as wallets or sibling parachains, wouldn’t need to make any changes when a new XCM version is released.
Additionally, there is an unwritten consensus that we should use VersionedLocation for extrinsic parameters.
Yes, this solution is a kind of 'best-effort' approach and assumes that we can convert/decode older XCM Location versions to the new one.
The text was updated successfully, but these errors were encountered:
Relates to old comment: #1130 (comment)
Relates to: #4826 (new XCMv5)
Potential problem
Let's imagine a simple scenario where a sibling parachain of AssetHub wants to create/register an asset on AssetHub's foreign assets instance, which uses
xcm::v3::Location
as theAssetId
:This means that the sibling needs to construct an XCM
Transact
with an encoded call that usesxcm::v3::Location
:Now, let's imagine we upgrade AssetHub to use
xcm::v4::Location
. At this point, the sibling parachain could encounter problems if it doesn't upgrade at the same time as AssetHub. And also upgrading at the "same" time is not 100%, because there could be some (e.g. HRMP) messages on the way. The real issue could arise if the new XCM version used by AssetHub has encoding/decoding that is incompatible with the older version. Essentially, AssetHub would be unable to decode theTransact
's encoded call and would discard the messages.Solution
I suggest changing
pallet_assets
:This could escalate to enable setting up the runtime like this:
AssetIdParameter
is used for extrinsic parameters. Therefore, if it wereVersionedLocation
, external users, such as wallets or sibling parachains, wouldn’t need to make any changes when a new XCM version is released.Additionally, there is an unwritten consensus that we should use
VersionedLocation
for extrinsic parameters.Yes, this solution is a kind of 'best-effort' approach and assumes that we can convert/decode older XCM
Location
versions to the new one.The text was updated successfully, but these errors were encountered: