Extending Blockchains in Computing - Transaction semantics for web services. Subhash Bhalla (Dept. of Comp. Sc., IIT Delhi)

Transcription

1 Extending Blockchains in Computing - Transaction semantics for web services Subhash Bhalla (Dept. of Comp. Sc., IIT Delhi)

2 Slashdot Items Tagged "blockchain" Thursday September 06, Blockchains Are Not Safe For Voting, Concludes NAP Report Friday August 24, China Shuts Down Blockchain News Accounts on WeChat App, Bans Hotels in Beijing From Hosting Cryptocurrency Events Friday August 10, The World Bank is Preparing For the World's First Blockchain Bond Thursday August 09, Colorado Candidate For Governor Wants To Put His State On the Blockchain Thursday August 09, Blockchain Hype May Have Peaked, But IBM is Still a Believer 2

3 Blockchain Philosophy Books, HBR, Sloan Management Review law, trust Technology Agriculture,. Land records, Legal systems, Healthcare(Standardized Electronic Health Records) Computing 3

4 Double Entry Book Keeping Ledger ( Append only log ) 4

5 No Cutting Compensation OK Horizontal Total Hash Number 1 (Control) Vertical Total Hash Number 2 (control) Linked List (serial no of Transations) Control Hash Numbers change with each New Transaction 5

6 Linked List Model Temper-proof Compensation is OK Transactions Over one Book ( Ledger ) 6

7 7

8

9 Multi-organization Trust: legal Doc- Registry Control Hash fixed size for all cases Legal Document / Documents Tempering Hash Change X N sites 9

10 Computing Systems : Web Developments SkyPe, MedlinePlus, MedlinePlus Encyclopedia, Google Docs, Google Maps API, gmail, google search, LMMP (NASA), PTF Caltech, Facebook, Twitter, LinkedIn, Air India, Ashoka University, AMAZON, Any e-auction web site, Postgres web site, Wikipedia, e-bay, yahoo auction,. Classify the above: sites, applications, Cloud-based 10

11 Palomar Transient Factory Time Domain Astronomy Since 2009 Sectors in Norther Sky Watched all night Real-time processing Machine Learning, data mining Archive (growing in time) 11

12 Categories of Web Applications

13 Computing as enterprise Change Computing W3C Application New Specifications

14 Development of Web Applications Specifications (25 Years): Front-end Form, client-server, XML, CSS, JavaScript, Web Services, HTML 5 (transmit GIS coordinates of clients), tracking tools/systems Back-end Map-reduce, Data centers, Hadoop,

15 Computing as enterprise (before years) Change Computing ISO, ANSI Application New Specifications Prior to 1993: Database System Distributed Systems on ETHERNET (web?,internet?) Banking, Stock exchange, Airlines, Railways,

16 Interactions thru the Web A number of processes (N) on ETHERNET Communicate through messages to Cooperate Interact with outside world (web) 16

17 ETHERNET Hand-shake, acknowledge, time-limit on response, network-status, fast vs- 17

18 In Transit Messages A message that has been sent but not yet received is called an in-transit message. Do rollback recovery protocols have to guarantee the delivery of in-transit messages? Depends on whether reliable communication is assumed! 1

19 LAN vs. Web/Internet Wired, replication (loaded standby) Synchronous Failure is detected by timeout 19

20 Distributed Systems: Computing as an Enterprise Network Eccentric and Mobile Applications 1. Middleware 2. Networks Mobile ad hoc networks ( MANETs ) 20

21 Network Eccentric and Mobile Aplications ( Middleware ): Mobile ad hoc networks (MANETs ) Energy in sensor networks, programming wireless sensor networks, Ad hoc routing, 5 G Software defined networks, Communication Models Population protocols, routing in opportunistic Networks, wireless Mesh networks Gossip-Based dissemination, Application layer Multicast, Distributed event routing in Publish/subscribe systems, Tuple Space Middleware for wireless networks, Security Middleware, Dynamic Adaptation.. Blockchain 21

22 Blockchain Networks Toyota to Bring Blockchain Networks to Smart Cars IEEE Spectrum, May 2017, By Philip E. Ross 1. It could make car-to-cloud communication easier and more secure, if your car wants to talk to another car, a service provider network 2. Blockchain Consensus, Tyler Crain, Vincent Gramoli, Michel Raynal, Mikel Larrea. Proceedings of AlgoTel

