# Trusted Electronic Contract for Enabling Peer-to-Peer HPC Resource Sharing
## 3 Proposed Design
### Smart Contract Design and Communication Flow
Pseudocode for finding a candidate set of HPC systems is presented as follows:  
Let \(DR_{q}\) represent computing resources and program requirement that are demanded by a user \(a\) (JSON data displayed in Figure 5c) and \(PR_{A}\) represent information regarding provided computing resources owned by cluster \(A\) (JSON data displayed in Figure 5a), the pseudo code of the _findResourceMatching()_ algorithm (Algorithm 1) is defined as follows  
```
Input: Object containing desired resources spec from user (\(DR_{user}\))
1: MatchedSpec \(\leftarrow\) query list of matched_cluster's IDs in which \(PR_{\text{{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{ \



Let \(HS_{A}\) denote the latest update on the utilization state of cluster \(A\), pseudocode of _displayResourcesAndRentalPrice_() algorithm (Algorithm 2) is defined as follows
```
Input:Object containing desired resources spec from user (\(DR_{user}\)), current user location
1:results = []
2:Candidates = findResourceMatching(\(DR_{user}\))
3:for all \(IDs\in Candidates\) do
4:differentDistance = calculate approximated distance between 2 IPs (user and \(PR_{ID}\).IP)
5: [adjustedCPUprice, adjustedGPUprice] = weighPriceByDistance (differentDistance,
[\(PR_{ID}\).rate.cpu_core_per_hr, \(PR_{ID}\).rate.gpu_core_per_hr(\"optional)]) // adjust price based on distance
6: \(HS_{ID}\leftarrow\) queryHealthState Object by cluster ID
7:results.push((ID: \(PR_{ID}\).clusterID, queues:{ available: \(PR_{ID}\).queues, current_state:  
\(HS_{ID}\).queues), rate: {cpu: adjustedCPUprice, gpu: adjustedGPUprice }})
8:return results
```
**Algorithm 2**Pseudocode of _displayResourcesAndRentalPrice_**0**

**Rentural List of Clusters (with the Adjusted Rental Price and Utilization State) That Match to User's Job**

**Rental Process** Once the user chooses an HPC system and a preferred queue type from the candidate list, he/she then composes and submits a transactional request to the blockchain. The user will then be requested to pay a security deposit which calculated from

Figure 5: Data Object in JSON format. (**a**) HPC System Object (stored on blockchain state); (**b**) Cluster State Object (stored on blockchain state); (**c**) User’s Job Submission Request Payload. security deposit = (requested cpu cores * _cpu_core_per_hr_) * 30% of queue's _max_walltime_* same calculation apply for requesting GPU cores. Note that _cpu_core_per_hr_, _gpu_core_per_hr_ (optional) and _max_walltime_ are retrieved from _resourceSpec_ attribute (JSON data displayed in Figure 5a) in _HPC System_ object (Figure 3) from blockchain state. This amount of money will be held by the blockchain as a security assurance for both parties until the job has been completely processed. The system will invoke the _generateAccessLisernane()_ function which will generate a globally unique username for the user. This username along with the user's contact address will also be sent to the HPC administrator for generating login credentials to access the HPC cluster. Users can expect to receive an access passcode from the service provider via provided contact channels. ### Job Submission & Status Notification

After the access passcode is sent, the user can now access the HPC system and submit his/her job. Upon a job being added to the queue or a change in a job's status (i.e., null \(\rightarrow\) QUEUE, QUEUE \(\rightarrow\) RUN, RUN \(\rightarrow\) END), the events will automatically be detected and composed into a blockchain transaction. Once the transaction is committed, the user will be notified by the _events_ generated by a smart contract. These functionalities are automatically performed by the interface module, in which the design and mechanism will be elaborated in the subsequent section. Design of Interface Module

Since some operations have to deal with large data input size and/or required confidentiality preservation, performing such actions off the chain while synchronizing small-sized checkpoint data on-chain is one of the efficient approaches used in this research work.