Content uploaded by Ingo Weber
Author content
All content in this area was uploaded by Ingo Weber on Jan 01, 2019
Content may be subject to copyright.
Dynamic Role Binding in Blockchain-Based
Collaborative Business Processes
Orlenys L´opez-Pintado1, Marlon Dumas1, Luciano Garc´ıa-Ba˜nuelos1, and Ingo Weber2
1University of Tartu, Estonia
{orlenyslp, marlon.dumas, luciano.garcia}@ut.ee
2Data61, CSIRO, Sydney, Australia
ingo.weber@data61.csiro.au
Abstract. Blockchain technology enables the execution of collabora-
tive business processes involving mutually untrusted parties. Existing
platforms allow such processes to be modeled using high-level notations
and compiled into smart contracts that can be deployed on blockchain
platforms. However, these platforms brush aside the question of who is
allowed to execute which tasks in the process, either by deferring the
question altogether or by adopting a static approach where all actors
are bound to roles upon process instantiation. Yet, a key advantage of
blockchains is their ability to support dynamic sets of actors. This paper
presents a model for dynamic binding of actors to roles in collaborative
processes and an associated binding policy specification language. The
proposed language is endowed with a Petri net semantics, thus enabling
policy consistency verification. The paper also outlines an approach to
compile policy specifications into smart contracts for enforcement. An
experimental evaluation shows that the cost of policy enforcement in-
creases linearly with the number of roles and constraints.
1 Introduction
Access control is an essential aspect in the design and execution of business
processes. Mainstream Business Process Management Systems (BPMSs) rely on
static Role-Based Access Control (RBAC) models. In these models, any worker
who plays a role is allowed to perform any task associated to this role in any
instance of the process, modulo additional constraints such as separation of
duties [13]. This approach is unsuitable for collaborative inter-organizational
processes involving untrusted actors. For example, a buyer may trust a given
carrier but not others, even though they all play the same role.
Blockchain technology enables the execution of collaborative business pro-
cesses involving untrusted actors [8]. Existing tools such as Caterpillar [6] and
Lorikeet [14], support the definition of collaborative processes using high-level
notations and their execution on top of blockchain platforms. However, these
tools either do not support access control or they adopt a static role binding
approach wherein all actors are bound to roles upon process instantiation.
The characteristics of blockchain technology shift the role binding problem in
two ways. First, rather than groups or individual users being bound to roles, we
arXiv:1812.02909v1 [cs.SE] 7 Dec 2018
need to bind blockchain accounts (or identities) to roles, as shown in Fig. 1. These
accounts, in turn, are controlled by users, groups, systems, or (IoT) devices.
System
IoT
Dynamic binding
(blockchain)
Conventional
role binding
User / Group
Blockchain
account / identity
Task
Role
Fig. 1. Relations between tasks,
roles, blockchain accounts, and actors
(blockchain case vs. conventional case).
Second and more significantly, in open
blockchain networks, instances of a col-
laborative process are created by differ-
ent actors, and each of these actors trusts
one subset of actors but not others. More-
over, the set of actors changes dynami-
cally and so do the trust relations. For
example, a buyer may initially trust a
carrier and agree to its appointment to-
gether with the supplier. But later, the
buyer may lose this trust (e.g. if the car-
rier misses a deadline). Thereafter, the
buyer may wish to re-bind the transportation task to another carrier, but this
re-binding must be endorsed by the supplier. This example illustrates the need
to support dynamic binding and un-binding of actors to roles and collaborative
binding of actors to roles (buyer and supplier both need to agree on the carrier).
This paper proposes a role binding model and a binding policy specification
language designed to support collaborative business processes in such open and
untrusted environments, as well as an approach to compile policies into exe-
cutable code. The semantics of the policy specification language is defined via a
mapping to Petri nets, which enables the static verification of policies prior to
their compilation. The proposed method has been implemented in Caterpillar
[6] – a blockchain-based execution engine that supports the Business Process
Model and Notation (BPMN). The paper reports on an experimental evaluation
aimed at assessing the cost of policy enforcement on the Ethereum blockchain.
The rest of the paper is structured as follows. Section 2 discusses basic con-
cepts of blockchain technology and the limitations of existing role binding models
for collaborative processes. Section 3 describes the role binding model and pol-
icy language. Section 4 presents the semantics of the policy language and the
policy verification approach. Finally, Section 5 discusses the implementation and
evaluation, while Section 6 draws conclusions and sketches future work.
2 Background and Related Work
2.1 Blockchain Technology and Collaborative Processes
A blockchain is a distributed append-only store of transactions distributed across
computational nodes and structured as a linked list of blocks, each containing
a set of transactions [16]. A blockchain network is made up of nodes, a subset
of which holds a replica of the data structure. Clients use a blockchain sys-
tem (a concrete network) by reading data from and submitting transactions to
it. Submitted transactions are grouped into blocks, which are broadcast across
the network to be appended to the blockchain. A consensus mechanism ensures
tamper-proofness without assuming mutual trust between participants.
2
A smart contract is a program deployed on the blockchain, which may be
invoked via a transaction [16]. In Ethereum, smart contracts are written in the
Solidity language, which is compiled into bytecode and executed on the Ethereum
Virtual Machine. The computational and data storage consumption of a transac-
tion are measured in gas, which translates to monetary costs for the transaction’s
sender. Each block has a gas limit and hence gas directly impacts throughput.
Existing blockchain-based process management tools support the specifica-
tion of collaborative processes using BPMN [6,14] or domain-specific languages
[4], and their execution via smart contracts. These systems focus mainly on the
control-flow perspective. Lorikeet [14] implements a static access control mech-
anism, where roles are bound to accounts upon process instantiation. A method
proposed in [11] allows dynamic handoffs of process instances between actors,
but does not support the specification and enforcement of permitted handoffs.
2.2 Binding and Delegation Models for Collaborative Processes
The question of dynamic role binding has been considered in the context of Web
service composition, e.g. in the Business Process Execution Language (BPEL) [1]
where role binding is supported via “partner links”. A partner link is a variable
that holds a reference to a service endpoint (i.e. a concrete address). This vari-
able can be modified anytime during the execution of a process instance. This
approach assumes that the whole process is orchestrated by a single entity and
that this entity unilaterally decides which actor (i.e. endpoint) should be bound
or re-bound to a role (i.e. a partner link). The same assumption is made in
BPEL4People [5] (which extends BPEL to support human actors), in Pautasso
et al. [10] and Lu et al. [7]. These approaches are not applicable in settings where
the binding of actors to roles is not determined by a single actor.
Other work studies the problem of dynamic role binding in settings where the
process is not orchestrated by a single actor. [12] extracts dynamic authoriza-
tion policies from service choreographies. These policies are enforced locally by
each party, but they rely on a centralized authority to specify the role bindings.
BPEL4Chor [3] allows an actor to bind other actors to the roles it has control
over. But each role is controlled by a single actor – in other words, collaborative
role binding is not supported, e.g. this approach does not support the scenario
where both the buyer and seller must agree on the actor who plays the role of car-
rier. Also, BPEL4Chor does not support role re-binding. In [15,2], dynamic role
bindings in decentralized processes are captured via a delegation and revocation
scheme. This approach supports un-binding (revocation) but does not support
collaborative binding (each actor decides on the roles it has control over).
In summary, none of the above studies has addressed the problem of dynamic
role binding and un-binding in decentralized processes, where multiple actors
must collaboratively agree on each role binding and un-binding decision.
3 Role Binding Model
The starting point of the proposed approach is a (collaborative) business process
model where each task is associated with a role. For a given process instance
(herein called a case), each role may be assigned to at most one actor. An actor
3
has an identity (e.g. a blockchain account) and may represent a user, a group,
an organization, a system or a device (cf. Fig. 1). As a running example, Fig. 2
shows a BPMN model of an order-to-cash process. There are six roles represented
by numbers below each task label: (1) Customer, (2) Supplier, (3) CarrierCan-
didate, (4) Carrier, (5) Invoicer and (6) Invoicee. Initially, a customer submits a
purchase order (PO) to a supplier. If the PO is rejected the process terminates.
Otherwise, the execution continues with the Shipment sub-process, where a
supplier requests quotes from multiple carrier candidates (cf. the multi-instance
task). Once the shipment completes, two parallel paths are taken to handle the
payments. These payments are encapsulated in sub-process Invoicing. This
sub-process is called twice: for the supplier’s invoice and for the carrier’s invoice.
Submit PO
(1)
PO Created
Validate PO
(2)
Is PO
Accepted?
Shipment
PO Rejected
PO Fulfilled
Supplier
Invoicing
Carrier
Invoicing
No
Yes
(a) Root process: Order-to-Cash
Shipment
Started
Request
Quotes
(2)
Submit
Quotes
(3)
Ship
Goods
(4) Shipment
Completed
(b) Sub-process: Shipment
Handling
Started
Issue Invoice
(5)
Validate
Invoice
(6)
Is Invoice
Accepted?
Correct
Invoice
(5)
Handling
Completed
No
Yes
(c) Sub-process: Invoicing
Fig. 2. Running example: (2a) An Order-to-cash process linked, via call activities, to
two reusable sub-processes; (2b) Shipment and (2c) Invoicing.
The act of assigning an actor to a role within a case is called binding. When
a role is not assigned to an actor within a case, we say that the role is unbound.
The binding of an actor to a role can be performed anytime during the execution
of a case. Actors can also be unbound from a role – an operation called release.
A task is performed by the actor bound to the task’s role. If a task is enabled
when its associated role is unbound, the task waits until the role is bound.
Actors may nominate themselves or other actors to play a role in a case, or
they may request to release themselves or other actors from a role. Given the
lack of trust, the nomination/release of an actor to/from a role may require the
endorsement of actors playing other roles. If an actor is nominated to play a
role in a case, this nomination only leads to the role’s binding if the required
endorsements are granted. A binding policy associated to a process model deter-
mines which role(s) are allowed to nominate an actor to a role, to request the
release an actor from a role, and to endorse a nomination or a release request.
3.1 Binding Policy Specification Language
A policy consists of a set of roles and a set of statements restricting how an actor
may be nominated/released to/from a role. A statement is formed by a nomina-
tor, a nominee, and optionally a binding and/or an endorsement constraint. The
4
nominator is a role that nominates/releases the actors of another role, namely
the nominee. A binding constraint is a boolean expression stipulating that the
nominee must be bound to an actor who is also bound to some other role(s).
An endorsement constraint is a boolean expression that determines which roles
need to endorse a nomination/release request. A role may be associated with the
case-creator, implying that the role is bound upon case creation and does not
need a nomination or endorsement. A policy statement applies by default to the
root process, but it can be scoped to a sub-process call activity. Fig. 3 shows an
extract of the grammar of the policy language in Backus Naur form (BNF).3
hstatementi::= [Under hsubprocessi‘,’ ] hrolei hbinding expri[hendorse expr i { ‘,’
hendorse expri } ] ‘;’
|‘case-creator’hrolei‘;’
hbinding expri::= (‘nominates’|‘releases’) hrolei[hbinding constrainti]
hbinding constrainti::= (‘in’|‘not in’) hset expr i
hendorse expri::= ‘endorsed-by’hset expri
hset expi::= hrolei
| hrolei(‘and’|‘or’) hset expr i
|‘(’hset expi‘)’
Fig. 3. BNF grammar describing the basic statement syntax of a binding policy.
Listing 1 shows a policy for the model in Fig. 2. The policy states that the case
creator is automatically bound to the Customer role. The Customer nominates
the Supplier (no endorsement needed here). The Supplier, in turn, nominates
the Candidate (i.e. the carrier candidate) and the Carrier. The Carrier must
be among the actors bound to the Candidate role (cf. binding constraint “Car-
rier in Candidate”). Note that Candidate is a role associated to a multi-instance
task (Submit Quotes), implying that multiple actors may be bound to this role.
The Customer must endorse the nomination of the Carrier. Under the Carrier
Invoicing call activity, the Invoicer is nominated by the Carrier with en-
dorsement from the Supplier and Customer, and reciprocally for the Invoicee.
Meanwhile, under the Supplier Invoicing activity, the Supplier nominates the
Invoicer with Customer endorsement, and reciprocally for the Invoicee.
1{Cu s to m er is ca se -c r ea t or ;
2Cu s to m er n om i na t es S up p li e r ;
3Un d er S hi pm e nt ,S u pp l ie r no m in a te s Ca n di d at e ;
4Un d er S hi pm e nt ,S u p pl i e r no m i na t e s Ca r ri e r in Ca n d id a t e en d or s ed -b y
Cu s to m er ;
5Un d er C ar ri e r In vo i ci n g ,Ca r r ie r n om i n at e s I nv o i ce r e nd o rs e d - b y Su p p li e r
an d Cu st o me r ;
6Un d er C ar ri e r In vo i ci n g ,Cu s t ome r n o m ina t e s I nvo i c e e en d ors e d -by Ca r rie r ;
7Un d er S up pl i er I nv o ic i ng ,S u p pl i e r no m i na t e s In v oi c e r en do r s ed -b y Cu s t om e r ;
8Un d er S up pl i er I nv o ic i ng ,S u p pl i e r no m i na t e s In v oi c e e en do r s ed -b y Cu s t om e r ;
9}
Listing 1. Binding Policy to control the execution of the processes modeled in Fig. 2.
3Some details (e.g. path expressions to refer to nested subprocesses) are omitted for
space reasons and can be found at http://git.io/caterpillar.
5
This example illustrates the possibilities offered by the policy language to deal
with lack of trust. For example, dishonest suppliers could try to derive benefits
by not selecting the best carrier candidate but their preferred one. However, the
customer would be able to reject such nominations. Also, the policy prevents the
supplier from selecting a carrier that has not been a carrier candidate before.
The policy language also allows us to state that the set of actors who endorse
a nomination request must fulfill a boolean expression. For instance, the above
policy requires that the Invoicer of the carrier services must be endorsed by
both the buyer and the supplier. This scenario is relevant in the context of
international trade, where both buyers and suppliers need to ensure that they
do not deal with black-listed entities or entities in countries banned from trading.
The boolean expressions in the endorsement constraint may contain arbitrary
combinations of conjunctions and disjunctions. They may not however contain
negation, e.g. it is not possible to state that the nomination is approved if a given
actor refuses to endorse it. Such scenarios are not applicable in this setting.
3.2 Runtime Binding Operations
The role binding model relies on three operations. The nominate operation al-
lows an actor to request that another actor (or itself) be bound to a role within
a process instance (herein called a case). Inversely, a release operation allows
an actor to request that another actor (or itself) be unbound from a role. The
vote operation allows an actor to accept/reject a nomination or release request.
These operations trigger transitions in the role lifecycle depicted in Fig. 4.
Within a case, a role is initially unbound. After a nominate operation, the
role changes to nominated if it requires to be endorsed, otherwise is considered
bound. A role in nominated state, can transition to the bound state after
avote operation where the endorser accepts the nomination if, as a result of
it, the endorsement constraint of this role is satisfied. On the contrary, a vote
operation where the endorser rejects the nomination and by doing so makes the
role’s endorsement constraint unsatisfiable, triggers a transition to the unbound
state. If after a vote operation, the endorsement constraint remains satisfiable,
then the role remains in the nominated state. Symmetrically, a role can transit
from bound to unbound as a result of a release operation, via a releasing
state, which is specular to the nominated state. If the endorsement constraint
associated to a release request becomes unsatisfiable, the role goes back to the
bound state, and if it becomes satisfied, the role moves to the unbound state.
4 Policy Consistency Verification
Nomination and release statements in a policy implicitly induce precedence de-
pendencies in the binding of roles. A statement R1 nominates R2 endorsed-by
R3 implies that for R2 to be bound, R1 and R3 must be bound before. Circular
and unresolvable dependencies induced in this way may lead to deadlocks. Ac-
cordingly, we define a notion of policy consistency as follows. A policy is consis-
tent if, starting from the state where only the roles associated with case-creator
6
UNBOUND NOMINATED
BOUNDRELEASING
Nominate(endorsement-required)
Vote(satisfiable-endorsement)
Vote(unsatisfied-endorsement)
Vote(satisfied-endorsement)
Release(no-endorsement-required)
Vote(satisfied-endorsement)
Release(endorsement-required)
Vote(unsatisfied-endorsement)
Nominate(no-endorsement-required)
Vote(satisfiable-endorsement)
Text
Text
Fig. 4. Lifecycle of a role within a case.
are Bound and after executing any allowed sequence of nomination, release and
endorse operations, we always reach a state where all roles will reach the Bound
state via some (other) sequence of nomination, release and endorse operations.
To verify policy consistency, we define a mapping from a policy to a Petri
net [9], herein called a nomination net. Given the nomination net of a policy,
we map the problem of checking policy consistency to a problem of reachability
analysis over Petri nets. Algorithm 1 maps a policy to a nomination net. For the
sake of conciseness, this algorithm focuses on nomination statements, leaving
aside release statements. The mapping of release statements follows a similar
structure. For the same reason, the algorithm leaves aside binding constraints.
To illustrate the algorithm, we consider the binding policy in Fig. 5. The
algorithm takes as input a symbolic representation of a policy consisting of a
set of roles and a set of tuples of the form (nominator, nominee, endorsement-
constraint), with ⊥denoting an empty constraint. For example, the symbolic
representation of the policy in Fig. 5 is given in Fig. 6. Given this input, the
algorithm will produce as output the nomination net in Fig. 7.
The algorithm proceeds as follows. After initializing variable RNets in line 2,
the algorithm builds a Petri net for each node in lines 3-4 (Step 1). Let us consider
that we are building the Petri net for role A, which is shown in color blue in
Fig. 7. In line 4, the algorithm creates such a Petri net with three places, namely
uA,nAand bA, which represent the states of the role’s lifecycle UNBOUND,
NOMINATED and BOUND, respectively. Similarly, two transitions are added
to the Petri net, namely nmAand enA, representing the operations ’nominate’
and ’endorse’. Finally, four arcs added to complete the Petri net, by connecting
the places and transitions. The Petri nets for all the other nodes are created in
a similar way. Every Petri net thus created is added to RNets that serves as a
map that associates a role to its corresponding Petri net.
In lines 5-9 (Step 2), all the role (Petri) nets are merged to form the initial
nomination net, which is held in variable NNet. This is done by taking the union
of the elements in the role nets. Also, the initial marking is set to the empty set.
In lines 11-14 (Step 3), the algorithm adds double-headed arcs to the Petri
net to synchronize the transition that represents the nomination of roles. To
illustrate the idea of nomination, consider the double-headed arc connecting the
place bAand the transition nmBin Fig. 7, highlighted in red. Simply put, role A
will be able to nominate role Bwhen role Bis UNBOUND and role Ais BOUND
(bAmust hold a token). The firing of transition nmB, that is ”nominate B”, will
7
Algorithm 1 Construction of the Nomination Net for a given Binding Policy
1: function ConstructNominationNet(R, BP)
2: RNets ← ∅
.Step 1: Build a Petri net for each role
3: for each role r∈Rdo
4: RNets ←RNets S
r7→ *{ur, nr, br}. Pr
{nmr, enr}. Tr
{(ur, nmr),(nmr, nr),(nr, enr),(enr, br)}. Fr+
.Step 2: Merge all role nets to form the nomination net
5: let NNet = hP, T, F , M0iin
6: P←Sr∈RP(RNets[r])
7: T←Sr∈RT(RNets[r])
8: F←Sr∈RF(RNets[r])
9: M0← ∅
10:
.Step 3: Wire up operation nominate
11: for each hrnr, rne ,i ∈ BP do
12: select bnr ∈ P(RNets[nr])
13: select nmrne ∈ T (RNets[ne])
14: F(NNet) ← F(NNet) ∪ {(brnr , nmrne ),(nmrne , brnr )}
.Step 4: Wire up operation endorse
15: for each hrnr, rne , eexi ∈ BP such that eex 6=⊥do
16: P(NNet) ← P(NNet) ∪ {disjrne , eexrne }
17: F(NNet) ← F(NNet) ∪ {(nmrne , disjrne ),(eexrne , enrne )}
18: for each conj ∈eex do
19: T(NNet) ← T (NNet) ∪ {eexconj }
20: F(NNet) ← F(NNet) S
r∈conj∧br∈P (RNets[r]) (br, eexconj ),(eexconj , br),
(disjrne , eexconj )
.Step 5: Update NNet’s initial marking
21: let rcc ∈R:rcc be case creator in
22: Ps ← {ur|r∈R\ {rcc} ∧ ur∈ P (NNet[r])} ∪ {brcc |brcc ∈ P (NNet[rcc ])}
23: M0(NNet)(p) = 1 if p∈P s
0 Otherwise
24:
25: return NNet
change the state of role Bfrom UNBOUND to NOMINATED. The double-
headed arc will keep a token in bAafter the nomination of role B.
The encoding of endorsement conditions is handled in lines 15-20 (Step 4).
Without loss of generality, we assume that the endorsement conditions are ex-
pressed in disjunctive normal form, meaning that there is only one disjunction
that relates several conjunctions. We consider two additional cases: (1) no en-
dorsement condition is specified (represented by ⊥), meaning that no endorse-
ment is required, and (2) only one conjunction is specified. To illustrate this step
of the construction of the nomination net, consider the binding policy:
D nominates E, endorsed-by (A and B) or (B and C);
8
{ A is case-creator;
A nominates B;
A nominates C;
C nominates D, endorsed-by A and B;
}
Fig. 5. Sample binding policy
R={A, B, C, D }
BP ={hA, B , ⊥i ,hA, C, ⊥i ,hC, D, A ∧Bi}
Fig. 6. Symbolic representation of the
binding policy in Fig. 5
nmAenA
nmBenB
nmCenC
nmDenD
uA
uB
uC
uD
nC
nDbD
bC
bA
bB
nB
nA
eexA^B
disjD
eexD
Fig. 7. Nomination net for binding policy in Fig. 5
The Petri net in Fig. 8 encodes the endorsement condition in the above
policy: (A∧B)∨(B∧C). The latter is bound to variable eex in line 15.
bB
eexA^B
disjE
eexE
eexB^C
bC
bA
Fig. 8. Net encoding condi-
tion (A∧B)∨(B∧C)
In line 16, the algorithm adds two new places: disjE
which encodes the disjunction, and eexE, which col-
lects the outcome of the endorsement (i.e. it holds
a token when one of the endorsement conditions is
met). In line 17, these are connected to the tran-
sitions of the role: from the nomination nmEto
disjE, and from the outcome eexEto the endorse-
ment enE(not shown in Fig. 8). Then, in line 18,
the algorithm iterates over each one of the conjunc-
tions. In line 19, a new transition, representing the
underlying conjunction is added to the net, and the
corresponding arc in line 20. For instance, the net in Fig. 8 has transition eexA∧B
representing conjunction A∧B, and eexB∧Crepresenting B∧C. Only eexA∧B
or eexB∧Cwill be able to consume the token held by disjE, which prevents
the generation of an arbitrary number of tokens in NNet.disjEreceives a token
when nmEfires, i.e., when Dnominates E. The disjunction expressed in this way
means that role Ecan be endorsed if at least one of the conjunctions holds true,
which corresponds to the firing of one of the transitions eexA∧Band eexB∧C.
Returning to the example in Figures 5-7, we observe that role Dis endorsed
if and only if both roles Aand Bare BOUND. The subnet implementing the
endorsement condition is shown in green in Fig. 7.
Finally, lines 21-23 set the initial marking for the nomination net. Briefly,
line 21 will add a token to the place representing the state UNBOUND of every
single role, except for the “case creator”. In the latter case, we add a token to
the place representing the state BOUND.
To verify policy consistency, we use reachability analysis to check if the mark-
ing where all roles are bound is always reachable starting from the initial mark-
9
{
J is case-creator;
J nominates K, endorsed-by L;
J nominates L, endorsed-by K;
}
nmJenJ
nmKenK
nmLenL
uJ
uK
uLnLbL
bJ
bK
nK
nJ
disjL
eexK
eexL
eexL
disjKeexK
Fig. 9. Binding policy with circular dependency and its nomination net
ing where only the roles associated to case-creator are bound. In other words,
there is no deadlock preventing a role from being bound. Fig. 9 shows a binding
policy with a circular dependency, leading to a deadlock in the corresponding
nomination net. Fig. 9 shows the marking where the deadlock occurs. Both roles
Kand Lhave been nominated by role J. Hence, disjKhas a token, but transi-
tion eexLcannot fire until bLhas also a token. In order for bLto have a token,
however, transition eexKneeds to fire because it requires bKto have a token.
5 Implementation and Evaluation
To demonstrate the proposal’s feasibility, we developed a compiler that takes
as input a policy specification and produces Solidity smart contracts to enforce
the policy. This policy compiler is designed to be used in conjunction with the
Caterpillar BPMN-to-Solidity compiler [6]. The smart contracts generated by
the policy compiler manage the association between roles and actors (represented
as blockchain accounts), while the smart contracts generated by the BPMN-to-
Solidity compiler enforce the control-flow constraints in the process model. When
a task is enabled, the worklist handler smart contract of Caterpillar, checks if
the corresponding role is bound to an actor within the current case, and ensures
that only this actor can execute the task. The source code of Caterpillar,
including the binding policy compiler and the examples used in this paper, are
available at http://git.io/caterpillar. Below we discuss the generation of
smart contracts and evaluate the costs generated by these contracts.
5.1 Compiling Binding Policies into Smart Contracts
Given a process model and a policy specification, the policy compiler generates a
smart contract (named BindingPolicy) to encode the policy and a smart con-
tract (TaskRoleMap) to encode the task-role relations in the process model.
The BindingPolicy contract encodes the logic of who can nominate and re-
lease each role and the binding and endorsement constraints for each role. A
third contract (BindingAccessControl) implements the runtime operations
sketched in Section 3. BindingPolicy and TaskRoleMap are singleton con-
tracts – only one instance of each of them is created since these contracts only
10
maintain schema-level data. Meanwhile, the BindingAccessControl contract
is instantiated once per case. The BindingAccessControl contract instance
of a given case maintains the state of each role, as per the lifecycle in Fig. 4.
When a nomination, release, or vote operation is invoked, the BindingAccess-
Control contract invokes the BindingPolicy contract. The latter checks if
this operation is allowed in the current state and computes the new state.
The class diagram in Fig 10 captures the functionality of the generated smart
contracts. Input parameters with no type specification are by default uint. As
stated above, contract BindingAccessControl implements the runtime op-
erations for nomination, release and voting. Since this contract does not encode
anything about a particular policy, it is not generated by the policy compiler, but
instead it is hard-coded and deployed once on the target Ethereum blockchain.
This contract maintains the state of the role bindings for a given case in a variable
called bindingState. Given that the cost of a smart contract depends on the
amount of data it maintains, we encode the bindingState using bitmaps. Sim-
ilarly, the endorsement constraints are represented as bit arrays. Specifically, we
first put these constraints in disjunctive normal form, e.g., (A and B and ...)
or (D and ...). Then we implement each conjunction set as a bit array and
encode it as a 256-bits unsigned integer – the default word size in Ethereum.
<<interface>>
BindingPolicy
canNominate (rNominator, rNominee)
assertNConstraint (rNominator, rNominee, nomineeRoles)
assertNVote (rNominator, rNominee, rEndorser, endorsedBy, rejectedBy, isAccepted :bool)
isCaseCreator ()
canRelease (rNominator, rNominee)
assertRConstraint (rNominator, rNominee, nomineeRoles)
assertRVote (rNominator, rNominee, rEndorser, endorsedBy, rejectedBy, isAccepted :bool)
<<interface>>
TaskRoleMap
getRoleFromTask (processIndex, taskIndex, ) :uint
BindingAccessControl
- bindingState
+ nominateCaseCreator (rNominee, nominee :address, pCase :address)
+ nominate (rNominator, rNominee, nominator :address, nominee :address, pCase :address)
+ voteN (rNominator, rNominee, rEndorser, endorser :address, pCase :address, isAccepted :bool)
+ release (rNominator, rNominee, nominator :address, nominee :address, pCase :address)
+ voteR (rNominator, rNominee, rEndorser, endorser :address, pCase :address, isAccepted :bool)
+ canPerform (actor :address, pCase :address, processIndex, taskIndex)
BindingPolicyContract TaskRoleMapContract
Fig. 10. Class diagram of the smart contracts derived from the policies.
Contract TaskRoleMap is generated from the process model. This contract
is straightforward (it maps tasks to roles), so we do not discuss it further.
The policy specification is compiled into the BindingPolicy contract. Below
we discuss how the role binding functions are generated (functions canNominate,
assertNConstraint and assertNVote). The generation of the release functions
(canRelease,assertRConstraint and asserRVote) is done in a similar way.
To generate function canNominate, for each distinct nominator in the policy
a conditional and bit array, namely nMask, is created with one bit per role such
that the presence of a nominee is represented with a one and the absence with a
zero. For example, a nominator with index 3 and nMask = 6 is translated into:
11
fu n c t ion c a nN o m in a te (uint r Nom in ato r , uint rNominee) returns(bool) {
.. .
if ( r N om in a to r == 3)
return 6 & (1 < < r N o mi n e e ) ! = 0 ;
.. .
}
Function assertNConstraint verifies if the roles held by a nominee do not
contradict the binding constraint. Thus, a conditional instruction per nomina-
tion statement including a binding constraint is added. A statement is iden-
tified by the union of nominator and nominee, i.e., (1 << rNominator) | (1
<< rNominee). Variable nomineeRoles is the bit array encoding the nominee’s
current roles. Given a constraint of the form (A and B) or (C) or .., the
constraint is fulfilled if at least one of the conjunction sets is fully included in
nomineeRoles. This is encoded as follows:
if ( (1 < < r No m in a to r ) | ( 1 < < r N om i ne e ) )
return no m i n e eRo l e s & (( 1 << A ) | (1 << B ) ) == (( 1 < < A ) | ( 1 << B ) )
|| n om i n e e R ol e s & (1 < < C ) == (1 < < C) || . .. ;
Function assertNVote checks if an endorser can vote for a nomination and
determines the state after this vote. Given the input parameters endorsedBy and
rejectedBy, which are bit arrays encoding the roles that already accepted and
rejected the nomination, this function determines the resulting state as follows:
1. Bound if all the roles in at least a conjunction set, namely CS, endorsed the
nomination, i.e., (endorsedBy | endorserRole) & CS == CS,
2. Unbound if in each conjunction set contains at least one role rejected the
nomination, i.e., for each CS,(rejectedBy | endorserRole) & CS != 0,
3. Nominated if none of the conditions 1. and 2. are fulfilled yet, i.e., there is
at least a conjunction set with no rejections and with roles pending to vote.
5.2 Experimental Setup
We conducted an evaluation to answer the following question: How does the cost
(in gas/ether) of enforcing a binding policy increase depending on the size and
complexity of the policy statements?4We decompose this question into three:
(Q1) How do the costs of deploying the generated smart contracts vary with the
size of the policy? (Q2) How do the costs of executing the runtime operations
vary with the size of the policy? (3) How does the combined cost of enforcing a
process model and a binding policy varies with the size of the model?
It follows from Section 5.1 that the costs depend on the number of roles
to nominate and the number of conjunction sets in the binding/endorsement
constraints. Thus, we designed the following experiments: (E1) We varied the
number of nomination statements in a policy from 1 to 40, without any binding or
endorsement constraints. (E2) We fixed the number of statements to 40, selected
one statement, and gradually increased the size of its conjunction set from 1 to
4In Ethereum, gas is linearly related to throughput, see Section 2.1. So by answering
this question we also indirectly answer the related throughput question.
12
40. (E3) We fixed the number of statements to 40, and gradually added a binding
constraint with one conjunction set to each of the 40 statements. (E4,E5) The
experiments E3 and E4 were repeated for the endorsement constraint (instead of
the binding constraint). (E6) We generated a policy with 40 roles such that each
statement includes a binding constraint stipulating that the nominated actor
must belong to the role in the previous statement and that the nomination must
be endorsed by all actors nominated in previous statements. (E7) Starting from a
BPMN model with only one task, we iteratively expanded it by one task at a time
(up to 40) and assigned each task to a different role. In this latter experiment,
once a role was bound to an actor, we checked that the corresponding task could
be performed. Note that the evaluation focuses on nomination statements, but
the release statements are symmetric.
We implemented a replayer in Java that generates the policies, triggers their
compilation and deployment, and executes the runtime operations via Cater-
pillar’s REST API. For each transaction included in the blockchain, Caterpillar
sends some meta-data that includes block number, consumed gas, transaction
hash which is collected and assessed by the replayer. For the experimentation we
run a Node.js based Ethereum client named ganache-cli5which is widely used
to simulate a full client for developing and testing purposes on Ethereum.
5.3 Experimental Results
Fig. 11. Growth of deployment costs with
size of binding policy.
Deployment costs for experiments E1-
E5 are plotted in Fig. 11. It can be
seen that deployment costs increase
quasi-linearly with the size and com-
plexity of the policy. The simplest
contract (with a single role bound to
case-creator) costs 154,167 gas. As ex-
pected, the most pronounced growth
in cost occurs for endorsement con-
straints (E4-E5) as they produce more
instructions during code generation.
We observe an increase of around
16.0−19.0% when adding a new en-
dorsement constraint and 5.0−6.5%
when adding a conjunction set to a
constraint. Experiments E2-E3 show
that adding a binding constraint in-
creases cost by 4.0−5.7%, while adding a conjunction to a constraint adds
2.4−3.5% overhead. E1 shows that adding one unrestricted statement to nom-
inate a role adds 4.0−4.5% overhead.
5https://github.com/trufflesuite/ganache-cli
13
E1 E2 E3 E4 E5
Nom.
Min. 151,586 112,476 111,407 132,417 131,493
Max. 152,638 152,790 113,447 152,746 153,800
Ave. 151,948 151,270 112,277 151,738 142,660
Vot.
Min. - - - 76,845 77,184
Max. - - - 78,136 78,184
Ave. - - - 77,463 77,541
Table 1. Cost of nominations and votes
For the runtime operations, we
observed that costs vary depending
on the number and the order of
statements and conjunction sets in
the constraints. The cost to nomi-
nate a role is higher when the corre-
sponding policy statement is at the
end of the policy. Similar behavior was observed for binding and endorsement
constraints. This is because in Ethereum, the gas depends on the number of byte-
code instructions executed. Hence, in a function with if-else-if instructions,
the cost increases with the number of evaluated conditions. Table 1 shows the
min, max, and average costs to perform the nominate and vote operations in ex-
periments E1-E5. Note that voting is less costly than nominating and nomination
costs are lower when restricted by binding constraints compared to endorsement
constraints.
The combined cost of executing a process model with an associated policy
(experiment E6) has several components. First, the contract BindingAccess-
Control must be deployed at a fixed cost of 1,340,098 gas, entailing a transac-
tion fee of 0.0067 Ether (ETH)6. Next, the contracts generated from the policy
must be deployed, with gas ranging from 154,167 (simplest) to 1,803,898 gas
(largest policy), corresponding to 0.0007 ETH to 0.0090 ETH. The smart con-
tracts derived from the policies are deployed once and then reused, while the
contracts handling the process execution are deployed for each case. Thus the
policy deployment costs are amortized as more cases are executed. At runtime,
roles have to be bound to actors. The costs of executing one nominate operation
ranged from 111,407 (0.0005 ETH) to 168,270 (0.0008 ETH), while the vote
operations cost between 76,845 (0.0003 ETH) and 78,184 (0.0003 ETH). Finally,
when an actor performs a task, function canPerform is called to check if the ac-
tor is bound to the task’s role. This function invokes the TaskRoleMap smart
contract to retrieve the task-role relation. We observed a linear growth in the
deployment cost of this contract as the number of tasks increased, from 129,539
gas (0.0006 ETH) to 241,114 (0.0012 ETH). The cost of function canPerform
also grew linearly from 31,693 (0.0001 ETH) to 33,066 (0.0001 ETH).
6 Conclusion
Motivated by the possibilities opened by blockchain-based collaborative pro-
cess execution, this paper presented a role binding model and a binding policy
language that support collaborative binding and unbinding of actors to roles
at runtime. The proposal includes a method to verify the consistency of poli-
cies defined in the proposed language and an approach to compile the policies
into smart contracts. The proposal has been implemented on the Caterpil-
lar blockchain-based collaborative process execution tool. We evaluated the
6Gas price: 5 Gwei, average from https://ethgasstation.info on 30/11/2018.
14
costs (and therefore throughput) to deploy and execute smart contracts gener-
ated from binding policy statements, on the Ethereum platform. The evaluation
shows that the deployment and runtime policy enforcement costs grow linearly
with the number of roles and the complexity of the constraints. We acknowledge
that the evaluation is limited in scope (only one business process and up to 40
roles) and focuses on evaluating cost. An avenue for future work is to further
validate the approach via more thorough experiments and case studies.
While the proposed approach has been designed with the goal of supporting
collaborative process execution on blockchain, its field of possible applications is
wider. Another future work avenue is to study the applicability of this approach
to other blockchain applications where dynamic role binding may be required,
e.g. in crowdsourcing and computer-supported collaborative work scenarios.
References
1. Andrews, T., et al.: BPEL4WS, Business Process Execution Language for Web
Services Version 1.1. IBM (2003)
2. Bussard, L., Nano, A., Pinsdorf, U.: Delegation of access rights in multi-domain
service compositions. Identity in the Information Society 2(2), 137–154 (2009)
3. Decker, G., Kopp, O., Leymann, F., Weske, M.: BPEL4Chor: Extending BPEL for
modeling choreographies. In: IEEE ICWS 2007, pp. 296–303 (2007)
4. Frantz, C., Nowostawski, M.: From institutions to code: Towards automated gen-
eration of smart contracts. In: IEEE FAS*W 2016, pp. 210–215 (2016)
5. Kloppmann, M., et al.: WS-BPEL extension for people - BPEL4People. Joint
white paper, IBM and SAP (2005)
6. 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.
CoRR abs/1808.03517 (2018)
7. Lu, Y., Zhang, L., Sun, J.: Task-activity based access control for process collabo-
ration environments. Computers in Industry 60(6), 403–415 (2009)
8. Mendling, J., et al.: Blockchains for business process management - challenges and
opportunities. ACM Trans. Management Inf. Syst. 9(1), 4:1–4:16 (2018)
9. Murata, T.: Petri nets: Properties, analysis and applications. Proceedings of the
IEEE 77(4), 541–580 (1989)
10. Pautasso, C., Alonso, G.: Flexible binding for reusable composition of web services.
In: Software Composition, pp. 151–166 (2005)
11. Prybila, C., Schulte, S., Hochreiner, C., Weber, I.: Runtime verification for business
processes utilizing the Bitcoin blockchain. Fut. Gen. Comp. Syst. 46, 36–50 (2017)
12. Robinson, P., Kerschbaum, F., Schaad, A.: From business process choreography to
authorization policies. In: Data and Applications Security, pp. 297–309 (2006)
13. Russell, N., van der Aalst, W.M.P., ter Hofstede, A.H.M., Edmond, D.: Workflow
resource patterns: Identification, representation and tool support. In: CAiSE (2005)
14. Tran, A., Lu, Q., Weber, I.: Lorikeet: A model-driven engineering tool for
blockchain-based business process execution and asset management. In: Demo
Track at BPM 2018, pp. 56–60 (2018)
15. Wainer, J., Kumar, A., Barthelmess, P.: DW-RBAC: A formal security model of
delegation and revocation in workflow systems. Inf. Syst. 32(3), 365 – 384 (2007)
16. Xu, X., Weber, I., Staples, M.: Architecture for blockchain applications. Springer
(2019)
15
