A few of us (@kianenigma @burdges @giulia @bkontur & Roman) discussed this topic and how to go about implementing something on a call today and wanted to sum up the discussion/first steps we plan to take.
First, we generally agreed with @rphmeier ‘s point that different chains could have different requirements, and that some Treasury process that roughly covers collators’ expenses is better than using a fixed percentage of inflation. This plays nice with the idea that one parachain might require more funding than another, so the Treasury proposals can account for that.
Regarding the specific mechanisms by which a chain splits up the DOT (or, once the Treasury holds stablecoins, perhaps those) allocated to it, we briefly discussed it but didn’t make any implementation decisions. There are also a few other services that collators can provide, like public RPC endpoints for the parachain and/or the Relay Chain that could be factored in if the particular node isn’t elected all the time. However, I think a good starting point is a pallet that pays from a single pallet-controlled account to some set of accounts with various strategy impl
s (e.g. equally, pro-rata based on number of blocks authored, etc.).
Second, we discussed election mechanisms. We were trying to balance two main aspects: (1) we want to ensure a diverse set of entities collating, and (2) we want most of the stake to be on validators, so we expect collator bonds to be low.
The problem with (2) is that low bonds makes it easy for one relatively small entity to take over collation on a system chain. Our opinion was that we could balance them with some nodes selected by governance. This is quite similar to the Invulnerables
system that exists today, except that rather than having those nodes run by Parity (as they were for Statemint/Statemine at genesis), there would be some conventions like having a verified identity, running a validator node, etc.
These governance selected collators would account for some percentage of the collator set (let’s say, arbitrarily, 30%), while the remainder of the set would be chosen by order of self-stake. This combination means that anyone can become a collator on a system chain by placing a bond higher than the n
th highest existing collator on a chain, but ensures some diversity of entities (assuming governance has chosen wisely) so that no amount of stake can fully take over collation (and kill liveness) of a system chain.
Those are all things we can do in the short term via small modifications to the Collator Selection pallet and some Treasury proposals/precendent.
Longer term, an election parachain or staking solution can pass the nomination info to parachains, which can apply approval backing to select collators that correspond to more approval behind the address that is also a validator (i.e. we’d expect the same AccountId
to be used on all chains). Jeff and Kian had more concrete ideas so probably better for one of them to respond to this.
I don’t think there is a single standard, but the invariant is that the Relay Chain validators must be able to validate whatever the collator passes them. So off the top of my head, I’d say validator benchmark specs are actually a ceiling of the max needed. That’s speaking very generally though, parachains might have higher storage or other special requirements on a per-para basis.
I also think it depends on the parachain. Some parathread that makes one block a day might be fine with a single primary collator with some fallback in case it goes down, while a storage or fast payments chain might want/need a lot to ensure the decentralization you mentioned.