ADVANCED TOPIC IN INFORMATION SECURITY

1
BLOCKCHAIN CONSNSUS
PROTOCOLS
LECTURE 9

Dr. IMRAN MAKHDOOM

 TOPICS
❑ Intro to consensus protocols
❑ TX validation rules (Bitcoin & Ethereum)
❑ Consensus protocols comparison
❑ Bitcoin-NG
❑ PBFT vs PoW
❑ IoTA
❑ Gap Analysis
❑ Requirements for IoT systems
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 2
 INTRO TO CONSENSUS PROTOCOLS
Two General Approaches to Consensus
❑ Nakamoto consensus, that elects a leader through some form of
“lottery”
❑ Traditional Byzantine Fault Tolerance (BFT) algorithms that use
multiple rounds of explicit votes to achieve consensus

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 3

 INTRO TO CONSENSUS PROTOCOLS Contd..

❑ Bitcoin Blockchain introduced the world to the whole new

concept of unforgeable distributed ledgers
❑ Implemented PoW (Hash Puzzle based lottery)
❑ Two stages of consensus
⮚ Leader is elected through lottery
⮚ Leader mines a Block

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 4

 INTRO TO CONSENSUS PROTOCOLS Contd..

❑ Other nodes validate the Block and TXs and vote in favor of the
block by extending the chain by creating a new block by
referring to the previous one
❑ If the consensus could not be achieved over previous block,
chain will be forked and ultimately the longest chain will be
accepted

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 5

 TX VALIDATION RULES
Bitcoin TXs
❑ In bitcoin the state is the collection of all UTXO and it does not
store address balances, rather balances are stored in the
wallet.
❑ The Validation of transactions in a block is based on the global
history of past transactions

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 6

 TX VALIDATION RULES Contd..

Bitcoin TX Validation

✔ Format of the TX

✔   been previously spent

Input of the TX has not

✔ The signatures are of the real owner

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 7

 TX VALIDATION RULES Contd..

Bitcoin Block Validation

❑ Miners are not the only nodes on the Bitcoin network that
validate transactions.
❑ Full nodes, which relay transactions through the network, also
perform checks to ensure transactions are valid before relaying
them to other nodes.
❑ An adversary may have a very hard time even getting his
invalid transaction to a mining node, let alone having it
included in a block

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 8

 TX VALIDATION RULES Contd..

Bitcoin Block Validation

✔ The previous block referenced in latest block, exists

✔ Timestamp is greater than that of the previous block

 

✔ Nonce and the resultant Block hash are valid

✔ All TXs in the block provide valid state transitions

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 9

 TX VALIDATION RULES
Ethereum TXs
❑ State comprises accounts (nonce, balance, contract code, and
account’s storage)
❑ The Ethereum Blockchain stores the record of all the
transactions that update the state of the accounts
❑ Along with the TXs, the Ethereum blockchain also stores the
account balances and the contract codes (smart contracts)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 10

 TX VALIDATION RULES Contd..

Ethereum TXs
❑ To mine a block in Ethereum, miners fetch random slices of data
from the state, compute some randomly selected transactions
from the previous N blocks in the blockchain, and return the hash
of the result
❑ The miner and full nodes need to store the entire state with each
block, moreover these nodes also validate the smart contracts by
executing them during TX validation

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 11

 TX VALIDATION RULES Contd..

Ethereum TX Validation

✔ TX is a well formed RLP

✔ Valid Signature

✔ Valid nonce  

✔ TX gas limit > Intrinsic gas used by the TX

✔ TX sender’s account balance > gas price / cost of the TX

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 12

 TX VALIDATION RULES Contd..

Ethereum Block Validation

✔ Time stamp > the time stamp of previous block

✔ Previous block referenced in the latest block is valid
✔ Valid block parameters (height, difficulty, TX root, etc)
✔ Valid PoW  

✔ There is no error in any application

✔ GasLimit > Total gas consumed during execution
✔ Merkle Root Hash of final state == Final state root in the block header

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 14

 CONSENSUS PROTOCOLS
