Blockchain and smart contracts solutions can represent key enablers for implementing and enacting exible and secure business processes, particularly those crossing organizational boundaries (i.e. inter-organizational business processes). Even though organizations foresee enormous potential bene ts in using such solutions, the percentage of projects involving Blockchain and Distributed Ledger Technologies (DLT) that reach the operational stage is still quite low. Among the several reasons that are limiting this growth, there is the lack of well-founded and integrated approaches that are able to help organizations in mitigating the risks of the concrete adoption of DLT-based business processes. To ll this lack, the paper proposes a methodological approach for the dynamic assessment of interorganizational business processes in which virtual environments, combined with simulation and analytical techniques, are used to create, validate and subject to stress tests business processes relying on blockchain and smart contracts solutions. In application of the model continuity paradigm, the simulation models and the data-driven techniques used for analyzing the business process under de nition, represent the starting point for the design of an enactable business process as well as for implementing monitoring, corrective and evolutionary maintenance services related to its operation. In order to show the e ectiveness of the proposal, a case study concerning a biomass production chain is presented.
Blockchain technology has been gaining increasing popularity and, currently, is widely
considered as a breakthrough invention which could change many everyday activities and business
processes in di erent application domains, like supply chain, healthcare and nancial sectors[
In[
One of the major issues in the deployment of business processes through blockchain solutions is to assess the suitability of applying a blockchain-based infrastructure against the requirements of use cases and to clearly analyze and de ne its boundary. When, among the others, a requirement is the deployment of inter-organizational processes, there is also the issue of assuring monitoring and analysis of the process itself. To ll the lack of well-founded and integrated approaches that are able to help organizations in mitigating the risks of the concrete adoption of DLT-based business processes, the paper proposes a methodological approach for the dynamic assessment of inter-organizational business processes in which virtual environments, combined with simulation and analytical techniques, are used to create, validate and subject to stress tests business processes relying on blockchain and smart contracts solutions. The combination of simulation models with process mining techniques allow to perform both predictive and prescriptive analysis and to e ectively grasp the requirements of the system/infrastructure that has to deliver the process/service under analysis. In application of the model continuity paradigm, the simulation models and the data-driven techniques used for analyzing the business process under de nition, represent the starting point for the design of an enactable business process as well as for implementing monitoring, corrective and evolutionary maintenance services related to its operation. The rest of the paper is structured as follows: In Section 2 the proposed simulation-based and data-driven framework for enabling the analysis and design of business processes based on blockchain and smart contracts solutions is presented; in order to show the e ectiveness of the proposal, Section 3 reports a case study, which concerns a biomass production chain, developed in the context of the \Id-Service: Digital Identity and Service Accountability" project, funded by the Ministry of Economic Development (MISE); nally, conclusions are drawn and future work delineated.
The proposed methodological framework for enabling the analysis and design of business
processes based on blockchain and smart contracts solutions is depicted in Figure 1. The method
combines simulation-based and data-driven approaches and techniques with the aim to provide
a full- edged analysis of the business process under consideration that could bene t from the
exploitation of DLT-based solutions; in particular, four main phases can be identi ed:
Requirement Analysis and System Speci cation, in which the requirements of both the
business process and the underlying system are derived along with its high-level model
and the blockchain speci cations;
Simulation-based and Data-driven Modeling and Assessment, in which, by using
agentbased simulation and process mining techniques, a \Simulation Final Report" and a
\Conformance Checking Report" are produced. Moreover, a \Simulation Data Exchange
Model", a \Network Con guration" document, and a report concerning the analysis of
XES (eXtensible Event Stream)[
Financial Impact Analysis, in which a report concerning the nancial impact of the solution under evaluation is produced;
Design and Operation, in which the work products produced in the previous phases are re ned to produce the detailed design of the enactable business process as well as for implementing monitoring, corrective and evolutionary maintenance services related to its operation.
In the following, the above introduced phases and work-products are discussed more in
details, using as reference the main steps provided by the IEEE Recommended Practice for
Distributed Simulation Engineering and Execution Process (DSEEP)[
This rst work phase requires domain speci c analysis and requirements engineering techniques in order to assess the AS-IS situation for the process at hand.
Here the modelling e ort starts with identifying the main concepts that need to be represented and with mapping high-level and domain-speci c features of the application process; the technical details|the main components of the operational perspective|are taken into account in the con guration phase of the business process simulation.
Moreover, since that phase guides the process implementation, more precise speci cations
are required in the software layer and thus speci ed and formalized requirements should come
in the form of a standard BPMN document [
According to said formal bounds, a Blockchain Speci cation must also be produced in this phase: this document contains information about what kind of speci c blockchain platform and technology is best suited for the given eld of analysis. 2.2
Technology assessment, which can be described as the set of techniques, algorithms and methodologies used to assess complex processes and systems, is an element that, especially when combined with Financial assessment, positively a ects the Value proposition of a company.
The simulation-based and data-driven modeling and assessment phase of the proposed methodological framework encompasses a series of goals : Design and build a testbed blockchain infrastructure, according to the Blockchain Speci cation produced before. Then, implement data and Smart Contracts in accordance to an ad-hoc de ned Platform Indipendent Model (PIM ), called Process-Agnostic Smart Contract Speci cation. Finally, break down each step found in the Business Process Model as a series of chained informational exchanges among clearly identi ed actors, in order to power conformance checking based on process mining techniques.
The rst activity changes heavily according to what speci c blockchain platform has been chosen after the analysis conducted before. Implementation of a test network with an API layer varies a great deal from platform to platform, be it Corda, Hyperledger Fabric or Ethereum. It also encompasses technical, DevOps oriented details, de nitely not suited for an extensive and in detail discussion in this paper, other than recommending the use of container technology, given how widespread, mature and handy to deploy it has become.
The second activity deals with implementing a process agnostic smart contract to then
deploy on the test network, while the third readies an interpretation layer for logs extracted
using process mining techniques from said contract's event data, thanks to a mapping with the
XES-metamodel[
All the information produced during the last activity results in a Process Model document, useful later on in reconstructing process-relevant knowledge from mining results.
More details on the above mentioned activities and work products are reported in Section 3 with reference to the selected case study. 2.3
If the results of the previous phase were positive, i.e. we were able to nd a system con guration that ts the process requirements, then we move forward with the Financial Impact Analysis phase. Here our objective is to evaluate the nancial feasibility of the blockchain system con guration, from the point of view of the commissioning organization.
We conducted an in-depth study to determine how much hardware resources cost for building up a network. We compared listings of blockchain resources o ered by di erent cloud service providers to estimate the cost of a blockchain con guration. Let us consider a single node with 250 GB of storage, if we look at the listings of Microsoft Azure, for say, a tentative Ethereum like solution. We can conclude that a single node has a monthly cost of 195,786 EUR. The cost is equal to 0,00447 EUR per node * 43.800 minutes per month of usage. For Storage resources we have a monthly cost of 10,75 EUR per single node. The cost is equal to number of nodes * 250 GB * 0,043 EUR per GB.
Obviously, such expenses per node vary heavily based on the choices discussed in the Blockchain Speci cation document, as di erent technologies mandate di erent price structures due to power consumption requirements. A proof of work based blockchain, such as Ethereum, is going to require a lot more power to run, compared to other solutions, such as Corda. 2.4
The simulation models and the data-driven techniques used for analyzing the business process
under consideration can be reused to support its operation by enabling the implementation of
monitoring, corrective and evolutionary maintenance services. In particular, the (agent-based)
simulation model used during the assessment phase can be re ned and transformed into an
enactable process model running, as an example, on a BPMN-based environment (see [
This section discusses the case study that was considered for validating the methodology. The discussion is structured as a function of the methodology phases. 3.1
We identi ed a process that could bene t from its integration with a blockchain-based
technology. Speci cally, we chose to model a biomass production chain, which involves many di erent
organisations that cooperate to pursue a common goal, i.e. producing and delivering high
quality biomass. The process was chosen due to the existence of accountability and traceability
issues [
The accountability issue arises with inter-organisation interactions: while the identities of a group of employees are clearly de ned within an organisation, thus enabling accountability, the same does not necessarily hold outside an organisation. The main idea behind the case study was to address the above mentioned issues by integrating the process with a blockchainbased technology, combined with digital identities. See Section 3.2.2 for additional details on the implemented system. The result of such integration is a process in which actors that participate in inter-organisation interactions use an identity-based digital service to certify the operation(s) performed. The certi cation consists in writing an association between the actors' identity and operation-related documents on the blockchain so that a permanent record is created. The record will serve as a veri able and immutable trace of what has happened between two participants.
The domain process that was considered for the case study is brie y described below. The biomass production chain involves a lot of di erent actors which are the following: landowner, supplier, wood company, transformer operator, electricity company , competent bodies. Some of the mentioned actors may be represented by a single organisation, for example supplier, wood company and transformer operator may coincide.
The process can be described with three macro activities: Preliminary Activity, Building Site Activity and Delivery Activity. The above list shows a clear breakdown of activities, in order of execution. Below we brie y describe each of these activities, assuming that the supplier also acts as wood company and transformer operator. In the Preliminary Activity, the supplier sends a competent body an authorisation request for harvesting raw materials and stipulates a contract with one or more landowners. If everything goes well, the Building Site Activity may start. The supplier opens the building site wherein biomass is produced. At the end of the transformation and production activities, the supplier prepares the shipment. At this point, the last macro activity begins. One or more logistics operators take part in the process to deliver biomass produced by the supplier. The process ends when the biomass is delivered and sold to the electricity company.
The remainder of this section elaborates on the case study from the perspective of the two central macro phases of the proposed methodology. 3.2 3.2.1
The process model design is the starting point of the Simulation-based on Data-driven Modelling and Assessment phase, along with the blockchain operational model design. The product of this phase supports both the process mining analysis and the simulation-based modelling and assessment process.
We modelled the production chain in order to emphasise the entities (participants and actors) that participate in the process and the interactions that are relevant from the accountability and traceability perspective. The result of the modelling phase is depicted in Figure 2. The model captures the most important actors, participants, operations that need to be made accountable and states of the production process. Upon the successful execution of the operations the process moves from the current state to the next one. Process states are represented as rectangles with rounded angles, whereas the operations as arrows that connect two states. The actors are listed inside the rectangle at the bottom left of the gure. For the sake of clarity, we refer to organisations as actors and employees as participants. Each actor's name is written with a distinct colour and preceded by a label that is used to indicate the organisation a participant works for. Each operation has a description, reported inside a dashed rectangle, about the agents participating in the operation (note the preceding label), the operation's name and a few examples of operation-related data. Participants that are not directly involved in the process, like employees of a competent body, were not included in the representation. The model assumes that there are ve actors that participate in the process: Buyer, Supplier, Logistics operator, Landowner and Specialised company. The remaining organisations that were previously mentioned are not directly involved in the process, because they do not need the operations performed to be both traceable and accountable. The model assumes that Specialised company serves as both wood company and transformer operator. Keep in mind that upon the completion of an operation the participants use the certi cation service to certify the operation they've just performed in order to make the process move from the current state to the next one. The following description speci es the state triggered by each operation between parenthesis. The rst four states are part of the Preliminary Activity. The base scenario considered assumes that the specialised company rst has to ask for permission to harvest raw materials and then it can stipulate a contract with a landowner. The specialised company sends a competent body an authorisation request (Authorisation requested ). After receiving a positive response (Authorisation granted ), the company stipulates a contract with a landowner (Specialised company acquired biomass ). The Preliminary Activity ends with the specialised company selling the biomass to be produced to the supplier (Specialised company sold biomass ), whose purpose is to sell the biomass to the buyer. In the Building Site Activity the specialised company opens a building site (Building site opened ) wherein raw materials are transformed into biomass. Upon the end of the production of biomass one or more logistics operators are contacted for the shipment (Biomass shipment ). This is where the last macro activity begins. The logistics operator elaborates a delivery plan (Ready to deliver biomass ). Upon the delivery of the entire product (Biomass delivered ), a participant working for the supplier veri es if all expected biomass was received (Supplier received biomass ). Thereafter, the supplier sells the buyer the biomass received in the previous phase (Biomass sold to the buyer). The process concludes with the acquisition of biomass by the buyer (Biomass is transferred to the buyer and Buyer obtained biomass ). 3.2.2
For this case study, domain analysis pointed towards an Ethereum-like implementation with blockchain 3.0 elements, in order to integrate master nodes, aptly named Accountability Nodes (ANs).
ANs serve as service providers w.r.t. users, and deploy user signed writes onto the blockchain. We generated a Docker swarm based deployment suite, capable of instantiating a full test blockchain network in one go, complete with an implementation of our PIM smart contract, with other contracts designed to handle user login, and distributed public key management. 3.2.3
The platform independent speci cation gave clear guidance in the implementation e orts to be carried out, once a de nite technological choice had been made, according to domain-speci c criteria.
We used Solidity, the premier programming language for Ethereum Smart Contracts at the moment. The implementation created retains its property of being process agnostic. That means: regardless of the process' speci c eld of application, a smart contract modelled according to the speci ed requirements, supports subsequent process mining e orts easily. The nite state machine is also a kind of behaviour that can easily be created using language speci c features, like invocation modi ers.
Code must, not only, support the PIM, but also respect the platform uniqueness. For example in Ethereum, each and every transaction or, speci cally, smart contract call, costs a certain amount of gas. Gas is a way to measure the resources needed to accomplish a certain computation on the distributed EVM-based network. The deployment itself of a smart contract also costs gas, and such price heavily depends on code size: keeping code short, concise and reusable is considered a de nite plus.
So, it is preferable to keep code as simple as possible, avoiding loops, redundant writes, and unnecessarily complicated data structures.
Also, it is very unwieldy to update smart contract code, while retaining all the information contained within. Standard techniques should be employed, such as the usage of speci c design patterns (Check-E ects-Interactions and CRUD ) and code must then be thoroughly tested.
It should be noted that we used a slightly modi ed version of the classical Check-E ectsInteractions pattern: we moved away from the require construct, using a simple if check, in order to emit an event logging the unexpected condition. 1 2 3 4 1 2 if ( log . isLogged ( _sender ) == false ){ emit TradeFailed ( _sender , _receiver , _valueTradedHash , msg . sender ); return false ; }
In order to correctly implement our PIM, we created a function for each edge connecting one state to another, exactly one event describing a correct execution for each function, and a certain number of other events emitted whenever execution encountered a particular error. Data was laid out in order to support the multi-FSM behaviour: the CRUD pattern was used in order to keep track of every new information exchange performed by actors. Structs and enums, instead, were put in place in order to contain relevant data, such as actors' UIDs, and timestamps. As an example, here's the signature for the O erTradeSigned function. function offerTradeSigned ( bytes32 _sender , bytes32 _receiver , bytes32 _valueHash , uint _tmout , uint8 sigV , bytes32 sigR , bytes32 sigS ) returns ( bool success ) public {} This function implements the very rst edge found in the PIM, with blockchain native signature checking. A correct execution of this particular function results in the emission of an instance of the following event. 1 2 event TradeOfferPlaced ( bytes32 indexed sender , bytes32 indexed receiver , bytes32 valueTradedHash , address indexed callingAn )
On the other hand, if the sender tries to re-enact an information exchange performed already in the past, execution stops, and this other event is emitted. 1 2 event ValueAlreadyTraded ( bytes32 indexed sender , bytes32 indexed valueTradedHash )
By applying the same principles for the other remaining functions, a fully functional implementation is obtained. 3.2.4
In order to validate the integration, we needed to create dynamic and complex scenarios that
could help us reproduce many di erent situations to deeply understand if the chosen
underlying blockchain technology provides satisfying responses. This requirement led us to choose the
agent-based simulation approach [
Agent-based simulation has proved to be a very powerful tool when it comes to manipulating the model. This type of model can be seen as an agent society which lives inside an environment where agents perform actions, interact with each other and respond to events according to their current state. By altering one or more of these elements (e.g. speci c interactions, the set of agents) it is possible to explore many di erent scenarios.
The process model presented previously helped us building the Conceptual Model and lay out the scenarios to simulate. Figure 2 refers to a base scenario that is characterised by a linear execution without cycles and/or alternate paths. However, such scenario serves as a starting point for laying out more complex what-if useful scenarios, two of which are shown in Figures 3 and 4, from the agent perspective. The scenarios are named Multiple stakeholder and Partial delivery, respectively. The agent-based representation decorates every operation (arrow) with a set of agents, which includes agents that either participate in the certi cation process or provide a service that contributes to completing the operation. For instance, let us consider the very rst operation in Partial delivery scenario. Claudia is responsible for sending a competent body an authorisation request. As can be seen in Figure 2, Claudia is presented as the only participant. There may be operations that need to be made accountable that involve only one participant. In this case, it would be risky to let only one participant use the certi cation service, because she could alter the content of operation-related documents for personal gain. In order to address this situation, the Conceptual Model ensures that the participant cannot use the service without engaging a manager from the same organisation. This constrain introduces new participants that act as witnesses. There are also agents that reproduce the behaviours of external participants that do not participate in the certi cation process. An example of these agents is Gennaro, an employee of a competent body.
The scenario shown in Figure 3 is characterised by the presence of two logistics operators and landowners. Increasing the number of actors has an impact on the number of operations to perform and, as a consequence, the number of participants required may rise. This type of scenario could be even more complex and could set up a basis for stress testing the infrastructure to evaluate if it can scale well up to the number of deployed agents. On the other hand, a scenario like the one shown in Figure 4 is interesting to explore rare, unusual or alternate situations to see how the process behaves from di erent perspectives. For instance, the Partial delivery scenario was designed to simulate a situation wherein the logistics operator is not able to dispatch the entire product. It would be interesting to see what is the impact of delivering only a partial amount of biomass that is equal to the total transport capacity provided by the operator. This scenario could lead the simulation team to lay out other what-if scenarios, where, for example, recovery procedures are explored.
The simulation environment derived from the Conceptual Model and other internal products was rst subject to testing to verify that the integrated member applications worked as intended and then was executed to evaluate the performance of the infrastructure with respect to a set of parameters of interest. The simulation execution and analysis were driven by the sets of dependent and independent variables described below, both from the point of view of a single AN, or the entire system as a whole: (i) Average Response Time, the average time taken by an AN or the entire infrastructure to ful l a transaction request from an end user; (ii) Throughput of number of requests per time unit ful lled by an AN, or by the entire infrastructure.
The evaluation was conducted based on the following two independent variables: (i) Number of ANs (ANw), the number of AN that can actually write transaction on behalf of an end user; (ii) Number of concurrent transaction requests (R).
The above-mentioned sets of variables were determined based on our needs; other behavioural aspects could be interesting for future analysis like system and blockchain usage. ANw takes values from the set S1 = (1; 2; 3), whereas R from S2 = (5; 10; 15; 20). The number of ANs was determined based on the number of available ANs on the network, while the number of concurrent transaction requests was based on available computational and memory resources. We tested the behaviour of the infrastructure by combining the values of ANw and R. In order to better understand how the evaluation was performed, it is important to note that there is a one-to-one relationship between transaction requests and smart contract execution, i.e. given a user transaction request, the infrastructure executes only one transaction (in other words only one atomic write operation). Moreover, a user request triggers a number of calls within the infrastructure, a few of which do not interact with the blockchain. When we measure the behaviour of the system as a whole we take into account both blockchain and API-related operations. When it comes to variables that describe the behaviour of a single AN, we also actually get readings on how the infrastructure behaves when it interacts solely with the blockchain. At last, the measurements were taken only after a transaction got con rmed, which means that we had to wait for a certain number of blocks to be mined (in our case 23 blocks). We conducted 12 simulation campaigns, which were divided in three groups. In each group we execute a validation campaign for each level assigned to ANw. Speci cally, we rst validate the infrastructure with only one AN that can write transactions on behalf of users, then with two and at last with three. The di erence between the groups lies in the maximum number of concurrent transactions that can be observed. For instance, in one group we can observe up to 5 transaction requests, in another 10 requests and so on.
Figures 5 report the most signi cant results of the campaign, in the perspective of nding the most suitable con guration that t our needs. Figure 5a shows the Average Response Time computed for requests processed by both the blockchain and high-level API. The maximum number of concurrent transaction requests is reported on the x-axis, whereas the Average Response Time, expressed as milliseconds, on the y-axis. Each curve describes how the system behaves with a speci c number of enabled ANs. As can be seen from the graph, the greater the number of requests is, the lower the response time gets. From the minimum to the maximum level of R evaluated, the response time improves by about 1 second. It is interesting to note that a few con gurations with a smaller number of enabled ANs may perform better than con gurations with a higher number of ANs. This behaviour is due to transaction-related computational costs, and higher consensus cost per update, given a higher number of nodes to sync. Regarding the System Throughput for blockchain and high-level API interactions, the results are reported in Figure 5b. Similarly to the previous graph, the maximum number of concurrent transaction requests is reported on the x-axis, while the System Throughput is expressed as milliseconds/requests, on the y-axis. The behaviour observed ts our expectations: the more simultaneous transaction requests arrive the better the throughput gets. Con gurations with two and three ANs achieve 180 requests per minute of throughput. If we consider the same number of concurrent requests, the con guration with only one AN achieves 200 requests per minute. The System Throughput tends to decrease as we enable new ANs, except for a few cases, even though the di erence is negligible. This trend becomes much more evident when the con guration with only one AN is compared with the remaining two con gurations. This behaviour is caused by synchronisation costs which increase when new nodes are added to the network. The analysis led us to choose a con guration with three ANs enabled for writing transactions on behalf of end users, forming the Network Con guration. At rst glance this choice might seem odd, because the con gurations with only one AN have often proved to o er better performances. However, there are two reasons that support our decision: i) there is no neat di erence with the results observed for con gurations with a higher number of nodes and ii) the less nodes are available the weaker the infrastructure gets from a security perspective. The nancial evaluation determined that the total yearly cost of the blockchain infrastructure would be about 7426 EUR. 3.2.5
After executing a set of campaigns, we extracted Simulation Logs from the blockchain itself, by using the implemented data transformation tool. From the 10865 events extracted, distributed among 5236 blocks of data generated by the simulation suite, the tool created a corresponding XES Log showed in Figure 6 The format is compliant with the XES mapping PIM, with some information added in order to track which AN was responsible for a speci c computation. We used Disco in order to analyze this XES log and obtained a trace graph, in the map view, shown in Figure 7. In the map every interaction either starts with an error event, thus ending the trace there and then, or with a Trade O er Placed event, that, as we know, is only emitted by a successful execution of the O erTrade function. And then in the vast majority of cases, a trace then moves from this event, towards either a successful TradeO erAccepted, or other error states, blocking the trace from progressing further. It is important to understand that error events are related to invalid attempts at calling a speci c function when the necessary preconditions are not true. And those can either be signals of malicious activities, aimed at subverting the business process, or benign, honest mistakes by actors. The map view, along with the other views present in the Disco tool, are instrumental in nding out whether or not the implemented process adheres to the model, or in other words, is compliant with business criteria analyzed during the modelling phase.Visual reports concerning this property of adherence form the Conformance Checking Report, while other, possibly non-visual and not strictly conformance checking related forms of information extracted from the xes le form the XES Logs Analysis, useful in the Design and Operation phase. To support organizations in mitigating the risks of the concrete adoption of DLT-based business processes, the paper proposed a methodological approach for the dynamic assessment of interorganizational business processes in which virtual environments, combined with simulation and analytical techniques, are used to create, validate and subject to stress tests business processes relying on blockchain and smart contracts solutions. With reference to a speci c business process under investigation that could bene t from the exploitation of DLT-based solutions, the proposed methodological framework, thanks to the combination of model-based and data driven techniques, allows not only to perform what-if/predictive analysis but also to get prescriptions on how to design, implement and con gure the concrete process and the underlying infrastructure by also taking into account the nancial impact of the development choices. Moreover, the simulation models and the data-driven techniques used for analyzing the business process under consideration can be reused to support its operation by enabling the implementation of monitoring, corrective and evolutionary maintenance services. Future research e orts will be devoted to further experiment the proposal with reference to inter-organizational business processes in several application domains as well as to improve its descriptive, predictive and prescriptive features. 5
This paper has been partially supported by the project \Id-Service: Digital Identity and Service Accountability" funded by the Ministry of Economic Development (MISE), project code number F/050238/01-03/X32. Terms and conditions enforced by the project regulation do not allow us to make public the source code of the software platform.