Blockchains: Architecture, Design and Use Cases

BLOCKCHAINS
ARCHITECTURE, DESIGN AND USE CASES

PRAVEEN JAYACHANDRAN
SANDIP CHAKRABORTY IBM RESEARCH,
COMPUTER SCIENCE AND ENGINEERING, INDIA
IIT KHARAGPUR
1
Image courtesy: http://beetfusion.com/
CONSENSUS IN BITCOIN
2
Consensus in Bitcoin
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
Bitcoin Consensus Objective:

Tx15
Which block do we add next? Tx16
Tx17
Tx18
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
Bitcoin Consensus Objective:

Tx15
Which block do we add next? Tx16
Challenge: Tx17
Tx18
The miners do not know each other
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
Possible Solution: Tx15

Broadcast the information and then apply a choice Tx16
function – traditional distributed consensus Tx17
Tx18
algorithms
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
May not be Feasible: Tx15

You do not have a global clock! How much time Tx16
Tx17
will you wait to hear the transactions Tx18
Remember the impossibility result
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
Observation - 1: Tx15
• Any valid block (a block with all valid Tx16
Tx17
transactions) can be accepted, even if it is Tx18
proposed by only one miner
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
Observation - 2: Tx15
• The protocol can work in rounds Tx16
Tx17
• Broadcast the accepted block to the peers Tx18
• Collect the next set of transactions
Tx1 Tx6 Tx15

Tx11 Tx15
Tx2 Tx7 Tx16
Tx12 Tx16
Tx3 Tx8 Tx18
Tx13 Tx17
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10 ? ?
Solution:
• Every miner independently tries to solve a Tx15
Tx16
challenge Tx17
• The block is accepted for the miner who can Tx18
prove first that the challenge has been solved ?
Tx1 Tx6
Tx11 Note: This communication Tx15
Tx2 Tx7 Tx16
Tx3 Tx8
Tx12 can work asynchronously
Tx13 Tx17
Tx4 Tx9
Tx14
Tx5 Tx10
?
Tx15
Tx16 Tx15
Tx18 Tx16
Tx19 Tx17
I have the solution Tx18
SOL
?
Tx1 Tx6 Tx15 Tx15

Tx11
Tx2 Tx7 Tx16 Tx16
Tx12
Tx3 Tx8 Tx18 Tx17
Tx13
Tx4 Tx9 Tx19
Tx14
Tx5 Tx10
?
Tx15
Tx16 Tx15
Tx18 Tx16
Tx19 Tx17
I have the solution Tx18
SOL
?
Tx17
Tx1 Tx6 Tx15 Tx20
Tx11
Tx2 Tx7 Tx16 Note: Everyone Tx21
Tx12
Tx3 Tx8 Tx18 can see that Tx18 Tx22
Tx13
Tx4 Tx9 Tx19 and Tx19 have Tx23
Tx14
Tx5 Tx10 been committed, ?
but Tx17 has not
Tx17 been committed. Tx17
Tx20 Include that in Tx20
Tx21 the next round Tx21
Tx22 Tx22
Tx23
?
?
Proof of Work (Pow)
• An economic measure to deter service abuses by requiring some work
from the service requester (usually processing time by a computer)
• The idea came from Dwork and Naor (1992), to combat junk emails
– You have to do some work to send a valid email
– The attacker would be discouraged to send junk emails
Dwork, Cynthia; Naor, Moni (1993). "Pricing via Processing, Or, Combatting Junk Mail, Advances in
Cryptology". CRYPTO’92: Lecture Notes in Computer Science No. 740. Springer: 139–147.
Proof of Work (PoW) Features
• Asymmetry
– The work must be moderately hard, but feasible for the service
requester
– The work must be easy check for the service provider
• Service requesters will get discouraged to forge the work, but service
providers can easily check the validity of the work
Cryptographic Hash as the PoW
• Use the puzzle friendliness property of cryptographic hash function as
the work
– Given 𝑋𝑋 and 𝑌𝑌, find out 𝑘𝑘, such that 𝑌𝑌 = 𝐻𝐻𝐻𝐻𝐻𝐻𝐻(𝑋𝑋||𝑘𝑘)
– It is difficult (but not infeasible) to find such 𝑘𝑘
– However, once you have a 𝑘𝑘, you can easily verify the challenge
• Used in Hashcash, a proof of work that can be added with an email as a

