diff --git a/404.html b/404.html index f96337a..645ce28 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 5874fbf..d0ac60d 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 1a8659a..da465b2 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 604be7f..abef7aa 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 a1cc036..e60e6b8 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 df68769..0548648 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 952d5ac..3104cc6 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 2d9bb67..ea0842f 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 1dac67c..3b77a7d 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 8e2461d..c5016e4 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 109707c..0ce4b02 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 39765ea..8b9bae4 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 49b00b7..d9186ff 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 c0d4d22..c818bd7 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 2787fae..50173cc 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 2832a7a..bc36959 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 5c22eb1..72730a4 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 c959551..847c31b 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 d3751e6..dae73fa 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 adde54c..aa439ce 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 fc25ea7..9b11628 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 7a26e79..767d8c6 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 6e98bae..c1135e8 100644 --- a/approved/0091-dht-record-creation-time.html +++ b/approved/0091-dht-record-creation-time.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index f4d5b97..1f1462e 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index f4d5b97..1f1462e 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0100-xcm-multi-type-asset-transfer.html b/new/0100-xcm-multi-type-asset-transfer.html index 325b890..c97c500 100644 --- a/new/0100-xcm-multi-type-asset-transfer.html +++ b/new/0100-xcm-multi-type-asset-transfer.html @@ -90,7 +90,7 @@ diff --git a/new/0101-xcm-transact-allow-unlimited-weight.html b/new/0101-xcm-transact-allow-unlimited-weight.html index e46c432..5214a7c 100644 --- a/new/0101-xcm-transact-allow-unlimited-weight.html +++ b/new/0101-xcm-transact-allow-unlimited-weight.html @@ -90,7 +90,7 @@ diff --git a/new/0102-offchain-parachain-runtime-upgrades.html b/new/0102-offchain-parachain-runtime-upgrades.html index 254f321..f8a75d7 100644 --- a/new/0102-offchain-parachain-runtime-upgrades.html +++ b/new/0102-offchain-parachain-runtime-upgrades.html @@ -90,7 +90,7 @@ @@ -415,6 +415,12 @@ time gets wasted because of this. Parachains will need to implement the introduced request/response protocol and adapt to the new signalling mechanism via an UMP message, instead of sending the code upgrade directly.

+

For parachain operators we should emit events on initiated runtime upgrade and +each block reporting the current counter and how many blocks to go until the +upgrade gets passed to pre-checking. This is especially important for on-demand +chains or bulk users not occupying a full core. Further more that behaviour of +requiring multiple blocks to fully initiate a runtime upgrade needs to be well +documented.

Compatibility

We will continue to support the old mechanism for code upgrades for a while, but will start to impose stricter limits over time, with the number of registered @@ -516,7 +522,7 @@ sharing if multiple parachains use the same data (e.g. same smart contracts).

- @@ -530,7 +536,7 @@ sharing if multiple parachains use the same data (e.g. same smart contracts).

- diff --git a/new/0103-introduce-core-index-commitment.html b/new/0103-introduce-core-index-commitment.html new file mode 100644 index 0000000..250ea9d --- /dev/null +++ b/new/0103-introduce-core-index-commitment.html @@ -0,0 +1,395 @@ + + + + + + + RFC-0103: Introduce a CoreIndex commitment in candidate receipts - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0103: Introduce a CoreIndex commitment in candidate receipts

+
+ + + +
Start Date15 July 2024
DescriptionConstrain parachain block validity on a specific core
AuthorsAndrei Sandu
+
+

Summary

+

The only requirement for collator nodes is to provide valid parachain blocks to the validators of a backing group and by definition the collator set is trustless. However, in the case of elastic scaling, for security reason, collators must be trusted - non-malicious. CoreIndex commitments are required to remove this limitation.

+

Motivation

+

At present time misbehaving collator nodes can prevent their parachain from effecitvely using elastic scaling by providing the same valid block to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core. +There are no special requirements from collators to do it, just being a full node is sufficient and there are no methods of punishing or rewarding good behaviour.

+

This RFC solves the problem by enabling a parachain to provide the core index information as part of it's PVF execution output and in the associated candidate receipt data structure.

+

Once this RFC is implemented the validity of a parachain block depends on the core it is being executed on.

