Whitepaper

Understanding Blockchain
Consensus Models

Dr Arati Baliga
Corporate CTO Office

© 2020 Persistent Systems Ltd. All rights reserved.

Contents

Executive Summary...................................................................................................................................................................3

Introduction................................................................................................................................................................................4

Consensus Background............................................................................................................................................................6

Bitcoin’s Proof-of-Work Invention...........................................................................................................................................8

Blockchain Consensus Models................................................................................................................................................9

Comparative Analysis.............................................................................................................................................................. 15

Conclusions............................................................................................................................................................................... 16

References................................................................................................................................................................................. 17

© 2020 Persistent Systems Ltd. All rights reserved. 2

Executive Summary

Blockchain technology enables participants being able to add a block to the blockchain.
to read from and update to a common shared It however has a few drawbacks such as high
ledger (or blockchain) whose state is collectively latencies, low transaction rate and significant
maintained by the network in a decentralized energy expenditure, which makes it a less than
fashion. The blockchain is updated via the perfect fit for many applications. As blockchain
consensus protocol that ensures a common, independently emerged as a powerful
unambiguous ordering of transactions technology, decoupled from the cryptocurrency,
and blocks and guarantees the integrity its consensus mechanisms also evolved
and consistency of the blockchain across independently dictated by the blockchain
geographically distributed nodes. The Bitcoin platform and application requirements. Since
cryptocurrency, which first popularized the the consensus model maintains the sanctity of
concept of blockchain, also introduced Proof-of- data recorded on the blockchain, it is important
Work (PoW) based consensus, which scaled to to ensure that it functions correctly in normal as
thousands of completely untrusted participants well as adversarial conditions. This whitepaper
(nodes). PoW based consensus requires nodes provides an overview of consensus models as
to solve a hard cryptographic puzzle by brute- adopted by popular blockchain platforms and
forcing and produce a winning value before analyzes their merits and demerits.

© 2020 Persistent Systems Ltd. All rights reserved. 3

Introduction

A blockchain-based system is a classical distributed and therefore can employ alternative consensus
system with shared state (i.e. the blockchain) where mechanisms. Achieving consensus in a distributed
all participants are geographically distributed and system has known solutions in the research
connected via different kinds of networks. literature, e.g. Paxos, RAFT, and various Byzantine
Blockchain platforms can be classified into two Fault Tolerance algorithms. Permissioned blockchain
main types — permissionless and permissioned. platforms have largely adopted these consensus
Open-ended systems such as Bitcoin and Ethereum algorithms.
are permissionless. They are publicly available for
use. Any node can conduct transactions as well As blockchain platforms are being challenged
as take part in the consensus process to advance to meet rigorous real-world application
the blockchain. Permissioned platforms such as requirements, such as low latencies, immediate
Hyperledger Fabric and MultiChain are aimed at transaction finality, high performance and good
consortiums where participation is close-ended. scalability, limitations of existing consensus models
While clients are allowed to submit transactions, are being recognized. On one hand, while PoW
advancing the blockchain is restricted to a fixed models support open-ended participation, they are
set of peering nodes that are run by consortium a poor match for applications that need immediate
members. transaction finality and have high transaction rates.
They also waste a lot of power. One study found
In a permissionless setup, the number of nodes that the electricity wasted in bitcoin mining is
is expected to be large, and these nodes are comparable to the average electricity consumption
anonymous and untrusted since any node is of Ireland1. On the other hand, consensus models
allowed to join the network. Consensus mechanisms designed for closed systems do not scale well
for such a setup have to account for maliciousness; beyond about twenty peering nodes and cannot
particularly Sybil attacks. Sybil attacks on a block- have any open-ended participation. To address
chain network can allow a single user to generate these limitations, new consensus models have been
several online identities to influence and manipulate designed and newer ones are still emerging.
the consensus process. Bitcoin solves this problem
by designing the consensus round to be computa- “A blockchain based system is as secure and robust
tionally hard. Nodes have to prove that they have as its consensus model.”
expended significant amount of energy as Proof-of-
Work (PoW) towards solving a hard cryptographic The security of the consensus model is perhaps
puzzle. This approach, though wasteful in terms of the most crucial aspect that requires close attention
energy expense, is required to ensure the safety of when choosing a blockchain platform. The
the consensus process. Early blockchain platforms consensus mechanism maintains the sanctity of
that were designed to be permissionless directly the data recorded on the blockchain. The block-
adopted PoW consensus mechanisms from chain system will safeguard the transaction and
bitcoin or designed some variant of it, for example, block order thereby safeguarding all the key
NameCoin, LiteCoin, DogeCoin and Monero. properties of blockchain, such as immutability and
auditability only when the underlying assumptions
Permissioned platforms have semi-trusted members are correct and the consensus model can uphold
where only known participating nodes that are the state of the blockchain under failure and
part of a consortium, are verified and registered. adversarial conditions.
These groups are expected to be small in number

