Dependent Types for Reasoning About Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi - Cincinnati

Dependent Types for Distributed Components2 Motivation and Context Aim: practical support for the development of high-confidence distributed systems practical: modularity (components) low cost high-confidence: respects resource budget, private memory… executes “correctly”

Dependent Types for Distributed Components3 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 Program Text of A... Program Text of B... Program Text of C...

Dependent Types for Distributed Components4 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

Dependent Types for Distributed Components5 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

Dependent Types for Distributed Components6 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

Dependent Types for Distributed Components7 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 ]

Dependent Types for Distributed Components8 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 intarray(n) is the type for integer arrays of size n.

Dependent Types for Distributed Components9 McCarthy’s 91 Function {i:nat} /* metric: max(0, 101-i) */ [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); }

Dependent Types for Distributed Components10 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

Dependent Types for Distributed Components11 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

Dependent Types for Distributed Components12 Feasibility of Project Certificates A tool (cidl) for testing transient in CORBA objects has been implemented Transient, and other local certificates, have been applied to several examples Dependent Types A dependently typed language (Xanadu) has been formalized and prototyped Xanadu applied to several examples

Dependent Types for Distributed Components13 Synergy of Collaboration Paul: Use transient properties to reason about progress in distributed systems Use locally-checkable component properties to establish global system properties Hongwei: Design a dependent type system to capture termination properties Implement a type-checker to verify captured termination properties

Dependent Types for Distributed Components14 Future Goals Research topics Certification of mobile code for distributed systems Build high confidence systems External Funding NSF (OS/Compiler & SE/Language) DARPA (high-confidence computing)

Dependent Types for Distributed Components15 Summary of Proposed Work Extend dependent types to capture termination Characterize certificates that can be supported by dependent types Key qualities: modular holistic high-confidence, not proof