+

Stakeholders

+
    +
  • Polkadot core developers.
    • +
  • Cumulus node developers.
    • +
  • Tooling, block explorer developers.
    • +
+

This approach and alternatives have been considered and discussed in this issue.

+

Explanation

+

The approach proposed below was chosen primarly because it minimizes the number of breaking changes, the complexity and takes far less implementation and testing time. The proposal is to free up space and introduce a new core index field in the CandidateDescriptor primitive and use the UMP queue as output for CoreIndex commitment.

+

Reclaiming unused space in the descriptor

+

The CandidateDescriptor currently includes collator and signature fields. The collator includes a signature on the following descriptor fields: parachain id, relay parent, validation data hash, validation code hash and the PoV hash.

+

However, in practice, having a collator signature in the receipt on the relay chain does not provide any benefits as there is no mechanism to punish or reward collators that have provided bad parachain blocks.

+

This proposal aims to remove the two fields and all the logic that checks the collator signatures. We reclaim the unused space as reserved fields and fill it with zeroes, so there is no change in the layout and lenght of the receipt. The new primitive binary compatible with the old one.

+

Backwards compatibility

+

There are two flavors of candidate receipts which are used in network protocols, runtime and node implementation:

+
    +
  • CommittedCandidateReceipt which includes the CanidateDescriptor and the CandidateCommitments
    • +
  • CandidateReceipt which includes the CanidateDescriptor and just a hash of the commitments
    • +
+

We want to support both the old and new versions in the runtime and node . The implementation must be able to detect the version of a given candidate receipt.

+

This is easy to do in both cases:

+
    +
  • the reserved fields are zeroed
    • +
  • the UMP queue contains the core index commitment that matches the core index in the descriptor.
    • +
+

Polkadot Primitive changes

+

New CandidateDescriptor

+
    +
  • reclaim 32 bytes from collator: CollatorId and 64 bytes from signature: CollatorSignature as reserved
    • +
  • use 4 bytes for a new core_index: CoreIndex field.
    • +
  • the unused reclaimed space will be filled with zeroes
    • +
+

Thew new primitive will look like this:

+
pub struct CandidateDescriptor<H = Hash> {
+	/// The ID of the para this is a candidate for.
+	pub para_id: Id,
+	/// The hash of the relay-chain block this is executed in the context of.
+	pub relay_parent: H,
+	/// The core index where the candidate is backed.
+	pub core_index: CoreIndex,
+	/// Reserved bytes.
+	pub reserved1: [u8; 28],
+	/// The blake2-256 hash of the persisted validation data. This is extra data derived from
+	/// relay-chain state which may vary based on bitfields included before the candidate.
+	/// Thus it cannot be derived entirely from the relay-parent.
+	pub persisted_validation_data_hash: Hash,
+	/// The blake2-256 hash of the PoV.
+	pub pov_hash: Hash,
+	/// The root of a block's erasure encoding Merkle tree.
+	pub erasure_root: Hash,
+	/// Reserved bytes.
+	pub reserved2: [u8; 64],
+	/// Hash of the para header that is being generated by this candidate.
+	pub para_head: Hash,
+	/// The blake2-256 hash of the validation code bytes.
+	pub validation_code_hash: ValidationCodeHash,
+}
+
+
+

In the future, parts of the reserved1 and reserved2 bytes can be used to include additional information in the descriptor.

+

Introduce new primitive for representing the CoreIndex commitment as an enum to allow future additions.

+
pub enum UMPSignal {
+	OnCore(CoreIndex),
+}
+
+

Cumulus primitives

+

Add a new version of the ParachainInherentData structure which includes an additional core_index field.

+
pub struct ParachainInherentData {
+	pub validation_data: PersistedValidationData,
+	/// A storage proof of a predefined set of keys from the relay-chain.
+	///
+	/// Specifically this witness contains the data for:
+	///
+	/// - the current slot number at the given relay parent
+	/// - active host configuration as per the relay parent,
+	/// - the relay dispatch queue sizes
+	/// - the list of egress HRMP channels (in the list of recipients form)
+	/// - the metadata for the egress HRMP channels
+	pub relay_chain_state: sp_trie::StorageProof,
+	/// Downward messages in the order they were sent.
+	pub downward_messages: Vec<InboundDownwardMessage>,
+	/// HRMP messages grouped by channels. The messages in the inner vec must be in order they
+	/// were sent. In combination with the rule of no more than one message in a channel per block,
+	/// this means `sent_at` is **strictly** greater than the previous one (if any).
+	pub horizontal_messages: BTreeMap<ParaId, Vec<InboundHrmpMessage>>,
+        /// The core index on which the parachain block must be backed
+        pub core_index: CoreIndex,
+}
+
+

