From 805ddde21e02d048170abb295c328d35963c7627 Mon Sep 17 00:00:00 2001 From: bkchr Date: Sun, 14 Jul 2024 01:01:39 +0000 Subject: [PATCH] deploy: 7410f5fc806ece2c3f323a5bf4b4e2a76418cdcc --- 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 +- 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 +- index.html | 2 +- introduction.html | 2 +- new/0100-xcm-multi-type-asset-transfer.html | 2 +- ...1-xcm-transact-allow-unlimited-weight.html | 6 +- ...2-offchain-parachain-runtime-upgrades.html | 526 +++++++ print.html | 1400 ++++++++++------- ...t-purchaser-reputation-reserved-cores.html | 10 +- proposed/0091-dht-record-creation-time.html | 6 +- proposed/0092-unbonding_queue.html | 2 +- .../0099-transaction-extension-version.html | 2 +- ...0xx-secondary-marketplace-for-regions.html | 2 +- .../00xx-smart-contracts-coretime-chain.html | 2 +- searchindex.js | 2 +- searchindex.json | 2 +- ...04-remove-unnecessary-allocator-usage.html | 2 +- ...namic-pricing-for-bulk-coretime-sales.html | 2 +- ...09-improved-net-light-client-requests.html | 2 +- stale/0015-market-design-revisit.html | 2 +- ...irmation-period-duration-modification.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 | 6 +- stale/0089-flexible-inflation.html | 6 +- 50 files changed, 1435 insertions(+), 611 deletions(-) create mode 100644 new/0102-offchain-parachain-runtime-upgrades.html rename {stale => proposed}/0088-broker-pallet-slashable-deposit-purchaser-reputation-reserved-cores.html (74%) diff --git a/404.html b/404.html index d5c595a..26da752 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 740e067..2e90ad0 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 5b7d034..cb068e4 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 eac74bf..6d693b5 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 633bf7b..72d9705 100644 --- a/approved/0008-parachain-bootnodes-dht.html +++ b/approved/0008-parachain-bootnodes-dht.html @@ -90,7 +90,7 @@ diff --git a/approved/0010-burn-coretime-revenue.html b/approved/0010-burn-coretime-revenue.html index 1f8bca6..fb56754 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 05d7b33..7f39a22 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 e9eb042..5c6abeb 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 7d7adb3..49f411f 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 b743e0c..6ffdf60 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 badd567..de7b0e2 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 1ab016f..7a94863 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 2fb5873..2d40e69 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 493101f..e9cb25e 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 14fd5df..288d5eb 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 ac3d20a..3b45db8 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 01c39fe..f125da0 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 5ec761a..e1de77e 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 8d9d23c..443e410 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 89471ef..cf3a507 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 d7e52f0..38dd946 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 bf374b0..5aab335 100644 --- a/approved/0084-general-transaction-extrinsic-format.html +++ b/approved/0084-general-transaction-extrinsic-format.html @@ -90,7 +90,7 @@ diff --git a/index.html b/index.html index 0d87840..034c511 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index 0d87840..034c511 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0100-xcm-multi-type-asset-transfer.html b/new/0100-xcm-multi-type-asset-transfer.html index 67e42af..219983a 100644 --- a/new/0100-xcm-multi-type-asset-transfer.html +++ b/new/0100-xcm-multi-type-asset-transfer.html @@ -90,7 +90,7 @@ diff --git a/new/0101-xcm-transact-allow-unlimited-weight.html b/new/0101-xcm-transact-allow-unlimited-weight.html index dd1959a..44902f3 100644 --- a/new/0101-xcm-transact-allow-unlimited-weight.html +++ b/new/0101-xcm-transact-allow-unlimited-weight.html @@ -90,7 +90,7 @@ @@ -268,7 +268,7 @@ both this new version and the old. In both cases, an "attacker" can do - @@ -282,7 +282,7 @@ both this new version and the old. In both cases, an "attacker" can do - diff --git a/new/0102-offchain-parachain-runtime-upgrades.html b/new/0102-offchain-parachain-runtime-upgrades.html new file mode 100644 index 0000000..6391346 --- /dev/null +++ b/new/0102-offchain-parachain-runtime-upgrades.html @@ -0,0 +1,526 @@ + + + + + + + RFC-0000: Feature Name Here - Polkadot Fellowship RFCs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+
+

(source)

+

