Exploring Tendermint Consensus

Bitcoin’s impact on the world of digital assets has been monumental, almost indescribable. Since the publication of its whitepaper in 2008, it has gone on to introduce many innovations to the world. One of those innovations is blockchain technology. With its intricate structure as a chain that holds pieces of data, it is difficult not to mention it when discussing cryptocurrency. 

Ever since its release, blockchain technology has been subject to widespread adoption. Many of the largest companies in the world are implementing the technology into their operations. Ethereum would later go on to present to the world the sheer strength and versatility of this cutting-edge technology.

However, along with this fast adoption comes a variety of issues. The main problems stem primarily from the topics of scalability and interoperability. In the case of scalability, it has to do with less than favourable transaction times. Ethereum manages roughly 20 transactions per second, whereas Bitcoin only manages less than 10. In the case of interoperability, the problem is communication difficulties. The truth of the matter is that it’s hard for individual entities (Litecoin, Bitcoin, etc.) to communicate with each other.

It is here that the Cosmos blockchain comes in. This is a system that is aspiring to solve these issues and bring blockchains to the next level. Its goal is to essentially become an “internet of blockchains.” To put simply, it is a project that shows great potential, and at the center of it is ‘Tendermint Core’.

What is it?

Cosmos’ architecture largely consists of an array of independent blockchains that go by the name ‘Zones’. They all attach themselves to the ‘Hub’, which is a central blockchain. According to the Cosmo whitepaper:

The zones are powered by Tendermint Core, which provides a high-performance, consistent, secure PBFT-like consensus engine, where strict fork-accountability guarantees hold over the behavior of malicious actors. Tendermint Core’s BFT consensus algorithm is well suited for scaling public proof-of-stake blockchains.”

Tendermint is software whose purpose is to securely and consistently replicate an application on a series of machines. In terms of “securely,” Tendermint operates even if a third of the machines fail in erratic ways. In terms of “consistently,” every non-faulty machine is able to see the same transaction log. Moreover, they can calculate the exact same state.

A replication that is both secure and consistent is a fundamental problem within distributed systems. Generally speaking, its role is integral in the fault tolerance of an extensive range of applications. These can often range from currencies to elections to infrastructure orchestration and anything beyond that.

Tendermint Core is a combination consisting of the Tendermint consensus algorithm and a peer-to-peer gossip protocol. When you put it all together in the software stack, you will end up with the Tendermint Core, plus the Cosmos-SDK application layer.

The technical side

The capability of enduring machine failure in arbitrary ways, including the machine becoming malicious, is ‘Byzantine fault tolerance’ (BFT). BFT is the characteristic that defines a system that tolerates the class of failures that correlate with the Byzantine Generals’ Problem. It is arguably the most difficult class of failure modes. The core theory of BFT is not new; it has been around for many years. However, the popularity of software implementations is relatively recent. This is mostly because of the success of blockchain technology, such as Bitcoin and Ethereum.

In essence, blockchain technology is just a reformation of BFT; specifically, in a modern setting. It places heavy emphasis on both peer-to-peer networking and cryptographic verification. The name comes from transactions basically being put into blocks. Each of these blocks contains a cryptographic hash of the one prior. When together, it builds a chain. Realistically speaking, the entire structure of blockchain data enhances the design of BFT.

Within Tendermint, there are two key technical components. One is a blockchain consensus engine and the other is a common application interface. The consensus engine (i.e. Tendermint Core) guarantees that every machine records the same transactions in the same order. The application interface – the Application Blockchain Interface (ABCI) – allows the transactions to undergo processing in any programming language.

Most other blockchain and consensus solutions come with built-in state machines. Think of them as an upscale key-value store or a unique scripting language. Conversely, developers can utilize Tendermint as a way to BFT state machine replication of applications. It is written in whatever programming language and development environment is suitable for them.

Architecture & ABCI

By utilizing the modular architecture, Tendermint’s concentrates on the following goals:

  • Supply the networking and consensus layers of a blockchain as a platform, where the construction of various decentralized applications is possible.
  • The only concern developers have to focus on is the application layer of the blockchain. Doing so will cut down on the time they waste working on both the consensus and the networking layer.
  • The software also includes the Tendermint consensus protocol. This is basically the BFT consensus algorithm that the Tendermint Core engine uses.

