CST 428 BLOCK CHAIN TECHNOLOGIES

S8 CSE – ELECTIVE
MODULE – 3

Consensus Algorithms and

Bitcoin
 Consensus Problem
● Distributed systems are classified into two main categories,
namely message passing and shared memory
● In the context of blockchain, we are concerned with the
message passing type of distributed systems, where
participants on the network communicate with each other via
passing messages to each other
 The Byzantine generals problem
● problem of reaching agreement in the presence of faults or
Byzantine consensus
● In distributed systems, a common goal is to achieve
consensus (agreement) among nodes on the network even in
the presence of faults
● fundamental requirement in a consensus mechanism is that it
must be fault-tolerant
 The Byzantine generals problem
● it must be able to tolerate a number of failures in a network
and should continue to work even in the presence of faults
● Based on the requirement of fault tolerance, consensus
algorithms are also called fault-tolerant algorithms, and there
are two types of fault-tolerant algorithms
● Crash fault-tolerance (CFT) and the other is Byzantine
fault-tolerance (BFT)
 CFT algorithms
● One of the most fundamental algorithms in this space is
Paxos
● Paxos - developed by Leslie Lamport
○ allowing consensus over a value under unreliable
communications
○ makes use of 2F + 1 processes to ensure fault tolerance
in a network
 Paxos
● Nodes are assigned values :-
● Proposer (Elected Leader)
● Acceptor
● Learner
● Consensus achieved in presence of faulty nodes by
agreement among majority of nodes
● Paxos can tolerate one crash failure in a three-node
network
 Paxos
● Paxos is a two-phase protocol - prepare phase and accept
phase
● Participants - proposer and acceptors
● Proposer nodes proposes values and Acceptor nodes
accepts values
● protocol assumes an asynchronous message-passing
network with less than 50% of crash faults
 Paxos
● the critical properties of the Paxos consensus algorithm are
safety and liveness
● Under safety, we have:
○ Agreement, which specifies that no two different values
are agreed on
○ Validity, which means that only the proposed values are
decided. In other words, the values chosen or learned
must have been proposed by a processor
 Paxos
● Under liveness, we have:
○ Termination, which means that, eventually, the protocol is
able to decide and terminate. In other words, if a value
has been chosen, then eventually learners will learn it
● Processes can assume different roles
○ Proposers, elected leader(s) that can propose a new
value to be decided
Paxos
● Acceptors, which participate in the protocol as a means to
provide a majority decision
● Learners, which are nodes that just observe the decision
process and value
 Paxos

● Proposer node proposes a value, which is considered final only if a

majority of the acceptor nodes accept it
● Learner nodes learn this as a final decision
● Similar to Two Phase Commit protocol, even if a single node,
cannot agree to commit, it is fully rolled back. (But here majority
based acceptance)
Paxos

<prepare(n)>

<ack(n, v, s)> <accept(n, v)> <accepted(n, v)>

 Paxos – Key points

● First, a proposer suggests a value with the aim that acceptors

achieve agreement on.
● The decided value is a result of majority consensus among the
acceptors and is finally learned by the learners.
 RAFT

● Node belongs to one of three states :-

● Follower
● Candidate
● Leader
• Leader is elected after a candidate node receives enough votes
• All changes go through leader
• Leader commits proposed changes once replication on majority of
follower nodes is completed.
RAFT
● developed by Diego Ongaro and John Ousterhout at Stanford
University
● composed of three sub-problems:
○ Leader election (a new leader election in case the existing
one fails)
○ Log replication (leader to follower log synch)
○ Safety (no conflicting log entries (index) between servers)
RAFT
● Each server in Raft can have either a follower, leader, or
candidate state
 RAFT

● the log (data) is eventually replicated across all nodes

● leader is responsible for log replication
● Once the leader has a new entry in its log, it sends out the
requests to replicate to the follower nodes
 RAFT

● When the leader receives enough confirmation votes back from