UMP transport

+

CandidateCommitments remains unchanged as we will store scale encoded UMPSignal messages directly in the parachain UMP queue by outputing them in the upward_messages.

+

The UMP queue layout is adjusted to allow the relay chain to receive both the XCM messages and UMPSignal messages. We will introduce a message separator that will be implemented as an empty Vec<u8>.

+

The separator marks the end of the XCM messages and the begging of the UMPSignal messages.

+

Example:

+
[ XCM message1, XCM message2, ..., EMPTY message, UMPSignal::CoreIndex ]
+
+

Parachain block validation

+

Backers will make use of the core index information to validate the blocks during backing and reject blocks if:

+
    +
  • the core_index in descriptor does not match the one in the UMPSignal.
    • +
  • the core_index in the descriptor does not match the core the backing group is assigned to
    • +
+

If core index information is not available (backers got an old candidate receipt), there will be no changes compared to current behaviour.

+

Drawbacks

+

The only drawback is that further additions to the descriptor are limited to the amount of remaining unused space.

+

Testing, Security, and Privacy

+

Standard testing (unit tests, CI zombienet tests) for functionality and mandatory secuirty audit to ensure the implementation does not introduce any new security issues.

+

Backwards compatibility of the implementation will be tested on testnets (Versi and Westend).

+

There is no impact on privacy.

+

Performance

+

The expectation is that performance impact is negligible for sending and processing the UMP message has negligible performance impact in the runtime as well as on the node side.

+

Ergonomics

+

Parachain that use elastic scaling must send the separator empty message followed by the UMPSignal::OnCore only after sending all of the UMP XCM messages.

+

Compatibility

+

To ensure a smooth transition the first step is to remove collator signature checking logic on the node side and upgrade validators. Any tooling that uses these fields will require similar changes as described above to support both formats.

+

The runtime does not check the collator signature so there are no other specific concers for compatibility except adding the support for the new primitives.

+

CoreIndex commitments are mandatory only for parachains using elastic scaling. No new implementation of networking protocol versions for collation and validation are required.

+

Prior Art and References

+

Forum discussion about a new CandidateReceipt format: https://forum.polkadot.network/t/pre-rfc-discussion-candidate-receipt-format-v2/3738

+

Unresolved Questions

+

N/A

+ +

The implementation is extensible and future proof to some extent. With minimal or no breaking changes, additional fields can be added in the candidate descriptor until the reserved space is exhausted

+

Once the reserved space is exhausted, versioning will be implemented. The candidate receipt format will be versioned. This will exteend to pvf execution which requires versioning for the validation function, inputs and outputs (CandidateCommitments).

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index dd4b6f9..439ccf4 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -769,6 +769,12 @@ time gets wasted because of this. Parachains will need to implement the introduced request/response protocol and adapt to the new signalling mechanism via an UMP message, instead of sending the code upgrade directly.

+

For parachain operators we should emit events on initiated runtime upgrade and +each block reporting the current counter and how many blocks to go until the +upgrade gets passed to pre-checking. This is especially important for on-demand +chains or bulk users not occupying a full core. Further more that behaviour of +requiring multiple blocks to fully initiate a runtime upgrade needs to be well +documented.

Compatibility

We will continue to support the old mechanism for code upgrades for a while, but will start to impose stricter limits over time, with the number of registered @@ -861,6 +867,173 @@ added host function. The nice thing about this approach is, that while we can upgrade incrementally, lifetime is still tied to the PVF and we get all the same guarantees. Assuming the validators store blobs by hash, we even get disk sharing if multiple parachains use the same data (e.g. same smart contracts).

+

(source)

+

Table of Contents

+ +

