diff --git a/404.html b/404.html index d515e71..5ff41ed 100644 --- a/404.html +++ b/404.html @@ -91,7 +91,7 @@ diff --git a/approved/0001-agile-coretime.html b/approved/0001-agile-coretime.html index cb1464a..a017cbe 100644 --- a/approved/0001-agile-coretime.html +++ b/approved/0001-agile-coretime.html @@ -90,7 +90,7 @@ diff --git a/approved/0005-coretime-interface.html b/approved/0005-coretime-interface.html index 2e29399..4a6c725 100644 --- a/approved/0005-coretime-interface.html +++ b/approved/0005-coretime-interface.html @@ -90,7 +90,7 @@ diff --git a/approved/0007-system-collator-selection.html b/approved/0007-system-collator-selection.html index b0ac99d..3da0523 100644 --- a/approved/0007-system-collator-selection.html +++ b/approved/0007-system-collator-selection.html @@ -90,7 +90,7 @@ diff --git a/approved/0008-parachain-bootnodes-dht.html b/approved/0008-parachain-bootnodes-dht.html index 646d513..29ebb49 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index ab85602..67c84e6 100644 --- a/approved/0010-burn-coretime-revenue.html +++ b/approved/0010-burn-coretime-revenue.html @@ -90,7 +90,7 @@ diff --git a/approved/0012-process-for-adding-new-collectives.html b/approved/0012-process-for-adding-new-collectives.html index 611c0b3..c603544 100644 --- a/approved/0012-process-for-adding-new-collectives.html +++ b/approved/0012-process-for-adding-new-collectives.html @@ -90,7 +90,7 @@ diff --git a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html index 6425a8d..f49e5a7 100644 --- a/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html +++ b/approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html @@ -90,7 +90,7 @@ diff --git a/approved/0014-improve-locking-mechanism-for-parachains.html b/approved/0014-improve-locking-mechanism-for-parachains.html index 0b61a6a..5ee782f 100644 --- a/approved/0014-improve-locking-mechanism-for-parachains.html +++ b/approved/0014-improve-locking-mechanism-for-parachains.html @@ -90,7 +90,7 @@ diff --git a/approved/0022-adopt-encointer-runtime.html b/approved/0022-adopt-encointer-runtime.html index 36cc270..cdd3d67 100644 --- a/approved/0022-adopt-encointer-runtime.html +++ b/approved/0022-adopt-encointer-runtime.html @@ -90,7 +90,7 @@ diff --git a/approved/0026-sassafras-consensus.html b/approved/0026-sassafras-consensus.html index 2870c36..a895ccd 100644 --- a/approved/0026-sassafras-consensus.html +++ b/approved/0026-sassafras-consensus.html @@ -90,7 +90,7 @@ diff --git a/approved/0032-minimal-relay.html b/approved/0032-minimal-relay.html index b19abc7..abd7e4a 100644 --- a/approved/0032-minimal-relay.html +++ b/approved/0032-minimal-relay.html @@ -90,7 +90,7 @@ diff --git a/approved/0042-extrinsics-state-version.html b/approved/0042-extrinsics-state-version.html index 1b5d88b..c55674c 100644 --- a/approved/0042-extrinsics-state-version.html +++ b/approved/0042-extrinsics-state-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0043-storage-proof-size-hostfunction.html b/approved/0043-storage-proof-size-hostfunction.html index 9381304..c71dcc6 100644 --- a/approved/0043-storage-proof-size-hostfunction.html +++ b/approved/0043-storage-proof-size-hostfunction.html @@ -90,7 +90,7 @@ diff --git a/approved/0045-nft-deposits-asset-hub.html b/approved/0045-nft-deposits-asset-hub.html index 7f1b9b1..2a4e720 100644 --- a/approved/0045-nft-deposits-asset-hub.html +++ b/approved/0045-nft-deposits-asset-hub.html @@ -90,7 +90,7 @@ diff --git a/approved/0047-assignment-of-availability-chunks.html b/approved/0047-assignment-of-availability-chunks.html index d16bd3f..53d12aa 100644 --- a/approved/0047-assignment-of-availability-chunks.html +++ b/approved/0047-assignment-of-availability-chunks.html @@ -90,7 +90,7 @@ diff --git a/approved/0048-session-keys-runtime-api.html b/approved/0048-session-keys-runtime-api.html index 06f87af..184c44a 100644 --- a/approved/0048-session-keys-runtime-api.html +++ b/approved/0048-session-keys-runtime-api.html @@ -90,7 +90,7 @@ diff --git a/approved/0050-fellowship-salaries.html b/approved/0050-fellowship-salaries.html index 0eb0c40..6925f9a 100644 --- a/approved/0050-fellowship-salaries.html +++ b/approved/0050-fellowship-salaries.html @@ -90,7 +90,7 @@ diff --git a/approved/0056-one-transaction-per-notification.html b/approved/0056-one-transaction-per-notification.html index 3460fe1..0901c54 100644 --- a/approved/0056-one-transaction-per-notification.html +++ b/approved/0056-one-transaction-per-notification.html @@ -90,7 +90,7 @@ diff --git a/approved/0059-nodes-capabilities-discovery.html b/approved/0059-nodes-capabilities-discovery.html index 45010b0..70e811f 100644 --- a/approved/0059-nodes-capabilities-discovery.html +++ b/approved/0059-nodes-capabilities-discovery.html @@ -90,7 +90,7 @@ diff --git a/approved/0078-merkleized-metadata.html b/approved/0078-merkleized-metadata.html index a800cfa..9560d32 100644 --- a/approved/0078-merkleized-metadata.html +++ b/approved/0078-merkleized-metadata.html @@ -90,7 +90,7 @@ diff --git a/approved/0084-general-transaction-extrinsic-format.html b/approved/0084-general-transaction-extrinsic-format.html index 7bf7041..2650112 100644 --- a/approved/0084-general-transaction-extrinsic-format.html +++ b/approved/0084-general-transaction-extrinsic-format.html @@ -90,7 +90,7 @@ diff --git a/approved/0091-dht-record-creation-time.html b/approved/0091-dht-record-creation-time.html index 18dbeee..7f59b91 100644 --- a/approved/0091-dht-record-creation-time.html +++ b/approved/0091-dht-record-creation-time.html @@ -90,7 +90,7 @@ diff --git a/approved/0097-unbonding_queue.html b/approved/0097-unbonding_queue.html index 6d0866c..f491f14 100644 --- a/approved/0097-unbonding_queue.html +++ b/approved/0097-unbonding_queue.html @@ -90,7 +90,7 @@ diff --git a/approved/0099-transaction-extension-version.html b/approved/0099-transaction-extension-version.html index ad1ddd6..886ac8e 100644 --- a/approved/0099-transaction-extension-version.html +++ b/approved/0099-transaction-extension-version.html @@ -90,7 +90,7 @@ diff --git a/approved/0100-xcm-multi-type-asset-transfer.html b/approved/0100-xcm-multi-type-asset-transfer.html index 63fe809..7a8dd8e 100644 --- a/approved/0100-xcm-multi-type-asset-transfer.html +++ b/approved/0100-xcm-multi-type-asset-transfer.html @@ -90,7 +90,7 @@ diff --git a/approved/0101-xcm-transact-remove-max-weight-param.html b/approved/0101-xcm-transact-remove-max-weight-param.html index 0980d75..4f9cb01 100644 --- a/approved/0101-xcm-transact-remove-max-weight-param.html +++ b/approved/0101-xcm-transact-remove-max-weight-param.html @@ -90,7 +90,7 @@ diff --git a/approved/0103-introduce-core-index-commitment.html b/approved/0103-introduce-core-index-commitment.html index 0a875db..271bc39 100644 --- a/approved/0103-introduce-core-index-commitment.html +++ b/approved/0103-introduce-core-index-commitment.html @@ -90,7 +90,7 @@ diff --git a/approved/0105-xcm-improved-fee-mechanism.html b/approved/0105-xcm-improved-fee-mechanism.html index d85f97b..62f0c69 100644 --- a/approved/0105-xcm-improved-fee-mechanism.html +++ b/approved/0105-xcm-improved-fee-mechanism.html @@ -90,7 +90,7 @@ diff --git a/approved/0107-xcm-execution-hints.html b/approved/0107-xcm-execution-hints.html index 00c8f98..fcf41d7 100644 --- a/approved/0107-xcm-execution-hints.html +++ b/approved/0107-xcm-execution-hints.html @@ -90,7 +90,7 @@ diff --git a/approved/0108-xcm-remove-testnet-ids.html b/approved/0108-xcm-remove-testnet-ids.html index bd12e6f..08837cc 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ diff --git a/approved/0122-alias-origin-on-asset-transfers.html b/approved/0122-alias-origin-on-asset-transfers.html index 2657af6..2e21fda 100644 --- a/approved/0122-alias-origin-on-asset-transfers.html +++ b/approved/0122-alias-origin-on-asset-transfers.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index e953043..365e635 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index e953043..365e635 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html b/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html index e94149c..7198a2f 100644 --- a/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html +++ b/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html @@ -90,7 +90,7 @@ @@ -249,7 +249,7 @@ For Polkadot/Kusama this means that also the parachain nodes need to be running - @@ -263,7 +263,7 @@ For Polkadot/Kusama this means that also the parachain nodes need to be running - diff --git a/new/0124-extrinsic-version-5.html b/new/0124-extrinsic-version-5.html new file mode 100644 index 0000000..f7b1786 --- /dev/null +++ b/new/0124-extrinsic-version-5.html @@ -0,0 +1,382 @@ + + + + + + + RFC-0124: Extrinsic version 5 - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0124: Extrinsic version 5

