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.

[0xthreebody]

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.

[burdges]

We must remember that rewards, staking, and nomination exist to serve network security, not to create an investment opportunity. In this, nomination informs the network about validator security, but nomination cannot achieve this if it focuses on rewards and not on risks.

We'd remove nominator rewards outright, meaning enforced 100% commission, if we thought the community would still nominate without them, perhaps by making nominators non-slashable and requiring a high slashable self-stake by validators.

In fact, we should actually consider doing exactly the opposite: We permit validators to change their commission not just at era boundaries but retroactively during the era, with the change applying to the whole era. We further include in the nomination signatures a statement that the signing nominator promises not to pursue legal damages against the validator operator for changing their commission.

In this way, there would be few mechanisms except trust in the validator operators' character by which a nominator could enforce that the commission does not change. As the network, we care largely about the nominators' trust in the validator operators' character.

We also care about validators being hacked of course, so additionally we permit the validator operator to retroactively change their rewards key, so any hackers could so easily make off with the rewards for one era that doing worse attacks aganist the network or profiting from slashing becomes a lesser concern. I'll caution this part becomes technically messy, but for talking purposes.

[gui1117]

In fact, we should actually consider doing exactly the opposite: We permit validators to change their commission not just at era boundaries but retroactively during the era, with the change applying to the whole era.

In the code this is very easy to do, we currently store the validator commission for all eras, so that when someone claims his reward for an era it uses the commission set for this era. But we can simply use the latest validator commission instead. So the commission for all unclaimed reward can be changed whenever validator wants.

[jonasW3F]

In fact, we should actually consider doing exactly the opposite: We permit validators to change their commission not just at era boundaries but retroactively during the era, with the change applying to the whole era.

In the code this is very easy to do, we currently store the validator commission for all eras, so that when someone claims his reward for an era it uses the commission set for this era. But we can simply use the latest validator commission instead. So the commission for all unclaimed reward can be changed whenever validator wants.

this would further increase the importance for nominators that their validator's frequently pay out.

[burdges]

We could artificially restrict payout frequency if we're worried about extra traffic there.

It's plausible that only using the latest commission creates a minor headache for validator operators since they must announce their change plans, an d then change at the an era beginning. That's not all bad since it punishes nominators who really know nothing about their validator operator. It's an avoidable headache for the validator operator though.

We could've a previous commission and a future commission with the future commission overwriting the previous current one at epoch end if its enactment date is the current era, and the current era using the previous commission if the future one is still in the future or unset.

[burdges]

There are seemingly other annoyances with increasing validators ability to change commission after the fact, which makes my plan work less well.

We're presumably fine with some lag time for commission changes, like currently exists. We could make this lag time larger, but really nominator should trust their validators so I do not see any reason to do so.

I'd vote to close this issue I guess. We of course need an ongoing discussion about how to best explain to validators that staking is not like an investment and the really do need to know the validators they nominate.

[burdges]

Around these topics, we should probably give validators a mechanism to identify nominators to whom they do not charge any commission. In this way, small groups could pool resources to run a validator without charging themselves commission, while still charging any strangers commission. Although meant to benefit small groups, we should verify that this does not benefit whales too much, well clearly the whales can exploit it in interesting ways.

[SimonKraus]

Comment to raise awareness! This should really be a high priority feature and not chilling for 6 months.

[gui1117]

https://github.com/paritytech/polkadot-sdk/issues/472

We're presumably fine with some lag time for commission changes, like currently exists. We could make this lag time larger, but really nominator should trust their validators so I do not see any reason to do so.

I'd vote to close this issue I guess. We of course need an ongoing discussion about how to best explain to validators that staking is not like an investment and the really do need to know the validators they nominate.

[kianenigma]

Unfortunately many people (mostly outside this thread) see nomination like an ETF investment that you set it once and the chain is responsible to protect you, and adjust accordingly, and you have little to no liability, which is exactly not the case and as a nominator you are expected to check who you are backing.

Indeed, substrate might decide to actually implement this feature someday, for the sake of other builders and chains, but in the context of polkadot's nomination, I don't think we'll see this anytime soon.

[burdges]

We should improve the UI to give nominator easier access to the data about the validators they nominate, like currently you cannot just click through to get their commission history, but must copy the validators' public key from one screen to another.

We should ideally give validators a mechanism to make announcements to their nominators too, probably off-chain. At least this way validators can announce that they plan to change their commission in a week, plan to attend some meetup, etc.

[laboon]

@burdges Actually Polkadot-JS does allow you to click through to see their commission history. Click on the little "graph" icon and it's in the bottom-right corner.

[burdges]

Only once you find your nominee on the big list, but you cannot restrict that list to "my nominees". It's easier to cut and paste the keys to the url where those graphs appear.

[jak-pan]

Unfortunately many people (mostly outside this thread) see nomination like an ETF investment that you set it once and the chain is responsible to protect you, and adjust accordingly, and you have little to no liability, which is exactly not the case and as a nominator you are expected to check who you are backing.

Indeed, substrate might decide to actually implement this feature someday, for the sake of other builders and chains, but in the context of polkadot's nomination, I don't think we'll see this anytime soon.

I think that in this case, this should probably not be inside the official docs.

https://wiki.polkadot.network/docs/en/maintain-guides-how-to-nominate-polkadot

https://wiki.polkadot.network/docs/en/learn-staking#validators-and-nominators

[apocys]

Is there a real case where a validator has to set 100% for the commissions ? If yes, is it still matching the goal of decentralization and quality ? From a UX perspective, I would propose to allow the nominator to set a max commision there are willing to pay.

[burdges]

The network needs validators to behave somewhat independently in that no more than 1/3rd ever collude, which is what decentralization means.

The network pays nominators to be witnesses to validator operators (a) independence from other validators, (b) character, asserting they would not willingly collude, and (c) competence, in that they are unlikely to be hacked. The network attempts to enforce nominators' being good witnesses by holding nominators responsible for validator missbehavior.

In essence, nominators exist to protect the network from collusion, aka not being decentralized.

Is there a real case where a validator has to set 100% for the commissions ?

It's likely whales trying to kick undesirable nominators did so. I know >5% bumps occur among regular validators.

There are worse things a validator could do to their nominators than raising commission. If you run into a drastic commission increase then unnominate the offender and discuss them in some polkadot/kusama forum. And consider yourself lucky the ofender showed their stripes so harmlessly.

[stale[bot]]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[rphmeier]

Seems like something to keep open.

[Nexus2k]

Other networks have validator dashboards that basically expose/warn from validators with frequently changing comissions. E.g. https://crypto.bzh/rank.php

[wpank]

bump - I think there's some interest from the community in re-visiting this

[kianenigma]

https://github.com/paritytech/substrate/issues/11672#issuecomment-1216235876 Is a good related comment -- I think this is a good way to implement this.

[kianenigma]

Also, we want to allow nominators to optionally set a maximum commission, and if any of their validators go above this limit, they should be automatically removed. We can either do this on_idle, or do it via a permissionless transaction.

This should be a new issue in itself.

[burdges]

We could close this in favor of https://github.com/paritytech/polkadot-sdk/issues/447 I think, as that issue shows consensus moving towards not doing maximum commissions.