DEV Community

Cover image for Consensus Protocols (part 1)
Emmanuel Akanji
Emmanuel Akanji

Posted on

Consensus Protocols (part 1)

A dive into the underlying structure of the blockchain Ecosystem

Overview

In this series, I will be taking a look at the several consensus protocols and trying to recreate them all in Python and compare their advantages and disadvantages.

We've all heard about the blockchain and how it's the web's future, and there are a lot of individuals who are looking into the possibilities, but still, the majority of the blockchain's applications that we see in the mainstream media are the introduction of cryptocurrencies and decentralized finance (DE-FI). We'll go under the surface in this article to see how blockchain networks come to an agreement on fresh block generation.

According to Euromoney, a blockchain is a digital ledger of transactions that is duplicated and distributed across the entire network of computer systems on the blockchain. Each block in the chain contains several transactions, and every time a new transaction occurs on the blockchain, a record of that transaction is added to every participant’s ledger. The decentralized database managed by multiple participants is known as Distributed Ledger Technology (DLT).

A blockchain, in my opinion, is similar to a group of people having information about each other in such a way that it is difficult for anyone outside the group to change information about a member, and before a new member of the group is added, all members of the group must agree. This makes it nearly impossible to cheat the system or the group.

So the blockchain works by adding blocks of data, and an agreement must be reached to ensure that every block added to the chain is true and based on the agreement of all or a majority of the nodes in the system.

The agreement that must be reached by the group is called a "consensus" as it is used for verifying information authenticity.

What are consensus protocols?

Consensus-Protocols-Pros-and-Cons.jpg
Image source

Consensus protocols serve as the underlying structure of the blockchain as it’s a key feature of the decentralized nature of the blockchain. it helps all the nodes in the network verify the authenticity of transactions. These protocols are set to help to provide a method of confirming what data should be added to the blockchain. These protocols exist to create a balance as no central authority dictates what is right or wrong, therefore all nodes of the blockchain must follow a set of predefined rules or protocols on how data is added to the blockchain.

We have several blockchain networks emerging today, each with their own consensus protocol/mechanism for reaching an agreement over a transaction or the creation of a new block.

**Note:* Nodes are members of the network or certain users within the network responsible for verifying transactions. *

Purpose of Consensus protocols

As we now know, the function of consensus protocols is to help nodes (participants) on a blockchain network agree on choosing what data should be added and what data shouldn’t be added to the network. This provides a level of security to the network.

Types of Consensus

Generally, for a consensus protocol to be implemented, it must overcome something called "The Byzantine Fault." Today, with several blockchain networks coming up, each has their own methods of overcoming this problem.

The Byzantine Fault

The notion of the Byzantine fault can be traced back to the Byzantine General’s problem, which is a condition where nodes in a distributed system fail and there are imperfections in whether a component has failed, and this can lead to the entire system being taken down.

In a Byzantine fault, a component such as a server can inconsistently appear both failed and functioning to failure detection systems, presenting different symptoms to different observers. It is difficult for the other components to declare it failed and shut it out of the network because they need to first reach an agreement regarding which component has failed in the first place.

The Byzantine Fault Tolerance (BFT)

This is a condition particular to distributed systems where a distributed system can remain fault-tolerant in the presence of malicious actors and imperfections on the network. This problem was developed to describe a situation in which the system’s actors or distributed systems must agree on a concerted strategy, to avoid a catastrophic failure of the system, assuming that some of the actors or nodes in the system are unreliable.

The goal of a BFT mechanism is to guard against system failures by employing collective decision making(both – correct and faulty nodes) which aims to reduce to influence of the faulty nodes

How Does BFT Apply to Blockchain?

Its relation to blockchain networks is that the network must be able to reach a certain level of agreement because some of the nodes participating in the agreement can choose to be deceitful.

As the Byzantine Fault Tolerance helps protect the network from dangerous system failures and ensures the ideal functioning of the network. It allows for both the honest and malicious nodes to carry out their intended tasks without affecting the overall network’s performance and only allows the agreement made by a majority of the honest nodes to be passed.

The Practical Byzantine Fault Tolerance(P-BFT) consensus Algorithm

The Practical Byzantine Fault Tolerance consensus algorithm was introduced in the late 90s by Barbara Liskov and Miguel Castro.

Their research work provided a high-performance Byzantine state machine replication, processing thousands of requests per second with a sub-millisecond increase in latency.

Generally taking an overview, the P-BFT is a consensus algorithm that can withstand byzantine faults, a process where a group of distributed systems has to reach an agreement because some of the nodes in the system can be faulty or compromised.

In a pBFT system, the nodes are sequentially ordered with one node being the leader and others referred to as backup nodes. It applies the majority rule in reaching an agreement based on the information from all the non-compromised nodes while communicating with each other.

