Bump Nominator Reward Limits

[kianenigma]

Polkadot is already passed this limit and there are half a dozen or so validators who have already been saturated, causing the reward of at least a few hundred nominators to remain unclaimed. Since this limit was arbitrarily set before benchmarks, now we can increase it.

Will re-benchmark to apply the changes to the staking weights.

Companion for: paritytech/substrate#7007

[shawntabrizi]

I would also suggest we reduce the number of historical eras we keep. Right now, the number is quite large, which imo is not needed given the current mechanisms and incentives.

Originally a long history was important cause nominators had to each individually reward themselves, but now that it happens through validators, this timeline could be short.

We would do this through a Root call (so council/democracy)

[wpank]

I think the current Historical Eras (84) is actually very useful for deriving metrics on performance. I would be in favor of keeping it for now.

[gui1117]

who will decide on this ?
what is the reason for having more nominator per validator in polkadot than kusama, because of the amount of stakers ?

[kianenigma]

what is the reason for having more nominator per validator in polkadot than kusama, because of the amount of stakers ?

Yes, although I am open to other suggestions. The main point for now is to finish paritytech/substrate#7007 sot that we can do it. The value is less relevant to me.

[kianenigma]

also made to be the companion for paritytech/substrate#7007

[kianenigma]

With 64:
Call staking_payout_stakers (with default args) takes 0.017354368 of the block weight
With 256:
Call staking_payout_stakers (with default args) takes 0.069417472 of the block weight

I think 256 is a good number to go for.

---

@jacogr Pinging you to update your 64 as well. Although if it is dynamic, then nothing to do from your side.

[jacogr]

Dynamic based on the constants exposed. However with the weights adjusted would need some tweaks since at the previous there were a max of 40 payout txs in a batch based on tests. So at say 128 it would be (64 / 128) * 40 that can be included in a single batch tx from the UI. (batch is only for a single block)

With weights adjusted will re-calculate that (via testing), but initially it would just adjust as per above, probably fitting in less than the new weights would suggest. (the new "40 number" would need to be determined inside a batch)

[ghost]

Waiting for commit status.

[redzsina]

We are done with our review for this PR and don't see any issues with it.