PBFT consensus blockchain
A consensus technique called Practical Byzantine Fault Tolerance (PBFT) was created expressly to ensure that nodes in a distributed system can agree even in the event of a Byzantine fault, which is a situation in which some nodes act deliberately or malfunction. Miguel Castro and Barbara Liskov created it in 1999 to offer a workable method for consensus in asynchronous networks with Byzantine faults. Byzantine fault tolerance was often seen as impractical prior to PBFT.
Also Read About Byzantine Failure: Threat to Consensus And System Integrity
The Byzantine Generals’ Problem and Byzantine Fault Tolerance (BFT)
Understanding the Byzantine Generals’ Problem (BGP) is a prerequisite for understanding PBFT. Robert Shostak formalised this logical decision challenge as the “interactive consistency” problem in 1982.
The issue depicts a military situation in which an enemy city is surrounded by multiple generals and their forces. To succeed, all loyal generals must operate in unison and agree on a common plan, and they must collectively decide whether to attack or retreat. The generals’ physical separation and reliance on messengers for communication creates complexity. Importantly, some generals may be traitors who try to stop the loyal generals from coming to a consensus or from launching a catastrophic, ill-planned attack by sending them twisted or contradictory messages. Additionally, the messages may be changed or the messengers themselves may be apprehended.
The problem of a network of autonomous, distrusting nodes needing to come to a consensus on the state of a distributed ledger, such the contents of the next block, is aptly captured by the BGP metaphor in the context of blockchain and distributed systems. Node self-interest is assumed, and there is no single authority, unlike centralised systems.
Byzantine Fault Tolerance (BFT) was established to solve the Byzantine Generals’ Problem. It ensures that a system can reach a consensus even if some nodes don’t respond or provide inconsistent, malicious, or erroneous information. It aims to reduce these rogue nodes’ network impact.
However, early BFT solutions, which usually relied on direct communications between each pair of nodes, were frequently ineffective and unscalable. Large networks like Bitcoin could not use it since the quantity of messages grew with the square of the number of nodes (O(n^2)).
How PBFT Works
The original BFT method is optimised by PBFT to make it workable for bigger networks. By guaranteeing a feasible Byzantine state machine replication, it tackles the issue of malevolent or Byzantine nodes.
Important Features and Organisation
- Since PBFT uses an asynchronous methodology, message delays have no upper constraint.
- In a PBFT system, nodes are arranged in a sequential fashion.
- The primary node is the leader node in the network, whereas the replicas are backup nodes. In addition to fulfilling client requests, the primary node facilitates communication between backup nodes and clients.
- For a PBFT network to be secure and correct, it needs at least 3f + 1 copies (nodes) to withstand f Byzantine faults in an asynchronous system. For instance, at least 3(1)+1 = 4 nodes are required if one node is defective (f=1). This guarantees that there are always enough good nodes to outnumber the bad ones and use majority rule to come to an agreement.
- To confirm honest nodes and guarantee message integrity, all nodes can communicate with one another.
Also Read About What Is FBFT? Knowing Federated Byzantine Fault Tolerance
PBFT consensus algorithm
Three major steps (or four, if the client’s original request and final confirmation are included) make up the PBFT consensus algorithm:
Client Request
By submitting a request to the leader (primary) node, a client starts the procedure.
Prepare Phase
- The client sends the request to the principal node.
- It gives the request a distinct sequence number.
- A “pre-prepare” message containing the request and its digest (a cryptographic hash) is subsequently broadcast to all backup nodes by the primary. The requests are arranged in this phase.
Pre-prepare Phase
- Backup nodes check a “pre-prepare” message’s content and authenticity after receiving it.
- They multicast a “prepare” message to every other replica, including the primary, if they are accepted.
- A node is deemed “prepared” if it has received the leader’s “pre-prepare” message and 2f + 1 (including itself) “prepare” messages from other nodes that match. During this stage, the sequence of requests within a certain “view” is agreed upon by honest replicas.
Commitment Stage
- After receiving 2f + 1 matching prepare messages, a node is said to be “prepared” when it multicasts a “commit” message to every other replica.
- A node carries out the client’s request if it receives f + 1 (including its own) “commit” messages that correspond to the pre-prepare. This stage guarantees that truthful copies concur on the overall sequence of requests across various “views,” which results in the ultimate decision.
Client Reply
Replicas send a direct response to the client after completing the request. Before approving it as legitimate, the client waits for f + 1 responses from various nodes that produce the same outcome.
Also Read About DBFT Delegated Byzantine Fault Tolerance Def And Advantages
To preserve message integrity, stop spoofing, and verify the legitimacy of senders, digital signatures and message authentication codes (MACs) are employed. PBFT mostly uses quicker MACs during regular operation, saving digital signatures for less frequent occurrences like view changes, even though they offer unforgeable proof to third parties.