⚫ [Unit 3]

⚫ Permissioned Blockchain Consensus

⚫ Permissioned Blockchain
⚫ These are the closed network only a set of groups are allowed to
validate transactions or data in a given blockchain network.
⚫ These are used in the network where high privacy and
security are required.

⚫ Characteristics:
⚫ A major feature is a transparency based
on the objective of the organization.
⚫ Another feature is the lack of anatomy
as only a limited number of users are
allowed.
⚫ It does not have a central authority.
⚫ Developed by private authority.
Unit – 3 Permissioned BC Consensus
⚫ Permissioned Blockchain
⚫ There is a central authority responsible for issuing licenses to
participate in the network.
⚫ This authority may or may not grant equal rights to participating
nodes, but in any case only authorized entities will have access to
the records contained in the ledger.
⚫ As permissioned blockchains usually have a restricted number of
participants, and as the consensus mechanism is more centralized,
they are able to process a larger number of transactions in less time
compared to a public blockchain.
⚫ However, since records cannot be independently verified, their
integrity will depend solely on the credibility of the participants —
meaning that they need to trust each other.
⚫Permissioned Model:
⚫A blockchain architecture where users are authenticated
apriroy.
⚫Users know each other
⚫However, users may not trust each other – security and
consensus are still required.
⚫Run blockchain among known and identified
participants.
⚫Permissioned Model:
⚫A blockchain application or application of public ledgers
where it have certain no. of nodes which is a kind of
closed environment, so the nodes which knows each other
and they tries to come to common platform where there
is no such centralized database or data server rather still
want a complete decentralized architecture,
⚫But the difference is that now rather than having
complete open environment, it have closed
environment.
⚫The set of nodes which knows each other apriory but they
may not trust each other such type of particular setting is
a permissioned model environment.
⚫ Permissioned Blockchain
⚫ Advantages:
⚫ This blockchain tends to be faster as it has some nodes for
validations.
⚫ They can offer customizability.
⚫ Strong Privacy as permission is needed for accessing
transaction information.
⚫ As few nodes are involved performance and scalability are increased.

⚫ Disadvantages:
⚫ 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.
⚫ Permissioned Blockchain
⚫ Use Cases:
⚫ With proper security and maintenance, this blockchain is a great
asset to secure information without exposing it to the public eye.
⚫ Therefore companies use them for internal auditing, voting, and
asset management.
⚫ An example of permissioned blockchains is Hyperledger, Corda.
⚫ Permissioned blockchains are generally used to manage
⚫ supply chains,
⚫ create contracts,
⚫ Particularly interesting for business applications – execute
certain contracts among a closed set of participants.
⚫ verify payment between parties, and much more…
⚫ Permissioned Blockchain
⚫ Use Cases:
⚫ Financial Services:
⚫ Trade Finance:Trade finance provides delivery and payment
assurance to buyers and sellers.
⚫ The blockchain can be used by the legal entities to sign all
approvals, keeping all parties informed regarding the approval
status, when goods are received and when payment is transferred
from the importer’s to the exporter’s bank.
⚫ Cross-border transactions: Nostro(ours)/vostro(yours) accounts
can become stored account transactions on a blockchain to
dramatically improve transparency and efficiency through
automated reconciliation of accounts.
⚫ Permissioned Blockchain
⚫ Government:
⚫ A considerable amount of government involves recording
transactions and tracking ownership of assets, all of which can be
made more efficient and transparent through the use of blockchain.
⚫ Organisations can apply blockchain by issuing digitally
authenticated birth certificates that are unforgeable, time-
stamped, and accessible to anyone in the world.
⚫ Health Care:
⚫ Blockchain holds the complete medical history for each patient,
with multiple granularities of control by the patient, doctors,
regulators, hospitals, insurers, and so on, providing a secure
mechanism to record and maintain comprehensive medical
histories for every patient.
⚫ Permissioned Blockchain
⚫ Supply Chain Management:
⚫ Food Safety: Powered by IBM Blockchain, IBM FoodTrust directly
connects participants through a permissioned, permanent, and
shared record of food origin details, processing data, shipping
details, and more.
⚫ Global Trade: More than $4 trillion in goods are shipped each year,
with 80 percent of those shipments carried by the ocean shipping
industry.
⚫ Yet the cost of trade documentation is estimated to reach one-fifth
of the actual physical transportation costs.
⚫ Blockchain’s distributed ledger technology to help speed goods on
their journey from manufacturer to market, providing one
universal view of the truth to unleash new transparency & remove
friction.
⚫ Design issues for Permissioned blockchain :
⚫ BGP (Byzantine General Protocols) protocols such as PBFT
provide consensus mechanisms in permissioned BCs.
⚫ A BGP protocol allows the network to detect the behavior of
malicious nodes, and all working nodes can reach a consensus if the
number of compromised node is less than one-third of the total
number of nodes, or n >= 3f +1 where n is the number of nodes
and f is the number of compromised nodes.
⚫ PBFT has three phases, and each node maintains its own view
of the network.
⚫ The protocol is initiated by a leader in the network. Even if the
leader failed, other nodes take over the responsibility and resume
the operation.
⚫ Design issues for Permissioned blockchain :

⚫ A simplified 3-phase process is as follows:

⚫ A leader sends out pre-prepare message to all the nodes;
⚫ Each node received the message will produce a response, and
send the response, i.e., prepare, to every node;

⚫ After receiving sufficient such as 2/3 prepare messages from the

nodes, each can commit to the agreement, and send out the
commit message to everyone.
⚫ Thus, to reach a consensus, there will be three rounds of
messaging, one for each pre-prepare, prepare, and commit
message.
⚫ Design issues for Permissioned blockchain :
⚫ The PBFT is more complicated as it also handles the case when a
leader is crashed.

⚫ In permissioned BCs, a Byzantine consensus will be needed only

when a new block is to be created, and all working nodes need to
agree with the contents of the new block.

⚫ However, for an enterprise system, due to asynchronous message

arrival and large volume of data, each node may receive different
messages since the previous block creation, and thus it can be
difficult for all the nodes to agree with all the contents of the new
block even if the nodes are working properly.
⚫ Design issues for Permissioned blockchain :
⚫ If the system has few transactions per second, this is not an issue, but this
is an issue for an enterprise system. Thus, the goal of consensus protocol
is modified as follows:
⚫ 1. Most of working nodes can reach a consensus on most of items in a
new block;
⚫ 2. Detection of those failed nodes so that they can be safely ignored
during consensus building;
⚫ 3. Detection of those compromised nodes that sent out different
messages to different nodes to disrupt the operation;
⚫ 4. Those items that should be in the BC, but not voted in the current
block, will be placed in the next block to be voted in the future;
⚫ 5. Those items that should not be in the BC should be clearly identified
and should not be placed in a queue to be considered in the next block.
⚫ Design issues for Permissioned blockchain :
⚫ Issue 1 is a relaxed version of a common BC.
⚫ Instead of having identical contents, one can allow each node to
have slightly different contents in a new block yet to be voted on.
⚫ This is to allow each node to receive different messages from different
sources due to asynchronous messaging. However, as a part of the
voting process, all working nodes must decide on the contents of the
new block.
⚫ In this way, after voting, all the nodes will have identical content in
the newly created block.
⚫ Issue 2 is important in a permissioned BC as failed nodes should not
be involved in future voting until they are fully recovered.The
recovered node also needs to retrieve any missing data during the
absent period.
⚫ Design issues for Permissioned blockchain:
⚫ Issue 3 is important as compromised nodes should not be
involved as a compromised node can cause significant troubles
for a BC.
⚫ In fact, they should be excluded from the BC operation completely
as soon as they are identified as the damage done by compromised
nodes is far greater than the damage done by failed nodes.
⚫ Issue 4 is a new problem in a Permissioned BC as each second
numerous data may enter the BC, and those valid data must be
stored to maintain the trust of the BC.
⚫ For example, a lottery machine may send out ticket
information to a Permissioned BC.
⚫ Due to message delays, some messages did not get into every
node, and they were not included in the new block.
⚫ Design issues for Permissioned blockchain:

⚫ As they are valid tickets, they should be stored in the next block.
⚫ This scenario is considered as false negative as a valid
message was excluded due to various reasons.
⚫ Issue 5 is a new problem due to Issue 4 as data not included in the
previous block can be included in the next new block to be created,
thus potentially an increasing number of data can be postponed and
continued to be considered for inclusion.
⚫ But some of these data may not be valid at all, and should be
removed for good rather than to be re-considered in future blocks.
⚫ This scenario is considered as false positive as invalid messages
continued to be considered in block creation.
⚫ Execute contracts :
⚫ Smart contract is a self executing contract in which the terms of
the agreement between the buyer and the seller is directly
written into the lines of code.
⚫ It is like that you can not use the pen and paper to write
down the contract rather the entire contract is written inside
the code.
⚫ The question comes that how this type of contract may get
executed or how a blockchain can help you to execute this type of
contracts.
⚫ Remember the bitcoin scripts – According to concept of bitcoin
script, It is certain small code through which you can change the
control on how the money that you are transferring to someone
that will be spend latter on.
⚫ Execute contracts :
⚫ So by writing the rules into the bitcoin script where there is input
script and output script and our task could be to map the output of the
previous transaction to the input of the next transaction which will
give you an
⚫ Idea or verifiable way of finding out how the bitcoin that you are
transferring to your friend or how the bitcoin that you are transferring
to your client that is going to be used latter on.
⚫ You can write the script where Your friend can use that money
immediately or
⚫ At the same time we have seen that you can write a script inside bitcoin
where you can prevent your friend to use that money for 2 months.
⚫ It is just like that whenever this 2 months pipeline duration gets over
your friend will be able to use that particular bitcoin for further
transactions.
⚫ Execute contracts :
⚫ In case of smart contract this idea is expand further where it is not
like that some small simple scripts which are been used by bitcoin
rather with detailed that script through some general purpose
programming language can execute complex type of contracts
like if certain conditions are met then only this particular bitcoin
will be spendable.
⚫ So if that friend meets certain condition or if some environment
condition that can comes from the other third parties they gets
validated or they made, only during that time the contract will get
executed and it will be used further or the money can be used
further after all these conditions get verified.
⚫ Execute contracts :
⚫ So the concept of smart contract comes from this fact like
⚫ You can extend this simple script which is used in bitcoin to ensure
smart contract execution
⚫ -- Execute a transaction only when certain condition is satisfied
⚫ Execute contracts :
⚫ Example:
⚫ You execute a transaction when certain condition is satisfied.
⚫ So you have a seller, you have a buyer and you have certain assets and the
contract mix the match with the buyer and seller now whenever you are
buying something there are certain scripts that will be executed at the
seller side and there will be certain scripts that will be executed at the
buyer side. So, whenever someone is selling something they have a
contract like if I get this much amount of money then I can transfer the
⚫ Execute contracts :
⚫ Example:
⚫ Assets from myself to you and the buyer the idea is that the moment I
have transferred this much of money the asset should be in my hand
within certain duration. So you can write a contract to ensure this kind
of environment. So, it is like that the moment the buyer transfers the
money to the seller, the ownership of the asset goes from the seller to
the buyer and the code that you have written that particular code
actually validate whether the
⚫ Execute contracts :
⚫ buyer has transferred that certain amount of money. In general you can
think of in terms of bitcoin or any type of digital currency, It is like that
the moment the buyer has send that certain amount of currency to the
seller and the contract actually verifies that well this amount of money
has been transferred from the buyer to the seller and then it sends the
ownership of that particular asset from the seller to the buyer. So the
seller will not be able to claim the ownership on that asset any further
whereas the buyer will be able to claim his or her ownership on that
particular asset. So, that is the concept of smart contract which we can
execute in closed environment
with the help of blockchain.
so here the fact is that in a
typical business platform you
have fixed number of sellers
⚫ Execute contracts :
⚫ Example:
⚫ Or fixed number of buyers or you can say that there are limited
numbers of buyers and sellers in the market and the buyers and
sellers can always register to a central portal so that everyone can
know each other.
⚫ So, we are making an insurance that everyone knows each other.The
buyer knows the seller and the seller knows the buyer, but there
may not be any trust relationship between them. It may happened
that some seller is fraud and that seller it is just taking the money
and not giving the asset to you.
⚫ So, that kind of fraud, that kind of malicious activities in the
systems we want to prevent with the help of the permissioned
blockchain.
⚫ Design Limitations:
⚫ Let us look into, many of the design limitations which are
there in permissioned environment.
⚫ So, if you look into the blockchain concept which actually comes
from the typical permission less environment like a bitcoin type
of example,
⚫ There is one issue that we execute the transaction sequentially
based on the consensus.
⚫ So, it is like that if certain transaction gets verified or if it gets
committed that will first executed and the transaction that is
committed latter on, that will executed next.
⚫ So, the request to the application, application here of the smart
contracts, they are ordered by the order of the consensus in which
the individual application of the individual contracts get a
consensus and they are executed in that particular order.
⚫ Design Limitations:
⚫ So, these kind of sequential order actually gives a bound on the
effective throughput because you want to ensure that certain
consensus or certain ordering of transactions are made.
⚫ We apply that proof of work base techniques in case of
permission less model where the network or the system gives the
challenge to the individual users.
⚫ Every user tries to solve that particular challenge individually and
the nature of the challenge is such that it is difficult to find out the
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 the consensus, but as we have seen like the challenge
is very hard.
⚫ Design Limitations:
⚫ As the challenge is taking certain time to get a solution and that is the
reason that if you want this kind of serializable order of transactions
execution you get a bound on the effective throughput.
⚫ So, ideally the throughput is inversely proportional to the commitment
latency. So it is like that if your commitment latency gets increased, your
throughput will get then decreased.
⚫ So it is like that in a permission less environment in a bitcoin type of
environment if you increase the difficulty of your challenge or if you
increase the complexity of your challenge the effective throughput that
you will get that (throughput here in terms of no. of transactions that can
be committed per second per unit time), So the effective throughput that
you will get it will drop inversely proportional to the commitment
latency so this can be a possible attack on the smart contract platform.
⚫ Design Limitations:
⚫ When you introduced contract, it will and which will take long
time to execute and that is why if certain contract take huge time to
execute, the other contracts will not able to execute in further,
because once the consensus for the previous contract has been
reached then only you will be execute the contracts which has been
submitted later on.
⚫ So you maintain a kind of serializability order of the transaction
which is preventing to execute later contract until the previous
contract gets executed.
⚫ If you introduced a malicious contract in the system which will take
huge amount of time for execution you will be able to launch a
denial of service attack on your consensus algorithm, this is the kind
of 1st problem.
⚫ Design Limitations:
⚫ 2nd problem is the implementation of smart contract.
⚫ To implement a smart contract need to go to some language which will
give more power compared to bitcoin script.
⚫ Bitcoin script is not turing complete language but because it is not turing
complete language, it dose not support all the contracts which can be
there.
⚫ For ex. It dose not support loops or it has certain limitation in execution
⚫ But to implement smart contract, because you want to increase a power
of that particular script, you can write any general purpose contract in
the form of a code by using different type of language for that.
⚫ So the developers are develop different types of languages. So one
interesting language is that Golang which widely used in this kind of
contract execution platform.
⚫ Execute Contracts:
⚫ In case of permissioned model you have to move from challenge
response based method of permissioned less to traditional distributed
system based consensus algorithm.
⚫ But in that case you have to ensure that you have sufficient no. of
trusted nodes in the system.
⚫ So one interesting question that comes for consensus of permissioned
blockchain model that do you always need to execute the contract at
each node.
⚫ Execute Contracts:
⚫ It is not necessary you just need state synchronization across all
the nodes.
⚫ So it is like that you execute the contract in one node then after
executing the contract in one node, you propagate the state of the
contract to your neighboring node and that like state get further
propagated so, that way every nodes in the system, it get same states of
the contract and they can be on the same page of your smart contract.
⚫ Execute Contracts:
⚫ But a typical question comes that what if the node that execute the
contract it becomes faulty. So if this particular nodes becomes faulty
then system gets down and the system will not be able to make any
progress further. So in this particular scenario the idea is that you used
the concept of state machine replication so you execute a contract at a
subset of node rather than a single node.
⚫ So you have multiple nodes which can be selected to run the
particular contracts.
⚫ Execute Contracts:
⚫ So here this 3 nodes are executing the contract and result of the 3
nodes are propagate to all the nodes in the network.
⚫ So that way it can ensure a kind of state machine replication
through which every node that is the part of the smart contract
they are on the same page and knows that upto this much of the
contract got executed and remaining part need to be executed.
⚫ State machine replication which is a powerful tool to ensure
consensus in permissioned blockchain environment.
⚫ Execute Contracts:
⚫ The concept of State machine replication ( do not need to execute a
smart contract to all the nodes rather can execute it on subset of nodes
and then ensure that the state of the contract is getting propagated to all
the nodes in the network and there are certain consensus mechanism
which will ensure that the state which have been propagated by multiple
state machine or the contract execute that are on the same page or are
indeed correct) help to achieve the consensus in a permissioned model so
it is a powerful tool to ensure consensus in permissioned blockchain
environment.
⚫ Distributed State Machine Replication:
⚫ So by applying this kind of distributed State machine
replication technology ensure the consensus in a
permissioned blockchain environment.
⚫ State machine replication can be characterized by set of parameters.
So the set of parameters are set of states based on the system design.
So here in this particular example you have 3 states S1, S2 and S3.
Then you have set of inputs which will tell you about how the system
will behave.
⚫
⚫ Distributed State Machine Replication:
⚫ So here there are 2 inputs. 0 can be input to the system and 1 can be
another input to the system. And then you have set of outputs. Here
S3 is final output of the system that is represented by the state
machine.
⚫ A transition function which will take a state and input, it will
produce a set as the output.
⚫ So here from S1 if you take 0 as an input it produces state S2 as
output.
⚫ (S1,0)-> S2 then output
function to produce output
of the system.
⚫ And S1 as designated as
⚫ Start state.
⚫ Distributed State Machine Replication:
⚫ So here there are 2 inputs. 0 can be input to the system and 1 can be
another input to the system. And then you have set of outputs. Here S3 is
final output of the system that is represented by the state machine.
⚫ A transition function which will take a state and input, it will produce a
set as the output.
⚫ So here from S1 if you take 0 as an input it produces state S2 as output.
⚫ (S1,0)-> S2 then output function to produce output of the system.
⚫ Distributed State Machine Replication:
⚫ In a typical distributed architecture, the distributed state machine
replication mechanism works in following way. It have multiple
servers which works in a distributed fashion.
⚫ Distributed State Machine Replication:
⚫ Distributed State Machine Replication:
⚫ Distributed State Machine Replication:

