10000 Upgrade Polkadot and Kusama to XCM v5 by claravanstaden · Pull Request #753 · polkadot-fellows/runtimes · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Upgrade Polkadot and Kusama to XCM v5 #753

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

claravanstaden
Copy link
Contributor
@claravanstaden claravanstade 10000 n commented Jun 5, 2025

Upgrades Kusama and Polkadot AssetHub and BridgeHub to use XCM V5. Adds a no-migration to check that changing ForeignAssets and AssetConversion pallets to XCM V5 do not wreck storage.

@acatangiu acatangiu moved this from Todo to In Progress in Runtime releases Jun 6, 2025
@claravanstaden claravanstaden marked this pull request as ready for review June 9, 2025 12:30
// See the License for the specific language governing permissions and
// limitations under the License.

pub mod migration {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This module is generic, and can be reused for Polkadot and Kusama AssetHub. I couldn't mind a common place to put it in this repo though, so I copied the module for now.

@claravanstaden
Copy link
Contributor Author

@yrong @alistair-singh @vgeddes please review. :)


// Test Asset storage items
for (asset_id, _asset_details) in
pallet_assets::Asset::<T, crate::ForeignAssetsInstance>::iter()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if using TryFrom::try_from isn't too late.
I'm thinking: if someone reads the storage directly (e.g., some DApps or wallets - which unfortunately they probably do), will it still produce the same result?

Maybe we could do some direct storage decode/encode comparison, for example, something like the very pseudocode below:

        // Define storage alias with xcm::v4 for pallet_assets::Asset
        #[frame_support::storage_alias]
	pub type AssetAsV4<T: Config<I>, I: 'static = ()> = StorageMap<
		pallet_assets::Pallet<T, I>,
		Blake2_128Concat,
		xcm::v4::Location,  // <- use storage alias with xcm::v4
		AssetDetails<T::Balance, T::AccountId, DepositBalanceOf<T, I>>,
	>;

        // Define storage alias with xcm::v5 for pallet_assets::Asset
        #[frame_support::storage_alias]
	pub type AssetAsV5<T: Config<I>, I: 'static = ()> = StorageMap<
		pallet_assets::Pallet<T, I>,
		Blake2_128Concat,
		xcm::v5::Location,  // <- use storage alias with xcm::v5
		AssetDetails<T::Balance, T::AccountId, DepositBalanceOf<T, I>>,
	>;

        // Compare that the both storage aliases decode/encode to the same keys/values
        assert_eq!(
                AssetAsV4::iter_keys(),
                AssetAsV5::iter_keys()
        );

Copy link
Contributor Author
@claravanstaden claravanstaden Jun 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @bkontur! #[frame_support::storage_alias] needs to match the storage item name exactly (Asset), otherwise it doesn't work. So I can only get one version of XCM using #[frame_support::storage_alias]. Maybe that is OK? Then I use it to get version 4, since the pallet is already using v5?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can wrap with submodules for example

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I changed the migration the way you suggested.

