From c79ba3c3494cb9b07bf30275af48b35b9b4acd8b Mon Sep 17 00:00:00 2001 From: Anton Kaliaev Date: Tue, 9 Jan 2018 12:18:50 -0600 Subject: [PATCH] document the maximum supported voting power due to overflow [ci skip] Refs #1075 --- docs/using-tendermint.rst | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/docs/using-tendermint.rst b/docs/using-tendermint.rst index 9076230e..086a2570 100644 --- a/docs/using-tendermint.rst +++ b/docs/using-tendermint.rst @@ -127,10 +127,14 @@ Some fields from the config file can be overwritten with flags. 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, -run tendermint with this additional flag: +To configure tendermint to not produce empty blocks unless there are +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 ``priv_validator.json`` is also present in the ``genesis.json``. -The genesis file contains the list of public keys which may participate -in the consensus, and their corresponding voting power. Greater than 2/3 -of the voting power must be active (ie. the corresponding private keys -must be producing signatures) for the consensus to make progress. In our -case, the genesis file contains the public key of our -``priv_validator.json``, so a tendermint node started with the default -root directory will be able to make new blocks, as we've already seen. +The genesis file contains the list of public keys which may participate in the +consensus, and their corresponding voting power. Greater than 2/3 of the voting +power must be active (ie. the corresponding private keys must be producing +signatures) for the consensus to make progress. In our case, the genesis file +contains the public key of our ``priv_validator.json``, so a tendermint node +started with the default root directory will be able to make progress. Voting +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 add a new validator node, who will also participate in the consensus by