pallet-domains storage migration for "Private EVM"

[teor2345]

TODO

• Merge feature PRs into main
• Bump versions: Sync mainnet runtime versions with taurus versions #3393
• Update the types in this PR to the latest main branch
• Test this migration on a devnet
• Confirm there are no EVM or AutoId domains on Mainnet

How to review this PR

This PR is part of a series of PRs which add "private EVM" functionality to subspace. It upgrades the existing storage formats for this feature.

The Taurus EVM and AutoId domains need this upgrade. Mainnet doesn't need an upgrade at this time, because it doesn't have any EVM or AutoId domains deployed. But doing the upgrade on mainnet is harmless, because it won't find any EVM/AutoId domains, and therefore won't change anything.

What it does

This PR upgrades the domain registry storage into a new format which stores the EVM type and initial contract creation allow list. (Or the AutoId domain config, which is currently empty.)

Code contributor checklist:

• I have read, understood and followed contributing guide

[teor2345]

This PR is up to date, but the diff will be a bit confusing until #3350 merges, and we merge those changes into the taurus-runtime-upgrades

[vedhavyas]

I had a conversation with @dariolina today here is what I have proposed.

Having these migrations specific to taurus defeats the whole purpose of having versioned migrations. We only want the spec_versions to be different from taurus and mainnet for both Consensus and Domains. So whenever we want to upgrade taurus, we can create a temporary branch that just updates the spec_versions.

The rest of the versions such as StorageVersions, Api versions would be part of the main branch.
Since the storage versions of pallet-domains are different in mainnet and taurus, we need to update the domains storage version to latest it needs to be on main and also add these migrations that will be only run taurus.

This will ensure we always write necessary migrations and compatibility code in main itself.

cc: @NingLin-P @teor2345

[teor2345]

I had a conversation with @dariolina today here is what I have proposed.

Having these migrations specific to taurus defeats the whole purpose of having versioned migrations.

Yes, I agree. It also makes it harder for anyone who happens to be running another network like ours (not that there’s anyone yet, but there might be in future).

We only want the spec_versions to be different from taurus and mainnet for both Consensus and Domains. So whenever we want to upgrade taurus, we can create a temporary branch that just updates the spec_versions.

Sounds good.

The rest of the versions such as StorageVersions, Api versions would be part of the main branch. Since the storage versions of pallet-domains are different in mainnet and taurus, we need to update the domains storage version to latest it needs to be on main and also add these migrations that will be only run taurus.

Would you like this version bump as a separate PR? It seems simpler.

This will ensure we always write necessary migrations and compatibility code in main itself.

Yes, I agree, I’ve updated the TODOs on this PR.

[NingLin-P]

LGTM

[vedhavyas]

Would you like this version bump as a separate PR? It seems simpler.

These changes are already in.

But would prefer if you take a moment to check current storage versions of taurus and bump them if required accordingly

[teor2345]

Would you like this version bump as a separate PR? It seems simpler.

These changes are already in.

But would prefer if you take a moment to check current storage versions of taurus and bump them if required accordingly

pallet-domains is on version 2 in the taurus-runtime-upgrades branch, which will change to version 3 when this PR is merged into that branch (or deployed directly to Taurus).