Celo Discord Validator Digest #16
Decreasing validator rewards, community fund, changing group epoch score calculation, useful info and community updates
One of the troubles we have faced as a validator for Celo is keeping up with all the information that comes up in the Celo's Discord discussions. This is especially true for smaller validators whose portfolios include several networks. To help everyone stay in touch with what is going on the Celo validator scene and contribute to the validator and broader Celo community, we have decided to publish the Celo Discord Validator Digest. Here are the notes for the period of 31 August - 13 September 2020.
Discussions
Decreasing validator rewards
If you wonder why validator reward keep on dropping amid the increasing uptime score, here's the explanation:
@Patrick | Validator.Capital: Our cUSD epoch rewards decreased over the course of this month from $202.01 on 8/1 to $199.99 on 8/31 but our uptime score has increased. Any ideas on why that is?
@zviad | WOTrust | celovote.com: This is because of
rewards multiplier
reason why voter rewards are decreasing is the same as why validator rewards are decreasing too....
Rewards multiplier is what gets readjusted to make sure CELO distribution continues to follow the predefined supply curve.
So since there are too many people actively receiving voter rewards, all rewards are reduced to make sure CELO distribution doesn't happen faster than the predefined schedule.
Even though validator rewards are given in cUSD, reserve must also receive equivalent amount of CELO too for each of those, so essentially it also causes CELO inflation.
...
When cUSD is minted for validator rewards, equivalent amount of CELO (based on current exchange rate) is also put in the reserve.
Community fund
In a previous issue, we mentioned the Community Fund that can be used to finance community initiatives. This topic has seen additional discussion:
@zviad | WOTrust | celovote.com: It's a bit confusing what is the difference right now between this fund and foundation grants. Considering in the end foundation has to approve and vote for any of the projects that would be sponsored by this fund.
Also since we don't know which projects applied or got foundation grants, it can create more confusion too. For example, if https://thecelo.com/ is not receiving any grants from foundation, it would definitely make sense to try to fund it at least on some level using this community fund. On the other hand, if it is already receiving foundation grants then there would be no need to setup this alternative scheme.
@victor | cLabs: At the most basic level, the Community Fund is a is an independent account, controlled entirely by the Governance process. So the intention is for the for the Community Fund to be used entirely at the direction of the majority of CELO holders, whereas the Foundation funds grants out of a pool it controls and may make decisions according to it's own criteria.
It's true that any Governance proposal must be approved by the multisig, but the intention, as I understand it (I don't represent the Foundation), is that while the approval process is controlled by a set of individuals, their responsibility is to act as a layer of defense against any malicious actions or edge conditions there a proposal could be passed without true consensus. (In the long term it's been our intention at cLabs that the approval process should be decentralized) Similarly with the Foundation's voting power, we certainly want to see more transparency with how they will apply their votes, but they have not shown any indication that they might back something the community does not already broadly approve.
That's a good point about the duplicate funding, and you could imagine a number of solutions to coordinate on this. Having more information, published by the Foundation, on the grant applications and their statuses would certainly help.
Changing group epoch score calculation
In the previous two weeks, zviad | WOTrust | celovote.com put forward a proposal to change the way how epoch score is calculated in order to prevent larger groups with many validators from having advantage over smaller validators. The proposal has sparkled some discussions:
@timmoreton | cLabs: This was definitely not a mistake, it was a carefully considered part of the design. Not one I love, but one that is inevitable without Sybil resistance. @asa | cLabs and I considered several metrics here when putting this together initially. The choice of AVG was because it is means validator and groups rewards are invariant regardless of how they arrange themselves into groups, and only depends on their performance.
I.e there is no advantage to be gained by groups splitting themselves into individual units. If we made the change you suggest, the rational behavior for any multi-validator groups would be to split into singletons, and I think that would potentially confuse users and seriously diminish the role of groups in Celo. FWIW I share the sentiment and considered several other ways of disincentivizing forming of larger groups, like a diminishing reward curve, but without Sybil resistance all are problematic. Would love a discussion on this!
@zviad | WOTrust | celovote.com: Yes @timmoreton | cLabs , I wouldn't call this a mistake as in a bug. But I still think there are enough advantages to the minimum version, compared to an average, that it provides more positives, compared to the potential that some groups might decide to break up into smaller groups. I put some comments here: https://github.com/celo-org/celo-proposals/pull/42#discussion_r483778762. But I can provide even more reasons why I think worrying that big groups will start splitting up because of this change is very unlikely. Reasons why single identity wont just split into smaller groups:
Reputation risk (if they depend on others to vote for them).
2x more locked CELO for 6 months
Much harder to manage votes (again, if they depend on others to vote for them)
Not really all that much upside or difference in returns (especially if they don't depend on others to vote for them)
Also one more thing, even today there is already a big incentive to split up groups into smaller ones, because when slashing event occurs, group gets slashed too for a month. So it is already better to run separate small groups vs one big one. But no one is really doing that (although slashing isn't working yet, but still).
@Patrick | Validator.Capital: I know the focus of this proposal is on groups that have multiple validators elected, where one goes down for a significant amount of time. How would this proposal impact a group that spins up a new validator starting with a 0 uptime score?
@zviad | WOTrust | celovote.com: It is in the comments on the pull request. Group epoch score doesn't use cumulative validator scores, it only depends on validator scores for that single epoch.
The cumulative uptime score isn't relevant for group score calculation, so it doesn't matter if validators are new or old.
@timmoreton | cLabs: ...
Reputation risk (if they depend on others to vote for them).
I believe most of the whales don't depend much on others to vote for them, so the reputation risk is not a factor.
2x more locked CELO for 6 months
The amount of LockedGold is the same in whichever arrangement (since the amount you need to lock at a group scales with the number of members).
Much harder to manage votes (again, if they depend on others to vote for them)
as above, not much of a consideration
Not really all that much upside or difference in returns (especially if they don't depend on others to vote for them)
If the rewards from their own voting funds would suffer if any of their validators went down (the whole point of this proposal) they would have a financial incentive to form singleton groups.
I am definitely interested in exploring ways we can further incentivize voting to support decentralization and broader participation of more validators. In general, whales can organize themselves exactly how n small validators would, and it's very hard to build a mechanism that gets round that.
Leveraging Foundation voting is a good avenue - since the foundation votes are a form of KYC. You can imagine a number of things that could be tied to the "identity" aspect of being a foundation vote recipient.
Useful info
Some news regarding DB corruption and zero downtime restarts from timmoreton | cLabs:
I think we nailed those DB corruption issues - one of our own making, one from upstream. They'll be in the next point release. Also @Joshua | cLabs has been working on zero downtime validator restarts.
If your attestation service have faced issues delivering messages to certain geos, timmoreton | cLabs is collecting feedback:
I just started this spreadsheet to track delivery failures/warnings to geos. If you could add lines to this sheet (no phone numbers or personally identifiable info please!!) that would be really helpful: https://docs.google.com/spreadsheets/d/1j0c6IPEUstm_H6n3NQGxcj1Ymcz70F5K2fQM-2qysQk/edit#gid=0
@aslawson | cLabs has also been investigating additional SMS providers for geos where we're getting poor results with Twilio and Nexmo. However we want to keep the burden on validators as low as possible in terms of sign up, etc. More updates next week.
Our goal with all our testing (and with collating any failures you see) is creating a recommended config where we can prioritize providers for different geos based on their success rate.
Community
A new Celo validator roundup from zviad | WOTrust | celovote.com: https://wotrust.substack.com/p/celo-validator-roundup-august-2020
Felix | chorus.one presented beta release of chorus.one Ledger integration for Celo voting (/staking) on staking platform Anthem:
Feel free to try out by visiting https://anthem.chorus.one/ and connecting your Ledger device with the Celo app. We are currently tweaking some of UI elements, but all transaction flows from locking to voting to activating votes are supported! Please feel free to reach out to me in case you have any feedback.
Like what we do? Support our validator group by voting for it!