Merge remote-tracking branch 'origin/develop' into dev/multisig
|
@ -4,4 +4,4 @@
|
|||
* @ebuchman @melekes @xla
|
||||
|
||||
# Precious documentation
|
||||
/docs/ @zramsay @jolesbi
|
||||
/docs/ @zramsay
|
||||
|
|
|
@ -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
|
||||
}()
|
||||
}
|
||||
|
||||
|
|
|
@ -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)
|
||||
}
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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)
|
|
@ -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
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
Before Width: | Height: | Size: 103 KiB After Width: | Height: | Size: 103 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 2.4 MiB After Width: | Height: | Size: 2.4 MiB |
Before Width: | Height: | Size: 52 KiB After Width: | Height: | Size: 52 KiB |
|
@ -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)
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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,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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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!
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
2507
docs/yarn.lock
|
@ -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
|
||||
}
|
||||
}
|
||||
|
|
|
@ -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{}{}
|
||||
}
|
||||
|
|
|
@ -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")
|
||||
}
|
||||
|
||||
|
|