Week 6

Blockchain and its applications
Prof. Sandip Chakraborty
Department of Computer Science & Engineering

Indian Institute of Technology Kharagpur
Lecture 26: Consensus for Permissioned Models

• Permissioned Model
• State Machine Replication

• Consensus on State Machines
Permissioned Model
• A blockchain architecture where users are authenticated a

priori
• A Membership Service Provider (MSP) helps to obtain the chain
membership
• 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
• Particularly interesting for business applications – execute

contracts among a closed set of participants
• Example: Provenance tracking of assets in a supply chain

A Use Case
Smart Contracts over Closed Networks
• Smart Contracts: “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” -
http://www.scalablockchain.com/
• Agreement on a Smart Contract Execution:

• Store the contract on a blockchain
• Once an event is triggered, execute the codes locally on
each peer
• Generate transactions as the output of the contract
execution
• The peers of the blockchain network validates the
transaction, and the output is committed in the
blockchain – may trigger the next event to execute the
code further
• Agreement on a Smart Contract Execution:

• Store the contract on a blockchain
• Once an event is triggered, execute the codes locally on
each peer
• Generate transactions as the output of the contract
execution
Do we really need to execute
• The peers of the blockchain network validates the
transaction,the code
and the oniseach
output peer?
committed in the
blockchain – may
When trigger
does thepeer
each next event to execute
execute the the
code further
code?
• Execute contract at a subset of nodes, and ensure

that the same state is propagated to all the nodes
• Majority of the peers should agree on the state
• Validation: Generate a "proof" that a peer has agreed
on the "state of execution"

How will we generate the

proof?

Smart Contract as State Machines
• State Machine Replication:

• Represent the smart contract as a state machine
– Remember, any deterministically executable
code can be represented as a state machine
Smart Contract as State Machines
S1:
while (moreGoods == 1)
DeliverGoods();
S2:
if (allOrderComplete == 0) goto S1;
else {
S3:
printf("Goods transfer complete");
}
State Machine Replication Replicate the state machine
on multiple independent
servers
State Machine Replication T1:
I have delivered 100kg
potatoes
T1
State Machine Replication
T1
T2:
I have delivered
50kg tomatoes
T2
T1
T2
T1
Consensus on the
Ordering of the
transactions
T2
State Machine Replication T1
T2
T1 T1
T2 T2
T2
T1 Independently T1
T2 execute the T2
transactions
on the state
machine
T2
T1 Independently T1
T2 execute the T2
transactions
on the state
machine
S2
S2
Consensus on the
Final State
S2
S2
S2
S2
Importance of Consensus
S2
S3
S2
Importance of Consensus
S2
Majority Voting – S3
Agree on S2
S2
Conclusion
• Consensus is still required within a closed environment
• How can we extend state machine replication for

permissioned models?

Lecture 27: State Machine Replication as Distributed

Consensus
• State Machine Replication as a Consensus
• Synchronous vs Asynchronous Consensus with Crash

Faults
• Crash Fault Tolerance
• Paxos
State Machine Replication as Consensus
• There is a natural reason to use state machine

replication-based consensus over permissioned
blockchains
• The network is closed, the nodes know each other, so
state replication is possible among the known nodes
• Avoid the overhead of mining - do not need to spend
anything (like power, time, bitcoin) other than message
passing
• However, consensus is still required - machines can be
faulty or behave maliciously

blockchains
• The network is closed, the nodes know each other, so
stateBut,
replication is possible
we need among
a bit the known
redesign ! nodes
• Avoid the overhead of mining - do not need to spend
passing

But, we need a bit redesign !
blockchains
• The networkCrypto is the
is closed, thenodes
saver
know each other, so
state replication
Crypto is possible among
+ Distributed the known
Consensus = nodes
• Avoid Consensus
the overheadfor of mining - do not need to spend
Permissioned
passing Blockchain
• Classical Distributed Consensus Algorithms (Paxos,

RAFT, Byzantine Agreement) are based on State
Machine Replication
• Let us (re)visit those algorithms
Faults in a Distributed Systems
• Crash Faults: The node stops operating – hardware

