UNIT NO- 03- Permissioned Model

Permissioned Blockchain – Introduction

Permissioned blockchain – A decentralized computation and information sharing
platform that enables multiple authoritative domains which do not trust each other
to cooperate, coordinate, and collaborate in a rational decision-making process
under a closed environment with the enablement of security services such as
authentication and authorization.

In the permissioned blockchain architecture, the users have to register and

authenticate themself to use the system. In this system, the users know each
other. However, users may not trust each other, assuming that certain users in
the blockchain network may behave maliciously. Although, they got authenticated
to use the system. The objective is to run the blockchain among this known and
identified set of participants, but security and consensus are still required for the
smooth functioning of the entire ecosystem.

The permissioned environment consists of a closed environment, and the

individual users knew each other. They try to come to a common platform with no
centralized database or data server rather a completely decentralized
architecture. Having a set of users known each other a priory, but they may not
trust each other. So in this particular setting, users cannot join the blockchain
network anytime. Rather, they have to go through the authentication mechanism
to authenticate themselves before accessing the permissioned blockchain
network.

Provenance Tracking of Assets (Supply Chain System)

To ensure that whenever a certain asset moves from one particular supplier to
the distributors, distributor to the vendors, and at the end, to the market via
retailers. At every stage, tracking information must be maintained by different
authoritative domains. Every authoritative domain has complete control over the
tracking information that they are providing. However, other authoritative
domains can verify the tracking information but can’t tamper. Here authoritative
domains represent Supplier, Distributor, and Vendor as these are independent
organizations with different policies to work. In this type of use case, we can use
premissioned blockchain architecture.
The interesting fact is that why not use a centralized server to have these
tracking entries? And anyone can look into that centralized tracking entries and
verify indeed. The problem is who will maintain the centralized server. Suppose if
a party, say Distributor, maintains a centralized server, then why Vendor or
Supplier trust the data uploaded by the distributor. In the other case, suppose
they are using a third-party solution—having high maintenance charges and
difficulty building a trust relationship among individuals.

Provenance Tracking of Assets (International Postal Services)

Let us understand how it works in the centralized environment.

National Postal Service

The single-party setup, such as sending or receiving goods within the same
country and the same service provider, is easy, and a centralized system solves
this problem. They can maintain tracking information in their centralized server,
and with tracking IDs, the users can easily track the status of consignments.

International Postal Service

Maintaining the tracking information for international goods services is difficult.

For example, A typical use case can be like sending postal mail from India to the
USA. The India Post is the one authoritative domain, and basically, they transfer
the post up to their border gateway, and from there, they will send it to some
international agency. Who will take the courier to USA post, and then USA post
will take it and transfer it internally.

The first problem is that whenever we have multiple authorities, it is difficult, or

there is a kind of trust issue whenever they rely on a centralized server. So the
question comes who will host that server? If India post will host the server, then
the question comes that why the USA post will trust or believe the data which is
there in the India Post server and vice versa.

The second problem is that if none of the India or USA posts will host that
particular service, they may purchase the service from some third-party agent. It
is like take the service of a third-party cloud. They have to pay a significant
amount of money for that third-party cloud. As there are multiple authoritative
domains, they require a certain kind of access to that central server, and the
question comes that system provides a guarantee that the data which is entered
by the USA post is not getting tampered with by the data which is being entered
by India post or vice versa.

Whenever there are multiple authoritative domains in the loop, there is a trust
relationship problem. That is why people do not go for any centralized server.

Premissioned Blockchain Architecture

For this kind of provenance tracking of assets, it is more beneficial to use the
permissioned blockchain environment and the beauty of the permissioned
blockchain environment is that it does not require to host any centralized server.
The individual would maintain the data, but everyone will be able to validate
other’s data.

The first typical use case was from the Supply Chain System, where goods are
transferred between the suppliers and distributors, distributors and vendors, and
vendors and retailers. In this scenario, we have multiple suppliers, distributors,
and vendors. Like every individual supplier, distributor, and the vendor has its
individual authoritative domain and follows its own policy of entering data. Still, a
third-party auditor should have access to this entire data. They should reliably
verify the correctness of data that is being passed through supplier distributor
vendor and the final in the market.

