=Paper=
{{Paper
|id=Vol-3298/BES-1
|storemode=property
|title=On Storing Data Objects of Business Processes on Blockchain Channels
|pdfUrl=https://ceur-ws.org/Vol-3298/paper_BES_1542.pdf
|volume=Vol-3298
|authors=Julius Köpke,Adnan Brdanin
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/KopkeB22
}}
==On Storing Data Objects of Business Processes on Blockchain Channels==
https://ceur-ws.org/Vol-3298/paper_BES_1542.pdf
On Storing Data Objects of Business Processes on
Blockchain Channels
Julius Köpke1 , Adnan Brdanin1
1
Alpen-Adria-Universität Klagenfurt, Universitätsstraße 65-67, 9020 Klagenfurt, Austria
Abstract
Blockchain systems provide strong support for enforceability if all data relevant for transaction veri-
fication is stored on-chain. An example is the effective prevention of double spending in the bitcoin
network. However, this approach has substantial drawbacks if privacy is a concern. One alternative
in the enterprise context are architectures where access to the blockchain can be restricted to specific
participants, and separate blockchains (channels) between subsets of participants can be established.
While such architectures are promising for supporting privacy, there can still be trade-offs between
the supported levels of enforcement and the degree of privacy that can be natively supported by those
systems. In this paper, we follow a model-based approach, where privacy and enforceability requirements
are explicitly modeled in business processes. We provide a detailed analysis of how different levels
of data privacy affect the possible placement of data in channels on Hyperledger Fabric (HLF) and to
what degree decisions over data with privacy requirements can be enforced by the built-in transaction
verification mechanism. Finally, we present a prototype based on distributed oracles that allows us to
enforce the correctness of decisions over data located on different channels.
Keywords
Smart Contracts, Permissioned Blockchains, Channels, Enforceability, Business Processes, Privacy,
Privity
1. Introduction
Blockchain platforms have gained interest in the Enterprise context over the previous years.
This is witnessed by a large body of research on the model-driven engineering of blockchain
based applications and the execution of business processes on blockchains [1, 2]. Blockchain
platforms provide highly desirable properties for inter-organizational collaborations such as
observability, immutability, availability, persistency, and they allow to execute transactions in
low-trust environments without a trusted third party. Peers in the blockchain network will
only accept a new block if all its transactions are valid. On public blockchains, this is typically
achieved by replaying the transactions on each peer. This allows blockchains to guarantee the
correctness of transactions in zero-trust environments (e.g., cryptocurrencies).
Second-generation blockchain platforms such as Ethereum [3] support Turing-Complete
languages for defining custom transactions referred to as smart contracts. The term smart
contract was originally coined by N. Szabo in [4] as the counterpart of traditional contracts
PoEM’2022 Workshops and Models at Work Papers, November 23-25, 2022, London, UK
$ julius.koepke@aau.at (J. Köpke); adnanbr@edu.aau.at (A. Brdanin)
https://www.aau.at/isys/ (J. Köpke)
0000-0002-6678-5731 (J. Köpke)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
enforced by hardware and software. Szabo proposed the design goals of observability, online
enforceability, and privity for smart contracts. Observability describes the possibility of each
participant to observe each other’s performance. Online enforceability aims at making a breach
of the contract infeasible. Privity in the context of smart contracts aims at limiting the spread
of knowledge and control to the participants with a contractual need-to-know. In this sense,
privity represents privacy requirements of smart contracts. We discriminate between the orig-
inal smart contracts and code on blockchains by using the term smart contract code for the latter.
To guarantee the correctness of a transaction on a blockchain, all data for verification must
be available on-chain. This can conflict with privacy requirements (e.g., when data must
not be publicly available). Permissioned blockchains such as Hyperledger Fabric (HLF) [5]
allow developers to restrict access to the shared ledger to known participants. HLF does not
require a replay of transactions on all nodes. Instead, the execute order validate approach is
used where the participants who have to endorse (execute and validate) transactions can be
defined via so-called endorsement policies. Furthermore, such systems may allow the usage
of sub-blockchains (channels in HLF). A channel is a logically separate blockchain that is
only shared between a subset of participants of the main chain. Since transactions are bound
to a specific chain, cross-channel transactions are not supported. In addition, HLF supports
so-called private data collections. Private data collections are a type of off-chain storage that
is governed by the blockchain network. They have the additional benefit that data can be
used within blockchain transactions. However, off-chain storage has a major implication: The
data itself is not stored on the blockchain. This can negatively impact blockchain properties
such as immutability, observability, and persistency. It should be noted that depending on
given requirements, data privacy can be achieved in various ways. This includes the usage of
off-chain data, data encryption, or storing only the digest of data on-chain. However, we argue
that for many applications on-chain data storage is beneficial. An example is the need for a full,
immutable trace of the evolution of data items for fulfilling data provenance requirements.
This paper is framed by the model-driven engineering of inter-organizational processes on
blockchains. In particular, we assume that the required levels of privacy and enforceability are
explicitly represented in process models. We then analyze, how different degrees of privacy can
be implemented via channels and we will discuss the consequences for the blockchain based
verification of data-based decisions. In particular, we aim in addressing the following research
questions: RQ1: How do different levels of privacy requirements of data objects influence the
possible placement of data in channels? RQ2: Which kinds of blockchain transactions are
required to enforce the correctness of data-based decisions over data with privacy requirements?
RQ3: How can the resulting transactions be implemented on HLF?
The remainder of the paper is organized as follows. In Sect. 2 we discuss related work.
Sect.3 provides the preliminaries for the paper by defining the process meta-model. In Sect.
4 we analyze how channels can be used to support privacy requirements (RQ1). Sect. 5
shows what kinds of transactions are required for enforcing the correctness of decisions over
data and introduces a classification of cross-channel transactions (RQ2). Sect. 6 presents an
implementation on HLF, supporting privacy requirements via channels and enforceability
requirements via distributed oracles (RQ3). Finally, Sect. 7 concludes the paper.
2. Related Work
Recently, numerous approaches explored the model-driven development of blockchain-based
applications and the execution business processes on blockchains (see [2, 1] for recent surveys).
The works on BPM on blockchains range from choreography monitoring [6] and enforcement
[7, 8] over on-chain business process engines such as [9] to the collaborative management of
models on blockchains [10]. While the execution of business processes on blockchain peers very
well with the objectives of enforceability and observability of smart contracts, privity/privacy
is not natively solved. The work in [11] gives an overview of the aspects of confidentiality
in business processes on blockchain, and discuss existing techniques to (partially) address
this aspect. Notably, most of the existing approaches focus on public blockchain systems and
ignore constraints on privacy or generally assume that all non-control-data is off-chain. Some
approaches such as [12, 8] apply encryption on public blockchains. A typical pattern for the
execution of business processes on blockchains is the translation of process models to smart
contract code. Consequently, a process is executed by calling blockchain transactions. This
approach can enforce the correctness of the control-flow. However, enforcing the correctness of
decisions within a process is challenging, if input data is stored off-chain or is encrypted since
blockchain transactions have no access to the data. In order to access off-chain data or encrypted
on-chain data oracles [13] are required. Oracles come with the risk of introducing central
entities. This problem can be reduced by using distributed oracles [14] instead. Additionally,
non-interactive Zero Knowledge Proofs [15] allow to proof the correctness of a transaction
without revealing private input data on-chain. Notably, [8] also covers implementations on
HLF, where different choreography instances are separated by channels and message data is
transferred privately via private data collections. However, to the best of our knowledge, no
existing approach analyzes the model-driven development of blockchains applications where
privacy requirements of business processes data are realized via channels in detail.
3. Process Meta Model
For our analysis, we model blockchain based business processes in form of block-structured
inter-organizational business process models [16, 17]. We repeat the essential definitions here.
While such models do not provide the full expressiveness of BPMN, they have a clear semantics
and allow us to focus on the core problems. In the remainder of the paper we use the usual
object-style dot notation to access components. E.g. for a tuple 𝑡 = (𝑎, 𝑏), we write 𝑡.𝑎 for
accessing 𝑡𝑎 .
Definition 3.1 (Process Model). A business process model is a tuple 𝑃 = (𝑁, 𝐸, 𝐷, 𝐴) with a
set of nodes 𝑁 , a set of data objects 𝐷 and a set of participants 𝐴. Nodes are connected by a
set of directed edges 𝐸 forming a directed acyclic graph. For each node 𝑛 we define 𝑛.𝑡𝑦𝑝𝑒 ∈
{𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑦, 𝑥𝑜𝑟-𝑠𝑝𝑙𝑖𝑡, 𝑥𝑜𝑟-𝑗𝑜𝑖𝑛, 𝑎𝑛𝑑-𝑠𝑝𝑙𝑖𝑡, 𝑎𝑛𝑑-𝑗𝑜𝑖𝑛, 𝑏𝑢𝑠𝑖𝑛𝑒𝑠𝑠-𝑟𝑢𝑙𝑒-𝑡𝑎𝑠𝑘} to declare the node
type. 𝑛.𝑛𝑎𝑚𝑒 is the label of the node, 𝑛.𝑑𝑟 ⊆ 𝑃.𝐷, the set of data objects read and 𝑛.𝑑𝑤 ⊆ 𝑃.𝐷,
the set of data objects written, and 𝑛.𝑎 ∈ 𝑃.𝐴, the actor executing the node.
Each edge (𝑚, 𝑛) ∈ 𝑃.𝐸 describes a precedence constraint between nodes 𝑚 ∈ 𝑃.𝑁 and
node 𝑛 ∈ 𝑃.𝑁 . There is one node without predecessor, called start node and one node without
successor called stop node. Nodes of type 𝑥𝑜𝑟-𝑠𝑝𝑙𝑖𝑡 and 𝑎𝑛𝑑-𝑠𝑝𝑙𝑖𝑡 have exactly 2 successors,
nodes of type 𝑥𝑜𝑟-𝑗𝑜𝑖𝑛 and 𝑎𝑛𝑑-𝑗𝑜𝑖𝑛 have exactly 2 predecessors. 𝐷𝑉 ⊂ 𝑃.𝐷 is a set of
Boolean decision variables. Each 𝑥𝑜𝑟- split node 𝑥 is located immediately after a node of
type 𝑏𝑢𝑠𝑖𝑛𝑒𝑠𝑠-𝑟𝑢𝑙𝑒-𝑡𝑎𝑠𝑘. The business rule task 𝑏𝑟 for 𝑥 may read data objects and writes to
a unique decision variable 𝑑𝑣 (𝑏𝑟.𝑑𝑤 = {𝑑𝑣}), which is also assigned to the 𝑥𝑜𝑟-𝑠𝑝𝑙𝑖𝑡 node
(𝑥.𝑑𝑟 = {𝑑𝑣}). One of the outgoing edges of 𝑥 is adorned with 𝑑𝑣, the other with ¬𝑑𝑣, indicating
which path is chosen at runtime. This decision variable of a 𝑥𝑜𝑟-𝑏𝑙𝑜𝑐𝑘 is not modified by any
other node except the corresponding business rule task.
The process model is block structured. Therefore, each split node is associated with exactly
one join node such that each path originating in the split node to the end node includes the
associated join node.
During the execution of a process instance, business rule tasks assign values to their decision
variables. These values result in either following the 𝑡𝑟𝑢𝑒 or 𝑓 𝑎𝑙𝑠𝑒 branch of the corresponding
gateway. An instance type of a process 𝑃 𝐼 is determined by an instantiation of decision variables
𝐼 = {(𝑑1 , 𝑣1 ), ..., (𝑑𝑛 , 𝑣𝑛 )}, where 𝑑 ∈ 𝐷 and v is a Boolean value. 𝑃 𝐼 is a sub-graph of 𝑃
where each 𝑥𝑜𝑟-𝑠𝑝𝑙𝑖𝑡 node has exactly one successor, the one that matches the value of the
corresponding decision variable in 𝐼. We define 𝑃 𝐼(𝑃 ) as the set of all possible instantiations
of decision variables.
The origin for a data object 𝑑 of a node 𝑛 in an instance type 𝑃 𝐼 , denoted 𝑜(𝑃 𝐼 , 𝑛, 𝑑), is
defined as a node 𝑚 such that there exists a path 𝑝 in 𝑃 𝐼 starting at 𝑚 and ending at 𝑛 and
there is no step 𝑚′ writing to 𝑑 between 𝑚 and 𝑛 in 𝑃 𝐼 . A process model 𝑃 = (𝑁, 𝐸, 𝐷, 𝐴) is
correct, iff for every instantiation 𝐼 ∈ 𝑃 𝐼(𝑃 ) of decision variables, for each input data object
𝑥 ∈ 𝐷 of each activity or business rule task 𝑛 ∈ 𝑁 : 𝑜(𝑃 𝐼 , 𝑛, 𝑥) exists and is unique. The
correctness criteria ensures that the process model is free of race-conditions of data objects.
3.1. Example Process
We present an example process first introduced in [17] in Fig. 1. It shows a collaboration between
a researcher 𝑅, a host organization 𝐻𝑂, a funding agency 𝐹 𝐴, a specialist 𝑆𝑃 , an international
reviewing agency 𝐴, and a national reviewing agency 𝐵. First, in 𝑇 1𝑅 the researcher applies
for a grant. This task stores the research proposal in data object 𝐷1. Then 𝐷1 is processed
and updated by the host organization in 𝑇 2𝐻𝑂 . Next, the funding agency decides based on the
provided data if the application is rejected due to formal reasons by setting the Boolean variable
𝑑𝑒𝑠𝑘𝑟𝑒𝑗𝑒𝑐𝑡. In case of a rejection, a rejection letter is created in 𝑇 7𝐹 𝐴 . If the application is not
rejected, an international 𝐴 or national reviewing agency 𝐵 is selected by setting 𝑖𝑛𝑡𝑟𝑒𝑣𝑖𝑒𝑤 by
a topic expert 𝑆𝑃 in 𝑇 4𝑆𝑃 . During review, a review document 𝐷2 is either created by 𝑇 5𝐴 or
𝑇 6𝐵 . The final decision is taken by the funding agency in 𝑇 8𝐹 𝐴 based on 𝐷1 and 𝐷2. Finally,
either an acceptance or rejection letter is created in 𝑇 7𝐹 𝐴 , 𝑇 9𝐹 𝐴 or 𝑇 10𝐹 𝐴 .
3.2. Privity Spheres
Privity spheres were introduced in [12] and formalized in [17]. They allow to define which set
of participants may gain access to which data object during process execution. We base our
discussion on channels on privity spheres and therefore repeat the essential definitions of [17]
T1R T2 HO T3 FA
Apply for Endorse Decide on
Grant Proposal Desk Reject
D1
Application T5A T9 FA
International Write Accept.
intreview
Review Letter
granted
T4SP
Assign
Review Type
!deskreject Review D2 T8FA
Take
!intreview Decision
deskrecject
T6B !granted
National
Review
T10FA
Write
T7FA Reject. Letter
Write Desk
Reject Letter
Figure 1: Example Collaboration between participants R, HO, FA, SP, A, B.
here. We annotate each data object 𝑑 with its minimal sphere requirements 𝑑.𝑠𝑝ℎ𝑒𝑟𝑒. The filler
of the 𝑑.𝑠𝑝ℎ𝑒𝑟𝑒𝑠 can be a value in {𝑝𝑟𝑖𝑣𝑎𝑡𝑒, 𝑠𝑡𝑎𝑡𝑖𝑐, 𝑤𝑒𝑎𝑘-𝑑𝑦𝑛𝑎𝑚𝑖𝑐, 𝑠𝑡𝑟𝑜𝑛𝑔-𝑑𝑦𝑛𝑎𝑚𝑖𝑐}.
Definition 3.2 (Private Sphere). Let P be a process model. A participant is in the private sphere
if she is an actor of the process: PrivateSphere(P) = P.A
Definition 3.3 (Static Sphere). A participant 𝑎 of a process is a member of the static sphere of
some data object 𝑑 if 𝑎 is an actor of any task accessing 𝑑 in 𝑃 . 𝑆𝑡𝑎𝑡𝑖𝑐𝑆𝑝ℎ𝑒𝑟𝑒(𝑃, 𝑑) = {𝑎|𝑎 ∈
𝑃.𝐴 : 𝑛 ∈ 𝑃.𝑁 ∧ 𝑛.𝑎 = 𝑎 ∧ (𝑑 ∈ 𝑛.𝑑𝑤 ∨ 𝑑 ∈ 𝑛.𝑑𝑟 )}
In the example process in Fig. 1, the static sphere for 𝐷1 is {𝑅, 𝐻𝑂, 𝐹 𝐴, 𝑆𝑃, 𝐴, 𝐵} since all
particiapnts execute at least one activity reading D1. The static sphere for 𝐷2 is {𝐴, 𝐵, 𝐹 𝐴}.
Definition 3.4 (Weak-Dynamic Sphere). Let 𝑑 ∈ 𝑃.𝐷 be a data object, 𝑤 be a task writing to 𝑑.
An actor 𝑎 is in the weak-dynamic sphere of 𝑑 for 𝑤, iff 𝑎 is the actor of 𝑤 or 𝑎 is an actor of
some task reading 𝑑 where 𝑤 is a possible origin for 𝑑:
𝑊 𝑒𝑎𝑘𝐷𝑦𝑛𝑎𝑚𝑖𝑐𝑆𝑝ℎ𝑒𝑟𝑒(𝑃, 𝑑, 𝑤) = {𝑤.𝑎} ∪ {𝑎|𝑎 ∈ 𝑃.𝐴 : 𝑛 ∈ 𝑃.𝑁 ∧ 𝑛.𝑎 = 𝑎 ∧ 𝑑 ∈
𝑛.𝑑𝑟 ∧ ∃𝐼 ∈ 𝑃 𝐼(𝑃 ) : 𝑜(𝑃 𝐼 , 𝑛, 𝑑) = 𝑤}
In the example process in Fig. 1, the weak-dynamic sphere for 𝐷1 for the writer 𝑇 1𝑅 is
{𝑅, 𝐻𝑂} since only the 𝐻𝑂 can read the version written by 𝑅.
While the weak-dynamic sphere of a writer contains all participants, that can execute some
task reading the written data value, the strong-dynamic sphere requires, that participants must
certainly execute some tasks reading the data value.
Definition 3.5 (Strong-Dynamic Sphere). Let 𝑑 ∈ 𝑃.𝐷 be a data object, 𝑤 be a task writing to
𝑑, 𝑟 be a node. An actor 𝑎 is in the strong-dynamic sphere of 𝑤 for 𝑑 at node 𝑟, iff for every
instance type where 𝑤 is the origin of 𝑟 for 𝑑, 𝑎 will execute some node reading the value of 𝑑
from 𝑤 or 𝑎 is the actor of 𝑤.
𝑆𝑡𝑟𝑜𝑛𝑔𝐷𝑦𝑛𝑎𝑚𝑖𝑐𝑆𝑝ℎ𝑒𝑟𝑒(𝑑, 𝑤, 𝑟) = {𝑎|𝑎 ∈ 𝑃.𝐴 : ∃𝐼 ∈ 𝑃 𝐼(𝑃 ) : 𝑜(𝑃 𝐼 , 𝑟, 𝑑) = 𝑤 ∧ ∀𝐼 ∈
{𝐼|𝐼 ∈ 𝑃 𝐼(𝑃 ) : 𝑜(𝑃 𝐼 , 𝑟, 𝑑) = 𝑤}∃𝑛 ∈ 𝑃 𝐼 .𝑁 : (𝑑 ∈ 𝑛.𝑑𝑟 ∧ 𝑛.𝑎 = 𝑎 ∧ 𝑜(𝑃 𝐼 , 𝑛, 𝑑) = 𝑤) ∨ 𝑎 =
𝑤.𝑎}
In the example process in Fig. 1, the strong-dynamic sphere for 𝐷1 for the writer 𝑇 1𝑅 is
{𝑅, 𝐻𝑂}. This equals the weak-dynamic sphere. However, the strong-dynamic sphere for the
writer 𝑇 2𝐻𝑂 is {𝐻𝑂, 𝐹 𝐴}. It does not contain 𝐴 and 𝐵 since it is not yet known if 𝑇 5𝐴 or
𝑇 6𝐵 will be executed. However, the strong-dynamic sphere for 𝑇 2𝐻𝑂 for 𝐷1 at position 𝑇 5𝐴
is {𝐻𝑂, 𝐹 𝐴, 𝑆𝑃, 𝐴} since at this point it is known that 𝐴 and 𝑆𝑃 will need the value of 𝐷1.
3.3. Modeling Enforceability Requirements of Decisions
Enforceability is an objective of smart contacts aiming to make a breach of the contract infeasible.
However, the required degree of enforcement of the correctness of some decision may differ
from decision to decision. While a decision whether an order is accepted may be taken solely by
the buyer, a decision if the buyer has sufficient funds should be secured by the entire blockchain
network. We assume that each business rule task 𝑑𝑟 of a process model has the additional
property 𝑑𝑟.𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑟𝑠. It holds a set of participants who have to verify the decision. This is
well-aligned with endorsement policies of permissioned blockchains such as HLF. By definition,
each verifier in 𝑑𝑟.𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑟𝑠 is a reader of all input data objects of the business rule task and
therefore has access to them. Therefore, each verifier is in the strong-dynamic-sphere of all
input data objects at the position of the business rule task.
4. Realizing Privacy Requirements via Channels
Since a channel is itself a sub blockchain, it is advisable to reuse channels for multiple instances
of a collaboration between the same participants and not to create new channels for every new
instance of a process. Otherwise, the channels are likely single block blockchains, questioning
the basic principles of blockchains.
We now extend the process model from Def. 3.1 with channels: We define a channel as a
tuple 𝑐 = (𝑖𝑑, 𝑡, 𝑀 ), where 𝑖𝑑 is a unique identifier and 𝑡 can be 𝑝𝑟𝑖𝑣𝑎𝑡𝑒 or 𝑚𝑎𝑖𝑛 to indicate if
𝑐 is a private channel or if it represents the main chain, 𝑀 is a set of members representing
the members of the channel (𝑀 ⊂ 𝑃.𝐴). We extend the definition of a process model from
Definition 3.1 with an additional property 𝐶 resulting in 𝑃 = (𝑁, 𝐸, 𝐷, 𝐴, 𝐶). 𝑃.𝐶 is a set of
channel definitions.
4.1. Example
We will now discuss how the different privacy requirements of data objects can be implemented
using channels based on the example in Fig. 1. The resulting channels are shown in Figure 2.
If data objects 𝐷1 and 𝐷2 both require the 𝑝𝑟𝑖𝑣𝑎𝑡𝑒 sphere, all data and the control flow state
can be stored on the main chain. For the 𝑠𝑡𝑎𝑡𝑖𝑐 sphere, every participant of the process owns
at least one activity accessing 𝐷1. It can therefore be stored on the main chain. 𝐷2 is only
accessed by 𝐴, 𝐵, 𝐹 𝐴. Therefore, 𝐷2 must be stored on a separate channel 𝑐2 with members
𝑐2.𝑀 = {𝐴, 𝐵, 𝐹 𝐴}. In the case of the 𝑤𝑒𝑎𝑘-𝑑𝑦𝑛𝑎𝑚𝑖𝑐 sphere, the value of 𝐷1 written by 𝑇 1𝑅
must only be available to 𝑇 2𝐻𝑂 . It is written to the private channel 𝑐1 with 𝑐1.𝑀 = {𝑅, 𝐻𝑂}.
The value of 𝐷1 written by 𝑇 2𝐻𝑂 must be available for all potential readers (𝐹 𝐴, 𝑆𝑃 , 𝐴,
𝐵). Therefore, it is written to a channel 𝑐2 with 𝑐2.𝑀 = {𝐻𝑂, 𝐹 𝐴, 𝑆𝑃, 𝐴, 𝐵}. For 𝐷2 we
have one channel 𝑐3 shared between 𝐴 and 𝐹 𝐴 which is used by 𝑇 5𝐴 , if it is executed and
a 𝑐4 with 𝑐4.𝑀 = {𝐵, 𝐹 𝐴} used by 𝑇 6𝐵 if it is executed. The 𝑠𝑡𝑟𝑜𝑛𝑔-𝑑𝑦𝑛𝑎𝑚𝑖𝑐 sphere is
most challenging to realize via channels. As for the weak-dynamic case, 𝑅 can store 𝐷1 on
a channel for 𝑅, and 𝐻𝑂 since 𝑇 2𝐻𝑂 will always be executed. This differs for 𝑇 2𝐻𝑂 since
only 𝑇 3𝐹 𝐴 is certainly executed. Writing to a channel containing 𝑆𝑃 is only possible when the
decision variable 𝑑𝑟𝑒𝑗𝑒𝑐𝑡 evaluates to 𝑓 𝑎𝑙𝑠𝑒 in the continuation of the process. Consequently,
we need 4 distinct channels to make the value of 𝐷1 written by 𝑇 2𝐻𝑂 available to the other
participants: 𝐶1 for 𝐻𝑂, 𝐹 𝐴, unconditional. 𝐶2 for 𝐻𝑂, 𝑆𝑃 if 𝑑𝑟𝑒𝑗𝑒𝑐𝑡 = 𝑓 𝑎𝑙𝑠𝑒. 𝐶3 for
𝐻𝑂, 𝐴 if 𝑑𝑟𝑒𝑗𝑒𝑐𝑡 = 𝑓 𝑎𝑙𝑠𝑒 and 𝑖𝑛𝑡𝑟𝑒𝑣𝑖𝑒𝑤 = 𝑡𝑟𝑢𝑒. 𝐶4 for 𝐻𝑂, 𝐴 if 𝑑𝑟𝑒𝑗𝑒𝑐𝑡 = 𝑓 𝑎𝑙𝑠𝑒 and
𝑖𝑛𝑡𝑟𝑒𝑣𝑖𝑒𝑤 = 𝑓 𝑎𝑙𝑠𝑒. None of the channels contains all participants. Therefore, no data object
can be stored on the main chain.
It should be noted that we cannot use one channel containing {𝐹 𝑂, 𝐹 𝐴, 𝑆𝑃, 𝐴} and another
one for {𝐹 𝑂, 𝐹 𝐴, 𝑆𝑃, 𝐵} to store 𝐷1 in 𝑇 2𝐻𝑂 in the strong-dynamic case. At the time when
𝑇 2𝐻𝑂 is executed it is not known if the application will be rejected by 𝑇 3𝐹 𝐴 and which
reviewing agency will be selected in 𝑇 4𝑆𝑃 . If we would only execute one process instance, and
our target blockchain system supports the dynamic change of participants we could dynamically
add participants to a single channel. In our scenario, where we aim in reusing channels for all
process instances between the same participants, this is not possible.
4.2. Characterization of Implementations via Channels
We will now characterize the properties of possible implementations of privacy requirements via
channels. For any implementation we can assume that it must be possible to know at any step in
a process instantiation, from which channel a particular data object must be read by a particular
actor. Based on our correctness criteria in Sect. 3, we know that the origin to read the data from
is unique in every run of the process. Therefore, we can assume the existence of a function
𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(𝑟, 𝑑, 𝑎, 𝐼*𝑟 ), that returns the channel, from which the participant 𝑎 must read
data object 𝑑 at step 𝑟 with the partial instantiation of decision variables 𝐼*𝑟 . 𝐼*𝑟 is defined as
a subset of an instantiation 𝐼 containing values for each decision variable of xor-split nodes on
the path from start-node to 𝑟. We will now characterize the output of 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(𝑟, 𝑑, 𝑎, 𝐼*𝑟 )
based on the privity spheres of 𝑑.
Proposition 4.1 (Placement Private). Let 𝑑 ∈ 𝑃.𝐷 with 𝑑.𝑠𝑝ℎ𝑒𝑟𝑒 = 𝑝𝑟𝑖𝑣𝑎𝑡𝑒. Every participant
𝑎 ∈ 𝑃.𝐴 can always read 𝑑 from the main chain:
{(𝑖𝑑, ‘𝑚𝑎𝑖𝑛‘, 𝑃.𝐴)} = {𝑐|𝑐 ∈ 𝑃.𝐶 : 𝑐 = 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(_, 𝑑, _, _)}.
Public and Private Sphere Static Sphere
C1.M={A,B,FA}
Main D1 D2 CF Main CF D1 C1 D2
Weak-Dynamic Sphere T1R C1.M={R,HO}
T2HO
Main CF C1 D1 C2 D1
T5A C3.M={A,FA} T6B C4.M={B,FA}
C2.M={HO,FA,SP,A,B}
C3 D2 C4 D2
Strong-Dynamic Sphere - only T2HO T2HO, unconditional T2HO, if deskreject=false
C1.M={HO,FA}, C2.M={HO,SP}
Main CF D1
C1 D1 C2
T2
T2HO, if dreject=false and intreview=true T2HO, if dreject=false and intreview=false
C3.M={HO,A} C4.M={HO,B}
C3 D1 C4 D1
T2 T2
Figure 2: Channel configuration for Example Process in Fig 1
Proposition 4.2 (Placement Static). Every participant accessing 𝑑 can always read 𝑑 from
the same channel: {(𝑖𝑑, 𝑡𝑦𝑝𝑒, 𝑚𝑒𝑚𝑏𝑒𝑟)} = {𝑐|𝑐 ∈ 𝑃.𝐶 : 𝑐 = 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(_, 𝑑, _, _)}, where
𝑚𝑒𝑚𝑏𝑒𝑟 = {𝑎|𝑎 ∈ 𝑃.𝐴 : ∃𝑡 ∈ 𝑃.𝑁 ∧ 𝑡.𝑎 = 𝑎 ∧ 𝑑 ∈ 𝑡.𝑑𝑟 ∪ 𝑡.𝑑𝑤 } and if 𝑚𝑒𝑚𝑏𝑒𝑟 = 𝑃.𝐴, then
𝑡𝑦𝑝𝑒 = ‘𝑝𝑢𝑏𝑙𝑖𝑐‘ otherwise 𝑡𝑦𝑝𝑒 = ‘𝑝𝑟𝑖𝑣𝑎𝑡𝑒‘.
Proposition 4.3 (Placement Weak-Dynamic:). Let 𝑤1 and 𝑤2 be tasks writing to 𝑑. Tasks 𝑤1
and 𝑤2 must store 𝑑 on different channels, if there are different sets of participants potentially
reading 𝑑 from 𝑤1 and from 𝑤2. Due to conditional writes, also the channel, where 𝑑 resides for
a reading node 𝑟 depends on the execution history of the process instance. Let 𝑎 and 𝑏 be actors
in 𝑃.𝐴. For the weak dynamic case, 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(𝑟, 𝑑, 𝑎, 𝑃 𝐼*𝑟 ) = 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(𝑟, 𝑑, 𝑏, 𝑃 𝐼*𝑟 )
holds. E.g., the channel of 𝑑 at step 𝑟 only depends on 𝑃 𝐼*𝑟 .
Proposition 4.4 (Placement Strong-Dynamic:). Due to conditional readers and only partially
known decision outcomes during instance execution, a task 𝑤 writing to some variable 𝑑 may
need to write it to multiple channels. Consequently, different participants may read the same
value of 𝑑 from different channels. Let 𝑎 and 𝑏 be actors. In contrast to the weak-dynamic case
𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(𝑟, 𝑑, 𝑎, 𝑃 𝐼*𝑟 ) = 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙(𝑟, 𝑑, 𝑏, 𝑃 𝐼*𝑟 ) is only guaranteed if 𝑎 = 𝑏.
Prrof-Sketch 4.1 (of Prop. 4.1 - 4.4). The proofs directly follow from the definitions of the
corresponding spheres in Def. 3.2 - 3.5.
5. Enforcing Correct Decisions via Transactions
After we have discussed how requirements on privacy expressed in form of privity spheres
influence the location of data in channels, we now discuss the consequences for the enforcement
of data-based decisions. In order to take full advantage of the underlying blockchain system, a
data-based decision should be realized by a single blockchain transaction. Therefore, it must be
possible by the blockchain system to verify the correctness of the transaction. In the case of
permissioned blockchains and in particular, on HLF, the transaction is replayed on the endorsing
peers (e.g., for a business rule task 𝑑 they are members of 𝑑.𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑟𝑠). We base our discussion
on the following assumptions: Like for many existing approaches for business processes on
blockchains [9], we assume that process models are compiled into smart contract code. The
smart contract code governing the control flow is deployed on the main chain. Business rule
tasks of xor-split node are executed on-chain and publish their output on the main chain. This
allows all participants to access all control-flow decisions to synchronize their processes.
5.1. Transaction Patterns
We now present patterns of the decision transactions for a business rule task 𝑐 with a set of
verifiers 𝑐.𝑣𝑒𝑟𝑖𝑓 𝑖𝑒𝑟𝑠 reading data objects 𝐷1 and 𝐷2 and executing some arbitrary decision
expression 𝑒𝑥𝑝 and producing some Boolean output 𝑜𝑢𝑡.
Private In the private case we have one transaction where all input data and the out-
put data are on the main chain (see Prop. 4.1).
r e a d D1 , D2 from main c h a i n
o u t = exp ( D1 , D2 )
p u b l i s h o u t on main c h a i n
Static In general, we cannot assume that 𝐷1 or 𝐷2 are located on the main chain. However,
for every instantiation of the decision transaction, the data will be read from the same channels
(see Prop.4.2). This leads to the following transaction with hard-coded channels:
r e a d D1 from c h a n n e l 1
r e a d D2 from c h a n n e l 2
o u t = exp ( D1 , D2 )
p u b l i s h o u t on main c h a i n
Weak-Dynamic In contrast to the static case, the channels where 𝐷1 and 𝐷2 reside depend on
the already taken decisions of the process 𝐼*𝑟 (see Prop. 4.3) leading to the following transaction:
r e a d D1 from g e t C h a n n e l ( c , D1 , _ , I ∗ c )
r e a d D2 from g e t C h a n n e l ( c , D2 , _ , I ∗ c )
o u t = exp ( D1 , D2 )
p u b l i s h o u t on main c h a i n
Strong-Dynamic In contrast to the weak-dynamic case, the location of data objects now
additionally depends on the participant (see Prop. 4.4). Consequently different participants
might read the data from different channels. This leads to the following transaction pattern for
a participant p1:
r e a d D1 from g e t C h a n n e l ( c , D1 , p1 , I ∗ c )
r e a d D2 from g e t C h a n n e l ( c , D2 , p1 , I ∗ c )
o u t = exp ( D1 , D2 )
p u b l i s h o u t on main c h a i n
It should be noted that each verifier and the actor of the business rule task may need to
perform a different transaction since they potentially need to read the data objects from another
channel.
5.2. Classification of Cross-Channel Transactions
Based on the previously described transactions for executing decisions, we introduce a classifi-
cation of the required cross-channel transactions.
1. None All input and output data resides on the main chain, or the input is transaction
input. Transaction output is also placed on the main chain.
2. Simple Input data is statically placed on one or more channels, and output data is written
to the main chain.
3. Complex Input data is placed on one or more channels. In contrast to the static case, the
channels where the data resides depend on the history of the process instance. Output
data is statically written to the main chain.
4. Dynamically Complex Input data is placed on one or more channels; the channels where
the data must be read from depends on the history of the process instance and additionally
on the participant. Consequently, the participant executing the transaction and each
verifier may need to read the input data from different channels.
To the best of our knowledge, no permissioned blockchain system currently supports cross-
channel transactions. Therefore, only type 𝑛𝑜𝑛𝑒 is directly supported by current blockchain
platforms. Even 𝑠𝑖𝑚𝑝𝑙𝑒 cross-channel transactions are not supported as on-chain transactions.
Therefore, we see the proposed classification as a benchmark for future blockchain platforms.
6. Implementation via Distributed Oracles
We have implemented a prototype1 for the blockchain-based execution of business processes
with privacy and enforceability requirements on HLF. For complying with privacy requirements,
data is stored on separate channels. We assume that each participant operates its own blockchain
node. The state of the control-flow of each process instance is stored on the main chain in
form of a petri-net configuration. Therefore, control-flow transactions result in updates of the
petri-net configuration. Process models are preprocessed in order to derive the 𝑔𝑒𝑡𝐶ℎ𝑎𝑛𝑛𝑒𝑙()
function from Sect. 4.2. Channels are reused between different process instances with the same
assignments of participants to blockchain identities. In HLF, it is not possible to implement a sin-
gle state-changing transaction reading data from different channels (cross channel transaction).
However, since each decider and verifier has access to all required data, it is possible to validate
1
Available online: https://github.com/adnanb97/DistributedOracleHLF. Implementation details are presented in [18]
decisions using oracles. To avoid the introduction of a central entity, we have implemented
a distributed oracle. In our architecture, each peer executes a dedicated oracle service. Each
such oracle service is triggered by specific changes of the ledger. Whenever some decision
gets active, each oracle service of the verifying peers compute the decision locally and sends it
digitally signed via HTTP to the oracle service of the deciding peer. The deciding peer waits
until a configured quorum is reached and then issues one main chain transaction containing its
own result and all signed votes as payload. The chain code behind this transaction checks if all
signatures are correct and if the quorum was correctly reached. The correctness of this main
chain transaction is enforced with the native endorsements of HLF. It should be noted that an
(distributed) orcale is an off-chain component. As such the correctness of each member oracle
is not guaranteed by the blockchain itself. However, due to the distribution of the oracle an
attacker would need to attack multiple or even all participating oracle services depending on
the required quorum to change the decision outcome.
7. Conclusion
Data privacy is a challenging problem on blockchains. Therefore, data is typically stored off-
chain. However, this can have a negative impact on other requirements such as auditability,
and immutability. For a large set of applications, permissioned blockchains can support privacy
without threatening these properties for data storage. In this paper, we have analyzed how
permissioned blockchain systems with channels can guarantee different levels of data privacy
when data is stored on-chain (RQ1). Depending on the requirements, data must be stored stati-
cally or dynamically and potentially redundantly on different channels. We have then analyzed
what kind of transactions are required for enforcing the correctness of data-based decisions
when referenced data objects have privacy requirements (RQ2). Native implementations using
the built-in verification mechanisms of current permissioned blockchain systems with channels
are only possible with the lowest degree of privacy (private privity sphere). All other levels lead
to various kinds of cross-channel transactions. We have therefore introduced a classification of
the resulting cross-channel transactions which is intended to be used as a reference for future
permissioned blockchain platforms natively supporting cross-channel transactions. For the
time being, we have implemented a prototype for enforcing the correctness of decisions over
data on different channels via distributed oracles in HLF (RQ3). In this paper we have assumed
that all verifying participants are allowed to read all input data. Interesting future work is to
relax this assumption by using advanced cryptography such as Zero Knowledge Proofs[15] and
to develop algorithms for the optimal placement of data objects in channels.
References
[1] S. Curty, F. Härer, H. Fill, Blockchain application development using model-driven engi-
neering and low-code platforms: A survey, in: Processings of EMMSAD and BPMDS 2022,
volume 450 of LNBIP, Springer, 2022, pp. 205–220.
[2] F. Stiehle, I. Weber, Blockchain for business process enactment: A taxonomy and system-
atic literature review, in: Business Process Management: Blockchain, Robotic Process
Automation, and Central and Eastern Europe Forum, Springer International Publishing,
Cham, 2022, pp. 5–20.
[3] V. Buterin, Ethereum: A next-generation smart contract and decentralized application
platform, 2014. URL: https://ethereum.org/en/whitepaper/, accessed: 2021-10-28.
[4] N. Szabo, Formalizing and securing relationships on public networks., First Monday 9
(1997).
[5] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart,
C. Ferris, G. Laventman, Y. Manevich, et al., Hyperledger fabric: a distributed operating
system for permissioned blockchains, in: Proc. of EuroSys 2018, 2018, pp. 1–15.
[6] I. Weber, X. Xu, R. Riveret, G. Governatori, A. Ponomarev, J. Mendling, Untrusted business
process monitoring and execution using blockchain, in: Proc. of BPM 2016, 2016, pp.
329–347.
[7] F. Corradini, A. Marcelletti, A. Morichetta, A. Polini, B. Re, F. Tiezzi, Engineering trustable
and auditable choreography-based systems using blockchain, ACM Trans. Manage. Inf.
Syst. 13 (2022).
[8] F. Corradini, A. Marcelletti, A. Morichetta, A. Polini, B. Re, E. Scala, F. Tiezzi, Model-driven
engineering for multi-party business processes on multiple blockchains, Blockchain:
Research and Applications 2 (2021) 100018.
[9] O. Pintado, L. García-Bañuelos, M. Dumas, I. Weber, A. Ponomarev, Caterpillar: A business
process execution engine on the ethereum blockchain, Software: Practice and Experience
(2019).
[10] H. Fill, F. Härer, Storing and attesting conceptual models on blockchains (invited paper),
in: Comp. Proc. of Modellierung 2020, volume 2542, 2020, pp. 51–52.
[11] B. Carminati, E. Ferrari, C. Rondanini, Blockchain as a platform for secure inter-
organizational business processes, in: Proc. of CIC 2018, 2018, pp. 122–129.
[12] J. Köpke, M. Franceschetti, J. Eder, Balancing privity and enforceability of BPM-based
smart contracts on blockchains, in: Proc. of BPM Blockchain Forum 2019, volume 361 of
LNCS, Springer, 2019, pp. 87–102.
[13] R. Mühlberger, S. Bachhofner, E. Castelló Ferrer, C. Di Ciccio, I. Weber, M. Wöhrer, U. Zdun,
Foundational oracle patterns: Connecting blockchain to the off-chain world, in: Proc. of
BPM Blockchain and RPA Forum 2020, Springer, 2020, pp. 35–51.
[14] D. Basile, V. Goretti, C. D. Ciccio, S. Kirrane, Enhancing blockchain-based processes with
decentralized oracles, in: Business Process Management: Blockchain and RPA Forum -
BPM 2021, volume 428 of LNBI, Springer, 2021, pp. 102–118.
[15] O. Goldreich, Y. Oren, Definitions and properties of zero-knowledge proof systems, Journal
of Cryptology 7 (1994) 1–32.
[16] J. Köpke, M. Franceschetti, J. Eder, Optimizing data-flow implementations for inter-
organizational processes, DAPD (2018) 1–45.
[17] J. Köpke, M. Nečemer, Measuring the effects of confidants on privacy in smart contracts,
in: Business Process Management: Blockchain, Robotic Process Automation, and Central
and Eastern Europe Forum, Springer International Publishing, Cham, 2022, pp. 84–99.
[18] A. Brdanin, Implementing Enforceability Requirements of Business Processes Using Hy-
perledger Fabric, Master’s thesis, Alpen-Adria-Universität Klagenfurt, 2022.