Smart contracts gain rapid exposure since the inception of blockchain technology. Today's smart contracts are coded in non-mainstream procedural programming languages (e.g. Solidity for Ethereum), which lifts the requirement to draft enterprise ready smart contract to both a legal professional and a programmer instead of only the former. In search for a smart contract language that reduces the threshold to draft one, this conceptual paper elaborates how business logic can be converted to executable code for commitment-based smart contracts. Hereby, a contract is viewed as a set of reciprocal commitments. The smart contract ensures the automated execution of all or most of these commitments. In order to leverage its event processing capabilities, Reaction RuleML has been used to appropriately represent the elements and working of passive and active rules within a commitment based smart
Smart contracts combine protocols with user interfaces to formalize and
secure relationships over computer networks. Objectives and principles
for the design of these systems are derived from legal principles,
economic theory and theories of reliable and secure protocols [
In order to make smart contracts more familiar to ordinary internet
users, it is important to minimize the threshold to read and write them, in
particular for users from the legal practice who draft paper-based or
electronic legal contracts (from now: conventional contracts). In this
context, [
Our research objective is to make a theoretical contribution to the
science of contract languages for (logic-based) smart contracts. Chopra's
concept of business contracts as a bundle of commitments is applied using
RuleML as a markup language for drafting smart contracts. We evaluate
existing approaches using declarative rules [
This paper is structured as follows. First, we explore the elements of commitment-based smart contract and possible execution styles, followed by an introduction to Reaction RuleML, code examples per execution style and a conclusion.
Elements of a Commitment-Based Smart Contract
A contract is a legally binding or valid agreement between two or more
parties. The main objective of a contract is to fulfill a certain goal and to
safeguard against undesirable outcomes, together referred to as contract
robustness [
It might be objected that commitments represent the positive actions to
be performed by the actors only. What about prohibitions? For instance,
a music customer is not allowed to copy the music he can download. In
some cases, like the music copying, there may be technical means to make
the prohibited action impossible, but there are also actions of agents that
are not under control. In these cases, what the parties should commit to,
is to take the consequences (e.g. paying a penalty). The prohibition – don’t
do A – is reformulated as a contingency commitment – IF <A> THEN
<consequence>, where a transformation is described between deontic
logic and dynamic logic [
In the context of blockchain, a commitment is equal to a future
transaction, the robustness of their smart contract depends on how its
commitments relate to the goals of the contract parties [
As each contract goal consists of reciprocal commitments. In line with
the economic exchange pattern [
Since there is no formal way to schedule transaction events via the
blockchain protocol itself [
Method Explanation Lazy Execution Transactions are (Must call to initiated by an execute paradigm) actor, either manually or scheduled Eager Execution The smart contract polls for events in order to trigger reciprocal transactions
Advantage Low compute costs Lower complexity due to lack of nesting inside contract code Fully automated Transactions provide security that they happen. Humans may forget to initialize a transaction when they should.
Disadvantage Less automation and leverage of the power smart contracts Full automation results in higher compute complexity, which equals transaction costs. In this paper, we provide code examples of business rules within commitment based smart contracts using Reaction RuleML, for both execution methods, as they are both relevant in practice today. Besides the execution method, we have made other considerations that can be summarized as follows:
Transaction events are atomic, meaning that they happen in total (‘execute’ in the technical sense) or not happen at all.
The business logic (or rules of engagement) for economic settlement, is preferred to executed on-chain Each commitment that has time constraints consists of at least two smart contracts, since a second smart contract is created that takes care of the scheduled call of business logic in the ‘main’ smart contract Smart contract transactions for settlement are initialized by the smart contract itself, not by the parties involved, since the smart contracts protects the interests of all actors.
RuleML
RuleML is as markup language with the ability to express business rules
as modular, stand-alone units. It can be extended and possesses the ability
to resolve conflicts using priorities and override predicates [
Commitments can be simulated by both branches of the RuleML
family of rules; transformative (declarative) rules and reactive rules.
Derivation rules are believed to provide the most accurate conceptual
representation of a contract. The main goal of a declarative rule is
knowledge generation [
Reaction rules are concerned with the invocation of actions in response to (complex) events and actionable situations [13]. Reaction RuleML is the quasi-standard for representing reaction rules. It is regarded as a userfriendly XML- serialized sublanguage of RuleML and acts as an interchange format for reactive rules and rule based event-processing languages. 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), ON/IF/DO (Event-Condition-Action or ECA) or a variation of ON/IF/DO and IF/THEN (Knowledge Representation or KR) [14].
Blockchain is considered to be a distributed database to transfer value or value derivatives (tokens). The introduction of smart contract functionality brought along functionality from the active database domain, like inserting and triggering. Nevertheless, blockchain is not limited to be an active distributed database either, since it has the capability to interact with (complex) events that consider time- and other constraints. Other (non-exhaustive) meta-model considerations for commitment based smart contract rules are summarized below: • • • • •
Since we consider commitments as social economic events that may contain other events (e.g. to pay) [15], the rules themselves should be event oriented.
These events should be callable or detectable, which allows IF conditions to be specific for detected events only.
The meta-model should allow multiple event definitions to be part of the same rule procedure, in order to process a contract goal as a bundle of reciprocal commitments.
It is preferred to support smart contract wide states (e.g. deposit percentage) that apply to the entire smart contract, instead of defining them on run-time. This will maximize re-usability and consistency when contracts grow in complexity.
Prohibitions or violations are not similarly handled compared to conventional contracts [16]. The prohibition – don’t do A – is reformulated as a contingency commitment – IF A THEN <consequence> or ON A DO <consequence> in order to eliminate the need for complex and hard-to-maintain ELSE statements.
The remainder of this paper shows how lazy and eager rules within the commitment based contract can be defined. RuleML inhibits three execution styles for rules: passive, active and reasoning. Figure x shows how passive and active rules align with the smart contract execution styles.
Method Blockchain Lazy
Method Reaction RuleML
Passive Eager
Active
Explanation The smart contract 'passively' waits for incoming events The smart contract 'actively' polls/detects occurred events Smart contract transactions are in essence text messages that are mined by network nodes. As a result, we depict transactions as <Messages> in Reaction RuleMl. The code examples provided fully adhere to the design considerations as presented in the previous section
Passive reaction rules wait for incoming events in order to trigger an action. In this example, we assume an <event> that contains a <Message> that is sent to the smart contract. This message may (transaction) or may not (query) change the state of the smart contract (e.g. balance), a condition that can be used in the <body>. For example, it could be verified is there is a change to the state or if there is an outstanding obligation between the sender and the receiver. Once the condition is fulfilled, the smart contract triggers an automatic response message <action>, which sends a <Message> to the blockchain network to settle the balance. <Reaction style=”passive”> <event> <Message mode=”inbound”> <oid><Var>PaymentID</Var></oid> <protocol>Protocol</protocol> <sender>SenderPublicKey</sender> <receiver>ContractPublicKey</receiver> <content>
<Var>Amount</Var> </content> </Message> </event> <body> <Naf> The same workflow holds for rights as well. The fact that a party has the ability to call (or schedule) execution when they want, gives a sense of control to stakeholders with regards to when actions are executed and transaction costs are incurred. Due to the lower compute costs involved with lazy execution, it is a popular way of designing smart contract rules.
Active reaction rules poll in order to verify whether or not an event has taken place by checking the changes to the state of the smart contract. This method does not require an additional smart contract that serves as the scheduler. All code can be part of one smart contract. In this example, we verify every hour through an <event>, whether or not a payment has been made that changed the state or settled an obligation from the sender to the receiver. Similar to lazy execution, once the condition is fulfilled, the smart contract triggers an automatic response message <action>, which sends a <Message> to the blockchain network to settle the balance. <Reaction style=”active”> <event> <Reaction> <event> This conceptual paper examines rule definition for commitment-based smart contracts using Reaction RuleML as the declarative smart contract language. We have distinguished two execution modes for smart contracts: lazy execution and eager execution. A commitment based smart contract code example is provided for each execution mode in order to illustrate how rules can be coded. These code examples comply to nonexhaustive design considerations with regards to reliability and accountability. Since both methods are used in parallel in practice, the paper aimed to provide a sufficient introduction to these modes and its semantics.
The Reaction RuleML examples in this paper are a first step. An important next step for the development of commitment based smart contracts as a concept is to apply it in distinctive use-cases and implementation options, as well as the verification of input events, in particular when these events are outside the blockchain. In addition, the code examples could be simplified by extending Reaction RuleML with dedicated properties for commitment based smart contracts.