# Trusted Electronic Contract for Enabling Peer-to-Peer HPC Resource Sharing
## 3 Proposed Design
### Overview of System Architecture and Components in Trusted Computing Resource Sharing  
To create an automated trust system, every action on the systems must be ensured to comply with the network agreement. Two key players in this architecture are users, who demand computing resources, and service providers, who are willing to offer HPC service to the public. Two possible models can be implemented according to setting requirements. Users are connected to the blockchain via a decentralized application (dApp), where all activities, such as requesting resources and getting notifications for change in the summited jobs' status, are carried out automatically by having a client-side script make a request to a smart contract. For HPC, the frontend node requires the installation of an _Interface Module_ to enable communication between blockchain and HPC. By having the module installed on HPC, any updates on blockchain or cluster state will automatically sync which benefits clusters in obtaining a symmetrical view of network states. (Details of this module will be elaborated in the subsequent section).  
Figure 2a: In this model, all participants in the network are trusted. This can be achieved by having a thorough consideration process; for example, the HPC system must go through stages of historical creditability screening, verifying SLA documents, etc., prior to registering the computing cluster to the network.  
Figure 2b: In this model, we allow the registration process of HPC systems and users to be less strict. This approach encourages new service providers who may have no creditability profile to freely participate in the market. Since we assume no entity can be trusted, there is a possibility that HPC systems deliver corrupted computation results or correct computational results get denied by dishonest users. Two main mechanisms to resolve the issues are:  
1. Majority voting-replicate job execution on multiple compute workers (let us say, \(n\) workers). The results obtained by the majority are assumed to be correct. The drawback of the scheme is intensive resource consumption as the computational resources needed are multiplied by a factor of \(n\).
2. Result validation--in this option, a user must implement a module to validate if the results he/she obtained are correct. However, the implementation of such a scheme is complex and requires efforts from users to some extent.  
Several research efforts have contributed to the design of a majority voting scheme. In 2002, a dynamic voting scheme [28] is presented by allowing the number of participating workers for a particular job execution to vary according to the level of confidence. The scheduler is responsible for deciding the number of replicated factors (i.e., number of computing nodes) during execution time. This scheme reduces time in reaching consensus and ensures that only the necessary amount of resources to attain confidence are used. Developed upon the previous concept, iExec [29] has proposed a tweak of design that includes a monetary factor to the model. The goal is to offer an incentive (in the form of digital currency) to honest workers. The approach is to let the worker attach a disposable personal identifier along with its computing result. If the result is correct and the worker can present the proof of ownership, it will then receive an incentive according to the commitment fund.