We present a logical framework to reason
about distributed systems called the Logic of Events. This logic has been formalized in Nuprl. We developed a suite of tools and tactics in Nuprl to reason about event classes. We also developed a programming language called EventML which allows programmers to write specifications of distributed protocols

Bickford, Mark

Constable, Robert L.

Rahli, Vincent

Open Repository and Bibliography - Luxembourg

The Logic of Events, a frameworkto reason about distributed systemsMark Bickford Vincent Rahli Robert ConstableCornell UniversityProtocol specification and verification. In response to the needof ensuring correctness and security properties of distributed sys-tems and system components in general, programming languageshave been developed, featuring rich types such as dependent typesor session types, expressive enough to specify such properties.Also, some progress has been done towards automatically provingthat programs meet such specifications (often by type checking).Following this line of work, we use constructive logic to synthe-size protocols from specifications, and provide tools that facilitatethe use of formal methods to prove the correctness of distributedprotocols based on asynchronous message passing.Constructive logic. Constructive logic is appropriate for speci-fying and reasoning about distributed algorithms for two reasons.The first is that the proofs-as-programs correspondence holds forconstructive logic and we want to extract correct-by-constructionalgorithms and protocols from our proofs. The second reason issubtler and equally important. A specification of a distributed algo-rithm at a high level of abstraction concentrates on specifying theinformation flow between the participating agents. This informa-tion can be viewed as the evidence for or knowledge of propertiesof the global system. Such evidence is precisely the semantics ofconstructive logic, so there is a natural affinity between construc-tive logic and specification of information flow. In reasoning aboutinformation flow it is important to reason both about the acquisi-tion and the loss of information. For example, when informationfrom different sources is aggregated it may be that knowledge ofthe source of the information is lost. Constructive logic, and in par-ticular constructive type theory, can account for precisely what anagent may infer from evidence it has received.The Logic of Events. We present a logical framework to reasonabout distributed systems called the Logic of Events. This logichas been formalized in Nuprl [1, 2]. Nuprl’s logic is a constructivetype theory called Computational Type Theory (CTT). This logicallows one to reason about events and how they relate to each othervia, among other things, a well-founded causal ordering on them.The Logic of Events is based on a model of message passing.An event is an abstract object corresponding to the receipt of amessage at a location; the message is called primitive informationof the event. A message is a triple of the following dependent type:Header×T : Type×T . For example, 〈`` this is a header`` ,Z, 1〉is a message. Event orderings provide the basic structure to reasonabout events. An event ordering consists of a set of events, afunction that associates a location with each event, a function thatassociates a primitive information with each event, and a causalordering relation on events. An event ordering can be seen as aformalization of the message sequence diagrams used by protocoldesigners. A fundamental method for reasoning about properties ofevent orderings, originally pioneered by Lamport [3], is inductionon the causal order. With this method we can prove both safety andliveness properties of our specifications.Event classes. A central concept in the Logic of Events is the oneof event classes, also called event observers. Event classes observehow distributed systems agents “react” on receipt of messages.Formally, an event class of type T , for some type T , is a functionthat takes an event ordering and an event in that event ordering, andreturns a bag (or multiset) of elements of type T . If the class Xassociates the bag {v1 , . . . , vn} with the event e , we say that Xobserves the values vi ’s at e . Typically, one can observe complexinformation by composing simple event classes. For example, aclass may observe that the receipt of a certain message meansthat consensus has been reached. Note that different classes mayobserve different values at a single event. Event classes can beseen as having two facets: a logical one and a programming one.By that we mean that, (1) each event class X can be describedby expressing the relation between the elements observed by Xand the elements observed by X ’s components (logical aspect); (2)one can extract programs from those classes we call programmable(programming aspect). Informally a class X is programmable iffthere exists a corresponding program that can produce all andonly the elements observed by X . Such extracted programs areimplementations of the corresponding classes.Specifying and proving protocols. We developed a suite of toolsand tactics in Nuprl to reason about event classes. We also devel-oped a programming language called EventML which allows pro-grammers to write specifications of distributed protocols. Such aspecification is an event class describing the information flow of adistributed program. EventML features an automatic program syn-thesizer. In addition, it can dock to Nuprl (EventML is interpretedto Nuprl) in order to formally prove protocol properties and gener-ate (within Nuprl) correct-by-construction programs by extraction;we say that these extracted programs are correct-by-docking.We have specified several protocols such as a simple two-thirdsconsensus protocol and Paxos, and we keep improving our Nuprltools and tactics as we prove properties of these protocols.A simple example. Here is a toy example that we call the “ping-pong” specification (written in EventML):p a r a m e t e r p : Loc p a r a m e t e r l o c s : Loc Bagi n t e r n a l p ing ‘ ‘ p ing ‘ ‘ Loci n t e r n a l pong ‘ ‘ pong ‘ ‘ Loci n p u t s t a r t ‘ ‘ s t a r t ‘ ‘ Loco u t p u t o u t ‘ ‘ o u t ‘ ‘ Loci m p o r t bag−mapc l a s s ReplyToPong c l i e n t l o c =l e t F j = i f l o c = j t h e n { o u t ’ s e n d c l i e n t l o c} e l s e {}i n F o pong’bas e ; ;c l a s s SendPing l o c = Outpu t (\ s l f .{ p i n g ’ s e n d l o c s l f } ) ; ;c l a s s Hand le r ( c l i e n t , l o c ) = SendPing l o c| | ReplyToPong c l i e n t l o c ; ;c l a s s ReplyToPing =(\ s l f .\ l o c .{ pong’s end l o c s l f }) o p i n g ’ b a s e ; ;c l a s s D e l e g a t e =l e t F c l i e n t = bag−map (\ l o c . ( c l i e n t , l o c ) ) l o c si n F o s t a r t ’ b a s e ; ;main ( D e l e g a t e >>= Hand le r ) @ {p} | | ReplyToPing @ l o c sFigure 1 Inductive logical form of the ping protocol∀[locs:bag(Id)]. ∀[p:Id]. ∀[es:EO’]. ∀[e:E]. ∀[i:Id]. ∀[m:Message].{<i, m> ∈ ping-pong_main(locs;p)(e)⇐⇒ ((loc(e) = p)∧ (↓∃e’:{e’:E| e’ ≤loc e }∃z:Id(z ∈ Base([start];Id)(e’)∧ (∃z1:Id(((((i = z1) ∧ (m = make-Msg([ping];Id;loc(e)))) ∧ (e = e’))↓∨ (((i = z) ∧ (m = make-Msg([out];Id;z1))) ∧ z1 ∈ Base([pong];Id)(e)))∧ bag-member(Id;z1;locs))))))↓∨ (bag-member(Id;loc(e);locs) ∧ (m = make-Msg([pong];Id;loc(e))) ∧ i ∈ Base([ping];Id)(e))}Similar to IO-Automata [4] and other specification languageswe have declared the input, output, and internal events. Unlike IO-Automata, there are no explicit state variables. Instead we have de-clared the base classes ( start’base , ping’base , and pong’base) thatobserve the receipt of input and internal messages (with headers`` start`` , `` ping`` , and `` pong`` respectively) and we have de-fined other classes (Delegate, Handler, SendPing, ReplyToPong, andReplyToPing) in terms of the base classes using class combinators.The combinator X || Y is a parallel composition of classesX and Y. An expression like (cout s loc) o Pong is a functioncomposition, applying the function (cout s loc) to the informationobserved by class Pong.The combinator (X >>= Y) is a delegation (or bind) operatorwith which event classes form a monad. It has the effect of spawn-ing a subprocess (Y v) whenever class X observes a value v. Wetypically use it to decompose a complex algorithm into subtasksthat are easier to define and reason about. One typical use is todefine subprocess (Y v) to be handler that sends some messages re-lated to parameter v, gather the responses to those messages, reportsan answer (by sending a message), and then halts.Message Automata. A class X declared main in an EventMLspecification must be a class of type Loc ∗ Msg. A run of theprogram implementing X will consist of a set of processes. When aprocess has a message in its in-box, it computes in response the bagof location-message pairs specified by class X and these responsesare added to its out-box. A message-passing layer moves messagesfrom out-boxes to the addressed in-boxes.Programmability and class relation. As mentioned above, eventclasses can be seen as having two facets: a programming one anda logical one. We have proved in Nuprl that all the event classesmentioned above are programmable, and we have extracted (dis-tributed) programs from these proofs. Using these basic results onprogrammability, Nuprl can automatically prove that the main classof an EventML specification is programmable and then extract theimplementation (the set of processes that implement the MessageAutomaton) from the proof. The EventML tools can mimic the tac-tic that Nuprl uses and synthesize code from specifications directlyin EventML without using Nuprl. If further assurance is neededNuprl can check that the synthesized code agrees with the codeextracted from a proof.Event classes also have a logical aspect. Given an event e insome event structure, a class X of type T , and a element v inT , we write v ∈ X (e) if X observes v at event e , i.e., v isin the bag of observations that the class X makes at event e .This relation between observed elements, events, and classes iscalled the class relation. One can then express the class relationof combinators in terms of their components. For example, one canexpress v ∈ (X >>= Y )(e) in terms of x ∈ X (e) for observationsx made by X and in terms of y ∈ (Y x)(e) for observations ymade by (Y x).For each of the event class combinators C mentioned above, wehave proved in Nuprl an equivalence relation that expresses whenan element v is observed by C . We use these lemmas to proveproperties of protocols.Inductive logical forms. The inductive logical form of a spec-ification is a first order formula that characterizes completely theobservations (the responses) made by the main class of the specifi-cation. The formula is inductive because it typically characterizesthe responses at event e in terms of observations made by a sub-component at a prior event e′ < e. Such inductive logical forms areautomatically generated in Nuprl from event class definitions, andsimplified using various rewritings. With an inductive logical formwe can easily prove invariants of the specification by induction oncausal order. For example, fig. 1 presents the inductive logical formautomatically generated for the “ping-pong” specification definedabove. Our “ping-pong” specification can either observe a messageproduced by the Handler class (corresponding to the violet part)or by the ReplyToPing (corresponding to the blue part). If Handlerobserves the sending of a message m, it means that a `` start`` mes-sage has been received at location p in the past and that m is eithera `` ping`` message sent to one of the locations from the bag locs ,or a `` out`` message sent in response to a `` pong`` message.Conclusion. Our EventML tool provides a language for ele-gant, abstract specification of distributed algorithms that use asyn-chronous message passing. It is not yet suited for reasoning aboutconcurrent shared memory systems.It provides automated code synthesis that is correct-by-construction.It also automates major parts of the reasoning about higher-levelsafety and liveness properties of the specified systems, by automat-ically generating the inductive logical form. We are working onmethods for automatic verification of invariants.The theory underlying these tools is quite mature and the toolshave already been used to carry out the verification of several non-trivial consensus algorithms. We have specified and generated codefor a complete version of Lamport’s Paxos algorithm (verificationof its high-level requirements is on-going, but should be completebefore 2012).References[1] Stuart F. Allen, Mark Bickford, Robert L. Constable, Richard Eaton,Christoph Kreitz, Lori Lorigo, and E. Moran. Innovations in computa-tional type theory using nuprl. J. Applied Logic, 4(4):428–469, 2006.[2] R. L. Constable, S. F. Allen, H. M. Bromley, W. R. Cleaveland, J. F.Cremer, R. W. Harper, D. J. Howe, T. B. Knoblock, N. P. Mendler,P. Panangaden, J. T. Sasaki, and S. F. Smith. Implementing mathematicswith the Nuprl proof development system. Prentice-Hall, Inc., UpperSaddle River, NJ, USA, 1986.[3] Leslie Lamport. Time, clocks, and the ordering of events in a distributedsystem. Commun. ACM, 21(7):558–565, 1978.[4] Nancy A. Lynch. Distributed Algorithms. Morgan Kaufmann, 1996.

Logic of Events, a framework to reason about distributed systems

Constable, Robert

eCommons@Cornell

The Logic of Events, a framework to reason about distributed systems

http://ecommons.cornell.edu/bitstream/1813/28695/2/The_Logic_of_Events-BCR2012.pdf

Logic of Events, a framework to reason about distributed systems

Abstract

Similar works

Full text

Available Versions

Open Repository and Bibliography - Luxembourg

eCommons@Cornell