the follower nodes indicating that the replicate request has been
accepted and processed by the followers, the leader commits
that entry to its local state machine
● At this stage, the entry is considered committed
Byzantine fault- tolerance (BFT) algorithms
1. Practical Byzantine Fault Tolerance
(PBFT)
● developed in 1999 by Miguel Castro and Barbara Liskov
● to provide consensus in the presence of Byzantine faults
● comprises three sub-protocols called normal operation, view
change, and checkpointing
○ Normal operation is executed when everything is running normally and
no errors are in the system
○ View change is runs when a faulty leader node is detected in the
system
○ Checkpointing is used to discard the old data from the system
1. Practical Byzantine Fault Tolerance
(PBFT)
● comprises three phases or steps
● pre-prepare, prepare & commit
● The protocol runs in rounds
● In each round, an elected leader node, called the primary
node, handles the communication with the client
● the protocol progresses through the three previously
mentioned phases
1. Practical Byzantine Fault Tolerance
(PBFT)
● when a client sends a request to a primary, the protocol
initiates a sequence of operations between replicas
● This leads to consensus and a reply back to the client
● Each replica maintains local state comprising 3 elements :
● Service state
● Message Log
● Number representing replicas current view
1. Practical Byzantine Fault Tolerance
(PBFT)
● participants in the PBFT protocol are called replicas
● one of the replicas becomes primary as a leader in each
round, and the rest of the nodes acts as backups
● in order to tolerate Byzantine faults, the minimum number of
nodes required is N = 3F + 1, where N is the number of nodes
and F is the number of faulty nodes
● PBFT ensures Byzantine fault tolerance as long as the
number of nodes in a system stays N >= 3F + 1
1. Practical Byzantine Fault Tolerance
(PBFT)
1. Practical Byzantine Fault Tolerance
(PBFT)
● The algorithm for the view-change protocol is shown as
follows:
1. Stop accepting pre-prepare, prepare, and commit
the collection of

messages for the current view 2F + 1 messages of a

particular type is a
certificate

2. Create a set of all the certificates prepared so far

3.Broadcast a view-change message with the next view
number and a set of all the prepared certificates to all replicas
1. Practical Byzantine Fault Tolerance
(PBFT)
● view-change protocol
1. Practical Byzantine Fault Tolerance
(PBFT)
● Check Pointing
○ to discard old messages in the log of all replicas
○ replicas agree on a stable checkpoint that provides a
snapshot of the global state at a certain point in time
○ variable called low watermark is used to record the
sequence number of the last stable checkpoint
1. Practical Byzantine Fault Tolerance
(PBFT)
● Check Pointing
○ This checkpoint is then broadcast to other nodes
○ As soon as a replica has at least 2F+1 checkpoint
messages, it saves these messages as proof of a stable
checkpoint
○ It discards all previous pre-prepare, prepare, and commit
messages from its logs
1. Practical Byzantine Fault Tolerance
(PBFT)
● Advantages
○ provides immediate and deterministic transaction finality
○ energy efficient as compared to PoW
● Disadvantages
○ not very scalable - more suitable for consortium networks,
instead of public blockchains
○ faster than PoW protocols
○ Sybil attacks can be carried out
Nakamoto consensus or PoW
● first introduced with Bitcoin in 2009
● Longest-running blockchain network
● the PoW mechanism is designed to mitigate Sybil attacks,
which facilitates consensus and the security of the network
Nakamoto consensus or PoW

PoW makes use of hash puzzles.