Table of Contents

+ +

RFC-0000: Feature Name Here

+
+ + + +
Start Date13 July 2024
DescriptionImplement off-chain parachain runtime upgrades
Authorseskimor
+
+

Summary

+

Change the upgrade process of a parachain runtime upgrade to become an off-chain +process with regards to the relay chain. Upgrades are still contained in +parachain blocks, but will no longer need to end up in relay chain blocks nor in +relay chain state.

+

Motivation

+

Having parachain runtime upgrades go through the relay chain has always been +seen as a scalability concern. Due to optimizations in statement +distribution and asynchronous backing it became less crucial and got +de-prioritized, the original issue can be found +here.

+

With the introduction of Agile Coretime and in general our efforts to reduce +barrier to entry more for Polkadot more, the issue becomes more relevant again: +We would like to reduce the required storage deposit for PVF registration, with +the aim to not only make it cheaper to run a parachain (bulk + on-demand +coretime), but also reduce the amount of capital required for the deposit. With +this we would hope for far more parachains to get registered, thousands +potentially even ten thousands. With so many PVFs registered, updates are +expected to become more frequent and even attacks on service quality for other +parachains would become a higher risk.

+

Stakeholders

+
    +
  • Parachain Teams
    • +
  • Relay Chain Node implementation teams
    • +
  • Relay Chain runtime developers
    • +
+

Explanation

+

The issues with on-chain runtime upgrades are:

+
    +
  1. Needlessly costly.
    2. +
  2. A single runtime upgrade more or less occupies an entire relay chain block, thus it +might affect also other parachains, especially if their candidates are also +not negligible due to messages for example or they want to uprade their +runtime at the same time.
    3. +
  3. The signalling of the parachain to notify the relay chain of an upcoming +runtime upgrade already contains the upgrade. Therefore the only way to rate +limit upgrades is to drop an already distributed update in the size of +megabytes: With the result that the parachain missed a block and more +importantly it will try again with the very next block, until it finally +succeeds. If we imagine to reduce capacity of runtime upgrades to let's say 1 +every 100 relay chain blocks, this results in lot's of wasted effort and lost +blocks.
    4. +
+

We discussed introducing a separate signalling before submitting the actual +runtime, but I think we should just go one step further and make upgrades fully +off-chain.

+

Introduce a new UMP message type RequestCodeUpgrade

+

As part of elastic scaling we are already planning to increase flexibility of UMP +messages, we can now use this to our advantage and introduce another UMP message:

+
#![allow(unused)]
+fn main() {
+enum UMPSignal {
+  // For elastic scaling
+  OnCore(CoreIndex),
+  // For off-chain upgrades
+  RequestCodeUpgrade(Hash),
+}
+}
+

We could also make that new message a regular XCM, calling an extrinsic on the +relay chain, but we will want to look into that message right after validation +on the backers on the node side, making a straight forward semantic message more +apt for the purpose.

+

Handle RequestCodeUpgrade on backers

+

We will introduce a new request/response protocol for both collators and +validators, with the following request/response:

+
#![allow(unused)]
+fn main() {
+struct RequestBlob {
+  blob_hash: Hash,
+}
+
+struct BlobResponse(Vec<u8>)
+}
+

This protocol will be used by backers to request the PVF from collators in the +following conditions:

+
    +
  1. They received a collation sending RequestCodeUpgrade.
    2. +
  2. They received a collation, but they don't yet have the code that was +previously registered on the relaychain. (E.g. disk pruned, new validator)
    3. +
+

In case they received the collation via PoV distribution instead of from the +collator itself, they will use the exact same message to fetch from the valiator +they got the PoV from.

+

Get the new code to all validators

+

Once the candidate issuing RequestCodeUpgrade got backed on chain, validators +will start fetching the code from the backers as part of availability +distribution.

+

To mitigate attack vectors we should make sure that serving requests for code +can be treated as low priority requests. Thus I am suggesting the following +scheme:

+

Validators will notice via a runtime API (TODO: Define) that a new code has been requested, the +API will return the Hash and a counter, which starts at some configurable +value e.g. 10. The validators are now aware of the new hash and start fetching, +but they don't have to wait for the fetch to succeed to sign their bitfield.

+

Then on each further candidate from that chain that counter gets decremented. +Validators which have not yet succeeded fetching will now try again. This game +continues until the counter reached 0. Now it is mandatory to have to code in +order to sign a 1 in the bitfield.

