Formalizing commitments using the event calculus and RuleML

Abstract

Smart Contracts enable the automated execution of exchanges on the blockchain. From an ontological perspective, smart contracts create and automate the fulfillment of social commitments between actors. Whereas traditional deontic logic is used to make a legal determination in contractual multi-actor interactions, this paper focuses on the consequences of these actions resulting from that determination, thereby shifting the focus from monitoring to execution. The interactions between actors and the consequences in terms of commitments have not yet been formalized for smart contracts. The perspective of smart contracts is interesting, since they are considered to be autonomous agents, able to generate automated actions. We use the Event Calculus as a formal logic to represent and reason about the effects of these automated actions and the resulting commitments. Since the Event Calculus deals with local events and the consideration of time, this approach enables the uniform representation of commitments, including their operations and reasoning rules.

Keywords

Blockchain Smart Contracts commitments the Event Calculus

1. Introduction

Since the early days of computing, paper-based (traditional) contracts have been digitized rapidly, aiming to reduce repetitive actions in drafting, updating and standardizing its basic elements. In the internet age, digital contracts are used to support e-commerce exchanges. In the field of AI, formal contracts have been studied as an important building block of multi-agent societies (Weigand et al., 2002). Together with smarter digitization and artificial intelligence, smart contracts using blockchain technology are yet another approach to innovate the legal sphere by subverting existing hierarchies and disrupting incumbent business models, for instance in Estonia (Jalakas, 2018). In contrast to both traditional- and digital contracts, smart contracts are considered to be intelligent as they have the robotic ability to execute logic by themselves. They act as a computer program that support an existing legal contract or even expresses the contents of a contractual agreement including the implementation of that content using blockchain technology (Governatori et al., 2018), using triggers provided by the users or extracted from the environment (Weigand, Blums and De Kruijff, 2018) or other smart contracts. Smart contracts are (alleged to be) predictable by design, as they automatically execute predefined actions when certain conditions are met, whereas traditional contracts are designed to be symbolic, are (only) observant (Norta, 2016) or lack robustness (Chopra et al., 2011).

1.1. Commitment based smart contracts

By default, a smart contract suffers shortcomings like its approach towards autonomy and endogenous nature, that undermine its usefulness and impose risk to the parties involved (Singh and Chopra, 2018). These shortcomings are alleged to be overcome by designing the smart contracts in alignment to the following considerations; (1) the smart contract is violable, verifiable (through public record) and validated, (2) the transactional design should include conflict management and dispute resolution, (3) the contract must be enforceable and (4) the enforcement (governance) is automated by coded actions. In our view, it is essential to recognize that these actions conform to the commitments in the smart contract, defined as the willingness to make a particular rule (convention) or norm (moral and social) the motive for actions. Rules involve expectations that oneself and other people might have towards behavior (Singh and Chopra 2018), while norms are (deontic) rules with a normative expectation towards conditional obligation and conformity (to the contract).

Deontic logic is characterized by the distinction between what is the case and what should be the case; between the actual and the ideal (Nute, 2000). The violability, verifiability and validity of commitments is measured by comparing the actual extent of fulfilment of commitments versus the defined commitments through reasoning on obligations and permissions, based on the rules of engagement (De Kruijff and Weigand, 2017a; 2017b), or ‘compact’ as described by Singh and Chopra (2018), conforming to the Ricardian Contract Triple of prose (similar to rules of engagement), parameters and code (De Oliveira et al., 2017). Besides fulfilment (or satisfied), one should also consider partial- and non-fulfillment of commitments as viable outcomes of interactions between agents. In contrast to standard deontic logic, we do not recognize partial or non-fulfilments to be contract violations per se. The deontic determination is important for legal soundness, but it does not solve the problem between the agents, nor does it define rules to follow going forward, which is important from a business point of view.

First generation smart contract languages were on low operational level. However, it is important to minimize the distance between the specification of the legal effects and their executable implementation by adopting a declarative language for the smart contracts (Governatori et al., 2018).

It is predicted that contractual intelligence will increase significantly in the years ahead (Rich, 2018). We predict that smart contracts, as autonomous agents, have the ability to make contracts more robust by extending deontic principles through monitoring the extent of fulfillment of the commitments, executed through the stages of the commitment lifecycle (explained in detail later). We earlier introduced the concept of Commitment Based Smart Contracts (CBSC) for that purpose (De Kruijff and Weigand, 2017b). We claim that (1) once the extent of fulfilment of commitments is monitored through on-chain analysis, (2) parts of the execution logic could be delegated or assigned to other actors (smart contracts or human agents), during the commitment lifecycle, while the rules of engagement remain immutable. Flexibility of executive control is important in complex and/or long-lasting eCommerce contracts, which are considered to be incomplete by design (Herold, 2010; Krasa and Williams, 2000). For example, a property seller may delegate the power to legalize the sales transaction to either a Notary (semi-autonomous) or a digital Notary on the blockchain (autonomous agent). Hereby, the blockchain ecosystem acts as a multi-agent system (MAS) that consists of smart contracts that consist themselves of bundles of reciprocal commitments, governed by rules of engagement and orchestrated by semi-autonomous- (human agents through wallets) and autonomous agents (smart contracts). We hereby consider smart contracts to be agents themselves. They are considered to be Turing-complete systems that contain arbitrary and sequential logic with the ability to retain states internally. That is, they have memory. Since sequential logic has the ability to inject state into a Turing machine (e.g. last week’s temperature), semi-autonomous smart contract owners can also delegate (parts of) the execution of logic to the smart contract itself. For example, a smart contract may execute a function that signals an event that complies to predefined rules of engagement in that contract. The resulting new transaction by the smart contract is recorded on the ledger on behalf of the smart contract itself (as an autonomous action) and not by the original actor. The ability to assign or delegate actions to a smart contract or other participants requires us to have a thorough understanding of the effects of these automated actions, since logic on the blockchain is immutable to change and intervention, posing a financial and legal risk to all actors involved if implemented or intended wrongly (Singh and Chopra, 2018).

1.2. Problem statement

There are various reasons to incentivize the delegation of control to a (semi)autonomous agent. For example, a smart contract owner may want to enforce neutrality between enterprises in a similar industry that do not trust each other, or mitigate costly opportunistic behavior between firms and consumers. In our view, under these circumstances, the notion of commitments becomes paramount. Commitments contain a mechanism producing consistent human behavior, ideally resulting in strong (contractual) commitments to increase the efficiency in exchange relationships (Becker, 1960). Smart contracts express the social or organizational relationship between two agents (Levy, 2017) through a state. Therefore, commitments between MAS agents are an important basis for organizing their interactions (Yolum and Singh, 2004), emphasizing the importance of formalizing the events that create and/or manipulate these commitments over time. Yet, there is insufficient up-to-date knowledge about the potential for (semi)autonomous assignment and delegation of smart contract actions, while this knowledge may create the ability to fully leverage the strength of a ledger.

1.3. Research objective

This paper aims to contribute in three ways. First, we aim to formalize the representation and reasoning of the effects of commitments and automated actions by smart contracts that result from them during the commitment lifecycle, with specific regards to creation, manipulation and fulfillment. Second, we introduce flexibility to the process of assigning or delegating control and responsibility roles inside an immutable smart contract, while adding to the robustness of the contract. Third, we translate these commitment formalizations (as rules and norms) into an executable language. Hereby, we explicitly define commitments in our contract, since, in our view, a smart contract itself is nothing more than a collection of reciprocal commitments. We choose the Event Calculus (EC) to formalize and semantically extend our initial model (De Kruijff and Weigand, 2017a; 2017b) as the EC offers the right tools to create and manipulate commitments using business rules like condition- and time constraints through axioms. This is to prove the formal correctness of the model (verification). To demonstrate the executability of our conceptual model (as first step of validation), we translate these formal business rules into executable code using Reaction RuleML. Due to the importance of states and events, we use the Knowledge Representation ReactionRuleML specification (KR Reaction RuleML) for the task. To be more concise and to better represent CBSCs, we extend KR ReactionRuleML with specific commitment related syntax and semantics. By a way of practical evaluation, we finish this paper with an illustration using a real estate transaction.

2. Background

