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.
# 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 parameters 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 default 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.
# Unsafe Consensus Timeout Overrides
Tendermint version v0.36 provides a set of unsafe overrides for the consensus timing parameters. These parameters are provided as a safety measure in case of unusual timing issues during the upgrade to v0.36 so that an operator may override the timings for a single node. These overrides will completely be removed in Tendermint v0.37.
unsafe-propose-override: How long the Tendermint consensus engine will wait for a proposal block before prevoting nil.
unsafe-propose-delta-override: How much the propose timeout increase with each round.
unsafe-vote-override: How long the consensus engine will wait after receiving +2/3 votes in a round.
unsafe-vote-delta-override: How much the vote timeout increases with each round.
unsafe-commit-override: How long the consensus engine will wait after receiving +2/3 precommits before beginning the next height.
unsafe-bypass-commit-timeout-override: Configures if the consensus engine will wait for the full commit timeout before proceeding to the next height. If this field is set to true, the consensus engine will proceed to the next height as soon as the node has gathered votes from all of the validators on the network.