+
+ + + +
Start Date18 October 2024
DescriptionDefinition and specification of version 5 extrinsics
AuthorsGeorge Pisaltu
+
+

Summary

+

This RFC proposes the definition of version 5 extrinsics along with changes to the specification and encoding from version 4.

+

Motivation

+

RFC84 introduced the specification of General transactions, a new type of extrinsic besides the Signed and Unsigned variants available previously in version 4. Additionally, RFC99 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. 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, +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, +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 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. +
  2. The result of the encoding should then be hashed using the BLAKE2_256 hasher;
    3. +
  3. The result of the hash should then be signed with the signature type specified in the extension definition.
    4. +
+
#![allow(unused)]
+fn main() {
+// 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 and +RFC99.

+

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. +
  2. Use the custom fields in the metadata to specify the details of the version 5.
    3. +
  3. Create a new trait similar to ExtrinsicMetadata, but for future versions of the extrinsic +format and add it to the metadata.
    4. +
+ +

Following this change, extrinsic version 5 will be introduced as part of the Extrinsic +Horizon effort, which will shape future +work.

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index be43f57..d97bbf1 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -246,6 +246,160 @@ For Polkadot/Kusama this means that also the parachain nodes need to be running +

(source)

+

Table of Contents

+ +

RFC-0124: Extrinsic version 5

+
+ + + +
Start Date18 October 2024
DescriptionDefinition and specification of version 5 extrinsics
AuthorsGeorge Pisaltu
+
+

Summary

+

This RFC proposes the definition of version 5 extrinsics along with changes to the specification and encoding from version 4.

+

Motivation

+

RFC84 introduced the specification of General transactions, a new type of extrinsic besides the Signed and Unsigned variants available previously in version 4. Additionally, RFC99 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

+ +

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. 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, +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, +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:

+ +

Signatures on Polkadot in General transactions

+

As stated before, PR3685 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. +
  2. The result of the encoding should then be hashed using the BLAKE2_256 hasher;
    3. +
  3. The result of the hash should then be signed with the signature type specified in the extension definition.
    4. +
+
#![allow(unused)]
+fn main() {
+// 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:

+ +

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 and +RFC99.

+

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. +
  2. Use the custom fields in the metadata to specify the details of the version 5.
    3. +
  3. Create a new trait similar to ExtrinsicMetadata, but for future versions of the extrinsic +format and add it to the metadata.
    4. +
+ +

Following this change, extrinsic version 5 will be introduced as part of the Extrinsic +Horizon effort, which will shape future +work.

(source)

Table of Contents

Given that these mistakes are likely, it is necessary to provide a solution to either prevent them or enable access to a pure account on a target chain.

-

Stakeholders

+

Stakeholders

Runtime Users, Runtime Devs, wallets, cross-chain dApps.

-

Explanation

+

Explanation

One possible solution is to allow a proxy to create or replicate a pure proxy relationship for the same pure account on a target chain. For example, Alice, as the proxy of the pure1 pure account on parachain A, should be able to set a proxy for the same pure1 account on parachain B.

To minimise security risks, the parachain B should grant the parachain A the least amount of permission necessary for the replication. First, Parachain A claims to Parachain B that the operation is commanded by the pure account, and thus by its proxy, and second, provides proof that the account is keyless.

The replication process will be facilitated by XCM, with the first claim made using the DescendOrigin instruction. The replication call on parachain A would require a signed origin by the pure account and construct an XCM program for parachain B, where it first descends the origin, resulting in the ParachainA/AccountId32(pure1) origin location on the receiving side.

@@ -891,7 +1045,7 @@ mod pallet_proxy_replica { } } -

Drawbacks

+

Drawbacks

There are two disadvantages to this approach:

-

Drawbacks

+

Drawbacks

The primary drawback is a reliance on governance for continued treasury funding of infrastructure costs for Invulnerable collators.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

The vast majority of cases can be covered by unit testing. Integration test should ensure that the Collator Selection UpdateOrigin, which has permission to modify the Invulnerables and desired number of Candidates, can handle updates over XCM from the system's governance location.

-

Performance, Ergonomics, and Compatibility

+

Performance, Ergonomics, and Compatibility

This proposal has very little impact on most users of Polkadot, and should improve the performance of system chains by reducing the number of missed blocks.

-

Performance

+

Performance

As chains have strict PoV size limits, care must be taken in the PoV impact of the session manager. Appropriate benchmarking and tests should ensure that conservative limits are placed on the number of Invulnerables and Candidates.

-

Ergonomics

+

Ergonomics

The primary group affected is Candidate collators, who, after implementation of this RFC, will need to compete in a bond-based election rather than a race to claim a Candidate spot.

-

Compatibility

+

Compatibility

This RFC is compatible with the existing implementation and can be handled via upgrades and migration.

-

Prior Art and References

+

Prior Art and References

Written Discussions

-

Unresolved Questions

+

Unresolved Questions

None at this time.

- +

There may exist in the future system chains for which this model of collator selection is not appropriate. These chains should be evaluated on a case-by-case basis.

(source)

@@ -2427,10 +2581,10 @@ appropriate. These chains should be evaluated on a case-by-case basis.

AuthorsPierre Krieger -

Summary

+

Summary

The full nodes of the Polkadot peer-to-peer network maintain a distributed hash table (DHT), which is currently used for full nodes discovery and validators discovery purposes.

This RFC proposes to extend this DHT to be used to discover full nodes of the parachains of Polkadot.

-

Motivation

+

Motivation

The maintenance of bootnodes has long been an annoyance for everyone.

When a bootnode is newly-deployed or removed, every chain specification must be updated in order to take the update into account. This has lead to various non-optimal solutions, such as pulling chain specifications from GitHub repositories. When it comes to RPC nodes, UX developers often have trouble finding up-to-date addresses of parachain RPC nodes. With the ongoing migration from RPC nodes to light clients, similar problems would happen with chain specifications as well.

@@ -2439,9 +2593,9 @@ When it comes to RPC nodes, UX developers often have trouble finding up-to-date

Because the list of bootnodes in chain specifications is so annoying to modify, the consequence is that the number of bootnodes is rather low (typically between 2 and 15). In order to better resist downtimes and DoS attacks, a better solution would be to use every node of a certain chain as potential bootnode, rather than special-casing some specific nodes.

While this RFC doesn't solve these problems for relay chains, it aims at solving it for parachains by storing the list of all the full nodes of a parachain on the relay chain DHT.

Assuming that this RFC is implemented, and that light clients are used, deploying a parachain wouldn't require more work than registering it onto the relay chain and starting the collators. There wouldn't be any need for special infrastructure nodes anymore.

-

Stakeholders

+

Stakeholders

This RFC has been opened on my own initiative because I think that this is a good technical solution to a usability problem that many people are encountering and that they don't realize can be solved.

-

Explanation

+

Explanation

The content of this RFC only applies for parachains and parachain nodes that are "Substrate-compatible". It is in no way mandatory for parachains to comply to this RFC.

Note that "Substrate-compatible" is very loosely defined as "implements the same mechanisms and networking protocols as Substrate". The author of this RFC believes that "Substrate-compatible" should be very precisely specified, but there is controversy on this topic.

While a lot of this RFC concerns the implementation of parachain nodes, it makes use of the resources of the Polkadot chain, and as such it is important to describe them in the Polkadot specification.

@@ -2478,10 +2632,10 @@ message Response {

The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that fork_id is typically very small and that the only variable-length field is addrs, this is easily achieved by limiting the number of addresses.

Implementers should be aware that addrs might be very large, and are encouraged to limit the number of addrs to an implementation-defined value.

-

Drawbacks

+

Drawbacks

The peer_id and addrs fields are in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame.

The values of the genesis_hash and fork_id fields cannot be verified by the requester and are expected to be unused at the moment. Instead, a client that desires connecting to a parachain is expected to obtain the genesis hash and fork ID of the parachain from the parachain chain specification. These fields are included in the networking protocol nonetheless in case an acceptable solution is found in the future, and in order to allow use cases such as discovering parachains in a not-strictly-trusted way.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Because not all nodes want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all parachain nodes.

This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms. However, if the principle of chain specification bootnodes is entirely replaced with the mechanism described in this RFC (which is the objective), then it becomes important whether the mechanism in this RFC can be abused in order to make a parachain unreachable.

@@ -2490,22 +2644,22 @@ Furthermore, when a large number of providers (here, a provider is a bootnode) a

For this reason, an attacker can abuse this mechanism by randomly generating libp2p PeerIds until they find the 20 entries closest to the key representing the target parachain. They are then in control of the parachain bootnodes. Because the key changes periodically and isn't predictable, and assuming that the Polkadot DHT is sufficiently large, it is not realistic for an attack like this to be maintained in the long term.

Furthermore, parachain clients are expected to cache a list of known good nodes on their disk. If the mechanism described in this RFC went down, it would only prevent new nodes from accessing the parachain, while clients that have connected before would not be affected.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours.

Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode.

Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the key corresponding to BabeApi_next_epoch.

Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the bootnodes of a parachain. Light clients are generally encouraged to cache the peers that they use between restarts, so they should only query these 20 Polkadot full nodes at their first initialization. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.

-

Ergonomics

+

Ergonomics

Irrelevant.

-

Compatibility

+

Compatibility

Irrelevant.

-

Prior Art and References

+

Prior Art and References

None.

-

Unresolved Questions

+

Unresolved Questions

While it fundamentally doesn't change much to this RFC, using BabeApi_currentEpoch and BabeApi_nextEpoch might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet?

- +

It is possible that in the future a client could connect to a parachain without having to rely on a trusted parachain specification.

(source)

Table of Contents

@@ -2526,13 +2680,13 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that AuthorsJonas Gehrlein -

Summary

+

Summary

The Polkadot UC will generate revenue from the sale of available Coretime. The question then arises: how should we handle these revenues? Broadly, there are two reasonable paths – burning the revenue and thereby removing it from total issuance or divert it to the Treasury. This Request for Comment (RFC) presents arguments favoring burning as the preferred mechanism for handling revenues from Coretime sales.

-

Motivation

+

Motivation

How to handle the revenue accrued from Coretime sales is an important economic question that influences the value of DOT and should be properly discussed before deciding for either of the options. Now is the best time to start this discussion.

-

Stakeholders

+

Stakeholders

Polkadot DOT token holders.

-

Explanation

+

Explanation

This RFC discusses potential benefits of burning the revenue accrued from Coretime sales instead of diverting them to Treasury. Here are the following arguments for it.

It's in the interest of the Polkadot community to have a consistent and predictable Treasury income, because volatility in the inflow can be damaging, especially in situations when it is insufficient. As such, this RFC operates under the presumption of a steady and sustainable Treasury income flow, which is crucial for the Polkadot community's stability. The assurance of a predictable Treasury income, as outlined in a prior discussion here, or through other equally effective measures, serves as a baseline assumption for this argument.

Consequently, we need not concern ourselves with this particular issue here. This naturally begs the question - why should we introduce additional volatility to the Treasury by aligning it with the variable Coretime sales? It's worth noting that Coretime revenues often exhibit an inverse relationship with periods when Treasury spending should ideally be ramped up. During periods of low Coretime utilization (indicated by lower revenue), Treasury should spend more on projects and endeavours to increase the demand for Coretime. This pattern underscores that Coretime sales, by their very nature, are an inconsistent and unpredictable source of funding for the Treasury. Given the importance of maintaining a steady and predictable inflow, it's unnecessary to rely on another volatile mechanism. Some might argue that we could have both: a steady inflow (from inflation) and some added bonus from Coretime sales, but burning the revenue would offer further benefits as described below.

@@ -2575,13 +2729,13 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that AuthorsJoe Petrowski -

Summary

+

Summary

Since the introduction of the Collectives parachain, many groups have expressed interest in forming new -- or migrating existing groups into -- on-chain collectives. While adding a new collective is relatively simple from a technical standpoint, the Fellowship will need to merge new pallets into the Collectives parachain for each new collective. This RFC proposes a means for the network to ratify a new collective, thus instructing the Fellowship to instate it in the runtime.

-

Motivation

+

Motivation

Many groups have expressed interest in representing collectives on-chain. Some of these include:

-

Drawbacks

+

Drawbacks

Other than all other system chains, development and maintenance of the Encointer Network is mainly financed by the KSM Treasury and possibly the DOT Treasury in the future. Encointer is dedicated to maintaining its network and runtime code for as long as possible, but there is a dependency on funding which is not in the hands of the fellowship. The only risk in the context of funding, however, is that the Encointer runtime will see less frequent updates if there's less funding.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

No changes to the existing system are proposed. Only changes to how maintenance is organized.

-

Performance, Ergonomics, and Compatibility

+

Performance, Ergonomics, and Compatibility

No changes

-

Prior Art and References

+

Prior Art and References

Existing Encointer runtime repo

-

Unresolved Questions

+

Unresolved Questions

None identified

- +

More info on Encointer: encointer.org

(source)

Table of Contents

@@ -3873,11 +4027,11 @@ other privacy-enhancing mechanisms to address this concern. AuthorsJoe Petrowski, Gavin Wood -

Summary

+

Summary

The Relay Chain contains most of the core logic for the Polkadot network. While this was necessary prior to the launch of parachains and development of XCM, most of this logic can exist in parachains. This is a proposal to migrate several subsystems into system parachains.

-

Motivation

+

Motivation

Polkadot's scaling approach allows many distinct state machines (known generally as parachains) to operate with common guarantees about the validity and security of their state transitions. Polkadot provides these common guarantees by executing the state transitions on a strict subset (a backing @@ -3889,13 +4043,13 @@ blockspace) to the network.

By minimising state transition logic on the Relay Chain by migrating it into "system chains" -- a set of parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot Ubiquitous Computer can maximise its primary offering: secure blockspace.

-

Stakeholders

+

Stakeholders

-

Explanation

+

Explanation

The following pallets and subsystems are good candidates to migrate from the Relay Chain: