Introduce a transaction extension version

[bkchr]

This RFC proposes to introduce a transaction extensions version. It is proposed to piggyback on RFC84 to not require a new extrinsic format version. With this RFC it will be possible to change the transaction extensions without breaking the extrinsic format of a chain and thus, staying backwards compatible.

[muharem]

If there is a new version, the client still has to support it, and the tx with old version and extension set is invalid for the runtime.
Thus the version only helps a client to prepare in advance for the new extension set.
I think the same can be achieved by a client with a chain's metadata, since it contains the list of extensions identifiers.
What am I missing?

[bkchr]

If there is a new version, the client still has to support it, and the tx with old version and extension set is invalid for the runtime.

No. The runtime would basically introduce code like this:

match extension_version {
   1 => (Ext1),
   2 => (Ext1, Ext2),
}

(highly simplified :P)

Then the runtime can decode correctly using the correct set of extensions.

I think the same can be achieved by a client with a chain's metadata, since it contains the list of extensions identifiers.
What am I missing?

If you for example introduce a new transaction extension that the client doesn't know, it can not encode the correct transaction.

[muharem]

@bkchr make sense to me. runtime basically will support at least a previous version for some time if there is no security concern. may be worth mentioning this in the RFC.

[bkchr]

may be worth mentioning this in the RFC.

@muharem added a sentence. Do you think this is enough or should I add more details?

[ggwpez]

Looks good. Just naming nits.

[bkchr]

/rfc propose

[paritytech-rfc-bot]

Hey @bkchr, here is a link you can use to create the referendum aiming to approve this RFC number 0099.

Instructions

1. Open the link.

2. Switch to the Submission tab.

3. Adjust the transaction if needed (for example, the proposal Origin).

4. Submit the Transaction

---

It is based on commit hash ed7f6784fd498648fd5ec51b55569f1661a47157.

The proposed remark text is: RFC_APPROVE(0099,7a44a11883527adcccc8bcbe09c7d1a27cdd816118fb9dae1ca56a0f593eeead).

[bkchr]

/rfc propose

[paritytech-rfc-bot]

Hey @bkchr, here is a link you can use to create the referendum aiming to approve this RFC number 0099.

Instructions

1. Open the link.

2. Switch to the Submission tab.

3. Adjust the transaction if needed (for example, the proposal Origin).

4. Submit the Transaction

---

It is based on commit hash 03fdf39991a1da18835fc3ae2cf4ce849d47e74b.

The proposed remark text is: RFC_APPROVE(0099,5459271b6b59d0c9337c12e0b631da8a2bd5f58e4eee91894c2a2b12eeb860d5).

[github-actions]

Voting for this referenda is ongoing.

Vote for it here

[github-actions]

PR can be merged.

Write the following command to trigger the bot

/rfc process 0x5cc6611824cd9f2da84db94f15d931476598834f0f073f0618c795f78ee815f8

[shawntabrizi]

/rfc process 0x5cc6611824cd9f2da84db94f15d931476598834f0f073f0618c795f78ee815f8

[paritytech-rfc-bot]

The on-chain referendum has approved the RFC.

[gui1117]

Should this transaction extension version be part of the inherited implications, and also signed payload?
So that signature inside a transaction extension, and signature for signed transaction can sign for a specific transaction extension.
Otherwise there can be some conflict between multiple version, a transaction could be valid but with different effect for different set of extensions. And user can't be able to sign for a specific version.

EDIT: we shoud probably sign for a specific extension version. we can bring a new transaction extension in system for this.

[bkchr]

Good point. I don't think we should add an extra extension for this. The version should be part of the signature. While this actually raises the question on what we do for general transactions.

[carlosala]

I don't think we should add an extra extension for this.

I agree. It has to be part of the signing payload.