Consensus and Proof of Stake in the Celo protocol
How Celo has reimagined Ethereum with Byzantine Fault Tolerance, Proof of Stake and incentives to serve mobile devices
Celo’s aim is to empower anyone with a smartphone anywhere in the world to have access to financial services, send money to phone numbers, and pay merchants — all on a decentralized platform that is developed and operated by the community. The surface area of the project is vast and to deliver better products sooner we chose to build on some of the crypto community’s best work.
Celo’s 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 and, while recognizing that Ethereum is an independent project with its own trajectory, we hope to contribute back where we can.
The Celo protocol incorporates a number of substantial changes in service of its end users. In this post, we focus on the consensus protocol, the core mechanism that applies new transactions and advances the agreed state of the network, and on Celo’s implementation of Proof of Stake — how it determines which nodes get to participate in consensus.
Byzantine Fault Tolerance
Like a number of recent crypto projects, Celo is adopting a Byzantine Fault Tolerant (BFT) consensus algorithm. A well-defined set of 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 quorum of validators have reached agreement, that decision is final.
Most BFT implementations are based on Miguel Castro and Barbara Liskov’s work on Practical Byzantine Fault Tolerance. Understanding and implementing consensus algorithms is notoriously tough: this is a good explainer on PBFT. Celo’s is based on an implementation called Istanbul, or IBFT. This is not to be confused with the upcoming Ethereum hard fork also codenamed Istanbul. IBFT was developed by AMIS and proposed as an extension to Geth but never merged. Variants of IBFT exist in both the Quorum and Pantheon clients. We’ve been modifying Istanbul to bring it up to date with the latest Geth releases, fix correctness and liveness issues, and improve its scalability and security. We’ll dive into the details in a subsequent post.
Moving beyond Proof of Work
Since the Celo protocol is leveraging Ethereum as the basis for its blockchain, it’s worth explaining why we took the time to move away from the Proof of Work scheme already deployed with Ethereum. (It’s also worth noting that Ethereum 2.0 will eventually make a similar move!)
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.
Here, safety comes in numbers. 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. 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.
Another benefit for new networks is being more secure, sooner. Attackers can and do rent compute resources to target Proof of Work networks and so only those networks that are most established can effectively resist 51% attacks. It is a difficult and lengthy process for a new network to get to that point.
Proof of Stake also offers immediate finality: almost all transactions complete and are irreversible within seconds, giving a better user experience. Proof of Work schemes have probabilistic finality: since many nodes are competing to mine blocks at the same time, a transaction can be reverted if the block in which it is included then does not end up as part of the longest chain and a conflicting transaction is applied instead: the chance this happens decays with time.
Proof of Stake: picking the validators
While the benefits of adopting BFT consensus seem extremely compelling, on its own it does not replace a Proof of Work scheme. BFT protocols rely on an external mechanism to determine the validators that participate in agreement. The algorithms also cannot scale beyond the order of hundreds of validators, and can resist malicious or faulty behavior by at most one third of validators. For these reasons, in an open system where there are many more participants than possible validators, some policy choice must be made to determine how to allocate these privileged roles. Further, admitting each validator has an associated risk: each new validator must be subject to a combination of strong economic incentives and/or trust to ensure the security of the network.
‘Proof of Stake’ schemes are an attempt to align the incentives of validators with those of the network. They overlay consensus algorithms (usually BFT) with mechanisms to hold potential validators’ funds in 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. Balancing these aspects is challenging to do. Cosmos and Tezos are examples of successful public networks using Proof of Stake.
This contrasts with the ‘permissionless’ nature of Proof of Work schemes which permit any node to attempt to mine a block without any coordination, and rewards them for successfully doing so. Such schemes require a miner to incur an energy cost up-front, meaning that at the point of mining a block, they have a strong incentive to correctly submit the block to the network. Furthermore the number of miners can change over time and has little impact on the protocol. The underlying currency is redistributed to new miners through block rewards as they participate.
This leads to the primary criticism of Proof of Stake schemes: that stakes present a barrier to entry to most participants, and this means that they concentrate power and rewards into too few hands, and that they lack a ‘permissionless on-ramp’ in the protocol, depriving new participants of an opportunity to earn currency and get to the point where they could participate as a validator.
Celo’s permissionless on-ramp: serving end users
Of course, applying transactions and validating state updates are only a small part of what a digital payments platform must do. Celo’s focus on providing the best user experience for mobile payments means that the Celo design assumptions differ from other networks, sometimes significantly.
We anticipate the majority of Celo’s end users will manage their accounts and send payments using a Wallet app on their cell phone. The open source Celo app embeds a “light client” that connects to the network and is optimized for low-power devices and low-bandwidth connections. These light clients need nodes that will answer their requests for account and transaction data and forward new transactions on their behalf. It’s likely that the vast majority of machines 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. Few nodes serve light clients, and this results in a poor experience for mobile wallets.
So Celo designed a protocol to incentivize users to operate regular nodes. With Celo, light clients pay a per-transaction fee to full nodes. Clients include in every transaction the address of a node which, when the transaction is processed, receives this fee. Full nodes advertise a minimum fee, and may choose to refuse to process transactions for which it will not receive the fee or it deems the fee insufficient.
While a full node provides other services for which they receive no specific fee, we expect that failing to service these requests will cause clients to seek other full nodes that do, who will then receive fees when they next make a transaction. 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. Refuse and you might not be so welcome next time.
We anticipate a market emerging where light clients will (automatically in most cases) choose full node peers based on cost, latency, reliability and other factors. An abundance of full nodes geolocated close to their communities will improve app performance and reliability. Since light clients need not trust full nodes, as they can verify their work, it also provides the ‘permissionless on-ramp’ lacking in other Proof of Stake networks.
As an aside, it also turns out that using BFT consensus allows Celo clients to synchronize dramatically faster than Ethereum, which is very important for devices on poor connections. You can read more about Celo’s ultralight sync mode here, and we’ll dig in to this in a future post.
Celo builds on the Ethereum protocol with the aim of creating a platform that empowers anyone with a smartphone anywhere in the world to have access to financial services. It replaces Ethereum’s use of Proof of Work for securely adding transactions to the ledger with a Byzantine Fault Tolerant consensus algorithm. And it creates a new permissionless on-ramp by creating incentives for full nodes to serve mobile devices.
In my next post, we dive into the details of Celo’s Proof of Stake design.
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.