In line with Enterprise Ontology and Business Ontologies like COFRIS (Weigand, Blums and De Kruijff, 2018) and REA (De Kruijff and Weigand, 2017a), we conceptualize smart contracts as a bundle of interrelated commitments (together: a contract) among those parties who have signed it. The main objective of a contract for the contract agents is to fulfill a certain goal and to safeguard against undesirable outcomes, together referred to as contract robustness (Chopra et al., 2011). Contracts that are not robust may lead to transaction costs, expensive conflict resolution, or even a collapse of a transaction as a whole. According to the sociological account of Becker (1960), “commitments” are needed to explain a consistent line of activity and come into being when an individual brings in extraneous interests. The example used in this paper is specifically on “side bets”. These “side bets” are often a consequence of the actors’ participation in social interactions. A more abstract way of saying the same is that commitments penalize the individual in the case of inconsistent behavior, and that the penalty has its basis in the social community. Importantly, the assumed effect of commitments is consistency in behavior, and this contributes directly to contract robustness. As a result, the role of commitments for decent business transactions is essential. It is not surprising that commitments are basic in UFO-S, the foundational ontology of services. They are also included in UFO-C (ontology of social entities) as a kind of social moments, that is, “types of intentional moments that are committed by social actions (e.g., an interaction composed of the exchange of communicative acts)” (De Kruijff and Weigand, 2017b).

In 1986, Kowalski and Sergot provided an elegant way to logically represent changes of the world through actions, captured in a protocol, called the Event Calculus (Kowalski and Sergot, 1986). The Event Calculus enables the uniform representation of commitments, including its operations and reasoning rules about them (Yolum and Singh, 2004). The Event Calculus originates from the Situation Calculus (McCarthy and Hayes, 1981), but there is a conceptual difference between the two: the Situation Calculus deals with global states, whereas the Event Calculus deals with local events and the consideration of time periods. The latter is similar to the structure of a blockchain, whereby transactions that change the state of the ledger (actions) occur sequentially, based on situations (time or condition constraints) as defined in the smart contract. The Event Calculus, can be formalized by means of Horn clauses augmented with negation by failure (McCarthy and Hayes, 1981). Based on the Event Calculus, Yolum and Singh (2004) developed a declarative protocol specification by capturing the meaning of actions including intrinsic meanings through commitments. As a result, they defined operations to commit, manipulate and terminate (discharge, delegate, cancel) these commitments, centered on events and fluents. Fluents are properties that may have different values at different time points (states) and the entire lifecycle of a commitment. We consider fulfillments to be a state of a commitment fluent. Events manipulate fluents. A fluent starts to hold after an event occurs that can initiate the fluent. Similarly, it ceases to hold when an event occurs that can terminate the fluent. This paper aims to contribute in two ways. First, we aim to formalize the representation and reasoning of the effects of commitments and automated actions by smart contracts that result from them, with specific regards to creation, manipulation and fulfillment. Second, we introduce flexibility to the process of assigning or delegating control and responsibility roles inside an immutable smart contract, thereby adding to the robustness of the contract.

3. Conceptual framework

The conceptual model in this paper builds upon earlier work by de Kruijff and Weigand (2017a), where we separated the implementation choices for blockchain using three human abilities derived from Enterprise Ontology: performa, informa, and forma. The forma ability concerns the form aspects of communication and information. Production acts at the forma level are datalogical in nature: they store, transmit, copy, destroy, etc. data. The informa ability concerns the content aspects of communication and information. Production acts at the informa level are infological in nature, meaning that they reproduce, deduce, reason, compute, etc. information, abstracting from the form aspect. The performa ability concerns the bringing about of new, original things, directly or indirectly by communication. Communicative acts at the performa level are about evoking or evaluating commitments; these communicative acts are realized at the informa level by means of messages with some propositional content. We previously presented our conceptual model for smart contracts at the informa level, where we emphasized the infological blockchain domain ontology to accommodate COFRIS-related components at the performa level (Weigand, Blums and De Kruijff, 2018). At the infological layer, the notion of transaction has been refined to three aggregation levels: transaction, event and posting. In this paper we extend our infological ontology by including formalizations for commitments through Event Calculus. Event Calculus semantically extends our ontology by offering tools to commit and manipulate commitments. We first explain and present the Event Calculus extensions for commitments, and then we will map these formalisms to our infological ontology.

3.1. Commitment lifecycle

In line with Yolum and Singh (2004), new knowledge changes a state (in terms of fluents) by fulfilling (partial) or realizing (full) a commitment cover time through transactions on the SL. A commitment here is a conditional business relationship directed from a debtor to a creditor, and can be formalized as C(debtor, creditor, antecedent, consequent). The lifecycle of a commitment has been explained by Telang et al. (2012), we converted it to UML for simplicity reasons as depicted in Fig. 1.

Fig. 1.

The commitment lifecycle from (Telang, Singh and Yorke-Smith, 2012) converted to UML.

A commitment transitions from one state to another through the operations: commit, detach (antecedent holds), discharge (consequent holds), cancel, assign and delegate. A commitment can be in one of the following states: Null (before it is Committed), Existing (when it is initially Committed), Active (when it is initialized), Expired (when its antecedent becomes forever false, while the commitment was Conditional), Discharged (or Satisfied) (when its consequent is brought about while the commitment was Active, regardless of its antecedent), Violated (when its antecedent has been true but its consequent will forever be false, or if the commitment is cancelled when Detached), Terminated (when cancelled while Conditional or released while Active), or Pending (when suspended while Active). Active has two sub-states: Conditional (when its antecedent is still false) and Detached (when its antecedent has become true). A debtor may Commit, Cancel, Suspend, or Reactivate a commitment. A creditor may Release a debtor from a commitment.

Although the commitment lifecycle is the basis for our conceptual model, we do make an important adjustment by adding the option to delay initialization (or activation) of a commitment in order to prevent the existence of active commitments that have no chance to satisfy yet (falsely pending). For example, a commitment to consider offers on a piece of property, will only activate once offers have been made by buyers to satisfy that commitment. As a result, there may be a time gap between the creation and the activation of a commitment, whereby the activation could be considered to be a handshake between buyer and seller. During the creation of a commitment, the seller signals to potential buyers that he/she has the intention to transact, and the activation of the commitment by a buyer is a signal that this commitment to transact is consensual and correlated.

3.2. Exchange vs control commitments

Actions are realized by means of messages and are a conjunction of sub actions. Actions may either be predefined or committed on-the-fly by participants. Governatori (2005) recommends to predefine action logic explicitly for better monitorability of the contract. We introduce exchange- and control commitments to distinguish between commitments that are defining the economic transaction (are about the resource exchange) like creating, activating and satisfying and those that deal with the conditioning of the contract like delegating or assigning. From a speech act perspective, commitments are a structure to communicate meaning and intent between actors. This structure as presented by Van Reijswoud (1996), originating in the context of Dietz’s Enterprise Ontology (2006), distinguishes between a success- and a dispute or failure layer. The success layer contains the set of communicational moves to complete a transaction successfully. Transactions hereby follow the transaction paradigm that state that actors commit and execute actions that result in the creation of new facts. We consider the action events on this layer to address exchange commitments. Characteristic of the success layer is that the proposition of the transaction is never changed during its lifecycle nor the constraints. On the other hand, the discussion layer (also mentioned as failure and dispute layer) is concerned with the communicative acts for situations where this is or may not be the case. In the event of opportunistic behavior by actors or changed circumstances that require a change to the proposition after committing to bring about the original proposition, the transaction should be resolved in a new request or be closed altogether. We introduce control commitments to deal with the conditioning of a contract under these circumstances, like changes to the rules of engagement, delegation- and assignment of actors and violation. Once the transaction diverts from its path towards success, control commitments prescribe what should happen. Key to control commitments is that they allow to change elements of the contract by manipulating commitments through constraints, without changing the proposition of the transaction itself.

Table 1
Comparison between communication layers and commitments

Communication layers Commitments

Success layer Exchange commitments

Discussion layer Control commitments

Communication layers	Commitments
Success layer	Exchange commitments
Discussion layer	Control commitments

3.3. Conceptual model

