UNIT-II

-----------------------------------------------------------------------------------------------
Consensus Algorithms And Permissioned Blockchain: Block Propagation,
Consensus -Requirements for the consensus protocols, Scalability aspects of Block
chain consensus protocols, Consensus in Bitcoin, Solving Double Spending,
Attacks, Proof of Work (PoW), Proof of Stake (PoS), Proof of Burn, Proof of
Elapsed Time (PoET), Mining.
Permissioned Block chain: Basics, Smart Contracts, Consensus State Machine
Replication, Crowd Funding, distributed Consensus.
Consensus Algorithms: Requirements, PAXOS consensus Algorithm, RAFT
consensus Algorithm, Byzantine general problem, Practical Byzantine fault
tolerance Algorithm, and Three phases commit Protocol
-----------------------------------------------------------------------------------------------
BLOCK PROPAGATION
The P2P network for Bitcoin is composed of miner nodes that connect to one
another at random. These nodes disseminate transactions and blocks throughout
the network until all have received the information. Hops are required for a
transaction to spread a message throughout the network. The network dispersion
increases by a factor of 2n with each iteration as a set of two nodes are delivered
the message. After twelve to fifteen hops, the message is distributed over the whole
network, with the diffusion growing exponentially as the number of hops rises.
The throughput of a blockchain is determined by the number of transactions it can
support per second and is expressed as –

Where, Transactions Block is the factor of the current block capacity of the Bitcoin
and average transaction size.
With an average transaction size of about 540 bytes and the current Bitcoin block
capacity of 1MB for a block interval of ten minutes, the network now handles about
1,950 transactions each block, or about three transactions every second (TPS).

Either the transactions per block or the blocks per second can be increased to boost
throughput. It has already taken a lot of effort to use both on-chain and off-chain
techniques to increase the number of transactions per block. Teams have
experimented with expanding the block size by ten times in an effort to multiply
the capacity by a factor of ten. A higher block size typically maintains the hop count
at twelve to fifteen for the whole network, but necessitates delivering a bigger block
(one block of 10MB) through the Bitcoin connection.

Although the transaction/block size grows in this case, it also raises the issue of
network throttling, which exponentially lengthens propagation times and raises
the stakes in the argument over Bitcoin splits. One such attempt is the hard fork of
Bitcoin into Bitcoin Cash.

On the other hand, blocks/second is another important component to take into

account for network scaling, although it has so far frequently been overlooked
owing to a variety of throttling considerations. The absence of features like
pipelining, latency optimization, redundancy, congestion, message losses, and
others prevent the Bitcoin network stack from achieving the per-node link
capacity, making the existing gossip mechanism that determines journey time on
the network plane inefficient.

Double-spending
Double-spending is the outcome of spending some money more than once. Bitcoin
users secured themselves from double-spending cheating by waiting for
verification when receiving payments on the blockchain. There is a possibility that
a digital currency can be spent twice. Transactions in bitcoin are a digital file. It is
possible to duplicate transactions and spend the same Bitcoin twice.

There is a weakness in double-currency that it faces the issue of copying and

pasting.
Here are some examples of how you can double-spend a digital currency:
Copy a coin and send it to another person while still keeping back the original one.
Send the same coin to two different people at the same time.
Alter a transaction that has been already been made while keeping the goods and
the money.
The double-spend problem is a serious issue for any digital currency since it can
boost up the money which spoils the value of the currency.
1. Centralized Solution:
The centralized solution is quite easy to spent double-spending. It includes a
central administration that keeps data of each person’s balance in the system. The
administration permits the transaction and the money is transferred. Every single
bank in the world operates on centralized servers. This administration has access
to all the individual person’s banking acts and has every information related to
one’s bank account. Suppose, if someone got your internet banking password or
hack the bank’s centralized servers, then the administration has access to all of this
information.
If the centralized servers failed, then your access would be denied. A decentralized
payment system solves all of these issues. When you are using a cryptocurrency to
send or receive money, you don’t need to depend on a third party to confirm the
transaction. There is no requirement for a third party. This makes cryptocurrencies
perfect for sending or receiving a payment from someone in a different country.
2. Decentralized Solution:
In decentralized currency, there is no central administration for approving
transactions. Bitcoin uses a mix of elements to solve the double-spend problem.
Decentralized systems are having no boundary. It makes no difference if you are
sending someone money to somebody in your hometown, or someone on the other
side of the world. Your funds are much more secure when using a decentralized
system. The only person that has access to your money is you.
Consensus algorithms:
• A consensus algorithm is a process in computer science used to achieve
agreement on a single data value among distributed processes or systems.
OR
• A consensus mechanism is a fault-tolerant mechanism that is used in
computer and block chain systems to achieve the necessary agreement on a
single data value or a single state of the network among distributed
processes or multi-agent systems
• A consensus mechanism refers to any number of methodologies used to
achieve agreement, trust, and security across a decentralized computer
network
• Some of the common objectives of the consensus mechanism for block chain
are collaboration, equal rights to each node, coming to an agreement,
cooperation, and mandatory participation of every node.
• These algorithms are designed to achieve reliability in a network involving
multiple users or nodes.

Types of Consensus Algorithms: Consensus algorithms have different types

working on different principles. So, let’s understand each of these algorithms
and how they work.

1. Proof of Work (PoW)

2. Proof of Authority
3. Proof of Stake (PoS)
• Delegated Proof of Stake (DPoS)
 • Leased Proof of Stake (LPoS)
• Proof of Importance (PoI)
4. Direct Acyclic Graph (DAG)
5. Byzantine Fault Tolerance (BFT)
• Practical Byzantine Fault Tolerance (pBFT)
• Delegated Byzantine Fault Tolerance (dBFT)
6. Proof of Capacity (PoC)
7. Proof of Identity (PoI)
8. Proof of Activity (PoA)
9. Proof of Elapsed Time (PoET)

Proof of Work (PoW):

Proof of work is the first Blockchain algorithm introduced in the blockchain

network. Many blockchain Technologies uses this Blockchain consensus model to
confirm all of their transactions and produce relevant blocks to the network chain.

It is one of the oldest consensus algorithms introduced by Cynthia Dwork and

Moni Naor in 1993 and reintroduced by Satoshi Nakamoto (founder of Bitcoin) in
2008. PoW aims to solve complex mathematical problems through nodes and
make as many predictions as possible in the shortest time.

