As witnessed, a considerable rise in demand for staking on both Polkadot and Kusama after the debut of NPoS on both networks. Some limits of the current staking settings as the number of accounts nominated on Polkadot and Kusama has grown. More memory as the size of the election solution set grows, up to the limitations of what the runtime WebAssembly configuration allows. Some constraints implement to the staking mechanism on both networks to avoid issues arising when reaching these limits.
The Network’s Stability is Crucial
While it’s crucial to allow as many individuals to nominate as possible, the network’s stability is even more important. To comprehend the imposition of these limitations, one must first comprehend the process of validator selection.
Determining which validators are in the active set in each era, and which nominators nominate them, is a memory-intensive job that yields a massive graph mapping nominators to validators. If the graph is too huge, WebAssembly will not be able to process it. Because all validators have a limited amount of memory, the amount allocated to this task without compromising the remainder of the validator’s functionality has limitations.
The Nodes’ Capacity
The size of this network has grown to the point where it can affect nodes’ capacity to operate appropriately since the number of nominators has increased to around 30 000. Guardrails put around cautious estimations of what the validating nodes can handle. Rather than waiting for failures to occur organically.
Two staking limitations added to runtime 9050 (native version included in Polkadot 0.9.5). These constraints ensure handling the resulting graphs without difficulty in WebAssembly.
The first is a fixed number of nominators of 20 000. (on both Polkadot and Kusama). That is, at any given time, only 20 000 accounts can be nominators. This value, like the number of validators in the active set, is modifiable by governance.
In terms of staking, a soft restriction was at the minimum stake that a nominator can use to nominate. On Polkadot, it sets to 20 DOT, while on Kusama, it sets to 0.1 KSM (100 milliKSM). Accounts with fewer than these limits will not be able to stake. Accounts can only bond smaller amounts and cannot be nominated. Any account can now forcibly cool (stop them from nominating) a nominator who is nominating with less than this minimal amount for those accounts who are already dominating. Shortly after the adjustments go online, Polkadot will run a sweep of all accounts nominating with less than this minimum amount, and those accounts will cool down (that is, they will stop nominating). This initial sweep will not perform on Kusama since the number of nominators now exceeds the new nominator limit.
Changes to Crypto Staking that are in the Works
Staking crypto on Polkadot and Kusama networks will modify in the near future. Improvements to the nominating mechanism develop, as well as more accurate estimations of the maximum number of nominators who can participate. Following that, we expect governance to change staking conditions, particularly the hard cap on the number of nominators, in order to promote staking participation. Another short-term option is the limitation of a nominator’s ability to nominate more than eight validators.
Other options for the increasing number of nominators in the system are under investigation in the long run. Storing the solution in many blocks or allocating a system parachain (common good) expressly for staking are two possible alternatives.
Because Polkadot’s code is open-source, the source code is the best place to look for further information. This pull request contains important changes.
“The views and opinions on this Crypto News Website are solely those of the authors and contributors. These views and opinions do not necessarily represent those of iBaseTrading or its partners.”
