System Throughput

Figure 11 shows the results obtained when considering the round as a single operation, i.e., aggregating the results for each single operation. The figure thus shows the number of rounds per seconds, i.e., ops/s. The throughput results in more than 0.2 ops/s for the number of owners *k* = 10 and linearly decreases with the increase in *k*. With *k* = 80, we have on average a throughput of ∼0.07 ops/s. In this case as well, we can notice how the influence of *t* is almost irrelevant. As we have seen before, *t* influences greatly the Create Kfrag and Get CFrag operations, but these two, overall, slightly increase the round response latency with respect to the Request Access and Grant Access operations. Indeed, here too, we can see the effect of the blockchain execution in delaying the response time.

**Figure 11.** System throughput considering a round as a single operation, i.e., aggregating the results for each single operation, while varying *t* and *k*.

Threshold Number

Figure 12 shows the results when increasing the *t* value and the number of owners *k* for each *i*-th round, i.e., it shows the performances for each subsequent round instead of aggregating all rounds through their mean. In this case, the results shown confirm that the increase in *t* does not influence much to the overall response delay. However, this temporal point of view shows the accumulation of delay in the response time when increasing *k*. We can see, for instance, that up to *k* = 30 each *i*-th round has more or less the same average latency. When increasing *k*, however, the latency of rounds in the middle spikes upwards, due to the accumulation of operations to perform, and then returns to a relatively normal value in the last rounds (i.e., 9-th and 10-th).

**Figure 12.** Average response latency when increasing the threshold *t* value and the number of owners *k* for each *i*-th round.
