A New Blockchain-Based Multi-Level Location Secure Sharing Scheme

: Currently, users’ location information is collected to provide better services or research. Using a central server to collect, store and share location information has inevitable defects in terms of security and efﬁciency. Using the point-to-point sharing method will result in high computation overhead and communication overhead for users, and the data are hard to be veriﬁed. To resolve these issues, we propose a new blockchain-based multi-level location secure sharing scheme. In our proposed scheme, the location data are set hierarchically and shared with the requester according to the user’s policy, while the received data can be veriﬁed. For this, we design a smart contract to implement attribute-based access control and establish an incentive and punishment mechanism. We evaluate the computation overhead and the experimental results show that the computation overhead of our proposed scheme is much lower than that of the existing scheme. Finally, we analyze the performances of our proposed scheme and demonstrate that our proposed scheme is, overall, better than existing schemes.


Introduction
With the development of technologies such as smart phones [1], smart wearable devices [2], and the Internet of Things [3], the location of target objects can be collected for enterprises or governments to meet business needs, such as vehicle navigation [4], epidemic prevention [5] and social software. For example, since December 2019, the COVID-19 virus has spread all over the world. Scientific epidemic prevention and control measures can effectively curb the spread of the epidemic and reduce the population infection rate. For this reason, it is of great significance to grasp the location information of cases, suspected cases, and the close contacts of cases. For this, location-based services (LBS) [6][7][8] have been developed and popularized.
Location information contains a large amount of private user information, which is a valuable information resource that should be properly managed. In the process of location sharing, if the location data are leaked, tampered with or forged, this will not only reveal the private information but also negatively affect the business of location acquisition services. Especially in a large-scale location-sharing system, containing a large number of location providers and location demanders, how to ensure information security and privacy protection has become a serious problem that cannot be ignored.
Undifferentiated information sharing [9] can no longer meet the needs of user privacy protection in location information sharing; hence, a secure, efficient, multi-level location information-sharing scheme is required. Location data demanders should be allowed to obtain location data with limited accuracy. For example, a social software server should be allowed to obtain a larger location area to determine the city in which the user is located.
However, a healthcare provider should be allowed to obtain a street-level area or even the exact user's location coordinates. This requires multi-level access control for location data.
Traditional data-sharing schemes [10][11][12] use centralized servers to process and save data, and implement certain access control rules. For the centralized servers, users' privacy cannot be fully protected, even with the help of some privacy protection technologies, such as k-anonymity [13,14], which will cause data loss. If the centralized server is attacked, large-scale data security problems will arise. Moreover, even if many users in the network already have relevant data, the centralized server must also participate in all data-sharing processes, making the burden of the centralized server very high.
There is no centralized node or authoritative manager in the blockchain network. Blockchain is a distributed ledger and, based on the agreed specifications and consensus protocols [15][16][17], it is jointly maintained by the nodes of the blockchain network in a detrusted environment. Smart contracts [18,19] support various data-access strategies, such as attribute-based access control (ABAC [20][21][22], and role-based access control (RBAC) [23][24][25]. Data can be circulated in the blockchain network according to the custom rules. In addition, the data structure of the blockchain has a strong immutability. All the above properties endow the blockchain technology with an inherent advantage in the field of data sharing.
The following problem needs to be solved: while effectively sharing location information, the user's location privacy must be protected, and the received data must be true and credible.
To solve this problem, in this paper, we propose a new blockchain-based, multi-level secure location sharing scheme. In our proposed scheme, location information is defined as multiple different accuracies. Location information demanders (LDs) are assigned different access levels, so they can learn the area where location information providers (LPs) are located with different accuracies. Moreover, we ensure that the received data can be verified. Our main contributions are summarized as follows: (1) We design a new method to strip the location information into multi-level virtual location data and offset vectors, thus realizing the multi-precision setting of location information; (2) We design a smart contract to implement fine-grained, attribute-based, multi-level access control to the location data in a decentralized environment; (3) We establish an incentive and punishment mechanism through a smart contract to ensure the honest operation of nodes in the location-sharing system; (4) We record the root node of the Merkle tree and the hash value of the data in the blockchain to realize the immutability and verifiability of the data; (5) We evaluate the computation overhead in the proposed scheme, and the experimental results show that our proposed scheme is more effective than the existing scheme; (6) We analyze the performances of our proposed scheme and prove that it not only inherits the decentralization and immutability of the blockchain but also has the properties of multi-level privacy protection, verifiability, etc. Compared with other existing schemes, our proposed scheme has better performance overall.
The organization of this paper is as follows. Related works are introduced in Section 2. We briefly introduce the smart contract and Merkle tree in Section 3. The system model and the scheme of this paper are described in Section 4. We evaluate the computation overheads of each phase in our proposed scheme in Section 5. We analyze the performances of our proposed scheme in Section 6. Section 7 concludes the paper.

Related Works
Using a centralized server to share location [9] is a common method. Dodgeball is one of the earliest location-based online social network (LSN) services; founded by Dennies Crowley and Alex Rainert in 2000, it relied heavily on short message services (SMS). Users texted their location to the service, which then notified other users. Google launched the "Latitude" service in 2009. Google latitude allows users to update their locations by manually typing an address, so as to disable real-time tracking and hide their locations from others. In WhatsApp [26], users are allowed to share their current coordinates to others over the system. However, if users share their location in a group consisting of individuals they have blocked, the blocked individuals will still be able to see their location. During the COVID-19 pandemic, Singapore and Australia used centralized apps [27], and sent data collected by a user's phone to a central database controlled by a national health agency or another governmental authority. In April 2020, Apple [28] and Google revealed that they were busy developing privacy-friendly contact-tracing technology, which is inspired by the ultra-privacy-sensitive DP-3T protocol. The protocol includes: (1) The use of Bluetooth. (2) The generation of random identification numbers by phones that change every 10-20 min. (3) An opt-in system. (4) The data being stored and processed on users' devices.
In 2008, S. Nakamoto [29] proposed blockchain technology to prevent the doublespending problem using a peer-to-peer network. Although the blockchain was originally developed as a trading platform for virtual cryptocurrency, the application of this technology in different fields [30,31] in recent years has been surprising. Among them, blockchain is expected to change the form of data management and sharing in many scenarios.
Guy zyskind et al. [32] proposed a blockchain-based personal data storage scheme UB-PPD. In UB-PPD, two types of transactions, namely, T access for access control management and T data for data storage and retrieval, are recorded in the blockchain as an automatic access controller. The user's personal data, including location data, are stored and accessed off-chain through Distributed Hash Table (DHT). Asaph Azaria et al. [33] proposed a blockchain-based, decentralized record-management system (MedRec) to process Electronic Medical Record (EMRs). Medical data are stored in care-providers' local database. Three types of smart contract, Registrar Contract (RC), Summary Contract (SC), and Patient-Provider Relationship Contract (PPRC), are used to manage the process of access control and data sharing. In the above two works, the requester cannot verify the received data, and the privacy protection of the data recorded in the blockchain is not considered. In UB-PPD, the nodes in the blockchain network can even freely access the user's personal data. Kai Fan et al. [34] proposed a blockchain-based medical-information-sharing scheme, Medblock. EMRs are stored in external databases, and the ciphertext and the summary information containing the storage address of the EMR are recorded in the blockchain. Any user can access the hash value in the blockchain to verify the data, while the access control protocol recorded in the block header is executed to allow legitimate users to obtain the ciphertext of the summary. Unfortunately, the access control in Medblock is inefficient. Blockchain, as a distributed database, is not suitable for recording heavyweight data.
For location data, Yaxian Ji et al. [35] proposed a blockchain-based, multi-level, location-data-sharing scheme (BMPLS). Location requesters with different access levels can obtain location data with different accuracy, then use Order-Preserving Encryption (OPE) [36] and Merkel tree to verify them. However, BMPLS has the following serious problems: (1) The authenticity of OPE ciphertext, which is used to verify the authenticity of the location data, cannot be verified. (2) Although the OPE scheme [37] used in BMPLS is one-way security [38], and the probability of adversary use of OPE ciphertext to recover the plaintext is negligible, the location requester can use two pairs of border OPE plaintextciphertext and the location OPE ciphertext to greatly, illegally, improve the accuracy of received location information. (3) The computation overhead of the location owner in BMPLS is too high.

Smart Contract
In the 1990s, Nick Szabo [39] first proposed the concept of smart contract, a computer protocol designed to propagate, verify, and execute contracts. In blockchain technology, especially after Ethereum [40] was proposed, smart contract became an executable program stored in the blockchain. Ethereum provides a platform, a virtual computing environment called Ethereum Virtual Machine (EVM), which allows users to use a complete program-ming language to write smart contracts. Once certain conditions are triggered, the smart contract program can run automatically. A smart contract allows verified transactions and protocols to be executed between different anonymous parties without a trusted third party. However, a smart contract cannot work actively; it must be called by the blockchain users or other smart contracts.
However, the blockchain is closed, and all external data can only enter the blockchain through transactions. Oracle [41] is the gateway to the outside world for the blockchain, but it is not a specific program, but "a concept". Anything providing external data to the blockchain can be classified as an oracle. When a smart contract concerning extrinsic data is executed, the code then calls for the data from a trusted oracle. In Ethereum, the use of smart contracts uses transactions as the interface. Users deploy or call smart contracts by creating signed transactions, in which the address of the smart contract, the function to be called, and the parameters are written. The transactions are broadcast in the blockchain network, while it is verified. The smart contract is executed locally by the Miners, then the execution result is packaged into the block.

Merkle Tree
A Merkle tree is a hash binary tree, which consists of a root node, a set of intermediate nodes and a set of leaf nodes. The leaf node is the hash value of the stored data, the intermediate node is the hash value of its two child nodes, and the root node is also the hash value of its two child nodes. Any changes in the underlying data (leaf nodes) will be passed up to its parent node, and eventually to the root node. In Bitcoin [29], most nodes use SPV (Simplified Payment Verification) wallets to access the Bitcoin network. Merkle tree-based SPV can be used to verify transactions without storing complete blockchain data.
Users can use a small number of intermediate nodes to generate root nodes. As shown in Figure 1, if the user tries to verify data B, he only needs to obtain four blue intermediate nodes and generate the root node through four hash calculations, then compare the root node with the one in the blockchain. In this paper, we declare that the four blue intermediate nodes in the Merkle tree are the verification data of data B.

System Model
The system model of our proposed scheme is shown in Figure 2. In addition to the Miners that maintain the blockchain, the proposed blockchain-based, multi-level, location-secure-sharing scheme consists of three entities: LP, LD and Fnode. Any user, if they have sufficient computing and storage capacity, can also act as a Miner to maintain the blockchain to gain some benefits.
LP is the owner and the provider of location data. LP sets the number of access levels N and the accuracy r = {r 1 , r 2 , ..., r N } according to the demand of LDs. LD is the requester of location data. LD i denotes the LD with level ID i, i ∈ [0, N]; the larger the level ID, the lower the access level. LD k is allowed to determine that the LP is located in a circular area with radius r k , k ∈ [1, N]. LD 0 is allowed to obtain the exact location of LP. Before applying for LP's location data, LD calls the smart contract SC to record the license for location-sharing into the blockchain. The license contains the addresses (public-key) of LD and LP, and LD's level ID. LD uses the license to obtain the secret key k ud for location updates that LP or other LDs have received. Therefore, LD is not only the data requester, but also the provider. In addition, the license has timeliness. After the block where the license is recorded is mined, the license is only valid within a valid time. With the blockchain, LD can verify the received data.
Fnode verifies, reserves and provides LD the virtual location data from LP according to the valid license, which is similar to the queried network node mentioned in Section 8 of [30]. However, in our proposed scheme, only the root node of Merkle tree is recorded in the blockchain, not the data to be verified. Fnode can be a network node that intends to gain benefits and be honest but curious.
In our proposed scheme, the smart contract SC is designed to do two works: (1) Implement attribute-based access control. LD calls SC to record a license for location-sharing into the blockchain. (2) Establish an incentive and punishment mechanism. Ensure that nodes can work honestly in the network. We will specifically explain the work of (1) and (2) in Sections 4.3 and 4.4.

Our Proposed Scheme
Our proposed scheme consists of four phases, namely, initialization, location record, location sharing and location update. The following are detailed descriptions of each phase.

Initialization
We designed a new method to set the user's location information to multi-precision, specifically, stripping the location data into multi-level virtual location data and offset vectors. The purpose of this is to enable LDs with different access levels to obtain user location information with different precisions. The location offset vector is recorded into the blockchain in the location update phase, which is illustrated in Section 4.2.4. In the initialization phase, LP generates multi-level virtual location data and the secret key for location updates. The specific steps are as follows.
First, LP, who is new to the network, executes Algorithm 1, inputting the precision radius set {r 1 , r 2 , ..., r N }, to generate virtual location data {Z 0 , Z 1 , Z 2 , ..., Z N }, as shown in Figure 3. Z k denotes a circle area with P k as the center point and r k as the radius, k ∈ [1, N]. The virtual location data meet the following three conditions: (1) The radius length of the 1: In the Cartesian coordinates,randomly select a point Z 0 .; 2: In the circle with Z 0 as the center point and r 1 as the radius, randomly select a point P 1 ; 3: for i = 1; i ≤ N − 1; i + + do 4: In the circle with P i as the center point and r (i+1) −r i as the radius, randomly select a point P (i+1) ; 5: end for 6: for i = 1; i ≤ N; i + + do 7: Z i ← P i ||r i 8: end for 9: return Z 0 , Z 1 , Z 2 , ..., Z N ; Second, LP sends the encrypted virtual location data to Fnodes and the encrypted symmetric secret key k 1 ud for the 1st location update to LDs, which requests the location according to the valid licenses introduced in Section 4.1, the details are shown in Algorithm 2. Enc(), PK Fnode and PK LD denote asymmetric encryption function, the public-key of Fnode and the public-key of LD. After asymmetric encryption, the data are confidential, even if it is transmitted through an insecure channel. Algorithm 2 Initialization: pseudocode for sharing virtual location data and key k 1 ud Input: Virtual location data: Z = {Z 0 , Z 1 , ..., Z N }; The secret key for 1-th location update:

Location Record
In the location record phase, LP generates the location record Record LP and records it into the blockchain. The data recorded in the blockchain have immutability. Fnodes and LDs can verify the data received by the record Record LP ; the details are shown in Algorithm 2.
In lines 2-3 of Algorithm 3, LP generates the leaf nodes of the Merkle Tree, Hash() denotes the hash function. In line 4, LP builds the Merkle tree VerMer using the leaf notes, Mer() denotes the function to generate a Merkle tree using leaf nodes. In line 8, LP broadcasts Record LP containing the root node VerMer root of VerMer and the hash value of the secret key k 1 ud to Miners. Miners verify Record LP with LP's digital signature Sig LP , then record it into the blockchain through a consensus process, such as proof of work (POW). The consensus mechanism is not a focus of this paper; readers can refer to [15][16][17].

Location Sharing
In the location-sharing phase, LD n uses a valid license to apply for the virtual location Z n to a Fnode. If LD n has not obtained the secret key k p ud for location updates, LD n can use the valid license to apply it to LD m , who has already obtained it. Then, LD n uses the blockchain to verify the data received. The details are shown in Algorithm 3. In this phase, the data can be securely shared between Fnodes and LDs without the participation of LP.
In lines 2-3 of Algorithm 4, LD n sends the Request n containing Id License to a Fnode. Id License is the block number of the block where the license is recorded. In lines 5-7, Fnode sends the In f o F n containing the ciphertext of the virtual location data Z n and the verification data NODE n to LD n . NODE n is a set of the intermediate nodes in the Merkle tree, which is the verification data of data (n||Z n ), as introduced in Section 3.2. In lines 9-10, after checking the license, LD m sends the ciphertext of the secret key k p ud to LD n , p indicates that LP has updated its location for p − 1 times at this time. We describe how to update the secret key in Section 4.  Output: Bool varaiable: Accept LD n ; 1: LD n execute: 2: Request n ← PK LP ||n||Id License ||Sig LD n ; 3: LD n sends Request n to a Fnode and LD m ; 4: Fnode execute: 5: Loc n ← Enc(PK LD n , Z n ); 6: In f o F n ← Loc n ||NODE n ; 7: Fnode sends In f o F n to LD n ; 8: LD m execute: 9: In f o m n ← Enc(PK LD n , k p ud ); 10: LD m sends In f o m n to LD n ; 11: LD n execute: 12: initialize Accept LD n ← False; Accept LD n ← Ture; 25: end if 26: end if 27: end if 28: return Accept LD n ; In lines 13-14, LD n decrypts the ciphertext VE k in the record Udrec p LD , and updates Z n with the vector (∆x k ,∆y k ), D() and Udarea() denote the symmetric decryption function and the function to translate location data Z n using a vector, respectively. In lines 15-17, LD generates k p+1 ud and verifies it by checking whether the hash value of it is equal to KeyHash in Udrec p LD . Finally, LD n can confirm that LP is located in Z p n . LD n can translate Z p n into the geographic coordinate by Translate −1 (), which is the inverse function of Translate() in line 2.
In order to prevent users from cheating by sending fake locations, many location-proof schemes [42][43][44][45][46] have been proposed. They focus on using BlueTooth or Wi-Fi technology to verify the authenticity of the user's location point. Here, we can use the location-proof schemes to ensure the authenticity of VE in Udrec Accept LP n ← Ture 18: end if 19: return Accept LP n ;

License Record
As mentioned above, to enable LDs with different access levels to obtain user location information with different precisions, we designed a smart contract to implement attributebased access control. In this section, we illustrate how the smart contract SC implements attribute-based access control and records the license. We test SC on Remix Solidity IDE, a browser-based IDE that is frequently used to develop Ethereum smart contracts.
As shown in Figure 4, the work of SC here is mainly composed of two parts. (1) LP and LD, respectively, call SC to record LP's policy and LD's public attribute. If LP has a high-security requirement, LP can also record LD's public key as the public attribute and corresponding access level in the policy. However, this will reduce the efficiency of access control and increase the gas consumption of the smart contract. (2) LD calls SC for LP's location, where the input is the address (public-key) of LP. SC judges LD's level ID according to LP's policy and LD's public attribute, then records the license into the blockchain. In addition, LPs are allowed to call SC to modify the policy to change the access level of LDs. Note that if the policy is modified, LP must re-execute the initialization phase and location record phase for security before updating location, and LD also needs to obtain and verify the new virtual location data and the new secret key. The smart contract is publicly deployed in the blockchain by the initiator of the system. One can verify the authenticity of the license by checking which smart contract records it.
We simulate the process that LP and LD, respectively, call SC to record the policy and the public attributes, as shown in Figure 5. The policy indicates the access level of a certain type or specific LD to LP's location. We also simulate the process by which the LDs call SC for LP's location; the recorded license is shown in Figure 6.
There is still an unsolved problem of how to ensure the authenticity of LD's recorded public attribute. Our approach is that LDs are required to provide relevant proof to an authority who is authorized by the system. After authenticating the identity of the LD, the authority confirms the public attribute recorded by LD in the smart contract, then the attribute can be recognized. We can specify in the smart contract that some operations can only be executed by the authority, to easily implement the above method.

Incentive and Punishment
In addition to implementing attribute-based access control, in order to drive system users to work honestly, smart-contract SC is also designed to implement an incentive and punishment mechanism, which can be summarized into two parts. First, Fnodes can gain benefits from reserving and providing LPs' virtual location data for LD. Second, Fnodes verify LPs' virtual location data and report to the network, so as to ensure the authenticity of the location data. Honest Fnode obtains benefits; dishonest LP and Fnode should be punished. The specific method is as follows.
The schematic diagram of the mechanism is shown in Figure 7. When LP or LD, respectively, calls on SC to record policy or license into the blockchain, they must transfer a small fee E 1 into SC. E 1 s are distributed to Fnodes by SC to motivate them to complete their work. In addition to E 1 , LP must transfer a larger amount of the margin into SC. If Fnode verifies that LP's virtual location data are false, using the method mentioned in line 17 of Algorithm 3, Fnode calls SC to report LP. Within time T, if more than 50% of Fnodes report LP, the collective believes that LP provides false data, LP is dishonest and Fnodes reported that LP is honest. Additionally, LP's margin and the fine E 2 of the Fnodes that have not reported LPs will be confiscated and distributed to the Fnodes participating in the report. Within time T, if fewer than 50% of Fnodes report LP, the collective believes that LP is honest, and the Fnodes report that LP is dishonest. The fine E 3 of Fnodes participating in the report will be distributed to the Fnodes that have not reported LP, and the margin will be returned to LP. Note that the margin must be at least greater than the maximum cost of reporting LP, which will be discussed further in Section 5.5. In theory, the bigger the margin, the better.
Specifically, the smart contract records a service count variable Src and honesty reward variable Hr for each Fnode. Whenever a new policy is recorded by LP, Src will increase. We clearly illustrate the change in Fnode's Hr in reporting LP in Algorithm 6. Fnode can redeem incentives in the smart contract based on Src and Hr at any time. In addition, the smart contract records a timestamp Ti for LP and a variable Ih (the initial value is 1) that marks whether LP is honest. If, within time T, more than half of Fnodes report LP, Ih is 0, which means LP is dishonest. After time T, if Ih is 1, LP can withdraw the margin.

Algorithm 6
Pseudocode for the change in Fnode's Hr in reporting LP.

10: end if
In most practical application scenarios, such as epidemic case statistics and mobile phone application services, it is LP's obligation to provide real data, or the basis for an LP to obtain services. 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.

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.
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 LDs. 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 LDs. Figure 8a 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 8b where we use the OPE algorithm proposed in [37]. From Figure 8b 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 9a 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 9b shows that the computation overhead of Fnode increases linearly with N, and LD's processing time is about 0.004 s.

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 10a 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 10b 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.

Computation Overhead of the Location Update Phase
In the location update phase, a location update record Udrec p LP is generated by LP and recorded into the blockchain by Miners to make LDs update the LP's location. We set N = 10 and evaluate the computation overhead of LP and LD, respectively. Figure 11 shows that the computation overhead of LP and LD in our proposed scheme is much lower than that of LP and LD in BMPLS. The computation overhead of LP and LD in our proposed scheme is about 9.76% and 0.22% of that in BMPLS, respectively. The reason is that the location-record phase and the location-sharing phase need to be executed again when the LP updates location in BMPLS. We evaluate the computation overhead of LP completing all the work with different location update times. Figure 12 shows that the computation overhead in our proposed scheme is significantly lower than that in BMPLS, which is more obvious as the times of location update increase.

Gas Cost of Smart Contract SC
SC is designed to implement attribute-based access control and establish an incentive and punishment mechanism, as introduced in Sections 4.3 and 4.4. First, the gas cost of deploying SC to the blockchain is 1,014,599 gas. The gas cost of LD recording the public attribute and the authority confirming it is 44,394 and 42,953 gas, respectively. The gas cost of LP recording policy depends on the size of the policy, as shown in Figure 13. This is the gas cost of the first time that LD and LP record attribute and policy, and the gas cost of modifying is much cheaper. For example, the gas cost of LP modifying the attribute to the same one is 19,429 gas. The gas cost of SC recording license is 26,382 gas. The gas cost of a Fnode reporting LP is 49,127 gas.
We noticed that Fnode reporting LP costs 49,127 gas in Ethereum. This means about $12 at present. This means the margin of LP must be greater than the product (maximum gas cost possible) of $12 and the number of Fnodes, which would be a large amount. This may result in our proposed scheme not being put into practice. For this reason, we propose two methods to solve this problem. (1) Fnode does not report LP in the smart contract, but reports to the authority. The authority records the report result (whether LP provides real data) and the dishonest Fnodes in the smart contract. In this way, the report in the smart contract is executed only once by the authority. The gas cost of the authority recording increases with the number of dishonest Fnodes, as shown in Figure 14. In theory, the margin needs to be greater than the product (maximum gas cost possible) of $1.6 and half of the number of Fnodes, which is much lower than before. (2) We used the Ethereum test network discussed above to evaluate the gas cost of the smart contract. Ethereum is one of the hottest blockchain projects, and the cost of the smart contract is high. It is not necessary to use Ethereum in practice. In some cases, system initiators can even create a private chain or alliance chain to implement our proposed scheme, which costs much less. However this is not the focus of this paper.

Performance of Our Proposed Scheme
In this section, we theoretically analyze the performance of our proposed scheme and prove that, when compared with other related works, our proposed scheme has better performance overall. Specifically, our proposed scheme has the following properties.

Multi-Level Location Privacy Protection and Verifiability
Information security is crucial, but different for the provider and the demander, in an information-sharing process. The provider hopes that data can be shared within the scope of their permission so that privacy can be fully protected, while the requester hopes to verify the authenticity and integrity of the data received.
Multi-level location privacy protection is implemented in our proposed scheme. Fnode sends virtual location data with different accuracy to LD with different access levels. LD cannot illegally obtain location information with higher accuracy. The virtual location data cannot be used to infer the location of LP, so that Fnode knows nothing about LP's location. Further, because of the key update method, as shown in line 6 of Algorithm 5, our proposed scheme has forward security, and the new LD cannot grasp LP's historical location information.
The integrity and authenticity of location data can be verified in our proposed scheme. Because of hash function's collision resistance, LD uses hash value and the root node of the Merkle tree to verify the integrity of location data, as shown in lines 15-23 of Algorithm 4. Fnode verifies the authenticity of virtual location data for LD as shown in lines 12-16 of Algorithm 3. The incentive and punishment mechanism is used to drive users work honestly.

Robust
Only a robust location-sharing scheme can be used in some complex environments, such as medical care, epidemic prevention, IoT device management, etc. We demonstrate that our proposed scheme is robust in two aspects. (1) The robustness of our scheme depends on the robustness of blockchain technology, which is essentially based on the robustness of the consensus mechanism. We choose the common consensus mechanism, POW, which is secure when more than 50% of computation power is held in honest nodes.
(2) In our proposed scheme, within the valid time of the license recorded in the blockchain, LD can obtain the virtual location data and the secret key for location updates from Fnode and the LD, respectively, that obtained the key, even if the LP is offline. In BMPLS, if LP is offline for some reason, no LD can obtain LP's location information although its identity is legal, which is unacceptable in some complex environments.

Immutability
Each block in the blockchain, except the genesis block, has a hash pointer that points to the previous block. When there is any change in the parent block, its hash value will change, which forces the "parent block hash value" of the child block to change, resulting in a change in the child block and its hash value. When we use POW as the consensus mechanism, the adversaries need to control at least 51% of the computation power to be able to tamper with the blockchain, the probability of which is negligible. Therefore, the data recorded on the blockchain cannot be tampered with.

Confidentiality
LP records Record LP and Udrec p LD into the blockchain. Record LP contains the root node of VerMer and the hash value of the secret key k 1 ud . Udrec p LD contains the ciphertext VE and the hash value of the secret key k p ud . First, due to the hash function's hiding property, the hash values can not reveal any information. Second, as long as the secret key is kept secret, VE cannot be decrypted by the adversaries. Therefore, although the blockchain is open to all users in the network, adversaries cannot recover LP's location data from the blockchain.

Decentralization
In the blockchain network, no node is in the central position or has full control and management authority over the blockchain. All nodes store the same blockchain data, which can be freely accessed by users. In addition, we use a smart contract to implement the decentralization of the access control process.

Low Computing Cost
LPs that provide location data are often mobile phones or IoT devices that do not have strong computing power. Therefore, the computation overhead in the location sharing scheme must be low. Compared with the related work BMLPS, the computing cost of our proposed scheme is significantly lower, which is proved by the experimental results in Section 5.

Flexibility
Our proposed scheme is flexible, which stems from two aspects: (1) In our proposed scheme, LP freely sets the accuracy of the location information obtained by LDs with different access levels, which cannot be realized in BMPLS due to using the quad-tree function to partition the region.
(2) Access control should be flexible to be adapted to different contexts. In our proposed scheme, LP can call the smart contract to record policy to flexibly set the access levels of LDs.

Acceptable Gas Cost
In our proposed scheme, the gas costs of the smart contract are acceptable, as shown in Section 5.5. However, frequent modifications to the policy of LP and the public attribute of LD, and Fnode frequently verifying data and reporting LP, will bring extra-high gas costs. This situation needs to be avoided. In essence, the more stable the public attribute of LD, the better. The addition of new LDs should also be controlled.

Conclusions
In our proposed scheme, we replaced the central database with a blockchain in the location sharing. The decentralization and immutability of the blockchain make our proposed scheme applicable to a system composed of peer nodes without a central server. Protecting user location privacy and verifiable location data is our focus. We use the multi-level setting of location data and effective access control to realize the former. To this end, we strip the location data into multi-level virtual location data and offset vectors, and design smart contract SC to implement attribute-based access control. The incentive and punishment mechanism established by SC can drive users in the network to work honestly. Besides these, we use hash algorithms, Merkle tree and the immutability of blockchain to achieve data verifiability. The results of the experimental evaluation and theoretical analysis show that our proposed scheme is more efficient and secure than the existing works. Smart contracts are not used in related schemes [32,34,35]. In our proposed scheme, the smart contract brings extra gas costs. However, we believe that the gas cost is acceptable when the above properties are achieved.
An increasing number of resources scattered in the network are willing to provide data storage services, which can be seen from the development of technologies such as BT, PT and IPFS in recent years. This type of technology can integrate the resources scattered in different places and work like a cloud server. The main limitation of our proposed scheme is that Fnode must not collude with LD. Fnode, in this paper, can be an node from a BT private network or a DHT network like [32], and it can freely choose whether to provide services for benefit. It is "honest but curious", similar to a cloud data service provider, but much cheaper. In other words, it will not betray the data owner and illegally share information with others. However, it should be prevented from prying into the privacy of the data owner. The system should choose as trustworthy a Fnodes as possible, such as those whose social credibility is high.
How to improve the query efficiency in our proposed scheme is a problem that we can continue to study in the future. For LDs, maintaining the blockchain is not their original purpose. They tend to be light nodes rather than full nodes, that is, they will not reserve complete blockchain data. Therefore, they query the corresponding blockchain data through other full nodes, similar to SPV-based queries in the bitcoin [29]. It is meaningful to improve the efficiency of this indirect query.