diff --git a/404.html b/404.html index 87b79f0c..829c42dc 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 80794a26..54254701 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 168dee17..d7757033 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 1db12009..6699cb16 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 cc7f12ab..206b74f4 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 15193208..0ae05292 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 3b41362c..72c069de 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 81aa9a03..995b33e8 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 50ebd4ab..5b8b69a2 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 0389c0a9..e1536f93 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 2b3b5d6e..3d8facc0 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 072616cb..a81dfc96 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 7d97de95..e70b4d13 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 34b90eb4..1ad89759 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 d9bd08c6..ad80677d 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 59dd40a8..631840ba 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 2affbbf5..1db54e49 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 bf0af3ff..6033f81e 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 1be29db1..b849ef0a 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 9d584687..7a0f3261 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 db7906d7..7d047adf 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 30cb1739..2474994c 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 f45199d5..ade3d52e 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 ade12484..6476237c 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 6ba0070c..46d85cf7 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 bcc68837..f0bd61e0 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 7544eead..ae5f6b5e 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 34d43527..092403c7 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 21f71bf5..f1f2aedf 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 0f6bc233..f112bcfa 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 f4641228..414de0c9 100644 --- a/approved/0108-xcm-remove-testnet-ids.html +++ b/approved/0108-xcm-remove-testnet-ids.html @@ -90,7 +90,7 @@ @@ -245,7 +245,7 @@

RFC-0106: Remove XCM fees mode

-
- - - -
Start Date23 July 2024
DescriptionRemove the SetFeesMode instruction and fees_mode register from XCM
AuthorsFrancisco Aguirre
-
-

Summary

-

The SetFeesMode instruction and the fees_mode register allow for the existence of JIT withdrawal. -JIT withdrawal complicates the fee mechanism and leads to bugs and unexpected behaviour. -The proposal is to remove said functionality. -Another effort to simplify fee handling in XCM.

-

Motivation

-

The JIT withdrawal mechanism creates bugs such as not being able to get fees when all assets are put into holding and none left in the origin location. -This is a confusing behavior, since there are funds for fees, just not where the XCVM wants them. -The XCVM should have only one entrypoint to fee payment, the holding register. -That way there is also less surface for bugs.

-

Stakeholders

