Causal Consistency for Reversible Multiparty Protocols

In programming models with a reversible semantics, computational steps can be undone. This paper addresses the integration of reversible semantics into process languages for communication-centric systems equipped with behavioral types. In prior work, we introduced a monitors-as-memories approach to seamlessly integrate reversible semantics into a process model in which concurrency is governed by session types (a class of behavioral types), covering binary (two-party) protocols with synchronous communication. The applicability and expressiveness of the binary setting, however, is limited. Here we extend our approach, and use it to define reversible semantics for an expressive process model that accounts for multiparty (n-party) protocols, asynchronous communication, decoupled rollbacks, and abstraction passing. As main result, we prove that our reversible semantics for multiparty protocols is causally-consistent. A key technical ingredient in our developments is an alternative reversible semantics with atomic rollbacks, which is conceptually simple and is shown to characterize decoupled rollbacks.


Introduction
This paper is about reversible computation in the context of models of concurrency for communication-centric software systems, i.e., collections of distributed software components in which concurrent interactions are governed by reciprocal dialogues or protocols.
Building upon process calculi techniques, these models provide a rigorous footing for message-passing concurrency; on top of them, many analysis techniques based on behavioral types and contracts have been put forward to enforce key safety and liveness properties (see, e.g., the survey [HLV + 16]). Reversibility is an appealing notion in concurrency at large [LMT14], but especially so in communication-centric scenarios: it may elegantly abstract fault-tolerant communicating systems that react to unforeseen circumstances (say, local failures) by "undoing" computational steps so as to reach a previous consistent state.
In communication-centric software systems, protocols specify the intended communication structures among interacting components. We focus on process calculi equipped with behavioral types, which use those protocols as types to enforce communication correctness. The interest is in protocol conformance, the property that ensures that each component atomic rollbacks, which we show to coincide with the semantics with decoupled rollbacks (Theorem 3.12).
(3) We formally connect reversibility at two distinct levels: the (declarative) level of global types and the (operational) level of processes monitored by local types with cursors (Theorem 3.27). We stress that asynchrony, abstraction passing, and decoupled rollbacks are not considered in prior works [TY16,DG16,MP16,MP17b]. Asynchrony and decoupled rollbacks are delicate issues in a reversible multiparty setting-we do not know of other asynchronous calculi with reversible semantics, nor featuring the same combination of constructs. The formal connection between global and local levels of abstraction (Theorem 3.27) is also unique to our multiparty setting.
Organization. In Section 2, we introduce our process model of reversible multiparty protocols, and illustrate it with examples. In Section 3 we establish causal consistency by relating decoupled and atomic semantics, and connect reversibility at global and local levels. Section 4 discusses an alternative decoupled semantics and related works. Section 5 collects some concluding remarks. This paper is a revised and extended version of the conference paper [MP17a]. In this presentation we consider a language with labeled choices (not treated in [MP17a]), provide additional examples, streamline the presentation of the decoupled and atomic semantics, extend comparisons with related works, and include technical details (definitions and proofs). Multiparty protocols are defined in terms of global types, which declaratively describe a protocol among two or more participants. A global type can be projected onto each participant so as to obtain its corresponding local type, i.e., a session type that abstracts a participant's contribution to the global protocol.

