Staking Update: September 2021

2021-09-30 in  Staking Updates
Avatar by Polkadot

By Kian Paimani, Parity Technologies


This month’s main focus was the completion and merge of the semi-sorted-list (aka. bags-list) pull request. We already mentioned this in the August update. As noted, this will allow any restrictions on the `nominate` transaction to be removed again, and allow many more nominators to set their *intention* to nominate, and leave it to the sorted list to determine the top 22500 (or whatever the limit may be). This sorting functionality is extremely important for the long-term future of the staking/election system.

To achieve an ordered list of nominators within the constraints of the relay chain runtime, we employ a “bags-list”. The bags list has two primary components, bags and nodes. The list is composed of bags that each describe a range of active bonded funds (e.g. the 1st bag will have nominators with 0 → 10 DOT, 2nd bag 11 → 20 DOT, etc). In each bag is a list of nodes that correspond to a nominator and their staked funds. With our previous example, a nominator with 14 staked would be in the 2nd bag. Within the context of a single bag, nodes are not sorted by their stake, but instead appear in insertion order. In other words, the mostly recently inserted node will be the last node in the bag, regardless of stake. Continue reading to see the rationale, design details and how to use the system.

Bags-List In Depth

While the system tries its best to ensure nominators are always represented in the correct bag, certain changes in bonded funds (e.g. a slash in the negative direction, or rewards in the positive direction) can cause an account to be in the wrong bag, and for operational safety reasons the system will not automatically self-adjust
To correct such circumstances, and maintain the sort property, the bags-list pallet comes with an important permissionless extrinsic: `rebag`. This allows anyone to specify another account that is in the wrong bag (for whatever reason that may be), and place it in the correct one. With this property, we expect the bags-list pallet to be self-maintaining, with minimal effort from the blockchain, making it extremely scalable.

With this bags-list in place, whenever the time for an election comes, the bags are iterated from the most staked to the least staked. This could leave the last touched bag to only be partially iterated. This means that in some edge cases, the order of members within a bag is also important. Recall that within each bag, the iteration order is simply the insertion order.

Next to the ability to move yourself from one bag to another, any account can also move itself within a bag. Of course, this is only allowed when an account A has more stake than B, but it is placed after B in the bag (most likely because it joined later). Then, A has the right to move itself to the spot before B, via a transaction. This can only be helpful to nominators of the last iterated bag (such as in the figure above), and give them a better chance at being included in the election process. This work is in progress, more updates about it in the next issues of this monthly update.

The 9.10 release was recently made, and it did not contain any of the bags-list related code. 9.11 should contain the enablement of the bags-list code on Kusama and Westend. That being said, we propose to first deploy this pallet in a fail-safe mode. In essence, the pallet is deployed and kept up to date, but its output data is not used. While this phase is enabled, we still recommend keeping the number of nominators bound to a safe value, like 22,500. Once the network is comfortable with the system, the next upgrade should flip the switch for the full enablement of the bags-list pallet, potentially upon 9.12 release. Subsequently, the limit on the number of nominators can be waived in Kusama (and Westend). Then, the same process can repeat on Polkadot.

Aside from this aforementioned PR, In the coming month, most efforts will be focused on testing and overseeing the deployment of the bags-list, making sure that everything goes smoothly, while concurrently working towards the overall goal of multi-block elections.

By The Numbers

At the time of writing, Polkadot has just shy of 22100 nominators, and the minimum nominating threshold is set to 120 DOT. A number of nominators are vulnerable to being chilled, which might happen when the 22500 limit is reached. Kusama, in the meantime, has been steadily below 7000 nominators and continues to be so.

Last month’s average of the minimum amount needed to be a validator in Polkadot is 1.7914 MDOT, and the total amount staked is 684.8421 MDOT (staking rate 68%). The same metrics for Kusama has been 4.2844 kKSM and 5.3596 MKSM respectively, over the last month.

Related articles
Gov2: Polkadot’s Next Generation of Decentralised Governance

Read the proposal for Polkadot's next-generation governance system - currently known as Gov2 - to discover how it aims to advance the decentralization of the network....

Introducing the Polkadot Staking Dashboard: The Easiest Way to Nominate and Stake Your DOT

Staking your DOT just got a whole lot easier with Polkadot’s new staking dashboard, a user-friendly interface for staking natively on Polkadot....

XCMv2 Audit Completed by Quarkslab

XCMv2 has now been audited for a second time to discover any potential cross-chain security or fairness issues, including logical bugs, denial-of-service, and incorrect lock/unlock or burn/mint on both chains...

Subscribe to the newsletter to hear about updates and events.