System Collator Set Selection #7
Conversation
merge upstream
| approximately: | ||
|
|
||
| - 20 collators per system chain, | ||
| - of which 15 are Invulnerable, and |
There was a problem hiding this comment.
any explanations of those numbers?
I would expect low number of invulnerable as it needs to be managed by governance and therefore high bar of entry.
There was a problem hiding this comment.
The numbers were recommendations from SR Labs, however I find them quite reasonable. Of course it will take time to get this many collators, and there may be situations where it makes sense to have more collators on a particular chain. But I think these are good general purpose targets.
With respect to the high bar of entry, that's the point. Due to the high number (supply) of system parachains, and low profitability (demand) for being a collator, the open election would likely be a very low bar of entry, making it vulnerable to malicious takeover.
As the Motivation section says,
"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."
There was a problem hiding this comment.
ok I see the reasons now. However this to me is more of a short term workaround that there is not enough incentive to be system chain collector. Any plan to fix that? Relying on governance to gate keep things should be a last resort.
There was a problem hiding this comment.
I don't see governance as a last resort, just as one of many tools. Our initial discussion was around creating incentives (see forum), but it's really not scalable. We expect many more collators than validators in the system, and as you know validators are expensive (e.g. 50 system chains x 20 collators = 1000 collators). Likewise, collation is not a secure activity and doesn't warrant large incentives.
The incentives for governance-selected collators is often around building reputation as, for example, a validator.
Also from the Motivation:
"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."
|
Would be great if the RFC file is renamed according to the template. |
👍 done |
|
I think this RFC sums the situation up really nicely. I am just missing a description of a mechanism by which the Invulnerable collators will be selected in the future - there were various ideas in the collator group but we ended up using a quite simple solution based on fairness and gentleman's agreement. Is this mechanism going to stay the same in the future or should we get general governance involved when new system chains come out (like Coretime)? |
|
There is no way to enforce on-chain what someone proposes to governance. Any individual or group can use any mechanism to propose to add or remove someone as an Invulnerable, and the referendum process will accept or reject the proposal. "Fairness" is quite subjective. Therefore, it is not part of the RFC. |
| 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. |
There was a problem hiding this comment.
Why are we not choosing randomly? Why based on the highest bond? What is the reason behind this?
There was a problem hiding this comment.
I don't really expect bonds to be high since there is not much incentive, but in case someone does have a strong incentive (e.g. thinks their transactions are being censored), they should have a path to getting selected.
With fixed bond and random selection, there are two problems (unless you see a better solution):
- We can limit the number of candidates like we do now and select randomly. But if the set is full, how does a new candidate join? With a fixed bond, there's no comparison to justify kicking someone out.
- We can have an unlimited number of candidates, but then people can just use multiple accounts and place the fixed bond many times, increasing their probability of being selected.
(2) could be an option, the selection rate would map to the bond amount (represented by number of accounts). It seems less efficient though as it requires running nodes for all the accounts, whereas top N requires only one node per candidate entity.
There was a problem hiding this comment.
2. We can have an unlimited number of candidates, but then people can just use multiple accounts and place the fixed bond many times, increasing their probability of being selected.
Yeah that is a valid point.
So, yeah scratch my idea.
|
/rfc process |
|
Please provider a block hash where the referendum confirmation event is to be found. Instructions to find the block hashHere is one way to find the corresponding block hash.
|
|
/rfc process 0x37ae0558f4b008f9e7e421488b3466bfb2ea3510a1a58a2d40beff681e84cc42 |
|
Unable to find the referendum confirm event in the given block. Instructions to find the block hashHere is one way to find the corresponding block hash.
|
|
/rfc process 0x9ad960de812071c892cc545743b4ffb85fcdaf969f1b77429ce9c1d4219f2f4b |
|
@joepetrowski Handling the RFC command failed :( You can open an issue here. |
The bot doesn't specify the merge option - apparently it defaults to a merge commit which is disabled in this repo. I have a change to use squash-merging in the bot. |
|
/rfc process 0x9ad960de812071c892cc545743b4ffb85fcdaf969f1b77429ce9c1d4219f2f4b |
|
The on-chain referendum has approved the RFC. |
As discussed in the roadmap with corresponding implementation issues, converting this to an RFC. This proposes a means of selecting collator sets on system chains.