Reversible Multiparty Protocols
The semantics of global types is given in terms of forward and backward transition systems (Fig. 3). There is a configuration for each protocol participant: it includes a located process that specifies asynchronous communication behavior, subject to a monitor that enables forward/backward steps at run-time based on the local type. The semantics of configurations is given in terms of forward and backward reduction relations (Figs. 6, 7, 8, 9, and 10). Figure 11 in § 3 summarizes our notations for semantics of global types and configurations.
We illustrate our model of reversible protocols with two examples. As a running example, we develop a reversible variant of the Three-Buyer protocol (see, e.g., [CDCPY15]) with abstraction passing (code mobility), one of the distinctive traits of our framework. This example comes in three parts-cf. § 2.1.2, § 2.2.2, and § 2.3.3. As second example, in § 2.4 we present a protocol with labeled choices.
Remark 2.1 (Colors). Throughout the paper, we use colors to improve readability. In particular, elements in blue belong to a forward semantics; elements in red belong to a backward semantics. Also, we use orange to highlight the cursor and other syntactic entities.
2.1. Global and Local Types.
2.1.1. Syntax. Let us write p, q, r, A, B . . . to denote protocol participants. The syntax of global types (G, G , . . .) and local types (T, T , . . .) is standard [HYC08] and defined as follows: G, G ::= p → q : U .G | p → q : {l i : G i } i∈I | µX.G | X | end U, U ::= bool | nat | · · · | T → T, T ::= p! U .T | p? U .T | p⊕{l i : T i } i∈I | p&{l i : T i } i∈I | µX.T | X | end The global type p → q : U .G says that p may send a value of type U to q, and then continue as G. Given a finite index set I and pairwise different labels l i , the global type p → q : {l i : G i } i∈I specifies a labeled choice: p may choose label l i , communicate this selection to q, and then continue as G i . In these two types we assume that p = q. Global recursive and terminated protocols are denoted µX.G and end, respectively. We write pa(G) to denote the set of participants in G.
Value types U include basic first-order values (constants), but also higher-order values: abstractions from names to processes. (We write to denote the type of processes.) Local types p! U .T and p? U .T denote, respectively, an output and input of value of type U by p. Type p&{l i : T i } i∈I says that p offers different behaviors, available as labeled alternatives; conversely, type p⊕{l i : T i } i∈I says that p may select one of such alternatives. Terminated and recursive local types are denoted end and µX.T , respectively. We use α to denote type prefixes p?(U ), p! U .
As usual, we consider only recursive types µX.G (and µX.T ) in which X occurs guarded in G (and T ). We shall take an equi-recursive view of (global and local) types, and so we consider two types with the same regular tree as equal.
Global and local types are connected by projection: following [HYC08], the projection of G onto participant p, written G ↓ p , is defined in Fig. 2. Projection for p → q : {l i : G i } i∈I is noteworthy: the projections of the participants not involved in the choice (different from p, q) should correspond to the same identical local type.
if r = q, r = p and ∀i, j ∈ I. 1. Alice sends a book title to Seller, which replies back to Alice and Betty with a quote. Alice tells Betty how much she can contribute. 2. Betty notifies Seller and Alice that she agrees with the price, and asks Carol to assist her in completing the protocol. To delegate her remaining interactions with Alice and Seller to Carol, Betty sends her the code she must execute. 3. Carol continues the rest of the protocol with Seller and Alice as if she were Betty. She sends Betty's address (contained in the mobile code she received) to Seller. 4. Seller answers to Alice and Carol (who represents Betty) with the delivery date.
We formalize this protocol as a global type denoted G (see below). We first define some convenient notation.
• We write p → {q 1 , q 2 } : U .G as a shorthand notation for p → q 1 : U .p → q 2 : U .G (and similarly for local types). • We write {{ }} to denote the type end → . As we will see, this is the type of a thunk process λx. P with x ∈ fn(P ), written {{P }}. A thunk is an inactive process; it can be activated by applying to it a dummy name of type end (which we will denote * ).
The global type G between A, B, and C is as follows: where price and share are base types treated as integers; also, title, OK, address, and date are base types treated as strings. Then, following the function defined in Fig. 2, we have the projections of G onto local types: Semantics of Protocols. The semantics of global types comprises forward and backward transition relations, denoted and , respectively (Fig. 3). To formalize backward steps, we require some auxiliary notions. We use global contexts, ranged over by G, G , . . . with holes '•', to record previous actions, including the choices discarded and committed: 2.2.1. Syntax. The syntax of processes and configurations is given in Fig. 4. For processes P, Q, . . . we follow the syntax of HOπ, the core higher-order session π-calculus studied in [KPY16,KPY19]. (Actually, our syntax of processes is related to HO, the sub-language of HOπ without name-passing.) The syntax of configurations builds upon that of processes.
Names a, b, c (resp. s, s ) range over shared (resp. session) names. We use session names indexed by participants, denoted s [p] , s [q] . Names n, n are session or shared names. First-order values v, v include base values and constants. Variables are denoted by x, y and recursion variables are denoted by X, Y . We write x to denote a sequence of variables, sometimes treated as a set. To define configurations, we use fresh name identifiers (keys), denoted κ, κ , . . ., and also identifiers , , . . ., which denote a process location or site (as in, e.g., the distributed π-calculus [Hen07]).
The syntax of values V includes shared names, first-order values, but also abstractions λx. P , where P is a process. Abstractions are higher-order values, as they denote functions from names to processes. As shown in [KPY16,KPY19], abstraction passing suffices to express name passing (delegation).
Process terms include prefixes for sending and receiving values V , written u! V .P and u?(x).P , respectively. Given a finite index set I, processes u {l i .P i } i∈I and u {l i : P i } i∈I implement selection and branching (internal and external labeled choices, respectively). The selection u {l i .P i } i∈I is actually a non-deterministic choice over I. In an improvement with respect to [MP16,MP17b], here we consider parallel composition of processes P | Q and recursion µX.P (which binds X in process P ). Process V u is the application which leads to substitute name u on the abstraction V . Constructs for restriction (ν n)P and inaction 0 are standard.
Session restriction (ν s)P simultaneously binds all the participant endpoints in P . We write fv(P ) and fn(P ) to denote the sets of free variables and names in P . We assume V in u! V .P does not include free recursion variables X. If fv(P ) = ∅, we call P closed.
The syntax of configurations M, N, . . ., includes inaction 0, the parallel composition M | N , and name restriction (ν n)M . Also, it includes constructs for session initiation: configuration {a! x .P } denotes the request of a service identified with a implemented in P as x; conversely, configuration {a?(x).P } denotes service acceptance.
Configurations also include the following run-time elements: • Running processes are of the form : C ; P , where is a location that hosts a process P and a (process) stack C. A stack is simply a list of processes, useful to record/reinstate the discarded alternatives in a labeled choice. • Monitors are of the form s H · x · σ ♠ , where s is the session being monitored, H is a local type with history (i.e. in which the cursorˆacts as a "memory"), x is a set of free variables, the store σ records the value of such variables (see Def. 2.4), and ♠ is the monitor's tag (see next).
These five elements allow us to track the current protocol and state of the monitored process. The tag ♠ can be either empty (denoted '♦') or full (denoted ' '). When first created, all monitors have an empty tag; a full tag indicates that the running process associated to the monitor is currently involved in a decoupled reversible step. We often omit the empty tag (so we write s H · x · σ instead of s H · x · σ ♦ ) and write s H · x · σ to emphasize the reversible (red) nature of a monitor with full tag.
• Following [KYHH16], we have message queues s : (h k), where s is a session, h is the input part of the queue, k is the output part of the queue, and ' ' acts as a delimiter between the two. Each queue contains messages of the form (p , q , m), which is read: "message m is sent from p to q". As we will see, an output prefix in a process places the message in its corresponding output queue; conversely, an input prefix retrieves the first message from its input queue. Messages in the queue are never consumed : a process reads a message (p , q , m) by moving it from the (tail of) queue k to the (top of) queue h. This way, the delimiter distinguishes the past of the queue from its future.
• We use running functions κ (V u) , to reverse an application V u. While κ is a fresh identifier (key) for this term, is the location of the running process that contains the application.
As customary, we write i∈{1..n} P i to stand for the process P 1 | P 2 | · · · | P n (and similarly for configurations). We shall write P and M to indicate the set of processes and configurations, respectively. We call agent an element of the set A = M ∪ P. We let P, Q to range over P; also, we use L, M, N to range over M and A, B, C to range over A.

