CSE446: Blockchain & Cryptocurrencies
Lecture – 5: Distributed Systems, Consensus Algorithms & History of Money
Agenda
• FLP Impossibility, CAP Theorem
• Various consensus algorithms
FLP Impossibility
• A well-known theorem*, by Fischer, Lynch and Paterson, called
FLP Impossibility has shown that
• a deterministic consensus protocol cannot satisfy all three
properties in an asynchronous network
• Safety and liveness are favoured over fault tolerance in the
domain of distributed system applications
*M. J. Fischer, N. A. Lynch, and M. S. Paterson. “Impossibility of distributed consensus with one faulty process”. Journal of the
ACM (JACM), 32(2):374382, 1985
CAP Theorem
Pick any two
• CAP theorem* states that a
shared replicated datastore (or,
more generally, a replicated
state machine) cannot achieve
both consistency and
availability when a network
partitions in such a way that an
arbitrary number of messages https://hazelcast.com/wp-content/uploads/2021/12/cap-theorem-diagram-800x753-1.png
might be dropped
*Brewer, E. A. “Towards robust distributed systems.”. In PODC (Vol. 7), July
2000.
Crash-tolerant consensus algorithm
• Algorithms belonging to this class aim to guarantee the atomic
broadcast (total order) of messages within the participating nodes
in the presence of certain number of node failures
• These algorithms utilise the notion of views or epochs
• which imply a certain duration of time or events
• A leader is selected for each epoch who takes decisions regarding
the atomic broadcast, and all other nodes comply with its decision
• In case a leader fails due to a crash failure, the protocols elect a
new leader to function
Crash-tolerant consensus algorithm
• The best known algorithms belonging to this class can
continue to function if the following condition holds:
• f < n/2 where f is the number of faulty nodes and n is the total
number of participating nodes
• Examples of some well-known crash-tolerant consensus
protocol are
• Paxos, Viewstamped Replication, ZooKeeper, and Raft
RAFT
• Raft is a distributed consensus algorithm
• It solves the problem of getting multiple servers to agree on a
shared state even in the face of failures
• The shared status is usually a data structure supported by a
replicated log
• We need the system to be fully operational as long as a
majority of the servers are up
RAFT
• Raft works by electing a leader in the cluster
• The leader is responsible for accepting client requests and managing
the replication of the log to other servers
• The data flows only in one direction: leader -> other servers
• Raft decomposes consensus into three sub-problems
• Leader Election: A new leader needs to be elected in case of the failure of
an existing one
• Log replication: The leader needs to keep the logs of all servers in sync with
its own through replication
• Safety: to ensure consistency across all nodes
RAFT slides prepared from this location:https://www.freecodecamp.org/news/in-search-of-an-understandable-consensus-
algorithm-a-summary-4bc294c97e0d/
RAFT: leader election
Each node can only be a leader, follower, or
• Raft divides time into terms of arbitrary candidate
length, each beginning with an election
• If a candidate wins the election, it
remains the leader for the rest of the
term
• If the vote is split, then that term ends
without a leader
• The term number increases
monotonically and is also exchanged in
every communication
RAFT slides prepared from this location:https://www.freecodecamp.org/news/in-search-of-an-understandable-consensus-
algorithm-a-summary-4bc294c97e0d/
Question?