Properties of Consensus Algorithm
❑ Termination: All non-faulty nodes/processes eventually decide on a value
❑ Agreement : All correct processes decide on a same value
❑ Validity: The value that has been decided must have been proposed by some
process i.e if all processes propose the same value ‘v’ then all correct processes
decide v
❑ Consensus Finality
❑ Fairness: The function should distribute leader election across the broadest
possible population of participants
❑ Investment: The cost of controlling the leader election process should be
proportional to the value gained from it
❑ Verification: It should be relatively simple for all participants to verify that the
leader was legitimately selected

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 15

 CONSENSUS PROTOCOLS
Practical Byzantine Fault Tolerance (PBFT)
❑ Except PBFT, rest of the consensus algorithms have been developed
for digital currencies
❑ Although PBFT is efficient than PoW, yet it can only tolerate 33%
malicious nodes
❑ Moreover, it is also not being used for IoT-specific applications. For
e.g., Hyperledger uses PBFT but it provides Blockchain-based
services to all types of users such as financial, healthcare and
industrial organizations
❑ In addition, PBFT is considered to be an expensive algorithm with
respect to number of messages required for consensus

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 16

 CONSENSUS PROTOCOLS
Practical Byzantine Fault Tolerance (PBFT)
❑ For m faulty nodes the consensus algorithm requires 3m+1 total
nodes, 2m+1 communication paths connecting each node
❑ It is obvious that with increase in number of faulty nodes, the
number of total nodes, required number of communication paths
connectingThe
each nodeofand
number the
faulty number
nodes of rounds
and total numberofof messages
network for
validation will greatly
nodes increase
require to reach an agreement, has to be pre-
determined

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 17

 CONSENSUS PROTOCOLS
Practical Byzantine Fault Tolerance (PBFT)
▪ For 1 client, 4 replicas
(1 x primary and 3
backups)
▪ 5 x rounds of
messages
▪ 4 x msgs Rd-1
▪ 3 x Msgs Rd-2
▪ 9 x msgs rd-3
▪ 12 x msgs rd-4
▪ 4 x msgs rd-5,
▪ Total 32 messages for
a single service
request
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 18
 CONSENSUS PROTCOLS
IOTA TENDERMINT HONEYBAD- DBFT PBFT PoW PoS PoET
GER BFT
Distributed Sys Fintech Fintech Distributed Sys Distributed Sys Fintech Fintech Distributed Ledger
No Ldr (Every Round Robin Round Robin Round Robin Round Robin Leader Election by Leader Election Leader Election by
Node validates 2 x Leader Election Leader Election Leader Election Leader Election Hash Puzzle based on Coinage least wait time
previous TXs)
Prevents Double Prevents Double Prevents Double Prevents Double Prevents Double Prevents Double Prevents Double
Prevents Double Spending Spending Spending Spending Spending Spending Spending
Spending
Avoids Sybil Avoids Sybil Avoids Sybil Avoids Sybil Mitigates Sybil Mitigates Sybil Sybil Attack
Avoids Sybil Attack Attack Attack Attack
Attack Attack Attack not given
Public Nodes are Known Nodes are Known Nodes are Known Nodes are Known Public Participation Public Participation Public Participation
Participation
Low Energy & High Computation Low Energy & Low Energy & High Energy & Low Energy & Low Energy &
Low Energy & Computation Costs vs other BFT Computation Computation Computation Costs Computation Costs
Computation Costs Protocols Costs Costs Computation Costs
Costs
Low Latency Low Latency Low Latency Low Latency High Latency Low Latency Low Latency
Low Latency (No
Fee, Parallelized Avoids 51% Avoids 51% Avoids 51% Avoids 51%
Consensus) 51% Attacks 51% Attacks Avoids 51% Attacks
Attacks Attacks Attacks Attacks
No voting req Vulnerable to Vulnerable to Vulnerable to Vulnerable to Dishonest Malicious Collusion Trust is Placed in
malicious nodes > malicious nodes > malicious nodes > malicious nodes > Computing Power of Rich the Enclave that
Avoids Quantum (n-1)/3 (n-1)/3 (n-1)/3 (n-1)/3 > ¼ (Network) Stakeholders Allocates Wait Time
Computing
Attacks No Special H/W No Special H/W No Special H/W Req Special H/W No Special H/W Req Special H/W
No Special H/W
No Special H/W
Consensus Finality Consensus Finality Consensus Finality Consensus Finality Lack of Consensus Lack of Consensus Lack of Consensus
Lack of Consensus Finality Finality Finality
Finality
No Forks No Forks No Forks No Forks Prone to Forks Prone to Forks Prone to Forks
Prone to Forks
Low Comm Low Comm Low Comm High Comm
Low Comm Complexity Complexity Complexity Complexity Legend Legend
Complexity Req - Require Sys – System
Vulnerable to DoS Asynchronous BFT Vulnerable to DoS Vulnerable to DoS
Attack Attack Attack H/W- Hardware Comm – Communication
Suitable for
Asynch Networks PoW – Proof of Work Asynch – Asynchronous
Poor Scalability Poor Scalability Poor Scalability Poor Scalability
w.r.t No of w.r.t No of w.r.t No of w.r.t No of PoS – Proof of Stake
Addresses TX Validating Nodes Validating Nodes Validating Nodes Validating Nodes PoET – Proof of Elapsed Time
Scalability
Punishment for
Validating Nodes
 CONSENSUS PROTOCOLS
