6878b38812
* Revert "abci: Add unsynchronized local client (#9660)"
This reverts commit 45071d1f23.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* proxy: Add unsync local client creator
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* e2e: Extend tests
Extend the E2E tests to randomly choose between the sync (default) and
unsync (new) local client creator.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* abci: Remove redundant interface constraint
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* abci: Remove irrelevant doc comment
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* proxy: Remove backticks in doc comments
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* e2e: Remove unnecessary gap between doc comment and struct
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add pending changelog entry
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* e2e: Expand on BuiltinProxyMode param docstring
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Remove builtin proxy mode config option from CI test
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* e2e: Make builtin proxy mode option testnet-wide
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* e2e: Embed sync/unsync notion in node protocol
The approach of randomly generating the proxy mode across testnets
resulted in a totally uneven ratio of sync to unsync modes for all
testnets that happened to have a protocol of "builtin".
This commit adapts the E2E tests to have a new ABCI protocol option:
"builtin_unsync". This results in a better spread of sync/unsync choices
for generated testnets.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* e2e: Remove unused type
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Tendermint
Byzantine-Fault Tolerant State Machine Replication. Or Blockchain, for short.
| Branch | Tests | Linting |
|---|---|---|
| main |  |
 |
Tendermint Core is a 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, refer to the Tendermint Specification.
For detailed analysis of the consensus protocol, including safety and liveness proofs, read our paper, "The latest gossip on BFT consensus".
Documentation
Complete documentation can be found on the website.
Releases
Please do not depend on main as your production branch. Use
releases instead.
Tendermint has been in the production of private and public environments, most notably the blockchains of the Cosmos Network. we haven't released v1.0 yet since we are making breaking changes to the protocol and the APIs. See below for more details about versioning.
In any case, if you intend to run Tendermint in production, we're happy to help. You can contact us over email or join the chat.
More on how releases are conducted can be found here.
Security
To report a security vulnerability, see our bug bounty program. For examples of the kinds of bugs we're looking for, see our security policy.
We also maintain a dedicated mailing list for security updates. We will only ever use this mailing list to notify you of vulnerabilities and fixes in Tendermint Core. You can subscribe here.
Minimum requirements
| Requirement | Notes |
|---|---|
| Go version | Go 1.18 or higher |
Install
See the install instructions.
Quick Start
Contributing
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. You may also find it helpful to read the specifications, and familiarize yourself with our Architectural Decision Records (ADRs) and Request For Comments (RFCs).
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 users of 0.X.X versions of Tendermint, the MINOR version is used to signal breaking changes across Tendermint's API. This API includes all publicly exposed types, functions, and methods in non-internal Go packages as well as the types and methods accessible via the Tendermint RPC interface.
Breaking changes to these public APIs will be documented in the CHANGELOG.
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 blockchain histories.
For more information on upgrading, see UPGRADING.md.
Supported Versions
Because we are a small core team, we have limited capacity to ship patch updates, including security updates. Consequently, we strongly recommend keeping Tendermint up-to-date. Upgrading instructions can be found in UPGRADING.md.
Currently supported versions include:
- v0.34.x
- v0.37.x (release candidate)
Resources
Libraries
- Cosmos SDK; A framework for building applications in Golang
- Tendermint in Rust
- ABCI Tower
Applications
Research
- The latest gossip on BFT consensus
- Master's Thesis on Tendermint
- Original Whitepaper: "Tendermint: Consensus Without Mining"
- Tendermint Core Blog
- Cosmos Blog
Join us!
Tendermint Core is maintained by Interchain GmbH. If you'd like to work full-time on Tendermint Core, we're hiring!
Funding for Tendermint Core development comes primarily from the Interchain Foundation, a Swiss non-profit. The Tendermint trademark is owned by Tendermint Inc., the for-profit entity that also maintains tendermint.com.