Overview of major consensus algorithms in blockchain and there comparative study

1. Blockchain Consensus
Algorithms
Anurag Dashputre

2. Agenda
● What is a Consensus Algorithm?
● Why we need them in Blockchain?
● Few popular consensus algorithms
● Consensus Algorithms - Comparative study

3. What is a Consensus Algorithm?
Consensus: A generally accepted opinion or decision among a group of people.
Algorithm: A set of rules for accomplishing a task in a certain number of steps.
Combining the two, you get: a set of rules and number of steps for accomplishing a generally accepted decision
among a group of people.

4. Why we need them in Blockchain?
Consensus algorithms are put in place to ensure a group of people agree that all transactions are validated and
authentic.
Consensus algorithms ensure a network of random people can achieve consensus about transactions in the
network. People have to cooperate and grow accustomed to these new decentralized networks that have no
central authority, unlike the governments, institutions, and businesses we are used to.
Consensus mechanisms secure a blockchain’s transactions by preventing the double-spending problem. At its
very basic, double-spending is much like sending a photo to someone digitally. You do not send the original
picture, but a copy and now two people have the same picture.
Imagine if someone could do this with cryptocurrencies.

5. Few popular consensus algorithms
Algorithm Description
PoW A Proof of Work is a piece of data which is difficult (costly, time-consuming) to produce but easy for others to
verify and which satisfies certain requirements. Producing a proof of work can be a random process with low
probability so that a lot of trial and error is required on average before a valid proof of work is generated.
PoS Proof of Stake (PoS) concept states that a person can mine or validate block transactions according to how
many coins he or she holds. This means that the more Bitcoin or altcoin owned by a miner, the more mining
power he or she has.
PoA Proof of Authority consensus protocols are used when participants are known to each other and there is a level
of trust between them.
PBFT Practical Byzantine Fault Tolerance (pBFT) is a specific case and the optimization of the Byzantine Fault
Tolerance network ability. Byzantine Fault Tolerance is the ability of a network to unmistakably reach a
consensus despite malicious nodes’ attempts to propagate false data to other peers.
IBFT Byzantine Fault Tolerant (leader is not trusted). Each block requires multiple rounds of voting
RAFT Raft is a consensus algorithm for managing a replicated log. It is CFT consensus, as opposed to BFT because in
Raft the leader is assumed to always act correctly (honestly).

6. RAFT
RAFT is a CFT (crash fault tolerant) consensus algorithm which relies on a trusted leader to form consensus and apply changes to
ledger. Node can be in 1 of 3 states: Follower, Candidate or Leader.
And has these processes
1. Leader Election - All nodes start in the follower state. If followers don't hear from a leader then they can become a candidate. The
candidate then requests votes from other nodes. The candidate becomes the leader if it gets votes from a majority of nodes.
Leader election process: Follower ⇒ Election Timeout happens ⇒ Become Candidate ⇒ Get Majority Votes ⇒ Become Leader,
send heartbeat messages ⇒ After Heartbeat Timeout ⇒ Become Follower (other follower goes to same cycle to become Leader)
2. Log Replication - All changes to the system now go through the leader. Each change is added as an entry in the node's log, which
is uncommitted at the moment. To commit the entry the node first replicates it to the follower nodes in next heartbeat and waits
until a majority of nodes have written the entry. The entry is now committed on the leader node and notifies it to follower about
the successful commit.

7. POA
• PoA relies on a set of trusted nodes called Authorities that use a simplified messaging algorithm to achieve better performance
• Each block signed by only one signature – that of the proposer’s.
• Forking will happen in a network with more than 4 authorities.

8. PBFT
• The PBFT model primarily focuses on providing a practical Byzantine state machine replication that tolerates "f" Byzantine faults
(malicious nodes) in system with "3f +1" nodes. E.g if f =1, total nodes = 4, faulty node = 1.
• Essentially, all of the nodes in the PBFT model are ordered in a sequence with one node being the primary node (leader) and the
others referred to as the backup nodes. Leader is selected on round robin basis (or few other protocols).
• The amount of malicious nodes in the network cannot simultaneously equal or exceed ⅓ of the overall nodes in the system
• The algorithm effectively provides both liveness and safety as long as at most (n-⅓), where n represents total nodes, are malicious or
faulty at the same time.
• Each round of PBFT consensus (called views) comes down to 4 phases. This model follows more of a “Commander and Lieutenant”
format than a pure Byzantine Generals’ Problem, where all generals are equal, due to the presence of a leader node. The phases are
below.
1. A client sends a request to the leader node to invoke a service operation.
2. The leader node multicasts the request to the backup nodes.
3. The nodes execute the request and then send a reply to the client.
4. The client awaits f + 1 (f represents the maximum number of nodes that may be faulty) replies from different nodes with the
same result. This result is the result of the operation.

9. PBFT (Continued)
Sequence of steps
1. Request - From Client to Leader node
2. Follows 3 phase protocol
a. Pre-Prepare - Leader sends Pre-Prepare
message to all. Nodes accept message if it is
valid node.
b. Prepare - If node accepts Pre-Prepare
message, it sends Prepare message to
everyone else and accepted if nodes are valid.
c. Commit - Nodes sent commit to messages to
all nodes.
3. Reply - From all nodes to Client

10. IBFT
The IBFT consensus mechanism comprises the following components:
● A PBFT inspired group consensus model.
● A process by which members can be added/removed from the validating group.
Its ideal if nodes belong to your fiercest competitors, or may be susceptible to compromises.
Its is one of the many flavours of PoA and provides the following benefits:
● Immediate block finality. There’s only 1 block proposed at a given chain height. The single chain thus removes forking, uncle
blocks, and the risk that a transaction may be “undone” once on the chain at a later time.
● Reduced time between blocks. The effort needed to construct and validate blocks is significantly reduced (in particular with
respect to PoW), greatly increasing the throughput of the chain.
● High data integrity and fault tolerance. IBFT uses a group of validators to ensure the integrity of each block being proposed. A
super-majority (~66%) of these validators are required to sign the block prior to insertion to the chain, making block forgery
very difficult. The ‘leadership’ of the group also rotates over time — ensuring a faulty node cannot exert long term influence
over the chain.
● Operationally flexible. The group of validators can be modified in time, ensuring the group contains only full-trusted nodes.

11. IBFT - Consensus Model
IBFT uses a pool of validating nodes (Validators) operating on an Ethereum network to determine if a proposed block is suitable for
addition to the chain.
One node of the Validators is arbitrarily selected as the Proposer and is responsible for constructing a block at the block-interval and
sharing said block with the group. If a super-majority of the Validators deem the block to be valid it is added to the blockchain.
At the completion of the consensus round, the Validators may select a new Proposer which will be responsible for providing the
candidate Block at the next block interval.
The members of the validation group may change over time through a voting mechanism. Members can be added or removed through
a majority ((N/2) + 1) vote.

12. Consensus Algorithms - Comparative study
Algorithm Public/
Private/
Both
No. of
Validators
Finality Malicious /
Malfunctioning Nodes
Trust Level Energy
Usage
PoW Public Many Probabilistic <50% Trustless Huge
PoS Public Many Probabilistic <50% Trustless Low
PBFT Private Many, with
periodic leader
rotation OR vote
based election
Instant (N-1)/3 Some trust Low
IBFT Private Many, with
periodic leader
rotation
Instant (N-1)/3 Some trust Low
POA (Clique) Both 1 Probabilistic
(within (N/2)+1 blocks)
None All trusted
nodes
Low
RAFT Private 1 Instant None All trusted
nodes
Low