Byzantine Generals Problem in Blockchain

The article focuses on discussing the following topics of Byzantine Generals Problem in
Blockchain:
1. What is Byzantine General’s Problem?
2. Money and Byzantine General’s Problem
3. How Bitcoin Solves the Byzantine General’s Problem?
4. Byzantine Fault Tolerance (BFT)
5. Byzantine General’s Problem in a Distributed System
6. Byzantine General’s Problem Example

What is Byzantine General’s Problem?

In 1982, The Byzantine General’s Problem was invented by Leslie Lamport, Robert
Shostak, and Marshall Pease. Byzantine Generals Problem is an impossibility result
which means that the solution to this problem has not been found yet as well as helps us
to understand the importance of blockchain. It is basically a game theory problem that
provides a description of the extent to which decentralized parties experience
difficulties in reaching consensus without any trusted central parties.
 The Byzantine army is divided into many battalions in this classic problem called
the Byzantine General’s problem, with each division led by a general.
 The generals connect via messenger in order to agree to a joint plan of action in
which all battalions coordinate and attack from all sides in order to achieve
success.
 It is probable that traitors will try to sabotage their plan by intercepting or
changing the messages.
 As a result, the purpose of this challenge is for all of the faithful commanders to
reach an agreement without the imposters tampering with their plans.

Money and Byzantine General’s Problem

Money is one such commodity whose value should be same throughout the society, that
is everyone should agree upon the value of a certain amount of money, despite all the
differences therefore in the initial times, precious metals and rare goods were chosen as
money because their value was seen equally throughout the society, but in some cases
such as precious metals the purity of the metals could not be known for sure or checking
the purity was an extremely tedious task which turned out to be very inefficient for the
daily transactions, therefore it was decided upon to replace gold with a central party
which would be highly trustable chosen by the people in the society to establish and
maintain the system of money. But with time it was later realized that those central
parties, how much-ever qualified were still not completely trustworthy as it was so simple
for them to manipulate the data.
 Centralized systems do not address the Byzantine Generals problem, which
requires that truth be verified in an explicitly transparent way, yet centralized
systems give no transparency, increasing the likelihood of data corruption.
 They forgo transparency in order to attain efficiency easily and prefer to avoid
dealing with the issue entirely.
 The fundamental issue of centralized systems, however, is that they are open to
corruption by the central authority, which implies that the data can be
manipulated by anyone who has control of the database itself because the
centralized system concentrates all power on one central decision maker.
Therefore, Bitcoin was invented to make the system of money decentralized using
blockchain to make money verifiable, counterfeit-resistant, trustless, and separate from a
central agency.

How Bitcoin Solves the Byzantine General’s Problem?

In the Byzantine Generals Problem, the untampered agreement that all the loyal generals
need to agree to is the blockchain. Blockchain is a public, distributed ledger that contains
the records of all transactions. If all users of the Bitcoin network, known as nodes, could
agree on which transactions occurred and in what order, they could verify the ownership
and create a functioning, trustless money system without the need for a centralized
authority. Due to its decentralized nature, blockchain relies heavily on a consensus
technique to validate transactions. It is a peer-to-peer network that offers its users
transparency as well as trust. Its distributed ledger is what sets it apart from other
systems. Blockchain technology can be applied to any system that requires proper
verification.
Proof Of Work: The network would have to be provable, counterfeit-resistant, and
trust-free in order to solve the Byzantine General’s Problem. Bitcoin overcame the
Byzantine General’s Problem by employing a Proof-of-Work technique to create a clear,
objective regulation for the blockchain. Proof of work (PoW) is a method of adding fresh
blocks of transactions to the blockchain of a cryptocurrency. In this scenario, the task
consists of creating a hash (a long string of characters) that matches the desired hash for
the current block.
1. Counterfeit Resistant: Proof-of-Work requires network participants to present
proof of their work in the form of a valid hash in order for their block, i.e. piece
of information, to be regarded as valid. Proof-of-Work requires miners to
expend significant amounts of energy and money in order to generate blocks,
encouraging them to broadcast accurate information and so protecting the
 network. Proof-of-Work is one of the only ways for a decentralized network to
agree on a single source of truth, which is essential for a monetary system.
There can be no disagreement or tampering with the information on the
blockchain network because the rules are objective. The ruleset defining which
transactions are valid and which are invalid, as well as the system for choosing
who can mint new bitcoin, are both objectives.
2. Provable: Once a block is uploaded to the blockchain, it is incredibly difficult
to erase, rendering Bitcoin’s history immutable. As a result, participants of the
blockchain network may always agree on the state of the blockchain and all
transactions inside it. Each node independently verifies whether blocks satisfy
the Proof-of-Work criterion and whether transactions satisfy additional
requirements.
3. Trust-free: If any network member attempts to broadcast misleading
information, all network nodes immediately detect it as objectively invalid and
ignore it. Because each node on the Bitcoin network can verify every
information on the network, there is no need to trust other network members,
making Bitcoin a trustless system.

