## 5 Efficiency Analysis
### Benchmarks  
We conducted our evaluation on two different hardware configurations with varying resources, using the Linode cloud infrastructure. As depicted in Table 4, in the first H/W setup (S1), an AMD EPYC 7501 32-core processor @2 GHz with 64 GB RAM is used. The second H/W setup (S2) is an environment with higher resources, based on an AMD EPYC 7702 64-core processor running at @2 GHz with 512 GB RAM. As our implementation Janus utilizes eight (8) Kubernetes pods, where each Pod corresponds to an independently managed server, setup S1 (resp. S2) corresponds to four cores/8 GB RAM (resp. 8 cores/64 GB RAM) per server.  
Both sets of configuration run Ubuntu 20.04.1 LTS OS and Kubernetes 1.20.11 was used for container orchestration. The multi blockchain components were developed in Hyperledger Fabric 2.4 beta with Raft as the underlying consensus algorithm and also fabric-ca-client 2.2.6, fabric-network 2.2.9 and fabric-gateway 0.1.0 were used for establishing communications.  
Following the two access rule examples mentioned in Section 4, we created both inter-domain queries (e.g., _\"Retrieve the medical record for patient P from all hospital databases\"_) and cross-domain queries (e.g., _\"Update the firmware for medical device D of manufacturer M at all hospitals\"_). Each database was running on a separate Pod and data were ABE encrypted. The initial ABE decryption was performed by the KSSC running in the relevant BC domain of the requesting user, as described in Section 4.3.5.  
We measured the average end-to-end query response time for various sizes of queries, ranging from 2 up to 300 _concurrent_ queries (req/s), with an approximately even portion of inter-domain and cross-domain queries. Table 5 shows the average execution time for all scenarios tested. In addition, the table presents the time needed for the main subprocesses of the query-response process.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \multicolumn{2}{c}{**CPU (\# Cores)**} & \multicolumn{2}{c}{**RAM (GB)**} \\ \hline  & **Total** & **Per Pod** & **Total** & **Per Pod** \\ \hline
**Setup S1** & 32 & 4 & 64 & 8 \\ \hline
**Setup S2** & 64 & 8 & 512 & 64 \\ \hline \hline \end{tabular}
\end{table}
Table 4: H/W specs for testing.  
_Ticketing_, refers to the time required by the system to issue a ticket for a user. _Endorse_, is the time it takes for peers to receive a request and sign the result. _Commit_, is the time required by the orderer nodes to create a new block. Finally, _BC_RTT_ is the time needed to execute all the required BC functions (smart contracts) and inter-BC communication. In addition, the minimum and maximum time required for a query is presented in each scenario, to exhibit the deviation from the average time. As expected, the most resource-intensive process is BC_RTT, which encompasses all subsystems, from Proxy BC up to the retrieval of encrypted data from the independently managed databases, as well as the partial decryption process using the domain keys.  
However, the overall time increase is linear (see Figure 7), which indicates the scalability of the HMBAC design.  
Adding new authorities will increase the number of users and, consequently, the number of requests. At the same time, it will also increase the overall system resources, as the new authorities will devote resources to become stakeholders of the Proxy and of their Domain blockchain. The system's performance is linearly dependent on the available resources, which means that as resources increase, the overall time decreases. Note that in both system setups the system presents zero errors per requests, due to the queuing module integration.