Honesty by Typing

We propose a type system for a calculus of contracting processes. Processes may stipulate contracts, and then either behave honestly, by keeping the promises made, or not. Type safety guarantees that a typeable process is honest - that is, the process abides by the contract it has stipulated in all possible contexts, even those containing dishonest adversaries.


Introduction 1.1 The problem
It is commonplace that distributed applications are not easy to design.Besides the intrinsic issues due e.g. to physical or logical distribution, and to the fragility of communication networks and their low-level protocols, distributed applications have to be engineered within an apparent dichotomy.On the one hand, distributed components have to cooperate in order to achieve their goals and, on the other hand, they may have to compete, e.g. to acquire shared resources.This dichotomy is well represented by the service-oriented paradigm, which fosters the shift from "stand-alone" applications to dynamically composed ones.
Cooperation and competition hardly coexist harmoniously.Most approaches to the formal specification of concurrent systems typically assume that components behave honestly, in that they always adhere to some agreed specification.For instance, this could be some behavioural type inferred from the component, and the assumption is that the static behaviour safely over-approximates the dynamic one.We argue that this assumption is unrealistic in scenarios where competition prevails against cooperation.Indeed, in Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page.To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Copyright c 2013 ACM [to be supplied]. . .$10.00 a competitive scenario components may act selfishly, and diverge from the agreed specification.
We envision a contract-oriented computing paradigm [3], for the design of distributed components which use contracts to discipline their interaction.CO2 [3] is a core calculus for contractoriented computing.A CO2 process may advertise contracts to some contract broker; once the broker has found a set of compliant contracts, a session is established among the processes which advertised them.Processes may then use this session to perform the actions needed to realise their contracts, similarly to other sessioncentric calculi.
A distinguished feature of CO2 is that processes are not supposed to respect their contracts, nor are they bound to them by an enforcing mechanism.More realistically, dishonest processes may avoid to perform some actions they have promised in their contracts.This may happen either intentionally, e.g. a malicious process which tries to swindle the system, or unintentionally, e.g. because of some implementation bug (possibly exploited by some adversary).In both cases, the infrastructure can determine which process has caused the violation, and adequately punish it.
A crucial problem is then how to guarantee that a process will behave honestly, in all possible contexts where it may be run.If such guarantee can be given, then the process is protected both against unintentional bugs, and against (apparently honest) adversaries which try to make it sanctioned.A negative result in [2] is that the problem of determining if a process is honest is undecidable for a relevant class of contracts.These are the contracts introduced in [10], and then refined in [11], for modelling WSDL and WSCL contracts.The problem is then how to find a computable approximation of honesty, which implies the dynamic one.

