Blockchain systems provide strong support for enforceability if all data relevant for transaction veriifcation is stored on-chain. An example is the efective 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-ofs 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 diferent levels of data privacy afect 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 diferent channels.
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 [
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 of-chain storage that is governed by the blockchain network. They have the additional benefit that data can be used within blockchain transactions. However, of-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 of-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 diferent 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 diferent 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 [
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, if 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]
D1 Application
T1R Apply for Grant T4SP
Assign
Review Type !deskreject deskrecject intreview !intreview
Review D2
T5A International
Review T6B National Review
T7FA Write Desk Reject Letter
T2HO Endorse Proposal
T3 FA Decide on
Desk Reject granted T8FA
Take Decision !granted
T9FA Write Accept.
Letter T10FA
Write Reject. Letter 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 , if 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 , if 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 difer 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 suficient 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 diferent 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 difers 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 .
Proposition 4.1 (Placement Private). Let ∈ . with .ℎ = . Every participant ∈ . can always read from the main chain: {(, ‘‘, .)} = {| ∈ . : = ℎ(_, , _, _)}.
Public and Private Sphere
C1
CF T1R
D1 C4 D1 C1.M={R,HO}
T6B D2
C1.M={HO,FA}, Main
C3
T5A C3.M={A,FA} D2
C1.M={A,B,FA} D2 T2HO
D1 C4.M={B,FA}
C2.M={HO,FA,SP,A,B}
T2HO, if deskreject=false
C2.M={HO,SP} C1
D1 D1 T2 T2HO, if dreject=false and intreview=true
C3.M={HO,A}
C4
D1 T2
C2 DT21 T2HO, if dreject=false and intreview=false
C4.M={HO,B} 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 diferent channels, if there are diferent 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, diferent participants may read the same value of from diferent 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 .
Private In the private case we have one transaction where all input data and the output 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 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 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: 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 diferent participants might read the data from diferent 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 diferent 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 diferent 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 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 diferent 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 diferent channels (cross channel transaction). However, since each decider and verifier has access to all required data, it is possible to validate 1Available 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 of-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 ofchain. 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 diferent 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 diferent 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 diferent 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. 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 interorganizational 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 of-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 interorganizational processes, DAPD (2018) 1–45. [17] J. Köpke, M. Nečemer, Measuring the efects 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 Hyperledger Fabric, Master’s thesis, Alpen-Adria-Universität Klagenfurt, 2022.