The second typical use case was from Postal services, where we know that the
posts/goods/couriers will either go from India to USA post or vise versa. So we
have a closed set of participants who are participating in the entire blockchain
environment. But still, the trust relationship is not there. To maintain a certain
kind of security or ensure that the data is not getting tampered with while
transferring from one authoritative domain to another authoritative domain.

However, why not permissionless architecture? We can also use the

permissionless model, but there are certain disadvantages of using the
permissionless model because we are going for an open environment. Whenever
we are going for an open environment, the network or system becomes more
complex. It has to handle many things all together, which is why we want to move
from a permissionless to a permissioned model.
Summary

We have seen permissioned blockchain architecture and different use cases

from Supply Chain System and another from International Postal Service.
Studies permissionless blockchain architecture is not suitable for these use
cases.

Design issues Challenges of Permissioned Solutions

Permissioned blockchains are not free from challenges. In fact, implementing
permissioned blockchain solutions can be a tough task. So, what makes it so
challenging? There are many challenges that it has to go through. Few of them include
data storage, messaging and integration, identity, smart contracts management, and so
on.
As a business, many decisions need to be made before starting a permissioned
network. For example,the company first needs to decide which blockchain platform to
use. They also need to determine the blockchain runtime to use. After all, answers to
these two questions will give them the development stack on which the development will
take place.

Let’s have a look at the challenges that one might come across while developing
permissioned solutions:

▪ Integration: One of the biggest challenges that a business or organization has to go

through integration challenges, especially when using APIs for communication. To make
it easy, you can use Rhombus, Chain Link, and Oraclize. They are great tools that will
help you connect and integrate services more efficiently.
▪ Data Privacy: Privacy is a big concern, especially when it comes to regulated industries.
To ensure proper privacy, they must meet specific requirements. Quorum and Aztec are a
good pick when it comes to developing permissioned blockchains that offer great privacy.
▪ Data Access: Accessing information in a permissioned blockchain can be slow
compared. The right solution is to use The Graph which can expose data to the APIs and
smart contracts for easy access.
▪ Data Storage: Data can be stored in many ways on a blockchain. However, not all of
them are optimal, considering that a huge amount of data is stored on the blockchain. To
ensure proper storage, it is advised to use data storage solutions such as IPFS Private
Network, Big chain DB, and AWS Quantum Ledger.
▪ Identity: The last challenge that we are going to discuss is the participant’s identity
problem. As it is permissioned network, the identity of the peers is already known, which
can cause issues during the consensus computations. To simplify the issue, it is advised to
use Azure BaaS or uPort that will help your business to better leverage their identity
protocols and solutions for decentralized applications.

Permissioned Blockchain – Smart Contracts

A smart contract is a self-executing contract and the contract terms between the two parties are written
directly in code or programable logic using some general-purpose, high-level programming language
rather than on paper documents. The blockchain environment facilitates the execution of these kinds of
contracts as similar to bitcoin scripts. However, the bitcoin script was simple as compared to the scripts
used in the smart contracts. Moreover, the bitcoin script concept is extended to execute complex types
of contract code in the blockchain environment.
Even the bitcoin script, apart from basic scripts like transfer bitcoins from sender to receiver, the sender
can also write a script in such a way so that the receiver will not able to spend the bitcoins immediately.
Rather, the bitcoins will become spendable only when the imposed condition is met.

Smart Contract

In the smart contract, generally, there are buyer, seller, assets, and contracts. A buyer is willing to buy
the asset which the seller possesses, and the contract is the agreement between the two. In general, a
certain script will be executed at the seller’s end whenever a buyer buys something, and similarly, a
certain script will be executed at the buyer’s ends.

Let us try to understand the smart contract with an example of an asset as ownership. Suppose the
buyer has sent a certain amount of currency to the seller, and the contract actually verifies that this
amount of money has been transferred from the buyer to the seller. Then, the seller sends the
ownership of that particular asset to the buyer. So in the future, the seller will not be able to claim
ownership of that asset. At the same time, the buyer will be able to claim his or her ownership of that
particular asset. This is the concept of smart contracts, which are executed in a closed environment with
the help of blockchain.

In a typical business platform, there is a limited number of buyers and sellers. The buyers and sellers can
always register at a central port so that everyone can know each other. But there may not be any trust
relationship between them, and most probably, it happens that some sellers are fraud. They are just
taking the money and not giving the asset to buyers. So these kinds of frauds or malicious activities in
the system can be prevented with the help of a permissioned blockchain.