Example
Let us consider an on-line food store (participant A), which sells apples (a) and bottles of an expensive italian Brunello wine (b).Selling apples is quite easy: once a customer places an order, it is accepted (with the feedback ok) and the store waits for payment (pay) before shipping the goods (ship-a).However, if the customer requests an expensive bottle of Brunello, the store reserves itself the right to choose whether to accept the order (and then wait for payment and ship the item, as above), or to decline it, by answering no to the customer.These intentions are modeled by the following store contract (using a simplified notation, see Ex.This contract features two kinds of branching operators: external choice +, and internal choice ⊕.External choice requires the other party (in this case, the customer) to choose which prefix will drive the contract evolution.The choice is between apples a and bottles b.Internal choice, instead, allows the advertising party (the store) to choose a branch, by selecting either ok or no.
In order to sell its goods, the store needs to find an agreement with a participant advertising a compliant contract.Intuitively, contract compliance is based on the duality of actions and internal/external choices.For instance, the store contract c is compliant with the following customer contract: A customer B who advertises such contract wants to buy Brunello wine: she promises to select b (dual of b in the store contract), and then presents an external choice that lets the store choose between ok or no feedbacks; in the first case, she promises to pay and wait for shipment.
CO2 allows for describing the behaviour of each participant as a process, with the ability to advertise contracts and execute the actions required to honour them.For instance, the store A can advertise its contract c by firing the prefix: where the index K is the name of an external broker, whom the contract is being advertised to.We shall not specify the behaviour of K, and just assume that it establishes sessions when compliant contracts are found.The index x in ↓x c is the name of a channel of A. When a session is established between A and (say) B, a fresh session name s is shared between A and B. Technically, x is replaced with s.Participants A and B will then use such session to perform the actions required by their contracts.
A possible specification of the store process is e.g.: Here, the store creates a private channel x, and advertises the contract c.Once a session is established, the process can proceed, and accept an order for a or b on x.This is modelled by the choice operator +, which is the usual one of CCS (not to be confused with + of contracts), with guards dox a and dox b.In both cases, the process XM (x) is invoked.There, the store accepts the transaction with an ok action, and waits for payment.Then it checks whether the contract requires the store to ship apples: if the query askx ship-a?passes, the goods are shipped.Otherwise, when the customer has selected Brunello, the store maliciously gets stuck, and so the customer has paid for nothing.This store is dishonest, because it does not respect its own contract c.Consider now a non-malicious implementation of the food store.Before accepting orders, the store requires an insurance policy against shipment damages -which may be particularly useful for the expensive (and fragile) Brunello bottles.Thus, now A advertises a contract cp to an insurance company C with an offer to pay (payP), followed by the possibility to choose between getting a full coverage on the value of the goods, or cancelling the request: The behaviour of the store is now modelled by the process: Here, the store first requests an insurance policy, by advertising the contract cp; once the insurance company C agrees, the store pays the fee (on channel y).Then, just like the previous case, the store advertises c, and once an agreement with a customer is reached, it waits for a or b orders.If apples are requested, the process acknowledges (ok) and invokes XN (x); there, the store waits for payment, checks which good is expected to be shipped according to the contract, and actually ships it.Otherwise, if Brunello is requested, YN (x, y) is invoked: there, the store requests the insurance coverage that was paid in advance; then, either the order is accepted and XN (x) is invoked for payment and shipment (as above), or the transaction is declined after an internal action τ (e.g.wake up after a timeout).This implementation is not as malicious as the first attempt, because at least it actually ships the goods upon payment -but it is not honest either.The problem lies in the interaction between the store and the other parties.If C does not deliver the promised cover, the store keeps waiting on doy cover (which is a blocking operation), unable to honour c by providing the expected ok/no.Furthermore, A is dishonest w.r.t.cp: the insurance fee is paid in advance, but A might never perform doy cover nor doy cancele.g. if no agreement on c is found, or if the customer B remains stuck, or if B simply chooses to buy apples.Thus, due to implementation naïveties, A may be blamed because of the unexpected (or malicious) behaviour of other participants.
An actually honest food store requires a slightly more complex implementation: This time, A advertises c and waits for a or b orders.If apples are requested, the store invokes XH (x), which acknowledges ok and, just like XN (x) above, waits for payment and ships the good expected by the contract.If Brunello is requested, then YH (x) is invoked instead.There, a new private channel y is created, the store advertises cp and tries to pay the insurance fee on y; in parallel, the store either requests the coverage and invokes XH (x) (as above), or it performs an internal action τ (e.g.wake up after a timeout).In the latter case, the order is declined and (in parallel) the insurance request is cancelled.As a result, even if either B or C remains stuck and culpable, A is always able to honour the contract stipulated with the other party.

Contributions
The main contribution of this paper is a type discipline for statically ensuring when a CO2 process is honest.The need for a static approximation is motivated by the fact that honesty is an undecidable property, as shown in [2].Our type system associates behavioural types (in the form of Basic Parallel Processes, BPPs [14]) to each channel of a process.Checking honesty on these abstractions is decidable (Theorem 5.11).We establish subject reduction (Theorem 5.32) and progress (Theorem 5.34), which are then used to prove type safety: typeable processes are honest (Theorem 5.35).Due to space constraints, we publish the proofs and further examples in a separate report [4].

Paper outline
In Sections 2 and 3 we present some background material on the contract model and on the calculus CO2 , respectively.In Section 4 we formalise a notion of honesty for CO2 processes.In Section 5 we introduce our type system, and we state its main properties.The scenario in Section 1.2 is used as a working example through the paper.Our type system will determine that PM and PN above are not honest, while PH is honest.Finally, in Section 6 we draw some conclusions and we discuss on related work.

A Theory of Contracts
Contracts are modelled in a variant of CCS, inspired by [11] and refined in [2].We assume a set of participants, ranged over A, B, . .., and a set of atoms a, b, . .., that represent the actions performed by participants.We use an involution ā, as in CCS.We assume a distinguished atom e (for "end") such that e = ē, which models a successfully terminated participant, similarly to [11].
We distinguish between (unilateral) contracts c, which model the promised behaviour of a single participant, and bilateral contracts γ, which combine the contracts of two participants.Definition 2.1 (Unilateral and bilateral contracts, [2]).Unilateral contracts are defined by the following grammar: c, d ::= i∈I ai ; ci i∈I ai .ci ready a.c rec X .c X where (i) the index set I is finite; (ii) the atoms in {ai}i∈I are pairwise distinct; (iii) the ready prefix may appear at the top-level, only; (iv) recursion is guarded.We stipulate that the continuation of e in a contract is always E = rec X .e ; X.We will omit trailing occurrences of E in contracts.
Bilateral contracts are terms of the form A says c | B says d, where A = B and at most one occurrence of ready is present.
An internal sum i∈I ai ; ci requires a participant A to choose and perform one of the actions ai, and then to behave according to its continuation ci.Dually, an external sum i∈I ai .ci requires A to offer B a choice among all the branches.If B chooses ai, then A must continue according to ci.Separators ; and .allow us to distinguish singleton internal sums (e.g., a ; c) from singleton external sums (e.g., a .c).We shall use binary operators to isolate a branch in a sum: e.g.The precise version of the customer contract in Sect.1.2 is: The behaviour of bilateral contracts is given in terms of a labelled transition relation.We refer to [2] for the full technical details.Here we just comment on the main rules.Rule [INTEXT] regulates the interaction between a participant A making an internal choice, and B offering an external choice: If A chooses the branch a in her internal sum, then B is committed to the corresponding branch ā in his external sum.This is modelled by marking the selected branch with ready ā, and by discarding the other branches.Rule [RDY] allows B to perform the marked branch: The previous rules do not define the behaviour of a bilateral contract in case an internal choice is not matched by any action in the external choice of the partner.To guarantee that a bilateral contract can keep evolving (until one of the participants wants to exit), we introduce the notion of compliance, by adapting that in [11].This relies on the notion of ready sets.Definition 2.3 (Ready sets, [2]).The ready sets of a contract c (denoted by RS(c)) are defined as:

A Calculus of Contracting Processes
The contracts of Sect. 2 are embedded in the process calculus CO2 [2].We report in this section the main concepts and definitions.Let V and N be disjoint sets of, respectively, session variables (ranged over by x, y, . ..) and session names (ranged over by s, t, . ..).Let u, v, . . .range over V ∪ N .Definition 3.1 (CO2 syntax).The syntax of CO2 is given by: where S are systems, K are latent contracts, P are processes, and π are prefixes.
Processes specify the behaviour of participants.A process can be a prefix-guarded finite sum i πi.Pi, a parallel composition P | Q, a delimited process ( u)P , or a constant X( u).We write 0 for ∅ P and π1.Q1 + P for i∈I∪{1} πi.Qi provided that P = i∈I πi.Qi and 1 ∈ I.We omit trailing occurrences of 0. We stipulate that each X has a unique defining equation X(u1, . . ., uj) def = P such that fv(P ) ⊆ {u1, . . ., uj} ⊆ V, and each occurrence of process identifiers in P is prefix-guarded.
Prefixes include the silent action τ , contract advertisement tell A ↓u c, contract stipulation fuse, action execution dou a, and contract query asku φ.In each prefix π = τ , the identifier u refers to the target session involved in the execution of π.As in [2], we leave the syntax of φ unspecified.
A latent contract ↓x A says c represents a contract c advertised by A but not stipulated yet.The variable x will be instantiated to a fresh session name upon stipulation.K simply stands for the parallel composition of latent contracts.
A system is composed of participants A[P ], sessions s[γ], sets of latent contracts advertised to A, denoted by A[K], and delimited systems ( u)S.Delimitation ( u) binds session variables and names, both in processes and systems.Free variables and names are defined as usual, and they are denoted by fv( ) and fn( ).A system/process is closed when it has no free variables.Each participant may have at most one process in a system, i.e. we forbid systems of the form We say that a system is A-free when it does not contain the participant A[P ], nor latent contracts of A, nor contracts of A stipulated in a session.Note that sessions cannot contain latent contracts.

A[(v)P ] ≡ (v)A[P ]
Figure 1.Structural congruence for CO2 (Z, Z , Z range over processes, systems, or latent contracts) A[tell B ↓u c.P The semantics of CO2 is formalised by a reduction relation on systems (Def.3.2).This relies on a structural congruence relation, defined in Fig. 1.In order to define honesty in Sect.4, here we decorate transitions with labels, by writing A : π,σ − −−− → for a reduction where participant A fires prefix π.Also, σ is a substitution which accounts for the instantiation of session variables upon a fuse.Rule [TAU] is standard.Rule [TELL] advertises the latent contract ↓x A says c to B. Rule [FUSE] stipulates contract: if the latent contracts of A include two compliant contracts K, a fresh session s is created with the stipulation γ of K.The latent contracts K are consumed, and the substitution σ is applied the system to instantiate session variables.Note that σ is recorded in the label, so to allow rule [PAR] to apply it to the context.Rule [DO] allows A to fire an action a in a session s[γ].This is only possible if the contract γ admits a transition labelled A says a.After the reduction both the participant and the contract γ evolve to their respective residuals.Rule [ASK] allows A to check if a condition φ is satisfied by the contract in s[γ].To this purpose, we use a relation , which as in [2] is left unspecified.The language for conditions φ and the relation are parameters of the calculus.A typical instantiation is LTL and its entailment relation.
Rules [DEL1] and [DEL2] propagate (together with [PAR]) substitutions through delimitations.Rule [DEL1] is applied when only one variable (x) is being instantiated (with s).Upon reaching the delimitation, all the free occurrences of x within S have already been instantiated, hence the substitution is discarded.Rule [DEL2] deals with two cases: that where multiple variables (including u) are being instantiated, and that where the delimited identifier u is not being instantiated.In the first case, the substitution is restricted to the variables different from u, i.e. σ =u .Notice that in this case the delimitation in the residual is immaterial, because u ∈ fv(S ), and so (u)S ≡ S .In the second case both the substitution and the delimitation are preserved.Rule [PAR] is standard, but for the fact that the substitution σ has to be applied to the context S .Rule [DEF] is used to unfold constants.
Example 3.3.Consider the following system: A possible execution of S is the following: where where Hence, by rules [PAR] and [DEL2], we have By applying rules

On Honesty
We now define when a participant is honest.Intuitively, honest participants always respect the contracts they advertise.As remarked in Sect. 1, this notion is crucial in contract-oriented systems, since honest participants will never be liable in case of misbehaviours.
More precisely, a participant A is honest when she realizes every contract she advertises, in every session she may be engaged in.Thus, if a system S contains a session s with a contract c advertised by A, such as: then A must realize c, even in a system populated by adversaries which play to cheat her.To realize c, A must be "ready" to behave according to c. Realizability requires the above readiness property to be preserved by arbitrary transitions taken by S. This amounts to say that, in any reduct of S containing a reduct P of P and a reduct c of c, the process P must still be ready for c .
To formalise the notion of "P is ready for c", we need to inspect P and c.At the contract level, the ready sets in RS(c) (Def.2.3) reveal whether c is exposing an internal or an external choice.At the process level, we consider the reachable actions in P .We now study whether P0, . . ., P3 are ready for contracts ci and ce (introduced in Ex. 4.1) in session s.According to Def. 2.3, the ready sets of ci are {a} and {b}, while ce has only the ready set {a, b}.We have that: • P0 is ready for ci, because there exists a ready set ({a}) in RS(ci) such that dos a is enabled in P0.Instead, P0 is not ready for ce, because the ready set {a, b} of ce also contains b, which is not enabled in P0. • P1 is ready for both ci and ce.This is because P1 enables two actions, dos a and dos b, which cover all the ready sets of ci and ce.Notice that the branch dos z is immaterial, because rule [DO] blocks any action not expected by the contract.• P2 is ready for ci, because whatever branch is taken by P2, it leads to an unguarded action which covers one of the ready sets in ci.Instead, P2 is not ready for ce, because after one of the two branches is chosen, one of the two actions expected by ce is no longer available.• The case of P3 is a bit more complex than the above ones.
Readiness w.r.t.ci depends on the context.If the context eventually enables one of the dot, then either dos a or dos b will be enabled, hence P3 is ready for ci.Otherwise, P3 is stuck, hence it is not ready for ci.Notice that P3 is not ready for ce, regardless of the context.
To formalise readiness, we start by defining the set RD A u (S) (for "Ready Do"), which collects all the atoms with an unguarded action dou of a participant A in a system S.We have that RD A x (S) = {ā}, and RD A y (S) = ∅.
As seen in the above example for processes P2 and P3, readiness may also hold when the actions expected in the contract ready sets are not immediately available in the process.To check if A[P ] is ready for session s (in a system S), we need to consider all the actions which (1) are exposed in P after some steps, taken by P itself or by the context, and (2) are not preceded by other dos actions performed by A. These actions are collected in the set WRD A s (S).
On channel y, the action a is weakly reachable through its τ prefix.Action b is not weakly reachable, because guarded by a stuck dox.Action c is not weakly reachable as well, because preceded by another do on the same channel.
Example 4.7.Recall the process P3 = dot w .dos a + dot z .dos b from Ex. 4.2.Consider the following system, where participant A is involved in two sessions s and t (respectively, with B and C): In session t, A is immediately ready to perform either w or z, and thus her ready do set coincides with her weak ready do set in t.The same holds for C, with the dual atoms w and z.Thus: = {w, z} In session s, the ready do sets of both A and B are empty, because their actions are not immediately enabled.Before they can be reached, the whole system S must first reduce, either with the contribution of C on session t (in the case of A), or through a τ action (in the case of B).These reductions fall within the definition of their weak ready do sets, which are accordingly non-empty.
Notice that b ∈ WRD B s (S): in fact, b is only reachable after B executes dos ā, thus requiring a reduction trace which does not have the form S =(B : dos) − −−−−− → * .Finally, we emphasize that, if C chooses to perform τ , then the actions in WRD A s (S) would not be reached.Indeed, Def. 4.5 only requires that each element in the set becomes reachable at the end of a suitable (weak) reduction trace -but it does not prevent S from reducing along other paths.
A participant A is ready in a system S containing a session s[A says c | • • • ] iff A is (weakly) ready to do all the actions in some ready set of c.Notice that A is vacuously ready in systems not containing sessions with contracts stipulated by A. Definition 4.8 (Readiness).We say that A is ready in S iff, whenever S ≡ ( u)S for some u and A process A[P ] is said to be honest when, for all contexts where A[P ] may be engaged in, A is persistently ready in all the reducts of that context.Notice that A[P ] is vacuously honest when P advertises no contracts.
Informally, we shall say that A realizes a contract c in a session s in S when S has the form A and the readiness condition is satisfied in S and in all its reducts.Then, A[P ] is honest when A realizes all the contracts she advertises.Definition 4.9 (Honesty).We say A[P ] honest iff for all A-free S, and for all S such that A[P ] | S → * S , A is ready in S .
The A-freeness requirement in Def.4.9 is used just to rule out those systems which already carry stipulated or latent contracts of A outside A[P ], e.g.
In the absence of A-freeness, the system could trivially make A[P ] dishonest.
Example 4.10.Consider the following system: Even though A might apparently look honest, she is not.In fact, if we reduce S by performing all the tell and fuse actions, we obtain: Here, S cannot reduce further.Indeed, C (dishonestly) avoids to perform the internal choice required by his contract.Then, A is stuck, waiting for a from C. Therefore, A is dishonest, because she does not perform the promised action b.Formally, the dishonesty of A follows because RS(b ; E) = {{b}}, but b ∈ WRD A s (S ).Thus, A is not ready in S , hence not honest in S.
Our definition of honesty subsumes a fair scheduler, which eventually allows participants to fire persistently (weakly) enabled do actions.This is illustrated by the following two examples.
Under an unfair scheduler, A could always take the first branch in X, while neglecting the others.Intuitively, this would make A not respect her contract, which expects a or b.However, a fair scheduler will eventually choose one of the other branches.Technically, the fair scheduler is rendered within Def. 4.5 and 4.9.Def.4.5 considers a and b weakly enabled in S , because there exists a way to reach each of them.Since from any reduct of S either a or b are reachable, then Def.4.9 considers A[P ] honest.
Example 4.12.Consider the contract c = a + b and let: After the fuse, the system S reduces to . As in the previous example, an unfair scheduler might make A not respect her contract.However, in all the reducts of S both a and b are reachable.
rec X .T ≡ T { rec X.T /X} commutative monoidal laws for |, + Indeed, there is no branch which definitely commits to one of the two actions.Therefore, according to Def. 4.9, A[P ] is honest.

A Type System for CO 2
We now introduce a type system for CO2 .The main result is type safety (established in Th.5.35), which guarantees that typeable participants are honest.
The type of a process P is a function f , which maps each channel (either session name or variable) to a channel type.Channel types are behavioural types which essentially preserve the structure of P (branching, parallel composition, recursion), while abstracting the actual prefixes and delimitations.Mainly, the prefixes of channel types distinguish between nonblocking and possibly blocking actions.
In Sect.5.1 we define channel types; then, in Sect.5.2 we define process types and the type system for processes.In Sect.5.3 we present an auxiliary set of typing rules for CO2 systems, which are only needed to state subject reduction and progress in Sect.5.4.Type safety is established in Sect.5.5.

Channel types
Channel types extend Basic Parallel Processes (BPPs [17]) by allowing prefixes of the following kinds: atoms (a, b, . ..), nonblocking silent actions (τ ), possibly blocking silent actions (τ ?), conditional silent actions depending on observables (τ φ ), and contract advertisement actions ( c ). Definition 5.1 (Channel types).The syntax of channel types T and prefixes α is defined as follows: We denote with T the set of all channel types.
The semantics of channel types is given in Def.5.2, in terms of a labelled transition relation where ci = ā ⊕ b, and d is immaterial.We anticipate that the channel types associated by our type system to P on channels x and y are, respectively: Note that the advertisement of ↓x ci is recorded in Tx, while that of ↓y d is abstracted there as a τ .Instead, the τ ? in Ty represents the fact that the dox ā may potentially block the actions in its continuation.The channel type Tx can reduce in several ways, e.g.: The execution of CO2 systems relies both on processes and on (advertised/stipulated) contracts.An abstraction of the contract/process interplay is then used to define an abstract semantics of processes.Definition 5.4 (Abstract processes).An abstract process is either a pair (C, T ) or a pair (c, T ), where C is a set of contracts, c is a contract, and T is a channel type.Definition 5.5 (Abstract process semantics).The semantics of abstract processes is given in terms of a transition relation →, which is the least relation closed under the rules of Fig. 4.
An abstract process (C, T ) represents a process abstracted by T on some channel x, after the contracts in C have been advertised.Instead, an abstract process (c, T ) represents a process abstracted by T on some channel x, after the contract c has been stipulated.
The set C grows when a channel type T in (C, T ) performs a transition with label c (rule [A-TELL1]).After one of the contracts in C has been stipulated (rule [A-FUSE]), it can be reduced through the rules [A-DO] and [A-CTX].Rule [A-DO] models a do a action performed by T , while rule [A-CTX] models an (unknown) action performed by the context.Further advertisements are neglected (rule A-TELL2).Notice that in rules [A-DO] and [A-CTX] contracts are reduced through the relation − → → .This relation abstracts the contract semantics − → →, by considering only the contract advertised by P (instead of the whole bilateral contract).The actions performed by the context are labelled with ctx .We leave the relation − → → unspecified (see [2] for a possible instantiation), and we just require that − → → is decidable, and for all γ Example 5.6.Recall the trace (5) in Ex. 5.3.That induces the following two traces for the abstract process (∅, Tx).Belows, we annotate arrows with rule names from Fig. 4.
Instead, we are not able to follow trace (6), since: Intuitively, in (6) the action a is performed before the contract ci is advertised -but this is not possible because of rule [A-DO].
We now introduce the abstract counterpart of the dynamic notion of honesty in Sect. 4. We shall follow the path outlined for concrete processes: first we define when a channel type T is "ready for a contract", and then when T is honest.
In the case of concrete processes, readiness requires to match the "weak ready do" set of the process against the ready sets of the contract (Def.4.8).Similarly, here we shall match the "weak transitions" of a channel type with the ready sets of the contract.
Indeed, such weak transitions abstract the weak ready do set.That is, if an abstract process can take a weak transition a, then also the concrete one will do that.This under-approximation is needed to ensure the correctness of abstract honesty: if an abstract process is honest, then also the concrete one will be such (while the vice versa is not always true).
Recall that the actions a in the weak ready do set (of session s) are those to be fired in a dos a by the concrete process.Their abstract counterpart, i.e. labels of weak transitions, consider actions reachable through sequences of non-blocking (abstract) transitions, which are included in the ready do set.Unlike in the concrete case, the context is immaterial in determining weak transitions.
Weak transitions are defined in Fig. 5 as a labelled relation a = ⇒c A (simply written as a = ⇒ when unambiguous).The first two rules are standard: they just collapse the τ actions as usual.The third rule also collapses contract advertisement actions, which are nonblocking as well.Possibly blocking actions τ ?are not collapsed, while τ φ are dealt with the last rule.The action τ φ is the abstraction of the CO2 prefix asku φ.Such action is collapsed only if such ask is non-blocking.The relation A safely (under-) approximates this condition.We leave A unspecified (just like in Sect.3), and we only require that it respects the constraint in Def.5.7 below.Definition 5.7 (Abstract observability).We write c A φ for any decidable relation between contracts and observables satisfying: The definition of abstract readiness (Def.5.8) follows along the lines of Def.4.8.Definition 5.8 (Abstract readiness).For a channel type T and a contract c, we say that T is abstractly ready for c iff: Hereafter, when referring to properties of abstract entities, we shall omit the qualifier "abstractly", e.g.we shall write that a channel type is "ready", instead of "abstractly ready".
Honesty of abstract processes is defined similarly to Def. 4.9.In order to be honest, a process must keep itself (abstractly) ready upon transitions.Readiness must be checked against all the contracts that may be stipulated along the reductions of the abstract process, starting from the empty set of contracts.Definition 5.9 (Abstract honesty).We say that: • An abstract process (−, T ) is honest iff Informally, we say that T realizes c whenever (c, T ) is honest.
Example 5.10.Recall the type Tx = ci | τ .a and the contract ci = a ⊕ b from Ex. 5.6.To determine whether Tx is honest, we examine all the reducts of the abstract process (∅, Tx) to check for readiness.We have the following cases: 1. (∅, Tx).Nothing to check, because no contracts have been advertised yet.2. (∅, ci | ā).Similar to the previous case.(ci, a).We have that a is ready for ci, similarly to the previous case.7. (E, 0).We have that 0 is vacuously ready for E.
Summing up, we conclude that Tx is honest.
Th.5.11 below establishes that checking the honesty of a channel type T is decidable.Indeed, both abstract readiness and abstract dishonesty are reachability properties.Abstract processes are the product of a finite state system (C and c only admit finitely many states), and a Basic Parallel Process.This product can be modelled as a Petri net.Decidability follows because reachability is decidable for Petri nets [17].

Process types
Process types associate session names/variables to channel types, thus abstracting the behaviour of a process on all channels.Additionally, we consider a special "dummy" channel * ∈ N ∪V, where we collect type information about unused channels.Definition 5.12 (Process type).A CO2 process type is a function Intuitively, our type system abstracts concrete prefixes of CO2 processes as actions of channel types.Such abstraction is rendered as the mapping in Def.5.13.We observe the behaviour of a process P on each channel, say u.When P performs an action on one of its channels, say v, we have two cases: • if v = u, we will only observe a silent action, either nonblocking (τ ) or blocking (τ ?), depending on the concrete prefix fired.
• if v = u, we may observe more information, depending on the concrete prefix fired. where Typing rules for processes.
For instance, if P advertises a contract c with a tell ↓v c, then the action c will be visible if v = u, while we shall just observe a τ if v = u (because tell is nonblocking).. Similarly, if P performs dov a we shall observe the action a if v = u and τ ?if v = u (because do is blocking).Finally, if P executes a query asku φ we shall observe the conditional silent action τ φ if u = v and τ ?otherwise.This allows for exploiting suitable static approximations of the relation (see Fig. 5).
Definition 5.13 (Prefix abstraction).For all u ∈ N ∪ V ∪ { * }, we define the mapping [•]u from CO2 prefixes to channel type prefixes as follows: The typing judgments for processes have the form Γ P : f , where Γ is a typing environment, giving types to processes X( v).Definition 5.14 (Typing environment).A typing environment Γ is a partial function which associates process types to constants X( v).
We can now introduce the typing rules for CO2 processes.Definition 5.15 (Typing rules for processes).The typing rules for processes are shown in Fig. 6. ) is worth some extra comments.Assume that P is typed with f .Since u in not free (u)P , the actions on channel u must not be observable in the typing of (u)P .To do that, in the typing of (u)P we discard the information on u, by replacing it with the typing information on the "dummy" channel * .However, since this might hide a dishonest behaviour on channel u, the rule also requires to check that f (u) is honest.Moreover, if the environment Γ has typing information on channel u, this cannot be used while typing P .The typing environment Γ =u , which discards the information on u, is used to this purpose.

Concluding Remarks and Related Work
Building on CO2 we gave a type system that allows for the static checking of honesty of systems.The channels onto which a CO2 process interacts are typed with a behavioural type.Such type abstracts the actual prefixes of the process while mimicking the non-deterministic and parallel branching of the process as well as its recursive behaviour.Our typing enjoys the subject reduction (Th.5.32) and progress properties (Th.5.34).More importantly, type safety establishes honesty of typeable processes, that is typeable processes honour their contracts in all contexts.
The process calculus CO2 has been introduced in [1], and in [2] it has been instantiated to a theory of bilateral contracts inspired by [11].We refer the reader to [2] for a comparison between our contract theory and the one in [11].In [2] a process A is hon- Figure 10.Abstract process reductions for the honest food store (YH (x) sub-process).The graph omits the τ ?channel type transitions.
est when, for each session she is engaged in, A is not definitely culpable.That is, A eventually performs the actions her contract prescribes.The definition of honesty we adopt here is based on readiness rather than culpability and we conjecture that it is equivalent to the notion of honesty in [2].The main advantage of this novel approach compared to [2] is that it simplifies the proof of the correctness of the static analysis of honesty, by more directly relating abstract transitions with concrete ones.Also, the new definition helps in proving decidability of abstract honesty, which was left open in [2].
In [5] (multiparty) asserted global types are used to adapt design-by-contract to distributed interactions.In our framework, a participant declares its contract independently of the others; a CO2 primitive (fuse) tries then to combine advertised contracts within a suitable agreement.In other words, one could think of our approach as based on orchestration rather than choreography.
In [16] the progress property is checked only when participants engage at most in one session at a time.Honesty is a sort of progress property, and our type system allows participants to interleave many sessions as done in [15].A crucial difference with respect to [15] is that the typing discipline there requires the consistency of the local types of any two participants interacting in a session.Namely, if in a session s, A and B are typed as T A and T B respectively and they interact then the projection of T A with respect to B must be dual of the projection of T B with respect to A. In our type system instead, participants are typechecked 'in isolation' and to establish the honesty of a participant A our typing discipline only imposes that the surrunding context is A-free.
Other approaches deal with safety properties, by generating monitors that check at runtime the interactions of processes against their local contract (e.g., [12,13]).
The problem of checking if a contract c representing the behaviour of a service conforms to a role r of a given choreography H has been investigated in [6].Under suitable well-formed conditions, conformance of c is attained by establishing a should testing pre-order between c and the projection of H with respect to role r.Similar techniques have been used in [7] to define contractbased composition of services.Besides using a different technical approach not base on pre-orders, a main difference with respect to the approach in [6] and [7] is that they do not consider conformance in the presence of dishonest participants.Actually, these papers focus on using the testing pre-order to determine if the abstract behaviour of a service (i.e., its contract), comply with a role of the choreography.Instead, we are interested in establishing weather a process abides by its own contract regardless its execution context.
Contracts for service-level agreement have been modelled in [9] as constraint-semirings.Such model is used in [8] for compiling clients and services so to guaranteed that, whener compatible, they progress harmoniously.This is orthogonal to our approach since our aim is not to rule out "inconsistent" executions, rather to blame participants that misbehave.

Example 2 . 5 .
we say that the contracts c and d are compliant.The contracts c and d of our working example (Ex.2.2) are compliant.

Definition 3 . 2 (
CO2 semantics).The relationA : π,σ − −−− → between systems (considered up-to structural congruence ≡) is the smallest relation closed under the rules of Fig. 2. The relation K σ γ holds iff (i) K has the form ↓x A says c | ↓y B says d, (ii) c d, (iii) γ = A says c | B says d, and (iv) σ = { s /x,y} maps x, y ∈ V to s ∈ N .The substitution σ =u in rule [DEL2] is defined as σ(v) for all v = u, and it is undefined on u.

Example 4 . 1 .
If A[P ] has advertised a contract c with an internal choice ci = a ⊕ b, then P must be ready to do at least one of the actions a, b.Instead, if c is an external choice ce = a + b, then P must be ready to do both the actions a and b.

Example 4 . 11 .
Consider the contract c = a ⊕ b, and let:P def = (x) tell A ↓x c .fuse .X(x) X(x) def = τ .X(x) + τ .dox a + τ .dox b Let S = A[P ] | S0,and assume that the fuse in P passes.Then, S reduces to S

Definition 5 . 2 ( 3 .Example 5 . 3 .
Channel type semantics).The relation α − − → is the least relation closed under the rules of Fig.The rules for α − − → are the standard ones for BPPs.Hereafter, we shall identify structurally congruent channel types.Consider the following CO2 process: P = tell B ↓x ci | tell B ↓y d .dox ā

Figure 5 .
Figure 5. Channel type semantics (weak transition, parameterised by A and c).