The entirety of the application connects to Tendermint Core by way of the ABCI socket protocol. Tendermint Core and the application running on it operate in different UNIX processes. Therefore, it is a requirement that they have a way in which they can speak with each other. ABCI has the ability to help these two with their communication.

The question that comes to mind at this point is “what does ABCI’s design look like?” The most straightforward answer is that ABCI has a collection of distinct design components.

Component #1 – Message Protocol

  • Pairs that consist of request and response messages
  • The creation of requests is by the consensus and the application deals with the response
  • Protocol Buffers (aka. protobuf) define it

Component #2 – Server & Client

  • The running of the client is done by the consensus engine
  • Application is responsible for the operation of the server
  • There are two proper and conventional implementations: 1) async raw bytes, and 2) grpc

Component #3 – Blockchain Protocol

If there is anything ABCI aligns with the most, it’s connection. There are three specific connections for Tendermint Core, and they are the following:

  1. Mempool connection – This connection inspects the transactions to see if they need to be relayed before they are committed. To do this, it can only use CheckTx.
  2. Consensus connection – This connection aids in the execution of transactions that have already been committed. The message sequence for every block goes like this: BeginBlock, [DeliverTx, …], EndBlock, Commit
  3. Query connection – This connection helps with the query about the application state. To do this, it only uses Query and Info.

More on ABCI message types

The DeliverTx message is the main worker of the application. This message accompanies each transaction upon delivery to the blockchain. It is a requirement for the application to verify each transaction it receives with the DeliverTx message. Moreover, when it’s against the current state, application protocol, and the cryptographic references of the transaction. A validated transaction then has to update the application state. It does so by attaching a value to a key values store. Alternatively, by – for instance – revising the UTXO database.

The CheckTx message shares some similarities with DeliverTx. What sets them apart, though, is that CheckTx is solely for transaction validation. First, Tendermint Core’s mempool checks the validity of a transaction by utilizing CheckTx, only transmitting credible transactions to its peers. For example, an application may review an advancing sequence number in the transaction. Furthermore, they return an error upon CheckTx should the sequence number turn out to be old. Otherwise, they might employ a system drawing from capabilities. To elaborate, a system that requires capabilities to be subject to renewal with every transaction.

The Commit message is useful for calculating a cryptographic commitment to the current application state. This is so that it can be placed into the ensuing block header. The properties that come with this are extremely handy. Any inconsistencies that occur when updating that state will appear as blockchain forks. Consequently, it will detect an entire class of programming errors. In addition, it will simplify the gradual development of secure lightweight clients. This is because Merkle-hash proofs are verifiable by way of checking against the block hash. On top of that, a quorum signs the block hash.

The appealing properties

By now, it’s evident that Tendermint’s intent is to provide developers with a practical tool. Not only that but to give these developers a tool that has a high throughput. To condense the appeal of Tendermint down to one or two points would provide little credit to the system. To further emphasize what makes it so alluring, we need to go over some other properties.

Property #1 – Compatibility with a public or private blockchain

Every project has its own specific set of needs. There are some projects that require an open system that anyone can join and be able to contribute. An example of such a project is Ethereum. On the other end of the spectrum, we have organizations like the Medical Industry. Groups like this cannot expose their data to anybody. In their case, they need something along the lines of the permissioned blockchain.

So, how does a system like Tendermint go about helping to appease both of these needs? Keep in mind that Tendermint predominantly deals with the networking and consensus for the blockchain. With that said, it helps in the following ways:

  • It aids the propagation of the transaction between the nodes through the use of the gossip protocol.
  • It assists the validators in deciding and ultimately agreeing on the set of transactions that gets to join the blockchain.

What this boils down to is the application layer being free to be defined in whatever way that the developers want. It is up to the developers as to how the validator set will be defined once it’s in the ecosystem. They have a couple of options:

  1. They can allow the application to have an election system. This system will elect validators by drawing from how many native tokens these validators stake within the ecosystem. This is otherwise known as ‘proof-of-stake’. They can then build a public blockchain
  2. The developers can create an application defining a restricted set of pre-approved validators. These validators tend to the consensus and the new nodes that are able to enter the ecosystem. This is ‘proof-of-authority’ and it is the trademark of a permissioned or private blockchain.

Property #2 – A tremendous performance

The applications that Tendermint Core makes have the capability of carrying out exceptional performances. The average block time of Tendermint Core is just 1 second. Furthermore, it is able to manage a transaction volume of 10,000 transactions per second for 250byte transactions. It’s important to note that this is only if the application allows it to do so.

