Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Blockchain - A Catalyst for Solving Age-old Distributed Systems Problems

88 views

Published on

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

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Blockchain - A Catalyst for Solving Age-old Distributed Systems Problems

  1. 1. Dilum Bandara, PhD Dept. of Computer Science & Engineering, University of Moratuwa Colombo Blockchain Dev Meetup, Sep 4, 2018
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×