Bitcoin-NG
❑ Major problem with Blockchain protocols
⮚ Scalability
❑ The rate of transactions processing is limited due to two factors
⮚ Block Size
⮚ Block Interval
❑ Increasing Block size improves throughput but it takes longer to
propagate in the network
❑ Reducing the block interval reduces the latency but leads to
instability due to disagreements and Blockchain is subject to forks

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 20

 CONSENSUS PROTOCOLS
Bitcoin-NG
BITCOIN BTCOIN-NG

Low Latency
High Latency (limited by the propagation
delay of the network only)

Low Throughput High Throughput

Decouples Leader
System Freeze b/w
Election & TX
Leader Election
Serialization

Adverse effects of reducing Block Interval & Increasing the Block Size

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 21

 CONSENSUS PROTOCOLS
How Bitcoin-NG Works
❑ Nodes generate key-pairs (no trusted PKI)
❑ PoW based on hash puzzle
❑ PoW based Blockchains including Bitcoin-NG are vulnerable to
selfish mining by attackers larger than ¼ of the network

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 22

 CONSENSUS PROTOCOLS
Reducing Latency

epoch1 epoch2 epochn

t
❑ Divides time into epochs

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 23

 CONSENSUS PROTOCOLS Contd..

Reducing Latency

L-1 generates blocks L-2 generates blocks L-n generates blocks

epoch-1 epoch-2 epoch-n

❑ In each epoch a single leader is responsible of ordering the TXs

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 24

 CONSENSUS PROTOCOLS Contd..

Reducing Latency

Key Key Key

Block micro micro micro
Block micro micro micro Block micro micro micro

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
❑ Two types of blocks are generated Key Blocks and micro blocks
❑ Once a node generates a Key Block, it becomes the leader
❑ The leader generates Micro blocks containing TXs, at a set rate
❑ Each block references to the previous block hash

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 25

 CONSENSUS PROTOCOLS Contd..
Reducing Latency
Key Key Key
Block micro micro micro
Block micro micro micro Block micro micro micro

L1 generates blocks L2 generates blocks Ln generates blocks

epoch-1 epoch-2 epoch-n