+

PVF pre-checking will happen after the candidate which brought the counter to +0 has been successfully included and thus is also able to assume that 2/3 of +the validators have the code.

+

This scheme serves two purposes:

+
    +
  1. Fetching can happen over a longer period of time with low priority. E.g. if +we waited for the PVF at the very first avaialbility distribution, this might +actually affect liveness of other chains on the same core. Distributing +megabytes of data to a thousand validators, might take a bit. Thus this helps +isolating parachains from each other.
    2. +
  2. By configuring the initial counter value we can affect how much an upgrade +costs. E.g. forcing the parachain to produce 10 blocks, means 10x the cost +for issuing an update. If too frequent upgrades ever become a problem for the +system, we have a knob to make them more costly.
    3. +
+

On-chain code upgrade process

+

First when a candidate is backed we need to make the new hash available +(together with a counter) via a +runtime API so validators in availability distribution can check for it and +fetch it if changed (see previous section). For performance reasons, I think we +should not do an additional call, but replace the existing one with one containing the new additional information (Option<(Hash, Counter)>).

+

Once the candidate gets included (counter 0), the hash is given to pre-checking +and only after pre-checking succeeded (and a full session passed) it is finally +enacted and the parachain can switch to the new code. (Same process as it used +to be.)

+

Handling new validators

+

Backers

+

If a backer receives a collation for a parachain it does not yet have the code +as enacted on chain (see "On-chain code upgrade process"), it will use above +request/response protocol to fetch it from whom it received the collation.

+

Availablity Distribution

+

Validators in availability distribution will be changed to only sign a 1 in +the bitfield of a candidate if they not only have the chunk, but also the +currently active PVF. They will fetch it from backers in case they don't have it +yet.

+

How do other parties get hold of the PVF?

+

Two ways:

+
    +
  1. Discover collators via relay chain DHT and request from them: Preferred way, +as it is less load on validators.
    2. +
  2. Request from validators, which will serve on a best effort basis.
    3. +
+

Pruning

+

We covered how validators get hold of new code, but when can they prune old ones? +In principle it is not an issue, if some validors prune code, because:

+
    +
  1. We changed it so that a candidate is not deemed available if validators were +not able to fetch the PVF.
    2. +
  2. Backers can always fetch the PVF from collators as part of the collation +fetching.
    3. +
+

But the majority of validators should always keep the latest code of any +parachain and only prune the previous one, once the first candidate using the +new code got finalized. This ensures that disputes will always be able to +resolve.

+

Drawbacks

+

The major drawback of this solution is the same as any solution the moves work +off-chain, it adds complexity to the node. E.g. nodes needing the PVF, need to +store them separately, together with their own pruning strategy as well.

+

Testing, Security, and Privacy

+

Implementations adhering to this RFC, will respond to PVF requests with the +actual PVF, if they have it. Requesters will persist received PVFs on disk for +as long as they are replaced by a new one. Implementations must not be lazy +here, if validators only fetched the PVF when needed, they can be prevented from +participating in disputes.

+

Validators should treat incoming requests for PVFs in general with rather low +priority, but should prefer fetches from other validators over requests from +random peers.

+

Given that we are altering what set bits in the availability bitfields mean (not +only chunk, but also PVF available), it is important to have enough validators +upgraded, before we allow collators to make use of the new runtime upgrade +mechanism. Otherwise we would risk disputes to not being able to succeed.

+

This RFC has no impact on privacy.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

This proposal lightens the load on the relay chain and is thus in general +beneficial for the performance of the network, this is achieved by the +following:

+
    +
  1. Code upgrades are still propagated to all validators, but only once, not +twice (First statements, then via the containing relay chain block).
    2. +
  2. Code upgrades are only communicated to validators and other nodes which are +interested, not any full node as it has been before.
    3. +
  3. Relay chain block space is preserved. Previously we could only do one runtime +upgrade per relay chain block, occupying almost all of the blockspace.
    4. +
  4. Signalling an upgrade no longer contains the upgrade, hence if we need to +push back on an upgrade for whatever reason, no network bandwidth and core +time gets wasted because of this.
    5. +
+

Ergonomics

+

End users are only affected by better performance and more stable block times. +Parachains will need to implement the introduced request/response protocol and +adapt to the new signalling mechanism via an UMP message, instead of sending +the code upgrade directly.

