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 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 original 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.
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.
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 𝑡 𝑎 .
. 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.
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 𝐹 𝐴 .
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] here. We annotate each data object 𝑑 with its minimal sphere requirements 𝑑.𝑠𝑝ℎ𝑒𝑟𝑒. The filler of the 𝑑.𝑠𝑝ℎ𝑒𝑟𝑒𝑠 can be a value 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.
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.
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.
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.
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 𝑑. ). 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.
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.
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 𝑜𝑢𝑡.
In the private case we have one transaction where all input data and the output data are on the main chain (see Prop.
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. 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.
Based on the previously described transactions for executing decisions, we introduce a classification 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 crosschannel 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.
We have implemented a prototype 1 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 single 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 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.
Data privacy is a challenging problem on blockchains. Therefore, data is typically stored offchain. 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 statically 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.