Tendermint Core can be configured via a TOML file in
$TMHOME/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.
The default configuration file create by
tendermint 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
# Empty blocks VS no empty blocks
# create-empty-blocks = true
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 = "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, Tendermint 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
0), Tendermint will be creating empty blocks even in the absence of
create-empty-blocks-interval. For instance, with
create-empty-blocks = false and
create-empty-blocks-interval = "30s",
Tendermint 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 technical explanation in the spec: The latest gossip on BFT consensus (opens new window).
Note that in a successful round, the only timeout that we absolutely wait no
matter what is
Here's a brief summary of the timeouts:
timeout-propose= how long we wait for a proposal block before prevoting nil
timeout-propose-delta= how much timeout-propose increases with each round
timeout-prevote= how long we 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 we 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 we 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)
# P2P settings
This section will cover settings within the p2p section of the
external-address= is the address that will be advertised for other nodes to use. We recommend setting this field with your public IP and p2p port.
We recommend setting an external address. When used in a private network, Tendermint Core currently doesn't advertise the node's public address. There is active and ongoing work to improve the P2P system, but this is a helpful workaround for now.
seeds= is a list of comma separated seed nodes that you will connect upon a start and ask for peers. A seed node is a node that does not participate in consensus but only helps propagate peers to nodes in the networks
persistent-peers= is a list of comma separated peers that you will always want to be connected to. If you're already connected to the maximum number of peers, persistent peers will not be added.
max-num-inbound-peers= is the maximum number of peers you will accept inbound connections from at one time (where they dial your address and initiate the connection).
max-num-outbound-peers= is the maximum number of peers you will initiate outbound connects to at one time (where you dial their address and initiate the connection).
unconditional-peer-ids= is similar to
persistent-peersexcept that these peers will be connected to even if you are already connected to the maximum number of peers. This can be a validator node ID on your sentry node.
pex= turns the peer exchange reactor on or off. Validator node will want the
pexturned off so it would not begin gossiping to unknown peers on the network. PeX can also be turned off for statically configured networks with fixed network connectivity. For full nodes on open, dynamic networks, it should be turned on.
private-peer-ids= is a comma-separated list of node ids that will not be exposed to other peers (i.e., you will not tell other peers about the ids in this list). This can be filled with a validator's node id.