Keywords

1 Introduction

Business processes are an acknowledged means to describe working procedures in organizations [1]. Activities, their ordering, the data they work on, and organizational responsibilities can be represented in business processes, for instance using the Business Process Model and Notation (BPMN) [2]. Recently, BPMN has been accompanied by the Decision Model and Notation (DMN) [3] standard to capture decision structure and decision logic, thereby achieving a separation of concerns of process and decision logic [4]. More and more companies use both standards to describe business processes and decisions taken by them. Process enactment architectures are enhanced by decision engines that are capable of executing decision logic during process executions.

While we currently witness a strong uptake of decision management in industry, decision models are almost exclusively used to represent internal decisions of a company, such as whether a specific credit can be granted or not. However, many decisions are linked to more than one process and are part of interacting business processes. Such processes have been subject to behavioral analysis [1, 5].

To address the security and transparency needs of interacting business processes, recently blockchain technology was proposed as an enactment platform for interacting business processes [6]. Blockchains enable the execution of interacting processes through software code to be run on a blockchain – so-called smart contracts – even if the participants do not trust each other.

While this work introduces blockchain technology to execute interacting processes, it does not address decisions that are taken by them. To close this gap, in this paper we propose an approach to execute DMN decision models on an Ethereum blockchain, thereby improving security, transparency, and auditing of decisions taken by multiple interacting business processes. The approach is based on a mapping of DMN decision models expressed in the language S-FEEL to Solidity, the programming language of the Ethereum blockchain [7].

The remainder of this paper is structured as follows. In Sect. 2 we provide an overview of DMN and of relevant aspects of blockchain technology. Section 3 contains the mapping of DMN decision models to Ethereum smart contracts. The approach is evaluated with respect to the blockchain specific costs in Sect. 4. An overview of related work is provided in Sect. 5. We discuss our research in Sect. 6.

2 Background

DMN decision models express requirements and logic of decisions. While the execution of DMN in process orchestrations can be achieved by traditional software systems, such as rule engines, decisions taken during interacting processes have not been investigated. We claim that blockchain technology proves to be useful in such settings due to a set of properties, which are provided in this section. First, we introduce the reader to decision models by means of a running example.

2.1 DMN

Decision Model and Notation (DMN) is a standard of the Object Management Group (OMG) to model operative decisions of enterprises. A decision model considers two layers: the requirements and the logic. The former provides a high level view on the information required for a decision, while the latter provides detailed information on how to take a decision [3].

For the remainder of this paper, we consider the following example: a manufacturer of bearings offers his customers reimbursement for delivered defective units. Therefore, a decision provides the fine as a ratio of the purchase price. In order to perform the decision, both manufacturer and customer must provide data. Figure 1 depicts the respective Decision Requirements Diagram (DRD), a graphical representation of the decisions and their dependencies. A node represents an entity, such as data (rounded shapes) and decisions (rectangles). The edges represent the information requirement relation indicating that data or decision results are required by a decision. The example consists of two decisions: SLA (service level agreement) and fine. SLA requires years as customer and number of units as data input. The decision fine requires the output of SLA and, additionally, the ratio of defective units. We marked the defective units in gray because it is contributed by the customer. The other (white) data inputs are provided by the manufacturer.

Fig. 1.
figure 1

Decision requirements diagram for the scenario; coloring of data input indicates the provider of the respective data, as detailed in the text.

Full size image

On a second level, decision models specify the decision logic. DMN offers various notations, but we solely consider decision tables because they are most widely used. The decision tables that we use in this paper represent rules horizontally. A set of conditions on the data inputs is followed by specific decision outputs.

Table 1. Decision table for the SLA
Full size table
Table 2. Decision table for the fine
Full size table

Tables 1 and 2 depict the decision tables for our scenario. The table body consists of rules (i.e. four for SLA). In addition, the table header provides meta information. It specifies the names and data types of inputs and outputs: years as customer and number of units are numbers, the SLA is an enumeration with the possible values 1 and 2. The upper left cell of the decision table contains the hit-policy. The hit-policy determines in which order the rules of the table are evaluated. The used hit-policy unique (U) indicates that no two rules overlap in their conditions. Thus, at most one rule triggers for a specific input, and the evaluation order does not matter. More generally, we distinguish between single and multi-hit policies depending on the number of rules that contribute to the decision’s result (one vs. multiple). Table 3 provides an overview of the different hit policies. In this paper, we map all the elements of DMN decision models and decision tables in particular to Source code for Ethereum. This includes all elements mentioned above.

Table 3. A description of DMN hit-policies
Full size table

2.2 Blockchain Technology

Blockchain technology emerged with Bitcoin: a cryptocurrency whose transactions are stored on a blockchain [8]. Ever since, the technology has been adapted for different domains (e.g. BPM and logistics) and for various use-cases. However, all adaptations rely on a set of core properties [9].