+

Compatibility

+

We will continue to support the old mechanism for code upgrades for a while, but +will start to impose stricter limits over time, with the number of registered +parachains going up. With those limits in place parachains not migrating to the +new scheme might be having a harder time upgrading and will miss more blocks. I +guess we can be lenient for a while still, so the upgrade path for +parachains should be rather smooth.

+

In total the protocol changes we need are:

+

For validators and collators:

+
    +
  1. New request/response protocol for fetching PVF data from collators and +validators.
    2. +
  2. New UMP message type for signalling a runtime upgrade.
    3. +
+

Only for validators:

+
    +
  1. New runtime API for determining to be enacted code upgrades.
    2. +
  2. Different behaviour of bitfields (only sign a 1 bit, if validator has chunk + +"hot" PVF).
    3. +
  3. Altered behaviour in availability-distribution: Fetch missing PVFS.
    4. +
+

Prior Art and References

+

Off-chain runtime upgrades have been discussed before, the architecture +described here is simpler though as it piggybacks on already existing features, +namely:

+
    +
  1. availability-distribution: No separate I have code messages anymore.
    2. +
  2. Existing pre-checking.
    3. +
+

https://github.com/paritytech/polkadot-sdk/issues/971

+

Unresolved Questions

+
    +
  1. What about the initial runtime, shall we make that off-chain as well?
    2. +
  2. Good news, at least after the first upgrade, no code will be stored on chain +any more, this means that we also have to redefine the storage deposit now. +We no longer charge for chain storage, but validator disk storage -> Should +be cheaper.
    3. +
+ +

Further Hardening

+

By no longer having code upgrade go through the relay chain, occupying a full relay +chain block, the impact on other parachains is already greatly reduced, if we +make distribution and PVF pre-checking low-priority processes on validators. The +only thing attackers might be able to do is delay upgrades of other parachains.

+

Which seems like a problem to be solved once we actually see it as a problem in +the wild (and can already be mitigated by adjusting the counter). The good thing +is that we have all the ingredients to go further if need be. Signalling no +longer actually includes the code, hence there is no need to reject the +candidate: The parachain can make progress even if we choose not to immediately +act on the request and no relay chain resources are wasted either.

+

We could for example introduce another UMP Signalling message +RequestCodeUpgradeWithPriority which not just requests a code upgrade, but +also offers some DOT to get ranked up in a queue.

+

Generalize this off-chain storage mechanism?

+

Making this storage mechanism more general purpose is worth thinking about. E.g. +by resolving above "fee" question, we might also be able to resolve the pruning +question in a more generic way and thus could indeed open this storage facility +for other purposes as well. E.g. smart contracts, so the PoV would only need to +reference contracts by hash and the actual PoV is stored on validators and +collators and thus no longer needs to be part of the PoV.

+ +
+ + +
+
+ + + +
+ + + + + + + + + + + + + + + + + + +
+ + diff --git a/print.html b/print.html index ffb44db..1cc5633 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -528,6 +528,412 @@ both this new version and the old. In both cases, an "attacker" can do

None.

If we see that nobody uses actual limits (all on-chain calls use weight_limit = Unlimited), we should remove it completely.

+

(source)

+

Table of Contents

+ +

RFC-0000: Feature Name Here

+
+ + + +
Start Date13 July 2024
DescriptionImplement off-chain parachain runtime upgrades
Authorseskimor
+
+

Summary

+

Change the upgrade process of a parachain runtime upgrade to become an off-chain +process with regards to the relay chain. Upgrades are still contained in +parachain blocks, but will no longer need to end up in relay chain blocks nor in +relay chain state.

+

Motivation

+

Having parachain runtime upgrades go through the relay chain has always been +seen as a scalability concern. Due to optimizations in statement +distribution and asynchronous backing it became less crucial and got +de-prioritized, the original issue can be found +here.

+

With the introduction of Agile Coretime and in general our efforts to reduce +barrier to entry more for Polkadot more, the issue becomes more relevant again: +We would like to reduce the required storage deposit for PVF registration, with +the aim to not only make it cheaper to run a parachain (bulk + on-demand +coretime), but also reduce the amount of capital required for the deposit. With +this we would hope for far more parachains to get registered, thousands +potentially even ten thousands. With so many PVFs registered, updates are +expected to become more frequent and even attacks on service quality for other +parachains would become a higher risk.

