docs: fix links & other imrpvoements
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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)
|
||||
|
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.
|
||||
|
||||

|
||||

|
||||
|
||||
## 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:
|
||||
|
||||

|
||||

|
||||
|
||||
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).
|
||||
|
||||

|
||||

|
||||
|
@ -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
|
||||
|
||||
|