[FRAME] Introduce `TransactionExtension` (V2 SE)

[ggwpez]

@gavofyork proposed an overhaul of the current SignedExtension to allow for a few new things; called TransactionExtension. The key points that should be possible with the new solution are:

• Arbitrary origin conversion in the form of Option<Origin> -> Option<Origin> by pre_validate.
• Attaching additional data to unsigned TX (this is important to make good use of the origin conversion).
• Removing the distinction between signed and unsigned TX and instead moving the signature check into a TE.
• Merging pre_dispatch_unsigned/pre_dispatch and validate_unsigned/validate.

Concretely, this would mean that pre_dispatch would change like this:

 	fn pre_dispatch(
 		self,
-		who: &Self::AccountId,
+		who: &Option<<Self::Call as Dispatchable>::RuntimeOrigin>,
 		call: &Self::Call,
 		info: &DispatchInfoOf<Self::Call>,
 		len: usize,
-	) -> Result<Self::Pre, TransactionValidityError>;
+	) -> Result<(Self::Pre, Option<<Self::Call as Dispatchable>::RuntimeOrigin>), TransactionValidityError>;

In the process of this we will probably bump the transaction version. Gav considered to keep it backwards compatible by a TE that can read the old signatures, but it was discarded since we would need to keep this compatibility TE forever until we decide to bump the TX version. Having the 6 months deprecation cycle is preferred here.

cc @bkchr @gupnik

[xlc]

Please at least allow parachains to be able to be backwards compatible.

[ggwpez]

There will be a simple SE -> TE adapter type, so that SEs can still be used as before.

[xlc]

Just to confirm, we won't be forced to bump tx version after 6 months deprecation cycle is completed?

[ggwpez]

Just to confirm, we won't be forced to bump tx version after 6 months deprecation cycle is completed?

I think the plan is to bump the TX version eventually on the Relay and System Parachains. AFAICT it should be possible to keep a runtime in compatibility mode indefinitely if a parachain wants to (lets wait for Gav to give some opinion).

[xlc]

I don't really care about Relay and System Parachains tx bump. But I want to be my own pace for tx bump of Acala/Karura. It costs a sizeable money and multiple months for a new ledger app to be developed, audited, reviewed, and released. There has to be a very good reason to justify all those cost.

We also have a long term plan of the metadata proof work so the compatibility mode only need to be maintained until that's completed.

[bkchr]

• Arbitrary origin conversion in the form of Option<Origin> -> Option<Origin> by pre_validate.

  • Attaching additional data to unsigned TX (this is important to make good use of the origin conversion).

Can you give some examples? Especially on origin conversion.

I don't really care about Relay and System Parachains tx bump.

I think you and @ggwpez are talking past each other. The version bump that would be required here, would be inside of UncheckedExtrinsic and declares the format of the underlying extrinsic. (below FRAME)

[ggwpez]

Can you give some examples? Especially on origin conversion.

An extrinsic comes in as origin None and is then promoted to Some(AccountId) after checking the unsigned additional data. The unsigned data could be a third-party identity scheme.

[bkchr]

Hmm sounds like we could also use this for some kind of voucher system to send "free" transaction 🤔

[ggwpez]

Yep and things like paying the TX fee by the proxied account (instead of the proxier) were mentiond by Gav as well. Should also work for multisig.

[gupnik]

Yep and things like paying the TX fee by the proxied account (instead of the proxier) were mentiond by Gav as well. Should also work for multisig.

@ggwpez Just to understand this better, what would be the current way of achieving this?

[bkchr]

#348