1. Dependent Types for High- Confidence Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.)

2. Specifying and Testing Quantified Progress Properties2 Gaining confidence that program text satisfies required behavior Two Challenges Specifying com- ponent behavior and reasoning about its com- position System Properties Component A Properties Component B Properties Component C Properties Component A Program Text Component B Program Text Component C Program Text

3. Specifying and Testing Quantified Progress Properties3 Dependent Types enriched types familiar, low cost Two Synergistic Solutions Synergy: locality Surprising Connection: termination Certificates temporal logic local properties Typically not used for reasoning about progress Typically not tied to real programs

4. Specifying and Testing Quantified Progress Properties4 Talk Outline Background and Motivation Phase I: foundational Dependent types for metrics local termination Certificates for progress with metrics functional transient, functional next Phase II: integration DXanadu: a distributed dependently typed language

5. Phase I Dependent Types for Metrics

6. Specifying and Testing Quantified Progress Properties6 Dependent Types Dependent types are types that can depend on the values of expressions Examples int(i) is a singleton type that contains the only integer equal to i int array(n) is the type for integer arrays of size n

7. Specifying and Testing Quantified Progress Properties7 Metrics and Integer Constraints Index variables and expressions i+j, i-j, i*j, i/j, … Let  = be a tuple of index expressions. We write   : metric if we have  i j :nat for 1  j  n Lexicographic ordering Well-founded

