-
Notifications
You must be signed in to change notification settings - Fork 829
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Paras
authorize code_hash for (force_)set_current_code
feature
#7592
base: master
Are you sure you want to change the base?
Conversation
/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 Subweight results:
Command output:✅ Successful benchmarks of runtimes/pallets: |
// TODO: FAIL-CI - more validations? | ||
// do we need to check against `FutureCodeHash`, `CodeHashRef`, | ||
// `PastCodeHash`,... code hashes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a reason. force_set_code_hash
will still do further checks and reject if the authorized code is incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, do_force_set_current_code_update
or force_set_current_code
does not do any validations.
So the only validation is here "if code is authorized".
I have the only doubt here:
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?
/// triggering the same functionality as `force_set_current_code`. | ||
#[pallet::call_index(10)] | ||
#[pallet::weight(<T as Config>::WeightInfo::apply_authorized_force_set_current_code(new_code.0.len() as u32))] | ||
pub fn apply_authorized_force_set_current_code( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could use the feeless_if
attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could use the
feeless_if
attribute.
I don't see much example of feeless_if
, but iiuc it can do calculation just based on the inputs?
Or should I do something like:
#[pallet::feeless_if(|_: &OriginFor<T>, para: ParaId, validation_code: ValidationCode| -> bool {
// check that the code was applied
Self::current_code(para) == Some(validation_code.hash())
})]
But this way, we allow spamming the chain for free, because I cannot check Self::current_code(para)
before and after.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because I cannot check Self::current_code(para) before and after.
What you mean by this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, the purpose of using feeless_if
here was to allow free execution when the code is actually applied, essentially the same effect as the PostDispatchInfo
hack at the end (which should be removed when using feeless_if
):
let post = PostDispatchInfo {
// Consume the rest of the block to prevent further transactions
actual_weight: Some(T::BlockWeights::get().max_block),
// No fee for a valid upgrade
pays_fee: Pays::No,
};
Ok(post)
However, in this case, the PostDispatchInfo
hack is applied after validations, when do_force_set_current_code_update
is actually executed.
Is this really enough? Is it ok to access storage and calculate hash again inside feeless_if
?
#[pallet::feeless_if(|_: &OriginFor<T>, para: ParaId, validation_code: ValidationCode| -> bool {
// check that the code was applied
Self::current_code(para) == Some(validation_code.hash())
})]
because I cannot check Self::current_code(para) before and after.
Forget about it, I'm probably overthinking. My idea was to check the result of the extrinsic inside #[pallet::feeless_if]
, something like (but that's not possible):
let code_before = Self::current_code(para);
.. wait extrinsic to do the job
let code_after = Self::current_code(para);
if code_before ! code_after {
PaysFee::No
} else {
PaysFee::Yes
}
In other words, I’m not sure how to properly use feeless_if
here. 😅
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Bastian Köcher <git@kchr.de>
All GitHub workflows were cancelled due to failure one of the required jobs. |
/cmd fmt |
Closes: #7574
Relates to: #7591
This feature can be useful when we want to trigger
Paras::force_set_current_code(para, code)
from a different chain than the one where theParas
pallet is deployed.The main reason is to avoid transferring the entire
new_code
wasm blob between chains.Instead, we authorize
new_code_hash
withroot
, which can later be applied byParas::apply_authorized_force_set_current_code(para, new_code)
by anyone.Open questions
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?