Altcoin News

A Deep Look into Consensus behind High-Performance ThunderChain

A consensus algorithm is used to achieve agreement. For blockchain, it defines the criteria for such achievement, or what should be followed if data do not agree with one another.

ThunderChain, a high-performance blockchain which handles more than millions of transactions per second, uses consensus algorithm based on DPoA+PBFT. As lately unveiled at ThunderChain Salon, ThunderChain engineers discussed why this consensus works best for the platform and what differences from other algorithms are.

Screenshot 2018-11-21 at 8.40.19 PM

Today’s consensus algorithms provide either probable or absolute agreement. The probable algorithms allow some disagreement among data from time to time. This is the typical case with Bitcoin, which is forked if two different nodes simultaneously find satisfying formulas, i.e., both are eligible to generate a block, during the consensus process. Disagreement exists shortly thereafter, until agreement is reached and the fork is corrected in the next round of mining and consensus.

The absolute algorithms always maintain agreement among data by sacrificing some availability. They are subdivided into those of Crash Fault Tolerance (CFT) and those of Byzantine Fault Tolerance (BFT).

A CFT algorithm reaches consensus as long as confirmation is given by a fixed number of nodes. For example, it deems a transaction to be closed if 4 out of 11 nodes cast favourable votes. This contributes to fast confirmation of transactions, perpetually determined results, and elimination of forks.

BFT algorithms are another common consensus models. They achieve consensus by going through three phases, namely, Pre-prepare, Prepare, and Commit, as follows:

1. Pre-prepare: When a node receives a request from a customer, it picks a sequence No. and broadcasts a PRE-PREPARE message to other nodes;

2. Prepare: Once any of the other nodes receives the PRE-PREPARE message, it validates the message. If the message is accepted, the node sends to other nodes a PREPARE message that comes with its node ID. In addition, the node receives and validates PREPARE messages from other nodes. A message cannot be prepared unless it has been verified by at least 2/3 of the nodes across the network;

3. Commit: The prepared message is broadcasted to all nodes across the network and is accepted once 2/3 of the nodes cast favourable votes have been reached.

Pros and Cons of Consensus Algorithms

The probable algorithms represented by Bitcoin are disadvantageous in their long time spent in confirmation. Before a transaction can be confirmed, Bitcoin has to generate six blocks with one in 10 minutes. It requires 60 minutes to confirm a single transaction and cannot guarantee successful payment. This seems impractical in real-life scenarios – who can pay and wait for a whole hour to settle the payment?

The issues of CFT algorithms are failures in preventing nodes familiar with each other to collude in confirming virtually all transactions. In addition, it cannot keep a node from, for example, simultaneously sending two opposite confirmation requests, one to four nodes and the other to other nodes. If this node succeeds in its malicious attempt, two antithetic transaction results are produced at the same time and system deviation occurs.

Therefore, CFT algorithms can be used only where node integrity is ensured such as on private chains.

BFT algorithms remove the above deficiencies. They deter malicious transactions by taking two rounds of voting and multiple verifications for each transaction.
However, these algorithms come with two disadvantages. The first is lower tolerance. Because each voting round requires favourable votes by at least 2/3 nodes, failure of 1/3 or more of the nodes is intolerable and will halt the entire blockchain.
The second disadvantage is the traffic. User traffic cam be as huge as a second power of the number of nodes over the network due to network-wide broadcasting in each of the three phases. BFT algorithms are inefficient where there are too many nodes.

Consensus Algorithm on ThunderChain

To better adapt to large-scale business scenarios, ThunderChain uses a proprietary consensus algorithm that is based on Practical Byzantine Fault Tolerance (PBFT) and Delegated Proof-of-Ability (DPoA) in homogeneous multi-chain architecture.

ThunderChain first selects premium nodes from its 1.5 million underlying nodes provided by OneThing Cloud shared computing. All these selected nodes feature stable Internet access, smooth transmission and good performance. They are gathered into a candidate pool. Next, the blockchain chooses a certain number of nodes from the pool and sets up its accounting network using the DPoA algorithm. The accounting nodes will be rotated and re-elected on a regular time basis to keep them from being exposed and attacked.

PBFT is used for accounting purpose. It is an ideal choice for business practice thanks to its fast confirmation, excellent concurrent processing, and perpetual fork immunity that provides robust consistency.

But PBFT still has its disadvantages. The first is in its low tolerance, or that it requires a high percentage of accounting nodes to be accessible over the Internet. The second is its huge traffic that disqualifies it for blockchains consisting of too many nodes. Fortunately, ThunderChain can counter these disadvantages by its design.
First, all accounting nodes are the best-of-best chosen ones that inherently boast low failure rate. Even if any of them does fail, it will have an immediate substitute from the huge number of candidates. After all, more than 1.5 million of nodes in total provide a profusion of candidates at any time.
Secondly, there will not be too many nodes performing accounting tasks at the same time because the accounting nodes are selected by the DPoA algorithm, thereby perfectly avoiding the huge traffic of PBFT.

With this double-algorithm design, ThunderChain is a highly secured and decentralized blockchain that not only provides superior performance such as millions of transactions per second (TPS) and verification in seconds but also eliminates forking and rollback.

Overall, no consensus is the best, no matter it is POW or DPoA+PBFT. Developers need to select algorithm subject to its underlying blockchain, or what business scenarios and purposes are targeted by the blockchain project.

About the author


Prateek Kulhari

Prateek is a business editor who writes about various topics such as technology, health and finance. At Pressly, he works along with the colourful folks that build a nation through tech startups. He is also a professional football player and video games enthusiast.

Add Comment

Click here to post a comment

Your email address will not be published. Required fields are marked *