Overview
This post is concerned with the delay of the runtime upgrade 3 for Altair, which was planed to be executed this week. The upgrade will allow users to participate in governance actions, like for example voting council members or submit council candidacies.
Unfortunately, we have to delay the upgrade until the end of the next week. The reason for this is that we faced issues during testing the upgrade that came from the current polkadot version (polkadot-v0.9.12) being used by Kusama validators.
This resulted in the cessation in the production blocks on the Altair development environment, or in the best cases really unreliable block production.
The upgrade cannot occur until there is a solution to this issue.
Once Kusama validators upgrade their nodes to the just released polkadot-v0.9.13 version, the runtime upgrade will be executed, enabling the named democracy features.
Detailed Explanation
The following section describes the reasons for the issues during the upgrade in more detail.
The issues Centrifuge, and other parachain teams like Acala faced, were linked to the relay-chain nodes that a parachain connects to. These relay-chain nodes are not within our control and we cannot change them.
The normal runtime-upgrade process can be split into three steps.
- The parachain signals its intend to change the runtime (either via
setCodeor viaenactAuthorizedUpgradefor a previously authorized upgrade) - The relay-chain builds a new artifact of this wasm in order to verify future state-changes
- Both parachain and relay-chain use the new wasm for computing new states.
Step 3 usually happens after a delay of $n$-blocks, where $n$ is defined by the relay-chain.
The issues parachains faced with the current polkadot version are related to step 2. In theses cases, building of the new artifact takes too long, which results in the worker of the relay-chain being terminated and an empty artifact being stored in the validators database.
Unfortunately, the relay-chain does not try to rebuild artifacts (in the current version) and the relay-chain and parachain can not come to consensus about the next state of the parachain from this point onwards. Resulting in the stopping of block production on the parachain side, as collators try to propose the same block over and over again.
Updated Timeline
We will execute RTU3 mid next week to give as much time as possible to Kusama validators to have their nodes updated to Polkadot V0.9.13.
We will notify in this forum when we do and more details about it.
Conclusion
Using bleeding-edge technology sometimes makes processes slower and timelines unpredictable.
We as a team will always be as cautious as possible when deploying new features for the sake of the safety of the network.