+

Stakeholders

+ +

Explanation

+

The issues with on-chain runtime upgrades are:

+
    +
  1. Needlessly costly.
    2. +
  2. A single runtime upgrade more or less occupies an entire relay chain block, thus it +might affect also other parachains, especially if their candidates are also +not negligible due to messages for example or they want to uprade their +runtime at the same time.
    3. +
  3. The signalling of the parachain to notify the relay chain of an upcoming +runtime upgrade already contains the upgrade. Therefore the only way to rate +limit upgrades is to drop an already distributed update in the size of +megabytes: With the result that the parachain missed a block and more +importantly it will try again with the very next block, until it finally +succeeds. If we imagine to reduce capacity of runtime upgrades to let's say 1 +every 100 relay chain blocks, this results in lot's of wasted effort and lost +blocks.
    4. +
+

We discussed introducing a separate signalling before submitting the actual +runtime, but I think we should just go one step further and make upgrades fully +off-chain.

+

Introduce a new UMP message type RequestCodeUpgrade

+

As part of elastic scaling we are already planning to increase flexibility of UMP +messages, we can now use this to our advantage and introduce another UMP message:

+
#![allow(unused)]
+fn main() {
+enum UMPSignal {
+  // For elastic scaling
+  OnCore(CoreIndex),
+  // For off-chain upgrades
+  RequestCodeUpgrade(Hash),
+}
+}
+

We could also make that new message a regular XCM, calling an extrinsic on the +relay chain, but we will want to look into that message right after validation +on the backers on the node side, making a straight forward semantic message more +apt for the purpose.

+

Handle RequestCodeUpgrade on backers

+

We will introduce a new request/response protocol for both collators and +validators, with the following request/response:

+
#![allow(unused)]
+fn main() {
+struct RequestBlob {
+  blob_hash: Hash,
+}
+
+struct BlobResponse(Vec<u8>)
+}
+

This protocol will be used by backers to request the PVF from collators in the +following conditions:

+
    +
  1. They received a collation sending RequestCodeUpgrade.
    2. +
  2. They received a collation, but they don't yet have the code that was +previously registered on the relaychain. (E.g. disk pruned, new validator)
    3. +
+

In case they received the collation via PoV distribution instead of from the +collator itself, they will use the exact same message to fetch from the valiator +they got the PoV from.

+

Get the new code to all validators

+

Once the candidate issuing RequestCodeUpgrade got backed on chain, validators +will start fetching the code from the backers as part of availability +distribution.

+

To mitigate attack vectors we should make sure that serving requests for code +can be treated as low priority requests. Thus I am suggesting the following +scheme:

+

Validators will notice via a runtime API (TODO: Define) that a new code has been requested, the +API will return the Hash and a counter, which starts at some configurable +value e.g. 10. The validators are now aware of the new hash and start fetching, +but they don't have to wait for the fetch to succeed to sign their bitfield.

+

Then on each further candidate from that chain that counter gets decremented. +Validators which have not yet succeeded fetching will now try again. This game +continues until the counter reached 0. Now it is mandatory to have to code in +order to sign a 1 in the bitfield.

+

PVF pre-checking will happen after the candidate which brought the counter to +0 has been successfully included and thus is also able to assume that 2/3 of +the validators have the code.

+

This scheme serves two purposes:

+
    +
  1. Fetching can happen over a longer period of time with low priority. E.g. if +we waited for the PVF at the very first avaialbility distribution, this might +actually affect liveness of other chains on the same core. Distributing +megabytes of data to a thousand validators, might take a bit. Thus this helps +isolating parachains from each other.
    2. +
  2. By configuring the initial counter value we can affect how much an upgrade +costs. E.g. forcing the parachain to produce 10 blocks, means 10x the cost +for issuing an update. If too frequent upgrades ever become a problem for the +system, we have a knob to make them more costly.
    3. +
+

On-chain code upgrade process

+

First when a candidate is backed we need to make the new hash available +(together with a counter) via a +runtime API so validators in availability distribution can check for it and +fetch it if changed (see previous section). For performance reasons, I think we +should not do an additional call, but replace the existing one with one containing the new additional information (Option<(Hash, Counter)>).

+

Once the candidate gets included (counter 0), the hash is given to pre-checking +and only after pre-checking succeeded (and a full session passed) it is finally +enacted and the parachain can switch to the new code. (Same process as it used +to be.)

