Content uploaded by Jan Ladleif
Author content
All content in this area was uploaded by Jan Ladleif on Jul 17, 2020
Content may be subject to copyright.
External Data Monitoring Using Oracles in
Blockchain-Based Process Execution
Jan Ladleif1, Ingo Weber2, and Mathias Weske1
1Hasso Plattner Institute, University of Potsdam, Germany
{jan.ladleif,mathias.weske}@hpi.de
2Chair of Software and Business Engineering, Technische Universitaet Berlin,
Germany, ingo.weber@tu-berlin.de
Abstract. In blockchain-based process execution, operational aspects
of business processes are encoded in smart contracts on blockchains, en-
abling powerful auditing and compliance capabilities due to the plat-
forms’ trust and integrity guarantees. However, smart contracts are sub-
ject to the blockchain’s conceptual limitations, which particularly re-
strict the real-time integration of external data. This potentially leads
to non-compliant runtime behavior of process instances when data up-
dates are missed and conditional constraints are wrongly evaluated. In
this paper, we analyze the semantics of established external data inter-
action patterns in business processes with regards to their support on
blockchain platforms. We extend and propose various oracle-based im-
plementation strategies to alleviate conceptual issues independent of the
concrete blockchain used, and discuss their properties and merits.
Keywords: Smart contracts Data monitoring Oracle architectures.
1 Introduction
Business processes and choreographies produce and maintain diverse sets of
data [13]. Account balances, customer details, or invoices are only some ex-
amples of data influencing the flow of individual process instances, which often
need to react to changes in data immediately to stay compliant and competitive
in today’s interconnected business environments. In Business Process Manage-
ment (BPM), it is the responsibility of the process engine to make sure of that—
irrespective of whether the data is local to a process instance, part of the process
environment at an organization, or managed externally by third parties [13].
Especially monitoring data hosted at third-party entities poses challenges,
which has been particularly evident in recent moves towards blockchain-based
process execution [10,14]. Here, process specifications containing data descrip-
tors and conditions are transformed into one or more smart contracts encoding
the process logic. While smart contracts readily store and engage with inter-
nal data, continuous monitoring of external data is restricted by the idiosyn-
cratic properties of common blockchain technologies: Smart contracts operate
in a closed-world environment without access to external services for integrity
2 J. Ladleif et al.
reasons [17]; and they are inherently passive, being exclusively driven via syn-
chronously executed transactions [5].
Current state-of-the-art frameworks like Caterpillar [8] and Lorikeet [9] prin-
cipally follow this philosophy and regard the blockchain as the single source of
truth, as a consequence lacking continuous external data monitoring capabili-
ties. They also largely omit the capabilities of oracle patterns, which somewhat
mitigate the closed-world assumption [16], but raise questions as to the trustwor-
thiness of the provided data [3]. This restricts the range of supported processes,
and remains an impediment to the wide-spread acceptance of blockchain-based
process execution approaches in practice.
In this paper, we pave the way towards external data monitoring in processes
within the confines of current blockchain environments. Our contribution is two-
fold: First, we formally describe the semantics of general monitoring patterns,
and transfer them to the transaction-driven blockchain environment. Second, we
give structured insights into the challenges faced when using existing oracle ap-
proaches to implement compliant behavior—in particular avoiding that crucial
data updates may be missed, and resolving temporal conflicts in deferred choice
scenarios. We suggest various novel strategies and architectures to this end.
The paper is structured as follows. First, preliminary knowledge is conveyed
in Sect. 2. We then formally introduce the semantics of data monitoring pat-
terns in business processes in Sect. 3. Oracle-based implementations and novel
solutions to certain runtime issues are developed in Sect. 4. Our results are eval-
uated in Sect. 5, and compared to related work in Sect. 6. The paper closes with
a discussion in Sect. 7and a conclusion in Sect. 8.
2 Preliminaries
In this section, we establish basic notions of data interaction patterns in busi-
ness processes with a focus on external data monitoring. We then describe core
concepts of blockchain technology and blockchain-based process execution.
2.1 Data Interaction Patterns
In their seminal work, Russell et al. describe patterns of data visibility and inter-
action in business processes [13]. They arrive at an eight-level hierarchy of data,
starting at task data accessible by single tasks, up to environment data includ-
ing services and databases outside the process engine’s control. In the context
of the latter external environment data, Russell et al. stress the importance of
mechanisms which provide “new items of data as they become available” [13]
from outside sources—that is, to continuously monitor the data.
The process shown in Fig. 1describes the ticketing system of a railway com-
pany, which we will use as a running example throughout the paper, modeled us-
ing a Business Process Model and Notation (BPMN) collaboration diagram [11].
It contains many references to internal data such as the “request” data object.
There are various instances of discrete external data interaction as well. The
External Data Monitoring Using Oracles 3
Railway Company
ticket request
received
send ticket
confirmation
Passenger
g
e2
e1
check
occupancy
request
[request granted]
route closure
reported
severe weather
warning issued
send refund
send voucher
send rejection
complete
reservation
details
train
departed
Fig. 1: Running example of a collaboration between a passenger and a railway
company during a simple ticketing scenario
message flows between the passenger and the railway company, for example, con-
stitute mutual external data exchanges transferring information like the ticket
request and reservation details.
The conditional events e1and e2after the event-based gateway ggo a step
further and wait for some condition to become true, in this case exceptional
circumstances like a severe weather warning or a route closure which result in the
train’s cancellation. Ensuring these events are captured in the right order requires
continuous monitoring of the external services involved [11, Ch. 10.5]. The exact
“specification of mechanisms to access such [environment] states” [11, p. 240] is
not discussed in the BPMN standard and deliberately left as an implementation
detail for concrete process engines. Smart contracts on blockchain platforms, for
example, may use oracles for that purpose.
2.2 Blockchain Technology and Oracles
Blockchain technology has moved on from being a purely financial instrument
and has emerged as a core application platform [17]. Applications benefit from
cryptographic algorithms, consensus protocols, and incentivization schemes re-
sulting in strong integrity, transparency, and immutability guarantees [14]. To
this end, executable application code and its associated state—generally called
asmart contract—are stored directly on the blockchain.
Smart contracts are not constantly running, but exclusively triggered using
transactions. Code executed in the scope of a transaction is subject to a strict
closed-world assumption, i.e., data external to the blockchain which could be
tampered with or disappear can not be accessed. Rather, the blockchain needs
to be entirely self-contained for later validation. This has severe implications for
blockchain-based process execution, in which participants drive the process via
transactions to ensure run time compliance and after-the-fact auditing.
4 J. Ladleif et al.
Blockchain
Consumer
SC
User
Oracle
SC
value
Provider
update(value)
1.1
store
value
1.2
2.1 action( )
use
value
2.3
2.2
get( )
: value
(a) Storage oracle
Provider
Blockchain
Consumer
SC
User
Oracle
SC
Event Layer
1.1 action()
1.2
request( )
1.3
emit
request
listen
2.1 callback(value)
use
value
2.2
(b) Request-response oracle
Fig. 2: Basic oracle architectures
Common patterns to bypass the closed-world assumption are oracles, which
are operated by third-party providers and supply external data to the block-
chain [15,16]. While there are various architectures [1], two general principles
illustrated in Fig. 2are usually followed depending on whether data is perma-
nently stored on the blockchain or delivered to it on request.
The former, which we will call storage oracles (see Fig. 2a), regularly update
data inside a publicly known smart contract (1.1, 1.2). The value of this data can
then be read by other smart contracts (2.1–2.3). For example, OrFeed3provides
current cryptocurrency exchange rates on Ethereum using this mechanism. Re-
quest-response oracles (see Fig. 2b), on the other hand, operate smart contracts
which can be called with specific requests, for example queries to a web service
(1.1, 1.2). These requests are emitted using an event layer, which the provider
actively listens to (1.3). The query is performed off-chain, and the provider calls
back the original contract with the result of the query (2.1, 2.2). Provable4is a
prominent real-world example of such a general-purpose oracle service.
3 External Data Monitoring Semantics
When processes reach states in which they wait for some external events and con-
ditions, relevant data sources need to be monitored. In this section we formally
describe the semantics of such patterns, which we will call monitoring points,
and discuss their support in a transaction-driven setting like the blockchain.
3.1 Core Semantics of Monitoring Points
In the pattern literature (see Sect. 2), Russell et al. describe variants of exter-
nal data interaction to transfer data between the environment and the process
engine [13], e.g., off-chain data to on-chain smart contracts. For example, the
conditional events e1and e2in the ticketing process in Fig. 1require data from
3https://orfeed.org/docs/, accessed 2020-05-25
4https://provable.xyz/, accessed 2020-05-25
External Data Monitoring Using Oracles 5
outside the process engine, or blockchain for that matter. In different languages
and even BPMN itself, there are various other elements used to express such
constraints. To argue more generally, we will refer to instances of this behavior
as monitoring points (for external data) in the following:
Definition 1 (monitoring points). Let Mbe the set of monitoring points and
S={ACTIVE,TRIGGERED,ABORTED}be the set of monitoring lifecycle states.
The function state :M→Smaps each monitoring point to a lifecycle state.
inactive
TRIGGERED ABORTED
activate
trigger
(condition evalu-
ates to true)
abort
(monitoring ends
or is withdrawn)
ACTIVE
Fig. 3: Monitoring point lifecycle
In our running example in Fig. 1two
monitoring points occur once the pro-
cess reaches the event-based gateway g;
one for monitoring the weather warn-
ing service (e1), and one for monitoring
the route closure service (e2). For sim-
plicity, we label the monitoring points
with the event labels, i.e., e1, e2∈M
and state(e1) = state(e2) = ACTIVE af-
ter reaching g. In the following, we will
refer to these examples frequently.
Figure 3shows the possible transitions between lifecycle states. Once they are
ACTIVE, monitoring points can either be triggered once their associated condition
evaluates to true, or they are eventually aborted. An abort may occur if the
monitoring ends without the condition arising, e.g., when the process is stopped,
or a different monitoring point is triggered first [11]. The latter may happen in
deferred choice scenarios, in which process decisions are “based on environmental
input” and create a “race between different branches” [12]. We will refer to such
competitors as siblings:
Definition 2 (siblings). Let siblings :M→2Mbe a function mapping each
monitoring point to its set of siblings, i.e., monitoring points within the same
deferred choice pattern.
The monitoring points e1and e2, for example, are mutual siblings since they
follow an event-based gateway g, that is, e1∈siblings(e2) and vice-versa.
3.2 Extension to Transaction-Driven Environments
The core semantics of monitoring points assume permanent tracking to trigger
them promptly once the associated condition evaluates to true. This, however,
does not align with transaction-driven semantics, where lifecycle transitions must
be explicitly invoked as part of synchronously executed transactions [5].
Consider the timeline in Fig. 4, which shows a sample scenario of the ticketing
system (see Fig. 1) with real-world off-chain data indicated along the time line
at the top. Assuming they were activated at some earlier time, both e1and e2
are expected to reach a final state when the severe weather warning is issued,
triggering e1and thus aborting e2.
6 J. Ladleif et al.
time
Severe weather
warning issued
Severe weather
warning expired
Real-world
events
Route closure
reported
tx1(g reached)
e1
e2
e1
e2
ACTIVE
TRIGGERED
ABORTED
inactive
inactive TRIGGERED?
ACTIVE
ACTIVE
Core
semantics
Transaction-
driven
tx2(re-evaluate)
ABORTED?
ACTIVE
Fig. 4: Timeline of transactions invoking a process smart contract alongside real-
world external data on the example of the ticketing process
For the transaction-driven setting, assume tx1and tx2invoke possible lifecy-
cle transitions and convey the current state of external data. When the gateway
is reached in tx1, none of the events trigger and they remain in ACTIVE until
tx2initiates a re-evaluation. This leads to a temporal conflict: At this point, not
only has the severe weather warning expired, but an additional route closure
was reported. Taking an isolated data snapshot at the point of time of tx2being
issued wrongly implies that e2should be triggered instead of e1.
This example shows that it is necessary to not only check a condition at the
atomic point in time when a transaction is executed, but take into account the
whole timeline since monitoring started, i.e., a monitoring point was activated:
Definition 3 (activation time). Let Tbe a totally ordered time domain con-
taining timestamps. For each monitoring point m∈M, let tm∈Tbe the times-
tamp at which monitoring started.
For the sake of simplicity, we assume monitoring starts when the lifecycle
state ACTIVE is reached. Further, we define a timed evaluation function that is
aware of historical states of data:
Definition 4 (timed evaluation). For a monitoring point m∈M, we define
the timed evaluation function evaluate :M×T→T∪ {>} with
evaluate(m, t) := min(t0)for t≤t0∈Tand mevaluated to true at t0
>if no such t0exists
that returns the earliest timestamp after tat which the condition associated to
mevaluated to true, or >with t00 <> ∀t00 ∈Tif that has never been the case.
Intuitively, >can be interpreted as a fixed point arbitrarily far in the future and
always larger than other timestamps, i.e., the “greatest element”.
We now suggest the algorithm in Listing 1to transfer the core monitoring
semantics into the transaction-driven setting under the assumption that a timed
evaluation function is available. The algorithm models a function step that ad-
vances the lifecycle state of a monitoring point m∈M, if possible. We focus on
lifecycle transitions and omit implementation specifics like token propagation.
This function is called in transactions on all relevant monitoring points.
External Data Monitoring Using Oracles 7
Listing 1: Pseudocode algorithm for lifecycle
state updates in transaction-driven settings
function step(m∈M)
1if state(m) = ACTIVE then :
2let result ←evaluate(m, tm)
3if ∃m0∈siblings(m) such that
4evaluate(m0, tm0)< result then :
5state(m)←ABORTED
6else if result 6=>then :
7state(m)←TRIGGERED
The algorithm first determines
whether the monitoring point is
in state ACTIVE (line 1), since
all other states are terminal, af-
ter which the associated condi-
tion is evaluated (line 2). Regard-
less of the result, the algorithm
checks if any of the siblings eval-
uated to true earlier (lines 3, 4),
“winning” the deferred choice, in
which case the the state changes
to ABORTED (line 5). If that is not
the case and mevaluated to true (line 6), the state is set to TRIGGERED (line 7).
Consider the example timeline in Fig. 4again. If the algorithm was applied to
the “route closure reported” monitoring point e2in tx2, it would detect that e1∈
siblings(e2) evaluated to true earlier when a severe weather warning was issued,
and would thus set the state of e2to ABORTED. Independently, calling step on
e1would correctly trigger it. It is important to note here that the algorithm
does not require a certain invocation order—lifecycle transitions are correctly
performed even if calls are delayed or switched.
4 Monitoring Strategies and Architectures Using Oracles
The semantics of monitoring points in transaction-driven environments such as
blockchains work under the assumption that a notion of timed evaluation is
available, that is, data can be queried over time. In this section, we discuss
implementation aspects and develop strategies and architectures to this end.
4.1 Sampling Strategies for Basic Oracles
Basic oracle architectures, specifically history and request-response oracles as
described in Sect. 2, provide discrete access to external data. Consumer smart
contracts call them within a transaction and receive external data valid at that
specific point in time, which already hints at a core issue: There is no way
to query historical data and resolve temporal conflicts, the same fundamental
problem present in the abstract case in Fig. 4. Thus, they may potentially miss
data updates and can not be used to implement fully compliant semantics.
However, basic oracle architectures are available in practice [1], and in the
following we propose several strategies to cope with their limitations and ap-
proximate the intended semantics using them. Arguably the probability of miss-
ing updates can be reduced by increasing the sampling frequency and lowering
the amount of time that passes between subsequent oracle calls. For example,
weather warnings are often only updated a few times within an hour, so any
such frequency would be sufficient. The general goal is to perform the sampling
in a way which limits implementation and transaction overhead.
8 J. Ladleif et al.
instance
txs
(ii)
context
txs
(i)
polling txs
(iii)
Fig. 5: Sampling strategies re-
lated to a monitoring point
To this end, we introduce three sampling
strategies (see Fig. 5) which use different sets
of transactions to sample an oracle and evaluate
a monitoring point. First, some transactions are
part of the immediate context of a monitoring
point. This includes all transactions which ac-
tivate it, e.g., because it was reached as a part
of the process execution. In the ticketing system
(see Fig. 1), this could be the case for e1and
e2with the transaction targeting “send ticket
confirmation”. Additionally, the context also in-
cludes those transactions specifically but manu-
ally issued by some participant to re-evaluate a monitoring point.
As a second sampling strategy, the set of context transactions can be aug-
mented with instance transactions targeting any element of the process. If a
monitoring point happens to be ACTIVE during one of those transactions, its
evaluation could simply be performed “on the side” even though they are not
directly related. For example, this is the case for the monitoring points e1and
e2and all transactions happening as a part of the parallel “complete reservation
details” sub-process (see Fig. 1).
As a third strategy, additional transactions with no other purpose but peri-
odically polling and evaluating monitoring points may be introduced. They are
similar to manual re-evaluation transactions as discussed before, but are instead
issued automatically in regular intervals, either by a designated participant or
a dedicated system component. Alternatively, the incentivized execution pat-
tern [16] could be used, where third-party agents issue those requests and are
rewarded, e.g., by small payments of tokens or cryptocurrency if available.
Figure 6shows an exemplary timeline view of how the strategies work on the
example of the weather warning monitoring point e1(see Fig. 1) and a storage
0 1 2
2 3
Oracle provider
Storage oracle
Blockchain
Smart Contracts
tx1tx2
ACTIVE
inactive
0 2 Process
state(e1)
Context
strategy
tx1
ACTIVE
inactive
0Process
state(e1)
tx22
txi1Instance
strategy
tx1
ACTIVE
inactive
0Process
state(e1)
11 2
TRIGGERED
3Polling
strategy
0 1 2 3 2 Real-world
warning level
time
Fig. 6: Sampling strategies on the example of the storage oracle and the weather
warning monitoring point e1
External Data Monitoring Using Oracles 9
oracle. The request-response oracle would be used similarly, shifting the evalu-
ation of the monitoring point into the callback transaction. Suppose now that
the weather warning level is a scalar value between 0 and 3, where 3 designates
a severe weather warning. For all strategies, a context transaction tx1initially
activates e1but does not yet trigger it. For the context strategy, only one later
transaction tx2is issued, but still does not trigger e1—even though the weather
warning actually was at level 3 for a time as indicated by the thick vertical
line. For the instance strategy another transaction txi, e.g., in the course of the
“complete reservation details” sub-process, is issued, albeit before the relevant
weather warning. Only the polling strategy actually notices and reacts correctly
to the weather warning because the polling frequency was sufficiently high.
4.2 Extended Oracle Architectures
While the sampling strategies decrease the probability of missing updates, gaps
may still occur. The core problem is the lack of a continuous view on the external
data, which can not be reliably solved by just increasing the sampling frequency
of the oracle, in the general case. Instead, we propose novel extensions to the basic
oracle architectures described before which approach the problem from two sides:
(i) by providing a historical perspective on data that allows consumers to resolve
temporal conflicts after-the-fact; and (ii) by immediate communication using a
publish-subscribe pattern, avoiding temporal conflicts before they happen.
History Oracles. The idea of history oracles is to provide a historical values on
top of current data. Consumers can then determine at which point in time a value
changed to first fulfill the condition associated with a monitoring point. This
would allow straightforward implementations of a timed evaluation function.
In principle, both storage and request-response oracles can be extended with
these capabilities, requiring the oracle provider to store data on-chain or off-
chain, respectively, subject to technological storage limitations. We will call those
variants on-chain and off-chain history oracles.
The top half of Fig. 7shows how the former, an on-chain history oracle, could
be used to resolve the temporal conflict of the weather warning monitoring point
e1(see Fig. 1). As before, tx1activates e1but does not trigger it yet. In tx2,
however, the situation is now different than for basic storage oracles (see Fig. 6):
Using the history, the severe weather warning which was issued and expired in
the meantime can be detected. This leads to the correct triggering of e1.
Publish-Subscribe Oracles. Further, we propose publish-subscribe oracles.
Instead of only receiving the data once, consumers receive new data immediately
as it changes as long as they are subscribed, i.e., an active monitoring point
requires the data. Thus, the process can promptly react to changes in data and
trigger monitoring points accordingly before any temporal conflicts arise. This
is a fundamental difference to history oracles, which may exhibit some delay
in triggering a monitoring point depending on when they are called, but do
not require proactive subscription. Again, the publish-subscribe oracle can be
implemented on top of both storage and request-response oracles, depending on
10 J. Ladleif et al.
0 1 2
2 3
tx1tx2
1
tx1
ACTIVE
inactive TRIGGERED
ACTIVE TRIGGERED
inactive
0 3
Blockchain
Smart
Contracts
Blockchain
Smart
Contracts
On-chain
history
oracle
Off-chain
publish-
subscribe
oracle
Oracle provider
Oracle
Process
Oracle provider
Oracle
Process
0 1 2 3 2
time
Real-world
warning level
state(e1)
state(e1)
32
Fig. 7: Usage of novel oracle architectures on the monitoring point e1
whether the subscription is handled on-chain by the oracle smart contract or off-
chain by the oracle provider, respectively.
The lower half of Fig. 7shows the same weather warning example as before
for the off-chain publish-subscribe oracle. As is evident, no updates are missed
anymore since the process receives all of them directly. The first two updates do
not trigger e1, but the third finally does. Unsubscribing is not explicitly shown
in the figure, but may be performed if no further updates are required.
Condition Interfaces. A further variant of both the history as well as the
publish-subscribe oracles concerns the interface. Until now, we assumed that the
process smart contract queries the data, and implements the timed evaluation
function used in the step algorithm (see Lst. 1) locally. However, one could also
implement the oracles so as to take a condition expression as an input, and only
call back the process once that condition evaluates to true, partly externalizing
the task of monitoring data to the third-party oracle provider. In the weather
example, the condition could filter for warning level 3 only. This may cut down on
the number of callback transactions, especially for the off-chain publish-subscribe
oracle—in Fig. 7, for example, two of the callback transactions would be saved.
5 Results and Preliminary Evaluation
The sampling strategies and oracle architectures introduced support the im-
plementation of monitoring points to varying degrees. In this section, we will
summarize the level of compliance that can be achieved, and give preliminary
arguments as to the overheads incurred by the various approaches from both a
process and an oracle perspective.
Process-Perspective Overhead. From the perspective of the process smart
contract, the overhead of the approaches is gauged using two metrics: (i) the
External Data Monitoring Using Oracles 11
Table 1: Overview of overhead and compliance metrics of the oracle architectures
Oracle Process-perspective overhead Compliance
architecture Sampling
strategy
Oracle
invocations
Additional
transactions
Miss pro-
bability
Temporal
conflicts
Storage oracle context few few high may occur
instance more few medium may occur
polling many many low may occur
Request-response context few few high may occur
oracle instance more few medium may occur
polling many many low may occur
History
oracle
On-chain — few few zero resolved
Off-chain — few few zero resolved
Pub/sub
oracle
On-chain —one none zero avoided
Off-chain —one none zero avoided
number of invocations of the oracle smart contract, (ii) and the number of addi-
tional transactions issued solely to evaluate the monitoring point, which accounts
for reuse of transactions which were scheduled either way to invoke the oracle.
The results are shown in Tab. 1. For the storage and request-response oracles,
the overhead depends on the sampling strategy chosen as each sample requires
one invocation. Notably, the instance strategy wraps extra oracle invocations in
existing transactions. The history oracle essentially incurs the same overhead as
the context strategy. The publish-subscribe oracle architecture only ever needs
a single transaction to subscribe to the oracle, which can be performed on acti-
vation and thus causes little to no overhead.
Oracle-Perspective Overhead. Storage and request-response oracles are al-
ready available in practice and their implementation overhead is well-known; con-
trary to history and publish-subscribe oracles which lack such reference points.
For the history oracle approach, storage considerations are paramount. In
principle, the entire data history must be held, which could induce large stor-
age requirements over time. Especially the on-chain history oracle may become
infeasible quickly as on-chain storage can be prohibitively expensive in practice.
Typically, one would thus opt for storing large amounts of data in off-chain stor-
age, and use the blockchain to ascertain its authenticity using hashes. Arguably,
the off-chain variant is more prone to traffic limitations: If the condition is not
externalized to the oracle, the entire data from the time span requested needs
to be relayed to the consumer smart contract. While many blockchains allow
arbitrary parameter payloads, they too become expensive rapidly.
The publish-subscribe oracle’s performance depends on the subscriber count
and the frequency of data updates. Each data update schedules one transaction
to each subscriber in the off-chain variant, which may become hard to manage. In
the on-chain variant, those transactions may be merged by instructing the oracle
smart contract to notify consumers via inter-contract calls, which is subject to
blockchain-specific limits on transactions complexity.
12 J. Ladleif et al.
Cost. The metrics discussed above are an important indicator as to the overall
cost of the approaches. To operate at a profit, transaction and storage fees are
reflected in the oracle provider’s pricing model and passed down to the con-
sumers [1]. For example, the request-response oracle provider Provable prices
regular API calls at USD 0.01, up to USD 0.04 if a notary proof is requested.
Presumably, history and publish-subscribe oracle architectures will be more
expensive in practice compared to the basic variants since they offer additional
functional value and tend to incur higher blockchain network fees on the oracle
provider’s end. To the best of the knowledge of the authors, though, no provider
currently offers such services, hence no market-adjusted pricing data is known
and no holistic assessment can be made as yet.
Transaction-Driven Semantics Compliance. The overall goal of the oracle
approaches is to comply to the transaction-driven semantics developed in Sect. 3
(see Lst. 1) as closely as possible. Table 1shows whether this is the case. The
history and publish-subscribe oracles have been designed specifically to fit these
requirements. They eliminate the chance of missing data updates and handle
temporal conflicts by resolving them after-the-fact or proactively avoiding them.
The storage and request-response oracles, on the other hand, do not resolve
temporal conflicts reliably, and the chance of missing data updates is inversely
proportional to the number of oracle invocations as discussed in Sect. 4.
6 Related Work
Blockchain-based process execution is a promising topic in BPM research [10].
Many implementation aspects are being worked on, and some virtually produc-
tion-ready process engines have emerged. Naturally, existing approaches allow
modeling and executing conditional constraints, and some have provisions for ac-
cessing external data through oracles. However, in most cases this is not a core
aspect of the respective publication, and the support for oracles is discussed
sparsely; also, most prototypical implementations are not publicly available.
Only few approaches consider native modeling elements for external data
interaction, namely via BPMN service tasks in Caterpillar [8]; on-chain asset
registries in Lorikeet [9]; and black-box message exchanges [4]. In the first work
in this area, Weber et al. already discuss the possibility of connecting to exter-
nal services via a dedicated trigger component [14]. Even though not explicitly
stated, this trigger component may assume the role of a request-response oracle.
The notion of continuous monitoring is rarely found, and if so only works on
data and events entirely local to the process: In our own previous work, BPMN
conditional events are used to monitor local process data using an instance-wide
re-evaluation strategy on data updates similar to the instance strategy proposed
in this paper [5]. Caterpillar supports BPMN event sub-processes, which likewise
requires instance-wide monitoring of local events [8].
Some approaches, including all of the above, also allow arbitrary scripts to be
added to the model which are then executed by the process smart contract [2,7].
These scripts can be used to call oracle smart contracts, potentially enabling the
External Data Monitoring Using Oracles 13
usage of storage and our proposed history oracles. However, oracles implemented
using callbacks are harder to access since the callback needs to be properly picked
up by the process smart contract. A few approaches provide specific interfaces
for their own callback mechanisms, e.g., subscription services [4] or triggers [14],
which could potentially be used if the oracle was adapted.
Part of our contribution is the proposal of novel oracle architectures, namely
on-chain and off-chain history and publish-subscribe oracles, in the conditional
variant or not. These build on top of patterns from literature [15,16] and operat-
ing oracle services [1]. We are not aware of related work in oracle literature with
a focus similar to ours. Instead, work on existing oracles mostly aims at securing
the way of the data from the source to the smart contract, that is, trust [3] and
reliability [6] are more important than monitoring and historical data.
In a recent survey, Al-Breiki et al. perform an exhaustive comparison of
blockchain oracle platforms focused on trust considerations [1]. They identify
three primary design patterns, including the basic request-response and storage
(which they call “immediate-read”) oracles. A third pattern is named publish-
subscribe pattern, but only shares the name with the proposal in this paper.
While the idea is still to manage data “that is expected to change” [1], sub-
scribers are notified via an on-chain or off-chain flag that they poll manually. As
such, their architecture can not be used to solve temporal conflicts, missing the
continuous aspect we strive for in this paper.
In summary, we assess that a dedicated investigation into the issues of exter-
nal data monitoring from within the blockchain has as yet been missing, both
in a wider practical context and in BPM research. This paper thus provides a
significant conceptual and technical extension of knowledge in the field.
7 Discussion
We have shown that publish-subscribe and history oracles can account for fully
compliant external data monitoring from smart contracts, while all other ap-
proaches are lacking in some aspects. In practice, however, the results need to
be put into context, as research is still in its infancy when it comes to oracle tech-
nology and its wider implications [1]. The intersection with BPM exacerbates
these issues, which we can only selectively discuss in the scope of this paper.
First and foremost, any approach represents a tradeoff in trust. Oracles
bend the blockchain’s integrity philosophy, and need to be trusted to provide
correct data in time. Until technologies or patterns are found that eliminate
this responsibility—and arguably, research in that area is focused primarily on
that [1,3]—, concrete approaches will have to walk the line between supporting
more process features and staying true to the blockchain’s original vision.
On a more grounded level, we did not consider some common blockchain pro-
tocol characteristics. One problem that occurs in practice is that the transaction
order on the blockchain ledger may not reflect the real-world order in which
the transactions were actually sent, depending on fees and incentives. Further,
the interval in which the blockchain produces new blocks and thus adds new
14 J. Ladleif et al.
information might be insufficient for quickly changing data sources, even when
updating the value in every block. Since the extent of these issues dramatically
varies, though, we decided to maintain a platform-agnostic perspective.
From a modeling perspective, we assume that each monitoring point de-
pends on exactly one external data source. This may not always be the case
if complex conditions, for example comparing prices at different online shops,
are evaluated. However, this does not pose major conceptual issues but rather
adds another layer of complexity to concrete implementations, which need to
aggregate and store data from multiple oracles between transactions. This may
be readily achieved using our proposed architectures.
Finally, the semantics presented in Sect. 3view monitoring points as rather
isolated, only interfering with each other if they are siblings in a deferred choice
pattern. This may not apply to some business processes, e.g., when timers, mes-
sages and signals may be part of the choice. Those concepts exhibit their own
difficulties in blockchain-based process execution environments, and the exact se-
mantics when combined with monitoring points will be interesting future work.
8 Conclusion and Future Work
The blockchain’s closed-world assumption and inherent passiveness severely com-
plicate facilitating common business process patterns, like external data moni-
toring within smart contracts. In this paper, we contributed a first assessment of
the exact nature of these issues, and developed a compliant transaction-driven
semantics working in these circumstances. We further proposed implementation
strategies and architectures using oracles to access external data from within the
process smart contracts in a way satisfying the semantics. As such, this work
contributes towards a holistic support for business processes on blockchain.
Several open points, partly discussed in the previous section, remain and
are left for future work. Notably, we did not provide an implementation of our
proposals on actual blockchain platforms, instead discussing properties and re-
strictions on a conceptual, technology-independent level. An empirical evaluation
on the basis of an implementation could elicit valuable further insights.
Bibliography
[1] Al-Breiki, H., Rehman, M.H.U., Salah, K., Svetinovic, D.: Trustworthy
blockchain oracles: Review, comparison, and open research challenges. IEEE
Access 8, 85675 (2020), https://doi.org/0.1109/ACCESS.2020.2992698
[2] Garc´ıa-Ba˜nuelos, L., Ponomarev, A., Dumas, M., Weber, I.: Optimized
execution of business processes on blockchain. In: Business Process
Management (BPM), LNCS, vol. 10445, pp. 130–146, Springer (2017),
https://doi.org/10.1007/978-3-319-65000-5 8
[3] Heiss, J., Eberhardt, J., Tai, S.: From oracles to trustworthy data on-
chaining systems. In: IEEE International Conference on Blockchain, pp.
496–503 (2019), https://doi.org/10.1109/Blockchain.2019.00075
External Data Monitoring Using Oracles 15
[4] Klinger, P., Bodendorf, F.: Blockchain-based cross-organizational execution
framework for dynamic integration of process collaborations. In: 15th In-
ternational Conference on Wirtschaftsinformatik (WI), pp. 893–908 (2020),
https://doi.org/10.30844/wi 2020 i2-klinger
[5] Ladleif, J., Weske, M., Weber, I.: Modeling and enforcing blockchain-
based choreographies. In: Business Process Management (BPM), pp. 69–85,
LNCS, Springer (2019), https://doi.org/10.1007/978-3-030-26619-6 7
[6] Lo, S.K., Xu, X., Staples, M., Yao, L.: Reliability analysis for block-
chain oracles. Computers & Electrical Engineering 83, 106582 (2020),
https://doi.org/10.1016/j.compeleceng.2020.106582
[7] L´opez-Pintado, O., Dumas, M., Garc´ıa-Ba˜nuelos, L., Weber, I.: Interpreted
execution of business process models on blockchain. In: IEEE International
Enterprise Distributed Object Computing Conference (EDOC), pp. 206–215
(2019), https://doi.org/10.1109/EDOC.2019.00033
[8] L´opez-Pintado, O., Garc´ıa-Ba˜nuelos, L., Dumas, M., Weber, I., Ponomarev,
A.: Caterpillar: A business process execution engine on the Ethereum
blockchain. Software: Practice and Experience 49(7), 1162–1193 (2019),
https://doi.org/10.1002/spe.2702
[9] Lu, Q., Tran, A.B., Weber, I., O’Connor, H., Rimba, P., Xu, X., Sta-
ples, M., Zhu, L., Jeffery, R.: Integrated model-driven engineering of block-
chain applications for business processes and asset management. CoRR
abs/2005.12685 (2020), URL http://arxiv.org/abs/2005.12685
[10] Mendling, J., Weber, I., et al.: Blockchains for business process management
– challenges and opportunities. ACM Trans. Manage. Inf. Syst. (TMIS)
9(1), 4:1–4:16 (2018), https://doi.org/10.1145/3183367
[11] OMG: Business Process Model and Notation (BPMN), Version 2.0.2 (2013),
URL http://www.omg.org/spec/BPMN/2.0.2/
[12] Russell, N., ter Hofstede, A.H., van der Aalst, W.M., Mulyar, N.: Workflow
control-flow patterns: A revised view. BPM Center Rep. BPM-06-22 (2006)
[13] Russell, N., ter Hofstede, A.H., Edmond, D., van der Aalst, W.M.: Work-
flow data patterns. Tech. Rep. FIT-TR-2004-01, Queensland University of
Technology, Brisbane (2004)
[14] Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev, A., Mendling,
J.: Untrusted business process monitoring and execution using blockchain.
In: Business Process Management (BPM), LNCS, vol. 9850, pp. 329–347,
Springer (2016), https://doi.org/10.1007/978-3-319-45348-4 19
[15] W¨ohrer, M., Zdun, U.: Design patterns for smart contracts in the ethereum
ecosystem. In: IEEE International Conference on Blockchain, pp. 1513–1520
(2018), https://doi.org/10.1109/Cybermatics 2018.2018.00255
[16] Xu, X., Pautasso, C., Zhu, L., Lu, Q., Weber, I.: A pattern collection for
blockchain-based applications. In: Conf. Pattern Languages of Programs
(EuroPLoP), ACM (2018), https://doi.org/10.1145/3282308.3282312
[17] Xu, X., Weber, I., Staples, M., Zhu, L., Bosch, J., Bass, L., Pautasso, C.,
Rimba, P.: A taxonomy of blockchain-based systems for architecture design.
In: IEEE Intl. Conf. Software Architecture (ICSA), pp. 243–252 (2017),
https://doi.org/10.1109/ICSA.2017.33
