fluencelabs/tendermint
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint synced 2025-04-25 14:52:17 +00:00
Code Issues Projects Releases Wiki Activity

Merge branch 'master' into marko/v0.32.1

Browse Source
This commit is contained in:
Marko Baricevic 2019-07-12 15:51:14 +02:00
commit e5084a4787
3 changed files with 16 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/spec/abci/abci.md
View File

@ -297,11 +297,9 @@ Commit are included in the header of the next block.
- **Request**: - **Request**:
- `Tx ([]byte)`: The request transaction bytes - `Tx ([]byte)`: The request transaction bytes
- `Type (CheckTxType)`: What type of `CheckTx` request is this? At present, - `Type (CheckTxType)`: What type of `CheckTx` request is this? At present,
there are two possible values: `CheckTx_Unchecked` (the default, which says there are two possible values: `CheckTx_New` (the default, which says
that a full check is required), and `CheckTx_Checked` (when the mempool is that a full check is required), and `CheckTx_Recheck` (when the mempool is
initiating a normal recheck of a transaction). initiating a normal recheck of a transaction).
- `AdditionalData ([]byte)`: Reserved for future use. See
[here](https://github.com/tendermint/tendermint/issues/2127#issuecomment-456661420).
- **Response**: - **Response**:
- `Code (uint32)`: Response code - `Code (uint32)`: Response code
- `Data ([]byte)`: Result bytes, if any. - `Data ([]byte)`: Result bytes, if any.

5
docs/spec/abci/apps.md
View File

@ -65,7 +65,10 @@ begin.
After `Commit`, CheckTx is run again on all transactions that remain in the After `Commit`, CheckTx is run again on all transactions that remain in the
node's local mempool after filtering those included in the block. To prevent the node's local mempool after filtering those included in the block. To prevent the
mempool from rechecking all transactions every time a block is committed, set mempool from rechecking all transactions every time a block is committed, set
the configuration option `mempool.recheck=false`. the configuration option `mempool.recheck=false`. As of Tendermint v0.32.1,
an additional `Type` parameter is made available to the CheckTx function that
indicates whether an incoming transaction is new (`CheckTxType_New`), or a
recheck (`CheckTxType_Recheck`).
Finally, the mempool will unlock and new transactions can be processed through CheckTx again. Finally, the mempool will unlock and new transactions can be processed through CheckTx again.

20
docs/tendermint-core/using-tendermint.md
View File

@ -20,7 +20,7 @@ Initialize the root directory by running:
tendermint init tendermint init
``` ```
This will create a new private key (`priv_validator.json`), and a This will create a new private key (`priv_validator_key.json`), and a
genesis file (`genesis.json`) containing the associated public key, in genesis file (`genesis.json`) containing the associated public key, in
`$TMHOME/config`. This is all that's necessary to run a local testnet `$TMHOME/config`. This is all that's necessary to run a local testnet
with one validator. with one validator.
@ -314,7 +314,7 @@ write-ahead-log](../tendermint-core/running-in-production.md#mempool-wal)
## Tendermint Networks ## Tendermint Networks
When `tendermint init` is run, both a `genesis.json` and When `tendermint init` is run, both a `genesis.json` and
`priv_validator.json` are created in `~/.tendermint/config`. The `priv_validator_key.json` are created in `~/.tendermint/config`. The
`genesis.json` might look like: `genesis.json` might look like:
``` ```
@ -335,7 +335,7 @@ When `tendermint init` is run, both a `genesis.json` and
} }
``` ```
And the `priv_validator.json`: And the `priv_validator_key.json`:
``` ```
{ {
@ -354,20 +354,20 @@ And the `priv_validator.json`:
} }
``` ```
The `priv_validator.json` actually contains a private key, and should The `priv_validator_key.json` actually contains a private key, and should
thus be kept absolutely secret; for now we work with the plain text. thus be kept absolutely secret; for now we work with the plain text.
Note the `last_` fields, which are used to prevent us from signing Note the `last_` fields, which are used to prevent us from signing
conflicting messages. 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_key.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 consensus, and their corresponding voting power. Greater than 2/3 in the consensus, and their corresponding voting power. Greater than 2/3
of the voting power must be active (i.e. the corresponding private keys of the voting power must be active (i.e. the corresponding private keys
must be producing signatures) for the consensus to make progress. In our must be producing signatures) for the consensus to make progress. In our
case, the genesis file contains the public key of our case, the genesis file contains the public key of our
`priv_validator.json`, so a Tendermint node started with the default `priv_validator_key.json`, so a Tendermint node started with the default
root directory will be able to make progress. Voting power uses an int64 root directory will be able to make progress. Voting power uses an int64
but must be positive, thus the range is: 0 through 9223372036854775807. but must be positive, thus the range is: 0 through 9223372036854775807.
Because of how the current proposer selection algorithm works, we do not Because of how the current proposer selection algorithm works, we do not
@ -453,16 +453,16 @@ not connected to the other peer.
The easiest way to add new validators is to do it in the `genesis.json`, The easiest way to add new validators is to do it in the `genesis.json`,
before starting the network. For instance, we could make a new before starting the network. For instance, we could make a new
`priv_validator.json`, and copy it's `pub_key` into the above genesis. `priv_validator_key.json`, and copy it's `pub_key` into the above genesis.
We can generate a new `priv_validator.json` with the command: We can generate a new `priv_validator_key.json` with the command:
``` ```
tendermint gen_validator tendermint gen_validator
``` ```
Now we can update our genesis file. For instance, if the new Now we can update our genesis file. For instance, if the new
`priv_validator.json` looks like: `priv_validator_key.json` looks like:
``` ```
{ {
@ -510,7 +510,7 @@ then the new `genesis.json` will be:
``` ```
Update the `genesis.json` in `~/.tendermint/config`. Copy the genesis Update the `genesis.json` in `~/.tendermint/config`. Copy the genesis
file and the new `priv_validator.json` to the `~/.tendermint/config` on file and the new `priv_validator_key.json` to the `~/.tendermint/config` on
a new machine. a new machine.
Now run `tendermint node` on both machines, and use either Now run `tendermint node` on both machines, and use either