DC Theory Assignment

Byzantine Problem and its

Solutions in Distributed
Computing
Preetika Sastry
PB 14
Batch: B1
Table of contents
Introduction

What Is The Byzantine Generals Problem?

What are Byzantine Failures?

Byzantine Fault Tolerance

Achieving Byzantine Fault Tolerance

01 Introduction
Introduction
The Byzantine Problem is an analogy in
computer science used to describe the
challenge of establishing and maintaining
security on a distributed network. To solve this
problem, honest nodes (e.g. computers or other
physical devices) need to be able to reach
consensus despite the presence of dishonest
nodes. This means a majority of nodes must
establish a set of rules and come to agreement
on how to enforce those rules on the network.
02 What is Byzantine
Generals Problem?
What is Byzantine Generals Problem?
The Byzantine Generals Problem is a common challenge that
decentralized computer systems must overcome.

The analogy used for the Byzantine Generals Problem basically goes
like this: Several divisions of the Byzantine army are stationed just
outside of an enemy city and are preparing for battle. Various
generals can only communicate with each other via a messenger.
They must agree upon a common course of action.

However, we must assume that some generals are traitors who wish
to prevent loyal generals from agreeing upon a common course of
action. An algorithm is needed to ensure that a small group of
traitors can’t disrupt communications. To solve the Byzantine
Generals problem, loyal generals need a secure way to come to
agreement on a plan (known as consensus) and carry out their
chosen plan (known as coordination). Whenever a distributed group
of nodes (e.g. computers or other physical devices) need to achieve
reliable communications, the network needs to solve the Byzantine
Generals Problem.
03 What are Byzantine
Failures?
What are Byzantine Failures?
There are several possible reasons why a distributed computer
system might fall. These are commonly known as Byzantine
failures (also known as Byzantine faults). Looking at the
analogy above, Byzantine failures are essentially the traitors
who attempt to disrupt communications between the loyal
generals.

Applying this concept to real-world computer systems, this

could be a software bug, hardware malfunction, and/or a
malicious attack. In other words, Byzantine failures don’t
necessarily have to be an orchestrated attack from a bad actor.
They can simply be issues that prevent nodes from coming to
agreement on decisions for a distributed network.
04 Byzantine Fault
Tolerance
Byzantine Fault Tolerance
Byzantine failures are practically inevitable within any
distributed computer system. Let’s say there is a power outage
and nodes suddenly go offline. Is the network still able to
function as normal and continue supporting reliable
communications? Or does the entire system suddenly stop
working or become vulnerable to attacks?

In a moderately secure network, something as simple as a few

nodes going offline doesn’t have any noticeable impact on the
network. The ability to defend against these scenarios is
known as Byzantine Fault Tolerance. Networks that are able to
handle more Byzantine failures are considered to have a higher
tolerance, which means they are more secure than ones that
can’t handle Byzantine failures.
05 Achieving Byzantine
Fault Tolerance
Achieving Byzantine Fault Tolerance
Early Solutions

Research on Byzantine Fault Tolerance began in the 1950s and mainly revolved around the aviation industry.
Several Byzantine Fault Tolerance solutions for aircraft and spacecraft were developed in the late 1970s and
early 1980s.

In 1978, researchers at Draper Laboratory published a technical report on the Fault-Tolerant Multiprocessor
(FTMP) — a multiprocessor computer that eliminates single-fault vulnerability for aircraft modules. This
research continued throughout the 1980s.

In the late 1970s, Honeywell Labs developed the Microprocessor Flight Control System (MMFCS), which
enabled precise detection of Byzantine failures and the ability to differentiate between other types of failures.
In 1981, SRI International, the same organization that coined the term “Byzantine Generals Problem”,
published a technical paper for an aircraft control computer called Software Implemented Fault Tolerance
(SIFT).
Practical Byzantine Fault Tolerance (pBFT)

In 1999, Miguel Castro and Barbara Liskov published a research paper titled, “Practical Byzantine Fault
Tolerance” that introduced a new algorithm for achieving Byzantine Fault Tolerance. The word “practical” is
used because Castro and Liskov found that previously-developed algorithms either assumed the network was
synchronous or didn’t provide a practical means of reaching consensus for asynchronous systems.

This algorithm, typically abbreviated as pBFT, allowed asynchronous networks to process thousands of
requests per second with only a sub-millisecond increase in latency. Although it became a major
breakthrough for distributed systems, pBFT faced two main issues that limited adoption. First, pBFT becomes
more costly to use as the number of nodes increases. Second, pBFT is susceptible to Sybil attacks— a
common security threat in which an attacker uses multiple pseudonymous identities to control a majority of
nodes on a peer-to-peer network. More protocols were later introduced to solve some of pBFT’s limitations.
For example, Q/U, HQ, Zyzzyva, and ABsTRACTs focused on solving performance and cost issues. Aardvark
and RBFT focused on solving robustness issues.
Byzantine Fault Tolerance Solutions For Blockchain Networks

There are currently three main types of consensus protocols used by blockchain networks. Quite a few
variations exist in the numerous implementations of these protocols; however, most networks share the same
general mechanics to achieve Byzantine Fault Tolerance.

Proof of Work (PoW)

In this system, the Byzantine Generals Problem is solved by rewarding honest users (known as miners) who
solve difficult math problems with powerful computers. Once the correct solution is verified, the miner
receives a reward in the blockchain network’s native coin. Miners on the Bitcoin network, for example, receive
6.25 BTC per block (as of the time of this writing). The block is then mined, and the transaction is completed.

It would take the millions of dollars to even attempt to attack the network and create a Byzantine failure. To
successfully carry out a double spending attack, dishonest miners would need to gain control of 51% of the
network’s computing power, which is known as a 51% attack. Although this is practically impossible on the
Bitcoin network, it’s actually a major problem for smaller networks with fewer miners since the computational
resources and costs are much lower.
Proof of Stake (PoS)

First implemented in 2012, Proof of Stake (PoS) is another blockchain consensus protocol that aims to solve
the Byzantine Generals Problem. Unlike PoW-based networks, PoS-based networks don’t rely upon
cryptocurrency mining. Instead, a process known as staking is used. In this system, users (known as
validators) stake funds. Validators that stake more of a blockchain’s coins are able to validate more blocks
and earn more rewards. Additionally, users who try to validate invalid transactions may lose their staked
funds.

Users can stake coins with basic home computers rather than needing to have specialized computers
required for mining in a PoW-based network. A few PoS-based networks have implemented solutions that
prevent double spending attacks and other possible security issues that might occur as a result of Byzantine
failures. For example, Ethereum 2.0 (Serenity) will feature a PoS algorithm called Casper, which requires a
two-thirds majority for nodes to reach consensus before blocks can be created.

Delegated Proof of Stake (DPoS)

First implemented in 2014, Delegated Proof of Stake (DPoS) is a blockchain consensus protocol that works
similarly to Proof of Stake. Both require users to stake funds. However, with DPoS-based networks, only a few
users (known as delegates) are able to validate transactions and create blocks. Generally, all users can stake
a blockchain’s coins as a means of casting a vote in favor of a delegate candidate. Elected nodes generally
distribute block rewards with their voters proportional to the amount of funds staked in delegate elections.
Thank You