RFC-0103: Introduce a CoreIndex commitment in candidate receipts

+
+ + + +
Start Date15 July 2024
DescriptionConstrain parachain block validity on a specific core
AuthorsAndrei Sandu
+
+

Summary

+

The only requirement for collator nodes is to provide valid parachain blocks to the validators of a backing group and by definition the collator set is trustless. However, in the case of elastic scaling, for security reason, collators must be trusted - non-malicious. CoreIndex commitments are required to remove this limitation.

+

Motivation

+

At present time misbehaving collator nodes can prevent their parachain from effecitvely using elastic scaling by providing the same valid block to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core. +There are no special requirements from collators to do it, just being a full node is sufficient and there are no methods of punishing or rewarding good behaviour.

+

This RFC solves the problem by enabling a parachain to provide the core index information as part of it's PVF execution output and in the associated candidate receipt data structure.

+

Once this RFC is implemented the validity of a parachain block depends on the core it is being executed on.

+

Stakeholders

+ +

This approach and alternatives have been considered and discussed in this issue.

+

Explanation

+

The approach proposed below was chosen primarly because it minimizes the number of breaking changes, the complexity and takes far less implementation and testing time. The proposal is to free up space and introduce a new core index field in the CandidateDescriptor primitive and use the UMP queue as output for CoreIndex commitment.

+

Reclaiming unused space in the descriptor

+

The CandidateDescriptor currently includes collator and signature fields. The collator includes a signature on the following descriptor fields: parachain id, relay parent, validation data hash, validation code hash and the PoV hash.

+

However, in practice, having a collator signature in the receipt on the relay chain does not provide any benefits as there is no mechanism to punish or reward collators that have provided bad parachain blocks.

+

This proposal aims to remove the two fields and all the logic that checks the collator signatures. We reclaim the unused space as reserved fields and fill it with zeroes, so there is no change in the layout and lenght of the receipt. The new primitive binary compatible with the old one.

+

Backwards compatibility

+

There are two flavors of candidate receipts which are used in network protocols, runtime and node implementation:

+ +

We want to support both the old and new versions in the runtime and node . The implementation must be able to detect the version of a given candidate receipt.

+

This is easy to do in both cases:

+ +

Polkadot Primitive changes

+

New CandidateDescriptor

+ +

Thew new primitive will look like this:

+
pub struct CandidateDescriptor<H = Hash> {
+	/// The ID of the para this is a candidate for.
+	pub para_id: Id,
+	/// The hash of the relay-chain block this is executed in the context of.
+	pub relay_parent: H,
+	/// The core index where the candidate is backed.
+	pub core_index: CoreIndex,
+	/// Reserved bytes.
+	pub reserved1: [u8; 28],
+	/// The blake2-256 hash of the persisted validation data. This is extra data derived from
+	/// relay-chain state which may vary based on bitfields included before the candidate.
+	/// Thus it cannot be derived entirely from the relay-parent.
+	pub persisted_validation_data_hash: Hash,
+	/// The blake2-256 hash of the PoV.
+	pub pov_hash: Hash,
+	/// The root of a block's erasure encoding Merkle tree.
+	pub erasure_root: Hash,
+	/// Reserved bytes.
+	pub reserved2: [u8; 64],
+	/// Hash of the para header that is being generated by this candidate.
+	pub para_head: Hash,
+	/// The blake2-256 hash of the validation code bytes.
+	pub validation_code_hash: ValidationCodeHash,
+}
+
+
+

In the future, parts of the reserved1 and reserved2 bytes can be used to include additional information in the descriptor.

+

Introduce new primitive for representing the CoreIndex commitment as an enum to allow future additions.

+
pub enum UMPSignal {
+	OnCore(CoreIndex),
+}
+
+

Cumulus primitives

+

Add a new version of the ParachainInherentData structure which includes an additional core_index field.

