diff --git a/404.html b/404.html index c332801..0ab0bce 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 204b4b8..b282465 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 170f95d..050d693 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 31762d2..2d319a5 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 0022996..d3b9238 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 d7a36cb..3482efd 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 4773d12..c1d0698 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 0c8d387..155fa59 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 140d315..ebd5b1b 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 8ce7e08..09609ec 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 2eccfc7..62d36a3 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 e534b39..7ec8333 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 26b684d..2018742 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 afc1322..aaf5c42 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 16eeca4..4e62e1f 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 4a1b6e1..b58442d 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 b9475b5..f73f7ba 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 330a5de..58c7ea1 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 4e268d8..1ebcc15 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 397a71e..4a3bbc4 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 870869a..5013da6 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 9fa6690..256b209 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 3e65a3b..c078abc 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 fdbc40c..ce2be49 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 d74bcc1..aa12c35 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 c8bcc2f..370a74c 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 6e0adec..7ecd83e 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 802ad67..65d11cf 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 bfd6cf6..51e6a9e 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 7cb102b..9d29066 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 4c74ce0..08e8323 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 @@ using NetworkId::ByGenesis.

- @@ -259,7 +259,7 @@ using NetworkId::ByGenesis.

- diff --git a/proposed/0122-alias-origin-on-asset-transfers.html b/approved/0122-alias-origin-on-asset-transfers.html similarity index 73% rename from proposed/0122-alias-origin-on-asset-transfers.html rename to approved/0122-alias-origin-on-asset-transfers.html index bcf9968..a6d4bdd 100644 --- a/proposed/0122-alias-origin-on-asset-transfers.html +++ b/approved/0122-alias-origin-on-asset-transfers.html @@ -90,7 +90,7 @@ @@ -174,7 +174,7 @@
-

(source)

+

(source)

Table of Contents

diff --git a/index.html b/index.html index ff19e9c..d8843df 100644 --- a/index.html +++ b/index.html @@ -90,7 +90,7 @@ diff --git a/introduction.html b/introduction.html index ff19e9c..d8843df 100644 --- a/introduction.html +++ b/introduction.html @@ -90,7 +90,7 @@ diff --git a/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html b/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html index e385583..48f70e0 100644 --- a/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html +++ b/new/0123-pending-code-as-storage-location-for-runtime-upgrades.html @@ -90,7 +90,7 @@ diff --git a/print.html b/print.html index cb59cc0..b93d477 100644 --- a/print.html +++ b/print.html @@ -91,7 +91,7 @@ @@ -1066,6 +1066,182 @@ for compression.

None.

None.

+

(source)

+

Table of Contents

+ +

RFC-0117: The Unbrick Collective

+
+ + + +
Start Date22 August 2024
DescriptionThe Unbrick Collective aims to help teams rescuing a para once it stops producing blocks
AuthorsBryan Chen, Pablo Dorado
+
+

Summary

+

A followup of the RFC-0014. This RFC proposes adding a new collective to the Polkadot Collectives +Chain: The Unbrick Collective, as well as improvements in the mechanisms that will allow teams +operating paras that had stopped producing blocks to be assisted, in order to restore the production +of blocks of these paras.

+

Motivation

+

Since the initial launch of Polkadot parachains, there has been many incidients causing parachains +to stop producing new blocks (therefore, being bricked) and many occurrences that requires +Polkadot governance to update the parachain head state/wasm. This can be due to many reasons range +from incorrectly registering the initial head state, inability to use sudo key, bad runtime +migration, bad weight configuration, and bugs in the development of the Polkadot SDK.

+

Currently, when the para is not unlocked in the paras registrar1, the Root origin is required to +perform such actions, involving the governance process to invoke this origin, which can be very +resource expensive for the teams. The long voting and enactment times also could result significant +damage to the parachain and users.

+

Finally, other instances of governance that might enact a call using the Root origin (like the +Polkadot Fellowship), due to the nature of their mission, are not fit to carry these kind of tasks.

+

In consequence, the idea of a Unbrick Collective that can provide assistance to para teams when +they brick and further protection against future halts is reasonable enough.

+

Stakeholders

+ +

Explanation

+

The Collective

+

The Unbrick Collective is defined as an unranked collective of members, not paid by the Polkadot +Treasury. Its main goal is to serve as a point of contact and assistance for enacting the actions +needed to unbrick a para. Such actions are:

+ +

In order to ensure these changes are safe enough for the network, actions enacted by the Unbrick +Collective must be whitelisted via similar mechanisms followed by collectives like the Polkadot +Fellowship. This will prevent unintended, not overseen changes on other paras to occur.

+

Also, teams might opt-in to delegate handling their para in the registry to the Collective. This +allows to perform similar actions using the paras registrar, allowing for a shorter path to unbrick a +para.

+

Initially, the unbrick collective has powers similar to a parachains own sudo, but permits more +decentralized control. In the future, Polkadot shall provide functionality like SPREE or JAM that +exceeds sudo permissions, so the unbrick collective cannot modify those state roots or code.

+

The Unbrick Process