⚫ In this entire algorithm it have certain outputs that can be produced.

⚫ Output is when both the share of the money has been transferred
between Bob and Alice.You send a output or you notified the client
that well the job is ready to get executed.
⚫ So that particular output is send from server to the individual users.
⚫ Now in this entire procedure there are 2 glitches.The 1st one is that
you need to maintain order in service.
⚫ Distributed State Machine Replication:

⚫ 2nd is that in presence of failure you need to ensure that all the
individual servers are on the same page, everyone knows each other
well.
⚫ Both the transactions from Bob and Alice they got executed
and the entire money has been transferred.
⚫ Why Distributed consensus:
⚫ Why do we apply for state machine replication based consensus
algorithm in permissioned model in contrast to challenge response
based consensus model apply for permissioned less settings?

⚫ So if you know that who are yours peers you can always replicate
your state machine with the current state to your peers.
⚫ Why Distributed consensus:
⚫ In case of consensus algorithm if there is only single decision maker
you don’t require any consensus.

⚫ Whenever there are multiple decision makers and in a collective way

they want to come to certain decision then you require the consensus.
⚫ Why Distributed consensus:
⚫ So the distributed consensus it helps you to reach in a agreement in
case of distributed computing. So in terms of state machine
replication concept you replicate the common states.
⚫ So that all the have the same view of the state, they can understand.

⚫ Flight Control Systems- when there are multiple flights and they want
to coordinate their position among themselves, you can apply this
kind of state machine replication technology and distributed system
to achieve consensus.
⚫ Why Distributed consensus:
⚫ For this kind of agreement protocols where the nodes collectively
needs to come to certain agreement, we require this kind of
distributed consensus algorithm.
⚫ We have looked into that we do not need a consensus in single node
process but when there are 2 nodes, so in case of 2 nodes, if there is
kind of fault, if the network is fault or even if there is a kind of crash
fault or even if the node behaves maliciously you cannot reach
consensus.
⚫ To reach consensus,
you always require
more than 2 nodes.
⚫ Faults in Distributed consensus:
⚫ In distributed environment you can have primarily 3 types of faults
⚫ Crash Fault:
⚫ Where a node crashes and not able to send message. It may
recovered after some time and it may start sending the message
again.
⚫ So these call as fail stop behavior.
⚫ Network or Partition Faults :
⚫ Where because of network fault entire network gets partitioned and
the message from one partition is not able to get propagated to
another partition.
⚫ Faults in Distributed consensus:
⚫ Byzantine Faults :
⚫ 3rd type of fault is difficult to handle in a distributed environment is
Byzantine fault. So you have kind of malicious behavior among the
nodes, which may come due to certain kind of hardware or
software faults.
⚫ So, this byzantine fault is that for certain views, the node is
behaving in one way whereas, for certain other views the node is
behaving in a different way.
⚫ Consensus for 3 processes:
⚫ To reach the consensus for 3 process, every process can have in 1 of 3
states, Undecided state : In undecided state the process or the node has
proposed certain value from a set of feasible value D. so every node has
proposed some value and they are in undecided state.
⚫ Communication state :Then in communication state they are exchanging
the value among themselves.
⚫ Decided state : So by exchanging the value and then by applying the
consensus algorithm then can reach to decided state where they set the
decision that
everyone in the
network they
agree under
certain variable
Di.
⚫ Requirements of Consensus Algorithm:

⚫ Termination: Eventually each correct process sets its decision

variable. So it terminates after setting the decision variable.

⚫ Agreement:The decision value of all correct processes is the

same. Everyone should reach to the common agreement.

⚫ Integrity: If the correct processes all proposed the same value,