+
pub struct ParachainInherentData {
+	pub validation_data: PersistedValidationData,
+	/// A storage proof of a predefined set of keys from the relay-chain.
+	///
+	/// Specifically this witness contains the data for:
+	///
+	/// - the current slot number at the given relay parent
+	/// - active host configuration as per the relay parent,
+	/// - the relay dispatch queue sizes
+	/// - the list of egress HRMP channels (in the list of recipients form)
+	/// - the metadata for the egress HRMP channels
+	pub relay_chain_state: sp_trie::StorageProof,
+	/// Downward messages in the order they were sent.
+	pub downward_messages: Vec<InboundDownwardMessage>,
+	/// HRMP messages grouped by channels. The messages in the inner vec must be in order they
+	/// were sent. In combination with the rule of no more than one message in a channel per block,
+	/// this means `sent_at` is **strictly** greater than the previous one (if any).
+	pub horizontal_messages: BTreeMap<ParaId, Vec<InboundHrmpMessage>>,
+        /// The core index on which the parachain block must be backed
+        pub core_index: CoreIndex,
+}
+
+

UMP transport

+

CandidateCommitments remains unchanged as we will store scale encoded UMPSignal messages directly in the parachain UMP queue by outputing them in the upward_messages.

+

The UMP queue layout is adjusted to allow the relay chain to receive both the XCM messages and UMPSignal messages. We will introduce a message separator that will be implemented as an empty Vec<u8>.

+

The separator marks the end of the XCM messages and the begging of the UMPSignal messages.

+

Example:

+
[ XCM message1, XCM message2, ..., EMPTY message, UMPSignal::CoreIndex ]
+
+

Parachain block validation

+

Backers will make use of the core index information to validate the blocks during backing and reject blocks if:

+ +

If core index information is not available (backers got an old candidate receipt), there will be no changes compared to current behaviour.

+

Drawbacks

+

The only drawback is that further additions to the descriptor are limited to the amount of remaining unused space.

+

Testing, Security, and Privacy

+

Standard testing (unit tests, CI zombienet tests) for functionality and mandatory secuirty audit to ensure the implementation does not introduce any new security issues.

+

Backwards compatibility of the implementation will be tested on testnets (Versi and Westend).

+

There is no impact on privacy.

+

Performance

+

The expectation is that performance impact is negligible for sending and processing the UMP message has negligible performance impact in the runtime as well as on the node side.

+

Ergonomics

+

Parachain that use elastic scaling must send the separator empty message followed by the UMPSignal::OnCore only after sending all of the UMP XCM messages.

+

Compatibility

+

To ensure a smooth transition the first step is to remove collator signature checking logic on the node side and upgrade validators. Any tooling that uses these fields will require similar changes as described above to support both formats.

+

The runtime does not check the collator signature so there are no other specific concers for compatibility except adding the support for the new primitives.

+

CoreIndex commitments are mandatory only for parachains using elastic scaling. No new implementation of networking protocol versions for collation and validation are required.

+

Prior Art and References

+

Forum discussion about a new CandidateReceipt format: https://forum.polkadot.network/t/pre-rfc-discussion-candidate-receipt-format-v2/3738

+

Unresolved Questions

+

N/A

+ +

The implementation is extensible and future proof to some extent. With minimal or no breaking changes, additional fields can be added in the candidate descriptor until the reserved space is exhausted

+

Once the reserved space is exhausted, versioning will be implemented. The candidate receipt format will be versioned. This will exteend to pvf execution which requires versioning for the validation function, inputs and outputs (CandidateCommitments).

(source)

Table of Contents

-

Drawbacks

+

Drawbacks

The main drawback of adding the additional complexity directly to the broker pallet is the potential increase in maintenance overhead. Therefore, we propose adding additional functionality as a separate pallet on the Coretime chain. To take the pressure off from implementing these features, implementation along with unit tests would be taken care of by Lastic (Aurora Makovac, Philip Lucsok).

There are potential risks of security vulnerabilities in the new market functionalities, such as unauthorized region transfers or incorrect balance adjustments. Therefore, extensive security measures would have to be implemented.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Testing

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance

-

Ergonomics

+

Ergonomics

-

Compatibility

+

Compatibility

-

Prior Art and References

+

Prior Art and References

-

Unresolved Questions

+

Unresolved Questions

- + -

Drawbacks

+

Drawbacks

There are several drawbacks to consider:

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Testing

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance

-

Ergonomics

+

Ergonomics

-

Compatibility

+

Compatibility

-

Prior Art and References

+

Prior Art and References

-

Unresolved Questions

+

