Polkadot and Kusama Staking Changes

2021-06-23 in  Polkadot, Kusama, Staking, NPoS
Avatar by Polkadot
Image

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.

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.

In the near future, 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.

arrow_upward
Related articles
Polkadot
XCM Part II: Versioning and Compatibility

Polkadot founder Gavin Wood inspects one interesting aspect of XCM in-depth: how XCM can change over time without introducing breakage between the very networks it is meant to connect....

Polkadot
XCM: The Cross-Consensus Message Format

This primer on XCM, Polkadot's inter-chain messaging format is the first in a series of articles explaining what it does, how it works, how to use it, and what it could become....

Kusama
Kusama’s First Batch of Parachains: An Interview with the Teams

This blog contains information provided by the projects Karura, Moonriver, Shiden, Khala, and Bifrost, in order of when they won their parachain slot. Discover what network each does, their achievements so far, and the phases ahead on their respective roadmaps....

Subscribe to the newsletter to hear about updates and events.
mail_outline
* To see how we use your information, please see our privacy policy.