# A Cross-Chain-Based Access Control Framework for Cloud Environment
## 6 Evaluation
### Result and Analysis  
Analyzing the extracted data from the BC logs of 50 different access transactions we constructed, we found that it takes an average of 5.39 ms to check access for legitimate cloud users with matching attributes that do not need a semantic intervention, with a 95% confidence interval (CI) of 4.57 to 6.20 ms (as shown in Figure 9a). The transaction latency of the first type hovers around an average of 13.50 s, with a 95% CI of 12.93 to 14.05 s (as shown in Figure 9b). The latency in our framework seems significant, but in contrast to other one-chain solutions, our cross-chain involves two verifications of cryptographic proof (the Merkle and commitment proofs) in each of the sending and receiving chains with instant block finality.  
The average AC time for a decision using semantic reasoning to grant access is 14.26 ms, with a 95% CI of 11.69 to 16.82 ms. Due to the additional pro  
Figure 9: AC processing time and latency results: **(a)** AC processing time averages with 95% CI (ms); **(b)** transaction latency averages with 95% CI (s); **(c)** AC processing time for different transaction types (ms); **(d)** transaction relay latency for different transaction types (s).  
knowledge about the attributes received from the ontology file, the tx relay latency reaches an average of 14.40 s and a 95% CI of 13.72 to 15.08 s.  
The third type of tx scores an AC processing time that averages 9.51 milliseconds with a 95% CI of 8 to 11.02 ms. The average relay latency of this type of transaction is 13.43 s, with a 95% CI of 13.06 to 13.79 s.  
As shown in Figure 9c, we compared the processing times of the deployed AC mechanism for the different evaluated transaction types, and we found that the first type of tx gives the fastest decision processing time for positive responses. The first-type tx AC processing times fall under the second tx type, which implies that our framework is efficient in processing requests from legitimate cloud users.  
To benchmark the performance of our framework, we stress-tested the Tendermint-based blockchain with a load of transactions. We initialized the test with 250-byte txs directed to the chain. This test covers an interval from 100 to 7000 TPS (as shown in Figure 10) in which we measured the amount of data in BPS for each value of TPS.  
The total and average transactions, as shown in Figure 10a,c, increase almost linearly up until 4000 TPS. The same pattern is also seen in the total bytes processed in Figure 10b, which increases proportionately until about 4000 TPS. Beyond 4000 TPS, deviations come  
Figure 10: TPS measure: total transactions vs. TPS. (**a**) Throughput measure: total bytes processed vs. TPS. (**b**) TPS measure: average transaction rate vs. TPS. (**c**) Throughput measure: average BPS vs. TPS (**d**).  
up, signaling that the system has hit a performance bottleneck, in which the transaction processing capacity becomes inconsistent with a 10% efficiency drop. The instant blockchain finality of Tendermint's consensus mechanism may also cause performance bottlenecks, as it cannot keep up with the growing number of transactions at 7000 TPS; the efficiency is at 46%. The average data rate (BPS), as shown in Figure 10d, peaks close to 750,000 Bytes/s and also becomes linear in proportion to the TPS. In these tests, we observed that up to 4000 TPS, the efficiency is constant at 250 bytes per transaction but decreases after 4000 TPS, indicating deviations and potential resource exhaustion.