or software faults
• In an asynchronous system: You do not know whether
messages have been delayed or the node is not
responding
• Rely on majority voting – progress as and when you have
received the confirmation from the majority
• Propagation of the consensus information – nodes on a
slow network will receive it eventually
Faults in a Distributed Systems
• Byzantine Faults: Nodes misbehave – send different

information to different peers (partition the
network)
• More difficult to handle
• More suitable for blockchains
Asynchronous Consensus with Crash Faults
• Remember the FLP Impossibility

• Give priority to safety over liveness
• Guarantees the followings --

• Validity: If all correct process proposes the same value v,
then any correct process decides v
• Agreement: No two correct processes decide differently
• Termination: Every correct process eventually decides
Asynchronous Consensus with Crash Faults
• Guarantees the followings --

• Validity: If all correct process proposes the same value v, then
any correct process decides v ( Unlikely to happen in PoW)
• Agreement: No two correct processes decide

differently (Safety – Not in PoW)
• Termination: Every correct process eventually

decides (Liveness – Priority in PoW)
CFT Consensus
• CFT Consensus
• Paxos (Proposed by Lamport, the most fundamental CFT) --
used in DynamoDB
• RAFT (Much simpler than Paxos) -- Used in Fabric Transaction
Ordering
CFT Consensus
We'll see how Paxos works
• CFT Consensus
• Paxos (Proposed by Lamport, the most fundamental CFT) --
used in DynamoDB
• RAFT (Much simpler than Paxos) -- Used in Fabric Transaction
Ordering
CFT in a Synchronous System
Let's go for
a dinner
Let's go for
a dinner
Perfect!
I'm in ...
Let's go ...
Let's go for
a dinner Majority agreed …
Perfect!
Perfect consensus
I'm in ...
Let's go ...
CFT in an Asynchronous System
Let's go for
a dinner
Let's go for
a dinner
I'm in
Let's go for
a dinner
I'm in
I'm okay
Let's go for
a dinner
I'm in
Can we go
I'm okay for a movie?
Let's go for
a dinner
I'm in
Can we go
I would
prefer movie
Let's go for
a dinner
I'm in
Can we go
I would
Movie is a prefer movie
better idea
Let's go for
a dinner
I'm in
Can we go
I would
better idea
I'm okay with
movie too ...
Let's go for
a dinner Consensus on a
I'm in Movie
Can we go
I would
better idea
I'm okay with
movie too ...
We are going for

dinner, right?
We are going for

dinner, right?
Nopes ! We decided
for a movie!
We are going for

