What Is CometBFT and How Does It Work?

What Is CometBFT?

CometBFT is open-source software that makes sure multiple computers can agree on the same blockchain data. Simply put: it helps nodes put transactions in the same order and all keep the same updated state of a blockchain.

That process is called Byzantine Fault Tolerance, or BFT. In this setup, the system assumes that some participants may make mistakes, go offline, or even act maliciously on purpose. As long as less than one-third of the total voting power behaves that way, CometBFT prevents two different blocks from being finalized at the same spot in the blockchain.

CometBFT is the successor to Tendermint Core and uses the Tendermint consensus algorithm. It is not a ready-made blockchain and also not a complete crypto project with its own fixed rules. The software mainly handles consensus, communication between nodes, and block production. The blockchain's own rules, like which transactions are valid, live in a separate application.

The connection between CometBFT and that application is called ABCI, short for Application Blockchain Interface. You can think of ABCI as a fixed communication layer: CometBFT asks, for example, whether a transaction is valid, and the application answers. That lets developers build their own blockchain logic without having to create a consensus engine from scratch too.

Key Takeaways

• CometBFT is open-source software for consensus and syncing blockchain data between nodes.
• It uses BFT consensus, which helps handle mistakes or malicious behavior from part of the validators.
• CometBFT is a fork and successor of Tendermint Core.
• The software does not decide on its own which transactions are valid in substance; the connected application does that.
• ABCI is the connection between CometBFT and the blockchain application.

How Does CometBFT Consensus Work?

CometBFT lets validators work together on each block through three fixed steps: propose, prevote, and precommit. A validator here is a participant that is allowed to sign blocks and votes. So not every node is automatically a validator.

Every new position in the blockchain is called a block height. At each height, the network tries to decide on one new block. First, the protocol assigns a proposer. That is the validator that gets to spread a proposal for a new block during that round.

Then the other validators review the proposal. Is the block valid and received on time? Then they cast a prevote: an initial vote for that block. If there is enough agreement, a precommit follows: the second and deciding vote.

A block is committed once more than two-thirds of all voting power has given a precommit for exactly the same block. Voting power does not necessarily depend on the number of validators. For example, one validator can have more voting power than another, depending on the rules of the blockchain application.

Example: Suppose the total voting power is 100. Then more than 66 votes are needed to commit a block. It does not matter whether that voting power comes from many small validators or a smaller number of larger validators.

If there is no valid proposal, the proposer is offline, or votes arrive too late, the same block height starts over in a new round. The waiting times can increase per round, so slower nodes still have a chance to catch up. That does not prevent delays, but it does give the network a way to keep going when a round fails.

What Role Do Validators Play in CometBFT?

Validators make the decisions in CometBFT. They sign block proposals and votes, check proposals, and help decide which block gets added. A regular node can pass information to other nodes, but without a private validator key, that node cannot vote in consensus itself.

The proposer is chosen automatically and predictably through a round-robin scheme. Validators with more voting power get a proportionally larger share of turns to make a proposal.

In practice, a validator does the following:

• the validator receives a block proposal;
• the validator checks whether the proposal is valid according to the application rules;
• if the proposal is valid and on time, a prevote follows;
• if there are enough prevotes, a precommit can follow;
• after enough precommits, the block is committed.

If no valid proposal is received, a validator can vote nil. That simply means: no vote for a specific block in this round. This lets the network move on to a new round without just accepting an incorrect proposal.

The validator set and the distribution of voting power come as input from the blockchain application. That application can also have rules for adjusting the validator set. Staking, delegation, and slashing are not fixed autonomous functions of CometBFT itself. The application decides whether such rules exist and how they work.

One more important thing: validator signing keys need to be well secured. If the same validator signs conflicting messages, that can be proof of Byzantine behavior. CometBFT can process this kind of proof, but any financial penalty is determined by the application.

How Does Communication Between Validators Work?

Validators communicate through a peer-to-peer network, often shortened to P2P. Nodes pass information to other nodes through gossip. That sounds informal, but it just means messages spread from node to node across the network.

Through that gossip, transactions, block parts, proposals, prevotes, and precommits are spread. Nodes also share their current status: which block height they are on, which round they are in, and which step of consensus they are performing. That way, a node that is behind can see what is happening and catch back up.