A blockchain is a linked list that uses hash pointers. It is shared by a peer-to-peer network. Each element of the list is a block that stores transactions. The blockchain represents a history of transactions that allows us to restore all past and the present states. Some nodes, called miners, propose new blocks and find consensus about the set and order of transactions. Once this is achieved, all nodes share the same blockchain [10, 11]. Thereby, relative immutability is reached: every node can detect inconsistent changes (e.g. changing the past) and reject respective transactions. However, if a majority of nodes agrees on a different version, the chain is adapted accordingly. The probability of a block being immutable increases as the number of succeeding blocks grows.

Another feature of (most) blockchains are cryptocurrencies. They are inherent currencies that are passed between users to reward mining, to pay for transactions, or to perform financial transactions. The so called 2nd generation of blockchains additionally supports complex smart contracts: Turing complete scripts, which are stored on the ledger and are executed by all miners. Thereby, immutability, publicity, and cryptocurrencies become available for computer programs. Smart contracts are like classes in an object-oriented language: they encapsulate data and functionality and can be instantiated.

Blockchains’ properties are powerful since they enable interactions between participants without the need for trust. In recent research Mendling and others investigated the challenges and opportunities for BPM [12]. For one, process choreographies require trust between participants, but, as we have seen before, a blockchain can be a replacement by offering tamper-proofed monitoring capabilities. Implementations of process choreographies exist for both the Ethereum [6] and the Bitcoin [13] blockchain.

3 Generation of Decision Contracts from DMN

In general, contracts are agreements, about services, products, and money that participants agree to provide to each other. Decisions can be part of these agreements. In order to make a decision, the information has to be provided and logic needs to be executed. In an interactive process, each participant might contribute data to a single decision. Thus, participants need to exchange data to perform a certain decision. The DMN standard suggests to map each decision of a decision model to a decision taken by a single participant. Consequently, each participant will communicate the result of their decision such that others can base their decisions on this result. Figure 2 shows a respective business process collaboration for the running example: the manufacturer determines the SLA, the output of which is used as input by the customer to calculate the fine. In conclusion both decision results are exchanged.

Fig. 2.
figure 2

DMN suggestion for decisions in interactive processes applied to the running example

Full size image

This method of realizing decisions has a major drawback: due to the lack of a central mediator or state, participants must trust each other to provide the correct information and to take the decisions in the right way. In case of a fraud, conflict resolution is difficult: no accountable source of information exists and an expensive lawsuit can follow.

Weber et al. showed that a blockchain provides accountable audits and can be used as a trusted intermediary for interactive processes [6]. In the same fashion, we use blockchain as an intermediary for decisions. The respective process collaboration via blockchain is depicted in Fig. 3. We use Ethereum and smart contracts to specify the executable decision logic. Further, participants can contribute data to a decision via transactions, and smart contracts execute and log decisions. This leads to a public audit trail, which consists of all information required to reconstruct the decision making process: who provided which inputs, what are the results, and how was the decision made.

Fig. 3.
figure 3

Blockchain based implementation of a sample decision in interactive processes

Full size image

Figure 4 depicts the mapping on the model level, where concrete decision tables are defined. As mentioned, a decision table defines the logic of a decision: it specifies inputs, outputs, rules, and a hit-policy. In our approach, we map each DMN decision table to a respective smart contract, which we call decision contract. A decision contract encapsulates the logic of the translated decision table and represents it in a function (called decide). Further, we provide two auxiliary structures: a state contract and a factory contract. The state contract encapsulates all inputs and outputs. The decision contract can, therefore, be implemented in a stateless manner following the best practices of DMN. Whenever a decision should be made, we provide a state contract instance with the respective data to the decision contract, which updates the outputs (inside the state contract) accordingly. The factory contract provides auxiliary functions for instantiation: it creates and holds new state contract instances and lazily initializes all decision contracts of a respective decision model.

Fig. 4.
figure 4

Mapping of DMN decisions (left) to Ethereum smart contracts (right), smart contracts are deployed on a blockchain

Full size image

The DMN standard provides the FEEL expression language to describe execution semantics of decisions. A subset of this language is called S-FEEL and can be used to express decision tables. Such a decision table consists of inputs and outputs, whereby, outputs can be input for other decision tables. A rule of a S-FEEL decision table consists of unary tests for each input (statements that evaluate to true or false for a specific value) and an expression for each output.

