I started this gist as an index for all of the staking reports. Almost a year in, we migrated everything to https://polkadot.network/tag/staking-updates/. This page will no longer be updated:
Polkadot's staking system is among the most complicated in the blockchain ecosystem. The relay chain's validator set is securing not just the state transition of the relay chain itself, but also a potentially large number of parallel chains, or parachains for short. Since security is its main goal, Polkadot has been designed with a complicated, and strict staking system, optimized for locking the most amount of tokens at stake while spreading that stake as evenly as possible to maximize decentralization - all with the goal of effectively minimizing the possibility of the validator set becoming compromised. Read more about this here, or watch this talk.
The complications of achieving NPoS has led to the staking system to come under strain with Polkadot's rapid scaling. This monthly note is compiled by the main developers maintaining the staking system, and will be updated every month with the latest changes, explaining what has been done and what is next, in the spirit of transparency and clear communication to the Polkadot stakers. Feel free to contact @kianenigma or @zeke in any of Parity/Polkadot Element chats, such as the Polkadot watercooler if you have further questions.
This note only mentions Polkadot. Nonetheless, at a technical level, everything mentioned here is applicable ot Kusama as well. Kusama has a smaller number of nominators, and is therefore not constrained by the same limits (well, yet, expect chaos!).
-
This month's main focus was on a PR that will allow the staking pallet to maintain a semi-sorted list of all nominators. This will allow us to remove the count limit on nominators (or increase it significantly) and make the
nominatetransaction available at all times again. That being said, the sorted list will still act as an entry barrier: When the time for a staking election comes, we will only take the topxnominators, wherexwill most likely be the same as our current limit,22500or very similar. This limit will be removed once we achive our next milestone, multi-block elections (read below). -
The semi-sorted list will act as the foundation of our next big step, which is multi-block elections. Sometime in the future, Polkadot will, for example, be able to allocate 5 blocks to its staking election, during which the 5 most highly staked pages of nominators (where each page has a fixed size) need to processed and used for the election. This is why the sorted list of nominators is important! The multi-block election change is being actively designed and prototyped, see this tracking issue. Furthermore, in the long term future something like an NPoS election parachains could enable virtually unbounded nominator participation as all blocks could be used to process elections.)
-
In motion 31 we proposed the increase of the minimum nomination bond to 80 DOTs. This is (inevitably) the chain's only strategy to deal with the influx of nominators as of now, until the multi-block elections are deployed. Most of nominators who had staked less than this amount have already been chilled through the permissionless
chill_othertransaction. -
Kusama's number of nominators is still below 7000, with a slight decrease over the last month, which can be attributed to the launch of parachains and stakers moving into crowdloans. So, for now, exceptionally, no chaos is expected 🦜.
Hello Kian,
I'm not aware of how complex the NPoS of Polkadot is. But the main issue right now is a number of nominators too great that would cause trouble to the network. So an idea have crossed my mind, I certainly miss important things, but wouldn't it possible for multiple addresses to act as one nominator ? (and the reward would be distributed between them). Let's say for example instead of having 10 nominators A, B, C ... A, B and C would work together as one nominator "Z" (let's call it an aggregated nominator), and from the algo point of view, A, B C does not exists, only Z as a nominator, for a total of 8 nominators, behind the scene, once the reward for aggregated-nominator Z is given out, then A B and C share the reward. I'm aware this add complexity (for starter, all nominators would need to trust each other and share the exact same set of validators), but maybe it is a way to reduce sorting without reducing the number of account that can nominate ? Anyway, I don't have the full picture of how it works, so I probably overlooked something.