config: Add SkipCheckIfFeeless signed extension

[lexnv]

This PR adds the SkipCheckIfFeeless to the signed extensions of subxt.

The extension was introduced in substrate to skip calculating feels if the extrinsics are feeless.

From substrate, the SkipCheckIfFeeless is simply a wrapper over another signed extension.

/// A [`SignedExtension`] that skips the wrapped extension if the dispatchable is feeless.
#[derive(Encode, Decode, Clone, Eq, PartialEq, TypeInfo)]
#[scale_info(skip_type_params(T))]
pub struct SkipCheckIfFeeless<T: Config, S: SignedExtension>(pub S, sp_std::marker::PhantomData<T>);

This extension will forward for encoding whatever extension it wraps.
The extension has implications for the pre_dispatch method where the inner extension is conditionally disabled depending on whether the transaction is feeless or not. As well for the post_dispatch to generate an event specific to the feeless extrinsics named FeeSkipped.

From the subxt perspective, we need to implement our SignedExtension trait for the SkipCheckIfFeeless. Doing so will propagate the extension name that is correlated for decoding purposes and it fixes errors such as:

 Error: ExtrinsicParams(UnknownSignedExtension("SkipCheckIfFeeless"))

Closes #1262

[jsdw]

#[derive(Encode, Decode, Clone, Eq, PartialEq, TypeInfo)]
#[scale_info(skip_type_params(T))]
pub struct SkipCheckIfFeeless<T: Config, S: SignedExtension>(pub S, sp_std::marker::PhantomData<T>);

This implies that the inner signed extension will be encoded into the tx payload; your code doesn't appear to cater for this?

Two cases to consider:

• How would a user configure the ExtraParams to use this, so that they can provide an instance of this with whatever signed ext wrapped inside it?
• How can we decode/skip over the bytes for this reliably, regardless of which signed extension it wraps (we can prob use metadata to skip over the relevant bytes?)

Anyway, back to being away hehe :)

[niklasad1]

This will break polkadot, westend and rococo.

AFAIU, only substrate-node has this so far

[niklasad1]

https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/runtime/westend/src/lib.rs#L836

[jsdw]

AnyOf is clever, and will just ignore signed extensions that aren't used on a given node, so it's always good to add all of the common ones to this list (other comment notwithstanding) :)

What I don't know is; what will it normally wrap? Seems like probably just one of the tip based exts. If it wrapped more than one ext on a chain it'd be an issue cos we match on signed extension name. We can prob assume it'll only one ext on a chain for now.

It might be that configs start to diverge a bit across chains if this is used in different ways. Hopefully we can stick with one nice extrinsic param setting interface for now!

[jsdw]

Ooh and yeah, let's not remove the charge asset one from the list, which I just noticed and maybe that ls what you were saying on second read :)

[niklasad1]

All right, thanks.

So you are saying that we shall have both SkipCheckIfFeeLess and ChargeTransactionPayment here and either is missing the signed extensions it's just ignored, correct?

[jsdw]

Since this can be used with different exts inside, I wonder how easily we could make it use encode_as_type to encode the inner extension based on the metadata. That'd offer extra safety because then we'd get an error if we try to encode an inner signed ext that doesn't match what the node is expecting, whereas without metadata we'd just blindly encode and hope for the best (and prolly get a super obscure decode error back from the node if it's wrong!)

It could enforce that the signed ext impls EncodeAsType too maybe! Not sure :)

[niklasad1]

it didn't work to derive clone for all types instead? :)

[lexnv]

Nope :( I've raised #1268 to track this in the future.

subxt/subxt/src/lib.rs

Lines 231 to 235 in eeacf4b

	/// ## `derive_for_type(path = "...", derive = "...")`
	///
	/// Unlike the above, which derives some trait on every generated type, this attribute allows you to derive traits only
	/// for specific types. Note that any types which are used inside the specified type may also need to derive the same traits.
	///

[niklasad1]

nice