then any correct process in the decided state has chosen that
value.
⚫ So if every correct process propose one value x. so at the decided
state they should decide on the same value x.
⚫ Different Algorithms:
⚫ We have different kind of algorithms for ensuring consensus in
atypical distributed system which we apply in permissioned
blockchain.
⚫ This algorithms based on the state machine replication principal.
⚫ So the initial algorithms for distributed consensus are
⚫ Paxos
⚫ RAFT
⚫ Which support crash of
network faults but they can
not support byzantine fault
so to support byzantine fault we have algorithms like
⚫ Paxos :
⚫ History:
⚫ Paxos has an interesting history, it was 1st consensus algorithm that
was proposed by Leslie Lamport in 1989 and the objective of Paxos
over to choose a single value under crash or network fault.
⚫ So this Paxos although was proposed by Lamport in 1989 but it took
around 13 years to get the paper published and there was a lot of
discussion among the community about the correctness of this
particular algorithm.
⚫ The algorithm proposed by Lamportis fair enough to ensure consensus
in a distributed environment and Lampaort try to come up with a
formal proof of this particular consensus algorithm and because of that
complicated proof, people say that it is very hard to understand or
implement Paxos algorithm but the inherent concept of Paxos is kind
of very simple.
⚫ Paxos :
⚫ History:
⚫ We looked into how Paxos can be implemented in real system to ensure
consensus in simplified way.
⚫ The idea behind Paxos is pretty simple. It is like
⚫ Example: In MGM Aurangabad, students have broadly 2 options where
student can go. Say after the class we have Gandili Campus and we have
Elora caves.After the class the students can collectively decide that all of
them want to go for either for the Gandili Campus or for the Elora caves.
⚫ Now the question comes that how will they select that whether they want
to go to Gandili Campus or go to Ellora caves.
⚫ And the interesting is that all of them want to go for together otherwise
field visit would not be that much good.
⚫ So that is why the students want to make some decision collectively that
they want to go either Gandili Campus or to the Elora caves.
⚫ Paxos :
⚫ History:
⚫ But there is no central leader the only way to communicate with
that, they will just everyone will propose certain values and from
that value proposal they will try to come to a consensus.
⚫ So the idea is something like that say assume that I am a member of
that particular team of students.
⚫ Now I just wait for some amount of time and I see that whether
someone else proposing a value to go for a caves or to campus if none
of my fiends are proposing any value,
⚫ then I initiate a proposal say let us go for campus so now I will see
whether my friends are accepting that value or not so that way, the
information get is propagate in the entire network and they try to have
to some certain consensus based on a majority decision that well.
⚫ Paxos :
⚫ If the majority of the nodes proposes that either proposes or agree that
we want to go to campus then all of them goes for campus otherwise
⚫ if majority of the students proposed to go for caves then all of them go

to Caves so that is the broad idea behind Paxos so let us look into that
algorithmically how it works.
• So you have certain proposers who are proposing the values that
proposed values should be chosen by the consensus algorithm.

⚫
⚫ Paxos :
⚫ So here proposers can propose a value that either go to campus or go to
caves then you have certain acceptors, they form the consensus and
accept the values.
⚫ So the acceptors whenever they are hearing certain proposal from the

proposers, they either accepted or rejected

⚫ It may happen that I am willing to go for campus but some proposals is
coming to go for caves I will simply rejected

⚫
⚫ Paxos :
⚫ And Some other friend of mine is proposing to go for campus I will agree
to that.
⚫ That way will try to look into that whether the majority of the nodes is
either proposing or accepting going for campus or caves and accordingly
this learner module will find out that which value has been chosen by
each of this acceptors, and then they will collectively accept that
particular value that is the broad idea behind the Paxos.
⚫ So there are this 3 types of nodes the proposer, the acceptor and the
learner.
⚫Everyone is a learner in
the network which learns
what is the majority
decision.
⚫ Paxos : Making a Proposal: Proposer process
⚫ So the process in detail is the proposer initially prepare with a proposal
number.This proposal number need to be good enough so that your
proposal gets accepted.
⚫So the proposer make a
prepared proposal number
and send it to the acceptor.
⚫ So this proposal number
forms a timeline and the
biggest number it is
considered up to date.
⚫ So it is like that one
proposal is coming from P1 with proposal number say 100, another
proposal is coming from P4 with proposal number say 102 then we will
accept proposal which coming from P4 then acceptor makes it.
⚫ Paxos : Making a Proposal: Acceptors’ Decision making
⚫ In this way each acceptor compares the received proposal number with
the current known values for all the proposals prepare message and if you
are getting higher number then you accept it otherwise you decline it.
⚫So then the acceptor
based on that prepared
the response, in response
the acceptor can either
accept or decline a
message based on the
proposal algorithm.
So the biggest number
the acceptor has seen till
Now, it put that number
in the response message
and it includes the acceptance values that has been accepted from other
proposals.
⚫ Paxos : Making a Proposal: Acceptors’ Message
⚫ So this accepted values is in form to the proposer now. We take a vote
based on majority decision.
⚫ Accepting a value: Proposer’s Decision making :
⚫ So the proposal looks that whether the majority of the acceptors, they
reject the proposal, if they have rejected the proposal then you updated
with the latest proposal number.
⚫ If they have not rejected it then you see that whether the majority of the
acceptors has accepted the value.Then you can not choose that particular
proposer value, if it is not then you send the accept message. So the idea
is that whenever the majority of the acceptors, they are sending some
accepted values, if
they have accepted
your value, that means
the value that you have
Shared that is coming
to a consensus.
⚫ Paxos : Making a Proposal: Acceptors’ Message
⚫ So it is just like that you have proposed for campus and once you have
proposed for campus and the majority of your friends are accepted for
the campus and from that all of you can go for campus.
⚫ Accepting a value: Notifying Leader
⚫ So the final stage is this accept message so the proposer sends the accept
message to all the acceptors and in accept message you include the
proposal number.
⚫ A similar to the prepare phase the proposer knows that my proposal has
been accepted and the value is the single value that is proposed by the
proposer.
⚫Now, whenever the
acceptor, it accept the
value from the proposer,
it informs the learner
about this majority voted value. So everyone learns that what is the
majority voting in the environment.
⚫ Paxos : Single Proposer: No rejection
⚫ If you have the single proposal in the system, then the system is very
simple with that single proposal, every acceptor will accept the proposal
because that is going to be the biggest.
⚫So the proposal does
not get rejected if the
acceptors are correct.
⚫ So you have to ensure
that if you need to
ensure majority of the
acceptors are non faulty.
Now see the case
whenever certain
acceptor fails
⚫ Paxos : Single Proposer: No rejection
⚫ Now see the case whenever certain acceptor fails
1) If the acceptor fails during prepare phase then you do not have any
issue that here other acceptors who can hear the proposal and they
can vote either for the proposal or against the proposal
⚫ Paxos : Single Proposer: No rejection
2) Now acceptor may fails during acceptor stage again If the acceptor fails
during acceptor stage
you do not have any
issue because other
acceptors are there
who have already
voted for the proposal
⚫ Now only thing you have to ensure that less number of i.e. N/2 number
of acceptors they can fail simultaneously because you are going for
majority voting principal.
⚫So whenever you are
going for majority voting
principal in the synchronous
Environment you need to
⚫ Paxos : Single Proposer: No rejection
ensure that majority of nodes are correct. So if more than N/2 number of
acceptors fail no proposal they get reply and you can not come to the
consensus algorithm.
Now let us look into
scenario when
proposer fails.
Proposer can fails
during prepare phase
or acceptor stage.
If the proposer fails during prepare phase it is just like that no one is
proposing for any value for go to campus or go to caves. So you wait, wait,
wait for getting a value from your friend and if you are not getting a value
so you become a proposal
With same idea if acceptor wait for certain times and if they do not hear
any proposal, one of the acceptor become proposal and proposes new value
⚫ Paxos :
⚫ So Paxos protocol proved that you can have certain consensus algorithm
in a distributed environment.
⚫ RAFT Consensus :
⚫ Whenever you can come to the consensus based on Paxos algorithm, by
applying some consensus technique you can always elect a leader.
⚫ If you have a leader in the system, achieving consensus becomes much
easier because in that case you can avoid multiple proposer proposing
something all together.
⚫ So the way RAFT is different from Paxos
⚫ -- In case of Paxos you didn’t have any kind of leader as such, so multiple
proposer can propose the thing simultaneously, and when multiple
proposer proposes the thing simultaneously protocol becomes complex
⚫ That the acceptors now have to accept one of the proposals from the

