# Trusted Electronic Contract for Enabling Peer-to-Peer HPC Resource Sharing
## 3 Proposed Design
### Smart Contract Design and Communication Flow
In addition, the amount of resources (e.g., CPU, memory) needed in the execution is very small and insignificant compared to the capability of HPC's frontend. The script also uses only memory for keeping track of state data, no read/write to the storage. Therefore, the inclusion of the module in the HPC systems will not impact the overall performance and system workload or interrupt the core operational process of HPC. ### Security Analysis

1. _Access Control on Blockchain Network Resources_

Two permission layers were configured to enhance security on the blockchain. The first was an access control list (ACL) which defined permission on network resources (i.e., submit transactions, perform system activities, subscribe to event hub). Another permission layer was defined within the smart contract's functions to ensure that only legitimate entities are allowed to make a request. Using attribute-based access control

\begin{table} \begin{tabular}{c c c c c c c} \hline \hline
**Network** & \multicolumn{3}{c}{**Query Transaction Latency**} & \multicolumn{3}{c}{**Invoke Transaction Latency**} \\ \cline{2-7}
**Deployment** & **Min** & **Max** & **Avg.** & **Min** & **Max** & **Avg.** \\ \hline Single Host & 0.01s & 0.05s & 0.01s & 0.57s & 0.88s & 0.68s \\ Multiple Hosts & 0.08s & 0.36s & 0.18s & 0.61s & 1.96s & 1.24s \\ \hline \hline \end{tabular} 

* _HPC Interface Module_

The interface module is one of the core parts of this system. Without it, communication between HPC and blockchain is not possible. Two key components in this module are the blockchain gateway service and the system monitoring service. As the blockchain gateway service can only be implemented in a single structural way following the Hyperledger Fabric implementation guideline, the experiment focused on only the system monitoring service in which the implementation can be tweaked to finetune performance. Since the system monitoring service leverages the concept of multiple threading to perform monitoring on different tasks simultaneously, the test was conducted by measuring the total time of a single execution loop which is calculated as follows:

\[ \begin{array}{ll}\textbf{Total Execution}&\textbf{Time}\\ &=\textbf{Time to spawn a worker thread}\left(\textbf{T}_{spawn}\right)\\ &+\textbf{Execution time in worker thread}\left(\textbf{T}_{executor}\right)\\ &+\textbf{Time for update on local state}\left(\textbf{T}_{update\_state}\right) \\ \end{array} \]

Note that the task executed on the worker thread \(\textbf{T}_{executor}\) can either be retrieving cluster health data (executes bash script _getResourceUtilization.sl_) or monitoring for changes in the job’s state (execute bash script _getJobStatus.sl_). In the case of monitoring a job’s state, \(\textbf{T}_{executor}\) can vary according to the job’s queueing time (which depends on previous jobs’ execution time) and processing time. Therefore, in this experiment, we assumed that the job’s initial status was RUN, and at the moment that monitoring started, the job's status changed to END. Thus, \(\textbf{T}_{executor}\), in this case, was the only duration that the worker executed/getJobStatus.sh plus the time that the status update message was returned to the main process. Table 4 displays the time for executing each sub-process in system monitoring services. After conducting five rounds of tests, the results showed that the execution time on the average of \(\textbf{T}_{spawn}\) was 8.6839734 ms, \(\textbf{T}_{executor}\) in monitoring change in the job’s status was 38.03848 ms, \(\textbf{T}_{executor}\), in retrieving current cluster utilization data was 667.663 ms, and \(\textbf{T}_{update\_state}\) was 0.2911276 ms. By summing up the average value of \(\textbf{T}_{spawn}\), \(\textbf{T}_{executor}\), _and \(\textbf{T}_{update\_state}\)_, the result shows the total execution time takes 46.9 ms for monitoring jobs and 676.6 ms for retrieving cluster state.