Nash Equilibria in Distributed Systems Mohamed G. Gouda & H. B. Acharya

1. Presenter Aly Farahat Ph.D. Student Automatic Software Design Lab Computer Science Department Michigan Technological University Nash Equilibria in Distributed SystemsMohamed G. Gouda & H. B. Acharya Automatic Software Design Lab

2. Automatic Software Design Lab • A Nash-Equilibrium is a property of stable states in a game. It means that no player should try to perturb this state (make a move) from this point as it may decrease its gain

3. Automatic Software Design Lab Contents • Definitions • Characterization • Taxonomy

4. Automatic Software Design Lab Definitions

5. Automatic Software Design Lab Nash Equilibrium • Origins Concepts from Game Theory • Goal Characterizing a state from which local actions might eventually lead to no gain

6. Automatic Software Design Lab Terminology • Stabilization: All distributed system computations are finite • Fixed-Point: Termination state in a distributed computation (no processes are enabled) • Equilibrium Point: Fixed-Point! • Local Perturbation: Transitions on a process local states while in a Fixed-Point

7. Automatic Software Design Lab Gain Function • A set G of local functions, one per process i G={ g.i } • g.i is defined only at equilibrium states and undefined elsewhere

8. Automatic Software Design Lab Nash Equilibrium A Fixed-Point s is a Nash Equilibrium wrt {g.i} iff For every process i, for every local perturbation, there exists a fixed-point s’ such that g.i(s’)<= g.i(s)

9. Automatic Software Design Lab Intuitively • In a Nash-Equilibrium s, no process i has the incentive to perturb its equilibrium as it might decrease its gain function. • In a non Nash-Equilibrium ns, there exists a process j that would necessarily increase its local gain g.j by perturbing ( by a specific perturbation) its equilibrium.

10. Automatic Software Design Lab Illustration

11. Automatic Software Design Lab Characterization of Nash Equilibria

12. Automatic Software Design Lab Sufficient Conditions Theorem 1: s is a Nash Equilibrium wrt {g.i} if any of the following is true: 1- g.i has its maximum at s, for all i. 2- For every local perturbation pi from s there exists a stable state s’ reachable by the actions of i such that g.i(s’)<=g.i(s) Why are these conditions unnecessary?

13. Automatic Software Design Lab Sufficient Conditions (Cont’d) Theorem 2: ns is not a Nash Equilibrium wrt { g.i } if: There exists i with a second fixed point s’ directly reachable from s by a local perturbation of i. Why this is not necessary?

14. Automatic Software Design Lab Absolute Nash Equilibrium(Sufficient Conditions) Theorem 3: s is a Nash Equilibrium w.r.t. any set of gain functions if: For every i, for every perturbation pi the system has a local action that returns it to state s.

15. Automatic Software Design Lab Construction of Gain Functions Theorem 4: For any stabilizing distributed system: • A set of constant gain functions { g.i | g.i=ci} makes every fixed-point a Nash-Equilibrium

16. Automatic Software Design Lab Construction of Gain Functions (Cont’d) Theorem 4(b): For any stabilizing distributed system: If there are two fixed points, s and s’, different only in one local variable of process j. We can make s’ a non-Nash Equilibrium by forcing a local perturbation from s’ to s with g.j(s’)<g.j(s)

17. Automatic Software Design Lab Taxonomy based on Nash Equilibira

18. Automatic Software Design Lab • Relatively Perturbation-Proof Systems • Relatively Perturbation-Prone Systems • Absolutely Perturbation-Proof Systems • Absolutely Perturbation-Prone Systems (empty)

19. Automatic Software Design Lab Relatively Perturbation-Proof • A stabilizing system is relatively perturbation-proof iff: • There exists S={ g.i } such that every fixed-point is a Nash Equilibrium w.r.t S

20. Automatic Software Design Lab Maximal Matching Bidirectional Ring m.i==i-1 && m.(i-1)==i-2  m.i:=i m.i==i+1 && m.(i+1)==i+2  m.i:=i m.i==i && m.(i-1)!=i-2 m.i:=i-1 m.i==i && m.(i+1)!=i+2  m.i:=i+1 g.i=0 if m.i==i g.i=1 otherwise Process i should match with one of its neighbors, otherwise it should keep its value to i.

21. Automatic Software Design Lab Nash Equilibrium of Matching • If m.i !=i, and m.i is a fixed-point, then g.i=1. This is a maximum! From theorem 1(a), it is a Nash-Equilibrium • If m.i==i, g.i=0. But no perturbation will break a match, hence, m.i == i is restablished. • “Bidirectional Matching” is relatively perturbation proof

22. Automatic Software Design Lab Relatively-Perturbation Prone • A stabilizing system is relatively perturbation-prone iff: • There exists S={ g.i } such that some fixed-point is a non-Nash Equilibrium w.r.t S • Use Theorem 4(b) to design such systems

23. Automatic Software Design Lab Absolutely Perturbation-Proof • A stabilizing system is absolutely perturbation-proof iff: • For every S={ g.i }, every fixed-point is a Nash Equilibrium w.r.t S • Use Theorem 3 to design such systems

24. Automatic Software Design Lab A subclass of absolutely perturbation proof systems Theorem 5: If a stabilizing system has only one fixed-point, it is absolutely-perturbation proof Why?

25. Automatic Software Design Lab Absolutely Perturbation-Prone • A stabilizing system is absolutely perturbation-prone iff: • For every S={ g.i }, there exists a non-Nash Equilibrium fixed-point w.r.t S • Use Theorem 4(a) to show that no such system exists: we can always construct a set of gain functions to make every fixed-point a Nash-Equilibrium

26. Automatic Software Design Lab Why?? Partial Order among Classes

27. Automatic Software Design Lab Further Investigations • Given a set of gain functions, automatically transforming a perturbation-prone to a perturbation-proof system • Identify the perturbations leading to other equilibria with higher gains • Applicability of this concept to set of states rather than states (consider the notion of invariant) • How to come up with gain-functions representing the system progress properties

28. Automatic Software Design Lab Further Readings • John F Nash, “Equilibrium point in n-person games,” Proceedings of the National Academy of Sciences of the United States of America, 36(1):48-49, 1950. • A. Arora & M. G. Gouda, “Closure and convergence: a foundation of fault-tolerant computing.” In Proceedings of the 22nd International Conference On Fault-Tolerant Computing Systems

29. Automatic Software Design Lab Thank you!