From 380bdbbc551008cf8ca30e2e454adad8bdbf19d5 Mon Sep 17 00:00:00 2001 From: georgepisaltu Date: Fri, 18 Oct 2024 19:25:16 +0300 Subject: [PATCH 1/6] initial extrinsic v5 RFC Signed-off-by: georgepisaltu --- text/0000-extrinsic-version-5.md | 123 +++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 text/0000-extrinsic-version-5.md diff --git a/text/0000-extrinsic-version-5.md b/text/0000-extrinsic-version-5.md new file mode 100644 index 000000000..be418585c --- /dev/null +++ b/text/0000-extrinsic-version-5.md @@ -0,0 +1,123 @@ +# RFC-0000: Extrinsic version 5 + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | 18 October 2024 | +| **Description** | Definition and specification of version 5 extrinsics | +| **Authors** | George Pisaltu | + +## Summary + +This RFC proposes the definition of version 5 extrinsics along with changes to the specification and encoding from version 4. + +## Motivation + +[RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md) introduced the specification of `General` transactions, a new type of extrinsic besides the `Signed` and `Unsigned` variants available previously in version 4. Additionally, [RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md) introduced versioning of transaction extensions through an extra byte in the extrinsic encoding. Both of these changes require an extrinsic format version bump as both the semantics around extensions as well as the actual encoding of extrinsics need to change to accommodate these new features. + +## Stakeholders + +- Runtime users +- Runtime devs +- Wallet devs + +## Explanation + +### Changes to extrinsic authorization + +The introduction of `General` transactions allows the authorization of any and all origins through extensions. This means that, with the appropriate extension, `General` transactions are capable of replicating the same behavior present day v4 `Signed` transactions. Specifically for Polkadot chains, an example implementation for such an extension is `VerifySignature`, introduced in the Transaction Extension [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685). Other extensions can be inserted into the extension pipeline to authorize different custom origins. Therefore, a `Signed` extrinsic variant is redundant to a `General` one strictly in terms of functionality available to users and would eventually need to be deprecated and removed. + +### Encoding format for version 5 + +As with version 4, the encoded v5 extrinsics will still be an array of SCALE encoded bytes, starting with the encoded length of the following bytes. The leading byte will determine the version and type of extrinsic, as specified by [RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md), with the addition that the `Signed` variant will not be supported for v5 extrinsics, for reasons mentioned above. + +NOTE: For `Bare` extrinsics, the following bytes will just be the encoded call and nothing else. + +For `General` transactions, as stated in +[RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md), +an extension version byte must be added in the next extrinsic version. This byte should allow +runtimes to expose more than one set of extensions which can be used for a transaction. As far as +the v5 extrinsic encoding is concerned, this extension byte should be encoded immediately after the +leading encoding byte. The extension version byte should be included in payloads to be signed by all +extensions configured by runtime devs to ensure a user's extension version choice cannot be altered +by third parties. + +After the extension version byte, the extensions will be encoded next, followed by the call itself. + +A quick visualization of the encoding: +- `Bare` extrinsics: `(extrinsic_encoded_len, 0b0000_0101, call)` +- `General` transactions: `(extrinsic_encoded_len, , 0b0100_0101, extension_version_byte, extension, call)` + +### Signatures on Polkadot in General transactions + +As stated before, [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685) comes with a +Transaction Extension which replicates the current `Signed` transactions in v5 extrinsics, namely +`VerifySignature`. This extension leverages the new inherited implication functionality introduced +in `TransactionExtension` and creates a payload to be signed using the data of all extensions after +itself in the extension pipeline. In order to run a transaction with a signed origin, a user must +create the transaction with an instance of the extension which provides a signature. Alternatively, +if users want to use some other origin, they should create the transaction with this particular +extension disabled. More on this behavior in the extension documentation. This extension can be +configured to accept a `MultiSignature`, which makes it compatible with all signature types +currently used in Polkadot. + +To generate the payload to be signed: +1. The extension version byte, call, extension and extension implicit should be encoded; +2. The result of the encoding should then be hashed using the `BLAKE2_256` hasher; +3. The result of the hash should then be signed with the signature type specified in the extension definition. + +```rust +// Step 1: encode the bytes +let encoded = (extension_version_byte, call, transaction_extension, transaction_extension_implicit).encode(); +// Step 2: hash them +let payload = blake2_256(&encoded[..]); +// Step 3: sign the payload +let signature = keyring.sign(&payload[..]); +``` + +### Summary of changes in version 5 + +In order to minimize the number of changes to the extrinsic format version and also to help all consumers downstream in the transition period between these extrinsic versions, we should: +- Remove the `Signed` variant starting with v5 extrinsics +- Add the `General` variant starting with v5 extrinsics +- Enable runtimes to support both v4 and v5 extrinsics + +## Drawbacks + +The metadata will have to accommodate two distinct extrinsic format versions at a given point in time in order to provide the new functionality in a non-breaking way for users and tooling. + +## Testing, Security, and Privacy + +There is no impact on testing, security or privacy. + +## Performance, Ergonomics, and Compatibility + +This change makes the authorization through signatures configurable by runtime devs in version 5 extrinsics, as opposed to version 4 where the signing payload algorithm and signatures were hardcoded. This moves the responsibility of ensuring proper authentication through `TransactionExtension` to the runtime devs, but a sensible default which closely resembles the present day behavior will be provided in `VerifySignature`. + +### Performance + +There is no performance impact. + +### Ergonomics + +Tooling will have to adapt to be able to tell which authorization scheme is used by a particular transaction by decoding the extension and checking which particular `TransactionExtension` in the pipeline is enabled to do the origin authorization. Previously, this was done by simply checking whether the transaction is signed or unsigned, as there was only one method of authentication. + +### Compatibility + +As long as extrinsic version 4 is still exposed in the metadata when version 5 will be introduced, the changes will not break existing infrastructure. This should give enough time for tooling to support version 5 and to remove version 4 in the future. + +## Prior Art and References + +This is a result of the work in [Extrinsic +Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) and +[RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md). + +## Unresolved Questions + +There is no clear way to expose two different extrinsic versions in the current metadata framework. A non-exhaustive list of options discussed so far: +1. Change the `ExtrinsicMetadata` trait to specify a list of versions instead of a single version. +2. Use the custom fields in the metadata to specify the details of the version 5. +3. Create a new trait similar to `ExtrinsicMetadata`, but for future versions of the extrinsic format and add it to the metadata. + +## Future Directions and Related Material + +Following this change, extrinsic version 5 will be introduced as part of the [Extrinsic Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) effort, which will shape future work. From 01bc75854ad5dfbeb8dcb9e724b982732e5a2cfc Mon Sep 17 00:00:00 2001 From: georgepisaltu Date: Fri, 18 Oct 2024 22:27:21 +0300 Subject: [PATCH 2/6] links and formatting Signed-off-by: georgepisaltu --- text/0000-extrinsic-version-5.md | 56 +++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 12 deletions(-) diff --git a/text/0000-extrinsic-version-5.md b/text/0000-extrinsic-version-5.md index be418585c..893940e4d 100644 --- a/text/0000-extrinsic-version-5.md +++ b/text/0000-extrinsic-version-5.md @@ -24,11 +24,25 @@ This RFC proposes the definition of version 5 extrinsics along with changes to t ### Changes to extrinsic authorization -The introduction of `General` transactions allows the authorization of any and all origins through extensions. This means that, with the appropriate extension, `General` transactions are capable of replicating the same behavior present day v4 `Signed` transactions. Specifically for Polkadot chains, an example implementation for such an extension is `VerifySignature`, introduced in the Transaction Extension [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685). Other extensions can be inserted into the extension pipeline to authorize different custom origins. Therefore, a `Signed` extrinsic variant is redundant to a `General` one strictly in terms of functionality available to users and would eventually need to be deprecated and removed. +The introduction of `General` transactions allows the authorization of any and all origins through +extensions. This means that, with the appropriate extension, `General` transactions are capable of +replicating the same behavior present day v4 `Signed` transactions. Specifically for Polkadot +chains, an example implementation for such an extension is +[`VerifySignature`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/verify-signature), +introduced in the Transaction Extension +[PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685). Other extensions can be inserted +into the extension pipeline to authorize different custom origins. Therefore, a `Signed` extrinsic +variant is redundant to a `General` one strictly in terms of functionality available to users and +would eventually need to be deprecated and removed. ### Encoding format for version 5 -As with version 4, the encoded v5 extrinsics will still be an array of SCALE encoded bytes, starting with the encoded length of the following bytes. The leading byte will determine the version and type of extrinsic, as specified by [RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md), with the addition that the `Signed` variant will not be supported for v5 extrinsics, for reasons mentioned above. +As with version 4, the encoded v5 extrinsics will still be an array of SCALE encoded bytes, starting +with the encoded length of the following bytes. The leading byte will determine the version and type +of extrinsic, as specified by +[RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md), +with the addition that the `Signed` variant will not be supported for v5 extrinsics, for reasons +mentioned above. NOTE: For `Bare` extrinsics, the following bytes will just be the encoded call and nothing else. @@ -44,6 +58,7 @@ by third parties. After the extension version byte, the extensions will be encoded next, followed by the call itself. A quick visualization of the encoding: + - `Bare` extrinsics: `(extrinsic_encoded_len, 0b0000_0101, call)` - `General` transactions: `(extrinsic_encoded_len, , 0b0100_0101, extension_version_byte, extension, call)` @@ -51,8 +66,9 @@ A quick visualization of the encoding: As stated before, [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685) comes with a Transaction Extension which replicates the current `Signed` transactions in v5 extrinsics, namely -`VerifySignature`. This extension leverages the new inherited implication functionality introduced -in `TransactionExtension` and creates a payload to be signed using the data of all extensions after +[`VerifySignature`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/verify-signature). +This extension leverages the new inherited implication functionality introduced in +`TransactionExtension` and creates a payload to be signed using the data of all extensions after itself in the extension pipeline. In order to run a transaction with a signed origin, a user must create the transaction with an instance of the extension which provides a signature. Alternatively, if users want to use some other origin, they should create the transaction with this particular @@ -61,6 +77,7 @@ configured to accept a `MultiSignature`, which makes it compatible with all sign currently used in Polkadot. To generate the payload to be signed: + 1. The extension version byte, call, extension and extension implicit should be encoded; 2. The result of the encoding should then be hashed using the `BLAKE2_256` hasher; 3. The result of the hash should then be signed with the signature type specified in the extension definition. @@ -76,14 +93,17 @@ let signature = keyring.sign(&payload[..]); ### Summary of changes in version 5 -In order to minimize the number of changes to the extrinsic format version and also to help all consumers downstream in the transition period between these extrinsic versions, we should: +In order to minimize the number of changes to the extrinsic format version and also to help all +consumers downstream in the transition period between these extrinsic versions, we should: + - Remove the `Signed` variant starting with v5 extrinsics - Add the `General` variant starting with v5 extrinsics - Enable runtimes to support both v4 and v5 extrinsics ## Drawbacks -The metadata will have to accommodate two distinct extrinsic format versions at a given point in time in order to provide the new functionality in a non-breaking way for users and tooling. +The metadata will have to accommodate two distinct extrinsic format versions at a given point in +time in order to provide the new functionality in a non-breaking way for users and tooling. ## Testing, Security, and Privacy @@ -91,7 +111,11 @@ There is no impact on testing, security or privacy. ## Performance, Ergonomics, and Compatibility -This change makes the authorization through signatures configurable by runtime devs in version 5 extrinsics, as opposed to version 4 where the signing payload algorithm and signatures were hardcoded. This moves the responsibility of ensuring proper authentication through `TransactionExtension` to the runtime devs, but a sensible default which closely resembles the present day behavior will be provided in `VerifySignature`. +This change makes the authorization through signatures configurable by runtime devs in version 5 +extrinsics, as opposed to version 4 where the signing payload algorithm and signatures were +hardcoded. This moves the responsibility of ensuring proper authentication through +`TransactionExtension` to the runtime devs, but a sensible default which closely resembles the +present day behavior will be provided in `VerifySignature`. ### Performance @@ -99,11 +123,14 @@ There is no performance impact. ### Ergonomics -Tooling will have to adapt to be able to tell which authorization scheme is used by a particular transaction by decoding the extension and checking which particular `TransactionExtension` in the pipeline is enabled to do the origin authorization. Previously, this was done by simply checking whether the transaction is signed or unsigned, as there was only one method of authentication. +Tooling will have to adapt to be able to tell which authorization scheme is used by a particular +transaction by decoding the extension and checking which particular `TransactionExtension` in the pipeline is enabled to do the origin authorization. Previously, this was done by simply checking whether the transaction is signed or unsigned, as there was only one method of authentication. ### Compatibility -As long as extrinsic version 4 is still exposed in the metadata when version 5 will be introduced, the changes will not break existing infrastructure. This should give enough time for tooling to support version 5 and to remove version 4 in the future. +As long as extrinsic version 4 is still exposed in the metadata when version 5 will be introduced, +the changes will not break existing infrastructure. This should give enough time for tooling to +support version 5 and to remove version 4 in the future. ## Prior Art and References @@ -113,11 +140,16 @@ Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) and ## Unresolved Questions -There is no clear way to expose two different extrinsic versions in the current metadata framework. A non-exhaustive list of options discussed so far: +There is no clear way to expose two different extrinsic versions in the current metadata framework. +A non-exhaustive list of options discussed so far: + 1. Change the `ExtrinsicMetadata` trait to specify a list of versions instead of a single version. 2. Use the custom fields in the metadata to specify the details of the version 5. -3. Create a new trait similar to `ExtrinsicMetadata`, but for future versions of the extrinsic format and add it to the metadata. +3. Create a new trait similar to `ExtrinsicMetadata`, but for future versions of the extrinsic + format and add it to the metadata. ## Future Directions and Related Material -Following this change, extrinsic version 5 will be introduced as part of the [Extrinsic Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) effort, which will shape future work. +Following this change, extrinsic version 5 will be introduced as part of the [Extrinsic +Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) effort, which will shape future +work. From f2f4f19ddd39f7ea2c5ae803656a3144bff7d173 Mon Sep 17 00:00:00 2001 From: georgepisaltu Date: Fri, 18 Oct 2024 22:31:46 +0300 Subject: [PATCH 3/6] Fix title Signed-off-by: georgepisaltu --- text/0000-extrinsic-version-5.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-extrinsic-version-5.md b/text/0000-extrinsic-version-5.md index 893940e4d..ce561fcc5 100644 --- a/text/0000-extrinsic-version-5.md +++ b/text/0000-extrinsic-version-5.md @@ -1,4 +1,4 @@ -# RFC-0000: Extrinsic version 5 +# RFC-0124: Extrinsic version 5 | | | | --------------- | ------------------------------------------------------------------------------------------- | From dd9e353d9c63fbf027fb31333a3fba8427178b99 Mon Sep 17 00:00:00 2001 From: georgepisaltu Date: Fri, 18 Oct 2024 22:32:19 +0300 Subject: [PATCH 4/6] Rename RFC Signed-off-by: georgepisaltu --- text/{0000-extrinsic-version-5.md => 0124-extrinsic-version-5.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0000-extrinsic-version-5.md => 0124-extrinsic-version-5.md} (100%) diff --git a/text/0000-extrinsic-version-5.md b/text/0124-extrinsic-version-5.md similarity index 100% rename from text/0000-extrinsic-version-5.md rename to text/0124-extrinsic-version-5.md From e13f615429c882d5b418b4a896344e2af9d1526e Mon Sep 17 00:00:00 2001 From: georgepisaltu Date: Mon, 28 Oct 2024 13:00:40 +0200 Subject: [PATCH 5/6] Rephrasing and other fixes Signed-off-by: georgepisaltu --- text/0124-extrinsic-version-5.md | 53 ++++++++++++++++---------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/text/0124-extrinsic-version-5.md b/text/0124-extrinsic-version-5.md index ce561fcc5..b74e405dd 100644 --- a/text/0124-extrinsic-version-5.md +++ b/text/0124-extrinsic-version-5.md @@ -25,24 +25,23 @@ This RFC proposes the definition of version 5 extrinsics along with changes to t ### Changes to extrinsic authorization The introduction of `General` transactions allows the authorization of any and all origins through -extensions. This means that, with the appropriate extension, `General` transactions are capable of -replicating the same behavior present day v4 `Signed` transactions. Specifically for Polkadot -chains, an example implementation for such an extension is +extensions. This means that, with the appropriate extension, `General` transactions can replicate +the same behavior present-day v4 `Signed` transactions. Specifically for Polkadot chains, an example +implementation for such an extension is [`VerifySignature`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/verify-signature), introduced in the Transaction Extension [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685). Other extensions can be inserted into the extension pipeline to authorize different custom origins. Therefore, a `Signed` extrinsic -variant is redundant to a `General` one strictly in terms of functionality available to users and -would eventually need to be deprecated and removed. +variant is redundant to a `General` one strictly in terms of user functionality and could eventually +be deprecated and removed. ### Encoding format for version 5 -As with version 4, the encoded v5 extrinsics will still be an array of SCALE encoded bytes, starting -with the encoded length of the following bytes. The leading byte will determine the version and type -of extrinsic, as specified by -[RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md), -with the addition that the `Signed` variant will not be supported for v5 extrinsics, for reasons -mentioned above. +As with version 4, the encoded extrinsic v5 is a SCALE encoded vector of bytes (`u8`), therefore +starting with the encoded length of the following bytes in compact format. The leading byte after +the length determines the version and type of extrinsic, as specified by +[RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md). +For reasons mentioned above, this RFC removes the `Signed` variant for v5 extrinsics. NOTE: For `Bare` extrinsics, the following bytes will just be the encoded call and nothing else. @@ -64,21 +63,29 @@ A quick visualization of the encoding: ### Signatures on Polkadot in General transactions +In order to run a transaction with a signed origin in extrinsic version 5, a user must create the +transaction with an instance of at least one extension responsible for authorizing `Signed` origins +with a provided signature. Alternatively, if users want to use some other origin, they should create +the transaction with this particular extension disabled. + As stated before, [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685) comes with a Transaction Extension which replicates the current `Signed` transactions in v5 extrinsics, namely [`VerifySignature`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/verify-signature). +I will use this extension as an example on how to replicate current `Signed` transaction +functionality in the new v5 extrinsic format, though the runtime logic is not constrained to this +particular implementation. + This extension leverages the new inherited implication functionality introduced in `TransactionExtension` and creates a payload to be signed using the data of all extensions after -itself in the extension pipeline. In order to run a transaction with a signed origin, a user must -create the transaction with an instance of the extension which provides a signature. Alternatively, -if users want to use some other origin, they should create the transaction with this particular -extension disabled. More on this behavior in the extension documentation. This extension can be -configured to accept a `MultiSignature`, which makes it compatible with all signature types -currently used in Polkadot. +itself in the extension pipeline. This extension can be configured to accept a `MultiSignature`, +which makes it compatible with all signature types currently used in Polkadot. -To generate the payload to be signed: +In the context of using and extension such as `VerifySignature` to replicate current `Signed` +transaction functionality, the steps to generate the payload to be signed are: -1. The extension version byte, call, extension and extension implicit should be encoded; +1. The extension version byte, call, extension and extension implicit should be encoded (by + "extension" and its implicit we mean only the data associated with extensions that follow this + one in the composite extension type); 2. The result of the encoding should then be hashed using the `BLAKE2_256` hasher; 3. The result of the hash should then be signed with the signature type specified in the extension definition. @@ -140,13 +147,7 @@ Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) and ## Unresolved Questions -There is no clear way to expose two different extrinsic versions in the current metadata framework. -A non-exhaustive list of options discussed so far: - -1. Change the `ExtrinsicMetadata` trait to specify a list of versions instead of a single version. -2. Use the custom fields in the metadata to specify the details of the version 5. -3. Create a new trait similar to `ExtrinsicMetadata`, but for future versions of the extrinsic - format and add it to the metadata. +None. ## Future Directions and Related Material From 0ac87dfeed91dcb3fd16f240fd783adf73c0e989 Mon Sep 17 00:00:00 2001 From: georgepisaltu Date: Wed, 6 Nov 2024 16:24:38 +0200 Subject: [PATCH 6/6] Rephrasing and formatting Signed-off-by: georgepisaltu --- text/0124-extrinsic-version-5.md | 40 +++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/text/0124-extrinsic-version-5.md b/text/0124-extrinsic-version-5.md index b74e405dd..393d0f185 100644 --- a/text/0124-extrinsic-version-5.md +++ b/text/0124-extrinsic-version-5.md @@ -8,11 +8,19 @@ ## Summary -This RFC proposes the definition of version 5 extrinsics along with changes to the specification and encoding from version 4. +This RFC proposes the definition of version 5 extrinsics along with changes to the specification and +encoding from version 4. ## Motivation -[RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md) introduced the specification of `General` transactions, a new type of extrinsic besides the `Signed` and `Unsigned` variants available previously in version 4. Additionally, [RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md) introduced versioning of transaction extensions through an extra byte in the extrinsic encoding. Both of these changes require an extrinsic format version bump as both the semantics around extensions as well as the actual encoding of extrinsics need to change to accommodate these new features. +[RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md) +introduced the specification of `General` transactions, a new type of extrinsic besides the `Signed` +and `Unsigned` variants available previously in version 4. Additionally, +[RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md) +introduced versioning of transaction extensions through an extra byte in the extrinsic encoding. +Both of these changes require an extrinsic format version bump as both the semantics around +extensions as well as the actual encoding of extrinsics need to change to accommodate these new +features. ## Stakeholders @@ -43,14 +51,14 @@ the length determines the version and type of extrinsic, as specified by [RFC84](https://github.com/polkadot-fellows/RFCs/blob/main/text/0084-general-transaction-extrinsic-format.md). For reasons mentioned above, this RFC removes the `Signed` variant for v5 extrinsics. -NOTE: For `Bare` extrinsics, the following bytes will just be the encoded call and nothing else. +For `Bare` extrinsics, the following bytes will just be the encoded call and nothing else. For `General` transactions, as stated in [RFC99](https://github.com/polkadot-fellows/RFCs/blob/main/text/0099-transaction-extension-version.md), -an extension version byte must be added in the next extrinsic version. This byte should allow -runtimes to expose more than one set of extensions which can be used for a transaction. As far as -the v5 extrinsic encoding is concerned, this extension byte should be encoded immediately after the -leading encoding byte. The extension version byte should be included in payloads to be signed by all +an extension version byte must be added to the extrinsic format. This byte should allow runtimes to +expose more than one set of extensions which can be used for a transaction. As far as the v5 +extrinsic encoding is concerned, this extension byte should be encoded immediately after the leading +encoding byte. The extension version byte should be included in payloads to be signed by all extensions configured by runtime devs to ensure a user's extension version choice cannot be altered by third parties. @@ -59,14 +67,14 @@ After the extension version byte, the extensions will be encoded next, followed A quick visualization of the encoding: - `Bare` extrinsics: `(extrinsic_encoded_len, 0b0000_0101, call)` -- `General` transactions: `(extrinsic_encoded_len, , 0b0100_0101, extension_version_byte, extension, call)` +- `General` transactions: `(extrinsic_encoded_len, , 0b0100_0101, extension_version_byte, + extensions, call)` ### Signatures on Polkadot in General transactions In order to run a transaction with a signed origin in extrinsic version 5, a user must create the transaction with an instance of at least one extension responsible for authorizing `Signed` origins -with a provided signature. Alternatively, if users want to use some other origin, they should create -the transaction with this particular extension disabled. +with a provided signature. As stated before, [PR3685](https://github.com/paritytech/polkadot-sdk/pull/3685) comes with a Transaction Extension which replicates the current `Signed` transactions in v5 extrinsics, namely @@ -80,8 +88,8 @@ This extension leverages the new inherited implication functionality introduced itself in the extension pipeline. This extension can be configured to accept a `MultiSignature`, which makes it compatible with all signature types currently used in Polkadot. -In the context of using and extension such as `VerifySignature` to replicate current `Signed` -transaction functionality, the steps to generate the payload to be signed are: +In the context of using an extension such as `VerifySignature`, for example, to replicate current +`Signed` transaction functionality, the steps to generate the payload to be signed would be: 1. The extension version byte, call, extension and extension implicit should be encoded (by "extension" and its implicit we mean only the data associated with extensions that follow this @@ -112,6 +120,10 @@ consumers downstream in the transition period between these extrinsic versions, The metadata will have to accommodate two distinct extrinsic format versions at a given point in time in order to provide the new functionality in a non-breaking way for users and tooling. +Although having to support multiple extrinsic versions in metadata involves extra work, the change +is ultimately an improvement to metadata and the extra functionality may be useful in other future +scenarios. + ## Testing, Security, and Privacy There is no impact on testing, security or privacy. @@ -131,7 +143,9 @@ There is no performance impact. ### Ergonomics Tooling will have to adapt to be able to tell which authorization scheme is used by a particular -transaction by decoding the extension and checking which particular `TransactionExtension` in the pipeline is enabled to do the origin authorization. Previously, this was done by simply checking whether the transaction is signed or unsigned, as there was only one method of authentication. +transaction by decoding the extension and checking which particular `TransactionExtension` in the +pipeline is enabled to do the origin authorization. Previously, this was done by simply checking +whether the transaction is signed or unsigned, as there was only one method of authentication. ### Compatibility