2.2.2.
Example: The Three-Buyer Seller Protocol (II). Continuing with the example in §2.1.2, we now give processes for each participant: where we assume price(·) returns a value of type price given a title. Observe how Betty's implementation sends part of its protocol to Carol in the form of a thunk containing her session name z and address. This is how abstraction passing implements session delegation.
The whole system, given by configuration M below, is obtained by placing these process implementations in appropriate locations: 2.3. A Decoupled Semantics for Configurations. We define a reduction relation on configurations, coupled with a structural congruence on processes and configurations. Our reduction semantics defines a decoupled treatment for reversing communication actions within a protocol. Reduction is thus defined as −→⊂ M × M, whereas structural congruence is defined as ≡ ⊂ P 2 ∪ M 2 .
2.3.1. Preliminaries. We require auxiliary definitions for contexts, stores, and type contexts. Evaluation contexts are configurations with one hole '•', as defined by the following grammar: General contexts C are processes or configurations with one hole •: they are obtained by replacing one occurrence of 0 (either as a process or as a configuration) with •. A congruence We define ≡ as the smallest congruence on processes and configurations that satisfies the rules in Fig. 5 and is closed under the equivalence on queues defined below.
Definition 2.3 (Equivalence on message queues). We define the structural equivalence on queues, denoted ≡ q , as follows: The equivalence ≡ q extends to configurations as expected.
A relation on configurations is evaluation-closed if it satisfies the following rules: The state of monitored processes is formalized as follows: Definition 2.4 (Store). The store σ is a mapping from variables to values. Given a store σ, a variable x, and a value V , the update σ[x → V ] and the reverse update σ \ x are defined as follows: The evaluation of value V under store σ, written σ(V ), is defined as follows: Together with local types with history, the following notion of type context allows us to record the current protocol state: Definition 2.5. We define type contexts as (local) types with one hole, denoted '•': Type contexts κ.T and ( , 1 , 2 ).T will be instrumental in formalizing reversibility of name applications and thread spawning, respectively, which are not described by local types. As already mentioned, abstraction passing can represent name passing in a fully abstract way (cf. [KPY16,KPY19]). Such a representation suffices to implement a form of session delegation, by including free session names (indexed by participant identities) in the body of an abstraction (cf. Betty's implementation, discussed above). The following definition identifies those names: where: where: where: Definition 2.6. Let h and p be a queue and a participant, respectively. Also, let {(q 1 , p , λx 1 . P 1 ), . . . , (q k , p , λx k . P k )} denote the (possibly empty) set of messages in h containing abstractions sent to p. We write roles(p, h) to denote the set of participant identities occurring in P 1 , . . . , P k .
2.3.2. Reduction. We define −→ as the union of two relations: the forward and backward reduction relations, denoted and , respectively. That is, −→= ∪ . Relations and are the smallest evaluation-closed relations satisfying the rules in Figs. 6 -9. We indicate with −→ * , * , and * the reflexive and transitive closure of −→, , and , respectively. We now discuss the forward reduction rules ( Fig. 6 and Fig. 7), omitting empty tags ♦: Rule (Init) initiates a given protocol G with n participants. Given the composition of one service request and n − 1 service accepts (all along a, available in different locations i ), this rule establishes the session by setting up the run-time elements: running processes and monitors-one for each participant, with empty tag (omitted)-and the empty session queue. A unique session identifier (s in the rule) is also created. The processes are inserted 1:12

C.A. Mezzina and J.A. Pérez
Vol. 17:4 where: where: where: in their respective running structures, and instantiated with an appropriate session name. The local types for each participant are inserted in their respective monitor, with the cursor 'ˆ' at the beginning. Rule (Out) starts the output of value V from p to q. Given an output-prefixed process as running process, and a monitor with a local type supporting an output action, reduction adds the message (p , q , σ(V )) to the output part of the session queue (where σ is the current store). Also, the cursor within the local type is moved accordingly. In this rule (but also in several other rules), the premise p = r ∨ p ∈ roles(r, h) allows performing actions on names previously received via abstraction passing. Rule (In) allows a participant p to receive a value V from q: it takes the first element of the output part of the queue and places it in the input part. The cursor of the local type and the state in the monitor for p are adjusted accordingly. Rule (Sel) is the forward rule for labeled selection, which in our case entails a nondeterministic choice between pairwise different labels indexed by I. We require that I (the set that indexes the choice in the process) is contained in J (the set that indexes the choice in the protocol). After reduction, the selected label (l w in the rule) is added to the output part of the queue, and the continuation P w is kept in the running process; to support reversibility, alternatives different from l w are stored in the stack C with their continuations. The cursor is also adjusted in the monitor accordingly. Rule (Bra) is similar to Rule (Sel): it takes a message containing a label l w as the first element in the output part of the queue, and places it into the input part. This entails a selection between the options indexed by I; the continuation P w is kept in the running process, and all those options different from l w are kept in the stack. Also, the local type in the monitor is adjusted accordingly. Rule (Beta) handles applications, which in our setting are always name applications. Reduction creates a fresh identifier (κ in the rule) for the running function, which keeps (i) the structure of the process prior to application, and (ii) the identifier of the running process that "invokes" the application. Notice that κ is recorded also in the monitor: this is needed to undo applications in the right order. We use the store σ to determine the actual abstraction and the name applied. Rule (Spawn) handles parallel composition. Location is "split" into running processes with fresh identifiers ( 1 , 2 in the rule). This split is recorded in the monitor. Now we comment on the backward rules ( Fig. 8, Fig. 9, and Fig. 10) which, in most cases, change the monitor tags (♦ and ): Rule (RInit) reverses session establishment. It requires that local types for every participant are at the beginning of the protocol, and that session queue and process stacks are empty. Run-time elements are discarded; located service accept/requests are reinstated. Rule (RollS) starts to reverse an input-output synchronization between p and q. Enabled when there are complementary session types in the two monitors, this rule changes the monitor tags from ♦ to . This way, the undoing of input and output actions occurs in a decoupled way. Rule (RollC) is the analog of (RollS) but for synchronizations originated in labeled choices. Rule (ROut) reverses an output. This is only possible for a monitor tagged with , exploiting the first message in the input queue. After reduction, the process prefix is reinstated, the cursor is adjusted, the message is removed from the queue, and the monitor is tagged with ♦. Rule (RIn) is the analog of Rule (ROut). In this case, we also need to update the state of the store σ. Rule (RBra) reverses the input part of a labeled choice: the choice context is reinstated; the cursor is moved; the last message in the input part of the queue is moved to the where: where: where: output part. Rule (RSel) is the analog of (RBra), but for the output part of the labeled choice. The non-deterministic selection is reinstated. Rule (RBeta) undoes β-reduction, reinstating the application. The running function disappears, using the information in the monitor (k in the rule). Rule (RSpawn) undoes the spawn of a parallel thread, using the identifiers in the monitor. where: where: where S 1 , A 1 , B 1 , and C 1 stand for the continuation of processes Seller, Alice, Betty, and Carol after the service request/declaration. This way, e.g., A 1 = y! 'Logicomix' .y?(p).y?(s).y?(ok).0. We use configuration M 1 to illustrate some forward and backward reductions. From M 1 we could either undo the reduction (using Rule (RInit)) or execute the communication from Alice to Seller (using Rules (Out) and (In)). This latter option would proceed as follows: where N 2 stands for the running processes and monitors for Seller, Betty, and Carol, not involved in the reduction. We now have: where N 3 stands for the participants not involved in the reduction, σ 3 stands for the resulting store [ where: where: the cursors in monitors s V and s A have evolved, and that the message from A to V has now been moved to the input queue.
We illustrate reversibility by showing how to return to M 1 starting from M 3 . We need to apply three rules: (RollS), (RIn), and (ROut). Reversibility is decoupled in the sense that there is no fixed order in which the latter two rules should be applied; below we just illustrate a possible sequence. First, Rule (RollS) modifies the tags of monitors s V and s A , leaving the rest unchanged: where, as before, N 4 represents participants not involved in the reduction. M 4 has several possible forward and backward reductions. One particular reduction uses Rule (RIn) to undo the input at V: Just as an application of Rule (RollS) need not be immediately followed by an application of Rule (RIn), an application of Rule (RIn) need not be immediately followed by an application of Rule (ROut). A particular reduction from M 5 undoes the output at A: Clearly, M 6 = M 1 . Summing up, the synchronization realized by the (forward) reduction sequence M 1 M 2 M 3 can be reversed by the (backward) reduction sequence To illustrate abstraction passing, let us assume that M 3 above follows a sequence of forward reductions until the configuration: [B] : 0 ; s [B] ! {{s [B] ! 'Urbino, 61029' .s [B] ?(d).0}} .0 If M 7 M 8 by using Rules (Out) and (In) then we would have: [B] ! 'Urbino, 61029' .s [B] ?(d).0}}) ) ) where σ 9 = σ 8 [code → {{s [B] ! 'Urbino, 61029' .s [B] ?(d).0}}]. We now may apply Rule (Beta) so as to obtain: [B] ! 'Urbino, 61029' .s [B] ?(d).0}}) ) ) = M 9 where N 6 stands for the rest of the system. Notice that this reduction has added a running function on a fresh κ, which is also used within the type stored in the monitor s C . The reduction M 8 M 9 completes the code mobility from B to C: the now active thunk will execute B's implementation from C's location. This justifies the premise p = r ∨ p ∈ roles(r, h) present in Rules (Out), (In), (Sel), and (Bra) (and in their backward counterparts): when executing previously received mobile code, the participant mentioned in the location (i.e., C) and that mentioned in the located process (i.e., B) may differ. Further forward reductions from M 9 will modify the cursor in the type stored in monitor s B based on the process behavior located at 4[C] .

