Substrate: Restrict validator change commission

[xlc]

Currently validators can change commission without restrictions, so it is not uncommon to see some validators starts with 0% commissions and bump it to like 100%.

This hurts nominators as well as small validators.

Validators should be able to make enforceable promise to cap their max commission or someway to limit their own ability to change commission.

This will help nominators to evaluate on the commission part of the validators.

[jiangfuyao]

Yes, many nominators have not looked at it for a long time, and come back to find that the nominated validator has been set to 100% commission.
When declares to become a validator, it should set its own maximum commission.

[wpank]

I think what might be nice here is to have a MaxCommissionChange parameter, which is the max amount of commission change a validator can increase or decrease per era (or maybe 28 days). For example if the Validators commission is 10% and they set a MaxCommissiojlnChange to 5%, they can only change it to up to 15% in the next era, and 20% in the era following that.

Trustworthy Validators should set this number to be quite low so that nominators know that they have a stable operation.

[kianenigma]

I will not object against this and all both @xlc and @wpank's ideas are good.

But end of the day, such issues will always exist. Only permanent way to solve this is to incentivise people to check on their accounts frequent enough.

I bet if we restrict this too much in favour of nominators (i.e. un-nominate if your validator bumps to 100%) then we will piss of some validators and then they will open an issue requesting the opposite :P

[staking4all]

The maximum commission changed that @wpank mentioned is the way. Most chains allow validators to stipulate this as part of their validator.

Should also show on staking board so users aware max change per validator.

[rphmeier]

MaxCommissionChange is nice conceptually. It does imply that we'd have to iterate through all nominators and remove that validator from their preferences. That would increase the weight of the call for validators to update their preferences to be very expensive

Alternatively, we might want the nominators to issue nominations as (Validator, VotePrefs) pairs where VotePrefs contains fields such as MaxCommission. We could also take the opportunity to allow nominators to express slashing preferences in VotePrefs as well.

I imagine this is lighter on-chain because it means that all the computation is back-loaded to the points where we have to iterate over all nominators and their votes anyway. Updating your ValidatorPrefs to change commission is basically free but will lose you your nominators.

@kianenigma Would this complicate the off-chain solution generator or the on-chain checking process substantially?

[kianenigma]

Neither of these really affect the offchain computation, thus safe with that regard. Only concern, as you pointed out, is iterating over all nominators.

---

MaxCommissionChange is nice conceptually. It does imply that we'd have to iterate through all nominators and remove that validator from their preferences.

Does it though? If I have understood @wpank's idea correctly, it implies that if a validator changes the commission by c and c < MaxCommissionChange, nothing happens, and we forbid c >= MaxCommissionChange.

updating MaxCommissionChange itself and should and must cause an immediate removal of all nominators. But I think a sane and trustworthy validator would barely call this and prefers sticking to their initial limit.

Alternatively, we might want the nominators to issue nominations as (Validator, VotePrefs) pairs where VotePrefs contains fields such as MaxCommission

I think having a _per-nominator_-config is inevitably more complicated, not to mention eating more space. Until we limit the number of nominators to a fixed and relatively small amount (and introduce _DNPoS_ or something of that sort), this will not be feasible in my opinion.

Therefore, I think having a single config to limit the commission change _per-validator_ is a more reasonable approach for now. It almost incurs no crazy heavy computations on-chain, the validators can still climb to 100% if they want, but potentially slower, nominators can see if their validators plan to climb to the top or not (i.e. if your validator has MaxCommissionChange), and generally have more time to react in case their validator has been snitching more commission.

[kianenigma]

Implementing MaxCommissionChange should be rather easy. The main complication is how to coordinate it. Active validators in networks don't have this value initially. We need to either

1. set some average value for them as the default.
2. allow them to update it, _only once_, without losing their nominators.

(or actually do both).

[wpank]

I should clarify a bit, MaxCommissiomChange is a preference the Validator would set for themselves, such that they cannot change their commission + or - more than that amount per era. So if a validator says their value is 10% and their commission is currently 5%, trying to set a 20% commission the next era will fail.

This would have no effect on Nominators and removing nominations.

For all current Validators, the default value can he 100%, which we then can encourage them to change

[rphmeier]

@wpank Thanks for clarifying. Then is MaxCommisionChange really about how _fast_ the validator can change their commission, not whether the validator can change their commission?

If I have a MaxCommissionChange of 3%, I'll be able to increase my commission from 1% to 100% in 33 eras or ~1 month without losing any nominators. Do I understand you correctly?

[kianenigma]

@rphmeier yes, that sounds about how I also interpreted this. Implementing this would be a good extra feature with minimal complication.

[wpank]

@shawntabrizi actually brought up a good point, in then what checks would then happen when trying to change MaxCommissionChange. A validator could maybe only set MaxCommissionChange once. But that's still not very clean. It seems like there might be a bunch of added complexity around dealing with that.

I think another alternative (which I would be more in support of) is removing all nominations when a validator increases commission (but keeping them if they decrease). This seems much simpler.

