certusone
/
tendermint
mirror of https://github.com/certusone/tendermint.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

document the maximum supported voting power due to overflow [ci skip] 

Refs #1075
This commit is contained in:
Anton Kaliaev 2018-01-09 12:18:50 -06:00 committed by Ethan Buchman
parent c521f385a6
commit c79ba3c349
1 changed files with 18 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/using-tendermint.rst
View File

@ -127,10 +127,14 @@ Some fields from the config file can be overwritten with flags.
No Empty Blocks No Empty Blocks
--------------- ---------------
This much requested feature was implemented in version 0.10.3. While the default behaviour of ``tendermint`` is still to create blocks approximately once per second, it is possible to disable empty blocks or set a block creation interval. In the former case, blocks will be created when there are new transactions or when the AppHash changes. This much requested feature was implemented in version 0.10.3. While the
default behaviour of ``tendermint`` is still to create blocks approximately
once per second, it is possible to disable empty blocks or set a block creation
interval. In the former case, blocks will be created when there are new
transactions or when the AppHash changes.
To configure tendermint to not produce empty blocks unless there are txs or the app hash changes, To configure tendermint to not produce empty blocks unless there are
run tendermint with this additional flag: transactions or the app hash changes, run tendermint with this additional flag:
:: ::
@ -246,13 +250,17 @@ conflicting messages.
Note also that the ``pub_key`` (the public key) in the Note also that the ``pub_key`` (the public key) in the
``priv_validator.json`` is also present in the ``genesis.json``. ``priv_validator.json`` is also present in the ``genesis.json``.
The genesis file contains the list of public keys which may participate The genesis file contains the list of public keys which may participate in the
in the consensus, and their corresponding voting power. Greater than 2/3 consensus, and their corresponding voting power. Greater than 2/3 of the voting
of the voting power must be active (ie. the corresponding private keys power must be active (ie. the corresponding private keys must be producing
must be producing signatures) for the consensus to make progress. In our signatures) for the consensus to make progress. In our case, the genesis file
case, the genesis file contains the public key of our contains the public key of our ``priv_validator.json``, so a tendermint node
``priv_validator.json``, so a tendermint node started with the default started with the default root directory will be able to make progress. Voting
root directory will be able to make new blocks, as we've already seen. power uses an `int64` but must be positive, thus the range is: 0 through
9223372036854775807. Because of how the current proposer selection algorithm works,
we do not recommend having voting powers greater than 10^12 (ie. 1 trillion)
(see `Proposals section of Byzantine Consensus Algorithm
<./specification/byzantine-consensus-algorithm.html#proposals>`__ for details).
If we want to add more nodes to the network, we have two choices: we can If we want to add more nodes to the network, we have two choices: we can
add a new validator node, who will also participate in the consensus by add a new validator node, who will also participate in the consensus by