# Please Upgrade Parachains to At Least Runtime v0.9.12

The current upgrade sequence is based on the block counting. In a nutshell, a parachain block signals that it wants to apply the new validation code that is embedded in this parachain block. When this block gets included then upgrade will be scheduled at a specific block we refer as `expected_at`. Each parablock is built referencing some relay-chain block which we call `relay-parent`. When a parablock with `relay-parent` ≥ `expected_at` is included, then the upgrade is applied, and the following parablock will be validated against the new validation code. At the same time, the parablock with `relay-parent` ≥ `expected_at` on the cumulus side will actually set the `:code` to the new runtime code. So this mechanism really depends that both parties know exactly when the upgrade takes place.

Unfortunately, this mechanism is not that flexible and it actively interferes with what we actually want to do.

Specifically, there are two things we want to do:

- PVF Pre-checking
- Off critical path upgrades.

PVF pre-checking is a mechanism that will make all PVFs, be it upgrading or onboarding, to go through a special vetting process conducted by validators. In a nutshell, every validator from the active validator set will fetch the PVF, check it locally whether it works for them and then submit a vote on-chain according to its opinion. If 2/3 of validators from the active set decide that the PVF is legit then it will be accepted and the upgrade or onboarding can go ahead. Otherwise, it will aborted. More on that in the issue [#3211](https://github.com/paritytech/polkadot/issues/3211)

This voting part can take as much as handful of blocks or can stretch to several sessions. We could fit this into our current time-based upgrade mechanism, but we will have to make every upgrade to take two sessions. It is unnecessary too long, considering that most of the time the voting can conclude quite quick.

The off critical path upgrades is the idea is that parachain blocks should not contain the validation code. This is because technically those upgrades are located in the `CandidateCommitments` data structure and those fly back and forth. This is also completely unnecessary. It is just an artifact of the first MVP version.

Ideally, parachain just only signals the upgrade via some hash and some meatbag just uploads the pre-image directly to the relay-chain eventually. The meatbag can upload right away after the signal from parachain or it can take quite some time. We are having the same problem again, with the current upgrade construction relay-chain and the parachain need to know the block exactly. We will have to again balance between giving enough time to upload the PVF pre-image (risking aborting the upgrade process and thus wasting the resources spent for the attempt) and decreasing the delay between signaling and applying the upgrade.

So that's why we decided to change the mechanism for the upgrade. Instead of synchronizing it based on counting a fixed number of blocks, we can make the relay-chain in charge of the upgrade process and just signal when the parachain should perform the upgrade. The astute readers may have also noticed that the upgrade process is now abortable as well, so the new mechanism should account for that.

This new mechanism was dubbed "Go ahead signal" and was landed on cumulus runtime runtime in [#517](https://github.com/paritytech/cumulus/pull/517). This PR was included in 0.9.12, which is why parachains should to be migrated to _at least_ 0.9.12. Parachain teams can also just go and cherry-pick this PR if they feel brave or lucky.

Now as to why this is being pushed this now, is because this PVF pre-checking is around the corner and is ready to be getting landed, and parachains upgrading will get rid of the blocker for the off critical path upgrades (even though they have less priority now).

(thanks to Sergei for the explanations)