6.2.2. Results

We recall that *n* is the number of validator/authorization blockchain nodes and was set to 4. We consider a round of operations the successful execution of the above described operations in order. The independent variables tested were the *threshold t*, from 1 to 4, and the *number of data owners k*, from 10 to 80 with an increase of 10 each time. We tested all the combinations of independent variables 3 times; then, we averaged the results. In each test, we initiated the round of operations 10 times for each data owner, with an interval of 3000 ms on average (value given by a Poisson Process with a mean of 3000 ms). This implies that, if overall, the set of operations lasted more than 3000 ms to be executed, probably another one was launched in parallel. This is for each data owner. The dependent metrics we measured with the tests are the *latency*, for a response to an operation, and the system *throughput*, i.e., the number of rounds of operations per second.

### Round of Operations

Figure 10 shows the average response latency and standard deviation for each operation in a round. The first result that stands out is the large difference in latency between the Request Access and Grant Access operations and the Create KFrags and Get CFrags operations. This is due to the fact that the first two operations involve writing in the authorization blockchain's ledger. Thus, we can already see the impact of the blockchain in the overall system response latency.

**Figure 10.** Average response latency and standard deviation for each operation in a round, varying the threshold from 1 to 4 and data owners from 10 to 80.

As can be seen, in general, the *t* value does not affect the results greatly. On the other hand, as expected, the *k* value that represents the number of data owners is the key factor. A slow but constant increase in the round response latency happens between 10 and 40 owners, starting from 2 s latency to 3, for both Request Access and Grant Access operations. After 40 owners, the latency increases faster per number of owners. This seems to be correlated to the fact that a new round is started on average each 3 s for each data owner. Thus, if the round takes approximately more than 3 s, as from *k* = 50 onward, many more operations start to be executed in parallel. The increase in such parallel executions seems to increase the response latency overall.

While the blockchain writing-dependent operations are in the order of the thousand milliseconds, i.e., seconds, the KFrags and CFrags operations are in the order of the hundreds and can be better analyzed using Table 3.


**Table 3.** Average response latency and confidence interval for the Create KFrags and Get CFrags operations in a round, varying *t* and *k*.


**Table 3.** *Cont.*

In both cases, we can see a direct correlation of response latency with both the *t* and *k* values. With *k* = 10, latency values for the Create Kfrag operation are around 90 ms, while those for the Get CFrag operation are around 110 ms. With *k* = 80, the values more or less double.