[kianenigma]

A validator could maybe only set MaxCommissionChange once. But that's still not very clean. It seems like there might be a bunch of added complexity around dealing with that.

I assumed that if you change MaxCommissionChange, you basically start from scratch, and pay a lot of fee.

It is unclean and unfriendly to the validator, but not complicated IMO.

[shawntabrizi]

I would be interested to simply remove nominators from the validator if the commission is increased.

The MaxComissionChange behavior does not really stop the underlying problem. If a validator has any non-zero MaxComissionChange, then as a nominator, I should assume that validator will trigger that change as often as they can. If nominators are not really responsive or participatory on the chain, then we run into the same issue where the validator takes from the user all their commission, but it just takes a bit longer.

And then the question comes up about how would we treat changes to the MaxComissionChange? Have yet another variable?

I think that changing your commission is ultimately changing your contract with a nominator. If a validator wants to do this, it should not be easy imo. They can instead reach out to all of their nominators on their own, and ask them to re-validate them with the new commission.

As a nominator, I nominate 16 people, and I should already expect some amount of un-nomination due to being offline or potentially for changing commission. It does not feel like it would really hurt underlying nominators.

[kianenigma]

And then the question comes up about how would we treat changes to the MaxComissionChange? Have yet another variable?

In idea, I would keep the nominations if the change is below MaxComissionChange and then any change to MaxComissionChange is an immediate contract change.

---

Hard to see a consensus here. Will probably pursue with a draft PR soon to see the tradeoffs.

[shawntabrizi]

I really dont see the justification to draw the line that a MaxComission change is where we breach contract between validator and nominator versus just the commission itself. It seems that we agree that changes in contract between a validator and a nominator would eventually kick a nominator off from nominating that validator.

Why allow a contract where the nominator wont really know how the validator will adjust and manipulate their commission? Sounds like a pretty weak contract, especially given any long period of time.

If it is sensible for some reason to allow for changing comission, I might suggest that there is instead a global max change percent which is controlled by governance, thus change of this number would _not_ need to kick off nominators, and thus we can achieve a system which avoids this unwanted behavior all together.

[windylion]

Hey all,

So, seems like fundamentally this discussion is about how often do we want nominators to check up on the network. How participatory do we want it to be.

Perhaps when Parachains launch there will be coins minted that are conducive to set-it-and-forget-it. Or when bridges launch people can invest in bitcoin or ethereum which need slower activity at the moment anyway.

But with NPOS like polkadot, I think at least the central relay chain is going to need to have pretty active nominators for it to work. What's a good target? I think 1x week check-in. People can work at jobs during the week, take a breather, etc, and then on weekends get up to speed. Or something like that.

Maybe once the network is more established and validators more proven, check-ins can stretch out a bit more.

But perhaps for now, we design the validator/nominator contract around the one week refresh target. Thoughts?

[wpank]

Just wanted to bump this with the sentiment that removing all nominations when a validator increases commission (but keeping them if they decrease) seems like a practical way forward. I think we should put this in front of the community to get a sense of whether they're for or against this.

[rphmeier]

The best way to do that is still with the VotePrefs change I recommended above.

[rrtti]

A summary of the discussion on Polkadot Direction Channel:

The goal of the implementation is to protect nominators from discretional increase of commissions by validators. The supported implementation seems to be to allow a gradual increase of commission and cap, decided in advance by the tacit agreement between validators and nominators. This would allow a nominator to allow for:

• an N% evolution per Era;
• capped by a max N% overall since the initial nomination.

Two issues arose when discussing this implementation:

1. What happens when nominators nominate in different periods? For example:

   Validator starts at 0%. person A nominates.
   Over time validator goes to 5%. B nominates.
   Validator should be able to go to 10 or 15% if the cap is 10%? It can't be both, and it can't be per nominator.

2. There were also some concerns regarding the increase in storage overhead for the implementation.

After discussion, it was agreed that the VotePrefs solution can accommodate the first concern since we can track the era in which nominations were submitted: It just takes a little extra filtering of nominators at election time. We would also need a MaxCommission pref and a MaxCommissionIncrease: (per_era, n_eras) pref

• Having 2 thresholds (as described above) does not mean all agreements between nominators and validators will use both: A MaxCommission would get us most of the way. e.g. a nominator can choose a validator that has a 7% commission but feels fine with accepting a 10% commission.
• The validators would be able to see on-chain what proportion of their nominators they'd lose by bumping their commission but nominators would be making a choice - tight bounds on MaxCommission might mean taking a more active role in choosing nominations more often. Looser bounds allow less operational overhead.
• All of these options means that ultimately users may lose nominators/validators at seemingly random times, so at the end of the day both validators and nominators should be actively deciding and re-evaluating their choices.
• For all current users the defaults will be set at what they currently are now: if they allow commission changes up to 100% per era, with a cap of 100%. The validator prefs would only get defined when nominators re-do their nominations.