+
  • Drawbacks
    • +
  • Testing, Security, and Privacy
    • +
  • Performance, Ergonomics, and Compatibility -

    Explanation

    -

    The SetFeesMode instruction will be removed. -The Fees Mode register will be removed.

    -

    Drawbacks

    -

    Users will have to make sure to put enough assets in WithdrawAsset when -previously some things might have been charged directly from their accounts. -This leads to a more predictable behaviour though so it will only be -a drawback for the minority of users.

    -

    Testing, Security, and Privacy

    -

    Implementations and benchmarking must change for most existing pallet calls -that send XCMs to other locations.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    -

    Performance will be improved since unnecessary checks will be avoided.

    -

    Ergonomics

    -

    JIT withdrawal was a way of side-stepping the regular flow of XCM programs. -By removing it, the spec is simplified but now old use-cases have to work with -the original intended behaviour, which may result in more implementation work.

    -

    Ergonomics for users will undoubtedly improve since the system is more predictable.

    -

    Compatibility

    -

    Existing programs in the ecosystem will break. -The instruction should be deprecated as soon as this RFC is approved -(but still fully supported), then removed in a subsequent XCM version -(probably deprecate in v5, remove in v6).

    -

    Prior Art and References

    -

    The previous RFC PR on the xcm-format repo, before XCM RFCs were moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/57.

    -

    Unresolved Questions

    -

    None.

    - -

    The new generic fees mechanism is related to this proposal and further stimulates it as the JIT withdraw fees mechanism will become useless anyway.

    -

    (source)

    -

    Table of Contents

    - -

    RFC-0111: Pure Proxy Replication

    +

    RFC-0000: Feature Name Here

    - - - + + +
    Start Date12 Aug 2024.
    DescriptionReplication of pure proxy account ownership to a remote chain
    Authors@muharem @xlc
    Start Date13 July 2024
    DescriptionImplement off-chain parachain runtime upgrades
    Authorseskimor
    -

    Summary

    -

    This RFC proposes a solution to replicate an existing pure proxy from one chain to others. The aim is to address the current limitations where pure proxy accounts, which are keyless, cannot have their proxy relationships recreated on different chains. This leads to issues where funds or permissions transferred to the same keyless account address on chains other than its origin chain become inaccessible.

    -

    Motivation

    -

    A pure proxy is a new account created by a primary account. The primary account is set as a proxy for the pure proxy account, managing it. Pure proxies are keyless and non-reproducible, meaning they lack a private key and have an address derived from a preimage determined by on-chain logic. More on pure proxies can be found here.

    -

    For the purpose of this document, we define a keyless account as a "pure account", the controlling account as a "proxy account", and the entire relationship as a "pure proxy".

    -

    The relationship between a pure account (e.g., account ID: pure1) and its proxy (e.g., account ID: alice) is stored on-chain (e.g., parachain A) and currently cannot be replicated to another chain (e.g., parachain B). Because the account pure1 is keyless and its proxy relationship with alice is not replicable from the parachain A to the parachain B, alice does not control the pure1 account on the parachain B.

    -

    Although this behaviour is not promised, users and clients often mistakenly expect alice to control the same pure1 account on the parachain B. As a result, assets transferred to the account or permissions granted for it are inaccessible. Several factors contribute to this misuse:

    +

    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

    -

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

    -

    Stakeholders

    -

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

    -

    Explanation

    -

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

    -

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

    -

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

    -

    To prove that the pure account is keyless, the client must provide the initial preimage used by the chain to derive the pure account. Parachain A verifies it and sends it to parachain B with the replication request.

    -

    We can draft a pallet extension for the proxy pallet, which needs to be initialised on both sides to enable replication:

    +

    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. Which also helps bringing down deposit costs in a secure way, as we +are also actually reducing costs for the network.

    +

    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() {
-// Simplified version to illustrate the concept.
-mod pallet_proxy_replica {
-  /// The part of the pure account preimage that has to be provided by a client.
-  struct Witness {
-    /// Pure proxy swapner
-    spawner: AccountId,
-    /// Disambiguation index
-    index: u16,
-    /// The block height and extrinsic index of when the pure account was created.  
-    block_number: BlockNumber,
-    /// The extrinsic index.
-    ext_index: u32,
-    // Part of the preimage, but constant.
-    // proxy_type: ProxyType::Any,
-  } 
-  // ...
-  
-  /// The replication call to be initiated on the source chain.
-  // Simplified version, the XCM part will be abstracted by the `Config` trait.
-  fn replicate(origin: SignedOrigin, witness: Witness, proxy: xcm::Location) -> ... {
-       let pure = ensure_signed(origin);
-       ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount);
-       let xcm = vec![
-         DescendOrigin(who),
-         Transact(
-             // …
-             origin_kind: OriginKind::Xcm,
-	     call: pallet_proxy_replica::create(witness, proxy).encode(),
-         )
-       ];
-       xcmTransport::send(xcm)?;
-  }
-  // …
-  
-  /// The call initiated by the source chain on the receiving chain.
-  // `Config::CreateOrigin` - generally open for whitelisted parachain IDs and 
-  // converts `Origin::Xcm(ParachainA/AccountId32(pure1))` to `AccountID(pure1)`.
-  fn create(origin: Config::CreateOrigin, witness: Witness, proxy: xcm::Location) -> ... {
-       let pure = T::CreateOrigin::ensure_origin(origin);
-       ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount);
-       proxy_pallet::create_pure_proxy(pure, proxy);
-  }
+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 {
+  blob: Vec<u8>
+}
 }
    -

    Drawbacks

    -

    There are two disadvantages to this approach:

    - -

    We could eliminate the first disadvantage by allowing only the spawner of the pure proxy to recreate the pure proxies, if they sign the transaction on a remote chain and supply the witness/preimage. Since the preimage of a pure account includes the account ID of the spawner, we can verify that the account signing the transaction is indeed the spawner of the given pure account. However, this approach would grant exclusive rights to the spawner over the pure account, which is not a property of pure proxies at present. This is why it's not an option for us.

    -

    As an alternative to requiring clients to provide a witness data, we could label pure accounts on the source chain and trust it on the receiving chain. However, this would require the receiving chain to place greater trust in the source chain. If the source chain is compromised, any type of account on the trusting chain could also be compromised.

    -

    A conceptually different solution would be to not implement replication of pure proxies and instead inform users that ownership of a pure proxy on one chain does not imply ownership of the same account on another chain. This solution seems complex, as it would require UIs and clients to adapt to this understanding. Moreover, mistakes would likely remain unavoidable.

    -

    Testing, Security, and Privacy

    -

    Each chain expressly authorizes another chain to replicate its pure proxies, accepting the inherent risk of that chain potentially being compromised. This authorization allows a malicious actor from the compromised chain to take control of any pure proxy account on the chain that granted the authorization. However, this is limited to pure proxies that originated from the compromised chain if they have a chain-specific seed within the preimage.

    -

    There is a security issue, not introduced by the proposed solution but worth mentioning. The same spawner can create the pure accounts on different chains controlled by the different accounts. This is possible because the current preimage version of the proxy pallet does not include any non-reproducible, chain-specific data, and elements like block numbers and extrinsic indexes can be reproduced with some effort. This issue could be addressed by adding a chain-specific seed into the preimages of pure accounts.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    -

    The replication is facilitated by XCM, which adds some additional load to the communication channel. However, since the number of replications is not expected to be large, the impact is minimal.

    -

    Ergonomics

    -

    The proposed solution does not alter any existing interfaces. It does require clients to obtain the witness data which should not be an issue with support of an indexer.

    -

    Compatibility

    -

    None.

    -

    Prior Art and References

    -

    None.

    -

    Unresolved Questions

    -

    None.

    - - -

    (source)

    +

    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.

    +

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

    +

    Compatibility

    +

    We will continue to support the old mechanism for code upgrades for a while, but +will start to impose stricter limits over time, with the number of registered +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. Solution to this: Not only store the hash on chain, but also the +size of the data. Then define a price per byte and charge that, but: +
        +
      • how do we charge - I guess deposit has to be provided via other means, +runtime upgrade fails if not provided.
        • +
      • how do we signal to the chain that the code is too large for it to reject +the upgrade? Easy: Make available and vote nay in pre-checking.
        • +
      +
      3. +
    +

    TODO: Fully resolve these questions and incorporate in RFC text.

    + +

    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.

    +

    A possible avenue would be to change the response to:

    +
    #![allow(unused)]
