## 4 HMBAC Design and Implementation
### Janus Implementation
#### 4.3.4 Smart Contracts  
As described in Section 4.2.3, the blockchain services are implemented through smart contracts. Five smart contracts utilize all system's functionality, at both the global and domain level. The PSC, TMSC, and LSC are stored at the Proxy Blockchain and shared among all stakeholders, while the ACSC and KSSC are stored at each Domain Blockchain and provide domain-specific functionality (see the relevant artifacts provided in [5] for details). Following the system design, smart contracts are able to interact with each other through the relevant APIs, as depicted in Figure 5. In particular, a logical connection between users and the PSC is achieved through the Frontend API while a similar connection among the Proxy BC's smart contracts and the Domain BCs is achieved through the Inter-BC API. In the following paragraphs we present the technical analysis for each smart contract along with the main services supported. **Proxy Smart Contract (PSC),** integrates the functions for _user validation_, _stakeholders' voting_ and _request forwarding_. For user validation, the \(validateUser()\) function takes as input an array of _userCerts_ provided by the user at login, and triggers the \(getUserValidation()\) \begin{table}
\begin{tabular}{c c c c} \hline \hline  & \multicolumn{3}{c}{**Congestion Types**} \\ \hline
**Scale** & **Congestion Level (CL)** & **Monitor Interval** & **Throttle Multiplier** \\ \hline
**Normal** & \(2\leq CL\) & 5 s & \(1\) \\ \hline
**Low** & \(1\leq CL<2\) & 4 s & 0.7 \\ \hline
**Medium** & \(0.5\leq CL<1\) & 3 s & 0.4 \\ \hline
**High** & \(0.3\leq CL<0.5\) & 2 s & 0.1 \\ \hline
**Extreme** & \(CL<0.3\) & 1 s & 0.01 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Types of congestion. function stored on the TMSC, in order to validate the certificate(s) provided. Based on the outcome of the validation, the PSC returns the validated user's roles (short- and long-term). The voting mechanism is a crucial component of the system. Through this mechanism, stakeholders can reach management decisions including: (a) adding/removing domains (and the relevant DBCs); (b) adding/removing stakeholders to an existing DBC; (c) modifying a (cross-) domain access policy; and (d) giving access to logs for external auditors. Other processes that require broader consent can also be supported. For each stakeholder, the stakeholder administrator or a delegated external auditor may invoke the \(majorityConsentInit()\) function to propose a new election. It first checks if another election with the same payload is active and then calculates the ElectionID based on the provided payload. A new Election instance is created and added to the ledger and also a ballot for each stakeholder. With \(majorityClientVote()\), the administrator of each stakeholder votes in an Election by signing with the organizations' private key. The \(updateElection()\) function checks if the Election has been finalized based either on the predefined majority rules or the timeout set. The \(requestAccess()\) function handles two processes. First, it constructs the \(requestDetails\), which is sent to the LSC for logging. Then, sends a \(requestForward\) event to the Inter-BC API to complete the request. **Trust Management Smart Contract (TMSC),** contains the functions that support trust management services. The \(initLedger()\) function is responsible for handling the certificates and revocation lists of each stakeholder. It takes an \(initPayload\) argument and appends the corresponding data to the PBC. Additionally, it creates empty Access Control List (ACL) files for each organization. The \(getUserValidation()\) function takes as input either an ACL file (to verify temporal roles assigned to users) or a certificate (to verify long-term user roles). Note that users may have obtained certificates issued by different stakeholders, provided that all certificates of a user include the same unique global identifier (GID).