Used by Etherium, Bitcoin, and other public blockchains, PoW is the most reliable
and secure consensus algorithm, but scalability concerns are plentiful.

In the proof of work algorithm, validators, also known as miners or node

participants, need to prove that the work they have done and submitted gives them
the right to add new transactions to the blockchain network. To achieve this,
miners mu st solve mathematical puzzles on the new block before approving it to
the ledger. After that, the solution is forwarded to other validators and verified by
them before accepting the copies of the ledger.

Using Proof of Work (PoW) verification for every transaction helps the core
network of the blockchain prevent double-spending. In other words, if anyone tries
to duplicate a transaction in the blockchain network, it will be seen in the system
and will not be accepted. Hence, no one can change the transaction once it has been
verified and approved by every node participant.

Proof of Authority
The Proof of Authority consensus algorithm uses the value of identities, so the
block validators don’t stake coins but their reputations. As this consensus
algorithm depends on the limited number of validators, it makes the system highly
scalable.

It is an effective solution for supply chains because it allows companies to maintain

their privacy and attain blockchain benefits simultaneously.

In Proof of Authority, the rights to create new blocks are given to participant nodes
that have proven their authority.

Proof of Authority-based blockchain networks is validated by approved validators

who run software that allows them to put transactions in the blockchain system.

Proof of Stake (PoS)

Proof of Stake (PoS) is a greener PoW substitute that requires fewer CPU
computations for mining. Although the purpose of PoS is similar to PoW, the
process differs. That being said, while a miner has to solve mathematical puzzles
and create a new block in PoW; the new block creator is chosen according to its
wealth in a deterministic manner, also known as Stake in PoS.

Moreover, PoS saves both energy and time. But, to become a validator, participants
need to invest some stake (money). And, the miners also get the opportunity to
take their transaction fees as there are no rewards for them in the system.

In simple terms, instead of investing in costly hardware to solve complex puzzles,

validators will invest in the system coins and lock some of them as stakes. By doing
that, the validators will validate the blocks by placing a bet on them if they find a
block that can be added to the network.

There are two popular types of PoS: DPoS and LPoS.

Delegated Proof of Stake (DPoS)

In DPoS, the miners stake their coin and vote for a particular amount of delegates,
in a way that, the more they invest, the more precedence they receive. They get
rewards in terms of coins or transaction fees.

In DPoS, there are 21-100 delegates charged periodically and assigned to deliver
their blocks. Having fewer delegates allows for an efficient organization to design
time slots for publishing blocks in the network. In case of, insufficient, invalid, or
missing block publishing, the miners vote them out to be replaced with other
selected delegates.

As DPoS works on the stake-weighted voting system, it has become one of the
fastest growing and adapted blockchain consensus models.

Leased Proof of Stake (LPoS)

LPoS operates on Waves' blockchain platform and is an advanced version of PoS.

In LPoS, users lease crypto tokens to the node that wants to act as a block producer
for the network. A node with the maximum number of staked tokens is more likely
to be selected for the next block generation as well as receive rewards.

It also helps users with smaller tokens who might not have been eligible for
participating as the blockchain creator in the traditional proof of Stake process in
pooling their assets while enhancing their chances of receiving network transaction
fees’ share.

The leased proof of stake (LPoS) consensus algorithm is best for networks with
high high-technical requirements for operating full nodes capable of verifying and
validating transactions.

Proof of Importance (PoI)

Proof of Importance (PoI) is also an advanced version of Proof of Stake (PoS) that
considers other factors than just weighing the level of influence of every node on
the network. It aims to take a comprehensive approach to evaluate contributions
from users rather than focusing on capital needs.

It resolves PoS limitations by prioritizing miners based on the transaction numbers

corresponding to cryptocurrency. In the case of PoI, the more transactions made
to and from the user’s crypto wallet, the merrier the chances of these users getting
blockchain mining projects.

Direct Acyclic Graph (DAG)

DAG is a data structuring or modeling consensus model often used in crypto
currencies. Unlike a typical blockchain network consisting of blocks, DAG has
edges and vertices, where transactions are recorded over each other.

As the name suggests, DAG looks like a graph rather than a set of chains and is
being seen as the possible alternative for blockchain due to its effective storage and
processing of transactions. They are directed because they move in one direction
and acyclic because the vertices do not loop.

In the DAG consensus mechanism, each node prepares to be the miner and reduces
the associated costs as the transactions get validated by users themselves, making
the whole process fastest, lightweight, and secured.

Byzantine Fault Tolerance (BFT)

The Byzantine Generals’ Problem was something established in 1982 that
represents a logical dilemma on how a group of generals faced communication
problems while trying to decide their next move.

So, Byzantine Fault Tolerance (BFT) is the blockchain system property that resists
the failures that might derive from this problem. Simply put, a BFT system can
continuously operate even when nodes act maliciously or fail.

BFT is used to fix the problem of unreliable nodes in the network. pBFT and dBFT
are two types of BFTs being used for determining unreliable chain code operations.

Practical Byzantine Fault Tolerance (pBFT)

PBFT attempts to provide a Byzantine state machine replication that works
regardless of malicious nodes.
Distributed systems with pBFT are sequentially ordered with a primary node (or
the leader) and several secondary ones (or the backups). In the event of a primary
node failure, any eligible node in the system can become the primary by
transitioning from secondary to primary. Using the majority rule, all honest nodes
should contribute to reaching a consensus regarding the state of the system.

Delegated Byzantine Fault Tolerance (dBFT)

dBFT is a consensus algorithm that provides remarkable security against fraud. It
is kind of similar to the DPoS model as the miners get the responsibility to vote for
the delegates but are independent of their investment amounts. Only the right
equipment, verified identity, and 1000 GAS are sufficient to become a delegate
themselves.

dBFT determines the validators based on real-time voting which improves the
algorithm and saves time and confirmation time for transactions. The selected
team of validators then uses the BFT algorithm to generate more blocks.

Proof of Capacity (PoC)

In the proof of capacity algorithm, miners create a list of every hash that is possible
beforehand in the plotting process, then store them on a hard drive. So, it can be
said that the more storage capacity a minder may have, the more possibility of
finding solutions. And possessing the correct hashes combination increases the
chances of miners winning the rewards.

As there’s no need for specialized and expensive components, the chances to

participate in the network are for the average participants.

Proof of Identity (PoI)

