CometBFT: Security and Consensus in Cosmos (Part 1)

The first of two articles on the CometBFT consensus algorithm, which allows Cosmos validators to come to consensus.

Table of Contents

• Introduction
• Delegated Proof of Stake
• A Simplified Network
• A Picture-Perfect Round
  - Phase 1: Propose
  - Phase 2: Prevote
  - Phase 3: Precommit
  - Phase 4: Commit
• Block Rewards
• Conclusion

Introduction

Bitcoin’s use of Proof of Work (POW) combined with the block reward incentive system has allowed for its incredible uptime since January 3, 2009. While this is impressive, it is natural to wonder if there are other ways for a decentralized monetary system to be trusted, without the massive energy expenditure and slow block production time of POW.

Enter CometBFT. CometBFT (a fork of the original Tendermint algorithm) is the algorithm used in most Cosmos blockchains, which means that it is the method by which many distrusting computers can come to agreement (or consensus) about the ownership of digital assets. If you’re new to the Cosmos, I recommend you have a read through our introductory article here.

I will break our discussion of CometBFT into two parts, with this article focussing on how it works under perfect conditions. I have used ideas freely from both Jae Kwon’s original paper¹ and Ethan Buchman’s Masters thesis² if you require more detailed reading.

Delegated Proof of Stake

CometBFT is a delegated proof of stake (dPOS) algorithm that allows computers running the software to reach consensus. These computers are called validators, rather than miners, and each Cosmos chain will have a maximum number of permitted validators.

For example, at the time of writing, the Cosmos Hub has 175 validators, while a smaller Cosmos chain like Regen Network has 75. You can check how many validators are running your favourite Cosmos blockchain at an explorer like Mintscan³.

The number of active validators is a parameter that can be changed by the on-chain governance mechanism of all Cosmos chains. At each point in time, the majority of these validators need to agree on who owns what (collectively called the state of the blockchain), and this agreement is not easy if there is no trust between them. A consensus algorithm like CometBFT is designed to ensure that individual validators do not need to trust each other in order to agree on the current state.

A Simplified Network

To ensure that this is not just a reproduction of the existing documentation, I’d like to explain this process with an example network: four validators — A, B, C, and D — who are all running a simplified Cosmos Hub together. In our example network, each of our four validators must commit a certain amount of ATOM as stake. Let us suppose validators A and B have each staked 400 ATOM, and validators C and D have each staked 200 ATOM (as above).

Some quick arithmetic should convince you that the total voting power in this network is 1200 ATOM — the sum total of all the ATOM staked. If the validators make mistakes or misbehave, some or all of their stake can be slashed or destroyed, and this incentivizes validators to respect the rules of the consensus protocol.

In addition to this, CometBFT chains are special because ordinary users can delegate their funds to an active validator. In doing so, they can receive a proportion of the block rewards earned by that validator (more on this later), but they also take on the risk of losing their funds if their validator is slashed. Since delegators do not participate in consensus, I will mostly leave them out of the coming discussion.

Remember that each validator keeps their own version of the blockchain on their computers, so the most important question for many validators to agree on the state of a blockchain is: “How does the next block of transactions get added to everyone’s version?”. Let’s look at how this happens under ideal circumstances.

A Picture-Perfect Round

In Bitcoin, the addition of new blocks to the blockchain is a chaotic affair — a frantic race by miners all over the world to solve proof of work and broadcast their solution to the rest of the network. In CometBFT, this process is considerably more democratic. The addition of each block to the blockchain is done through a sequence of interactions between the validators called a round and in each round, one validator is the block proposer.

Let us suppose that the proposed block will be the 100th block added to this simplified blockchain. We refer to this number (100) as the block height or just the height. The goal of the round is that the validators will agree that the proposed block is valid, and everyone will commit this block to their own local version of the blockchain. The round has three initial phases.

Phase 1: Propose

Let us suppose that the proposer for the 100th block is Validator A. Their first job is to listen to the network and package a collection of valid transactions into a block (just like miners in Bitcoin). This proposed block is then broadcast to Validators B, C, and D.

Since we don’t know anything about the connections between A and the others, we can’t guarantee that the proposed block will be received by everyone. But, whenever any validator receives a proposal, they also broadcast it, so all validators should receive the proposal from someone.

Phase 2: Prevote

Once validators have received the block, the prevote stage begins. Each validator needs to communicate with each other about the proposed block. There are two options:

1. If the block is valid, they broadcast a cryptographic signature (a ‘yes’ prevote)
2. If they receive an invalid block (one with bad transactions or other mistakes in it), they broadcast a special nil prevote (a ‘no’). This nil prevote is also broadcast if the validator does not receive a block within an agreed-upon period of time.

Each of these validator prevotes is weighted by their amount of staked ATOM. Validator A will (almost certainly) broadcast a signature for their own proposed block.