Smart Contract Design Limitations

Sequential execution

The blockchain concept came from a permissionless environment, and the best use case is bitcoin
cryptocurrency. In bitcoin, the transactions are executed sequentially based on the consensus. If a
transaction gets verified and committed, that will be executed first, and the transaction committed later
will be executed next. Similarly, in the context of smart contracts, the request to the applications (i.e.,
smart contracts) are ordered by order of the consensus in which the individual application of the
contracts get a consensus, and they are executed in that particular order.

These sequential order types actually give the effective throughput and ensure that certain consensus or
ordering of transactions is made. We can apply “Proof of Work” based techniques in the permissionless
model where the network chooses a challenge, and the user tries to solve that particular challenge
individually. The nature of the challenge is that it is difficult to find a solution for that challenge, but
once a solution is found, everyone can verify it very easily. So with that particular challenge-response-
based method, the nodes try to come to a consensus.

The serializable order of transaction execution gives a bound on the effective throughput. If the
commitment latency gets increased, then throughput gets decreased. It is similar to if we increase the
difficulty of the challenge, the effective throughput will decrease. The throughput is defined as the
number of transactions committed per unit time. So the effective throughput is inversely proportional to
the commitment latency.

This can be a possible attack on the smart contract platform. The attacker introduces a contract that will
take a long time to execute, and that is why if a certain contract takes a huge time to execute, the other
contracts will not be able to execute further, as once the consensus for the previous contract has been
reached, then only other will be able to execute the contracts which are submitted later on.

Maintaining a serializable order of the transactions prevents you from executing a later contract until
the previous contract gets executed. If an attacker introduces a malicious contract in the system, which
will take a huge amount for execution, the attacker will launch a denial of service attack on the
consensus algorithm.

Non-deterministic execution

To implement a smart contract, we need to go to some programming language that gives us more
power than the bitcoin script. Bitcoin script is not turning complete language and does not support all
the constructs. For example, it does not support loops and has a certain limitation on execution.
However, to implement a smart contract, we need to increase the power of the script so that we can
write any general-purpose contract in the form of a code. Thus, we choose programming language
based on the requirements. One of the interesting languages is golang, and it has been used in the smart
contracts Ethereum platform.
For example, in golang, iteration over a map construct may produce a different order in two executions.
However, the smart contract execution is contrary; it should always need to be deterministic; otherwise,
the system may lead to a certain inconsistent state or may have many forks in the system. One
particular user executes the contract and gets one result or one order of result compared to another
user executes and gets another result. So if we are getting two different ordering of results, it may be
difficult for the system to ensure the longest chain in the blockchain.

Execution on all nodes

We execute the smart contract to all nodes and propagate the state to others; that way, it reaches a
consensus. To ensure consensus, the question is, do we have a sufficient number of trusted nodes to
validate the execution of the smart contracts. If the number of trusted nodes is less than the number of
malicious nodes, they may control the entire environment. However, it can be prevented by going to a
permissionless setting and use a Proof of Work-based consensus mechanism. But the major problem is
like we may be stuck to a particular block or a kind of starvation scenario where a contract is taking a
long time to execute, and all the contracts are getting backlog. So that is why we want to move from the
challenge response-based method to the traditional distributed system-based consensus algorithm in
this permission setting. But in that case, we have to ensure that you have a sufficient number of trusted
nodes in the system.

Do we really need to execute contracts at each node?

Indeed it is not necessary, and we need state synchronization across all the nodes. So, we execute the
contract in one node and propagate the state of the contract to the neighboring node, and those nodes
will propagate it further. That way, every node in the system gets the same states of the contract.

But a typical question comes that what if the node that executes the contract becomes faulty. The
system gets down, and it will not be able to make any progress further. In this scenario, the idea is to
use state machine replication and execute the contract at a subset of nodes to ensure that the same
state is propagated to all the nodes. This way, we can ensure that every node that is there is the part of
the smart contract they are on the same page. They know that list of contracts gets executed, and the
remaining part needs to be executed.

State machine replication is a powerful tool to ensure consensus in a permission blockchain

environment.
Summary

we have seen and try to understand it with a toy example of the Smart Contract concept, one of the
most popular use cases of permissioned model, along with smart contract design limitations.

Permissioned Blockchain – 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.

