Elements of Distributed

Computing
Dr.M.Selvi
Elements of Distributed Computing
• Distributed Database,
• Two General Problem,
• Byzantine General problem and Fault
Tolerance,
• Hadoop Distributed File System,
• Distributed Hash Table
 Distributed Database
• Understanding distributed systems is essential to our
understanding of blockchain, as blockchain is a distributed
system at its core.
• It is a distributed ledger that can be centralized or decentralized.
• It is a decentralized-distributed system.
• A distributed system is a computing paradigm whereby two or
more nodes work with each other in a coordinated fashion to
achieve a common outcome.
• For example, Google’s search engine is based on a large
distributed system;
– however, to a user, it looks like a single, coherent platform. It is
composed of processes (nodes) and channels (communication channels)
where nodes communicate by passing messages.
 Distributed Database
• A node is an individual player (a computer) in a
distributed system.
• All nodes can send and receive messages to and
from each other.
• Nodes can be honest, faulty, or malicious, and
they have memory and a processor.
• A node that exhibits arbitrary behavior is
known as a Byzantine node after the Byzantine
Generals problem
 Distributed Database
• This type of inconsistent behavior of
Byzantine nodes can be intentionally
malicious, which is detrimental to the
operation of the network.
• Any unexpected behavior by a node on the
network, whether malicious or not, can be
categorized as Byzantine
 Example of Distributed System
This distributed system has six nodes, of which one (N4) is a
Byzantine node, leading to possible data inconsistency. L2 is a link
that is broken or slow, and this can lead to a partition in the
network:

Figure 1: Design of a distributed system: N4 is a Byzantine node and L2 is broken

or a slow network link
 key challenges of a distributed system
• Two key challenges of a distributed system design are
– the coordination between nodes and
– fault tolerance.
• Even if some (a certain threshold dictated by the consensus
protocol) of the nodes become faulty or network links break,
the distributed system should be able to tolerate this and
continue to work to achieve the desired result.
• This problem has been an active area of distributed system
design research for many years, and several algorithms and
mechanisms have been proposed to overcome these issues.
 The history of blockchain
• 1976 – Diffie–Hellman work on securely exchanging
cryptographic keys.
• 1978 – Invention of public key cryptography.
• 1979 – Invention of Merkle trees (hashes in a tree
structure) by Ralph C. Merkle.
• 1980s – Development of TCP/IP.
• 1980 – Protocols for public key cryptosystems, Ralph
C. Merkle.
• 1982 – Blind signatures proposed by David Chaum.
• 1982 – The Byzantine Generals problem
 The history of blockchain
• 1985 – Work on elliptic curve cryptography by Neal
Koblitz and Victor Miller.
• 1991 – Haber and Stornetta work on tamper-proofing
document timestamps. This can be considered the earliest
idea of a chain of blocks or hash chains.
• 1992 – Cynthia Dwork and Moni Naor publish Pricing
via Processing or Combatting Junk Mail. This is
considered the first use of PoW.
• 1993 – Haber, Bayer, and Stornetta upgraded the tamper-
proofing of document timestamps system with Merkle
trees.
 The history of blockchain
• 1995 – David Chaum’s Digicash system (an anonymous
electronic cash system) started to be used in some banks.
• 1998 – Bit Gold, a mechanism for decentralized digital
currency, invented by Nick Szabo. It used hash chaining
and Byzantine Quorums.
• 1999 – Emergence of a file-sharing application mainly
used for music sharing, Napster, which is a P2P network,
but was centralized with the use of indexing servers.
• 1999 – Development of a secure timestamping service
for the Belgian project TIMESEC.
 The history of blockchain
• 2000 – Gnutella file-sharing network, which introduced
decentralization.
• 2001 – Emergence of BitTorrent and Distributed Hash Tables
(DHTs).
• 2002 – Hashcash by Adam Back.
• 2004 – Development of B-Money by Wei Dei using Hashcash.
• 2004 – Hal Finney, the invention of the reusable PoW system.
• 2005 – Prevention of Sybil attacks by using computation
puzzles, due to James Aspnes et al.
• 2009 – Bitcoin (first blockchain).
 Consensus
• A fundamental problem in distributed
computing is achieving overall system
reliability in the presence of some faulty nodes.
• This often requires nodes to agree on some data
value that is needed during computation.
• The method that makes a distributed system
achieve this agreement is called consensus. In
simpler terms, a consensus is a dynamic way of
reaching agreement in a group
 Two General Problem
• Let suppose two generals (A and B as seen in Figure 2) planning an
attack on a common enemy struggle to decide on an attacking strategy
due to the location of the enemy city.
• The city is securely placed in a valley and has a solid defence that can
easily fight off a single army.
• The only chance of winning against this enemy is to attack from two
sides of the city at the same time.
• This constraint requires the generals to communicate with each other to
plan a synchronised attack.
• As the enemy’s city separates two attacking armies, the generals must
communicate with each other by sending a messenger across the territory.
• If the enemy captures the messenger of General A, the message will go
lost, and General B would not know when to attack and vice versa.
 Two General Problem

Figure 2: Two generals planning an attack on a common enemy

 Two General Problem
