Browse Source

Merge remote-tracking branch 'origin/develop' into dev/multisig

pull/2164/head
ValarDragon 6 years ago
parent
commit
aab26c3ff7
31 changed files with 393 additions and 2573 deletions
  1. +1
    -1
      .github/CODEOWNERS
  2. +3
    -3
      abci/example/example_test.go
  3. +2
    -0
      crypto/multisig/compact_bit_array.go
  4. +4
    -4
      docs/README.md
  5. +2
    -2
      docs/app-dev/abci-cli.md
  6. +2
    -3
      docs/app-dev/app-architecture.md
  7. +183
    -0
      docs/architecture/adr-012-ABCI-propose-tx.md
  8. +150
    -0
      docs/architecture/adr-019-multisigs.md
  9. +0
    -0
      docs/imgs/a_plus_t.png
  10. +0
    -0
      docs/imgs/abci.png
  11. +0
    -0
      docs/imgs/consensus_logic.png
  12. +0
    -0
      docs/imgs/tm-application-example.png
  13. +0
    -0
      docs/imgs/tm-transaction-flow.png
  14. +0
    -0
      docs/imgs/tmint-logo-blue.png
  15. +5
    -5
      docs/introduction/introduction.md
  16. +6
    -5
      docs/introduction/quick-start.md
  17. +1
    -1
      docs/networks/deploy-testnets.md
  18. +1
    -1
      docs/spec/p2p/connection.md
  19. +2
    -2
      docs/spec/reactors/mempool/reactor.md
  20. +1
    -1
      docs/spec/software/abci.md
  21. +1
    -2
      docs/spec/software/wal.md
  22. +5
    -5
      docs/tendermint-core/how-to-read-logs.md
  23. +2
    -0
      docs/tendermint-core/rpc.md
  24. +10
    -9
      docs/tendermint-core/running-in-production.md
  25. +0
    -4
      docs/tendermint-core/secure-p2p.md
  26. +5
    -9
      docs/tendermint-core/using-tendermint.md
  27. +1
    -1
      docs/tools/monitoring.md
  28. +0
    -2507
      docs/yarn.lock
  29. +5
    -5
      libs/clist/clist_test.go
  30. +1
    -1
      mempool/mempool.go
  31. +0
    -2
      p2p/conn/connection_test.go

+ 1
- 1
.github/CODEOWNERS View File

@ -4,4 +4,4 @@
* @ebuchman @melekes @xla
# Precious documentation
/docs/ @zramsay @jolesbi
/docs/ @zramsay

+ 3
- 3
abci/example/example_test.go View File

@ -39,7 +39,7 @@ func TestGRPC(t *testing.T) {
}
func testStream(t *testing.T, app types.Application) {
numDeliverTxs := 200000
numDeliverTxs := 20000
// Start the listener
server := abciserver.NewSocketServer("unix://test.sock", app)
@ -72,7 +72,7 @@ func testStream(t *testing.T, app types.Application) {
}
if counter == numDeliverTxs {
go func() {
time.Sleep(time.Second * 2) // Wait for a bit to allow counter overflow
time.Sleep(time.Second * 1) // Wait for a bit to allow counter overflow
close(done)
}()
return
@ -148,7 +148,7 @@ func testGRPCSync(t *testing.T, app *types.GRPCApplication) {
t.Log("response", counter)
if counter == numDeliverTxs {
go func() {
time.Sleep(time.Second * 2) // Wait for a bit to allow counter overflow
time.Sleep(time.Second * 1) // Wait for a bit to allow counter overflow
}()
}


+ 2
- 0
crypto/multisig/compact_bit_array.go View File

@ -37,6 +37,8 @@ func (bA *CompactBitArray) Size() int {
} else if bA.ExtraBitsStored == byte(0) {
return len(bA.Elems) * 8
}
// num_bits = 8*num_full_bytes + overflow_in_last_byte
// num_full_bytes = (len(bA.Elems)-1)
return (len(bA.Elems)-1)*8 + int(bA.ExtraBitsStored)
}


+ 4
- 4
docs/README.md View File

@ -11,17 +11,17 @@ replicates it on many machines. In other words, a blockchain.
Tendermint requires an application running over the Application Blockchain
Interface (ABCI) - and comes packaged with an example application to do so.
Follow the [installation instructions](./introduction/install) to get up and running
quickly. For more details on [using tendermint](./tendermint-core/using-tendermint) see that
Follow the [installation instructions](./introduction/install.md) to get up and running
quickly. For more details on [using tendermint](./tendermint-core/using-tendermint.md) see that
and the following sections.
## Networks
Testnets can be setup manually on one or more machines, or automatically on one
or more machine, using a variety of methods described in the [deploy testnets
section](./networks/deploy-testnets).
section](./networks/deploy-testnets.md).
## Application Development
The first step to building application on Tendermint is to [install
ABCI-CLI](./app-dev/getting-started) and play with the example applications.
ABCI-CLI](./app-dev/getting-started.md) and play with the example applications.