2.4.
A Protocol with Choices. We close this section by showcasing reversibility of labeled choices. Consider the following global type, specifying a simple binary (two-party) protocol between a Buyer (B) and a Seller (V): The whole system, given by configuration M below, is obtained by placing these process implementations in appropriate locations: We may then have: [B] : 0 ; s [B] {ok : s [B] ?(addr).s [B] ! date .0 ; quit : 0} where M 1 is the configuration obtained from M once the two participants have initiated the session and exchanged the title and the corresponding price. Above, x 1 and x 2 are the free variables of V and B after the first three interactions; also, σ 1 and σ 2 represent their respective stores. Queue h 1 contains the two messages related to title and price. The context types are: In M 1 , Buyer can decide either (a) to accept the suggested price and continue with the prescribed protocol or (b) to refuse it and exit. The first possibility may proceed using Rule (Sel) as follows: M 1 (ν s)( 2 [B] : 0, s [B] {quit : 0} ; s [B] ?(addr).s [B] ! date .0 where N 1 contains the rest of the Seller process and monitor of M 1 . As we can see, in M 2 the cursorˆof the Buyer monitor has been moved into the choice. Moreover, the process stack of Buyer is updated in order to register the discarded branch of the choice (i.e., the branch involving label quit following, using Rule (Bra): : 0, s [B] {quit : 0} ; s [B] ?(addr).s [B] ! date .0 In the second case, we can revert the labeled choice by using Rule (RollC) from M 3 first, and then using Rules (RBra) and (RSel) in a decoupled fashion.
Having introduced and illustrated our process model and its reversible semantics, we now move on to establish its key properties.

Main Results
We now establish our main result: we prove that reversibility in our model of multiparty asynchronous communication is causally consistent. We proceed in three steps: a) First, we introduce an alternative atomic semantics and show that it corresponds, in a tight technical sense, to the decoupled semantics in § 2.3 (Theorems 3.9 and 3.12). b) Second, in the light of this correspondence, we establish causal consistency for the atomic semantics, following the approach of Danos and Krivine [DK04] (Theorem 3.21). c) Finally, we state a fine-grained, bidirectional connection between the semantics of (high-level) global types with the decoupled semantics of (low-level) configurations (Theorem 3.27). These steps allow us to transfer causal consistency to protocols expressed as global types.
3.1. An Atomic Semantics. Our main insight is that causal consistency for asynchronous communication can be established by considering a coarser synchronous reduction relation.
Definition 3.1 (Atomic Reduction). We define atomic versions of the forward and backward reduction relations, relying on the rules in Fig. 12 and 13.
• The forward atomic reduction, denoted →, is the smallest evaluation-closed relation that satisfies Rules (AC) and (AS) (Fig. 12), together with Rules (Init), (Beta), and (Spawn) (Fig. 6 and 7). • Similarly, the backward atomic reduction, denoted → , is the smallest evaluation-closed relation that satisfies Rules (RAC) and (RAS) (Fig. 13), together with Rules (RInit), (RBeta), and (RSpawn) (Fig. 8 and 10). We then define the atomic reduction relation as → ∪ → . Figure 11 summarizes our notations for reductions. We start by introducing reachable configurations: configuration is reachable, if it is derived from an initial configuration by using −→ (cf. § 2.3). A configuration is atomically reachable, if it is derived from an initial configuration by using . Symbol Meaning Forward transition for global types (Fig. 3) Backward transition for global types (Fig. 3) Forward decoupled reduction ( Fig. 6 and 7) Backward decoupled reduction (Fig. 8, 9, and 10) −→ ∪ → Forward atomic reduction (Fig. 12) → Backward atomic reduction (Fig. 13) → ∪ → Figure 11. Notations for transition and reduction relations. where: where: To relate the decoupled semantics −→ with the atomic reduction (just defined), we introduce the concept of stable configuration. Roughly speaking, in a stable configuration there are no "ongoing" reduction steps. In the forward case, an ongoing step is witnessed by non-empty output queues (which should eventually become empty to complete a synchronization); in the backward case, an ongoing step is witnessed by a marked monitor (which should be eventually unmarked when a synchronization is undone). This way, e.g., in the example of § 2.3.3 configurations M 3 and M 7 are stable, whereas M 2 and M 4 are not. Reduction will move between stable configurations only. We therefore have: where: where: Proof. By induction on the reduction sequence M −→ * N .
We now show the Loop lemma [DK04], which offers a local consistency guarantee for the interplay of forward and backward reductions: it ensures that every reduction step can be reverted. This lemma will be crucial both in proving a correspondence between atomic and decoupled semantics, but also in showing causal consistency of the atomic semantics.  The following lemma allow us to "reorder" decoupled reduction steps so to have the generation of a message (e.g., an application of Rules (Out) or (Bra)) followed by its consumption (e.g., an application of Rules (In) or (Sel)). This way, the two consecutive decoupled reductions can be mimicked by one atomic step, which will be in turn instrumental to relate the atomic and decoupled semantics. Below we write i (and i ) to denote a specific step in a reduction sequence.  N 1 and N 1 2 N 2 , where 1 denotes the use of Rule ( ROut) or ( RSel) and 2 denotes the respective use of Rule ( RIn) or ( RBra), then M * 1 2 N * N 2 , for some N .

