Mastering the Art of Validating | Celo
•Download as PPTX, PDF•
0 likes•53 views
How can you validate on the Celo Platform? Learn the basics of Proof of Stake and how to collect rewards.
More Related Content
Similar to Mastering the Art of Validating | Celo
Similar to Mastering the Art of Validating | Celo (20)
More from cLabs, working on Celo
More from cLabs, working on Celo (8)
Recently uploaded
Recently uploaded (20)
Mastering the Art of Validating | Celo
- 1. Validating Mastering The Art Of Tim Moreton @timmoreton November 26, 2019
- 2. Agenda 1. Introduction to Celo 2. Network Topology 3. Proof of Stake Basics - Voters, Groups and Validators - Locked Gold - Validator Elections 4. Epoch Rewards 5. Penalties 6. Attestations 7. Q&A
- 3. Build a monetary system that creates conditions of prosperity for all. The Celo mission
- 5. Topology
- 6. Setup
- 7. Proof of Stake Basics
- 9. Concepts
- 10. The network’s interests are best served by selecting validators running on secure hardware, with good monitoring, and undergoing regular audits. Validators
- 11. Groups will be able, and incentivized, to build up long-term judgements on their validators’ operational practices and security setups. Validator Groups
- 12. The network is secured by voters locking up Gold and selecting groups that maximize their rewards and that they trust, making the cost of influencing elections prohibitive. Holders of Celo Gold
- 13. Concurrent Uses of Locked Gold - Voting for Validator Groups - Stake for Validators - Stake for Validator Groups - Voting on Governance Proposals
- 14. Concurrent Uses of Locked Gold - Voting for Validator Groups - Stake for Validators - Stake for Validator Groups - Voting on Governance Proposals
- 15. Concurrent Uses of Locked Gold - Voting for Validator Groups - Stake for Validators - Stake for Validator Groups - Voting on Governance Proposals
- 16. Locked Gold
- 17. Locked Gold
- 18. Locked Gold
- 19. Locked Gold
- 20. Elections
- 21. Epoch Rewards
- 22. Recipients - Validators - Validator Groups (group share) - Locked Gold (that elects a validator) - Community Fund - Carbon Offsetting Fund - Reserve
- 23. Recipients - Validators - Validator Groups (group share) - Locked Gold (that elects a validator) - Community Fund - Carbon Offsetting Fund - Reserve
- 24. Recipients - Validators - Validator Groups (group share) - Locked Gold (that elects a validator) - Community Fund - Carbon Offsetting Fund - Reserve
- 25. Rewards to Validators and Validator Groups
- 26. Validator Uptime
- 27. Rewards to Locked Gold that elects a validator
- 28. Penalties
- 29. - Validator removed from group (effective next epoch) - Validator and group each lose a fixed amount of their stake - ‘Slashing penalty’: Halve validator, group and voter rewards for 30 days Consequences of penalties vary
- 30. Categories of offense - Double Signing - Persistent Downtime - By Governance
- 31. Categories of offense - Double Signing - Persistent Downtime - By Governance
- 32. Categories of offense - Double Signing - Persistent Downtime - By Governance
- 33. Attestations
- 34. Attestations
- 35. Mastering the Art of Validating - Learn the protocol - Pick a secure provider - Repeatable, best-practices setup - Deploy Attestations Service and maybe a full node or two - Join a group, or start one! (you’ll need to build differentiation) - Vote with your stake!
- 36. Stake Off - Webinar Thursday December 5 at 1600 UTC https://tinyurl.com/sxpeehk Starts Dec 4th! celo.org/stake-off Questions? Join our AMA! NOW: ‘Baklava Testnet’ on Celo Forum tinyurl.com/ud6j9re
- 37. Thanks, we value your time @CeloHQ | @CeloDevs Photos by Jeff Siepman, Lana Graves, Sam Beasley, Plush Design Studio on Unsplash
Editor's Notes
- This webinar is going to cover the role of validators in the Celo protocol, and how the Proof of Stake scheme by which validators get elected, rewarded and slashed works.
- Before we dive in, I wanted to set the context for the webinar and some logistics. The Great Celo Stake Off begins Dec 4th -- The Stake Off is a competition that will run on top of Baklava, the Celo incentivized testnet. It helps anyone interested in becoming a potential mainnet validator build operational experience, have time to get familiar with the software and build security good practices, and generally helps the community building the Celo protocol to further harden the software too. Subject to the Stake Off Terms and Conditions, the top 50 teams on the leaderboard will have the opportunity to receive Celo Gold at Mainnet launch -- enough according to the current design to be able to put up a stake for one or more validators and validator groups. On top of that, there are additional ways to receive Mainnet Celo Gold for helping the community in other ways -- contributing code, improving documentation, extending test coverage, or helping others participate. There will be an AMA straight after this on the Celo Forum -- follow the link or QR code there. As well as this webinar and AMA which is focused on the technical material, there will be a second webinar on December 5th about the Stake Off, the rules of the competition and generally answering any questions you have about participating. I highly recommend you sign up for that session too at the link on the slide.
- Before we dive into the details of Celo’s Proof of Stake mechanism, I think it’s important to start with the purpose for which the Celo protocol has been designed. The Celo mission is to build a monetary system that creates the conditions of prosperity for all. This starts by empowering anyone with a smartphone anywhere in the world to have access to sound currency, and be able to participate in basic financial services through their phones: maintain a balance, send money to friends and family via their phone numbers, be able to use their phones to pay for goods at stores — all on a decentralized platform that is developed and operated by the community, and that can form the foundation for a whole range of new services from apps for managing savings and micro-lending through to products no one has thought of yet. That’s a wildly ambitious mission, and one that requires taking a whole stack approach, combining mobile Wallet, smart contract platform to provide stable value currencies, an identity protocol for sending directly to phone numbers, and an architecture focused on serving many mobile clients using little of their scarce data connectivity, and a platform enabling fast finality and high throughput at a reasonable infrastructure cost. To help get there faster, Celo is based on Ethereum as a starting point. The Celo blockchain reference implementation is based on go-ethereum, the Go implementation of the Ethereum protocol. We’re indebted to the Geth community for providing these shoulders to stand on. So for those familiar with Ethereum, there are going to be familiar concepts here, but there also a lot of things that Celo does differently. So smartphones are at the heart of this vision -- and validators are at the heart of the infrastructure powering this vision.
- So let’s look at what the Celo network looks like in terms of the running components and how they communicate.
- There are four kinds of node. The most numerous constituents in the network will be light clients, running alongside Wallet apps on every users’ mobile device. These light clients use Full Nodes to answer their requests for account and transaction data and forward new transactions on their behalf. It’s likely that the majority of permanently-connected computers in the Celo network will need to fulfil this role. In Ethereum right now, there are few incentives to run a full node that is not mining. To address incentives, the Celo protocol incentivizes users to operate regular non-validator nodes. I’m not going to cover this in much detail, except that you should know -- there are two routes by which to receive rewards for participating in the network. With Celo, light clients pay a per-transaction fee to a ‘gateway’ full node. This is a fixed fee, separate from fees for gas. Clients include in every transaction the address of this gateway node which, when the transaction is processed, receives this fee. The model is analogous to a cafe: while you may freeload on their rent, heat, wifi, etc, you’ll likely be required to buy a coffee periodically. Also this is more casual route -- a permissionless on-ramp: you can join or leave the network whenever you like, and there is no stake, no slashing. It’s a route for anyone to earn currency, but as a potential validator there’s nothing to say you also cannot run full nodes -- in fact I hope you will. Finally in the center of the diagram, there are the validators. Like several other proof of stake blockchain projects, Celo uses a Byzantine Fault Tolerant (BFT) agreement protocol to agree new blocks being added to the blockchain. Validator nodes broadcast signed messages between themselves in a sequence of steps to reach agreement even when up to a third of the total nodes are offline, faulty or malicious. When a byzantine quorum of ⅔+1 validators have reached agreement, their signatures together allow other nodes to certify that the new block is valid. Let’s look at what that really means…
- Operating a Validator in the Celo network really means operating a setup that looks like this. First, the validator itself is an instance running the celo-blockchain software configured as a validator. Validators hold two keys. One ECDSA key, as used in regular Ethereum, is used for signing messages in the BFT agreement process. The second, the BLS key, is used for signing the block once agreement has been reached. We strongly recommend that you run validators behind proxies. Proxies are celo-blockchain instances running as regular full nodes, but they also forward messages to and from a validator that sits on a private network and communicates only via one of its proxies. This avoids the machine holding the actual keys that can sign blocks being exposed to the public internet. It also mitigates Distributed Denial of Service attacks. Right now, the protocol supports one proxy, but support for additional proxies should be coming soon. Right now there isn’t support for hardware wallets (also called Hardware Security Modules, HSMs), because none support BLS signatures out of the box. However there is promising progress on running custom signing code in a performant way on a Nano Ledger X. Another thing to watch out for is Threshold Validator support. Celo will soon support a setup where you can run several validator shard instances, each of which have a share of a single validator’s private keys, such that say 2 of 3 are needed to create a signature. This improves both security (because you have to compromise two of the three before you can steal the key) and availability (because a single host can be down and signing can continue). The attestation service is a separate service (not the celo-blockchain software) that is part of the Celo identity protocol. It allows validators to get paid to direct text messages to prove new users’ access to a specific phone number. We’ll talk more about this later. For now, it’s just worth noting that it holds its own Attestation Key, listens for requests from Mobile Wallets directly, and sends SMS using various provider APIs. It acts as a light client to read details from the blockchain, but otherwise doesn’t play a part in the blockchain network.
- So let’s now look at how you become a validator. That is what Proof of Stake is all about.
- First, a quick recap on Proof of Work vs Proof of Stake. In a Proof of Work scheme, nodes compete to solve a computational puzzle that consumes the vast majority of those nodes’ compute power — and entails high electricity usage, too. The chain of blocks accepted as the current state of the network is (more or less) the one that is longest and would cost the most energy to rewrite. Network security relies on no one organization acquiring a majority of the total “hashing power” and so being able to conduct a 51% attack. This means that users of a Proof of Work network are in effect paying for miners whose presence rarely results in transactions being processed but instead prevents the takeover of the network. The higher the security, the higher the cost and environmental impact. In BFT consensus, validators only do the useful work of building blocks by running transactions and verifying the blocks proposed by each other. This allows the network to deliver higher transaction throughput. Its block rate can also be more predictable. The network is secured by having two-thirds of the validators faithfully execute the BFT algorithm: when a quorum is achieved, that block is final. The greater capacity of Proof of Stake networks and the need to fund a far smaller pool of hardware means that its operating cost, overall and on a per-transaction basis, is far lower. Importantly, the network can use a fraction of the energy of Proof of Work. However BFT on its own does not replace a Proof of Work scheme. BFT protocols rely on an external mechanism to determine the validators that participate in agreement -- that is what Proof of Stake is. ‘Proof of Stake’ is how you pick who gets to be part of the BFT algorithm. However BFT cannot scale beyond a few hundred nodes at most -- Celo will probably launch with 100 validators -- so it cannot encompass all of the participants that Proof of Work can. That means the cost of picking validators badly is really high. That can be the biggest downside vs Proof of Work, where anyone can come along -- in a permissionless fashion -- and take part. So Proof of Stake also attempts to align the incentives of validators with those of the network. They overlay the consensus algorithm with a way of holding potential validators’ funds in a type of smart contract escrow as a ‘stake’, accept some of those as validators and reward them, while also incentivizing other nodes to detect and prove misbehavior, for which validators will be ‘slashed’ portions of those stakes.
- So let’s look at how Celo implements proof of stake. First I want to introduce some concepts. Starting from the right, Validators are nodes that are ready to participate in BFT consensus -- or are actively doing so. To do that they need to get elected. The Celo protocol runs an election once every epoch, a certain number of blocks that is going to be approximately 1 hour for Baklava but might be 1 day for mainnet. In the election, votes are not made for individual Validators, but instead 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 portion of validator rewards. And, as a decentralized platform, there is no real way of identifying users, per se, only accounts. By design, anyone can generate any number of new accounts. What they cannot do is just generate assets. So to resist so-called sybil attacks where users create multiple identities and vote with each of them, or even where they can transfer assets between accounts and vote multiples times with the same funds, we require accounts to lock up their gold, essentially escrowing it, in order to use it to vote. Crucially, unlike a number of other proof of stake platforms, voters’ Locked Gold funds are never slashed as a result of misbehavior by validators they voted for. The same Locked Gold mechanism is used by both validators and validator groups to put up a stake --- and they can vote with that at the same time.
- I think it’s worth just re-iterating the roles of each of these three groups in making the network secure and highly available. Because BFT scales only to few hundred nodes, and can tolerate only a third malicious participants, each validator may have a significant negative effect on the performance and security of the network. The network’s interests are best served by selecting validators running on secure hardware, with good monitoring, and undergoing regular audits. Operational security and best practice is critical and is something that is entirely in the control of validator admins. Because of this, Celo encourages the ‘professionalization’ of validators -- having good physical data center security, future support for hardware wallets, having monitoring, alerting, intrusion detection configured, and so on. You’ll see there is a lot of attention to this during the Stake Off. However it’s not always possible for users to tell whether a validator is doing all of this stuff.
- In fact, in Celo introduces the concept of validator groups to address this. Groups will be able, and incentivized, to build up long-term judgements on their validators’ operational practices and security setups. Validator groups can help mitigate the information disparity between voters and validators. 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 have better information on the quality of a validator operator than each of the numerous Celo Gold holders that might vote for it would.
- The network is secured by voters locking up Gold and selecting groups that maximize their rewards and that they trust, making the cost of influencing elections prohibitive. The Celo protocol does not rely on the holders of Celo Gold being able to necessarily make great decisions about which validators most diligently rotate their keys. Instead, it relies on them making the relatively easier decision of selecting a group that performs well and that they trust -- that has with a good reputation. Celo Gold holders earn rewards if they vote for groups that have one or more validators elected, and those rewards are structured to align Gold holders’ incentives with validator behavior and performance. But reputation still matters. It is worth highlighting one other, critical way in which rewards to Gold holders results in network security. By locking up gold, and reducing liquidity, it - from an economics perspective - is expected to become prohibitively expensive to purchase large quantities of Celo Gold to elect malicious validators.
- So let’s look at Locked Gold in some more detail. Celo has a single LockedGold smart contract. This means that “escrowed” funds can be used concurrently for a number of purposes. The first is voting for validator groups in validator elections.
- When registering a validator or validator group, the account’s LockedGold balance is used to satisfy staking requirements.
- And Celo also has an on-chain governance mechanism in which Locked Gold holders can vote for or against proposals to change the protocol. I won’t cover that here, but this is expected to be more fully tested in Phase 3 of the Stake Off. And it’s worth noting that since these users are concurrent, funds staked can also be used for voting for validator groups -- yourself or if you’re playing a complicated game, someone else -- and earn rewards for doing so.
- Let’s look at the lifecycle of this process. An account can lock up an amount of its Celo Gold. It can then vote for a group using that amount. That counts towards the next subsequent election, but is marked “pending” for rewards.
- In the last block of the epoch, the election is run and new validators may be selected. Pending votes made in a previous epoch for a group that has one or more elected validators can now be “activated”, so that from the end of that epoch they count for rewards. Rewards are applied to the pool of voting Gold, which means that votes and rewards automatically compound.
- At some point later, the account can unvote some or all of the Locked Gold, including rewards accrued, and it immediately becomes available for voting on a different group. Alternatively, the account can unlock some of it.
- 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 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. However it short enough that it does not represent a significant liquidity risk for most users.
- So finally, let’s look at how Validator Elections work. Validators are selected according to the D’Hondt method, a form of proportional representation. 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. Celo 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. Celo limits group size because a diverse set of groups and validators makes the network less centralized and more secure. However that means the votes in excess of the number needed to achieve that limit are unproductive in the sense that they do not raise the number of votes needed to get the least-voted-for validator elected -- the one that an attacker is trying to supplant. 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.
- Celo uses epoch rewards, 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. 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. 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.
- They are used to: make payments to validators and validator groups. (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.)
- The protocol also distributes rewards to holders of Locked Celo Gold voting for groups that elected validators;
- And finally, there are three other recipients -- The 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.
- 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. 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. 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. Worth noting that validators (not groups) have two other sources of rewards: attestations (i’ll cover that later) and a portion of transaction fees in blocks that they propose.
- 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 12 blocks. The rate this happens is put through a formula and a moving average calculated -- full details will be in the docs. But basically downtime of less than a minute doesn’t affect your uptime score, but downtime of more affects it rapidly.
- Let’s look at Rewards to Locked Gold. Remember this applies only to Locked Gold voting -- and activated -- for a group that elects at least one validator in that epoch. These rewards are totally independent from validator and validator group rewards, and are not subject to the ‘group share’. Rewards are in Celo Gold, not Celo Dollars. 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.
- The team working on Celo is still fleshing out details of penalties but the current design includes types of behavior the protocol wants to disincentivize, and several ways of doing that.
- TBD precisely but most likely signing with BLS signatures two blocks at the same height with different parents. The protocol treats double signing as an offense because otherwise validators suffer a ‘nothing at stake’ problem -- because there is no cost to signing a block, unlike in proof of work, they sign all of them in order to be part of whatever chain is valid.
- Persistent downtime -- in terms of BFT, failed validators are no different to malicious validators. So most likely that the protocol will just cause a validator to be removed from the group so an active validator can be elected in its place.