3.

Permissioned Blockchain
 Permissioned model
 Permissioned blockchains are blockchains that are closed (i.e., not
publicly accessible) or have an access control layer.
 This additional layer of security means that the blockchain can only
be accessed by users with permissions. Permissioned users are only
able to perform blockchain operations within the strict confines of
roles assigned to them by the ledger administrators and require that
they authenticate themselves through certificates or digital identifier
methods. In addition, the roles would dictate what information a user
would be able to access.
Aspects of a permissioned blockchain

 Decisions are authorized by a private group

Decisions are made by the owners of the network through a central, pre-defined level.
 Security
Permissioned blockchains provide the operating organization granular control over permissions,
data access, and the scope of user roles.
 Decentralization isn’t fixed
Permissioned blockchains can either be fully centralized or partially decentralized. Its members
typically decide on the network’s level of decentralization and the mechanisms for consensus.
 Transparency is not required
Unlike permissionless blockchains, permissioned blockchains do not need to be
transparent. Transparency is optional, as most permissioned blockchain networks
are specifically intended to not be transparent for security purposes. Levels of
transparency usually depend on the goals of the organization running the
blockchain network.
In the meantime, the ledger maintains a record of every transaction and the
identities of the participating parties.
 Lack of anonymity
Access to the identify of every transactional participant can be crucial
information for private entities concerned with accountability and a provable
chain of custody. Every change is tracked to a specific user, so network
administrators can have instantaneous access to has made a change to the system
and when.
 Advantages of permissioned blockchains

•Security
•Flexibility of Decentralization
•Performance
 Disadvantages of permissioned
blockchains
•Not truly decentralized as it requires permission
•Risk of corruption as only a few participants are
involved.
•Anytime owner and operator can change the rules as
per their need.
 state machine replication-
state machine replication- execute the contract at a subset
of nodes and ensure that the same state is propagated to all
the nodes.
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
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.
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
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.
 Paxos
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. Consensus is achieved when a
majority of the computers running Paxos agrees on one of the proposed
values.
In general terms, Paxos selects a single value from one or more of the
values that are proposed, and then broadcasts that value to all of the
cooperating computers. Once the Paxos algorithm has run, all of the
computers (or database nodes)) agree upon the proposed value, and the
cluster clocks forward.
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.
•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.
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.
 Raft consensus algorithm

Raft is a distributed consensus algorithm. It was designed to be easily

understood. It solves the problem of getting multiple servers to agree
on a shared state even in the face of failures. The shared status is
usually a data structure supported by a replicated log. We need the
system to be fully operational as long as a majority of the servers are
up.
Raft works by electing a leader in the cluster. The leader is
responsible for accepting client requests and managing the
replication of the log to other servers. The data flows only in one
direction: from leader to other servers.
 Raft decomposes consensus into three sub-problems:
•Leader Election: A new leader needs to be elected in case of the
failure of an existing one.
•Log replication: The leader needs to keep the logs of all servers in
sync with its own through replication.
•Safety: If one of the servers has committed a log entry at a particular
index, no other server can apply a different log entry for that index.
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
 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.
 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:
•Term: 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

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.
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.
 Byzantine generals Problem
The concept of BFT has a promising relationship with military
tactics in a scenario where different Byzantine generals gather
around an enemy city before attacking it. Some of the notable
highlights of the Byzantine General’s Problem could help in
understanding the actual work of the Byzantine Fault
Tolerance consensus.
1.The different Byzantine generals command their respective
units at different positions outside the city they are about to
attack.
2.The generals can communicate with each other through
messengers, sending one message at a time.
1.The Byzantine generals must have coordination and agreement
on a particular plan of action for successfully attacking or
retreating.
2.If all the generals attack at the same time or all of them retreat at
the same time, there is no problem. However, if one general
retreats while others attack or attack while the others retreat, the
general would end up losing. Therefore, the outcome will be bad
for all of the generals and their units.
3.Another important point in the Byzantine General’s Problem is
the fact that some of the generals are not loyal. These generals
could try sending the wrong or manipulated information to other
generals for confusing them.
Byzantine Fault Tolerance(BFT)
Byzantine Fault Tolerance(BFT) is the feature of a
distributed network to reach consensus(agreement on
the same value) even when some of the nodes in the
network fail to respond or respond with incorrect
information. The objective of a BFT mechanism is to
safeguard against the system failures by employing
collective decision making(both – correct and faulty
nodes) which aims to reduce to influence of the faulty
nodes. BFT is derived from Byzantine Generals’
Problem.
 Byzantine Fault Tolerance
In an attempt to overcome the Byzantine problems, Barbara Liskov
and Miguel Castro introduced a Practical Byzantine Fault Tolerance
(pBFT) consensus algorithm in 1999. They aim to ensure a
practical byzantine state machine replication for tolerating
malicious or byzantine nodes.
The pBFT follows an asynchronous approach. The following are
essential aspects of the pBFT consensus algorithm:
•All nodes are assembled in a sequence.
•One network node serves as a leader node, and the rest of them
are backup nodes.
•The primary or leader node serves the client’s request. It works as a
moderator between client and backup nodes.
•All nodes are capable of communicating with other nodes to check
the honest nodes.
•Honest nodes should be able to reach a consensus for the next global
change in the network based on majority rule.
•It identifies the source of the message to make sure it’s sent by the
correct sender.
•Ensures the message has not been modified or corrupted in between.
 pBFT work

pBFT tries to provide a practical Byzantine state machine replication

that can work even when malicious nodes are operating in the
system.
Nodes in a pBFT-enabled distributed system are sequentially ordered,
with one node being the primary (or the leader node) and others
referred to as secondary (or the backup nodes). Note here that any
eligible node in the system can become the primary by transitioning
from secondary to primary (typically, in the case of a primary node
failure). The goal is that all honest nodes help in reaching a
consensus regarding the state of the system using the majority rule.
A practical Byzantine Fault Tolerant system can function on the
condition that the maximum number of malicious nodes must not be
greater than or equal to one third of all the nodes in the system. As
the number of nodes increases, the system becomes more secure.
pBFT consensus rounds are broken into 4 phases
• The client sends a request to the primary (leader) node.
•The primary (leader) node broadcasts the request to all the secondary
(backup) nodes.
•The nodes (primary and secondary) perform the service requested and
then send back a reply to the client.
•The request is served successfully when the client receives 'm+1'
replies from different nodes in the network with the same result, where
m is the maximum number of faulty nodes allowed.