proposers and in that highest proposal number used as a tie breaking

mechanism and we embed certain algorithm inside a Paxos to ensure that
⚫ RAFT Consensus :
⚫ Every proposal that is coming from different individual proposers
they are in date unique. So it is not like that 2 proposals are
proposing with the same proposal value that we ensure inside Paxos.
So all this internal details makes the Paxos more complicated.
⚫ But when it is convinced that you can design a consensus algorithm
based on Paxos or any other principal through majority voting then
you make a simplified version of the protocol where you have elected
a leader.
⚫ Then task of leader is to propose something, so there is single
proposer now which is the leader and all the acceptors are now the
followers of the leader. So the idea is that the nodes, they collectively
selects a leader.
⚫ Once the leader and other followers are in the system, now the
leader is responsible for state transition log replication across the
followers in terms of this replicated state machine concept.
⚫ RAFT Consensus :
⚫ So that is the RAFT algorithm whenever the system starts up it has the
set of followers nodes. Now this followers nodes some of them just look
for whether there is already a leader or not.
⚫ If it is time out that means there is no leader in the system then start the
election. In the election you choose some of the candidates, so some of
your friends says that well I want to be a leader.
⚫ Now whenever they are saying that I want to be a leader then you
received the votes from the majority of the server saying that who is
going to be the leader.
⚫Now among the
candidates who wins for
the majority of the votes,
that person becomes the
leader.
⚫ RAFT Consensus :
⚫ Now you have chosen one leader so this particular leader finds out that
what should be the proposed value and then the followers can either vote
for the proposal which coming from he leader or they can go against the
leader. So here the RAFT consensus algorithm we can explain
traditionally in the form of transition log.
⚫ So it is the concept from this replicated database, it is like that you have
multiple replicated servers and you want to build a consensus algorithm
among this multiple replicated servers so whenever some transitions are
coming up form the clients when you want that, this replicated servers
say S1, S2, S3 and S4,
they collectively take
some decision about
this consensus and
based on that they
decide whether to that
transition or not.
⚫ RAFT Consensus :
⚫ Let us see algorithm in detail. Initially the first part of RAFT is to elect a
leader. For that you need certain leader candidates, it is just like among
the servers someone can just wait for certain amount of time to see
whether some leader is already there and once if times out you just think
of whether you want to be a leader or not.
⚫ If you want to be a leader just announce I am the candidate so once these
leader candidates are there then these leader candidates request for the
votes. So this votes contain 2 parameters:
⚫ 1) Term 2) Index
⚫RAFT algorithm
also runs in rounds.
⚫Now every round
you need to take one
decision. And this
term parameter
denotes in which
⚫ RAFT Consensus :
⚫ Particular round you are. So this term is calculated as last calculated
number known to the candidate.What was the last candidate term +1.
⚫ It is like that the earlier round was round 20 when your term was 20 now
you want to have new vote to elect a new leader. So you make the new
term as 21.
⚫ Index parameter says about the committed transaction which is available
to the candidate i.e. it says that upto this many of transactions have been
committed till now.
⚫Now this request
vote message it is
passed to all the
nodes in the network
⚫Now when the
nodes they receive
message they have to
elect a leader.
⚫ RAFT Consensus :
⚫ So the idea of RAFT is to make a comparison on top of the term and
index value.
⚫ So node i executes the algorithm in this way – node i receives the term
value from one of the candidate. So it looks into its own term so it 1st
find out its own term. Is the proposed term is less than its own term?
⚫ Means node i says this is the candidate and this is the node. Now this
candidate sends a proposal message with a term value. Now the candidate
proposed say term 20 and index i
⚫So this proposal
message is receive to
the node n. now the
nodes look out what
is the term, it has say
suppose 21 which is
already there at node
n so if node n has
⚫ RAFT Consensus :
⚫ Term 21, and candidates is requesting to be leader from term 20 that
means that it is requesting for some earlier term some earlier round so
you decline this message.
⚫ If it is not like this, if your term is either equal to current term then look
into index. Now assume that in the proposal message index value is
100and node has index value 150, it indicates that this node has already
committed upto transaction 150 and some leader candidate is proposing
to be a leader for some old transaction 100. then should not allow
because particular
transaction has already
been committed so in
this case decline means
decline that particular
node request to be a
leader otherwise you
Make a vote for the
⚫ RAFT Consensus :
⚫ candidate so this is the way you select a leader for the RAFT
consensus algorithm. Now the leader is getting a vote. Every node
sends their vote and we use the concept of majority voting for leader
election and commit the corresponding log entry.
⚫ So if certain leader candidate it receives the majority of the vote form
the nodes then that particular candidate becomes the leader and other
becomes the follower of that node.
 ⚫ RAFT Consensus :
⚫Example: when there are multiple leader candidates. One
leader has 3 followers with term 10 and commit index 100.

⚫ Now leader node has failed then you need to elect new leader with
term 11.
⚫ RAFT Consensus :
now this new leader sends
the message that I am the
new leader in term 11 and
community index is 100.

once the old leader receives

the message from new
leader with greater term.
Old leader drops to follower
state.
So that way whenever the
leader fails you have one
way of handling a new
leader by utilizing this term
parameter.
⚫ RAFT Consensus :

⚫ RAFT has improved the concept from Paxos rather than going for
repeated Paxos i.e. multi Paxos we will go for leader election
mechanism where we will apply some consensus algorithm based
on the majority voting. So make consensus easy to understand or
easy to prove.

⚫ So once leader is elected you can not have multiple proposers.

⚫So the case when partially you are proposing for caves and partially
for campus, for this kind of application your Paxos and RAFT will
not be able to tolerate this kind of faults.
⚫ So this class of faults called as Byzantine fault where a particular
node can behave maliciously or faulty.
⚫ RAFT and Paxos Consensus Protocol:

⚫ When we have looked into different aspects of this fault tolerant

nature of distributed consensus protocols i.e. RAFT consensus and
Paxos consensus they work good for crash faults, but if there is
some kind of byzantine behavior in the network where the node
starts behaving maliciously then RAFT and Paxos protocol can not
handle this kind of scenario.
⚫ Permissioned blockchain environment :

⚫ So the permissioned blockchain environment which is a

closed environment and every node knows each other.
⚫ Under this permissioned model fault can occur and whenever
there is possibility of having certain kind of faults during that time
you may have broadly 3 different types of faults.
⚫ Crash fault where a node can fail arbitrarily due to crash that can
be hardware or software crash and in case of crash fault it may
happen that the node starts transmitting messages to all its sphere.
⚫ Crash faults are recoverable.

⚫ Network or Partition Faults :

