Reduce Elected Validator set from 110 to 55

[clemens]

Personally, I think the key question is what the real goal of this proposal is.

1. Just cutting token emissions / save money

→ For me, the most logical answer would be to reduce the rewards for all validators equally.

Technically, this also seems to be a straightforward change:

@marek

This seems even less risky, as we’ve also made this change via governance.

However, combining this with an increase of the validator group size could also push out smaller groups:

@marek

If we were to do this, I would suggest increasing the validator group size to 7 or 10 so the folks that want to stick around, have the option to try to earn more revenue.

2. Reduce elected validator set / keep same validator rewards for remaining groups / save money

@Thylacine

Reduce validator count and/or group count as per this thread

Again technically possible:

@marek

This introduces no extra work, and we’ve changed the count via governance in the past so it seems low risk and thus low effort.

However, this would mean:

• smaller groups will be pushed out
• fewer groups in total

Also if smaller groups are getting pushed out and have no chance of ever getting re-elected, it would only be fair to reduce validator and group de-registration durations at the same time:

@Thylacine

If this goes to vote - could we also bundle in to it a proposal I began last year to reduce the cooldown unlock time for deregistering groups and validators?

3. Reduce validator group size / keep more groups / still cut token emissions and save money

This could be achieved, for example, by:

• Limit each group to 1 validator
• Still reduce the elected validator set to ~55

→ Less total amount of validators = saving money
→ more independent groups are being kept

---

Some other comments:

@thezviad

Imo, it is better to have smaller amount of well paid entities as validators/operators, vs larger amount that are all getting paid way less.

There is definitely a payment threshold after which you are going to lose majority of the qualified operators because it is no longer going to be worth it to stay involved and keep up with the changes, updates and so on.

Larger groups already greatly benefit from economies of scale. Smaller groups, which are often on the edge of being elected or unelected, must still maintain the same reliable and adequate infrastructure. While a group with five validators earns five times the rewards, their operating costs don’t scale linearly. A big cost factor (if not the biggest) is the time of the person or team operating the infrastructure and following the technical developments and operating requirements. These costs barely increase when running additional validator instances.

@marek

I don’t think this would work unless we also want to lower the staking rewards for people who have locked and staked CELO. These rewards are proportional to the validator scores.

As far as I know, the CSMC can set two different scores:

• ValidatorScore (affects the payment of validator rewards)
• GroupScore (I think this affects the staking rewards of group stakers/voters)

In theory, this would allow for lower validator reward payments without affecting staking rewards, if my information is correct.

---

(relevant disclosure: operator of a “small” validator group (atweb3), currently part of the CSMC)

[thezviad]

This is precisely what everyone wants to have clarity on.

If the goal is to go down to 0 in 6months, or even 12months, lets lead with that. Say that the goal is to reduce validator count to 0, and because of implementation difficulties, we will take step by step approach instead of just going to 0 right away.

Being clear what the end goal is, will make everything easier to discuss.

Because if the end goal is to have 0 validators, it really doesn’t matter how we cut costs right now. It can be either reducing the validator count or reducing the rewards. Then none of it matters all that much since it will all be short term anyways.

[alex_Verda]

@thezviad

If the goal is to go down to 0 in 6months, or even 12months, lets lead with that. Say that the goal is to reduce validator count to 0, and because of implementation difficulties, we will take step by step approach instead of just going to 0 right away.

My original target when I first posted was indeed to go to 55, hence the original title. After receiving feedback that going to 55 is “arbitrary” and, ‘if our goal is to cut costs, let’s go all the way as well’ (example: Reduce Elected Validator set from 110 to 55 - #12 by Thylacine ), I suggested a revision (see here: Reduce Elected Validator set from 110 to 55 - #29 by alex_Verda). To account for cLabs audit requirements and engineering time (see Marek’s comments above) as well as mitigate potential unforeseen risks from reducing/eliminating the validator set, suggested a phased approach of first 55 and then 0 (after 3 months).

[alex_Verda]

@thezviad

If the goal is to go down to 0 in 6months, or even 12months, lets lead with that. Say that the goal is to reduce validator count to 0, and because of implementation difficulties, we will take step by step approach instead of just going to 0 right away.

My original target when I first posted was indeed to go to 55, hence the original title. After receiving feedback that going to 55 is “arbitrary” and, ‘if our goal is to cut costs, let’s go all the way as well’ (example: Reduce Elected Validator set from 110 to 55 - #12 by Thylacine ), I suggested a revision (see here: Reduce Elected Validator set from 110 to 55 - #29 by alex_Verda ). To account for cLabs audit requirements and engineering time (see Marek’s comments above) as well as mitigate potential unforeseen risks from reducing/eliminating the validator set, suggested a phased approach of first 55 and then 0 (after 3 months).

@clemens

the most logical answer would be to reduce the rewards for all validators equally.

The feedback I received is that current revenue already isn’t super high and reducing it further would be insufficient incentive to run a validator and disproportionately unfairly affect single-validator groups.

Should I maybe use a Google Doc to take a poll? I guess it could be gamed where one person makes multiple votes and wouldn’t take account of people voting CELO amount, but maybe it would be incrementally better quantitative evidence of where the broader community is landing? I’m open to suggestions.

[aaronmgdr]

Im not sure i understand how “staking” would work if we went to zero “validators”.

For users would locking celo only before voting in governance and have no election or ‘yield’ component?

For this reason id say we should keep some number. Or come up with some well though our alternative to why someone would want to lock celo.

[marek]

I huddled with the cLabs team and I think you’re right. We can keep the current smart contracts, the current UI, and keep stCELO unchanged if we both changed the targetValidatorEpochPayment parameter without touching the targetVotingYieldParams, and if the CSMS continues to set the GroupScore as you described.

We will do some testing today and tomorrow to confirm that this would be feasible.

[alex_Verda]

Quick update following 12/18 Governance Call:

I’m asking Martin Volpe if it’s possible to provide 3 options for people to vote on (apparently it’s not something that has been done before). Synthesizing suggestions from the call (+above) and given this proposal would affect a lot of people, it seems worth giving an option:

1. Reduce the set by half

2. Reduce rewards by half

3. Keep the current set, with rewards reduced to zero (economically equivalent to reducing validator set to 0). Note, this wouldn’t require a huge heads up time for cLabs like reducing the validator set to 0 would.

From my perspective, they all reduce costs (target outcome), but I’m trying to incorporate folks feedback to be “smart” about how we best do it.

[alex_Verda]

Created a new post to cover all three proposals, so folks not too bogged down with comments (but provided a link in the new post for those that want to dig in to all the comments).