t
• Contains reference to previous • Reference to previous block
block (mostly it’s the micro block • Time stamp
• Time stamp • Hash of TXs
• Coinbase TX to payout the reward • Signed by the leader
• Target value (generator)
• Nonce
• Pub Key of the leader
Ledger Entries

Interval b/w Key Blocks is as per difficulty to achieve a set

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 26
rate as in Bitcoin (2016 blocks in 2 weeks or 6 Blocks/hr)
 CONSENSUS PROTOCOLS Contd..
Reducing Latency

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
❑ Size of micro-blocks is bounded by a pre-defined max (not given)
❑ Rate of micro-blocks is smaller than a pre-defined max
(deterministic)
❑ Micro-blocks do not involve PoW, so they do not affect the weight
of the chain

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 27

 CONSENSUS PROTOCOLS Contd..
Reducing Latency

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Validity of Micro-blocks
❑ If the time stamp is in future (different from system time)
❑ If the difference in time from its predecessor is less than min
Check: To prevent a malicious leader from flooding the system with
micro-blocks
❑ All TXs must be valid as per rules of the State Machine
❑ Valid signatures of the leader
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 28
 CONSENSUS PROTOCOLS Contd..
Reducing Latency
micro micro

Key Key Key

Block micro micro micro
Block micro micro micro Block micro micro micro

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

❑ When micro-blocks are frequent, short forks occur on every

KeyBlock
❑ Resolved, when the KeyBlock is propagated

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 29

 CONSENSUS PROTOCOLS
Minimizing Selfish Mining

40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Reward for KeyBlock generation
❑ TX fee is distributed between current and next leader by the ratio of
40% and 60%
❑ Reward can be spent only after 100 KeyBlocks as in bitcoin
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 30
 CONSENSUS PROTOCOLS Contd..
Minimizing Selfish Mining

40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
❑ 40% and 60% ratio is derived to prevent selfish behaviour by
the nodes
❑ Nodes are now incentivised and motivated to mine a block on
top of other node’s TXs (microBlocks)
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 31
 CONSENSUS PROTOCOLS
Prevent Double Spending
40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
❑ A Poison TX is published, that invalidates the revenue of the fraudulent
leader
❑ It includes the header of the first Block of the pruned branch as a proof
of fraud (Every microBlock is signed by its generator)
❑ Poison TX is to be published before a node can spend its reward
❑ 5% of the invalidated revenue is granted to the current leader
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 32
 CONSENSUS PROTOCOLS
Fast Transactions
40%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Fast TX Confirmation as compared to Bitcoin
❑ If a merchant wants to accept a 0 confirmation TX. It is very risky
in Bitcoin as for next 10 mins there is no confirmation
❑ However in Bitcoin-NG, the microBlocks generated between
KeyBlocks give some level of security to the merchant to accept 0
confirmation TXs
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 33
 CONSENSUS PROTOCOLS
Punishment

40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Malicious TXs
❑ A miner engaging in a microblock fork in Bitcoin-NG
will lose his block reward and fees

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 34

 CONSENSUS PROTOCOLS
Mining Power Variations
40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Resilience to Mining Power Variation
❑ Mining power varies depends upon coin exchange rate (lower
the rate less is the profit in capital currency for the miner)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 35

 CONSENSUS PROTOCOLS Contd..
Mining Power Variations
40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Resilience to Mining Power Variation
❑ Higher the difficulty, more is the cost of mining a Block
(energy and computation)
❑ Miners are subject to shifting to suitable coins for mining

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 36

 CONSENSUS PROTOCOLS Contd..
Mining Power Variations
40% fee 60%

PKA PKB PKn

SigA SigA SigA SigB SigA SigA Sign Sign Sign

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn

t
Resilience to Mining Power Variation
❑ Due to this variation the Block generation rate is affected thus also
affecting the TX confirmations
❑ However, in Bitcoin-NG the TX processing rate is constant as it does not
depend upon PoW
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 37
 CONSENSUS PROTOCOLS
Recovering from Forks
micro micro micro micro

Key Key Key

Block micro micro micro Block micro micro micro Block micro micro micro

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn
t
Forks
• Forks in Bitcoin-NG are created at every KeyBlock, but resolved
quickly at every new Key Block
• Whereas, in Bitcoin, Forks are resolved based on heaviest chain, and
different miners may mine on different chains, therefore forks
remain for longer durations
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 38
 CONSENSUS PROTOCOLS
Recovering from Forks
micro micro micro micro

Key Key Key

Block micro micro micro Block micro micro micro Block micro micro micro

L1 generates blocks L2 generates blocks Ln generates blocks

epoch1 epoch2 epochn
t

Forks
• Bitcoin-NG also resists frequent keyBlock forks, as the small
keyBlocks with low frequency, propagate very fast in the network

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 39

 CONSENSUS PROTOCOLS
PBFT vs PoW

Question: Why BFT was not implemented in Bitcoin as a consensus

protocol for achieving agreement on order of transactions?

Answer: BFT protocol’s agreement process is vulnerable to Sybil

Attack. To counter Sybil Attack, Bitcoin implements PoW based
consensus mechanism. That is computation power based voting
instead of one entity one vote system
⮚However PoW pays an enormous price in terms of low throughput
and Tx latency

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 40

 CONSENSUS PROTOCOLS
PBFT vs PoW
Feature PoW BFT /PBFT
Goal Totally order transactions on a distributed ledger State Machine Replication Protocol
i.e Blockchain
Consensus One hour low
Latency

Energy High low

Consumption
Vulnerability to No Yes
Sybil Attack

Vulnerability Vulnerable to 51% Attack or >= 25% computing More than 33% faulty nodes
power acquired by an adversary

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 41

 CONSENSUS PROTOCOLS
Contd..
PBFT vs PoW
Feature PoW BFT /PBFT

Depends on Yes (Can be subjected to DoS attack

Network by an attacker capable of exploiting the
reliability timeout period during agreement
protocol)

Future use case Development of Ethereum and its ability to

execute smart contracts, has taken Blockchain
beyond its initial purpose of cryptocurrency to
the domain of Database Replication Protocol
or State Machine Replication Protocol

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 42

 CONSENSUS PROTOCOLS
Contd..
PBFT vs PoW
Feature PoW BFT /PBFT
Smart contract can be termed as a State Replication Protocol
state machine, and its consistent
execution across multiple nodes
require a state replication protocol

Throughput Low (7 TPS) High (tens of thousands TPS)

Scalability Support thousands of clients Support thousands of clients
(Number of
nodes in a A permission-less network with Limitation of number of nodes (Replication
network) thousands of nodes (Miner Nodes) Nodes)

Both are at the opposite ends of scalability with respect to each other

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 43

 CONSENSUS PROTOCOLS
Contd..
PBFT vs PoW
Feature PoW BFT /PBFT
Identity Permission-less Permissioned
Management Each node is suppose to know its peers.
Therefore, it is the desired protocol for
permissioned Blockchains, in which identity
of nodes is require to be known
Consensus PoW does not guarantee consensus After end of the protocol, all the correct
Finality finality, once a block is mined. The nodes agree or not agree on the order of
block can be orphaned and only the transactions
chain with longest PoW is accepted.
Therefore, a TX confirmation takes
6 x Blocks generation time

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 44

 CONSENSUS PROTOCOLS
PBFT vs PoW Contd..

Feature PoW BFT /PBFT

Network Blocks are time-stamped by nodes based on Does not require synchrony for safety but
Synchrony their local clock require for liveness

Block is accepted as valid if the timestamp is

> median of last 11 blocks

Correctness Rarely come with detailed security and BFT protocols are required to satisfy
Proof distributed protocol analysis security proofs for academic scrutiny

Limitations High computation power, high energy High communication overhead, less faulty
requirement, size of Blockchain, latency in TX node tolerance, subject to DoS attack (due
confirmation to network latency), vulnerability to Sybil
attack, suitable only for small network with
10-100 nodes

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 45

 IOTA
Underlying Principles of TANGLE

❑ At its core it is a distributed ledger

❑ P-2-P Network

❑ Relies on consensus and validation

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 46

 IOTA vs BLOCKCHAIN
Ser IOTA BLOCKCHAIN

1. No Blocks Chain of Blocks

2. Zero fee transactions Transaction fee

Consensus (validation of transactions) and Consensus mechanism and transactions are
normal transaction process is interknitted decoupled
 
A single transaction references two past
3. transactions i.e. To initiate a transaction
first you have to validate two past
transactions
(This makes IOTA to scale without any
Transaction Fee)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 47

 IOTA vs BLOCKCHAIN Contd..

IOTA

Consensus Achieved Uncertainty about full acceptance Tips – unconfirmed

Transactions

Blockchain

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 48

 IOTA vs BLOCKCHAIN Contd..
Ser IOTA BLOCKCHAIN
Consensus does not require a miner, rather it is done Consensus requires a miner to
based on validity of a TX checked through Markov perform PoW and include TXs in a
Chain Monte Carlo (MCMC) model Block
(The user has freedom that with which probability he
4. accepts a TX say he runs the MCMC 100 times, if a path
is selected to a past TX 51 times (with 51% probability),
then that TX may be accepted. For high value TX this
probability can be risen to 99%

No fixed limit on how many transactions can be Limited block size

5. confirmed per second

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 49

 IOTA vs BLOCKCHAIN Contd..
Ser IOTA BLOCKCHAIN

TX rate is 182 TPS (Aim to raise it to 1000 TX rate is 7 TPS

6.
TPS)
Scaling limitations have been removed, since Latency is increasing with increase in
throughput grows in conjunction with activity number of TXs as consensus process is
and consensus process is parallelized i.e. sequential
7.
More the activity, more are the transactions
that can be processed & the faster is the
network

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 50

 IOTA vs BLOCKCHAIN Contd..

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 51

 IOTA vs BLOCKCHAIN Contd..

Ser IOTA BLOCKCHAIN

8. Protection against double spending Protection against double spending

9. Supports offline TXs Supports offline wallet as well

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 52

 IOTA
Terminology Explanation

TX Transaction

Tangle Graph Directed Acyclic Graph called Tangle, is a ledger for storing TXs

These are the transactions (issued by the nodes) represented on the tangle
Site Set
graph

Nodes These are the entities that issue transactions

Genesis TX The first Transaction (All the tokens were created in the genesis )

MCMC Markov Chain Monte Carlo

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 53

 IOTA

❑ The transaction making process in IOTA is a 3 step

process:
⮚ Signing: A user signs the transaction inputs with his private
keys
⮚ Tip Selection: MCMC is used to randomly select two tips (i.e.
unconfirmed transactions), which will be referenced by the new
transaction (branchTransaction  and  trunkTransaction)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 54

 IOTA Contd..
⮚ Proof of Work: In order to have his transaction accepted by
the network, the user needs to do some Proof of Work — similar
to Hashcash (spam and sybil-resistance)
⮚ After the PoW the new transaction will be broadcast to the
network. Someone else will come along, choose the new
transaction in the tip selection process and validate it
⮚ The transaction will then be confirmed

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 55

 IOTA
X-3 X-1

X-t

X
X-2
X-4

• A new TX ‘X’ must, first

approve 2 previous TXs
• Approvals are represented
by ‘Direct Edges’
The TXs issued by the Nodes constitute
• Indirect Edges i.e. If there
the Site Set of Tangle
is no direct edge between
X & X-3 but there is a
directed path of length at
least 2 from X to X-3, X
indirectly approves X-3
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 56
 A TX getting more and more
approvals Allis the tokens were
strongly accepted
IOTA
created in the Genesis
by the system and ittfr
TX, later will to
be
difficult foundation
to doubleaddresses
spend it
X-3 X-1

X-t

X
X-2
X-4

❑ In an Asynchronous Network, all the nodes may not see the same set of TXs
❑ Nodes do not have to achieve consensus on, which • Therevalid
is noTXs to rule
fixed be included
for in the
ledger selecting the TXs to
❑ Nodes, just check, whether the two other TXs are approve
conflicting or not
• All nodes in the network
❑ For a TX ‘X’ to be valid, the node has to solve some
may cryptographic puzzle just like in
follow some reference
Bitcoin rule
❑ The genesis TX is directly or indirectly approved by all other TXs

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 57

 IOTA
X-3 X-1

X-t

X
X-2
X-4

Rule to Decide between two Conflicting TXs

❑ Node runs the Tip Selection Algorithm (same algorithm followed by all the nodes)
many times
❑ If a TX is selected 97 times, it means it is confirmed with 97% confidence

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 58

 IOTA
X-3 X-1

X-t

X
X-2
X-4

Motivation for nodes to propagate TXs

❑ Every node keeps a record that “How many new TXs it has received from a
neighbour”
❑ So even if a node does not issue TXs (has no direct incentive to share new TX that
approves its own one), it still has to work hard

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 59

 IOTA
A
6 1
1
1

F
9 4 B
3 3

E
2
1
1 C
1

Weighted TXs
❑ Each TX has a “Weight”, which is proportional to the amount of work invested into it
by the issuing node
❑ The only values the weight may assume – 3n
(n is a positive int and belongs to some non-empty interval of acceptable values)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 60

 IOTA Contd..
D A
6 1
1
1

F
9 4 B
3 3

E
2
1
1 C
1

Weighted TXs
❑ Cumulative weight of a TX
⮚ Own weight of TX + Sum of own weights of all TX that approve it
directly or indirectly

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 61

 IOTA Contd..
D A
6 1
1
1

F
9 4 B
3 3
XX
3
E 3
2 C
1
1
1

Weighted TXs
❑ The only un-approved TXs are A and C
❑ When a new TX ‘X’ comes and approves A and C, then X becomes the only tip, and
cumulative weight of all other TXs increases by 3 (the weight of X)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 62

 IOTA Contd..
D A
9 4
1
1

F
12 7 B X
3 3
3
E 3
5
1
4 C
1

Weighted TXs
❑ The only un-approved TXs are A and C
❑ When a new TX ‘X’ comes and approves A and C, then X becomes the only tip, and
cumulative weight of all other TXs increases by 3 (the weight of X)

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 63

 IOTA

1
3

❑ Height
Length of longest oriented path to the genesis TX
❑ Depth
Length of longest reverse oriented path to some Tip

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 64

 CONSENSUS PROTOCOLS
Gap Analysis

Protocol Common Observations

PoW, PoS, PoET • Public
• Blockchain forks
• Lack of consensus finality

• No data privacy

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 65

 CONSENSUS PROTOCOLS Contd..
Gap Analysis

Protocol Common Observations

BFT-based Algorithms Weak Synchrony
• Low throughput
• Vulnerable to DoS Attacks
• Scalability (BFT-based protocols are not
considered suitable for large number of
replicating nodes)
Vulnerable to Sybil Attack
Faulty node tolerance level (n-1)/3

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 66

 CONSENSUS PROTOCOLS Contd..
Gap Analysis

Protocol Common Observations

Tendermint Faulty node tolerance level (n-1)/3
Vulnerable to Sybil Attack
IOTA Lack of consensus finality
Forks
Not much tested
Faulty node tolerance not mentioned

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 67

 CONSENSUS PROTOCOLS Contd..
Gap Analysis

Protocol Additional Observations

All Protocols No device integrity check (IoT device TX validation

BFT Protocols Only mask the Byzantine Faults

Do not detect faults and the malicious nodes

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 68

 CONSENSUS PROTOCOLS
Requirements for IoT Systems
Tolerate Maximum
SMR Faulty Nodes
TX integrity &
Integrity Check
Authentication
Asynchronous
Block & TX Validation
Network
Identity Management
(Private / Consortium Low Latency
Chain)
Avoid/Protect Sybil Low Communication
Attack Complexity
Low Communication
Consensus Finality
Complexity

No Forks Low Energy Costs

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 69

 CONSENSUS PROTOCOLS
Requirements for IoT Systems
Feature Existing Protocol (If implemented)
State machine replication BFT, PBFT, DBFT, Honeybadger BFT, IOTA
Permissioned ledger BFT
Identity Management BFT
Un-forgeability All
IoT Devices’ TX validation None
TX integrity and authentication All
Device integrity check None
• Consensus finality All BFT-based Protocols
• No forks
• Low Latency in TX Confirmation

ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom 70

 CONSENSUS PROTOCOLS Contd..
Requirements for IoT Systems
Feature Existing Protocol (If implemented)
Asynchronous Network (No weak timing assumptions) • Honeybadger BFT, IOTA
Avoid DoS attacks (weak timing assumptions)
Asymptotic efficiency • Honeybadger BFT
Maximum faulty nodes tolerance level >(n-1)/3
Protection against Sybil Attack • PoW, PoS (How it can be applicable to IoT)
Detect faulty nodes None (only in Tendermint, that flags a double
spending node)
Penalty for faulty node or replicator None (Only in Tendermint, bonded coins are
(Something at stake) confiscated)

71
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom
 CONSENSUS PROTOCOLS Contd..
Requirements for IoT Systems
Feature Existing Protocol (If implemented)
Sybil Attack • In PoW and PoS, a Sybil Node has to invest
in energy and coinbase to make an impact
• In Voting based consensus, a randomized
selection of consensus quorum in each
epoch
Fault Detection in BFT • Based on request and response messages
only

72
ADVANCED TOPIC IN INFORMATION SECURITY - Dr Imran Makhdoom
 THANKS

ADVANCED TOPIC IN INFORMATION SECURITY 73