Constraints consist of conditions that verify if an event happened (Happens) or if a commitment holds (HoldsAt). Whereas control commitments are more straight-forward, exchange commitments between agents are easier to predict when goals of the agents are known, since goals describe the state of the world that an individual agent is motivated to bring about (antecedent or consequent) (Telang, Singh and Yorke-Smith, 2019). We distinguish between the control and the responsibility role of an event. The control role is concerned with the execution of an event, without social responsibility. Responsibility means social responsibility but not necessarily execution. Roles are not set in stone and may change due to time- or conditional constraints. We consider two role transitions; (1) Delegation is concerned with the change of debtor, without changing anything else. Since the creditor and conditions are unchanged, the creditor remains socially responsible for the commitment; he delegates control of execution to the smart contract as in the case of a Notary or bank, for example. (2) Assigning is concerned with the change of creditor, without changing anything else. Even though the creditor changes, the new creditor becomes participant in bringing about the commitment. This may be the case when a house owner assigns the ownership transfer to a Notary, or in a future situation, to a smart contract.

Fig. 2.

Conceptual model commitment formalization using the event calculus.

3.4. Mapping between infological level and event calculus

Now that we understand the basic lifecycle of commitments, it is important to map this concept to our infological ontology. Hereby, the concept of Events, and Fluents are mapped to Transfers and Accounts, respectively (Weigand, Blums and De Kruijff, 2018), but the two conceptualizations have a slightly different focus. Whereas a transfer manipulates agnostic accounts (through inflow- and outflows), Events manipulate specific fluents through actions, namely commitments, by specific operations from the commitment lifecycle. On the other hand, in the infological model a transfer is conceived as inflow and outflow. To combine the two models, we have to restrict Transfers to specific commitment-manipulating actions and we have to specify these actions in terms of inflow and outflow.

The main concern with regards to reasoning about transfers in smart contracts, is that so far, there is a lack of standards for rules of engagement. The clauses and defaults that govern the transfers can be anything. By mapping the rules of engagement to Event Calculus axioms, the rules become a sound axiom system. A distinction must be made between the general Event Calculus axioms, generic commitment axioms and contract-specific rules. For example, it is a generic commitment axiom that only a debtor agent is allowed to discharge a commitment. Further, by allowing preconditions to be associated with the initiation and termination of properties, different commitments can be associated with communicative acts to model the communications among agents more concretely.

Fig. 3.

Mapping infology to the event calculus.

4. Manipulating commitments using the event calculus

The Event Calculus uses various predicates to reason about events. Based on the predicates and axioms presented in (Yolum and Singh, 2004) and Telang et al. (2012). We have modified the notation to e for events and c for commitments. The symbol ← denotes implication, as in Horn logic, ∧ denotes conjunction and ∼ denotes negation by failure. The time points are ordered by the < relation, which is defined to be transitive and asymmetric. We write a commitment as $C (x, y, p, q)$ where x is the debtor, y is the creditor and p and q are the antecedent and consequent respectively. When c is a commitment, debtor(c) yields the x, and similar to the other roles. We emphasize syntax (in bold) to highlight specific parts of a larger block of syntax. Before we explain the axioms that are required to create and manipulate commitments, it is important to distinguish between the various commitment types used in this paper, that have been identified by Yolum and Singh (2004). Base commitments (BC) written as $BC (x, y, p)$ are commitments from debtor x to a creditor y to satisfy condition p. This type of commitment is also known as an unconditional commitment. Likewise, conditional commitments are written as $CC (x, y, p, q)$ , whereby debtor x will bring about condition q to creditor y, once condition p is satisfied. In contrast to a BC, the behavior of a CC is slightly more complex. In line with the state knowledge update paradigm by McCarthy et al. (1981), a CC is terminated and subsequently reinitiated. In line with Yolum and Singh (2004), we then implement Foara and Colombetti’s (2004) definitions of conditional commitments, where a CC resolves into a new BC upon the realization of p. This new BC is committed to satisfy q. When a CC holds and an event happens that fulfils p, the CC is terminated and a new BC is being created. In the event when a BC does not satisfy p, it is considered to be a persistent commitment, written as $PC (x, y, G (p))$ (Yolum and Singh, 2004). According to the transaction paradigm by Van Reijswoud (1996), every fulfilment leads to the satisfaction (and termination) of a commitment, regardless of the length or size of the commitment. Realistically, there are very few examples where p is not satisfiable. Even in the event of a mortgage payment, which is a multi-year commitment to the bank, it will be satisfiable in the end. Every monthly payment can even be considered as an independent commitment, which it actually is once you carefully read the terms that come with a mortgage; it is a collection of repayments. Therefore, we consider persistent commitments to be similar to base commitments.

Table 2 summarizes the formalization rules and commitment type used in our protocol run. Commitments denoted as c can be either a BC or a CC.

Table 2
EC rules

R Explanation EC Notation Type Axiom Yolum and Singh (2004)

r1 Creation of a commitment that is not activated during the create event. Commit(e, x, c) ← Happens(e, t) Exchange 2

r2 Activation of a commitment or the creation of a commitment that is activated in the same event Activate (e, c, t) ← Happens(e, t) ˆ Commit(e, x, c) Exchange 2

r3 Termination of a BC that is fulfilled through p, whereby the BC does not originate from a CC Satisfy(e, BC(x, y, p), t) ← Happens(e, t) ∧ Discharge(e, x, BC(x, y, p)) Exchange 3

r4 Termination of a BC that is fulfilled through q, whereby the BC originates from a CC Terminates(e, CC(x, y, p, q), t) ← Initiates(e, q, t) HoldsAt(CC(x, y, p, q), t) ∧ Happens(e, t) Exchange 10

r5 Termination of a CC that resolves in a BC to provide q in a later event Commit(e, x, BC(x, y, q)) ← Happens(e, t) Exchange 9

Satisfy(e, CC(x, y p, q), t) ← Happens(e, t) ∧ HoldsAt (CC(x, y, p, q)) ∧ Activate(e, CC(x, y, p, q), t))

r6 Termination of a CC that resolves in a BC to provide q that is activated in the same event of satisfying the CC Activate (e, BC(x, y, q), t) ← Happens(e, t) ∧ Commit(e, x, BC(x, y, q)) Exchange 9

Satisfy(e, CC(x, y, p, q), t) ← Happens(e, t) ∧ HoldsAt (CC(x, y, p, q)) ∧ Activate(e, CC(x, y, p, q), t))

r7 The delegate operation that replaces the debtor of the commitment with agent z Commit(e, z, CC(⟨x, z⟩, y, p, q)) ← Happens(e, t) ∧ Delegate(e, x, z, CC(x, y, p, q)) Control 7

Cancel(e, x CC(x, y, p, q)) ← Happens(e, t) ∧ Delegate(e, x„z, CC(x, y, p, q))

r8 The assign operation that replaces the creditor of the commitment with agent z Commit(e, x, CC(x, ⟨y, z⟩, p, q)) ← Happens(e, t) ∧ Assign(e, y, z, CC(x, y, p, q)) Control 6

Release(e, y, cc(x, y, p, q)) ← Happens(e, t) ∧ Assign(e, y, z, CC(x, y, p, q))

R	Explanation	EC Notation	Type	Axiom Yolum and Singh (2004)
r1	Creation of a commitment that is not activated during the create event.	Commit(e, x, c) ← Happens(e, t)	Exchange	2
r2	Activation of a commitment or the creation of a commitment that is activated in the same event	Activate (e, c, t) ← Happens(e, t) ˆ Commit(e, x, c)	Exchange	2
r3	Termination of a BC that is fulfilled through p, whereby the BC does not originate from a CC	Satisfy(e, BC(x, y, p), t) ← Happens(e, t) ∧ Discharge(e, x, BC(x, y, p))	Exchange	3
r4	Termination of a BC that is fulfilled through q, whereby the BC originates from a CC	Terminates(e, CC(x, y, p, q), t) ← Initiates(e, q, t) HoldsAt(CC(x, y, p, q), t) ∧ Happens(e, t)	Exchange	10
r5	Termination of a CC that resolves in a BC to provide q in a later event	Commit(e, x, BC(x, y, q)) ← Happens(e, t)	Exchange	9
Satisfy(e, CC(x, y p, q), t) ← Happens(e, t) ∧ HoldsAt (CC(x, y, p, q)) ∧ Activate(e, CC(x, y, p, q), t))
r6	Termination of a CC that resolves in a BC to provide q that is activated in the same event of satisfying the CC	Activate (e, BC(x, y, q), t) ← Happens(e, t) ∧ Commit(e, x, BC(x, y, q))	Exchange	9
Satisfy(e, CC(x, y, p, q), t) ← Happens(e, t) ∧ HoldsAt (CC(x, y, p, q)) ∧ Activate(e, CC(x, y, p, q), t))
r7	The delegate operation that replaces the debtor of the commitment with agent z	Commit(e, z, CC(⟨x, z⟩, y, p, q)) ← Happens(e, t) ∧ Delegate(e, x, z, CC(x, y, p, q))	Control	7
Cancel(e, x CC(x, y, p, q)) ← Happens(e, t) ∧ Delegate(e, x„z, CC(x, y, p, q))
r8	The assign operation that replaces the creditor of the commitment with agent z	Commit(e, x, CC(x, ⟨y, z⟩, p, q)) ← Happens(e, t) ∧ Assign(e, y, z, CC(x, y, p, q))	Control	6
Release(e, y, cc(x, y, p, q)) ← Happens(e, t) ∧ Assign(e, y, z, CC(x, y, p, q))

