Celo’s Proof of Stake mechanism
How Celo secures its consensus mechanism with incentives for validators, group and voters
In my previous post, I explained how Celo replaces Ethereum’s use of Proof of Work for securely adding transactions to the ledger with a Byzantine Fault Tolerant (BFT) consensus algorithm operated between validators. In this follow-up post, we deep dive into the design of Celo’s Proof of Stake mechanism — how the protocol determines which nodes become validators and how incentives are arranged to secure the network.
Before we get started, you might also be interested in this recording, which covers some of the same material:
Casual full nodes, professional validators
As discussed in my previous post, Celo offers two routes to contributing compute resources. Incentives for full nodes provide a new, ‘casual’ opportunity for individuals in the community to operate a computer that joins the network and earns currency for services it provides. Full nodes do not need to obtain any ‘permission’ in advance, and can join and leave at will.
In contrast, Celo encourages the ‘professionalization’ of validators. Since BFT limits the total number of validators that can exist in the network to a few hundred at most (for now! — see below), each validator may have a significant effect on the performance and security of the network. So the network’s interests are best served by selecting a slow-changing set of well-maintained, secure validators. This means regular security audits, being actively monitored, deploying a set of proxy nodes to mitigate DDoS and attack surface, and using hardware wallets attached to hardware residing in secure co-lo facilities. It also means individuals or organizations with the resources to swap out faulty hardware to maximize availability.
How to facilitate the selection of well-maintained, secure validators yet include every possible user in the process to select them? Celo uses an election mechanism in which holders of the native asset, Celo Gold, are incentivized to vote. But users don’t cast votes for validators directly — instead, they vote for validator groups. A validator group has ‘members’, an ordered list of candidate validators (each of which must have chosen to affiliate itself with that group). The group may add, remove or reorder members at any time. Depending on how many votes a group receives, anywhere from none to all of its members may be elected. Validator groups are compensated by taking a share of validator rewards.
Validator groups can help mitigate the information disparity between voters and validators. We anticipate that groups might emerge that do not necessarily operate validators themselves but attract votes for their reputation for ensuring their associated validators have known real-world identities, have high uptime, are well maintained and regularly audited. Since every validator needs to be accepted by a single group to stand for election, that group will be more able to build up long-term judgements on their validators’ operational practices and security setups than each of the numerous Celo Gold holders that might vote for it would.
Equally, a number of organizations may want to attempt to field multiple validators under their own control, or be able to interchange the specific machines or keys under which they validate in the case of hardware or connectivity failure. By switching out validators in the list, groups can accomplish this without users having to change their votes.
Validator groups can have no more than a small, fixed maximum number of validators. This means an organization wanting to get more validators elected than this maximum has the added challenge of managing multiple group identities and reputations simultaneously. This further promotes decentralization and strengthens operational security, making it more likely that the validator set will be composed of nodes operated in different fashions by independent individuals and organizations.
To participate in validator elections, users must first make a transfer of Celo Gold to a ‘Locked Gold’ smart contract. Locked Gold can also be used as a stake to register a validator or validator group, as described below, and it also permits voting for proposals in Celo’s on-chain governance mechanism.
Optionally, a voting key can be set up to allow the wallet’s private key to be held offline (e.g., at a custody solution) while the voting key is used to continue to participate in governance and validator elections.
A user’s Locked Gold balance corresponds to the number of votes they are able to cast. Why not one user, one vote? In a decentralized system like Celo or Ethereum, there is no way of identifying users, per se, only accounts. By design, anyone can generate any number of new accounts. What they cannot do is generate the native asset. As a result, the only voting mechanism known to be resistant to spoofing attacks is to tally account value, not accounts. Vitalik Buterin has a great blog post on identity and collusion that explores these challenges.
Locking up Celo Gold further guarantees that the same asset is not used more than once in the same vote. However every unit of Locked Gold can be deployed in several ways at once. Using an amount for voting for a validator does not preclude that same amount also being used to vote for a governance proposal, or as a stake at the same time. Users do not need to choose whether to have to move funds from validator elections in order to vote on a governance proposal — more convenient for the user, more secure for the network, and likely to result in higher participation.
As Locked Gold receives rewards for voting for a group that elected validators, it automatically compounds, using the new funds to increase its votes for the same group, thereby increasing future rewards, benefitting participants who have elected to continuously participate in governance.
At any time, after removing all active votes (and deregistering as a validator or validator group if applicable, which carries an additional delay — see below), a user can ‘unlock’ all or a portion of their Locked Gold. Once an unlocking period of 3 days has passed, the user can transfer the amount back to their wallet.
This unlocking period of 3 days balances two concerns. First, it is long enough that an election will have taken place since the request to unlock, so that those units of Celo Gold will no longer have any impact on which validators are managing the network. This deters an attacker from manipulations in the form of borrowing funds to purchase Celo Gold, then using it to elect malicious validators, since they will not be able to return the borrowed funds until after the attack, when presumably it would have been detected and the borrowed funds’ value have fallen.
Second, the unlocking period is short enough that it does not represent a significant liquidity risk for most users. This limits the attractiveness to users of exchanges creating secondary markets in Locked Celo Gold and thereby pooling voting power.
Once a user has Locked Gold, they can allocate an amount of it as a vote for a validator group.
Validator elections are held once every fixed number of blocks, a period called the election epoch. Votes persist between epochs, and the same vote is applied to each election until revoked, in which case it has no effect on the validator set until the following election.
One way to consider the security of a Proof of Stake system is the marginal cost of getting a malicious validator elected. In a steady state, assuming the Celo community set the incentives appropriately, we can assume that a full complement of validators is elected, which means the attack cost is the cost of acquiring sufficient Celo Gold to receive more votes than the currently elected validator with fewest votes, and thereby supplant it. As such, the objective of Celo’s validator elections differs from real-world elections: they aim to translate voter preferences into representation while promoting decentralization and creating a moat around existing, well-performing elected validators. Two design choices influence this: a limit on the maximum number of member validator that a group can list, and a cap on the number of votes that any one group can receive.
Since voting for a group can cause only the group’s member validators to get elected, and no more, votes in excess of the number needed to achieve that are unproductive in the sense that they do not raise the number of votes needed to get the least-voted-for validator elected. This would translate into a lower cost for a malicious actor to acquire enough Celo Gold to supplant that validator. This is particularly true because the protocol limits the maximum number of members in a group, to promote decentralization.
The Celo protocol addresses this by enforcing a per-group vote cap. This cap is set to be the number of votes that would be needed to elect all of its validators, plus one more validator. The cap is enforced at the point of voting: a user can only cast a vote for a group if it currently has fewer votes than this cap. If a group adds a new validator, or the total amount of voting Locked Gold increases, the group’s cap rises and new votes are permitted. If a group removes a validator or a validator chooses to leave, or the total amount of voting Locked Gold falls, then the group’s cap falls: if it has more votes than this new cap, then new votes are no longer permitted, but all existing votes continue to be counted.
The Celo protocol allows an account to divide its vote between up to three groups, since there may be cases where the vote cap prevents an account allocating its entire vote to its first choice group.
At the end of every epoch, the validator election is run to determine the validator set that can sign blocks in the following epoch. Validators are selected according to the D’Hondt method, a form of proportional representation.
First, groups that do not receive a minimum threshold of the total vote are excluded. Then, the first slot is assigned to the validator ranked first in the group receiving the most votes. Then, at each step, the process considers the highest-ranked candidate that has not yet been selected from each group, and elects the one that would maximize the average votes received over its group’s selected validators. Finally, the order of the validators is shuffled using an on-chain source of randomness.
Celo uses a variant on the familiar notion of ‘block rewards’, minting and distributing new units of Celo Gold as blocks are produced, to create several kinds of incentives. Epoch rewards are paid in the final block of the epoch and are used to: make payments to validators and validator groups; distribute rewards to holders of Locked Celo Gold voting for groups that elected validators; bolster the stablecoin reserve if it is under-collateralized, and make payments for protocol development grants and for carbon offsetting.
Since there is a fixed total supply of Celo Gold, the protocol has a target schedule on which additional tokens are minted in order to maintain epoch rewards for a significant period into the future. However, that needs to be balanced with the fact that several factors can increase or decrease the value of the payments that would ideally be made in a given epoch (including the Celo Gold to Dollar exchange rate, the collateralization of the reserve, and whether payments to validators or groups are held back due to poor uptime or prior slashing).
Before disbursing incentives, the protocol determines a number of tokens to mint using this target, then adjusts it based on how closely the cumulative amount of tokens minted is tracking to the target schedule. If the protocol has been under-spending to this point, baseline payments are increased. If it has been overspending, they are reduced.
Rewards for validators and groups
Four factors affect validator and group rewards: the on-target reward amount for this epoch; the validator’s ‘uptime score’; and the slashing penalty (see below) and group share for the group of which it was a member at the last election.
The on-target validator reward is a constant value (as block rewards typically would be) and is intended to cover costs plus an attractive margin for amortized capital and operating expenses associated with a recommended set up that includes redundant hosts with hardware wallets in a secure co-lo facility, proxy nodes at cloud or edge hosting providers, as well as security audits. As with most parameters of the Celo protocol, it can be changed by governance proposal.
In the usual case where no validator in the group has been slashed recently, and the validator has signed almost every block in the epoch, then the validator receives the full amount of the on-target reward, less the fraction sent to the validator group based on the group share. Unlike in some other Proof of Stake schemes, epoch rewards to validators do not depend on the number of votes the validator’s group has received.
Epoch rewards to validators and validator groups are denominated in Celo Dollars, since it is anticipated that most of their expenses will be incurred in fiat currencies, allowing organizations to understand their likely return regardless of volatility in the price of Celo Gold. To enable this, the protocol mints new Celo Dollars that correspond to the epoch reward equivalent of Celo Gold and transfers those to the Reserve to maintain its collateralization ratio. Of course, the effect on the target schedule depends on the prevailing exchange rate.
The Celo protocol tracks an ‘uptime score’ for each validator. When a validator proposes a block, it also includes in the block body every signature that it has received from validators committing the previous block. For a validator to be ‘up’ at a given block, it must have its signature included in at least one in the previous ten blocks. (Because the proposer order is shuffled at each election, it is very hard for a malicious actor withholding an honest validator’s signatures to affect this.) Then, a validator’s uptime score for the epoch is the proportion of blocks in the epoch for which it is ‘up’ raised to an exponent. This means that downtime of less than around a minute do not count against the validator, but that longer periods begin to reduce the score rapidly.
The validator’s overall uptime score is an exponential moving average of the uptime score from this and previous epochs. Since this starts out at zero, validators have a disincentive to change identities and an incentive to prioritize activities that improve long-term availability.
The protocol also tracks for each group a ‘slashing penalty’, initially equal to one but successively reduced on each occasion a validator in that group is slashed. The penalty returns to one 30 days after it was last reduced. This factor is applied to all rewards to validators in that group, to the group itself, and to voters for the group.
The slashing penalty gives groups a further incentive to vet validators they accept as members, not only to avoid reducing their own future rewards from existing validators but to attract and retain the best validators. Validators have an incentive to be elected through groups with a high value, so a recent slashing makes a group less attractive. Validators also have an incentive to select groups where they believe careful vetting processes are in place, because poor vetting of other validators in the group reduces their own expectation of future rewards.
When a validator is slashed, reduced rewards may lead other validators in the same group to consider equivalently ‘safe’ slots in other groups, if they are available. A validator disassociating from the group would cause the group’s rewards to further decline. While that may cause churn in the set of groups through which validators are elected, it is unlikely that a validator would move to a group where they could not be elected (since in this case they would receive no rewards, as opposed to fewer rewards), hence making the votes by which they were previously elected unproductive.
Validator groups are compensated by taking a share of the rewards allocated to validators. Validator groups set a ‘group share’ rate when they register, and can change that at any time. The protocol automatically deducts this share, sending that portion of the epoch rewards to the validator group of which they were a member at the time of the last election.
Since the sum of a validator’s reward and its validator group’s reward are the same regardless of the ‘group share’ that the group chooses, no side-channel collusion is possible to avoid deductions for downtime or previous slashing.
Finally, there are two more sources of incentives for validators (but not groups). First, validators have an additional incentive to be up and proposing blocks when it is their turn to do so because they receive a portion of the fees for transactions included in those blocks. The validator group share does not apply to these transaction fees.
Second, as part of Celo’s identity protocol, validators run an Attestation Service which sends SMS messages to users verifying control of the registered phone number. When users receive the SMS and redeem its contents with the smart contract, the validator receives a fee that exceeds the cost of sending the SMS.
Rewards on Locked Gold
Locked Gold holders who voted in the previous epoch for a group that elected one or more validators and have activated their votes are eligible for rewards. These rewards are totally independent from validator and validator group rewards, and are not subject to the ‘group share’. They are added directly to the Locked Gold voting for that group, and re-applied as votes for that same group, so future rewards are compounded without the account holder needing to take any action.
First, an on-target reward rate is determined. The protocol has a target for the proportion of circulating Celo Gold that is locked and used for voting, and adjusts the reward rate to increase or reduce the attractiveness of locking up additional supply. This aims to balance having sufficient liquidity for Celo Gold, while making it more challenging to buy enough Celo Gold to meaningfully influence the outcome of a validator election.
Adjusting the on-target reward rate to account for under- or over-spending against the target schedule gives a baseline reward, essentially the percentage increase for a unit of Locked Gold voting for a group eligible for rewards.
The reward for each account’s vote for a particular group is determined by taking the baseline reward and factoring in the group’s slashing penalty and the average epoch uptime score for elected validators in the group.
Other uses of epoch rewards
Besides validators, groups and Locked Gold holders, there are three other possible recipients of epoch rewards.
A Community Fund provides for general upkeep of the Celo platform. The community decides how to allocate these funds through governance proposals. Funds might be used to pay bounties for bugs or vulnerabilities, security audits, or grants for protocol development. This is the default destination for any slashed assets, too.
A Carbon Offsetting Fund provides for making the Celo platform carbon-neutral, by making a payment every epoch to an organization nominated by the governance process.
Finally, in rare circumstances, epoch rewards may also be used to bolster the reserve underpinning the Celo platform stablecoins in the event that the reserve is under-collateralized due to a sharp fall in the value of Celo Gold or of the other cryptocurrencies it holds.
Stakes and slashing
Validators and validator groups put up a stake by maintaining a minimum Locked Gold balance which is at risk from when they register until when they de-register, which must be at least an ‘unstaking period’ after they last were a member of a group (for validators), or had any members (for groups). For groups, a stake is required per member validator.
Slashing has several effects: it deducts a sum from the validator’s stake, and the same sum from the stake of the group it was a member of at the time in question. It also halves the group’s slashing penalty, and resets a timer that after a ‘forgiveness period’ returns the slashing penalty to one. Finally, it automatically removes the validator from its current group, so that the group has to decide explicitly to re-add the validator before it can be re-elected.
For behavior that can be detected and proved by a third party (in the current design, double-signing), any address can make a submission that if previously unreported results in an amount being deducted and the proceeds split between the submitter and the Community Fund.
For some cases, slashing can be initiated automatically through the protocol (right now, for excessive downtime). Alternatively, the community can use governance proposals to slash funds, a decentralized mechanism that can evolve to tackle unforeseen malicious behavior. In both routes, the Community Fund receives all slashed funds.
If a validator or group’s stake falls below the required level (due to slashing), no rewards are earned until it is topped up.
It is worth highlighting that regular users’ Locked Gold is not staked and is never at risk.
Long-term roadmap: permissionless, scalable BFT
Celo’s mechanism for selecting validators stems from the reality that only a small number of nodes can ever fulfill this role due to the scalability constraints of existing BFT consensus algorithms. This means it is important for network performance and stability to avoid the failure or malicious behavior of even a small number of nodes.
In concert with building the Celo platform, the Celo community has been developing BF-Tree, a BFT consensus algorithm that scales to thousands of nodes. This is a radical step change from the existing state of the art. But it means that the Celo project could embed a Proof of Stake mechanism that is truly trust-free and permissionless, in that nodes can join without a selection process. Full nodes would take on the additional role of validating, just as they do with mining in the public Ethereum chain, except of course without the environmental impact. This would facilitate validator rewards that everyone contributing compute resources can share in, on top of the incentives for serving light clients described above.
The work is at an early stage, and we look forward to working with the community to make this a reality in the coming year or two.
If you’re interested in finding out more about operating a node on the Celo network, either a validator or full node, or can see yourself running a validator group, you should absolutely join The Great Celo Stake Off.
We’d also love to hear your thoughts on what we’re building. The design space around mechanisms for validator incentives has many complicated trade-offs and we look forward to working with the community to iterate on this.
You can read more about the Celo Protocol in the Celo Developer Documentation, and try out Celo on the Alfajores Testnet. You can ask questions and find answers on the Celo Forum, or chat with Celo developers on Discord.
Thanks to Asa Oines, Claire Belmont, Jason Ansel, Roman Croessmann, Marek Olszewski, Taylor Lahey, Brian Crain and numerous others for contributions to this design and description.