Nakamoto consensus or PoW
Nakamoto consensus or PoW
● key idea behind PoW as a solution to the Byzantine generals
problem is that all honest generals (miners in the Bitcoin
world) achieve agreement on the same state (decision value)
● As long as honest participants control the majority of the
network, PoW solves the Byzantine generals problem
Nakamoto consensus or PoW
● two main variants of PoW algorithms, based on the type of
hardware used for processing
○ CPU-bound PoW - processing required to find the solution
to the cryptographic hash puzzle is directly proportional to
the calculation speed of the CPU or hardware such as
ASICs
Nakamoto consensus or PoW
○ Memory-bound PoW - performance is bound by the
access speed of the memory or the size of the memory
Proof of stake (PoS)
● energy-efficient alternative to the PoW
● first used in Peercoin, and now, prominent cryptocurrency
blockchains such as EOS, NxT, Steem, and Tezos are using
PoS algorithms
● stake represents the number of coins (money) in the
consensus protocol staked by a blockchain participant
Proof of stake (PoS)
● key idea is that if someone has a stake in the system, then
they will not try to sabotage the system
● the chance of proposing the next block is directly proportional
to the value staked by the participant
● Variations of PoS - chain-based PoS, committee-based PoS,
BFT-based PoS, delegated PoS, leased PoS, and master
node PoS
Proof of stake (PoS)
● PoS miner is called either a validator, minter, or stakeholder
● right to win the next proposer role is usually assigned
randomly
● Proposers are rewarded either with transaction fees or block
rewards
● control of a large portion of the stake is required to attack and
control the network
Proof of stake (PoS)
Proof of stake (PoS) types
● very similar to PoW
● only change is the block generation method
● Transactions are picked up from the memory pool
1
Chain- and a candidate block is created
based ● Hash (B || clock time) < target x stake value
PoS ● hashing puzzle in PoS is solved at regular intervals
based on the clock tick

● group of stakeholders is chosen randomly,

using a verifiable random function (VRF)
Committe ● VRF produces a random set of stakeholders
2 based on their stake and the current state of
e- based
the blockchain
PoS
● The chosen group of stakeholders becomes
responsible for proposing blocks in sequential
Proof of stake (PoS) types
● Instead of using a random function to derive
the group of stakeholders, the group is
chosen by stake delegation
● group selected is a fixed number of
Delegate minters that create blocks in a round-
3 d PoS robin fashion
● Delegates are chosen via voting by
network users
● Votes are proportional to the amount of the
stake that participants have on the
network
● used in Lisk, Cosmos, and EOS
Bitcoin definition
● defined in various ways; it's a protocol, a digital currency, and
a platform
● It is a combination of a peer-to-peer network, protocols, and
software that facilitates the creation and usage of the
digital currency
● Nodes in this peer-to-peer network talk to each other using the
Bitcoin protocol
Bitcoin definition
● The double-spending problem arises when, a user sends
coins to two different users at the same time and they are
verified independently as valid transactions
● resolved in Bitcoin by using a distributed ledger (the
blockchain) where every transaction is recorded permanently,
and by implementing a transaction validation and confirmation
mechanism
 Bitcoin
Payment
Payment request is initiated through
mail or SMS with address
Bitcoin
Payment
 Bitcoin
Payment
● fee is calculated based on size of the
transaction and a fee rate, which is a
value that depends on the volume of
the transactions in the network at
that time
● This is measured in Satoshis per
byte
● Bitcoin network fees ensure that your
transaction will be included by miners in
the block
●
 Bitcoin
Payment
● transaction has been constructed, signed,
and sent out to the Bitcoin network
● This transaction will be picked up by miners to
be verified and included in the block
● confirmation is pending for this transaction
● These confirmations will start to appear as
soon as the transaction is verified, included in
the block, and mined
● the appropriate fee will be deducted from the
original value to be transferred and will be paid
to the miner who has included it in the block
for mining
Bitcoin Payment

size of the transaction in bytes.