The rule templates presented in Table 2 implement the axioms introduced by Yolum and Singh (2004), which are based on Telang’s et al. (2012) commitment lifecycle as illustrated in Fig. 1. Although we semantically modified these rule templates to be a better fit for e-commerce use-cases, they follow the commitment lifecycle logic as set out in Section 3.1. As an example of possible further development, we remark that r1 should be considered as a rule that compounds multiple rules in our workflow to relate commitments as they evolve. For example, the commitment to Relocate has a direct relation with the commitment to ConsiderOffers. It seems that the creation of a commitment as in r1 is never an isolated event. Therefore, once all the specific cases are listed, as e.g. in r6-8, the rule r1 may be superfluous. For r7 we remark that debtor x can be compounded as $⟨ x r, x c ⟩$ , consisting of $x r$ (responsible) and $x c$ (control), in order to track the change of role for x during delegation. After delegation by x to z, the debtor of the commitment is $⟨ x, z ⟩$ . Similarly, we remark for r7 that y can be compounded as $⟨ y r, y c ⟩$ , consisting of $y r$ (responsible) and $y c$ (control), in order to track the change of creditor role during assignment. Whenever we write x (or y) without compound specification, it means that x is both responsible and in control of execution.

5. Application: The real estate example

We now evaluate the CBSC framework and Event Calculus axioms through a single use-case; a basic real-estate transaction, often mentioned as an important application area for smart contracts (Deloite, 2017; Karamitsos, Papadaki and Al Barghuthi, 2018). BUY represents the buyer (or debtor agent). SEL represents the seller (or creditor agent) and SC represents a smart contract as a replacement for a traditional Notary.

Since this process is standardized and regulated in most countries, it is likely that the process follows a happy flow. We assume that only one action can occur at one time point. Hence, we are not concerned with concurrent events. In principle, the frame problem mentioned in Yolum and Singh (2004) is handled through circumscription as explained by Shanahan (2000). Through circumscription, the set of Activates, Satisfies and Release clauses is kept to a minimum to reduce the chance of unexpected effects. The minimization of Happens leads to a minimal number of unexpected events. However, as circumscription is not always a good solution, we do not exclude pragmatic approaches that exploit domain semantics.

Table 3
Protocol run events

Event Event description Event notation P/Q Detail

e1 The event where the seller decides to relocate to another location, which would result in the sale of his/her property DecideToRelocate(a) f1 Decide

e2 The event where the seller lists his/her property and starts considering offers from buyers ListProperty(a, m) f2 List

e3 The event where the buyer offers to buy the property from the seller for a certain amount MakeOffer(a, m) f3 Offer

e4 The event where the seller accepts the offer made by the buyer. In this example, the number of offers is not relevant AcceptOffer(a, m) f4 Accept

e5 The event where the seller and buyer sign the agreement SignContract(a, m) f5 Sign

e6 The event where he buyer transfers the down payment (1) and (2) remaining for the property TransferPayment(a, m) f6 Transfer

e7 The event where the seller vacates the property VacateProperty(a) f7 Vacate

Event	Event description	Event notation	P/Q	Detail
e1	The event where the seller decides to relocate to another location, which would result in the sale of his/her property	DecideToRelocate(a)	f1	Decide
e2	The event where the seller lists his/her property and starts considering offers from buyers	ListProperty(a, m)	f2	List
e3	The event where the buyer offers to buy the property from the seller for a certain amount	MakeOffer(a, m)	f3	Offer
e4	The event where the seller accepts the offer made by the buyer. In this example, the number of offers is not relevant	AcceptOffer(a, m)	f4	Accept
e5	The event where the seller and buyer sign the agreement	SignContract(a, m)	f5	Sign
e6	The event where he buyer transfers the down payment (1) and (2) remaining for the property	TransferPayment(a, m)	f6	Transfer
e7	The event where the seller vacates the property	VacateProperty(a)	f7	Vacate

Table 3 shows the EC events e1 $\dots$ e5 that correspond to interface messages of the smart contract. Since this property event cycle is heavily regulated, the order of events is rather standard and does not provide room for change. To name the events, we have chosen to uppercase the second main action words, like listProperty, where the first word is a fluent. The next step is to convert the chain of events to the EC. Commit( $e, x, c$ ) establishes commitment c, in our interpretation BC or CC. When event e is performed, the commitment c or a state (fluent) p is initiated. HoldsAt explains which states (fluents) hold at a given time point, and Happens defines a predicate relation between events possibly surrounded by conditions and times.

Table 4 shows the protocol run for the first five events of a generic real estate transaction, including the agent that controls the execution and the one that is responsible. We have modified the protocol as such that we could illustrate all rules presented in Table 2.

Table 4

Protocol run

Event	Time	P/Q	Rule	EC	C	Title	Control	Responsible
e1	t1.1	f1	r2	Commit	bc1	Relocate	SEL	SEL
e1	t1.2	f1	r2	Activate	bc1	Relocate	SEL	SEL
e2	t2.1	f2	r3	Satisfy	bc1	Relocate	SEL	SEL
e2	t2.2	f2	r1	Commit	cc2	Consider	SEL	SEL
e3	t3.1	f3	r1	Commit	cc3	Buy	BUY	BUY
	t3.2		r2	Activate	cc2	Consider	SEL	SEL
	t3.3		r7	Delegate	cc3	Buy	SC	BUY
	t3.4		r2	Activate	cc3	Buy	SC	BUY
e4	t4.1	f4	r6	Satisfy	cc2	Consider	SEL	SEL
	t4.2		r6	Commit	bc4	Consider	SEL	SEL
	t4.3		r2	Activate	bc4	Consider	SEL	SEL
	t4.4		r4	Satisfy	bc4	Consider	SEL	SEL
	t4.5		r1	Commit	cc5	Sell	SEL	SEL
	t4.6		r8	Assign	cc5	Sell	SC	SEL
	t4.7		r2	Activate	cc5	Sell	SC	SEL
	t4.8		r5	Satisfy	cc5	Sell	SC	SEL
	t4.9		r5	Commit	bc6	Sell	SC	SEL
	t4.10		r5	Activate	bc6	Sell	SC	SEL
	t4.11		r5	Satisfy	cc3	Buy	SC	BUY
	t4.12		r5	Commit	bc7	Buy	SC	BUY
	t4.13		r5	Activate	bc7	Buy	SC	BUY
e5	t5.1	f5	r6	Satisfy	bc6	Sell	SC	SEL
	t5.2		r2	Satisfy	bc7	Buy	SC	BUY
	t5.3		r2	Commit	cc8	Transfer	BUY	BUY
	t5.4		r2	Commit	cc9	Vacate	SEL	SEL
e6	t6.1	f6	r2	Activate	cc8	Transfer	BUY	BUY
e6	t6.2	f6	r2	Activate	cc9	Vacate	SEL	SEL
e7	t7.1	f7	r5	Satisfy	cc9	Vacate	SEL	SEL
e7	t7.2	f7	r5	Satisfy	cc8	Transfer	BUY	BUY

For each event and subsequent time point in Table 4, we can apply the rules as defined in Table 2. We will illustrate with some examples. The example starts with the (arbitrary) decision by the seller to commit to relocate for any reason. Since the seller commits to his/herself in this instance, the seller represents both x and y. It is important to note that we do not imply r1 here, since the commitment and its activation both happen in r1. We could write this commitment conforming to r2 and initialized as R2 in two ways:

