diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js index 892ea204..b4e2c3fa 100644 --- a/docs/.vuepress/config.js +++ b/docs/.vuepress/config.js @@ -11,12 +11,12 @@ module.exports = { nav: [{ text: "Back to Tendermint", link: "https://tendermint.com" }], sidebar: [ { - title: "Getting Started", + title: "Introduction", collapsable: false, children: [ "/introduction/quick-start", "/introduction/install", - "/introduction/introduction" + "/introduction/what-is-tendermint" ] }, { @@ -48,7 +48,7 @@ module.exports = { title: "Networks", collapsable: false, children: [ - "/networks/deploy-testnets", + "/networks/docker-compose", "/networks/terraform-and-ansible", ] }, diff --git a/docs/README.md b/docs/README.md index 2ecf625e..15ce74e3 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,43 +1,27 @@ # Tendermint -Welcome to the Tendermint Core documentation! Below you'll find an -overview of the documentation. +Welcome to the Tendermint Core documentation! -Tendermint Core is Byzantine Fault Tolerant (BFT) middleware that takes a state -transition machine - written in any programming language - and securely -replicates it on many machines. In other words, a blockchain. +Tendermint Core is a blockchain application platform; it provides the equivalent +of a web-server, database, and supporting libraries for blockchain applications +written in any programming language. Like a web-server serving web applications, +Tendermint serves blockchain applications. -Tendermint requires an application running over the Application Blockchain -Interface (ABCI) - and comes packaged with an example application to do so. +More formally, Tendermint Core performs Byzantine Fault Tolerant (BFT) +State Machine Replication (SMR) for arbitrary deterministic, finite state machines. +For more background, see [What is +Tendermint?](introduction/what-is-tendermint.md). -## Getting Started +To get started quickly with an example application, see the [quick start guide](introduction/quick-start.md). -Here you'll find quick start guides and links to more advanced "get up and running" -documentation. +To learn about application development on Tendermint, see the [Application Blockchain Interface](spec/abci). -## Core +For more details on using Tendermint, see the respective documentation for +[Tendermint Core](tendermint-core), [benchmarking and monitoring](tools), and [network deployments](networks). -Details about the core functionality and configuration of Tendermint. +## Contribute -## Tools - -Benchmarking and monitoring tools. - -## Networks - -Setting up testnets manually or automated, local or in the cloud. - -## Apps - -Building appplications with the ABCI. - -## Specification - -Dive deep into the spec. There's one for each Tendermint and the ABCI - -## Edit the Documentation - -See [this file](./DOCS_README.md) for details of the build process and +To contribute to the documentation, see [this file](./DOCS_README.md) for details of the build process and considerations when making changes. ## Version diff --git a/docs/introduction/README.md b/docs/introduction/README.md new file mode 100644 index 00000000..ad9a93dd --- /dev/null +++ b/docs/introduction/README.md @@ -0,0 +1,15 @@ +# Introduction + +## Quick Start + +Get Tendermint up-and-running quickly with the [quick-start guide](quick-start.md)! + +## Install + +Detailed [installation instructions](install.md). + +## What is Tendermint? + +Dive into [what Tendermint is and why](what-is-tendermint.md)! + + diff --git a/docs/introduction/introduction.md b/docs/introduction/introduction.md index 389bf965..f80a159c 100644 --- a/docs/introduction/introduction.md +++ b/docs/introduction/introduction.md @@ -1,5 +1,7 @@ # What is Tendermint? +DEPRECATED! See [What is Tendermint?](what-is-tendermint.md). + Tendermint is software for securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to 1/3 of machines fail in arbitrary ways. By consistently, diff --git a/docs/introduction/quick-start.md b/docs/introduction/quick-start.md index c10ba10a..05facadf 100644 --- a/docs/introduction/quick-start.md +++ b/docs/introduction/quick-start.md @@ -1,4 +1,4 @@ -# Tendermint +# Quick Start ## Overview @@ -9,45 +9,21 @@ works and want to get started right away, continue. ### Quick Install -On a fresh Ubuntu 16.04 machine can be done with [this script](https://git.io/fFfOR), like so: +To quickly get Tendermint installed on a fresh +Ubuntu 16.04 machine, use [this script](https://git.io/fFfOR). + +WARNING: do not run this on your local machine. ``` curl -L https://git.io/fFfOR | bash source ~/.profile ``` -WARNING: do not run the above on your local machine. - The script is also used to facilitate cluster deployment below. ### Manual Install -Requires: - -- `go` minimum version 1.10 -- `$GOPATH` environment variable must be set -- `$GOPATH/bin` must be on your `$PATH` (see [here](https://github.com/tendermint/tendermint/wiki/Setting-GOPATH)) - -To install Tendermint, run: - -``` -go get github.com/tendermint/tendermint -cd $GOPATH/src/github.com/tendermint/tendermint -make get_tools && make get_vendor_deps -make install -``` - -Note that `go get` may return an error but it can be ignored. - -Confirm installation: - -``` -$ tendermint version -0.23.0 -``` - -Note: see the [releases page](https://github.com/tendermint/tendermint/releases) and the latest version -should match what you see above. +For manual installation, see the [install instructions](install.md) ## Initialization diff --git a/docs/introduction/what-is-tendermint.md b/docs/introduction/what-is-tendermint.md new file mode 100644 index 00000000..389bf965 --- /dev/null +++ b/docs/introduction/what-is-tendermint.md @@ -0,0 +1,332 @@ +# What is Tendermint? + +Tendermint is software for securely and consistently replicating an +application on many machines. By securely, we mean that Tendermint works +even if up to 1/3 of machines fail in arbitrary ways. By consistently, +we mean that every non-faulty machine sees the same transaction log and +computes the same state. Secure and consistent replication is a +fundamental problem in distributed systems; it plays a critical role in +the fault tolerance of a broad range of applications, from currencies, +to elections, to infrastructure orchestration, and beyond. + +The ability to tolerate machines failing in arbitrary ways, including +becoming malicious, is known as Byzantine fault tolerance (BFT). The +theory of BFT is decades old, but software implementations have only +became popular recently, due largely to the success of "blockchain +technology" like Bitcoin and Ethereum. Blockchain technology is just a +reformalization of BFT in a more modern setting, with emphasis on +peer-to-peer networking and cryptographic authentication. The name +derives from the way transactions are batched in blocks, where each +block contains a cryptographic hash of the previous one, forming a +chain. In practice, the blockchain data structure actually optimizes BFT +design. + +Tendermint consists of two chief technical components: a blockchain +consensus engine and a generic application interface. The consensus +engine, called Tendermint Core, ensures that the same transactions are +recorded on every machine in the same order. The application interface, +called the Application BlockChain Interface (ABCI), enables the +transactions to be processed in any programming language. Unlike other +blockchain and consensus solutions, which come pre-packaged with built +in state machines (like a fancy key-value store, or a quirky scripting +language), developers can use Tendermint for BFT state machine +replication of applications written in whatever programming language and +development environment is right for them. + +Tendermint is designed to be easy-to-use, simple-to-understand, highly +performant, and useful for a wide variety of distributed applications. + +## Tendermint vs. X + +Tendermint is broadly similar to two classes of software. The first +class consists of distributed key-value stores, like Zookeeper, etcd, +and consul, which use non-BFT consensus. The second class is known as +"blockchain technology", and consists of both cryptocurrencies like +Bitcoin and Ethereum, and alternative distributed ledger designs like +Hyperledger's Burrow. + +### Zookeeper, etcd, consul + +Zookeeper, etcd, and consul are all implementations of a key-value store +atop a classical, non-BFT consensus algorithm. Zookeeper uses a version +of Paxos called Zookeeper Atomic Broadcast, while etcd and consul use +the Raft consensus algorithm, which is much younger and simpler. A +typical cluster contains 3-5 machines, and can tolerate crash failures +in up to 1/2 of the machines, but even a single Byzantine fault can +destroy the system. + +Each offering provides a slightly different implementation of a +featureful key-value store, but all are generally focused around +providing basic services to distributed systems, such as dynamic +configuration, service discovery, locking, leader-election, and so on. + +Tendermint is in essence similar software, but with two key differences: + +- It is Byzantine Fault Tolerant, meaning it can only tolerate up to a + 1/3 of failures, but those failures can include arbitrary behaviour - + including hacking and malicious attacks. - It does not specify a + particular application, like a fancy key-value store. Instead, it + focuses on arbitrary state machine replication, so developers can build + the application logic that's right for them, from key-value store to + cryptocurrency to e-voting platform and beyond. + +The layout of this Tendermint website content is also ripped directly +and without shame from [consul.io](https://www.consul.io/) and the other +[Hashicorp sites](https://www.hashicorp.com/#tools). + +### Bitcoin, Ethereum, etc. + +Tendermint emerged in the tradition of cryptocurrencies like Bitcoin, +Ethereum, etc. with the goal of providing a more efficient and secure +consensus algorithm than Bitcoin's Proof of Work. In the early days, +Tendermint had a simple currency built in, and to participate in +consensus, users had to "bond" units of the currency into a security +deposit which could be revoked if they misbehaved -this is what made +Tendermint a Proof-of-Stake algorithm. + +Since then, Tendermint has evolved to be a general purpose blockchain +consensus engine that can host arbitrary application states. That means +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/cosmos/ethermint). And we plan to do +the same for Bitcoin, ZCash, and various other deterministic +applications as well. + +Another example of a cryptocurrency application built on Tendermint is +[the Cosmos network](http://cosmos.network). + +### Other Blockchain Projects + +[Fabric](https://github.com/hyperledger/fabric) takes a similar approach +to Tendermint, but is more opinionated about how the state is managed, +and requires that all application behaviour runs in potentially many +docker containers, modules it calls "chaincode". It uses an +implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). +from a team at IBM that is [augmented to handle potentially +non-deterministic +chaincode](https://www.zurich.ibm.com/~cca/papers/sieve.pdf) It is +possible to implement this docker-based behaviour as a ABCI app in +Tendermint, though extending Tendermint to handle non-determinism +remains for future work. + +[Burrow](https://github.com/hyperledger/burrow) is an implementation of +the Ethereum Virtual Machine and Ethereum transaction mechanics, with +additional features for a name-registry, permissions, and native +contracts, and an alternative blockchain API. It uses Tendermint as its +consensus engine, and provides a particular application state. + +## ABCI Overview + +The [Application BlockChain Interface +(ABCI)](https://github.com/tendermint/tendermint/tree/develop/abci) +allows for Byzantine Fault Tolerant replication of applications +written in any programming language. + +### Motivation + +Thus far, all blockchains "stacks" (such as +[Bitcoin](https://github.com/bitcoin/bitcoin)) have had a monolithic +design. That is, each blockchain stack is a single program that handles +all the concerns of a decentralized ledger; this includes P2P +connectivity, the "mempool" broadcasting of transactions, consensus on +the most recent block, account balances, Turing-complete contracts, +user-level permissions, etc. + +Using a monolithic architecture is typically bad practice in computer +science. It makes it difficult to reuse components of the code, and +attempts to do so result in complex maintenance procedures for forks of +the codebase. This is especially true when the codebase is not modular +in design and suffers from "spaghetti code". + +Another problem with monolithic design is that it limits you to the +language of the blockchain stack (or vice versa). In the case of +Ethereum which supports a Turing-complete bytecode virtual-machine, it +limits you to languages that compile down to that bytecode; today, those +are Serpent and Solidity. + +In contrast, our approach is to decouple the consensus engine and P2P +layers from the details of the application state of the particular +blockchain application. We do this by abstracting away the details of +the application to an interface, which is implemented as a socket +protocol. + +Thus we have an interface, the Application BlockChain Interface (ABCI), +and its primary implementation, the Tendermint Socket Protocol (TSP, or +Teaspoon). + +### Intro to ABCI + +[Tendermint Core](https://github.com/tendermint/tendermint) (the +"consensus engine") communicates with the application via a socket +protocol that satisfies the ABCI. + +To draw an analogy, lets talk about a well-known cryptocurrency, +Bitcoin. Bitcoin is a cryptocurrency blockchain where each node +maintains a fully audited Unspent Transaction Output (UTXO) database. If +one wanted to create a Bitcoin-like system on top of ABCI, Tendermint +Core would be responsible for + +- Sharing blocks and transactions between nodes +- Establishing a canonical/immutable order of transactions + (the blockchain) + +The application will be responsible for + +- Maintaining the UTXO database +- Validating cryptographic signatures of transactions +- Preventing transactions from spending non-existent transactions +- Allowing clients to query the UTXO database. + +Tendermint is able to decompose the blockchain design by offering a very +simple API (ie. the ABCI) between the application process and consensus +process. + +The ABCI consists of 3 primary message types that get delivered from the +core to the application. The application replies with corresponding +response messages. + +The messages are specified here: [ABCI Message +Types](https://github.com/tendermint/tendermint/blob/develop/abci/README.md#message-types). + +The **DeliverTx** message is the work horse of the application. Each +transaction in the blockchain is delivered with this message. The +application needs to validate each transaction received with the +**DeliverTx** message against the current state, application protocol, +and the cryptographic credentials of the transaction. A validated +transaction then needs to update the application state — by binding a +value into a key values store, or by updating the UTXO database, for +instance. + +The **CheckTx** message is similar to **DeliverTx**, but it's only for +validating transactions. Tendermint Core's mempool first checks the +validity of a transaction with **CheckTx**, and only relays valid +transactions to its peers. For instance, an application may check an +incrementing sequence number in the transaction and return an error upon +**CheckTx** if the sequence number is old. Alternatively, they might use +a capabilities based system that requires capabilities to be renewed +with every transaction. + +The **Commit** message is used to compute a cryptographic commitment to +the current application state, to be placed into the next block header. +This has some handy properties. Inconsistencies in updating that state +will now appear as blockchain forks which catches a whole class of +programming errors. This also simplifies the development of secure +lightweight clients, as Merkle-hash proofs can be verified by checking +against the block hash, and that the block hash is signed by a quorum. + +There can be multiple ABCI socket connections to an application. +Tendermint Core creates three ABCI connections to the application; one +for the validation of transactions when broadcasting in the mempool, one +for the consensus engine to run block proposals, and one more for +querying the application state. + +It's probably evident that applications designers need to very carefully +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. + +![](../imgs/abci.png) + +## A Note on Determinism + +The logic for blockchain transaction processing must be deterministic. +If the application logic weren't deterministic, consensus would not be +reached among the Tendermint Core replica nodes. + +Solidity on Ethereum is a great language of choice for blockchain +applications because, among other reasons, it is a completely +deterministic programming language. However, it's also possible to +create deterministic applications using existing popular languages like +Java, C++, Python, or Go. Game programmers and blockchain developers are +already familiar with creating deterministic programs by avoiding +sources of non-determinism such as: + +- random number generators (without deterministic seeding) +- race conditions on threads (or avoiding threads altogether) +- the system clock +- uninitialized memory (in unsafe programming languages like C + or C++) +- [floating point + arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/) +- language features that are random (e.g. map iteration in Go) + +While programmers can avoid non-determinism by being careful, it is also +possible to create a special linter or static analyzer for each language +to check for determinism. In the future we may work with partners to +create such tools. + +## Consensus Overview + +Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus +protocol. The protocol follows a simple state machine that looks like +this: + +![](../imgs/consensus_logic.png) + +Participants in the protocol are called **validators**; they take turns +proposing blocks of transactions and voting on them. Blocks are +committed in a chain, with one block at each **height**. A block may +fail to be committed, in which case the protocol moves to the next +**round**, and a new validator gets to propose a block for that height. +Two stages of voting are required to successfully commit a block; we +call them **pre-vote** and **pre-commit**. A block is committed when +more than 2/3 of validators pre-commit for the same block in the same +round. + +There is a picture of a couple doing the polka because validators are +doing something like a polka dance. When more than two-thirds of the +validators pre-vote for the same block, we call that a **polka**. Every +pre-commit must be justified by a polka in the same round. + +Validators may fail to commit a block for a number of reasons; the +current proposer may be offline, or the network may be slow. Tendermint +allows them to establish that a validator should be skipped. Validators +wait a small amount of time to receive a complete proposal block from +the proposer before voting to move to the next round. This reliance on a +timeout is what makes Tendermint a weakly synchronous protocol, rather +than an asynchronous one. However, the rest of the protocol is +asynchronous, and validators only make progress after hearing from more +than two-thirds of the validator set. A simplifying element of +Tendermint is that it uses the same mechanism to commit a block as it +does to skip to the next round. + +Assuming less than one-third of the validators are Byzantine, Tendermint +guarantees that safety will never be violated - that is, validators will +never commit conflicting blocks at the same height. To do this it +introduces a few **locking** rules which modulate which paths can be +followed in the flow diagram. Once a validator precommits a block, it is +locked on that block. Then, + +1. it must prevote for the block it is locked on +2. it can only unlock, and precommit for a new block, if there is a + polka for that block in a later round + +## Stake + +In many systems, not all validators will have the same "weight" in the +consensus protocol. Thus, we are not so much interested in one-third or +two-thirds of the validators, but in those proportions of the total +voting power, which may not be uniformly distributed across individual +validators. + +Since Tendermint can replicate arbitrary applications, it is possible to +define a currency, and denominate the voting power in that currency. +When voting power is denominated in a native currency, the system is +often referred to as Proof-of-Stake. Validators can be forced, by logic +in the application, to "bond" their currency holdings in a security +deposit that can be destroyed if they're found to misbehave in the +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](https://cosmos.network) is designed to use this +Proof-of-Stake mechanism across an array of cryptocurrencies implemented +as ABCI applications. + +The following diagram is Tendermint in a (technical) nutshell. [See here +for high resolution +version](https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf). + +![](../imgs/tm-transaction-flow.png) diff --git a/docs/networks/README.md b/docs/networks/README.md new file mode 100644 index 00000000..b1ba2712 --- /dev/null +++ b/docs/networks/README.md @@ -0,0 +1,9 @@ +# Networks + +Use [Docker Compose](docker-compose.md) to spin up Tendermint testnets on your +local machine. + +Use [Terraform and Ansible](terraform-and-ansible.md) to deploy Tendermint +testnets to the cloud. + +See the `tendermint testnet --help` command for more help initializing testnets. diff --git a/docs/networks/deploy-testnets.md b/docs/networks/deploy-testnets.md index 35732f9b..4df6916b 100644 --- a/docs/networks/deploy-testnets.md +++ b/docs/networks/deploy-testnets.md @@ -1,8 +1,8 @@ # Deploy a Testnet -Now that we've seen how ABCI works, and even played with a few -applications on a single validator node, it's time to deploy a test -network to four validator nodes. +DEPRECATED DOCS! + +See [Networks](../networks). ## Manual Deployments @@ -21,17 +21,16 @@ Here are the steps to setting up a testnet manually: 3. Generate a private key and a node key for each validator using `tendermint init` 4. Compile a list of public keys for each validator into a - `genesis.json` file and replace the existing file with it. -5. Run - `tendermint node --proxy_app=kvstore --p2p.persistent_peers=< peer addresses >` on each node, where `< peer addresses >` is a comma separated - list of the ID@IP:PORT combination for each node. The default port for - Tendermint is `26656`. The ID of a node can be obtained by running - `tendermint show_node_id` command. Thus, if the IP addresses of your nodes - were `192.168.0.1, 192.168.0.2, 192.168.0.3, 192.168.0.4`, the command - would look like: + new `genesis.json` file and replace the existing file with it. +5. Get the node IDs of any peers you want other peers to connect to by + running `tendermint show_node_id` on the relevant machine +6. Set the `p2p.persistent_peers` in the config for all nodes to the comma + separated list of `ID@IP:PORT` for all nodes. Default port is 26656. + +Then start the node ``` -tendermint node --proxy_app=kvstore --p2p.persistent_peers=96663a3dd0d7b9d17d4c8211b191af259621c693@192.168.0.1:26656, 429fcf25974313b95673f58d77eacdd434402665@192.168.0.2:26656, 0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@192.168.0.3:26656, f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@192.168.0.4:26656 +tendermint node --proxy_app=kvstore ``` After a few seconds, all the nodes should connect to each other and diff --git a/docs/networks/docker-compose.md b/docs/networks/docker-compose.md new file mode 100644 index 00000000..a1924eb9 --- /dev/null +++ b/docs/networks/docker-compose.md @@ -0,0 +1,85 @@ +# Docker Compose + +With Docker Compose, we can spin up local testnets in a single command: + +``` +make localnet-start +``` + +## Requirements + +- [Install tendermint](/docs/install.md) +- [Install docker](https://docs.docker.com/engine/installation/) +- [Install docker-compose](https://docs.docker.com/compose/install/) + +## Build + +Build the `tendermint` binary and the `tendermint/localnode` docker image. + +Note the binary will be mounted into the container so it can be updated without +rebuilding the image. + +``` +cd $GOPATH/src/github.com/tendermint/tendermint + +# Build the linux binary in ./build +make build-linux + +# Build tendermint/localnode image +make build-docker-localnode +``` + + +## Run a testnet + +To start a 4 node testnet run: + +``` +make localnet-start +``` + +The nodes bind their RPC servers to ports 26657, 26660, 26662, and 26664 on the host. +This file creates a 4-node network using the localnode image. +The nodes of the network expose their P2P and RPC endpoints to the host machine on ports 26656-26657, 26659-26660, 26661-26662, and 26663-26664 respectively. + +To update the binary, just rebuild it and restart the nodes: + +``` +make build-linux +make localnet-stop +make localnet-start +``` + +## Configuration + +The `make localnet-start` creates files for a 4-node testnet in `./build` by calling the `tendermint testnet` command. + +The `./build` directory is mounted to the `/tendermint` mount point to attach the binary and config files to the container. + +For instance, to create a single node testnet: + +``` +cd $GOPATH/src/github.com/tendermint/tendermint + +# Clear the build folder +rm -rf ./build + +# Build binary +make build-linux + +# Create configuration +docker run -e LOG="stdout" -v `pwd`/build:/tendermint tendermint/localnode testnet --o . --v 1 + +#Run the node +docker run -v `pwd`/build:/tendermint tendermint/localnode + +``` + +## Logging + +Log is saved under the attached volume, in the `tendermint.log` file. If the `LOG` environment variable is set to `stdout` at start, the log is not saved, but printed on the screen. + +## Special binaries + +If you have multiple binaries with different names, you can specify which one to run with the BINARY environment variable. The path of the binary is relative to the attached volume. + diff --git a/docs/networks/terraform-and-ansible.md b/docs/networks/terraform-and-ansible.md index 5a4b9c53..c08ade17 100644 --- a/docs/networks/terraform-and-ansible.md +++ b/docs/networks/terraform-and-ansible.md @@ -29,7 +29,7 @@ export SSH_KEY_FILE="$HOME/.ssh/id_rsa.pub" These will be used by both `terraform` and `ansible`. -### Terraform +## Terraform This step will create four Digital Ocean droplets. First, go to the correct directory: @@ -49,7 +49,7 @@ and you will get a list of IP addresses that belong to your droplets. With the droplets created and running, let's setup Ansible. -### Ansible +## Ansible The playbooks in [the ansible directory](https://github.com/tendermint/tendermint/tree/master/networks/remote/ansible) @@ -144,7 +144,7 @@ Peek at the logs with the status role: ansible-playbook -i inventory/digital_ocean.py -l sentrynet status.yml ``` -### Logging +## Logging The crudest way is the status role described above. You can also ship logs to Logz.io, an Elastic stack (Elastic search, Logstash and Kibana) @@ -160,7 +160,7 @@ go get github.com/mheese/journalbeat ansible-playbook -i inventory/digital_ocean.py -l sentrynet logzio.yml -e LOGZIO_TOKEN=ABCDEFGHIJKLMNOPQRSTUVWXYZ012345 ``` -### Cleanup +## Cleanup To remove your droplets, run: diff --git a/docs/spec/abci/README.md b/docs/spec/abci/README.md index c0956db6..02e369bf 100644 --- a/docs/spec/abci/README.md +++ b/docs/spec/abci/README.md @@ -1,7 +1,7 @@ # ABCI ABCI is the interface between Tendermint (a state-machine replication engine) -and an application (the actual state machine). It consists of a set of +and your application (the actual state machine). It consists of a set of *methods*, where each method has a corresponding `Request` and `Response` message type. Tendermint calls the ABCI methods on the ABCI application by sending the `Request*` messages and receiving the `Response*` messages in return. diff --git a/docs/spec/abci/abci.md b/docs/spec/abci/abci.md index a1217098..0e9b3d78 100644 --- a/docs/spec/abci/abci.md +++ b/docs/spec/abci/abci.md @@ -7,9 +7,9 @@ file](https://github.com/tendermint/tendermint/blob/develop/abci/types/types.pro ABCI methods are split across 3 separate ABCI *connections*: -- `Consensus Connection: InitChain, BeginBlock, DeliverTx, EndBlock, Commit` -- `Mempool Connection: CheckTx` -- `Info Connection: Info, SetOption, Query` +- `Consensus Connection`: `InitChain, BeginBlock, DeliverTx, EndBlock, Commit` +- `Mempool Connection`: `CheckTx` +- `Info Connection`: `Info, SetOption, Query` The `Consensus Connection` is driven by a consensus protocol and is responsible for block execution. diff --git a/docs/tendermint-core/README.md b/docs/tendermint-core/README.md new file mode 100644 index 00000000..7f5dc677 --- /dev/null +++ b/docs/tendermint-core/README.md @@ -0,0 +1,4 @@ +# Tendermint Core + +See the side-bar for details on the various features of Tendermint Core. + diff --git a/docs/tools/README.md b/docs/tools/README.md new file mode 100644 index 00000000..b08416bb --- /dev/null +++ b/docs/tools/README.md @@ -0,0 +1,4 @@ +# Tools + +Tendermint comes with some tools for [benchmarking](benchmarking.md) +and [monitoring](monitoring.md). diff --git a/docs/tools/benchmarking.md b/docs/tools/benchmarking.md index 691d3b6e..e17c2856 100644 --- a/docs/tools/benchmarking.md +++ b/docs/tools/benchmarking.md @@ -20,7 +20,7 @@ Blocks/sec 0.818 0.386 1 9 ## Quick Start -[Install Tendermint](../introduction/install) +[Install Tendermint](../introduction/install.md) This currently is setup to work on tendermint's develop branch. Please ensure you are on that. (If not, update `tendermint` and `tmlibs` in gopkg.toml to use the master branch.) diff --git a/docs/tools/monitoring.md b/docs/tools/monitoring.md index bd0105c8..c0fa94c0 100644 --- a/docs/tools/monitoring.md +++ b/docs/tools/monitoring.md @@ -33,21 +33,21 @@ docker run -it --rm -p "26670:26670" --link=tm tendermint/monitor tm:26657 ### Using Binaries -[Install Tendermint](https://github.com/tendermint/tendermint#install) +[Install Tendermint](../introduction/install.md). -then run: +Start a Tendermint node: ``` tendermint init tendermint node --proxy_app=kvstore ``` +In another window, run the monitor: + ``` tm-monitor localhost:26657 ``` -with the last command being in a seperate window. - ## Usage ``` diff --git a/networks/local/README.md b/networks/local/README.md index 09a0b12c..8d429969 100644 --- a/networks/local/README.md +++ b/networks/local/README.md @@ -1,5 +1,9 @@ # Local Cluster with Docker Compose +DEPRECATED! + +See the [docs](https://tendermint.com/docs/networks/docker-compose.html). + ## Requirements - [Install tendermint](/docs/install.md) diff --git a/networks/remote/README.md b/networks/remote/README.md index 2094fcc9..4c035be8 100644 --- a/networks/remote/README.md +++ b/networks/remote/README.md @@ -1,3 +1,3 @@ # Remote Cluster with Terraform and Ansible -See the [docs](/docs/terraform-and-ansible.md) +See the [docs](https://tendermint.com/docs/networks/terraform-and-ansible.html).