See beacon directory and consensus/state.go for main changes. Swig and C++ Boost libraries will need to be installed for the c++ to go interface and serialisation, respectively.
Install dependencies:
git clone https://github.com/herumi/mcl
cd mcl
make installYou will also need swig and GMP for the go-c++ interface and mcl. On Ubuntu
sudo apt-get libgmp-dev swigTo run all tests:
make testTo create a single node, which also generates entropy, run the following from the root directory
make build
cd build
./tendermint initThis creates genesis and validator information. To start the node
./tendermint node --proxy_app=kvstoreThe logs should show the node running the DKG and executing blocks, which contain the entropy in hex format after DKG completion.
For creating testnet with 4 validator nodes run
./tendermint testnetThis will create the required tendermint files for each node.
Second, determine the IDs for each node by running. We will denote the IDs as ID0, ID1, ID2, ID3.
./tendermint show_node_id --home mytestnet/node0
./tendermint show_node_id --home mytestnet/node1
./tendermint show_node_id --home mytestnet/node2
./tendermint show_node_id --home mytestnet/node3Now, assign each node two unique port numbers, denoted by P and Q, for listening to incoming peer connections and rpcs. Start each node in a separate terminal using
./tendermint node --home mytestnet/node0 --proxy_app=kvstore --p2p.laddr="tcp://127.0.0.1:P0" --rpc.laddr="tcp://127.0.0.1:Q0" --p2p.persistent_peers="ID1@127.0.0.1:P1,ID2@127.0.0.1:P2,ID3@127.0.0.1:P3"
./tendermint node --home mytestnet/node1 --proxy_app=kvstore --p2p.laddr="tcp://127.0.0.1:P1" --rpc.laddr="tcp://127.0.0.1:Q1" --p2p.persistent_peers="ID0@127.0.0.1:P0,ID2@127.0.0.1:P2,ID3@127.0.0.1:P3"
./tendermint node --home mytestnet/node2 --proxy_app=kvstore --p2p.laddr="tcp://127.0.0.1:P2" --rpc.laddr="tcp://127.0.0.1:Q2" --p2p.persistent_peers="ID0@127.0.0.1:P0,ID1@127.0.0.1:P1,ID3@127.0.0.1:P3"
./tendermint node --home mytestnet/node3 --proxy_app=kvstore --p2p.laddr="tcp://127.0.0.1:P3" --rpc.laddr="tcp://127.0.0.1:Q3" --p2p.persistent_peers="ID0@127.0.0.1:P0,ID1@127.0.0.1:P1,ID2@127.0.0.1:P2" After starting the third node blocks should start to be executed.
Byzantine-Fault Tolerant State Machines. Or Blockchain, for short.
| Branch | Tests | Coverage |
|---|---|---|
| master |  |
 |
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.
For protocol details, see the specification.
For detailed analysis of the consensus protocol, including safety and liveness proofs, see our recent paper, "The latest gossip on BFT consensus".
NOTE: The master branch is now an active development branch (starting with v0.32). Please, do not depend on it and
use releases instead.
Tendermint is being used in production in both private and public environments, most notably the blockchains of the Cosmos Network. However, we are still making breaking changes to the protocol and the APIs and have not yet released v1.0. See below for more details about versioning.
In any case, if you intend to run Tendermint in production, please contact us and join the chat.
To report a security vulnerability, see our bug bounty program
For examples of the kinds of bugs we're looking for, see SECURITY.md
| Requirement | Notes |
|---|---|
| Go version | Go1.13 or higher |
Complete documentation can be found on the website.
See the install instructions
- Single node
- Local cluster using docker-compose
- Remote cluster using terraform and ansible
- Join the Cosmos testnet
Please abide by the Code of Conduct in all interactions.
Before contributing to the project, please take a look at the contributing guidelines and the style guide.
To get more active, Join the wider community at Discord or jump onto the Forum.
Learn more by reading the code and the specifications or watch the Developer Sessions and read up on the Architectural Decision Records.
Tendermint uses Semantic Versioning to determine when and how the version changes. According to SemVer, anything in the public API can change at any time before version 1.0.0
To provide some stability to Tendermint users in these 0.X.X days, the MINOR version is used to signal breaking changes across a subset of the total public API. This subset includes all interfaces exposed to other processes (cli, rpc, p2p, etc.), but does not include the in-process Go APIs.
That said, breaking changes in the following packages will be documented in the CHANGELOG even if they don't lead to MINOR version bumps:
- crypto
- types
- rpc/client
- config
- node
- libs
- bech32
- common
- db
- errors
- log
Exported objects in these packages that are not covered by the versioning scheme
are explicitly marked by // UNSTABLE in their go doc comment and may change at any
time without notice. Functions, types, and values in any other package may also change at any time.
In an effort to avoid accumulating technical debt prior to 1.0.0, we do not guarantee that breaking changes (ie. bumps in the MINOR version) will work with existing tendermint blockchains. In these cases you will have to start a new blockchain, or write something custom to get the old data into the new chain.
However, any bump in the PATCH version should be compatible with existing histories (if not please open an issue).
For more information on upgrading, see UPGRADING.md.
Because we are a small core team, we only ship patch updates, including security updates, to the most recent minor release and the second-most recent minor release. Consequently, we strongly recommend keeping Tendermint up-to-date. Upgrading instructions can be found in UPGRADING.md.
For details about the blockchain data structures and the p2p protocols, see the Tendermint specification.
For details on using the software, see the documentation which is also hosted at: https://docs.tendermint.com/master/
Benchmarking is provided by tm-load-test.
The code for tm-load-test can be found here this binary needs to be built separately.
Additional documentation is found here.
- Amino, reflection-based proto3, with interfaces
- IAVL, Merkleized IAVL+ Tree implementation
- Tm-db, Data Base abstractions to be used in applications.
- Cosmos SDK; a cryptocurrency application framework
- Ethermint; Ethereum on Tendermint
- Many more