© 2020 Persistent Systems Ltd. All rights reserved. 4

Poor choice of a consensus mechanism can Dominance
render the blockchain platform useless thereby Consensus round outcomes can be manipulated
compromising the data recorded on the blockchain. by a single or group of entities if it is not designed
Below are some of the issues that can result when to be resilient against Sybil attacks, where one or
the consensus mechanism fails. handful of nodes can generate millions of identities
that they control. Having such dominance allows
Blockchain Fork the dominating group to confirm the transactions
A blockchain fork can result in different nodes and blocks as per their rules, even include
in the system converging on different blocks transactions that can double-spend the crypto-
as being part of the blockchain. In bitcoin, though currency. Dominance can also be achieved by other
temporary forks may exist due to network latencies, means, such as controlling 51% of mining power in
the protocol is designed such that all nodes will a PoW network3.
eventually converge on a single chain. A blockchain
fork can wreak havoc on applications leading Cheating
to completely inconsistent view of data recorded Validating nodes either individually or in collusion
on the blockchain thereby forcing applications can independently maintain parallel forks in the
to behave in an unpredictable manner. The Stellar blockchain of fraudulent transactions or altered
network, which originally forked code from Ripple, reality that can been provided as proof to the
experienced a fork in the Stellar blockchain due auditor or external third party. The consensus
to a misconfiguration2. and blockchain reading mechanism has to ensure
that such attacks cannot be carried out on the
Consensus Failure blockchain platform.
Certain consensus algorithms may not guarantee
the ability to reach consensus. For e.g. if the Poor Performance
consensus algorithm requires a super-majority vote Based on the design of the consensus algorithm, it
from a certain percentage of nodes, failing to reach may require more time under certain conditions for
this number because of node or network failures, consensus to converge. These conditions could be
non-compliant nodes or as a result of valid honest dynamic where other nodes have turned malicious
nodes not being able to make a decision due to or a network partition may delay messages that are
inconsistent messages received from other nodes, exchanged between nodes, etc. This may manifest
may result in consensus failure. as inconsistently high latencies in applications.

© 2020 Persistent Systems Ltd. All rights reserved. 5

Consensus Background

Consensus mechanisms allow secure updating 2\ Liveness — A consensus protocol guarantees

of a distributed shared state and have been a topic liveness if all non-faulty nodes participating
of active research in the past three decades. in consensus eventually produce a value.
Common technique used for achieving fault
tolerance in a distributed system is to distribute 3\ Fault Tolerance — A consensus protocol provides
the shared state across multiple replicas in the net- fault tolerance if it can recover from failure
work. Updating the replicated shared state happens of a node participating in consensus.
according to pre-defined state transition rules
defined by the state machine that is executed on While all the above three properties are crucial,
all the replicas. This technique is known as state a famous result by Fischer, Lynch and Paterson[4]
machine replication. Replication of state ensures known as the FLP Impossibility Result, states
that the state is not lost if one or more nodes crash. that no deterministic consensus protocol can
The state machine rules ensure that all nodes guarantee safety, liveness and fault tolerance
executing them with identical inputs, will eventually in an asynchronous system. While fault tolerance
produce the same outputs. This results in eventual is crucial for globally distributed networks
agreement on the change of state via the consensus to operate, distributed systems tend to choose
protocol. The replicas also communicate with each between safety and liveness depending on their
other to build consensus and agree upon the finality system requirements and assumptions.
of the state after a state change is executed.
With a blockchain based system, the shared state Fault tolerance refers to two types of faults
is the blockchain and the state transition rules are in distributed systems. Fail-stop faults deal with
the rules of the blockchain protocol. node failures that cause nodes to stop participating
in the consensus protocol. These are benign
Achieving consensus in a distributed system is faults caused by hardware or software crashes.
challenging. Consensus algorithms are resilient to When a fail-stop fault occurs, the node just stops
failures of nodes, partitioning of the network, responding. The second category of faults are
message delays, messages reaching out-of-order Byzantine faults, which cause nodes to behave
and corrupted messages. They also have to deal erratically. This category of faults was identified and
with selfish and deliberately malicious nodes. characterized by Leslie Lamport as the Byzantine
Several algorithms are proposed in the research General’s Problem [5], summarized in the side
literature to solve this, with each algorithm making note. Byzantine faults or failures can occur because
the required set of assumptions in terms of of software bugs or as a result of the node being
synchrony, message broadcasts, failures, malicious compromised. A Byzantine node can lie, can provide
nodes, performance and security of the messages ambivalent responses or completely mislead
exchanged. For a blockchain network, achieving other nodes involved in the consensus protocol.
consensus ensures that all nodes in the network The consensus protocol has to be able to operate
agree upon a consistent global state of blockchain. correctly and reach consensus in the presence of
Byzantine nodes as long as the number of Byzantine
A consensus protocol has three key properties nodes within a distributed system are limited.
based upon which its applicability and efficacy
can be determined.