C.A. Mezzina and J.A. Pérez
Vol. 17:4 The following theorem provides a first connection between decoupled and atomic reductions; its proof is immediate from their definitions: We now embark ourselves in providing a tighter formal connection between −→ and , using back-and-forth bisimulations [LMS16]. We shall work with binary relations on configurations, written ⊆ M × M. We now adapt the usual notion of barbs [SW01] to our setting: rather than communication subjects (which are hidden/unobservable names in intra-session communications), it suffices to use participant identities as observables: Definition 3.10 (Barbs). A reachable configuration M has a barb p, written M p , if Notice that our definition of barbs is connected to the notion of stability: since in M p we require a monitor with empty tag, this ensures that p is not involved in an ongoing backward step. In a way, this allows us to consider just forward barbs (as in [AC17]).
We now adapt the definition of weak barbed back-and-forth (bf) bisimulation and congruence [LMS16] in order to work with decoupled and atomic reduction semantics: This way, in establishing M · ≈ N we should consider that atomic reduction steps from M are matched by N with decoupled reduction steps. This is how · ≈ enables us to state our second connection between decoupled and atomic reductions. To prove the correspondence between the two semantics, we shall relate the same configuration M under the two different semantics. Hence: both stable configurations. By applying Theorem 3.9 on M −→ * N 1 we infer M * N 1 ; then, by applying the Loop Lemma (Lemma 3.6) we further infer N 1 * M . Using again Theorem 3.9 we infer that N 1 −→ * M ; since we have deduced that N −→ * N −→ * M , we know that N weakly matches all the barbs of M , as desired.
• Suppose now that N challenges M with a barb. We proceed similarly as above: if sb(M ) then M has the same barb; otherwise, if ¬sb(M ), since M −→ * N , by Corollary 3.5 we have that M −→ * N −→ * N 1 , with sb(N 1 ). Let us note that the reductions in N −→ * N 1 do not add barbs to N 1 : they only finalize ongoing synchronizations; by definition of barbs (Def. 3.10) parties involved in ongoing rollbacks do not contribute to barbs. We can conclude by applying Theorem 3.9 and deriving M * N 1 , which has the same barbs of N , as desired.
Let us now consider reductions. We will just focus on synchronizations due to input/output and branching/selection reduction steps, since these are the cases in which −→ and differ; indeed, reductions due to Rules Spawn and Beta can be trivially matched. Let us consider challenges from M . There are two cases: M →M 1 and M → M 1 . In the first case, as we distinguish two sub-cases: either N has already started the synchronization or not. In the first sub-case, N can conclude the step: N N . Now we have that M * N N . Thanks to Lemma 3.7 we can rearrange such a reduction sequence as follows: M M 1 * N . We then have that the pair (M 1 , N ) ∈ , as desired. In the second sub-case, N can match the step with 2 reductions: N N . Also in this case we can rearrange the reduction sequence so as to obtain M M 1 * N , with (M 1 , N ) ∈ , as desired. The case M → M 1 (i.e., the challenge is a backward move) is handled similarly. We now consider challenges from N , focusing only on synchronizations, just as before. If N N , we distinguish two cases: whether the reduction ends an ongoing input/output and branching/selection, or it opens a new one. In the second case M matches the move with an idle move, i.e., (M, N ) ∈ . In the other case we can rearrange the reduction M * N N into a similar reduction sequence M −→ * N 1 * N with sb(N 1 ), and all reductions in N 1 * N just start new synchronizations. Thanks to Theorem 3.9, M can mimick the same reduction to N 1 , i.e., M → * N 1 , and we have that (N 1 , N ) ∈ , as desired. The case in which N N (i.e., the challenge is a backward move) is similar. This concludes the proof.
By observing that the set of atomic configurations is a subset of reachable configurations, this result can also be formulated as full abstraction. Let f be the (injective, identity) mapping from atomic reachable configurations to reachable configurations. We then have: The results above ensure that the loss of atomicity preserves the reachability of configurations yet does not make undesired configurations reachable. 3.2. Causal Consistency. Theorems 3.9 and 3.12 allow us to focus on the atomic reduction for the purposes of establishing causal consistency. We follow the approach we developed in our prior work [MP16,MP17b], here considering the more general multiparty setting with asynchronous, higher-order communication; in turn, our prior approach adapts to the proof technique by Danos and Krivine [DK05] (developed for a reversible CCS).
In a nutshell, causal consistency concerns traces of transitions, each one endowed with an appropriate stamp. The proof of causal consistency relies on square, rearranging, and shortening lemmas, which together express properties of traces and transitions that characterize flexible and consistent reversible steps. We start by defining transitions: Some terminology on transitions, taken from [MP16,MP17b], is in order. • We say M and N are the source and target of t (written src(t) and trg(t), respectively).
• The inverse of t, denoted t, is the transition t : =⇒ N 2 , we define t 2 /t 1 (read "t 2 after t 1 ") as N 1 η 2 =⇒ N 2 , i.e., the transition with stamp η 2 that starts from the target of t 1 and ends in the target of t 2 .
Two important classes of transitions are conflicting and concurrent ones: We now consider the so-called Square Lemma [DK04], which may be informally described as follows. Assume a configuration from which two transitions are possible: if these transitions are concurrent then the order in which they are executed does not matter, and the same configuration is reached. The licit combinations are given by pairs of rules in the set {(r i , r j ) | {r i , r j } ⊂ Rule∪Rule}.
Let us note that the definition of concurrent transitions (Definition 3.16) ensures that the pairs (r i , r j ) concern rule applications that involve different participants. All valid cases are treated similarly; we content ourselves by considering only the case (RAS, AC), in which queue equivalence (Definition 2.3) plays an important role. We have that: From M we have two possible reductions: either p 1 , q 1 communicate or p 2 , q 2 undo the selection. By Definition 3.14, η 1 = {p 1 , q 1 } and η 2 = {p 2 , q 2 }. By Rule AC we have: and by Rule RAS we have: Now it is easy to see that there is an N such that M 1

