Byzantine Problem in Distributed System

Multiple nodes have their own copy of shared ledger

Nodes must agree on state of ledger
Some of the nodes are malicious or faulty
Non-faulty/honest nodes must reach consensus
despite of faulty nodes
Challenge!!
To design a consensus algorithm that ensures that the
honest nodes can agree on the state of the ledger even
in the presence of Byzantine (faulty or malicious) nodes.
crucial to maintaining the integrity and security of the
blockchain ledger.
PBFT (Practical Byzantine Fault Tolerance)
• This algorithm withstand the presence of Byzantine nodes and
reach a consensus on the state of the ledger in a decentralized
and secure manner.
Applications:
Permissioned Blockchain
 IBM’s Open chain
 Hyperledger
PBFT (Practical Byzantine Fault Tolerance)

•Asynchronous distributed
system
-delay, out of order message

•Byzantine failure handling

-Arbitrary node behavior

•Privacy
-tamper proof message
-authentication
PBFT (Practical Byzantine Fault Tolerance)
• A state machine is replicated across different nodes
• 3f+1 replicas are there, where f is the number of
faulty replicas
• Replicas moves through a succession of
configurations, known as views
• One replica on view is primary and others are
backups
• Views are changed when primary is detected as
faulty
• Every view has unique integer number ‘v’
PBFT
Client initiates transaction, This
client request moves to the
primary

Primary multicasts the request to

backups
PBFT
Backups execute a request
and send reply to the client

In case of blockchain, backups

checks for validity of transaction

Commit/failure message will

be sent
Client waits for f+1 replies from
different backups with the same
result

f is maximum number of faulty

replicas that can be tolerated
 PBFT
3 phases:
1. Pre-prepare: Primary assigns a sequence number n
to request and multicast a message
<<PRE-PREPARE, v, n, d > б –p, m > to all backups
 v is current view number
 n is message sequence number
 d is the message digest
 б –p is the private key of primary – works as digital
signature
 m is message to transmit
 PBFT
 A backup accepts a pre-prepare message if
 Signature is correct and d is the digest for m
 Backup is in the view v
 It has not received a different PRE-PREPARE message
with sequence n and view v with different digest
 The sequence number is within a threshold
2. Prepare phase:
 PBFT
2. Prepare phase:
Replicas agree on the assigned sequence number
If backups accepts the Pre-prepare message, it enters
prepare phase by multicasting a message
< PREPARE, v, n, d, I > б –I to all other replicas
A replica (both primary and backups) accepts prepare
message if:
 Signatures are correct
 View number is equal to current view
 Sequence number is within a threshold
 PBFT
• Commits a message if:
• 2f prepares from different backups matches with corresponding
preapre
• You have total 2f+1 votes(one from primary that already have)
from non-faulty replicas

Why do we require 3f+1 replicas to ensure safety in asynchronous

system when there are f faulty nodes?

 If you have 2f+1 replicas, you need all votes to decide

majority
 You may not receive votes from certain replicas due to
delay, in case of asynchronous system
 F+1 does not ensure majority (may be you have received
f votes from byzantine nodes and just 1 vote from a non-
faulty node)
 PBFT
• Majority can be decided once 2f+1 votes are received – even
if f are faulty, you know f+1 are from correct nodes, donot
care about remaining f votes
• At the end every node multicast a commit message :
Multicast< COMIT, v, n, d, i> б –I message to all replicas including
primary

• Commit a message when a replica

 Has sent a commit message itself
 Has received 2f+1 commit including its own