1\ Safety — A consensus protocol is determined

to be safe if all nodes produce the same output
and the outputs produced by the nodes are valid
according to the rules of the protocol. This is also
referred to as consistency of the shared state.

© 2020 Persistent Systems Ltd. All rights reserved. 6

The Byzantine Generals’ Problem
A group of generals, each commandeering a part of the Byzantine army has surrounded an enemy city.
To attack the city, all the generals have to agree on a battle plan. Generals can communicate via messengers
only. The messengers might be captured by the enemy and the message might never reach the other general.
The difficulty in the agreement is that one or more generals might be traitors and are interested in sabotaging
the battle plan. To this end, they might send false messages, distort messages or not send any messages at all.
All loyal generals will act according to the plan. A small number of traitors should not cause the loyal generals
to adopt a bad plan.

Traditional consensus approaches in distributed in such networks are “2f+1” to be able to tolerate
systems have focused on building fault tolerance “f” fail-stop failures. Tolerating Byzantine faults,
in the face of unreliable systems provisioning mainly increases the complexity of the consensus protocol
for fail-stop faults. Paxos [6], Raft [7] and variants, by adding several extra layers of messaging into the
view-stamped replication [8] can be used for system. Practical Byzantine Fault Tolerance (PBFT)
ordering transactions in distributed databases [9], which was first proposed by Miguel Castro and
or to order client generated requests and respective Barbara Liskov, was the first practical approach that
state change in distributed applications using allowed for Byzantine fault tolerant applications with
replicated state machines. Paxos was built to low-overhead. Tolerating Byzantine faults needs
achieve fault tolerance and consistency in the face “3f+ 1” replicas to be able to tolerate “f” faults in
of failing nodes, which might either permanently fail the system. PBFT uses the concept of primary and
or fail for some time and then recover, or in the face secondary replicas, where the secondary replicas
of an unreliable network, where messages are not automatically check the sanity and liveness of
reliably delivered. In the face of such failures, these decisions taken by the primary and can collectively
algorithms guarantee progress and consistency switch to a new primary if the primary is found
in the data structures that were replicated across to be compromised.
physical machines. The number of nodes needed

© 2020 Persistent Systems Ltd. All rights reserved. 7

Bitcoin’s Proof-of-Work Invention

The bitcoin system facilitates transfer of the crypto- consensus is however vulnerable to “51%” attacks,
currency (bitcoins) from one individual to another in where a mining pool that is able to control 51% of
a completely decentralized fashion, and no central the mining power (i.e. hashrate), can write its own
entity controls either the production of bitcoins or is blocks into the blockchain or fork it to create an
involved in their transfer. The bitcoin blockchain independent branch that converges at a later point
is replicated on multiple nodes and the nodes order with the main blockchain. The advantage for the
the transactions based on a proof-of-work (PoW) attacker in launching such an attack, is that he can
consensus mechanism. double spend his own funds and selectively reject
transactions that he does not want included on
To add blocks to the blockchain, each node has the blockchain.
to show that it has performed some amount of work
also known as proof-of-work (PoW). In bitcoin, the Another research10 proves that a new type of attack
node has to find a hash value that is less than a can be carried out with an approach known as
certain number, also referred to as the difficulty level selfish mining, where the normally honest miners
set by the network. The difficulty level is dynamically are incentivized to support the attacker and join in
tuned by the bitcoin protocol, which currently carrying out a 51% attack. In this attack, the attacker
ensures that one block is produced every 10 mins. performs erratic mining, at the cost of his short-term
The process of solving the PoW puzzle to find a revenue by maintaining a separate pvt blockchain
winning hash value is known as mining. The first in parallel to the Bitcoin blockchain. He selectively
node to get a winning hash gets to add its proposed publishes many blocks all at once, forcing rest of
block to the blockchain and also claim the mining the network to discard their blocks and ultimately
reward. Due to the distributed, concurrent nature losing revenue. This incentivizes honest miners to
of this process, sometimes more than one node is join the attackers’ coalition to increase their revenue,
able to find a winning hash at the same time. Each which eventually can get to the size of 51% of the
winning node adds its own proposed block to the network’s mining power, enabling the attacker to
blockchain and broadcasts this over the peer-to- carry out a 51% attack.
peer network. In such cases, there is a temporary
fork in the blockchain, where some nodes are add- Bitcoin uses the PoW model, which guarantees
ing blocks to one branch, while other nodes are eventual consistency in the Bitcoin blockchain
adding blocks to other branches, based on which despite temporary forks. This approach results
winning node is closest to them. However, as more in longer transaction confirmation times, to ensure
blocks are added to these forks, the protocol will reasonable consensus finality, resulting in slower
ensure that the branch with the maximum PoW transaction confirmation rate, which at the time
(i.e. the longest branch) will get included in the of writing is approximately 7 transactions/second.
blockchain and others will be discarded. This leads This is considered very slow in the world of
to an eventual consistency among all nodes payments, particularly when contrasted with
regarding the state of the blockchain. MasterCard or VISA’s 10,000 transactions/sec.
Bitcoin-PoW also wastes a lot of energy in
The bitcoin PoW consensus algorithm works well computation of hashes during the mining process.
in an open environment where any number of It however has excellent scalability in terms of
nodes can participate in the network and start nodes participating in the network and operates
mining. No knowledge or authentication is needed completely in a decentralized fashion.
of any participants, thereby making this kind of
consensus model extremely scalable in terms of
supporting thousands of nodes. The bitcoin PoW

