(source)
+Table of Contents
+
+
+ | |
|---|
+| Start Date | 03 July 2024 |
+| Description | Introduce a versioning for transaction extensions. |
+| Authors | Bastian Köcher |
+
+
This RFC proposes a change to the extrinsic format to include a transaction extension version.
+
+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 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.
+
+
+- Runtime users
+- Runtime devs
+- Wallet devs
+
+
+RFC84 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, Version, Extensions)General: (Version, 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.
+
+This adds a least one byte more to each signed transaction.
+
+There is no impact on testing, security or privacy.
+
+This will ensure that changes to the transactions extensions can be done in a backwards compatible way.
+
+There is no performance impact.
+
+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.
+
+When introduced together with extrinsic format version 5 from RFC84, 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.
+
+None.
+
+None.
+
+None.
(source)
Table of Contents
diff --git a/proposed/0091-dht-record-creation-time.html b/proposed/0091-dht-record-creation-time.html
index 120262e..f70aec2 100644
--- a/proposed/0091-dht-record-creation-time.html
+++ b/proposed/0091-dht-record-creation-time.html
@@ -90,7 +90,7 @@
@@ -271,7 +271,7 @@ in order to speed up the time until all nodes have the newest record, nodes can