BAR Gossip. Lorenzo Alvisi UT Austin
|
|
|
- Miles Miller
- 5 years ago
- Views:
Transcription
1 BAR Gossip Lorenzo Alvisi UT Austin
2 MAD Services Nodes collaborate to provide service that benefits each node Service spans multiple administrative domains (MADs) Examples: Overlay routing, wireless mesh routing, content distribution, archival storage,
3 How MAD Services Fail Nodes can break Fail-stop e.g., disk crash Byzantine arbitrary deviation Misconfigured, compromised by virus, operator error ( rm rf * ), malicious user,
4 How MAD Services Fail Nodes can break Fail-stop e.g., disk crash Byzantine arbitrary deviation Misconfigured, compromised by virus, operator error ( rm rf * ), malicious user, Nodes can be selfish Minimize work and maximize gain e.g., in a cooperative backup service, store less than fair share of data
5 Byzantine Model [Lamport 1982, ] Tolerates arbitrary deviations from specification Can be practical [Castro and Liskov 1999, Rodrigues et al 2001, Yin et al 2003, Abd El-Malek et al 2005, Johansen et al 2006, Cowling et al 2006]
6 Byzantine Model [Lamport 1982, ] Tolerates arbitrary deviations from specification Can be practical [Castro and Liskov 1999, Rodrigues et al 2001, Yin et al 2003, Abd El-Malek et al 2005, Johansen et al 2006, Cowling et al 2006] Limits number f of faulty nodes e.g. Agreement requires f <n/3 Assumes all other nodes are correct Inappropriate when all nodes may deviate when in their interest
7 Rational Model [Nash 1950, ] All nodes are rational, and rational nodes can deviate selfishly from their specification [Papadimitriou 2001, Cox and Noble 2003, Littlebridge et al ]
8 Rational Model [Nash 1950, ] All nodes are rational, and rational nodes can deviate selfishly from their specification [Papadimitriou 2001, Cox and Noble 2003, Littlebridge et al ] Does not tolerate Byzantine behavior Broken nodes may violate assumptions Malicious nodes may cause unbounded damage Inappropriate when some node may deviate against its interest
9 Three Challenges 1. To develop a model in which it is possible to prove properties about MAD services 2. To understand how to simplify the development of MAD services in the new model 3. To demonstrate that MAD services developed under the new model can be practical
10 Who s to blame Jeff Napper Allen Clement Harry Li Jean-Philippe Martin Amit Aiyer Edmund Wong Lorenzo Alvisi Mike Dahlin Indrajit Roy
11 A First Foray BAR (Byzantine, Altruistic, Rational) Tolerance no bound on rational nodes utility functions add expectation of Byzantine behavior BAR-B, a BAR tolerant cooperative backup service (SOSP 05) uses BAR-tolerant RSM to implement abstraction of Altruistic node on top of Rational and Byzantine ones FlightPath, a BAR tolerant data streaming application (OSDI 06) uses BAR-tolerant gossip protocol to disseminate updates
12 Live Streaming Examples: Internet radio, NCAA tournament, web concerts, Internet TV Practical challenges: Reduce broadcaster s used bandwidth Minimize latency Increase reliability Tolerate link and node failures
13 Live Streaming Setup Broadcaster Clients
14 Live Streaming Setup Broadcaster Clients
15 Live Streaming Setup Broadcaster Clients
16 Live Streaming Setup Broadcaster Clients
17 Live Streaming Setup Broadcaster Clients
18 Rational Peers Don t Share! Broadcaster Clients
19 Rational Peers Don t Share! Broadcaster??? Clients
20 Reliability Degrades...
21 ...and Altruistic nodes suffer
22 BAR Gossip
23 BAR Gossip
24 BAR Gossip
25 BAR Gossip
26 The Setup Application Altruistic broadcaster BAR clients Static membership Full membership list Updates useful for finite time
27 The Setup Application Altruistic broadcaster BAR clients Static membership Full membership list Updates useful for finite time Crypto Public/Private key pairs Notation: M A
28 The Setup Application Altruistic broadcaster BAR clients Static membership Full membership list Updates useful for finite time Crypto Public/Private key pairs Notation: M A Incentive Structure Benefit: playing updates Cost: bandwidth No long-term reputations
29 BAR Gossip Overview Balanced Exchange Optimistic Push
30 BAR Gossip Overview Balanced Exchange Optimistic Push In each round: Select partner Exchange histories Trade equal number of updates
31 BAR Gossip Overview Balanced Exchange Optimistic Push In each round: Select partner Exchange histories Trade equal number of updates Little help to peers that fall behind
32 BAR Gossip Overview Balanced Exchange In each round: Select partner Exchange histories Trade equal number of updates Optimistic Push In each round: Select partners Exchange histories Little help to peers that fall behind
33 BAR Gossip Overview Balanced Exchange In each round: Select partner Exchange histories Trade equal number of updates Little help to peers that fall behind Optimistic Push In each round: Select partner Exchange histories Trade possibly unequal numbers of updates Safety net for lagging peers
34 Balanced Exchange In each round Select a partner Exchange histories Trade equal number of updates
35 Balanced Exchange In each round Select a partner Exchange histories Trade equal number of updates
36 Balanced Exchange In each round Select a partner Exchange histories Trade equal number of updates fair exchange
37 Balanced Exchange In each round Select a partner Exchange histories Trade equal number of updates fair exchange is impossible without a trusted third party B. Garbinato and I. Rickebusch. Impossibility results on fair exchange. Tech. Rep. DOP , Université de Lausanne, Distributed Object Programming Lab.
38 Balanced Exchange In each round Select a partner Exchange histories Trade equal number of updates fair exchange is impossible without a trusted third party so we settle for fair enough!
39 Balanced Exchange In each round Select a partner Exchange histories Trade equal number of updates Exchange briefcases Exchange keys }fair enough exchange
40 Design principles
41 Design principles Restrict choice
42 Design principles Restrict choice Eliminate non-determinism
43 Design principles Restrict choice Eliminate non-determinism Evict provably deviant peers
44 Design principles Restrict choice Eliminate non-determinism Evict provably deviant peers Delay gratification
45 Design principles Restrict choice Eliminate non-determinism Evict provably deviant peers Delay gratification Postpone payoff to keep rational peers engaged
46 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C
47 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C
48 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Send history
49 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Claim less Select B Select C Send history
50 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Send history
51 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Send history Send briefcase
52 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Don t send briefcase Send history Send briefcase
53 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Don t send briefcase Send history Send bad briefcase Send briefcase
54 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Don t send briefcase Send history Send bad briefcase Send briefcase Send key
55 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Don t send briefcase Send history Send bad briefcase Don t send key Send briefcase Send key
56 The Intuition Restrict choice! Eliminate non-determinism! Evict provably deviant peers Delay gratification Select D Select B Select C Claim less Claim more Don t send briefcase Send history Send bad briefcase Don t send key Send briefcase Send wrong key Send key
57 Balanced Exchange is a Nash Equilibrium Theorem: A balanced exchange is incentive compatible for strategies that maximize the number of useful updates received in that exchange
58 Balanced Exchange is a Nash Equilibrium Theorem: A balanced exchange is incentive compatible for strategies that maximize the number of useful updates received in that exchange Partner selection History exchange Briefcase exchange Key exchange
59 Balanced Exchange is a Nash Equilibrium Theorem: A balanced exchange is incentive compatible for strategies that maximize the number of useful updates received in that exchange Partner selection History exchange Briefcase exchange Key exchange } Incentive compatible
60 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A B C D E
61 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A: Verifiable pseudo-random partner selection A B C D E
62 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A: Verifiable pseudo-random partner selection A B A s PRNG seed in round r : r A C D E
63 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A: Verifiable pseudo-random partner selection A r A,... A B check current round check selection A s PRNG seed in round r : r A C D E
64 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A: Verifiable pseudo-random partner selection A r A,... A B check current round check selection A s PRNG seed in round r : r A C D E
65 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A: Verifiable pseudo-random partner selection A r A,... A B check current round check selection A s PRNG seed in round r : r A Eliminates non-determinism C D E
66 Partner Selection Q: How do we limit a peer to one uniformly selected partner per round? A: Verifiable pseudo-random partner selection A r A,... A B check current round check selection A s PRNG seed in round r : r A Eliminates non-determinism Retains strength of randomness: uniform selection of partners unpredictability D E C
67 History Exchange Q: How do we handle a client lying about its history?
68 History Exchange Q: How do we handle a client lying about its history? A r A, #H A A B A: Client commits to a history before discovering partner s history H B B H A A
69 History Exchange Q: How do we handle a client lying about its history? A r A, #H A A B A: Client commits to a history before discovering partner s history H B B H A A Under-reporting decreases number of useful updates exchanged Over-reporting risks eviction
70 Briefcase Exchange Q: How do we encourage a rational client to send a briefcase? A History exchange B ids, upds A ids, upds B
71 Briefcase Exchange Q: How do we encourage a rational client to send a briefcase? A History exchange B A: Client gives key only after swapping briefcases ids, upds A ids, upds B
72 Valid Briefcase Exchange Q: How do we encourage a rational client to send only appropriate briefcases? A History exchange ids, upds A B ids, upds B
73 Valid Briefcase Exchange Q: How do we encourage a rational client to send only appropriate briefcases? A History exchange B A: Hold client accountable for contents of briefcase ids, upds A ids, upds B
74 Valid Briefcase Exchange Q: How do we encourage a rational client to send only appropriate briefcases? A History exchange B A: Hold client accountable for contents of briefcase ids, upds A Briefcase contains encrypted updates and ids of updates Inconsistencies risk eviction Decryption key is reproducible by broadcaster ids, upds B
75 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B AB A BA B
76 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B AB A
77 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests AB A
78 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests AB A AB A
79 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests AB A AB A AB A
80 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests Rational client minimizes cost by sending key AB A AB A AB A
81 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests Rational client minimizes cost by sending key AB A AB A AB A BA B
82 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests Rational client minimizes cost by sending key Rational client proactively sends key AB A BA B
83 Key Exchange Q: How do we encourage a rational client to send the appropriate key? A History exchange Briefcase exchange B A: Repeated Key Requests Rational client minimizes cost by sending key Rational client proactively sends key Hold client accountable for key responses AB A BA B
84 BAR Gossip Overview Balanced Exchange In each round: Select partner Exchange histories Trade equal number of updates Incentive compatible! Optimistic Push In each round: Select partners Exchange histories Trade possibly unequal numbers of updates Safety net for lagging peers
85 BAR Gossip Overview Balanced Exchange In each round: Select partner Exchange histories Trade equal number of updates Incentive compatible! Optimistic Push In each round: Select partner Exchange histories Trade possibly unequal numbers of updates Safety net for lagging peers
86 BAR Gossip Overview Balanced Exchange In each round: Select partner Exchange histories Trade equal number of updates Incentive compatible! Optimistic Push In each round: Select partner Exchange histories Trade possibly unequal numbers of updates Safety net for lagging peers
87 Optimistic Push A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange B
88 Optimistic Push A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange B ids, {u 7,u 8,u 9 } A
89 Optimistic Push A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange B ids, {u 7,u 8,u 9 } A ids, {u 1 } B
90 Optimistic Push A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange B ids, {u 7,u 8,u 9 } A ids, {u 1 } B
91 Optimistic Push Q: How do we encourage a lagging client to send as many updates as possible? A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange ids, {u 7,u 8,u 9 } A B ids, {u 1 } B
92 Optimistic Push Q: How do we encourage a lagging client to send as many updates as possible? A: Require both briefcases to have the same number of items If necessary, include junk A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange ids, {u 7,u 8,u 9 } A B ids, {u 1 } B
93 Optimistic Push Q: How do we encourage a lagging client to send as many updates as possible? A: Require both briefcases to have the same number of items A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange ids, {u 7,u 8,u 9 } A B If necessary, include junk ids,{u 1, junk, junk} B
94 Optimistic Push Q: How do we encourage a lagging client to send as many updates as possible? A: Require both briefcases to have the same number of items A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange ids, {u 7,u 8,u 9 } A B If necessary, include junk Junk is larger than an update ids,{u 1, junk, junk} B
95 Optimistic Push Q: How do we encourage a lagging client to send as many updates as possible? A: Require both briefcases to have the same number of items A {u 2,u 4,u 5,u 6,u 7,u 8,u 9 } {u 1,u 3 } History exchange ids, {u 7,u 8,u 9 } A B If necessary, include junk Junk is larger than an update ids,{u 1,u 3, junk} B
96 BAR Gossip Recap Balanced Exchange In each round: Select partner Exchange histories Trade equal number of updates Incentive compatible! Optimistic Push In each round: Select partner Exchange histories Trade possibly unequal numbers of updates Explore strategy space experimentally
97 FlightPath Experiments Setup: 45 Emulab clients, each update multicast to random 3 clients Goal: evaluate Optimistic Push strategy space Which strategies are attractive? Which strategies are attractive with failures?
98 Alternate Strategies in Optimistic Push Responds with updates Responds with junk Doesn t respond Initiates Pushes Does not initiate pushes
99 Alternate Strategies in Optimistic Push Responds with updates Responds with junk Doesn t respond Initiates Pushes Follow Protocol Does not initiate pushes
100 Alternate Strategies in Optimistic Push Responds with updates Responds with junk Doesn t respond Initiates Pushes Follow Protocol Wasteful Strategy Does not initiate pushes
101 Alternate Strategies in Optimistic Push Responds with updates Responds with junk Doesn t respond Initiates Pushes Follow Protocol Wasteful Strategy Does not initiate pushes Other Strategies
102 Convergence Graph
103 Convergence Graph
104 Convergence Graph
105 Convergence Graph
106 Reliability with Byzantine Viewable
107 Conclusions BAR Gossip: Balanced Exchange: provable, ~98% Optimistic Push: ~99.9% Two key ideas: Verifiable partner selection Fair enough exchange Currently working on: Dynamic membership Partial membership Network awareness
108 Backup Slides
109 Optimistic Push s Effect Probability of receiving an update Balanced + Optimistic Traditional gossip Balanced Proportion of rational nodes 72
110 Why Resend Key Requests? A History exchange B Cost to A is small compared to big benefit of unlocking briefcase Cost to B is large compared to small benefit of not sending key Briefcase exchange AB A BA? A BA? A BA B 73
111 TCP and UDP UDP necessary so that each peer believes its partner will send key requests A History exchange Briefcase exchange B TCP Key exchange UDP 74
112 Why Reject? Peer terminates an exchange if that peer expects nothing useful from its partner Peer expects something useful only if it believes in fair enough exchange Fair enough exchange mechanism relies on mutual fear of eviction 75
113 How Does Eviction Work? Broadcaster evicts clients by attaching eviction notices onto updates Broadcaster periodically asks clients to testify against their peers Clients testify because they expect nothing useful from future exchanges with those peers 76
114 End-to-End Metric Strategy Jitter Std. Dev. Follow Protocol 0.48% 1.16% Wasteful Strategy 0.32% 0.78% Initiate OP, Decline OP 11.59% 6.22% Respond to OP with useful 18.10% 6.08% Respond to OP with junk 14.76% 9.44% Never run OP 47.94% 7.52% 77
115 Collusion 1 Probability of receiving an update Proportion of colluding nodes Colluding nodes use unrealistic protocol BAR Gossip still robust for small colluding groups For large groups, colluding nodes may not trust each other 78
116 Denial-of-Service DoS Resistant Unforgeable Multicast (DRUM) Resource bounding Random port hopping Gal Badishi, Idit Keidar, Amir Sasson. Exposing and Eliminating Vulnerabilities to Denial of Service Attacks in Secure Gossip-Based Multicast, In Proceedings of DSN,
BAR gossip. Antonio Massaro. May 9, May 9, / 40
BAR gossip Antonio Massaro May 9, 2016 May 9, 2016 1 / 40 MAD services Single nodes cooperate to provide services in Multiple Administrative Domains Internet routing File distribution Archival storage
BAR Gossip. small-scale providers might find it simpler to use a selforganizing p2p network instead of maintaining a dedicated
BAR Gossip Harry C. Li, Allen Clement, Edmund L. Wong, Jeff Napper, Indrajit Roy, Lorenzo Alvisi, Michael Dahlin Dept. of Computer Sciences, The University of Texas at Austin We present the first peer-to-peer
Game Theory. Presented by Hakim Weatherspoon
Game Theory Presented by Hakim Weatherspoon Game Theory Main Question: Can we cheat (and get away with it)? BitTorrent P2P file distribution tool designed with incentives for contribution Users contribute
BAR Gossip. 1 Introduction
BAR Gossip Harry C. Li, Allen Clement, Edmund L. Wong, Jeff Napper, Indrajit Roy, Lorenzo Alvisi, Michael Dahlin Laboratory for Advanced Systems Research (LASR), Dept. of Computer Sciences, The University
BAR Gossip. 1 Introduction
BAR Gossip Harry C. Li, Allen Clement, Edmund L. Wong, Jeff Napper, Indrajit Roy, Lorenzo Alvisi, Michael Dahlin Laboratory for Advanced Systems Research (LASR), Dept. of Computer Sciences, The University
CS5412: TORRENTS AND TIT-FOR-TAT
1 CS5412: TORRENTS AND TIT-FOR-TAT Lecture VII Ken Birman BitTorrent 2 Widely used download technology Implementations specialized for setting Some focus on P2P downloads, e.g. patches Others focus on
Byzantine fault tolerance. Jinyang Li With PBFT slides from Liskov
Byzantine fault tolerance Jinyang Li With PBFT slides from Liskov What we ve learnt so far: tolerate fail-stop failures Traditional RSM tolerates benign failures Node crashes Network partitions A RSM w/
Byzantine Agreement with a Rational Adversary
Byzantine Agreement with a Rational Adversary Adam Groce, Jonathan Katz, Aishwarya Thiruvengadam, and Vassilis Zikas Department of Computer Science, University of Maryland {agroce,jkatz,aish,vzikas}@cs.umd.edu
Zyzzyva. Speculative Byzantine Fault Tolerance. Ramakrishna Kotla. L. Alvisi, M. Dahlin, A. Clement, E. Wong University of Texas at Austin
Zyzzyva Speculative Byzantine Fault Tolerance Ramakrishna Kotla L. Alvisi, M. Dahlin, A. Clement, E. Wong University of Texas at Austin The Goal Transform high-performance service into high-performance
FlightPath: Obedience vs. Choice in Cooperative Services
FlightPath: Obedience vs. Choice in Cooperative Services Harry C. Li 1, Allen Clement 1, Mirco Marchetti 2, Manos Kapritsos 1, Luke Robison 1, Lorenzo Alvisi 1, and Mike Dahlin 1 1 The University of Texas
BAR Fault Tolerance for Cooperative Services
BAR Fault Tolerance for Cooperative Services Amitanand S. Aiyer, Lorenzo Alvisi, Allen Clement Mike Dahlin, Jean-Philippe Martin, Carl Porth University of Texas at Austin - Dept. of Computer Science 1
Today: Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Authenticated Agreement
Chapter 18 Authenticated Agreement Byzantine nodes are able to lie about their inputs as well as received messages. Can we detect certain lies and limit the power of byzantine nodes? Possibly, the authenticity
Tradeoffs in Byzantine-Fault-Tolerant State-Machine-Replication Protocol Design
Tradeoffs in Byzantine-Fault-Tolerant State-Machine-Replication Protocol Design Michael G. Merideth March 2008 CMU-ISR-08-110 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213
DCast: Sustaining Collaboration in Overlay Multicast despite Rational Collusion
DCast: Sustaining Collaboration in Overlay Multicast despite Rational Collusion Haifeng Yu National University of Singapore Republic of Singapore haifeng@comp.nus.edu.sg Phillip B. Gibbons Intel Labs Pittsburgh,
FlightPath: Obedience vs. Choice in Cooperative Services
FlightPath: Obedience vs. Choice in Cooperative Services Harry C. Li 1, Allen Clement 1, Mirco Marchetti 2, Manos Kapritsos 1, Luke Robison 1, Lorenzo Alvisi 1, and Mike Dahlin 1 1 The University of Texas
Robust BFT Protocols
Robust BFT Protocols Sonia Ben Mokhtar, LIRIS, CNRS, Lyon Joint work with Pierre Louis Aublin, Grenoble university Vivien Quéma, Grenoble INP 18/10/2013 Who am I? CNRS reseacher, LIRIS lab, DRIM research
The Lotus-Eater Attack
Ian A. Kash Computer Science Dept. Cornell University kash@cs.cornell.edu The Lotus-Eater Attack Eric J. Friedman School of Operations Research and Information Engineering Cornell University ejf27@cornell.edu
Fault Tolerance. Distributed Software Systems. Definitions
Fault Tolerance Distributed Software Systems Definitions Availability: probability the system operates correctly at any given moment Reliability: ability to run correctly for a long interval of time Safety:
A definition. Byzantine Generals Problem. Synchronous, Byzantine world
The Byzantine Generals Problem Leslie Lamport, Robert Shostak, and Marshall Pease ACM TOPLAS 1982 Practical Byzantine Fault Tolerance Miguel Castro and Barbara Liskov OSDI 1999 A definition Byzantine (www.m-w.com):
Practical Byzantine Fault Tolerance. Castro and Liskov SOSP 99
Practical Byzantine Fault Tolerance Castro and Liskov SOSP 99 Why this paper? Kind of incredible that it s even possible Let alone a practical NFS implementation with it So far we ve only considered fail-stop
SocialLink: Utilizing Social Network and Transaction Links for Effective Trust Management in P2P File Sharing Systems
SocialLink: Utilizing Social Network and Transaction Links for Effective Trust Management in P2P File Sharing Systems Kang Chen 1, Guoxin Liu 2, Haiying Shen 2 and Fang Qi 2 1 Dept. Of ECE Southern Illinois
Today: Fault Tolerance. Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Today: Fault Tolerance. Replica Management
Today: Fault Tolerance Failure models Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Failure recovery
Revisiting Fast Practical Byzantine Fault Tolerance
Revisiting Fast Practical Byzantine Fault Tolerance Ittai Abraham, Guy Gueta, Dahlia Malkhi VMware Research with: Lorenzo Alvisi (Cornell), Rama Kotla (Amazon), Jean-Philippe Martin (Verily) December 4,
Introduction to Cryptoeconomics
Introduction to Cryptoeconomics What is cryptoeconomics? Cryptoeconomics is about... Building systems that have certain desired properties Use cryptography to prove properties about messages that happened
Practical Byzantine Fault
Practical Byzantine Fault Tolerance Practical Byzantine Fault Tolerance Castro and Liskov, OSDI 1999 Nathan Baker, presenting on 23 September 2005 What is a Byzantine fault? Rationale for Byzantine Fault
BYZANTINE GENERALS BYZANTINE GENERALS (1) A fable: Michał Szychowiak, 2002 Dependability of Distributed Systems (Byzantine agreement)
BYZANTINE GENERALS (1) BYZANTINE GENERALS A fable: BYZANTINE GENERALS (2) Byzantine Generals Problem: Condition 1: All loyal generals decide upon the same plan of action. Condition 2: A small number of
Byzantine Fault Tolerance
Byzantine Fault Tolerance CS6450: Distributed Systems Lecture 10 Ryan Stutsman Material taken/derived from Princeton COS-418 materials created by Michael Freedman and Kyle Jamieson at Princeton University.
Practical Byzantine Fault Tolerance. Miguel Castro and Barbara Liskov
Practical Byzantine Fault Tolerance Miguel Castro and Barbara Liskov Outline 1. Introduction to Byzantine Fault Tolerance Problem 2. PBFT Algorithm a. Models and overview b. Three-phase protocol c. View-change
Proactive and Reactive View Change for Fault Tolerant Byzantine Agreement
Journal of Computer Science 7 (1): 101-107, 2011 ISSN 1549-3636 2011 Science Publications Proactive and Reactive View Change for Fault Tolerant Byzantine Agreement Poonam Saini and Awadhesh Kumar Singh
Byzantine Fault Tolerance
Byzantine Fault Tolerance CS 240: Computing Systems and Concurrency Lecture 11 Marco Canini Credits: Michael Freedman and Kyle Jamieson developed much of the original material. So far: Fail-stop failures
What is Distributed Storage Good For?
Efficient Robust Storage using Secret Tokens Dan Dobre, Matthias Majuntke, Marco Serafini and Neeraj Suri Dependable Embedded Systems & SW Group Neeraj Suri www.deeds.informatik.tu-darmstadt.de EU-NSF
Introduction to Distributed Systems Seif Haridi
Introduction to Distributed Systems Seif Haridi haridi@kth.se What is a distributed system? A set of nodes, connected by a network, which appear to its users as a single coherent system p1 p2. pn send
Process groups and message ordering
Process groups and message ordering If processes belong to groups, certain algorithms can be used that depend on group properties membership create ( name ), kill ( name ) join ( name, process ), leave
Fault Tolerance Part I. CS403/534 Distributed Systems Erkay Savas Sabanci University
Fault Tolerance Part I CS403/534 Distributed Systems Erkay Savas Sabanci University 1 Overview Basic concepts Process resilience Reliable client-server communication Reliable group communication Distributed
Practical Byzantine Fault Tolerance Consensus and A Simple Distributed Ledger Application Hao Xu Muyun Chen Xin Li
Practical Byzantine Fault Tolerance Consensus and A Simple Distributed Ledger Application Hao Xu Muyun Chen Xin Li Abstract Along with cryptocurrencies become a great success known to the world, how to
CS 261 Notes: Algorand
CS 261 Notes: Algorand Scribe: Rachel Lawrence September 17, 2018 1 Introduction: Why Algorand? Algorand [6] is a cryptocurrency that works to reach consensus on transactions with a system based on Proof
Greedy Cheating Liars and the Fools Who Believe Them
Greedy Cheating Liars and the Fools Who Believe Them Stefano Arteconi, David Hales, and Ozalp Babaoglu University of Bologna Dept. of Computer Science {arteconi,hales,babaoglu}@cs.unibo.it Abstract. Evolutionary
Initial Assumptions. Modern Distributed Computing. Network Topology. Initial Input
Initial Assumptions Modern Distributed Computing Theory and Applications Ioannis Chatzigiannakis Sapienza University of Rome Lecture 4 Tuesday, March 6, 03 Exercises correspond to problems studied during
Leveraging Altruism in Cooperative Services
Leveraging Altruism in Cooperative Services Jean-Philippe Martin June 20, 2007 Abstract When there is no central administrator to control the actions of nodes in a distributed system, the users may deviate
Byzantine Techniques
November 29, 2005 Reliability and Failure There can be no unity without agreement, and there can be no agreement without conciliation René Maowad Reliability and Failure There can be no unity without agreement,
Wait-Free Regular Storage from Byzantine Components
Wait-Free Regular Storage from Byzantine Components Ittai Abraham Gregory Chockler Idit Keidar Dahlia Malkhi July 26, 2006 Abstract We consider the problem of implementing a wait-free regular register
Bitcoin, Security for Cloud & Big Data
Bitcoin, Security for Cloud & Big Data CS 161: Computer Security Prof. David Wagner April 18, 2013 Bitcoin Public, distributed, peer-to-peer, hash-chained audit log of all transactions ( block chain ).
Distributed Algorithms Practical Byzantine Fault Tolerance
Distributed Algorithms Practical Byzantine Fault Tolerance Alberto Montresor University of Trento, Italy 2017/01/06 This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International
Fault Tolerance. Basic Concepts
COP 6611 Advanced Operating System Fault Tolerance Chi Zhang czhang@cs.fiu.edu Dependability Includes Availability Run time / total time Basic Concepts Reliability The length of uninterrupted run time
Contracts: Practical Contribution Incentives for P2P Live Streaming
Contracts: Practical Contribution Incentives for P2P Live Streaming Michael Piatek, Arvind Krishnamurthy, Arun Venkataramani, Richard Yang, David Zhang, Alexander Jaffe U. of Washington, U. of Massachusetts,
Metrics for Security and Performance in Low-Latency Anonymity Systems
Metrics for Security and Performance in Low-Latency Anonymity Systems Tor user Entry node Tor Network Middle node Exit node Bandwidth per node (kb/s) (log scale) 1e+01 1e+03 1e+05 Encrypted tunnel Web
Heterogeneous Gossip. Davide Frey Rachid Guerraoui Anne-Marie Kermarrec Boris Koldehofe Maxime Monod Martin Mogensen Vivien Quéma
Heterogeneous Gossip Davide Frey Rachid Guerraoui Anne-Marie Kermarrec Boris Koldehofe Maxime Monod Martin Mogensen Vivien Quéma Outline Context Live Streaming Gossip Limitations Heterogeneous Gossip Protocol
Failure models. Byzantine Fault Tolerance. What can go wrong? Paxos is fail-stop tolerant. BFT model. BFT replication 5/25/18
Failure models Byzantine Fault Tolerance Fail-stop: nodes either execute the protocol correctly or just stop Byzantine failures: nodes can behave in any arbitrary way Send illegal messages, try to trick
Intuitive distributed algorithms. with F#
Intuitive distributed algorithms with F# Natallia Dzenisenka Alena Hall @nata_dzen @lenadroid A tour of a variety of intuitivedistributed algorithms used in practical distributed systems. and how to prototype
Incentive for P2P Fair Resource Sharing
Incentive for P2P Fair Resource Sharing Emmanuelle Anceaume CNRS IRISA, France Joint work with Maria Gradinariu (IRISA), Aina Ravoaja (IRISA) Facing Rationality Classical distributed systems P2P Either
Semi-Passive Replication in the Presence of Byzantine Faults
Semi-Passive Replication in the Presence of Byzantine Faults HariGovind V. Ramasamy Adnan Agbaria William H. Sanders University of Illinois at Urbana-Champaign 1308 W. Main Street, Urbana IL 61801, USA
Fast Byzantine Consensus
Fast Byzantine Consensus Jean-Philippe Martin, Lorenzo Alvisi Department of Computer Sciences The University of Texas at Austin Email: {jpmartin, lorenzo}@cs.utexas.edu Abstract We present the first consensus
9 Steps to Protect Against Ransomware
9 Steps to Protect Against Ransomware IT Support Analyst Task Overview Security Manager Security Dashboard Self Service log Secur Devices With Vulnerabilities Critical Important/High Moderate/Medium 40
Failures, Elections, and Raft
Failures, Elections, and Raft CS 8 XI Copyright 06 Thomas W. Doeppner, Rodrigo Fonseca. All rights reserved. Distributed Banking SFO add interest based on current balance PVD deposit $000 CS 8 XI Copyright
Secure Algorithms and Data Structures for Massive Networks
Secure Algorithms and Data Structures for Massive Networks Jared Saia Joint work with: Amos Fiat(U. Tel Aviv), Valerie King(U. Vic), Erik Vee (IBM Labs), Vishal Sanwalani(U. Waterloo), and Maxwell Young(UNM)
Peer-to-Peer Systems and Security
Peer-to-Peer Systems and Security Attacks! Christian Grothoff Technische Universität München April 13, 2013 Salsa & AP3 Goal: eliminate trusted blender server Idea: Use DHT (AP3: Pastry, Salsa: custom
Denial of Service, Traceback and Anonymity
Purdue University Center for Education and Research in Information Assurance and Security Denial of Service, Traceback and Anonymity Clay Shields Assistant Professor of Computer Sciences CERIAS Network
Information Security CS526
Information CS 526 Topic 3 Ciphers and Cipher : Stream Ciphers, Block Ciphers, Perfect Secrecy, and IND-CPA 1 Announcements HW1 is out, due on Sept 10 Start early, late policy is 3 total late days for
Distributed Algorithms Practical Byzantine Fault Tolerance
Distributed Algorithms Practical Byzantine Fault Tolerance Alberto Montresor Università di Trento 2018/12/06 This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Middleware and Distributed Systems. System Models. Dr. Martin v. Löwis
Middleware and Distributed Systems System Models Dr. Martin v. Löwis System Models (Coulouris et al.) Architectural models of distributed systems placement of parts and relationships between them e.g.
Recap. CSE 486/586 Distributed Systems Paxos. Paxos. Brief History. Brief History. Brief History C 1
Recap Distributed Systems Steve Ko Computer Sciences and Engineering University at Buffalo Facebook photo storage CDN (hot), Haystack (warm), & f4 (very warm) Haystack RAID-6, per stripe: 10 data disks,
Viewstamped Replication to Practical Byzantine Fault Tolerance. Pradipta De
Viewstamped Replication to Practical Byzantine Fault Tolerance Pradipta De pradipta.de@sunykorea.ac.kr ViewStamped Replication: Basics What does VR solve? VR supports replicated service Abstraction is
Two New Protocols for Fault Tolerant Agreement
Two New Protocols for Fault Tolerant Agreement Poonam Saini 1 and Awadhesh Kumar Singh 2, 1,2 Department of Computer Engineering, National Institute of Technology, Kurukshetra, India nit.sainipoonam@gmail.com,
Stay or Go? Participation in Under-Provisioned Video Streams
Stay or Go? Participation in Under-Provisioned Video Streams Dave Levin Daniel Malter Neil Spring Bobby Bhattacharjee University of Maryland, Computer Science Department, Robert H. Smith School of Business
Dynamically Provisioning Distributed Systems to Meet Target Levels of Performance, Availability, and Data Quality
Dynamically Provisioning Distributed Systems to Meet Target Levels of Performance, Availability, and Data Quality Amin Vahdat Department of Computer Science Duke University 1 Introduction Increasingly,
Peer-to-peer Sender Authentication for . Vivek Pathak and Liviu Iftode Rutgers University
Peer-to-peer Sender Authentication for Email Vivek Pathak and Liviu Iftode Rutgers University Email Trustworthiness Sender can be spoofed Need for Sender Authentication Importance depends on sender Update
Content Overlays (continued) Nick Feamster CS 7260 March 26, 2007
Content Overlays (continued) Nick Feamster CS 7260 March 26, 2007 Administrivia Quiz date Remaining lectures Interim report PS 3 Out Friday, 1-2 problems 2 Structured vs. Unstructured Overlays Structured
Fault Tolerance. Distributed Systems. September 2002
Fault Tolerance Distributed Systems September 2002 Basics A component provides services to clients. To provide services, the component may require the services from other components a component may depend
Enforcing Fairness in a Live-Streaming System
Enforcing Fairness in a Live-Streaming System Maya Haridasan a, Ingrid Jansch-Porto b and Robbert van Renesse a a Dept. of Computer Science, Cornell University Ithaca, New York b Institute of Informatics,
CS505: Distributed Systems
Cristina Nita-Rotaru CS505: Distributed Systems Protocols. Slides prepared based on material by Prof. Ken Birman at Cornell University, available at http://www.cs.cornell.edu/ken/book/ Required reading
CprE Fault Tolerance. Dr. Yong Guan. Department of Electrical and Computer Engineering & Information Assurance Center Iowa State University
Fault Tolerance Dr. Yong Guan Department of Electrical and Computer Engineering & Information Assurance Center Iowa State University Outline for Today s Talk Basic Concepts Process Resilience Reliable
International Journal of Advanced Research in Computer Science and Software Engineering
Volume 2, Issue 9, September 2012 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Backup Two
Agreement in Distributed Systems CS 188 Distributed Systems February 19, 2015
Agreement in Distributed Systems CS 188 Distributed Systems February 19, 2015 Page 1 Introduction We frequently want to get a set of nodes in a distributed system to agree Commitment protocols and mutual
Using Arithmetic of Real Numbers to Explore Limits and Continuity
Using Arithmetic of Real Numbers to Explore Limits and Continuity by Maria Terrell Cornell University Problem Let a =.898989... and b =.000000... (a) Find a + b. (b) Use your ideas about how to add a and
WHITE PAPER Cloud FastPath: A Highly Secure Data Transfer Solution
WHITE PAPER Cloud FastPath: A Highly Secure Data Transfer Solution Tervela helps companies move large volumes of sensitive data safely and securely over network distances great and small. We have been
Arvind Krishnamurthy Fall Collection of individual computing devices/processes that can communicate with each other
Distributed Systems Arvind Krishnamurthy Fall 2003 Concurrent Systems Collection of individual computing devices/processes that can communicate with each other General definition encompasses a wide range
When You Don t Trust Clients: Byzantine Proposer Fast Paxos
2012 32nd IEEE International Conference on Distributed Computing Systems When You Don t Trust Clients: Byzantine Proposer Fast Paxos Hein Meling, Keith Marzullo, and Alessandro Mei Department of Electrical
CS5412: CONSENSUS AND THE FLP IMPOSSIBILITY RESULT
1 CS5412: CONSENSUS AND THE FLP IMPOSSIBILITY RESULT Lecture XII Ken Birman Generalizing Ron and Hermione s challenge 2 Recall from last time: Ron and Hermione had difficulty agreeing where to meet for
The Long March of BFT. Weird Things Happen in Distributed Systems. A specter is haunting the system s community... A hierarchy of failure models
A specter is haunting the system s community... The Long March of BFT Lorenzo Alvisi UT Austin BFT Fail-stop A hierarchy of failure models Crash Weird Things Happen in Distributed Systems Send Omission
Basic concepts in fault tolerance Masking failure by redundancy Process resilience Reliable communication. Distributed commit.
Basic concepts in fault tolerance Masking failure by redundancy Process resilience Reliable communication One-one communication One-many communication Distributed commit Two phase commit Failure recovery
Zyzzyva: Speculative Byzantine Fault Tolerance
: Speculative Byzantine Fault Tolerance Ramakrishna Kotla Microsoft Research Silicon Valley, USA kotla@microsoft.com Allen Clement, Edmund Wong, Lorenzo Alvisi, and Mike Dahlin Dept. of Computer Sciences
Today: Fault Tolerance. Failure Masking by Redundancy
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Failure recovery Checkpointing
Reliable Distributed Storage A Research Perspective. Idit Keidar Technion
Reliable Distributed Storage A Research Perspective Idit Keidar Technion UnDistributed Enterprise Storage (What I Won t Talk About Today) Expensive Needs to be replaced to scale up Direct fiber access
Distributed Mechanism Design and Computer Security
Distributed Mechanism Design and Computer Security John Mitchell Vanessa Teague Stanford University Acknowledgements: J. Feigenbaum, R. Sami, A. Scedrov General problem Want to design distributed systems
Toward Intrusion Tolerant Clouds
Toward Intrusion Tolerant Clouds Prof. Yair Amir, Prof. Vladimir Braverman Daniel Obenshain, Tom Tantillo Department of Computer Science Johns Hopkins University Prof. Cristina Nita-Rotaru, Prof. Jennifer
TCP Nice: A Mechanism for Background Transfers
Improving Internet Availability and Reliability TCP : A Mechanism for Background Transfers Z. Morley Mao Lecture 7 Feb 2, 2004 Arun Venkataramani, Ravi Kokku, Mike Dahlin Laboratory of Advanced Systems
An Attack-Resilient Architecture for Large-Scale Intrusion-Tolerant Replication
An Attack-Resilient Architecture for Large-Scale Intrusion-Tolerant Replication Yair Amir 1, Brian Coan 2, Jonathan Kirsch 1, John Lane 1 1 Johns Hopkins University, Baltimore, MD. {yairamir, jak, johnlane}@cs.jhu.edu
Failure Tolerance. Distributed Systems Santa Clara University
Failure Tolerance Distributed Systems Santa Clara University Distributed Checkpointing Distributed Checkpointing Capture the global state of a distributed system Chandy and Lamport: Distributed snapshot
Proof of Stake Made Simple with Casper
Proof of Stake Made Simple with Casper Olivier Moindrot ICME, Stanford University olivierm@stanford.edu Charles Bournhonesque ICME, Stanford University cbournho@stanford.edu Abstract We study the recent
Simplifying Distributed System Development
Simplifying Distributed System Development We predict that the future is in... predicting the future. Maysam Yabandeh, Nedeljko Vasić, Dejan Kostić and Viktor Kuncak School of Computer and Communication
Shuffling with a Croupier: Nat Aware Peer Sampling
Shuffling with a Croupier: Nat Aware Peer Sampling Jim Dowling Amir H. Payberah {jdowling,amir}@sics.se 1 Introduction 2 Gossip based Protocols Gossip based protocols have been widely used in large scale
Detecting Sybil Nodes in Wireless Networks. *: SIS Dept., UNC Charlotte **: ECE Dept., WPI
Detecting Sybil Nodes in Wireless Networks with Physical Layer Network Coding Weichao Wang*, DiPu**, and Alex Wyglinski** *: SIS Dept., UNC Charlotte **: ECE Dept., WPI Motivation Network coding technique
From eventual to strong consistency. Primary-Backup Replication. Primary-Backup Replication. Replication State Machines via Primary-Backup
From eventual to strong consistency Replication s via - Eventual consistency Multi-master: Any node can accept operation Asynchronously, nodes synchronize state COS 418: Distributed Systems Lecture 10
Distributed Systems Fault Tolerance
Distributed Systems Fault Tolerance [] Fault Tolerance. Basic concepts - terminology. Process resilience groups and failure masking 3. Reliable communication reliable client-server communication reliable
Fair exchange and non-repudiation protocols
Fair exchange and non-repudiation protocols Levente Buttyán Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics buttyan@crysys.hu 2010 Levente Buttyán
MODELS OF DISTRIBUTED SYSTEMS
Distributed Systems Fö 2/3-1 Distributed Systems Fö 2/3-2 MODELS OF DISTRIBUTED SYSTEMS Basic Elements 1. Architectural Models 2. Interaction Models Resources in a distributed system are shared between
Algorand: Scaling Byzantine Agreements for Cryptocurrencies
Algorand: Scaling Byzantine Agreements for Cryptocurrencies Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, Nickolai Zeldovich Presented by: Preet Patel and Umang Lathia Outline Overview of Distributed
Coordination 1. To do. Mutual exclusion Election algorithms Next time: Global state. q q q
Coordination 1 To do q q q Mutual exclusion Election algorithms Next time: Global state Coordination and agreement in US Congress 1798-2015 Process coordination How can processes coordinate their action?