Concurrency, time, ordering, consensus, consistency, availability, partition tolerance, Byzantine fault tolerance in Blockchains

1. Dilum Bandara, PhD
Dept. of Computer Science & Engineering,
University of Moratuwa
Colombo Blockchain Dev Meetup, Sep 4, 2018

2. 2
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781

3. 3
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Bob 1,000
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Bob 1,000
Peter 500
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Peter 500
Rani Plot 123 @ Col 7
Rasa
Mango
Polonnaruwa,
Org. #45781
ID Assets
Alice 500
Bob 1,000
Rani Plot 123 @ Col 7

4. 4
ID Assets
Alice 500
Bob 1,000
Peter 500
A
ID Assets
Alice
Bob
Peter 500
B
ID Assets
Alice 200 500
Bob 1,300 1,000
Peter 500
P
Transfer 300 to Bob
200 500
1,300 1,000
• Alice may initiate request from
her node or any other node
• No of messages increase with no
of ledger copies

5. 5
ID Assets
Alice 500
Bob 1,000
Peter 500
A
ID Assets
Alice
Bob
Peter 500
B
ID Assets
Alice 500
Bob 1,000
Peter 500
P
Transfer 300 to Bob
200 500
1,300 1,000
• Likeliness of failure increases
with no of ledger copies

6. 6
ID Assets
Alice 500
Bob 1,000
Peter 500
A
ID Assets
Alice 200 500
Bob 1,300 1,000
Peter 500
B
ID Assets
Alice 100 500
Bob 1,000
Peter 900 500
P
Transfer 300 to Bob
• Likeliness of attack increases
with no of ledger copies

7. Blockchain concept focuses on Public-Key Cryptography &
Hashing
Implementation needs to address many distributed system
problems
 Timing & Ordering
 Consensus
 CAP Theorem
Distributed systems research community seems to not care
Lots of others want to solve these problems due to monetary
benefits (e.g., cryptocurrency)
7

8. 8
ID Assets
Alice 200 500
Bob 1,300 1,000
Peter 500
A
ID Assets
Alice 200 500
Bob 1,300 1,000
Peter 500
B
ID Assets
Alice 500
Bob 1,000
Peter 500
P
Transfer 300 to Bob
t = 10 t = 12
Transfer 1,200 to Peter t = 15t = 18
t = 16t = 18
Reject
Accept
• Inconsistent ledger due to
concurrent transactions (TXs)
• Inconsistency increases with no
of ledger copies

9.  Use of sender’s time to order TXs not reliable
 Clocks aren’t accurate – Drift & skew
 Difficult to sync them & keep them synched
 Sender could change time to game the system
 Global ordering of TXs
 Lamport’s time stamp
 A logical counter that increments when messages
are send & received
 Lamport’s Totally Ordered Multicast
 Vector clocks
 Address “lower logical clock doesn’t guarantee
happened before relationship” in Lamport’s time stamp
 Doesn’t scale with no of ledger copies
9

10.  No concurrent TXs related to same account in same block
 E.g., Bitcoin, Ethereum, & Hyperledger
 Low transaction throughput – 3-6 TX/Sec
 Store global state in a database (RDBMS or NO-SQL) & proof of
existence on Blockchain
 E.g., Stellar & BigchainDB
 Fully or semi-centralized
 Not quite Blockchain
 Need more scalable concurrent transaction support
 High throughput
 Low Latency
10

11.  2 Blue armies need to simultaneously attack or retreat
 Blue army have to communicate across area controlled by White army
 White army area  Unreliable communication channel
 Goal – 2 blue armies to reach agreement about attacking
11
Source:
www.ee.surrey.ac.uk/Projects/CAL/networks/
Network-Transport_Application_Layers.htm

12. Agreement in the judgment or opinion reached by a
group as a whole
 Getting 2 nodes to agree is hard
 Getting many nodes to agree is even harder
Achieving consensus under:
 Unreliable communication – Partition tolerance
 Failed nodes – Fault tolerance
 Misbehaving nodes – Byzantine fault tolerance
12

13. 13
I have a plan – Let’s attack at dawn tomorrow
Splendid idea, A! See you at dawn tomorrow!
Received message. We are ready for the battle.
Received acknowledgement. We are also ready
Blue 1
Blue 2
Gotcha,
I lied

14. “It’s impossible for a web service to provide following 3
guarantees at the same time” (Eric Brewer, 2000)
 Consistency
 Availability
 Partition-tolerance
14
ID Assets
Alice 500
Bob 1,300 1,000
Peter 200 500
ID Assets
Alice 500
Bob 1,300 1,000
Peter 200 500
Peter = 200
Peter = 500

15. Nodes loose network
connectivity
 Networks will partition!
 Partition tolerance is mandatory in
distributed systems
So, choose Consistency or
Availability…
 Blockchain needs to be Available
 Ledger needs to be Consistent
 Consensus  Consistency
15
C A
P
Required

16.  No guarantee that a TX will be included in next block
 Leader election
 Selected leader decides on what goes into block
 Believe leader’s block/ledger as ground truth
 How to elect leader?
 Proof of Authority (PoA) – e.g., VeChain, Kovan (Ethereum testnet)
 Based on trust – e.g., Stellar
 Random leader
 Based on votes – e.g., Hyperledger Fabric & Sawtooth
 Proof of Stake – e.g., Hyperledger Iroha
 Proof of Brain – Steem
 Fast
 Consistency depends on leader
16

17.  Proof of Work
 Believe 1st one that solves a given puzzle
 Puzzle should be difficult to compute (no short-cuts), but easy check
 E.g., calculating a hash with specific no of 0/1 bits
 Anyone can compete & difficult to game
 Slow & expensive
 Multiple truths may exist for a while
 Longest chain wins
 New truth may replace current truth  Some TXs need to be reversed
 E.g., wait for 6 blocks in Bitcoin to confirm a TX
 TXs need to be fast, persistent, & low cost
17

18.  Low-latency TX processing
 Inclusion guarantees
 Fast confirmations
 Persistence
 High-throughput Concurrent TX processing
 Low cost
 Truly distributed ledger
 Beyond proof of existence 18
Distributed
System
Problems
Blockchain
 Working systems used & contributed by many
 But
 Slow
 No guarantees
 High cost
 Not scalable