+

Handling new validators

+

Backers

+

If a backer receives a collation for a parachain it does not yet have the code +as enacted on chain (see "On-chain code upgrade process"), it will use above +request/response protocol to fetch it from whom it received the collation.

+

Availablity Distribution

+

Validators in availability distribution will be changed to only sign a 1 in +the bitfield of a candidate if they not only have the chunk, but also the +currently active PVF. They will fetch it from backers in case they don't have it +yet.

+

How do other parties get hold of the PVF?

+

Two ways:

+
    +
  1. Discover collators via relay chain DHT and request from them: Preferred way, +as it is less load on validators.
    2. +
  2. Request from validators, which will serve on a best effort basis.
    3. +
+

Pruning

+

We covered how validators get hold of new code, but when can they prune old ones? +In principle it is not an issue, if some validors prune code, because:

+
    +
  1. We changed it so that a candidate is not deemed available if validators were +not able to fetch the PVF.
    2. +
  2. Backers can always fetch the PVF from collators as part of the collation +fetching.
    3. +
+

But the majority of validators should always keep the latest code of any +parachain and only prune the previous one, once the first candidate using the +new code got finalized. This ensures that disputes will always be able to +resolve.

+

Drawbacks

+

The major drawback of this solution is the same as any solution the moves work +off-chain, it adds complexity to the node. E.g. nodes needing the PVF, need to +store them separately, together with their own pruning strategy as well.

+

Testing, Security, and Privacy

+

Implementations adhering to this RFC, will respond to PVF requests with the +actual PVF, if they have it. Requesters will persist received PVFs on disk for +as long as they are replaced by a new one. Implementations must not be lazy +here, if validators only fetched the PVF when needed, they can be prevented from +participating in disputes.

+

Validators should treat incoming requests for PVFs in general with rather low +priority, but should prefer fetches from other validators over requests from +random peers.

+

Given that we are altering what set bits in the availability bitfields mean (not +only chunk, but also PVF available), it is important to have enough validators +upgraded, before we allow collators to make use of the new runtime upgrade +mechanism. Otherwise we would risk disputes to not being able to succeed.

+

This RFC has no impact on privacy.

+

Performance, Ergonomics, and Compatibility

+

Performance

+

This proposal lightens the load on the relay chain and is thus in general +beneficial for the performance of the network, this is achieved by the +following:

+
    +
  1. Code upgrades are still propagated to all validators, but only once, not +twice (First statements, then via the containing relay chain block).
    2. +
  2. Code upgrades are only communicated to validators and other nodes which are +interested, not any full node as it has been before.
    3. +
  3. Relay chain block space is preserved. Previously we could only do one runtime +upgrade per relay chain block, occupying almost all of the blockspace.
    4. +
  4. Signalling an upgrade no longer contains the upgrade, hence if we need to +push back on an upgrade for whatever reason, no network bandwidth and core +time gets wasted because of this.
    5. +
+

Ergonomics

+

End users are only affected by better performance and more stable block times. +Parachains will need to implement the introduced request/response protocol and +adapt to the new signalling mechanism via an UMP message, instead of sending +the code upgrade directly.

+

Compatibility

+

We will continue to support the old mechanism for code upgrades for a while, but +will start to impose stricter limits over time, with the number of registered +parachains going up. With those limits in place parachains not migrating to the +new scheme might be having a harder time upgrading and will miss more blocks. I +guess we can be lenient for a while still, so the upgrade path for +parachains should be rather smooth.

+

In total the protocol changes we need are:

+

For validators and collators:

+
    +
  1. New request/response protocol for fetching PVF data from collators and +validators.
    2. +
  2. New UMP message type for signalling a runtime upgrade.
    3. +
+

Only for validators:

+
    +
  1. New runtime API for determining to be enacted code upgrades.
    2. +
  2. Different behaviour of bitfields (only sign a 1 bit, if validator has chunk + +"hot" PVF).
    3. +
  3. Altered behaviour in availability-distribution: Fetch missing PVFS.
    4. +
+

Prior Art and References

+

Off-chain runtime upgrades have been discussed before, the architecture +described here is simpler though as it piggybacks on already existing features, +namely:

+
    +
  1. availability-distribution: No separate I have code messages anymore.
    2. +
  2. Existing pre-checking.
    3. +
+