Proof of Identity (PoI) is similar to authorized identities. Each transaction is
attached to a cryptographic confirmation of the user's private key. A block of data
can be created and managed by each identified user in a network and presented to
others.

Needless to say, the PoI consensus algorithm helps in ensuring the integrity and
authenticity of the data, and therefore, is a great choice for being used in smart
cities.

Proof of Activity (PoA)

In the Proof of Activity algorithm, miners solve the cryptographic problem as soon
as possible using electric energy and hardware. But, one thing to remember while
using PoA is that when one comes across a given set of blocks only has the
information about the identity and reward transaction of the winner.

A block's validity is verified by its validators. A complete block is activated if the

block has been checked many times. Thus, open transactions are confirmed to be
processed and are finally incorporated into block containers.

Proof of Elapsed Time (PoET)

Proof of Elapsed Time or PoET, developed by Intel, had the purpose to solve the
challenge of “random election of leaders” in computing systems. Released as part
of Software Guard Extensions, PoET is being used by private blockchain networks
that depend on a random timer system to select network participants.

The idea behind PoET is to equally distribute and expand bigger participants'
fractions by asking each of them to wait for a certain amount of time before
working on the next process. So, whenever a block is available and the node is
activated, that node gets the authority to share the information on the network
while maintaining decentralization and earning rewards.

Permissioned blockchains

Permissioned blockchains are blockchains that are closed or have an access control
layer. This additional layer of security only allows participants to perform the
actions that they are authorized to perform.

In a permissioned blockchain, a user would need permission from the network

owner to become part of the said network. Technically, a user can only access read
and write information on the blockchain if they are given access to it. A private
permissioned blockchain defines the roles that dictate how each participant can
contribute to the blockchain and what they can access.

A permissioned blockchain also supports customization. Hence, identity

verification can also be done to let people into the permissioned network, instead
of having the network owner approve each user. Users would ideally still be able to
perform only certain activities in the network, based on the block chain’s
designated permissions.

Benefits of Permissioned Blockchains

There are many benefits of permissioned blockchains. Let’s understand the

beneficial features of permissioned blockchains with its benefits.

Efficient performance: When we compared permissioned blockchains to

permission less blockchains, they offer better performance. The core reason
behind this is the limited number of nodes on the platform. This removes the
unnecessary computations required to reach consensus on the network, improving
the overall performance. On top of that, permissioned networks have their own
pre-determined nodes for validating a transaction.

Proper governance structure: Permissioned networks do come with an

appropriate structure of governance. This means that they are organized.
Administrators also require less time to update the rules over the network, which
is considerably faster when compared to public blockchains. The public blockchain
network suffers from the consensus problem as not all nodes work together to get
the new update implemented. These nodes might place their self-interest above
the needs of the blockchain, which, in return, means slower updates to the whole
network. In comparison, permissioned blockchain doesn’t have the problem, as the
nodes work together to move the updates faster.

Decentralized storage: Permissioned networks also make proper use of

blockchain, including utilizing its decentralized nature for data storage.

Cost-Effective: There is no doubt that permissioned blockchains are more cost-

effective when compared with the permissionless blockchains

Drawbacks of Permissioned blockchains

Permissioned blockchains are not free from disadvantages or drawbacks. Here are
te disadvantages of permissioned blockchains:

Compromised security – A public or private blockchain has better security as

the nodes participate in a consensus method properly. But, in the case of
permissioned blockchains, this might not hold true. The security of a permissioned
network is as good as the member’s integrity. This means that a small section of a
permissioned system can work together to modify the data stored within the
network. In this way, the integrity of the network can be compromised. To resolve
it, the system should have proper permissions set so those bad actors cannot merge
together to cause the desired effect.

Control, Censorship, and Regulation – In an ideal world, these permissioned

blockchains should work as that of a public blockchain, but with regulations.
However, the regulations bring censorship to the network, where the authority can
restrict a transaction or control it from happening. These are a threat to any
business or organization that is using the permissioned network. This approach
also stops the permissioned network from making the most out of the whole
blockchain ecosystem.

State Machine Replication

The state machine replication helps us to achieve a consensus in a permission
model. We do not need to execute a smart contract to all the nodes. Rather, the
selected subset of contract executor executes it and propagates it with other nodes
to ensure the contract’s status is propagated to all the nodes uniformly in the
network, and they are on the same page. The distributed state machine replication
technology ensures consensus in a permission blockchain environment.

Smart Contracts in Blockchain

A Smart Contract (or crypto contract) is a computer program that directly and
automatically controls the transfer of digital assets between the parties under
certain conditions. A smart contract works in the same way as a traditional contract
while also automatically enforcing the contract. Smart contracts are programs that
execute exactly as they are set up (coded, programmed) by their creators. Just like
a traditional contract is enforceable by law, smart contracts are enforceable by
code.
• The Bitcoin network was the first to use some sort of smart contract by using
them to transfer value from one person to another.
• The smart contract involved employs basic conditions like checking if the
amount of value to transfer is actually available in the sender account.
• Later, the Etherium platform emerged which was considered more powerful,
precisely because the developers/programmers could make custom contracts in
a Turing-complete language.
• It is to be noted that the contracts written in the case of the bitcoin network were
written in a Turing-incomplete language, restricting the potential of smart
contracts implementation in the bitcoin network.
• There are some common smart contract platforms like Ethereum, Solana,
Polkadot, Hyperledger fabric, etc.

History: In 1994, Nick Szabo, a legal scholar, and a cryptographer recognized the
application of a decentralized ledger for smart contracts. He theorized that these
contracts could be written in code which can be stored and replicated on the
system and supervised by the network of computers that constitute the
blockchain. These smart contracts could also help in transferring digital assets
between the parties under certain conditions.
Features of Smart Contracts
The following are some essential characteristics of a smart contract:
1. Distributed: Everyone on the network is guaranteed to have a copy of all the
conditions of the smart contract and they cannot be changed by one of the
parties. A smart contract is replicated and distributed by all the nodes
connected to the network.
2. Deterministic: Smart contracts can only perform functions for which they are
designed only when the required conditions are met. The final outcome will not
vary, no matter who executes the smart contract.
3. Immutable: Once deployed smart contract cannot be changed, it can only be
removed as long as the functionality is implemented previously.
4. Autonomy: There is no third party involved. The contract is made by you and
shared between the parties. No intermediaries are involved which minimizes
bullying and grants full authority to the dealing parties. Also, the smart contract
is maintained and executed by all the nodes on the network, thus removing all
the controlling power from any one party’s hand.
5. Customizable: Smart contracts have the ability for modification or we can say
customization before being launched to do what the user wants it to do.
6. Transparent: Smart contracts are always stored on a public distributed ledger
called blockchain due to which the code is visible to everyone, whether or not
they are participants in the smart contract.
7. Trustless: These are not required by third parties to verify the integrity of the
process or to check whether the required conditions are met.
8. Self-verifying: These are self-verifying due to automated possibilities.
9. Self-enforcing: These are self-enforcing when the conditions and rules are met
at all stages.

