Consider automatic rebaging when rewards are received or slashes happen

[kianenigma]

Currently, we don't rebag nominators to the correct bag after rewards and slashes.

As of paritytech/substrate#12645, we would have to keep track of validators as well in a bags-list, and they would HAVE TO BE ACCURATE, both for rewards.

Perhaps we should do the same for nominators too.

[kianenigma]

@gpestana this will be closed by the end of having target list fully implemented.

[kianenigma]

@gpestana can you confirm if this is the case?

[gpestana]

Automatically rebaging of nominators can be done by the stake-tracker pallet #1933.

The only downside I see is the extra costs of the score update and potential rebaging of the nominator node for each nominator's stake update. OTOH, it may improve the security as it does not require nominators to explicitly rebag to get the max nominator stake as possible in the snapshot.

I will make sure the rebaging happens for nominators too in stake-tracker and close this issue once #1933 is merged.

Perhaps we should do the same for nominators too.

What are your concerns, if any, of using the stake-tracker to keep the voter list sorted?

[kianenigma]

What are your concerns, if any, of using the stake-tracker to keep the voter list sorted?

My only concern is weight. Given that the stake-trakcer is now recording everything, a potential reward payout can possibly be pretty big. Do you have an estimate of how big the weight of a payout_staker now is, and what percentage of the full block weight will it consume?

[gpestana]

I calculated the overhead of keeping both target and voter lists sorted at payout time and did some back of the envelope calculations wrt to the overhead per operation. The TL;DR; is:

• Keeping the voters list sorted is negligible compared to the overhead of keeping the targets sorted by approval voting (when worst case scenario is considered).
• Maintaining the target list sorted at reward payout is a considerable added overhead compared to the status-quo; However, with the paginated rewards the costs can be spread across multiple blocks.
• Mass slashing events will overload the block.
• In the context of the Staking parachain, the slashing needs to be multi-block and the exposure size page size needs to consider the costs of updating the target and voter lists in the worst case scenario.
• For the worst case scenario (full page of 512 exposures, 16 nominations for all nominators exposed, all approval stake updates require the most expensive rebag), keeping the target list sorted at (paged) payout (512 exposures/page), the ref_time required to update the lists in the worst case is ~250% of Polkadot's max_block.ref_time and proof_size impact is negligible.
  • note, however, that the worst case scenario is very pessimistic; most of the updates should not require a rebag in real-world scenarios; And the avg exposures/validator/era is ~75 in Polkadot (much less than the 512 used in the calculations).

More details here https://hackmd.io/FH8Uhi2aQ5mD0aMm-BbqMQ

[kianenigma]

Thanks for the write-up and calculations, very informative!

A couple of comments:

• How have you calculated the number ~75, and how many exceptions have we had in the past? For example, how often the number of exposures/validator/era significantly higher?
• In general, though, it is (unfortunately) not correct to make a permissionless system based on the "norm". So, if we want to rely on this assumption, we have to answer the following: what is the cost for an attacker to tweak the nominator->validator graph such that every payout is significantly more expensive and slow down the chain? And then we can compare this cost against the added value for the attacker, which is slowing down Polkadot.
• Probably a more worthwhile approach, we need to ensure paged rewards are deployed and being utilized before (or soon after) this is deployed. And, the decision of the reward page size should be such that even the worst of payouts doesn't cause any harm.
• Lastly, this is a good reason to again consider an upper bound on the number of nominators, and double down on pools as the primary primitive for staking.

[gpestana]

How have you calculated the number ~75, and how many exceptions have we had in the past?

This number was obtained in a few recent eras in Polkadot. Not very demonstrative of the worst case scenario.

what is the cost for an attacker to tweak the nominator->validator graph such that every payout is significantly more
expensive and slow down the chain?

I'd expect to be relatively expensive to perform an attack that relies on the voter/target list rebaging due to rewards. The main reason being that the exposed nominators per validator need to be high, which means that the attacker would have to bond multiple nominators. On the other hand, even if it's relatively cheap to perform this attack, there are two factors that help preventing the attack: 1. In general, a reward per era should not be high enough to trigger a voter/target rebagging for each tuple of (validator, nominator) in exposed to an era. moreover, 2) we have ultimate control over the number of exposures per pages, so we can be conservative and make the number of exposures/pages relatively low.

To confirm the assumptions above, I'll improve the estimates and costs to get a better and more realist number of the weight overhead of keeping the target and voter list up to date at rewards/slashing, given diff conditions.

But at this point I'm inclined to say that there is no fundamental problem with keeping target and voter list always sorted, given the paged exposure implementation and the staking <> stake-tracker integration (and an eventual pagination of slashes).