https://github.com/paritytech/polkadot-sdk/issues/971

+

Unresolved Questions

+
    +
  1. What about the initial runtime, shall we make that off-chain as well?
    2. +
  2. Good news, at least after the first upgrade, no code will be stored on chain +any more, this means that we also have to redefine the storage deposit now. +We no longer charge for chain storage, but validator disk storage -> Should +be cheaper.
    3. +
+ +

Further Hardening

+

By no longer having code upgrade go through the relay chain, occupying a full relay +chain block, the impact on other parachains is already greatly reduced, if we +make distribution and PVF pre-checking low-priority processes on validators. The +only thing attackers might be able to do is delay upgrades of other parachains.

+

Which seems like a problem to be solved once we actually see it as a problem in +the wild (and can already be mitigated by adjusting the counter). The good thing +is that we have all the ingredients to go further if need be. Signalling no +longer actually includes the code, hence there is no need to reject the +candidate: The parachain can make progress even if we choose not to immediately +act on the request and no relay chain resources are wasted either.

+

We could for example introduce another UMP Signalling message +RequestCodeUpgradeWithPriority which not just requests a code upgrade, but +also offers some DOT to get ranked up in a queue.

+

Generalize this off-chain storage mechanism?

+

Making this storage mechanism more general purpose is worth thinking about. E.g. +by resolving above "fee" question, we might also be able to resolve the pruning +question in a more generic way and thus could indeed open this storage facility +for other purposes as well. E.g. smart contracts, so the PoV would only need to +reference contracts by hash and the actual PoV is stored on validators and +collators and thus no longer needs to be part of the PoV.

+

(source)

+

Table of Contents

+ +

RFC-0088: Add slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker pallet

+
+ + + +
Start Date25 Apr 2024
DescriptionAdd slashable locked deposit, purchaser reputation, and reserved cores for on-chain identities to broker pallet
AuthorsLuke Schoen
+
+

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

+

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

+

The types of purchasers may include:

+ +

Chaoatic repurcussions could include the following:

+ +

Solution Requirements

+
    +
  1. +

    On-chain identity. It may be possible to circumvent bots and scalpers to an extent by requiring a proportion of Kusama Coretime purchasers to have an on-chain identity. As such, a possible solution could be to allow the configuration of a threshold in the Broker pallet that reserves a proportion of the cores for accounts that have an on-chain identity, that reverts to a waiting list of anonymous account purchasers if the reserved proportion of cores remain unsold.

    +
    2. +
  2. +

    Slashable deposit. A viable solution could be to require a slashable deposit to be locked prior to the purchase or renewal of a core, similar to how decision deposits are used in OpenGov to prevent spam, but where if you buy a Kusama Coretime core you could be challenged by one of more collectives of fishermen to provide proof against certain criteria of how you used it, and if you fail to provide adequate evidence in response to that scrutiny, then you would lose a proportion of that deposit and face restrictions on purchasing or renewing cores in future that may also be configured on-chain.

    +
    3. +
  3. +

    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.

    +
    4. +
+

Stakeholders

+ +

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

+

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

+

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

+

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

+

Compatibility

+

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

+

Prior Art and References

+

Prior Art

+

No prior articles.

+

Unresolved Questions

+

None

+ +

None

(source)

Table of Contents

-

Drawbacks

+

Drawbacks

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

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

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Testing

-

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)

@@ -1997,10 +2403,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.

@@ -2009,9 +2415,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.

@@ -2048,10 +2454,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.

@@ -2060,22 +2466,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

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

Summary

+

Summary

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

-

Motivation

+

Motivation

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

-

Stakeholders

+

Stakeholders

Polkadot DOT token holders.

-

Explanation

+

Explanation

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

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

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

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

Summary

+

Summary

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

-

Motivation

+

Motivation

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

-

Drawbacks

+

Drawbacks

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

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

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

-

Performance, Ergonomics, and Compatibility

+

Performance, Ergonomics, and Compatibility

No changes

-

Prior Art and References

+

Prior Art and References

Existing Encointer runtime repo

-

Unresolved Questions

+

Unresolved Questions

None identified

- +

More info on Encointer: encointer.org

(source)

Table of Contents

@@ -3443,11 +3849,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 @@ -3459,13 +3865,13 @@ blockspace) to the network.

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

-

Stakeholders

+

Stakeholders

-

Explanation

+

Explanation

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