8. Specifying and Testing Quantified Progress Properties8 McCarthy’s 91 Function {i:nat} => [j:int | (i 100  j = i-10)] int(j) ninetyone (x:int(i)) { if (x <= 100) { return ninetyone (ninetyone (x+11)); } else { return (x-10); }

9. Specifying and Testing Quantified Progress Properties9 Cost Effectiveness In general, termination of a program is difficult to prove However, critical sections tend to be small and manageable More importantly, we provide the programmer with a range of choices higher effort  lower effort higher benefit  lower benefit

10. Specifying and Testing Quantified Progress Properties10 Spectrum of Choices Static Check Programmer provides a metric Type-checker verifies monotonicity of metric Dynamic Check Programmer provides a metric Type-checker inserts run-time tests to check monotonicity of metric Checkpointing Programmer does not provide a metric Checkpoint taken before “dangerous” action

11. Specifying and Testing Quantified Progress Properties11 Bit Reversing from FFT {a:nat,b:pos} => int bitrev (j:int(a),k:int(b)) { if (k < j) { return bitrev (j-k,k/2); } else { return j+k; }

12. Specifying and Testing Quantified Progress Properties12 Bit Reversing from FFT {a:nat,b:pos} => int bitrev (j:int(a),k:int(b)) { if (k < j) { assert (k > 1); return bitrev (j-k,k/2); } else { return j+k; }

13. Phase I Functional Certificates

14. Specifying and Testing Quantified Progress Properties14 Transient P for component C means: progress: if P ever becomes true, it eventually becomes false locality: guaranteed by an action of C alone More formally: transient P   a  C : [ P  wp.a.  P ] “Transient”: A Certificate for Progress

15. Specifying and Testing Quantified Progress Properties15 E.g.: Mutual Exclusion System: every client request is eventually satisfied Token-passing Layer Client C Client D Client E Client B Client A Client: token is eventually returned transient holding

16. Specifying and Testing Quantified Progress Properties16 Client Program To prove transient holding, show CS terminates (ie ninetyone terminates) *[ non CS ! request ? token //holding is true CS: ninetyone(0); ! token //holding is false ]

17. Specifying and Testing Quantified Progress Properties17 Testing Transience Recall for transient.P: If P ever becomes true, it is later false Note: P may never become true Consequence of formal definition: transient.P  infinitely often  P To test for transience, use:  transient.P  finitely often  P Look for a finite trace after which only P

18. Specifying and Testing Quantified Progress Properties18 Timestamped History transient.P true false P time danger P set timestamp clear timestamp predicate evaluation…

19. Specifying and Testing Quantified Progress Properties19 Multiple Properties A component may have many progress properties transient.(status = critical) transient.(status = idle ^ button_down) transient.(... )

20. Specifying and Testing Quantified Progress Properties20 Multiple Transient Prop’s transient.P ^ transient.Q ^ transient.R Complexity: Space: n timestamps kept Time: n predicate evaluations with each step P Q R

21. Specifying and Testing Quantified Progress Properties21 Quantification of Transient Transient properties often quantified “state changes eventually” Ak :: transient.(status = k) “value of metric changes eventually” Ak :: transient.(metric = k ^ status = critical) Naïve expansion is costly to monitor If dummy ranges over a set D of values: |D| timestamps to maintain |D| predicate evaluations to perform

22. Specifying and Testing Quantified Progress Properties22 Observation: Singularity Predicates are mutually exclusive Ak :: transient.(metric = k ^ status = critical) (P) = transient.(metric = 0 ^ status = critical) (P 0 ) ^ transient.(metric = 1 ^ status = critical) (P 1 ) ^ transient.(metric = 2 ^ status = critical)… (P 2 )… Truth of predicate functionally determines value of dummy variable For P.(s,k) : predicate on state s, dummy k: Ak :: transient.(P.(s,k)) is functional iff Ef :: (P.(s,k)  k = f.s)

23. Specifying and Testing Quantified Progress Properties23 Functional Transience Ak :: transient.(metric = k ^ status = critical) When is there “danger” of a possible violation? P0P0 P1P1 P2P2 P3P3

24. Specifying and Testing Quantified Progress Properties24 Satisfying Functional Transience A functional transient property is “satisfied” when either: The predicate that is true changes Value(s) of dummy variable(s) that makes predicate true changes All predicates become false Provide f: states  dummy values Evaluate k using f Evaluate P using k

25. Specifying and Testing Quantified Progress Properties25 Functional Transience Ak :: transient.(metric = k ^ status = critical) Complexity: Space: 1 timestamp & value(s) of dummy(s) Time: 1 function & 1 predicate evaluation P0P0 P1P1 P2P2 P3P3 TS SRRRCRS

26. Specifying and Testing Quantified Progress Properties26 Generalization: Relational Transience Number of predicates that can be simultaneously true is bounded (B) Ak :: transient.(k <= metric <= k+1 ^ critical) P0P0 P1P1 P2P2 P3P3 012

27. Specifying and Testing Quantified Progress Properties27 Monitoring Relational Transience Complexity Space: B timestamps & dummy values Time: 1 relation eval’n & 2B timestamp updates P0P0 P1P1 P2P2 P3P3 TS 1 TS 0 S S RRC RR SC C S

28. Specifying and Testing Quantified Progress Properties28 Ubiquity of Functional Transience Observation: Many quantifications of transient appear to be functional E.g., timeouts and metrics Method-response semantics “method M returns a value eventually” Ak :: transient.(rcv_M = k+1 ^ snd_M = k) Ak :: transient.(rcv_M > k ^ snd_M = k) Ajk : j > k : transient.(rcv_M = j ^ snd_M = k)

29. Specifying and Testing Quantified Progress Properties29 Other Progress Operators Transient is a very basic operator Nice compositional properties Higher-order operator: leads-to (+->) Testing leads-to does not always benefit from notion of functionality E.g., (Ak :: x = k +-> y = k) Other simplifications can be made (Ak :: x = k +-> x < k)

30. Specifying and Testing Quantified Progress Properties30 Quantification of Safety Properties Safety operator: P next Q “if P holds, Q holds in the next state” Similar quantifications arise Ak :: x = k next x <= k Also commonly functional Truth of pre-predicate determines value(s) of dummy(s) Similar performance benefit 1 function & 1 predicate evaluation

31. Phase II DXanadu: A distributed dependently-typed language

32. Specifying and Testing Quantified Progress Properties32 DXanadu Integration: dependent types and distributed programming Metrics for termination and progress Certificates for specs and reasoning Implementation test bed

33. Specifying and Testing Quantified Progress Properties33 Communication Primitives Sequential Xanadu augmented with send() and receive() keywords Point-to-point communication, with fair merge at destination unit send(m,d) m : basic type, arrays, non-nested records d : integer id of destination node m = receive() Asynchronous send, blocking receive

34. Specifying and Testing Quantified Progress Properties34 Architecture Java RMI for communication backbone Serialization of message types Static bootstrapping and component binding DXanadu #0 DXanadu #1 DXanadu #2 POBox A DXanadu #3 POBox B DXanadu #4 POBox C PostCentral java ocaml

35. Specifying and Testing Quantified Progress Properties35 Challenges to Be Faced Message typing Dynamic structures (nesting, lists) Preserving (dependent) type information Fault tolerance Conservative checkpointing for rollback Linking code with certificate spec Run-time tests for validation Dynamic computations Discovery, binding, departure Experimentation with DXanadu

36. Specifying and Testing Quantified Progress Properties36 Papers Acknowledging OBR LICS 01: “Dependent Types for Program Termination Verification” FSE 01: “Increasing Client-Side Confidence in Remote Component Implementations” ICFP 01: “A Dependently-Typed Assembly Language” ICSE 01: “The Specification and Testing of Quantified Progress Properties in Distributed Systems” J. of Applied Systems Studies: “Testing the Protocol Conformance of Distributed components” (submitted)

37. Dependent Types for High- Confidence Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.)