## 4 HMBAC Design and Implementation
### Janus Implementation
#### 4.3.3 Inter-Blockchain API  
The goal of the Inter-Blockchain API is to enable the interaction between the Proxy and the Domain Blockchains. This however raises performance and management challenges at the implementation level. Handling and prioritizing requests between different blockchains is a difficult task, as it may result in a significant performance decrease or even system failure. To deal with this issue we have implemented a novel queuing mechanism for Request Handling and Prioritization. In addition, reaching management decisions for blockchain actions that require the agreement of stakeholders at a domain or at a global level (e.g., adding/removing stakeholders or domains) requires a distributed and asynchronous decision support mechanism. To achieve this, we have implemented an efficient voting management mechanism, integrated into this layer. The implementation of these key Inter-Blockchain mechanisms is described below. Note that the Inter-Blockchain API is also developed in Node.js. Each stakeholder runs a different instance, executed on a distinct Kubernetes Pod, while its services are accessible to other Pods via the Kubernetes-exposed ports. (a) Request Handling and Prioritization  
To manage requests, the Inter-BC API, utilizes two general types of queue. The _Proxy Queue_, for every request that needs to be forwarded to the PBC and _Domain Queues_, for requests that need to be forwarded to one or more DBCs. Every DBC has its own Domain Queue, and thus their number depends on the number of DBCs. The request handling flow is illustrated in Figure 6 and is described below. **Step1: Listen and acquire. ** When an organization (_Stakeholder instance_ in the Inter-Blockchain API) receives an event, it first verifies if it is the intended recipient. Next, it forwards the user query, say \(Q_{i}\), to _Queue Manager_ in order to temporarily save the message and process it later when it is ready for consumption. **Step2: Get the request \(Q_{i}\) and forward it to the relevant DBC. ** When it is time for a request \(Q_{i}\) to be consumed by the appropriate DBC, the Queue Manager receives it (from the relevant Domain Queue of the Inter-BC API) and forwards it to the instance of the organization to which the requesting user belongs. The organization instance then forwards \(Q_{i}\) to the DBC of which the organization is a member. Upon completing the request, the response that was received from the DBC is then, again, sent to the Queue Manager in order to queue the new message and consume it, i.e., forward the response to the PBC when ready. The Queue Manager also sends an Acknowledgment message (ACK) to RabbitMQ to inform it that the message was successfully consumed. RabbitMQ receives the ACK and removes the message from the Domain Queue. **Step3: Get the response \(R_{i}\) and forward it to the PBC. ** When the response \(R_{i}\) to the query \(Q_{i}\) is received from the relevant DBC, it is ready to be consumed. The Queue Manager receives it through _Proxy Queue_ and forwards it to the appropriate organization instance. The organization then receives the response and forwards it to the PBC to continue processing the response. When forwarding \(R_{i}\) back to the PBC, the Queue Manager sends an ACK to RabbitMQ to inform it that the message was successfully consumed. RabbitMQ receives the ACK and removes the message from the Proxy Queue. To maintain the flow healthy and avoid Denial-of-Service errors or attacks on the Proxy BC, a _Queue Supervisor_ is utilized. The Queue Supervisor constantly monitors the Proxy Queue for spikes/congestion in the network. As shown in Table 3, we define five types of congestion, each of which is chosen based on the current level of congestion (CL). Figure 6: Inter Blockchain API Flow. Depending on the type of congestion, the system adjusts, in order to handle requests, avoiding DoS, and assuring that all requests will be served.