c5cc3c8d3f
At Oasis we have spend some time writing a new Ed25519/X25519/sr25519 implementation called curve25519-voi. This PR switches the import from ed25519consensus/go-schnorrkel, which should lead to performance gains on most systems. Summary of changes: * curve25519-voi is now used for Ed25519 operations, following the existing ZIP-215 semantics. * curve25519-voi's public key cache is enabled (hardcoded size of 4096 entries, should be tuned, see the code comment) to accelerate repeated Ed25519 verification with the same public key(s). * (BREAKING) curve25519-voi is now used for sr25519 operations. This is a breaking change as the current sr25519 support does something decidedly non-standard when going from a MiniSecretKey to a SecretKey and or PublicKey (The expansion routine is called twice). While I believe the new behavior (that expands once and only once) to be more "correct", this changes the semantics as implemented. * curve25519-voi is now used for merlin since the included STROBE implementation produces much less garbage on the heap. Side issues fixed: * The version of go-schnorrkel that is currently imported by tendermint has a badly broken batch verification implementation. Upstream has fixed the issue after I reported it, so the version should be bumped in the interim. Open design questions/issues: * As noted, the public key cache size should be tuned. It is currently backed by a trivial thread-safe LRU cache, which is not scan-resistant, but replacing it with something better is a matter of implementing an interface. * As far as I can tell, the only reason why serial verification on batch failure is necessary is to provide more detailed error messages (that are only used in some unit tests). If you trust the batch verification to be consistent with serial verification then the fallback can be eliminated entirely (the BatchVerifier provided by the new library supports an option that omits the fallback if this is chosen as the way forward). * curve25519-voi's sr25519 support could use more optimization and more eyes on the code. The algorithm unfortunately is woefully under-specified, and the implementation was done primarily because I got really sad when I actually looked at go-schnorrkel, and we do not use the algorithm at this time.
Tendermint
Byzantine-Fault Tolerant State Machines. Or Blockchain, for short.
| Branch | Tests | Coverage | Linting |
|---|---|---|---|
| master |  |
 |
 |
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, 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
Please do not depend on master 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.
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 | Go1.15 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.
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, watch the Developer Sessions, and familiarize yourself with our Architectural Decision Records.
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 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
- config
- libs
- bits
- bytes
- json
- log
- math
- net
- os
- protoio
- rand
- sync
- strings
- service
- node
- rpc/client
- types
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 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.
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 is provided by tm-load-test.
Additional tooling can be found in /docs/tools.
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: "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.