Bitcoin
Payment
Bitcoin
Payment
Cryptographic Keys used in Bitcoin
● possession of Bitcoins and the transfer of value via
transactions are reliant upon private keys, public keys, and
addresses
● Elliptic Curve Cryptography (ECC) is used to generate public
and private key pairs
Private Keys used in Bitcoin
● to be kept safe and normally reside only on the owner's side
● used to digitally sign the transactions, proving ownership of
the bitcoins
● fundamentally 256-bit numbers randomly chosen in the range
specified by the SECP256K1 ECDSA curve
recommendation
● usually encoded using Wallet Import Format (WIF) in order to
make them easier to copy and use
Private Keys used in Bitcoin
● It is a way to represent the full-size private key in a different
format
● WIF can be converted into a private key and vice versa
Private Keys used in Bitcoin
● mini private key format is sometimes used to create the
private key with a maximum of 30 characters in order to allow
storage where physical space is limited
● The first character of the mini private key is always the
uppercase letter S
● A mini private key can be converted into a normal-sized
private key, but an existing normal-sized private key cannot be
converted into a mini private key (Mini Key)
Public keys in Bitcoin
● Public keys are derived from private keys due to their special
mathematical relationship with those private keys
● Once a transaction signed with the private key is broadcast on
the Bitcoin network, public keys are used by the nodes to
verify that the transaction has indeed been signed with the
corresponding private key
● This process of verification proves the ownership of the bitcoin
Public keys in Bitcoin
● makes use of an Elliptic Curve Digital Signature Algorithm
(ECDSA) to ensure that funds remain secure and can only be
spent by the legitimate owner
Addresses in Bitcoin
● Bitcoin address is created by taking the corresponding public
key of a private key and hashing it twice.
● The resultant 160-bit hash is then prefixed with a version
number and finally encoded with a Base58Check encoding
scheme
● The Bitcoin addresses are 26-35 characters long and begin
with digits 1 or 3
Addresses in Bitcoin
● Addresses are also commonly encoded in a QR code for easy
distribution
Transactions
● Each transaction is composed of at least one input (coins
being spent created in previous transactions) and one output
(coins being created)
● If a transaction is minting newcoins , then there is no input
and no signature is needed.
● If a transaction is sending coins to another user, then it
needs to be signed with senders private key
 The Transaction Life Cycle (Lifecycle of a BitCoin Transaction)
1. A user/sender sends a transaction using wallet software or some other
interface.

2. The wallet software signs the transaction using the sender's private key.

3. The transaction is broadcasted to the Bitcoin network using a flooding

algorithm.

4. Mining nodes (miners) who are listening for the transactions verify and
include this transaction in the next block to be mined. Just before the
transactions are placed in the block, they are placed in a special memory
buffer called the transaction pool.
 The Transaction Life Cycle (Lifecycle of a BitCoin Transaction)

5. Next, the mining starts, which is the process through which the
blockchain is secured and new coins are generated as a reward for the
miners who spend appropriate computational resources. Once a miner
solves the PoW problem, it broadcasts the newly mined block to the
network. The nodes verify the block and propagate the block further,
and confirmations start to generate.
 The Transaction Life Cycle (Lifecycle of a BitCoin Transaction)

6. Finally, the confirmations start to appear in the receiver's wallet and

after approximately three confirmations, the transaction is considered
finalized and confirmed. However, three to six is just a recommended
number; the transaction can be considered final even after the first
confirmation. The key idea behind waiting for six confirmations is that
the probability of double spending is virtually eliminated after six
confirmations
Transaction Pool (Memory Pool)
● To maintain temporary list of transactions that had not been
added to block yet.
● Miners pick transactions from these memory pools to
create candidate blocks
● This is done after they pass verifications and validity
checks
● Selection of which transactions to select is based on the
fee and their place in the order of transactions in the pool
Coinbase Transaction
● Coinbase/Generation transaction is the first transaction in a
block.
● Usually used to create new coins.
● Coinbase transaction input has same number of fields as a
usual transaction i/p.
● It does not have a reference pointer to the previous
transaction
Coinbase Transaction
Blockchain (Bitcoin Perspective)
Blockchain (Bitcoin Perspective)

Data structure
of a block
header
Blockchain (Bitcoin Perspective)
 Genesis Block

● First block in bitcoin blockchain (Created on January 3rd 2009)

● Block height is the number of blocks before a particular block in the
blockchain.
● Stale blocks are old blocks that are already mined
● They exists on shorter chain and will not provide any reward to miner.
● Orphan blocks – parents are unknown, so they cant be validated
● Occurs when two or more miners discover a block almost at the same
time.
Blockchain (Bitcoin Perspective)
 Fork
● Condition that occurs when two different versions of blockchain exists.
● Types :-
 Temporary Forks
 Soft Forks
 Hard Forks
 Mining
● Process by which hnew blocks are added to blockchain
● Task of Miners:-
 Synching up with network
 Transaction Validation
 Block Validation
 Create a new block
 Perform PoW
 Fetch reward
Mining Algorithm
Mining Process