# The practical Byzantine Fault Tolerance (pBFT)

Practical Byzantine Fault Tolerance (pBFT) is a type of consequence algorithm. It was introduced by Barbara Liskov and Miguel Castro in the 90s. It was designed to perform the work operation efficiently. It is optimized to work on low time. Its main goal is to solve any problem in a fraction of the time. The application area or practical Byzantine Fault Tolerance (pBFT) includes Blockchain and distributed computing.

## What is Byzantine Fault Tolerance?

Byzantine Fault Tolerance is a type of feature for the distributed networking system by which we can recover the networks when some nodes are not able to respond the incorrect information. The main objective of Byzantine Fault Tolerance is to provide a safeguard against the failure of the system. It has another aim to reduce the faulty node. This problem was first derived from the Byzantine General problem.

## Byzantine General Problem

The Byzantine Fault Tolerance can be controlled if the correctly working nodes reach the agreement of network values. There should be a network value that is given to every node of the network. That means if we assume, there is a faulty node and the network value may not reach the agreement. But we can overcome this problem with the help of the Byzantine General problem. Also, if there is a majority of certain values given by every node, then we assign that certain value to the entire nodes of the network. Leslie Lamport proves that if we have a 3m+1 number of processors working perfectly, then m is the number of processes that are faulty.

## Types of Byzantine Failure

There are two types of category of Byzantine Failure. These two failures are arbitrary node failure and fail-stop failure. Some arbitrary node failures are as follows.

1. Failure to return a result.
2. Respond with an incorrect result.
3. Respond with a deliberately misleading result.
4. Respond with a different result to different parts of the system.

## Advantages of practical Byzantine Fault Tolerance (pBFT)

1. Energy Efficiency

Practical Byzantine Fault Tolerance (pBFT) can achieve the consequences without calculating the complex mathematical operation. The employee of Zillaqa performs the complex mathematical operation with the combination of every 100th block of the practical Byzantine Fault Tolerance (pBFT).

2. Transaction finality

In practical Byzantine Fault Tolerance (pBFT), there is no need for multiple confirmations for the distribution network. In the case of the mechanism of Bitcoin, every node of the Bitcoin is individually connected with multiple nodes, and every node verifies every incoming and outgoing transaction. The confirmation of every transaction takes up to 10-60 minutes to complete the whole operation. The completion of the whole operation depends on the number of nodes connected in it.

3. Low reward variance

Every node has the responsibility to respond to the request from the client, resolve the query, and respond back to the client. Hence every node has a feature to make the decision.

## How does pBFT work?

pBFT tries to provide a practical Byzantine state machine replication that can work even when malicious nodes are operating in the system.

Nodes in a pBFT-enabled distributed system are sequentially ordered, with one node being the primary (or the leader node) and others referred to as secondary (or the backup nodes). Note here that any eligible node in the system can become the primary by transitioning from secondary to primary (typically, in the case of a primary node failure). The goal is that all honest nodes help in reaching a consensus regarding the state of the system using the majority rule.

A practical Byzantine Fault Tolerant system can function on the condition that the maximum number of malicious nodes must not be greater than or equal to one third of all the nodes in the system. As the number of nodes increases, the system becomes more secure.

pBFT consensus rounds are broken into 4 phases(refer with the image below):

• The client sends a request to the primary (leader) node.
• The primary (leader) node broadcasts the request to all the secondary (backup) nodes.
• The nodes (primary and secondary) perform the service requested and then send back a reply to the client.
• The request is served successfully when the client receives 'm+1' replies from different nodes in the network with the same result, where m is the maximum number of faulty nodes allowed.

The primary (leader) node is changed during every view (pBFT consensus rounds). It can be substituted by a view change protocol if a predefined quantity of time has passed without the top node broadcasting a request to the backups (secondary). If needed, most of the honest nodes can vote on the legitimacy of the current leading node and replace it with the next leading node.

## Limitations of pBFT

The pBFT consensus model works efficiently only when the number of nodes in the distributed network is small due to the high communication overhead that increases exponentially with every extra node in the network.

• Sybil attacks: The pBFT mechanisms are susceptible to Sybil attacks, where one entity (party) controls many identities. As the number of nodes in the network increase, Sybil attacks become increasingly difficult to carry out. But as pBFT mechanisms have scalability issues, too, the pBFT mechanism is used in combination with another mechanism (s).
• Scaling: pBFT does not scale well because of its communication (with all the other nodes at every step) overhead. As the number of nodes in the network increase (increases as O(n^k), where n is the messages and k is the number of nodes), so does the time taken to respond to the request.

## Platforms using pBFT variants:

There are some platforms that are used for pBFT variant. These are as follows:

1. Zilliqa: This is the combination of PoW conceous with pBFT.
2. Hyperledger Fabric: This is the permission version of pBFT.
3. Tendermint: This is the combination of DPoS and pBFT.