© 2020 Persistent Systems Ltd. All rights reserved. 8

Blockchain Consensus Models

Blockchain platforms use a range of consensus proof-of-elapsed-time (PoeT) and variations

models which are PoW and PBFT in their original of PBFT appear as viable alternatives. In this section,
form or variations of it providing certain advantages we review the broad categories of consensus
desired over the original model. Bold new models models used by the popular blockchain platforms.
are also proposed, such as proof-of-stake (PoS) and

Proof of Work — Ethereum (Homestead)

Ethereum is a general purpose blockchain platform Ethhash uses two techniques for combating mining
that supports smart contracts, a Turing complete centralization. First technique uses a property
programming language, Solidity, for writing smart called memory hardness. Memory hardness refers
contracts and a virtual machine called Ethereum to the ability of the computer to move data around
Virtual Machine (EVM) for executing smart contract in memory (rather than perform calculations), a
code on Ethereum nodes. Like bitcoin, Ethereum property that general purpose computer hardware
network is open and permissionless; any user can is already designed to perform significantly well but
download the Ethereum client to create an account cannot be achieved efficiently on ASICs.
and join the Ethereum network. It uses an internal By making the algorithm ASIC resistant, it prevents
cryptocurrency called Ether, which is used to pay large powerful companies from seizing control
for the network resources as well serve as an anti- of the mining power in the Ethereum network. A
spamming/DDoS defense measure. Ethereum is second technique referred to as GHOST, includes
designed to be general purpose and can be used the headers of the recently orphaned blocks known
by any kind of application requiring blockchain as uncles. Orphaned blocks are blocks that were
support. All transactions are recorded on the included on the temporary forks created off the
Ethereum blockchain and can be verified by any main blockchain. The node producing the uncle
entity using the Ethereum network. block and the node including it in the blockchain
are given a reduced reward to encourage them
Ethereum (in the current version called Homestead) to continue with the latest block in the Ethereum
uses its own PoW consensus model, called EthHash blockchain.
that provides fast confirmation times and builds
ASIC resistance to counter 51% attacks that bitcoin Ethhash also (similar to bitcoin) uses the concept
is susceptible to. Ethhash was designed to counter of finding a correct nonce input that can generate
mining centralization. Mining centralization was a a hash value below a certain difficulty level. In all
weakness in bitcoin where a large number of ASICs PoW algorithms, this is a time consuming process
were cheaply produced to perform hashing opera- where the node simply needs to cycle through the
tions at very high rates, thereby outnumbering and nonce values and run the algorithm each time to
outperforming the general purpose computer hard- generate a result. The algorithm works by choosing
ware by a very large margin. This allowed select subsets to a fixed resource dependent on the
powerful entities, such as large corporations to nonce and the block header. The fixed resource
create mining pools, with a very high hashing rate is a directed acyclic graph (DAG), which is few
and that allowed them to control a large portion gigabytes in size, which each Ethereum client
of the computing power of the bitcoin network. has to generate. The DAG changes and is totally

© 2020 Persistent Systems Ltd. All rights reserved. 9

different for each epoch in the Ethereum system. network adjusts the difficulty level to produce
An epoch is identified as a time period taken to a block every 15 seconds.
generate 30,000 blocks. The DAG only depends on
the block height and the clients can pre-generate Ethereum shares the same concerns as bitcoin
and cache the DAG. If the pre-generation is not regarding the 51% attack. If an attacker can control
done, the client can experience massive delays 51% of the mining power, a fork can be generated
at every epoch transition as mining cannot begin in the Ethereum blockchain. However, the ASIC
without having a DAG for that epoch. DAG is resistant design builds in significant resistance
needed for mining only and not for verification. towards carrying out a 51% attack in the Ethereum
Verification is a light weight process that can be network. Ethereum is scheduled to move to a proof-
computed in a fixed amount of time with low power of-stake algorithm in its future release (Serenity).
CPU and small amount of memory. The Ethereum

