From 1b5b0a235f950f6233f0806627f46602b0e9eceb Mon Sep 17 00:00:00 2001 From: bkchr Date: Wed, 5 Mar 2025 01:08:10 +0000 Subject: [PATCH] deploy: f346983cbd4b347e8cdd5c920b9124ea4dc85bf1 --- 404.html | 2 +- approved/0001-agile-coretime.html | 2 +- approved/0005-coretime-interface.html | 2 +- approved/0007-system-collator-selection.html | 2 +- approved/0008-parachain-bootnodes-dht.html | 2 +- ...09-improved-net-light-client-requests.html | 2 +- approved/0010-burn-coretime-revenue.html | 2 +- ...12-process-for-adding-new-collectives.html | 2 +- ...uilder-and-core-runtime-apis-for-mbms.html | 2 +- ...rove-locking-mechanism-for-parachains.html | 2 +- approved/0022-adopt-encointer-runtime.html | 2 +- approved/0026-sassafras-consensus.html | 2 +- approved/0032-minimal-relay.html | 2 +- approved/0042-extrinsics-state-version.html | 2 +- .../0043-storage-proof-size-hostfunction.html | 2 +- approved/0045-nft-deposits-asset-hub.html | 2 +- ...047-assignment-of-availability-chunks.html | 2 +- approved/0048-session-keys-runtime-api.html | 2 +- approved/0050-fellowship-salaries.html | 2 +- ...0056-one-transaction-per-notification.html | 2 +- .../0059-nodes-capabilities-discovery.html | 2 +- approved/0078-merkleized-metadata.html | 2 +- ...-general-transaction-extrinsic-format.html | 2 +- approved/0091-dht-record-creation-time.html | 2 +- approved/0097-unbonding_queue.html | 2 +- .../0099-transaction-extension-version.html | 2 +- .../0100-xcm-multi-type-asset-transfer.html | 2 +- ...-xcm-transact-remove-max-weight-param.html | 2 +- .../0103-introduce-core-index-commitment.html | 2 +- approved/0105-xcm-improved-fee-mechanism.html | 2 +- approved/0107-xcm-execution-hints.html | 2 +- approved/0108-xcm-remove-testnet-ids.html | 2 +- .../0122-alias-origin-on-asset-transfers.html | 2 +- approved/0125-xcm-asset-metadata.html | 2 +- index.html | 2 +- introduction.html | 2 +- print.html | 1384 ++++++++--------- proposed/0000-rewards.html | 6 +- ...-state-response-message-in-state-sync.html | 10 +- ...storage-location-for-runtime-upgrades.html | 6 +- proposed/0126-introduce-pvq.html | 2 +- proposed/0135-compressed-blob-prefixes.html | 2 +- .../0138-invulnerable-collator-election.html | 2 +- searchindex.js | 2 +- searchindex.json | 2 +- ...04-remove-unnecessary-allocator-usage.html | 2 +- ...namic-pricing-for-bulk-coretime-sales.html | 2 +- stale/0015-market-design-revisit.html | 2 +- ...-absolute-location-account-derivation.html | 2 +- ...ction-voting-delegation-modifications.html | 2 +- stale/0044-rent-based-registration.html | 2 +- stale/0054-remove-heap-pages.html | 2 +- stale/0070-x-track-kusamanetwork.html | 2 +- stale/0073-referedum-deposit-track.html | 2 +- stale/0074-stateful-multisig-pallet.html | 2 +- ...gth-of-identity-pgp-fingerprint-value.html | 2 +- ...t-purchaser-reputation-reserved-cores.html | 2 +- ...0xx-secondary-marketplace-for-regions.html | 2 +- .../00xx-smart-contracts-coretime-chain.html | 2 +- ...2-offchain-parachain-runtime-upgrades.html | 2 +- stale/0106-xcm-remove-fees-mode.html | 2 +- stale/0111-pure-proxy-replication.html | 6 +- stale/0114-secp256r1-hostfunction.html | 6 +- stale/0117-unbrick-collective.html | 2 +- ...enda-confirmation-by-candle-mechanism.html | 2 +- stale/0121-iterable-referenda-tracks.html | 2 +- stale/0124-extrinsic-version-5.html | 2 +- ...ust Tipper Track Confirmation Periods.html | 2 +- stale/TODO-stale-nomination-reward-curve.html | 2 +- 69 files changed, 772 insertions(+), 772 deletions(-) rename {stale => proposed}/0112-compress-state-response-message-in-state-sync.html (60%) diff --git a/404.html b/404.html index 45514b6..ed6b0c0 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 45950fe..efcf2a6 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 ebba487..3d6f501 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 54ded44..9fc9084 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 74835cc..eb15c7c 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0009-improved-net-light-client-requests.html b/approved/0009-improved-net-light-client-requests.html index ef233eb..2a75907 100644 --- a/approved/0009-improved-net-light-client-requests.html +++ b/approved/0009-improved-net-light-client-requests.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index b5c30cc..38d9bf7 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 fcbf40a..b9447c1 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 39b99f9..2248173 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 37ab55f..374864d 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 baae4c3..6d02014 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 4a20698..bc2154b 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 f370107..d595880 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 789e7c9..d5600b1 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 87e4e6f..cccd6ef 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 6bac9bc..e335c6b 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 cb80250..e804a5a 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 fb46b99..3ba7d97 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 01f89a7..514290c 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 9114822..a7b7ccf 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 8ec9536..2918c86 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 9c86330..d3dc57d 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 d6cda7b..33ddf01 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 b0c272c..483b860 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 c02af96..52ed885 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 f06c817..c26523b 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 bd6f8eb..55425ac 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 ef496fd..19f3b46 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 c3dc97c..58d90d1 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 9855c3a..1694446 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 f800f1d..ab06f98 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 2fab4e1..8031f14 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 79abad4..32be230 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/approved/0125-xcm-asset-metadata.html b/approved/0125-xcm-asset-metadata.html index 7820a88..bb4d4fd 100644 --- a/approved/0125-xcm-asset-metadata.html +++ b/approved/0125-xcm-asset-metadata.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index ccc56a6..3fddaa6 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index ccc56a6..3fddaa6 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/print.html b/print.html index 238ea3d..bb8a9f6 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -398,6 +398,76 @@ At this point, we compute $\beta\prime_w = \sum_v \beta\prime_{w,v}$ on-chain fo

Synthetic parachain flag

Any rewards protocol could simply be "out voted" by too many slow validators: An increase the number of parachain cores increases more workload, but this creates no-shows if too few validators could handle this workload.

We could add a synthetic parachain flag, only settable by governance, which treats no-shows as positive approval votes for that parachain, but without adding rewards. We should never enable this for real parachains, only for synthetic ones like gluttons. We should not enable the synthetic parachain flag long-term even for gluttonsm, because validators could easily modify their code. Yet, synthetic approval checks might enable pushing the hardware upgrades more agressively over the short-term.

+

(source)

+

Table of Contents

+ +

RFC-0112: Compress the State Response Message in State Sync

+
+ + + +
Start Date14 August 2024
DescriptionCompress the state response message to reduce the data transfer during the state syncing
AuthorsLiu-Cheng Xu
+
+

Summary

+

This RFC proposes compressing the state response message during the state syncing process to reduce the amount of data transferred.

+

Motivation

+