“good-will” token Adam Back, "Hashcash - A Denial of Service Counter-Measure", technical
report, August 2002
Hashcash PoW
• A textual encoding of a hashcash stamp is included in an email header
– Proof that the sender has expended a modest amount of CPU time
calculating the stamp before sending the email
– It is unlikely that the sender is a spammer
• The receiver can verify the hashcash stamp very easily
• Any change in the header requires a change in the hashcash

– Brute force is the only way to find a hashcash
Hashcash PoW
• The hashcash is included in the email header, looks like this
X-Hashcash:
1:20:180401:sandipc@cse.iitkgp.ac.in::0000000267674
b591257b87:6078
• Version: number of zero bits in the hashed code: date: resource:

optional extension: string of random characters: counter
Hashcash PoW – Sender Side
• Construct the header
1:20:180401:sandipc@cse.iitkgp.ac.in::<hash>:<count
er>
• The sender initializes the counter value to a random number
• Compute 160 bit SHA-1 hash of the header.

– If the first 20 bit of the hash are all zeros, then it is accepted
– Else try with a different counter
Hashcash PoW – Recipient Side
• Recipient checks
– The date – should be within two days
– Email address
– The random string – should not be used repeatedly within a certain duration
(prevent replay)
• Compute the 160 bit SHA-1 hash of the entire received string
1:20:180401:sandipc@cse.iitkgp.ac.in::0000000267674b591257b87:6078
– If the first 20 bits are not zero then it is invalid
Hashcash PoW
• On average, the sender will have to try 220 hash values to find a valid
header (takes about a few seconds in a general purpose computer)
– There are 2160 possible hash values
– 20 zero bits at the beginning – 2140 possible hash values that satisfy
this criteria
– Chance of randomly selecting a header with 20 zero bits at the prefix is
1 in 220
• The recipient requires around 2 microsecond to validate

Bitcoin Proof of Work System
PH PH PH Tx17
Tx1 Tx6 BH: Block Hash Tx20
Tx11 PH: Previous Block Hash Tx21
Tx2 Tx7
Tx12 MR: Merkle Root Tx22
Tx3 Tx8
Tx13 Tx23
Tx4 Tx9 N: Nonce
Tx14
Tx5 Tx10 ?
N N N
Tx17
Tx17 BH should have certain zeros (difficulty) Tx20
Tx20 at the beginning Tx21
Tx21
Tx22
BH = Hash(PH:MR:N) Tx22
Tx23
? N=?
?
Bitcoin Proof of Work (PoW) System
• Most implementations of Bitcoin PoW use double SHA256 hash function
• The miners collect the transactions for 10 minutes (default setup) and
starts mining the PoW
• The probability of getting a PoW is low – it is difficult to say which miner

will be able to generate the block
– No miner will be able to control the bitcoin network single handedly
Explore …
• http://www.hashcash.org/
– Download the source and try with different numbers of zero
bit targets
– Increase the number of targeted zero bits at the hash prefix,
say from 20 to 2020, at a step of 100, and observe the time to
compute the hashcash
– Use sha1sum (in Linux) to compute the SHA-1 checksum of
the obtained hashcash values from the above experiment.
How much time do you require to validate a hashcash?
24
BLOCKCHAINS
IIT KHARAGPUR
1
POW AND BEYOND