Our approach provides a translation of all these elements to Solidity source code. Figure 5 shows the mapping of abstract S-FEEL elements to Solidity code templates. The code is refined as further elements of the decision table are mapped (e.g. for each model, we create one state contract, for each input and output clause we add a respective attribute with a setter method to it). A decision contract additionally has an event: a mechanism to broadcast information. It is used to publish the results of a decision. For each decision table, we create one decision contract and for each rule we create/extend an if-statement by adding the unary tests to its condition and the output expression to its consequence. However, different hit policies require different rule generations. We abstracted from this details in Fig. 5 but described them in Table 4.

Fig. 5.
figure 5

Mapping of DMN elements to Solidity elements

Full size image
Table 4. Handling of different hit-policies in DecisionContracts
Full size table
Fig. 6.
figure 6

Sequence diagram showing the interactions of the sample contracts

Full size image

3.1 Interaction with the Decision Contracts

In order to persist the participant’s agreement on a blockchain, it is sufficient to deploy a single instance of the FactoryContract The FactoryContract is capable of instantiating decision contracts and the state contract and, thereby includes, the binary representation of the StateContract and the decision contracts (SLADecisionContract, FineDecisionContract). For the remainder we assume that a respective instance has been deployed.

The sequence diagram in Fig. 6 shows the interaction of participants with smart contracts as well as among smart contracts. A participant (e.g. the manufacturer) calls the FactoryContract to create a new instance. If it has not been called before it initializes the decision contracts (i.e. SLADecisionContract and FineDecisionContract), and then creates a new StateContract instance with references to the decisions. The StateContract’s address is returned to the caller. Participants can then set input variables (i.e. years as customer, number of units, and defective units) on the StateContract, and thereby, provide the requirements for a decision. Once all decision requirements are fulfilled, a participant calls the decision(s) providing a StateContract instance. The decision logic is executed, outputs are determined, and eventually the state contract is updated. In this example, the output of SLA together with the defective units fulfills the requirements for the second decision, which can then be called.

4 Evaluation

To evaluate the approach, we investigate its applicability on the basis of a set of real life decision models. In addition, we provide an empirical cost evaluation of the example introduced above.

4.1 Applicability of the Mapping

To study the applicability of the mapping on real life decision models, we implemented the mapping in a proof-of-concept prototype. The prototype consists of a compiler, which translates DMN models (serialized as XML) to Solidity source code and is integrated into the Camunda modelerFootnote 1. In this way, the Solidity source code is automatically derived from the decision model during design time.

Since Solidity is a Turing-complete language, S-FEEL can be translated to Solidity. However, due to Solidity’s restricted type system, we encountered some engineering issues when defining the mapping.

S-FEEL’s type Number is a generic floating-point number, but Solidity supports only integers and fractions. Therefore, floating-point numbers need to be represented with integers, which requires implementing auxiliary functions, for example, to compare two integer-based floating-point numbers. Another limitation comes from the fact that strings are stored as byte-arrays in Solidity, but only one-dimensional arrays can be dynamically sized. Therefore, lists of strings (requiring two-dimensional arrays) must be limited to items of a fixed length. Such lists are, for instance, returned by multi-hit decision tables.

We used the prototype to translate a real life set of decision tables to Solidity and from there to byte code for the Ethereum virtual machine. Our test data set consisted of 51 DMN models that were designed by participants of an online course on BPMN and DMNFootnote 2. The prototype translated 46 of 51 models into Solidity code. Of the remaining five, two models were missing an output definition (optional in DMN but required for our compiler) and three were syntactically incorrect. Afterwards, we ran the Solidity compiler to produce byte code for the Ethereum virtual machine. Out of the 46 remaining models 31 were compiled successfully. Two tables used long strings and compiled after adapting the data types manually. Eleven of the other 13 were not compiled, because identifiers for inputs or outputs used characters (e.g., brackets) or words (e.g., “contract”) that are reserved words in Solidity. The remaining two decision models used comparison operators (\(<, \le , =, \ge ,>\)) on sets, which is forbidden in S-FEEL and in Solidity. These results of the investigation are summarized in Fig. 7.

Fig. 7.
figure 7

Results of compiling the decision model test set to Solidity/Ethereum and reasons for failure

Full size image

To conclude, the majority of the decision models could be translated to executable Solidity code. Problems can occur because models are often used for documentation and not defined precisely enough for execution. Furthermore, special guidance during the modeling process could be helpful to prevent the use of reserved words or characters or from omitting necessary information.

4.2 Cost Evaluation

Ethereum is a second generation blockchain that integrates the full capabilities of a 1st generation blockchain—including a cryptocurrency called Ether. It is used to pay for transactions, i.e., all operations that store information in the blockchain. In our scenario, creating new contract instances, calling functions, and raising events causes transactions. In Ethereum, transaction costs are calculated in gas. Gas is an abstract unit that is mapped to Ether via a dynamic gas-price; in this way, the transaction costs can stay stable even though the value of Ether fluctuates.

