diff --git a/404.html b/404.html index 770ff00..a841695 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 02ab8d3..c0cd770 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 b7304be..3328218 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 c724ba3..2fb7d3d 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 82b606b..e115091 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 5e17dbe..0a995a2 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 8cb6114..7d41b86 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 0db771e..18cdea0 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 e9833d1..70c8570 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 7e9d1b2..d827b56 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 7456cb6..565743f 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 2c3f789..3c6b6af 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 050b922..7ce97b3 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 0edd935..d2e83cc 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 e9cd642..a1c9d29 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 633541b..26d2c9b 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 1ce20bb..953b060 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 792d020..d344cd6 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 d6f102c..67c92f4 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 224a22f..a5f46d3 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 14d9b3b..0d9949f 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 bd6b738..6624b1d 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 d52b098..b515f8d 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 0c7f490..ef202ea 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 22fce81..02f9182 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 5109567..e74195e 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 c8ea0af..2a28ea9 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 9ea9090..741e079 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 ca2ceae..402f6be 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 dd2e4fa..a3e5c4f 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 ecaf30c..4151afa 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 ac6d661..2fdfd95 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 0face9d..909d841 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index 0face9d..909d841 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0124-extrinsic-version-5.html b/new/0124-extrinsic-version-5.html index 3fe0887..813a667 100644 --- a/new/0124-extrinsic-version-5.html +++ b/new/0124-extrinsic-version-5.html @@ -90,7 +90,7 @@ @@ -337,7 +337,7 @@ work.

- @@ -351,7 +351,7 @@ work.

- diff --git a/new/0125-xcm-asset-metadata.html b/new/0125-xcm-asset-metadata.html new file mode 100644 index 0000000..a9ca1cb --- /dev/null +++ b/new/0125-xcm-asset-metadata.html @@ -0,0 +1,442 @@ + + + + + + + RFC-0125: XCM Asset Metadata - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0125: XCM Asset Metadata

+
+ + + +
Start Date22 Oct 2024
DescriptionXCM Asset Metadata definition and a way of communicating it via XCM
AuthorsDaniel Shiposha
+
+

Summary

+

This RFC proposes a metadata format for XCM-identifiable assets (i.e., for fungible/non-fungible collections and non-fungible tokens) and a set of instructions to communicate it across chains.

+

Motivation

+

Currently, there is no way to communicate metadata of an asset (or an asset instance) via XCM.

+

The ability to query and modify the metadata is useful for two kinds of entities:

