mirror of
https://github.com/fluencelabs/tendermint
synced 2025-04-25 14:52:17 +00:00
Merge branch 'master' into marko/v0.32.1
This commit is contained in:
commit
e5084a4787
@ -297,11 +297,9 @@ Commit are included in the header of the next block.
|
||||
- **Request**:
|
||||
- `Tx ([]byte)`: The request transaction bytes
|
||||
- `Type (CheckTxType)`: What type of `CheckTx` request is this? At present,
|
||||
there are two possible values: `CheckTx_Unchecked` (the default, which says
|
||||
that a full check is required), and `CheckTx_Checked` (when the mempool is
|
||||
there are two possible values: `CheckTx_New` (the default, which says
|
||||
that a full check is required), and `CheckTx_Recheck` (when the mempool is
|
||||
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**:
|
||||
- `Code (uint32)`: Response code
|
||||
- `Data ([]byte)`: Result bytes, if any.
|
||||
|
@ -65,7 +65,10 @@ begin.
|
||||
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
|
||||
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.
|
||||
|
||||
|
@ -20,7 +20,7 @@ Initialize the root directory by running:
|
||||
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
|
||||
`$TMHOME/config`. This is all that's necessary to run a local testnet
|
||||
with one validator.
|
||||
@ -314,7 +314,7 @@ write-ahead-log](../tendermint-core/running-in-production.md#mempool-wal)
|
||||
## Tendermint Networks
|
||||
|
||||
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:
|
||||
|
||||
```
|
||||
@ -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.
|
||||
Note the `last_` fields, which are used to prevent us from signing
|
||||
conflicting messages.
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
`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
|
||||
but must be positive, thus the range is: 0 through 9223372036854775807.
|
||||
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`,
|
||||
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
|
||||
```
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
Now run `tendermint node` on both machines, and use either
|
||||
|
Loading…
x
Reference in New Issue
Block a user