2
Bitcoin Proof of Work (PoW)
• Based on Hashcash PoW system
– The miners need to give a proof that they have done some work, before
proposing a new block
– The attackers will be discouraged to propose a new block, or make a change
in the existing blocks
Tx17 Tx17
Tx17 Tx20 Tx20
Tx20 Tx21 Tx21
Tx21 Tx22 Tx22
Tx22 Tx23 Tx23
? ? ?
Bitcoin Proof of Work System
PH PH PH Tx17
Tx1 Tx6 BH: Block Hash Tx20
Tx11 PH: Previous Block Hash Tx21
Tx2 Tx7
Tx12 MR: Merkle Root Tx22
Tx3 Tx8
Tx13 Tx23
Tx4 Tx9 N: Nonce
Tx14
Tx5 Tx10 ?
N N N
Tx17
Tx17 BH should have certain zeros (difficulty) Tx20
Tx20 at the beginning Tx21
Tx21
Tx22
BH = Hash(PH:MR:N) Tx22
Tx23
? N=?
?
Bitcoin Proof of Work (PoW) System
• Most implementations of Bitcoin PoW use double SHA256 hash function
• The miners collect the transactions for 10 minutes (default setup) and
starts mining the PoW
• The probability of getting a PoW is low – it is difficult to say which miner

will be able to generate the block
– No miner will be able to control the bitcoin network single handedly
Tampering PoW Blockchain
Block 22 Block 23 Block 24

Prev_Hash Timestamp Prev_Hash Timestamp Prev_Hash Timestamp
Tx_Root Nonce Tx_Root Nonce Tx_Root Nonce
Curr_Hash Curr_Hash Curr_Hash
• The blockchain together contain a large amount of work

– The attacker needs to perform more work to tamper the blockchain
– This is difficult with the current hardware
Solving the Double Spending Problem
• The attack: Successful use of the same fund twice
– A transaction is generated with BTC10 to both
Bob and Carol at the same time
• The solution:
– The transactions are irreversible
(computationally impractical to modify)
– Every transaction can be validated against
the existing blockchain
Sybil Attacks
• Attacker attempts to fill the network with the clients under its control
– Refuse to relay valid blocks
– Relay only attacked blocks – can lead to double spending
• Solution:
– Diversify the connections – Bitcoin allows outbound connection to one
IP per /16 (a.b.0.0) IP address
Denial of Service (DoS) Attacks
• Send lot of data to a node – they will not be able to process normal Bitcoin
transactions
• Solutions:
– No forwarding of orphaned blocks
– No forwarding of double-spend transactions
– No forwarding of same block or transactions
– Disconnect a peer that sends too many messages
– Restrict the block size to 1 MB
– Limit the size of each script up to 10000 bytes
– …
Breaking Bitcoin PoW
• Bitcoin PoW is computationally difficult to break, but not impossible
• Attackers can deploy high power servers to do more work than the total
work of the blockchain
• A known case of successful double-spending

