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.
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.
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.
seed_mode= is used for when node operators want to run their node as a seed node. Seed node's run a variation of the PeX protocol that disconnects from peers after sending them a list of peers to connect to. To minimize the servers usage, it is recommended to set the mempool's size to 0.
private_peer_ids= is a comma separated list of node ids that you would not like exposed to other peers (ie. you will not tell other peers about the private_peer_ids). This can be filled with a validators node id.