Proof-of-Stake Model (PoS) — Ethereum (Serenity)

Proof-of-stake algorithms are designed to overcome Nodes are allowed to be bonded with the Ethereum
the disadvantages of PoW algorithms in terms of the system by making significant security deposits set
high electricity consumption in mining operations. by the protocol. These nodes are bonded validators
PoS completely replaces the mining operation with and show commitment and interest in advancing
an alternative approach involving a user’s stake or the Ethereum blockchain via staking their security
ownership of virtual currency in the blockchain deposits. The initial list of bonded validators is
system. Putting it another way, instead of a user tracked by a special contract known as the Casper
spending say $2000 buying mining equipment to contract. From there on, the bonded validator list
engage in PoW algorithm and winning a mining can evolve based on newer nodes joining in and
reward, with PoS she can buy $2000 worth crypto- older ones leaving the system. Each validator is
currency and use it as stake to buy proportionate pseudo-randomly selected to produce a block
block creation chances in the blockchain system by from the active validator set, with the probability
becoming a validator. The PoS algorithm pseudo- of selection linearly weighted by each validator’s
randomly selects validators for block creation, deposit. If a validator is offline, a different validator
thereby ensuring that no validator can predict its is selected and this process repeats until an online
turn in advance. Naïve PoS algorithms suffer from validator is found that creates a block. If a validator
a problem called Nothing-at-Stake. produces a block that gets included in the chain,
These implementations do not provide incentives they receive a block reward equal to the total ether
for nodes to vote on the correct block. Therefore in the active validator set. If the validator produces
nodes can vote on multiple blocks supporting a block that does not get included in the chain, the
multiple forks to maximize their chances of winning protocol works such that the validator loses the
a reward as they do not “expend” anything in doing security deposit equal to the block reward. This
so as opposed to in PoW, where the node would mechanism proposes to solve the Nothing-at-Stake
be splitting up its resources to vote on multiple problem where it stop nodes from producing blocks
forks. This is the Nothing-at-Stake problem which that won’t get included in the main chain. Proof-
needs to be tackled for a correct and efficient of-stake was first designed and a naïve version of
implementation of PoS. it used by PeerCoin. Different variations of PoS are
also used by BitShares, NXT and Tendermint.
Ethereum’s PoS algorithm, called Casper, is perhaps
the most advanced PoS algorithm. Though multiple
rounds of PoCs are released, it is still in testing and
is expected to be released in the Serenity version
of the Ethereum platform. Casper uses the concept
of security deposits and bets to achieve consensus.

© 2020 Persistent Systems Ltd. All rights reserved. 10

Proof of Elapsed Time — Intel SawtoothLake

IntelLedger or Intel SawtoothLake is a blockchain Leader election works as follows — all validating
platform developed by Intel and subsequently open or mining nodes have to run the TEE using Intel
sourced for use by the community. The project is SGX. Each validator requests a wait time from the
officially now under Linux Foundation HyperLedger code running inside the TEE. The validator with
project as a proposal for further development. the shortest wait time wins the lottery and can
IntelLedger uses a consensus algorithm, designed become the leader. The functions within the TEE
by Intel, called proof-of-elapsed-time (PoET) meant are designed such that their execution cannot be
to run in a Trusted Execution Environment (TEE), tampered with by external software.
such as Intel’s Software Guard Extensions (SGX).
When a validating node claims to be a leader and
PoET uses a random leader election model or mines a block, it can also produce proof generated
a lottery based election model based on SGX, within the TEE that other nodes can easily verify.
where the protocol randomly selects the next leader It has to prove that it had the shortest wait time and
to finalize the block. The random leader election it waited for a protocol designated amount of time
algorithm uses this model to deal with untrusted before it is allowed to start mining the next block.
nodes and open–ended participation of nodes in
the consensus algorithm. For the consensus to work The randomness in generating wait times ensures
correctly, it has to randomly distribute the leader that the leader role is randomly distributed among
election among all available participating nodes all validating nodes. The only drawback of this
and it needs a secure way for other nodes to verify algorithm is the reliance on specialized hardware.
that a given leader was correctly selected without
any scope for manipulation. This is achieved using
the TEE to guarantee the safety and randomness of
electing a leader.

© 2020 Persistent Systems Ltd. All rights reserved. 11

Byzantine Fault Tolerance and Variants — HyperLedger Fabric

