Tendermint
Tendermint is a software for securely and consistently replicating an application on many machines. It provides consistent PoS BFT Consensus algorithm.
Properties
Prioritizes consistency over availability (see CAP theorem).
Can be used for both public and private chains. Private consortiums or public permissioned blockchains can be developed by setting permissioned nodes instead of a public PoS approach.
Provides instant block finality between 1-3 seconds. Every block is finalized once the block is committed and cannot be reversed. // TODO
Highly scalable. See the Tendermint's throughput section.
Guarantees safety in asynchronous & liveness in weekly synchronous environments. System stalls instead of breaking apart in case the whole network system falls. Assuming less than ⅓ of the validators are Byzantine, Tendermint guarantees that safety will never be violated — that is, validators will never commit conflicting blocks at the same height. Therefore, a Tendermint-based blockchain never forks.
Basis of PoS systems like Casper.
In terms of development, Tendermint is programmable in any language. // TODO, add examples of Tendermint implementations in different languages.
Business logic focused, instead of consensus focused.
–––––– TODO
Each block in Tendermint has a unique index - its Height. A block atHeight == Hcan only be committed_after_the block atHeight == H-1. Each block is committed by a known set of weighted Validators. Membership and weighting within this set may change over time. Tendermint guarantees the safety and liveness of the blockchain so long as less than 1/3 of the total weight of the Validator set is malicious or faulty.
A commit in Tendermint is a set of signed messages from more than 2/3 of the total weight of the current Validator set. Validators take turns proposing blocks and voting on them. Once enough votes are received, the block is considered committed. These votes are included in the_next_block as proof that the previous block was committed - they cannot be included in the current block, as that block has already been created.
Once a block is committed, it can be executed against an application. The application returns results for each of the transactions in the block. The application can also return changes to be made to the validator set, as well as a cryptographic digest of its latest state.
Tendermint is designed to enable efficient verification and authentication of the latest state of the blockchain. To achieve this, it embeds cryptographic commitments to certain information in the block "header". This information includes the contents of the block (eg. the transactions), the validator set committing the block, as well as the various results returned by the application. Note, however, that block execution only occurs_after_a block is committed. Thus, application results can only be included in the_next_block.
Also note that information like the transaction results and the validator set are never directly included in the block - only their cryptographic digests (Merkle roots) are. Hence, verification of a block requires a separate data structure to store this information. We call this theState. Block verification also requires access to the previous block.