+ 2
- 2
docs/app-dev/abci-cli.md View File

@ -36,7 +36,7 @@ Available Commands:
console Start an interactive abci console for multiple commands
counter ABCI demo example
deliver_tx Deliver a new tx to the application
kvstore ABCI demo example
kvstore ABCI demo example
echo Have the application echo a message
help Help about any command
info Get some info about the application
@ -140,7 +140,7 @@ response.
The server may be generic for a particular language, and we provide a
[reference implementation in
Golang](https://github.com/tendermint/tendermint/tree/develop/abci/server). See the
[list of other ABCI implementations](./ecosystem.html) for servers in
[list of other ABCI implementations](./ecosystem.md) for servers in
other languages.
The handler is specific to the application, and may be arbitrary, so


+ 2
- 3
docs/app-dev/app-architecture.md View File

@ -46,6 +46,5 @@ See the following for more extensive documentation:
- [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1028)
- [Tendermint RPC Docs](https://tendermint.github.io/slate/)
- [Tendermint in Production](https://github.com/tendermint/tendermint/pull/1618)
- [Tendermint Basics](https://tendermint.readthedocs.io/en/master/using-tendermint.html)
- [ABCI spec](https://github.com/tendermint/tendermint/blob/develop/abci/docs/abci-spec.md)
- [Tendermint in Production](../tendermint-core/running-in-production.md)
- [ABCI spec](./abci-spec.md)

+ 183
- 0
docs/architecture/adr-012-ABCI-propose-tx.md View File

@ -0,0 +1,183 @@
# ADR 012: ABCI `ProposeTx` Method
## Changelog
25-06-2018: Initial draft based on [#1776](https://github.com/tendermint/tendermint/issues/1776)
## Context
[#1776](https://github.com/tendermint/tendermint/issues/1776) was
opened in relation to implementation of a Plasma child chain using Tendermint
Core as consensus/replication engine.
Due to the requirements of [Minimal Viable Plasma (MVP)](https://ethresear.ch/t/minimal-viable-plasma/426) and [Plasma Cash](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298), it is necessary for ABCI apps to have a mechanism to handle the following cases (more may emerge in the near future):
1. `deposit` transactions on the Root Chain, which must consist of a block
with a single transaction, where there are no inputs and only one output
made in favour of the depositor. In this case, a `block` consists of
a transaction with the following shape:
```
[0, 0, 0, 0, #input1 - zeroed out
0, 0, 0, 0, #input2 - zeroed out
<depositor_address>, <amount>, #output1 - in favour of depositor
0, 0, #output2 - zeroed out
<fee>,
]
```
`exit` transactions may also be treated in a similar manner, wherein the
input is the UTXO being exited on the Root Chain, and the output belongs to
a reserved "burn" address, e.g., `0x0`. In such cases, it is favourable for
the containing block to only hold a single transaction that may receive
special treatment.
2. Other "internal" transactions on the child chain, which may be initiated
unilaterally. The most basic example of is a coinbase transaction
implementing validator node incentives, but may also be app-specific. In
these cases, it may be favourable for such transactions to
be ordered in a specific manner, e.g., coinbase transactions will always be
at index 0. In general, such strategies increase the determinism and
predictability of blockchain applications.
While it is possible to deal with the cases enumerated above using the
existing ABCI, currently available result in suboptimal workarounds. Two are
explained in greater detail below.
### Solution 1: App state-based Plasma chain
In this work around, the app maintains a `PlasmaStore` with a corresponding
`Keeper`. The PlasmaStore is responsible for maintaing a second, separate
blockchain that complies with the MVP specification, including `deposit`
blocks and other "internal" transactions. These "virtual" blocks are then broadcasted
to the Root Chain.
This naive approach is, however, fundamentally flawed, as it by definition
diverges from the canonical chain maintained by Tendermint. This is further
exacerbated if the business logic for generating such transactions is
potentially non-deterministic, as this should not even be done in
`Begin/EndBlock`, which may, as a result, break consensus guarantees.
Additinoally, this has serious implications for "watchers" - independent third parties,
or even an auxilliary blockchain, responsible for ensuring that blocks recorded
on the Root Chain are consistent with the Plasma chain's. Since, in this case,
the Plasma chain is inconsistent with the canonical one maintained by Tendermint
Core, it seems that there exists no compact means of verifying the legitimacy of
the Plasma chain without replaying every state transition from genesis (!).
### Solution 2: Broadcast to Tendermint Core from ABCI app
This approach is inspired by `tendermint`, in which Ethereum transactions are
relayed to Tendermint Core. It requires the app to maintain a client connection
to the consensus engine.
Whenever an "internal" transaction needs to be created, the proposer of the
current block broadcasts the transaction or transactions to Tendermint as
needed in order to ensure that the Tendermint chain and Plasma chain are
completely consistent.
This allows "internal" transactions to pass through the full consensus
process, and can be validated in methods like `CheckTx`, i.e., signed by the
proposer, is the semantically correct, etc. Note that this involves informing
the ABCI app of the block proposer, which was temporarily hacked in as a means
of conducting this experiment, although this should not be necessary when the
current proposer is passed to `BeginBlock`.
It is much easier to relay these transactions directly to the Root
Chain smart contract and/or maintain a "compressed" auxiliary chain comprised
of Plasma-friendly blocks that 100% reflect the canonical (Tendermint)
blockchain. Unfortunately, this approach not idiomatic (i.e., utilises the
Tendermint consensus engine in unintended ways). Additionally, it does not
allow the application developer to:
- Control the _ordering_ of transactions in the proposed block (e.g., index 0,
or 0 to `n` for coinbase transactions)
- Control the _number_ of transactions in the block (e.g., when a `deposit`
block is required)
Since determinism is of utmost importance in blockchain engineering, this approach,
while more viable, should also not be considered as fit for production.
## Decision
### `ProposeTx`
In order to address the difficulties described above, the ABCI interface must
expose an additional method, tentatively named `ProposeTx`.
It should have the following signature:
```
ProposeTx(RequestProposeTx) ResponseProposeTx
```
Where `RequestProposeTx` and `ResponseProposeTx` are `message`s with the
following shapes:
```
message RequestProposeTx {
int64 next_block_height = 1; // height of the block the proposed tx would be part of
Validator proposer = 2; // the proposer details
}
message ResponseProposeTx {
int64 num_tx = 1; // the number of tx to include in proposed block
repeated bytes txs = 2; // ordered transaction data to include in block
bool exclusive = 3; // whether the block should include other transactions (from `mempool`)
}
```
`ProposeTx` would be called by before `mempool.Reap` at this
[line](https://github.com/tendermint/tendermint/blob/master/consensus/state.go#L906).
Depending on whether `exclusive` is `true` or `false`, the proposed
transactions are then pushed on top of the transactions received from
`mempool.Reap`.
### `DeliverTx`
Since the list of `tx` received from `ProposeTx` are _not_ passed through `CheckTx`,
it is probably a good idea to provide a means of differentiatiating "internal" transactions
from user-generated ones, in case the app developer needs/wants to take extra measures to
ensure validity of the proposed transactions.
Therefore, the `RequestDeliverTx` message should be changed to provide an additional flag, like so:
```
message RequestDeliverTx {
bytes tx = 1;
bool internal = 2;
}
```
Alternatively, an additional method `DeliverProposeTx` may be added as an accompanient to
`ProposeTx`. However, it is not clear at this stage if this additional overhead is necessary
to preserve consensus guarantees given that a simple flag may suffice for now.
## Status
Pending
## Consequences
### Positive
- Tendermint ABCI apps will be able to function as minimally viable Plasma chains.
- It will thereby become possible to add an extension to `cosmos-sdk` to enable
ABCI apps to support both IBC and Plasma, maximising interop.
- ABCI apps will have great control and flexibility in managing blockchain state,
without having to resort to non-deterministic hacks and/or unsafe workarounds
### Negative
- Maintenance overhead of exposing additional ABCI method
- Potential security issues that may have been overlooked and must now be tested extensively
### Neutral
- ABCI developers must deal with increased (albeit nominal) API surface area.
## References
- [#1776 Plasma and "Internal" Transactions in ABCI Apps](https://github.com/tendermint/tendermint/issues/1776)
- [Minimal Viable Plasma](https://ethresear.ch/t/minimal-viable-plasma/426)
- [Plasma Cash: Plasma with much less per-user data checking](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298)

+ 150
- 0
docs/architecture/adr-019-multisigs.md View File

@ -0,0 +1,150 @@
# ADR 019: Encoding standard for Multisignatures
## Changelog
06-08-2018: Minor updates
27-07-2018: Update draft to use amino encoding
11-07-2018: Initial Draft
## Context
Multisignatures, or technically _Accountable Subgroup Multisignatures_ (ASM),
are signature schemes which enable any subgroup of a set of signers to sign any message,
and reveal to the verifier exactly who the signers were.
This allows for complex conditionals of when to validate a signature.
Suppose the set of signers is of size _n_.
If we validate a signature if any subgroup of size _k_ signs a message,
this becomes what is commonly reffered to as a _k of n multisig_ in Bitcoin.
This ADR specifies the encoding standard for general accountable subgroup multisignatures,
k of n accountable subgroup multisignatures, and its weighted variant.
In the future, we can also allow for more complex conditionals on the accountable subgroup.
## Proposed Solution
### New structs
Every ASM will then have its own struct, implementing the crypto.Pubkey interface.
This ADR assumes that [replacing crypto.Signature with []bytes](https://github.com/tendermint/tendermint/issues/1957) has been accepted.
#### K of N threshold signature
The pubkey is the following struct:
```golang
type ThresholdMultiSignaturePubKey struct { // K of N threshold multisig
K uint `json:"threshold"`
Pubkeys []crypto.Pubkey `json:"pubkeys"`
}
```
We will derive N from the length of pubkeys. (For spatial efficiency in encoding)
`Verify` will expect an `[]byte` encoded version of the Multisignature.
(Multisignature is described in the next section)
The multisignature will be rejected if the bitmap has less than k indices,
or if any signature at any of the k indices is not a valid signature from
the kth public key on the message.
(If more than k signatures are included, all must be valid)
`Bytes` will be the amino encoded version of the pubkey.
Address will be `Hash(amino_encoded_pubkey)`
The reason this doesn't use `log_8(n)` bytes per signer is because that heavily optimizes for the case where a very small number of signers are required.
e.g. for `n` of size `24`, that would only be more space efficient for `k < 3`.
This seems less likely, and that it should not be the case optimized for.
#### Weighted threshold signature
The pubkey is the following struct:
```golang
type WeightedThresholdMultiSignaturePubKey struct {
Weights []uint `json:"weights"`
Threshold uint `json:"threshold"`
Pubkeys []crypto.Pubkey `json:"pubkeys"`
}
```
Weights and Pubkeys must be of the same length.
Everything else proceeds identically to the K of N multisig,
except the multisig fails if the sum of the weights is less than the threshold.
#### Multisignature
The inter-mediate phase of the signatures (as it accrues more signatures) will be the following struct:
```golang
type Multisignature struct {
BitArray CryptoBitArray // Documented later
Sigs [][]byte
```
It is important to recall that each private key will output a signature on the provided message itself.
So no signing algorithm ever outputs the multisignature.
The UI will take a signature, cast into a multisignature, and then keep adding
new signatures into it, and when done marshal into `[]byte`.
This will require the following helper methods:
```golang
func SigToMultisig(sig []byte, n int)
func GetIndex(pk crypto.Pubkey, []crypto.Pubkey)
func AddSignature(sig Signature, index int, multiSig *Multisignature)
```
The multisignature will be converted to an `[]byte` using amino.MarshalBinaryBare. \*
#### Bit Array
We would be using a new implementation of a bitarray. The struct it would be encoded/decoded from is
```golang
type CryptoBitArray struct {
ExtraBitsStored byte `json:"extra_bits"` // The number of extra bits in elems.
Elems []byte `json:"elems"`
}
```
The reason for not using the BitArray currently implemented in `libs/common/bit_array.go`
is that it is less space efficient, due to a space / time trade-off.
Evidence for this is outlined in [this issue](https://github.com/tendermint/tendermint/issues/2077).
In the multisig, we will not be performing arithmetic operations,
so there is no performance increase with the current implementation,
and just loss of spatial efficiency.
Implementing this new bit array with `[]byte` _should_ be simple, as no
arithmetic operations between bit arrays are required, and save a couple of bytes.
(Explained in that same issue)
When this bit array encoded, the number of elements is encoded due to amino.
However we may be encoding a full byte for what we actually only need 1-7 bits for.
We store that difference in ExtraBitsStored.
This allows for us to have an unbounded number of signers, and is more space efficient than what is currently used in `libs/common`.
Again the implementation of this space saving feature is straight forward.
### Encoding the structs
We will use straight forward amino encoding. This is chosen for ease of compatibility in other languages.
### Future points of discussion
If desired, we can use ed25519 batch verification for all ed25519 keys.
This is a future point of discussion, but would be backwards compatible as this information won't need to be marshalled.
(There may even be cofactor concerns without ristretto)
Aggregation of pubkeys / sigs in Schnorr sigs / BLS sigs is not backwards compatible, and would need to be a new ASM type.
## Status
Proposed.
## Consequences
### Positive
* Supports multisignatures, in a way that won't require any special cases in our downstream verification code.
* Easy to serialize / deserialize
* Unbounded number of signers
### Negative
* Larger codebase, however this should reside in a subfolder of tendermint/crypto, as it provides no new interfaces. (Ref #https://github.com/tendermint/go-crypto/issues/136)
* Space inefficient due to utilization of amino encoding
* Suggested implementation requires a new struct for every ASM.
### Neutral

docs/assets/a_plus_t.png → docs/imgs/a_plus_t.png View File


docs/assets/abci.png → docs/imgs/abci.png View File


docs/assets/consensus_logic.png → docs/imgs/consensus_logic.png View File


docs/assets/tm-application-example.png → docs/imgs/tm-application-example.png View File


docs/assets/tm-transaction-flow.png → docs/imgs/tm-transaction-flow.png View File


docs/assets/tmint-logo-blue.png → docs/imgs/tmint-logo-blue.png View File


+ 5
- 5
docs/introduction/introduction.md View File

@ -90,7 +90,7 @@ it can be used as a plug-and-play replacement for the consensus engines
of other blockchain software. So one can take the current Ethereum code
base, whether in Rust, or Go, or Haskell, and run it as a ABCI
application using Tendermint consensus. Indeed, [we did that with
Ethereum](https://github.com/tendermint/ethermint). And we plan to do
Ethereum](https://github.com/cosmos/ethermint). And we plan to do
the same for Bitcoin, ZCash, and various other deterministic
applications as well.
@ -227,7 +227,7 @@ design their message handlers to create a blockchain that does anything
useful but this architecture provides a place to start. The diagram
below illustrates the flow of messages via ABCI.
![](assets/abci.png)
![](imgs/abci.png)
## A Note on Determinism
@ -263,7 +263,7 @@ Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus
protocol. The protocol follows a simple state machine that looks like
this:
![](assets/consensus_logic.png)
![](imgs/consensus_logic.png)
Participants in the protocol are called **validators**; they take turns
proposing blocks of transactions and voting on them. Blocks are
@ -321,7 +321,7 @@ consensus protocol. This adds an economic element to the security of the
protocol, allowing one to quantify the cost of violating the assumption
that less than one-third of voting power is Byzantine.
The [Cosmos Network](http://cosmos.network) is designed to use this
The [Cosmos Network](https://cosmos.network) is designed to use this
Proof-of-Stake mechanism across an array of cryptocurrencies implemented
as ABCI applications.
@ -329,4 +329,4 @@ The following diagram is Tendermint in a (technical) nutshell. [See here
for high resolution
version](https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf).
![](assets/tm-transaction-flow.png)
![](imgs/tm-transaction-flow.png)

+ 6
- 5
docs/introduction/quick-start.md View File

@ -26,7 +26,7 @@ Requires:
- `go` minimum version 1.10
- `$GOPATH` environment variable must be set
- `$GOPATH/bin` must be on your `$PATH` (see https://github.com/tendermint/tendermint/wiki/Setting-GOPATH)
- `$GOPATH/bin` must be on your `$PATH` (see [here](https://github.com/tendermint/tendermint/wiki/Setting-GOPATH))
To install Tendermint, run:
@ -43,9 +43,12 @@ Confirm installation:
```
$ tendermint version
0.23.0-dev
0.23.0
```
Note: see the [releases page](https://github.com/tendermint/tendermint/releases) and the latest version
should match what you see above.
## Initialization
Running:
@ -142,8 +145,6 @@ tendermint node --home ./mytestnet/node3 --proxy_app=kvstore --p2p.persistent_pe
Note that after the third node is started, blocks will start to stream in
because >2/3 of validators (defined in the `genesis.json`) have come online.
Seeds can also be specified in the `config.toml`. See [this
PR](https://github.com/tendermint/tendermint/pull/792) for more information
about configuration options.
Seeds can also be specified in the `config.toml`. See [here](../tendermint-core/configuration.md) for more information about configuration options.
Transactions can then be sent as covered in the single, local node example above.

+ 1
- 1
docs/networks/deploy-testnets.md View File

@ -71,4 +71,4 @@ local testnet. Review the target in the Makefile to debug any problems.
### Cloud
See the [next section](./terraform-and-ansible.html) for details.
See the [next section](./terraform-and-ansible.md) for details.

+ 1
- 1
docs/spec/p2p/connection.md View File

@ -38,7 +38,7 @@ type msgPacket struct {
}
```
The `msgPacket` is serialized using [go-wire](https://github.com/tendermint/go-wire) and prefixed with 0x3.
The `msgPacket` is serialized using [go-amino](https://github.com/tendermint/go-amino) and prefixed with 0x3.
The received `Bytes` of a sequential set of packets are appended together
until a packet with `EOF=1` is received, then the complete serialized message
is returned for processing by the `onReceive` function of the corresponding channel.


+ 2
- 2
docs/spec/reactors/mempool/reactor.md View File

@ -2,12 +2,12 @@
## Channels
[#1503](https://github.com/tendermint/tendermint/issues/1503)
See [this issue](https://github.com/tendermint/tendermint/issues/1503)
Mempool maintains a cache of the last 10000 transactions to prevent
replaying old transactions (plus transactions coming from other
validators, who are continually exchanging transactions). Read [Replay
Protection](https://tendermint.readthedocs.io/projects/tools/en/master/app-development.html?#replay-protection)
Protection](../../../../app-development.md#replay-protection)
for details.
Sending incorrectly encoded data or data exceeding `maxMsgSize` will result


+ 1
- 1
docs/spec/software/abci.md View File

@ -7,7 +7,7 @@ The ABCI message types are defined in a [protobuf
file](https://github.com/tendermint/tendermint/blob/develop/abci/types/types.proto).
For full details on the ABCI message types and protocol, see the [ABCI
specification](https://github.com/tendermint/tendermint/blob/develop/docs/abci-spec.md).
specification](https://github.com/tendermint/tendermint/blob/develop/docs/app-dev/abci-spec.md).
Be sure to read the specification if you're trying to build an ABCI app!
For additional details on server implementation, see the [ABCI


+ 1
- 2
docs/spec/software/wal.md View File

@ -28,6 +28,5 @@ WAL. Then it will go to precommit, and that time it will work because the
private validator contains the `LastSignBytes` and then we’ll replay the
precommit from the WAL.
Make sure to read about [WAL
corruption](https://tendermint.readthedocs.io/projects/tools/en/master/specification/corruption.html#wal-corruption)
Make sure to read about [WAL corruption](../../../tendermint-core/running-in-production.md#wal-corruption)
and recovery strategies.

+ 5
- 5
docs/tendermint-core/how-to-read-logs.md View File

@ -63,8 +63,8 @@ Next follows a standard block creation cycle, where we enter a new
round, propose a block, receive more than 2/3 of prevotes, then
precommits and finally have a chance to commit a block. For details,
please refer to [Consensus
Overview](./introduction.md#consensus-overview) or [Byzantine Consensus
Algorithm](./spec/consensus).
Overview](../introduction/introduction.md#consensus-overview) or [Byzantine Consensus
Algorithm](../spec/consensus/consensus.md).
```
I[10-04|13:54:30.393] enterNewRound(91/0). Current: 91/0/RoundStepNewHeight module=consensus
@ -112,7 +112,7 @@ I[10-04|13:54:30.410] Recheck txs module=mempoo
Here is the list of modules you may encounter in Tendermint's log and a
little overview what they do.
- `abci-client` As mentioned in [Application Development Guide](./app-development.md), Tendermint acts as an ABCI
- `abci-client` As mentioned in [Application Development Guide](../app-dev/app-development.md), Tendermint acts as an ABCI
client with respect to the application and maintains 3 connections:
mempool, consensus and query. The code used by Tendermint Core can
be found [here](https://github.com/tendermint/tendermint/tree/develop/abci/client).
@ -133,9 +133,9 @@ little overview what they do.
- `p2p` Provides an abstraction around peer-to-peer communication. For
more details, please check out the
[README](https://github.com/tendermint/tendermint/blob/master/p2p/README.md).
- `rpc` [Tendermint's RPC](./specification/rpc.md).
- `rpc` [Tendermint's RPC](./rpc.md).
- `rpc-server` RPC server. For implementation details, please read the
[README](https://github.com/tendermint/tendermint/blob/master/rpc/lib/README.md).
[doc.go](https://github.com/tendermint/tendermint/blob/master/rpc/lib/doc.go).
- `state` Represents the latest state and execution submodule, which
executes blocks against the application.
- `types` A collection of the publicly exposed types and methods to


+ 2
- 0
docs/tendermint-core/rpc.md View File

@ -1,3 +1,5 @@
# RPC
The RPC documentation is hosted [here](https://tendermint.github.io/slate) and is generated by the CI from our [Slate repo](https://github.com/tendermint/slate). To update the documentation, edit the relevant `godoc` comments in the [rpc/core directory](https://github.com/tendermint/tendermint/tree/develop/rpc/core).
NOTE: We will be moving the RPC documentation into the website in the near future. Stay tuned!

+ 10
- 9
docs/tendermint-core/running-in-production.md View File

@ -28,7 +28,7 @@ send & receive rate per connection (`SendRate`, `RecvRate`).
### RPC
Endpoints returning multiple entries are limited by default to return 30
elements (100 max).
elements (100 max). See [here](./rpc.md) for more information about the RPC.
Rate-limiting and authentication are another key aspects to help protect
against DOS attacks. While in the future we may implement these
@ -40,12 +40,12 @@ to achieve the same things.
## Debugging Tendermint
If you ever have to debug Tendermint, the first thing you should
probably do is to check out the logs. See ["How to read
logs"](./how-to-read-logs.md), where we explain what certain log
probably do is to check out the logs. See [How to read
logs](./how-to-read-logs.md), where we explain what certain log
statements mean.
If, after skimming through the logs, things are not clear still, the
second TODO is to query the /status RPC endpoint. It provides the
next thing to try is query the /status RPC endpoint. It provides the
necessary info: whenever the node is syncing or not, what height it is
on, etc.
@ -80,7 +80,7 @@ Other useful endpoints include mentioned earlier `/status`, `/net_info` and
We have a small tool, called `tm-monitor`, which outputs information from
the endpoints above plus some statistics. The tool can be found
[here](https://github.com/tendermint/tools/tree/master/tm-monitor).
[here](https://github.com/tendermint/tendermint/tree/master/tools/tm-monitor).
Tendermint also can report and serve Prometheus metrics. See
[Metrics](./metrics.md).
@ -206,14 +206,15 @@ operation systems (like Mac OS).
### Miscellaneous
NOTE: if you are going to use Tendermint in a public domain, make sure
you read [hardware recommendations (see "4.
Hardware")](https://cosmos.network/validators) for a validator in the
you read [hardware recommendations](https://cosmos.network/validators) for a validator in the
Cosmos network.
## Configuration parameters
- `p2p.flush_throttle_timeout` `p2p.max_packet_msg_payload_size`
`p2p.send_rate` `p2p.recv_rate`
- `p2p.flush_throttle_timeout`
- `p2p.max_packet_msg_payload_size`
- `p2p.send_rate`
- `p2p.recv_rate`
If you are going to use Tendermint in a private domain and you have a
private high-speed network among your peers, it makes sense to lower


+ 0
- 4
docs/tendermint-core/secure-p2p.md View File

@ -3,10 +3,6 @@
The Tendermint p2p protocol uses an authenticated encryption scheme
based on the [Station-to-Station
Protocol](https://en.wikipedia.org/wiki/Station-to-Station_protocol).
The implementation uses
[golang's](https://godoc.org/golang.org/x/crypto/nacl/box) [nacl
box](http://nacl.cr.yp.to/box.html) for the actual authenticated
encryption algorithm.
Each peer generates an ED25519 key-pair to use as a persistent
(long-term) id.


+ 5
- 9
docs/tendermint-core/using-tendermint.md View File

@ -151,7 +151,7 @@ and the `latest_app_hash` in particular:
curl http://localhost:26657/status | json_pp | grep latest_app_hash
```
Visit http://localhost:26657> in your browser to see the list of other
Visit http://localhost:26657 in your browser to see the list of other
endpoints. Some take no arguments (like `/status`), while others specify
the argument name and use `_` as a placeholder.
@ -224,7 +224,7 @@ new blockchain will not make any blocks.
## Configuration
Tendermint uses a `config.toml` for configuration. For details, see [the
config specification](./specification/configuration.md).
config specification](./tendermint-core/configuration.md).
Notable options include the socket address of the application
(`proxy_app`), the listening address of the Tendermint peer
@ -235,8 +235,7 @@ 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
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.
@ -365,10 +364,7 @@ case, the genesis file contains the public key of our
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.md#proposals)
for details).
recommend having voting powers greater than 10\^12 (ie. 1 trillion).
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
@ -520,7 +516,7 @@ failing, you need at least four validator nodes (e.g., 2/3).
Updating validators in a live network is supported but must be
explicitly programmed by the application developer. See the [application
developers guide](./app-development.md) for more details.
developers guide](../app-dev/app-development.md) for more details.
### Local Network


+ 1
- 1
docs/tools/monitoring.md View File

@ -3,7 +3,7 @@
Tendermint blockchain monitoring tool; watches over one or more nodes,
collecting and providing various statistics to the user:
- https://github.com/tendermint/tools/tree/master/tm-monitor
- https://github.com/tendermint/tendermint/tree/master/tools/tm-monitor
## Quick Start


+ 0
- 2507
docs/yarn.lock
File diff suppressed because it is too large
View File


+ 5
- 5
libs/clist/clist_test.go View File

@ -149,8 +149,8 @@ func _TestGCRandom(t *testing.T) {
func TestScanRightDeleteRandom(t *testing.T) {
const numElements = 10000
const numTimes = 1000
const numElements = 1000
const numTimes = 100
const numScanners = 10
l := New()
@ -209,7 +209,7 @@ func TestScanRightDeleteRandom(t *testing.T) {
// Stop scanners
close(stop)
time.Sleep(time.Second * 1)
// time.Sleep(time.Second * 1)
// And remove all the elements.
for el := l.Front(); el != nil; el = el.Next() {
@ -244,7 +244,7 @@ func TestWaitChan(t *testing.T) {
for i := 1; i < 100; i++ {
l.PushBack(i)
pushed++
time.Sleep(time.Duration(cmn.RandIntn(100)) * time.Millisecond)
time.Sleep(time.Duration(cmn.RandIntn(25)) * time.Millisecond)
}
close(done)
}()
@ -283,7 +283,7 @@ FOR_LOOP2:
if prev == nil {
t.Fatal("expected PrevWaitChan to block forever on nil when reached first elem")
}
case <-time.After(5 * time.Second):
case <-time.After(3 * time.Second):
break FOR_LOOP2
}
}


+ 1
- 1
mempool/mempool.go View File

@ -401,7 +401,7 @@ func (mem *Mempool) collectTxs(maxTxs int) types.Txs {
// NOTE: unsafe; Lock/Unlock must be managed by caller
func (mem *Mempool) Update(height int64, txs types.Txs) error {
// First, create a lookup map of txns in new txs.
txsMap := make(map[string]struct{})
txsMap := make(map[string]struct{}, len(txs))
for _, tx := range txs {
txsMap[string(tx)] = struct{}{}
}


+ 0
- 2
p2p/conn/connection_test.go View File

@ -433,7 +433,6 @@ func TestMConnectionReadErrorLongMessage(t *testing.T) {
_, err = client.Write(buf.Bytes())
assert.Nil(t, err)
assert.True(t, expectSend(chOnRcv), "msg just right")
assert.False(t, expectSend(chOnErr), "msg just right")
// send msg thats too long
buf = new(bytes.Buffer)
@ -446,7 +445,6 @@ func TestMConnectionReadErrorLongMessage(t *testing.T) {
assert.Nil(t, err)
_, err = client.Write(buf.Bytes())
assert.NotNil(t, err)
assert.False(t, expectSend(chOnRcv), "msg too long")
assert.True(t, expectSend(chOnErr), "msg too long")
}


Loading…
Cancel
Save