Hyperledger Fabric, the most popular permissioned handles transactions that are usually deterministic,
blockchain platform being developed by the Linux but which may occasionally yield different outputs.
Foundation provides a flexible architecture with The SIEVE protocol treats the chaincode itself
a pluggable consensus model. Fabric is designed like a bloack box. It initially executes all operations
for consortiums where the group of participants speculatively and then compares the outputs
in the consortiums is not only known, but their across replicas. If the protocol detects a minor
identities are registered and verified with a central divergence among a small number of replicas, the
registry service running within the system. It also diverging values are sieved out. If the divergence
supports smart contracts on the blockchain, also occurs across several processes, then the offending
known as chaincode. Hyperledger currently operation itself is sieved out.
supports two consensus models — the popular
Practical Byzantine Fault Tolerance algorithm Cross-Fault Tolerance (XFT)
(PBFT) and its variation SIEVE that is able to handle The XFT protocol is a new protocol that simplifies
non-deterministic chaincode execution. Current the attack model and makes Byzantine Fault
proposals are considering Crash Fault Tolerance Tolerance feasible and efficient for practical
(XFT) [11], which is a variation of Paxos with scenarios. BFT protocols assume a powerful
Byzantine Fault Tolerance built-in, as an alternative adversary where the adversary is able to control the
consensus algorithm for future versions. compromised nodes as well as the message delivery
of the entire network. Being able to tackle such
PBFT a powerful adversary brings in lot of complexity
The Practical Byzantine Fault Tolerance algorithm in BFT protocols and therefore makes them less
proposed by Miguel Castro and Barbara Liskov efficient. XFT relaxes the assumption of the powerful
was the first practical solution to the achieving adversary and solves the state machine replication
consensus in the face of Byzantine failures. It problem by simplifying it and providing an efficient
uses the concept of replicated state machine solution that can tolerate Byzantine faults.
and voting by replicas for state changes. It also
provides several important optimizations, such as XFT assumes that the adversary cannot control
signing and encryption of messages exchanged majority of the nodes and generate network
between replicas and clients, reducing the size partitions at will at the same time. XFT is particularly
and number of messages exchanged, for the interesting to blockchain based systems. In such
system to be practical in the face of Byzantine systems, nodes might have financial incentives to
faults. This algorithm requires “3f+1” replicas to be act maliciously, yet lack the means and capabilities
able to tolerate “f” failing nodes. This approach to compromise communications between nodes
imposes a low overhead on the performance of or create arbitrary network partitions. In such
the replicated service. The authors report a 3% geo-replicated systems, often there are multiple
overhead for a replicated network file system (NFS) communication paths between peers and therefore
service that they conducted their experiments on. communication is harder to break.
PBFT however has only been scaled and studied
to 20 replicas. It’s messaging overhead increases XFT is designed to to provide correct service as
significantly as the number of replicas increase. long as majority of the replicas are correct and can
communicate with each other synchronously. It uses
SIEVE the same number of resources as protocols that
SIEVE consensus protocol is designed to handle can tolerate fail-stop failures and can yet tolerate
non-determinism in chaincode execution. When Byzantine faults.
non-determinism is present within the chaincode,
it can produce different output when executed by
different replicas in a distributed network. SIEVE

© 2020 Persistent Systems Ltd. All rights reserved. 12

Federated Byzantine Agreement — Ripple and Stellar

Ripple and Stellar are two blockchain based other Ripple nodes that are trusted by the given
platforms and payment protocols that use variations node not to collude against it. Consensus
of the Byzantine Fault Tolerance consensus models in the Ripple network is achieved by each node
by making them open-ended with respect to node by consulting other nodes in its UNL. Each UNL
participation. These blockchain platforms target has to have a 40% overlap with other nodes in the
financial use cases and the payments domain in Ripple network [12]. Consensus happens in multiple
particular. They provide payment protocols, which rounds where each node collects transactions
can settle cross-border transactions in a matter of in a data structure called “candidate set” and
seconds as opposed to today’s infrastructure that broadcasts its candidate sets to other nodes in its
takes days for the same. UNL. Nodes validate the transactions, vote on them
and broadcast the votes. Based on the accumulated
The participants in such systems are end users, votes, each node refines its candidate set and
financial institutions that act as gateways and transactions receiving the largest number of votes
market makers that can be either users or are passed to the next round. When a candidate
financial institutions. End users generate payment set receives a super-majority of 80% of votes from
transactions using client software and must trust all nodes in the UNL, the candidate set becomes
some gateways to hold their payments. Gateways a valid block or in Ripple terms a “ledger”. This
are like banks that people use in the real world ledger is finalized and considered the “Last Closed
to hold their money. Gateways hold user funds Ledger (LCL)” and added to the Ripple blockchain
issued to the gateway in fiat currencies and create by each node. Next round of consensus is started
equivalent issuances in the Ripple/Stellar network, with newer transactions and pending transactions
which reflect as an account balance in the global that did not make it into the last round of consensus.
blockchain. A payment transaction can be verified Consensus in the entire network is reached when
by all nodes by referring to account balances in the each individual sub-network reaches consensus.
global blockchain. Transaction settles by adjusting
balances in the blockchain. Market-makers provide Stellar Consensus Protocol
the required liquidity in this network. Marketmakers Stellar Consensus protocol algorithm [13] uses
maintain accounts with multiple gateways and in the concept of quorums and quorum slices. Quorum
multiple currencies. They can trade in multiple is a set of nodes sufficient to reach agreement.
currencies and their liquidity is used to settle trades A quorum slice is a subset of a quorum that can
and payment transactions. Since most transactions convince one particular node about agreement.
deal with payments in fiat and other cryptocurrency, An individual node can appear on multiple quorum
it is of utmost importance that the protocol orders slices. Stellar introduces quorum slices to allow each
transactions consistently to prevent double spend individual node to choose a set of nodes within its
attacks. Ripple and Stellar use their own consensus slice thereby allowing open participation. These
models that are a derived form of Byzantine Fault quorum slices and quorums are based on real life
tolerance modified to include open-ended parti- business relationships between various entities
cipation from users, gateways and marketmakers. thereby leveraging trust that already exists in
business models. To reach global consensus in the
Ripple Consensus Protocol Algorithm entire systems, quorums have to intersect. Overall
Ripple protocol requires each node to define consensus is reached globally from decisions made
a unique node list (UNL). The UNL comprises by individual nodes.

