From ff60cbe23cba94ef99f748cd113f91a1049a9c11 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Fri, 7 Jul 2023 08:16:05 +0200 Subject: [PATCH 01/16] create file --- text/RFC-000X-System Collator Selection.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 text/RFC-000X-System Collator Selection.md diff --git a/text/RFC-000X-System Collator Selection.md b/text/RFC-000X-System Collator Selection.md new file mode 100644 index 00000000..e69de29b From 0a5f1fab46c128e3f4e14ee5658d360b15e2bba6 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Tue, 11 Jul 2023 20:43:48 +0200 Subject: [PATCH 02/16] add body of rfc --- text/RFC-000X-System Collator Selection.md | 162 +++++++++++++++++++++ 1 file changed, 162 insertions(+) diff --git a/text/RFC-000X-System Collator Selection.md b/text/RFC-000X-System Collator Selection.md index e69de29b..551ee3f6 100644 --- a/text/RFC-000X-System Collator Selection.md +++ b/text/RFC-000X-System Collator Selection.md @@ -0,0 +1,162 @@ +# RFC-000X: System Collator Selection + +| | | +| --------------- | ----------------------------------------------------------------------------- | +| **Start Date** | 07 July 2023 | +| **Description** | Mechanism for selecting collators of system chains. | +| **Authors** | Joe Petrowski | + +## Summary + +As core functionality moves from the Relay Chain into system chains, so increases the reliance on +the liveness of these chains for the use of the network. It is not economically scalable, nor +necessary from a game-theoretic perspective, to pay collators large rewards. This RFC proposes a +mechanism -- part technical and part social -- for ensuring reliable collator sets that are +resilient to attemps to stop any subsytem of the Polkadot protocol. + +## Motivation + +In order to guarantee access to Polkadot's system, the collators on its system chains must propose +blocks (provide liveness) and allow all transactions to eventually be included. That is, some +collators may censor transactions, but there must exist one collator in the set who will include a +given transaction. In fact, all collators may censor varying subsets of transactions, but as long +as no transaction is in the intersection of every subset, it will eventually be included. The +objective of this RFC is to propose a mechanism to select such a set on each system chain. + +While the network as a whole uses staking (and inflationary rewards) to attract validators, +collators face different challenges in scale and have lower security assumptions than validators. +Regarding scale, there exist many system chains, and it is economically expensive to pay collators +a premium. Likewise, any staked DOT for collation is _not_ staked for validation. Since collator +sets do not need to meet Byzantine Fault Tolerance criteria, staking as the primary mechanism for +collator selection would remove stake that is securing BFT assumptions, making the network less +secure. + +Another problem with economic scalability relates to the increasing number of system chains, and +corresponding increase in need for collators (i.e., increase in collator slots). "Good" (highly +available, non-censoring) collators will not want to compete in elections on many chains when they +could use their resources to compete in the more profitable validator election. Such dilution +decreases the required bond on each chain, leaving them vulnerable to takeover by hostile +collator groups. + +This RFC proposes a system whereby collation is primarily an infrastructure service, with the +on-chain Treasury reimbursing costs of semi-trusted node operators, referred to as "Invulnerables". +The system need not trust the individual operators, only that as a _set_ they would be resilient to +coordinated attempts to stop a single chain from halting or to censor a particular subset of +transactions. + +In the case that users do not trust this set, this RFC also proposes that each chain always have +available collator positions that can be acquired by anyone by placing a bond. + +### Requirements + +- System MUST have at least one valid collator for every chain. +- System MUST allow anyone to become a collator, provided they `reserve`/`hold` enough DOT. +- System SHOULD select a set of collators with reasonable expectation that the set will not collude + to censor any subset of transactions. +- Collators selected by governance SHOULD have a reasonable expectation that the Treasury will + reimburse their operating costs. + +## Stakeholders + +- Infrastructure providers (people who run validator/collator nodes) +- Polkadot Treasury + +## Explanation + +This protocol builds on the existing +[Collator Selection pallet](https://github.com/paritytech/cumulus/tree/b15da70/pallets/collator-selection) +and its notion of Invulnerables. Invulnerables are collators (identified by their `AccountId`s) who +will be selected as part of the collator set every session. Operations relating to the management +of the Invulnerables are done through privileged, governance origins. The implementation should +maintain an API for adding and removing Invulnerable collators. + +In addition to Invulnerables, there are also open slots for "Candidates". Anyone can register as a +Candidate by placing a fixed bond. However, with a fixed bond and fixed number of slots, there is +an obvious selection problem: The slots fill up without any logic to replace their occupants. + +This RFC proposes that the collator selection protocol allow Candidates to increase (and decrease) +their individual bonds, sort the Candidates according to bond, and select the top `N` Candidates. +The selection and changeover should be coordinated by the session manager. + +A FRAME pallet already exists for sorting ("bagging") "top N" groups, the +[Bags List pallet](https://github.com/paritytech/substrate/blob/5032b8d/frame/bags-list/src/lib.rs). +This pallet's `SortedListProvider` should be integrated into the session manager of the Collator +Selection pallet. + +Despite the lack of apparent economic incentives (i.e., inflation), several reasons exist why one +may want to bond funds to participate in the Candidates election, for example: + +- They want to build credibility to be selected as Invulnerable; +- They want to ensure availability of an application, e.g. a stablecoin issuer might run a collator + on Asset Hub to ensure transactions in its asset are included in blocks; +- They fear censorship themselves, e.g. a voter might think their votes are being censored from + governance, so they run a collator on the governance chain to include their votes. + +Unlike the fixed-bond mechanism that fills up its Candidates, the election mechanism ensures that +anyone can join the collator set by placing the `Nth` highest bond. + +### Set Size + +In order to achieve the requirements listed under _Motivation_, it is reasonable to have +approximately: + +- 20 collators per system chain, +- of which 15 are Invulnerable, and +- five are elected by bond. + +## Drawbacks + +The primary drawback is a reliance on governance for continued treasury funding of infrastructure +costs for Invulnerable collators. + +## 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 + +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 + +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 + +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 + +This RFC is compatible with the existing implementation and can be handled via upgrades and +migration. + +## Prior Art and References + +### Written Discussions + +- [GitHub: Collator Selection Roadmap](https://github.com/paritytech/roadmap/issues/34) +- [GitHub: Revisit Collator Selection Mechanism](https://github.com/paritytech/cumulus/issues/1159) +- [Polkadot Forum: Economic Model for System Para Collators](https://forum.polkadot.network/t/economic-model-for-system-para-collators/1010) + +### Prior Feedback and Input From + +- Kian Paimani +- Jeff Burdges +- Rob Habermeier +- SR Labs Auditors +- Current collators including Paranodes, Stake Plus, Turboflakes, Peter Mensik, SIK, and many more. + +## Unresolved Questions + +None at this time. + +## Future Directions and Related Material + +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. From 83ea77d720efb1ad5109b73d0809f58244f1acc7 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Tue, 11 Jul 2023 20:57:34 +0200 Subject: [PATCH 03/16] update rfc number --- ...lator Selection.md => RFC-0007-System Collator Selection.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{RFC-000X-System Collator Selection.md => RFC-0007-System Collator Selection.md} (99%) diff --git a/text/RFC-000X-System Collator Selection.md b/text/RFC-0007-System Collator Selection.md similarity index 99% rename from text/RFC-000X-System Collator Selection.md rename to text/RFC-0007-System Collator Selection.md index 551ee3f6..43ed4d8c 100644 --- a/text/RFC-000X-System Collator Selection.md +++ b/text/RFC-0007-System Collator Selection.md @@ -1,4 +1,4 @@ -# RFC-000X: System Collator Selection +# RFC-0007: System Collator Selection | | | | --------------- | ----------------------------------------------------------------------------- | From ed2862b55832c13a87f1ad0764fe76578a21e243 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 14 Aug 2023 19:41:40 +0200 Subject: [PATCH 04/16] rename file --- text/0007-system-collator-selection.md | 162 +++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 text/0007-system-collator-selection.md diff --git a/text/0007-system-collator-selection.md b/text/0007-system-collator-selection.md new file mode 100644 index 00000000..43ed4d8c --- /dev/null +++ b/text/0007-system-collator-selection.md @@ -0,0 +1,162 @@ +# RFC-0007: System Collator Selection + +| | | +| --------------- | ----------------------------------------------------------------------------- | +| **Start Date** | 07 July 2023 | +| **Description** | Mechanism for selecting collators of system chains. | +| **Authors** | Joe Petrowski | + +## Summary + +As core functionality moves from the Relay Chain into system chains, so increases the reliance on +the liveness of these chains for the use of the network. It is not economically scalable, nor +necessary from a game-theoretic perspective, to pay collators large rewards. This RFC proposes a +mechanism -- part technical and part social -- for ensuring reliable collator sets that are +resilient to attemps to stop any subsytem of the Polkadot protocol. + +## Motivation + +In order to guarantee access to Polkadot's system, the collators on its system chains must propose +blocks (provide liveness) and allow all transactions to eventually be included. That is, some +collators may censor transactions, but there must exist one collator in the set who will include a +given transaction. In fact, all collators may censor varying subsets of transactions, but as long +as no transaction is in the intersection of every subset, it will eventually be included. The +objective of this RFC is to propose a mechanism to select such a set on each system chain. + +While the network as a whole uses staking (and inflationary rewards) to attract validators, +collators face different challenges in scale and have lower security assumptions than validators. +Regarding scale, there exist many system chains, and it is economically expensive to pay collators +a premium. Likewise, any staked DOT for collation is _not_ staked for validation. Since collator +sets do not need to meet Byzantine Fault Tolerance criteria, staking as the primary mechanism for +collator selection would remove stake that is securing BFT assumptions, making the network less +secure. + +Another problem with economic scalability relates to the increasing number of system chains, and +corresponding increase in need for collators (i.e., increase in collator slots). "Good" (highly +available, non-censoring) collators will not want to compete in elections on many chains when they +could use their resources to compete in the more profitable validator election. Such dilution +decreases the required bond on each chain, leaving them vulnerable to takeover by hostile +collator groups. + +This RFC proposes a system whereby collation is primarily an infrastructure service, with the +on-chain Treasury reimbursing costs of semi-trusted node operators, referred to as "Invulnerables". +The system need not trust the individual operators, only that as a _set_ they would be resilient to +coordinated attempts to stop a single chain from halting or to censor a particular subset of +transactions. + +In the case that users do not trust this set, this RFC also proposes that each chain always have +available collator positions that can be acquired by anyone by placing a bond. + +### Requirements + +- System MUST have at least one valid collator for every chain. +- System MUST allow anyone to become a collator, provided they `reserve`/`hold` enough DOT. +- System SHOULD select a set of collators with reasonable expectation that the set will not collude + to censor any subset of transactions. +- Collators selected by governance SHOULD have a reasonable expectation that the Treasury will + reimburse their operating costs. + +## Stakeholders + +- Infrastructure providers (people who run validator/collator nodes) +- Polkadot Treasury + +## Explanation + +This protocol builds on the existing +[Collator Selection pallet](https://github.com/paritytech/cumulus/tree/b15da70/pallets/collator-selection) +and its notion of Invulnerables. Invulnerables are collators (identified by their `AccountId`s) who +will be selected as part of the collator set every session. Operations relating to the management +of the Invulnerables are done through privileged, governance origins. The implementation should +maintain an API for adding and removing Invulnerable collators. + +In addition to Invulnerables, there are also open slots for "Candidates". Anyone can register as a +Candidate by placing a fixed bond. However, with a fixed bond and fixed number of slots, there is +an obvious selection problem: The slots fill up without any logic to replace their occupants. + +This RFC proposes that the collator selection protocol allow Candidates to increase (and decrease) +their individual bonds, sort the Candidates according to bond, and select the top `N` Candidates. +The selection and changeover should be coordinated by the session manager. + +A FRAME pallet already exists for sorting ("bagging") "top N" groups, the +[Bags List pallet](https://github.com/paritytech/substrate/blob/5032b8d/frame/bags-list/src/lib.rs). +This pallet's `SortedListProvider` should be integrated into the session manager of the Collator +Selection pallet. + +Despite the lack of apparent economic incentives (i.e., inflation), several reasons exist why one +may want to bond funds to participate in the Candidates election, for example: + +- They want to build credibility to be selected as Invulnerable; +- They want to ensure availability of an application, e.g. a stablecoin issuer might run a collator + on Asset Hub to ensure transactions in its asset are included in blocks; +- They fear censorship themselves, e.g. a voter might think their votes are being censored from + governance, so they run a collator on the governance chain to include their votes. + +Unlike the fixed-bond mechanism that fills up its Candidates, the election mechanism ensures that +anyone can join the collator set by placing the `Nth` highest bond. + +### Set Size + +In order to achieve the requirements listed under _Motivation_, it is reasonable to have +approximately: + +- 20 collators per system chain, +- of which 15 are Invulnerable, and +- five are elected by bond. + +## Drawbacks + +The primary drawback is a reliance on governance for continued treasury funding of infrastructure +costs for Invulnerable collators. + +## 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 + +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 + +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 + +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 + +This RFC is compatible with the existing implementation and can be handled via upgrades and +migration. + +## Prior Art and References + +### Written Discussions + +- [GitHub: Collator Selection Roadmap](https://github.com/paritytech/roadmap/issues/34) +- [GitHub: Revisit Collator Selection Mechanism](https://github.com/paritytech/cumulus/issues/1159) +- [Polkadot Forum: Economic Model for System Para Collators](https://forum.polkadot.network/t/economic-model-for-system-para-collators/1010) + +### Prior Feedback and Input From + +- Kian Paimani +- Jeff Burdges +- Rob Habermeier +- SR Labs Auditors +- Current collators including Paranodes, Stake Plus, Turboflakes, Peter Mensik, SIK, and many more. + +## Unresolved Questions + +None at this time. + +## Future Directions and Related Material + +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. From 7eb2193a1a82818c83be4501c4b2a1e6d343dedb Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 14 Aug 2023 19:42:33 +0200 Subject: [PATCH 05/16] remove old --- text/RFC-0007-System Collator Selection.md | 162 --------------------- 1 file changed, 162 deletions(-) delete mode 100644 text/RFC-0007-System Collator Selection.md diff --git a/text/RFC-0007-System Collator Selection.md b/text/RFC-0007-System Collator Selection.md deleted file mode 100644 index 43ed4d8c..00000000 --- a/text/RFC-0007-System Collator Selection.md +++ /dev/null @@ -1,162 +0,0 @@ -# RFC-0007: System Collator Selection - -| | | -| --------------- | ----------------------------------------------------------------------------- | -| **Start Date** | 07 July 2023 | -| **Description** | Mechanism for selecting collators of system chains. | -| **Authors** | Joe Petrowski | - -## Summary - -As core functionality moves from the Relay Chain into system chains, so increases the reliance on -the liveness of these chains for the use of the network. It is not economically scalable, nor -necessary from a game-theoretic perspective, to pay collators large rewards. This RFC proposes a -mechanism -- part technical and part social -- for ensuring reliable collator sets that are -resilient to attemps to stop any subsytem of the Polkadot protocol. - -## Motivation - -In order to guarantee access to Polkadot's system, the collators on its system chains must propose -blocks (provide liveness) and allow all transactions to eventually be included. That is, some -collators may censor transactions, but there must exist one collator in the set who will include a -given transaction. In fact, all collators may censor varying subsets of transactions, but as long -as no transaction is in the intersection of every subset, it will eventually be included. The -objective of this RFC is to propose a mechanism to select such a set on each system chain. - -While the network as a whole uses staking (and inflationary rewards) to attract validators, -collators face different challenges in scale and have lower security assumptions than validators. -Regarding scale, there exist many system chains, and it is economically expensive to pay collators -a premium. Likewise, any staked DOT for collation is _not_ staked for validation. Since collator -sets do not need to meet Byzantine Fault Tolerance criteria, staking as the primary mechanism for -collator selection would remove stake that is securing BFT assumptions, making the network less -secure. - -Another problem with economic scalability relates to the increasing number of system chains, and -corresponding increase in need for collators (i.e., increase in collator slots). "Good" (highly -available, non-censoring) collators will not want to compete in elections on many chains when they -could use their resources to compete in the more profitable validator election. Such dilution -decreases the required bond on each chain, leaving them vulnerable to takeover by hostile -collator groups. - -This RFC proposes a system whereby collation is primarily an infrastructure service, with the -on-chain Treasury reimbursing costs of semi-trusted node operators, referred to as "Invulnerables". -The system need not trust the individual operators, only that as a _set_ they would be resilient to -coordinated attempts to stop a single chain from halting or to censor a particular subset of -transactions. - -In the case that users do not trust this set, this RFC also proposes that each chain always have -available collator positions that can be acquired by anyone by placing a bond. - -### Requirements - -- System MUST have at least one valid collator for every chain. -- System MUST allow anyone to become a collator, provided they `reserve`/`hold` enough DOT. -- System SHOULD select a set of collators with reasonable expectation that the set will not collude - to censor any subset of transactions. -- Collators selected by governance SHOULD have a reasonable expectation that the Treasury will - reimburse their operating costs. - -## Stakeholders - -- Infrastructure providers (people who run validator/collator nodes) -- Polkadot Treasury - -## Explanation - -This protocol builds on the existing -[Collator Selection pallet](https://github.com/paritytech/cumulus/tree/b15da70/pallets/collator-selection) -and its notion of Invulnerables. Invulnerables are collators (identified by their `AccountId`s) who -will be selected as part of the collator set every session. Operations relating to the management -of the Invulnerables are done through privileged, governance origins. The implementation should -maintain an API for adding and removing Invulnerable collators. - -In addition to Invulnerables, there are also open slots for "Candidates". Anyone can register as a -Candidate by placing a fixed bond. However, with a fixed bond and fixed number of slots, there is -an obvious selection problem: The slots fill up without any logic to replace their occupants. - -This RFC proposes that the collator selection protocol allow Candidates to increase (and decrease) -their individual bonds, sort the Candidates according to bond, and select the top `N` Candidates. -The selection and changeover should be coordinated by the session manager. - -A FRAME pallet already exists for sorting ("bagging") "top N" groups, the -[Bags List pallet](https://github.com/paritytech/substrate/blob/5032b8d/frame/bags-list/src/lib.rs). -This pallet's `SortedListProvider` should be integrated into the session manager of the Collator -Selection pallet. - -Despite the lack of apparent economic incentives (i.e., inflation), several reasons exist why one -may want to bond funds to participate in the Candidates election, for example: - -- They want to build credibility to be selected as Invulnerable; -- They want to ensure availability of an application, e.g. a stablecoin issuer might run a collator - on Asset Hub to ensure transactions in its asset are included in blocks; -- They fear censorship themselves, e.g. a voter might think their votes are being censored from - governance, so they run a collator on the governance chain to include their votes. - -Unlike the fixed-bond mechanism that fills up its Candidates, the election mechanism ensures that -anyone can join the collator set by placing the `Nth` highest bond. - -### Set Size - -In order to achieve the requirements listed under _Motivation_, it is reasonable to have -approximately: - -- 20 collators per system chain, -- of which 15 are Invulnerable, and -- five are elected by bond. - -## Drawbacks - -The primary drawback is a reliance on governance for continued treasury funding of infrastructure -costs for Invulnerable collators. - -## 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 - -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 - -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 - -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 - -This RFC is compatible with the existing implementation and can be handled via upgrades and -migration. - -## Prior Art and References - -### Written Discussions - -- [GitHub: Collator Selection Roadmap](https://github.com/paritytech/roadmap/issues/34) -- [GitHub: Revisit Collator Selection Mechanism](https://github.com/paritytech/cumulus/issues/1159) -- [Polkadot Forum: Economic Model for System Para Collators](https://forum.polkadot.network/t/economic-model-for-system-para-collators/1010) - -### Prior Feedback and Input From - -- Kian Paimani -- Jeff Burdges -- Rob Habermeier -- SR Labs Auditors -- Current collators including Paranodes, Stake Plus, Turboflakes, Peter Mensik, SIK, and many more. - -## Unresolved Questions - -None at this time. - -## Future Directions and Related Material - -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. From e3ec1b901f18a91604379e8ebb6615b216ccc039 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Tue, 12 Sep 2023 20:13:50 +0200 Subject: [PATCH 06/16] make file --- text/XXXX-minimal-relay.md | 59 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 text/XXXX-minimal-relay.md diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md new file mode 100644 index 00000000..36da986b --- /dev/null +++ b/text/XXXX-minimal-relay.md @@ -0,0 +1,59 @@ +# RFC-0000: Minimal Relay + +| | | +| --------------- | ----------------------------------------------------------------------------- | +| **Start Date** | XX September 2023 | +| **Description** | Proposal to minimise Relay Chain functionality. | +| **Authors** | Joe Petrowski, Gavin Wood | + +## Summary + +One paragraph summary of the RFC. + +## Motivation + +Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. + +## Stakeholders + +A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. + +## Explanation + +Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. + +## Drawbacks + +Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. + +## Testing, Security, and Privacy + +Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. + +## Performance, Ergonomics, and Compatibility + +Describe the impact of the proposal on the exposed functionality of Polkadot. + +### Performance + +Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? + +### Ergonomics + +If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? + +### Compatibility + +Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. + +## Prior Art and References + +Provide references to either prior art or other relevant research for the submitted design. + +## Unresolved Questions + +Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. + +## Future Directions and Related Material + +Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. From 9870668db2598d2ac5a01d0f6eeb4715b7f87069 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Wed, 20 Sep 2023 08:51:25 +0200 Subject: [PATCH 07/16] first draft --- text/XXXX-minimal-relay.md | 84 ++++++++++++++++++++++++++++++++------ 1 file changed, 71 insertions(+), 13 deletions(-) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index 36da986b..4eac0d7a 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -2,33 +2,84 @@ | | | | --------------- | ----------------------------------------------------------------------------- | -| **Start Date** | XX September 2023 | +| **Start Date** | 20 September 2023 | | **Description** | Proposal to minimise Relay Chain functionality. | | **Authors** | Joe Petrowski, Gavin Wood | ## Summary -One paragraph summary of the RFC. +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 -Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. +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 of the total +validator set. + +However, state transitions on the Relay Chain need to be executed by _all_ validators. This +execution consumes compute time on a vast majority of validators that could be used for validating +parachains, as in, offering more blockspace, coretime, etc. to the network. + +By moving as much state transition logic off the Relay Chain and into "system chains" -- a set of +parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot Ubiquitous +Computer can specialise in providing its primary offering: secure blockspace. ## Stakeholders -A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. +- Parachains who interact with affected logic on the Relay Chain; +- The XCM format and its developers; +- Tooling and UI developers. ## Explanation -Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. +The following pallets and subsystems are good candidates to migrate from the Relay Chain: + +- Identity +- Preimage +- Balances +- Staking + - Staking + - Election Provider + - Bags List + - NIS + - Nomination Pools + - Fast Unstake +- Governance + - Treasury and Bounties + - Conviction Voting + - Referenda + +### Migrations + +Some subsystems are simpler to move than others. For example, migrating Identity can be done by +simply preventing state changes in the Relay Chain, using the Identity-related state as the genesis +for a new chain, and launching that new chain with the genesis and logic (pallet) needed. + +Other subsystems cannot experience any downtime like this because they are essential to the +network's functioning, like Staking and Governance. However, these do not store information for a +long time the way that Identity does, and can likely coexist with a similarly-permissioned system +chain for some time, much like how "Gov1" and "OpenGov" coexisted at the latter's introduction. + +### APIs + +The Relay Chain, in many cases, will still need to interact with these subsystems, especially +Staking and Governance. These subsystems will require making some APIs available either via +dispatchable calls or XCM `Instruction`s. For example, Staking provides a pallet-API to register +points (e.g. for block production) and offences. This API is often called every block to register +the points. With Staking in a system chain, that chain would need to allow the Relay Chain to update +validator points periodically so that it can correctly calculate rewards. ## Drawbacks -Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. +None at present. ## Testing, Security, and Privacy -Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. +Standard audit/review requirements apply. More powerful multi-chain integration test tools would be +useful in developement. ## Performance, Ergonomics, and Compatibility @@ -36,24 +87,31 @@ Describe the impact of the proposal on the exposed functionality of Polkadot. ### Performance -Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? +This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its +primary resources are allocated to system performance. ### Ergonomics -If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? +This proposal alters very little for coretime users (e.g. parachain developers). Application +developers will need to interact with multiple chains, making ergonomic light client tools +particularly important for application development. ### Compatibility -Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. +Implementing this proposal will require some changes to pallet APIs. Application developers will +need to interact with multiple chains in the network. ## Prior Art and References -Provide references to either prior art or other relevant research for the submitted design. +- [Transactionless Relay-chain](https://github.com/paritytech/polkadot/issues/323) +- [Moving Staking off the Relay Chain](https://github.com/paritytech/polkadot-sdk/issues/491) ## Unresolved Questions -Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. +There remain some implementation questions, like how to use balances for both Staking and +Governance. See, for example, [Moving Staking off the Relay +Chain](https://github.com/paritytech/polkadot-sdk/issues/491). ## Future Directions and Related Material -Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. +Ideally the Relay Chain becomes transactionless, such that not even balances are represented there. From 4be81b2fe8fa78f33fdc50ee08e5f4c7520db445 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Wed, 20 Sep 2023 20:16:24 +0200 Subject: [PATCH 08/16] tweaks --- text/XXXX-minimal-relay.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index 4eac0d7a..cfe1e7d8 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -21,7 +21,7 @@ validator set. However, state transitions on the Relay Chain need to be executed by _all_ validators. This execution consumes compute time on a vast majority of validators that could be used for validating -parachains, as in, offering more blockspace, coretime, etc. to the network. +parachains, as in, offering more coretime (a.k.a. blockspace) to the network. By moving as much state transition logic off the Relay Chain and into "system chains" -- a set of parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot Ubiquitous @@ -29,9 +29,9 @@ Computer can specialise in providing its primary offering: secure blockspace. ## Stakeholders -- Parachains who interact with affected logic on the Relay Chain; -- The XCM format and its developers; -- Tooling and UI developers. +- Parachains that interact with affected logic on the Relay Chain; +- Core protocol and XCM format developers; +- Tooling, block explorer, and UI developers. ## Explanation @@ -52,6 +52,9 @@ The following pallets and subsystems are good candidates to migrate from the Rel - Conviction Voting - Referenda +Note: The Auctions and Crowdloan pallets will be replaced by Coretime, its system chain and +interface described in RFC-1 and RFC-5, respectively. + ### Migrations Some subsystems are simpler to move than others. For example, migrating Identity can be done by @@ -63,14 +66,17 @@ network's functioning, like Staking and Governance. However, these do not store long time the way that Identity does, and can likely coexist with a similarly-permissioned system chain for some time, much like how "Gov1" and "OpenGov" coexisted at the latter's introduction. -### APIs +Specific migration plans will be included in release notes of runtimes from the Polkadot Fellowship. + +### Interfaces The Relay Chain, in many cases, will still need to interact with these subsystems, especially Staking and Governance. These subsystems will require making some APIs available either via -dispatchable calls or XCM `Instruction`s. For example, Staking provides a pallet-API to register -points (e.g. for block production) and offences. This API is often called every block to register -the points. With Staking in a system chain, that chain would need to allow the Relay Chain to update -validator points periodically so that it can correctly calculate rewards. +dispatchable calls accessible to XCM `Transact` or possibly XCM `Instruction`s in future versions. + +For example, Staking provides a pallet-API to register points (e.g. for block production) and +offences (e.g. equivocation). With Staking in a system chain, that chain would need to allow the +Relay Chain to update validator points periodically so that it can correctly calculate rewards. ## Drawbacks From d2b3e93b8b0a37f3d0a164c1657f20cf1742372a Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Wed, 20 Sep 2023 21:05:54 +0200 Subject: [PATCH 09/16] pubsub --- text/XXXX-minimal-relay.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index cfe1e7d8..4d4e1d3a 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -16,16 +16,16 @@ parachains. This is a proposal to migrate several subsystems into system paracha 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 of the total -validator set. +provides these common guarantees by executing the state transitions on a strict subset (a backing +group) of the total validator set. -However, state transitions on the Relay Chain need to be executed by _all_ validators. This -execution consumes compute time on a vast majority of validators that could be used for validating -parachains, as in, offering more coretime (a.k.a. blockspace) to the network. +However, state transitions on the Relay Chain need to be executed by _all_ validators. The resources +of the complement of a single backing group could be used to offer more cores. As in, they could be +offering more coretime (a.k.a. blockspace) to the network. -By moving as much state transition logic off the Relay Chain and into "system chains" -- a set of -parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot Ubiquitous -Computer can specialise in providing its primary offering: secure blockspace. +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 @@ -78,6 +78,8 @@ For example, Staking provides a pallet-API to register points (e.g. for block pr offences (e.g. equivocation). With Staking in a system chain, that chain would need to allow the Relay Chain to update validator points periodically so that it can correctly calculate rewards. +A pub-sub protocol may also lend itself to these types of interactions. + ## Drawbacks None at present. @@ -104,8 +106,8 @@ particularly important for application development. ### Compatibility -Implementing this proposal will require some changes to pallet APIs. Application developers will -need to interact with multiple chains in the network. +Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol. +Application developers will need to interact with multiple chains in the network. ## Prior Art and References From ff7141526b121e8642d8b1921697cf09d7c1c564 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Thu, 21 Sep 2023 09:59:29 +0200 Subject: [PATCH 10/16] migration text tweak --- text/XXXX-minimal-relay.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index 4d4e1d3a..c1527bf8 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -62,11 +62,12 @@ simply preventing state changes in the Relay Chain, using the Identity-related s for a new chain, and launching that new chain with the genesis and logic (pallet) needed. Other subsystems cannot experience any downtime like this because they are essential to the -network's functioning, like Staking and Governance. However, these do not store information for a -long time the way that Identity does, and can likely coexist with a similarly-permissioned system -chain for some time, much like how "Gov1" and "OpenGov" coexisted at the latter's introduction. +network's functioning, like Staking and Governance. However, these can likely coexist with a +similarly-permissioned system chain for some time, much like how "Gov1" and "OpenGov" coexisted at +the latter's introduction. -Specific migration plans will be included in release notes of runtimes from the Polkadot Fellowship. +Specific migration plans will be included in release notes of runtimes from the Polkadot Fellowship +when beginning the work of migrating a particular subsystem. ### Interfaces From c24acf196b69830b86ac2fe78cdbb3580bd0ad4c Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Wed, 27 Sep 2023 13:34:41 +0200 Subject: [PATCH 11/16] add discussions on identity, governance, and staking --- text/XXXX-minimal-relay.md | 56 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index c1527bf8..4162951f 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -81,6 +81,62 @@ Relay Chain to update validator points periodically so that it can correctly cal A pub-sub protocol may also lend itself to these types of interactions. +### Deployment + +Actual migrations should happen based on some prioritization. This RFC proposes to migrate Identity, +Staking, and Governance as the systems to work on first. A brief discussion on the factors involved +in each one: + +#### Identity + +Identity will be one of the simpler pallets to migrate into a system chain, as its logic is largely +self-contained and it does not "share" balances with other subsystems. As in, any DOT is held in +reserve as a storage deposit and cannot be simultaneously used the way locked DOT can be locked for +multiple purposes. + +Therefore, migration can take place as follows: + +1. A runtime upgrade will block all calls to the pallet, preventing updates to identity info. +1. The frozen state will form the genesis of a new system parachain. +1. A Relay Chain runtime upgrade will allow migrating the deposit to the parachain. The parachain + deposit is on the order of 1/100th of the Relay Chain's. Therefore, this will result in freeing + up Relay State as well as most of each user's reserved balance. +1. The pallet and any leftover state can be removed from the Relay Chain. + +User interfaces that render Identity information will need to source their data from the new system +parachain. + +#### Governance + +Migrating governance into a parachain will be more complicated, especially as the balances used for +voting in referenda are also used for staking. However, most of the other primitives needed for the +migration already exist. The Treasury supports spending assets on remote chains and collectives like +the Polkadot Technical Fellowship already function in a parachain. That is, XCM already provides the +ability to express system origins across chains. + +Therefore, actually moving the governance logic into a parachain will be simple. It can run in +parallel with the Relay Chain's governance, which can be removed when the parachain has demonstrated +sufficient functionality. It's possible that the Relay Chain maintain a Root-level emergency track +for situations like [parachains +halting](https://forum.polkadot.network/t/stalled-parachains-on-kusama-post-mortem/3998). The only +problem that remains to solve is how to deal with balances that are used for staking too. + +#### Staking + +Migrating the staking subsystem will likely be the most complex technical undertaking, as the +staking system cannot stop (the system MUST always have a validator set) nor run in parallel (the +system MUST have _one_ validator set) and the system itself is made up of subsystems in the runtime +and the node. For example, if offences are reported to the Staking parachain, validator nodes will +need to submit their reports there. + +Handling balances also introduces complications. The same balance can be used for staking and +governance. Ideally, all balances stay on Asset Hub, and only report "credits" to system chains like +Staking and Governance. However, staking mutates balances by issuing new DOT on era changes and for +rewards. + +There is more discussion about staking in a parachain in [Moving Staking off the Relay +Chain](https://github.com/paritytech/polkadot-sdk/issues/491). + ## Drawbacks None at present. From b452c7ee3e4a21b9e0771c7fcda73d8c371d314f Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Wed, 27 Sep 2023 15:27:30 +0200 Subject: [PATCH 12/16] nits --- text/XXXX-minimal-relay.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index 4162951f..e795b5e7 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -17,11 +17,12 @@ parachains. This is a proposal to migrate several subsystems into system paracha 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 -group) of the total validator set. +group) of the Relay Chain's validator set. -However, state transitions on the Relay Chain need to be executed by _all_ validators. The resources -of the complement of a single backing group could be used to offer more cores. As in, they could be -offering more coretime (a.k.a. blockspace) to the network. +However, state transitions on the Relay Chain need to be executed by _all_ validators. If any of +those state transitions can occur on parachains, then the resources of the complement of a single +backing group could be used to offer more cores. As in, they could be offering more coretime (a.k.a. +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 @@ -125,14 +126,14 @@ problem that remains to solve is how to deal with balances that are used for sta Migrating the staking subsystem will likely be the most complex technical undertaking, as the staking system cannot stop (the system MUST always have a validator set) nor run in parallel (the -system MUST have _one_ validator set) and the system itself is made up of subsystems in the runtime -and the node. For example, if offences are reported to the Staking parachain, validator nodes will -need to submit their reports there. +system MUST have _one_ validator set) and the subsystem itself is made up of subsystems in the +runtime and the node. For example, if offences are reported to the Staking parachain, validator +nodes will need to submit their reports there. Handling balances also introduces complications. The same balance can be used for staking and governance. Ideally, all balances stay on Asset Hub, and only report "credits" to system chains like Staking and Governance. However, staking mutates balances by issuing new DOT on era changes and for -rewards. +rewards. Allowing DOT directly on the Staking parachain would simplify staking changes. There is more discussion about staking in a parachain in [Moving Staking off the Relay Chain](https://github.com/paritytech/polkadot-sdk/issues/491). From b17a254cf36b456da8d1ea4d7aebf4a73401cd36 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 2 Oct 2023 10:26:12 +0200 Subject: [PATCH 13/16] commit more to balances on staking para --- text/XXXX-minimal-relay.md | 41 ++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/text/XXXX-minimal-relay.md b/text/XXXX-minimal-relay.md index e795b5e7..c8584199 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/XXXX-minimal-relay.md @@ -107,26 +107,11 @@ Therefore, migration can take place as follows: User interfaces that render Identity information will need to source their data from the new system parachain. -#### Governance - -Migrating governance into a parachain will be more complicated, especially as the balances used for -voting in referenda are also used for staking. However, most of the other primitives needed for the -migration already exist. The Treasury supports spending assets on remote chains and collectives like -the Polkadot Technical Fellowship already function in a parachain. That is, XCM already provides the -ability to express system origins across chains. - -Therefore, actually moving the governance logic into a parachain will be simple. It can run in -parallel with the Relay Chain's governance, which can be removed when the parachain has demonstrated -sufficient functionality. It's possible that the Relay Chain maintain a Root-level emergency track -for situations like [parachains -halting](https://forum.polkadot.network/t/stalled-parachains-on-kusama-post-mortem/3998). The only -problem that remains to solve is how to deal with balances that are used for staking too. - #### Staking Migrating the staking subsystem will likely be the most complex technical undertaking, as the -staking system cannot stop (the system MUST always have a validator set) nor run in parallel (the -system MUST have _one_ validator set) and the subsystem itself is made up of subsystems in the +Staking system cannot stop (the system MUST always have a validator set) nor run in parallel (the +system MUST have only _one_ validator set) and the subsystem itself is made up of subsystems in the runtime and the node. For example, if offences are reported to the Staking parachain, validator nodes will need to submit their reports there. @@ -135,9 +120,30 @@ governance. Ideally, all balances stay on Asset Hub, and only report "credits" t Staking and Governance. However, staking mutates balances by issuing new DOT on era changes and for rewards. Allowing DOT directly on the Staking parachain would simplify staking changes. +Given the complexity, it would be pragmatic to include the Balances pallet in the Staking parachain +in its first version. Any other systems that use overlapping locks, most notably governance, will +need to recognise DOT held on both Asset Hub and the Staking parachain. + There is more discussion about staking in a parachain in [Moving Staking off the Relay Chain](https://github.com/paritytech/polkadot-sdk/issues/491). +#### Governance + +Migrating governance into a parachain will be less complicated than staking. Most of the primitives +needed for the migration already exist. The Treasury supports spending assets on remote chains and +collectives like the Polkadot Technical Fellowship already function in a parachain. That is, XCM +already provides the ability to express system origins across chains. + +Therefore, actually moving the governance logic into a parachain will be simple. It can run in +parallel with the Relay Chain's governance, which can be removed when the parachain has demonstrated +sufficient functionality. It's possible that the Relay Chain maintain a Root-level emergency track +for situations like [parachains +halting](https://forum.polkadot.network/t/stalled-parachains-on-kusama-post-mortem/3998). + +The only complication arises from the fact that both Asset Hub and the Staking parachain will have +DOT balances; therefore, the Governance chain will need to be able to credit users' voting power +based on balances from both locations. This is not expected to be difficult to handle. + ## Drawbacks None at present. @@ -181,3 +187,4 @@ Chain](https://github.com/paritytech/polkadot-sdk/issues/491). ## Future Directions and Related Material Ideally the Relay Chain becomes transactionless, such that not even balances are represented there. +With Staking and Governance off the Relay Chain, this is not an unreasonable next step. From 8e9ae25d0d600e2eecfc0344a40d956e35d207fc Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Mon, 2 Oct 2023 11:33:50 +0200 Subject: [PATCH 14/16] add RFC number --- text/{XXXX-minimal-relay.md => 0032-minimal-relay.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{XXXX-minimal-relay.md => 0032-minimal-relay.md} (99%) diff --git a/text/XXXX-minimal-relay.md b/text/0032-minimal-relay.md similarity index 99% rename from text/XXXX-minimal-relay.md rename to text/0032-minimal-relay.md index c8584199..9c98e1a7 100644 --- a/text/XXXX-minimal-relay.md +++ b/text/0032-minimal-relay.md @@ -1,4 +1,4 @@ -# RFC-0000: Minimal Relay +# RFC-0032: Minimal Relay | | | | --------------- | ----------------------------------------------------------------------------- | From 099975ee61225592894733845ab0c69e92681a79 Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Wed, 4 Oct 2023 07:30:51 +0200 Subject: [PATCH 15/16] review changes --- text/0032-minimal-relay.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/text/0032-minimal-relay.md b/text/0032-minimal-relay.md index 9c98e1a7..34dd5dec 100644 --- a/text/0032-minimal-relay.md +++ b/text/0032-minimal-relay.md @@ -39,7 +39,6 @@ Ubiquitous Computer can maximise its primary offering: secure blockspace. The following pallets and subsystems are good candidates to migrate from the Relay Chain: - Identity -- Preimage - Balances - Staking - Staking @@ -107,6 +106,9 @@ Therefore, migration can take place as follows: User interfaces that render Identity information will need to source their data from the new system parachain. +Note: In the future, it may make sense to decommission Kusama's Identity chain and do all account +identities via Polkadot's. However, the Kusama chain will serve as a dress rehearsal for Polkadot. + #### Staking Migrating the staking subsystem will likely be the most complex technical undertaking, as the @@ -146,7 +148,8 @@ based on balances from both locations. This is not expected to be difficult to h ## Drawbacks -None at present. +These subsystems will have reduced resources in cores than on the Relay Chain. Staking in particular +may require some optimizations to deal with constraints. ## Testing, Security, and Privacy @@ -168,6 +171,9 @@ This proposal alters very little for coretime users (e.g. parachain developers). developers will need to interact with multiple chains, making ergonomic light client tools particularly important for application development. +For existing parachains that interact with these subsystems, they will need to configure their +runtimes to recognize the new locations in the network. + ### Compatibility Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol. From 87ab0f1be5bafd404e7a1e6f465db027b5271ecd Mon Sep 17 00:00:00 2001 From: joepetrowski Date: Sat, 14 Oct 2023 16:41:54 +0200 Subject: [PATCH 16/16] add architecture, resource allocation, and kusama's role --- text/0032-minimal-relay.md | 76 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 72 insertions(+), 4 deletions(-) diff --git a/text/0032-minimal-relay.md b/text/0032-minimal-relay.md index 34dd5dec..1903f074 100644 --- a/text/0032-minimal-relay.md +++ b/text/0032-minimal-relay.md @@ -81,6 +81,49 @@ Relay Chain to update validator points periodically so that it can correctly cal A pub-sub protocol may also lend itself to these types of interactions. +### Functional Architecture + +This RFC proposes that system chains form individual components within the system's architecture and +that these components are chosen as functional groups. This approach allows synchronous +composibility where it is most valuable, but isolates logic in such a way that provides flexibility +for optimal resource allocation (see [Resource Allocation](#resource-allocation)). For the +subsystems discussed in this RFC, namely Identity, Governance, and Staking, this would mean: + +- People Chain, for identity and personhood logic, providing functionality related to the attributes + of single actors; +- Governance Chain, for governance and system collectives, providing functionality for pluralities + to express their voices within the system; +- Staking Chain, for Polkadot's staking system, including elections, nominations, reward + distribution, slashing, and non-interactive staking; and +- Asset Hub, for fungible and non-fungible assets, including DOT. + +The Collectives chain and Asset Hub already exist, so implementation of this RFC would mean two new +chains (People and Staking), with Governance moving to the _currently-known-as_ Collectives chain +and Asset Hub being increasingly used for DOT over the Relay Chain. + +Note that one functional group will likely include many pallets, as we do not know how pallet +configurations and interfaces will evolve over time. + +### Resource Allocation + +The system should minimise wasted blockspace. These three (and other) subsystems may not each +consistently require a dedicated core. However, core scheduling is far more agile than functional +grouping. While migrating functionality from one chain to another can be a multi-month endeavour, +cores can be rescheduled almost on-the-fly. + +Migrations are also breaking changes to some use cases, for example other parachains that need to +route XCM programs to particular chains. It is thus preferable to do them a single time in migrating +off the Relay Chain, reducing the risk of needing parachain splits in the future. + +Therefore, chain boundaries should be based on functional grouping where synchronous composibility +is most valuable; and efficient resource allocation should be managed by the core scheduling +protocol. + +Many of these system chains (including Asset Hub) could often share a single core in a semi-round +robin fashion (the coretime may not be uniform). When needed, for example during NPoS elections or +slashing events, the scheduler could allocate a dedicated core to the chain in need of more +throughput. + ### Deployment Actual migrations should happen based on some prioritization. This RFC proposes to migrate Identity, @@ -96,11 +139,12 @@ multiple purposes. Therefore, migration can take place as follows: -1. A runtime upgrade will block all calls to the pallet, preventing updates to identity info. +1. The pallet can be put in a locked state, blocking most calls to the pallet and preventing updates + to identity info. 1. The frozen state will form the genesis of a new system parachain. -1. A Relay Chain runtime upgrade will allow migrating the deposit to the parachain. The parachain - deposit is on the order of 1/100th of the Relay Chain's. Therefore, this will result in freeing - up Relay State as well as most of each user's reserved balance. +1. Functions will be added to the pallet that allow migrating the deposit to the parachain. The + parachain deposit is on the order of 1/100th of the Relay Chain's. Therefore, this will result in + freeing up Relay State as well as most of each user's reserved balance. 1. The pallet and any leftover state can be removed from the Relay Chain. User interfaces that render Identity information will need to source their data from the new system @@ -146,6 +190,28 @@ The only complication arises from the fact that both Asset Hub and the Staking p DOT balances; therefore, the Governance chain will need to be able to credit users' voting power based on balances from both locations. This is not expected to be difficult to handle. +### Kusama + +Although Polkadot and Kusama both have system chains running, they have to date only been used for +introducing new features or bodies, for example fungible assets or the Technical Fellowship. There +has not yet been a migration of logic/state from the Relay Chain into a parachain. Given its more +realistic network conditions than testnets, Kusama is the best stage for rehearsal. + +In the case of identity, Polkadot's system may be sufficient for the ecosystem. Therefore, Kusama +should be used to test the migration of logic and state from Relay Chain to parachain, but these +features may be (at the will of Kusama's governance) dropped from Kusama entirely after a successful +migration on Polkadot. + +For Governance, Polkadot already has the Collectives parachain, which would become the Governance +parachain. The entire group of DOT holders is itself a collective (the legislative body), and +governance provides the means to express voice. Launching a Kusama Governance chain would be +sensible to rehearse a migration. + +The Staking subsystem is perhaps where Kusama would provide the most value in its canary capacity. +Staking is the subsystem most constrained by PoV limits. Ensuring that elections, payouts, session +changes, offences/slashes, etc. work in a parachain on Kusama -- with its larger validator set -- +will give confidence to the chain's robustness on Polkadot. + ## Drawbacks These subsystems will have reduced resources in cores than on the Relay Chain. Staking in particular @@ -194,3 +260,5 @@ Chain](https://github.com/paritytech/polkadot-sdk/issues/491). Ideally the Relay Chain becomes transactionless, such that not even balances are represented there. With Staking and Governance off the Relay Chain, this is not an unreasonable next step. + +With Identity on Polkadot, Kusama may opt to drop its People Chain.