Blockchain technology represents a sum of many parts, and its consensus algorithm is certainly one of the most important pieces of this puzzle. Decentralized blockchains are envisioned as peer-to-peer systems that don’t have centralized authority points; consensus algorithms play a massive role in enabling this decentralized infrastructure to exist and work.
Typical centralized systems rely on trust where certain entities act as network “leaders”, controlling the network and making important decisions about it.
Everyone else trusts these leaders that they’ll stay honest and behave in a manner beneficial to the entire network. This can sometimes backfire as the network leaders can become corrupt and start acting in malicious ways. When this happens, the entire network is put at risk.
These new blockchain systems had to have some sort of a built-in decision-making feature that would allow the whole network to self-determine its future.
The idea of a consensus was implemented, allowing every network member to take a part in blockchain development and help make decisions on a blockchain’s future that would be in the best interest of the whole.
By basing decentralized blockchain networks on a consensus (which is achieved between a network of widely distributed nodes that manage the blockchain), original programmers of cryptocurrencies like Bitcoin introduced a dynamic, non-centrally-controlled way of reaching agreement in a group.
This gave decentralized blockchains the ability to stay immutable, censorship-free, central-point-of-failure-free and infinitely more secure than similar centralized data management systems.
Resourceful minds realized the potential of a trustless, leaderless system that is able to self-govern and self-direct while maintaining the integrity of its data.
Such a system lends itself perfectly to the world of finance and saw its first successful, widespread implementation with Satoshi Nakamoto’s Bitcoin cryptocurrency. But before taking a look at Bitcoin’s PoW and some of the more modern consensus algorithms, we need to understand why exactly was it so difficult to create a consensus algorithm capable of governing a decentralized blockchain in the first place.
What you'll learn 👉
The Byzantine Fault Tolerance problem
A problem with governing decentralized data aggregating blockchains via consensus comes when the nodes that are a part of the consensus become faulty or malicious.
A node can start disobeying the network rules and start presenting fake data to other nodes. The question that arises here is the following: how will the honest nodes acknowledge that this data is fake and come to a consensus about not adding it to the blockchain?
This problem is known in the literature as a Byzantine Fault Tolerance Problem. BFT problem is seen as a generalized version of the Two Generals Problem that adds a twist of having more than two generals in the mix to the story. The Two Generals Problem presents us with a hypothetical scenario where two Byzantine generals, one being the superior to the other, are sitting on the opposite walls of an enemy city they are trying to conquer.
Each general’s army on its own is not enough to take over the city successfully, which is why they need to coordinate a joint attack that will happen at an exact time.
The issue becomes apparent when the attack coordination starts; the superior general has to send a messenger through the sieged city to inform the second general that the attack will happen at a determined time. The messenger can deliver the time of attack successfully to the other general but he can also easily get caught by the enemy.
The enemy now knows the exact time of the attack and can even send a fake message to the second general, duping him into attacking earlier/later or into staying put. The second general now has to send a messenger back to the first one, confirming that he received the instructions. This messenger can also be captured and his message altered, leading to a situation where it’s impossible for the generals to reach an agreement.
BFT problem, as explained before, adds more than two generals that need to agree on a time to attack an enemy city. Interestingly enough in this case there is a potential solution, as the goal isn’t to have all the generals attack at the same time but rather to have a majority of them do so. If more than two thirds of generals listen to the supreme commander and attack at the same time, the city will be taken and
Earning money passively is very possible in crypto thanks to staking. What are the best staking coins? Click here to find out.
When transferred to blockchain, each node is basically one of the generals from the story. One node will provide data that the others will need to come to a consensus regarding whether or not this data should be added to the blockchain.
If more than two thirds of network nodes are capable of reaching a consensus that stays true to the pre-determined rules of the decentralized blockchain, the consensus algorithm is considered as Byzantine Fault-tolerant.
Bitcoin was the first one to present a BF-tolerant consensus with its Proof-of-Work algorithm which allowed Bitcoin’s blockchain to operate in a decentralized manner without a single authority controlling it.
Even though this algorithm is still used to create a consensus between Bitcoin nodes that manage Bitcoin’s blockchain, it does come with some unsolved issues regarding efficiency, scalability, costs and commercial viability. Attempts were made in the past to create improved consensus algorithms that would eliminate the issues of PoW. Today we’ll take a closer look at how a consensus algorithm called PBFT (Practical Byzantine Fault Tolerant) attempts to one-up what PoW originally brought to the table.
Practical Byzantine Fault Tolerant Mechanism
PBFT model attempts to provide a Byzantine Fault tolerant algorithm that would be resistant to malicious attacks and software errors caused by faulty and rogue nodes.
Developed back in the 90’s by Castro and Liskov, the algorithm was designed to work in asynchronous (no upper bound on when the response to the request will be received) environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms.
PBTF is a robust, high-performance algorithm that comes with only a 3% increase in latency over a standard unreplicated BFT models.
Unlike PoW or PoS (Proof of Stake) mechanisms, PBFT doesn’t require any hashing power to add new blocks to the underlying blockchain. This makes the algorithm much more energy efficient and eventually allows it to avoid issues with centralization that PoW (mining pools) and PoS (large stake holders cutting deals behind the scenes) suffer from.
Nodes in a pBFT enabled distributed system are sequentially ordered with one node being the primary (so-called leader node) and others considered as secondary (the backup nodes). Any node in the system can assume the role of primary if an old primary node fails or starts acting maliciously. The primary node is changed during every consensus round nonetheless.
Each node will send its own opinion on a certain issue to the rest of the network; the state that is supported by more than two thirds of the nodes is seen as the correct one.
This entire system is based on the assumption that, at any point in time, the total share of faulty or malicious nodes on the network isn’t bigger than 1/3 of the total number of network nodes. The more nodes a PBFT system has, the safer it becomes.
In more detail, all the nodes within a consensus group are ordered in a sequence, with one primary node (aka a leader) and the others are referred to as backup nodes. Every round of PBFT has three phases as discussed below:
- Pre-prepare phase: In this phase, the leader announces the next piece of record that the group should agree on. This is done by sending a “pre-prepare” message.
- Prepare phase: Upon receiving the pre-prepare message, every node validates the correctness and validity of the record and multicasts a “prepare” message to all the other nodes.
- Commit phase: Upon receiving the prepare messages from the 2/3 majority, each node multicasts a “commit” message to the group. Finally, each node waits for commit messages from the 2/3 majority to ensure that a sufficient number of nodes have agreed on the record proposed by the leader.
The algorithm is quite message-heavy, as nodes (also known as replicas) need to inform every other replica on the network of their decision.
One PBFT algorithm needs to have a minimum of 3f + 1 replicas (where f is the maximum number of faulty replicas) to ensure that its Byzantine Fault tolerance is unharmed. For example, a system with 7 replicas (presumption being that 2 of those are faulty) would need to exchange 71 messages to achieve consensus, while increasing the number of faulty replicas by one would increase the number of required replicas to 10 and the number of required messages to 142.
What are the best crypto portfolio trackers?
This shows us the biggest problem with PBFT, which is its inability to scale as well as other consensus algorithms. The model only works well in its classical form with small consensus group sizes due to the cumbersome amount of communication that is required to reach the consensus.
This scalability can be improved by reducing the required cryptographic proofs for each message, but the improvement is still not enough to make this algorithm commercially viable. As such, PBFT is mostly suitable for consortiums of enterprise organizations, where each organization would represent a node on the network. Each of these major nodes would then have clusters of support instances and load balancers to increase the scalability of the network.
PBFT mechanisms can also be susceptible to Sybil attacks in situations where the network has fewer nodes. This could be solved by increasing the number of nodes but that will ultimately cause further scalability problems.
Cryptocurrencies that use pBFT
These issues are often solved by combining the PBFT with other algorithms. Some of the most popular blockchains that utilize the PBFT algorithm are:
- Zilliqa
Zilliqa utilizes a combination of PBFT and a classical PoW, where PoW is used to shard the network every 100 blocks into smaller groups of nodes called shards and then consensus is reached within each of the shards using PBFT. Zilliqa has been posting some impressive throughputs (in thousands of transactions per second), confirming that the combination of sharding and PBFT has some serious potential.
Here is our price prediction for ZIL in 2019
- Hyperledger
Validators in the Hyperledger protocol run a permissioned version of the PBFT algorithm. As such, this algorithm fits nicely in the low number of nodes requirement, allowing for high transaction throughputs and good scalability.
- Tendermint
Combines the more modern PoS with the benefits of PBFT. Tendermint algorithm is also seen as a “blockchain consensus engine”; it is called Tendermint Core, ensures that the same transactions are recorded on every machine in the same order.
Developers can use Tendermint for BFT state machine replication of applications written in whatever programming language and development environment is right for them thanks to an added Application Blockchain Interface.
Final thoughts
Byzantine-fault-tolerant algorithms will remain important as they ensure that systems suffering from software errors and faulty nodes will keep operating. BFT algorithms previously existed in industries like aeronautics and others that utilize systems which depend on distributed, independent sensors or nodes; their future seems to be closely tied to the blockchain industry as well.
With PBFT specifically, features like enabling transaction finality without the need for confirmations, reduction of energy usage/waste, and an incentive layer that supports equality are what motivated several projects to start using it. It remains to be seen if any of them will manage to overcome the drawbacks of PBFT and usher in a new era of commercially viable, Byzantine Fault tolerant algorithms.