State syncing can require downloading several gigabytes of data, particularly for blockchains with large state sizes, such as Astar, which +has a state size exceeding 5 GiB (https://github.com/AstarNetwork/Astar/issues/1110). This presents a significant +challenge for nodes with slower network connections. Additionally, the current state sync implementation lacks a persistence feature (https://github.com/paritytech/polkadot-sdk/issues/4), +meaning any network disruption forces the node to re-download the entire state, making the process even more difficult.

+

Stakeholders

+

This RFC benefits all projects utilizing the Substrate framework, specifically in improving the efficiency of state syncing.

+ +

Explanation

+

The largest portion of the state response message consists of either CompactProof or Vec<KeyValueStateEntry>, depending on whether a proof is requested (source):

+ +

Drawbacks

+

None identified.

+

Testing, Security, and Privacy

+

The code changes required for this RFC are straightforward: compress the state response on the sender side and decompress it on the receiver side. Existing sync tests should ensure functionality remains intact.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

This RFC optimizes network bandwidth usage during state syncing, particularly for blockchains with gigabyte-sized states, while introducing negligible CPU overhead for compression and decompression. For example, compressing the state response during a recent Polkadot warp sync (around height #22076653) reduces the data transferred from 530,310,121 bytes to 352,583,455 bytes — a 33% reduction, saving approximately 169 MiB of data.

+

Performance data is based on this patch, with logs available here.

+

Ergonomics

+

None.

+

Compatibility

+

No compatibility issues identified.

+

Prior Art and References

+

None.

+

Unresolved Questions

+

None.

+ +

None.

(source)

Table of Contents

-

Stakeholders

+

Stakeholders

-

Explanation

+

Explanation

The core idea of PVQ is to have a unified interface that meets the aforementioned requirements.

On the runtime side, an extension-based system is introduced to serve as a standardization layer across different chains. Each extension specification defines a set of cohesive APIs. @@ -828,12 +898,12 @@ enum PvqError {

  • ExceedsMaxMessageSize
  • Transport
    • -

    Drawbacks

    +

    Drawbacks

    Performance issues

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    As a newly introduced feature, PVQ operates independently and does not impact or degrade the performance of existing runtime implementations.

    -

    Ergonomics

    +

    Ergonomics

    From the perspective of off-chain tooling, this proposal streamlines development by unifying multiple chain-specific RuntimeAPIs under a single consistent interface. This significantly benefits wallet and dApp developers by eliminating the need to handle individual implementations for similar operations across different chains. The proposal also enhances development flexibility by allowing custom computations to be modularly encapsulated as PolkaVM programs that interact with the exposed APIs.

    -

    Compatibility

    +

    Compatibility

    For RuntimeAPI integration, the proposal defines new APIs, which do not break compatibility with existing interfaces. For XCM Integration, the proposal does not modify the existing XCM message format, which is backwards compatible.

    -

    Prior Art and References

    +

    Prior Art and References

    There are several discussions related to the proposal, including:

    -

    Unresolved Questions

    +

    Unresolved Questions

    - +

    Once PVQ and the aforementioned Facade Project are ready, there are opportunities to consolidate overlapping functionality between the two systems. For example, the metadata APIs could potentially be unified to provide a more cohesive interface for runtime information. This would help reduce duplication and improve maintainability while preserving the distinct benefits of each approach.

    (source)

    Table of Contents

    @@ -928,14 +998,14 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View Authorss0me0ne-unkn0wn (13WGadgNgqSjiGQvfhimw9pX26mvGdYQ6XgrjPANSEDRoGMt) -

    Summary

    +

    Summary

    This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.

    -

    Motivation

    +

    Motivation

    Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Apart from being error-prone by itself, the current approach does not allow to properly route the blob through the execution paths before its decompression, which will result in suboptimal implementations when more blob types are used. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.

    This proposal is intended to support future work enabling Polkadot to execute PolkaVM and, more generally, other-than-Wasm parachain runtimes, and allow developers to introduce arbitrary compression methods seamlessly in the future.

    -

    Stakeholders

    +

    Stakeholders

    Node developers are the main stakeholders for this proposal. It also creates a foundation on which parachain runtime developers will build.

    -

    Explanation

    +

    Explanation

    Overview

    The current approach to compressing binary blobs involves using zstd compression, and the resulting compressed blob is prefixed with a unique 64-bit magic value specified in that subsection. The same procedure is used to compress both Wasm code blobs and proofs-of-validity. Currently, having solely a compressed blob, it's impossible to tell what's inside it without decompression, a Wasm blob, or a PoV. That doesn't cause problems in the current protocol, as Wasm blobs and PoV blobs take completely different execution paths in the code.

    The changes proposed below are intended to define the means for distinguishing compressed blob types in a backward-compatible and future-proof way.

    @@ -956,26 +1026,26 @@ PVQ does not conflict with them, and it can take advantage of these Pallet View
  • Conservatively, wait until no more PVFs prefixed with CBLOB_ZSTD_LEGACY remain on-chain. That may take quite some time. Alternatively, create a migration that alters prefixes of existing blobs;
  • Removing CBLOB_ZSTD_LEGACY prefix will be possible after all the nodes in all the networks cease using the prefix which is a long process, and additional incentives should be offered to the community to make people upgrade.
    • -

    Drawbacks

    +

    Drawbacks

    Currently, the only requirement for a compressed blob prefix is not to coincide with Wasm magic bytes (as stated in code comments). Changes proposed here increase prefix collision risk, given that arbitrary data may be compressed in the future. However, it must be taken into account that:

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    As the change increases granularity, it will positively affect both testing possibilities and security, allowing developers to check what's inside a given compressed blob precisely. Testing the change itself is trivial. Privacy is not affected by this change.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    The current implementation's performance is not affected by this change. Future implementations allowing for the execution of other-than-Wasm parachain runtimes will benefit from this change performance-wise.

    -

    Ergonomics

    +

    Ergonomics

    The end-user ergonomics is not affected. The ergonomics for developers will benefit from this change as it enables exact checks and less guessing.

    -

    Compatibility

    +

    Compatibility

    The change is designed to be backward-compatible.

    -

    Prior Art and References

    +

    Prior Art and References

    SDK PR#6704 (WIP) introduces a mechanism similar to that described in this proposal and proves the necessity of such a change.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    - +

    This proposal creates a foundation for two future work directions:

    -

    Drawbacks

    +

    Drawbacks

    The first major drawback of this proposal is that it would put more responsibility on governance by having people vote regularly in order to maintain the invulnerable collator set on each chain. Today the collator-selection pallet employs a fire-and-forget system where the invulnerables are chosen @@ -1140,24 +1210,24 @@ possibly communicate with all system chains via XCM. While this voting system co other contexts as well, I don't think it's worth conditioning the invulnerable collator redesign on a separate implementation of the multiple choice voting system when the Two-Round proposed achieves the objectives of this RFC.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    All election mechanisms as well as corner cases can be covered with unit tests.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    The chain will have to run extrinsics to start and end elections periodically, but the impact in terms of weight and PoV size is negligible.

    -

    Ergonomics

    +

    Ergonomics

    The invulnerables will be the most affected group, as they will have to now compete in elections periodically to secure their spots. Permissionless candidates will now have a clear, though not guaranteed, path towards becoming an invulnerable, at least for a period of time.

    -

    Compatibility

    +

    Compatibility

    Any changes to the election mechanism of invulnerables should be compatible with the current invulnerable set interaction with the collator set chosen at the session boundary. The current invulnerable set for each chain can be grandfathered in when upgrading the collator-selection pallet version.

    -

    Prior Art and References

    +

    Prior Art and References

    This RFC builds on RFC-7, which introduced the election mechanism for system chain collators.

    -

    Unresolved Questions

    +

    Unresolved Questions

    - +

    The main spinoff of this RFC might be a multiple choice poll implementation in a separate pallet to hold a First Past the Post election instead of the Two-Round System proposed, which would prompt a migration to the new voting system within the collator-selection pallet. Additionally, a more @@ -1220,9 +1290,9 @@ of this RFC.

    AuthorsGavin Wood -

    Summary

    +

    Summary

    This proposes a periodic, sale-based method for assigning Polkadot Coretime, the analogue of "block space" within the Polkadot Network. The method takes into account the need for long-term capital expenditure planning for teams building on Polkadot, yet also provides a means to allow Polkadot to capture long-term value in the resource which it sells. It supports the possibility of building rich and dynamic secondary markets to optimize resource allocation and largely avoids the need for parameterization.

    -

    Motivation

    +

    Motivation

    Present System

    The Polkadot Ubiquitous Computer, or just Polkadot UC, represents the public service provided by the Polkadot Network. It is a trust-free, WebAssembly-based, multicore, internet-native omnipresent virtual machine which is highly resilient to interference and corruption.

    The present system of allocating the limited resources of the Polkadot Ubiquitous Computer is through a process known as parachain slot auctions. This is a parachain-centric paradigm whereby a single core is long-term allocated to a single parachain which itself implies a Substrate/Cumulus-based chain secured and connected via the Relay-chain. Slot auctions are on-chain candle auctions which proceed for several days and result in the core being assigned to the parachain for six months at a time up to 24 months in advance. Practically speaking, we only see two year periods being bid upon and leased.

    @@ -1243,7 +1313,7 @@ of this RFC.

  • The solution SHOULD avoid creating additional dependencies on functionality which the Relay-chain need not strictly provide for the delivery of the Polkadot UC.

    • Furthermore, the design SHOULD be implementable and deployable in a timely fashion; three months from the acceptance of this RFC should not be unreasonable.

    -

    Stakeholders

    +

    Stakeholders

    Primary stakeholder sets are:

    Socialization:

    The essensials of this proposal were presented at Polkadot Decoded 2023 Copenhagen on the Main Stage. A small amount of socialization at the Parachain Summit preceeded it and some substantial discussion followed it. Parity Ecosystem team is currently soliciting views from ecosystem teams who would be key stakeholders.

    -

    Explanation

    +

    Explanation

    Overview

    Upon implementation of this proposal, the parachain-centric slot auctions and associated crowdloans cease. Instead, Coretime on the Polkadot UC is sold by the Polkadot System in two separate formats: Bulk Coretime and Instantaneous Coretime.

    When a Polkadot Core is utilized, we say it is dedicated to a Task rather than a "parachain". The Task to which a Core is dedicated may change at every Relay-chain block and while one predominant type of Task is to secure a Cumulus-based blockchain (i.e. a parachain), other types of Tasks are envisioned.

    @@ -1684,16 +1754,16 @@ InstaPoolHistory: (empty)
  • Governance upgrade proposal(s).
  • Monitoring of the upgrade process.
    • -

    Performance, Ergonomics and Compatibility

    +

    Performance, Ergonomics and Compatibility

    No specific considerations.

    Parachains already deployed into the Polkadot UC must have a clear plan of action to migrate to an agile Coretime market.

    While this proposal does not introduce documentable features per se, adequate documentation must be provided to potential purchasers of Polkadot Coretime. This SHOULD include any alterations to the Polkadot-SDK software collection.

    -

    Testing, Security and Privacy

    +

    Testing, Security and Privacy

    Regular testing through unit tests, integration tests, manual testnet tests, zombie-net tests and fuzzing SHOULD be conducted.

    A regular security review SHOULD be conducted prior to deployment through a review by the Web3 Foundation economic research group.

    Any final implementation MUST pass a professional external security audit.

    The proposal introduces no new privacy concerns.

    - +

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

    RFC-5 proposes the API for interacting with Relay-chain.

    Additional work should specify the interface for the instantaneous market revenue so that the Coretime-chain can ensure Bulk Coretime placed in the instantaneous market is properly compensated.

    @@ -1709,7 +1779,7 @@ InstaPoolHistory: (empty)
  • The percentage of cores to be sold as Bulk Coretime.
  • The fate of revenue collected.
    • -

    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

    @@ -1742,10 +1812,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

    @@ -1840,17 +1910,17 @@ assert_eq!(targets.iter().map(|x| x.1).sum(), 57600);

    Realistic Limits of the Usage

    For request_revenue_info, a successful request should be possible if when is no less than the Relay-chain block number on arrival of the message less 100,000.

    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

    +

    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

    @@ -1896,13 +1966,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 @@ -1938,12 +2008,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 @@ -1979,27 +2049,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

    +

    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)

    @@ -2055,10 +2125,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.

    @@ -2067,9 +2137,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.

    @@ -2106,10 +2176,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.

    @@ -2118,22 +2188,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

    @@ -2166,9 +2236,9 @@ If this every becomes a problem, this value of 20 is an arbitrary constant that AuthorsPierre Krieger -

    Summary

    +

    Summary

    Improve the networking messages that query storage items from the remote, in order to reduce the bandwidth usage and number of round trips of light clients.

    -

    Motivation

    +

    Motivation

    Clients on the Polkadot peer-to-peer network can be divided into two categories: full nodes and light clients. So-called full nodes are nodes that store the content of the chain locally on their disk, while light clients are nodes that don't. In order to access for example the balance of an account, a full node can do a disk read, while a light client needs to send a network message to a full node and wait for the full node to reply with the desired value. This reply is in the form of a Merkle proof, which makes it possible for the light client to verify the exactness of the value.

    Unfortunately, this network protocol is suffering from some issues:

    Once Polkadot and Kusama will have transitioned to state_version = 1, which modifies the format of the trie entries, it will be possible to generate Merkle proofs that contain only the hashes of values in the storage. Thanks to this, it is already possible to prove the existence of a key without sending its entire value (only its hash), or to prove that a value has changed or not between two blocks (by sending just their hashes). Thus, the only reason why aforementioned issues exist is because the existing networking messages don't give the possibility for the querier to query this. This is what this proposal aims at fixing.

    -

    Stakeholders

    +

    Stakeholders

    This is the continuation of https://github.com/w3f/PPPs/pull/10, which itself is the continuation of https://github.com/w3f/PPPs/pull/5.

    -

    Explanation

    +

    Explanation

    The protobuf schema of the networking protocol can be found here: https://github.com/paritytech/substrate/blob/5b6519a7ff4a2d3cc424d78bc4830688f3b184c0/client/network/light/src/schema/light.v1.proto

    The proposal is to modify this protocol in this way:

    @@ -11,6 +11,7 @@ message Request {
@@ -2238,26 +2308,26 @@ An alternative could have been to specify the child_trie_info for e
 Also note that child tries aren't considered as descendants of the main trie when it comes to the includeDescendants flag. In other words, if the request concerns the main trie, no content coming from child tries is ever sent back.
    
 
    This protocol keeps the same maximum response size limit as currently exists (16 MiB). It is not possible for the querier to know in advance whether its query will lead to a reply that exceeds the maximum size. If the reply is too large, the replier should send back only a limited number (but at least one) of requested items in the proof. The querier should then send additional requests for the rest of the items. A response containing none of the requested items is invalid.
    
 
    The server is allowed to silently discard some keys of the request if it judges that the number of requested keys is too high. This is in line with the fact that the server might truncate the response.
    
-
    Drawbacks
    
+
    Drawbacks
    
 
    This proposal doesn't handle one specific situation: what if a proof containing a single specific item would exceed the response size limit? For example, if the response size limit was 1 MiB, querying the runtime code (which is typically 1.0 to 1.5 MiB) would be impossible as it's impossible to generate a proof less than 1 MiB. The response size limit is currently 16 MiB, meaning that no single storage item must exceed 16 MiB.
    
 
    Unfortunately, because it's impossible to verify a Merkle proof before having received it entirely, parsing the proof in a streaming way is also not possible.
    
 
    A way to solve this issue would be to Merkle-ize large storage items, so that a proof could include only a portion of a large storage item. Since this would require a change to the trie format, it is not realistically feasible in a short time frame.
    
-
    Testing, Security, and Privacy
    
+
    Testing, Security, and Privacy
    
 
    The main security consideration concerns the size of replies and the resources necessary to generate them. It is for example easily possible to ask for all keys and values of the chain, which would take a very long time to generate. Since responses to this networking protocol have a maximum size, the replier should truncate proofs that would lead to the response being too large. Note that it is already possible to send a query that would lead to a very large reply with the existing network protocol. The only thing that this proposal changes is that it would make it less complicated to perform such an attack.
    
 
    Implementers of the replier side should be careful to detect early on when a reply would exceed the maximum reply size, rather than inconditionally generate a reply, as this could take a very large amount of CPU, disk I/O, and memory. Existing implementations might currently be accidentally protected from such an attack thanks to the fact that requests have a maximum size, and thus that the list of keys in the query was bounded. After this proposal, this accidental protection would no longer exist.
    
 
    Malicious server nodes might truncate Merkle proofs even when they don't strictly need to, and it is not possible for the client to (easily) detect this situation. However, malicious server nodes can already do undesirable things such as throttle down their upload bandwidth or simply not respond. There is no need to handle unnecessarily truncated Merkle proofs any differently than a server simply not answering the request.
    
-
    Performance, Ergonomics, and Compatibility
    
-
    Performance
    
+
    Performance, Ergonomics, and Compatibility
    
+
    Performance
    
 
    It is unclear to the author of the RFC what the performance implications are. Servers are supposed to have limits to the amount of resources they use to respond to requests, and as such the worst that can happen is that light client requests become a bit slower than they currently are.
    
-
    Ergonomics
    
+
    Ergonomics
    
 
    Irrelevant.
    
-
    Compatibility
    
+
    Compatibility
    
 
    The prior networking protocol is maintained for now. The older version of this protocol could get removed in a long time.
    
-
    Prior Art and References
    
+
    Prior Art and References
    
 
    None. This RFC is a clean-up of an existing mechanism.
    
-
    Unresolved Questions
    
+
    Unresolved Questions
    
 
    None
    
-
+
 
    The current networking protocol could be deprecated in a long time. Additionally, the current "state requests" protocol (used for warp syncing) could also be deprecated in favor of this one.
    
 
    (source)
    
 
    Table of Contents
    
@@ -2278,13 +2348,13 @@ Also note that child tries aren't considered as descendants of the main trie whe
 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.
    
@@ -2327,13 +2397,13 @@ Also note that child tries aren't considered as descendants of the main trie whe
 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:
    
 
      
 
    • Parachain technical fellowship (new)
      • 
@@ -2349,12 +2419,12 @@ path to having its collective accepted on-chain as part of the protocol. Accepta
 the Fellowship to include the new collective with a given initial configuration into the runtime.
 However, the network, not the Fellowship, should ultimately decide which collectives are in the
 interest of the network.
      
-
      Stakeholders
      
+
      Stakeholders
      
 
        
 
      • Polkadot stakeholders who would like to organize on-chain.
        • 
 
      • Technical Fellowship, in its role of maintaining system runtimes.
        • 
 
      
-
      Explanation
      
+
      Explanation
      
 
      The group that wishes to operate an on-chain collective should publish the following information:
      
 
        
 
      • Charter, including the collective's mandate and how it benefits Polkadot. This would be similar
@@ -2388,22 +2458,22 @@ Fellowship would help them identify the pallet indices associated with a given c
 or not the Fellowship member agrees with removal.
        
 
        Collective removal may also come with other governance calls, for example voiding any scheduled
 Treasury spends that would fund the given collective.
        
-
        Drawbacks
        
+
        Drawbacks
        
 
        Passing a Root origin referendum is slow. However, given the network's investment (in terms of code
 maintenance and salaries) in a new collective, this is an appropriate step.
        
-
        Testing, Security, and Privacy
        
+
        Testing, Security, and Privacy
        
 
        No impacts.
        
-
        Performance, Ergonomics, and Compatibility
        
+
        Performance, Ergonomics, and Compatibility
        
 
        Generally all new collectives will be in the Collectives parachain. Thus, performance impacts
 should strictly be limited to this parachain and not affect others. As the majority of logic for
 collectives is generalized and reusable, we expect most collectives to be instances of similar
 subsets of modules. That is, new collectives should generally be compatible with UIs and other
 services that provide collective-related functionality, with little modifications to support new
 ones.
        
-
        Prior Art and References
        
+
        Prior Art and References
        
 
        The launch of the Technical Fellowship, see the
 initial forum post.
        
-
        Unresolved Questions
        
+
        Unresolved Questions
        
 
        None at this time.
        
 
        (source)
        
 
        Table of Contents
        
@@ -2440,13 +2510,13 @@ ones.
        
 AuthorsOliver Tale-Yazdi
 
 
-
        Summary
        
+
        Summary
        
 
        Introduces breaking changes to the Core runtime API by letting Core::initialize_block return an enum. The versions of Core is bumped from 4 to 5.
        
-
        Motivation
        
+
        Motivation
        
 
        The main feature that motivates this RFC are Multi-Block-Migrations (MBM); these make it possible to split a migration over multiple blocks.
        
 Further it would be nice to not hinder the possibility of implementing a new hook poll, that runs at the beginning of the block when there are no MBMs and has access to AllPalletsWithSystem. This hook can then be used to replace the use of on_initialize and on_finalize for non-deadline critical logic.
        
 In a similar fashion, it should not hinder the future addition of a System::PostInherents callback that always runs after all inherents were applied.
        
-
        Stakeholders
        
+
        Stakeholders
        
 
          
 
        • Substrate Maintainers: They have to implement this, including tests, audit and
 maintenance burden.
          • 
@@ -2454,7 +2524,7 @@ maintenance burden.
 
        • Polkadot Parachain Teams: They have to adapt to the breaking changes but then eventually have
 multi-block migrations available.
          • 
 
        
-
        Explanation
        
+
        Explanation
        
 
        Core::initialize_block
        
 
        This runtime API function is changed from returning () to ExtrinsicInclusionMode:
        
 
        fn initialize_block(header: &<Block as BlockT>::Header)
@@ -2475,23 +2545,23 @@ multi-block migrations available.
        • 
 
        1. Multi-Block-Migrations: The runtime is being put into lock-down mode for the duration of the migration process by returning OnlyInherents from initialize_block. This ensures that no user provided transaction can interfere with the migration process. It is absolutely necessary to ensure this, otherwise a transaction could call into un-migrated storage and violate storage invariants.
        
 
        2. poll is possible by using apply_extrinsic as entry-point and not hindered by this approach. It would not be possible to use a pallet inherent like System::last_inherent to achieve this for two reasons: First is that pallets do not have access to AllPalletsWithSystem which is required to invoke the poll hook on all pallets. Second is that the runtime does currently not enforce an order of inherents. 
        
 
        3. System::PostInherents can be done in the same manner as poll.
        
-
        Drawbacks
        
+
        Drawbacks
        
 
        The previous drawback of cementing the order of inherents has been addressed and removed by redesigning the approach. No further drawbacks have been identified thus far.
        
-
        Testing, Security, and Privacy
        
+
        Testing, Security, and Privacy
        
 
        The new logic of initialize_block can be tested by checking that the block-builder will skip transactions when OnlyInherents is returned.
        
 
        Security: n/a
        
 
        Privacy: n/a
        
-
        Performance, Ergonomics, and Compatibility
        
-
        Performance
        
+
        Performance, Ergonomics, and Compatibility
        
+
        Performance
        
 
        The performance overhead is minimal in the sense that no clutter was added after fulfilling the
 requirements. The only performance difference is that initialize_block also returns an enum that needs to be passed through the WASM boundary. This should be negligible.
        
-
        Ergonomics
        
+
        Ergonomics
        
 
        The new interface allows for more extensible runtime logic. In the future, this will be utilized for
 multi-block-migrations which should be a huge ergonomic advantage for parachain developers.
        
-
        Compatibility
        
+
        Compatibility
        
 
        The advice here is OPTIONAL and outside of the RFC. To not degrade
 user experience, it is recommended to ensure that an updated node can still import historic blocks.
        
-
        Prior Art and References
        
+
        Prior Art and References
        
 
        The RFC is currently being implemented in polkadot-sdk#1781 (formerly substrate#14275). Related issues and merge
 requests:
        
 
-
        Unresolved Questions
        
+
        Unresolved Questions
        
 
        Please suggest a better name for BlockExecutiveMode. We already tried: RuntimeExecutiveMode,
 ExtrinsicInclusionMode. The names of the modes Normal and Minimal were also called
 AllExtrinsics and OnlyInherents, so if you have naming preferences; please post them.
        
 => renamed to ExtrinsicInclusionMode
        
 
        Is post_inherents more consistent instead of last_inherent? Then we should change it.
        
 => renamed to last_inherent
        
-
+
 
        The long-term future here is to move the block building logic into the runtime. Currently there is a tight dance between the block author and the runtime; the author has to call into different runtime functions in quick succession and exact order. Any misstep causes the block to be invalid.
        
 This can be unified and simplified by moving both parts into the runtime.
        
 
        (source)
        
@@ -2545,14 +2615,14 @@ This can be unified and simplified by moving both parts into the runtime.
        
 AuthorsBryan Chen
 
 
-
        Summary
        
+
        Summary
        
 
        This RFC proposes a set of changes to the parachain lock mechanism. The goal is to allow a parachain manager to self-service the parachain without root track governance action.
        
 
        This is achieved by remove existing lock conditions and only lock a parachain when:
        
 
          
 
        • A parachain manager explicitly lock the parachain
          • 
 
        • OR a parachain block is produced successfully
          • 
 
        
-
        Motivation
        
+
        Motivation
        
 
        The manager of a parachain has permission to manage the parachain when the parachain is unlocked. Parachains are by default locked when onboarded to a slot. This requires the parachain wasm/genesis must be valid, otherwise a root track governance action on relaychain is required to update the parachain.
        
 
        The current reliance on root track governance actions for managing parachains can be time-consuming and burdensome. This RFC aims to address this technical difficulty by allowing parachain managers to take self-service actions, rather than relying on general public voting.
        
 
        The key scenarios this RFC seeks to improve are:
        
@@ -2571,12 +2641,12 @@ This can be unified and simplified by moving both parts into the runtime.
        
 
      • A parachain SHOULD be locked when it successfully produced the first block.
        • 
 
      • A parachain manager MUST be able to perform lease swap without having a running parachain.
        • 
 
      
-
      Stakeholders
      
+
      Stakeholders
      
 
        
 
      • Parachain teams
        • 
 
      • Parachain users
        • 
 
      
-
      Explanation
      
+
      Explanation
      
 
      Status quo
      
 
      A parachain can either be locked or unlocked3. With parachain locked, the parachain manager does not have any privileges. With parachain unlocked, the parachain manager can perform following actions with the paras_registrar pallet:
      
 
        
@@ -2616,31 +2686,31 @@ This can be unified and simplified by moving both parts into the runtime.
        
 
      • Parachain never produced a block. Including from expired leases.
        • 
 
      • Parachain manager never explicitly lock the parachain.
        • 
 
      
-
      Drawbacks
      
+
      Drawbacks
      
 
      Parachain locks are designed in such way to ensure the decentralization of parachains. If parachains are not locked when it should be, it could introduce centralization risk for new parachains.
      
 
      For example, one possible scenario is that a collective may decide to launch a parachain fully decentralized. However, if the parachain is unable to produce block, the parachain manager will be able to replace the wasm and genesis without the consent of the collective.
      
 
      It is considered this risk is tolerable as it requires the wasm/genesis to be invalid at first place. It is not yet practically possible to develop a parachain without any centralized risk currently.
      
 
      Another case is that a parachain team may decide to use crowdloan to help secure a slot lease. Previously, creating a crowdloan will lock a parachain. This means crowdloan participants will know exactly the genesis of the parachain for the crowdloan they are participating. However, this actually providers little assurance to crowdloan participants. For example, if the genesis block is determined before a crowdloan is started, it is not possible to have onchain mechanism to enforce reward distributions for crowdloan participants. They always have to rely on the parachain team to fulfill the promise after the parachain is alive.
      
 
      Existing operational parachains will not be impacted.
      
-
      Testing, Security, and Privacy
      
+
      Testing, Security, and Privacy
      
 
      The implementation of this RFC will be tested on testnets (Rococo and Westend) first.
      
 
      An audit maybe required to ensure the implementation does not introduce unwanted side effects.
      
 
      There is no privacy related concerns.
      
-
      Performance
      
+
      Performance
      
 
      This RFC should not introduce any performance impact.
      
-
      Ergonomics
      
+
      Ergonomics
      
 
      This RFC should improve the developer experiences for new and existing parachain teams
      
-
      Compatibility
      
+
      Compatibility
      
 
      This RFC is fully compatibility with existing interfaces.
      
-
      Prior Art and References
      
+
      Prior Art and References
      
 
        
 
      • Parachain Slot Extension Story: https://github.com/paritytech/polkadot/issues/4758
        • 
 
      • Allow parachain to renew lease without actually run another parachain: https://github.com/paritytech/polkadot/issues/6685
        • 
 
      • Always treat parachain that never produced block for a significant amount of time as unlocked: https://github.com/paritytech/polkadot/issues/7539
        • 
 
      
-
      Unresolved Questions
      
+
      Unresolved Questions
      
 
      None at this stage.
      
-
+
 
      This RFC is only intended to be a short term solution. Slots will be removed in future and lock mechanism is likely going to be replaced with a more generalized parachain manage & recovery system in future. Therefore long term impacts of this RFC are not considered.
      
 
      1
 
      https://github.com/paritytech/cumulus/issues/377
@@ -2674,19 +2744,19 @@ This can be unified and simplified by moving both parts into the runtime.
      
 Authors@brenzi for Encointer Association, 8000 Zurich, Switzerland
 
 
      
-
      Summary
      
+
      Summary
      
 
      Encointer is a system chain on Kusama since Jan 2022 and has been developed and maintained by the Encointer association. This RFC proposes to treat Encointer like any other system chain and include it in the fellowship repo with this PR.
      
-
      Motivation
      
+
      Motivation
      
 
      Encointer does not seek to be in control of its runtime repository. As a decentralized system, the fellowship has a more suitable structure to maintain a system chain runtime repo than the Encointer association does.
      
 
      Also, Encointer aims to update its runtime in batches with other system chains in order to have consistency for interoperability across system chains. 
      
-
      Stakeholders
      
+
      Stakeholders
      
 
        
 
      • Fellowship: Will continue to take upon them the review and auditing work for the Encointer runtime, but the process is streamlined with other system chains and therefore less time-consuming compared to the separate repo and CI process we currently have.
        • 
 
      • Kusama Network: Tokenholders can easily see the changes of all system chains in one place.
        • 
 
      • Encointer Association: Further decentralization of the Encointer Network necessities like devops.
        • 
 
      • Encointer devs: Being able to work directly in the Fellowship runtimes repo to streamline and synergize with other developers. 
        • 
 
      
-
      Explanation
      
+
      Explanation
      
 
      Our PR has all details about our runtime and how we would move it into the fellowship repo.
      
 
      Noteworthy: All Encointer-specific pallets will still be located in encointer's repo for the time being: https://github.com/encointer/pallets 
      
 
      It will still be the duty of the Encointer team to keep its runtime up to date and provide adequate test fixtures. Frequent dependency bumps with Polkadot releases would be beneficial for interoperability and could be streamlined with other system chains but that will not be a duty of fellowship. Whenever possible, all system chains could be upgraded jointly (including Encointer) with a batch referendum.
      
@@ -2695,17 +2765,17 @@ This can be unified and simplified by moving both parts into the runtime.
      
 
    • Encointer will publish all its crates crates.io
      • 
 
    • Encointer does not carry out external auditing of its runtime nor pallets. It would be beneficial but not a requirement from our side if Encointer could join the auditing process of other system chains. 
      • 
 
    
-
    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
    
@@ -3625,11 +3695,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
@@ -3641,13 +3711,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
    
 
      
 
    • Parachains that interact with affected logic on the Relay Chain;
      • 
 
    • Core protocol and XCM format developers;
      • 
 
    • Tooling, block explorer, and UI developers.
      • 
 
    
-
    Explanation
    
+
    Explanation
    
 
    The following pallets and subsystems are good candidates to migrate from the Relay Chain:
    
 
      
 
    • Identity
      • 
@@ -3793,36 +3863,36 @@ sensible to rehearse a migration.
      
 Staking is the subsystem most constrained by PoV limits. Ensuring that elections, payouts, session
 changes, offences/slashes, etc. work in a parachain on Kusama -- with its larger validator set --
 will give confidence to the chain's robustness on Polkadot.
      
-
      Drawbacks
      
+
      Drawbacks
      
 
      These subsystems will have reduced resources in cores than on the Relay Chain. Staking in particular
 may require some optimizations to deal with constraints.
      
-
      Testing, Security, and Privacy
      
+
      Testing, Security, and Privacy
      
 
      Standard audit/review requirements apply. More powerful multi-chain integration test tools would be
 useful in developement.
      
-
      Performance, Ergonomics, and Compatibility
      
+
      Performance, Ergonomics, and Compatibility
      
 
      Describe the impact of the proposal on the exposed functionality of Polkadot.
      
-
      Performance
      
+
      Performance
      
 
      This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its
 primary resources are allocated to system performance.
      
-
      Ergonomics
      
+
      Ergonomics
      
 
      This proposal alters very little for coretime users (e.g. parachain developers). Application
 developers will need to interact with multiple chains, making ergonomic light client tools
 particularly important for application development.
      
 
      For existing parachains that interact with these subsystems, they will need to configure their
 runtimes to recognize the new locations in the network.
      
-
      Compatibility
      
+
      Compatibility
      
 
      Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol.
 Application developers will need to interact with multiple chains in the network.
      
-
      Prior Art and References
      
+
      Prior Art and References
      
 
-
      Unresolved Questions
      
+
      Unresolved Questions
      
 
      There remain some implementation questions, like how to use balances for both Staking and
 Governance. See, for example, Moving Staking off the Relay
 Chain.
      
-
+
 
      Ideally the Relay Chain becomes transactionless, such that not even balances are represented there.
 With Staking and Governance off the Relay Chain, this is not an unreasonable next step.
      
 
      With Identity on Polkadot, Kusama may opt to drop its People Chain.
      
@@ -3857,13 +3927,13 @@ With Staking and Governance off the Relay Chain, this is not an unreasonable nex
 AuthorsVedhavyas Singareddi
 
 
-
      Summary
      
+
      Summary
      
 
      At the moment, we have system_version field on RuntimeVersion that derives which state version is used for the
 Storage.
 We have a use case where we want extrinsics root is derived using StateVersion::V1. Without defining a new field
 under RuntimeVersion,
 we would like to propose adding system_version that can be used to derive both storage and extrinsic state version.
      
-
      Motivation
      
+
      Motivation
      
 
      Since the extrinsic state version is always StateVersion::V0, deriving extrinsic root requires full extrinsic data.
 This would be problematic when we need to verify the extrinsics root if the extrinsic sizes are bigger. This problem is
 further explored in https://github.com/polkadot-fellows/RFCs/issues/19
      
@@ -3875,11 +3945,11 @@ One of the main challenge here is some extrinsics could be big enough that this
 included in the Consensus block due to Block's weight restriction.
 If the extrinsic root is derived using StateVersion::V1, then we do not need to pass the full extrinsic data but
 rather at maximum, 32 byte of extrinsic data.
      
-
      Stakeholders
      
+
      Stakeholders
      
 
        
 
      • Technical Fellowship, in its role of maintaining system runtimes.
        • 
 
      
-
      Explanation
      
+
      Explanation
      
 
      In order to use project specific StateVersion for extrinsic roots, we proposed
 an implementation that introduced
 parameter to frame_system::Config but that unfortunately did not feel correct.
@@ -3905,26 +3975,26 @@ pub const VERSION: RuntimeVersion = RuntimeVersion {
 		system_version: 1,
 	};
 }
    -

    Drawbacks

    +

    Drawbacks

    There should be no drawbacks as it would replace state_version with same behavior but documentation should be updated so that chains know which system_version to use.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    AFAIK, should not have any impact on the security or privacy.

    -

    Performance, Ergonomics, and Compatibility

    +

    Performance, Ergonomics, and Compatibility

    These changes should be compatible for existing chains if they use state_version value for system_verision.

    -

    Performance

    +

    Performance

    I do not believe there is any performance hit with this change.

    -

    Ergonomics

    +

    Ergonomics

    This does not break any exposed Apis.

    -

    Compatibility

    +

    Compatibility

    This change should not break any compatibility.

    -

    Prior Art and References

    +

    Prior Art and References

    We proposed introducing a similar change by introducing a parameter to frame_system::Config but did not feel that is the correct way of introducing this change.

    -

    Unresolved Questions

    +

    Unresolved Questions

    I do not have any specific questions about this change at the moment.

    - +

    IMO, this change is pretty self-contained and there won't be any future work necessary.

    (source)

    Table of Contents

    @@ -3953,9 +4023,9 @@ is the correct way of introducing this change.

    AuthorsSebastian Kunert -

    Summary

    +

    Summary

    This RFC proposes a new host function for parachains, storage_proof_size. It shall provide the size of the currently recorded storage proof to the runtime. Runtime authors can use the proof size to improve block utilization by retroactively reclaiming unused storage weight.

    -

    Motivation

    +

    Motivation

    The number of extrinsics that are included in a parachain block is limited by two constraints: execution time and proof size. FRAME weights cover both concepts, and block-builders use them to decide how many extrinsics to include in a block. However, these weights are calculated ahead of time by benchmarking on a machine with reference hardware. The execution-time properties of the state-trie and its storage items are unknown at benchmarking time. Therefore, we make some assumptions about the state-trie:

     Transact Over Bridge -

    Drawbacks

    +

    Drawbacks

    In terms of ergonomics and user experience, this support for combining an asset transfer with a subsequent action (like Transact) is a net positive.

    In terms of performance, and privacy, this is neutral with no changes.

    In terms of security, the feature by itself is also neutral because it allows preserve_origin: false usage for operating with no extra trust assumptions. When wanting to support preserving origin, chains need to configure secure origin aliasing filters. The one suggested in this RFC should be the right choice for the majority of chains, but each chain will ultimately choose depending on their business model and logic (e.g. chain does not plan to integrate with Asset Hub). It is up to the individual chains to configure accordingly.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Barriers should now allow AliasOrigin, DescendOrigin or ClearOrigin.

    Normally, XCM program builders should audit their programs and eliminate assumptions of "no origin" on remote side of this instruction. In this case, the InitiateAssetsTransfer has not been released yet, it will be part of XCMv5, and we can make this change part of the same XCMv5 so that there isn't even the possibility of someone in the wild having built XCM programs using this instruction on those wrong assumptions.

    The working assumption going forward is that the origin on the remote side can either be cleared or it can be the local origin's reanchored location. This assumption is in line with the current behavior of remote XCM programs sent over using pallet_xcm::send.

    The existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear origin same as before for compatibility reasons.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    No impact.

    -

    Ergonomics

    +

    Ergonomics

    Improves ergonomics by allowing the local origin to operate on the remote chain even when the XCM program includes an asset transfer.

    -

    Compatibility

    +

    Compatibility

    At the executor-level this change is backwards and forwards compatible. Both types of programs can be executed on new and old versions of XCM with no changes in behavior.

    New version of the InitiateAssetsTransfer instruction acts same as before when used with preserve_origin: false.

    For using the new capabilities, the XCM builder has to verify that the involved chains have the required origin-aliasing filters configured and use some new version of Barriers aware of AliasOrigin as an allowed alternative to ClearOrigin.

    For compatibility reasons, this RFC proposes this mechanism be added as an enhancement to the yet unreleased InitiateAssetsTransfer instruction, thus eliminating possibilities of XCM logic breakages in the wild. Following the same logic, the existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear the origin same as before for compatibility reasons.

    Any one of DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport instructions can be replaced with a InitiateAssetsTransfer instruction with or without origin aliasing, thus providing a clean and clear upgrade path for opting-in this new feature.

    -

    Prior Art and References

    +

    Prior Art and References

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    - +

    (source)

    Table of Contents

    -

    Drawbacks

    +

    Drawbacks

    This RFC might be difficult to implement in Substrate due to the internal code design. It is not clear to the author of this RFC how difficult it would be.

    Prior Art

    The API of these new functions was heavily inspired by API used by the C programming language.

    -

    Unresolved Questions

    +

    Unresolved Questions

    The changes in this RFC would need to be benchmarked. This involves implementing the RFC and measuring the speed difference.

    It is expected that most host functions are faster or equal speed to their deprecated counterparts, with the following exceptions:

      @@ -7308,10 +7378,10 @@ This would remove the possibility to synchronize older blocks, which is probably LicenseMIT -

      Summary

      +

      Summary

      This RFC proposes a dynamic pricing model for the sale of Bulk Coretime on the Polkadot UC. The proposed model updates the regular price of cores for each sale period, by taking into account the number of cores sold in the previous sale, as well as a limit of cores and a target number of cores sold. It ensures a minimum price and limits price growth to a maximum price increase factor, while also giving govenance control over the steepness of the price change curve. It allows governance to address challenges arising from changing market conditions and should offer predictable and controlled price adjustments.

      Accompanying visualizations are provided at [1].

      -

      Motivation

      +

      Motivation

      RFC-1 proposes periodic Bulk Coretime Sales as a mechanism to sell continouos regions of blockspace (suggested to be 4 weeks in length). A number of Blockspace Regions (compare RFC-1 & RFC-3) are provided for sale to the Broker-Chain each period and shall be sold in a way that provides value-capture for the Polkadot network. The exact pricing mechanism is out of scope for RFC-1 and shall be provided by this RFC.

      A dynamic pricing model is needed. A limited number of Regions are offered for sale each period. The model needs to find the price for a period based on supply and demand of the previous period.

      The model shall give Coretime consumers predictability about upcoming price developments and confidence that Polkadot governance can adapt the pricing model to changing market conditions.

      @@ -7323,7 +7393,7 @@ This would remove the possibility to synchronize older blocks, which is probably
    • The solution SHOULD provide a maximum factor of price increase should the limit of Regions sold per period be reached.
    • The solution should allow governance to control the steepness of the price function
      • -

      Stakeholders

      +

      Stakeholders

      The primary stakeholders of this RFC are:

      • Protocol researchers and evelopers
        • @@ -7331,7 +7401,7 @@ This would remove the possibility to synchronize older blocks, which is probably
      • Polkadot parachains teams
      • Brokers involved in the trade of Bulk Coretime
      -

      Explanation

      +

      Explanation

      Overview

      The dynamic pricing model sets the new price based on supply and demand in the previous period. The model is a function of the number of Regions sold, piecewise-defined by two power functions.

        @@ -7430,9 +7500,9 @@ SCALE_DOWN = 1 SCALE_UP = 1 OLD_PRICE = 1000 -

        Drawbacks

        +

        Drawbacks

        None at present.

        -

        Prior Art and References

        +

        Prior Art and References

        This pricing model is based on the requirements from the basic linear solution proposed in RFC-1, which is a simple dynamic pricing model and only used as proof. The present model adds additional considerations to make the model more adaptable under real conditions.

        Future Possibilities

        This RFC, if accepted, shall be implemented in conjunction with RFC-1.

        @@ -7468,9 +7538,9 @@ OLD_PRICE = 1000 AuthorsJonas Gehrlein -

        Summary

        +

        Summary

        This document is a proposal for restructuring the bulk markets in the Polkadot UC's coretime allocation system to improve efficiency and fairness. The proposal suggests separating the BULK_PERIOD into MARKET_PERIOD and RENEWAL_PERIOD, allowing for a market-driven price discovery through a clearing price Dutch auction during the MARKET_PERIOD followed by renewal offers at the MARKET_PRICE during the RENEWAL_PERIOD. The new system ensures synchronicity between renewal and market prices, fairness among all current tenants, and efficient price discovery, while preserving price caps to provide security for current tenants. It seeks to start a discussion about the possibility of long-term leases.

        -

        Motivation

        +

        Motivation

        While the initial RFC-1 has provided a robust framework for Coretime allocation within the Polkadot UC, this proposal builds upon its strengths and uses many provided building blocks to address some areas that could be further improved.

        In particular, this proposal introduces the following changes:

          @@ -7490,14 +7560,14 @@ OLD_PRICE = 1000

        The premise of this proposal is to reduce complexity by introducing a common price (that develops releative to capacity consumption of Polkadot UC), while still allowing for market forces to add efficiency. Longterm lease owners still receive priority IF they can pay (close to) the market price. This prevents a situation where the renewal price significantly diverges from renewal prices which allows for core captures. While maximum price increase certainty might seem contradictory to efficient price discovery, the proposed model aims to balance these elements, utilizing market forces to determine the price and allocate cores effectively within certain bounds. It must be stated, that potential price increases remain predictable (in the worst-case) but could be higher than in the originally proposed design. The argument remains, however, that we need to allow market forces to affect all prices for an efficient Coretime pricing and allocation.

        Ultimately, this the framework proposed here adheres to all requirements stated in RFC-1.

        -

        Stakeholders

        +

        Stakeholders

        Primary stakeholder sets are:

        • Protocol researchers and developers, largely represented by the Polkadot Fellowship and Parity Technologies' Engineering division.
        • Polkadot Parachain teams both present and future, and their users.
        • Polkadot DOT token holders.
        -

        Explanation

        +

        Explanation

        Bulk Markets

        The BULK_PERIOD has been restructured into two primary segments: the MARKET_PERIOD and RENEWAL_PERIOD, along with an auxiliary SETTLEMENT_PERIOD. This latter period doesn't necessitate any actions from the coretime system chain, but it facilitates a more efficient allocation of coretime in secondary markets. A significant departure from the original proposal lies in the timing of renewals, which now occur post-market phase. This adjustment aims to harmonize renewal prices with their market counterparts, ensuring a more consistent and equitable pricing model.

        Market Period (14 days)

        @@ -7544,12 +7614,12 @@ OLD_PRICE = 1000
        • Long-term Coretime: The Polkadot UC is undergoing a transition from two-year leases without an instantaneous market to a model encompassing instantaneous and one-month leases. This shift seems to pivot from one extreme to another. While the introduction of short-term leases, both instantaneous and for one month, is a constructive move to lower barriers to entry and promote experimentation, it seems to be the case that established projects might benefit from more extended lease options. We could consider offering another product, such as a six-month Coretime lease, using the same mechanism described herein. Although the majority of leases would still be sold on a one-month basis, the addition of this option would enhance market efficiency as it would strengthen the impact of a secondary market.
        -

        Drawbacks

        +

        Drawbacks

        There are trade-offs that arise from this proposal, compared to the initial model. The most notable one is that here, I prioritize requirement 6 over requirement 2. The price, in the very "worst-case" (meaning a huge explosion in demand for coretime) could lead to a much larger increase of prices in Coretime. From an economic perspective, this (rare edgecase) would also mean that we'd vastly underprice Coretime in the original model, leading to highly inefficient allocations.

        -

        Prior Art and References

        +

        Prior Art and References

        This RFC builds extensively on the available ideas put forward in RFC-1.

        Additionally, I want to express a special thanks to Samuel Haefner and Shahar Dobzinski for fruitful discussions and helping me structure my thoughts.

        -

        Unresolved Questions

        +

        Unresolved Questions

        The technical feasability needs to be assessed.

        (source)

        Table of Contents

        @@ -7581,16 +7651,16 @@ OLD_PRICE = 1000 AuthorsGabriel Facco de Arruda -

        Summary

        +

        Summary

        This RFC proposes changes that enable the use of absolute locations in AccountId derivations, which allows protocols built using XCM to have static account derivations in any runtime, regardless of its position in the family hierarchy.

        -

        Motivation

        +

        Motivation

        These changes would allow protocol builders to leverage absolute locations to maintain the exact same derived account address across all networks in the ecosystem, thus enhancing user experience.

        One such protocol, that is the original motivation for this proposal, is InvArch's Saturn Multisig, which gives users a unifying multisig and DAO experience across all XCM connected chains.

        -

        Stakeholders

        +

        Stakeholders

        • Ecosystem developers
        -

        Explanation

        +

        Explanation

        This proposal aims to make it possible to derive accounts for absolute locations, enabling protocols that require the ability to maintain the same derived account in any runtime. This is done by deriving accounts from the hash of described absolute locations, which are static across different destinations.

        The same location can be represented in relative form and absolute form like so:

        #![allow(unused)]
@@ -7647,25 +7717,25 @@ OLD_PRICE = 1000
 
        DescribeFamily
        
 
        The DescribeFamily location descriptor is part of the HashedDescription MultiLocation hashing system and exists to describe locations in an easy format for encoding and hashing, so that an AccountId can be derived from this MultiLocation.
        
 
        This implementation contains a match statement that does not match against absolute locations, so changes to it involve matching against absolute locations and providing appropriate descriptions for hashing.
        
-
        Drawbacks
        
+
        Drawbacks
        
 
        No drawbacks have been identified with this proposal.
        
-
        Testing, Security, and Privacy
        
+
        Testing, Security, and Privacy
        
 
        Tests can be done using simple unit tests, as this is not a change to XCM itself but rather to types defined in xcm-builder.
        
 
        Security considerations should be taken with the implementation to make sure no unwanted behavior is introduced.
        
 
        This proposal does not introduce any privacy considerations.
        
-
        Performance, Ergonomics, and Compatibility
        
-
        Performance
        
+
        Performance, Ergonomics, and Compatibility
        
+
        Performance
        
 
        Depending on the final implementation, this proposal should not introduce much overhead to performance.
        
-
        Ergonomics
        
+
        Ergonomics
        
 
        The ergonomics of this proposal depend on the final implementation details.
        
-
        Compatibility
        
+
        Compatibility
        
 
        Backwards compatibility should remain unchanged, although that depend on the final implementation.
        
-
        Prior Art and References
        
+
        Prior Art and References
        
 
          
 
        • DescirbeFamily type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/location_conversion.rs#L122
          • 
 
        • WithComputedOrigin type: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/barriers.rs#L153
          • 
 
        
-
        Unresolved Questions
        
+
        Unresolved Questions
        
 
        Implementation details and overall code is still up to discussion.
        
 
        (source)
        
 
        Table of Contents
        
@@ -7697,7 +7767,7 @@ OLD_PRICE = 1000
 ChaosDAO
 
 
-
        Summary
        
+
        Summary
        
 
        This RFC proposes to make modifications to voting power delegations as part of the Conviction Voting pallet. The changes being proposed include:
        
 
          
 
        1. Allow a Delegator to vote independently of their Delegate if they so desire.
          2. 
@@ -7705,7 +7775,7 @@ OLD_PRICE = 1000
 
        2. Make a change so that when a delegate votes abstain their delegated votes also vote abstain.
          3. 
 
        3. Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call. 
          4. 
 
        
-
        Motivation
        
+
        Motivation
        
 
        It has become clear since the launch of OpenGov that there are a few common tropes which pop up time and time again:
        
 
          
 
        1. The frequency of referenda is often too high for network participants to have sufficient time to review, comprehend, and ultimately vote on each individual referendum. This means that these network participants end up being inactive in on-chain governance.
          2. 
@@ -7713,13 +7783,13 @@ OLD_PRICE = 1000
 
        2. Delegating votes for all tracks currently requires long batched calls which result in high fees for the Delegator - resulting in a reluctance from many to delegate their votes.
          3. 
 
        
 
        We believe (based on feedback from token holders with a larger stake in the network) that if there were some changes made to delegation mechanics, these larger stake holders would be more likely to delegate their voting power to active network participants – thus greatly increasing the support turnout.
        
-
        Stakeholders
        
+
        Stakeholders
        
 
        The primary stakeholders of this RFC are:
        
 
          
 
        • The Polkadot Technical Fellowship who will have to research and implement the technical aspects of this RFC
          • 
 
        • DOT token holders in general 
          • 
 
        
-
        Explanation
        
+
        Explanation
        
 
        This RFC proposes to make 4 changes to the convictionVoting pallet logic in order to improve the user experience of those delegating their voting power to another account. 
        
 
          
 
        1. 
@@ -7735,21 +7805,21 @@ OLD_PRICE = 1000
 
          Allow a Delegator to delegate/ undelegate their votes for all tracks with a single call - in order to delegate votes across all tracks, a user must batch 15 calls - resulting in high costs for delegation. A single call for delegate_all/ undelegate_all would reduce the complexity and therefore costs of delegations considerably for prospective Delegators.
          
 
          2. 
 
        
-
        Drawbacks
        
+
        Drawbacks
        
 
        We do not foresee any drawbacks by implementing these changes. If anything we believe that this should help to increase overall voter turnout (via the means of delegation) which we see as a net positive.
        
-
        Testing, Security, and Privacy
        
+
        Testing, Security, and Privacy
        
 
        We feel that the Polkadot Technical Fellowship would be the most competent collective to identify the testing requirements for the ideas presented in this RFC.
        
-
        Performance, Ergonomics, and Compatibility
        
-
        Performance
        
+
        Performance, Ergonomics, and Compatibility
        
+
        Performance
        
 
        This change may add extra chain storage requirements on Polkadot, especially with respect to nested delegations. 
        
 
        Ergonomics & Compatibility
        
 
        The change to add nested delegations may affect governance interfaces such as Nova Wallet who will have to apply changes to their indexers to support nested delegations. It may also affect the Polkadot Delegation Dashboard as well as Polkassembly & SubSquare.
        
 
        We want to highlight the importance for ecosystem builders to create a mechanism for indexers and wallets to be able to understand that changes have occurred such as increasing the pallet version, etc.
        
-
        Prior Art and References
        
+
        Prior Art and References
        
 
        N/A
        
-
        Unresolved Questions
        
+
        Unresolved Questions
        
 
        N/A
        
-
+
 
        Additionally we would like to re-open the conversation about the potential for there to be free delegations. This was discussed by Dr Gavin Wood at Sub0 2022 and we feel like this would go a great way towards increasing the amount of network participants that are delegating: https://youtu.be/hSoSA6laK3Q?t=526
        
 
        Overall, we strongly feel that delegations are a great way to increase voter turnout, and the ideas presented in this RFC would hopefully help in that aspect.
        
 
        (source)
        
@@ -7791,9 +7861,9 @@ OLD_PRICE = 1000
 AuthorsSergej Sakac
 
 
-
        Summary
        
+
        Summary
        
 
        This RFC proposes a new model for a sustainable on-demand parachain registration, involving a smaller initial deposit and periodic rent payments. The new model considers that on-demand chains may be unregistered and later re-registered. The proposed solution also ensures a quick startup for on-demand chains on Polkadot in such cases.
        
-
        Motivation
        
+
        Motivation
        
 
        With the support of on-demand parachains on Polkadot, there is a need to explore a new, more cost-effective model for registering validation code. In the current model, the parachain manager is responsible for reserving a unique ParaId and covering the cost of storing the validation code of the parachain. These costs can escalate, particularly if the validation code is large. We need a better, sustainable model for registering on-demand parachains on Polkadot to help smaller teams deploy more easily.
        
 
        This RFC suggests a new payment model to create a more financially viable approach to on-demand parachain registration. In this model, a lower initial deposit is required, followed by recurring payments upon parachain registration.
        
 
        This new model will coexist with the existing one-time deposit payment model, offering teams seeking to deploy on-demand parachains on Polkadot a more cost-effective alternative.
        
@@ -7807,11 +7877,11 @@ OLD_PRICE = 1000
 
      • The solution MUST allow anyone to pay the rent.
        • 
 
      • The solution MUST prevent the removal of validation code if it could still be required for disputes or approval checking.
        • 
 
-
        Stakeholders
        
+
        Stakeholders
        
 
          
 
        • Future Polkadot on-demand Parachains
          • 
 
        
-
        Explanation
        
+
        Explanation
        
 
        This RFC proposes a set of changes that will enable the new rent based approach to registering and storing validation code on-chain. 
 The new model, compared to the current one, will require periodic rent payments. The parachain won't be pruned automatically if the rent is not paid, but by permitting anyone to prune the parachain and rewarding the caller, there will be an incentive for the removal of the validation code.
        
 
        On-demand parachains should still be able to utilize the current one-time payment model. However, given the size of the deposit required, it's highly likely that most on-demand parachains will opt for the new rent-based model.
        
@@ -7918,27 +7988,27 @@ pub(super) type CheckedCodeHash<T: Config> =
 	StorageMap<_, Twox64Concat, ParaId, ValidationCodeHash>;
 }

        To enable parachain re-registration, we should introduce a new extrinsic in the paras-registrar pallet that allows this. The logic of this extrinsic will be same as regular registration, with the distinction that it can be called by anyone, and the required deposit will be smaller since it only has to cover for the storage of the validation code.

        -

        Drawbacks

        +

        Drawbacks

        This RFC does not alter the process of reserving a ParaId, and therefore, it does not propose reducing it, even though such a reduction could be beneficial.

        Even though this RFC doesn't delve into the specifics of the configuration values for parachain registration but rather focuses on the mechanism, configuring it carelessly could lead to potential problems.

        Since the validation code hash and head data are not removed when the parachain is pruned but only when the deregister extrinsic is called, the T::DataDepositPerByte must be set to a higher value to create a strong enough incentive for removing it from the state.

        -

        Testing, Security, and Privacy

        +

        Testing, Security, and Privacy

        The implementation of this RFC will be tested on Rococo first.

        Proper research should be conducted on setting the configuration values of the new system since these values can have great impact on the network.

        An audit is required to ensure the implementation's correctness.

        The proposal introduces no new privacy concerns.

        -

        Performance, Ergonomics, and Compatibility

        -

        Performance

        +

        Performance, Ergonomics, and Compatibility

        +

        Performance

        This RFC should not introduce any performance impact.

        -

        Ergonomics

        +

        Ergonomics

        This RFC does not affect the current parachains, nor the parachains that intend to use the one-time payment model for parachain registration.

        -

        Compatibility

        +

        Compatibility

        This RFC does not break compatibility.

        -

        Prior Art and References

        +

        Prior Art and References

        Prior discussion on this topic: https://github.com/paritytech/polkadot-sdk/issues/1796

        -

        Unresolved Questions

        +

        Unresolved Questions

        None at this time.

        - +

        As noted in this GitHub issue, we want to raise the per-byte cost of on-chain data storage. However, a substantial increase in this cost would make it highly impractical for on-demand parachains to register on Polkadot. This RFC offers an alternative solution for on-demand parachains, ensuring that the per-byte cost increase doesn't overly burden the registration process.

        (source)

        @@ -7972,16 +8042,16 @@ This RFC offers an alternative solution for on-demand parachains, ensuring that AuthorsPierre Krieger -

        Summary

        +

        Summary

        Rather than enforce a limit to the total memory consumption on the client side by loading the value at :heappages, enforce that limit on the runtime side.

        -

        Motivation

        +

        Motivation

        From the early days of Substrate up until recently, the runtime was present in two forms: the wasm runtime (wasm bytecode passed through an interpreter) and the native runtime (native code directly run by the client).

        Since the wasm runtime has a lower amount of available memory (4 GiB maximum) compared to the native runtime, and in order to ensure sure that the wasm and native runtimes always produce the same outcome, it was necessary to clamp the amount of memory available to both runtimes to the same value.

        In order to achieve this, a special storage key (a "well-known" key) :heappages was introduced and represents the number of "wasm pages" (one page equals 64kiB) of memory that are available to the memory allocator of the runtimes. If this storage key is absent, it defaults to 2048, which is 128 MiB.

        The native runtime has since then been disappeared, but the concept of "heap pages" still exists. This RFC proposes a simplification to the design of Polkadot by removing the concept of "heap pages" as is currently known, and proposes alternative ways to achieve the goal of limiting the amount of memory available.

        -

        Stakeholders

        +

        Stakeholders

        Client implementers and low-level runtime developers.

        -

        Explanation

        +

        Explanation

        This RFC proposes the following changes to the client:

        • The client no longer considers :heappages as special.
          • @@ -8007,27 +8077,27 @@ This RFC offers an alternative solution for on-demand parachains, ensuring that

        Each parachain can choose the option that they prefer, but the author of this RFC strongly suggests either option C or B.

        -

        Drawbacks

        +

        Drawbacks

        In case of path A, there is one situation where the behaviour pre-RFC is not equivalent to the one post-RFC: when a host function that performs an allocation (for example ext_storage_get) is called, without this RFC this allocation might fail due to reaching the maximum heap pages, while after this RFC this will always succeed. This is most likely not a problem, as storage values aren't supposed to be larger than a few megabytes at the very maximum.

        In the unfortunate event where the runtime runs out of memory, path B would make it more difficult to relax the memory limit, as we would need to re-upload the entire Wasm, compared to updating only :heappages in path A or before this RFC. In the case where the runtime runs out of memory only in the specific event where the Wasm runtime is modified, this could brick the chain. However, this situation is no different than the thousands of other ways that a bug in the runtime can brick a chain, and there's no reason to be particularily worried about this situation in particular.

        -

        Testing, Security, and Privacy

        +

        Testing, Security, and Privacy

        This RFC would reduce the chance of a consensus issue between clients. The :heappages are a rather obscure feature, and it is not clear what happens in some corner cases such as the value being too large (error? clamp?) or malformed. This RFC would completely erase these questions.

        -

        Performance, Ergonomics, and Compatibility

        -

        Performance

        +

        Performance, Ergonomics, and Compatibility

        +

        Performance

        In case of path A, it is unclear how performances would be affected. Path A consists in moving client-side operations to the runtime without changing these operations, and as such performance differences are expected to be minimal. Overall, we're talking about one addition/subtraction per malloc and per free, so this is more than likely completely negligible.

        In case of path B and C, the performance gain would be a net positive, as this RFC strictly removes things.

        -

        Ergonomics

        +

        Ergonomics

        This RFC would isolate the client and runtime more from each other, making it a bit easier to reason about the client or the runtime in isolation.

        -

        Compatibility

        +

        Compatibility

        Not a breaking change. The runtime-side changes can be applied immediately (without even having to wait for changes in the client), then as soon as the runtime is updated, the client can be updated without any transition period. One can even consider updating the client before the runtime, as it corresponds to path C.

        -

        Prior Art and References

        +

        Prior Art and References

        None.

        -

        Unresolved Questions

        +

        Unresolved Questions

        None.

        - +

        This RFC follows the same path as https://github.com/polkadot-fellows/RFCs/pull/4 by scoping everything related to memory allocations to the runtime.

        (source)

        Table of Contents

        @@ -8065,7 +8135,7 @@ The :heappages are a rather obscure feature, and it is not clear wh AuthorAdam Clay Steeber -

        Summary

        +

        Summary

        This RFC proposes adding a trivial governance track on Kusama to facilitate X (formerly known as Twitter) posts on the @kusamanetwork account. The technical aspect of implementing this in the runtime is very inconsequential and straight-forward, though it might get more technical if the Fellowship wants to regulate this track with a non-existent permission set. If this is implemented it would need to be followed up with:

        @@ -8073,7 +8143,7 @@ with a non-existent permission set. If this is implemented it would need to be f
      • the establishment of specifications for proposing X posts via this track, and
      • the development of tools/processes to ensure that the content contained in referenda enacted in this track would be automatically posted on X.
        • -

        Motivation

        +

        Motivation

        The overall motivation for this RFC is to decentralize the management of the Kusama brand/communication channel to KSM holders. This is necessary in my opinion primarily because of the inactivity of the account in recent history, with posts spanning weeks or months apart. I am currently unaware of who/what entity manages the Kusama X account, but if they are affiliated with Parity or W3F this proposed solution could also offload some of the legal ramifications of making (or not making) @@ -8083,11 +8153,11 @@ and the community becomes totally autonomous in the management of Kusama's X pos that could be offloaded to openGov, provided this proof-of-concept is successful.

        Finally, this RFC is the epitome of experimentation that Kusama is ideal for. This proposal may spark newfound excitement for Kusama and help us realize Kusama's potential for pushing boundaries and trying new unconventional ideas.

        -

        Stakeholders

        +

        Stakeholders

        This idea has not been formalized by any individual (or group of) KSM holder(s). To my knowledge the socialization of this idea is contained entirely in my recent X post here, but it is possible that an idea like this one has been discussed in other places. It appears to me that the ecosystem would welcome a change like this which is why I am taking action to formalize the discussion.

        -

        Explanation

        +

        Explanation

        The implementation of this idea can be broken down into 3 primary phases:

        Phase 1 - Track configurations

        First, we begin with this RFC to ensure all feedback can be discussed and implemented in the proposal. After the Fellowship and the community come to a reasonable @@ -8140,7 +8210,7 @@ to implement them. Here's what would be needed:

      • a UI to allow layman users to propose referenda on this track

      After everything is complete, we can update the Kusama wiki to include documentation on the X post specifications and include links to the tools/UI.

      -

      Drawbacks

      +

      Drawbacks

      The main drawback to this change is that it requires a lot of off-chain coordination. It's easy enough to include the track on Kusama but it's a totally different challenge to make it function as intended. The tools need to be built and the auth tokens need to be managed. It would certainly add an administrative burden to whoever manages the X account since they would either need to run the tools themselves or manage auth tokens.

      @@ -8152,28 +8222,28 @@ If that happens, we risk getting Kusama banned on X!

      agency to manage posts. It wouldn't be decentralized but it would probably be more effective in terms of creating good content.

      Finally, this solution is merely pseudo-decentralization since the X account manager would still have ultimate control of the account. It's decentralized insofar as the auth tokens are given to people actually running the tools; a house of cards is required to facilitate X posts via this track. Not ideal.

      -

      Testing, Security, and Privacy

      +

      Testing, Security, and Privacy

      There's major precedent for configuring tracks on openGov given the amount of power tracks have, so it shouldn't be hard to come up with a sound configuration. That's why I recommend restricting permissions of this track to remarks and batches of remarks, or something equally inconsequential.

      Building the tools for this implementation is really straight-forward and could be audited by Fellowship members, and the community at large, on Github.

      The largest security concern would be the management of Kusama's X account's auth tokens. We would need to ensure that they aren't compromised.

      -

      Performance, Ergonomics, and Compatibility

      -

      Performance

      +

      Performance, Ergonomics, and Compatibility

      +

      Performance

      If a track on Kusama promises users that compliant referenda enacted therein would be posted on Kusama's X account, users would expect that track to perform as promised. If the house of cards tumbles down and a compliant referendum doesn't actually get anything posted, users might think that Kusama is broken or unreliable. This could be damaging to Kusama's image and cause people to question the soundness of other features on Kusama.

      As mentioned in the drawbacks, the performance of this feature would depend on off-chain coordinations. We can reduce the administrative burden of these coordinations by funding third parties with the Treasury to deal with it, but then we're relying on trusting these parties.

      -

      Ergonomics

      +

      Ergonomics

      By adding a new track to Kusama, governance platforms like Polkassembly or Nova Wallet would need to include it on their applications. This shouldn't be too much of a burden or overhead since they've already built the infrastructure for other openGov tracks.

      -

      Compatibility

      +

      Compatibility

      This change wouldn't break any compatibility as far as I know.

      References

      One reference to a similar feature requiring on-chain/off-chain coordination would be the Kappa-Sigma-Mu Society. Nothing on-chain necessarily enforces the rules or facilitates bids, challenges, defenses, etc. However, the Society has managed to maintain itself with integrity to its rules. So I don't think this is totally out of Kusama's scope. But it will require some off-chain effort to maintain.

      -

      Unresolved Questions

      +

      Unresolved Questions

      • Who will develop the tools necessary to implement this feature? How do we select them?
      • How can this idea be better implemented with on-chain/substrate features?
        • @@ -8212,11 +8282,11 @@ out of Kusama's scope. But it will require some off-chain effort to maintain.

        AuthorsJelliedOwl -

        Summary

        +

        Summary

        The current size of the decision deposit on some tracks is too high for many proposers. As a result, those needing to use it have to find someone else willing to put up the deposit for them - and a number of legitimate attempts to use the root track have timed out. This track would provide a more affordable (though slower) route for these holders to use the root track.

        -

        Motivation

        +

        Motivation

        There have been recent attempts to use the Kusama root track which have timed out with no decision deposit placed. Usually, these referenda have been related to parachain registration related issues.

        -

        Explanation

        +

        Explanation

        Propose to address this by adding a new referendum track [22] Referendum Deposit which can place the decision deposit on another referendum. This would require the following changes:

        • [Referenda Pallet] Modify the placeDecisionDesposit function to additionally allow it to be called by root, with root call bypassing the requirements for a deposit payment.
          • @@ -8240,23 +8310,23 @@ out of Kusama's scope. But it will require some off-chain effort to maintain.

          Approval & Support curves: As per the root track, timed to match the decision period
        • Maximum deciding: 10
        -

        Drawbacks

        +

        Drawbacks

        This track would provide a route to starting a root referendum with a much-reduced slashable deposit. This might be undesirable but, assuming the decision deposit cost for this track is still high enough, slashing would still act as a disincentive.

        An alternative to this might be to reduce the decision deposit size some of the more expensive tracks. However, part of the purpose of the high deposit - at least on the root track - is to prevent spamming the limited queue with junk referenda.

        -

        Testing, Security, and Privacy

        +

        Testing, Security, and Privacy

        Will need additional tests case for the modified pallet and runtime. No security or privacy issues.

        -

        Performance, Ergonomics, and Compatibility

        -

        Performance

        +

        Performance, Ergonomics, and Compatibility

        +

        Performance

        No significant performance impact.

        -

        Ergonomics

        +

        Ergonomics

        Only changes related to adding the track. Existing functionality is unchanged.

        -

        Compatibility

        +

        Compatibility

        No compatibility issues.

        -

        Prior Art and References

        +

        Prior Art and References

        -

        Unresolved Questions

        +

        Unresolved Questions

        Feedback on whether my proposed implementation of this is the best way to address the issue - including which calls the track should be allowed to make. Are the track parameters correct or should be use something different? Alternative would be welcome.

        (source)

        Table of Contents

        @@ -8301,7 +8371,7 @@ out of Kusama's scope. But it will require some off-chain effort to maintain.

        AuthorsAbdelrahman Soliman (Boda) -

        Summary

        +

        Summary

        A pallet to facilitate enhanced multisig accounts. The main enhancement is that we store a multisig account in the state with related info (signers, threshold,..etc). The module affords enhanced control over administrative operations such as adding/removing signers, changing the threshold, account deletion, canceling an existing proposal. Each signer can approve/reject a proposal while still exists. The proposal is not intended for migrating or getting rid of existing multisig. It's to allow both options to coexist.

        For the rest of the RFC We use the following terms:

          @@ -8309,7 +8379,7 @@ out of Kusama's scope. But it will require some off-chain effort to maintain.

          Stateful Multisig to refer to the proposed pallet.
        • Stateless Multisig to refer to the current multisig pallet in polkadot-sdk.
        -

        Motivation

        +

        Motivation

        Problem

        Entities in the Polkadot ecosystem need to have a way to manage their funds and other operations in a secure and efficient way. Multisig accounts are a common way to achieve this. Entities by definition change over time, members of the entity may change, threshold requirements may change, and the multisig account may need to be deleted. For even more enhanced hierarchical control, the multisig account may need to be controlled by other multisig accounts.

        Current native solutions for multisig operations are less optimal, performance-wise (as we'll explain later in the RFC), and lack fine-grained control over the multisig account.

        @@ -8351,12 +8421,12 @@ DAOs can utilize multisig accounts to ensure that decisions are made collectivel

      and much more...

      -

      Stakeholders

      +

      Stakeholders

      • Polkadot holders
      • Polkadot developers
      -

      Explanation

      +

      Explanation

      I've created the stateful multisig pallet during my studies in Polkadot Blockchain Academy under supervision from @shawntabrizi and @ank4n. After that, I've enhanced it to be fully functional and this is a draft PR#3300 in polkadot-sdk. I'll list all the details and design decisions in the following sections. Note that the PR is not 1-1 exactly to the current RFC as the RFC is a more polished version of the PR after updating based on the feedback and discussions.

      Let's start with a sequence diagram to illustrate the main operations of the Stateful Multisig.

      multisig operations

      @@ -8769,14 +8839,14 @@ pub type PendingProposals<T: Config> = StorageDoubleMap<
    • In case threshold is lower than the number of approvers then the proposal is still valid.
    • In case threshold is higher than the number of approvers then we catch it during execute proposal and error.
    -

    Drawbacks

    +

    Drawbacks

    • New pallet to maintain.
    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Standard audit/review requirements apply.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    Doing back of the envelop calculation to proof that the stateful multisig is more efficient than the stateless multisig given it's smaller footprint size on blocks.

    Quick review over the extrinsics for both as it affects the block size:

    Stateless Multisig: @@ -8840,17 +8910,17 @@ We have the following extrinsics:

    | Stateless | N^2 | Nil | | Stateful | N | N |

    So even though the stateful multisig has a larger state size, it's still more efficient in terms of block size and total footprint on the blockchain.

    -

    Ergonomics

    +

    Ergonomics

    The Stateful Multisig will have better ergonomics for managing multisig accounts for both developers and end-users.

    -

    Compatibility

    +

    Compatibility

    This RFC is compatible with the existing implementation and can be handled via upgrades and migration. It's not intended to replace the existing multisig pallet.

    -

    Prior Art and References

    +

    Prior Art and References

    multisig pallet in polkadot-sdk

    -

    Unresolved Questions

    +

    Unresolved Questions

    • On account deletion, should we transfer remaining deposits to treasury or remove signers' addition deposits completely and consider it as fees to start with?
    - +
    • Batch addition/removal of signers.
      • @@ -8896,9 +8966,9 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsLuke Schoen -

      Summary

      +

      Summary

      This proposes to increase the maximum length of PGP Fingerprint values from a 20 bytes/chars limit to a 40 bytes/chars limit.

      -

      Motivation

      +

      Motivation

      Background

      Pretty Good Privacy (PGP) Fingerprints are shorter versions of their corresponding Public Key that may be printed on a business card.

      They may be used by someone to validate the correct corresponding Public Key.

      @@ -8916,7 +8986,7 @@ Implement call filters. This will allow multisig accounts to only accept certain

    Solution Requirements

    The maximum length of identity PGP Fingerprint values should be increased from the current 20 bytes/chars limit at least a 40 bytes/chars limit to support PGP Fingerprints and GPG Fingerprints.

    -

    Stakeholders

    +

    Stakeholders

    • Any Polkadot account holder wishing to use a Polkadot on-chain identity for their:
        @@ -8925,30 +8995,30 @@ Implement call filters. This will allow multisig accounts to only accept certain
    -

    Explanation

    +

    Explanation

    If a user tries to setting an on-chain identity by creating an extrinsic using Polkadot.js with identity > setIdentity(info), then if they try to provide their 40 character long PGP Fingerprint or GPG Fingerprint, which is longer than the maximum length of 20 bytes/chars [u8;20], then they will encounter this error:

    createType(Call):: Call: failed decoding identity.setIdentity:: Struct: failed on args: {...}:: Struct: failed on pgpFingerprint: Option<[u8;20]>:: Expected input with 20 bytes (160 bits), found 40 bytes

    Increasing maximum length of identity PGP Fingerprint values from the current 20 bytes/chars limit to at least a 40 bytes/chars limit would overcome these errors and support PGP Fingerprints and GPG Fingerprints, satisfying the solution requirements.

    -

    Drawbacks

    +

    Drawbacks

    No drawbacks have been identified.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Implementations would be tested for adherance by checking that 40 bytes/chars PGP Fingerprints are supported.

    No effect on security or privacy has been identified than already exists.

    No implementation pitfalls have been identified.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    It would be an optimization, since the associated exposed interfaces to developers and end-users could start being used.

    To minimize additional overhead the proposal suggests a 40 bytes/chars limit since that would at least provide support for PGP Fingerprints, satisfying the solution requirements.

    -

    Ergonomics

    +

    Ergonomics

    No potential ergonomic optimizations have been identified.

    -

    Compatibility

    +

    Compatibility

    Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

    -

    Prior Art and References

    +

    Prior Art and References

    No prior articles or references.

    -

    Unresolved Questions

    +

    Unresolved Questions

    No further questions at this stage.

    - +

    Relates to RFC entitled "Increase maximum length of identity raw data values from 32 bytes".

    (source)

    Table of Contents

    @@ -8994,10 +9064,10 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsLuke Schoen -

    Summary

    +

    Summary

    This proposes to require a slashable deposit in the broker pallet when initially purchasing or renewing Bulk Coretime or Instantaneous Coretime cores.

    Additionally, it proposes to record a reputational status based on the behavior of the purchaser, as it relates to their use of Kusama Coretime cores that they purchase, and to possibly reserve a proportion of the cores for prospective purchasers that have an on-chain identity.

    -

    Motivation

    +

    Motivation

    Background

    There are sales of Kusama Coretime cores that are scheduled to occur later this month by Coretime Marketplace Lastic.xyz initially in limited quantities, and potentially also by RegionX in future that is subject to their Polkadot referendum #582. This poses a risk in that some Kusama Coretime core purchasers may buy Kusama Coretime cores when they have no intention of actually placing a workload on them or leasing them out, which would prevent those that wish to purchase and actually use Kusama Coretime cores from being able to use any at cores at all.

    Problem

    @@ -9029,34 +9099,34 @@ Implement call filters. This will allow multisig accounts to only accept certain

    Reputation. To disincentivise certain behaviours, a reputational status indicator could be used to record the historic behavior of the purchaser and whether on-chain judgement has determined they have adequately rectified that behaviour, as it relates to their usage of Kusama Coretime cores that they purchase.

    -

    Stakeholders

    +

    Stakeholders

    • Any Kusama account holder wishing to use the Broker pallet in any upcoming Kusama Coretime sales.
    • Any prospective Kusama Coretime purchaser, developer, and user.
    • KSM holders.
    -

    Drawbacks

    -

    Performance

    +

    Drawbacks

    +

    Performance

    The slashable deposit if set too high, may result in an economic impact, where less Kusama Coretime core sales are purchased.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    Lack of a slashable deposit in the Broker pallet is a security concern, since it exposes Kusama Coretime sales to potential abuse.

    Reserving a proportion of Kusama Coretime sales cores for those with on-chain identities should not be to the exclusion of accounts that wish to remain anonymous or cause cores to be wasted unnecessarily. As such, if cores that are reserved for on-chain identities remain unsold then they should be released to anonymous accounts that are on a waiting list.

    No implementation pitfalls have been identified.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    It should improve performance as it reduces the potential for state bloat since there is less risk of undesirable Kusama Coretime sales activity that would be apparent with no requirement for a slashable deposit or there being no reputational risk to purchasers that waste or misuse Kusama Coretime cores.

    The solution proposes to minimize the risk of some Kusama Coretime cores not even being used or leased to perform any tasks at all.

    It will be important to monitor and manage the slashable deposits, purchaser reputations, and utilization of the proportion of cores that are reserved for accounts with an on-chain identity.

    -

    Ergonomics

    +

    Ergonomics

    The mechanism for setting a slashable deposit amount, should avoid undue complexity for users.

    -

    Compatibility

    +

    Compatibility

    Updates to Polkadot.js Apps, API and its documentation and those referring to it may be required.

    -

    Prior Art and References

    +

    Prior Art and References

    Prior Art

    No prior articles.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None

    - +

    None

    (source)

    Table of Contents

    @@ -9095,13 +9165,13 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsAurora Poppyseed, Philip Lucsok -

    Summary

    +

    Summary

    This RFC proposes the addition of a secondary market feature to either the broker pallet or as a separate pallet maintained by Lastic, enabling users to list and purchase regions. This includes creating, purchasing, and removing listings, as well as emitting relevant events and handling associated errors.

    -

    Motivation

    +

    Motivation

    Currently, the broker pallet lacks functionality for a secondary market, which limits users' ability to freely trade regions. This RFC aims to introduce a secure and straightforward mechanism for users to list regions they own for sale and allow other users to purchase these regions.

    While integrating this functionality directly into the broker pallet is one option, another viable approach is to implement it as a separate pallet maintained by Lastic. This separate pallet would have access to the broker pallet and add minimal functionality necessary to support the secondary market.

    Adding smart contracts to the Coretime chain could also address this need; however, this process is expected to be lengthy and complex. We cannot afford to wait for this extended timeline to enable basic secondary market functionality. By proposing either integration into the broker pallet or the creation of a dedicated pallet, we can quickly enhance the flexibility and utility of the broker pallet, making it more user-friendly and valuable.

    -

    Stakeholders

    +

    Stakeholders

    Primary stakeholders include:

    • Developers working on the broker pallet.
      • @@ -9109,7 +9179,7 @@ Implement call filters. This will allow multisig accounts to only accept certain
    • Users who own regions and wish to trade them.
    • Community members interested in enhancing the broker pallet’s capabilities.
    -

    Explanation

    +

    Explanation

    This RFC introduces the following key features:

    1. @@ -9150,10 +9220,10 @@ Implement call filters. This will allow multisig accounts to only accept certain
    -

    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