# A New Blockchain-Based Multi-Level Location Secure Sharing Scheme
## 4 Our Proposed Scheme
### Our Proposed Scheme
#### 4.2.2 Location Record
\(LP\) should not gain a benefit from providing real data. For example, an online travel service provider provides local attraction introductions and different coupons to tourists in different regions. In this case, \(LP\) provides location data to obtain attraction introductions and coupons. ## 5 Experimental Evaluation

In this section, we evaluate the computation overhead of each phase in our proposed scheme and compare it to the existing scheme BMPLS [35]. The experiments are implemented on a PC (CPU: AMD Ryzen 7 4800U CPU @ 1.80 GHz, RAM:16 G, OS: Windows 10) using python-3.7. We used RSA-1024 as the asymmetric encryption algorithm, AES-256 as the symmetric encryption algorithm, SHA-256 as the hash algorithm, and ECDSA-SECP256K1 as the digital signature algorithm in the experiments. The results show that the computation overhead of our proposed scheme is much lower. Figure 7: Schematic diagram of the incentive and punishment mechanism. In Section 5.5, we deploy our designed \(SC\) in the Ethereum test network Ganache, whose predecessor was testRPC. Additionally, we evaluate the gas cost of smart contract \(SC\). ### Computation Overhead of the Initialization Phase

In the initialization phase, \(LP\) generates and encrypts the virtual location data \(Z\), and sends the ciphertext of \(Z\) to all \(Fnodes\). \(LP\) generates and encrypts the secret key \(k^{1}_{ud}\), and sends the ciphertext of \(k^{1}_{ud}\) to the \(LD\)s. We evaluate the computation overhead of \(LP\) in this phase with the different number of \(Fnodes\), where we assume that \(LP\) sends data to 20 \(LD\)s. Figure 7(a) shows that the computation overhead of \(LP\) increases linearly with the number of \(Fnodes\). We compare our proposed scheme to BMPLS, as shown in Figure 7(b) where we use the OPE algorithm proposed in [37]. From Figure 7(b) we can see that, compared to BMPLS, when \(N\) is larger than 4, the computation overhead of \(LP\) in our proposed scheme is much lower; \(O(k)\) denotes that the size of OPE plaintext space is \(2^{k}\). The computation overhead in BMPLS increases exponentially with \(N\). When \(N\) is larger, such as \(N=20\), the \(LP\) in our proposed scheme can still work with a very low computation overhead, while the \(LP\) in BMPLS will be unable to work because of the extremely high computation burden. ### Computation Overhead of the Location Record Phase

In the location record phase, \(LP\) generates the location record \(Record_{LP}\). \(Fnodes\) and the \(LPS\) verify the data received in the initialization phase with \(Record_{LP}\). Figure 8(a) shows that, compared to BMPLS (here, we use the plaintext-space of OPE \(O(15)\) for \(LP\)), the computation overhead of \(LP\) in our proposed scheme is much lower, about 13.5% of the computation overhead in BMPLS, where we set \(N=10\). Figure 8(b) shows that the computation overhead of \(Fnodes\) increases linearly with \(N\), and \(LD\)'s processing time is about 0.004 s.

Figure 8: Computation overhead of \(LP\) in the initialization phase. ### Computation Overhead of the Location Sharing Phase

In the location-sharing phase, _Fnode_ and provider-\(LD\) (the \(LD\) that has obtained the secret key \(k_{ud}\)), respectively, provide the virtual location data and \(k_{ud}\) to the demander-\(LD\) (the \(LD\) that has not obtained the secret key \(k_{ud}\)). First, we evaluate the computation overhead of data providers including _Fnode_ and provider-\(LD\). Figure 9(a) shows that the computation overhead of _Fnode_ and provider-\(LD\) in our proposed scheme is almost equal to that of \(LP\) in BMPLS. Second, we set \(N=10\) and evaluate the computation overhead of demander-\(LD\). Figure 9(b) shows that the computation overhead of demander-\(LD\) in our proposed scheme is twice as high as that of \(LD\) in BMPLS, \(LD_{0}\) and \(LD_{m}\) denote the \(LD\) that obtains a location point and the \(LD\) that obtains a location area, respectively. This phase needs to be executed only once during the running of our proposed scheme.