Capabilities of Smart Contracts

1. Accuracy: Smart contracts are accurate to the limit a programmer has
accurately coded them for execution.
2. Automation: Smart contracts can automate the tasks/ processes that are done
manually.
3. Speed: Smart contracts use software code to automate tasks, thereby reducing
the time it takes to maneuver through all the human interaction-related
processes. Because everything is coded, the time taken to do all the work is the
time taken for the code in the smart contract to execute.
4. Backup: Every node in the blockchain maintains the shared ledger, providing
probably the best backup facility.
5. Security: Cryptography can make sure that the assets are safe and sound. Even
if someone breaks the encryption, the hacker will have to modify all the blocks
that come after the block which has been modified. Please note that this is a
highly difficult and computation-intensive task and is practically impossible for
a small or medium-sized organization to do.
6. Savings: Smart contracts save money as they eliminate the presence of
intermediaries in the process. Also, the money spent on the paperwork is
minimal to zero.
7. Manages information: Smart contract manages users’ agreement, and stores
information about an application like domain registration, membership
records, etc.
8. Multi-signature accounts: Smart contracts support multi-signature accounts to
dist

How Do Smart Contracts Work?

A smart contract is just a digital contract with the security coding of the blockchain.
• It has details and permissions written in code that require an exact sequence of
events to take place to trigger the agreement of the terms mentioned in the
smart contract.
• It can also include the time constraints that can introduce deadlines in the
contract.
• Every smart contract has its address in the blockchain. The contract can be
interacted with by using its address presuming the contract has been
broadcasted on the network.
The idea behind smart contracts is pretty simple. They are executed on a basis of
simple logic, IF-THEN for example:
• IF you send object A, THEN the sum (of money, in cryptocurrency) will be
transferred to you.
• IF you transfer a certain amount of digital assets (cryptocurrency, for example,
ether, bitcoin), THEN the A object will be transferred to you.
• IF I finish the work, THEN the digital assets mentioned in the contract will be
transferred to me.
Note: The WHEN constraint can be added to include the time factor in the smart
contracts. It can be seen that these smart contracts help set conditions that have
to be fulfilled for the terms of the contract agreement to be executed. There is
no limit on how much IF or THEN you can include in your intelligent contract.

Smart Contract Working

• Identify Agreement: Multiple parties identify the cooperative opportunity

and desired outcomes and agreements could include business processes, asset
swaps, etc.
• Set conditions: Smart contracts could be initiated by parties themselves or
when certain conditions are met like financial market indices, events like GPS
locations, etc.
• Code business logic: A computer program is written that will be executed
automatically when the conditional parameters are met.
• Encryption and blockchain technology: Encryption provides secure
authentication and transfer of messages between parties relating to smart
contracts.
• Execution and processing: In blockchain iteration, whenever consensus is
reached between the parties regarding authentication and verification then the
code is executed and the outcomes are memorialized for compliance and
verification.
• Network updates: After smart contracts are executed, all the nodes on the
network update their ledger to reflect the new state. Once the record is posted
and verified on the blockchain network, it cannot be modified, it is in append
mode only.

Applications of Smart Contracts

1. Real Estate: Reduce money paid to the middleman and distribute between the
parties actually involved. For example, a smart contract to transfer ownership
of an apartment once a certain amount of resources have been transferred to
the seller’s account(or wallet).
2. Vehicle ownership: A smart contract can be deployed in a blockchain that
keeps track of vehicle maintenance and ownership. The smart contract can, for
example, enforce vehicle maintenance service every six months; failure of which
will lead to suspension of driving license.
3. Music Industry: The music industry could record the ownership of music in
a blockchain. A smart contract can be embedded in the blockchain and royalties
 can be credited to the owner’s account when the song is used for commercial
purposes. It can also work in resolving ownership disputes.
4. Government elections: Once the votes are logged in the blockchain, it would
be very hard to decrypt the voter address and modify the vote leading to more
confidence against the ill practices.
5. Management: The blockchain application in management can streamline and
automate many decisions that are taken late or deferred. Every decision is
transparent and available to any party who has the authority(an application on
the private blockchain). For example, a smart contract can be deployed to
trigger the supply of raw materials when 10 tonnes of plastic bags are produced.
6. Healthcare: Automating healthcare payment processes using smart contracts
can prevent fraud. Every treatment is registered on the ledger and in the end,
the smart contract can calculate the sum of all the transactions. The patient
can’t be discharged from the hospital until the bill has been paid and can be
coded in the smart contract.

Example Use cases:

1. Smart contracts provide utility to other contracts. For example, consider a
smart contract that transfers funds to party A after 10 days. After 10 days, the
above-mentioned smart contract will execute another smart contract which
checks if the required funds are available at the source account (let’s say party
B).
2. They facilitate the implementation of ‘multi-signature’ accounts, in which the
assets are transferred only when a certain percentage of people agree to do so
3. Smart contracts can map legal obligations into an automated process.
4. If smart contracts are implemented correctly, can provide a greater degree of
contractual security.

Advantages of Smart Contracts

1. Recordkeeping: All contract transactions are stored in chronological order in
the blockchain and can be accessed along with the complete audit trail.
However, the parties involved can be secured cryptographically for full privacy.
2. Autonomy: There are direct dealings between parties. Smart contracts
remove the need for intermediaries and allow for transparent, direct
relationships with customers.
3. Reduce fraud: Fraudulent activity detection and reduction. Smart contracts
are stored in the blockchain. Forcefully modifying the blockchain is very
difficult as it’s computation-intensive. Also, a violation of the smart contract
can be detected by the nodes in the network and such a violation attempt is
marked invalid and not stored in the blockchain.
4. Fault-tolerance: Since no single person or entity is in control of the digital
assets, one-party domination and situation of one part backing out do not
happen as the platform is decentralized and so even if one node detaches itself
from the network, the contract remains intact.
5. Enhanced trust: Business agreements are automatically executed and
enforced. Plus, these agreements are immutable and therefore unbreakable and
undeniable.
6. Cost-efficiency: The application of smart contracts eliminates the need for
intermediaries (brokers, lawyers, notaries, witnesses, etc.) leading to reduced
costs. Also eliminates paperwork leading to paper saving and money-saving.