Byzantine Fault Tolerance (BFT)

The Byzantine Fault Tolerance was developed as inspiration in order to address the
Byzantine General’s Problem. The Byzantine General’s Problem, a logical thought
experiment where multiple generals must attack a city, is where the idea for BFT
originated.
 Byzantine Fault Tolerance is one of the core characteristics of developing
trustworthy blockchain rules or features is tolerance.
 When two-thirds of the network can agree or reach a consensus and the system
still continues to operate properly, it is said to have BFT.
 Blockchain networks’ most popular consensus protocols, such as proof-of-work,
proof-of-stake, and proof-of-authority, all have some BFT characteristics.
 In order to create a decentralized network, the BFT is essential.
The consensus method determines the precise network structure. For instance, BFT has a
leader as well as peers who can and cannot validate.
In order to maintain the sequence of the Blockchain SC transactions and the consistency
of the global state through local transaction replay, consensus messages must pass
between the relevant peers.
More inventive approaches to designing BFT systems will be found and put into practice
as more individuals and companies investigate distributed and decentralized systems.
Systems that use BFT are also employed in sectors outside of blockchains, such as
nuclear power, space exploration, and aviation.
Byzantine General’s Problem in a Distributed System

In order to address this issue, honest nodes (such as computers or other physical devices)
must be able to establish an agreement in the presence of dishonest nodes.
 In the Byzantine agreement issue, an arbitrary processor initializes a single value
that must be agreed upon, and all nonfaulty processes must agree on that value.
Every processor has its own beginning value in the consensus issue, and all
nonfaulty processors must agree on a single common value.
 The Byzantine army’s position can be seen in computer networks.
 The divisions can be viewed as computer nodes in the network, and the
commanders as programs running a ledger that records transactions and events
in the order that they occur. The ledgers are the same for all systems, and if any
of them is changed, the other ledgers are updated as well if the changes are
shown to be true, so all distributed ledgers should be in agreement.
Byzantine General’s Problem Example

A basic Byzantine fault is a digital signal that is stuck at “1/2,” i.e. a voltage that is
anywhere between the voltages for a valid logical “0” and a valid logical “1.” Because
these voltages are in the region of a gate’s transfer function’s maximum gain, little
quantities of noise on the gate’s input become enormous amounts of noise on the gate’s
output. This is due to the fact that “digital circuits are simply analog circuitry driven to
extremes.”
This problem is solvable because, with a dominating input, even a Byzantine input has no
output impact.
 An excellent composite example is the well-known 3-input majority logic “voter.”
 If one of the inputs is “1/2” and the other two are both 0 or both 1, the result is 0 or
1 (due to masking within the voter).
 When one of the inputs is “1/2” and the other two are different values, the output
can be 0, “1/2,” or 1, depending on the precise gain and threshold voltages of
the voter gates and the properties of the “1/2” signal.

practical Byzantine Fault Tolerance(pBFT)

Practical Byzantine Fault Tolerance is a consensus algorithm introduced in the late 90s
by Barbara Liskov and Miguel Castro. pBFT was designed to work efficiently in
asynchronous(no upper bound on when the response to the request will be received)
systems. It is optimized for low overhead time. Its goal was to solve many problems
associated with already available Byzantine Fault Tolerance solutions. Application areas
include distributed computing and blockchain.

What is Byzantine Fault Tolerance?

Byzantine Fault Tolerance(BFT) is the feature of a distributed network to reach
consensus(agreement on the same value) even when some of the nodes in the network fail
to respond or respond with incorrect information. The objective of a BFT mechanism is
to safeguard against the system failures by employing collective decision making(both –
correct and faulty nodes) which aims to reduce to influence of the faulty nodes. BFT is
derived from Byzantine Generals’ Problem.
Byzantine Generals’ Problem
The problem was explained aptly in a paper by LESLIE LAMPORT, ROBERT
SHOSTAK, and MARSHALL PEASE at Microsoft Research in 1982:
Imagine that several divisions of the Byzantine army are camped outside an enemy city,
each division commanded by its own general. The generals can communicate with one
another only by messenger. After observing the enemy, they must decide upon a common
plan of action. However, some of the generals may be traitors, trying to prevent the loyal
generals from reaching an agreement. The generals must decide on when to attack the
city, but they need a strong majority of their army to attack at the same time. The
generals must have an algorithm to guarantee that (a) all loyal generals decide upon the
same plan of action, and (b) a small number of traitors cannot cause the loyal generals to
adopt a bad plan. The loyal generals will all do what the algorithm says they should, but
the traitors may do anything they wish. The algorithm must guarantee condition (a)
regardless of what the traitors do. The loyal generals should not only reach agreement,
but should agree upon a reasonable plan.
Byzantine fault tolerance can be achieved if the correctly working nodes in the network
reach an agreement on their values. There can be a default vote value given to missing
messages i.e., we can assume that the message from a particular node is ‘faulty’ if the
message is not received within a certain time limit. Furthermore, we can also assign a
default response if the majority of nodes respond with a correct value.
Leslie Lamport proved that if we have 3m+1 correctly working processors, a
consensus(agreement on same state) can be reached if atmost m processors are faulty
which means that strictly more than two-thirds of the total number of processors should
be honest.
Types of Byzantine Failures:
There are two categories of failures that are considered. One is fail-stop(in which the
node fails and stops operating) and other is arbitrary-node failure. Some of the arbitrary
node failures are given below :
 Failure to return a result
 Respond with an incorrect result
 Respond with a deliberately misleading result
 Respond with a different result to different parts of the system

