Staking Update: February 2022
By Polkadot•February 28, 2022
By Kian Paimani, Parity Technologies
Nomination bags-list active on Polkadot
As of writing this, Polkadot is a day or so away from its scheduled upgrade to 9170, where the bags-list will finally become active. A lot has been said in the previous issues of this update about the impact of this!
Minimum nominator bond: temporary increase
In the previous month’s update, it was mentioned that the release of runtime version 9160 will be an important milestone for staking as it fully enables the bags-list pallet. It was also mentioned that as soon as this is enacted, governance can both increase the maximum nominator count, and reduce the minimum nominator bond. Unfortunately, due to a technical bug found in the enactment of 9160 on Kusama, this release was canceled on Polkadot. This delayed the staking teams plans, and in the meantime the number of nominator slots (22500 as of now) became full again. To temporarily resolve this, the council proposed to increase the minimum bond of nominators to 160 DOT, allowing some to be chilled.
At the time of writing 9170 is almost enacted in Polkadot, marking the beginning of the end for the aforementioned configuration parameters. As soon as this runtime is enacted and testing indicates that everything is sound, it will be recommended to proceed with increasing the maximum nominator intentions, and reducing the minimum nomination intention bond.
Upcoming Proposals
In preparation for scaling the staking system, it is expected that there will be a consistent stream of proposals that aim at altering the staking parameters. This document is a draft of some of the upcoming ones, and the corresponding Polkassembly posts for discussions can be found here and here.
TL;DR:
- Both networks are suggested to start adopting a minimum stake for validators.
- Kusama’s nominator snapshot size needs to be reduced, since it supports up to 24 nominations per nominator, or the “24 nominations” need to be reduced back to 16.
- Both networks can and should relax the limits on the count of nominator intentions.
Minimum commission in Kusama: passed ✅
A proposal to introduce a minimum commission for validators has passed on Kusama, and will be enacted at block #11,707,200. Interestingly, runtime 9170 has already been enacted in Kusama and this runtime version contains a permissionless transaction that can enforce the minimum commission against a validator.
Other notable developments
Amid the proposals, maintenance, and the ongoing discussion in the staking world, the staking team also kept pushing forward in the technical side of things; below are a few noteworthy PRs for technical readers
- Soon, validator self-votes will be treated 100% equal to a normal nomination. For context, while each nominator gets 16 votes, each validator automatically casts one self vote with their self stake. Prior to this PR every validators self vote was included, and the remaining space for voters was filled with the highest staked nominators. Now the self vote of validators will be included only if it's as large as the highest staked nominators. This will be the final patch to make sure the “Phantom Nominator” issue (explained in depth in last month’s report) does not happen again.
- As a follow up to the aforementioned proposals to introduce minimum self-stake for validators, the staking team is planning on deploying a new instance of the bags-list for validators candidates as well. This means that the validator candidates will have the same dynamic as with the nominators: They compete over a slot to be included in the election snapshot based on their self-stake, and an instance of the bags-list will provide this functionality.
- A community contributor has made a valuable PR to make the election process slightly more lenient, for the case where there are not enough candidates. This should greatly help the Substrate based test-nets to not get trapped into the scenario of a failed election.
- Another community contributor has made a PR to simplify the process of updating the staking parameters. Governance of the chains will appreciate this one!
- An optimization to unlocking chunks will merge all the `unbond` calls that are made within one era, meaning that users can create more unlocking chunks in total and have a generally better UX when unbonding!
- Nomination pools are still in progress here. For a high level overview see the “Upcoming: Nomination Pools” section in the previous update.
On the Polkadot JS apps side, we still have some open issues, and we are looking into different options to make sure the bags-list and nomination-pool pallet will have some basic UI functionality in the apps. If you are a frontend developer who’s interested in contributing, and are somewhat familiar with the Polkadot JS API and apps, definitely reach out to us!
P.S. For those who want to follow the development closely, there is a project in Substrate’s github about all the “NPoS and Election” related work 😉.
Staking Terminology
The Staking system of Polkadot is changing, and changing fast. In this section, we formalize some of the most commonly used terminology in the staking system, hoping it will help foster richer ground for communication.
The staking election system has 3 stages for both validators and nominators, namely "intention", "electable/electing", and "active".
- intention to validate: an account that has stated the intention to validate; also called simply a "validator".
- electable validator: a validator who is selected to be a part of the input to the NPoS election algorithm. Once #10944 is introduced, this selection will be done by taking the top staked validators. As of now, it includes all intentions.
- active validator: a validator who came out of the NPoS election algorithm as a winner, consequently earning rewards, and being exposed to slashing.
- intention to nominate: an account that has stated the intention to nominate; also called simply a "nominator".
- electing nominator: a nominator who is selected to be a part of the input to the NPoS election algorithm. In both Polkadot and Kusama, this selection is based on stake, and is done using the bags-list pallet.
- active nominator: a nominator who came out of the NPoS election algorithm backing an active validator, sharing their rewards and slashes. Unless voting for all non-elected-validators, all electing nominators become active as well.
Thus, for nominator counters, we have:
1. count of nominator intentions, and max possible nominator intentions.
2. count of electing nominators, and maximum possible electing nominators.
3. count of active nominators, and maximum possible active nominators.
For nominator stake, we have:
1. min-intention-threshold: minimum stake to declare the intention to nominate. This is a strict threshold decided by the chain protocol.
2. min-electing: minimum stake among the electing nominators. Since this is almost always the same as “min-active”, it might not be reported.
3. min-active: minimum stake among the active nominators.
Similarly, for validator counters we have:
1. count of validator intentions, and max possible validator intentions.
2. count of electable validators, and max possible electable validators.
3. count of active validators, and max possible active validators.
For validator stake, we have:
1. min-intention-threshold: minimum (self) stake to declare intention.
2. min-electable: minimum (self) stake among the electable validators.
3. min-active: minimum (total) stake among the active validators.
A few FAQs could be as follows:
- What would be the minimum amount a nominator needs to be rewarded, assuming they are not backing oversubscribed validators? “min-electing”, which as noted is almost always the same as “min-active”.
- What would be the minimum amount a nominator needs to have an influence on the election of validators? “min-electing”.
- What would be the self-stake needed for a validator, in order to have a chance at being active? “min-electable”.
- What would be the total-stake needed for a validator, in order to be in the active set and earn rewards? “min-active”.
NOTE: a validator has two types of stake: self stake and total stake. In the intention and electable stages, their total stake is unknown. But in the active stage, the total stake and self stake is known. By default, we mean self stake in the first two stages, and total stake in the stage.
NOTE: The set of electing nominators is in fact the combination of all nominators and all validators as well, each acting as a nominator that only nominates for themselves (aka. self-stake). As of now, this set is created first from validators, and then nominators are appended. Soon, it will change to be sorted based on stake all the way through (see #10821).
NOTE: in some places in the code (particularly, in Substrate, which is independent of Polkadot), based on abstraction, we also refer to Nominators as “Voters”, and Validators as “Targets”. While this slightly adds more complexity to the terminology, it is necessary since the terms Nominator and Validators are specific to Polkadot, and to the staking system, while in principle a Substrate-based chain might want to refer to them as something else. Moreover, a lot of the election code in substrate is generic over its use case, meaning that it can elect validators, or anything else. Therefore, the more generic terms “Target” and “Voter” have been used.
By The Numbers.
With these definition, the Polkadot metrics are as follows:
Nominators
Stake
Count
Minimum
Current
Max
intention
160 DOT
20981
22500
electing
124.64 DOT
22049
22500
active
124.19 DOT
20061
22500
Validators
Stake
Count
Minimum
Current
Max
intention
0
1076
1200
electable
0
1076
1200
active
1.78 MDOT
297
297
And for Kusama:
Nominators
Stake
Count
Minimum
Current
Max
intention
100 mKSM
7236
20000
electing
630 µKSM
7073
22500
active
1 pKSM
7449
22500
Validators
Stake
Count
Minimum
Current
Max
intention
0
2120
4000
electable
0
2120
4000
active
4.12 KKSM
1000
1000
As usual, every nominator in both Polkadot and Kusama has been rebagged by Parity Staking Miner, ensuring every nominator is located in the correct bag. Moreover, 2,000 chill_other calls were performed on Polkadot across here, here, here, and here.
