# Trusted Electronic Contract for Enabling Peer-to-Peer HPC Resource Sharing
## 3 Proposed Design
### Smart Contract Design and Communication Flow
While in a multi-host setting, Hyperledger Caliper was deployed as a Kubernetes Pod. Table 3 shows the latency in transaction processing of both setups. Multi-host setting exhibited a larger delay which possibly resulted from external uncontrollable factors, such as network connection delays between machines, which can be improved by adjusting network configuration. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & \multicolumn{3}{c}{**Ordering Service Type**} \\ \cline{2-4}
**Transaction Types** & **Single-Node** & **Multi-Node** & \\ \cline{2-4}  & **Solo** & **Kafka** & **Raft** \\ \hline Query & 0.01s & 0.06s & 0.02s \\ Invoke & 0.34s & 0.85s & 0.68s \\ \hline \hline \end{tabular}

* TPS = Transactions per second.

\end{table} 
Table 2: Average Latency in Transaction Processing (Total transactions submitted = 300, Rate = 100 TPS *). * _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.0384 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. These values are very small compared to the duration that a typical job normally takes to change its states which could take from seconds (e.g., job crashed: RUN \(\rightarrow\) END) to weeks (e.g., job wait in the long-running queue: QUEUE \(\rightarrow\) RUN). 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.