Challenges of Smart Contracts

1. No regulations: A lack of international regulations focusing on blockchain
technology (and related technology like smart contracts, mining, and use cases
like crypto currency) makes these technologies difficult to oversee.
2. Difficult to implement: Smart contracts are also complicated to implement
because it’s still a relatively new concept and research is still going on to
understand the smart contract and its implications fully.
3. Immutable: They are practically immutable. Whenever there is a change that
has to be incorporated into the contract, a new contract has to be made and
implemented in the blockchain.
4. Alignment: Smart contracts can speed the execution of the process that span
multiple parties irrespective of the fact whether the smart contracts are in
alignment with all the parties’ intention and understanding.

Paxos — A distributed consensus algorithm

Paxos is an algorithm that enables a distributed set of computers (for example, a
cluster of distributed database nodes) to achieve consensus over an asynchronous
network. To achieve agreement, one or more of the computers proposes a value to
Paxos.

Imagine a file, replicated across different servers around the world. An algorithm
that ensures that a change you make on that file is propagated to all of its replicas,
is called a consensus algorithm.
Paxos is a family of consensus protocols, that ensure replica consistency in a
distributed system of unreliable processors (that is servers can fail). The Paxos
protocol was introduced in 1989 by Leslie Lamport, named after a fictional
legislative consensus system used on the Paxos island in Greece

Paxos Objective of the algorithm: To maintain the same ordering of

commands among multiple replicas so that all the replicas eventually converge to
the same value. This is similar to the case where multiple cars following the same
directions arrive at the same final destination.

Assumptions
The following assumptions are made about the processors and the network on
which the protocol is implemented.

Processors
• Operate at arbitrary speed and may experience failures.
• Processors with stable storage may re-join the protocol after failures (following
a crash-recovery failure model).
• Do not collude, lie, or otherwise attempt to subvert the protocol. (Byzantine
failures aren’t considered)
Network
• Processors can send messages to any other processor.
• Messages are sent asynchronously and may take arbitrarily long to deliver.
• Messages may be lost, reordered, or duplicated.
• Messages are delivered without corruption.

The wedding of replicas

Imagine a wedding happening between n people instead of 2. The priest asks the
‘Do you …’ question to each one of the n people being wed and only if each and
every person replies ‘I do’, the wedding is complete. Replica consensus in Paxos is
achieved through a similar mechanism.
When a client executes a command on a given replica, the replica nominates itself
as a leader. This execution is tagged with the highest number that this replica has
seen. Consensus is achieved among replicas through a 2 phase commit protocol
which is detailed below:

Prepare phase: This replica (Proposer) now sends a message to majority of

replicas (possibly including itself), about the change and its associated number. If
a replica hasn’t previously seen a change with a higher number than the proposal
number, it accepts the change.

Commit phase: If all the replicas accept the message, then the proposer sends
an accept request to all the replicas and the change is then asynchronously
propagated to all of them.

However, even if one of those replicas reject the proposer’s request, then the
proposer may abort the change or retry the commit with a higher number.
Raft Consensus Algorithm
It is named after Reliable, Replicated, Redundant, And Fault-Tolerant. The Raft
consensus algorithm mascot. Raft is not a Byzantine fault tolerant algorithm: the
nodes trust the elected leader.

Introduction
Raft protocol was developed by Diego Ongaro and John Ousterhout (Stanford
University) which won Diego his Ph.D in 2014(The link for the paper is in the
References section at the end of the article). Raft was designed for better
understandability of how Consensus(we will explain what consensus is, in a
moment) can be achieved considering that its predecessor, the Paxos Algorithm,
developed by Lesli Lamport is very difficult to understand and implement. Hence,
the title of the paper by Diego, ‘In Search of an Understandable Consensus
Algorithm’. Before Raft, Paxos was considered the holy grail in achieving
Consensus..
Consensus
So, to understand Raft, we shall first have a look at the problem which the Raft
protocol tries to solve and that is achieving Consensus. Consensus means multiple
servers agreeing on same information, something imperative to design fault-
tolerant distributed systems. Lets describe it with the help of couple visuals.
So, lets first define the process used when a client interacts with a server to clarify
the process.
Process : The client sends a message to the server and the server responds back
with a reply.
A consensus protocol tolerating failures must have the following features :

• Validity: If a process decides(read/write) a value, then it must have been

proposed by some other correct process
• Agreement: Every correct process must agree on the same value
• Termination: Every correct process must terminate after a finite number of
steps.
• Integrity: If all correct processes decide on the same value, then any process has
the said value.

Now, there can be two types of systems assuming only one client(for the sake of
understandability):

• Single Server system: The client interacts with a system having only one
server with no backup. There is no problem in achieving consensus in such a
system.

Fig: single server raft visual

• Multiple Server system: The client interacts with a system having multiple
servers. Such systems can be of two types:
• Symmetric :- Any of the multiple servers can respond to the client and all the
other servers are supposed to sync up with the server that responded to the
client’s request, and
• Asymmetric: - Only the elected leader server can respond to the client. All
other servers then sync up with the leader server.

Such a system in which all the servers replicate (or maintain) similar data (shared
state) across time can for now be referred to as, replicated state machine.
We shall now define some terms used to refer individual servers in a distributed
system.

• Leader – Only the server elected as leader can interact with the client. All other
servers sync up themselves with the leader. At any point of time, there can be at
most one leader(possibly 0, which we shall explain later)
• Follower – Follower servers sync up their copy of data with that of the leader’s
after every regular time intervals. When the leader server goes down(due to any
reason), one of the followers can contest an election and become the leader.
• Candidate – At the time of contesting an election to choose the leader server,
the servers can ask other servers for votes. Hence, they are called candidates
when they have requested votes. Initially, all servers are in the Candidate state.
So, the above system can now be labelled as in the following snap.

