The progress of the blockchain network consensus algorithm represents a higher level of efficiency and security. After we understand the pow of Bitcoin and the pos consensus of Ethereum and other chains, we can find that many consensuses are improved from the bft consensus. However, there are also innovators in the other direction, namely Tendermint. The most typical representative of Tendermint is Cosmos and projects created using the Cosmos SDK, and networks such as Oasis also use Tendermint.
In this article, we summarize the Tendermint data for an overall understanding.
Tendermint is an application used to replicate securely and consistently across multiple machines, where security is expressed as Tendermint works even if up to 1/3 of the machines fail in any way; consistent means that each machine does not fail machines see the same transaction log and compute the same state.
The ability to tolerate machines failing in arbitrary ways (including becoming malicious) is known as Byzantine Fault Tolerance (BFT). Blockchain technology transforms BFT to place more emphasis on peer-to-peer networking and cryptographic authentication. Transactions are batched in blocks to form a chain, and this blockchain data structure actually optimizes the BFT design.
The improved Tendermint can be called an easy-to-understand, asynchronous BFT consensus protocol. The protocol follows a simple state machine operation as shown below:
The participants in the protocol, called validators, take turns proposing blocks of transactions and voting on them. Blocks are committed in the chain, one block per height. When a block cannot be submitted, the protocol goes to the next round, and new validators can propose another block for that height.
A successful block commit requires two stages of voting; called pre-vote and pre-commit. A block is committed when more than 2/3 of the validators have pre-committed for the same block in the same round.
In the lower right corner of the illustration is a photo of a couple dancing polka, called polka when more than two-thirds of validators pre-vote for the same block. Each pre-commit must be justified by a polka in the same round.
A validator may fail to submit a block for a number of reasons, for example the current proposer may be offline, or the network may be slow. Tendermint allows them to determine that validators should be skipped. Because the validator wait time timeout makes Tendermint a weakly synchronous protocol rather than an asynchronous one. The rest of the protocol happens asynchronously, though, and ultimately validators can only make progress after receiving more than two-thirds of the validator set’s opinion. A simplified element of Tendermint is that it uses the same mechanism to commit a block as it does to skip to the next round.
Assuming that less than one-third of validators are Byzantine, Tendermint guarantees that security will never be violated, i.e. validators will never commit conflicting blocks at the same height. To this end, locking rules are introduced that regulate the paths that can be followed in the flow graph, and once a validator pre-commits a block, it is locked on that block. That validator must vote for the block it locks, and can only unlock and pre-commit a new block if there is a polka for that block in a later round.
At the software level, Tendermint consists of two main technical components: a blockchain consensus engine and a common application programming interface. A consensus engine called Tendermint Core ensures that identical transactions are recorded on every machine in the same order. The application programming interface, called the Application Blockchain Interface (ABCI), enables transactions to be processed in any programming language. Unlike other blockchain and consensus solutions that come pre-installed with built-in state machines, developers can use Tendermint to replicate BFT state machines for applications written in any programming language. Therefore, it can be seen that Tendermint is designed to be easy to use, easy to understand, high performance and suitable for various distributed applications.
Tendermint has evolved into a general-purpose blockchain consensus engine that can host arbitrary application state. This means it can be used as a plug-and-play replacement for other blockchain software consensus engines.
Tendermint Core communicates with applications primarily by meeting ABCI’s protocol requirements. Tendermint is able to decompose the blockchain design by providing a very simple API (i.e. ABCI) between the application process and the consensus process.
ABCI consists of the following 3 main message types, which are passed from the core to the application. The application replies with the corresponding response message.
DeliverTx message, through which every transaction in the blockchain is delivered. Applications need to verify each transaction received via DeliverTx messages based on the current state, the application protocol, and the transaction’s cryptographic credentials. Then, the verified transaction needs to update the application state.
CheckTx messages are similar to DeliverTx, but are only used to verify transactions. Tendermint Core’s mempool first checks the validity of a transaction using CheckTx, and only relays valid transactions to its peers. .
The Commit message is used to calculate a cryptographic commitment to the current application state to put into the next block header.
So it can be summed up that there are three ABCI connections created in Tendermint Core to the application; one for validating transactions when broadcast in the memory pool, one for the consensus engine to run block proposals, and one for querying the application condition.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/tendermint-the-representative-of-the-new-school-consensus/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.