Understanding of State Machine Concept

State Machine is characterized by a set of parameters such as set of Inputs, set

of Outputs, and the Transition States.

• A set of state (S) based on the system design

• A set of inputs (I)
• A set of outputs (O)
• A transition function S x I –> S; takes the current state and input value and
produces a set as the output.
• A output function S x I –> O
• A start state

Example of State Machine: Smart Contract – Crowd-Funding

In general any algorithm can be represented by the finite state machine and we
will understand it with an example of Crowdfunding platform in smart contract.
The smart contract state machine representation are as follows:

In the crowdfunding platform, there are mainly two parties which include the
project proposes and project funders. The project proposers propose the project
to the funders, and if they are interested, they will invest money in their project.
The funders will release funds after the completion of a certain job. In the above
diagram, Alice and Bob are the two funders, and they are transferring money
after completing the proposed jobs by the proposers. Once the entire job is
completed, money will be transferred to them.

Distributed State Machine Replication Mechanism

In a typical distributed architecture, the distributed state machine replication

mechanism work in the following way.

It has multiple distributed servers which work independently in a distributed

fashion. Initially, copies of the state machine are placed on each server that
resides in the closed network, assume that each server knows the information
about other servers.
In the distributed setup, it may be possible that different users are communicating
to different servers. The servers get the client’s request independently. In our
example, Alice and Bob are two clients who are transferred their share of money
via the distributed network. However, at this moment, this information is locally
stored in the connected servers. The end goal is to ensure that all three servers
reach the same state after a certain time. i.e., Each server must have information
about Alice and Bob have transferred their share of the money.

To achieve this, the state machine replication mechanism works in this principle
that, individually, all the servers propagate their state to others. However the
problem is to understand ordering or sequences in which requests came from the
users.
This can be achieved using the timestamp concept. So, whenever Alice and Bob
are making the transactions, the transactions are associated with the timestamp.
This way, information will be executed in each server in that particular ordering
algorithm. Consequently, all will execute in the same order in which it was
support to be executed. This way, all servers are reaching the same state.

Once execution is finished, then the states should be propagated in the entire
network. It might be possible that one of the servers was offline due to some
failure. This way, all the servers will have a state copy. So that update is done
through synchronization of the state machine.
At the end, there will be certain outputs and those outputs will be updated to
clients.

In the entire procedure, there are two glitches. The first one is that we need to
maintain ordering in service, and the second is that in the presence of failure, the
system needs to ensure that all the individual servers are on the same page.
From our example, in the end, all the three servers must know that Alice and Bob
had shared their money, and money has been transferred to the recipient.

Why do we apply the state machine replication-based consensus

algorithm in a permissioned model compared to the challenge-response-
based consensus algorithm in the permissionless model?

There is a natural reason to use state machine replication-based consensus over

permissioned blockchains are there as follows:
 •The network is closed, the nodes know each other, so state replication is
possible among the known nodes.
• Avoid mining overhead, do not need to spend anything like power, time,
bitcoin other than message passing.
• However, the consensus is still required as machines can be faulty or
behave maliciously.
Summary

We have seen and understand with a toy example of state machine replication
consensus algorithm in the permissioned model, comparing why state machine
replication consensus algorithm is suitable in the permissioned model compared
to the challenge-response based consensus algorithm.

Overview of Consensus models for permissioned blockchain-Distributed consensus in closed

environment

Need for Distributed Consensus

If there is only a single decision-maker, we don’t need a consensus algorithm. In

the case of two decision-makers (nodes) and the presence of any faults such as
crash fault, or network fault or even if the node behaves maliciously, we can not
reach a consensus. To reach a consensus, we always require more than two
nodes or decision-makers.

In the case of multiple decision-makers, and collectively, they want to come to a

certain decision, and then we require a consensus algorithm. The distributed
consensus helps us to reach an agreement in the case of distributed computing.
In the case of the state machine replication concept, we replicate the common
status so that all the processes have the same view of the state.

Examples:

• State machine replication is the flight control system when there are
multiple flights. They want to coordinate their positions among themselves
in the closed distributed environment to achieve consensus.
• Fund transferring system in a closed distributed environment.
• Distributed leader election in a closed distributed environment where all
the nodes collectively need to elect one leader in the system.
Faults in Distributed Consensus
It is easy and trivial to reach a consensus in the absence of failures in the
distributed system. It is as simple as each node broadcasts the personal choice
to all and applies a choice function, say the maximum of all the values, and
achieves the common viewpoint or decision. However, it is challenging in the
presence of faults in a distributed system. These are various kinds of faults that
exist in the distributed system:

