diff --git a/text/0007-system-collator-selection.md b/text/0007-system-collator-selection.md new file mode 100644 index 000000000..43ed4d8ce --- /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.