Property #3 – A sense of finality

‘Finality’, in basic terms, means that upon the execution of a certain action, it is impossible to take it back. To further illustrate it, imagine a conventional financial transaction. Let’s assume that you purchase a handful of stocks in a company. Just because there is a glitch in their system, that doesn’t mean you should lose out on stock ownership. At the risk of stating the obvious, finality is crucial for any financial system. Imagine conducting a million-dollar transaction and then the next day, that transaction is not valid. What’s more, that lack of validity is thanks to a glitch.

Bitcoin and Ethereum (that is, until full implementation of Casper FFG) do not necessarily have settlement finality. Upon the occurrence of a hard fork or a 51% attack, there is a chance for transactions to regress.

This is where Tendermint deviates from the norm. It provides users with instantaneous finality within 1 second of completing the transaction. Forks do not undergo their creation within the system when less than 2/3rd of the validators are malicious. Once there is the creation of a block (which happens within a second), the users know that their transaction is finalized.

Property #4 – Strong security

Tendermint is a secure system that demands its participants to be accountable for their actions. As you may recall, it’s not possible for Tendermint to fork if less than 2/3rd of the validators are malicious. If for any reason the blockchain does end up forking, then you need not worry. There actually is a way to determine the liability. Moreover, Tendermint consensus is a fault-tolerant system and as a bonus, it is also Byzantine fault-tolerant.

Property #5 – It is very easy to use

On top of its exceptional security and transaction performance, another admirable thing about Tendermint is how user-friendly it is. To reference what was discussed earlier, they possess a modular architecture that allows for the customization of the application layer. This effectively makes it possible for the linkage of pre-existing blockchain codebases to Tendermint by way of ABCIs.

An ideal example of this is Etheremint. In essence, it is the Ethereum Virtual Machine codebase plug on top of Tendermint. The primary function of Ethermint is similar to Ethereum. However, it also benefits from the positive features that we have been going over thus far. All tools that correlate with Ethereum, like Metamask and Truffle, are compatible with Ethermint.

Property #6 – Scalability

The proof-of-stake implementation of Tendermint is considerably more scalable than a standard proof-of-work consensus algorithm. The primary reason for this being that POW systems are unable to do any sharding. The concept of sharding is essentially horizontal separation of a database. This creates smaller databases (or shards) which the nodes then parallelly execute. The reason for this being that a strong mining pool is capable of taking over a shard rather easily.

Tendermint will allow the implementation of sharding. As a result, it will increase the scalability by an exceptional amount.

A brief overview of Proof-of-Work

Before moving forward, let us first clarify the connection ‘proof-of-work’ has with Tendermint. To do that, we have to define it.

A proof-of-work system (alternatively a protocol or function) is a type of consensus mechanism. The POW system averts denial of service attacks and other similar service abuses. Such attacks and abuses include spam on a network. To deter them, the system requires some work from the service requester. Most of the time this means processing time by a computer.

Proof-of-work also makes it difficult for any aspect of the blockchain to undergo alteration. This is because such an alteration would require re-mining all consecutive blocks. It makes it hard for a user or user pool to dominate the network’s computing power. The reason for this being that the machinery and power that can complete the hash functions are very costly.

There are three key problems that come with the POW algorithm.

  1. Energy wastage: Bitcoin tends to eat up a substantial amount of power. This incredible waste of energy is one of the most noteworthy principles of Bitcoin. Overall, it’s a complete waste for the sake of waste.
  2. Centralization: Bitcoin utilizes ASICs for the purpose of mining. The main problem with that is how expensive ASICs. Moreover, pools with more money are prone to having more ASICs and, as a result, more mining power. Therefore, Bitcoin is not really as decentralized as it claims to be.
  3. Scalability: The basic architecture of POW does not allow for scalability. Bitcoin manages very few transactions per second; less than 10, if you recall. For a financial system in modern times, it’s not satisfactory enough.

Enter Tendermint, whose system was built to counteract these issues. Its construction was in a permissionless setting with the proof-of-stake as the fundamental security mechanism.

Introduction to consensus

Before we talk about the consensus protocol, let us first elaborate on consensus decision-making. Wikipedia’s definition of this concept is as follows:

Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the “favorite” of each individual. “Consensus” is defined by Merriam-Webster as, first, general agreement, and second, group solidarity of belief or sentiment.”