© 2020 Persistent Systems Ltd. All rights reserved. 13

The consensus protocol works as follows: that statement. A v-blocking set is a set of nodes
Each node performs initial voting on transactions, one each from a quorum slice to which the current
also generically considered as statements. This is node belongs to. Quorum slices influence one
the first step of the federated voting process. Each another leading to quorums that agree on a certain
node performs its selection of statements and will statements. This step is known as ratification when
never vote for another statement contradicting its all members of a quorum agree on a statement.
selection. It can however accept a different state- Confirmation is the final step of the voting process
ment if its quorum slice has accepted a different and signifies system level agreement. This step
one. Second step is the acceptance step. A node ensures that nodes send each other confirmation
accepts a statement if it has never accepted a messages so that all agree upon the final value of
statement contradicting the current statement the state in the system.
and each node in its v-blocking set has accepted

© 2020 Persistent Systems Ltd. All rights reserved. 14

Comparative Analysis

Below, we present a comparison of the consensus model categories that we discussed so far in this document.

Table 1 below summarizes our findings, which are further elaborated in this section.

BFT and
PoW PoS PoET variants Federated BFT
Blockchain
Permissionless Both Both Permissioned Permissionless
Type
Transaction
Probabilistic Probabilistic Probabilistic Immediate Immediate
Finality
Transaction
Low High Medium High High
Rate
Token
Yes Yes No No No
Needed?
Cost of
Yes Yes No No No
Participation
Scalability of
High High High Low High
Peer Network
Trust
Untrusted Untrusted Untrusted Semi-trusted Semi-trusted
Model
Depends
Adversary
<=25% on specific Unknown <=33% <=33%
Tolerance
algorithm used

Table 1: A comparison of popular blockchain consensus mechanisms

Blockchain Type latencies. Since this generates temporary forks in

Blockchain type indicates the type of blockchain the blockchain and there is eventual chain that
platform – permissioned or permissionless, in which becomes the main chain, transactions that were
the consensus model can be used. This is mainly previously confirmed and ended up is losing
governed by the type of membership allowed by blocks will get rejected. This leads to a probabilistic
the consensus model. While PoW and Federated transaction finality model where clients will have to
BFT models are built exclusively for permissionless wait much longer for transactions to be confirmed
platforms with open-ended participation, they can and finalized. With PoS, temporary forks can co-
technically be used with permissioned platforms exist for short times if validators vote in parallel on
but won’t be ideal in that setting. multiple chains to maximize their rewards. However,
a good PoS algorithm like Casper can impose
Transaction Finality penalties for voting on multiple chains causing them
Transaction finality indicates whether the to lose security deposits. This will disincentivize
transaction once added to a block in the blockchain validators from exhibiting greedy behavior. In such
is considered final. PoW and PoET based consensus systems, the chain with maximum stake behind it is
models carry the risk of multiple blocks being the final chain. In the other models with immediate
mined at the same time due to their model of finality, once the transaction is included in the block,
leader election in combination with network it is confirmed and will not be rolled back.

© 2020 Persistent Systems Ltd. All rights reserved. 15