+
    +
  • +

    Asset collections (both fungible and nonfungible).

    +

    Any collection has some metadata, such as the name of the collection. The standard way of communicating metadata could help with registering foreign assets within a consensus system. Therefore, this RFC could complement or supersede the RFC for initializing fully-backed derivatives (note that this RFC is related to the old XCM RFC process; it's not the Fellowship RFC and hasn't been migrated yet).

    +
    • +
  • +

    NFTs (i.e., asset instances).

    +

    The metadata is the crucial aspect of any nonfungible object since metadata assigns meaning to such an object. The metadata for NFTs is just as important as the notion of "amount" for fungibles (there is no sense in fungibles if they have no amount).

    +

    An NFT is always a representation of some object. The metadata describes the object represented by the NFT.

    +

    NFTs can be transferred to another chain via XCM. However, there are limitations due to the inability to communicate its metadata:

    +
      +
    1. Teleports are inherently impossible because they imply the complete transfer of an NFT, including its metadata, which can't be done via XCM now.
      2. +
    2. Reserve-based transfers currently have limited use-case scenarios if the reserve chain provides a way of modifying metadata for its users (usually, the token's owner has privileged rights to modify a specific metadata subset). When a user transfers an NFT using this model to another chain, the NFT owner-related metadata can't be updated anymore because another chain's sovereign account owns the original token, and another chain cannot modify the metadata. However, if it were possible to update NFT metadata in the standard XCM way, another chain could offer additional metadata-related logic. For instance, it could provide a facade logic to metadata modification (i.e., provide permission-based modification authorization, new value format check, etc.).
      3. +
    +
    • +
+

Besides metadata modification, the ability to read it is also valuable. On-chain logic can interpret the NFT metadata, i.e., the metadata could have not only the media meaning but also a utility function within a consensus system. Currently, such a way of using NFT metadata is possible only within one consensus system. This RFC proposes making it possible between different systems via XCM so different chains can fetch and analyze the asset metadata from other chains.

+

Stakeholders

+

Runtime users, Runtime devs, Cross-chain dApps, Wallets.

+

Explanation

+

The Asset Metadata is information bound to an asset class (fungible or NFT collection) or an asset instance (an NFT). +The Asset Metadata could be represented differently on different chains (or in other consensus entities). +However, to communicate metadata between consensus entities via XCM, we need a general format so that any consensus entity can make sense of such information.

+

We can name this format "XCM Asset Metadata".

+

This RFC proposes:

+
    +
  1. +

    Using key-value pairs as XCM Asset Metadata since it is a general concept useful for both structured and unstructured data. Both key and value can be raw bytes with interpretation up to the communicating entities.

    +

    The XCM Asset Metadata should be represented as a map SCALE-encoded equivalent to the BTreeMap.

    +

    Let's call the type of the XCM Asset Metadata map MetadataMap.

    +
    2. +
  2. +

    Communicating only the demanded part of the metadata, not the whole metadata.

    +
      +
    • +

      A consensus entity should be able to query the values of interested keys to read the metadata. +To specify the keys to read, we need a set-like type. Let's call that type MetadataKeys and make its instance a SCALE-encoded equivalent to the BTreeSet.

      +
      • +
    • +

      A consensus entity should be able to write the values for specified keys.

      +
      • +
    +
    3. +
  3. +

    New XCM instructions to communicate the metadata.

    +
    4. +
+

New instructions

+

ReportMetadata

+

The ReportMetadata is a new instruction to query metadata information. +It can be used to query metadata key list or to query values of interested keys.

+

This instruction allows querying the metadata of:

+
    +
  • a collection (fungible or nonfungible)
    • +
  • an NFT
    • +
+

If an asset (or an asset instance) for which the query is made doesn't exist, the Response::Null should be reported via the existing QueryResponse instruction.

+

The ReportMetadata can be used without origin (i.e., following the ClearOrigin instruction) since it only reads state.

+

Safety: The reporter origin should be trusted to hold the true metadata. If the reserve-based model is considered, the asset's reserve location must be viewed as the only source of truth about the metadata.

+

The use case for this instruction is when the metadata information of a foreign asset (or asset instance) is used in the logic of a consensus entity that requested it.

+
#![allow(unused)]
+fn main() {
+/// An instruction to query metadata of an asset or an asset instance.
+ReportMetadata {
+    /// The ID of an asset (a collection, fungible or nonfungible).
+    asset_id: AssetId,
+
+    /// The ID of an asset instance.
+    ///
+    /// If the value is `Undefined`, the metadata of the collection is reported.
+    instance: AssetInstance,
+
+    /// See `MetadataQueryKind` below.
+    query_kind: MetadataQueryKind,
+
+    /// The usual field for Report<something> XCM instructions.
+    ///
+    /// Information regarding the query response.
+    /// The `QueryResponseInfo` type is already defined in the XCM spec.
+    response_info: QueryResponseInfo,
+}
+}
+

Where the MetadataQueryKind is:

+
#![allow(unused)]
+fn main() {
+enum MetadataQueryKind {
+    /// Query metadata key list.
+    KeyList,
+
+    /// Query values of the specified keys.
+    Values(MetadataKeys),
+}
+}
+

The QueryMetadata works in conjunction with the existing QueryResponse instruction. The Response type should be modified accordingly: we need to add a new AssetMetadata variant to it.

+
#![allow(unused)]
+fn main() {
+/// The struct used in the existing `QueryResponse` instruction.
+pub enum Response {
+    // ... snip, existing variants ...
+
+    /// The metadata info.
+    AssetMetadata {
+        /// The ID of an asset (a collection, fungible or nonfungible).
+        asset_id: AssetId,
+
+        /// The ID of an asset instance.
+        ///
+        /// If the value is `Undefined`, the reported metadata is related to the collection, not a token.
+        instance: AssetInstance,
+
+        /// See `MetadataResponseData` below.
+        data: MetadataResponseData,
+    }
+}
+
+pub enum MetadataResponseData {
+    /// The metadata key list to be reported
+    /// in response to the `KeyList` metadata query kind.
+    KeyList(MetadataKeys),
+
+    /// The values of the keys that were specified in the
+    /// `Values` variant of the metadata query kind.
+    Values(MetadataMap),
+}
+}
+

ModifyMetadata

+

The ModifyMetadata is a new instruction to request a remote chain to modify the values of the specified keys.

+

This instruction can be used to update the metadata of a collection (fungible or nonfungible) or of an NFT.

+

The remote chain handles the modification request and may reject it based on its internal rules. +The request can only be executed or rejected in its entirety. It must not be executed partially.

+

To execute the ModifyMetadata, an origin is required so that the handling logic can authorize the metadata modification request from a known source. Since this instruction requires an origin, the assets used to cover the execution fees must be transferred in a way that preserves the origin. For instance, one can use the approach described in RFC #122 if the handling chain configured aliasing rules accordingly.

+

The example use case of this instruction is to ask the reserve location of the asset to modify the metadata. So that, the original asset's metadata is updated according to the reserve location's rules.

+
#![allow(unused)]
+fn main() {
+ModifyMetadata {
+    /// The ID of an asset (a collection, fungible or nonfungible).
+    asset_id: AssetId,
+
+    /// The ID of an asset instance.
+    ///
+    /// If the value is `Undefined`, the modification request targets the collection, not a token.
+    instance: AssetInstance,
+
+    /// The map contains the keys mapped to the requested new values.
+    modification: MetadataMap,
+}
+}
+

Repurposing AssetInstance::Undefined

+

As the new instructions show, this RFC reframes the purpose of the Undefined variant of the AssetInstance enum. +This RFC proposes to use the Undefined variant of a collection identified by an AssetId as a synonym of the collection itself. I.e., an asset Asset { id: <AssetId>, fun: Undefined } is considered an NFT representing the collection itself.

+

As a singleton non-fungible instance is barely distinguishable from its collection, this convention shouldn't cause any problems.

+

Thus, the AssetInstance docs must be updated accordingly in the implementations.

+

Drawbacks

+

Regarding ergonomics, no drawbacks were noticed.

+

As for the user experience, it could discover new cross-chain use cases involving asset collections and NFTs, indicating a positive impact.

+

There are no security concerns except for the ReportMetadata instruction, which implies that the source of the information must be trusted.

+

In terms of performance and privacy, there will be no changes.

+

Testing, Security, and Privacy

+

The implementations must honor the contract for the new instructions. Namely, if the instance field has the value of AssetInstance::Undefined, the metadata must relate to the asset collection but not to a non-fungible token inside it.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

No significant impact.

+

Ergonomics

+

Introducing a standard metadata format and a way of communicating it is a valuable addition to the XCM format that potentially increases cross-chain interoperability without the need to form ad-hoc chain-to-chain integrations via Transact.

+

Compatibility

+

This RFC proposes new functionality, so there are no compatibility issues.

+

Prior Art and References

+

RFC: XCM Asset Metadata

+

Unresolved Questions

+

Should the MetadataMap and MetadataKeys be bounded, or is it enough to rely on the fact that every XCM message is itself bounded?

+ +

The original RFC draft contained additional metadata instructions. Though they could be useful, they're clearly outside the basic logic. So, this RFC version omits them to make the metadata discussion more focused on the core things. Nonetheless, there is hope that metadata approval instructions might be useful in the future, so they are mentioned here.

+

You can read about the details in the original draft.

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index 20c2401..6e9e0df 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -334,6 +334,220 @@ format and add it to the metadata.

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

+ +

RFC-0125: XCM Asset Metadata

+
+ + + +
Start Date22 Oct 2024
DescriptionXCM Asset Metadata definition and a way of communicating it via XCM
AuthorsDaniel Shiposha
+
+

Summary

+

This RFC proposes a metadata format for XCM-identifiable assets (i.e., for fungible/non-fungible collections and non-fungible tokens) and a set of instructions to communicate it across chains.

+

Motivation

+

Currently, there is no way to communicate metadata of an asset (or an asset instance) via XCM.

+

The ability to query and modify the metadata is useful for two kinds of entities:

+ +

Besides metadata modification, the ability to read it is also valuable. On-chain logic can interpret the NFT metadata, i.e., the metadata could have not only the media meaning but also a utility function within a consensus system. Currently, such a way of using NFT metadata is possible only within one consensus system. This RFC proposes making it possible between different systems via XCM so different chains can fetch and analyze the asset metadata from other chains.

+

Stakeholders

+

Runtime users, Runtime devs, Cross-chain dApps, Wallets.

+

Explanation

+

The Asset Metadata is information bound to an asset class (fungible or NFT collection) or an asset instance (an NFT). +The Asset Metadata could be represented differently on different chains (or in other consensus entities). +However, to communicate metadata between consensus entities via XCM, we need a general format so that any consensus entity can make sense of such information.

+

We can name this format "XCM Asset Metadata".

+

This RFC proposes:

+
    +
  1. +

    Using key-value pairs as XCM Asset Metadata since it is a general concept useful for both structured and unstructured data. Both key and value can be raw bytes with interpretation up to the communicating entities.

    +

    The XCM Asset Metadata should be represented as a map SCALE-encoded equivalent to the BTreeMap.

    +

    Let's call the type of the XCM Asset Metadata map MetadataMap.

    +
    2. +
  2. +

    Communicating only the demanded part of the metadata, not the whole metadata.

    + +
    3. +
  3. +

    New XCM instructions to communicate the metadata.

    +
    4. +
+

New instructions

+

ReportMetadata

+

The ReportMetadata is a new instruction to query metadata information. +It can be used to query metadata key list or to query values of interested keys.

+

This instruction allows querying the metadata of:

+ +

If an asset (or an asset instance) for which the query is made doesn't exist, the Response::Null should be reported via the existing QueryResponse instruction.

+

The ReportMetadata can be used without origin (i.e., following the ClearOrigin instruction) since it only reads state.

+

Safety: The reporter origin should be trusted to hold the true metadata. If the reserve-based model is considered, the asset's reserve location must be viewed as the only source of truth about the metadata.

+

The use case for this instruction is when the metadata information of a foreign asset (or asset instance) is used in the logic of a consensus entity that requested it.

+
#![allow(unused)]
+fn main() {
+/// An instruction to query metadata of an asset or an asset instance.
+ReportMetadata {
+    /// The ID of an asset (a collection, fungible or nonfungible).
+    asset_id: AssetId,
+
+    /// The ID of an asset instance.
+    ///
+    /// If the value is `Undefined`, the metadata of the collection is reported.
+    instance: AssetInstance,
+
+    /// See `MetadataQueryKind` below.
+    query_kind: MetadataQueryKind,
+
+    /// The usual field for Report<something> XCM instructions.
+    ///
+    /// Information regarding the query response.
+    /// The `QueryResponseInfo` type is already defined in the XCM spec.
+    response_info: QueryResponseInfo,
+}
+}
+

Where the MetadataQueryKind is:

+
#![allow(unused)]
+fn main() {
+enum MetadataQueryKind {
+    /// Query metadata key list.
+    KeyList,
+
+    /// Query values of the specified keys.
+    Values(MetadataKeys),
+}
+}
+

The QueryMetadata works in conjunction with the existing QueryResponse instruction. The Response type should be modified accordingly: we need to add a new AssetMetadata variant to it.

+
#![allow(unused)]
+fn main() {
+/// The struct used in the existing `QueryResponse` instruction.
+pub enum Response {
+    // ... snip, existing variants ...
+
+    /// The metadata info.
+    AssetMetadata {
+        /// The ID of an asset (a collection, fungible or nonfungible).
+        asset_id: AssetId,
+
+        /// The ID of an asset instance.
+        ///
+        /// If the value is `Undefined`, the reported metadata is related to the collection, not a token.
+        instance: AssetInstance,
+
+        /// See `MetadataResponseData` below.
+        data: MetadataResponseData,
+    }
+}
+
+pub enum MetadataResponseData {
+    /// The metadata key list to be reported
+    /// in response to the `KeyList` metadata query kind.
+    KeyList(MetadataKeys),
+
+    /// The values of the keys that were specified in the
+    /// `Values` variant of the metadata query kind.
+    Values(MetadataMap),
+}
+}
+

ModifyMetadata

+

The ModifyMetadata is a new instruction to request a remote chain to modify the values of the specified keys.

+

This instruction can be used to update the metadata of a collection (fungible or nonfungible) or of an NFT.

+

The remote chain handles the modification request and may reject it based on its internal rules. +The request can only be executed or rejected in its entirety. It must not be executed partially.

+

To execute the ModifyMetadata, an origin is required so that the handling logic can authorize the metadata modification request from a known source. Since this instruction requires an origin, the assets used to cover the execution fees must be transferred in a way that preserves the origin. For instance, one can use the approach described in RFC #122 if the handling chain configured aliasing rules accordingly.

+

The example use case of this instruction is to ask the reserve location of the asset to modify the metadata. So that, the original asset's metadata is updated according to the reserve location's rules.

+
#![allow(unused)]
+fn main() {
+ModifyMetadata {
+    /// The ID of an asset (a collection, fungible or nonfungible).
+    asset_id: AssetId,
+
+    /// The ID of an asset instance.
+    ///
+    /// If the value is `Undefined`, the modification request targets the collection, not a token.
+    instance: AssetInstance,
+
+    /// The map contains the keys mapped to the requested new values.
+    modification: MetadataMap,
+}
+}
+

Repurposing AssetInstance::Undefined

+

As the new instructions show, this RFC reframes the purpose of the Undefined variant of the AssetInstance enum. +This RFC proposes to use the Undefined variant of a collection identified by an AssetId as a synonym of the collection itself. I.e., an asset Asset { id: <AssetId>, fun: Undefined } is considered an NFT representing the collection itself.

+

As a singleton non-fungible instance is barely distinguishable from its collection, this convention shouldn't cause any problems.

+

Thus, the AssetInstance docs must be updated accordingly in the implementations.

+

Drawbacks

+

Regarding ergonomics, no drawbacks were noticed.

+

As for the user experience, it could discover new cross-chain use cases involving asset collections and NFTs, indicating a positive impact.

+

There are no security concerns except for the ReportMetadata instruction, which implies that the source of the information must be trusted.

+

In terms of performance and privacy, there will be no changes.

+

Testing, Security, and Privacy

+

The implementations must honor the contract for the new instructions. Namely, if the instance field has the value of AssetInstance::Undefined, the metadata must relate to the asset collection but not to a non-fungible token inside it.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

No significant impact.

+

Ergonomics

+

Introducing a standard metadata format and a way of communicating it is a valuable addition to the XCM format that potentially increases cross-chain interoperability without the need to form ad-hoc chain-to-chain integrations via Transact.

+

Compatibility

+

This RFC proposes new functionality, so there are no compatibility issues.

+

Prior Art and References

+

RFC: XCM Asset Metadata

+

Unresolved Questions

+

Should the MetadataMap and MetadataKeys be bounded, or is it enough to rely on the fact that every XCM message is itself bounded?

+ +

The original RFC draft contained additional metadata instructions. Though they could be useful, they're clearly outside the basic logic. So, this RFC version omits them to make the metadata discussion more focused on the core things. Nonetheless, there is hope that metadata approval instructions might be useful in the future, so they are mentioned here.

+

You can read about the details in the original draft.

(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.

@@ -979,7 +1193,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)

@@ -2581,10 +2795,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.

@@ -2593,9 +2807,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.

@@ -2632,10 +2846,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.

@@ -2644,22 +2858,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

@@ -2680,13 +2894,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.

@@ -2729,13 +2943,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

@@ -4027,11 +4241,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 @@ -4043,13 +4257,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: