# ID-Service: A Blockchain-Based Platform to Support Digital-Identity-Aware Service Accountability
## 3 Case Study: A Biomass Production Chain
### Simulation and Assessment System
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. The following dependent variables were identified: (i) Average Response Time, the average time taken by an AN or the entire infrastructure to fulfill a transaction request from an end-user; (ii) Throughput of the number of requests per time unit fulfilled by an AN, or by the entire infrastructure. The evaluation was conducted based on the following two independent variables: (i) Number of ANs (\(AN_{w}\)), the number of AN that can actually write transaction on behalf of an end-user; (ii) Number of concurrent transaction requests (\(R\)). Figure 4: Agent-based representation of what-if scenario where the logistics operator is not able to dispatch all biomass produced by the specialised company. 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. \(AN_{w}\) takes values from the set \(S_{1}=(1,2,3)\), whereas \(R\) from \(S_{2}=(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 \(AN_{w}\) 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 confirmed, 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 into three groups. In each group, we execute a validation campaign for each level assigned to \(AN_{w}\). Specifically, we first validate the infrastructure with only one AN that can write transactions on behalf of users, then with two and at last with three. The difference 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 significant results of the campaign. 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 in milliseconds, on the y-axis. Each curve describes how the system behaves with a specific 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 configurations with a smaller number of enabled ANs may perform better than configurations 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.