Impose new restrictions on paras init and cleanup (#4360)
* Impose new restrictions on paras init and cleanup For upcoming PVF pre-checking feature we will need to impose a couple of new restrictions for: - `schedule_para_initialize`. - `schedule_para_cleanup`. Specifically, for the former we do not want to allow registration of wasm blob that is empty, i.e. 0 bytes. While that currently already does not make a lot of sense, it allows us to simplify the PVF pre-checking logic: if this PR is deployed before the following changes for PVF prechecking then we can be sure that no paras onboarding have to have to go through the PVF pre-checking. In case, we deploy it altogether this property will allow us to distingush paras that came in before PVF pre-checking. For `schedule_para_cleanup` we do not want to allow offboarding of paras that are undergoing the upgrade process. While this is not a harsh restriction this change allows us to avoid making the PVF prechecking more complicated than it has to be. * Add a test for schedule_para_initialize * Link to `ParaLifecycle::is_stable` in docs. * `schedule_para_{init,cleanup}` docs Now they link to their original declarations in the pallet for more details.
Showing
- polkadot/runtime/common/src/paras_registrar.rs 3 additions, 0 deletionspolkadot/runtime/common/src/paras_registrar.rs
- polkadot/runtime/parachains/src/lib.rs 4 additions, 0 deletionspolkadot/runtime/parachains/src/lib.rs
- polkadot/runtime/parachains/src/paras.rs 70 additions, 32 deletionspolkadot/runtime/parachains/src/paras.rs
- polkadot/runtime/parachains/src/scheduler.rs 1 addition, 1 deletionpolkadot/runtime/parachains/src/scheduler.rs
Please register or sign in to comment