23 Blockchain in use 1. Bay area in California Rent a Toyota car 1. Down load an APP Smartphone Location nearest car on Map Walk to the car Select pay Car door unlocks 2. Driverless car / Remote Guidance System for Spacecraft 23

24 Blockchain 24

25 Blockchain / Distributed Ledger Technology Distributed Systems Applications 1. Extremely Large Amount of Data 2. Extremely Critical Data 3. Real-time Data Streaming 4. Consensus Among Nodes in an Asynchronous System Blockchain is an enabling technique Immutability Asynchrony Consensus 25

26 Distributed Systems: Immutability Log-structured Files / Append-only Logs Example: Database Nodes Asynchrony Achieve a common history at nodes thru a stamp server Consensus In the absence of globally synchronous clock, there is a need for global consensus 26

27 Database Change of State Backup 27

28 Database Systems + Dist. Syst. On Ethernet Banking 100s of ATMs, Audit system, Accounting report 1. Backup at time (To) 2. Database 3. Append only log (journal) of activity since last backup (To) Recovery after failure: Combine 1. and 2 3.

29 Computing Systems- Protocols Fail-stop Model - Communication Channel uses parity Byzantine fault tolerance Atomic commit Brooks Iyengar algorithm List of mathematical concepts named after places List of terms relating to algorithms and data structures Byzantine Paxos Quantum Byzantine agreement Two Armies Problem Impossible to win on web? Blockchain 29

30 Fail-Safe Model Communication Channel : Parity bit changes Fail-prone Fail-stop 0 3 bits are 1s Parity odd as 1 30

31 Byzantine General s Problem

32 Workflow processing 1. e-bay : Cart HP Notebook + EPSON Color printer + SONY Camera + Customer bank + e-bay bank 5 Processes in a TWO-phase Commit, with resources blocked ( Atomic ) (Consistent)(Isolation)(Durability) On top of web service connections (no Ethernet) 32

33 Transaction Atomicity 33

34 Atomicity 34

35 2 Phase Commit 35

36 Participants make note in Log 36

37 3 Phase Commit - 3PC is non-blocking (in cases C or P failure) 37

38 3

39 39

40 40

41 Application Systems on Web Services 41

42 Complexity in Distributed Systems Multiple Nodes Messages 42

43 Problems: Long Running Process Blue Gene (1999) parallel computer, for the study of bio-molecular phenomena such as protein folding P1 Process Failure Checkpoint 1 Checkpoint ( 1,., n ) : STABLE STORE Data, threads, register values Run-time overhead; Failure most recent checkpoint 64 x 64 grid of parallel computers middleware for checkpoints 43

44 Cooperating Processes Distributed System P 0 P 1 m 0 P 2 P 3 m 1 C 1,0 C 2,0 m 3 m 2 m 5 m 4 C 3,0 C 0,0 m 6 C 2,1 m 7 C 3,1 m C 1,1 C 2,2 Crashed C 0,1 44

45 Middleware Distributed System Distributed system a collection of processes that communicate through messages in a network Fault tolerance periodically using stable storage to save the processes states during the failure-free execution. After a failure a failed process restarts from one of its saved states, reducing the amount of lost computation. Each of the saved states is called a checkpoint 45

46 Checkpont Cascading Rollback Problem Last checkpoint: C 1,1 by P1, before P1 crashed Cannot use C 0,1 at P0 because it is inconsistent with C 1,1 => P0 rollbacks to C 0,0 Cannot use C 2,1 at P2 because it fails to reflect the sending of m6 => P2 rollbacks to C 2,0 P 0 P 1 m 0 C 0,0 C 0,1 m 5 m C 1,0 C 2,0 C 1,1 m 4 m 6 Crashed m 2 P 2 P 3 m1 Cannot use C 3,1 and C 3,0 as a result => P3 rollbacks 46 to initial state C 2,1 C 2,2 m 3 m 7 C 3,0 C 3,1

47 Uncoordinated Checkpointing Uncoordinated checkpoints: full autonomy, and simple. Problems Most Checkpoints are not be useful Cascading rollback to the initial state (domino effect) To select a set of consistent checkpoints during a recovery, the dependency of checkpoints has to be determined and recorded together with each checkpoint Extra overhead and complexity => not simple after all 47