Unresolved Questions

- + -

Prior Art and References

+

Prior Art and References

Robert Habermeier initially wrote on the subject of Polkadot blockspace-centric in the article Polkadot Blockspace over Blockchains. While not going into details, the article served as an early reframing piece for moving beyond one-slot-per-chain models and building out secondary market infrastructure for resource allocation.

(source)

Table of Contents

@@ -2033,10 +2206,10 @@ InstaPoolHistory: (empty) AuthorsGavin Wood, Robert Habermeier -

Summary

+

Summary

In the Agile Coretime model of the Polkadot Ubiquitous Computer, as proposed in RFC-1 and RFC-3, it is necessary for the allocating parachain (envisioned to be one or more pallets on a specialised Brokerage System Chain) to communicate the core assignments to the Relay-chain, which is responsible for ensuring those assignments are properly enacted.

This is a proposal for the interface which will exist around the Relay-chain in order to communicate this information and instructions.

-

Motivation

+

Motivation

The background motivation for this interface is splitting out coretime allocation functions and secondary markets from the Relay-chain onto System parachains. A well-understood and general interface is necessary for ensuring the Relay-chain receives coretime allocation instructions from one or more System chains without introducing dependencies on the implementation details of either side.

Requirements

-

Stakeholders

+

Stakeholders

Primary stakeholder sets are:

Socialization:

This content of this RFC was discussed in the Polkdot Fellows channel.

-

Explanation

+

Explanation

The interface has two sections: The messages which the Relay-chain is able to receive from the allocating parachain (the UMP message types), and messages which the Relay-chain is able to send to the allocating parachain (the DMP message types). These messages are expected to be able to be implemented in a well-known pallet and called with the XCM Transact instruction.

Future work may include these messages being introduced into the XCM standard.

UMP Message Types

@@ -2133,15 +2306,15 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600);

For assign_core, a successful request should be possible if begin is no less than the Relay-chain block number on arrival of the message plus 10 and workload contains no more than 100 items.

Performance, Ergonomics and Compatibility

No specific considerations.

-

Testing, Security and Privacy

+

Testing, Security and Privacy

Standard Polkadot testing and security auditing applies.

The proposal introduces no new privacy concerns.

- +

RFC-1 proposes a means of determining allocation of Coretime using this interface.

RFC-3 proposes a means of implementing the high-level allocations within the Relay-chain.

Drawbacks, Alternatives and Unknowns

None at present.

-

Prior Art and References

+

Prior Art and References

None.

(source)

Table of Contents

@@ -2187,13 +2360,13 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600); AuthorsJoe Petrowski -

Summary

+

Summary

As core functionality moves from the Relay Chain into system chains, so increases the reliance on the liveness of these chains for the use of the network. It is not economically scalable, nor necessary from a game-theoretic perspective, to pay collators large rewards. This RFC proposes a mechanism -- part technical and part social -- for ensuring reliable collator sets that are resilient to attemps to stop any subsytem of the Polkadot protocol.

-

Motivation

+

Motivation

In order to guarantee access to Polkadot's system, the collators on its system chains must propose blocks (provide liveness) and allow all transactions to eventually be included. That is, some collators may censor transactions, but there must exist one collator in the set who will include a @@ -2229,12 +2402,12 @@ to censor any subset of transactions.

  • Collators selected by governance SHOULD have a reasonable expectation that the Treasury will reimburse their operating costs.
    • -

    Stakeholders

    +

    Stakeholders

    -

    Explanation

    +

    Explanation

    This protocol builds on the existing Collator Selection pallet and its notion of Invulnerables. Invulnerables are collators (identified by their AccountIds) who @@ -2270,27 +2443,27 @@ approximately:

  • of which 15 are Invulnerable, and
  • five are elected by bond.
    • -

    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

    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)

    @@ -2346,10 +2519,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.

    @@ -2358,9 +2531,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.

    @@ -2397,10 +2570,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.

    @@ -2410,21 +2583,21 @@ Furthermore, when a large number of providers (here, a provider is a bootnode) a 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

    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

    @@ -2445,13 +2618,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.

    @@ -2494,13 +2667,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

    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

    @@ -3792,11 +3965,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 @@ -3808,13 +3981,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: