Consolidate Nominator Support in Slashing and Rewards

[kianenigma]

Currently, staking is keeping two storage items:

https://github.com/paritytech/substrate/blob/b0eefebc2a85fe18b5bf072910ad8c4c614548e4/frame/staking/src/lib.rs#L1078-L1101

Where the latter is basically equal to the former, but the exposure.others has been clipped to 64. ErasStakers is used for slashing (and generally all purposes), and ErasStakersClipped is only kept around for rewarding.

https://github.com/paritytech/substrate/blob/b0eefebc2a85fe18b5bf072910ad8c4c614548e4/frame/staking/src/lib.rs#L2883-L2894

This is bad because as a nominator you will only get a slice of the reward if you are among the top 64, but you will get slashed pro rata anyhow.

Instead, we should only keep ErasStakersClipped around. Basically, each validator will only be backed by its top 64 supporters. If a validator is not among the top 64, then there is really no point in being exposed to slashing with no chance of being rewarded.

The trend of this change will be toward making participation in staking potentially limited in the future. At some point, we might have too many nominators and too few validators to be able to accompany all of them. In this case we should observe the formation of services from the community for nomination delegation (if that makes any sense -- or nomination pool), where few nominators gather to make their aggregate stake higher, enabling them to make it to the top 64.

@thiolliere we can work on this cooperatively.

[xlc]

We would love to see some nomination pool support from Substrate side, that will greatly simplify Acala staking liquidity protocol implementation, which is basically a cross-chain nomination pool.

[kianenigma]

Correction from @rphmeier: We use session::historical for slashing.

Based on this, I really can't find any reason why we should keep both ErasStakers and ErasStakersClipped for the entire last HISTORY_DEPTH. Even if we don't want to have the improvement that I suggested in this issue, we should store ErasStakersClipped for the last HISTORY_DEPTH eras ErasStakers only for the current/active era.

A scan of the usages of eras_stakers(* and ErasStakers<T>:: confirms that we are not using this double map with any other era other than the active/current era.

[gui1117]

indeed I see multiple possibilities:

• currently staking needs to hold ErasStakers only for [active_era, current_era], we could delete the ErasStaker of an era when the era is not active anymore, in end_session.

• we could factorize to only make use of ErasStakersClipped everywhere:

  • first runtime upgrade: write into ErasStakers the ErasStakersClipped
  • second runtime update (after historical_depth sessions): make use of ErasStakersClipped everywhere and deleted ErasStakers.

• (also good improvement) we could enforce the limit on the number of nominator per validator when accepting phragmen solutions, this would make the accepted solution score more sensible I think. (the clipping would be done offchain and the score would be taking into account this clipped nominations)

If web3F is ok to use the clipped exposure for slashing (even though the phragmen solution have score computed using full exposure) I can implement the second proposal.

[kianenigma]

If web3F is ok to use the clipped exposure for slashing (even though the phragmen solution have score computed using full exposure) I can implement the second proposal.

As mentioned in the comment above, slashing happens only with session::historical, so it is good.

Regarding your approach: We do we need two runtime migrations? AFAIK ErasStakersClipped is exactly the same as ErasStakers except for clipping 64 nominators, so with just one upgrade and PR we can:

• Remove all usage of ErasStakers and replace it with ErasStakersClipped
• Remove everything in ErasStakers.

[kianenigma]

(also good improvement) we could enforce the limit on the number of nominator per validator when accepting phragmen solutions, this would make the accepted solution score more sensible I think. (the clipping would be done offchain and the score would be taking into account this clipped nominations)

Yeah good idea. Let's make this a parallel/follow up issue/PR that I can work on.

[kianenigma]

will be closed by paritytech/substrate#11935

[kianenigma]

cc @Ank4n

[Ank4n]

If web3F is ok to use the clipped exposure for slashing (even though the phragmen solution have score computed using full exposure) I can implement the second proposal.

As mentioned in the comment above, slashing happens only with session::historical, so it is good.

Regarding your approach: We do we need two runtime migrations? AFAIK ErasStakersClipped is exactly the same as ErasStakers except for clipping 64 nominators, so with just one upgrade and PR we can:

• Remove all usage of ErasStakers and replace it with ErasStakersClipped
• Remove everything in ErasStakers.

May be the better thing to do would be to implement the multi-block reward payout so we are able to pay all stakers and then get rid of the ErasStakersClipped storage instead.