Tendermint is a low-level blockchain engine that provides secure and consistent state replication on many machines. It is a weakly synchronous (mostly asynchronous), Byzantine Fault Tolerant (BFT) tool that is used as a plug-and-play consensus for arbitrary application states and distributed systems.
Primarily conceived as a more efficient and secure consensus mechanism to Bitcoin’s proof of work protocol, Tendermint has evolved over the course of its existence and is now the underlying consensus engine of the Cosmos Network.
Background of Tendermint
Tendermint is an open-source project proposed by Jae Kwon in 2014 in an academic publication that is now outdated but is a fascinating read if you have the time. It addresses the problem of secure and consistent replication in state machines that are inherently difficult to achieve.
In blockchain systems, the need to tolerate malicious actors compromising nodes and propagating false messages is a critical feature that allows them to function and come to an honest consensus on the state of the network. However, the means to achieve this consensus with Bitcoin’s proof of work model are inefficient and resource intensive. Tendermint proposed a new BFT model, particularly also focusing on allowing the primary consensus engine of the Tendermint software to be used in various other blockchain networks and be universally compatible with other programming languages.
Read: What is Nakamoto Consensus?
As a result, the initial concept of Tendermint has been optimized over the years to facilitate its use as a general purpose blockchain consensus engine with a proprietary application interface. Currently, Tendermint is the infrastructure engine of the Cosmos Network — a multi-chain framework platform — commonly known as the “Internet of Blockchains.”
Overall, Tendermint has some unique capabilities and intriguing technology. So how does it work?
How Does it Work?
Tendermint is a general purpose blockchain engine that can host arbitrary application states and is primarily composed of 2 major components:
- Tendermint Core – The Tendermint BFT consensus engine
- Application BlockChain Interface (ABCI) – Enables BFT replication of apps written in any programming language
Tendermint functions as a proof of stake protocol that is BFT. Designed as a plug-and-play tool, it is both intuitive to use and crafted for efficient interoperability. It can be implemented effectively as the consensus mechanism for any blockchain network. The ABCI decouples the consensus mechanism from the P2P layer of the application state and enables a clean interface between the application logic and the consensus engine.
Tendermint uses a proof of stake mechanism, which is critical to keep in mind when reading the below section. Let’s look at the 2 primary components.
Tendermint Core
The underlying consensus engine of the overall Tendermint software, Tendermint Core ensures that the machines in the distributed network record the order of transactions the same way. Since Tendermint is a BFT consensus mechanism, it makes the same assumptions as other BFT systems, specifically that no more than ⅓ of the nodes in the network can be byzantine at any given instance.
Similarly, it uses a round-based voting mechanism like other BFT mechanisms. To better put the concept into context, a list of similar BFT mechanics for selecting the leader node in each round is below:
- Practical BFT uses a round-robin style format for selecting the leader node for each round.
- Proof of Elapsed Time uses a randomized timer within SGX for its leader selection process.
- Bitcoin uses Nakamoto Consensus, where a proof of work computational puzzle is solved in a lottery-like format to determine the leader of each round (mining).
Tendermint uses an optimized version designed to scale to thousands of transactions per second and allow for easy plug-and-play functionality. We can break down the round in Tendermint BFT into 3 stages:
- Block Proposal
- Pre-vote
- Pre-commit
Participants in the protocol are validators. Validators propose and vote on blocks in the network based on their overall stake in the round. Therefore, the ⅓ BFT assumption is predicated on the “weight” of each validator — determined by their correlated stake — rather than ⅓ of the total nodes participating.
Validators maintain a full-client node with a copy of the blockchain and use public keys as their identifiers. The block proposal phase is when a validator proposes a new block in a round.
The pre-vote phase is where the validators vote on the proposed block and proceed to the pre-commit phase if more than ⅔ of the validators pre-vote the proposed block. This is known as a polka.
In the pre-commit round, if more than ⅔ of the validators pre-commit the pre-voted block, then the block is committed to the blockchain. Notably, every pre-commit must be justified by a polka in the same round.
Validators that propose failed blocks or sign inappropriate blocks risk having their stake slashed. The 3-step process iterated above is considered one round.
Tendermint is mostly asynchronous (or weakly synchronous) so it may take several rounds before a block is committed. The proposal process is partially synchronous while the voting process is asynchronous. According to Tendermint:
“Validators may fail to commit a block for a number of arbitrary reasons; i.e., the current proposer may be offline, or a network may be experiencing latency. Tendermint allows a validator to be skipped. Validators wait a small amount of time to receive a complete proposal block from the proposer before voting to move to the next round. This reliance on a timeout is what makes Tendermint a weakly synchronous protocol, rather than an asynchronous one. However, the rest of the protocol is asynchronous, and validators only make progress after hearing from more than ⅔ of the validator set.”
Due to its design, Tendermint guarantees that safety will never be violated, so a Tendermint blockchain will never fork. However, the network can halt due to the requirement that a supermajority of the validators has 100% uptime.
Overall, the consensus mechanism sacrifices a degree of liveness for consensus safety and instant finality.
Application BlockChain Interface (ABCI)
The ABCI is a critical component of the Tendermint flexibility and allows for BFT replication of applications to be written in any programming language.
Tendermint describes the motivation behind the ABCI as the monolithic stack design of current cryptocurrency platforms like Bitcoin and Ethereum. Monolithic designs lead to maintenance complexities of the protocol and limit the ability of other programming languages to interact with the blockchain. For instance, Ethereum supports a Turing-complete bytecode virtual machine, but programming languages are limited to those that can compile down to that bytecode such as Solidity and Vyper.
The primary implementation of the ABCI is the Tendermint Socket Protocol (TSP) and is how Tendermint Core communicates with the application. While Tendermint Core is responsible for maintaining and verifying the canonical order of transactions in the blocks of the blockchain, the ABCI validates cryptographic signatures, maintains the transaction database, and allows clients to query the transaction database.
The ABCI uses 3 primary message types:
- DeliverTX
- CheckTX
- Commit
The DeliverTX message accompanies every transaction in the blockchain and can only update the application state after validation.
The CheckTX message is for validating transactions and is first verified by Tendermint Core’s mempool. Only valid transactions are propagated across the network.
The Commit message computes a commitment to the current application state, enabling Merkle proofs to be verified against a block hash that is signed by a quorum.
The ABCI is connection-oriented, and Tendermint Core maintains three ABCI connections to the application.
- Mempool Connection
- Consensus Connection
- Query Connection
The Mempool Connection uses the CheckTX message and is for verifying whether transactions should be relayed before they’re committed.
The Consensus Connection executes transactions that have been committed.
The Query Connection allows clients to query the application state.
The ABCI is a dynamic component of the Tendermint software and is integral to the multi-chain framework capacity of the Cosmos Network, which it powers as the underlying blockchain engine of the network.
Image Credit – Tendermint Documentation
Tendermint & The Cosmos Network
The Cosmos Network is a multi-chain blockchain framework focusing on addressing the major issues of scalability and interoperability of blockchain systems.
Read: Blockchain Interoperability: Issues & Future Solutions
It is powered by the Tendermint classical BFT blockchain engine and acts as a broader structure for independent blockchains to plug into and function within a standardized environment of communication. The network allows both public and private blockchains to communicate and exchange value with each other and leverages interoperable scalability through Tendermint’s proof of stake consensus mechanism.
Further, the ABCI of Tendermint enables developers to easily build diverse blockchains as part of the ecosystem, using any programming language. The Cosmos SDK is an ABCI framework written in the Go programming language, and Lotion JS is an ABCI framework written in JavaScript.
There is substantial excitement surrounding multi-chain frameworks like Cosmos and Polkadot. You can find more information and resources about Cosmos and its integration with Tendermint in their documentation.
Conclusion
Tendermint represents another advance in research and development of Byzantine Fault Tolerance in distributed networks, particularly blockchain systems. These types of innovations are crucial to the development of more scalable and interoperable blockchain networks like Cosmos.
Tendermint and similar progressions in BFT consensus are excellent examples of how far the cryptocurrency industry has come in pushing the envelope in cutting-edge technologies. Much more innovation is needed for the broader concept behind blockchain technology to achieve its true potential, but projects are on the right track and are dynamically changing the distributed computing landscape.
