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.
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.
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.
Recently the Tendermint Team conducted a refactor of the p2p layer. This lead to multiple config paramters being deprecated and/or replaced.
We will cover the new and deprecated parameters below.
# New Parameters
There are three new parameters, which are enabled if use-legacy is set to false.
queue-type= sets a type of queue to use in the p2p layer. There are three options available
wdrr. The default is priority
bootstrap-peers= is a list of comma seperated peers which will be used to bootstrap the address book.
max-connections= is the max amount of allowed inbound and outbound connections.
# Deprecated Parameters
Note: For Tendermint 0.35, there are two p2p implementations. The old version is used by deafult with the deprecated fields. The new implementation uses different config parameters, explained above.
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). This was replaced by
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).This was replaced by
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. Deprecated
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 Deprecated, replaced by bootstrap peers
# Indexing Settings
Operators can configure indexing via the
[tx_index] section. The
field takes a series of supported indexers. If
null is included, indexing will
be turned off regardless of other values provided.
# Supported Indexers
kv indexer type is an embedded key-value store supported by the main
underlying Tendermint database. Using the
kv indexer type allows you to query
for block and transaction events directly against Tendermint's RPC. However, the
query syntax is limited and so this indexer type might be deprecated or removed
entirely in the future.
psql indexer type allows an operator to enable block and transaction event
indexing by proxying it to an external PostgreSQL instance allowing for the events
to be stored in relational models. Since the events are stored in a RDBMS, operators
can leverage SQL to perform a series of rich and complex queries that are not
supported by the
kv indexer type. Since operators can leverage SQL directly,
searching is not enabled for the
psql indexer type via Tendermint's RPC -- any
such query will fail.
Note, the SQL schema is stored in
state/indexer/sink/psql/schema.sql and operators
must explicitly create the relations prior to starting Tendermint and enabling
psql indexer type.