– (November 2013) “it was discovered that the GHash.io mining pool
appeared to be engaging in repeated payment fraud against BetCoin
Dice, a gambling site” [Source: https://en.bitcoin.it/]
The Monopoly Problem
• PoW depends on the computing resources available to a miner
– Miners having more resources have more probability to complete the
work
• Monopoly can increase over time (Tragedy of the Commons)

– Miners will get less reward over time
– Users will get discouraged to join as the miner
– Few miners with large computing resources may get control over the
network
PoW Power Consumption
Source: https://www.planetblockcha.in/2018/03/27/bitcoin-is-dead/
Handling Monopoly and Power Consumption - Proof of Stake (PoS)
• Possibly proposed in 2011 by a Member in Bitcoin Forum -

https://bitcointalk.org/index.php?topic=27787.0
– Make a transition from PoW to PoS when bitcoins are widely distributed
• PoW vs PoS
– PoW: Probability of mining a block depends on the work done by the
miner
– PoS: Amount of bitcoin that the miner holds – Miner holding 1% of the
Bitcoin can mine 1% of the PoS blocks.
Proof of Stake (PoS)
• Provides increased protection
– Executing an attack is expensive, you need more Bitcoins
– Reduced incentive for attack – the attacker needs to own a majority of
bitcoins – an attack will have more affect on the attacker
• Variants of “stake”
– Randomization in combination of the stake (used in Nxt and BlackCoin)
– Coin-age: Number of coins multiplied by the number of days the coins
have been held (used in Peercoin)
Proof of Burn (PoB)
• Miners should show proof that they have burned some coins
– Sent them to a verifiably un-spendable address
– Expensive just like PoW, but no external resources are used other than
the burned coins
• PoW vs PoB – Real resource vs virtual/digital resource
• PoB works by burning PoW mined cryptocurrencies

PoW vs PoS vs PoB
PoW PoS PoB
• Do some work to • Acquire sufficient stake • Burn some wealth to
mine a new block to mine a new block mine a new block
• Consumes physical • Consumes no external • Consumes virtual or
resources, like CPU resource, but participate digital resources,
power and time in transactions like the coins
• Power hungry • Power efficient • Power efficient
Proof of Elapsed Time (PoET)
• Proposed by Intel, as a part of Hyperledger Sawtooth – a blockchain
platform for building distributed ledger applications
• Basic idea:
– Each participant in the blockchain network waits a random amount of
time
– The first participant to finish becomes the leader for the new block
PoET over Trusted Environments
• How will one verify that the proposer has really waited for a random
amount of time?
– Utilize special CPU instruction set – Intel Software Guard Extension
(SGX) – a trusted execution platform
– The trusted code is private to the rest of the application
– The specialized hardware provides an attestation that the trusted code
has been set up correctly
Interesting Reads …
• Analysis of hashrate-based double-spending, by Meni Rosenfeld -
https://bitcoil.co.il/Doublespend.pdf
• The proposal of PoS - https://bitcointalk.org/index.php?topic=27787.0
• The Peercoin protocol - https://peercoin.net/assets/paper/peercoin-

paper.pdf
• Hyperledger Sawtooth - https://www.hyperledger.org/projects/sawtooth

20
BLOCKCHAINS
IIT KHARAGPUR
1
THE MINERS
2
The Life of a Miner
• Validate transactions and construct a block
• Use hash power to vote on consensus and commit transactions with a new
block
• Store and broadcast the blockchain to the peers

Mining Bitcoins
• Join the network and listen for transactions – validate the proposed
transactions
• Listen for new blocks – validate and re-broadcast a new block when it is
proposed
• Collect transactions for a predefined time and construct a new block

Mining Bitcoins
• Find a nonce to make the new block valid
• Broadcast the new block – everybody accepts it if it is a part of the main

chain
• Earn the reward for participating in the mining procedure

Mining Difficulty
• A measure of how difficult it is to fond a hash below a given target
– Bitcoin network has a global block difficulty
– Mining pools also have a pool-specific share difficulty
• The difficulty changes for every 2016 blocks

– Desired rate – one block each 10 minutes
– Two weeks to generate 2016 blocks
– The change in difficulty is in proportion to the amount of time over or
under two weeks the previous 2016 blocks took to find (en.bitcoin.it)
Setting the Difficulty
• Compute the following for every two weeks
current_difficulty = previous_difficulty *
(2 weeks in milliseconds)/(milliseconds to
mine last 2016 blocks)
Hash-rate versus Difficulty
• The hash is a random number between 0 and 2256-1
– To find a block, the hash must be less than a given target
• The offset for difficulty 1 is 0xffff * 2208
• The offset for difficulty D is 0xffff * 2208/D
• The expected number of hashes we need to calculate to find a block with

difficulty D is (D * 2256) / (0xffff * 2208)
Mining Difficulty
• Current difficulty: 3511060552899.72 (as of 2nd April, 2018)
– https://blockexplorer.com/api/status?q=getDifficulty
Mining Difficulty
Source: http://bitcoin.sipa.be/
Mining Hardware
• Specialized hardware
– GPU
– FPGA
• ASIC
– Released in 2013
– Fast computation of
SHA256
Image source:
https://steemkr.com/bitcoin/@pawank/bitcoin-mining
TerraMiner IV
• ASIC based bitcoin mining rig
• 2 Terahash per second
• Cost: USD 3500 approx
Mining Pool
• Pooling of resources by the miners
– Share the processing power over

a network to mine a new block
– Split the reward proportionally to

the amount of work they
contributed
Hash-rate Distribution: blockchain.info
Mining Pool Methods
• Contains hundreds or thousands of miners through special protocols
• 𝐵𝐵: Block reward minus pool fee
• 𝑝𝑝: Probability of finding a block in a share attempt (𝑝𝑝 = 1/𝐷𝐷), 𝐷𝐷 is the

block difficulty
Mining Pool Methods
• Pay per Share (PPS)
– Instant guaranteed payout to a miner
– Miners are paid from pool’s existing balance, share of a miner is
𝑅𝑅 = 𝐵𝐵 × 𝑝𝑝
– Miners get almost equal payment, risk is at the pool operator
Mining Pool Methods
• Proportional
– Miners earn share until the pool finds a block (end of mining round)
𝑛𝑛
– 𝑅𝑅 = 𝐵𝐵 × , where 𝑛𝑛 is amount of his own share, and 𝑁𝑁 is amount of
𝑁𝑁
all shares in the round
– Payments are made once a pool finds out a block
Mining Pool Methods
• Pay per Last N Share (PPLNS)
– Similar to proportional
– Miner’s reward is calculated on the basis of N last shares
– Miners get more profit for a short round
Mining Pools – Pros and Cons
• Pros
– Small miners can participate
– Predictable mining
• Cons
– Leads to centralization
– Discourages miners for running complete mining procedure
Summary – Permissionless Blockchain and Bitcoin
• The permissionless or open model of blockchain – any user can join the network
and participate in transactions
– Bitcoin is developed on this principle
• The blockchain provides the backbone of the permissionless digital currency

– Provides a decentralized architecture
– Tamper-proof through hash-chain
• Miners ensures the consensus in the system

20
BLOCKCHAINS
IIT KHARAGPUR
1
Image Source: https://nem.io/enterprise/
Permissioned Blockchain – I
Basics
2
Permissioned Model
• A blockchain architecture where users are authenticated apriory
• Users know each other
• However, users may not trust each other – Security and consensus are
still required.
• Run blockchain among known and identified participants

Use Cases
• Particularly interesting for business applications – execute contracts

among a closed set of participants
• Example: Provenance tracking of assets
Supplier Distributor Vendor Market
Auditor
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/
• Remember the bitcoin scripts – you can change the script to control
how the money that you are transferring to someone can be spend further
– Your friend can use that money immediately
– Your friend can use that money after 2 months
Smart Contracts
• You can extend the script to ensure smart contract execution

– Execute a transaction only when certain condition is satisfied
Source: http://www.scalablockchain.com/smartcontract.html
Design Limitations
• Sequential Execution
– Execute transactions sequentially based on consensus
– Requests to the application (smart contract) are ordered by the
consensus, and executed in the same order
– This give a bound on the effective throughput – throughput is
inversely proportional
– Can be a possible attack on the smart contract platform – introduce
contract which will take long time to execute
Design Limitations
• Non-deterministic Execution
– Consider golang – iteration over a map may produce a different order
in two executions
m := map[string]string{ "key1":"val1", "key2":"val2" };

for k, v := range m {
fmt.Printf("key[%s] value[%s]\n", k, v)
}
Design Limitations
• Non-deterministic Execution
– Smart-contract execution should always needs to be deterministic;
otherwise the system may lead to inconsistent states (many fork in
the blockchain)
– Solution: Domain specific language (DSL) for smart contract
Design Limitations
• Execution on all nodes

– Generally, execute smart contracts at all nodes, and propagate the
state to others – try to reach consensus
– Consensus: Propagate same state to all nodes, verify that the states
match
– Do you have sufficient numbers of trusted nodes to validate the
execution of smart contracts?
Do We Really Need to Execute Contracts at Each Node
• Not necessary always, we just need state synchronization across all

the nodes

the nodes Execute
Contract

the nodes Broadcast
State

the nodes Broadcast
State
• What if the node that executes the contract is faulty?

• Use state machine replication – execute contract at a subset of nodes,
and ensure that the same state is propagated to all the nodes
State Machine Replication
• State machine
– A set of states (S) based on the
system design
– A set of inputs (I)
– A set o outputs (O)
– A transition function 𝑆𝑆 × 𝐼𝐼 → 𝑆𝑆
– A output function 𝑆𝑆 × 𝐼𝐼 → 𝑂𝑂
– A start state
Image source: commons.wikimedia.org
Smart Contract State Machine - Crowd-Funding
Alice transferred
Bob transferred the committed
the committed Bob money Job 1 Job 1 Job 2
money donated done complete done
Initiate Money Job 1 & 2

Job Available Complete
Alice Job 2 Job 1 Jobs

Alice transferred Job 2
donated Complete done done
the committed Bob transferred done
money the committed
money Money
transferred
Distributed State Machine Replication
1. Place copies of the state machine on multiple independent servers

2. Receive client requests, as an input to the state machine

3. Propagate the inputs to all the servers

4. Order the inputs based on some ordering algorithm

4. Execute the inputs based on the order decided, individually at each

server
5. Sync the state machines across the servers, to avoid any failure.
6. If output state is produced, inform the clients about the output

Permissioned Blockchain and State Machine Replication
• 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
27
BLOCKCHAINS
IIT KHARAGPUR
1
Image Source: https://nem.io/enterprise/
Permissioned Blockchain - II
Consensus Algorithms
2
Why Distributed Consensus
One Decision No
Maker Consensus
Multiple Consensus
Decision Maker Required
• Reaching agreement in distributed computing
• Replication of common state so that all processes have same view
• Applications:
– Flight control system: E.g. Boeing 777 and 787
– Fund transferring system: Bitcoin and cryptocurrencies
– Leader election/Mutual Exclusion
• So, no need of consensus in a single node process.
• What about when there are two nodes?
• Network or partitioned fault, consensus cannot be reached
Faults in Distributed Consensus
• Crash Fault
• Network or Partitioned Faults
• Byzantine Faults
– malicious behaviour in nodes
– hardware fault
– software error
Consensus for three processes
• Each process Pi (i=1,2,...N):

– Undecided state: proposed
value vi from set D
– Communication state:
exchange values
– Decided state: set decision
variable di
Requirements of a Consensus Algorithm
• Termination:
– Eventually each correct process sets its decision variable
• Agreement:
– The decision value of all correct processes is the same
• Integrity:
– If the correct processes all proposed the same value, then any
correct process in the decided state has chosen that value
Different Algorithms
• Crash or Network Faults:
• PAXOS
• RAFT
• Byzantine Faults (including Crash or Network Failures):

• Byzantine fault tolerance (BFT)
• Practical Byzantine Fault Tolerance (PBFT)
PAXOS
• First Consensus Algorithm

proposed by L. Lamport in 1989
• Objective: choosing a single
value under crash or network
fault
• System process
– Making a proposal
– Accepting a value
Source: Lamport, Leslie. "Paxos made simple." ACM Sigact News 32.4 (2001): 18-25. – Handling Failures
PAXOS: Types of Nodes
• Proposer: propose values

that should be chosen by the
consensus
• Acceptor: form the
consensus and accept values
• Learner: learn which value
was chosen by each
acceptor
Making a Proposal: Proposer Process
• proposal number: form a

timeline, biggest number
considered up-to-date
Making a Proposal: Acceptor’s Decision Making
• Each acceptor compares

received proposal number
with the current known
values for all proposer’s
prepare message
Making a Proposal: Acceptor’s Message
• accept/decline: whether
prepare accepted or not
• proposal number: biggest
number the acceptor has
seen
• accepted values: already
accepted values from other
proposer
Accepting a Value: Proposer’s Decision Making
• Proposer receive a
response from majority
of acceptors before
proceeding
Accepting a Value: Accept Message
• proposal number:
same as prepare phase
value
• value: single value
proposed by proposer
Accepting a Value: Notifying Learner
• Each acceptor accept

value from any of the
proposer
• Notify learner the
majority voted value
Single Proposer: No Rejection
• Proposer always have

proposal with biggest
number
• No proposal rejected
Handling Failure: Acceptor Failure
• Acceptor fails during

prepare
• No issues, other
acceptor can hear
the proposal and
vote
• Acceptor fails during

accept
• Again, no issues,
other acceptor can
vote for the proposal
• More than N/2 - 1

acceptors fail
– no proposer get a
reply
– no values can be
accepted
Handling Failure: Proposer Failure
• Proposer fails during

prepare phase
• Acceptors wait, wait, wait,
and then someone else
become the proposer
Handling Failure: Proposer Failure
• Proposer fails during accept

phase
• Acceptors have already
agreed upon whether to
choose or not to choose
the proposal
Handling Failure: Dueling Proposers
• Proposer received confirmations

to her prepare message from
majority
– yet to send accept messages
• Another proposer sends prepare
message with higher proposal
number
• Block the first proposer’s
proposal from being accepted
Handling Failure: Dueling Proposers
• Use leader election - select one

of the proposer as leader
• Paxos can be used for leader

election !!
27

Blockchains: Architecture, Design and Use Cases

Uploaded by

Document Information

Original Description:

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

Blockchains: Architecture, Design and Use Cases

Uploaded by

Copyright:

Available Formats

BLOCKCHAINS

ARCHITECTURE, DESIGN AND USE CASES

Tx1 Tx6 Tx15

Bitcoin Consensus Objective:

Tx1 Tx6 Tx15

Bitcoin Consensus Objective:

Tx1 Tx6 Tx15

Possible Solution: Tx15

Tx1 Tx6 Tx15

May not be Feasible: Tx15

Tx1 Tx6 Tx15

Tx1 Tx6 Tx15

Tx1 Tx6 Tx15

Tx1 Tx6 Tx15 Tx15

• Used in Hashcash, a proof of work that can be added with an email as a

• The receiver can verify the hashcash stamp very easily

• Any change in the header requires a change in the hashcash

• Version: number of zero bits in the hashed code: date: resource:

• The sender initializes the counter value to a random number

• Compute 160 bit SHA-1 hash of the header.

• The recipient requires around 2 microsecond to validate

• The probability of getting a PoW is low – it is difficult to say which miner

POW AND BEYOND

• The probability of getting a PoW is low – it is difficult to say which miner

Block 22 Block 23 Block 24

Tx_Root Nonce Tx_Root Nonce Tx_Root Nonce

Curr_Hash Curr_Hash Curr_Hash

• The blockchain together contain a large amount of work

• A known case of successful double-spending

• Monopoly can increase over time (Tragedy of the Commons)

• Possibly proposed in 2011 by a Member in Bitcoin Forum -

• PoW vs PoB – Real resource vs virtual/digital resource

• PoB works by burning PoW mined cryptocurrencies

• The proposal of PoS - https://bitcointalk.org/index.php?topic=27787.0

• The Peercoin protocol - https://peercoin.net/assets/paper/peercoin-

• Hyperledger Sawtooth - https://www.hyperledger.org/projects/sawtooth

• Store and broadcast the blockchain to the peers

• Collect transactions for a predefined time and construct a new block

• Broadcast the new block – everybody accepts it if it is a part of the main

• Earn the reward for participating in the mining procedure

• The difficulty changes for every 2016 blocks

• The offset for difficulty 1 is 0xffff * 2208

• The offset for difficulty D is 0xffff * 2208/D

• The expected number of hashes we need to calculate to find a block with

– Share the processing power over

– Split the reward proportionally to

• 𝐵𝐵: Block reward minus pool fee

• 𝑝𝑝: Probability of finding a block in a share attempt (𝑝𝑝 = 1/𝐷𝐷), 𝐷𝐷 is the

• The blockchain provides the backbone of the permissionless digital currency

• Miners ensures the consensus in the system

• A blockchain architecture where users are authenticated apriory

• Users know each other

• Run blockchain among known and identified participants

• Particularly interesting for business applications – execute contracts

• Example: Provenance tracking of assets

Supplier Distributor Vendor Market

• “A self executing contract in which the terms of the agreement between

• You can extend the script to ensure smart contract execution

m := map[string]string{ "key1":"val1", "key2":"val2" };

• Execution on all nodes

• Not necessary always, we just need state synchronization across all

• Not necessary always, we just need state synchronization across all