Activate(DecideToRelocate(Mainstreet 1), Relocate(SEL, SEL, Decide(Mainstreet 1)), $t 1.2$ ) ← Happens(DecideToRelocate(Mainstreet 1), $t 1.1$ ) ∧ Commit(ListProperty(Mainstreet 1, 100.000), SEL, Relocate(SEL, SEL, Decide(Mainstreet 1)))

Or simplified via the shortcuts provided in Tables 3 and 4. Hereby, a represents the asset (e.g. Mainstreet 1) and m the amount paid (e.g. 100.000 USD).

Activate( $e 1$ (Mainstreet 1), bc1 (SEL, BUY, f1(a)), $t 1.2$ ) ← Happens( $e 1$ (Mainstreet 1), t1.1) ∧ Commit( $e 2$ ( $a, m$ ) $, SEL, b c 1$ (SEL, SEL, f 1(a)))

We prefer the second method using short codes as a matter of convenience. c1 is satisfied by listing the property. This does not mean that the seller is relocated yet, but all he/she could do after committing to relocate was to list the property.

We continue with e2. The list fluent in e2 commits the seller to consider offers. The Consider commitment (c2) is created in conformation to r1 but is not activated, since there are no offers to consider yet. The effect of e2 conforming to r3 is defined as:

Satisfy( $e 2$ ( $a, m$ ) $, c 1, t 2$ .1) ← Happens( $e 2, t 2$ .1) ∧ Activate( $e 1, c 1, t 1$ .2) ∧ Discharge( $e 2, SEL, c 1$ (SEL, BUY, f2))

Commit( $e 2$ (a,m) $, SEL, c 2$ (SEL, BUY, f2( $a, m$ )))← Happens( $e 2, t 2$ .2)

We continue with e3-5. The Buy and Sell commitments stretch from e3 (offer) to e5 (sign) and comply to r5, whereby the conditional commitments resolve as p (accept) holds into a new base commitment bcx to provide q (sign). The Buy commitment is created in an event (e3) where it could not be activated yet (only during e4). In contrast to the Consider conditional commitment cc3 which implies r6, q is only brought about in a later event at t5.1 and t5.2. The Buy commitment confirms to r6 and evolves as follows:

Activate ( $e 4 (a, m), b c 7 (BUY, SEL, f5 (a, m)), t 4.13) \leftarrow Happens (e 4 (a, m), t 4.13) \land Commit (e 4 (a, m), BUY, b c 7 (BUY, sell, f5 (a, m))$ )

$Satisfy (e 4 (a, m), c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)), t 4.11) \leftarrow Happens (e 4 (a, m), t 4.4) \land HoldsAt (cc3 (BUY, SEL, f4 (a, m), f 5 (a, m))) \land Activate (e 3 (a, m), c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)), t 3.4))$

$Activate (e 3 (a, m), c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)), t 3.4) \leftarrow Happens (e 3 (a, m), t 3.1) \land Commit (e 3 (a, m), BUY, c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)))$

The Buy commitment also delegates control to the smart contract (SC) conforming to r7 by changing x to z, written as SCc, since the Smart Contract takes the control role. Please note that x remains responsible, written as $x r$ .

$Commit (e 3 (a, m), ⟨ x r, S C c ⟩, c c 3 (⟨ x r, S C c ⟩, SEL, f 4 (a, m), f 5 (a, m))) \leftarrow Happens (e 3, t 3.3) \land Delegate (e 3 (a, m), BUY, ⟨ x r, S C c ⟩, c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)))$

$Cancel (e 3 (a, m), x, c c 3 (x, y, f 4 (a, m), f 5 (a, m))) \leftarrow Happens (e 3, t 3.3) \land Delegate (BUY, ⟨ x r, S C c ⟩, c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)))$

The process for the assignment operation for the Sell commitment is similar to the delegate operation but conforms to r8 instead of r7 to change the creditor agent from y to z.

Non-fulfillment is the event where p or q are not satisfied as committed. When there is no fulfilment for p at all, the commitment reaches the state of expiration; where there is no intention to satisfy p and the commitment is canceled permanently, including all forward commitments for satisfying q and beyond. In case of a partial fulfilment of p, instead of updating the existing active commitment, the original commitment conforming to r4 is canceled and a new and activated commitment is created holding the remaining obligations for p (in bold).

$Satisfy (e 4 (a, m), c c 3 (BUY, SEL, f4(a,m), f 5 (a, m)), t 4.11) \leftarrow Happens (e 4 (a, m), t 4.4) \land HoldsAt (cc3 (BUY, SEL, f4 (a, m), f 5 (a, m))) \land Activate (e 3 (a, m), c c 3 (BUY, SEL, f4(a,m), f 5 (a, m)), t 3.4))$

When there is no fulfilment for q at all, the commitment does not reach the state of expiration as with p, since BUY already committed to p, cancelling the commitment at this point would lead to loss for BUY. In case of both a non- or a partial fulfilment of q by SEL, instead of updating the existing active commitment, the original commitment is canceled and a new and activated commitment is created conforming to r4 holding the remaining obligations for q and may include a penalty as per the rules of engagement.

$Satisfy (e 4 (a, m), c c 3 (BUY, SEL, f4 (a, m), f5(a,m)), t 4.11) \leftarrow Happens (e 4 (a, m), t 4.4) \land HoldsAt (cc3 (BUY, SEL, f4 (a, m), f 5 (a, m))) \land Activate (e 3 (a, m), c c 3 (BUY, SEL, f4 (a, m), f5(a, m)), t 3.4))$

6. KR ReactionRuleML for CBSCs

6.1. Rule languages vs coordination languages

There are multiple approaches to express the interaction of agents, like rule languages (Boley, 2006) and coordination languages like Linda or Limbo (Jacquet et al., 1997). As in our EC formalizations, reaction rules are concerned with the invocation of actions in response to (complex) events and actionable situations, whereas in coordination model provides a framework in which the interaction between active and independent agents can be expressed. A coordination model should solve the issues of creation and destruction of agents, communication among agents, and spatial distribution of agents, as well as synchronization and distribution of their actions over time. A coordination language orthogonally combines two languages: one for coordination (the inter-agent actions) and one for (sequential) computation (the intra-agent actions). Both approaches concern the concept of state, either through fluents (Reaction Rule Markup Language) or shared memory (Coordination Languages). Although coordination languages have been applied in event-based multi-agent systems, they are most applicable in open and highly dynamic systems like the world-wide-web (Davies et al., 1997), under the assumption that multi-agent systems are open and dynamic at any time. Smart contracts are not necessarily open, are logically static and reflect predefined logic between two or more agents when events occur. For that reason, we choose ReactionRuleML to express our EC expressions.

6.2. ReactionRuleML

Reaction RuleML is the quasi-standard for representing reaction rules since its introduction in 2006, as it is regarded as a user-friendly XML-serialized sublanguage of RuleML. It acts as an interchange format for reactive rules and rule-based event-processing languages (Paschke et al., 2012). Reaction rules using Reaction RuleML typically implement forward-chaining operational semantics for Condition-Action rules where changing conditions trigger update actions, like IF/THEN/ELSE (derivative reasoning), IF/DO (production rules), ON/DO (trigger rules) or ON/IF/DO (Event-Condition-Action or ECA) (Paschke et al., 2012). In order to determine the best conceptual and semantic model for CBSC, various meta-model requirements have been formulated; (1) Since we consider commitments as social economic events that contain other events (e.g. to pay), the rules themselves should be event oriented. (2) The events should be detectable, which allows IF conditions to be specific for detected events only. (3) The meta-model should allow multiple event definitions to be part of the same rule procedure, in order to process a contract as a bundle of reciprocal commitments. (4) It should be possible to define variables that apply to the entire smart contract. Finally, (5) in adherence to (Governatori et al., 2018), the algorithms for logic approaches should be efficient and ‘cheap’ as measured within the environment where they are deployed and according to its economic rules.