48 Disadvantages of Uncoordinated Checkpointing Susceptible to the domino effect Checkpoints that will never be part of a global consistent state are recorded Stable Storage overhead do not advance the recovery line A process needs to maintain multiple checkpoints and to use garbage collector to reclaim checkpoints Not suitable for output commit, because output commit requires global coordination to compute the recovery line 4

49 Coordinated Blocking (LAN based solution) Processes are coordinated to form a consistent global state, and initiator Ready! Go! * okay, channels flushed p1 * p2 * * p3 Next: Coordinated Blocking Chkpnt (cont ) 49

50 Coordinated Blocking (cont ) Advantage Always consistent No Domino Effect Less storage overhead Disadvantage Large latency to chkpnt! Next: Coordinated Non-blocking Chkpnt 50

51 Individual Log Based Protocols Work might be lost upon recovery using checkpointbased protocols By logging messages, we may be able to recover the system to where it was prior to the failure System mode: the execution of a process is modeled as a set of consecutive state intervals Each interval is initiated by a nondeterministic state or initial state We assume the only type of nondeterministic event is receiving of a message 1st State Interval 2nd State Interval 3rd State Interval P i m 0 m1 m 2 m 3 m 4 m 5 51

52 Log Based Protocols In practice, logging is always used together with checkpointing Limits the recovery time: start with the latest checkpoint instead of from the initial state Limits the size of the log: after taking a checkpoint, previously logged events can be purged Logging protocol types: Pessimistic logging: msgs are logged prior to execution Optimistic logging: msgs are logged asynchronously Causal logging: nondeterministic events that not yet logged (to stable storage) are piggybacked with each msg sent For optimistic and causal logging, dependency of processes has to be tracked => more complexity, longer recovery time 52

53 Pessimistic Logging Synchronously log every incoming message to stable storage prior to execution Each process periodically checkpoints its state: no need for coordination Recovery: a process restores its state using the last checkpoint and replay all logged incoming msgss 53

54 Lamport s logical clock Happened before relation a -> b : Event a occurred before event b. Events in the same process p1. b -> c : If b is the event of sending a message m1 in a process p1 and c is the event of receipt of the same message m1 by another process p2. a -> b, b -> c, then a -> c; -> is transitive. 54

55 Lamport s logical clock Causally Ordered Events a -> b : Event a causally affects event b Concurrent Events a e: if a!-> e and e!-> a 55

56 Lamport s logical clock Algorithm Sending end Receiving end time = time+1; time_stamp = time; send(message, time_stamp); (message, time_stamp) = receive(); time = max(time_stamp, time)+1; 56

57 a -> b Lamport s logical clock C(a) < C(b) b -> c C (b) and C(c) must be assigned in such a way that C(b) < C(c) and the clock time, C, must always go forward (increasing), never backward (decreasing). Corrections to time can be made by adding a positive value, never by subtracting one. 57

58 Lamport s logical clock An illustration: Three processes, each with its own clock. The clocks run at different rates and Lamport's algorithm corrects the clocks. 5

59 Lamport s logical clock Limitations m1 >m3 C(m1)<C(m3) m2 >m3 C(m2)<C(m3) m1 or m2 caused m3 to be sent? 59

60 Lamport s logical clock Lamport s logical clocks all events in a distributed system are totally ordered. That is, if a -> b, then we can say C(a)<C(b). Lamport s clocks nothing can be said about the actual time of a and b. logical clock says a -> b, that does not mean in terms of real time. Lamport clocks do not capture causality. If a -> c and b -> c we do not kno which action initiated c. Problems : when trying to replay events in a distributed system (such as when trying to recover after a crash). The theory goes that if one node goes down, if we know the causal relationships between messages, then we can replay those messages and respect the causal relationship to get that node back up to the state it needs to be in. Piece-wise Deterministiic (PWD)? 60

61 Vector clocks Vector clocks allow causality to be captured Rules of Vector Clocks Properties of a process Implementation 61

62 Vector clocks Rules and properties A vector clock VC(i) is assigned to an event i. If VC(i)<VC(j) for events i and j, then event i is known to causally precede j. Each process i maintains a vector V such that Vi [i] : number of events that have occurred at i Vi [j] : number of events I knows have occurred at process j 62