• Crash Fault: A node suddenly crashes or becomes unavailable in the

middle of communication. This may be because of hardware or software
faults due to which the node or the process is communicating with another
one gets disconnect or fail.
• Network or Partitioned Faults: A network fault occurs because of the link
failure, and the network gets partitioned. This may be because of the edge
router failures and, consequently, hamper reaching the consensus.
• Byzantine Faults: A node starts behaving maliciously. It is a kind of fault
that is very difficult to handle as the node’s behavior is unpredictable. It
also includes software and hardware faults.
The crash and network faults are expected and can be predicted using the
probabilistic models. However, Byzantine fault can be crafted with malicious
intent. Thus, it isn’t easy to guess to apply suitable remedies. So the consensus
protocols have to deal with these three kinds of faults in the distributed
ecosystem.

Requirements of Consensus Algorithms

The distributed consensus protocols need to satisfy certain properties, and these
are as follows:

• Termination: Every correct individual decides some value at the end of

the consensus protocol. It means whoever are the non-faulty nodes in the
network terminates the consensus protocol at the end and decides on one
value, and that value must be the correct value.
• Validity: If all the individuals propose the same value, then all correct
individuals decide on that value – This is the basic idea of validity property.
• Integrity: Every correct individual decides at most one value, and some
individuals must propose the decided value. The integrity property ensures
that the consensus value should not deviate from the value individuals in
the network propose.
• Agreement: Every correct or non-faulty individual must agree on the same
value.
Whenever they agreed on the same value after termination, we call that the
system has reached the consensus.
Popular Distributed Consensus Algorithms

There are various consensus algorithms that the distributed system community
has explored, and the most famous are as follows:

• Crash or Network Faults:

• PAXOS
• RAFT
• Byzantine Fault (including Crash or Network Failures):
• Byzantine fault tolerance (BFT)
• Practical Byzantine Fault Tolerance (PBFT)
Correctness of a Distributed Consensus Algorithms

These two properties can characterize the correctness of a distributed consensus

algorithms:

• Safety: Correct individuals must not agree on an incorrect value. It means

nothing bad will happen in the system. This property ensures that the
system will never convert to an incorrect value or the correct individuals in
the network will never convert to an incorrect value.
• Liveliness: Every correct value must be accepted eventually. It means
something good eventually happens. If someone is proposing some good
values, that good value will be committed eventually. Although, there can
be some time lag or delay in reaching the consensus. But after the
consensus protocol terminates, expected to have a correct consensus
value.
These two correctness properties for a distributed consensus algorithm need to
ensure whenever we design a distributed consensus algorithms.
Permissioned Blockchain – Simplified view
of Paxos Consensus Algorithm
It was the first consensus algorithm proposed by L. Lamport in 1989. The
objective was to choose a single value under the crash or network faults. We will
look into the Paxos in a simplified view, and later we will try to understand how it
can be implemented in a real system to ensure consensus.

The main idea behind the Paxos consensus algorithm is straightforward, and we
will understand it with an example. Let us consider that we are at the college and
after classes, we are going to hang out all together. We have two options to hang
out with classmates after classes: Subway and Coffee Cafe Day (CCD). So after
classes, we can either go to Subway or CCD based on the collective decision,
but everyone will go to the same place. In this case, there is no central leader.
The only way to take a collective decision is that a few of them (in this case, max
could be the two students) will propose an option (i.e., CCS or Subway). Others
will either accept or reject that proposed option, and the majority count will be the
final value, which will be the consensus.

Paxos: Types of Nodes

There is a certain terminology used in PAXOS, and there are as follows: There
are three types of nodes, the proposer, acceptor, and learner. However,
everyone is a learner in the network who learns what the majority decision is.
Permissioned Blockchain – Raft Consensus
The idea behind the Raft consensus algorithm is that the nodes (i.e., server
computers) collectively select a leader, and the remaining nodes become the
followers. The leader is responsible for state transition log replication across the
followers under the closed distributed environment, assuming that all the nodes
are trustworthy and have no malicious intent.