C.A. Mezzina and J.A. Pérez
Vol. 17:4 Let us note that in M 1 the equivalence on queues (cf. Definition 2.3) allows the swapping of the two messages (p 2 , q 2 , l w ) • (p 1 , q 1 , V ) so to enact the Rule RAS.
We now turn our attention to traces, sequences of pairwise composable transitions. We let ρ range over traces. Notions of target, source, composability and inverse extend naturally from transitions to traces. We write ε M to denote the empty trace with source M , and ρ 1 ; ρ 2 to denote the composition of two composable traces ρ 1 and ρ 2 .
Definition 3.18. We define as the least equivalence between traces that is closed under composition and that obeys: i) t 1 ; t 2 /t 1 t 2 ; t 1 /t 2 ; ii) t; t ε src(t) ; iii) t; t ε trg(t) .
Intuitively, says that: (a) given two concurrent transitions, the traces obtained by swapping their execution order are equivalent; (b) a trace consisting of opposing transitions is equivalent to the empty trace.
The proof of causal consistency follows that in [DK04], but with simpler arguments (because of our simpler transition stamps), which mirror those in [MP16,MP17b].
The following lemma says that, up to causal equivalence, traces can be rearranged so as to reach the maximum freedom of choice, first going only backwards, and then going only forward.
Proof. By lexicographic induction on the length of ρ and on the distance between the beginning of ρ and the earliest pair of opposing transitions in ρ. The analysis uses both the Loop Lemma (Lemma 3.6) and the Square Lemma (Lemma 3.17).
If trace ρ 1 and forward trace ρ 2 start from the same configuration and end up in the same configuration, then ρ 1 may contain some "local steps", not present in ρ 2 , which must be eventually reversed-otherwise there would be a difference with respect to ρ 2 . Hence, ρ 1 could be shortened by removing such local steps and their corresponding reverse steps.
Proof. By induction on the length of ρ 1 , using Square and Rearranging Lemmas (Lemmas 3.17 and 3.19). The proof uses the forward trace ρ 2 as guideline for shortening ρ 1 into a forward trace, relying on the fact that ρ 1 and ρ 2 share the same source and target.
We may now state our main result: At this point one may object that causal-consistency has been proved on the atomic semantics and not on the decoupled semantics, and wonder whether the chosen behavioural equivalence (cf. Definition 3.11) is causal-preserving. First, we observe that our notion of equivalence is a congruence, and that the only visible event in a message-passing system is the receipt of a message itself. Then it is easy to see that our equivalence preserves the order of messages sent, and hence that the decoupled semantics respects the same notion of causality of the atomic semantics.
3.3. Connecting (Reversible) Protocols and (Reversible) Configurations. We now connect the two levels of abstraction in our reversible model by relating protocols and configurations. This is the content of Theorem 3.27, which relies on a few auxiliary definitions.
We introduce a notion of well-formed processes and configurations that implement a given local type. Figure 14 reports a set of rules for decreeing well-formed processes: it is inspired by the type system for higher-order session processes defined in [KPY16].
Our system for well-formedness is simple, and relies on two contexts: Γ (for recursion variables) and ∆ (for assignments of variables to local types). We omit these contexts when empty and/or unimportant. Well-formedness uses the following judgments: • u :: T says that u is a name of local type T • Γ; ∆ V :: U says that V is a well-formed value of type U • Γ; ∆ P says that P is a well-formed process The first three rules in Figure 14 are for values: booleans and abstractions (rules for other base values are similar). Then we have a rule enforcing a weakening principle, and rules for inaction and application, which are as expected. The rule for output enables us to account 1:30

