Contract Automata: Towards an Algebra of Contracts - Dr. Gordon J. Pace

Contract AutomataTowards an Algebra of Contracts

Gordon J. PaceDepartment of Computer Science

University of MaltaMalta

March 2016

Gordon J. Pace Contract AutomataTowards an Algebra of Contracts

What’s so Interesting about Contracts?

I Normative notions — ideal vs actual behaviour.

I Enabling representation of concepts such as obligations,prohibitions permissions, and exceptional behaviour.

I Ought-to-do or ought-to-be?

I Plagued by paradoxes unless one is very careful and restrictsthe language.


Paradox of Blame

Paradox of Blame

The law says: You are obliged to hand in Form A on Monday andForm B on Tuesday, unless officials stop you from doing so.

But it’s sunny outside: On Monday, John spent a day on thebeach, thus not handing in Form A. On Tuesday at 00:00 he wasarrested, and taken to court on Wednesday.

Prosecuting lawyer: To satisfy his obligation the defendant hadto hand in Form A on Monday, which he did not. Hence he shouldbe found guilty.

Defendant’s lawyer: But to satisfy the obligation the defendanthad to hand in Form B on Tuesday, which he was stopped fromdoing by officials. He is hence innocent.


Contracts vs. Specifications

I What are contracts, and are they different from properties orspecifications?

I Obligation to perform x related to the property ‘action takenmust include x ’

I Prohibition from performing x related to the property ‘actiontaken may not include x ’

I But what are permission to perform x? Actions may includex? What are violations?

I And what about liability?I Or exceptional (non-ideal) behaviour?

I Contracts are by definition an agreement between two or moreinteracting parties but most formal studies regulate a party ata time.


Contract clause #1

“John is permitted to withdraw cash.”

I John may choose to perform an action ‘withdraw cash’,

I which the bank is bound to engage with.

I John may also choose not to perform the action.

I but if he does and the bank does not allow the bank hasviolated the contract.


Contract clause #2

“John is obliged to pay an annual fee.”

I John should perform an action ‘pay annual fee’,

I If John chooses not to perform the action, he has violated thecontract.

I But the bank is bound to engage with John’s action to allowhim to satisfy the contract.


Interacting Systems

I Interaction has a long history in computer science providingtools such as communication and synchronisation which allowthe modelling of directed modalities in a two-party contractsetting.

I We formalise two-party contracts modelling interaction usingsynchronous composition with multiset-actions.


Synchronous Composition over Multisets of Actions

I The synchronous composition of two automataSi = 〈Qi , q0i , →i 〉 synchronising over alphabet G , is writtenS1‖GS2, is defined to be 〈Q1 × Q2, (q01, q02),→〉.

q1A−→1 q′1

(q1, q2)A−→ (q′1, q2)

A ∩ G = ∅q2

A−→2 q′2

(q1, q2)A−→ (q1, q

′2)

A ∩ G = ∅

q1A−→1 q′1 q2

B−→2 q′2

(q1, q2)A∪B−−−→ (q′1, q

′2)

A ∩ G = B ∩ G 6= ∅


But What About the Contract?

I Contracts are also encoded as automata with states taggedwith the contract clauses that will be in force at that point.

Contract

“Initially, the user (party u) is forbidden from using the service butpermitted to pay after which the provider (party p) is obliged toprovide the service.”

Pu(pay), Fu(service) Op(service)

∅

{service}

{pay}

{pay, service}

anything


Contract Automata

I A contract clause is one of the following:

Clause ::= Op(a) | Op(!a) | Pp(a) | Pp(!a)

I A contract automaton is a normal automaton with anadditional function Q → 2Clause.

I The transition relation of contract automata is always total toensure no deadlock, even after a violation occurs.


Contract Automata





Prohibition

Prohibition Fp(a) is just Op(!a).


Contract Automata





Negative clauses

!Op(x) = Pp(!x)!Pp(a) = Op(!a)


Regulated Two-Party Systems

I A regulated two-party system synchronising over the set ofactions G consists of three parts: (i) the interacting systemsS1 and S2 and (ii) the contract A.

I By composing the contract automaton A with the parties’behaviour we can then identify what clauses are in force andwhen, hence allowing analysis for contract violation:(S1‖GS2)‖ΣA.


Contract Violation

I Given a regulated two-party system, we can now analyse thesystem automata with respect to the contract clauses and tagviolations and the responsible party.

I Violations can occur on:I Transitions: e.g. a transition which contains an action which

is prohibited at that point.I States: e.g. a state in which a party does not permit (allow)

the other party to perform an action which should bepermitted.


Obligations

I Obligation Op(a) brings in constraints on both parties:

1. party p must include the action in any outgoing transition inthe composed system; and

2. the other party p must provide a viable action set which allowsp to perform all its obligation.

I The former marks transitions as violations, whereas the lattermarks states.

viablep(qA,A)df= Op(qA) ⊆ A ∧ Fp(qA) ∩ A = ∅

satOp ((q1, q2)qA

A−→ (q′1, q′2)q′

A)

df= viablep(qA,A)

satOp ((q1, q2)qA)

df= ∃A ∈ acts(qp), A′ ⊆ G c · viablep(qA,A ∪ A′)


Permissions

I If party p is permitted to perform shared action a, then theother party p must provide p with at least one viable outgoingtransition which contains a but does not include any forbiddenactions.

I Violations of a permission occur when no appropriate action ispossible, and is thus a property of a state not a transition.

I We use a semantics that tags as a violation a state in whichone party is permitted to perform an action, while the otherprovides no way of actually doing so.

(q1, q2)qA `p Pp(a)df= true

(q1, q2)qA `p Pp(a)df=

a ∈ G =⇒ ∃A ∈ acts(qp), A′ ⊆ G c · a ∈ A ∧ viablep(qA,A ∪ A′)

satPp ((q1, q2)qA)

df= ∀Pp(x) ∈ qA · (q1, q2)qA `p Pp(x)


Breach-incapability

I A regulated system gives an automaton of all potentialbehaviours when composed.

I It is breach-incapable if no violating states and/or transitionsare reachable from the initial state.

I This is stronger than being compliant for one specific run.

correct(p,R)df=

(∀q ∈ reachableS (R) · satp(q)) ∧ (∀t ∈ reachableT (R) · satp(t))


Ordering of contracts based on leniency

I A contract A is more lenient than another contract A′ for aparticular party p (A vp A′) if any system behaviour of pwhich may violate A may also violate A′.

I This definition allows us to characterise the notion of contractequivalence for a particular party or even for all parties.

A vp A′ df= ∀S1, S2 · correct(p, 〈S1,S2〉A′) =⇒ correct(p, 〈S1,S2〉A)


Pp(c)

Op(a)

{a} or {b} or ∅

{a, b}

anything

vp

Pp(c) Op(a)

Op(a), Pp(b)

{a} or ∅

{a, b}

{b}

{a} or {b} or ∅

{a, b}

anything


Conflicts in Contracts

Axiom 1: Opposite permissions conflict: ` Pp(x) z !Pp(x).Axiom 2: Obligation to perform mutually exclusive actions is aconflict: a ./ b ` Op(a) z Op(b).Axiom 3: Conflicts are closed under symmetry: C z C ′ ` C ′ z C .Axiom 4: Conflicts are closed under increased strictness:C z C ′ ∧ C ′ v C ′′ ` C z C ′′.


John and his Bank

The contract says that (i) whenever he is logged into his Internetbanking account, he is to be permitted to make money transfers;and (ii) if a malicious attempt to log in to his account is identified,logging in and making transfers will be prohibited until thesituation is cleared.

Fj(transfer) Pj(transfer) Pj(login) Fj(login), Fj(transfer)

login

logout

malicious

cleared

Note what happens after {login, malicious} in the composition ofthese contracts.


Adding Reparations

I Some reparations can be ‘handled’ by contract automata.

I e.g. “The passenger is obliged to show a means ofidentification when presenting the ticket, and would otherwisebe prohibited from boarding.”

Op(proveIdentity)start

Fp(boardPlane)

{showTicket, proveIdentity}

{showTicket}

I But with such an encoding, we have no notion of whichtransitions are violating ones.

I And even worse, we cannot express a reparation of apermission in this manner.


Reparations

Pp(boardPlane)Pp(handLuggage)

Pp(coat)Pp(report)

Oc (inCargo)Pp(report)Oc (inCargo)

Op(switchOffDevices)Vc (Pp(coat)) . {boardPlane} ok . {boardPlane}

Vc (Pp(handLuggage)) . {boardPlane} Vc (Pp(coat)) ∧ Vc (Pp(handLuggage)) . {boardPlane}

I By tagging each transition with which clauses would have tobe violated to take that transition, we can model reparations.

I In addition, we can talk about hypothetical reparations.


Discussion

I By keeping the contract as a separate automaton:I We share the same formalism and theory as for systems;I We are able to reason about contracts independently of the

system — e.g. compose contracts using synchronouscomposition

I Although we can reduce a regulated system to a singleautomaton, by keeping the original systems and contract asautomaton we keep the system behaviours separate andintact. Permission can only be deduced with thisunadulterated behaviour.


Conclusions

I The main contributions of this work are:I A formalisation of the meaning of directed deontic operators in

a two-party setting;I The use of standard techniques from computer science, namely

communication and synchronisation, to analyse contractsregulating two parties.

I Practically all the work done on directed obligations andpermissions introduces new modalities such as intention,causality, etc.

I We are now looking into how much further such anautomaton based approach supports contract analysis, andextending it to deal with multi-party (n > 2) systems.


Engineering

Contract Automata: Towards an Algebra of Contracts - Dr. Gordon J. Pace