The basic idea of Raft came from the fact that in a distributed environment, we
can come to a consensus based on the Paxos algorithm and elect a leader.
Interestingly, if we have a leader in the system, we can avoid multiple proposers
proposing something altogether.

In the case of Paxos, we don’t have any straightforward mechanism to elect a

leader. However, to elect a leader, multiple proposers propose the thing
simultaneously. Consequently, the protocol becomes complex, and the acceptors
have to accept one of the proposals from the proposer. In that case, we use the
highest proposal number for the tie-breaking mechanism and embed a certain
algorithm in Paxos to ensure that every proposal coming from a different
proposer is unique. Thus, all these internal details make the Paxos more
complicated.

In a distributed environment and under a synchronous assumption (closed

environment), it is possible to design a consensus algorithm. First, we will elect a
leader and then the tasks of the leader to propose something. There will be a
single proposer, and all the acceptors are followers of the leader. They may
either accept or reject the leader’s opinion.

Raft Overview

The system starts up and has a set of follower nodes. The follower nodes look for
a leader. If a timeout happens, there is no leader, and there is a need to elect a
leader in the system. A few candidates stand for a leader in the election process,
and the remaining nodes vote for the candidate. The candidates who receive the
majority votes become the leader. The leader proposes a proposal, and the
followers can either vote for or against that proposal.
Raft consensus algo

An example from the database replication: We have distributed multiple

replicated servers, and we want to build a consensus among these multiple
replicated servers. Whenever some transactions are coming up from the clients,
we want these replicated servers to decide whether to commit those transactions
collectively.

Raft Consensus Algorithm

Electing the Leader: Voting Request

The first part of the Raft is to elect a leader, and for that, there should be some
leader candidates. The nodes sense the network, and if there is no leader
candidate, then one of the nodes will announce that I want to be a leader. The
leader candidate requests the votes. This voting request contains 2 parameters:

• Team: The last calculated number known to candidate + 1.

• Index: Committed transactions available to the candidate.
These algorithms work in multiple rounds, and the term indicates a new voting
round. If the last voting finishes, then the next term will be old term number + 1;
The index indicates committed transactions available to the candidate. It is just
like an increasing number to distinguish between already committed and new
transactions.

Electing the Leader: Follower Node’s Decision Making

Once the nodes receive a voting request, their task is to vote pro or against the
candidate. So, this is the mechanism to elect a leader in the Raft consensus
algorithm. Each node compares the received term and index with the
corresponding current known values.
 • The node(i) receives the voting request. It compares the already seen
team with the newly received team. If a newly received team is less than
the already seen team, then it discards because the node considers this
request as an old request.
• The newly received team is greater than the already seen team. It checks
for the newly received index number with the already seen index number.
If the newly received index number is greater than already seen, it votes
for the candidate; else, it declines.
Electing the Leader: Majority Voting

Every node sends their vote and candidates who get majority vote becomes a
leader, and commit the corresponding log entry. in other words, If a certain
leader candidate, receives majority of the vote from the nodes, then that
particular candidate becomes a leader and other becomes the follower of that
node.
Multiple Leader Candidates: Current Leader Failure

Let us understand a scenario where there is a leader, and three followers and the
current team is 10, and the commit index value is 100. Suppose the leader node
has failed or followers didn’t receive a heartbeat message within the heartbeat
timeout period.
After the timeout, one of the nodes will become a leader candidate, initiates a
leader election, and becomes a new leader with team 11 and commit index value
100. The new leader periodically sends the heartbeat message to everyone to
indicate his presence.
In the meantime, the old leader gets recovered, and he also receives a heartbeat
message from the new leader. The old leader understands that a new term has
started. Then the old leader will change his status from leader to follower. So this
is the one way to handling a new leader by utilizing the team parameter.
Multiple Leader Candidates: Simultaneous Request Vote

Let us understand a scenario where there is a leader, and three followers and the
current team is 20, and the commit index value is 200. Suppose the leader node
has failed or followers didn’t receive a heartbeat message within the heartbeat
timeout period. It may be possible that multiple followers sense the timeout
period simultaneously and become a leader candidate, and initiates the leader
election procedure independently. Two nodes send the request messages with
team 21 at the same time in the network.
There are two leader candidates, and both are sending voting request messages,
at the same time, for round (term) 21. Then, they look for the majority voting. In
this example, the first candidate receives two votes, and the second candidate
receives one vote, so based on the majority voting, the first candidate is a
winner.
The node which gets the majority votes send a heartbeat message to everyone.
Another leader candidate also received the heartbeat message from the winner,
and this leader candidate falls back to a follower from the leader candidate.