Recall from above that Validator A has 400 ATOM staked, and so this block immediately has 400/1200 = 1/3 of the voting power attesting to its validity. At the end of the Prevote phase, each validator listens to the votes of the other validators and adds up the total weight for each outcome.

In summary, the prevote stage is where validators tell each other what THEY think of the proposed block.

Phase 3: Precommit

After listening to all of the incoming prevotes, each validator must make a decision. Let’s consider the best-case scenario from the perspective of Validator A (who is anxious to know what the other validators thought of their block):

• First, they receive Validator C’s vote (200 ATOM): signature (valid)
• Next, Validator D (200 ATOM): signature (valid)

Tallying up all the votes that A has received so far (including their own 400 ATOM vote) gives:

Valid votes: (400 + 200 + 200) / 1200 = 2/3

In CometBFT consensus, 2/3 of the voting power is considered a majority. Because a majority of voting power has signed for the validity of the proposed block, Validator A will sign a precommit vote and broadcast this to the network.

But what about Validator B? Actually, Validator A is incentivized to wait for a short period of time for Validator B because they will receive a small bonus⁴ in their block rewards for having more than 2/3 signatures. They need to be careful though, for if they wait too long other validators will vote to restart the round with a new proposer.

In general, once a validator confirms that 2/3 of the voting power attests to the validity of the proposed block, they will (should) sign a precommit vote for that block. If a validator does not receive at least 2/3 signatures for the proposed block, they must broadcast a nil precommit vote, much like in the prevote stage.

The precommit phase ends with validators listening to the network for other precommit votes. Like in the prevote stages, there are two main outcomes:

1. If they receive 2/3 signatures from other validators, they enter a special fourth phase called the commit phase.
2. If they receive 2/3 nil votes from other validators, a new round begins with a new proposer at the Propose phase.

Since this is our example where everything goes perfectly, at the end of this phase all validators will have received at least 2/3 precommit votes from each other. Each will then enter the commit phase.

In summary, the precommit stage is where validators tell each other what THEY THINK THE NETWORK thinks of the proposed block.

Phase 4: Commit

We did it! Consensus has been reached! The majority of validators agree that the proposed block was valid, and in the commit phase, each validator will update their blockchain by adding the proposed block. If you recall from above, this block was the 100th block of our chain, and so now every validator will update to block height 101 and begin the first round with a new block proposer. Yipee!

Here is the entire process, as illustrated in Ethan Buchman’s thesis²:

Block Rewards

Even though block rewards are not strictly part of the CometBFT protocol, these chains do not run themselves and no one would do it for free. So let’s talk about incentives.

In Bitcoin, whichever miner provided the proof of work for a given block the fastest will receive the block reward. The addition of blocks is a solo effort by each miner, and they keep 100% of the profits. But CometBFT is a more democratic process. The proposer could not have added the block alone, so who gets the block rewards? Actually, everyone.

Each time a new block is added to the blockchain three important things happen⁴:

1) A special proposer reward will be allocated to and be claimable by the block proposer

2) All transaction fees from that block are gathered into a special address.

3) A percentage of the total circulating supply of ATOM will be created and also deposited into this address (inflation).

Let us suppose that at the end of our 100th block, 1000 ATOM was created and that our Proposer reward is currently set at 5%. This means that 50 ATOM will be claimable by Validator A. The remaining 1000–50 = 950 ATOM will then be split across all validators proportional to their delegated stake. A little bit of math should give:

This is how the validators are compensated for providing the security needed to run Cosmos blockchains. If you are a delegator to one or many of these validators, then you would be entitled to your fair share of the rewards that went to each. For more details, you can have a look at this medium post⁵.

Conclusion

You have now seen how block commits occur in CometBFT-based blockchains in a very friendly network environment, but what makes CometBFT special is its ability to handle unfriendly environments.

What if the validators have trouble communicating? What if some validators misbehave? A blockchain needs to be resilient in adversarial conditions, and the real elegance of CometBFT is how it handles such situations. If you’re interested, please head on over to our next article.

Thanks for reading ❤
Robin Tunley
Twitter: @the5thforce0_0

References

[1]: J. Kwon, Tendermint: Consensus without Mining, https://tendermint.com/static/docs/tendermint.pdf, (2014)

[2]: E. Buchman: Tendermint: Byzantine Fault Tolerance in the Age of Blockchains, https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769 (2016)

[3]: Mintscan Block Explorer, https://www.mintscan.io/cosmos/validators

[4]: Cosmos Github FAQ, https://github.com/cosmos/cosmos/blob/master/VALIDATORS_FAQ.md

[5]: Node A-Team, Understanding a Few Key Features of Cosmos, https://medium.com/node-a-team/understanding-few-key-features-of-cosmos-hub-87394317d10a

If you found this article interesting or informative, please help us out by sharing it with your friends and family. If there are other topics within the Cosmos you’d like to know more about, don’t hesitate to contact us and let us know!

Notional: Website
Notional on Twitter: @notionaldao