OpenGov Call + Preimage data migration and integrity

[bkontur]

• To migrate the calls of ongoing referenda from RC to AH. Needs to consider the fact that some calls might be provided not inline and instead via a preimage.
• Needs to provide tests to ensure proposals dispatch/execute in the same manner.

To be very pedantic, we can dispatch all proposals pre-migration and post-migration, and inspect the 1. state diff 2. dispatch result. Ideally all would match.

This approach need not be exhaustive. We may let some proposals that are hard to identify, decode, and migrate remain in the RC, and organically fail. Of course, this is not preferred, as for a proposal that has already passed, now it would have to re-gain its approval.

My (@kianenigma) opinion is that we can let most proposals fail as above, and do offchain coordination to help people re-create the same proposals.

In fact, I am not sure what to do about proposals which are only submitted as a hash, but the full call data is not revealed yet.

Other questions, hints

• When we migrate governance to AssetHub, existing preimages/referenda might contain calls to pallet_xcm::send(child_parachain). If these calls are migrated to AssetHub, they will fail because AssetHub cannot send to Location { parent: 0 }.
  • One option is to change Location { parent: 0 } to Location { parent: 1 }, but it's unclear if this is possible since preimages are stored as BoundedVec. Can we modify the decoding to achieve this?
  • Alternatively, we can introduce another XcmRouter as a wrapper over XcmpQueue, which rewrites (0, [Parachain(id)]) to (1, [Parachain(id)]). Another option is to modify XcmpQueue itself to support both (1, [Parachain(id)]) and (0, [Parachain(id)]), which should work.
    • The only potential issue is routing directly to AssetHub, which is currently Here instead of (0, [Parachain(1000)]). However, this can also be addressed using XcmRouters.
• The same applies to preimages/referenda that should be executed on the relay chain, likely for all calls that do not start with pallet_xcm::send(. There are multiple ways to handle these, depending on where the call is supposed to be executed:
  • If the call should be executed on the relay chain (e.g., calls to the paras pallet, which remains on the relay chain), we might need to wrap them with pallet_xcm::send(Parent, ...) ?
  • If the call should be executed on migrated AssetHub pallets, how do we ensure the correct pallet_index for these migrated pallets? Should we modify the calls accordingly?