Fig: multiple servers labeled raft visual

CAP theorem CAP Theorem is a concept that a distributed database system can
only have 2 of the 3:
• Consistency – The data is same in all the server nodes (leader or follower),
implying the system has nearly instantaneous sync capabilities

• Availability – Every request gets a response (success/failure). It requires the

system to be operational 100% of the time to serve requests, and

• Partition Tolerance – The system continues to respond, even after some of

the server nodes fail. This implies that the system maintains all the
requests/responses function somehow.

What is the Raft protocol

Raft is a consensus algorithm that is designed to be easy to understand. It’s

equivalent to Paxos in fault-tolerance and performance. The difference is that it’s
decomposed into relatively independent subproblems, and it cleanly addresses all
major pieces needed for practical systems. We hope Raft will make consensus
available to a wider audience, and that this wider audience will be able to develop
a variety of higher quality consensus-based systems than are available today.

Raft consensus algorithm explained

To begin with, Raft states that each node in a replicated state machine (server
cluster) can stay in any of the three states, namely, leader, candidate, follower. The
image below will provide the necessary visual aid.
Under normal conditions, a node can stay in any one of the above three states. Only
a leader can interact with the client; any request to the follower node is redirected
to the leader node. A candidate can ask for votes to become the leader. A follower
only responds to candidate(s) or the leader.

To maintain these server status(es), the Raft algorithm divides time into small
terms of arbitrary length. Each term is identified by a monotonically increasing
number, called term number.

Term number

This term number is maintained by every node and is passed while

communications between nodes. Every term starts with an election to determine
the new leader. The candidates ask for votes from other server nodes(followers) to
gather majority. If the majority is gathered, the candidate becomes the leader for
the current term. If no majority is established, the situation is called a split vote
and the term ends with no leader. Hence, a term can have at most one leader.

Purpose of maintaining term number

Following tasks are executed by observing the term number of each node:

• Servers update their term number if their term number is less than the term
numbers of other servers in the cluster. This means that when a new term starts,
the term numbers are tallied with the leader or the candidate and are updated
to match with the latest one(Leader’s)

• Candidate or Leader demotes to the Follower state if their term number is out
of date(less than others). If at any point of time, any other server has a higher
term number, it can become the Leader immediately.

• As we said earlier that the term number of the servers are also communicated,
if a request is achieved with a stale term number, the said request is rejected.
This basically means that a server node will not accept requests from server with
lower term number

Raft algorithm uses two types of Remote Procedure Calls(RPCs) to carry out the
functions :

• RequestVotes RPC is sent by the Candidate nodes to gather votes during an

election
• AppendEntries is used by the Leader node for replicating the log entries and
also as a heartbeat mechanism to check if a server is still up. If heartbeat is
responded back to, the server is up else, the server is down. Be noted that the
heartbeats do not contain any log entries.

Now, lets have a look at the process of leader election.

Leader election

In order to maintain authority as a Leader of the cluster, the Leader node sends
heartbeat to express dominion to other Follower nodes. A leader election takes
place when a Follower node times out while waiting for a heartbeat from the Leader
node. At this point of time, the timed out node changes it state to Candidate state,
votes for itself and issues RequestVotes RPC to establish majority and attempt to
become the Leader. The election can go the following three ways:

• The Candidate node becomes the Leader by receiving the majority of votes from
the cluster nodes. At this point of time, it updates its status to Leader and starts
sending heartbeats to notify other servers of the new Leader.

• The Candidate node fails to receive the majority of votes in the election and
hence the term ends with no Leader. The Candidate node returns to the
Follower state.

• If the term number of the Candidate node requesting the votes is less than other
Candidate nodes in the cluster, the AppendEntries RPC is rejected and other
nodes retain their Candidate status. If the term number is greater, the
Candidate node is elected as the new Leader.
 Fig: Raft leader election

The following excerpt from the Raft paper(linked in the references below) explains
a significant aspect of server timeouts.

Raft uses randomized election timeouts to ensure that split votes are rare and that
they are resolved quickly. To prevent split votes in the first place, election timeouts
are chosen randomly from a fixed interval (e.g., 150–300ms). This spreads out the
servers so that in most cases only a single server will time out; it wins the election
and sends heartbeats before any other servers time out. The same mechanism is
used to handle split votes. Each candidate restarts its randomized election timeout
at the start of an election, and it waits for that timeout to elapse before starting the
next election; this reduces the likelihood of another split vote in the new election.

Log Replication

For the sake of simplicity while explaining to the beginner level audience, we will
restrict our scope to client making only write requests. Each request made by the
client is stored in the Logs of the Leader. This log is then replicated to other
nodes(Followers). Typically, a log entry contains the following three information :
• Command specified by the client to execute

• Index to identify the position of entry in the log of the node. The index is 1-
based(starts from 1).

• Term Number to ascertain the time of entry of the command.

The Leader node fires AppendEntries RPCs to all other servers(Followers) to

sync/match up their logs with the current Leader.The Leader keeps sending the
RPCs until all the Followers safely replicate the new entry in their logs.

There is a concept of entry commit in the algorithm. When the majority of the
servers in the cluster successfully copy the new entries in their logs, it is considered
committed. At this point, the Leader also commits the entry in its log to show that
it has been successfully replicated. All the previous entries in the log are also
considered committed due to obvious reasons. After the entry is committed, the
leader executes the entry and responds back with the result to the client.

It should be noted that these entries are executed in the order they are received.

If two entries in different logs(Leader’s and Followers’) have identical index and
term, they are guaranteed to store the same command and the logs are identical
upto that point(Index).

However, in case the Leader crashes, the logs may become inconsistent. Quoting
the Raft paper :

In Raft, the leader handles inconsistencies by forcing the followers’ logs to

duplicate its own. This means that conflicting entries in follower logs will be
overwritten with entries from the leader’s log.

The Leader node will look for the last matched index number in the Leader and
Follower, it will then overwrite any extra entries further that point(index number)
with the new entries supplied by the Leader. This helps in Log matching the
Follower with the Leader. The AppendEntries RPC will iteratively send the RPCs
with reduced Index Numbers so that a match is found. When the match is found,
the RPC succeeds.

Safety
In order to maintain consistency and same set of server nodes, it is ensured by the
Raft consensus algorithm that the leader will have all the entries from the previous
terms committed in its log.

