Code Talks: Tendermint Introduction and Analysis

Technical analysis of Tendermint, discussions on how consensus is formed, and a tutorial on building your own public chain in just 15 minutes.

PPIO Code Talks is an open platform for high-quality presentations and discussions on blockchain technology with the aim of engaging the community and spreading ideas. The following is an adaption of a slideshow presentation given on June 29 by PPIO’s Senior Blockchain Engineer Wu Shouhe. Talks were also given by other prominent members of the Shanghai blockchain and internet industry.

When it comes to blockchain technology, most people think of Bitcoin and Ethereum. Indeed both are representative of the origin and development of blockchain technology and as a result, have been widely disseminated and intensively studied. However, with the continuous development of Bitcoin, the shortcomings of Bitcoin’s workload proof consensus mechanism, in terms of speed and scalability, have gradually emerged.

Tendermint, the Cosmos ecosystem’s development team, realized Bitcoin’s shortcomings as early as 2014 and has focused on finding consensus mechanisms that do not rely on high power consumption — such as mining — to provide fast transaction processing capabilities. Their goal with Tendermint is to provide speed, security, and scalability for all blockchains around the world. At present, Tendermint is the core of cross-chain technology.

The Tendermint protocol has many similarities to Bitcoin as they both record information through blocks. However, each has a different solution to the problem of the “Byzantine General” consensus mechanism. Bitcoin’s protocol optimizes a decentralized auditing mechanism, while Tendermint optimizes Byzantine fault tolerance for distributed applications and data processing in multi-node WANs which can include nodes that number in the millions. The above two figures introduce Tendermint’s software development layer and application deployment network structure.

At present, most blockchain implementations use a “network-consensus algorithm-application” framework to implement a monolithic program, but this can easily cause two problems:

1. Code reuse is difficult, and branch management of the codebase becomes complicated.
2. Limits the language of application development.

In response to these two issues, Tendermint designed its own set of frameworks that are easy to use, easy to understand, and offer high performance for a variety of distributed applications. Its innovation is that the blockchain application (state) is separated from the underlying consensus, and the consensus engine and P2P network layer are packaged into Tendermint Core. At the same time, their Application BlockChain Interface (ABCI) is used to interact with the application layer. The application logic can be written in any language. The application is actually controlled by the state machine. Not only that, but Tendermint also provides a number of useful development libraries, such as password libraries, Merkel trees, iavl state trees, and more. Based on this architecture, application developers can easily implement their own blockchain.

Next, we will dig deeper into the details of Tendermint covering three central components: the consensus algorithm, state machine replication, and the ABCI interface.

The figure below shows the Tendermint block procedure selection mechanism and its advantages and disadvantages.

There are two main roles involved in the Tendermint consensus process:

• Validator: A node in the network can vote in the consensus process. Different Validators may have different voting power during the voting process.
• Proposer: A round Proposer is chosen from the Validators using a deterministic non-blocking polling selection algorithm that selects the Proposer based on the proportion of voting weights of the Validators. The higher the voting power, the faster the Validator moves to the front of the queue and becomes a Proposer.

The Tendermint blockchain is determined by a round-based mechanism to determine the next block. Each round consists of three processes: propose, prevote, and precommit.

The advantage of this mechanism is that the Proposer’s choice is related to Stake, so the application layer can implement its own consensus (DPOS), passing the weight of the application layer’s Validator to Tendermint. Tendermint will then choose a Proposer in the way that the application layer needs. Of course, no technology is perfect. This mechanism also has a disadvantage as this round-robin strategy is too simple. It is easy for a malicious player to predict who the next Validator is then DDoS attack that Validator in advance. The solution proposed by Tendermint is to put the Validator node behind the Sentry Node to prevent the IP address from being exposed.

Tendermint has an easy to understand BFT consensus protocol. This protocol follows a simple state machine: the Validators take turns proposing blocks for the transaction and voting on the proposed blocks. The blocks are submitted to the chain with each block on the chain at each height. However, the block may also fail to submit. In this case, the protocol will select the next certifier to propose a new block at the same height and start voting again.

As shown in the above figure, in order to successfully submit a block, you must go through two stages of voting, called a pre-vote and a pre-commit. When more than 2/3 of the certifiers pre-commit the same block in the same round, the block will be submitted.

Due to offline or network delays, etc., the proposer may propose a block failure. This situation is also allowed in Tendermint because the Validators will wait a certain amount of time before receiving the next round of offers of the block proposed by the proposer.

Assuming that less than 1/3 of the Validators are Byzantine nodes, Tendermint can guarantee that the Validator will never repeatedly submit the block at the same height and cause a conflict. To do this, Tendermint introduces a locking mechanism that is locked in the block once the Validator has pre-voted a block. The following two situations will then occur:

• The Validator must pre-vote in the pre-submitted block contest.
• When the current round of pre-proposal and pre-voting does not successfully submit the block, the Validator will be unlocked and then the next round of pre-submissions for the new block will be made.

The advantage of Tendermint is the certainty of its consensus: unlike the consensus of Bitcoin and Ethereum that has the probability of becoming invalid at some point in the future, the consensus of Tendermint is permanent once achieved. Therefore, there is no blockchain fork in Tendermint. The downside is that the Tendermint consensus is Byzantine fault-tolerant, with up to 1/3 of malicious nodes being tolerated, whereas Bitcoin can tolerate up to 50% of malicious nodes.

The figure above shows Tendermint’s state machine replication process, and its security is that the BFT algorithm guarantees that there is only one block at the same height.

Tendermint Core interacts with applications through a socket protocol that satisfies the ABCI standard.

ABCI contains three message types: DeliverTx messages, CheckTx messages, and Commit messages. The Tendermint Core sends the message to the application, and the application responds accordingly based on the message.

DeliverTx messaging is the primary workflow for an application. Every transaction on the chain is transmitted with this message. Applications must validate every transaction that is received with DeliverTx against the current state, application protocol, and transaction encryption credentials. The verified transaction then updates the app status.

The CheckTx message is similar to DeliverTx, but it is only used to verify transactions. The Tendermint Core’s memory pool first uses CheckTx to verify the validity of the transaction and only broadcasts valid transactions to other nodes.

The Commit message is used to inform the application to calculate the encryption guarantee for the current application state, which is guaranteed to be placed at the head of the next block.

An application may be connected to multiple ABCI sockets. Tendermint Core creates three ABCI connections for the application: one for transaction validation when the memory pool is broadcast, one for the consensus engine when the block is proposed, and one for querying the application state.

Below is a look at how you can develop your own public chain with Tendermint. It’s easy to do and we encourage everyone to follow along.

More In The Code Talks Series

• Libra and PPIO: Our first Code Talks coincided with the announcement of Libra so we break down how it works and then share what we can learn from it.
• The A-to-Z on zkSnarks: Why zero-knowledge proof is ideal for authentication so no one else can knows what you’re communicating.
• Talking Sense About Digital Currency Exchanges: Unpacking the business mechanics of exchanges and the biggest challenges they need to know in order to grow.

Want more? Join the PPIO community on Discord or follow us on Twitter.