+fn main() {
+enum BlobResponse {
+  Blob(Vec<u8>),
+  Blobs(MerkleTree),
+}
+}
    +

    With this the hash specified in the request can also be a merkle root and the +responder will respond with the entire merkle tree (only hashes, no payload). +Then the requester can traverse the leaf hashes and use the same request +response protocol to request any locally missing blobs in that tree.

    +

    One leaf would for example be the PVF others could be smart contracts. With a +properly specified format (e.g. which leaf is the PVF?), what we got here is +that a parachain can not only update its PVF, but additional data, +incrementally. E.g. adding another smart contract, does not require resubmitting +the entire PVF to validators, only the root hash on the relay chain gets +updated, then validators fetch the merkle tree and only fetch any missing +leaves. That additional data could be made available to the PVF via a to be +added host function. The nice thing about this approach is, that while we can +upgrade incrementally, lifetime is still tied to the PVF and we get all the same +guarantees. Assuming the validators store blobs by hash, we even get disk +sharing if multiple parachains use the same data (e.g. same smart contracts).

    +

    (source)

    Table of Contents

    -

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

    +

    RFC-0106: Remove XCM fees mode

    - - - + + +
    Start Date14 August 2024
    DescriptionCompress the state response message to reduce the data transfer during the state syncing
    AuthorsLiu-Cheng Xu
    Start Date23 July 2024
    DescriptionRemove the SetFeesMode instruction and fees_mode register from XCM
    AuthorsFrancisco Aguirre
    -

    Summary

    -

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

    +

    Summary

    +

    The SetFeesMode instruction and the fees_mode register allow for the existence of JIT withdrawal. +JIT withdrawal complicates the fee mechanism and leads to bugs and unexpected behaviour. +The proposal is to remove said functionality. +Another effort to simplify fee handling in XCM.

    +

    Motivation

    +

    The JIT withdrawal mechanism creates bugs such as not being able to get fees when all assets are put into holding and none left in the origin location. +This is a confusing behavior, since there are funds for fees, just not where the XCVM wants them. +The XCVM should have only one entrypoint to fee payment, the holding register. +That way there is also less surface for bugs.

    +

    Stakeholders

    + +

    Explanation

    +

    The SetFeesMode instruction will be removed. +The Fees Mode register will be removed.

    +

    Drawbacks

    +

    Users will have to make sure to put enough assets in WithdrawAsset when +previously some things might have been charged directly from their accounts. +This leads to a more predictable behaviour though so it will only be +a drawback for the minority of users.

    +

    Testing, Security, and Privacy

    +

    Implementations and benchmarking must change for most existing pallet calls +that send XCMs to other locations.

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    +

    Performance will be improved since unnecessary checks will be avoided.

    +

    Ergonomics

    +

    JIT withdrawal was a way of side-stepping the regular flow of XCM programs. +By removing it, the spec is simplified but now old use-cases have to work with +the original intended behaviour, which may result in more implementation work.

    +

    Ergonomics for users will undoubtedly improve since the system is more predictable.

    +

    Compatibility

    +

    Existing programs in the ecosystem will break. +The instruction should be deprecated as soon as this RFC is approved +(but still fully supported), then removed in a subsequent XCM version +(probably deprecate in v5, remove in v6).

    +

    Prior Art and References

    +

    The previous RFC PR on the xcm-format repo, before XCM RFCs were moved to fellowship RFCs: https://github.com/polkadot-fellows/xcm-format/pull/57.

    +

    Unresolved Questions

    +

    None.

    + +

    The new generic fees mechanism is related to this proposal and further stimulates it as the JIT withdraw fees mechanism will become useless anyway.

    +

    (source)

    +

    Table of Contents

    + +

    RFC-0111: Pure Proxy Replication

    +
    + + + +
    Start Date12 Aug 2024.
    DescriptionReplication of pure proxy account ownership to a remote chain
    Authors@muharem @xlc
    +
    +

    Summary

    +

    This RFC proposes a solution to replicate an existing pure proxy from one chain to others. The aim is to address the current limitations where pure proxy accounts, which are keyless, cannot have their proxy relationships recreated on different chains. This leads to issues where funds or permissions transferred to the same keyless account address on chains other than its origin chain become inaccessible.

    Motivation

    +

    A pure proxy is a new account created by a primary account. The primary account is set as a proxy for the pure proxy account, managing it. Pure proxies are keyless and non-reproducible, meaning they lack a private key and have an address derived from a preimage determined by on-chain logic. More on pure proxies can be found here.

    +

    For the purpose of this document, we define a keyless account as a "pure account", the controlling account as a "proxy account", and the entire relationship as a "pure proxy".

    +

    The relationship between a pure account (e.g., account ID: pure1) and its proxy (e.g., account ID: alice) is stored on-chain (e.g., parachain A) and currently cannot be replicated to another chain (e.g., parachain B). Because the account pure1 is keyless and its proxy relationship with alice is not replicable from the parachain A to the parachain B, alice does not control the pure1 account on the parachain B.

    +

    Although this behaviour is not promised, users and clients often mistakenly expect alice to control the same pure1 account on the parachain B. As a result, assets transferred to the account or permissions granted for it are inaccessible. Several factors contribute to this misuse:

    + +

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

    +

    Stakeholders

    +

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

    +

    Explanation

    +

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

    +

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

    +

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

    +

    To prove that the pure account is keyless, the client must provide the initial preimage used by the chain to derive the pure account. Parachain A verifies it and sends it to parachain B with the replication request.

    +

    We can draft a pallet extension for the proxy pallet, which needs to be initialised on both sides to enable replication:

    +
    #![allow(unused)]