Transaction Rate Scalability of Peer Network
Transaction rate is higher with platforms that can Scalability of the consensus models is its ability
confirm transactions immediately and reach con- to reach consensus when number of peering nodes
sensus fast. PoW approaches are probabilistic and are constantly increasing. All models summarized
have to spend significant amount of time solving above, except BFT and variants, have high scal-
the cryptographic puzzle. Therefore these models ability. For BFT and variants it is recommended
have high transaction latencies and therefore a low to keep the number of peers in consensus network
transaction rate. PoET might be able to support to less than 20. Increasing the number of peers
much higher transaction rate because of a faster beyond 20 causes an increase in the number of
mechanism for leader election compared to PoW. messages sent between them resulting in a huge
Therefore, it supports medium transaction rate. amount of overhead.
BFT based approaches, PBFT and PoS can confirm
transactions fast and are expected to support high Trust Model
transaction rates. Trust model determines if the nodes participating
in the consensus have to be known or trusted. In
Token Needed? PoW, PoS and PoET, nodes can be untrusted as the
A cryptographic token is inherently required for mechanism to reach consensus is based on other
PoW and PoS models as their design itself is based means such as computational work or security
on existence of the token. Other three models do deposits. As long as more than 25-50% of the
not require a token for consensus to function. network is not adversarial, consensus decisions
It might however be used in certain platforms using will not be affected. With blockchains using BFT,
these models mainly as an anti-spam, anti-DDoS peering nodes have to be known and registered
measure. with the system to be involved in consensus
decisions. The nodes can get compromised or
Cost of Participation contain bugs in code but as long as more than
PoW and PoS have an inherent cost associated for 33% of the nodes are not compromised, consensus
participation in consensus. PoW requires expending process will be intact. With Federated Byzantine
energy, which is a resource that is external to the agreement, each node has to ensure that it include
consensus protocol, while PoS requires nodes to its trustworthy nodes in its trusted list.
buy some initial cryptocurrency to generate a
security deposit for declaring interest and bonding Adversary Tolerance
with the platform. The fraction of the network that can be
compromised without the consensus being
affected. Each consensus model has a certain
threshold to adversary tolerance.

Conclusions

Consensus models used by popular blockchain model that ensures faster transaction finality. When
platforms today are largely driven by the type looking at Blockchain to solve a business problem,
of applications the platform expects to cater to it is imperative to look at the scale of the intended
and the threats it envisages to the integrity of the network, the relationships between participants, and
chain. Typically the permissionless platforms are both functional and non-functional aspects
achieving robust consensus among very high (such as performance and confidentiality) before
number of untrusted peers using computational or determining the right platform and the right
memory complexity while sacrificing transaction consensus model to use. We hope that this
finality and throughput. On the other hand, the whitepaper sheds light on the background and
permissioned, consortium blockchains are opting current landscape of the consensus models and
for a less scalable but much higher throughput helps in that decision making.

© 2020 Persistent Systems Ltd. All rights reserved. 16

References

1\ Bitcoin mining and its Energy Footprint, Karl J. O’Dwyer and David Malone

2\ Stellar switches to Centralized System after node issue causes accidental fork.

3\ Are 51% attacks a real threat to Bitcoin?

4\ Impossibility of Distributed Consensus with One Faulty Process, Michael J. Fischer, Nancy A. Lynch
and Michael S. Paterson.

5\ The Byzantine Generals Problem, Leslie Lampot, Robert Shostak and Marshall Pease.

6\ Paxos made Simple, Leslie Lamport.

7\ In Search of an Understandable Consensus Algorithm, Diego Ongaro and John Ousterhout.

8\ V
 iewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems,
Brian M. Oki and Barbara H. Liskov.

9\ 
Practical Byzantine Fault Tolerance, Miguel Castro and Barbara Liskov.

10\ Majority is not Enogh: Bitcoin Mining is Vulnerable, Ittay Eyal and Emin Gun Sirer.

11\ P
 ractical Fault Tolerance Beyond Crashes, Shengyun Liu, Paolo Viotti, Cristian Cachin, Vivian Quema,
Marko Vukolic.

12\ The Ripple Protocol Consensus Algorithm, David Schwartz, Noah Youngs and Arthur Britto.

13\ Stellar Consensus Protocol: A Federated Model for Internet-level Consensus, David Mazieres.

About Persistent
Persistent Systems (BSE & NSE: PERSISTENT) builds software that drives our customers’ business; enterprises and software product companies
with software at the core of their digital transformation.
www.persistent.com

India USA
Persistent Systems Limited Persistent Systems, Inc.
Bhageerath, 402, 2055 Laurelwood Road, Suite 210
Senapati Bapat Road Santa Clara, CA 95054
Pune 411016. Tel: +1 (408) 216 7010
Tel: +91 (20) 6703 0000 Fax: +1 (408) 451 9177
Fax: +91 (20) 6703 0008 Email: [email protected]

© 2020 Persistent Systems Ltd. All rights reserved.