Content uploaded by Fabian Stiehle
Author content
All content in this area was uploaded by Fabian Stiehle on May 26, 2023
Content may be subject to copyright.
Process Channels: A New Layer for Process
Enactment Based on Blockchain State Channels
Fabian Stiehle1and Ingo Weber1,2
1Technical University of Munich, School of CIT, Germany, first.last@tum.de
2Fraunhofer Gesellschaft, Munich, Germany
Abstract. For the enactment of inter-organizational processes, block-
chain can guarantee the enforcement of process models and the integrity
of execution traces. However, existing solutions come with downsides
regarding throughput scalability, latency, and suboptimal tradeoffs be-
tween confidentiality and transparency. To address these issues, we pro-
pose to change the foundation of blockchain-based process enactment:
from on-chain smart contracts to state channels, an overlay network on
top of a blockchain. State channels allow conducting most transactions
off-chain while mostly retaining the core security properties offered by
blockchain. Our proposal, process channels, is a model-driven approach
to enacting processes on state channels, with the aim to retain the desired
blockchain properties while reducing the on-chain footprint as much as
possible. We here focus on the principled approach of state channels as a
platform, to enable manifold future optimizations in various directions,
like latency and confidentiality. We implement our approach prototypical
and evaluate it both qualitatively (w.r.t. assumptions and guarantees)
and quantitatively (w.r.t. correctness and gas cost). In short, while the
initial deployment effort is higher with state channels, it typically pays
off after a few process instances; and as long as the new assumptions
hold, so do the guarantees.
1 Introduction
For the enactment of inter-organizational processes, blockchain can guarantee the
enforcement of rules and the visibility and integrity of execution traces, without
introducing a centralised trusted party. The current state of the art focuses on
on-chain enactment, where a process model is transformed into a smart contract
and executed on the blockchain [1]. However, blockchain execution comes with
downsides and suboptimal tradeoffs regarding scalability and other factors. [2,
Chapter 3]. On-chain process enactment inherits these problems; to address this,
related work has focused on improving the cost of the on-chain enactment compo-
nents (e.g., [3–5]). In contrast, we propose a more fundamental change: to move
from full on-chain enactment to layer two state channels. Layer-two technolo-
gies have emerged as a promising direction to address fundamental challenges
of blockchain technology [6]. One of these technologies are state channels. State
arXiv:2304.01107v2 [cs.CR] 25 May 2023
2 Fabian Stiehle and Ingo Weber
channels move the bulk of transactions into off-chain channels. In these chan-
nels, participants transact directly without the involvement of the blockchain.
The blockchain is only used for channel creation and as a dispute resolution and
settlement layer. This can greatly reduce the on-chain footprint, enabling new
levels of scalability and improved confidentiality, while mostly retaining the core
security properties offered by blockchain.
In this paper, we focus on conceptualising the principled approach of enacting
processes in state channels. We focus on the fundamental aspects of this new ap-
proach: conceiving how to achieve the main functionality and quality attributes,
studying where advantages and disadvantages lie, and creating a basis for a
new line of research. To this end, we propose process channels: a model-driven
approach to transform process models into state channel constructions.
To evaluate our approach, we develop a prototype: Leafhopper. As we propose
a new platform for blockchain-based enactment, we provide a qualitative assess-
ment and investigate the guarantees and assumptions compared to on-chain
enactment. We also provide a quantitative evaluation and benchmark our pro-
totype in terms of correctness and gas cost. While gas cost is foremost known as
a measure for transaction cost on Ethereum, it is directly linked to the amount,
size, computational complexity, and storage requirement of transactions [7]—
serving well as a measure to assess the on-chain footprint. We find that, while
the initial deployment cost of Leafhopper is higher, it can considerably reduce
gas cost. Leafhopper does so without weakening the main security guarantees of
the blockchain, given that some additional assumptions hold.
Following open science principles, we make the entire code and data of our
prototype and evaluation publicly available – see Footnote 10. Beyond Leafhop-
per, we also publish Chorpiler, the first open-source compiler capable of gener-
ating optimised smart contracts from choreographies. In the remainder of the
paper, we first discuss the background (Section 2) and related work (Section 3),
before presenting the process channel approach (Section 4). Implementation and
evaluation are covered in Section 5, before Section 6 concludes.
2 Blockchain and Layer Two Channels
A blockchain is an append-only store of transactions distributed across a net-
work of nodes [2, Chapter 1]. This data store is called ledger; the ledger and the
network of nodes form the defining parts of a particular blockchain system. Par-
ticipants in the network are identified through their blockchain address, which is
derived from a public key. Each transaction is cryptographically signed with the
sender’s corresponding private key, and is validated according to the blockchain
system’s protocol. Smart contracts allow to execute user-defined programs on the
blockchain. In practice, a blockchain system can provide integrity, immutability,
non-repudiation, equal-rights and full transparency [2, Chapter 1.4]
Layer two channels attempt to scale the underlying blockchain layer by of-
floading transactions [6]. The blockchain is no longer involved in every minute
transaction—these are moved into channels. The idea first emerged in the con-
cept of payment channels (e.g., [8]). Say, you want to pay an online news site
Process Channels: A New Layer for Process Enactment 3
$0.10 per article that you read. You create a channel with the news site, where
you lock $5.00 as initial funds (or collateral ). Every time you read an article,
you exchange an off-chain transaction with the news site, assigning an additional
$0.10 to their account. After 32 articles, you decide to close the channel, with
the accrued $3.20 assigned to the news site and the remaining $1.80 refunded
to your account. The concept has since been generalised to state channels [9].
Participants wishing to transact first agree on a contract governing the rules
of the channel and encode these on the blockchain (e.g., in a smart contract).
They then conduct off-chain transactions directly across the channel. For each
transaction, they agree on the outcome and cryptographically commit to their
agreement. Finally, when they have concluded their contract, they submit the
final state to the chain. If at any point a participant (supposedly) violates the
rules, e.g., attempts to falsify the outcome of a transaction, or become unavail-
able, the last unanimously agreed transaction is posted to the blockchain. From
this state, participants can then safely resume their interaction on the chain,
where the blockchain protocol enforces the honest execution of the contract.
More specifically, a channel constructs off-chain peer-to-peer connections be-
tween all channel participants. The off-chain channel replicates an on-chain state
machine, e.g., a smart contract, called the channel contract. Both can be mod-
elled with state iand state transition function step. The transition function takes
a set of commands cmdi+1 and transitions the state from ito i+ 1. Channels
typically transition through the following lifecycle phases [6]:
1. Establishment: All participants agree on a channel contract, which encodes
the rules of the channel and the initial state. Usually, this phase involves on-
chain activity, such as locking collateral or deploying the contract.
2. Transition(s): A participant proposes a new state transition stepi+1 through
a cryptographically signed message. Every other participant verifies that
stepi+1 is in conformance with their local version of the contract. If so, they
confirm by signing it and also sending their signature to every other partic-
ipant. Once a participant receives all other signatures on transition i+ 1,
they can consider the result of stepi+1 the new valid state.
3. Dispute: If a participant did not receive all signatures on a state transition
in time, or they receive conflicting transitions, they must assume that some
fault occurred. They must now start a dispute process on the blockchain. To
do so, the participant submits the last unanimously signed state transition
to the channel contract, which will install the result as new current state.
This closes the off-chain channel and starts the dispute window. Should a
participant submit a state transition that has already been superseded by a
more recent one, so called stale state, another participant must notice and
submit the most recent state.
4. Closure: After a channel closes and the dispute window elapses, future
transitions can be sent directly to the channel contract, which ensures the
continued validity of transitions. A channel can also be closed by unanimous
vote, installing the last agreed state transition as final state of the contract.
4 Fabian Stiehle and Ingo Weber
Channels introduces new assumptions that must hold for the channel protocol
to function as intended [6]:
1. Blockchain Reliability: The security properties of the blockchain hold and
valid transactions submitted to the blockchain are eventually accepted.
2. At Least One Honest Participant must be present in the channel to
contest faulty state transitions.
3. Always Online: State channels require participants to remain online during
the entire lifecycle of the channel to prevent execution forks [10], in which
a malicious actor starts the dispute phase and submits stale state to the
blockchain, e.g., statei−1. Honest participants must notice such an attempt
and submit statei.1
Given these assumptions, channels can achieve safety: the integrity of the con-
tract’s state is ensured, even when all parties but one are malicious; and liveness:
an honest participant can always advance the contract given a valid transition
function, even when all other parties try to stall the process [9].
3 Related Work
The current state of the art in blockchain-based business process enactment
focuses on on-chain enactment [1]. To reduce the on-chain footprint, related
work has focused on improving the cost of the on-chain components. Garc´ıa-
Ba˜nuelos et al. [3] introduced an optimised generation of smart contracts through
petri net reduction. We extend this approach for BPMN choreographies. L´opez-
Pintado et al. [4], and Loukil et al. [5] propose an interpreted approach, where a
process model is not compiled but executed by an interpreter component on the
blockchain. While the deployment becomes more costly, it leads to cost savings
over multiple instance runs.
In a recent survey, we pointed to layer two technologies as a promising re-
search direction [1]. To the best of our knowledge, this is the first work to in-
vestigate layer two state channels for enacting business processes. The state of
the art in state channel2constructions focuses on the formalisation and security
of protocols for general applications (e.g., [9,12,13]). More in line with our
work, McCorry et al. [14] present a case study investigating the feasibility and
applicability of their state channel construction. They present a template for mi-
grating an existing smart contract to a state channel construction. While they
present a state channel architecture for nparties, they chose a two-party game
as their case. In two-party games, participants can take turns. However, when
more participants are involved, a schedule becomes necessary [13] (see also Sec-
tion 4.1) We present process channels: a model-driven approach, where a process
1We generally assume a party “looks after themselves”, and follows a strategy with
the highest payoff.
2Hyperledger Fabric uses the terminology of channels for their subnet functional-
ity [11]. The similarity to state channels is weak; like subnets, fabric channels par-
tition the on-chain ledger. State channels construct off-chain channels and use the
security guarantees of the on-chain ledger as settlement and dispute resolution layer.
Process Channels: A New Layer for Process Enactment 5
Generate
BPMN Choreography
Design Time
Interaction Net
tn
t0
...
Communicate
Channel with
n triggers
Run Time
Channel Contract
Fig. 1: Overview: From BPMN choreographies to process channels.
model is used to automatically generate the entire channel setup. The process
control-flow naturally enforces a schedule upon the participants. We discuss the
particularities of enforcing choreographies in channels and evaluate our approach
quantitatively and qualitatively in comparison to a full on-chain baseline. For
our evaluation, we chose two commonly used business processes, which allows us
to compare our approach to existing related work.
4 Process Channels
Before we introduce our approach, we address a particular challenge when design-
ing n-party state channels: the scheduling problem. After, we give an overview of
our approach, describe our model transformation approach, and, lastly, outline
the channel’s protocol in detail.
4.1 Prelude: The Scheduling Problem
In an n-party state channel construction, multiple concurrent proposals can
deadlock the protocol, where a subset of participants is waiting for the con-
sent to a proposed state transition, while other participants, in turn, are waiting
for the consent of a concurrently proposed transition [13]. In 2-party state chan-
nels, participants can simply take turns (e.g., in [12]). However, for n-parties,
this problem constitutes a leader election problem. A probable solution is the
utilisation of a leader election algorithm; however, this would introduce commu-
nication overhead and is not done in practice. Instead, this problem is either
not addressed in literature, or a specific schedule of turns is enforced over all
participants (see [15] for a survey). However, the scheduling of a process is a
well understood problem in the world of business process management. A pro-
cess model inherently contains rules considering the order of events, while a
process choreography contains rules regarding the roles and interactions of par-
ticipants [16, Chapter 6]. We can make direct use of these properties to derive a
valid state channel construction.
4.2 Overview
In Figure 1, we show an overview of our approach. At the core of our approach
is the model-driven engineering paradigm. This paradigm has been found to ad-
dress many challenges of developing blockchain-based applications [17]. Channel
6 Fabian Stiehle and Ingo Weber
constructions exacerbate the complexity issue of developing blockchain-based
applications further. More functionality is required, both on and off the chain,
thus, introducing a new trust concern: the security of the channel protocol. To
alleviate this issue, we propose to generate channel components from a process
model. We base our approach on BPMN choreography diagrams. These fit well
the model of state channels, where the focus is on a set of interconnected au-
tonomous participants, initiating messages according to some schedule. From
a BPMN choreography model, a compiler component generates an interaction
Petri net. This serves as a middle layer presentation, and allows us to apply
optimisation techniques before compilation. From the optimised interaction net,
we generate the process channel contract, which is deployed on the blockchain.
Furthermore, process enactment capabilities are generated for the channel trig-
ger components. Each organisation deploys such a trigger and exposes it to the
channel network. Each trigger is interconnected. Additionally, each trigger must
be connected to the blockchain, providing access to the channel contract. On the
blockchain, the channel contract handles channel establishment, disputes, and
closure. We assume that each organisation runs a process-aware information sys-
tem (PAIS) in their (private) organisational network. The PAIS communicates
with the trigger to interact with the network. In particular, the responsibilities
of each generated component are as follows.
– The channel contract is deployed on the blockchain. Upon deployment, the
blockchain addresses of the participants are bound to their corresponding
role. Should a dispute be triggered, the contract validates the submitted
state transition by verifying that it has been signed by all participants. The
channel also contains process enactment capabilities: it enforces the honest
continuation of the contract, should a dispute occur.
– The channel trigger communicates with the channel network to enact the
public part of the model. Each trigger must be configured with: the identify
and secret key of the participant, the blockchain addresses of the other par-
ticipants, the host information of the other triggers, and the address of the
channel contract. Once a trigger receives a request from the PAIS, the trigger
performs a conformance check to verify the request locally; when success-
ful, it proposes a new state transition to the network. The trigger monitors
continuously whether the channel contract has transitioned into the dispute
phase. Should a trigger not be able to advance the public process, or receive
a non-conforming transition request, it starts a dispute phase.
4.3 Optimised Generation
As outlined, channel contract and trigger components require process enact-
ment capabilities. We generate these from a BPMN choreography model. Our
approach, hereby, is based on the optimised translation technique presented in
Garc´ıa-Ba˜nuelos et al. [3]: a process model is converted into a Petri net, and
this net is reduced according to well-established equivalence rules. In the code,
the process state is then encoded as a bit array. Our approach is based on in-
teraction Petri nets, which are a special kind of labelled Petri nets. Interaction
Process Channels: A New Layer for Process Enactment 7
Petri nets have been proposed as the formal basis for BPMN choreographies [18].
As labels, they store the initiator and respondent information, which are essen-
tial for the channel construction. After conversion, we apply the same reduction
rules as in [3]. For this contribution, we limit the scope to choreography tasks,
start and end events, and parallel and exclusive gateways. As in [3], this also
supports looping behaviour. In contrast to [3], we must restrict enforcement
to certain roles: only initiators are allowed to enforce tasks.3Thus, in our ap-
proach, we can differentiate between manual and autonomous transitions. Man-
ual transitions correspond to tasks that are initiated by a participant; these must
be explicitly executed. Autonomous transitions are the remaining silent transi-
tions. Converting a process model into a Petri net creates silent transitions, and
while most of them can be deleted through reduction, some cannot be removed
without creating infinite-loops [3]. These transitions must then be performed by
the blockchain autonomously, given that the correct conditions are met. Conse-
quently, these transitions are not bound to a role. The differentiation allows a
more efficient execution: if the conditions for a manual task are met, it is fired
and terminated; further autonomous transitions may be fired, without requiring
further manual transitions.
4.4 Channel Protocol
Once the components are generated, they execute the channel protocol. In the
following, we outline the protocol of our channel construction, based on the
channel lifecycle model introduced in Section 2.
Establishment. For the following, we assume all channel triggers are deployed
and have established, secure connections. From here, blockchain addresses are
exchanged between participants and a random participant is chosen to deploy the
channel contract. The deployment initialises the contract, binding all addresses
to their role and setting the initial state. The address of the deployed contract is
distributed to all participants; these verify the contract to ensure it was initialised
with the correct addresses and the correct initial process state.4If the contract
passes verification, the contract is accepted as channel contract.
Transition. We depict the protocol for a state transition for a sequence flow from
state statei−1to stateiin Fig. 2. The PAIS sends an enactment request for a task
to its corresponding channel trigger. The task must encode all required infor-
mation to compute the new process state and can additionally include arbitrary
data. The trigger verifies that the enactment of the task is in conformance with
its local process state. It then becomes the proposing initiator pfor this task, and
prepares the state transition proposal stepi. Each transition proposal is assigned
a sequence number i, which is incremented after each successful transition. stepi
3A choreography task can be one-way or two-way: i.e., it optionally includes a re-
sponse. We assume that a choreography task is one-way; two-way tasks can be
regarded as syntactic sugar and adding support for those is no conceptual challenge.
4This procedure can be made easier by forcing deployment from an agreed upon
channel factory contract [2, Chapter 7.4.4].
8 Fabian Stiehle and Ingo Weber
confirm
Proposing
Initiator p
when all signatures
received:
state = newStatei
Signing
Participant s
stepi, sigi,p check stepi, sigi,p
sigi,s
check stepi, (sigi,p, sigi,s, ..., sigi,n)
state = newStatei
PAIS
enact task
stepi, (sigi,p, sigi,s, ..., sigi,n)
notify PAIS
Fig. 2: Sequence diagram for a channel transition (happy path).
includes the proposed task and resulting state newStatei.5The trigger crypto-
graphically signs the proposed transition and sends stepi, and its signature sigi,p
to all other participants, called the signing participants. All signing participants
verify that stepiwas proposed by the correct initiator by verifying the signa-
ture, and that stepileads to the next conforming state. If all checks pass, each
signing participant ssigns the new step and sends their signature sigi,s back to
the initiator. Once the initiator has collected all signatures (sigi,s, ..., sigi,n ), it
can accept newStateias new state of the process. It now confirms the transi-
tion proposal by sending the set of signatures to all signing participants. These
also verify the signatures and, when all checks pass, can also accept newStatei.
All participants must store the received signatures and corresponding transition
proposals, as they are required should a dispute occur.6
As we have discussed in Section 4.1, a problem of n-party state channels are
multiple concurrent state transition proposals. Imposing an order of transitions
is, therefore, paramount. Using the control-flow information of the model, it is
often trivial to enforce such an order. Consider, a simple sequence flow from
task tto task t′. The ordering t<t′naturally follows. This is less so when
control-flow branches after gateways. For exclusive gateway branches, it suffices
to collapse the possible branches into one during run time. That is, the conditions
present on the outgoing sequence flows of the gateway must be based on internal
channel state and be part of the transition proposal, so it can be made available
to the blockchain in case of a dispute; it can not be based on external state.
This requirement can be lifted when all immediately following tasks belong to
the same initiator, as it then becomes a (private) choice of a single participant.
Parallel gateways, on the other hand, permit concurrent behaviour and a
unique order is not enforceable. Real concurrency is a non-trivial problem in
state channel constructions [15]. As each state transition must encode a sequence
number and the new global process state for a possible dispute phase, a concur-
rent execution can deadlock the protocol. We, thus, require that tasks on parallel
branches are serialised at run time into any order chosen by the participants.
5To prevent the replay of transitions across cases, instances, or blockchains, unique
identifiers must also be included, e.g., case ID, instance ID, and chain ID.
6To reduce the amount of messages, confirmations can be prepended to a transition
proposal. That is, once an initiator has collected all signatures for stepi., it only sends
the confirmation to the next initiator. The next initiator prepends the confirmations
to the next transition proposal stepi+1 .
Process Channels: A New Layer for Process Enactment 9
Dispute. At any point, the channel contract is in a certain state i. A participant
can trigger a dispute by providing all participants’ signatures for state transition
stepj, where i<j. Once the contract is in dispute mode, additional state can
be submitted until the dispute window elapses. Then, the contract continues
on-chain. We describe possible dispute scenarios.
–Non-Conforming Transition: Consider a non-conforming transition is pro-
posed in the channel. Assuming there is at least one honest participant, the
transition would not acquire unanimous consent. A participant can trigger a
dispute submitting the last agreed transition to the blockchain; thus, forcing
the continuation of the contract on the blockchain. Faulty participants can,
however, also stop to take part in the protocol, which we discuss next.
–Unavailability: Consider a transition is proposed to the channel. After a local
timeout, the initiator does not receive signatures from all participants. To
ensure liveness, a dispute must be triggered to force the transition on-chain.
Consider the reverse: after a local timeout, a signing participant does not
receive the expected transition proposal or confirmation. The participant can
trigger a dispute. Now, the initiator has to perform the transition on-chain
or be identified as participant stalling the process, which could be penalised.
Closure. Once participants reach the end event in unanimous consent, they sub-
mit the final state to the channel contract. Otherwise, the end event is reached
on-chain. In both scenarios, the process terminates and a new case can be in-
stantiated. The contract assigns a new case ID and resets the process state.
5 Implementation and Evaluation
To enable the evaluation of our approach, we developed two prototypes, Chor-
piler and Leafhopper. We perform a quantitative and qualitative evaluation and
compare our approach to an on-chain enactment baseline. For the quantita-
tive evaluation, we use two use case process models from literature. We verify
the correctness of our implementation by replaying process traces and perform
benchmarks to assess cost. For the qualitative evaluation, we discuss the required
assumptions and provided guarantees of process channel enactment.
5.1 Implementation and Setup
Chorpiler and Leafhopper. We have developed two tools, Chorpiler and
Leafhopper. Chorpiler implements the optimised generation of enactment com-
ponents, as outlined in Section 4. It is capable of generating process channel
contracts and on-chain enactment contracts in Solidity, as well as enactment
functionality in TypeScript, which is used in the channel triggers. The static
trigger component capabilities, e.g., routing, signature verification etc., are im-
plemented in Leafhopper and run on Node.js7. Leafhopper uses Chorpiler to
generate the process channel contract and the enactment capabilities of the
7See Node.js,https://nodejs.org/en, accessed 2023-03-17.
10 Fabian Stiehle and Ingo Weber
channel trigger. For each participant in the choreography, a trigger is deployed.
For ease of deployment, each trigger is run in a Docker container and the trigger
network can be deployed using Docker Compose.8
Benchmark Setup. We benchmark the supply chain [19] (adapted from [20])
and incident management [21] case, which are well known from related work. To
help assess our approach, we compare it to a baseline. The baseline provides the
same model support as Leafhopper, but enacts the process completely on-chain,
as in related work. For each case, we generate the baseline, channel triggers, and
channel contract. The triggers are run in a local network. The smart contracts
are deployed to an Ethereum environment; we use the Ethereum simulation tool
Ganache.9Following open science principles, and to enable replicability, we made
both our prototypes, evaluation scripts, and data publicly available.10
5.2 Quantitative Evaluation
Correctness. We verify that the network only accepts conforming traces and
always remains in a stable state, i.e., all triggers report the same state after
some finite time. To do so, we follow the methodology outlined in [19]. For each
case, we replayed all conforming traces (two for supply chain and four for the
incident management case). After, we generated 2000 non-conforming traces;
to do so, a conforming trace was randomly manipulated by one of the following
operations: add an event, remove an event, and swap the position of two events.11
We replayed these traces from a local script which, for each event, connects to the
corresponding initiator to propose the task.12 All events were classified correctly
w.r.t. conformance, and after each trace replay the channel was in a stable state.
Cost Analysis. We compare the cost of our baseline to Leafhopper. For the
baseline, we replayed, for each case, all conforming process variants (two for
supply chain and four for the incident management case) and recorded the gas
cost of all interactions with the blockchain. As gas costs are deterministic, mul-
tiple runs of the same variant are not required.
Cost in Leafhopper is more difficult to assess and is driven by the cost for the
channel establishment (deployment of the contract) and successful closure (unan-
imous submission of the final state) or dispute. To study the cost behaviour, we
performed, analogous to our baseline, for each conforming process variant the
following benchmarks:
1. A best case run with no disputes, where the channel is unanimously closed.
8See Docker Compose,https://docs.docker.com/compose, accessed 2023-03-17.
9See Ganache,https://trufflesuite.com/ganache, accessed 2023-03-17.
10 Leafhopper is available at https://github.com/fstiehle/leafhopper. The reposi-
tory includes instructions and scripts to automate the replication of our evaluation.
Chorpiler is available at https://github.com/fstiehle/chorpiler.
11 We removed any coincidentally created conforming traces. In total we replayed 1812
non-conforming traces to the incident mgmt. and 1933 to the supply chain case.
12 Normally, the local trigger would also verify the request and only forward valid
requests. We disabled this functionality to allow us to simulate a faulty component.
Process Channels: A New Layer for Process Enactment 11
Case
Baseline Leafhopper
Deploy-
ment
Avg. Exec. Deploy-
ment
Exec.
Best
Case
Avg. Exec.
Case Task Bad Case Worst Case On-Chain
Task
Supply
Chain 396.732 347.076 34.708 772.282 88.319 310.186 495.207 38.691
Incident
Mgmt. 408.954 190.509 31.752 784.823 88.319 199.545 328.889 34.774
Table 1: Gas cost of Leafhopper in relation to the baseline.
−2,000 K
−1,000 K
0 K
1,000 K
2,000 K
2 4 6 8 10 12 14 16 18 20
Number of Case Executions
Gas Savings
Baseline
Only Best
5% Disputes
20% Disputes
Only Bad
Only Worst
Fig. 3: Gas savings compared to baseline, when the initial deployment is re-used.
2. A bad case run, where a dispute is triggered after half of the process. As a
result, the other half must be completed on the blockchain.
3. A worst case run, where a dispute with stale state is made immediately
after the start event. An honest participant then submits the last agreed-
upon state, and the entire remaining process must be completed on-chain.
Table 1shows the recorded gas costs for our benchmark experiments.13 Com-
pared to our baseline, Leafhopper incurs around twice the cost for deployment
due to the implemented channel capabilities. However, the best case execution
considerably improves upon the avg. execution cost of the baseline. Furthermore,
we can see that the best case execution cost is fixed. It requires one round of
signature verification. The cost, hence, does not depend on the complexity of
the process or its tasks, only on the number of participants—five participants
for both cases.
The bad case execution cost is still lower for the supply chain case and slightly
higher for the incident management case compared to the avg. execution cost of
the baseline. The incident management case is on average shorter (six versus ten
tasks of the supply chain case) but has the same number of participants. Thus,
the fixed state verification cost has a higher impact on the total cost of the shorter
process. The worst case cost is considerably higher than the baseline’s average.
This is expected, as it constitutes two state submissions and the enactment of
the entire remaining process on the chain. Should a dispute occur, Leafhopper
exhibits slightly (around 10%) higher cost for enacting a task on the blockchain.
This is the result of having to determine whether a dispute is currently active.
Cost Under Different Dispute Scenarios. To put the cost of Leafhopper into
context, we assess the relative overhead of Leafhopper compared to the base-
13 While our baseline is based on [3], it incurs increased gas cost (compare with Table 2),
as it additionally implements role enforcement (c.f. Section 4.3).
12 Fabian Stiehle and Ingo Weber
Case Approach Deploy-
ment
Avg. Case
Execution
Leafhopper Overhead
Deploy-
ment
Best
Case
Bad
Case
Worst
Case
Supply
Chain
Garc´ıa-Ba˜nuelos et al. [3] 298.564 272,186 1.6 -0.7 0.1 0.8
Caterpillar [22] 1,100,590 566,861 -0.3 -0.8 -0.5 -0.1
ChorChain [23] 2,802,543 1,156,734 -0.7 -0.9 -0.7 -0.6
CoBuP [5] 4,832,706 254,661 -0.8 -0.6 0.2 0.9
Incident
Mgmt.
Garc´ıa-Ba˜nuelos et al. [3] 345.743 166,345 1.3 -0.5 0.2 1.0
Caterpillar [4] 1,119,803 324,420 -0.3 -0.7 -0.4 0
ChorChain [23] 3,278,656 1,028,505 -0.8 -0.9 -0.8 -0.7
CoBuP [5] 4,639,652 249,378 -0.8 -0.6 -0.2 0.3
Table 2: Gas cost of Leafhopper in relation to other approaches.
line when considering different dispute rates. That is, the number of expected
disputes over multiple case runs. We illustrate this in Fig. 3, where we show
how the average cost savings for a case execution on Leafhopper develops for
different dispute scenarios, when the initial deployment is re-used. We depict
five scenarios, only best case runs, 5% disputes, 20% disputes, only bad, and
only worst case runs. For the 5% and 20% runs, we assume an equal share of
bad and worst cases. Both percentages are taken from an industry survey, where
5% constitutes the best and 20% the worst measured average contract dispute
rate by industry sector.14
We can see that, when considering only best cases, the deployment costs
of Leafhopper is amortised after three case runs. The 5% dispute rate follows
closely, while the 20% run requires 4 cases to break even. Furthermore, we can
see that less than one best case run can more than amortise one worst case run.
Cost Compared to Related Work. In Table 2, we compare the cost of Leafhopper
to selected approaches from literature by reporting its relative overhead.15 We
chose Garc´ıa-Ba˜nuelos et al. [3] for its efficient implementation technique; Cater-
pillar [22] for providing the most complete feature set; and the choreography-
based approaches ChorChain [23] (compiled) and CoBuP [5] (interpreted).
The results of this comparison are in line with our above analysis. Leafhop-
per’s best case provides vast cost improvements (between 1/10 to 1/2 of the
cost). The medium case overhead ranges from big improvement (1/10) to slightly
worse (20% more expensive) depending on the efficiency and feature support of
the approach. The worst case cost ranges from double the cost to still consid-
erably (3/10) cheaper. Notably, Caterpillar and ChorChain exhibit the highest
cost. However, both provide more features. ChorChain additionally implements
answer and response patterns and does not implement net reduction and encodes
the process state as simple array type, leading to increased cost. This shows the
potential of Leafhopper to improve the cost of more complex implementations
with its fixed state verification cost.
14 IACCM: Are you in an adversarial industry? Insights for contract negotiators and
managers. 2014. https://wp.me/pa5oX-RH, accessed 2023-03-28.
15 Due to the different feature sets being supported, these approaches incur different
gas costs; cost should not be understood as the only yardstick to compare approaches
by. Since our approach in this paper is quite different from full on-chain approaches,
we find this comparison worthwhile reporting.
Process Channels: A New Layer for Process Enactment 13
5.3 Qualitative Evaluation
To gain a more holistic understanding of the proposed approach, we now move
to a higher level of abstraction and compare the process channel approach to
our baseline on-chain approach, which enacts the entire process on-chain, on the
basis of relevant quality attributes. As such, we assess which guarantees the ap-
proaches provide, and which assumptions must hold. Xu et al. [2, Chapter 1.4]
identify the main non-functional properties that blockchain provides: immutabil-
ity, non-repudiation, integrity, transparency, and equal rights. We summarise our
assessment in Table 8.2.
Assumptions. Both approaches assume the reliability of the blockchain. In ad-
dition, process channels require at least one honest participant in a channel;
otherwise, colluding participants can install arbitrary state. In contrast, an on-
chain approach can still rely on other validators in the blockchain network to
verify a transaction. Process channels also require explicit role-binding: roles
must be bound to (trigger) hostnames and blockchain accounts. This informa-
tion must be propagated through the channel. Additionally, participants joining
the network must deploy trigger components. This inhibits process flexibility.
Also, participants in the channel must be always available, they cannot go of-
fline in-between tasks. They must sign transitions and watch for disputes. Some
usage scenarios, e.g., energy-constrained wireless devices, may be ruled out by
this requirement. Finally, channels introduce additional components and, thus,
additional attack surface.
Guarantees. As only channel participants see and verify transitions, integrity
and transparency can only be demonstrated to participants with access to the
channel. Also, equal rights can only hold within the channel. Immutability and
non-repudiation require that transition proposals are stored durably by a partic-
ipant. Otherwise, a faulty participant can submit stale state. Additionally, under
certain circumstances a participant can stall the process without being identified
as doing such. It is undecidable whether an initiator is stalling the process by
not sending the next transition proposal or whether a signing participant has
Table 3: Assumptions and guarantees of on-chain and process channel enactment.
Assumptions On-Chain Process Channel
Blockchain Reliability ✓ ✓
At Least One Honest Participant ✕✓
Explicit Role-Binding ✕✓
Participants are Always Available ✕✓
Security of Off-Chain Protocol ✕✓
Guarantees
Integrity ✓ ✓§
Immutability ✓ ✓†
Non-Repudiation ✓ ✓†⋆
Transparency ✓ ✓§
Equal Rights ✓ ✓§
⋆Stalling is a non-attributable fault †Requires storage of proof
§Requires access to channel
14 Fabian Stiehle and Ingo Weber
refused to sign it [14]. While the process will be forced to continue on-chain, the
channel contract cannot attribute who was at fault, limiting the use of penalties.
5.4 Discussion
In Section 5.3, we analysed the assumptions and guarantees of off-chain en-
actment. When these assumptions are met, the channel can offer comparable
guarantees to an on-chain approach. However, the closed nature of the channel
hinders flexibility. Furthermore, third parties can only verify the honest execu-
tion of the process if given access to all messages in the channel. Additionally,
process data is no longer durably stored on the blockchain; where such durability
is required, it needs to be ensured off-chain.
In Section 5.2, we reported on the gas cost of our prototype Leafhopper.
While gas costs are an especially limiting factor when enacting processes on
public blockchains, they can also limit scalability of private and permissioned
deployments, as gas costs are directly linked to the number, computational com-
plexity, and storage requirement of transactions. We found that, for processes
which are repeated more than 3-4 times without disputes, Leafhopper can signifi-
cantly reduce the gas cost of on-chain enactment. In Leafhopper, costs are highly
dependent on how often a dispute occurs. If we assume the off-chain protocol
will resolve trivial faults, such as temporary connectivity issues, the blockchain
will be mainly involved in resolving permanent faults, such as malicious acts
or long-term crashes, which constitute a contract breach. For our benchmarked
cases, a worst case run was amortised after only one dispute-free run. In the case
of interorganisational processes, organisations generally form a collaboration to
work towards a common business goal; and under typical industry dispute rates,
Leafhopper was able to significantly reduce cost. Nonetheless, Leafhopper’s cost
is case specific and not as predictable as on-chain enactment. This introduces
additional uncertainties. We have provided an analysis to help gauge the cost
of Leafhopper. Still, future studies are required to address the uncertainties and
aspects not covered in our current evaluation.
Beyond cost, process channels have the potential to improve further dimen-
sions such as latency and confidentiality. On-chain approaches are highly depen-
dent on the underlying latency of the blockchain. Process channels can reduce
this reliance. Blockchain latency differs greatly between different blockchain plat-
forms and the required trust assumptions of the application; related work reports
latency ranging from seconds (e.g., [19,24]) to minutes and more (e.g., [25]). Fur-
thermore, blockchain consensus can be highly probabilistic, resulting in high la-
tency outliers (see e.g., [24,25]). Similarly, channels reduce the exposure of data.
While confidentiality is breached during a dispute phase, there is potential to
design the dispute phase in a confidentiality-preserving manner; for example, by
utilising zero-knowledge proofs. While these are usually costly operations, they
would only be required in the case of a dispute, making their use viable [26].
There are further topics not addressed and left to future work.
–Length of Dispute Window: The choice of the dispute window is an important
factor. It must be chosen so that an honest participant has time to react to
Process Channels: A New Layer for Process Enactment 15
stale state. Thus, it must be multiples of the underlying blockchain latency.
There is currently no consensus in literature on how to determine this. In
the BPM context, the particular business case may also influence this choice.
–Dispute Phase Design: In a choreography, a participant that stops to collabo-
rate will stall the process indefinitely. A more advanced dispute design could
penalise faulty participants and replace them. There is potential to design
dispute processes, specific to business cases, to incentivise honest participa-
tion. However, such a design is limited by non-attributable faults.
–Channel Networks: In channel networks, multiple channels are supported by
one smart contract. In our current design, the contract is application specific.
Exploring a design where a contract can support multiple processes could
pave the way toward a network of cost efficient, on-chain choreographies.
6 Conclusion
In this paper, we propose to address challenges in inter-organizational process
enactment by moving to a layer two approach: blockchain-based state channels.
With this approach, we aim to reduce the on-chain footprint per process in-
stance. The evaluation of gas cost showed a significant reduction for common
settings. Unsurprisingly, in our correctness evaluation, we found no issues. More
interestingly, the qualitative evaluation showed that the blockchain properties
largely remain intact when moving to our channel approach—as long as the
assumptions are met, such as having at least one honest participant per channel.
Moving communication and state into channels may, in the future, prove use-
ful to achieve lower latency and improved confidentiality – but those aspects were
out of scope for this paper, where we focused on the principled approach and and
extensive evaluation. Future work will, thus, address latency and confidentiality,
but also expanding the business-level guarantees and adding flexibility, e.g., for
dynamic role assignment.
References
1. Stiehle, F., Weber, I.: Blockchain for business process enactment: a taxonomy and
systematic literature review. In: BPM: Forum. Volume 459 of LNBIP. (2022) 5–20
2. Xu, X., Weber, I., Staples, M.: Architecture for Blockchain Applications. Springer
(2019)
3. Garc´ıa-Ba˜nuelos, L., Ponomarev, A., Dumas, M., Weber, I.: Optimized Execution
of Business Processes on Blockchain. In: BPM. Springer, Cham (2017) 130–146
4. L´opez-Pintado, O., Dumas, M., Garc´ıa-Ba˜nuelos, L., Weber, I.: Interpreted exe-
cution of business process models on blockchain. In: EDOC, IEEE (2019) 206–215
5. Loukil, F., Boukadi, K., Abed, M., Ghedira-Guegan, C.: Decentralized collabora-
tive business process execution using blockchain. WWW 24(5) (2021) 1645–1663
6. Gudgeon, L., Moreno-Sanchez, P., Roos, S., McCorry, P., Gervais, A.: Sok: Layer-
two blockchain protocols. In: Financial Cryptography and Data Security. 201–226
7. Buterin, V.: A Next-Generation Smart Contract and Decentralized Application
Platform. https://ethereum.org/en/whitepaper (2014) Accessed 2023-03-29.
16 Fabian Stiehle and Ingo Weber
8. Poon, J., Dryja, T.: The bitcoin lightning network: Scalable off-chain instant
payments. https://lightning.network/lightning-network-paper.pdf (2016)
Online, Accessed 2023-03-29.
9. Miller, A., Bentov, I., Bakshi, S., Kumaresan, R., McCorry, P.: Sprites and state
channels: Payment networks that go faster than lightning. In: Financial Cryptog-
raphy and Data Security. 508–526
10. McCorry, P., Bakshi, S., Bentov, I., Meiklejohn, S., Miller, A.: Pisa: Arbitration
outsourcing for state channels. In: AFT ’19, ACM 16–30
11. Androulaki, E., Barger, A., Bortnikov, et al.: Hyperledger fabric: a distributed
operating system for permissioned blockchains. In: EuroSys. (2018) 1–15
12. Dziembowski, S., Faust, S., Host´akov´a, K.: General state channel networks. In:
ACM SIGSAC CCS. (2018) 949–966
13. Dziembowski, S., Eckey, L., Faust, S., Hesse, J., Host´akov´a, K.: Multi-party virtual
state channels. In: EUROCRYPT, Springer, Cham (2019) 625–656
14. McCorry, P., Buckland, C., Bakshi, S., W¨ust, K., Miller, A.: You sank my battle-
ship! a case study to evaluate state channels as a scaling solution for cryptocur-
rencies. In: Financial Cryptography and Data Security, Springer 35–49
15. Negka, L.D., Spathoulas, G.P.: Blockchain state channels: A state of the art. IEEE
Access 9(2021) 160277–160298
16. Weske, M.: Business Process Management: Concepts, Languages, Architectures.
Third edn. Springer, Heidelberg (2019)
17. Di Ciccio, C., Cecconi, A., Dumas, M., Garc´ıa-Ba˜nuelos, L., L´opez-Pintado, O.,
Lu, Q., Mendling, J., Ponomarev, A., Binh Tran, A., Weber, I.: Blockchain Support
for Collaborative Business Processes. Informatik Spektrum 42(3) (2019) 182–190
18. Decker, G., Weske, M.: Local enforceability in interaction Petri nets. In: BPM.
Volume 4714 of LNCS., Springer, Cham (2007) 305–319
19. Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev, A., Mendling, J.:
Untrusted Business Process Monitoring and Execution Using Blockchain. In: BPM.
Volume 9850 of LNCS. Springer, Cham (2016) 329–347
20. Fdhila, W., Rinderle-Ma, S., Knuplesch, D., Reichert, M.: Change and compliance
in collaborative processes. In: IEEE SCC. (2015) 162–169
21. OMG: BPMN 2.0 by Example, Version 1.0. https://www.omg.org/cgi-bin/doc?
dtc/10-06-02 (2010) Online, Accessed 2023-03-29.
22. 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. Soft-
ware: Practice and Experience (2019) spe.2702
23. Corradini, F., Marcelletti, A., Morichetta, A., Polini, A., Re, B., Tiezzi, F.: Engi-
neering Trustable and Auditable Choreography-based Systems Using Blockchain.
ACM TMIS 13(3) (2022) 1–53
24. Corradini, F., Marcelletti, A., Morichetta, A., Polini, A., Re, B., Scala, E., Tiezzi,
F.: Model-driven engineering for multi-party business processes on multiple block-
chains. Blockchain: Research and Applications 2(3) (2021) 100018
25. Prybila, C., Schulte, S., Hochreiner, C., Weber, I.: Runtime verification for business
processes utilizing the Bitcoin blockchain. FGCS 107 (2020) 816–831
26. Zhang, Y., Long, Y., Liu, Z., Liu, Z., Gu, D.: Z-channel: Scalable and efficient
scheme in zerocash. Computers & Security 86 (2019) 112–131
