State Machine Rules

The permissible transitions in the ASM are described through rules, which are repre- sented using the following notation.

rule name(v1, v2,· · ·) : condition1(v1, v2,· · ·) ∧ condition2(v1, v2,· · ·)∧ · · · → { pseudo statement1; · · · pseudo statementn; }

Rules are identified by their name and a number of parameters that the rule operates over. Any number of conditions must be met for a rule to fire. Once a rule’s conditions are met, the rule can fire. The execution of a rule is a transition of the state machine and is atomic in order to maintain its consistency. A new state is achieved after applying all the rule’s pseudo-statements to the state that met the rule’s conditions.

We use send, receive and table update pseudo-statements. Informally, send(a1, a2, m)

inserts a message m into the channel from actor a1 to actor a2, and receive(a1, a2, m)

removes the message. Likewise, the table update operation puts a message into a table. The notation table T is used to refer to any table in the state space. Formally, these pseudo-statements act as state transformers and are defined as follows.

Chapter 4 Recording Process Documentation 90

• We use the operators ⊕and to denote union and difference on bags. Ifk is the set of message channels of a stateh. . . , k, . . .i, then the expressionsend(a1, a2, m)

andreceive(a1, a2, m) respectively denote the stateh. . . , k0, . . .i, wherek0(a1, a2) = k(a1, a2)⊕{m}andk(a1, a2) {m}, andk0(ai, aj) =k(ai, aj),∀(ai, aj)6= (a1, a2). • Iftable T is a component of stateh. . . , table T, . . .i, then the expressiontable T(. . .).y

:=V denotes the stateh. . . , table T0, . . .i, wheretable T(. . .).x=table T0(. . .).xif

x6=y, and table T0(. . .).y=V.

To ease the readability of the rules, we also define the following pseudo functions. The function below determines if a View is complete:

Definition

complete:A×IK×RI→ {true, f alse}

complete(a, κ, v) :=

Ifstore T(a)(κ, v).sf 6=⊥,

then returnstore T(a)(κ, v).sf.na=|store T(a)(κ, v).recs|

else returnfalse.

The complete function takes as input an actor identity, an interaction key and a role identifier, which together identify a particular View within a provenance store. Once the View is found, the function tests to see if it contains a submission finished message. If the View does, the function tests whether the number of p-assertions within the View is the same as the number of expected p-assertions as specified in the submission finished message. If the numbers are equal, the function returns true. In all other cases, the function returns false.

The following pseudo function creates new interactions keys, updating an actor’s local counter table.

Definition

newIdentif ier:Senders×Receivers→IK

newIdentif ier(as, ar) :=

lc(as) :=lc(as) + 1

returnha_s, ar, lc(as)i.

The function ensures that interaction keys are uniquely created. It takes two actor iden- tities as inputs: one for the sender and one for the receiver. It then obtains the local counter of the sender and increments it by one. It then constructs a new interaction key using the two actor identities and the local counter. This interaction key is then re- turned by the function. This models the notion that senders are responsible for creating interaction keys.

Chapter 4 Recording Process Documentation 91

receive record passertion(a, aps, κ, v, `, α) : rec(κ, v, a, `, α)∈ K(a, aps)

→ {

receive(rec(κ, v, a, `, α), a, aps); -6

if (` /∈store T(aps)(κ, v).lpids∧ ¬complete(aps, κ, v)), then

store T(aps)(κ, v).lpids:=store T(aps)(κ, v).lpids∪ {`}; +1 or +0 store T(aps)(κ, v).recs:=store T(aps)(κ, v).recs∪ {rec(κ, v, a, `, α)}; +1 or +0

send(ack(κ, v, `), aps, a); +2

} overall: -2 or -4

receive submission f inished(a, aps, κ, v, `, na) : sf(κ, v, a, `, na)∈ K(a, aps)

→ {

receive(sf(κ, v, a, `, na), a, aps); -5

if(` /∈store T(aps)(κ, v).lpids∧store T(aps)(κ, v).sf =⊥), then

store T(aps)(κ, v).lpids:=store T(aps)(κ, v).lpids∪ {`}; +1 or +0

store T(aps)(κ, v).sf :=sf(κ, v, a, `, na); +1 or +0

send(ack(κ, v, `), aps, a); +2

} overall: -1 or -3

Figure 4.12: Provenance Store rules

Figures 4.12 and 4.13 show the ASM’s transition rules, which formally define the be- haviour described in Section 4.4.3. The annotations to the right of each rule are used in our termination proof and will be discussed later. We now discuss the two rules that govern the provenance store’s behaviour shown in Figure4.12.

Provenance Store Rules The receive record passertion rule takes an incoming record message from a particular actor and places it in the correct View in the provenance store as defined by store T, and thereby also stores the p-assertion enclosed in the message. The View is looked up via the interaction key and role identifier located in therec message. An acknowledgement message (ack) is then sent to the actor who sent the rec message. During its execution, the rule checks to see whether or not the local p-assertion id (`) of the p-assertion contained within the message has already been used in the interaction record. If `has not been used, the message is stored, otherwise it is not. Likewise, if the View is complete (i.e. it already contains the requisite number of p-assertions) the message is not stored. In all cases, the same acknowledgement is sent. This rule satisfies part of Behaviour Rule 5 (See Section4.4.3.

The receive submission f inished rule operates in a similar manner and satisfies the rest of behaviour rule 5. However, only one submission finished message (sf) is allowed to be recorded. If subsequent sf messages are received by the provenance store, the message is discarded and an ackmessage is sent to the actor.

We note that all local p-assertion ids made available in the provenance store correspond to a message stored in the provenance store. This correspondence is made in order to

Chapter 4 Recording Process Documentation 92

simplify the rules. To show this, we establish the following lemma.

Lemma 4.2 (Local P-Assertion Id Correspondence). For any configurationc, for all `, κ, v, a, α, na, `∈store T(κ, v).lpids if and only if there exists a rec(κ, v, a, `, α)

∈store T(κ, v).recs or a sf(κ, v, a, `, na) =store T(κ, v).sf.

Proof. We prove this lemma by induction on the length of the transition sequence from the intitial configuration ci to a configurationc. In the base case, where the length is 0,

all sets are empty and the lemma trivially holds.

In the inductive case, for transition lengths greater than zero, we assume that the lemma holds for ci 7−→∗ cn and we consider all possible transition sequences from cn 7−→ c.

The only two rules that modify the provenance store arereceive record passertionand

receive submission f inished.

In the case of the receive record passertion, if a local p-assertion id is added to the provenance store then a corresponding record message is also added. Likewise, if a record message is added then a corresponding local p-assertion id is added. This is shown in the third and fourth pseudo-statements of the rule. There is only one local p-assertion used in the rule as shown by the rules guard, thus, the local p-assertion id that is stored to the set store T(κ, v).lpids is the same as the one inside the stored record message.

The same reasoning also holds true ofreceive submission f inished, however, with sub- mission finished messages not record messages.

In both rules nothing is deleted, therefore, the correspondence is always maintained.

Sender and Receiver rules The rules shown in Figure 4.12 define the behaviour of a provenance store in the ASM. However, in order to prove the properties of safety, liveness and attributability, we need to prescribe some behaviour of the actors that use provenance stores. Our aim is to show that if an actor behaves in the manner defined then certain guarantees can be given. This behaviour is formalised in Figure4.13. The functionality of these rules can be summarised as follows. When involved in an in- teraction (i.e. either sending or receiving a message), an actor makes p-assertions related to that interaction. This behaviour is shown in the send app msg and receive app msg

rules. We highlight themakeAssertions function which takes an actor identity (a), an interaction key (κ), some data (d), and a business logic description (r) and produces a set of p-assertions,{α1, . . . , αn}. The business logic description is equivalent to the type

of relationship p-assertion that should be produced by the makeAssertions function. An instantiation ofmakeAssertions is crucial in the proof of liveness.

Once the set has been created, a rec message for each p-assertion is then constructed and added to the table of messages to be sent to the provenance store (to send T).

Chapter 4 Recording Process Documentation 93

send app msg(as, ar, d, r) :

// triggered whend, produced by a function described byr, is to be sent byastoar

→ {

letκ=newIdentif ier(as, ar)

in {α1, . . . , αn}=makeAssertions(as, κ, d, r); send(app(κ, d), as, ar);

assert T(as, κ,S) :=assert T(as, κ,S)∪ {α1, . . . , αn};

} annotations not applicable

receive app msg(as, ar, κ, d) : app(κ, d)∈ K(as, ar)

→ {

receive(app(κ, d), as, ar);

// receive business logic

{α1, . . . , αn}=makeAssertions(ar, κ, d,⊥);

assert T(ar, κ,R) :=assert T(ar, κ,R)∪ {α1, . . . , αn};

} annotations not applicable

make passertion msg(a, α, v, κ) :

α∈assert T(a, κ, v) → {

let` /∈lpid T(a, κ, v)

in to send T(a, κ) :=to send T(a, κ)∪ {rec(κ, v, a, `, α)}; +9

assert T(a, κ, v) :=assert T(a, κ, v) α; -30

lpid T(a, κ, v) :=lpid T(a, κ, v)⊕`; + 1

let`2∈/lpid T(a, κ, v)∪ {`}

in if (assert T(a, κ, v) =∅), then

to send T(a, κ) :=to send T(a, κ)∪ {sf(κ, v, a, `2,|lpid T(a, κ, v)|)}; +0 or +9

lpid T(a, κ, v) :=lpid T(a, κ, v)⊕`2; +0 or +1 } overall: -10 or -20 record message(a, aps, m) : m∈to send T(a, κ) → { to send T(a, κ) :=to send T(a, κ) m; -9 sent T(a, κ) :=sent T(a, κ)⊕m; +1 send(m, a, aps); +5 or +6 } overall: -2 or -3 receive ack(a, aps, κ, v, `) : ack(κ, v, `)∈ K(aps, a) → { receive(ack(κ, v, `), aps, a); -2

ack T(a, κ) :=ack T(a, κ)⊕ack(κ, v, `); +1

} overall: -1

Chapter 4 Recording Process Documentation 94

Furthermore, a sf message is constructed when all the recmessages have been added to

to send T. The sf message could be constructed at any time, but we have chosen to do so at this stage to make the rules simpler. Creating sf messages in this manner is an eager strategy, they could also be generated using a lazy strategy. These steps are formalised in make passertion msg, which also obtains the asserter identity and keeps track of the local p-assertion ids that the actor has used.

Once a message has been sent, it is added to a table of messages that have been sent to the provenance store,sent T, and removed fromto send T. Finally, when an acknowl- edgement has been received, it is stored in the table ack T. This models how an actor keeps track of its communication with a provenance store for a particular interaction identified byκ. The rules that correspond to this tracking functionality arerecord msg

andreceive ack and satisfy Behaviour Rule 4. Behaviour Rules 1 through 3 are discussed during the analysis of the protocol, which we now introduce.