Change group epoch score calculation

Copying proposal in forum too, for wider reach and discussion.

Overview from the pull request:

Currently group epoch score is calculated as an average score of its members epoch score for voter rewards. Because of this, larger groups with more validators in them have a distinct advantage for voters since their average score per epoch is likely going to be higher since they are able to average out individual bad validator scores with better performing validators.

This seems counter productive since for network health it would be better to incentivize voters to vote for smaller groups for more decentralization. Fix for this can be very simple, we change group epoch score to be:

  • Minimum(member validator epoch scores), instead of Avg(member validator epoch scores).

Calculating score per epoch using minimum incetinvizes voting for smaller groups since they are more likely to maintain better epoch scores, and it also puts more pressure on larger groups to make sure all their validators maintain high uptime.

This is a pretty simple change, and it only needs to be changed in one place here: calculateGroupEpochScore function in Validators.sol https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Validators.sol#L418

4 Likes

Thank you @thezviad for bringing this up and to @tim and everyone else for contributing to the discussion. It’s an important topic that impacts all Celo validators and token holders.

Reading the discussion, I’d like to call out that the true topic at hand seems to be whether we want singleton groups or not. It appears to me that Zviad and co think they are inevitable so we might as well get there sooner, while Tim and co think we should resist them and continue to disincentivize their formation. This issue may be worth discussing at length at some point.

Overall, I appreciate and am supportive of efforts to help smaller validators. They are crucial to decentralization and a strong community. However I believe this proposal does not accomplish that goal and is hurtful to the protocol and the people it is trying to help. My rationale is below:

  • Encouraging and normalizing singleton groups will raise the Elected Minimum Votes and make it more difficult for small validators to get elected.
    • More groups means an increase in the minimum stake required to be in the active set. Currently large validator groups tend to keep their CELO delegated to one group instead of launching an additional group, despite having significantly more locked CELO than needed to have all five validators elected to the active set. If they break up or add additional groups, the minimum stake required will increase.
  • Large groups are experts at running infrastructure so running more groups to avoid punitive measures will not put a dent in their operations.
    • From an operations standpoint, running one group with five validators or five groups with one validator each is not that different. The challenge lies in the validator infrastructure, not the on-chain group identity.
  • Zviad argues the slashing penalty is enough of a reason for group operators to split into singleton groups, but people haven’t done it yet so they won’t do it in the future. I don’t believe this is true. Protocol incentives that encourage specific behaviors are often compounded to produce the desired results. Slashing is relatively rare - you need a very long period of downtime or to join an attack on the network. The most common problem people are dealing with these days is simple downtime, which in its current form is not sufficient to incentivize splitting into singleton groups, but with this proposal it may be worth the trouble.
    • Celo is already extremely punitive towards even the brief periods of downtime. Just being down for a few minutes during maintenance punishes groups harshly. I think we should be talking about how to make it less punitive, not ratchet it up!
  • Using the lowest score is most punitive towards groups most aligned with Celo’s vision - groups that include validators run by multiple different parties. This idea is already seen as a scary proposition with limited adoption because garnering delegation is highly reputation based and it’s hard for a group operator to know for certain how well an external party runs validators. Under the current system, if a validator makes a mistake, all validators in that group and the organization running the group feel the error, but the damage can be limited if the rest continue to do well. With this proposal, all validators in the group will be punished to the level of the lowest common denominator, which is likely to permanently eliminate the possibility of Celo Groups being used for their intended purpose.
  • The proposal works against maintaining a healthy protocol.
    • Take these two scenarios:
  1. Group A with 5 validators has one validator go down to a score of 50% while the others are fully operational at 100%
  2. Group B with 5 validators has all validators go down to 55%

Which group was more harmful to the protocol? I would argue it is undeniably Group B, but under the proposal, they will receive more rewards than Group A! This proposal flips the incentive model on its head because if you’re in a group with an already low score from a single validator, you are incentivized to not take as good care of the other validators since their scores don’t matter anyway (barring of course that they go even lower than the first validator).

  • Delegators are capable of splitting their stake among many validators.
    • On protocols like Cardano, Kusama, and Polkadot, single entities run 20+ validators / pools and their delegators split their stake among those validators.
    • This method is not always perfectly even, but it gets the job done, and will continue to get easier as more CELO is staked, lowering the variability in the Elected Minimum Votes.
  • Reputational risk is a concern until it isn’t.
    • Only two or three groups need to switch to the singleton model for the community to follow suit or risk being uncompetitive. Once it is common practice, it will no longer come with the risk of reputational damage.
1 Like

First, I think it is clear we have to table this discussion until we have some form of lightweight “signaling” method to poll for this type of changes. We won’t be able to come to 100% consensus on proposals like this and using current governance proposal method for this would be an overkill. Current governance proposal also can’t actually enact this change anyways, since change would need to be done as a full on core contract upgrade.

i will pick on the arguments though just to provide my view point:

  • “Encouraging and normalizing singleton groups will raise the Elected Minimum Votes and make it more difficult for small validators to get elected .”

i don’t think this is actually the case. having larger groups makes votes more efficient, which actually makes minimum threshold higher. having more groups will actually make threshold smaller because there will be a lot more “wasted” votes due to more inefficient allocation. This is why in TCSGO everyone ended up in alliances to create larger groups, because larger groups are more efficient and actually increase the election minimum.

  • " The proposal works against maintaining a healthy protocol"
    I disagree with this too. i will give you a different example instead:
  • Group A with 5 validators has one validator go down to a score of 50%.
  • Group B with 1 validator has one validator go down to a score of 90%.

Right now, from voter rewards perspective, those two will have the same result (i.e. you would receive same rewards if you voted for A or voted for B). Where clearly Group A-s validator did much more damage to the ecosystem. This is what this whole proposal is trying to fix.


Also I think the key point that is getting missed here is that this change won’t affect validator epoch rewards (i.e. rewards that are paid out in cUSD). And this will affect voter rewards in pretty small way too, because the score there isn’t cumulative. Hence why no large self-funded group will be rushing to work around this issue. For large self-funded groups, this change makes no real difference.

This change makes difference only for groups that need to gather votes from other people. Even there, the actual difference between rewards will be very marginal, but it can help smaller groups when people look at “voter rewards” rankings and things like that to choose what is the best group to vote for.