Anton KaliaevandGitHub
fb8b00f1d8
Refs #1771 ADR: https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-044-lite-client-with-weak-subjectivity.md ## Commits: * add Verifier and VerifyCommitTrusting * add two more checks make trustLevel an option * float32 for trustLevel * check newHeader time * started writing lite Client * unify Verify methods * ensure h2.Header.bfttime < h1.Header.bfttime + tp * move trust checks into Verify function * add more comments * more docs * started writing tests * unbonding period failures * tests are green * export ErrNewHeaderTooFarIntoFuture * make golangci happy * test for non-adjusted headers * more precision * providers and stores * VerifyHeader and VerifyHeaderAtHeight funcs * fix compile errors * remove lastVerifiedHeight, persist new trusted header * sequential verification * remove TrustedStore option * started writing tests for light client * cover basic cases for linear verification * bisection tests PASS * rename BisectingVerification to SkippingVerification * refactor the code * add TrustedHeader method * consolidate sequential verification tests * consolidate skipping verification tests * rename trustedVals to trustedNextVals * start writing docs * ValidateTrustLevel func and ErrOldHeaderExpired error * AutoClient and example tests * fix errors * update doc * remove ErrNewHeaderTooFarIntoFuture This check is unnecessary given existing a) ErrOldHeaderExpired b) h2.Time > now checks. * return an error if we're at more recent height * add comments * add LastSignedHeaderHeight method to Store I think it's fine if Store tracks last height * copy over proxy from old lite package * make TrustedHeader return latest if height=0 * modify LastSignedHeaderHeight to return an error if no headers exist * copy over proxy impl * refactor proxy and start http lite client * Tx and BlockchainInfo methods * Block method * commit method * code compiles again * lite client compiles * extract updateLiteClientIfNeededTo func * move final parts * add placeholder for tests * force usage of lite http client in proxy * comment out query tests for now * explicitly mention tp: trusting period * verify nextVals in VerifyHeader * refactor bisection * move the NextValidatorsHash check into updateTrustedHeaderAndVals + update the comment * add ConsensusParams method to RPC client * add ConsensusParams to rpc/mock/client * change trustLevel type to a new cmn.Fraction type + update SkippingVerification comment * stress out trustLevel is only used for non-adjusted headers * fixes after Fede's review Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com> * compare newHeader with a header from an alternative provider * save pivot header Refs https://github.com/tendermint/tendermint/pull/3989#discussion_r349122824 * check header can still be trusted in TrustedHeader Refs https://github.com/tendermint/tendermint/pull/3989#discussion_r349101424 * lite: update Validators and Block endpoints - Block no longer contains BlockMeta - Validators now accept two additional params: page and perPage * make linter happy
Tendermint
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".
Releases
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.
Security
To report a security vulnerability, see our bug bounty program
For examples of the kinds of bugs we're looking for, see SECURITY.md
Minimum requirements
| Requirement | Notes |
|---|---|
| Go version | Go1.11.4 or higher |
Documentation
Complete documentation can be found on the website.
Install
See the install instructions
Quick Start
- Single node
- Local cluster using docker-compose
- Remote cluster using terraform and ansible
- Join the Cosmos testnet
Contributing
Please abide by the Code of Conduct in all interactions, and the contributing guidelines when submitting code.
Join the larger community on the forum and the chat.
To learn more about the structure of the software, watch the Developer Sessions and read some Architectural Decision Records.
Learn more by reading the code and comparing it to the specification.
Versioning
Semantic Versioning
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.
Upgrades
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
Resources
Tendermint Core
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/
Tools
Benchmarking and monitoring is provided by tm-load-test and tm-monitor, respectively.
The code for tm-monitor can be found here and the code for tm-load-test can be found here these binaries need to be built seperately.
Additional documentation is found here.
Sub-projects
- Amino, reflection-based proto3, with interfaces
- IAVL, Merkleized IAVL+ Tree implementation
- Tm-cmn, Commonly used libs across Tendermint & Cosmos repos
Applications
- Cosmos SDK; a cryptocurrency application framework
- Ethermint; Ethereum on Tendermint
- Many more
Research
- The latest gossip on BFT consensus
- Master's Thesis on Tendermint
- Original Whitepaper
- You can find the link at the bottom of the readme
- Blog