During a leader election, the RequestVote RPC also contains information about the
candidate’s log(like term number) to figure out which one is the latest. If the
candidate requesting the vote has less updated data than the Follower from which
it is requesting vote, the Follower simply doesn’t vote for the said candidate. The
following excerpt from the original Raft paper clears it in a similar and profound
way.

Raft determines which of two logs is more up-to-date by comparing the index and
term of the last entries in the logs. If the logs have last entries with different terms,
then the log with the later term is more up-to-date. If the logs end with the same
term, then whichever log is longer is more up-to-date.

Rules for Safety in the Raft protocol

The Raft protocol guarantees the following safety against consensus malfunction
by virtue of its design:

• Leader election safety – At most one leader per term)

• Log Matching safety(If multiple logs have an entry with the same index and
term, then those logs are guaranteed to be identical in all entries up through to
the given index.

• Leader completeness – The log entries committed in a given term will always
appear in the logs of the leaders following the said term)

• State Machine safety – If a server has applied a particular log entry to its state
machine, then no other server in the server cluster can apply a different
command for the same log.

• Leader is Append-only – A leader node(server) can only append(no other

operations like overwrite, delete, update are permitted) new commands to its
log

• Follower node crash – When the follower node crashes, all the requests sent to
the crashed node are ignored. Further, the crashed node can’t take part in the
 leader election for obvious reasons. When the node restarts, it syncs up its log
with the leader node

Cluster membership and Joint Consensus

When the status of nodes in the cluster changes(cluster configuration changes),

the system becomes susceptible to faults which can break the system. So, to prevent
this, Raft uses what is known as a two phase approach to change the cluster
membership. So, in this approach, the cluster first changes to an intermediate
state(known as joint consensus) before achieving the new cluster membership
configuration. Joint consensus makes the system available to respond to client
requests even when the transition between configurations is taking place. Thus,
increasing the availability of the distributed system, which is a main aim.

What are its advantages/Features

• The Raft protocol is designed to be easily understandable considering that the

most popular way to achieve consensus on distributed systems was the Paxos
algorithm, which was very hard to understand and implement. Anyone with
basic knowledge and common sense can understand major parts of the protocol
and the research paper published by Diego Ongaro and John Ousterhout

• It is comparatively easy to implement than other alternatives, primarily the

Paxos, because of a more targeted use case segment, assumptions about the
distributed system. Many open source implementations of the Raft are available
on the internet. Some are in Go, C++, Java

• The Raft protocol has been decomposed into smaller subproblems which can
be tackled relatively independently for better understanding, implementation,
debugging, optimizing performance for a more specific use case

• The distributed system following the Raft consensus protocol will remain
operational even when minority of the servers fail. For example, if we have a 5
server node cluster, if 2 nodes fail, the system can still operate.

• The leader election mechanism employed in the Raft is so designed that one
node will always gain the majority of votes within a maximum of 2 terms.

• The Raft employs RPC(remote procedure calls) to request votes and sync up the
cluster(using AppendEntries). So, the load of the calls does not fall on the leader
node in the cluster.
• Raft was designed recently, so it employs modern concepts which were not yet
understood at the time of the formulation of the Paxos and similar protocols.

• Any node in the cluster can become the leader. So, it has a certain degree of
fairness.

• Many different open source implementations for different use cases are already
out there on GitHub and related places

• Companies like MongoDB, HashiCorp, etc. are using it!

Raft Alternatives

• Paxos – Variants :- multi-paxos, cheap paxos, fast paxos, generalised paxos

• Practical Byzantine Fault Tolerance algorithm (PBFT)

• Proof-of-Stake algorithm (PoS)

• Delegated Proof-of-Stake algorithm (DPoS)

Limitations

• Raft is strictly single Leader protocol. Too much traffic can choke the system.
Some variants of Paxos algorithm exist that address this bottleneck.

• There are a lot of assumptions considered to be acting, like non-occurrence of

Byzantine failures, which sort of reduces the real life applicability.

• Raft is a more specialized approach towards a subset of problems which arise

in achieving consensus.

• Cheap-paxos(a variant of Paxos), can work even when there is only one node
functioning in the server cluster. To generalise, K+1 replicated servers can
tolerate shutting down of/ fault in K servers.

Byzantine General’s Problem

In 1982, The Byzantine General’s Problem was invented by Leslie Lamport, Robert
Shostak, and Marshall Pease. Byzantine Generals Problem is an impossibility
result which means that the solution to this problem has not been found yet as well
as helps us to understand the importance of blockchain. It is basically a game
theory problem that provides a description of the extent to which decentralized
parties experience difficulties in reaching consensus without any trusted central
parties.

• The Byzantine army is divided into many battalions in this classic problem
called the Byzantine General’s problem, with each division led by a general.

• The generals connect via messenger in order to agree to a joint plan of action in
which all battalions coordinate and attack from all sides in order to achieve
success.

• It is probable that traitors will try to sabotage their plan by intercepting or

changing the messages.

• As a result, the purpose of this challenge is for all of the faithful commanders to
reach an agreement without the imposters tampering with their plans.

Money and Byzantine General’s Problem

Money is one such commodity whose value should be same throughout the society,
that is everyone should agree upon the value of a certain amount of money, despite
all the differences therefore in the initial times, precious metals and rare goods
were chosen as money because their value was seen equally throughout the society,
but in some cases such as precious metals the purity of the metals could not be
known for sure or checking the purity was an extremely tedious task which turned
out to be very inefficient for the daily transactions, therefore it was decided upon
to replace gold with a central party which would be highly trustable chosen by the
people in the society to establish and maintain the system of money. But with time
it was later realized that those central parties, how much-ever qualified were still
not completely trustworthy as it was so simple for them to manipulate the data.

• Centralized systems do not address the Byzantine Generals problem, which

requires that truth be verified in an explicitly transparent way, yet centralized
systems give no transparency, increasing the likelihood of data corruption.

• They forgo transparency in order to attain efficiency easily and prefer to avoid
dealing with the issue entirely.
• The fundamental issue of centralized systems, however, is that they are open to
corruption by the central authority, which implies that the data can be
manipulated by anyone who has control of the database itself because the
centralized system concentrates all power on one central decision maker.

Therefore, Bitcoin was invented to make the system of money decentralized using
blockchain to make money verifiable, counterfeit-resistant, trustless, and separate
from a central agency.