Reaction rules are used in distributed Complex Event Processing (CEP), Knowledge Representation (KR) calculus, as well as Event- Condition-Action (ECA) rules, Production (CA) rules, and Trigger (EA) rules (Paschke et al., 2012). Since in our context the event calculus reasons about effects of automated actions (on the blockchain) and the commitments that result from them through states, we leverage KR Reaction RuleML for CBSC. KR Reaction RuleML focus on inferences that are made from happened or planned events/actions (increment or decrement), they thereby describe inferences about the effects of these events/actions on changeable social effects (fluents/states) (Paschke, 2005). By focusing on the transition of knowledge states instead of just event detection, KR Reaction RuleML has close relations to formalisms of process and transition logics, where the focus is to create axioms to formalize the notion of actions and events (Paschke, 2006). The KR transaction perspective suggests the existence of internal knowledge and dynamic self-update sequences through extensional (facts/data) and intentional (rules) knowledge. We believe that a combination of event detection and conditional/constraint-based action invocation using KR Reaction RuleML shows major similarities to our conceptual model towards delegation of control and responsibilities of events using a smart contract. So far we have formalized our conceptual model using the EC to create a foundation in the context of temporal event and action logics. In a similar approach to (Yolum and Singh, 2004; Paschke, 2005), we now represent these EC axioms in KR ReactionRuleML to generate non-human oriented business rules for executable representation.

6.3. KR reaction RuleML extended

KR Reaction RuleML has been designed in the same vein as RuleML extensions like PolicyRuleML, LegalRuleML and ECA-RuleML (Paschke, 2006). It converts the EC axioms into RuleML properties for those properties that are missing in KR ReactionRuleML. Our extensions have two objectives over KR ReactionRuleML; (1) it should shorten the syntax for simple operations, and (2), the syntax should be tailored towards commitments. That means that all predicates mentioned in previous sections, missing in KR Reaction RuleML specified by Paschke, Athan and Boley (2017), will be added (e.g. A, M, or BC), and KR ReactionRuleML properties that are not usable, will be renamed. For example, the property ⟨sender⟩, which pre-exists in RuleML and is functionally useful, can be renamed to represent a buyer like ⟨BUY⟩, ⟨X⟩ or ⟨debtor⟩.

6.3.1. Variables

Every CBSC starts with defining the variables in RuleML that consist across the entire contract using the @scope attribute, like the address of the property (a), the agreed price (m) and the identities for the buyer (BUY) and sellers (SEL). We apply the <slot> property to store values as key-value pairs (e.g. Address | Mainstreet 1) apply directive attributes like @key and @beneficiary.

<!ELEMENT A (Ind)> <!ELEMENT M (Ind)> <!ELEMENT BUY (Agent, sender)> <!ELEMENT SEL (Agent, receiver)> <slot @scope="global" @key="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> <slot @scope="global" @key="amount"> <Ind>Amount</Ind> <Ind>Mainstreet 1</Ind> <slot> <slot @scope="global" @key="buyer"> <Ind>Buyer</Ind> <Ind>Miss Smith</Ind> <slot> <slot @scope="global" @key="seller"> <Ind>Seller</Ind> <Ind>Mister Jones</Ind> <slot> <slot @scope="global" @keyref="balance" @beneficiary="seller"> <Ind>Balance</Ind> <Ind>100.000</Ind> <slot>

6.3.2. Rules of engagement

Our infological model distinguishes between clauses and rules of engagement. Whereas the formalized commitments serve as contract clauses in CBSC’s, the rules of engagement are global by design and capture the state of the entire contract. Commitments may be conditioned by these rules of engagement. Under these circumstances, the ON/DO trigger rules are converted to ECA like ON/IF/DO, whereby the <if> rules contains the conditioning for Holds. For example, the global variable address can be used as a condition in the <HoldsAt> segment of a conditional commitment.

<slot @scope="global" @key="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> <on>...</on> <if> <HoldsAt> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> </HoldsAt> </if> <do>..</do>

6.4. Translation of EC rules into KR reaction RuleML

With these (‘class’ variables) rules of engagement in mind, we can convert the EC formalizations to KR Reaction RuleML. Let’s assume rule r2 at t1.1:

$Activate (e 1 (Mainstreet 1), b c 1 (SEL, BUY, f1 (a)), t 1.2) \leftarrow Happens (e 1 (Mainstreet 1), t 1.1) \land Commit (e 2 (a, m), SEL, b c 1 (SEL, SEL, f 1 (a)))$

We can reuse the default property <Event>, which is an existing RuleML property. Since there is only a <Happens> condition applied, we follow the ON/DO trigger rules. The metadata for our EC rules would semantically look like:

<!ELEMENT Interface (on, if, do)> <!ELEMENT on | do (Event)> <!ELEMENT do (Event)> <!ELEMENT Activate (Action)> <!ELEMENT Commit (Initiate)> <!ELEMENT BC (Fluent)> <!ELEMENT P (fluent)>

The <Rulebase><Rule><Event><Time><BC><CC> properties apply the @key and/or @type attributes for referability and semantic categorization (exchange and control commitments). The <Rule @key="r2"> refers to EC rule formalization r2, whereas the <Rulebase @key="0x5db26eced697d23786dc914a4e2debf35937d195ac4dd838ec34dbe0bdcf07fb"> refers to a set of rules, or in better terms, the smart contract itself on the blockchain identified by its hash. With all elements in place, the BC at e1 looks is defined as:

The <on> section describes the event DecideToRelocate where the seller decides to relocate to another location

<on> <And> <Happens> <Event @key="e1;DecideToRelocate"> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> </Event <Time @key="1.1"/> </Happens> </And> <And> <Commit> <Event @key="e2;ListProperty"> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> </Event> <SEL>Mister Jones</SEL> <BC @key="bc1;Relocate" @type="Exchange"> <SEL>Mister Jones</SEL> <BUY>Miss Smith</BUY> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> </BC> </Commit> </And> </on>

The <do> section describes activation of the commitment Relocate through the event DecideToRelocate.

<do> <Activate> <Event @key="e1;DecideToRelocate"><A>Mainstreet 1</A></Event> <BC @key="bc1;relocate" @type="Exchange"> <SEL>Mister Jones</SEL> <SEL>Mister Jones</SEL> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> </BC> <Time @key="1.2"/> </Activate> </do> </Rule>

Conditional commitments are semantically different as we illustrate for cc3 at t2.2. We focus on the part (in bold) where cc3, conditioned by the <HoldsAt> property in <if>, is satisfied by fulfilling p, after which a BC is created to fulfil q.

$Activate (e 4 (a, m), b c 7 (BUY, SEL, f5 (a, m)), t 4.13) \leftarrow Happens (e 4 (a, m), t 4.13) \land Commit (e 4 (a, m), BUY, b c 7 (BUY, sell, f5 (a, m)))$

$Satisfy (e4(a, m), cc3(BUY, SEL, f4 (a, m), f5(a, m)), t4.11) \leftarrow Happens (e4(a, m), t4.4) \land HoldsAt (cc3 (BUY, SEL, f4 (a, m), f5(a, m))) \land Activate (e3(a, m), cc3(BUY, SEL, f4 (a, m), f5(a, m)), t3.4))$

$Activate (e 3 (a, m), c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)), t 3.4) \leftarrow Happens (e 3 (a, m), t 3.1) \land Commit (e 3 (a, m), BUY, c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)))$

We have to add several elements to extend KR Reaction RuleML in order to match the properties to the EC formalizations for conditional commitments:

<!ELEMENT CC (Fluent)> <!ELEMENT Satisfy (Terminates)> <!ELEMENT Q (fluent)> <!ELEMENT HoldsAt (Holds)>

The <on> section describes the event AcceptOffer in which the fulfilment of the event is being evaluated. In this case, it will describe the event in which the offer is accepted by the seller.

<on> <And> <Happens> <Event @key="e4;AcceptOffer"> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> </Event> <Time @key="4.4"/> </Happens> </And> <And> <Activate> <Event @key="e3;MakeOffer"> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> </Event> <CC @key="cc3;buy" @type="exchange"> <BUY>Miss Smith</BUY> <SEL>Mister Jones</SEL> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> <Q @key="f5;Sign"/> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> </Q> </CC> <Time @key="3.4"/> </Activate> </And> </on>

The <if> section describes the conditional part of the commitment, that states that the seller will only accept the offer once the buyer offers the asking price.

<if> <HoldsAt> <CC @key="cc3;Buy" @type="Exchange"> <BUY>Miss Smith</BUY> <SEL>Mister Jones</SEL> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> <Q @key="f5;Sign"/> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M>100.000</M> </Q> </CC> </HoldsAt> </if>

The <do> section describes the action that will take place once the seller accepts the offer during the event AcceptOffer, in this case, signing the contract.