⚫ Byzantine Faults :
⚫ Byzantine Faults :
⚫ In byzantine fault when a node starts behaving maliciously, in this
fault it may happen that node sends different messages to different
peers. So this is the Byzantine General Problem for example where
the general sends one attack message to one group whereas send
retreat message to another group. Now if general becomes faulty
then it becomes difficult for a system to find out what to do?
⚫ Byzantine General Problem :
⚫ So we look into this general class of faults in distributed system under
closed environment which is called as Byzantine General Problem or
Byzantine fault tolerant Problem and we try to develop a fault tolerant
architecture where the system will be able to tolerate this kind of
byzantine faults.
⚫ Let us look into Byzantine General Problem under multiple node
scenario
⚫ -- Here considering 3 Byzantine General Problem where you have 3
generals in terms of this kind of Lamport timestamp to denote this kind
of Byzantine General Problem and in this architecture you have one
commander and 2 different Lieutenants.
⚫ So the commander sends the message to Lieutenants and Lieutenants
shared the message among themselves and try to find out whether the
commander is faulty or whether the Lieutenants is faulty.
⚫ In this architecture we assume that the Lieutenant is faulty. Now if the
Lieutenant is faulty then the Lieutenant may send different messages.
⚫ Three Byzantine General Problem :
⚫ So the Commander is correct:
⚫ The commander sends retreat message to both Lieutenants. Now one
particular Lieutenant is faulty Lieutenant. So the faulty Lieutenant does
not obey the massage which is send by the commander rather the faulty
Lieutenant sends an attack message to other Lieutenant.
⚫ Now 2nd is the correct Lieutenant sends the retreat message what he
heard from the commander that same message send to the 2nd
Lieutenant.
⚫ Three Byzantine General Problem :
⚫ 2) Lieutenant is faulty :
⚫ Now under this particular scenario when the commander is correct but
one of the Lieutenant is faulty then let us see that whether we can reach
to the consensus under this scenario or not.
⚫ So in this scenario Lieutenant-1 receives the different messages. So it
receives retreat message from commander and attack message from
Lieutenant-2. Now in this case in general principal of normal army
scenario, the Lieutenant
always obey the commander
and if the commander is
non faulty then the entire
system acts correctly
even if the Lieutenant-2
is faulty.
⚫ Three Byzantine General Problem :
⚫ So if the Lieutenant is faulty but the commander is correct then by this
general principle of integrity in the army we will able to solve this
problem that all the Lieutenant will follow the commander because the
commander is correct.Then we do not have any kind of consensus
problem in the system.
⚫ Now look into 2nd condition that the commander is faulty so this is the
kind of non trivial case.
⚫ Three Byzantine General Problem :
⚫ Commander is faulty :
⚫ Which is difficult to handle in Byzantine General Problem with 3
generals. So in this case the commander sends the retreat message to one
Lieutenant and different message attack to 2nd Lieutenant.
⚫ Now in this case we assume that commander is faulty and both the
Lieutenants are correct.
⚫ So according to integrity principal Lieutenant-2 heard attack message
from commander and it sends back or echoes this attack message to
other Lieutenant.
⚫ Three Byzantine General Problem :
⚫ Commander is faulty :
⚫ So in this particular case by the message passing principle the entire
system will not be able to work because Lieutenant-1 it will have
different message from different generals.
⚫ So it will get the retreat message form commander and attack message
from Lieutenant -2. so because it was different message so with the
integrity condition if we try to do the retreat then it will follow that
principle but whereas this Lieutenant-2 it got the attack message.
⚫ Three Byzantine General Problem :
⚫ Commander is faulty :
⚫ If it attacks then obviously the entire army will get defeated so by this
message passing principle if we try to obey to commander and if we do
not have any way to find out that whether to go for majority voting or
whether to go for the instruction that the commander has send then the
entire system is in dilemma that which particular instruction to follow.
⚫ So even under the Byzantine General Problem we can solve this
particular problem of Byzantine failure.With the principle of majority
voting that we
have seen in
the case of
Paxos
or RAFT.
⚫ Byzantine General Problem :
⚫ Commander is faulty :
⚫ With the context of crash failure in RAFT consensus protocol, entire
system works on the principle of leader.
⚫ But in this particular case when the system is a kind of byzantine system
and leader itself who is the commander here sends different messages to
different Lieutenant, then coming up to a consensus on this principle
becomes difficult.
⚫ In this example Lieutenants are followers in the RAFT consensus
terminology, the Lieutenant can start sharing the message among
themselves and they can took into this majority principle.
⚫ Construct like if majority of Lieutenants votes against the commander
then we will assume that the commander is faulty. Otherwise consider
that Lieutenant is faulty.
⚫ If we are not getting majority voting rather some individual Lieutenant
Who are differing from the message which is send by the commander.
⚫ Three Byzantine General Problem :
⚫ Commander is faulty :
⚫ If we try to apply this majority voting principle what we see that with 3
byzantine generals with one commander and 2 Lieutenants the problem
still remain unsolvable because the majority principle does not work.
⚫ You get equal voting for attack and retreat or Lieutenant get equal
voting for attack and retreat and Lieutenant can not decide what to do.
⚫ And if Lieutenant at that time tries to follow what the commander has
asked to do then the Lieutenant can take a decision which differs from
the decision taken by the other Lieutenant.
⚫ Byzantine General Problem :
⚫ So we will not be able to solve the Byzantine General Problem with 3
generals where we have one commander and 2 different Lieutenants.
⚫ So that is one learning that we will not able to solve Byzantine General
Problem with 3 generals.
⚫ Let us look into another use case if we have 4 different byzantine
generals where 3 are Lieutenants and every individual Lieutenant with
the message passing principle they can talk with each other.
⚫ Four Byzantine General Problem :
⚫ So here the commander sends message to all Lieutenants and
Lieutenants they share the message what the commander has shared
with them with each other.
⚫ But the Lieutenant can be faulty and in this case we assume that one
Lieutenant is faulty. Now among this 3 Lieutenants if one is faulty.
⚫ Let us see what happens for in 2 different cases.
⚫ 1) consider Lieutenant is faulty 2) when commander is faulty
⚫ Four Byzantine General Problem :When Lieutenant is faulty:
⚫ 1) consider Lieutenant is faulty then Lieutenant send message which is
differ from the message which is send by commander.
⚫ Now commander here sends the retreat message to all the Lieutenants.
⚫ And this Lieutenant-1 and Lieutenant-3 they correctly echoes the
message to other Lieutenants.
⚫ So this Lieutenant-1 it informs retreat message to Lieutenant-2
and Lieutenant-3 but the Lieutenant-2 differs because Lieutenant-2 is
faulty general here.
⚫ Four Byzantine General Problem :When Lieutenant is faulty:
⚫ So Lieutenant-2 incorrectly echoes the message to other.
⚫ So Lieutenant-2 sends an attack to Lieutenant-1 and similarly it sends an
attack to Lieutenant-3 whereas the commander has send the retreat.
⚫ Now here in this case if we go for the majority voting principle,
Lieutenant-1 receives 2 retreat message. One retreat message from
commander and 2nd retreat message from Lieutenant-3.
⚫ So the majority is retreat so this Lieutenant-1 is able to correctly decode
what the commander has actually instructed for.
⚫ Four Byzantine General Problem :When Lieutenant is faulty:
⚫ In 2nd case for Lieutenant-3 who is the correct Lieutenant and receives
retreat message from commander and Lieutenant-1 but receives attack
message from Lieutenant-2. here also with majority voting principle, it
decides to retreat. But Lieutenant-2 is faulty so we do not consider the
behavior of faulty Lieutenant.
⚫So in this case we observe that our objective of fault tolerant algorithm
was the integrity principle like that all the correct Lieutenants or all the
correct nodes in a fault tolerant system, they will follow the majority
votes. So here we
observe that even if
Lieutenant-2 is the
byzantine node then
also Lieutenant-1 and
Lieutenant-3 is able
to correctly decode
the message from the majority voting.
⚫ Four Byzantine General Problem :When Lieutenant is faulty:
⚫ Now if we further consider the malicious behavior or byzantine
behavior of Lieutenant-2, so instead of sending an attack if Lieutenant-2
sends an retreat here so it is like that Lieutenant-2 is making a malicious
behavior where it is sending the correct message to one node and it is
sending fault message to another node. Even in this case we can find out
that well this particular Lieutenant-3, it gets all the retreat message so it
remain retreat whereas with majority voting principle Lieutenant-1 can
correctly decode the message. So with the Lieutenant Faulty or with
One Lieutenant
faulty we can
correctly decode
the message in
case of this
Byzantine General
Problem.
⚫ Four Byzantine General Problem :WhenTwo Lieutenant is faulty:
⚫ But instead of one Lieutenant to be faulty, if we take a different case
where 2 Lieutenants are faulty. Assume that Lieutenant-1 and
Lieutenant -2 faulty.
⚫ So Lieutenant-1 can also start behaving maliciously and rather than the
correct retreat message it sends attack message at this stage then
Lieutenant-3 receives one retreat message from commander but 2
attack message from faulty Lieutenant-2 and faulty Lieutenant -1.
⚫ So it will not be able to take correct decision based on majority voting.
So here out of 3
Lieutenants if one
Lieutenant is faulty they
will be able to correctly
decode the message
otherwise not.
⚫ Four Byzantine General Problem : Commander is faulty :
⚫ 2) when commander is faulty : Whereas with 4 byzantine generals,
commander is faulty means commander starting behaving
maliciously and all the Lieutenants are correct. So here Lieutenant-1
receives retreat message from commander so echoes retreat
message to other 2 Lieutenants.
⚫ Lieutenant-2 is also correct but heard attack message from commander
so send attack message to other 2 nodes whereas Lieutenant-3 is correct
it heard retreat message so it passes retreat message to other 2
Lieutenants.
⚫ Four Byzantine General Problem : Commander is faulty :
⚫ Now see whether the majority voting works in this case or not.
Lieutenant-1 receives 2 retreat and 1 attack vote so it decides that the
decision is retreat, now Lieutenant-2 receives one attack vote from
commander and retreat vote from other 2 Lieutenants.
⚫ So it can decide based on the majority principle that retreat is the
correct decision and if retreat is the correct decision it can correctly
finds out that commander was indeed faulty.
⚫ Now Lieutenant-3 receives retreat message from commander, one
attack message from Lieutenant-2 and one retreat from Lieutenant-1.
⚫ Four Byzantine General Problem :
⚫ So here if you have 3 different Lieutenants who are correct and you have
one commander who is behaving maliciously.You need to ensure that
majority voting principle will give you the correct results.
⚫ Now if we look integral principle that we look into normal byzantine
problem with f number of faulty nodes. So if a Lieutenant is faulty in
that case we need to ensure that there are 2f+1 number of total
Lieutenants in the system.
⚫ Four Byzantine General Problem :
⚫ So if we have 2f+1 Lieutenants and one commander then we will able to
correctly apply this majority voting principle to find out the byzantine
nodes in the system.
⚫ Now again in this entire system if we see that commander sends attack
message to more than one Lieutenant then whatever the majority
decision that the commander is sending, the entire system will take that
particular message in the consensus i.e. one retreat and 2 attack message
then consensus in the system will reach to the attack message by this
⚫ Four Byzantine General Problem :
⚫ majority voting principle. So conclusion is that if we have 2f+1 number
of Lieutenants and one commander and out of them if the Lieutenant is
faulty then the system will come to consensus.With the value that
commander has proposed and
⚫ if the commander is faulty then the system will come to other consensus
with the value that commander has proposed to majority of the
Lieutenants. So that way we can come to the consensus with the 4
byzantine generals.
⚫So the byzantine
general model is works
in the way like we
assume that there are n
number of process out
of which at most f
number of process can
be faulty
⚫ Four Byzantine General Problem :
⚫ so for that we ensure that in the system there are 2f+1 Lieutenants and
⚫ The receiver it always knows the identity of the sender.
⚫ So that our closed model in the context of blockchain technology, this
model helps to design an algorithm for permissioned blockchain
environment. So the system is fully connected.
⚫ The communication is reliable communication medium.
⚫ The system is synchronous
i.e. every node will be able
to receive all the messages
within some predefined
Time out duration.
⚫Whereas in fully
asynchronous system even if
a single node is faulty, system
will not be able to reach a consensus within a predefined timeout interval.
⚫ Lamport-Shostak-Pease algorithm :
⚫ So we do not look into the asynchronous nature of the system at this
moment. So develop an algorithm which is synchronous in nature.
This algorithm is known as Lamport-Shostak-Pease algorithm which
was one of the 1st algorithm for this kind of Byzantine General
Problem which was published in ACM transaction on programming
language. So in this particular case the commander sends the
message at pulse-1. so pulse-1 is the initial pulse when the
commander sends the
message to all the
Lieutenants.
⚫So we are 1st
considering a base
condition. So this
base condition we
have 2 parameters.
⚫ Lamport-Shostak-Pease algorithm :
⚫ 1) N is the number of processes in the system and
⚫ 2) t is the algorithm parameter that denotes the individual rounds so
t=0 indicates you are in pulse 0 when the commander is sending the
message to all the Lieutenants.
⚫ So the commander decides on its own value whether to go for retreat or
to go for attack and at pulse-0 it broadcast this particular message.
⚫ So here it is the retreat message an example to all the Lieutenants.
⚫ Lamport-Shostak-Pease algorithm :
⚫ For this example N=3 because we have 3 different processes among
which we are trying to reach to the consensus. So we send the 3
messages to 3 different Lieutenants. Now that is the base condition for
commander.
⚫ For Lieutenants base condition is the Lieutenant receives the message
from commander, it 1st check whether it is a pulse-1 message or not.
⚫ It is pulse-1 message means that message is coming from commander.
⚫ Lamport-Shostak-Pease algorithm :
⚫ If it is NO that means it is not a pulse-1 message then you can not take
any decision because you do not know that from where the message is
coming from.
⚫ If It is pulse-1 message that means the 1st message in the system and the
message is coming from commander, then you accept, what commander
is saying. Otherwise the system goes to the undefine state.
⚫ So what the commander is saying you then broadcast that particular
message to all other processes in the system.
⚫ Lamport-Shostak-Pease algorithm :
⚫ So that is the initiation. As the system progress in round, so at
every individual round, commander who is sending this message so
this commander it broadcast again the message to all the
Lieutenants in the tth round.
⚫ Lamport-Shostak-Pease algorithm :
⚫ For the Lieutenants, every individual Lieutenant whatever message it
receives from the commander, it broadcast this message to all the
Lieutenants, except the sender of that particular message.
⚫ So it dose not broadcast the message to the commander rather it
broadcast this message to all other Lieutenants in the system.
⚫ Now with this broadcasting of message at every individual round, it may
happen that if you have n number of Lieutenants in the system then after
nth round you are getting the message from all the individual the
Lieutenants.
⚫ Lamport-Shostak-Pease algorithm :
⚫ As the system is synchronous you are known to get the message from all
other Lieutenants who are there in the system after nth round.
⚫ So once you receive all this messages then you can apply the majority
voting principle so every individual Lieutenant they apply the majority
voting principle and by applying the majority voting principle they
decides based on majority voting what should be their decision whether
the decision would be to go for what the commander is saying or to go
for what majority of the Lieutenants is saying for.
⚫Lamport-Shostak-Pease algorithm :
⚫So the example that we have seen for the 4 general
problem so here in a general condition the algorithm
works with this principle like at every individual round
the commander is sending the message, broadcasting the
message to every individual Lieutenants.
⚫And once this Lieutenant get the message it again
broadcast that message to other Lieutenants except
the sender.
⚫So here the sender is the commander so every Lieutenant
get the message from all other Lieutenants along with the
commander and they apply them majority voting
principle, what the majority voting says it takes that
particular decision.
⚫Lamport-Shostak-Pease algorithm :
⚫ So this is the algorithm for achieving consensus
which was develop primarily by Lamport for
synchronous environment.
⚫ When you know that you are going to receive the
message within some predefined time out interval and if
you are able to receive the message within predefined
time out interval then you can apply the majority voting
principle to decide what should be your decision.
⚫Lamport-Shostak-Pease algorithm :
⚫So if majority voting principle says that you go for attack
then you should go for attack and if majority voting
principle says that you go for retreat then you should go
for retreat.
⚫And in this case if a Lieutenant is faulty until you have
sufficient number of Lieutenant in the system. Like if
there are f number of Lieutenants which you are assuming
to be faulty and you have 2f+1 number of Lieutenants in
the system you can simply assume that with the majority
voting principle you will accept only message which the
majority of the correct Lieutenants says.
⚫Lamport-Shostak-Pease algorithm :