63 Vector clocks Implementation Before executing an event (i.e., sending a message over the network, delivering a message to an application, or some other internal event), 1. Pi executes VCj [i] ~ VCj [i] When process Pi sends a message m to Pj, it sets m's (vector) timestamp ts (m) equal to VCj after having executed the previous step. 3. Upon the receipt of a message m, process lj adjusts its own vector by setting VCj [k] ~ max{vcj [k], ts (m )[k]} for each k, after which it executes the first 63 step and delivers the message to the application.

64 Vector clocks 64

65 Sum Up: Checkpoints and Recovery Prevent Orphan process Lamport s timestamps Integer clocks assigned to events Obeys causality Cannot distinguish concurrent events Vector timestamps Obeys causality By using more space, can also identify concurrent events 65

66 Message Dependencies 66

67 Sender and Receiver - Dependencies Sender Dependency In Figure 1.(a), the process state P1 depends on P3 (state change by message m3). (after failure of process p3, if p3 restarts from state 0, p1 becomes an orphan process. Similarly, P1 transitively depends on P2 ( transitive sender dependency.). Receiver Dependency In Figure 1.(b), the process state P1 depends on P2 (message m2) After failure of process p2, m2 becomes a lost message. Process p1 should roll back and send the message m2 again. Similarly, P1 transitively depends on P3 (transitive receiver dependency). 67

68 Interacting Processes 6

69 Total Dependency Graph 69

70 Minimum Reachability Graph 70

71 Interacting Processes Total Dependency Vector clock 71

72 TDG - Cumulative State Dependencies Vector clock 72

73 Independent Dependency Tracking using TDT Vector Clock Extending Blockchains Reliable Communication Network Vs Dependency Tracking LOST Messages Tracking + Orphan Message Tracking Instantantaneous Minimum Reachability Graph Reduced time Check-poining and Rollback 73 Recovery

74 Blockchain Distributed Ledger Philosophy same as double entry book-keeping Example: Bank Passbook Credits Debits Balance Description ( transactions (cr + db = bal) No change is allowed; compensation is allowed) [Controls on Cr, Db, Bal Check SUMs] 74

75 Distributed Ledger (Blockchain) Replicated Database 75

76 Application Systems on Web Services 76

77 Checkpont Cascading Rollback Problem Last checkpoint: C 1,1 by P1, before P1 crashed Cannot use C 0,1 at P0 because it is inconsistent with C 1,1 => P0 rollbacks to C 0,0 Cannot use C 2,1 at P2 because it fails to reflect the sending of m6 => P2 rollbacks to C 2,0 P 0 P 1 m 0 C 0,0 C 0,1 m 5 m C 1,0 C 2,0 C 1,1 m 4 m 6 Crashed m 2 P 2 P 3 m1 Cannot use C 3,1 and C 3,0 as a result => P3 rollbacks 77 to initial state C 2,1 C 2,2 m 3 m 7 C 3,0 C 3,1

78 BLOCKCHAIN 7

79 79

80 Distributed Ledger Common / one Log 0

81 1

82 2

83 3

84 4

85 5

86 Different Rollback Recovery Schemes Rollback Recovery Schemes Checkpoint based Log based Uncoordinated check pointing Blockchain Pessimistic Logging Coordinated check pointing Optimistic Logging Comm. induced check pointing Casual Logging 6

87 Computing Systems- Protocols Component Level, Sub-systems, Blockchain: - End-to-end, - at Application layer System : Sum of its parts Application recovers from underlying component failure 7

88 Computing Systems- Protocols Individual System Replicated DBMS, Internal Architecture for a Distributed Application Supports reliable computations Fail-Stop Model, Byzantine Generals protocols, RPC level End-to-end Application delivery systems: Communicate thru Web Services at Application Layer Blockchain

89 Distributed Systems: new paradigms Crash / fault tolerant consensus algorithms run by one organization BLOCKCHAINS May run with multiplicity of Organizations [ Malicious Nodes ] : No trust between each other Byzantine General s Problems; Network not reliable, Internet delays, Network Partitions, Message loss and / reordering 9

90 Blockchains ( Distributed Ledger Technology ) Blockchains Clever way to detect message loss / reordering messages Log of bloc Log of blocks log of block Copies Every block in the log has a pointer back to previous block ( Linked Lists ) Broadcasts reach many nodes ( detect missing or reorder is no problem ) Distributed Database across (no trust entities ) 90

91 Time 1 : Distributed Information Systems Distributed Oracle (Database System) : 1 Organization ( Banking SBI ) : LAN based; Synchronous Communication Time 2 : Distributed Systems : Inter-bank reconciliations (group of Org. ) : LAN + Internet ; Grid Computing Time 3: Cloud-based Mushups and Computing :Aggregate Applications (Multiple organizations); Web Services 91

92 Distributed Systems in perspective 70-0s 90s 2000s LAN Synchronous Comm. LAN + Internet; Grid Computing Asynchronous Comm. Delay/Disconnectio n Web Services; Cloud Computing Asynchronous Comm. Delay/Disconnectio n Distributed Oracle +.. J2EE / Jini Web Services One Organization Banking - SBI Super-computers Group of Organizations (Banks) Networked Workstations Multiple Organizations (may be unknown)? CLOUD Multiplicity 92 of Channels

93 What are Chellenges- BANK ATMs work on dedicated lines (similar to a FAX machine, Synchronous network) AT&T goal in circa 2000 Aimed to change to telephony using Internet in -10yrs US Govt. Air-traffic Control automation in 90s (IBM) Driverless cars Real-time Control Problems ; High-speed streams of Data Stock Exchange (in TOKYO, NY, Germany) 1 hour Internet trade handling > 1 year Budget of Japan Govt. LAN+Internet 10MB (Megabits) Giga bits Networks Multiplicity of channels- 93 Blockchains

94 How to meet the Challenges- One item Big Internet ( one Bullock ) One item Big clouds ( one Bullock ) MULTIPLICITY Individual site logs [one organization] No Global Clock Time-order (LAMPORT) Log Structured Files (append only logs) [one group] Vector Clocks Distributed logs Blockchain Technolgy / Distributed Ledger Technoloogy [Not one globe?] Globally ordered transaction logs 94

95 Problems: Long Running Process Blue Gene (1999) parallel computer, for the study of bio-molecular phenomena such as protein folding P1 Process Failure Checkpoint 1 Checkpoint ( 1,., n ) : STABLE STORE Data, threads, register values Run-time overhead; Failure most recent checkpoint 64 x 64 grid of parallel computers middleware for checkpoints 95

96 Cooperating Processes Distributed System P 0 P 1 m 0 P 2 P 3 m 1 C 1,0 C 2,0 m 3 m 2 m 5 m 4 C 3,0 C 0,0 m 6 C 2,1 m 7 C 3,1 m C 1,1 C 2,2 Crashed C 0,1 96

97 Cooperating Logs / Blockchain Distributed Ledger (external for Web services, managed by a cloud data center) P 0 P 1 m 0 P 2 P 3 m 1 C 1,0 C 2,0 m 3 m 2 m 5 m 4 C 3,0 C 0,0 m 6 C 2,1 m 7 C 3,1 m C 1,1 C 2,2 C 0,1 Crashed 97

98 Problems: Long Running Blockchain External Blockchain supports the Web Service transaction can tolerate a few failure P1 Process Failure Checkpoint 1 Log is Checkpoints ( 1,., n ) : on STABLE STORE? It is all for Web Services Data, threads, register values Run-time overhead; No Failure No most recent checkpoint Dist. / parallel computers middleware for checkpoints 9

99 References Advanced Concepts in Operating Systems by Singhal and Shivaratri on pages Distributed Systems: Principles and Paradigms, Andrew S. Tanenbaum and Maarten Van Steen, (Second Edition) on pages Time, clocks, and the ordering of events in a distributed system by Lamport (197) Youtube videos

100 References C. Lee, B. Nick, U. Brandes, and P. Cunningham, Link prediction with social vector clocks, in Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, ser. KDD 13, Apr. 2013, pp M. Harrigan, Using vector clocks to visualize communication flow. in ASONAM, N. Memon and R. Alhajj, Eds. IEEE Computer Society, 2010, pp C. E. Hrischuk and C. M. Woodside, Logical clock requirements for reverse engineering scenarios from a distributed system, IEEE Trans. Software Eng., 2(4), Apr. 2002, M. Raynal and M. Singhal, Logical Time: Capturing Causality in Distributed Systems, IEEE Computer Magazine, vol. 29, no. 2, pp , Feb

101 Reference BLOCKCHAINS : 101