<do> <Activate> <Event @key="e4;AcceptOffer"> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> </Event> <CC @key="cc3;buy" @type="exchange"> <BUY>Miss Smith</BUY> <SEL>Mister Jones</SEL> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> <Q @key="f5;Sign"/> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> </Q> </CC> <Time @key="4.11"/> </Activate> </do>

The previous example assumed that p was fulfilled. Imagine the event of non-fulfillment where p is only partly fulfilled at t5 and only half of the purchase price is transferred to the notary. The global balance variable will be updated through the <Update> property and the commitment will be terminated and re-committed to reflect the new (in bold) value for p.

$Satisfy (e 6 (a, m), c c 8 (BUY, SEL, f6(a,m), f 7 (a, m)), t 6 . x) \leftarrow Happens (e 4 (a, m), t 4.4) \land HoldsAt (cc8 (BUY, SEL, f6 (a, m), f 7 (a, m))) \land Activate (e 6 (a, m), c c 8 (BUY, SEL, f6(a,m), f 7 (a, m)), t 6 . x))$

<A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="balance" @beneficiary="seller"> <Ind>Balance</Ind> <Ind>50.000</Ind> <slot> </M> <Update> <slot @scope="global" @keyref="balance" @beneficiary="seller"> <Ind>Balance</Ind> <Ind>50.000</Ind> <slot> </Update>

When there is no fulfilment for q at all, the commitment does not reach the state of expiration as with p, since BUY already committed to p, cancelling the commitment at this point would lead to loss for BUY. In case of both a non- or a partial fulfilment of q by SEL, instead of updating the existing active commitment, the original commitment is canceled and a new and activated commitment is created for q’s remaining obligations and may include a penalty as per the rules of engagement.

$Satisfy (e 6 (a, m), c c 9 (BUY, SEL, f6 (a, m), f7(a,m)), t 6 . x) \leftarrow Happens (e 4 (a, m), t 4.4) \land HoldsAt (cc9 (BUY, SEL, f6 (a, m), f 7 (a, m))) \land Activate (e 6 (a, m), c c 9 (BUY, SEL, f6 (a, m), f7(a, m)), t 6 . x))$

When q is not fulfilled (e.g. house not vacated during final inspection), a penalty may be imposed to the seller by subtracting 10.000 USD penalty of the remaining balance by the buyer.

<Q @key="f7;Vacate"/> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> </Q> <Update> <slot @scope="global" @keyref="balance" @beneficiary="seller"> <Ind>Balance</Ind> <Ind>40.000</Ind> <slot> </Update>

SBCS’s are logically immutable, but are able to switch the x and y roles to third parties in the event of (re)assignment (switch x) or delegation (switch y). The delegation of actions is written as follows at e3:

$Commit (e3(a, m), ⟨ xr, SCc ⟩, cc3(⟨ xr, SCc ⟩, SEL, f4(a,m), f5(a,m))) \leftarrow Happens (e3, t3.3) \land Delegate (e3(a,m), BUY, SEC, cc3 (⟨ xr, SCc ⟩, SEL, f4(a,m), f5(a,m)))$