Non-validating nodes can also be useful here. They are allowed to relay proposals, blocks, and votes, even though they do not cast a consensus vote themselves. That helps spread information widely across the network.

Transactions that the application considers sufficiently valid through CheckTx can end up in the mempool. The mempool is basically a waiting area for transactions that may end up in a new block. Through gossip, those transactions can be spread further. But that does not guarantee that a transaction will actually be included: the proposer, block limits, and application rules all play a role.

Do not confuse communication between nodes with ABCI. P2P and gossip are about messages between nodes in the network. ABCI is about local communication between CometBFT and the blockchain application, for example within the same process, through a socket, or through gRPC.

How Is CometBFT Built?

CometBFT is roughly made up of a consensus part and an application part, with ABCI as the connection between them. That separation is useful: one side handles how nodes agree, and the other side decides what the blockchain actually does.

The CometBFT engine includes components for consensus, P2P communication, the mempool, block propagation, state storage, and an RPC server. Through that RPC server, client applications can request data about consensus and the blockchain.

The application, on the other hand, manages its own rules and data. Think of whether a transaction is valid, how balances change, or which other actions the blockchain supports. In many Cosmos SDK nodes, CometBFT and the application run together in one daemon, but they can also work together as separate processes through ABCI.

Important to know: CometBFT calls the application through ABCI. So the application does not control CometBFT, but gives answers when CometBFT asks for them during the lifecycle of a transaction or block.

What Does the Consensus Layer Do?

The consensus layer of CometBFT decides when and how new blocks are finalized. This layer handles BFT consensus, P2P networking, block production, and block propagation to nodes.

For each new block, the protocol chooses a proposer and guides the propose, prevote, and precommit rounds. Once more than two-thirds of the voting power has precommitted to the same block, that block is committed.

The consensus layer also manages the mempool. When a node receives a transaction, CometBFT asks the application through ABCI whether that transaction is suitable for the mempool. That check is called CheckTx. A successful CheckTx does not mean the transaction has been executed for good yet. It only means the transaction may be eligible for a later block proposal.

After consensus on a block, CometBFT makes sure the application executes the block and stores the new state. So the consensus layer does not decide on its own whether a transaction is correct in substance. That remains the application’s job.

What Does the Application Layer Do?

The application layer defines the rules of the blockchain. That is where, for example, which data is tracked, which transactions are valid, and how a valid transaction changes the state.

This layer is the deterministic state machine of the blockchain. That is a technical term for something simple: if two nodes get the same input, they must calculate exactly the same result. Otherwise nodes can end up with different versions of the blockchain, and that obviously does not work.

In a Cosmos SDK application, this layer includes modules, transaction processing, and state stores. The current state also gets a cryptographic summary, the AppHash. If nodes calculate different AppHash values after the same block, that points to a problem with execution.

Through ABCI, the application handles different moments in the process:

• CheckTx: checks whether a received transaction may enter the mempool.
• PrepareProposal: lets the proposer application choose, sort, leave out, or add transactions for a block proposal within the allowed limits.
• ProcessProposal: lets other validators judge whether they accept the proposal.
• FinalizeBlock: executes a block after consensus is reached.
• Commit: permanently stores the new state.

Not every ABCI call has exactly the same requirements. PrepareProposal, for example, may differ because only the proposer performs it. ProcessProposal and block execution, on the other hand, must be deterministic so that all validators reach the same result.

What Is CometBFT Used For?

CometBFT is used as a general consensus and replication engine for blockchains with their own rules. So developers can put a deterministic application behind it instead of building a system from scratch where nodes have to agree on blocks.

The possible use cases vary. A blockchain application could, for example, focus on currencies, e-voting, or infrastructure orchestration. CometBFT does not define what the application has to be. It provides the technical base to reliably copy the same transactions and state across multiple nodes.

Within the Cosmos Stack, CometBFT has a clear role: it handles consensus, network communication, and block production. The Cosmos SDK then provides the building blocks for the application logic. That way, developers do not have to build both parts entirely on their own.

CometBFT also has its own RPC server. A wallet, dApp, or other client can use it to request data about blocks and consensus, alongside the APIs of a Cosmos SDK application.

How Does CometBFT Work With Cosmos SDK?