Committing Entry Log

In the above sections, we have seen the procedure to elect a leader and other
special cases. Now we will understand how the transactions are managed in a
closed distributed environment. Let us consider that the current term value is 10,
and the index value is 100, which means most of the nodes have seen and
committed transaction index value number 100.
The leader proposes a new transaction, adds an entry log with term 10 and the
new transaction index value as 101. Further, the leader sends a message called
append entries to all the followers, and they collectively vote either for or against
this transaction.
The leader receives the vote for this transaction index value 101. The followers’
node votes for or against this transaction. If the majority says that they are fine
with committing this particular log. Then, the leader considers that the transaction
log is approved by the followers.
After successful acceptance of the entry log, the leader sends an accept
message based on the majority voting to all the individual followers to update the
committed index to 101.
Handling Failure

Multiple kinds of failures exist in the environment. However, Paxos and Raft
consensus algorithms only support Crash or Network fault. The followers may
have crashed, but the system can tolerate up to N/2 -1, where N is the total
number of nodes in the environment, as it does not affect the system due to the
majority voting. This indicates that the majority of the followers are non-faulty,
and they can send a vote. The leader can take the majority decision whether to
accept or reject a particular transaction.
PAXOS – Type of nodes
 • Proposer: The proposer proposes values, and the consensus algorithm
should choose that proposed values.
• Acceptor: They form the consensus and accept the values. Whenever
they hear a certain proposal from the proposer, the acceptors either accept
or reject the proposal.
• Learner: This learner will determine which value has been chosen by each
acceptor and collectively accept that particular value.
Making a Proposal: Proposer Process

The proposer initially prepares a proposal number so that this number needs to
be good enough for the proposal to be accepted by the acceptors. The proposal
number forms a timeline, and the biggest number considered up to date.

For example, there are two proposers P1 and P2, and P1 and P2 proposed
values are 100 and 101. The acceptor always accepts a bigger proposal number,
so in this case, it is P2 rather than P1.

Making a Proposal: Acceptor’s Decision Making

If the received proposal number is less or equal to the already seen or received
proposal number, then it rejects else it accepts. It means the acceptor compares
the recently received proposal number with the currently known values for all
proposer’s received messages. If it gets the higher number, then it accepts;
otherwise, it rejects.

Making a Proposal: Acceptor’s Message

Acceptor prepares the response, including accept or decline status, biggest

proposal number, and accepted values. The acceptor can either accept or reject
a message based on the proposed algorithm. The acceptor includes the biggest
number that the acceptor has seen in the response message. It also includes the
values that the acceptor has accepted to inform the proposer.
Accepting a value: Proposer’s Decision Making

The proposer looks for the response’s status, whether the majority of the
acceptors reject/accept the proposal. If they have rejected the proposal, then the
proposer updates with the latest proposal number. However, if most acceptors
have accepted values, then the proposer cannot be chosen this value. In other
cases, like the majority of acceptors accepted the proposal and this value was
not chosen, then the proposer sends accept messages to others.
The basic idea is that whenever the majority of the acceptors send to accept the
response. It means the value that the proposer has shared that is coming to be a
consensus.

Accepting a Value: Accept Message

The final stage is accept message, the proposer sends the accept message to all
the acceptors and in the accept message, the proposer includes the proposal
number. A similar to the prepare phase, the proposal knows that his proposal has
been accepted, and the value is the proposal’s single value.

Accepting a Value: Notifying Learner

Whenever the acceptor accepts a value from the proposer, it informs the learner
about this is the majority voted value. So everyone learns that what is the
majority voting in the environment.
Single Proposer: No Rejection

If there is a single proposal in the system, then the system is very simple, and
with a single proposal, every acceptor will accept the proposal because that will
be the biggest. So the proposal does not get rejected if the acceptors are correct.
So we have to ensure that majority of acceptors are non-faulty.
Handling Failure: Acceptor Failure

