# Trusted Electronic Contract for Enabling Peer-to-Peer HPC Resource Sharing
## 3 Proposed Design
### Smart Contract Design and Communication Flow
Each network component was deployed as a Docker [33] container and communicates with others inside the Docker internal network. For the multi-host setting, we used four virtual machines (each has 2 CPU cores and 4 GB of RAM, Ubuntu 18.04) to create a Kubernetes cluster [34] of one master node and three worker nodes. Figure 6: Interface Module. Figure 7: Job Monitoring Operation in Interface Module. Role-based access control (RBAC) was configured according to the condition specified in Table 1 by overriding default Hyperledger Fabric's Access Control List. Therefore, only a specified set of roles were capable of accessing specific types of network resources (i.e., business logic chaincode*, system chaincode, and event service). In addition, to enforce another layer of control on the business logic level, built-in attributed-based access control (ABAC) was implemented on a smart contract by importing a class 'ClientIdentity' from the 'fabric-shim' library to perform credential checking on transactions prior to proceeding operation on the requested functions. (* note that _chaincode_ is the term used for representing smart contract in HLF)

1: const ClientIdentity = require('fabric-shim').ClientIdentity; **(Smart Contract - function)**

2: function requestComputingResources(arguments) {

3: let cid = new ClientIdentity(stub);

4: if (cid_assertAttributeValue(node_name', 'HPC_user){ // assert if the requester is user of HPC service

5: // perform matching

6: } else { throw new Error('Invoking Entity is Unauthorized');}

7: }

### Implementation of Interface Module

The module along with its dependencies was packed and built as a Docker image. Container runtime was installed on the HPC cluster, consisting of a single frontend node with Intel(R) Xeon(R) Silver 4110 CPU 2.10 GHz 16 Cores and 64 GB of memory, five compute nodes each with Intel(R) Xeon(R) Platinum 8168 CPU 2.70 GHz 192 Cores and 768 GB of memory. To ensure the module was seamlessly operated regardless of differences in the host machine environment, the module was deployed as a Docker container in which the Docker volume was mounted to the path that kept blockchain's cryptographic credentials, network connection profile, and action scripts. * Sub-module #1: Blockchain Gateway Service

The service was implemented in NodeJS using Hyperledger Fabric SDK for establishing a connection with the blockchain. Once the connection is created, the script will automatically make a request to the Certificate Authority node for registering the HPC system's identity. If registration is successful, cryptographic credentials will be generated and saved to a local folder named 'wallet'. Below displays the script for requesting identity generation. * Sub-module #2: System Monitoring Service

This sub-module acts as a middleman that helps querying, formatting, and passing system data to the Blockchain Gateway Service once there is a request for updated status information. The goal of this module is to monitor users' jobs status. Once a new job has been submitted to the HPC service, the system monitoring service will spawn new threads to monitor the job in particular. To implement the module, the code was written with the _worker_thread_ module in NodeJS. The code executed in the main thread (app.js) helped monitor and maintain the latest update of all users' jobs status. In addition, HTTP REST API endpoints were exposed to allow the blockchain gateway service to add a new monitored process. For the worker thread (worker.js), the script will periodically call _getJobStatus.sh_ and pass the interested _jobID_ as an input parameter. The script then performs querying on a scheduler and waits for the return status value of the job. If the thread finds the status is changed (by comparing with the variable _currentStatus_), it then sends a notification update to its parent (main thread).