$Cancel (e, x, c c 3 (x, y, f 4 (a, m), f 5 (a, m))) \leftarrow Happens (e 3, t 3.3) \land Delegate (BUY, (⟨ xr, SCc ⟩, c c 3 (BUY, SEL, f4 (a, m), f 5 (a, m)))$

Before we draft the KR Reaction RuleML (in bold), we have to add the Delegate, SC (smart contract) and Cancel elements to KR Reaction RuleML.

<!ELEMENT Delegate (Action)> <!ELEMENT SC (Agent, receiver)> <!ELEMENT Cancel (Action)>

In this example we delegate the sales transaction from SEL to SC. The delegation starts by updating the seller key-value pair for the rules of engagement through the <Update> property.

<Update> <slot @scope=’’global’’ @keyref=’’seller’’> <Ind>Seller</Ind> <Ind>SC</Ind> <slot> </Update>

Once changed, the commitment is canceled and recommitted and delegated to the SC. We have added a @type to the SEL property, since Mister Jones remains responsible after delegating control to the SC.

<Delegate> <Eventkey="e3;MakeOffer"> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M>100.000</M> </Event> <BUY @keyref="buyer">Miss Smith</BUY> <<SEL @keyref="seller" @type="responsible">Mister Jones</SEL> <SEL @keyref="seller" @type="control">SC</SEL>> <CC @key="cc3;Buy" @type="Control"> <BUY>Mister Smith</BUY> <SEL>Mister Jones</SEL> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <Q @key="f5;sign"/> <A> <slot @scope="global" @keyref="address"> <Ind>Address</Ind> <Ind>Mainstreet 1</Ind> <slot> </A> <M> <slot @scope="global" @keyref="purchase\_price"> <Ind>Purchase Price</Ind> <Ind>100.000</Ind> <slot> </M> </Q> </CC> </Delegate>

7. Discussion

While creating our model, we studied, adopted and extended approaches to (1) define the lifecycle of commitments, (2) formalize commitments and (3) express these commitment formalizations into an actionable language. For the lifecycle of commitments (1), we adopted the commitment lifecycle model presented by Yolum and Singh (2004), which is in line with the transaction paradigm by Van Reijswoud (1996) to close commitments and create new ones on events of change, instead of changing or extending the original commitment, in order to make the commitments stateless while the contract governs its state through the only moveable parts of the smart contract; the rules of engagement. In our view, the approach to modify commitments during their lifetime is in juxtaposition to the concept of smart contracts itself, since blockchain technology is designed to avoid changes to data once added to the ledger (e.g., commitments). CBSC safeguards against unfulfilled commitments that drag on until infinity by adopting the transaction paradigm that initializes and terminates commitments when required. This method allows smart contracts to be modularized into active and inactive reciprocal commitments. Therefore, commitments in a CBSC may even be considered as (sub)contracts themselves.

The commitment lifecycle could have been formalized in multiple ways; using speech act theories, in accordance to the Contract Lifecycle by Governatori et al. (2018) or Horn clauses similar to formalizations for ECA (Paschke et al., 2012). We adopted the Event Calculus formalization as implemented by Yolum and Singh (2004) for its clear integration between commitments and the Event Calculus. To express our Event Calculus formalizations (3), we introduced KR Reaction RuleML for CBSC based on reaction rules invocated through events to advance the concept of smart contracts. We choose this high-level declarative approach to include the concept of ‘state’ into our model, similar to the inner workings of blockchain and in line with the concept of how concur-rent languages using message passing and shared variables work. By extending KR Reaction RuleML, all the Event Calculus axioms are included as RuleML properties. As a result, only one syntax can be used to define CBSCs, instead of the inter- and intra-agent logic that has to be defined for coordination language syntax.

8. Conclusion

This paper introduced a commitment-based formalization approach towards smart contracts using the Event Calculus. The concept of commitment based smart contracts builds on the idea of expressing multi-agent interactions through the lens of smart contracts and commitments, while delegating and assigning action execution responsibility to smart contracts as (semi)autonomous agents. Hereby, the scope of agents is extended from agents as ‘human’ to be ‘human’ and ‘non-human’. In the current era of ‘weak artificial intelligence’, we assume that smart contracts are and will remain a collaboration between human and digital agents, since smart contracts can only create new smart contracts if instructed by a human agent in advance.

We introduced a formalization process similar to Governatori’s (2005). We leveraged the Event Calculus for foundation and KR ReactionRuleML for the representation of execution. A running example illustrated how base, conditional and persistent commitments can be created and manipulated through events over time. Hereby, commitments are created and recreated on each event in line with the transaction paradigm and the Singh commitment lifecycle. Yet, in contrast to the commitment lifecycle of Singh, we maintain that commitments can be created, activated and satisfied at different time points across a (business) transaction as we have demonstrated in our running example.

In addition, we have added formalisms to change the role that actors play during a transaction. In our view, this extension allows to go beyond the mere monitoring function that Singh assigns to smart contracts. Although smart contracts are immutable once saved on the ledger, we introduce a way to inject some level of flexibility through delegation and assign operations. By allowing to adapt the control role of the debtors and creditors during a transaction (e.g., from seller to smart contract), smart contracts may become useful for complex contracts that stretch over longer periods of time and include many unknown future events. We think that these additions to the commitment lifecycle may foster the application of commitment-based approaches towards executable smart contracts. This approach could be further extended by adding the complete glossary for KR Reaction RuleML extensions so that (declarative) protocol runs could be automatically be converted to code, exploring more in-depth state monitoring mechanisms (guarding), and approaches towards the (deontic) concept of contract violation. Future research may also further axiomatize our conceptual model. We think that the combination of (extended) KR ReactionRuleML and blockchain’s autonomous execution capability with immutable and agreed upon logic, has the potential to be a very powerful instrument to manage contracts in the future.

References

Bailey, J., Poulovassilis, A. & Wood, P.T. (2002). An event-condition-action language for XML. In Proc. of the 11th International Conference on World Wide Web (pp. 486–495).

Becker, H.S. (1960). Notes on the concept of commitment. American Journal of Sociology, 66(1), 32–40. doi:10.1086/222820.

Boley, H. (2006). The RuleML Family of Web Rule Languages. Principles and Practice of Semantic Web Reasoning: 4th International Workshop. Revised Selected Papers, 1–17.

Chopra, A.K., Oren, N., Modgil, S., Desai, N., Miles, S., Luck, M. & Singh, M.P. (2011). Analyzing contract robustness through a model of commitments. In Int. Workshop on Agent-Oriented Software Engineering XI (AOSE 2010) (pp. 17–36). Revised Selected Papers. doi:10.1007/978-3-642-22636-6_2.

Davies, N., Wade, S.P., Friday, A. & Blair, G.S. (1997). Limbo: A tuple space-based platform for adaptive mobile applications. Open Distributed Processing and Distributed Platforms, 291–302. doi:10.1007/978-0-387-35188-9_22.

De Kruijff, J. & Weigand, H. (2017a). Understanding the blockchain using enterprise ontology. In Proc CAiSE 2017 (pp. 29–43). Springer.

De Kruijff, J. & Weigand, H. (2017b). Ontologies for commitment-based smart contracts. In Proc. on the Move 2017, Part II (pp. 383–398).

De Oliveira, L.C., Simoyama, F., Grigg, I. & Bueno, R.L.P. (2017). Triple entry ledgers with blockchain for auditing. International Journal of Auditing Technology, 163–183. 2017.

Deloitte Center for Financial Services (2017). Blockchain in Commercial Real Estate. Retrieved from, https://www2.deloitte.com/us/en/pages/financial-services/articles/blockchain-in-commercial-real-estate.html.

10.

Dietz, J. (2006). Enterprise Ontology. Springer.

11.

Foara, N. & Colombetti, M. (2004). A commitment based approach to agent communication. Appl Artif Intell, 18(9–10), 853–866. doi:10.1080/08839510490509054.

12.

Governatori, G. (2005). Representing business contracts in RuleML. Int J Coop Inf Syst, 14(02n03), 181–216. doi:10.1142/S0218843005001092.

13.

Governatori, G., Idelberger, F., Milosevic, Z., Riveret, R., Sartor, G. & Xu, X. (2018). On legal contracts, imperative and declarative smart contracts, and blockchain systems. Artificial Intelligence and Law, 26, 377–409. doi:10.1007/s10506-018-9223-3.

14.

Herold, F. (2010). Contractual incompleteness as a signal of trust. Games and Economic Behavior, 68(1), 180–191. doi:10.1016/j.geb.2009.05.001.

15.

Jacquet, J.M., De Bosschere, K. & Brogi, A. (2000). On timed coordination languages. In Proc.Int. Conference on Coordination Languages and Models (Coordination 2000) (pp. 81–98). doi:10.1007/3-540-45263-X_6.

16.

Jalakas, P. (2018). Blockchain from Public Administration Perspective: Case of Estonia. 2018, Retrieved from, https://digikogu.taltech.ee/en/Download/d591ed87-3350-44a1-acb3-f0e184f9dc18#:~:text=The%20Estonian%20case%20demonstrates%20a,using%20blockchain%20in%20public%20administration.&text=Blockchain%20could%20be%20used%20as,the%20Neo%2DWeberian%20State%20framework.

17.

Karamitsos, I., Papadaki, M. & Al Barghuthi, N.B. (2018). Design of the blockchain smart contract. Journal of Information Security, 09(03), 177–190. doi:10.4236/jis.2018.93013.

18.

Kowalski, R. & Sergot, M. (1986). A logic-based calculus of events. New Generat Comput, 4(1), 67–95. doi:10.1007/BF03037383.

19.

Krasa, S. & Williams, S.R. (2000). Incompleteness as a Constraint in Contract Design. Bureau of Econ. & Bus. Research Paper No. 00-0113.

20.

Levy, K.E.C. (2017). In Book-Smart, Not Street-Smart: Blockchain-Based Smart Contracts and the Social Workings of Law, Engaging Science, Technology, and Society (pp. 1–15).

21.

McCarthy, J. & Hayes, P.J. (1981). In Readings in Artificial Intelligence. Chapter 5 Adv Top (pp. 431–450). doi:10.1016/B978-0-934613-03-3.50033-7.

22.

Norta, A. (2016). Designing a smart-contract application layer for transacting decentralized autonomous organizations. In Proc. Int. Conference on Advances in Computing and Data Science (ICADS 2016) (pp. 595–604).

23.

Nute, D. (2000). Defeasible deontic logic. Artificial Intelligence and Law, 8, 75–91. doi:10.1023/A:1008338019879.

24.

Paschke, A. (2005). ECA-RuleML: An approach combining ECA rules with temporal interval-based KR event/action logics and transactional update logics. In ECA-RuleML Proposal for “RuleML Reaction Rules Technical Group”.

25.

Paschke, A. (2006). The Reaction RuleML Classification of the Event/Action/State Processing and Reasoning Space, Special Event on Reaction RuleML. Technical University Munich, Technical Report 11/2005.

26.

Paschke, A., Athan, T. & Boley, H. (2017). Glossary of Reaction RuleML 1.02. Retrieved from, http://wiki.ruleml.org/index.php/Glossary_of_Reaction_RuleML_1.02.

27.

Paschke, A., Boley, H., Zhao, Z., Teymourian, K. & Athan, T. (2012). Reaction RuleML 1.0: Standardized Semantic Reaction Rules.

28.

Rich, B. (2018). How AI Is Changing Contracts, Harvard Business Review. Retrieved from, https://hbr.org/2018/02/how-ai-is-changing-contracts.

29.

Schulz, K. & Van Rooij, R. (2006). Pragmatic meaning and non-monotonic reasoning: The case of exhaustive interpretation. Linguistics and Philosophy, 29(2), 205–250. doi:10.1007/s10988-005-3760-4.

30.

Shanahan, M. (2000). An abductive event calculus planner. J Log Program, 44(1–3), 207–240. doi:10.1016/S0743-1066(99)00077-1.

31.

Singh, M.P. & Chopra, A.K. (2018). Violable Contracts and Governance for Blockchain Applications. Retrieved from, https://www.researchgate.net/publication/322354899_Violable_Contracts_and_Governance_for_Blockchain_Applications.

32.

Telang, P.R., Singh, M.P. & Yorke-Smith, N. (2012). In Proc. Int. Workshop on Programming Multi-Agent Systems. (ProMAS 2011), Revised Selected Papers, 22–37.

33.

Telang, P.R., Singh, M.P. & Yorke-Smith, N. (2019). A coupled operational semantics for goals and commitments. Journal of Artificial Intelligence Research, 65, 31–85. doi:10.1613/jair.1.11494.

34.

Van Reijswoud, V.E. (1996). The Structure of Business Communication: Theory Model and Application. PhD Thesis, Delft University of Technology.

35.

Weigand, H., Blums, I. & de Kruijff, J. (2018). Shared ledger accounting – implementing the economic exchange pattern. In Proc. CAiSE 2018 (pp. 342–356). Springer.

36.

Weigand, H., Dignum, V., Meyer, J.J. & Dignum, F. (2002). Specification by refinement and agreement: Designing agent interaction using landmarks and contracts. In Int. Workshop on Engineering Societies in the Agents World (pp. 257–269). Springer.

37.

Yolum, P. & Singh, M.P. (2004). Reasoning about commitments in the event calculus: An approach for specifying and executing protocols. Ann Math Artif Intel, 42(1–3), 227–253. doi:10.1023/B:AMAI.0000034528.55456.d9.