Table 5. Instantiation costs for each contract and impact of features (based on avg. gas price and exchange rate on 11/07/2017 from https://etherscan.io/chart/gasprice)
Full size table

The costs to instantiate smart contracts depend mainly on the required storage. Table 5 lists the cost for each contract after manually optimizing the used data types and the respective savings. The FactoryContract is the most expensive one (5€) because it stores an array of instances, which can grow indefinitely and holds the definition of the other contracts to initialize them. The FactoryContract is for convenience: its functionality can be executed off-chain. This would save more than half of the instantiation costs. Moreover, we showed before that DMN data types cannot be mapped perfectly to Solidity types. In general, the latter supports more precise types, for example, integers of different sizes; thus, we can optimize them manually. However, this optimization has a relatively small impact on the costs saving only up to 1.23€.

All but the StateContract are initialized only once; if a decision is executed frequently, high instantiation costs can be tolerated. See Table 5 for details. The baseline costs of a single instance is the sum of instantiating the State-Contract, calling setters, and executing the decision logic (includes setters for the outcome). Figure 8 depicts the costs for a single instance. From bottom to top we sum the different operations. We show both a version with and a version without optimized types. It should come as no surprise that the instantiation is the most expensive operation. One can see that the costs of a single instance are about 1.70€ and type optimization saves up only 0.10€.

Fig. 8.
figure 8

Cost of an instance in gas and Euro—bottom to top: different operations, left to right: additional features

Full size image

5 Related Work

Within the BPM community increasing interest is spent on blockchain technology. Mendling et al. give an overview of challenges and opportunities that arise from combining BPM and blockchains [12]. So far, existing research in this direction focuses mostly on business process choreographies. These efforts include an Ethereum based solution to enable and monitor choreographies [6]. All messages are logged and state progression is monitored via the blockchain. The current consensus on the blockchain describes the current state of the choreography and conform state progression is enforced. This concept has also been applied to the Bitcoin blockchain [13].

A similar approach is Caterpillar—a blockchain enabled process engine [14]. However, none of these approaches consider decisions and decision models. In Caterpillar XOR gateways are implemented by manually defining Solidity code snippets. Implementing XOR gateways for choreographies is a challenging task since a common understanding of both data and logic is required [2].

We propose smart contracts as a solution for implementing collaborative business decisions. The term smart contract has been formed by Szabo [15]. Kõlvart et al. summarize different smart contract developments and describe some opportunities of smart contracts on blockchains [16]. However, current smart contracts are implemented using procedural languages such as Solidity. In [17] Idelberger et al. discuss using logical programming languages instead because the respective contracts are more comprehensible and less error-prone. We build upon this idea by combining logical programming (decision tables) with a model based approach.

Most blockchains are public. This limits their usage to non-sensitive data [18]. The Ethereum community discusses this limitation and proposes secret sharing decentralized autonomous organizations that use data partitioning to sustain privacy [19]. Kosba and others take this idea further and present Hawk: a blockchain, which supports smart contracts and protects privacy through encryption [20]. Privacy protecting blockchains (supporting smart contracts), are not ready for productive usage, yet. Therefore, private and permissioned blockchains can be used to create a peer-to-peer network with a restricted set of nodes.

6 Conclusion and Discussion

Collaborative decisions span across multiple processes and organizations. They apply to interacting business process and influence their behavior. In these cases, it is difficult to establish a trusted exchange of data and a common understanding of both the information and the decision logic [2]. Therefore, we proposed the use of a decentralized blockchain as an intermediary entity. It saves both the data that is required for the decision and the underlying logic. Based on the blockchain technology, trust becomes obsolete due to a technical and reliable mechanism. We also showed a prototypical implementation that automatically translates DMN models into smart contracts. However, current limitations of the type system of Solidity (a language to write smart contracts) requires manual adjustment and workarounds, for example, to handle floating-point numbers.

To make our approach feasible, we extended the mapping with additional features: A push mechanism calls decisions automatically from the state contract. In addition, access rights limit the write access for each attribute to a set of participants or contracts (addresses); hence, unauthorized users cannot temper with the data. Further, only decision contracts can set their respective outputs.

An important issue of modern blockchains, such as Ethereum, is that all data is public. Everything saved to the ledger is visible to every node. This is not an issue for “public” contracts such as the terms of service of a company. However, sensitive or enterprise internal data cannot be stored on the blockchain. Alternatively, one can build a private or permissioned blockchain or use a new kind of blockchain such as Hawk [20] that offers built-in privacy mechanisms such as secret sharing decentralized autonomous organizations [19] and zero-knowledge proofs.

To conclude, DMN decisions can be implemented with blockchain technology making trust and a centralized third party, such as a DMN decision service, obsolete. Therefore, we closed the gap left open by previous work to execute interacting business processes on a blockchain by also taking the decision perspective into account.