System Collator Set Selection (#7)

* create file * add body of rfc * update rfc number * rename file * remove old
2026-04-22 02:07:57 +00:00 · 2023-09-13 16:20:26 +02:00
parent 5bdc6f85f1
commit cc9a16f713
1 changed files with 162 additions and 0 deletions
@@ -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.