To put simply, the consensus is a compelling method of coming to an agreement in a group. Voting merely settles for a majority rule, taking little to no consideration into the feelings and well-being of the minority. Conversely, a consensus ensures the reaching of an agreement, which could potentially benefit the entire group.

Objectives of the mechanism

The method that makes consensus decision-making achievable is what is known as ‘consensus mechanism’. The objectives pertaining to a consensus mechanism are:

  • Agreement Seeking: It is imperative that a consensus mechanism brings about as much agreement from the group as it possibly can.
  • Collaborative: All participants should focus on collaborating in order to achieve the ideal result that puts the group’s best interest first.
  • Cooperative: All participants should not put their own interests above everyone else’s and they should work as a team, not individuals.
  • Participatory: The consensus mechanism needs to be able to allow everyone to actively participate in the overall process.
  • Inclusive: As many people as possible should be able to participate in the consensus process. Under no circumstances should the process be like normal voting. Specifically, where people do not feel like voting due to the belief that their vote will not impact anything.
  • Egalitarian: The group that is trying to achieve consensus should be as egalitarian as possible. This means that each and every vote has equal weight and every individual is equal in fundamental worth. One person’s vote cannot hold more worth and importance than another person’s vote.

The protocol

Tendermint is a BFT consensus protocol that is straightforward and predominantly asynchronous. This refers to a procedure requiring a form of a computer control timing protocol. In it, a specific operation commences upon receiving a signal that indicates the completion of the preceding operation.

Participants in the protocol go by the name of ‘validators’. Their job is to take turns proposing blocks of transactions and eventually voting on them. The blocks are attached to a chain, with one block at each height. In some cases, a block may be unable to attach. In this particular instance, the protocol will move on to the next round. Furthermore, a new validator will get to propose a block for that specific height.

There are two stages of voting that are a requirement for successfully committing a block. The majority typically call them ‘pre-vote’ and ‘pre-commit’. A block is will undergo an attachment when more than 2/3rd of validators pre-commit for the same block in the same round. When more than 2/3rd of the validators pre-vote for the same block, that is what’s called a ‘polka’. Every pre-commit has to be justifiable in the proverbial eyes of a polka within the same round.

Commitment failure & Locking

Validators will sometimes fail to commit a block for several different reasons. Maybe the current proposer is currently offline, or maybe the network is running pretty slow. Tendermint grants them the ability to establish if they should skip a specific validator. Validators standby and wait for a short period of time to receive a complete proposal block from the proposer. Only then will they be able to vote on moving on to the next round.

This dependency on a timeout is what basically makes Tendermint a fragile synchronous protocol, instead of an asynchronous one. Be that as it may, the rest of the protocol is asynchronous. What’s more, validators will only make progress after they hear from more than 2/3rd of the validator set. A notable element of Tendermint is that it utilizes the exact same mechanism to attach a block that lets them skip to the next round.

If less than 1/3rd of the validators are Byzantine, then Tendermint ensures that safety will never experience a violation. That is to say, validators will never commit contradictory blocks at the same height. To properly carry this out, it introduces a few locking rules. These rules will regulate which paths are worth following in the flow diagram. As soon as a validator pre-commits a block, it will lock on that block. Then…

  1. …it has to prevote for the block it is locked on.
  2. …it is only able to unlock and pre-commit for a new block. That is if there is a polka for that block later in another round.


In most systems, not all of the validators will possess the exact same “weight” in the consensus protocol. Therefore, we do not show much interest in 1/3rd or 2/3rd of the validators. Instead, we show interest in those proportions of the total voting power. It should be noted that there may not be orderly distribution across individual validators.

The Tendermint system is able to replicate arbitrary applications, so it is conceivable to define a currency. Moreover, to designate the voting power in that particular currency. When a native currency has the designation of voting power, the system is often proof-of-stake.

Validators can typically be forced – by application logic – to “bond” their currency holdings in a security deposit. This deposit can be destroyed if they misbehave in the consensus protocol. As a result, there is an addition of an economic element to the security of the protocol. This allows someone to measure the cost of a violation of a particular assumption. That assumption being that less than 1/3rd of voting power is Byzantine.

The design of the Cosmos network allows it to use this Proof-of-Stake mechanism. It can do so across a wide variety of cryptocurrencies that implement as ABCI applications.

trade predictions