{
let v5_location: xcm::v5::Location = asset_id.clone().into();
let v4_location: xcm::v4::Location =
xcm::v4::Location::try_from(v5_location.clone()).unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And another question is, do we want to break runtime upgrade here?

From the docs:

	/// Similar to [`Hooks::on_initialize`], any code in this block is mandatory and MUST execute.
	/// It is strongly recommended to dry-run the execution of these hooks using
	/// [try-runtime-cli](https://github.com/paritytech/try-runtime-cli) to ensure they will not
	/// produce and overweight block which can brick your chain. Use with care!

I would better not use unwrap and assert_eq here.

Maybe this comparision/check could be done just with pre_uprade / post_upgrade offchain check.

And we don't need to even implement fn on_runtime_upgrade here, because it has default impl:

fn on_runtime_upgrade() -> Weight {
        Weight::from_parts(20, 0)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea! Done.

@@ -64,26 +64,26 @@ use xcm_executor::{traits::ConvertLocation, XcmExecutor};
parameter_types! {
pub const RootLocation: Location = Location::here();
pub const DotLocation: Location = Location::parent();
pub const DotLocationV4: xcm::v4::Location = xcm::v4::Location::parent();
pub const DotLocationV4: xcm::v5::Location = xcm::v5::Location::parent();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the name be DotLocationV5?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, fixed!

Comment on lines 83 to 86
pub PoolAssetsPalletLocationV5: xcm::v5::Location =
xcm::v5::Junction::PalletInstance(<PoolAssets as PalletInfoAccess>::index() as u8).into();
pub PoolAssetsPalletLocationV4: xcm::v5::Location =
xcm::v5::Junction::PalletInstance(<PoolAssets as PalletInfoAccess>::index() as u8).into();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this duplicated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

Comment on lines 26 to 30
parameter_types! {
pub EthereumNetworkXcmV4: xcm::v4::NetworkId = xcm::v4::NetworkId::Ethereum { chain_id: 1 };
pub WethLocationXcmV4: xcm::v4::Location = xcm::v4::Location::new(2, [xcm::v4::Junction::GlobalConsensus(EthereumNetworkXcmV4::get()), xcm::v4::Junction::AccountKey20 { network: None, key: WETH }]);
pub EthLocationXcmV4: xcm::v4::Location = xcm::v4::Location::new(2, [xcm::v4::Junction::GlobalConsensus(EthereumNetworkXcmV4::get())]);
pub EthereumNetworkXcmV5: xcm::v5::NetworkId = xcm::v5::NetworkId::Ethereum { chain_id: 1 };
pub WethLocationXcmV5: xcm::v5::Location = xcm::v5::Location::new(2, [xcm::v5::Junction::GlobalConsensus(EthereumNetworkXcmV5::get()), xcm::v5::Junction::AccountKey20 { network: None, key: WETH }]);
pub EthLocationXcmV5: xcm::v5::Location = xcm::v5::Location::new(2, [xcm::v5::Junction::GlobalConsensus(EthereumNetworkXcmV5::get())]);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit curious - seems we explicitly specify the XCM version everywhere in the codebase, why not just import it globally, something like:

use xcm::opaque::v5::{*}
... 
pub EthereumNetwork = NetworkId::Ethereum { chain_id: 1 };
pub WethLocation =  Location::new(2, [Junction::GlobalConsensus(EthereumNetwork::get()),Junction::AccountKey20 { network: None, key: WETH }]);
pub EthLocation =  Location::new(2, [Junction::GlobalConsensus(EthereumNetwork::get())]);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, we should remove all these versioned names and just use xcm::latest::*

this ^ was always the plan but because we didn't add the right migrations at the pallet-level, we ended up doing migrations at the runtime level and having to differentiate between versions at the runtime level

my plan is that by the time XCMv6 comes out, we have pallet-level migrations and runtimes can always use xcm::latest::* - so let's work in that direction starting now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I changed everything to xcm::latest::*.

@@ -64,26 +64,26 @@ use xcm_executor::{traits::ConvertLocation, XcmExecutor};
parameter_types! {
pub const RootLocation: Location = Location::here();
pub const DotLocation: Location = Location::parent();
pub const DotLocationV4: xcm::v4::Location = xcm::v4::Location::parent();
pub const DotLocationV4: xcm::v5::Location = xcm::v5::Location::parent();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same thing as pub const DotLocation: Location = Location::parent(); above

Suggested change
pub const DotLocationV4: xcm::v5::Location = xcm::v5::Location::parent();

# Conflicts:
#	CHANGELOG.md
@claravanstaden
Copy link
Contributor Author

@bkontur @acatangiu @yrong I have made all the requested changes, please review again.

# Conflicts:
#	system-parachains/asset-hubs/asset-hub-kusama/src/lib.rs
#	system-parachains/asset-hubs/asset-hub-polkadot/src/lib.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

4 participants
0