⚫Now if the commander is faulty in that case scenario is

little tricky that the commander is sending one vote to one
group of Lieutenants and another vote to another group of
Lieutenants. And if you have 2f+1 number of Lieutenants
in the system you already have some odd number of
Lieutenants andwhen the odd number of Lieutenants,
commander has no way of saying some majority decision
exactly for say f number of Lieutenants it will say one
decision and for remaining f Lieutenants it may say another
decision.
⚫Lamport-Shostak-Pease algorithm :
⚫So what the commander is saying to the majority of the
nodes, you will be able to decide on that majority voting on
that majority value.
⚫So in this case 2f+1 number of Lieutenants and one
commander we can achieve consensus in synchronous
system.
⚫When we have either the commander is faulty or f number
of Lieutenants are faulty so when f number of Lieutenants
are faulty with 2f+1 number of Lieutenants, you will be
able to achieve consensus otherwise if commander is faulty
but all the Lieutenants are correct then also you will be
able to achieve consensus under this Lamport algorithm.
⚫Lamport-Shostak-Pease algorithm :

⚫So this is an consensus algorithm which is for

synchronous environment but we understand that our
practical networking system environments are
asynchronous which does not behave like synchronous
environment and to that asynchronous network it may
happen that you will not be to receive message within a
predefine timeout.
⚫ BFT over Asynchronous systems:
⚫ Practical Byzantine Fault Tolerance is a consensus algorithm
introduced in the late 90s by Barbara Liskov and Miguel Castro.
⚫ PBFT was designed to work efficiently in asynchronous(no upper
bound on when the response to the request will be received)
systems.
⚫ It is optimized for low overhead time. Its goal was to solve
many problems associated with already available Byzantine
Fault Tolerance solutions. Application areas include distributed
computing
and blockchain.
⚫BFT over Asynchronous systems:

⚫Practical Byzantine Fault Tolerance: 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).
⚫BFT over Asynchronous systems:

⚫Practical Byzantine Fault Tolerance:

⚫ 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
increase, the system becomes more secure.
⚫Byzantine Fault Tolerance:
⚫ Trust and security are vital to blockchain technology—
and the Byzantine fault tolerance (BFT) consensus
mechanism is at the core of a blockchain's safety.
⚫BFT ensures that blockchains continue operating, even if
some network participants are unreliable or malicious.

⚫What Is Byzantine Fault Tolerance?

⚫Byzantine fault tolerance refers to the ability of a network
or system to continue functioning even when some
components are faulty or have failed.
⚫With a BFT system, blockchain networks keep functioning
or implementing planned actions as long as most network
participants are reliable and genuine.
⚫What Is Byzantine Fault Tolerance?
⚫This means that over half or two-thirds of the nodes on the
blockchain network must agree to validate a transaction and
add it to the block.
⚫For compromised nodes to cause malice on a Byzantine fault-
tolerant blockchain, they must be in the majority. This
malice can be in the form of double spending, a 51% attack,
a Sybil attack, and so on.
⚫Byzantine fault tolerance in blockchain technology originates
from the Byzantine general problem pioneered by Leslie
Lamport, Marshall Pease, and Robert Shostak. This concept
became prominent when they published a paper, with a copy
hosted by Microsoft, called 'The Byzantine Generals Problem
(PDF)' in 1982.
⚫What Is Byzantine Fault Tolerance?

⚫Lamport, Pease, and Shostak described the case of a group of

generals from the Byzantine army camping outside an enemy
city. Each general had their own army and needed to
communicate and make a unanimous decision on whether to
attack or retreat.
⚫The problem was carrying out a joint action amid some
compromised generals. This dilemma was called a Byzantine
fault, and when a system successfully tackles this problem, it
is said to be Byzantine fault-tolerant.
⚫The Byzantine fault-tolerant concept was then applied to the
cryptocurrency blockchain network. In the crypto space, the
generals are the nodes that validate crypto transactions.
⚫How Does the Byzantine Fault Tolerance Work?

⚫Decentralized networks implement Byzantine fault tolerance

via consensus rules or protocols. All the nodes in the
network must adhere to these protocols or algorithms if they
want to participate in validating and processing transactions.
⚫For a transaction to be validated, processed, and added to a
growing block, most nodes must agree that the transaction is
authentic through the network's consensus algorithm.
Bitcoin, Ethereum, and other proof of work (PoW) and
proof of stake (PoS) blockchains employ BFT algorithms.
⚫In the PoW consensus algorithm, the miners on the network
solve cryptographic puzzles to validate and produce blocks
recording transactions.
⚫How Does the Byzantine Fault Tolerance Work?

⚫The miner that solves the puzzles first wins the right to add
the transaction to the growing block and earn the block
reward. But the miner must publish proof that they solved
the puzzle to add the block.
⚫The mining process in PoW blockchains requires expensive
computers or mining rigs. This high cost disincentivizes
miners from sharing false information because other
participants would reject it. It also reduces the likelihood of
malicious actors gaining control of most nodes in the system.
⚫How Does the Byzantine Fault Tolerance Work?

⚫Meanwhile, with the PoS consensus mechanism, you must

stake a certain amount of crypto tokens to earn the right to
validate the transaction. Then, if the network protocol
selects you, you can add the transaction to the growing block
and earn the block reward.
⚫PoS systems solve Byzantine faults using different methods.
For instance, Ethereum uses the Casper algorithm, which
requires at least two-thirds of the nodes to reach a consensus
on blocks. Ultimately, PoS systems need most nodes to agree
on blocks before they can be added.
⚫How Does the Byzantine Fault Tolerance Work?

⚫These blockchains use BFT consensus algorithms to resist the

nodes in the minority that do not agree with the consensus.
This way, the blockchain network can proceed with its
function, rejecting faulty or dishonest transactions.

⚫The Role of Byzantine Fault Tolerance in Blockchain

Technology
⚫Blockchain technology relies on Byzantine fault tolerance for
these reasons:
⚫BFT keeps the blockchain network continuously functional,
even with some disagreeing nodes.
⚫The Role of Byzantine Fault Tolerance in Blockchain
Technology
⚫ It keeps the network secure, preventing malice which can
come in the form of a 51% attack (or Sybil attacks) or double-
spending.
⚫Some limitations of the PBFT include the following:

⚫ High Communication: To stay functional, the system requires

heightened communication between the nodes. This process is
time-consuming and leads to scalability problems.
⚫ Scalability Issues: PBFT has problems with scalability,
especially with networks that are very extensive.
⚫ Low Security: PBFT is prone to Sybil attacks, where one node
on the network pretends to be 51% of the other nodes to
dominate the network and cause malice.