Whenever a certain acceptor fails during the prepare phase, the system does not
have any issue as the other acceptors can listen and vote either for or against
the proposal. If the acceptor fails during the accept stage, the system does not
have any issue because other acceptors are there who have already voted for
the proposal. The only thing to ensure that the not more than N/2 number of
acceptors fails simultaneously in the system. If that happens, then that violates
the majority voting principle, and the system cannot come to a consensus.
Handling Failure: Proposer Failure

We will understand what happens when the proposer fails during the prepare
phase or accept phase. If the proposer fails during the prepare phase, it is just
like no one is proposing for any value, so the acceptor will keep on waiting for the
state, and if they are not getting any value, others will become a proposer. It
means, the acceptor waits for a certain duration, and if they do not receive any
proposal, one of the acceptor becomes the proposal and propose a new value.

Suppose the proposal fails during the accept phase, the acceptors who have
already agreed upon whether to choose or not choose the proposal value based
on the majority vote. As they have already shared the majority vote among
themselves, and from there, they can find out that whether the proposal has been
accepted or not by the proposer.
Handling Failure: Dueling Proposers

There can be an interesting attack, which we called the dueling proposal. Let us
consider, there are two proposals and the first proposer has sent a certain
proposal to all the acceptors. Later, the second proposer has sent another
proposal with the higher proposal number to all the acceptors. Again, the first
proposer (an attacker) sees a proposal with a higher proposal number, and then
she sent a higher proposal number. So it is like that whenever she sees that any
other proposer has sent a proposal higher than her proposal number, she
chooses a higher proposal number and sent to all the acceptors.

To break this tie, what other acceptors do, they block the proposer with a lower
height. To do this, which particular proposer has a lower height, we need to
execute a certain algorithm. We have a leader election algorithm. So this leader
election algorithm can select one of the proposers as a leader as the Paxos is a
consensus algorithm. Paxos itself can be used as a leader election algorithm.
The overall idea is that the proposer is proposing a certain opinion to all the
acceptors and acceptors collectively look into the proposal. If they agree with the
proposal, they send the accept message and receive that particular accept
message. If the proposer finds out that his message has been accepted, then he
sends back the accept message to all other acceptors. And from there, through
the majority voting, they come to a consensus protocol.

The simple view of the Paxos is easier to understand, it is just like making one
selection, but if we look into the real system, we may go for a sequence of
selection choices rather than having a single choice. So that kind of system we
call a multi-Paxos system. This multi Paxos system is something like make a
sequence of choices by applying repeated Paxos protocol.

Applying repeated Paxos is something complicated because have all these

messages need to be exchanged among each other again and again and which
increases the complexity of the Paxos protocol so that is why although the Paxos
gives a nice theoretical idea about why the system can reach a consensus, or
how are distributed system can lead to a consensus. Indeed this Paxos protocol
was the first that has proved that you can have a certain consensus algorithm in
a distributed environment.

By applying this kind of proposal and acceptors accepting certain values, you can
do a certain level of optimizations on top of this repeated Paxos, which is
basically done in the case of multi Paxos to come to a consensus.

Permissioned Blockchain – Paxos Vs. Raft

Consensus Algorithm
The idea of Paxos was difficult to prove because the individual nodes propose
certain values and the acceptors accept those values. However, there is no
leader in the system, and individual nodes need to wait for a certain amount of
time to see whether someone is proposing a value. If none of them proposes a
value or timeout, then one of the nodes proposes a value, and the remaining
nodes may accept or reject the proposal. If the node is getting a majority voting,
then that node knows that its proposal is being accepted, and then it sends the
accept message to all the nodes. If there are multiple proposers in the system, it
becomes difficult to theoretically prove that the repeated execution of Paxos,
which is called a multi-Paxos protocol, can achieve consensus in the closed
distributed system.

When the Paxos designed, there was no leader concept because electing a
leader requires a consensus algorithm. But, once the system has a leader, the
entire system becomes streamline. The Raft algorithm improved the concept
proposed in Paxos. It is like, rather than going for repeated Paxos or multi Paxos,
it preferred leader election based on the majority voting.

In Raft, it first runs a Paxos type of algorithm to elect a leader. But, once a leader
is elected, the elected leader can execute a series of transactions until either
leader dies or fails. However, in Paxos, the multi-Paxos algorithm needs to run
for consensus for executing each transaction.

The Raft consensus algorithm has improved the concept of leader election and
made it easy to understand and easy to prove theoretically.