C.A. Mezzina and J.A. Pérez
Vol. 17:4 for processes in which a communicated abstraction specifies a protocol which is continued outside the output action; this is case for process Betty in § 2.2.2, in which part of the protocol on z is sent around as a thunk. The remaining rules, for input, selection, branching, and recursive processes, are self-explanatory. Notice that for the sake of simplicity, we consider restriction-free, single-threaded processes (i.e., no processes of the form (ν n)P and P 1 | P 2 ). We are interested in well-formed processes that implement a single session with local type T along u (a session name or a variable): Definition 3.22 (Well-Formed Processes). We say process P is well-formed if ∅; {u : T } P in the system of Figure 14, for some u and T . This is denoted P u T .
We may then define the configurations that implement a global type with history (cf. Def. 2.2). First, an auxiliary definition: Definition 3.23 (Reachable Global Types). We say the global type with history H is reachable if it can be obtained from a global type G via a sequence of and transitions (cf. Fig. 3).
Definition 3.24 (Configurations Implementing Global Types). Let G be a global type, with pa(G) = {p 1 , · · · , p n }. following Rule (Init) (cf. Fig. 6). This way, N H reflects the evolution from an initial implementation, with H being reachable from G and N being reachable from M following forward and backward rules. The following proposition details the shape of a configuration that is reachable from M o G: where, for all i ∈ {1,· · ·, n}, Figure 15.
Recall that ♠ can be either full or empty ♦; thus, if M H then M may not be stable.
The last ingredient required is a swapping relation over global types, denoted ≈ sw , which enables behavior-preserving transformations among causally independent communications.  Figure 15. Well-formed configurations with respect to a local type with history. Definition 3.26 (Swapping). We define ≈ sw as the smallest congruence on G that satisfies the rules in Fig. 16 (where we omit the symmetric versions of (Sw1), (Sw2), and (Sw3)). We extend ≈ sw to global types with history H as follows: Notice that Definition 2.3 and swapping play similar rôles but at different levels: queues/configurations and global types, respectively.
We comment on the statement of Theorem 3.27, given next, which relates (i) transitions in the semantics of (high-level) global types (with history) with (ii) reductions in the Proof. We consider both parts separately: Part (a): By induction on the transitions H H and H H , with a case analysis on the last applied rule (Fig. 3).
For H H there are four possible transitions, we have a one-to-one correspondence: • a transition derived using Rule (FVal1) is matched by M using Rule (Out); • a transition derived using Rule (FVal2) is matched by M using Rule (In); • a transition derived using Rule (FCho1) is matched by M using Rule (Sel); • a transition derived using Rule (FCho2) is matched by M using Rule (Bra).
The analysis for H H is similar, but we may require an additional reduction step from M , depending on the tag of the corresponding monitor (cf. Prop. 3.25). If the tag of M is then the transition can be immediately matched as follows (j = 1): • a transition derived using Rule (BVal1) is matched by M using Rule (ROut); • a transition derived using Rule (BVal2) is matched by M using Rule (RIn); • a transition derived using Rule (BCho1) is matched by M using Rule (RSel); • a transition derived using Rule (BCho2) is matched by M using Rule (RBra). Otherwise, if the tag of M is ♦, then j = 2 because an additional reduction (using Rule (RollS) or (RollC)) is required in order to reach a configuration with tag . Part (b): By induction on transitions M N and M N , with a case analysis on the last applied rule, following similar lines. There are two main cases: (i) There is exactly one reduction M N (and M N ), which involves participants that appear at the top-level in H. (ii) There are one or more reductions M N i (and M N i ) whose involved participants cannot be found at the top-level in H. We discuss case (i) first. Suppose M N : then the reduction was obtained using one of the following Rules (Out), (In), (Sel), (Bra), and (Beta). Notice that a reduction with Rule (Spawn) is not possible under our definition of well-formed processes (and configurations). For the first four cases, a corresponding transition H H can be easily obtained, as in the analysis for Part (a); a reduction obtained with Rule (Beta) does not involve the global type, and so H = H. In either case, N H holds easily. Now suppose M N . Here the analysis depends on the tag in where the difference with respect to M 7 is in the last line, with the following local queues: We now relate the decoupled semantics (given by ∪ ) with the alternative decoupled semantics (given by ∪ ) by means of the following correspondence: Proof. Immediate from the definitions of [·] , , and (resp. and ).
This tight correspondence between the original and alternative decoupled semantics ensures that our main results (in particular, causal consistency) carry over to a setting in which each participant handles its own queue for messages. ]. These checkpoints are choice points in the global protocol to which the computation may return. The initial theory has been presented in [DG16] and further developed in [CDG17], with improvements that include a more liberal syntax for processes and types and refined representations for past communications. The work in [CDG19] extends [CDG17] with flexible choices and connecting communications, allowing for different sets of participants in each branch. The intuition is that in some parts of the protocol (as delimited by a choice construct) some participants are required to take part in the interaction, while some others may be optional.
We briefly compare our approach with respect to the framework in [CDG17]. While our reversible actions are embedded in/guaranteed by the semantics, rollbacks in [CDG17] should specify the name of the checkpoint to which computation should revert. Defining reversibility in [CDG17] requires modifying both processes and types. In contrast, we consider untyped processes governed by local types (with cursors) as monitors. While we show causal consistency with a direct proof, in [CDG17] causal consistency follows indirectly, as a consequence of typing. Another difference with respect to [CDG17] is that reversibility in our model is fine-grained, in that we allow reversible actions concerning exactly two of the protocol participants; in [CDG17], when a checkpoint is taken, also parties not related with that choice are forced to return to a checkpoint. A distinctive aspect of [CDG17] is that when a branch of a choice is reversed, it is discarded: this way, the same choice is not redone in the future. We have chosen to be more liberal, as the same action can be done and redone infinite times. To encode this behavior, we could use the reversibility modes-annotations that describe the reversibility capabilities of the processes governed by types)-that we introduced in [MP17b].
Similarly to our work, Francalanza et al. [FMT18,FMT20] use monitors that enact reversibility by storing the decision points (e.g., distributed choices) that the different participants may take, and by coordinating with each other in order to bring the system back to a previous consistent state when certain conditions are met. To do so, they extend the global graphs by Tuosto and Guanciale [TG18] (a formalism that expresses the behaviour of a message passing system from a global point of view) with a decoration on choices, which includes a condition dictating when a computation on a particular branch of a distributed choice should be reversed. Then, these extended global descriptions can be used to (i) synthesise actors implementing the normal (forward) local behaviour of the system prescribed by the global graph, but also (ii) synthesise monitors that are able to coordinate a distributed rollback when certain conditions (denoting abnormal behaviour) are met. Their synthesis algorithm produces Erlang code, with two actors per participant derived from the global graph: one implements the normal/forward behaviour of the participant; the second one (a monitor) implements its backward behaviour. Reversibility is confined into distributed choices, and triggered by conditions on the internal state of some participants. In contrast, in our framework every communication step can be undone; the mechanism devised 1:38

