Since the launch of NPoS on Polkadot and Kusama, we’ve seen a significant increase in demand for participating in staking on both networks. With the increase in the number of accounts nominating on Polkadot and Kusama, we have seen some limitations of the current staking parameters. Specifically, as the size of the election solution set grows, more memory is used, up to the limits of what the runtime WebAssembly is configured to permit. In order to prevent issues from occurring when these limits are reached, some restrictions are being added to the staking system on both networks.
While it’s important to allow as many people to nominate as possible, it’s even more important to ensure the stability of the network. To understand why these restrictions were added, one should first understand the process of electing validators.
Determining which validators are in the active set in each era, and which nominators are nominating them, is a memory-intensive task that results in a very large graph, mapping the nominators to their respective validators. If this graph is too large, then cannot be processed in WebAssembly. As all validators have a finite amount of memory, there are limits to how much can be allocated to this task without affecting the rest of the validators’ functionality.
As the number of nominators has increased up to approximately 30_000, the size of this graph has reached the point where it can impact nodes’ ability to function correctly. Instead of waiting for failures to occur naturally, “guardrails” have been added around conservative estimates of what the validating nodes can handle.
Starting with runtime 9050 (native version included in Polkadot 0.9.5), two limits to staking have been added. These limits will ensure that the generated graphs can be processed in WebAssembly without problems.
The first is a hard limit of 20_000 nominators (on both Polkadot and Kusama). That is, only 20_000 accounts can be nominators at any given time. Just like the number of validators in the active set, this value can be modified by governance.
As for staking, a soft limit has also been added in terms of the minimum stake with which a nominator can nominate. This has been set to 20 DOT on Polkadot and 0.1 KSM (100 milliKSM) on Kusama. Accounts will not be able to stake with less than these limits. Accounts can bond lesser amounts, but not nominate. For those accounts who are already nominating, any account can now forcibly chill (stop them from nominating) a nominator who is nominating with less than this minimal amount. An initial sweep of all accounts nominating with less than this minimal amount will be made on Polkadot shortly after the changes are live, and those accounts will be chilled (that is, they will stop nominating). This initial sweep will not be done on Kusama; it is not necessary because the current number of nominators is under the new nominator limit.
Planned Changes to Crypto Staking
In the near future, staking crypto on Polkadot and Kusama neworks will be updated. Improvements to the nominating system are being developed and better estimates as to the maximum number of nominators that can participate are being determined. After this, we expect that governance will modify staking parameters, especially increasing the hard cap on the number of nominators to increase participation in staking. Another near-term solution being explored is reducing the number of validators that a nominator can nominate to eight.
In the longer term, other solutions are currently being explored to increase the number of nominators possible in the system. Some potential solutions include storing the solution in multiple blocks or having a system parachain (common good) allocated specifically for staking.
As the code for Polkadot is open-source, the best place to get more information is the source code. You can find the relevant changes in this pull request.
UPDATE: As of June 30, 2021, the staking parameters have been modified to a minimum of 40 DOT to nominate, and a maximum of 22_500 total nominators. For more information, see the Referendum 28 Polkassembly post.
From the blog
Elevating Polkadot's Performance and Scale with Asynchronous Backing
Asynchronous backing is the latest step in the roadmap towards natively scaling Polkadot’s performance and flexibility for Web3 use cases across every industry.