Posting this here for wider visibility.
If you are staking as a nominator on Polkadot, you might have seen a value shown as the minimum DOT you need to stake to earn rewards (~502 DOT currently). If you have staked more than this value, you might assume that you will earn rewards, but this is not the full truth. It might turn out that the validator you are exposed to on a given day (era in relay chain terms) is oversubscribed and any nominator outside of the top 512 nominators by stake would not receive any rewards. You would be understandably pissed off if it happened to you.
The reason for this limitation is, any work chain does in a block needs to be a bounded value and we bound how many payouts we can do while paying out staking rewards to 512 per validator. Any nominator outside this bound is ignored.
We can payout unbounded nominators in bounded chunks (called page) of 512 nominators. For example, if a validator has 1000 nominators, it will have two pages of rewards to payout, first page with 512 nominators and the second page with 488 nominators.
This is what this merged PR does which is now live on Westend and if all goes well, will be released on Kusama and Polkadot in the coming months. This change would also help with our ongoing effort to pagify various parts of validator election process and get the staking system ready for being moved to its own system parachain.
Hopefully not much but you will not have to worry about oversubscription issue once these changes are live. As long as you have more DOTs staked than the minimum needed, you should be good. Otherwise, you can always stake via Nomination Pool.
If you have more than 512 pages, you will need to payout multiple pages. This can be done simply by calling the permissionless extrinsic
payout_stakers in the
Staking module multiple times (once for each page). There is also a new extrinsic
payout_stakers_by_page if for some reason you want to invoke paying out only a specific page (might be useful for nominators if they want to invoke the reward payout and only care about the page they belong in).
The number of pages for an era can be queried by looking at the new storage item ErasStakersOverview. If you use bots to claim payouts, these changes would need to be integrated in the bot expecially if your bot needs to read era exposure which is now in a new storage. These changes are only partially backward compatible as in, the extrinsic
payout_stakers if called once, would continue to payout
page 0. But if you have more than 1 page of nominators, then you might miss out on paying your other nominators.
The old storages for exposure has now been deprecated and stored in new storage keys in a paged manner. We took the decision to lazy migrate the exposure since we save 84 eras of historical exposure and it would not be possible to migrate them in one block.
What this means is, the old storage items will keep all the values, but once paged rewards changes are applied to runtime, any future era exposures will be written in the new storage items.
Following are the storage items that are deprecated along with their corresponding new storage item:
- ErasStakers and ErasStakersClipped will be deprecated. Two new storage item are introduced for storing exposures by era and page, (1) ErasStakersOverview which contains metadata about all the pages (such as total stake and own stake of the validator), and (2) ErasStakersPaged which is very similar to
ErasStakersbut is now a triple key map of era, validator stash and page index.
- Data for eras for which rewards are already claimed was earlier stored as one of the fields in storage Ledger, which is deprecated and a new storage map is introduced ClaimedRewards.
You can find more details in the description of the original PR as well as refer to the changes in the Staking Dashboard PR to integrate with these changes. I am happy to answer any questions or concerns you may have.