CometBFT and Cosmos SDK complement each other: CometBFT handles consensus and Cosmos SDK handles the blockchain application. So they are two different parts that can together form one working blockchain node.

The Cosmos SDK provides modules, transaction processing, state management, and other application rules. CometBFT, meanwhile, handles P2P communication, the mempool, choosing a proposer, and reaching consensus on new blocks.

The bridge between the two is ABCI. In a Cosmos SDK application, BaseApp implements this interface. CometBFT then makes requests such as CheckTx, PrepareProposal, ProcessProposal, FinalizeBlock, and Commit. BaseApp processes those requests and sends back a response.

For a new proposal, CometBFT first chooses a proposer based on validator voting power. Then the proposer’s application can use PrepareProposal to decide which transactions go into the proposal and in what order, within the block limits. Other validators review the proposal through ProcessProposal before they vote.

That split is practical. Developers can work on their own blockchain application while the proven consensus engine stays separate. That also means the same CometBFT engine can be used with different SDK applications.

What Are the Benefits of CometBFT?

One important benefit of CometBFT is clear BFT safety. As long as less than one-third of the relevant validator voting power behaves Byzantine, no conflicting blocks are committed at the same block height.

The separation between consensus and application logic is also very useful. Through ABCI, a developer can create their own blockchain rules without having to build a full BFT consensus engine themselves. That makes the technical work more manageable: CometBFT handles agreement, and the application handles the content.

Other benefits include:

• Clear voting process: a block is only finalized after more than two-thirds of precommits for that same block.
• Reusable technology: the same engine can support different blockchain applications.
• Flexible connection: ABCI can work in-process in Go, but also through socket or gRPC.
• Separation of responsibilities: consensus code and application code can be developed separately.

Still, it is important to know that these benefits do not automatically mean every blockchain using CometBFT is fast, secure, or highly decentralized. That also depends on the validator set, network connections, hardware, configuration, and the application code.

What Limitations and Risks Does CometBFT Have?

CometBFT has clear safety conditions and operational risks. The main condition is that less than one-third of validator voting power may be Byzantine. Byzantine here means validators behave incorrectly or maliciously, for example by sending conflicting information, not following the rules, or working together to manipulate the network. If that threshold is exceeded, the safety guarantee against conflicting commits no longer applies.

Enough active voting power is also needed for progress. If validators with enough voting power are offline, or if a network partition keeps them from communicating with each other, the network cannot reach quorum. Then new rounds follow and block production can slow down or temporarily stop.

Network latency plays a big role here. If proposals, block parts, or votes do not arrive on time, the round ends and the protocol tries again. The timeouts can then increase. That helps slower participants, but it also means confirmations can take longer.

The application behind ABCI is another important point. Where determinism is required, every node must produce the same result from the same input. A bug that makes nodes calculate different results can cause AppHash mismatches and consensus problems. So the separation between CometBFT and the application does not prevent all consequences of bad application code.

Validator keys and node infrastructure are also sensitive. Poorly secured signing keys can be abused, and validators can become targets of denial-of-service attacks. A sentry-node architecture can help keep validator nodes less directly exposed to those attacks.

Also, a transaction in the mempool is not yet safely included in a block. Nodes can crash before a transaction makes it into a proposal, which can cause the transaction to be lost from the mempool. So anyone sending a transaction has to wait until it is actually in a committed block.

Finally, version upgrades can create compatibility issues. Breaking changes in a minor release may require a new chain or a custom data migration. Upgrading therefore requires good preparation, both for the application and for the nodes running the blockchain.

Conclusion

CometBFT is the technical engine that helps blockchain nodes agree on new blocks and keep the same state. It works with a BFT consensus process in which validators make proposals, vote, and only commit a block when more than two-thirds of the voting power approves the same block.

The strength is mainly in the division of labor. CometBFT handles consensus, P2P communication, and block production, while the application behind ABCI defines the blockchain rules. Combined with Cosmos SDK, developers can build their own blockchain application without having to create the full consensus layer themselves.

At the same time, real-world use still matters. Security depends on validator voting power, reliable networks, well-secured keys, and an application that always calculates the same result. So CometBFT provides a strong technical base, but how a chain ultimately works always depends on how that base is used.