For a system implementing the pBFT consensus algorithm to function effectively, the number of compromised nodes must not equal or exceed one-third of all nodes in the system in a given vulnerability.

given by the formula [(n-1)/3]
.,

where n = the total number of nodes in the system.

The more nodes there are in a pBFT system, the more secure it becomes.

How a pBFT algorithm reaches a consensus?

The pBFT consensus rounds are called views and are broken into 4 phases:

  1. A client sends a request to the leader node to invoke a service operation.
  2. The leading node broadcasts the request to the backup nodes.
  3. The nodes execute the request, then send a reply to the client
  4. The client awaits \( f + 1 \) replies from different nodes with the same result, where f, equals the maximum number of potentially faulty nodes.

As the pBFT consensus requires a leader which stands in place between the client and the backup nodes. During every view (consensus round) the leading node is changed and can be replaced with a protocol called a view change if a certain amount of time has passed without the leading node broadcasting the request. If a leader is determined to be faulty or compromised, the majority of honest nodes can replace the leader node with the next node in line.

Projects Implementing the pBFT consensus Algorithm

Many projects are currently implementing the pBFT consensus algorithm.

  1. Hyperledger Fabric: This is an open-source collaborative environment by the Linux Foundation for blockchain hosted by it. It is a permissioned version of the pBFT for the platform. Since permissioned chains use small consensus groups and don’t need the same decentralization as public blockchains, pBFT is effective for providing high transaction throughput.

  2. Ziliqa: ziliqa uses an optimized version of classical pBFT to achieve consensus about data on the blockchain. Ziliqa also implements the proof-of-work consensus around every 100 blocks to perform network sharding

    Network sharding: network sharding involves splitting miners into smaller groups known as shards. Where each shard is capable of processing transactions in parallel, yielding a high transaction throughput for the network.

    The network uses multi-signatures to reduce the communication overhead of classical pBFT, compared to MACs (Message Authentication Codes), being implemented in the system.

Benefits of the pBFT

  • Transaction finality: The transactions performed on a network implementing the pBFT consensus do not require multiple confirmations after they have been finalized.
💡 **Note:*** unlike Bitcoin where every node individually confirms all the transactions before adding the new block to the blockchain; at times these confirmations take from as low as 10 minutes to an hour, the pBFT does not require multiple transaction confirmations.*
  • Energy efficiency: pBFT achieves distributed consensus without having to carry out complex mathematical computations.
  • Low reward variance: Every node in the network has a part to play, as it requires a collective decision made by a majority of honest nodes in responding to the request by the client, which allows for every node to be incentivized leading to low variance in rewarding the nodes that help in decision making.

Disadvantages of the pBFT consensus Algorithm

The pBFT works efficiently well only when the number of nodes in the network is small.

  • Scaling: when it comes to the issue of scaling the pBFT consensus falls short as it becomes inefficient for large networks. This is because each node is required to communicate with every other node to keep the network secure, and this task of communicating with every node increases communication cost and overall decreases transaction throughput as the amount of nodes scales is increased.
  • Sybil attacks: Sybil attacks involve when a single party creates and manipulates a large number of nodes in the network and compromises security. This threat is reduced with larger network sizes but considering the scalability issue of pBFT, this makes it susceptible to Sybil attacks. For most networks that implement pBFT, they are used in combination with another consensus mechanism.

Applications of pBFT for Social Good.

The mainstream application we see of blockchains and consensus mechanisms are cryptocurrencies and De-FI (Decentralized Finance). And while these applications are great, I want to explore other applications of the blockchain and see how its impact can help the immediate society.

  1. Health Care: Nowadays, it’s quite difficult to receive treatment from a particular hospital that isn’t the one you’re registered with especially when you’re on a trip. The pBFT mechanism can be implemented for hospitals whereby hospitals stand in as the node and patients’ information is shared amongst the hospitals in the case where the patients need access to them and aren’t within their registered hospital. This would make treating patients easier as all it takes is accessing the information through a shared network for patients’ data and that node is verified as the honest by all the hospital nodes and the patient's records are easily fetched.
  2. NGOs (Non Governmental organizations): When it comes to the allocation of the resources raised by NGOs and ensuring that they are appropriately used is quite difficult. The pBFT consensus can be applied in helping those who donate to these organizations monitor and decide on how the funds are given are managed and utilized, eventually making the process transparent.

Conclusion

This article is just a first-part series on looking beneath the blockchain and understanding how different blockchains reach consensus using various consensus protocols.

We would seek to understand how these protocols work and I would replicate a scaled-down version of it with python and then we would see other applications of these consensus mechanisms and blockchain networks beyond the hype of cryptocurrencies, De-Fi, and NFTs.

Oldest comments (0)