C.A. Mezzina and J.A. Pérez
Vol. 17:4 in [FMT18,FMT20] can be encoded in an extension of our framework with conditional reversibility. Neykova and Yoshida [NY17] develop a recovery algorithm for Erlang programs by exploiting causal information induced by global protocols. They then show that their recovery algorithm outperforms Erlang's built-in recovery algorithm.
Behavioural contracts are abstract descriptions of expected communication patterns followed by either clients or servers during their interaction. They come naturally equipped with a notion of compliance: when a client and a server follow compliant contracts, their interaction is guaranteed to progress or successfully complete. Barbanera et al. [BLd18] study two extensions of behavioural contracts: (i) retractable contracts dealing with backtracking and (ii) speculative contracts dealing with speculative execution. These two extensions give rise to the same notion of compliance. As a consequence, they also give rise to the same subcontract relation, which determines when one server can be replaced by another while preserving compliance.
From a global specification (e.g., a global graph) an abstract semantics can be derived [GT19]. The semantics is abstract since it is given in terms of a partial order of events, representing the causality induced by the global specification. Recently, Kapus-Kolar [Kap20] has enhanced this abstract semantics to account for reversibility. Here, the assumption is that a global graph is realizable (i.e., the projection function can be defined on all participants) and that each automata implementing the behaviour of a single participant has an inverse. Then, it is shown that the causality induced by the global specification is preserved also while going backwards.

Concluding Remarks
We have presented a process framework of reversible, multiparty protocols built upon sessionbased concurrency. As illustrated throughout the paper, the distinguishing features of our framework (decoupled rollbacks and abstraction passing, including delegation) endow it with substantial expressiveness, improving on and distinguishing it from prior works.
Our processes/configurations are untyped, but their (reversible) behaviour is governed by monitors derived from local (session) types. In our view, our monitored approach to reversibility is particularly appropriate for specifying and reasoning about systems with components whose behaviour may not be statically analyzed (e.g., legacy components or services available as black-boxes). A monitored approach is general enough to support also the analysis of reversible systems that combine typed and untyped components.
We proved that our reversible semantics is causally consistent, which ensures that reversing a computation leads to a state that could have been reached by performing only forward steps. The proof is challenging (and, in our view, also interesting), as we must resort to an alternative atomic semantics for rollbacks ( Fig. 12 and 13). We then connected reversibility at the level of process/configurations with reversibility at the level of global types, therefore linking the operational and declarative levels of abstraction typical of multiparty sessions communication-centric software systems.
Extensions and Future Work. As already mentioned, our framework does not include name passing, which is known to be representable, in a fully abstract way, using name abstractions [KPY16]. Primitive support for name passing is not difficult, but would come at the cost of additional notational burden. An extension with name passing would allow us to relate our framework with known typed frameworks for monitored networks (without reversibility) based on multiparty sessions [BCD + 17].
In future work, we plan to extend our framework with reversibility modes [MP17b], which implement controlled reversibility [LMSS11] by specifying how many times a particular protocol step can be reversed-zero (e.g., it is an atomic action), one, or infinite times. (Currently, all actions can be reversed infinite times.) In a related vein, we plan to explore variants of our model in which certain protocol branches are "forgotten" after they have been reversed; this modification is delicate, because it would weaken the notion of causal consistency.
On the practical side, the work [dVP19] describes a Haskell implementation of our reversible model, where algebraic types are used to represent all the various formal ingredients defined in § 2. We plan to keep improving this implementation, as we believe that pure functional languages support natively reversibility. In this direction, it would be beneficial to have a "reversible workbench" to test and compare all the different semantics of the aforementioned reversible behavioural types.