Advantages of pbft:
  Energy efficiency : pBFT can achieve distributed consensus without carrying out
complex mathematical computations(like in PoW). Zilliqa employs pBFT in
combination with PoW-like complex computations round for every 100th block.
 Transaction finality : The transactions do not require multiple confirmations(like
in case of PoW mechanism in Bitcoin where every node individually verifies all
the transactions before adding the new block to the blockchain; confirmations
can take between 10-60 minutes depending upon how many entities confirm the
new block) after they have been finalized and agreed upon.
 Low reward variance : Every node in the network takes part in responding to the
request by the client and hence every node can be incentivized leading to low
variance in rewarding the nodes that help in decision making.
How pBFT works ?
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 increase, 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 the all the secondary(backup)
nodes.
 The nodes(primary and secondaries) 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.
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 other 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:

 Zilliqa – pBFT in combination with PoW consensus
 Hyperledger Fabric – permissioned version of pBFT
  Tendermint – pBFT + DPoS(Delegated Proof-of-Stake)

Variations of pBFT:
To enhance the quality and performance of pBFT for specific use cases and conditions,
many variations were proposed and employed. Some of them are :
 RBFT – Redundant BFT
 ABsTRACTs
 Q/U
 HQ – Hybrid Quorum Protocol for BFT
 Adapt
 Zyzzyva – Speculative Byzantine Fault Tolerance
 Aardvark

Three Phase Commit Protocol

Three-Phase Commit (3PC) Protocol is an extension of the Two-Phase Commit (2PC)
Protocol that avoids blocking problem under certain assumptions. In particular, it is
assumed that no network partition occurs, and not more than k sites fail, where we
assume ‘k’ is predetermined number. With the mentioned assumptions, protocol avoids
blocking by introducing an extra third phase where multiple sites are involved in the
decision to commit.
Instead of directly noting the commit decision in its persistent storage,
the coordinator first ensures that at least ‘k’ other sites know that it intended to commit
transaction.
In a situation where coordinator fails, remaining sites are bound to first select new
coordinator. This new coordinator checks status of the protocol from the remaining sites.
If the coordinator had decided to commit, at least one of other ‘k’ sites that it informed
will be up and will ensure that commit decision is respected. The new coordinator restarts
third phase of protocol if any of rest sites knew that old coordinator intended to commit
transaction. Otherwise, new coordinator aborts the transaction.
Drawback of the Three-Phase Commit Protocol :
While 3PC protocol has desired property of not blocking unless ‘k’ sites fail, it has
drawback that partitioning of network may appear to be same as more than ‘k’ sites
failing, which would lead to blocking. The protocol also has to be implemented carefully
to ensure that network partitioning does not result in inconsistencies, where transaction is
committed in one partition and aborted in another. Because of its overhead, 3PC protocol
is not widely used.
The difference between Three-Phase Control Protocol and Two-Phase Control Protocol
can be understood by the following figures.
Fig-1 This figure represents Two-Phase Commit Protocol
 Fig-2 This figure represents the Three-Phase Control Protocol

Dissemination Phase :
It is introduced above helps the user to deal with the cases as when either a participant
failure or both coordinator and participant node failure during the commit phase.
The recovery coordinator when it takes over after coordinator failure during Phase-2 of
the previous Two-Phase Commit Protocol the new additional phase comes handy as
follows.
Note –
On querying participants, if it learns that some nodes are in the commit phase, it then
assumes that previous coordinator before crashing has made decision to commit.
Hence it can shepherd the protocol to commit. Similarly, if a participant responds that it
doesn’t receive prepare to commit, then new coordinator can assume that previous
coordinator failed even before it started the preparation to commit phase. Hence it can
safely assume that no other participant would have committed any of changes and hence
it can now safely abort the transaction.