+fn main() {
+// Simplified version to illustrate the concept.
+mod pallet_proxy_replica {
+  /// The part of the pure account preimage that has to be provided by a client.
+  struct Witness {
+    /// Pure proxy swapner
+    spawner: AccountId,
+    /// Disambiguation index
+    index: u16,
+    /// The block height and extrinsic index of when the pure account was created.  
+    block_number: BlockNumber,
+    /// The extrinsic index.
+    ext_index: u32,
+    // Part of the preimage, but constant.
+    // proxy_type: ProxyType::Any,
+  } 
+  // ...
+  
+  /// The replication call to be initiated on the source chain.
+  // Simplified version, the XCM part will be abstracted by the `Config` trait.
+  fn replicate(origin: SignedOrigin, witness: Witness, proxy: xcm::Location) -> ... {
+       let pure = ensure_signed(origin);
+       ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount);
+       let xcm = vec![
+         DescendOrigin(who),
+         Transact(
+             // …
+             origin_kind: OriginKind::Xcm,
+	     call: pallet_proxy_replica::create(witness, proxy).encode(),
+         )
+       ];
+       xcmTransport::send(xcm)?;
+  }
+  // …
+  
+  /// The call initiated by the source chain on the receiving chain.
+  // `Config::CreateOrigin` - generally open for whitelisted parachain IDs and 
+  // converts `Origin::Xcm(ParachainA/AccountId32(pure1))` to `AccountID(pure1)`.
+  fn create(origin: Config::CreateOrigin, witness: Witness, proxy: xcm::Location) -> ... {
+       let pure = T::CreateOrigin::ensure_origin(origin);
+       ensure!(pure == proxy_pallet::derive_pure_account(witness), Error::NotPureAccount);
+       proxy_pallet::create_pure_proxy(pure, proxy);
+  }
+}
+
+}
    +

    Drawbacks

    +

    There are two disadvantages to this approach:

    + +

    We could eliminate the first disadvantage by allowing only the spawner of the pure proxy to recreate the pure proxies, if they sign the transaction on a remote chain and supply the witness/preimage. Since the preimage of a pure account includes the account ID of the spawner, we can verify that the account signing the transaction is indeed the spawner of the given pure account. However, this approach would grant exclusive rights to the spawner over the pure account, which is not a property of pure proxies at present. This is why it's not an option for us.

    +

    As an alternative to requiring clients to provide a witness data, we could label pure accounts on the source chain and trust it on the receiving chain. However, this would require the receiving chain to place greater trust in the source chain. If the source chain is compromised, any type of account on the trusting chain could also be compromised.

    +

    A conceptually different solution would be to not implement replication of pure proxies and instead inform users that ownership of a pure proxy on one chain does not imply ownership of the same account on another chain. This solution seems complex, as it would require UIs and clients to adapt to this understanding. Moreover, mistakes would likely remain unavoidable.

    +

    Testing, Security, and Privacy

    +

    Each chain expressly authorizes another chain to replicate its pure proxies, accepting the inherent risk of that chain potentially being compromised. This authorization allows a malicious actor from the compromised chain to take control of any pure proxy account on the chain that granted the authorization. However, this is limited to pure proxies that originated from the compromised chain if they have a chain-specific seed within the preimage.

    +

    There is a security issue, not introduced by the proposed solution but worth mentioning. The same spawner can create the pure accounts on different chains controlled by the different accounts. This is possible because the current preimage version of the proxy pallet does not include any non-reproducible, chain-specific data, and elements like block numbers and extrinsic indexes can be reproduced with some effort. This issue could be addressed by adding a chain-specific seed into the preimages of pure accounts.

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    +

    The replication is facilitated by XCM, which adds some additional load to the communication channel. However, since the number of replications is not expected to be large, the impact is minimal.

    +

    Ergonomics

    +

    The proposed solution does not alter any existing interfaces. It does require clients to obtain the witness data which should not be an issue with support of an indexer.

    +

    Compatibility

    +

    None.

    +

    Prior Art and References

    +

    None.

    +

    Unresolved Questions

    +

    None.

    + + +

    (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

    +

    Stakeholders

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

    -

    Explanation

    +

    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

    +

    Drawbacks

    None identified.

    -

    Testing, Security, and Privacy

    +

    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

    +

    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

    +

    Ergonomics

    None.

    -

    Compatibility

    +

    Compatibility

    No compatibility issues identified.

    -

    Prior Art and References

    +

    Prior Art and References

    None.

    -

    Unresolved Questions

    +

    Unresolved Questions

    None.

    - +

    None.

    (source)

    Table of Contents

    @@ -3406,11 +3745,11 @@

    AuthorsPablo Dorado, Daniel Olano -

    Summary

    +

    Summary

    In an attempt to mitigate risks derived from unwanted behaviours around long decision periods on referenda, this proposal describes how to finalize and decide a result of a poll via a mechanism similar to candle auctions.

    -

    Motivation

    +

    Motivation

    Referenda protocol provide permissionless and efficient mechanisms to enable governance actors to decide the future of the blockchains around Polkadot network. However, they pose a series of risks derived from the game theory perspective around these mechanisms. One of them being where an actor @@ -3426,7 +3765,7 @@

    Motivation -

    Stakeholders

    +

    Stakeholders

    -

    Explanation

    +

    Explanation

    Currently, the process of a referendum/poll is defined as an sequence between an ongoing state (where accounts can vote), comprised by a with a preparation period, a decision period, and a confirm period. If the poll is passing before the decision period ends, it's possible to push @@ -3517,43 +3856,43 @@

    Explanation cf --> [*] rj --> [*] -

    Drawbacks

    +

    Drawbacks

    This approach doesn't include a mechanism to determine whether a change of the poll status in the confirming period is due to a legitimate change of mind of the voters, or an exploitation of its aforementioned vulnerabilities (like a sniping attack), instead treating all of them as potential attacks.

    This is an issue that can be addressed by additional mechanisms, and heuristics that can help determine the probability of a change of poll status to happen as a result of a legitimate behaviour.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    The implementation of this RFC will be tested on testnets (Paseo and Westend) first. Furthermore, it should be enabled in a canary network (like Kusama) to ensure the behaviours it is trying to address is indeed avoided.

    An audit will be required to ensure the implementation doesn't introduce unwanted side effects.

    There are no privacy related concerns.

    -

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    The added steps imply pessimization, necessary to meet the expected changes. An implementation MUST exit from the Finalization period as early as possible to minimize this impact.

    -

    Ergonomics

    +

    Ergonomics

    This proposal does not alter the already exposed interfaces or developers or end users. However, they must be aware of the changes in the additional overhead the new period might incur (these depend on the implemented VRF).

    -

    Compatibility

    +

    Compatibility

    This proposal does not break compatibility with existing interfaces, older versions, but it alters the previous implementation of the referendum processing algorithm.

    An acceptable upgrade strategy that can be applied is defining a point in time (block number, poll index) from which to start applying the new mechanism, thus, not affecting the already ongoing referenda.

    -

    Prior Art and References

    +

    Prior Art and References

    -

    Unresolved Questions

    +

    Unresolved Questions

    - +

    A proposed implementation of this change can be seen on this Pull Request.

    (source)

    Table of Contents

    @@ -3586,12 +3925,12 @@

    Summary

    +

    Summary

    The protocol change introduces flexibility in the governance structure by enabling the referenda track list to be modified dynamically at runtime. This is achieved by replacing static slices in TracksInfo with iterators, facilitating storage-based track management. As a result, governance tracks can be modified or added based on real-time decisions and without requiring runtime upgrades.

    -

    Motivation

    +

    Motivation

    Polkadot's governance system is designed to be adaptive and decentralized, but modifying the referenda tracks (which determine decision-making paths for proposals) has historically required runtime upgrades. This poses an operational challenge, delaying governance changes until an upgrade @@ -3599,12 +3938,12 @@

    Motivation -

    Stakeholders

    +

    Stakeholders

    -

    Explanation

    +

    Explanation

    The protocol modification replaces the current static slice method used for storing referenda tracks with an iterator-based approach that allows tracks to be managed dynamically using chain storage. Governance participants can define and modify referenda tracks as needed, which are then accessed @@ -3616,12 +3955,12 @@

    Explanation to alter track configurations based on storage data rather than static definitions. This opens up possibilities for new track types and governance configurations to be deployed without the need for upgrades that might take up weeks.

    -

    Drawbacks

    +

    Drawbacks

    The most significant drawback is the increased complexity for developers managing track configurations via storage-based iterators, which require careful handling to avoid misuse or inefficiencies.

    Additionally, this flexibility could introduce risks if track configurations are modified improperly during runtime, potentially leading to governance instabilities.

    -

    Testing, Security, and Privacy

    +

    Testing, Security, and Privacy

    To ensure security, the change must be tested in testnet environments first (Paseo, Westend), particularly in scenarios where multiple track changes happen concurrently. Potential vulnerabilities in governance adjustments must be addressed to prevent abuse.

    @@ -3629,27 +3968,27 @@

    Performance, Ergonomics, and Compatibility

    -

    Performance

    +

    Performance, Ergonomics, and Compatibility

    +

    Performance

    The proposal optimizes governance track management by avoiding the overhead of runtime upgrades, reducing downtime, and eliminating the need for full consensus on upgrades. However, there is a slight performance cost related to runtime access to storage-based iterators, though this is mitigated by the overall system efficiency gains.

    -

    Ergonomics

    +

    Ergonomics

    Developers and governance actors benefit from simplified governance processes but must account for the technical complexity of managing iterator-based track configurations.

    Tools may need to be developed to help streamline track adjustments in runtime.

    -

    Compatibility

    +

    Compatibility

    The change is backward compatible with existing governance operations, and does not require developers to adjust how they interact with referenda tracks.

    A migration is required to convert existing statically-defined tracks to dynamic storage-based configurations without disruption.

    -

    Prior Art and References

    +

    Prior Art and References

    This dynamic governance track approach builds on previous work around Polkadot's on-chain governance and leverages standard iterator patterns in Rust programming to improve runtime flexibility. Comparable solutions in other governance networks were examined, but this proposal uniquely tailors them to Polkadot’s decentralized, runtime-upgradable architecture.

    -

    Unresolved Questions

    +

    Unresolved Questions

    -

    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