• Now, consider a scenario where
– General A, who is the leader amongst them, sends a message to
General B – “Attack at dawn tomorrow”.
– General B receives the message and acknowledges sending another
message, “Message received, attacking at dawn tomorrow”.
• A receives B’s confirmation and starts preparing for the attack.
• But, is this enough to reach a consensus between the generals?
• Sadly, not. General A knows B received the message, but B
still does not know if A received his acknowledgement and will
be ready for the attack.
• If General A sends a confirmation of receiving B’s response,
that makes B relieved, but then A starts to worry.
• This way they end up in an infinite exchange of confirmations.
 Two General Problem
• In another scenario,
• let us assume that General A posts a message to General B.
• As time passes, General A starts to wonder what might
happen to his message because of General B not sending an
acknowledgement yet.
• There might be two possibilities.
– Either General A’s messenger got captured and failed to deliver
the message, or
– B’s soldier carrying the message ended up in the enemy’s hand.
• In both situations, the two generals cannot come to a
consensus again.
• A is not sure if his message or B’s confirmation was lost,
and B is doubtful if A received his response.
 Two General Problem
• The preceding scenarios show no matter how
many different combinations we try and how
many messages we send, it is not possible to
guarantee that a consensus is reached and the
generals cannot be certain that their ally will
attack at the same time.
• This is an unsolved problem to date.
 Two General Problem: Solution
• Many people tried to solve this paradox and came up with a
few useful approaches.
• Although there exists mathematical proof that this problem is
unsolvable, accepting the uncertainty of the communication
channel is a potential solution that can improve the likelihood
of a synchronised attack.
• The Transmission Control Protocol (TCP), the backbone of
the modern World Wide Web (WWW), establishes the
connection between a client computer and the server using a
mechanism called three-way handshake that mimics the
attempted agreement between the generals described in this
paradox.
 The Byzantine Generals problem
• The Byzantine Generals Problem is a modified version of
the Two Generals Paradox.
• In this setup, the leader is called the commanding general
or the commander who leads the Byzantine army consisting
of n–1 number of lieutenant generals responsible for their
battalions.
• The commander and every lieutenant general must agree on
the decision of attack or retreat.
• This new version introduces a twist stating that one or more
of the generals can be a traitor to the Byzantine state who
lies about his choices.
 The Byzantine Generals problem
• The problem stated that the commander must
send an order to his n–1 lieutenant generals
such that
• (1) all loyal lieutenants obey the same order; or
• (2) if the commanding general is loyal, then
every loyal lieutenant obeys the order he sends.
• In this problem, the algorithm to reach
consensus is based on the value of the majority
of the decisions a lieutenant observes.
 The Byzantine Generals problem
• Let us do a hands-on approach to find out how a possible
consensus can be achieved.
• We consider a scenario where three Byzantine lieutenant generals
led by a commanding general take their positions around an
enemy city.
• Amongst them, Lieutenant General 3 is a traitor.
• The message from the commanding general is Attack but the
traitor changed it to Retreat as shown in Figure 3.
• Having received the message from the commander, each
lieutenant forwards it to other lieutenants.
• Despite having a traitor, the general consensus, in this case, is
Attack, which was the original message sent by the commander
The Byzantine Generals problem

Figure 3: Three Byzantine lieutenant generals led by a commanding general

planning to attack an enemy city. The message from Commanding General is
Attack, but the traitor (Lieutenant) changed it to Retreat. Despite that
Consensus is Attack, which was the original message sent by the commander.
 The Byzantine Generals problem
• In the same scenario, what if the commander himself is the
traitor rather than a lieutenant?
• Let us draw the same diagram again but with commander as
the traitor who sends three different kinds of messages –
Attack, Wait and Retreat – to his lieutenants as shown in
Figure 4.
• Despite the commander being the traitor, the generals still
reach a consensus. To understand the outcome of this
consensus we must realise that because each lieutenant
receives three different kinds of messages from multiple
sources, they cannot decide on attacking the city and act on the
default option, which is Retreat
The Byzantine Generals problem

Figure 4: Three Byzantine lieutenant generals led by a commanding general, who is

traitor in this scenario, planning to attack an enemy city. The message from the
commanding general is Attack, Wait, and Retreat. Despite that the consensus is
“Retreat” is the default option.
 The Byzantine Generals problem
• The original paper by Lamport et al. provided a
theorem stating that for any m, the algorithm
reaches consensus if there are more than 3m
generals and at most m traitors.
• This implies that the algorithm can reach consensus
as long as 2/3 of the generals are honest.
• If the traitors are more than 1/3, consensus is not
reached, the armies do not coordinate their attack
and the enemy wins.
 Byzantine Fault Tolerance
• The fault tolerance is the property that enables a system
to continue operating properly in the event of the failure
of some of its components.
• The Byzantine fault tolerance (BFT) is a special class of
fault tolerance that is very challenging to achieve.
• In a “Byzantine failure”, a component such as a server
can inconsistently appear both failed and functioning to
failure-detection systems, presenting different symptoms
to different observers.
• BFT is the characteristic defining a system that tolerates
the Byzantine failure.
 Byzantine Fault Tolerance
• Blockchains are decentralised ledgers by definition that are
not managed by a central authority.
• This gives bad nodes the motivation to try to cause faults to
achieve unfair economic benefits.
• In the absence of BFT, a node will be able to send false
transactions nullifying the reliability of the blockchain.
• To make things worse, no central authority can step in to
take over and repair the damage in this context.
• Thus having the Byzantine fault tolerance and a solution to
the Byzantine Generals Problem for blockchains is much
needed.
 Reference
• Niaz Chowdhury Inside Blockchain, Bitcoin and
Cryptocurrencies