Skip to main content
CometBFT can be configured via a TOML file in $CMTHOME/config/config.toml. Some of these parameters can be overridden by command-line flags. For most users, the options in the ##### main base configuration options ##### are intended to be modified while config options further below are intended for advance power users.

Options

The default configuration file create by cometbft init has all the parameters set with their default values. It will look something like the file below, however, double check by inspecting the config.toml created with your version of cometbft installed:

Empty blocks VS no empty blocks

create_empty_blocks = true

If create_empty_blocks is set to true in your config, blocks will be created ~ every second (with default consensus parameters). You can regulate the delay between blocks by changing the timeout_commit. E.g. timeout_commit = "10s" should result in ~ 10 second blocks.

create_empty_blocks = false

In this setting, blocks are created when transactions received. Note after the block H, CometBFT creates something we call a “proof block” (only if the application hash changed) H+1. The reason for this is to support proofs. If you have a transaction in block H that changes the state to X, the new application hash will only be included in block H+1. If after your transaction is committed, you want to get a light-client proof for the new state (X), you need the new block to be committed in order to do that because the new block has the new application hash for the state X. That’s why we make a new (empty) block if the application hash changes. Otherwise, you won’t be able to make a proof for the new state. Plus, if you set create_empty_blocks_interval to something other than the default (0), CometBFT will be creating empty blocks even in the absence of transactions every create_empty_blocks_interval. For instance, with create_empty_blocks = false and create_empty_blocks_interval = "30s", CometBFT will only create blocks if there are transactions, or after waiting 30 seconds without receiving any transactions.

Consensus timeouts explained

There’s a variety of information about timeouts in Running in production. You can also find more detailed explanation in the paper describing the Tendermint consensus algorithm, adopted by CometBFT: The latest gossip on BFT consensus.
Note that in a successful round, the only timeout that we absolutely wait no matter what is timeout_commit. Here’s a brief summary of the timeouts:
  • timeout_propose = how long a validator should wait for a proposal block before prevoting nil
  • timeout_propose_delta = how much timeout_propose increases with each round
  • timeout_prevote = how long a validator should wait after receiving +2/3 prevotes for anything (ie. not a single block or nil)
  • timeout_prevote_delta = how much the timeout_prevote increases with each round
  • timeout_precommit = how long a validator should wait after receiving +2/3 precommits for anything (ie. not a single block or nil)
  • timeout_precommit_delta = how much the timeout_precommit increases with each round
  • timeout_commit = how long a validator should wait after committing a block, before starting on the new height (this gives us a chance to receive some more precommits, even though we already have +2/3)