How Bitcoin Solves the Byzantine General’s Problem?

In the Byzantine Generals Problem, the untampered agreement that all the loyal
generals need to agree to is the blockchain. Blockchain is a public, distributed
ledger that contains the records of all transactions. If all users of the Bitcoin
network, known as nodes, could agree on which transactions occurred and in what
order, they could verify the ownership and create a functioning, trustless money
system without the need for a centralized authority. Due to its decentralized
nature, blockchain relies heavily on a consensus technique to validate transactions.
It is a peer-to-peer network that offers its users transparency as well as trust. Its
distributed ledger is what sets it apart from other systems. Blockchain technology
can be applied to any system that requires proper verification.

Proof Of Work: The network would have to be provable, counterfeit-resistant,

and trust-free in order to solve the Byzantine General’s Problem. Bitcoin overcame
the Byzantine General’s Problem by employing a Proof-of-Work technique to
create a clear, objective regulation for the blockchain. Proof of work (PoW) is a
method of adding fresh blocks of transactions to the blockchain of a
cryptocurrency. In this scenario, the task consists of creating a hash (a long string
of characters) that matches the desired hash for the current block.

1. Counterfeit Resistant: Proof-of-Work requires network participants to

present proof of their work in the form of a valid hash in order for their block,
i.e. piece of information, to be regarded as valid. Proof-of-Work requires miners
to expend significant amounts of energy and money in order to generate blocks,
encouraging them to broadcast accurate information and so protecting the
network. Proof-of-Work is one of the only ways for a decentralized network to
agree on a single source of truth, which is essential for a monetary system. There
can be no disagreement or tampering with the information on the blockchain
network because the rules are objective. The ruleset defining which transactions
 are valid and which are invalid, as well as the system for choosing who can mint
new bitcoin, are both objectives.

2. Provable: Once a block is uploaded to the blockchain, it is incredibly difficult

to erase, rendering Bitcoin’s history immutable. As a result, participants of the
blockchain network may always agree on the state of the blockchain and all
transactions inside it. Each node independently verifies whether blocks satisfy
the Proof-of-Work criterion and whether transactions satisfy additional
requirements.

3. Trust-free: If any network member attempts to broadcast misleading

information, all network nodes immediately detect it as objectively invalid and
ignore it. Because each node on the Bitcoin network can verify every
information on the network, there is no need to trust other network members,
making Bitcoin a trustless system.

Byzantine General’s Problem in a Distributed System

In order to address this issue, honest nodes (such as computers or other physical
devices) must be able to establish an agreement in the presence of dishonest nodes.

• In the Byzantine agreement issue, an arbitrary processor initializes a single

value that must be agreed upon, and all nonfaulty processes must agree on that
value. Every processor has its own beginning value in the consensus issue, and
all nonfaulty processors must agree on a single common value.

• The Byzantine army’s position can be seen in computer networks.

• The divisions can be viewed as computer nodes in the network, and the
commanders as programs running a ledger that records transactions and events
in the order that they occur. The ledgers are the same for all systems, and if any
of them is changed, the other ledgers are updated as well if the changes are
shown to be true, so all distributed ledgers should be in agreement.

Byzantine General’s Problem Example

A basic Byzantine fault is a digital signal that is stuck at “1/2,” i.e. a voltage that is
anywhere between the voltages for a valid logical “0” and a valid logical “1.”
Because these voltages are in the region of a gate’s transfer function’s maximum
gain, little quantities of noise on the gate’s input become enormous amounts of
noise on the gate’s output. This is due to the fact that “digital circuits are simply
analog circuitry driven to extremes.”

This problem is solvable because, with a dominating input, even a Byzantine input
has no output impact.

• An excellent composite example is the well-known 3-input majority logic

“voter.”

• If one of the inputs is “1/2” and the other two are both 0 or both 1, the result is
0 or 1 (due to masking within the voter).

• When one of the inputs is “1/2” and the other two are different values, the
output can be 0, “1/2,” or 1, depending on the precise gain and threshold
voltages of the voter gates and the properties of the “1/2” signal.

Three Phase Commit Protocol

Three-Phase Commit (3PC) Protocol is an extension of the Two-Phase Commit

(2PC) Protocol that avoids blocking problem under certain assumptions. In
particular, it is assumed that no network partition occurs, and not more than k
sites fail, where we assume ‘k’ is predetermined number. With the mentioned
assumptions, protocol avoids blocking by introducing an extra third phase where
multiple sites are involved in the decision to commit.

Instead of directly noting the commit decision in its persistent storage, the
coordinator first ensures that at least ‘k’ other sites know that it intended to commit
transaction.

In a situation where coordinator fails, remaining sites are bound to first select new
coordinator. This new coordinator checks status of the protocol from the
remaining sites. If the coordinator had decided to commit, at least one of other ‘k’
sites that it informed will be up and will ensure that commit decision is respected.
The new coordinator restarts third phase of protocol if any of rest sites knew that
old coordinator intended to commit transaction. Otherwise, new coordinator
aborts the transaction.

Drawback of the Three-Phase Commit Protocol:

While 3PC protocol has desired property of not blocking unless ‘k’ sites fail, it has
drawback that partitioning of network may appear to be same as more than ‘k’ sites
failing, which would lead to blocking. The protocol also has to be implemented
carefully to ensure that network partitioning does not result in inconsistencies,
where transaction is committed in one partition and aborted in another. Because
of its overhead, 3PC protocol is not widely used.

The difference between Three-Phase Control Protocol and Two-Phase Control

Protocol can be understood by the following figures.

Fig-1 This figure represents Two-Phase Commit Protocol

 Fig-2 This figure represents the Three-Phase Control Protocol

Dissemination Phase:
It is introduced above helps the user to deal with the cases as when either a
participant failure or both coordinator and participant node failure during the
commit phase.

The recovery coordinator when it takes over after coordinator failure during Phase-
2 of the previous Two-Phase Commit Protocol the new additional phase comes
handy as follows.

Note –On querying participants, if it learns that some nodes are in the commit
phase, it then assumes that previous coordinator before crashing has made
decision to commit.

Hence it can shepherd the protocol to commit. Similarly, if a participant responds

that it doesn’t receive prepare to commit, then new coordinator can assume that
previous coordinator failed even before it started the preparation to commit phase.
Hence it can safely assume that no other participant would have committed any of
changes and hence it can now safely abort the transaction.