Convert Signed Extensions to Transaction Extensions

[wilwade]

Currently most of our Transaction Extensions use the older Signed Extrinsic pattern. Update all of them

• CheckNonce
• ChargeFrqTransactionPayment
• CheckFreeExtrinsicUse
• HandlesSignedExtension

Needs updates

• tests
• passkey checks
• runtime updates

Resources

• https://forum.polkadot.network/t/introducing-transactionextension/10827

[saraswatpuneet]

Extrinsic Horizon

Check if this is a blocker that would prevent the migration (due to strict separation of concern about origins in TransactionExecution) here for more details

• Currently, unsigned extrinsics (such as our passkey flow) are still validated via ValidateUnsigned, which means the new CheckNonce TransactionExtension does not automatically check or increment the nonce for these transactions.
• If we want to update the nonce for passkey extrinsics, we must do it manually in our pallet logic or within our ValidateUnsigned implementation, since the extension pipeline only handles signed transactions for now.
• Once phase 2 of Extrinsic Horizon lands and ValidateUnsigned is deprecated, we should migrate this logic into a custom TransactionExtension so that nonce management and other checks are handled consistently for all transaction types.

Checking if any actions have been taken but looks like ValidateUnsigned isnt deprecated to new form factor yet,

Looks like there was some work done to move them to General Transaction but reverted

This might be a blocker to reliably migrate without duplicating or deprecating our own implementations for just passkey calls and put in place migrated version for everything else

[saraswatpuneet]

Some suggestions here

That would entail taking some steps of origin is None ( due to enforcement of as system origin signer) maybe have a combination of None and some flag to know if calling tx is passkey

.If you make use of SignedExtension::validate_unsigned or SignedExtension::pre_dispatch_unsigned, then:

Just use the regular versions of these functions instead.
Have your logic execute in the case that the origin is None.
Ensure your transaction creation logic creates a General Transaction rather than a Bare Transaction; this means having to include all TransactionExtensions' data.
ValidateUnsigned can still be used (for now) if you need to be able to construct transactions which contain none of the extension data, however these will be phased out in stage 2 of the Transactions Horizon, so you should consider moving to an extension-centric design.

[aramikm]

It was a while ago when I looked into this and if I'm not wrong I think there was a way to use conditional extensions. So I think we probably want to setup our Passkey extensions to run in passkey origin condition and then we should be able to remove those duplicated ones.