Lecture 1.2.3 - Byzantine Fault-Tolerant Distributed Computing
Lecture 1.2.3 - Byzantine Fault-Tolerant Distributed Computing
ENGINEERING
COMPUTER SCIENCE ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Block chain Technology
Subject Code: 20_CST-412
• The different Byzantine generals command their respective units at different positions
outside the city they are about to attack.
• The generals can communicate with each other through messengers, sending one
message at a time.
• The Byzantine generals must have coordination and agreement on a particular plan of
action for successfully attacking or retreating.
• If all the general’s attack at the same time or all of them retreat at the same time, there
is no problem. However, if one general retreats while others attack or attacks while the
others retreat, the general would end up losing. Therefore, the outcome will be bad for
all of the generals and their units.
• Another important point in the Byzantine General’s Problem is the fact that some of the
generals are not loyal. These generals could try sending the wrong or manipulated
information to other generals for confusing them.
Introduction
• All the loyal generals would act and agree on the same plan of action.
• The loyal generals of the Byzantine army would not follow a bad plan
under the influence of traitor generals.
• The loyal generals would follow all the rules specified in the algorithm
• All the loyal generals of the Byzantine army must reach a consensus
irrespective of the actions of traitors.
• The goal of BFT is to protect against catastrophic system failures by
reducing the influence of these malicious nodes.
Working of pBFT
• Practical Byzantine Fault tolerance(pBFT) is an algorithm that optimizes aspects of
Byzantine fault tolerance and has been implemented in modern distributed computer
systems.
• It also applied to airplane engine system, nuclear power plants, and almost any systems with
actions that depend on many sensors.
• The most prominent assumption regarding practical BFT refers to the fact that the number
of malicious nodes in the network could not be equal to or more than one-third of the
total nodes in the system for a specific window of vulnerability.
• In order to understand the practical variant of the Byzantine Fault tolerance algorithm, you
have to understand stages in its consensus.
• 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).
• The goal is that all honest nodes help in reaching a consensus regarding the state of the
system using the majority rule.
• 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 the all the
secondary(backup) nodes.
• The nodes(primary and secondary's) 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) and can be substituted by a view change
protocol if a predefined quantity of time has passed without the
leading node broadcasting a request to the backups(secondary).
• If needed, a majority of the honest nodes can vote on the legitimacy
of the current leading node and replace it with the next leading node
in line.
Benefits of Practical BFT
• 1. Low Energy Consumption
• The important advantage with this Byzantine Fault Tolerance
algorithm in comparison to PoW consensus is the reduced energy
usage.
• Gradually, miners in the Bitcoin network increase electrical
consumption, which can outperform the annual electricity
consumption of small countries.
Limitations of pBFT:
• Communication overhead: 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.
• 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:
• Zilliqa – pBFT in combination with PoW consensus
• Hyperledger Fabric – permissioned version of pBFT
• Tendermint – pBFT + DPoS(Delegated Proof-of-Stake)
SHA(Data+Nonce(?)) = Hash < Target Hash Value
Target Hash should start with some leading zeros