CheckOnlySudoAccount: Provide some tags

[bkchr]

Close: #7816

[bkchr]

/cmd prdoc --audience runtime_user --bump patch

[paritytech-workflow-stopper]

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

[gui1117]

Sometimes tag are prefixed to avoid collision, but here it is not necessary.

Suggested change

	provides: vec![(who, call).encode()],
	provides: vec![("Sudo", who, call).encode()],

[michalkucharczyk]

dq: is call guaranteed to be unique here?
Otherwise we won't be able to send numerous sudo calls (with the same operation, e.g.: I can imagine someone calling same sudo operation few times like transfer funds).

[clangenb]

AFAIU it is not, but for chains that also have the CheckNonce extension there is another unique tag provided. A chain with only the CheckOnlySudoAccount extension but without CheckNonce will have to work around this uniqueness guarantee (e.g., batch transactions).

[s0me0ne-unkn0wn]

dq: is call guaranteed to be unique here?
Otherwise we won't be able to send numerous sudo calls

Fair enough. Does it help, say, to add the block number here?

[clangenb]

Hmm, not really I suppose, as it is going to be the identical too for the duration of one block. If the inherents are available, we could add the timestamp though.

[s0me0ne-unkn0wn]

as it is going to be the identical too for the duration of one block

True, but being able to make the same sudo calls once per block is better than not being able to do them at all 🤔

[michalkucharczyk]

but for chains that also have the CheckNonce

So I assume that chains w/o CheckNonce are rather for development purpose. And typically runtime should provide other mean to distinguish transaction sent from the same account, not necessarily responsibility of the sudo itself.

We could use hash of call to avoid sending all the bytes across a runtime boundary, also txpool will have smaller amount of data to track.

[bkchr]

I can imagine someone calling same sudo operation few times like transfer funds

Always to the same address?

[bkchr]

Someone would need to send the exact same call multiple times. Just sending multiple transfer calls is not the same. Each call has the arguments directly "baked in".

[michalkucharczyk]

Yes, I meant exactly the same call - for transfer that would be same amount, same address.

[bkchr]

I see this happening quite unlikely.

[clangenb]

It will only close the #7816 if you also remove the CheckNonce TxExtension from glutton, but it unblocks the issue at least. ;)

[gui1117]

We could also add a sufficient reference to the signer here automatically. Sounds cleaner than removing CheckNonce.

[bkchr]

What you mean by this?

[gui1117]

We remove CheckNonce because CheckNonce requires the account to exist.

But if we put CheckOnlySudoAccount before CheckNonce and CheckOnlySudoAccount creates the account with inc_sufficient (if it doesn't exist yet):

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

Line 1656 in 007565a

pub fn inc_sufficients(who: &T::AccountId) -> IncRefStatus {

Then the account exists and the nonce is checked.

[bkchr]

And when is dec_sufficients called? :D

[gui1117]

yes true forget it :-), he could live forever