`apply_authorized_upgrade`: Remote authorization if the version check fails by bkchr · Pull Request #7812 · paritytech/polkadot-sdk

bkchr · 2025-03-05T21:59:39Z

This pr ensures that we remove the authorization for a runtime upgrade if the version check failed. If that check is failing, it means that the runtime upgrade is invalid and the check will never succeed.

Besides that the pr is doing some clean ups.

This pr implements the `feeless_if` feature for `apply_authorized_upgrade`. The call would be feeless if the given code is authorized. Besides that the pr is doing some clean ups.

bkchr · 2025-03-05T22:00:01Z

/cmd prdoc --audience runtime_user --bump major

…mp major'

bkontur · 2025-03-05T23:45:12Z

substrate/frame/system/src/lib.rs

 		/// All origins are allowed.
 		#[pallet::call_index(11)]
 		#[pallet::weight((T::SystemWeightInfo::apply_authorized_upgrade(), DispatchClass::Operational))]
+		#[pallet::feeless_if(|_: &OriginFor<T>, code: &Vec<u8>| -> bool {


Nice! Finally, a real usage example. I will also adjust my PR accordingly.

But iiuc, feeless_if won't work unless we add SkipCheckIfFeeless and pallet_skip_feeless_payment to the runtimes, right? Please see my related questions here: #7592 (comment).

So, iiuc, feeless_if won't have any effect without SkipCheckIfFeeless, but in this case, execution will still be free because of pays_fee: Pays::No, correct?

Next, if we add SkipCheckIfFeeless and pallet_skip_feeless_payment, and we change DispatchResultWithPostInfo to DispatchResult, then we no longer need the PostDispatchInfo { pays_fee: Pays::No, ... } code, right? (Probably because of prevent further transactions we want to keep it as it is here)

And lastly, when we make feeless_if + SkipCheckIfFeeless work with TransactionExtensions, how does it behave in the case of an extrinsic error? For example, if feeless_if passes and returns true, but fn apply_authorized_upgrade(..) fails on Self::can_set_code(..), will the user still be charged, or will it remain free?

But iiuc, feeless_if won't work unless we add SkipCheckIfFeeless and pallet_skip_feeless_payment to the runtimes, right? Please see my related questions here: #7592 (comment).

Yes feeless_if is effective only if SkipCheckIfFeeless is used, usually wrapping the transaction payment extension.

So, iiuc, feeless_if won't have any effect without SkipCheckIfFeeless, but in this case, execution will still be free because of pays_fee: Pays::No, correct?

It would be free only if successful, people will have to pay for it, and they get refunded at the end of the transaction if is successful.

Next, if we add SkipCheckIfFeeless and pallet_skip_feeless_payment, and we change DispatchResultWithPostInfo to DispatchResult, then we no longer need the PostDispatchInfo { pays_fee: Pays::No, ... } code, right? (Probably because of prevent further transactions we want to keep it as it is here)

Yes, but it doesn't harm.

And lastly, when we make feeless_if + SkipCheckIfFeeless work with TransactionExtensions, how does it behave in the case of an extrinsic error? For example, if feeless_if passes and returns true, but fn apply_authorized_upgrade(..) fails on Self::can_set_code(..), will the user still be charged, or will it remain free?

if feeless_if passes, the user is never charged, (the transaction payment happens in the transaction extension in prepare phase, this payment will be skipped).
So if the transaction fails the changes in the call dispatch is reverted. So probably people will be able to spam a failing transaction for free.
Signer will not be charged after the failing of the transaction.

@gui1117 Thank you :)

So if the transaction fails the changes in the call dispatch is reverted. So probably people will be able to spam a failing transaction for free.
Signer will not be charged after the failing of the transaction.

This is exactly what I was worried about :), but we probably just need to ensure that feeless_if is correct and covers all the necessary validations, right?

Also, another thing, here we are using/expecting an unsigned call: ValidateUnsigned::validate_unsigned(Call::apply_authorized_upgrade(..)). So, is this the spam protection mechanism that it doesn’t even add call to the transaction pool?

will the user still be charged, or will it remain free?

If this fails, it is not because of the guy who tried to apply the authorized call, it is because of the one who wanted authorized some incorrect upgrade.

georgepisaltu

The inherent problem of feeless_if is that it does the check for call validity twice, once in the feeless_if closure called on the SkipCheckIfFeeless extension wrapping the tx fee extension, and then it must do the checks again inside the call, otherwise it may be spammable. If the feeless_if check fails, all it does is charge the fee, so it is mandatory that the checks are done again in the call.

We have a better approach for these free transactions using the authorized mechanism, soon to be introduced in #6324. You can see it addressing the issue of this PR in this draft implementation here.

After the last 3 remaining PRs related to this mechanic are merged, we should deprecate SkipCheckIfFeeless altogether and use the new mechanic. I don't think there's anything wrong in this PR but I don't see a reason to merge it considering we have a better solution already drafted.

bkchr · 2025-03-06T11:22:44Z

We have a better approach for these free transactions using the authorized mechanism, soon to be introduced in #6324. You can see it addressing the issue of this PR in this draft implementation here.

Your draft implementation there is not correct. Like you are checking the version in the is_authorized call, which is not a great idea.

bkchr · 2025-03-06T11:23:14Z

But yeah, I will remove the feeless_if stuff and just merge the rest of the code changes.

bkchr · 2025-03-06T12:59:10Z

@bkontur @georgepisaltu @gui1117 as I have you here now, please review :D

…stuff'

paritytech-workflow-stopper · 2025-03-06T19:58:14Z

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13706992656
Failed job name: fmt

gui1117 · 2025-03-07T01:34:41Z

substrate/frame/system/src/lib.rs

 		fn validate_unsigned(_source: TransactionSource, call: &Self::Call) -> TransactionValidity {
 			if let Call::apply_authorized_upgrade { ref code } = call {
-				if let Ok(hash) = Self::validate_authorized_upgrade(&code[..]) {
+				if let Ok(res) = Self::validate_code_is_authorized(&code[..]) {


If a migration is ongoing, the call will fail, and here we don't test for it. But at the same time, if a migration is ongoing it is impossible to dispatch the transaction, so we are fine.

The call is still valid. We are not testing here if the call will not error, we never do this.

Yes, but failing code is roll-backed, so people can spam the chain with this failing code for free, it is better to avoid.
But here we are fine.
And also in any case, the provides being unique, I think it can't spam the transaction pool, only one per block would then be included. But still validator could fill the block with useless extrinsic and the fees would go up.

I wouldn't say a replayable free failing call is valid.

EDIT: Maybe it is useful to keep it around in the transaction pool until it can dispatched, I guess the correct implementation would be to mark it as invalid: Future.

You should not upload invalid wasm files that would fail this check :)

Also the code is now changed to remove the authorization if someone tried and the version check failed. So, you can only send this once.

the check I was talking about is T::MultiBlockMigrator::ongoing()

polkadot-sdk/substrate/frame/system/src/lib.rs

Lines 2269 to 2271 in 007565a

if T::MultiBlockMigrator::ongoing() {

return CanSetCodeResult::MultiBlockMigrationsOngoing

}

Not about the version check.

Hmm yeah okay, good point.

apply_authorized_upgrade: Implement feeless_if

cd05afc

This pr implements the `feeless_if` feature for `apply_authorized_upgrade`. The call would be feeless if the given code is authorized. Besides that the pr is doing some clean ups.

bkchr added the T2-pallets This PR/Issue is related to a particular pallet. label Mar 5, 2025

bkchr requested a review from a team as a code owner March 5, 2025 21:59

github-actions bot and others added 2 commits March 5, 2025 22:02

Update from bkchr running command 'prdoc --audience runtime_user --bu…

0342b1b

…mp major'

Fix compile error

408daab

bkontur reviewed Mar 5, 2025

View reviewed changes

bkontur approved these changes Mar 5, 2025

View reviewed changes

bkontur mentioned this pull request Mar 6, 2025

Check/setup SkipCheckIfFeeless for #[pallet::feeless_if(..)] for runtimes #7815

Closed

4 tasks

georgepisaltu reviewed Mar 6, 2025

View reviewed changes

Remote feeless_if and some other things

dfc6b4e

bkchr changed the title ~~apply_authorized_upgrade: Implement feeless_if~~ apply_authorized_upgrade: Remote authorization if the version check fails Mar 6, 2025

bkchr added 2 commits March 6, 2025 13:55

Update pr_7812.prdoc

7e1e963

Update pr_7812.prdoc

4ee3329

bkontur approved these changes Mar 6, 2025

View reviewed changes

georgepisaltu approved these changes Mar 6, 2025

View reviewed changes

bkchr added 2 commits March 6, 2025 20:52

Fix test

908768e

Merge remote-tracking branch 'refs/remotes/origin/bkchr-code-upgrade-…

bcd1ab5

…stuff'

AHHHH

562f352

bkchr requested a review from gui1117 March 6, 2025 20:31

Merge branch 'master' into bkchr-code-upgrade-stuff

ba30ae3

bkchr enabled auto-merge March 6, 2025 21:21

gui1117 approved these changes Mar 7, 2025

View reviewed changes

bkchr added this pull request to the merge queue Mar 7, 2025

github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 7, 2025

bkchr added this pull request to the merge queue Mar 7, 2025

Merged via the queue into master with commit 6ce9948 Mar 7, 2025
250 of 255 checks passed

bkchr deleted the bkchr-code-upgrade-stuff branch March 7, 2025 11:08

bkontur mentioned this pull request Mar 12, 2025

Add Paras authorize_code_hash + apply_authorized_code feature #7592

Merged

6 tasks

ggwpez mentioned this pull request Jun 4, 2025

Bump to stable2503 polkadot-fellows/runtimes#711

Merged

7 tasks

github-actions bot mentioned this pull request Jun 10, 2025

Update polkadot-sdk from stable2412 to stable2503 moondance-labs/tanssi#1087

Closed

This was referenced Jul 16, 2025

Update polkadot-sdk from stable2412 to stable2503 moonbeam-foundation/moonbeam#3362

Closed

Update polkadot-sdk from stable2412 to stable2503-7 moonbeam-foundation/moonbeam#3363

Closed

pgherveou added this to [preview] release tracker Mar 20, 2026

github-project-automation bot moved this to Done in [preview] release tracker Mar 20, 2026

pgherveou removed this from [preview] release tracker Mar 20, 2026

pgherveou added this to [preview] release tracker Mar 23, 2026

github-project-automation bot moved this to Todo in [preview] release tracker Mar 23, 2026

github-project-automation bot moved this from Todo to Done in [preview] release tracker Mar 23, 2026

	if T::MultiBlockMigrator::ongoing() {
	return CanSetCodeResult::MultiBlockMigrationsOngoing
	}

Conversation

bkchr commented Mar 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bkchr commented Mar 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

georgepisaltu left a comment

Choose a reason for hiding this comment

Uh oh!

bkchr commented Mar 6, 2025

Uh oh!

bkchr commented Mar 6, 2025

Uh oh!

bkchr commented Mar 6, 2025

Uh oh!

paritytech-workflow-stopper bot commented Mar 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gui1117 Mar 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

bkchr commented Mar 5, 2025 •

edited

Loading

gui1117 Mar 10, 2025 •

edited

Loading