+
flowchart TD
+    A[Start] 
+
+    A -- Bricked --> C[Request para unlock via Root]
+    C -- Approved --> Y
+    C -- Rejected --> A
+    
+    D[unbrick call proposal on WhitelistedUnbrickCaller]
+    E[whitelist call proposal on the Unbrick governance]
+    E -- call whitelisted --> F[unbrick call enacted]
+    D -- unbrick called --> F
+    F --> Y
+
+    A -- Not bricked --> O[Opt-in to the Collective]
+    O -- Bricked --> D
+    O -- Bricked --> E
+
+    Y[update PVF / head state] -- Unbricked --> Z[End]
+
+

Initially, a para team has two paths to handle a potential unbrick of their para in the case it +stops producing blocks.

+
    +
  1. Opt-in to the Unbrick Collective: This is done by delegating the handling of the para +in the paras registrar to an origin related to the Collective. This doesn't require unlocking +the para. This way, the collective is enabled to perform changes in the paras module, after +the Unbrick Process proceeds.
    2. +
  2. Request a Para Unlock: In case the para hasn't delegated its handling in the paras +registrar, it'll be still possible for the para team to submit a proposal to unlock the para, +which can be assisted by the Collective. However, this involves submitting a proposal to the Root +governance origin.
    3. +
+

Belonging to the Collective

+

The collective will be initially created without members (no seeding). There will be additional +governance proposals to setup the seed members.

+

The origins able to modify the members of the collective are:

+ +

The members are responsible to verify the technical details of the unbrick requests (i.e. the hash +of the new PVF being set). Therefore, they must have the technical capacity to perform such tasks.

+

Suggested requirements to become a member are the following:

+ +

Drawbacks

+

The ability to modify the Head State and/or the PVF of a para means a possibility to perform +arbitrary modifications of it (i.e. take control the native parachain token or any bridged assets +in the para).

+

This could introduce a new attack vectorm, and therefore, such great power needs to be handled +carefully.

+

Testing, Security, and Privacy

+

The implementation of this RFC will be tested on testnets (Rococo and Westend) first.

+

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

+

This RFC should not introduce any performance impact.

+

Ergonomics

+

This RFC should improve the experience for new and existing parachain teams, lowering the barrier +to unbrick a stalled para.

+

Compatibility

+

This RFC is fully compatible with existing interfaces.

+

Prior Art and References

+ +

Unresolved Questions

+ + +
1 +

The paras registrar refers to a pallet in the Relay, responsible to gather registration info +of the paras, the locked/unlocked state, and the manager info.

+
+

(source)

Table of Contents

 -

Drawbacks

+

Drawbacks

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

Prior Art

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

-

Unresolved Questions

+

Unresolved Questions

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

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

 -

Drawbacks

+

Drawbacks

  • New pallet to maintain.
-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

Standard audit/review requirements apply.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

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

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

Stateless Multisig: @@ -8884,13 +9060,13 @@ We have the following extrinsics:

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

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

-

Ergonomics

+

Ergonomics

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

-

Compatibility

+

Compatibility

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

-

Prior Art and References

+

Prior Art and References

multisig pallet in polkadot-sdk

-

Unresolved Questions

+

Unresolved Questions

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

Summary

+

Summary

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

-

Motivation

+

Motivation

Background

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

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

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

Solution Requirements

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

-

Stakeholders

+

Stakeholders

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

Explanation

+

Explanation

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

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

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

-

Drawbacks

+

Drawbacks

No drawbacks have been identified.

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

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

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

No implementation pitfalls have been identified.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

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

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

-

Ergonomics

+

Ergonomics

No potential ergonomic optimizations have been identified.

-

Compatibility

+

Compatibility

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

-

Prior Art and References

+

Prior Art and References

No prior articles or references.

-

Unresolved Questions

+

Unresolved Questions

No further questions at this stage.

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

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

Summary

+

Summary

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

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

-

Motivation

+

Motivation

Background

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

Problem

@@ -9073,32 +9249,32 @@ Implement call filters. This will allow multisig accounts to only accept certain

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

-

Stakeholders

+

Stakeholders

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

Drawbacks

-

Performance

+

Drawbacks

+

Performance

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

-

Testing, Security, and Privacy

+

Testing, Security, and Privacy

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

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

No implementation pitfalls have been identified.

-

Performance, Ergonomics, and Compatibility

-

Performance

+

Performance, Ergonomics, and Compatibility

+

Performance

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

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

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

-

Ergonomics

+

Ergonomics

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

-

Compatibility

+

Compatibility

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

-

Prior Art and References

+

Prior Art and References

Prior Art

No prior articles.

-

Unresolved Questions

+

Unresolved Questions

None

None

@@ -9133,7 +9309,7 @@ Implement call filters. This will allow multisig accounts to only accept certain AuthorsKian Paimani -

Summary

+

Summary

This RFC proposes a new pallet_inflation to be added to the Polkadot runtime, which improves inflation machinery of the Polkadot relay chain in a number of ways:

    @@ -9143,7 +9319,7 @@ inflation machinery of the Polkadot relay chain in a number of ways:

    systems, as proposed RFC32.
-

Motivation

+

Motivation

The existing inflation logic in the relay chain suffers from a number of drawbacks: