Langshaw: Declarative Interaction Protocols Based on Sayso and Conflict

1 Introduction

Our setting of interest is a decentralized multiagent system (MAS) [Boissier et al., 2023] in which agents, each reflecting its stakeholder's autonomy, interact in a loosely coupled manner. To achieve interoperation between agents independently of their construction or reasoning presupposes that we specify their interactions at a high level [Poslad, 2007].

Classically, agents interact by sending messages, each a bundle of information, to one another. Achieving interoperation requires (see Section 2) specifying (1) the information each message conveys, (2) constraints on message ordering and occurrence, and (3) the meaning of each message in mental [Sadek et al., 1997] or social [Singh, 2000] constructs.

However, modeling interaction via messages is problematic. First, a message is a low-level construct-the smallest operational unit of interaction. Models based on messages must contend with an explosion in possible messages and orders, and the complexity of coordination. Second, there is not always a natural mapping between messages and meanings.

In contrast to existing MAS approaches, we model communicative actions directly inspired by Austin's (1962) speech act theory, separately both from messages and meanings.

Approach. We propose Langshaw (after Austin's middle name), a declarative language for specifying protocols in terms of communicative actions. Langshaw enables the precise and succinct specification of protocols via novel primitives for expressing the information content and the social arrangements needed for coordination. Respecting the fundamental Austinian doctrine of saying makes it so, Langshaw introduces sayso to capture who can declare what information (i.e., "make it so"). To support flexible interactions, the saysos of agents over the same information are prioritized. Langshaw also introduces primitives to directly capture conflict between actions. Moreover, to support flexible interactions, Langshaw supports agents concurrently attempting actions. The semantics ensures the consistency of the system state without unduly compromising flexibility.

Contributions. One, we introduce the Langshaw language and give its semantics and efficient decision procedures for checking the safety and liveness of Langshaw specifications.

Two, we bridge the gap between synchronous and asynchronous communication. Assuming synchronous actions simplifies specification and reasoning. We give Langshaw a synchronous semantics. However, synchrony is an unrealistic model for MAS intended to be deployed over asynchronous infrastructures such as the Internet. We show how to compile a Langshaw protocol into a protocol that can be enacted via asynchronous messaging. Our compilation highlights Langshaw's simplicity and high-level nature: A compiled protocol may involve subtle coordination that would be difficult to write by hand. We prove the correctness of the compiler.

2 RelatedWork and Novelty

Protocols are crucial to MAS engineering methodologies [Cernuzzi and Zambonelli, 2004; Desai et al., 2005; Rooney et al., 2004; Padgham and Winikoff, 2005], but are traditionally expressed in semiformal notations such as AUML. Thus, they fall short of the goals for engineering MAS [Winikoff, 2007]. Through its precision and flexibility, Langshaw offers an opportunity to rethink MAS methodologies by capturing stakeholder intuitions and helping realize implemented MAS.

Ferrando et al. [2019] specify protocols as trace expressions over messages. They study diverse communication models, ranging from fully synchronous to fully asynchronous, but do not give a method to translate from one model to another, as we do. Moreover, as is common, Ferrando et al. express the information content implicitly and coordination explicitly, which limits flexibility. Ferrando et al. [2017] devise techniques for the runtime verification of protocols; here, we focus on static verification.

BSPL (Blindingly Simple Protocol Language) [Singh, 2011a; Singh, 2011b; Singh, 2012] and HAPN (Hierarchical Agent Protocol Notation) [Winikoff et al., 2018] mix information content with coordination, gaining flexibility and concurrency at the cost of unwieldiness. HAPN's state-machine model is compatible with our synchronous semantics. BSPL supports flexible asynchronous enactments, and we show how to compile Langshaw into BSPL to benefit from asynchrony.

Baldoni et al.'s (2014) 2CL specifies social meaning via commitments and temporal and relational constraints. 2CL does not model information or support asynchrony. Langshaw supports encoding social meaning and thus helps support accountability [Baldoni et al., 2023]. Its model enhances those of Custard [Chopra and Singh, 2016] and Clouseau [Singh and Chopra, 2020] via primitives to capture coordination.

CArtAgO [Ricci et al., 2009] undergirds multiagent programming frameworks such as JaCaMo [Boissier et al., 2013]. CArtAgO agents coordinate via tuple spaces [Carriero and Gelernter, 1989]. MAS programming models such as JaCaMo, Jason [Vieira et al., 2007], and Jade [Bellifemine et al., 2007; Bergenti et al., 2020] lack support for protocols. Ricci et al. [2019] argue for decentralization and scalability by combining MAS with the Web, but their interaction model is limited to HTTP (as on the Web). Langshaw give an abstract model for richer interactions, supporting asynchrony while based on a conceptually central social state (Section 3).

Traditional approaches rely on a "synchronizer" in the infrastructure to decide which actions occurred in what order. For example, in Weyns and Holvoet's (2004) model, when agents perform conflicting actions simultaneously, the environment picks the successful ones. Such a synchronizer is not a social entity. It may avoid an integrity violation by forcing an ordering, but only arbitrarily. In Langshaw, such decisions are handled socially-a good protocol would have the right saysos to avoid the mishaps of concurrency.

3 Langshaw Syntax and Informal Semantics

We first conceive a Langshaw-based multiagent system as operating one social artifact, the locus of its social state. Synchronous (and concurrent) social actions by (agents playing) roles in the system update this artifact. These updates respect local consistency (only different roles make take conflicting actions) and causality (an action may occur in a state only if the the information it relies on is present there). The social state is nothing but the set of such (performed) actions. The purpose of a Langshaw protocol is to specify such a system. Enacting the protocol means updating the social state.

Listing 1 illustrates Langshaw's syntax (Table 1); we use it to explain how a protocol is enacted. As shown, the Purchase protocol specifies roles SELLER, BUYER, and SHIPPER.

Lines 4:-10: specify social actions, each to be performed by a role; each action specifies one or more attributes (to capture its meaning), including one or more key attributes to uniquify instances. For example, BUYER may attempt the action RFQ by providing bindings (values) for ID and item and SELLER may attempt Quote by providing bindings for ID, item, and price. Each Action is reified in an implicit action attribute, which is bound if and only if that action has

Listing 1 Purchase in Langshaw.

1: Purchase / / Name of t he p r o t oco l 2: who Buyer , Se l l e r , Shippe r / / r o l e s 3: what ID key , Re j ec t or De l i ve r / / Comp l e t i on 4: do / / How t o change t he s o c i a l s t a t e 5: Buyer : RFQ( ID , i tem ) 6: S e l l e r : Quote ( ID , i tem , p r i c e ) 7: Buyer : Accept ( ID , i tem , pr i ce , add r e s s ) 8: Buyer : Re j ec t ( ID , Quote ) 9: S e l l e r : I n s t r u c t ( ID , Accept , i tem , address , f ee ) 10: Shippe r : De l i ve r ( ID , I n s t r u c t , i tem , add r e s s ) 11: sayso / / Soc i a l a u t h o r i t y over what 12: Buyer > S e l l e r : i tem 13: S e l l e r > Buyer : p r i c e 14: Buyer : add r e s s 15: S e l l e r : f ee 16: nono / / What p a i r s a r e i ncompa t i b l e 17: Accept Re j ec t 18: Re j ec t De l i ve r 19: nogo / / What a c t i on s p r even t ano t he r 20: Re j ec t -/> I n s t r u c t

been instantiated for the specified key bindings. When an action includes such an attribute, it indicates a reliance on the first action. For example, Reject applies to an instance of Quote. Accept could include Quote but item and price make its meaning clearer.

Attributes are defined only in reference to their keys: it makes no sense to talk of an item without its ID. Therefore, we assume that if an attribute occurs in two actions, their keys overlap and their intersection uniquely determines that attribute. For a key attribute, a role may either generate a fresh binding or reuse a previous binding from the social state. For any other attribute, if it is bound in the social state relative to a key binding, a role must use the same binding relative to that key. For example, in a social state with RFQ with some ID and item, a Quote or an Accept with the same ID must contain the same item. If no such binding exists, the role may generate a fresh binding for that attribute only if it has sayso over that attribute, as Line 11: and those following illustrate. For example, BUYER and SELLER can both generate item.

Attempts may be concurrent. When an agent attempts multiple actions, their bindings must be consistent with each other and the social state. For example, BUYER may concurrently attempt several RFQs, each with a distinct binding for ID. When multiple agents attempt actions concurrently, the agents need not be consistent with each other, just within each agent's actions and between the agent and the social state. For example, BUYER and SELLER may concurrently attempt an RFQ and Quote by generating the same binding for ID but different bindings for item (since they both have sayso over item). In Langshaw, the saysos over the same attribute must be prioritized over agents (indicated by >): here, by Line 12:, BUYER's sayso (being ranked higher) dominates. Consequently, its attempt succeeds (updates the social state) whereas SELLER's attempt fails (is a noop).

If only one agent attempts any actions, then all its attempts succeed and become part of the social state. If two or more agents attempt actions, exactly those of their collected attempts succeed where for each attribute not already bound in the social state, the attempting role has the highest sayso of all the roles concurrently attempting to produce a binding for that attribute. When attempts dominate each other (on different attributes), neither affects the social state. For example, if BUYER and SELLER concurrently attempt Accept and Quote by each generating item and price for the same ID, both attempts fail because BUYER's sayso dominates for item whereas SELLER's sayso dominates for price.

Line 16: and those following specify pairwise conflicts between actions. Accept and Reject conflict, meaning that they are mutually exclusive for the same bindings of ID. But since they are both actions of BUYER, it can choose either one.

Line 19: and those following specify an asymmetric conflict. Once Reject is in the social state, Instruct may not be performed. Importantly, Instruct may precede or occur simultaneously with Reject. This constraint is not needed in Purchase but we insert it to explain the construct.

Consider safety. Concurrent conflicting attempts by two agents can succeed, resulting in an inconsistent social state. A safe protocol prevents such attempts. Purchase is safe. Accept and Reject are both actions of BUYER, which means that if BUYER does one, it cannot do the other. Reject and Deliver are actions of BUYER and SHIPPER, respectively, but there is no social state in which both can be attempted concurrently. To do Deliver, SHIPPER needs to know the binding address, which can only happen if BUYER does Accept, which rules out Reject because it would be a local conflict at BUYER.

Let protocol Unsafe Purchase be obtained from Listing 1 by omitting Line 17:: thus, both Accept and Reject may occur. Suppose Accept has occurred, followed by Instruct. Now the social state is such that Reject and Deliver may both be attempted concurrently by BUYER and SHIPPER, respectively. Both BUYER and SHIPPER will succeed, thus violating the specified nono between Reject and Deliver.

Consider liveness. Line 3: gives a completion criterion for Purchase's enactments as a list of attributes or disjunctions of attributes; one or more of which are designated ⌜key⌝ and distinguish enactments. Specifically, it says that an enactment of Purchase, as identified by a binding for ID, is complete when a binding exists for either Reject or Deliver.

A protocol violates liveness if at least one of its enactments fails to complete. Purchase has two alternative branches for an enactment, one ending with Reject and the other ending with Deliver. Thus, on each branch, Purchase's completion criterion is satisfied, which means Purchase is live. Nonliveness could result from too little sayso or where the saysos induce a cyclic information dependency between the actions.

4 Formal Semantics

Semantic tableaux [Fitting, 1999] are a computational representation for proofs. Each node is a social state of the system, and the transitions are the successful concurrent actions attempted. Each tableau captures all possible enactments of a protocol: one per branch beginning from the root. Our semantics (Figure 1) is framed as inference rules to derive all possible transitions. Section 5 gives heuristics to produce a small tableau, i.e., a tractable model of a protocol.

Figure 1 lists the inference rules for our semantics, based on propositional logic. Below, m is an instance x: m[⃗a] where ⃗a is its entire set of attributes. We write x: m[⃗k, ⃗ p] or m[⃗k, ⃗ p] to mean role x performs m with attributes ⃗ p and key attributes ⃗k ⊆ ⃗ p. We omit the role where it is clear. S captures the social state. Yx,y a means x has higher sayso over a than y (both x and y have sayso). Yx a means x has sayso over a of whatever priority. Braces {} capture sets. Subscripts on sets and operators capture the obvious indices and ranges. An instance mi[ ⃗ ki, ⃗ pi] fits m[⃗k, ⃗ p] if and only if their common key attributes have the same bindings, i.e., mi[⃗ ki ∩⃗k] = m[ ⃗ ki ∩⃗k].

In Z-SOCIAL, Z captures what bindings can be inferred from the social state relative to a (potential or actual) message instance. For an instance m[⃗k, ⃗ p], the bindings of its attributes occurring in a fitting instance in the present social state can be inferred (i.e., are known). Z-SUBSET and Z-UNION state that Z bindings are closed under subset and union.

In ATTEMPT, an instance is attemptable by x if (1) it includes any bindings already established (for the key) in the social state and (2) x has sayso over the remaining attributes.

In ABIDE, an instance abides by another if: if the bindings of their common key attributes agree, then the bindings of all their common attributes also agree. Any nono and nogo constraints are ignored here and captured in FEASIBLE.

UNSOCIAL-M states that an instance is unsocial (i.e., socially inconsistent) if there is an instance in the social state with which it does not abide. UNSOCIAL-N states that an instance is unsocial if an instance in the social state has a nono or a nogo (asymmetric) constraint toward that instance.

FEASIBLE-1 states that an instance is feasible if (1) it is attemptable and (2) its attribute bindings are not inconsistent with the social state. In FEASIBLE, a set of instances is feasible if each instance is feasible and for each pair of instances performed by the same role, they are not related by a nono and each instance in a pair abides by the other. This is a crucial design decision in Langshaw: Feasibility avoids only local

Z-SOCIAL S mi[ ⃗ ai] mi[⃗ ai] fits m[⃗a] Z(m[⃗a], ⃗ ai ∩⃗a) · · · · · · · · · · · · · · · · · · · · · · · · · · · Z-SUBSET Z(m[⃗a], ⃗ qi) ⃗q ⊆ ⃗ qi Z(m[⃗a], ⃗q) · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · Z-UNION {Z(m[⃗a], ⃗ qi)}ni=1 Z(m[⃗a], ∪ni=1 ⃗ qi) · · · · · · · · · · · · · · · · · ATTEMPT Z(m[⃗k, ⃗ p], ⃗q) ¬Z(m[⃗k, ⃗ p], ⃗y) Yx⃗y attemptable x : m[⃗k, ⃗q ∪ ⃗y] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ABIDE mi[ ⃗ ai] fits m[⃗a] → mi[ ⃗ pi ∩⃗ p] =m[ ⃗ pi ∩⃗ p] mi[ ⃗ ai] abides m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · UNSOCIAL-M S mi[ ⃗ ai] ¬mi abidesm unsocial m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · UNSOCIAL-N S mi[ ⃗ ai] mi[⃗ ai] fits m[⃗a] nogo(mi, m) ∨ nono(mi, m) unsocial m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · FEASIBLE-1 attemptablem[⃗a] ¬unsocialm[⃗a] feasible m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · FEASIBLE {feasible xi : mi[ ⃗ ai]}ni=1 ∧xi=xj ¬ nono(mi, mj ) ∧ mi abides mj feasible{xi : mi[⃗ ai]}ni=1 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · DOMINATES mi[ ⃗ ai] fitsm[⃗a] p ∈ ⃗ ai ∩⃗a ¬Z(m[⃗a], p) Yxi,xp xi : mi[⃗ ai] dominates x : m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · JOINT feasible{mi[ ⃗ ai]}ni=1 ∧i̸=j¬mi dominatesmj jointly-feasible{xi : mi[⃗ ai]}ni=1 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · COMMUNICATION jointly-feasible{mi[ ⃗ ai]}ni=1 S xi : mi[ai]ni=1

incompatibilities. A protocol may be incorrect (e.g., unsafe) because of nono conflicts across roles. Since such errors cannot be avoided in a decentralized architecture, proper saysos are essential in a protocol that remains correct in asynchrony.

DOMINATES captures that mi dominates m if they have the same bindings for their common key attributes, a common unbound attribute p, and xi has sayso priority on p over x. (Thus, mi and m can dominate each other.) Dominance goes away once the conflicting sayso attribute (y above) is bound.

JOINT states that a feasible set of instances whose members do not dominate another is jointly feasible. If mi and m dominate each other, at most one can be part of a jointly feasible set. Note that joint feasibility is closed under subsets.

4.1 Generating Enactments from a Tableau

The preceding rules (dotted lines) show inference within a single social state: no S assertions are inferred, hence no state change. COMMUNICATION (solid line) shows the progress of time. A set of jointly feasible actions may be concurrently performed and the resulting social state records each of the actions as having occurred via S assertions.

A tableau begins from a root node-no S assertion. Any action there relies entirely on its performer's sayso. Under COMMUNICATION, each jointly feasible set forks a tableau branch. Where a branch terminates (i.e., at a state with no more feasible actions) forms a unique history.

4.2 Verifying Correctness Properties

Properties of interest, e.g., liveness and safety, are concerned with the reachability or otherwise of a state through an enactment. These properties are expressed via propositional combinations of the actions (and attributes). We assert a property at the root. A consistent branch that ends provides an example of the property at the root. A branch that hits a contradiction is closed; a tableau closes if all its branches close, which indicates the property is inconsistent and its negation is proved.

For liveness, we derive a formula from its what line-for the simple case, this means each protocol attribute becomes bound. To this end, we expand the social state to include bound attributes. For example, from SDeliver we can infer S ID and S item. A liveness violation occurs precisely when at least one of the attributes remains unbound. For example, in Listing 1, ¬ S ID ∨ (¬ S Reject ∧ ¬ S Deliver). A consistent branch is a counterexample since our formula is negated. But if every branch closes, liveness is established.

For safety, an integrity violation is when two actions of different performers with a nono constraint occur. In Listing 1, Reject and Deliver are such actions. A safety violation occurs for any such pair of actions. The negation of this property means that safety is preserved. We place the negated property, ¬SReject ∨ ¬SDeliver, at the root of the tableau. If any branch of the tableau closes, i.e., runs into a contradiction, we determine that safety is violated.

Theorem 1. Liveness and safety properties based as above on the what and nono parts of a protocol are verified by negating and checking for contradiction.

Argument. Follows from the construction of the tableau.

5 Reducing the Tableau

A tableau produced naively would include a branch for every jointly feasible set of actions at a state (node), leading to an exponential explosion of mostly redundant information. If we take the branches as individual actions, we will end up unrolling every feasible interleaving of the actions, also leading to an exponential explosion. How can we effectively reduce that redundancy? Our idea is to consolidate branches where possible and retain enough (heuristically, typically a few) branches to cover all semantically distinct possibilities.

5.1 HowActions Relate in a Protocol

Three cases are relevant. First, mutually unrelated pairs of actions may occur in any combination or order. We can discard all but one branch in which they are performed: a single-shot concurrent performance would lead to a shallower tableau, but any arbitrary interleaving would produce the same social state. Second, where one action enables another, the tableau would simply unfold such that an action would not become attemptable unless the right S assertions were present.

Third, where two actions may interfere with each other, we must include enough branches in the tableau so that each alternative is included. We capture potential interference as hampers below. If an action m1 may disable m2 (as based on a nono or a nogo) or prevent its concurrent performance (as based on sayso priority), we must include both possibilities with m1 or m2 going first and the other action being disabled or allowed later. We must recognize such cases even if one of the actions is not presently enabled and make sure we do not prematurely eliminate it. Figure 2 formalizes this reasoning.

In ENABLE, action xi : mi enables action x: m if mi is a potential precursor to m. That is, x lacks sayso on some attribute p of m that is not established from the social state (i.e., ¬Z(m[⃗a], p)) but xi has sayso on p and p appears in mi. Action mi enables action m if there is a chain of one or more direct enablements frommi to m. CHAIN expresses that enablement is transitively closed.

Action mi may hamper action m in two ways. The first case is if there is a nono or a nogo assertion involving mi and m. Accept and Reject and Reject and Deliver are examples. BLOCK captures this case. The second case is when xi has priority over x for an attribute p that is not yet established in the social state, exactly as specified by dominates. Quote and Accept is an example pair. DELAY captures this case.

FUTURE extends hampers to accommodate future (potential) interference. Action mi hampers action m if mi hampers action mj and m enables mj.

5.2 Computing Jointly Feasible Sets of Actions

Identify all feasible actions at a state. Next, group these actions into jointly feasible sets, reflecting two intuitions.

First, [Colors] when an action hampers another, the tableau must include both orders and maximally group nonhampering actions to reduce its size. To this end, create a graph whose vertices are the feasible actions and an edge indicates one hampers another. A coloring [Br´elaz, 1979] finds sets of vertices with no edge between them. Each set is jointly feasible (no action in a set hampers another), but maximality maps to minimum graph coloring, which is NP-Hard. We apply Br´elaz's polynomial-time approximation to compute Colors.

Second, [Concs] when an action hampers another, the two can be performed concurrently if they have different performers, there is a nono between them (nogos are OK), and neither performer dominates the other on some unbound attribute that is common to the actions. This gives the set Concs.

We construct a reduced tableau by including branches whose action sets are in Colors ∪ Concs.

Theorem 2. A reduced tableau is closed for a property constructed from Boolean combinations of S assertions if and only if the full tableau is closed for that property.

ENABLE mi[ ⃗ ai] fitsm[⃗a] ¬Z(m[⃗a], p) Yxi p ¬Yx p p ∈ ⃗ pi ∩ ⃗ p xi : mi[⃗ ai] enables x: m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · CHAIN mi[ ⃗ ai] enables m[⃗a] m[⃗a] enables mj[ ⃗ aj ] mi[ ⃗ ai] enables mj[ ⃗ aj ] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · BLOCK mi[ ⃗ ai] fits m[⃗a] nono(mi, m) ∨ nogo(mi, m) xi : mi[⃗ ai] hampers x: m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · DELAY xi : mi[⃗ ai] dominates x: m[⃗a] xi : mi[⃗ ai] hampers x: m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · FUTURE mi[ ⃗ ai] hampers mj [ ⃗ aj] m[⃗a] enablesmj[ ⃗ aj ] mi[ ⃗ ai] hampers m[⃗a] · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Argument. If: All branches in a reduced tableau are jointly feasible and occur in the full tableau. Only if: A branch closes based on the S assertions on it. Since the nogo and sayso constraints are incorporated into the tableau construction of Figure 1, the only closures (contradictions) observed on a branch pertain to nono constraints. Suppose the reduced tableau lacks an equivalent branch. By Concs, it must include branches for the nono constraints, let Sm be the first assertion that it does not include. Therefore, it must include an action Sm′ that disables Sm. By our coloring construction, that means Sm should have been in a different color from Sm′ . Therefore, there is a branch including Sm on which no Sm′ precedes it. Hence, we have a contradiction.

Theorem 2 is important because it means all verification of properties based on S (including safety and liveness, as seen in Section 4.2) can be carried out on a reduced tableau.

6 Compilation into Asynchronous Protocols

For concreteness, we adopt BSPL for specifying asynchronous messaging protocols. As Listing 2 shows, a BSPL protocol lists roles, a completion criterion, and one or more messages. Each message specifies information dependencies via adornments ⌜in⌝ , ⌜out⌝ , and ⌜nil⌝ . Each role has a local state and may send a message only if it is compatible with its local state. Specifically, let m be a message schema x ↦→ y : m[⃗ pI , ⃗ pO, ⃗ pN], where ⃗ pI , ⃗ pO, ⃗ pN are sets of its parameters adorned ⌜in⌝ , ⌜out⌝ , and ⌜nil⌝ , respectively. An instance of m is a message that has bindings only for the ⌜in⌝ and ⌜out⌝ parameters; x may send an instance of m only if the bindings of the ⌜in⌝parameters are known (already present in its local state), bindings of the ⌜out⌝ parameters are unknown (but added to the local state upon sending), bindings of the ⌜nil⌝ parameters are unknown (and not added to the local state). For example, to send an Accept, BUYER must know ID and item and not know price. Moreover, Accept and Reject

Listing 2 A simple protocol to explain BSPL constructs.

1: Accept -Re j ec t / / P r o t oco l name 2: r o l e s B, S / / r o l e s Buyer and S e l l e r 3: pa r ame t e r s out ID key , out done / / compl e t i on c r i t e r i o n 4: S ↦→ B: Of f e r [out ID key , out i tem , out p r i c e ] / / Message 5: B ↦→ S : Accept [ in ID key , in i tem , in pr i ce , out done ] 6: B ↦→ S : Re j ec t [ in ID key , in i tem , in pr i ce , out done ]

are mutually exclusive because each includes done as ⌜out⌝ . Figure 3 shows Singh and Christie's (2021) tableau-based asynchronous semantics of BSPL. Each tableau branch (sequence of message send and receive events) is an enactment. Kx captures that x knows specified parameter bindings. Lx means x sent or received a message, simulating a channel. Initially, each role knows no bindings. What is known to each role grows monotonically: the bindings are immutable, and each message sent and received adds to a role's knowledge.

In SEND, an instance of x ↦→ y : m[⃗ pI , ⃗ pO, ⃗ pN] is enabled for emission by x if and only if x knows ⃗ pI but does not know ⃗ pO or ⃗ pN. Concomitantly with the emission, the sender produces and comes to know the bindings for ⃗ pO. In RECEIVE, a message from x to y is enabled for reception by y if and only if x has (previously) sent that message. Concomitantly with reception, y comes to know the bindings for ⃗ pI and ⃗ pO.

Each tableau branch takes up one of the allowed observations (emission or reception of a message) and maps to an enactment. A tableau contains all possible observation orders.

6.1 Compiling Langshaw

We now describe how to compile Langshaw specifications into BSPL in a manner that respects the demands of asynchrony. Langshaw roles map to BSPL roles, attributes to parameters, actions to messages, saysos to data flows, and nonos to integrity constraints. Resolving the saysos and nonos requires parameters and messages not present in Langshaw.

Completion Requirements. Langshaw completion requirements are a sequence of disjunctive clauses. Each attribute (atom in a clause) yields a BSPL parameter of the same name. Each disjunction is replaced by a parameter representing the achievement of any of its terms. When generating protocol messages, we append messages that are enabled when any of the clause terms is completed to notify each role that the clause is satisfied.

Listing 3 (full version online; URL below) shows some lines generated from Purchase. The what line yields two

Listing 3 Purchase: Completion requirements.

1: pa r ame t e r s out ID key , out done0 2: . . . 3: Buyer ↦→ S e l l e r : Re j ec t #done0 [ in ID key , in Re j ec t , out done0 ]

clauses. ID maps to BSPL parameter ID. And, Reject or Deliver maps to done0. Each role gets a message for each of its actions. We also create messages to convey important facts to other roles: e.g., Reject maps to messages indicating that the primary Reject has been sent and the what line satisfied.

Generating Messages from Actions. Each action yields a BSPL message schema, whose sender is the performer and whose receiver is a role that needs the content of the message.

• Each attribute (including the attributes reifying the actions) becomes a message parameter.
• The adornment of each parameter depends on whether the action's role (message's sender) has sayso.
• Each combination of parameter adornments yields a different morph, i.e., message schema variant.
• The above possibilities are constrained via a series of filters to remove incorrect and redundant combinations.

Modeling Sayso in BSPL. We model sayso in BSPL via delegation. That is, since BUYER has priority over SELLER to bind item, it must either bind item, or bind a newly added delegation parameter (item@Seller) to empower SELLER to bind it. Conversely, SELLER cannot bind item until BUYER has delegated that authority. Figure 4 illustrates the delegation pattern with message sequence diagrams. The pattern is inherently asymmetric: traditionally the priorities are arbitrary [Mattern, 1990] whereas our priorities have a social basis.

Filtering Out Improper Schemas. The above steps produce redundant or incorrect morphs. We apply a series of filters to exclude such cases. For instance, reasoning about causality is needed to ensure enactability and reasoning about priority to avoid race conditions.

Conflicts and Data Flow. To generate BSPLmessages, we model a nono constraint by adding ⌜nil⌝ parameters to each of the conflicting messages. For example, in Purchase, the Reject and Deliver actions conflict, so we add nil Deliver to each generated Reject morph, and nil Reject to each generated Deliver morph, as shown in Listing 4. Likewise, we model a nogo constraint (a ̸→ b) by placing a ⌜nil⌝ parameter on the message for the disabled action, i.e., b[. . . ⌜nil⌝ a]. This approach echoes the idea of disabling an action until information is received to proceed [Singh, 1996].

Next, we model the protocol's data flow by specifying the recipients of each message schema. A role can observe any attribute (including an action) that features in an action it can perform and any attribute present in the what line of the protocol. Information is shared at the granularity of actions, not attributes piecemeal, so we determine which roles can see what action. We generate a separate message schema for each of the desired data flows. Since BSPL does not support multicast, we emulate any multicast with separate messages. The first message schema (to one role) has the relevant parameters as ⌜out⌝ ; message schemas to other roles include the same parameters as ⌜in⌝ . As described above, every message is given a least one ⌜out⌝ parameter.

Theorem 3. For any asynchronous messaging enactment produced by a BSPL protocol generated through our method, there is a corresponding synchronous enactment produced by the Langshaw semantics.

Argument. We derive messages using Langshaw's semantics. Each action maps to a message and each attribute to a parameter with the constraints (nono, nogo, and sayso dominance) via crafted ⌜nil⌝parameters. We filter the schemas according to rules derived from the delegation model of sayso, i.e., constraining the available actions according to DOMINATES. Thus, the generated BSPL protocol allows moves corresponding to any Langshaw action. Due to our filters, it cannot make any moves prevented by the sayso constraints. Although Langshaw allows concurrent actions and BSPL does not allow multicast, the effect of multicast is achieved through additional messages: such messages can be delayed, as allowed by the BSPL's asynchronous semantics, but not disabled. We capture Langshaw's disjunctive completion requirements via messages producing a designated parameter.

6.2 Empirical Results

We implemented our verifier for Langshaw protocols in Python. Table 2 shows the performance (averaged over 10 runs) of testing liveness (including the time for constructing a tableau) for several protocols from the literature. The times for safety are similar, though slightly faster in most cases.

The results show that the Langshaw verifier is effective. The node and branch numbers are sometimes fractions, due to unordered sets in the implementation randomizing the selection and thus producing different numbers of nodes and branches in different runs of the verifier.

7 Discussion: Conclusion and Perspectives

Specifying coordination constraints for MAS can be nontrivial. Langshaw's abstractions force a designer to think of coordination in social terms. The synchronous semantics provides a simplified model for a MAS engineer while maintaining the realism and power of asynchrony in that conflicting action attempts by multiple agents may succeed though they violate a nono constraint. Thus, it does not obviate correctness concerns arising in asynchrony and thereby facilitates translation to an asynchronous protocol.

For now, the best approach to implement agents to participate in Langshaw protocols is to (1) verify a Langshaw protocol; (2) compile it to BSPL; and (3) apply a BSPL programming model such as Kiko [Christie et al., 2023]. Research into native programming models for Langshaw is needed. Both BDI-based and the newer hypermedia-based programming models [Vachtsevanou et al., 2023] are promising as direct programming models for Langshaw because they naturally complement Langshaw's information orientation.

The engineering MAS community has long debated the relative merits of synchrony and asynchrony [Singh, 1999]. Langshaw bypasses some of the debate by showing that a synchronous semantics can be a pathway to asynchrony. Popular approaches provide constructs such as artifacts [Ricci et al., 2009] or the environment [Weyns et al., 2007] that provide a unitary view of the state of a MAS. Though they may be accessed through low-level asynchronous means, their unitary view reflects a central point. Blockchain provides a shared state between otherwise independent entities [Mendling et al., 2018]. Langshaw's synchronous semantics provides a basis for interaction governed by sayso, which is more conducive to business meaning [Christie et al., 2021] than arbitrary ordering, and enables maximal concurrency given a protocol.

Theoretical studies of protocols, e.g., [Mallya and Singh, 2007; Ferrando et al., 2019], may need to be revisited in light of Langshaw. Further, the problem of verifying protocolbased agents [Baldoni et al., 2006] remains largely unaddressed for information-based representations.

Online supplement. The code and all examples are available online at https://gitlab.com/masr/langshaw

Acknowledgments

Thanks to the anonymous reviewers for helpful comments. Thanks to the NSF (grant IIS-1908374) and EPSRC (grant EP/N027965/1) for support.