From 93d2e727e94f3661def48a5ebbc47133148add38 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Wed, 3 Jul 2024 15:47:21 +0200 Subject: [PATCH 1/7] Introduce a transaction extension version This RFC proposes to introduce a transaction extensions version. It is proposed to piggyback on [RFC84](https://github.com/paritytech/polkadot-sdk/issues/2415) 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. --- text/0098-transaction-extension-version.rs | 79 ++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 text/0098-transaction-extension-version.rs diff --git a/text/0098-transaction-extension-version.rs b/text/0098-transaction-extension-version.rs new file mode 100644 index 000000000..8dec99676 --- /dev/null +++ b/text/0098-transaction-extension-version.rs @@ -0,0 +1,79 @@ +# RFC-0098: Introduce a transaction extension version + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | 03 July 2024 | +| **Description** | Introduce a versioning for transaction extensions. | +| **Authors** | Bastian Köcher | + +## Summary + +This RFC proposes a change to the extrinsic format to include a transaction extension version. + +## Motivation + +The extrinsic format supports to be extended with transaction extensions. These transaction extensions are runtime specific and can be different per chain. Each transaction extension can add data to the extrinsic itself or extend the signed payload. +This means that adding a transaction extension is breaking the chain specific extrinsic format. A recent example was the introduction of the [`CheckMetadatHash`](https://github.com/polkadot-fellows/runtimes/pull/337) to Polkadot and all its system chains. +As the extension was adding one byte to the extrinsic, it broke a lot of tooling. By introducing an extra version for the transaction extensions it will be possible to introduce changes to these transaction extensions while still being backwards compatible. +Based on the version of the transaction extensions, each chain runtime could decode the extrinsic correctly and also create the correct signed payload. + +## Stakeholders + +- Runtime users +- Runtime devs +- Wallet devs + +## Explanation + +[RFC84](https://github.com/paritytech/polkadot-sdk/issues/2415) introduced the extrinsic format `5`. The idea is to piggyback onto this change of the extrinsic format to add the extra version for the transaction extensions. If required, this could also come +as extrinsic format `6`, but `5` is not yet deployed anywhere. + +The extrinsic format supports the following types of transactions: +- `Bare`: Does not add anything to the extrinsic. +- `Signed`: `(Address, Signature, Extensions)` +- `General`: `Extensions` + +The `Signed` and `General` transaction would change to: + +- `Signed`: `(Address, Signature, Compact, Extensions)` +- `General`: `(Compact, Extensions)` + +The `Compact` being a SCALE encoded compact representing the version of the transaction extensions. + +## Drawbacks + +This adds a least one byte more to each signed transaction. + +## Testing, Security, and Privacy + +There is no impact on testing, security or privacy. + +## Performance, Ergonomics, and Compatibility + +This will ensure that changes to the transactions extensions can be done in a backwards compatible way. + +### Performance + +There is no performance impact. + +### Ergonomics + +Runtime developers need to take care of the versioning and ensure to bump as required, so that there are no compatibility breaking changes without a bump of the version. It will also add a little bit more code in the runtime +to decode these old versions, but this should be neglectable. + +### Compatibility + +When introduced together with extrinsic format version `5` from [RFC84](https://github.com/paritytech/polkadot-sdk/issues/2415), it can be implemented in a backwards compatible way. So, transactions can still be send using the +old extrinsic format and decoded by the runtime. + +## Prior Art and References + +None. + +## Unresolved Questions + +None. + +## Future Directions and Related Material + +None. From ebe428d34942349845ec59c24c48d5923543b03f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Wed, 3 Jul 2024 15:52:44 +0200 Subject: [PATCH 2/7] It is 99... --- ...tension-version.rs => 0099-transaction-extension-version.rs} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{0098-transaction-extension-version.rs => 0099-transaction-extension-version.rs} (98%) diff --git a/text/0098-transaction-extension-version.rs b/text/0099-transaction-extension-version.rs similarity index 98% rename from text/0098-transaction-extension-version.rs rename to text/0099-transaction-extension-version.rs index 8dec99676..a5d920f8a 100644 --- a/text/0098-transaction-extension-version.rs +++ b/text/0099-transaction-extension-version.rs @@ -1,4 +1,4 @@ -# RFC-0098: Introduce a transaction extension version +# RFC-0099: Introduce a transaction extension version | | | | --------------- | ------------------------------------------------------------------------------------------- | From 66361cc16d4c8957a662e9fda2ad236698bdc808 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Wed, 3 Jul 2024 16:13:57 +0200 Subject: [PATCH 3/7] It is markdown and not rust :see_no_evil: --- ...extension-version.rs => 0099-transaction-extension-version.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0099-transaction-extension-version.rs => 0099-transaction-extension-version.md} (100%) diff --git a/text/0099-transaction-extension-version.rs b/text/0099-transaction-extension-version.md similarity index 100% rename from text/0099-transaction-extension-version.rs rename to text/0099-transaction-extension-version.md From 1d2fe0e4dff1e3af1d1b2e922bace68ebf0cd3a6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Wed, 3 Jul 2024 20:47:50 +0200 Subject: [PATCH 4/7] Mention that the version should be used to determine the set of transaction extensions --- text/0099-transaction-extension-version.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0099-transaction-extension-version.md b/text/0099-transaction-extension-version.md index a5d920f8a..271ce490e 100644 --- a/text/0099-transaction-extension-version.md +++ b/text/0099-transaction-extension-version.md @@ -40,6 +40,8 @@ The `Signed` and `General` transaction would change to: The `Compact` being a SCALE encoded compact representing the version of the transaction extensions. +In the chain runtime the version can be used to determine which set of transaction extensions should be used to decode and to validate the transaction. + ## Drawbacks This adds a least one byte more to each signed transaction. From ed7f6784fd498648fd5ec51b55569f1661a47157 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Wed, 3 Jul 2024 22:26:16 +0200 Subject: [PATCH 5/7] Apply suggestions from code review Co-authored-by: Oliver Tale-Yazdi --- text/0099-transaction-extension-version.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0099-transaction-extension-version.md b/text/0099-transaction-extension-version.md index 271ce490e..2878e573d 100644 --- a/text/0099-transaction-extension-version.md +++ b/text/0099-transaction-extension-version.md @@ -35,10 +35,10 @@ The extrinsic format supports the following types of transactions: The `Signed` and `General` transaction would change to: -- `Signed`: `(Address, Signature, Compact, Extensions)` -- `General`: `(Compact, Extensions)` +- `Signed`: `(Address, Signature, Version, Extensions)` +- `General`: `(Version, Extensions)` -The `Compact` being a SCALE encoded compact representing the version of the transaction extensions. +The `Version` being a SCALE encoded compact `u32` representing the version of the transaction extensions. In the chain runtime the version can be used to determine which set of transaction extensions should be used to decode and to validate the transaction. From 9f52f6ec5f79a646c6ea1e53577de315edbf8598 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Thu, 18 Jul 2024 15:00:27 +0200 Subject: [PATCH 6/7] Update text/0099-transaction-extension-version.md --- text/0099-transaction-extension-version.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0099-transaction-extension-version.md b/text/0099-transaction-extension-version.md index 2878e573d..07e1d86fb 100644 --- a/text/0099-transaction-extension-version.md +++ b/text/0099-transaction-extension-version.md @@ -38,7 +38,7 @@ The `Signed` and `General` transaction would change to: - `Signed`: `(Address, Signature, Version, Extensions)` - `General`: `(Version, Extensions)` -The `Version` being a SCALE encoded compact `u32` representing the version of the transaction extensions. +The `Version` being a SCALE encoded `u8` representing the version of the transaction extensions. In the chain runtime the version can be used to determine which set of transaction extensions should be used to decode and to validate the transaction. From 03fdf39991a1da18835fc3ae2cf4ce849d47e74b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bastian=20K=C3=B6cher?= Date: Thu, 18 Jul 2024 15:01:07 +0200 Subject: [PATCH 7/7] Update text/0099-transaction-extension-version.md --- text/0099-transaction-extension-version.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0099-transaction-extension-version.md b/text/0099-transaction-extension-version.md index 07e1d86fb..c9ea85f45 100644 --- a/text/0099-transaction-extension-version.md +++ b/text/0099-transaction-extension-version.md @@ -44,7 +44,7 @@ In the chain runtime the version can be used to determine which set of transacti ## Drawbacks -This adds a least one byte more to each signed transaction. +This adds one byte more to each signed transaction. ## Testing, Security, and Privacy