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

Tim Moreton
Nov 8, 2019 · 8 min read

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

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

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

‘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.

Webinar recording, which deep dives 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.

Celo’s permissionless on-ramp: serving end users

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.

Conclusion

In my next post, we dive into the details of Celo’s Proof of Stake design.

Get involved!

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.

The Celo Blog

Celo is an open platform that makes financial tools…

The Celo Blog

Celo is an open platform that makes financial tools accessible to anyone with a mobile phone. Visit celo.org for info on the community, contributors, and technology.

Tim Moreton

Written by

Engineering @celo.org. Previously ran Apple's cloud infrastructure for data science, analytics, monitoring and observability. Founder/CEO/CTO at Acunu.

The Celo Blog

Celo is an open platform that makes financial tools accessible to anyone with a mobile phone. Visit celo.org for info on the community, contributors, and technology.