dinner, right?
Nopes ! We decided
for a movie!
Umm! May
not like, but that's
the only option for
me :(
How many
We are going for people can be
dinner, right?
sleeping at a time?
Nopes ! We decided
for a movie!
Umm! May
the only option for
me :(
How many people can be

sleeping
We are going for at a time?
dinner, right?
Nopes ! We decided
for a movie!
2
Umm! May
the only option for
me :(
Asynchronous CFT
• If there are F faulty nodes (crash fault), we need atleast 2F+1
nodes to reach consensus
• Paxos: A family of distributed algorithms to reach consensus

in an asynchronous CFT
What is Paxos?
• We'll discuss vanilla Paxos

• Proposed by Lamport in 1989
• Received a lot of criticism about its proof of
correctness
• Accepted in ACM Transactions on Computer
Systems in 1998, titled "The Part-
time Parliament"
• Lamport received the Turing award in 2013
Conclusion
• Consensus is harder on asynchronous environment
• For asynchronous CFT, we need 2F+1 nodes with F crash

faults only
• Let's explore Paxos in the next class


Lecture 28: Paxos

• Paxos – CFT Consensus
• Paxos
• CFT
Paxos – The Roles of Individuals
Let's go for
a dinner
I'm in
Can we go
I would
better idea
I'm okay with
movie too ...
Proposer Proposer
Let's go for
a dinner
I'm in
Can we go
I would
better idea
I'm okay with
movie too ...
Acceptor Proposer Acceptor Acceptor Proposer
Let's go for
a dinner
I'm in
Can we go
I would
better idea
I'm okay with
movie too ...
Acceptor Acceptor
Let's go for
a dinner
I'm in
Can we go
I would
better idea
I'm okay with
movie too ...
Learner Learner
Learner Acceptor Learner Learner Acceptor
Let's go for
a dinner
I'm in
Can we go
I would
better idea
I'm okay with
movie too ...
Learner Learner
Let's go for
a dinner
I'm in
A node can have any or all of
the three roles Can we go
I would
better idea
I'm okay with
movie too ...
Learner Learner
Let's go for
a dinner
A node can have any or all of the three roles
I'm in
However, the nodes must knowCan howwe go
many acceptors aI majority
would
is
better idea
I'm okay with
movie too ...
Learner Learner
Let's go for
a dinner
Two majorities will always overlap in
I'm in
atleast I'm
one okay nodes Can we go
for a movie?
5 acceptors, majority = 3,I would
Movie is a 2 proposers: prefer movie
better idea
To accept based on majority voting, at least one acceptor
I'm okay with
movie need
too ... to choose between one of the two proposals
Paxos Basics
• Paxos is based on state-machine replication

• Proposers and Acceptors maintain a state of the running
epochs
• Uses a variable IDp where p is an epoch number –
maintains the state
• A Paxos run aims at reaching a single consensus
• Once a consensus is reached, Paxos cannot progress to
another consensus
• To reach multiple consensus, you need to run Paxos in
rounds (Multi-Paxos)
Paxos Algorithm
Proposer
Acceptor
Acceptor
Acceptor
Paxos Algorithm
Proposer
Acceptor
Acceptor
Acceptor
• Proposer wants to propose its choice (values):

• Sends PREPARE IDp to a majority (or all) of
the acceptors
Paxos Algorithm
PREPARE 100
Proposer
Acceptor
Acceptor
Acceptor

the acceptors
Paxos Algorithm
PREPARE 100
Proposer
IDp must be unique across proposers
for each PREPARE message
Acceptor Ex. Use Hash(timestamp+Proposer
Acceptor
Acceptor ID) to generate p

the acceptors
Paxos Algorithm
PREPARE 100
Proposer
Acceptor
Acceptor
Acceptor
• Acceptor received a PREPARE message with IDp:

• Did it promised to ignore requests with this IDp?
• YES: Ignore
• NO: Will promise to ignore any request lower than IDp
• (?) Reply with PROMISE IDp
Paxos Algorithm
PREPARE 100
Proposer
Acceptor
Acceptor
Acceptor
PROMISE 100

• YES: Ignore
Paxos Algorithm If majority of acceptors
PREPARE 100 promise, no ID < IDp can pass
Proposer
the protocol
The acceptors agree on State

Acceptor
Acceptor
Acceptor 100
PROMISE 100

• YES: Ignore
Paxos Algorithm
PREPARE 100
Proposer
Acceptor
Acceptor
Acceptor
PROMISE 100
• Proposer gets majority of PROMISE messages for a specific

IDp:
• Sends ACCEPT-REQUEST IDp, VALUE to a majority (or
all) of Acceptors
• (?) It picks any value of its choice
Paxos Algorithm ACCEPT-REQUEST 100,
PREPARE 100 "Dinner"
Proposer
Acceptor
Acceptor
Acceptor
PROMISE 100
• Proposer gets majority of PROMISE messages for a specific

IDp:
• Sends ACCEPT-REQUEST IDp, VALUE to a majority (or
all) of Acceptors
• (?) It picks any value of its choice
Proposer
Acceptor
Acceptor
Acceptor
PROMISE 100
• Acceptor receives an ACCEPT-REQUEST IDp, VALUE :

• Did it promised to ignore request with this IDp?
• YES: Ignore
• NO: Reply with ACCEPT IDp, VALUE; Also send it
to all learners
Proposer
Learner
Acceptor
Acceptor
Acceptor
PROMISE 100 ACCEPT 100, "Dinner"

• YES: Ignore
to all learners
Proposer
Learner
If majority of acceptors accept
IDp, VALUE, consensus is
Acceptor reached
Acceptor
Acceptor
Consensus is reached on the
value, not on IDp
• YES: Ignore
to all learners
Proposer
Learner
Acceptor
Acceptor
Acceptor
• Proposer or Learner gets ACCEPT message with IDp, VALUE:

• If a proposer/learner gets majority of accept for a
specific IDp, they know that consensus is reached for
the value (not IDp).
Paxos – Multiple Proposers
PREPARE 50
Proposer Proposer
Acceptor
Acceptor
Acceptor
ACCEPT 100, "Dinner"
PREPARE 150
Proposer Proposer
PROMISE 150,
accepted 100,
Acceptor "Dinner"
Acceptor
Acceptor
• YES: Ignore
• Has it ever accepted anything? (Assume accepted ID = IDa)
• YES: Reply with PROMISE IDp accepted IDa, VALUE
• NO: Reply with PROMISE IDp
PREPARE 150
Proposer Proposer
PROMISE 150,
accepted 100,
Acceptor "Dinner"
Acceptor
Acceptor
What the proposer will do?

PREPARE 150
Proposer Proposer
PROMISE 150,
accepted 100,
Acceptor "Dinner"
Acceptor
Acceptor
• Proposer gets majority of PROMISE messages for a specific IDp:

• It sends ACCEPT-REQUEST IDp, VALUE to a majority (or
all) of Acceptors
• (?) It picks any value it wants
PREPARE 150
Proposer Proposer
PROMISE 150,
accepted 100,
Acceptor "Dinner"
Acceptor
Acceptor
all) of Acceptors
• Has it got any already accepted value from promises?
• YES: Picks the value with the highest IDa
• NO: Picks the value of its choice
Paxos – Multiple Proposers ACCEPT-
PREPARE 150 REQUEST 150, "Dinner
Proposer Proposer "
PROMISE 150,
accepted 100,
Acceptor "Dinner"
Acceptor
Acceptor
all) of Acceptors
• Has it got any already accepted value from promises?
• YES: Picks the value with the highest IDa
• NO: Picks the value of its choice
Conclusion
• Paxos works in two rounds
• Agreement on the state (ID)
• Agreement on the value
• Safety and liveness of Paxos?


Lecture 29: Paxos – Safety and Liveness

• Safety and Liveness of Paxos
• Paxos: Correctness
• Leader Election
• Multi-Paxos
Paxos – Message Exchanges
PREPARE 100 ACCEPT-REQUEST 100, "Dinner"
Proposer
Learner
Acceptor
Acceptor
Acceptor
• Two rounds of message exchanges

• PREPARE – PROMISE: Agree on a state (ID)
• ACCEPT-REQUEST – ACCEPT: Agree on a value
• The consensus is on the "value"
Majority Voting
Proposer 1
PREPARE 100
Proposer 2
Acceptor 1
Acceptor 2
Acceptor 3
Majority Voting
Proposer 1
PREPARE 100
Proposer 2
Acceptor 1
PROMISE 100
Acceptor 2
Acceptor 3
Majority Voting
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100
Acceptor 2
Acceptor 3
Majority Voting
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100
Acceptor 2
PROMISE 100
Acceptor 3
Majority Voting
If the majority of the acceptors
PREPARE 100
Proposer 1 promised on ID100, ID50 cannot
PREPARE 50 get through (those acceptors will
Proposer 2
ignore)
Acceptor 1
PROMISE 100
Acceptor 2
PROMISE 100
Acceptor 3
Majority Voting
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 100 ignore
Acceptor 3
Majority Voting
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 100 ignore
Acceptor 3
Majority Voting
Proposer 1
PREPARE 100 Not a majority
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 100 ignore
Acceptor 3
PROMISE 50
Majority Voting
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 100 ignore
Acceptor 3
PROMISE 50 PROMISE 100
Majority Voting – Case 2
Proposer 1
PREPARE 100
Proposer 2
Acceptor 1
PROMISE 100
Acceptor 2
Acceptor 3
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 50
Acceptor 3
PREPARE 100 Becomes the
Proposer 1
majority
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 50
Acceptor 3
PROMISE 50
Proposer 1
PREPARE 100
PREPARE 50 ACCEPT-REQUEST 50, "Movie"

Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
PROMISE 50
Acceptor 3
PROMISE 50
Proposer 1
PREPARE 100

Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
PROMISE 50
Proposer 1
PREPARE 100

Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
Proposer 1
PREPARE 100

Proposer 2
Acceptor 1
PROMISE 100 ignore ignore
ignore
Acceptor 2
PROMISE 50 PROMISE 100 ignore
Acceptor 3
Majority Voting – Case 2 100 Becomes the
majority
Proposer 1
PREPARE 100

Proposer 2
Acceptor 1
PROMISE 100 ignore ignore
ignore
Acceptor 2
PROMISE 50 PROMISE 100 ignore
Acceptor 3
Liveness
Proposer 1
PREPARE 100
Proposer 2
Acceptor 1
Acceptor 2
Acceptor 3
Liveness
Proposer 1
PREPARE 100
Proposer 2
Acceptor 1
PROMISE 100
Acceptor 2
PROMISE 100
Acceptor 3
Liveness
Proposer 1
PREPARE 100
PREPARE 150
Proposer 2
Acceptor 1
PROMISE 100
Acceptor 2
PROMISE 100
Acceptor 3
Liveness
Proposer 1
PREPARE 100
PREPARE 150
Proposer 2
Acceptor 1
Acceptor 2
Acceptor 3
Liveness
Proposer 1
PREPARE 150
Proposer 2
Acceptor 1
Acceptor 2
Acceptor 3
Liveness
Proposer 1
PREPARE 150
Proposer 2
ignore
Acceptor 1
ignore
Acceptor 2
Acceptor 3
Liveness
PREPARE 100 ACCEPT-REQUEST 100, "Dinner" PREPARE 200
Proposer 1
PREPARE 150
Proposer 2
ignore
Acceptor 1
ignore
Acceptor 2
Acceptor 3
Liveness
Proposer 1
PREPARE 150
Proposer 2
ignore
Acceptor 1
PROMISE 100 PROMISE 150 PROMISE 200
ignore
Acceptor 2
Acceptor 3
Liveness
Proposer 1 There is no termination guarantee
PREPARE 150 on Paxos
Proposer 2
ignore
Acceptor 1
ignore
Acceptor 2
Acceptor 3
Majority of Accepts
• Majority of acceptors accept a request with an ID and a
value
• Consensus has been reached
• The consensus is on the value
• Accept request with a lower ID

• Will not be accepted by the majority (Would require
majority of promises with the lower ID, but we got
for a higher one, hence the accept request)
Majority of Accepts
• Majority of acceptors accept a request with an ID and a
value
• Consensus has been reached
• The consensus is on the value
• Accept request with a lower ID

• Will not be accepted by the majority (Would require
majority of promises with the lower ID, but we got
for a higher one, hence the accept request)
Majority of Accepts
• Accept request with a higher ID but a different value
• Will not be accepted by the majority
• At least one acceptor will piggyback the previously
accepted value (Remember, two majority implies
that there is a common node)
Majority of Accepts
• Accept request with a higher ID but a different value
• Will not be accepted by the majority
• At least one acceptor will piggyback the previously
So, thevalue
accepted consensus is on
(Remember, the
two valueimplies
majority
that there is a common node)
We need the ID to maintain the current
state of promise and accept, so that
multiple values does not propagate
Paxos for Leader Election
PREPARE 100 ACCEPT-REQUEST 100, "Leader"
Proposer
Learner
Acceptor
Acceptor
Acceptor
PROMISE 100 ACCEPT 100, "Leader"
Multi-Paxos
• Applications often needs a continuous stream of agreed
values
• Commit the transactions in a replicated database – each
transaction needs a consensus to be agreed upon by the
replicas
• Run multiple instances of Paxos with different round

numbers
• Each value is associated with a round number
Multi-Paxos
• If a value is already accepted for Round n, ignore the accept
requests for a different value under Round n
• Forward an ACCEPT IDp, (ROUNDn, VALUE) only when no
value has been agreed upon for the Round n
Conclusion
• CFT consensus in asynchronous system – Paxos
• Safety is ensured, but liveness is compromised
• Does Paxos work when a node sends a wrong message?

Conclusion – Attack on Paxos
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3

Lecture 30: Byzantine Faults

• Byzantine Faults
• Byzantine Agreement Protocols

• BFT Consensus
• BFT Agreement
Malicious Behavior on Paxos
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
PROMISE 50
Malicious Behavior on100Paxos
is the
majority
Proposer 1
PREPARE 100
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
PROMISE 50
Malicious Behavior on100Paxos
is the
majority
50 is the
Proposer 1
PREPARE 100 majority
PREPARE 50
Proposer 2
Acceptor 1
PROMISE 100 ignore
Acceptor 2
Acceptor 3
PROMISE 50
Proposer 1
A-R 100, "Dinner"
A-R 50, "Movie"

Proposer 2
Acceptor 1
ACCEPT 100, ignore
"Dinner"
Acceptor 2
ACCEPT 100, ACCEPT 50,
"Dinner" "Movie"
Acceptor 3
ACCEPT 50,
"Movie"
We agreed
for Dinner
Proposer 1
A-R 100, "Dinner"
A-R 50, "Movie"

Proposer 2
Acceptor 1
ACCEPT 100, ignore
"Dinner"
Acceptor 2
"Dinner" "Movie"
Acceptor 3
ACCEPT 50,
"Movie"
We agreed
for Dinner No, we
A-R 100, "Dinner" agreed for
Proposer 1
Movie
A-R 50, "Movie"
Proposer 2
Acceptor 1 Click to add text

ACCEPT 100, ignore
"Dinner"
Acceptor 2
"Dinner" "Movie"
Acceptor 3
ACCEPT 50,
"Movie"
Byzantine Generals Problem
Lieutenant - 1
Commander
Lieutenant - 2
Attack
Lieutenant - 1
Commander
Lieutenant - 2
Attack
Faulty Attack
Commander
Lieutenant - 1
Commander
Lieutenant - 2
Retreat
Byzantine Generals Problem We need a consensus
mechanism to decide
who is faulty
Faulty Attack
Commander
Lieutenant - 1
Commander
Lieutenant - 2
Retreat
Faulty Attack
Commander
Lieutenant - 1
Attack
Commander
Lieutenant - 2
Retreat
Faulty Attack
Commander
Lieutenant - 1
Attack Retreat
Commander
Lieutenant - 2
Retreat
Can we reach
consensus?
Faulty Attack
Commander
Lieutenant - 1
Attack Retreat
Commander
Lieutenant - 2
Retreat
Good Attack
Commander
Lieutenant - 1
Commander
Attack Lieutenant - 2
Good Attack
Commander
Lieutenant - 1
Attack Retreat
Commander
Faulty
Lieutenant
Good Attack
Commander
Lieutenant - 1
Consensus is NOT POSSIBLE with one
commander and two lieutenants,
when one is faulty Attack Retreat
Commander
Faulty
Lieutenant
Byzantine Generals Problem – Case 2
Faulty
Commander Attack
Attack
Retreat
Faulty
Commander Attack
Attack
Retreat
Retreat
Retreat
Faulty
Commander Attack
Attack Attack
Attack
Retreat
Attack
Retreat
Retreat
Attack
Faulty Attack: 2
Commander Attack Retreat: 1
Attack Attack
Attack
Retreat
Attack
Retreat
Retreat
Attack: 2 Attack: 2
Attack
Retreat: 1 Retreat: 1
Faulty Attack: 2
Attack Attack
Consensus is reached !Attack
Retreat
Attack
Retreat
Retreat
Attack: 2 Attack: 2
Attack
Good
Commander Attack
Attack
Attack
Good
Commander Attack
Attack
Attack
Retreat
Faulty Attack
Lieutenant
Good
Commander Attack
Attack Attack
Attack
Attack
Attack
Retreat
Faulty
Commander
Attack
Attack
Good Attack: 2
Attack Attack
Attack
Attack
Attack
Retreat
Faulty
Commander
Attack
Attack: 3 Attack: 3
Attack
Good Attack: 2
Attack Attack
Consensus is reached !Attack
Attack
Attack
Retreat
Faulty
Commander
Attack
Attack: 3 Attack: 3
Attack
Asynchronous Byzantine Agreement
• F faulty nodes – need 3F + 1 nodes to reach consensus
• Faulty nodes create partition in the network
3F
F F F
F F F
PL PF PR
F F F
0 1
0 1
PL PF PR
Either PL or PR
• F faulty nodes – need 3F + 1 nodes to reach consensus must break the
• Faulty nodes create partition in the network tie
F F F
0 1
0 1
PL PF PR
Put
• F faulty nodes – need 3F + 1 nodes to reach consensus one additional
• Faulty nodes create partition in the network node to PL / PR
F F F
0 1
0 1
PL PF PR
Put
• F faulty nodes – need 3F + 1 nodes to reach consensus one additional
• Faulty nodes create partition in the network node to PL / PR
F+1 F F
0 1
Breaks the
tie to
reach 0 1
consensus
PL PF PR
Conclusion
• Paxos does not work with Byzantine faults
• Much harder to solve than crash faults
• With F faulty nodes, we need 3F + 1 nodes to reach

consensus in a BFT system

Week 6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Week 6

Uploaded by

Copyright:

Available Formats

Blockchain and its applications

Prof. Sandip Chakraborty

Department of Computer Science & Engineering

Lecture 26: Consensus for Permissioned Models

• State Machine Replication

• A blockchain architecture where users are authenticated a

• Particularly interesting for business applications – execute

• Example: Provenance tracking of assets in a supply chain

• Smart Contracts: “A self-executing contract in which the

• Agreement on a Smart Contract Execution:

• Agreement on a Smart Contract Execution:

• Execute contract at a subset of nodes, and ensure

• Execute contract at a subset of nodes, and ensure

How will we generate the

• Execute contract at a subset of nodes, and ensure

• State Machine Replication:

• How can we extend state machine replication for

Department of Computer Science & Engineering

Lecture 27: State Machine Replication as Distributed

• Synchronous vs Asynchronous Consensus with Crash

• There is a natural reason to use state machine

• There is a natural reason to use state machine

• There is a natural reason to use state machine

• Classical Distributed Consensus Algorithms (Paxos,

• Crash Faults: The node stops operating – hardware

• Byzantine Faults: Nodes misbehave – send different

• Remember the FLP Impossibility

• Guarantees the followings --

• Guarantees the followings --

• Agreement: No two correct processes decide

• Termination: Every correct process eventually

We are going for

We are going for

We are going for

How many people can be

• Paxos: A family of distributed algorithms to reach consensus

• We'll discuss vanilla Paxos

• For asynchronous CFT, we need 2F+1 nodes with F crash

• Let's explore Paxos in the next class

Department of Computer Science & Engineering

Lecture 28: Paxos

• Paxos is based on state-machine replication

• Proposer wants to propose its choice (values):

• Proposer wants to propose its choice (values):

• Proposer wants to propose its choice (values):

• Acceptor received a PREPARE message with IDp:

• Acceptor received a PREPARE message with IDp:

The acceptors agree on State

• Acceptor received a PREPARE message with IDp:

• Proposer gets majority of PROMISE messages for a specific

• Proposer gets majority of PROMISE messages for a specific

• Acceptor receives an ACCEPT-REQUEST IDp, VALUE :

• Acceptor receives an ACCEPT-REQUEST IDp, VALUE :

• Proposer or Learner gets ACCEPT message with IDp, VALUE:

What the proposer will do?

• Proposer gets majority of PROMISE messages for a specific IDp:

• Safety and liveness of Paxos?

Department of Computer Science & Engineering

Lecture 29: Paxos – Safety and Liveness

• Two rounds of message exchanges

PREPARE 50 ACCEPT-REQUEST 50, "Movie"

PREPARE 50 ACCEPT-REQUEST 50, "Movie"

PREPARE 50 ACCEPT-REQUEST 50, "Movie"