# Blockchain-Empowered Fair Computational Resource Sharing System in the D2D Network +
## 5 Problem Formulation
### Response Delay Optimization
* Greedy D2D task cooperation without our credit system: Without connectivity awareness, each helper device will equally contribute its available computing power to all connecting requesters at the beginning of a task period. For example, helper \(h_{5}\) will assign \(\frac{c_{k}^{h}}{3}\) computing power to each of \(p_{1}\), \(p_{3}\), \(p_{4}\) for the current task period if and only if \(p_{1}\), \(p_{3}\), \(p_{4}\) are the only requesters in connection with \(h_{5}\) at time \(\tau=0\). * Greedy D2D task cooperation with our credit system: This is very similar to the above case, except that our blockchain-based credit system is added in to enforce fairness. Therefore, the supernode at BS will check on requester balances before task assignment, ensuring that the assistance expected to be received by a requester will not exceed her.his available balance in that task period. * Connectivity-aware task scheduling without our credit system: At the start of each task period, the supernode at BS will perform task scheduling calculation according to Algorithm 1 without our blockchain-based credit system. * Connectivity-aware task scheduling with our credit system: This is very similar to the above case, except that our blockchain-based credit system is added in to enforce fairness, as illustrated in (15). Apart from being a reasonable incentive for users to provide help and gain credit for future needs, the blockchain credit also provides selfishness avoidance to our system. That is, it prevents certain users who only want to get help from peers, but not contribute to other users' need. We define hereof the level of selfishness, \(LoS\), to reflect whether users have been contributing relatively equally over task periods \(\Psi\in\{1,2,3,...,\chi\}\):  
\[LoS=\frac{1}{u}\sum_{k=1}^{u}(\sum_{\Psi=1}^{\chi}R_{k}^{\Psi}-\sum_{\Psi=1}^ {\chi}H_{k}^{\Psi}-\varpi)^{2} \tag{18}\]  
In the following experimental illustrations, we show the comparison of \(LoS\) in a normalized way: with respect to the greedy D2D task cooperation without our credit system case since \(LoS\) for this case is much larger than the other three cases and it appears to be stable over the changing factors. For simplicity, the mining process is simplified to a random selection of idle users to be miners in the network. To validate the performance of our proposed system, we set up the following experiment. Default simulation parameters are illustrated in Table 1, where the uniform distribution between two values \(a\), \(b\) is denoted as \(U[a,b]\). We used three real-world traces \"Intel\" (Trace 1), \"Cambridge\" (Trace 2) and \"Infocom\" (Trace 3) in the Cambridge/Haggle dataset in [30] for our simulations. Traces 1-3 were recorded by 8, 12 and 41 mobile iMotes using Bluetooth with a 30-metre radio range, respectively. Although these iMotes were not smartphones or tablets, the connection states recorded in these traces can be used to reproduce the dynamic topology for mobile users. The interval of each iMote sending a beacon (i.e., hello message) is 120 \(\pm\) 12 s.  
The connectivity between mobile users is assumed to be symmetric in our work. However, the connect and disconnect events in traces were recorded by each iMote individually. Thus, we consider that a pair of iMotes was connected (or disconnected) as long as one of them detected a connect (or disconnect) event. In the real-world traces, an iMote has recorded a connect event with a zero contact duration when it was connected with another iMote for a short period of time such that the iMote failed to receive two or more consecutive beacons. Thus, for a record with the zero contact duration, we assume that the actual contact duration is uniformly distributed on [0 s, 120 s]. We concatenate the contact and inter-contact durations recorded by each pair of iMotes in a chronological order to reproduce the connect and disconnect events for both of them. We then run trace-driven simulations with the D2D topologies reproduced by all iMote pairs in each trace.