Special Motion (#0): Restore council and other pallets by a runtime storage migration

hangyin · 2 January 2022 07:05

This is a special motion with an id of zero. Due to the missed storage migration at runtime 1090, the council and a few other pallets cannot recognize the storage any more. So the id of this motion is reset to zero. This motion and the corresponding runtime upgrade v1091 aim to fix it.

To learn the details, please refer to:

github.com/Phala-Network/phala-blockchain

Runtime level storage migration

opened 10:10AM - 28 Dec 21 UTC

h4x3rotab

In the past, we assume the storage migrations are always handled by the `on_runt…ime_upgrade` hooks in the pallet. However this is not the approach adopted by Polkadot. Instead, they write the runtime-level migration to trigger the logic defined in each pallets. I consider this approach better. A lot of pallets come from FRAME. They will be upgraded when we update the substrate dependencies. In this case, we always want to be aware of any storage migration rather than to have it executed silently. By manually trigger the storage migration, we can be sure what migrations will be executed on each runtime release. On the other hand, it becomes a problem that the downstream may miss some migrations. For instance, Khala v1090 was upgraded from substrate v0.9.10 to v0.9.13, which requires the migration of Council, TechnicalCommittee, Tips, and Bounties. As a result, the pallets were broken after the upgrade. As a short term solution, we can follow a strict process before each runtime release to check the required storage migrations, and only release after the full test. The process is still error prone. So in long term, we should have some post-upgrade check to ensure all the pallets is at the correct storage version. Ideally every pallet should do the self-check. So maybe it's a good idea to implement at Substrate. This issue tracks: - [ ] The fix of the Khala v1090 upgrade accident https://github.com/Phala-Network/khala-parachain/pull/54 - [ ] Solution to prevent from missing some future storage migrations

The plan to fix the problem:

Use the current temporary Council to designate HashForest as the temporary Technical Committee member
Use the current temporary Council and the Technical Committee to apply a fast track runtime upgrade (v1091) to trigger the runtime upgrade
After the runtime upgrade, the storage migration will restore all the past data to override the temporary Council and the Technical Committee
Notify the indexers (subsquare) to rescan the council proposals

This motion contains a batch call:

The proposalHash refers to this preimage (on subscan), which can be decoded to the runtime upgrade:

To learn more about the runtime upgrade v1091, please refer to the Github release page.