Add Paras authorize_code_hash + apply_authorized_code feature#7592
Add Paras authorize_code_hash + apply_authorized_code feature#7592
Paras authorize_code_hash + apply_authorized_code feature#7592Conversation
|
/cmd fmt |
…-set-current-code
…-set-current-code
…code' into bko-paras-authorize-set-current-code
|
/cmd prdoc --audience runtime_dev --bump patch |
|
/cmd bench --pallet polkadot_runtime_parachains::paras --runtime westend rococo |
|
Command "bench --pallet polkadot_runtime_parachains::paras --runtime westend rococo" has started 🚀 See logs here |
…parachains::paras --runtime westend rococo'
|
Command "bench --pallet polkadot_runtime_parachains::paras --runtime westend rococo" has finished ✅ See logs here DetailsSubweight results:
Command output:✅ Successful benchmarks of runtimes/pallets: |
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Bastian Köcher <git@kchr.de>
|
/cmd fmt |
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
| let code = ValidationCode(vec![0; c as usize]); | ||
| let para_id = ParaId::from(1000); | ||
| let expire_at = | ||
| frame_system::Pallet::<T>::block_number().saturating_add(BlockNumberFor::<T>::from(c)); |
There was a problem hiding this comment.
Seems strange to also use the code size as the expiry time. If we expect this to affect the benchmark, it should be its own parameter, if not should we not just set it to something constant?
| ); | ||
| for para in to_remove { | ||
| AuthorizedCodeHash::<T>::remove(¶); | ||
| weight.saturating_accrue(T::DbWeight::get().writes(1)); |
There was a problem hiding this comment.
Yea I believe @kianenigma looked into this quite a bit for benchmarking MB staking when there were a lot of removals and ended up using a measured weight IIRC
…7592) Closes: #7574 Relates to: #7591 ## Motivation This feature is useful when triggering a `Paras` pallet call from a different chain than the one where the `Paras` pallet is deployed. For example, we may want to send `Paras::force_set_current_code(para, code)` from the Collectives and/or AssetHub to the relay chain (because the relaychain governance will be migrated to the AssetHub as a part of AHM). The primary reason for this approach is to avoid transferring the entire `new_code` Wasm blob between chains. Instead, we authorize the `code_hash` using `root` via `fn authorize_force_set_current_code_hash(new_authorization, expire_at)`. This authorization can later be applied by anyone using `Paras::apply_authorized_force_set_current_code(para, new_code)`. If `expire_at` is reached without the authorization being used, it is automatically removed. ## Usage This feature is intended for use in two scenarios: - The D-Day scenario, where we can restart AssetHub from Collectives — see the PoC: #8141 - Using `force_set_current_code` for any parachain from migrated governance to AssetHub (AHM) ## TODO - [x] ~cover also `add_trusted_validation_code` or `force_schedule_code_upgrade` - see comment bellow: #7592 (comment) no see other [comment](#7592 (comment)) ## Open questions - [ ] ~Do we need something like `poke_authorized_code_hash`? E.g. in case that we authorize code hash, but nobody would apply it and the parachain starts working with old/other_new code? Is this possible?~ - [ ] Do we need something similar for `frame_system` pallet and `set_code` / `set_code_without_checks`? - [ ] Can we achieve the same with `pallet-whitelist`? - [ ] Do we have other extrinsics over chains which has `code` attribute? - [x] Do we need to add `validate_unsigned` for `apply_authorized_code`? --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
This brings in `stable2506` Polkadot SDK, and integrates many new features. Integrated breaking changes to be verified by the original authors: - [x] ~paritytech/polkadot-sdk#8127 @kianenigma @Ank4n~ This will come in with AHM, and not before. - [x] paritytech/polkadot-sdk#7597 @gui1117 - [x] paritytech/polkadot-sdk#8254 @bkchr - [x] paritytech/polkadot-sdk#7592 @bkontur - [x] paritytech/polkadot-sdk#8382 @UtkarshBhardwaj007 - [x] paritytech/polkadot-sdk#8021 @serban300 - [x] paritytech/polkadot-sdk#8344 @serban300 - [x] paritytech/polkadot-sdk#8262 @athei - [x] paritytech/polkadot-sdk#8584 @athei - [x] paritytech/polkadot-sdk#8299 @skunert - [x] paritytech/polkadot-sdk#8652 @pgherveou - [x] paritytech/polkadot-sdk#8554 @pgherveou - [x] paritytech/polkadot-sdk#8281 @mrshiposha - [x] paritytech/polkadot-sdk#7730 @franciscoaguirre - [x] paritytech/polkadot-sdk#8599 @yrong @claravanstaden - [x] paritytech/polkadot-sdk#8531 @bkontur - [x] paritytech/polkadot-sdk#8409 @kianenigma - [x] paritytech/polkadot-sdk#9137 @franciscoaguirre - [x] paritytech/polkadot-sdk#7944 @bkontur - [x] paritytech/polkadot-sdk#8179 @bkontur - [x] paritytech/polkadot-sdk#8037 @yrong --------- Co-authored-by: GitHub Action <action@github.com> Co-authored-by: claravanstaden <claravanstaden64@gmail.com> Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Alain Brenzikofer <alain@integritee.network> Co-authored-by: kianenigma <kian@parity.io> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: ron <yrong1997@gmail.com> Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com> Co-authored-by: Overkillus <maciej.zyszkiewicz@parity.io>
…7592) Closes: #7574 Relates to: #7591 ## Motivation This feature is useful when triggering a `Paras` pallet call from a different chain than the one where the `Paras` pallet is deployed. For example, we may want to send `Paras::force_set_current_code(para, code)` from the Collectives and/or AssetHub to the relay chain (because the relaychain governance will be migrated to the AssetHub as a part of AHM). The primary reason for this approach is to avoid transferring the entire `new_code` Wasm blob between chains. Instead, we authorize the `code_hash` using `root` via `fn authorize_force_set_current_code_hash(new_authorization, expire_at)`. This authorization can later be applied by anyone using `Paras::apply_authorized_force_set_current_code(para, new_code)`. If `expire_at` is reached without the authorization being used, it is automatically removed. ## Usage This feature is intended for use in two scenarios: - The D-Day scenario, where we can restart AssetHub from Collectives — see the PoC: #8141 - Using `force_set_current_code` for any parachain from migrated governance to AssetHub (AHM) ## TODO - [x] ~cover also `add_trusted_validation_code` or `force_schedule_code_upgrade` - see comment bellow: #7592 (comment) no see other [comment](#7592 (comment)) ## Open questions - [ ] ~Do we need something like `poke_authorized_code_hash`? E.g. in case that we authorize code hash, but nobody would apply it and the parachain starts working with old/other_new code? Is this possible?~ - [ ] Do we need something similar for `frame_system` pallet and `set_code` / `set_code_without_checks`? - [ ] Can we achieve the same with `pallet-whitelist`? - [ ] Do we have other extrinsics over chains which has `code` attribute? - [x] Do we need to add `validate_unsigned` for `apply_authorized_code`? --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Closes: #7574
Relates to: #7591
Motivation
This feature is useful when triggering a
Paraspallet call from a different chain than the one where theParaspallet is deployed. For example, we may want to sendParas::force_set_current_code(para, code)from the Collectives and/or AssetHub to the relay chain (because the relaychain governance will be migrated to the AssetHub as a part of AHM).The primary reason for this approach is to avoid transferring the entire
new_codeWasm blob between chains. Instead, we authorize thecode_hashusingrootviafn authorize_force_set_current_code_hash(new_authorization, expire_at). This authorization can later be applied by anyone usingParas::apply_authorized_force_set_current_code(para, new_code). Ifexpire_atis reached without the authorization being used, it is automatically removed.Usage
This feature is intended for use in two scenarios:
force_set_current_codefor any parachain from migrated governance to AssetHub (AHM)TODO
cover alsono see other commentadd_trusted_validation_codeorforce_schedule_code_upgrade- see comment bellow: AddParasauthorize_code_hash+apply_authorized_codefeature #7592 (comment)Open questions
Do we need something likepoke_authorized_code_hash? E.g. in case that we authorize code hash, but nobody would apply it and the parachain starts working with old/other_new code? Is this possible?frame_systempallet andset_code/set_code_without_checks?pallet-whitelist?codeattribute?validate_unsignedforapply_authorized_code?