ae275d791e
(left after committing a block) Fixes #2961 -------------- ORIGINAL ISSUE Tendermint version : 0.26.4-b771798d ABCI app : kv-store Environment: OS (e.g. from /etc/os-release): macOS 10.14.1 What happened: Set mempool.recheck = false and create empty block = false in config.toml. When transactions get added right between a new empty block is being proposed and committed, the proposer won't propose new block for that transactions immediately after. That transactions are stuck in the mempool until a new transaction is added and trigger the proposer. What you expected to happen: If there is a transaction left in the mempool, new block should be proposed immediately. Have you tried the latest version: yes How to reproduce it (as minimally and precisely as possible): Fire two transaction using broadcast_tx_sync with specific delay between them. (You may need to do it multiple time before the right delay is found, on my machine the delay is 0.98s) Logs (paste a small part showing an error (< 10 lines) or link a pastebin, gist, etc. containing more of the log file): https://pastebin.com/0Wt6uhPF Config (you can paste only the changes you've made): [mempool] recheck = false create_empty_block = false Anything else we need to know: In mempool.go, we found that proposer will immediately propose new block if Last committed block has some transaction (causing AppHash to changed) or mem.notifyTxsAvailable() is called. Our scenario is as followed. A transaction is fired, it will create 1 block with 1 tx (line 1-4 in the log) and 1 empty block. After the empty block is proposed but before it is committed, second transaction is fired and added to mempool. (line 8-16) Now, since the last committed block is empty and mem.notifyTxsAvailable() will be called only if mempool.recheck = true. The proposer won't immediately propose new block, causing the second transaction to stuck in mempool until another transaction is added to mempool and trigger mem.notifyTxsAvailable().
Tendermint
Byzantine-Fault Tolerant State Machine Replication. Or Blockchain for short.
| Branch | Tests | Coverage |
|---|---|---|
| master |  |
 |
| develop |  |
 |
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".
A Note on Production Readiness
While Tendermint is being used in production in private, permissioned environments, we are still working actively to harden and audit it in preparation for use in public blockchains, such as the Cosmos Network. We are also still making breaking changes to the protocol and the APIs. Thus, we tag the releases as alpha software.
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.10 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
Resources
Tendermint Core
For details about the blockchain data structures and the p2p protocols, see the the Tendermint specification.
For details on using the software, see the documentation which is also hosted at: https://tendermint.com/docs/
Tools
Benchmarking and monitoring is provided by tm-bench and tm-monitor, respectively.
Their code is found here and these binaries need to be built seperately.
Additional documentation is found here.
Sub-projects
Applications
- Cosmos SDK; a cryptocurrency application framework
- Ethermint; Ethereum on Tendermint
- Many more
Research
Contributing
Yay open source! Please see our contributing guidelines.
Versioning
SemVer
Tendermint uses SemVer 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:
- 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 here
Code of Conduct
Please read, understand and adhere to our code of conduct.