key: cord-223669-hs5pfg4b
authors: Song, Jinyue; Gu, Tianbo; Feng, Xiaotao; Ge, Yunjie; Mohapatra, Prasant
title: Blockchain Meets COVID-19: A Framework for Contact Information Sharing and Risk Notification System
date: 2020-07-20
journal: nan
DOI: nan
sha: 
doc_id: 223669
cord_uid: hs5pfg4b

COVID-19 causes a global epidemic infection, which is the most severe infection disaster in human history. In the absence of particular medication and vaccines, tracing and isolating the source of infection is the best option to slow the spread of the virus and reduce infection and death rates among the population. There are three main obstacles in the process of tracing the infection: 1) Patient's electronic health record is stored in a traditional centralized database that could be stolen and tampered with the infection data, 2) The confidential personal identity of the infected user may be revealed to a third party or organization, 3) Existing infection tracing systems do not trace infections from multiple dimensions. Either the system is location-based or individual-based tracing. In this work, we propose a global COVID-19 information sharing system that utilizes the Blockchain, Smart Contract, and Bluetooth technologies. The proposed system unifies location-based and Bluetooth-based contact tracing services into the Blockchain platform, where the automatically executed smart contracts are deployed so that users can get consistent and non-tamperable virus trails. The anonymous functionality provided by the Blockchain and Bluetooth technology protects the user's identity privacy. With our proposed analysis formula for estimating the probability of infection, users can take measures to protect themselves in advance. We also implement a prototype system to demonstrate the feasibility and effectiveness of our approach.

Until today, coronavirus has infected more than 11.5 million people and caused nearly 530,000 deaths [3] . In particular, the United States has become the country with the largest number of known infections [4] . Every country has its own privacy policy to share information about infected people. It is challenging to share information across the world with reliable privacy protection since different countries have their own privacy policy to share the information of infected people.

Information sharing in a centralized manner, such as MIT, Apple, and Google who announced their tracking solutions by storing users' personal data in cloud [1] [2] , is highly relying on users' trust. Once the personal data has been uploading to the cloud, users generally cannot control the potential abuse. If a comprehensive data security solution is missing, the private user data in the cloud may be hacked for any other harmful purposes. As a global organization, the World Health Organization (WHO) collaborates with the governments around the world to share information and enhance the management of epidemic prevention. However, WHO is losing trust from some countries and cannot obtain sufficient support. Some other governments may conceal, falsely report, or hinder from reporting epidemic information. These may create a gaping security hole for global epidemic prevention. To this end, there is no way for individuals to share their information and protect their data privacy simultaneously. Government departments and organizations may access the health medical data of all people, and go beyond the scope of their responsibility and duty. For example, some government health departments may locate the personal identity of infected patients, and then enforce them in a centralized isolation shelter, resulting in secondary infections, and restricting personal freedom. Actually, Apple and Google will share the infected individuals' information with health authorities [2] , which means people's personal data privacy and human rights are being violated without their knowledge.

Currently, there are two separate tracing systems existing: location-based and individual-based contact tracing. Locationbased contact tracing always provides a centralized service and records if there are infections in the given locations without the knowledge of infection movement [5] . The individual-based tracing systems only focus on the person-to-person contact via Bluetooth [1] [2] , and they do not have a record about where users get infected. WHO states that the virus could survive on materials surfaces [6] [7] , so the virus has an effect on the people daily activity environment. But the individual-based system cannot trace and estimate the COVID-19 effect on the given location. Our proposed system combines the locationbased and individual-based systems together for users to access the public area infection status and lookup personal contact tracing history at the same time. Our lab already deploys the centralized location-based tracing system [5] and we may merge our two systems together for a future research.

Blockchain can natively provide the decentralized service to share the information and protect the privacy of people [8] . User information can be packaged in transactions and stored in the blockchain in each computing node. Even if the data of one node is manipulated, it will not affect the data's consistency because the manipulated data will not pass the verification by other nodes. A smart contract is a program that runs on the blockchain platform; it can execute instructions in a distributed manner, and maintain output consistency. In our system, the smart contract allows the user to check-in at each location and query the blockchain database for the location infection status.

Even though MIT, Apple, and Google provide virus contact tracking solutions, the tracking service still brings the following new challenges. The infection transmission factors considered by current existing virus tracking service systems are too simple. The virus is not only carried by the infected person but also remains in the environment, so the user will still be infected by the virus attached to the object surface. Therefore, our proposed system not only records the user's contact history but also tracks the user's travel trajectory.

Protecting user data privacy about his personal health information in a public network is also very challenging. Traditional methods of hiding users' personal information, such as removing names, addresses, and social security numbers, cannot fully protect user privacy. So we embedded the function of Bluetooth randomization address in the contact tracking service of the system. Besides, after users uploading health data and identity information, they lose the ownership and the ability to control the data. Apple and Google provide anonymous services to users, but the infected patients will be reported to the government health department [2] . We choose the blockchain database as the storage method for the system, combined with the address randomization function of Bluetooth, only users can identify and verify their health data and personal information stored in the database.

We design and propose a blockchain-based Covid-19 contact information sharing and risk notification system that can be used by the world to take preventive measures against epidemics. This system implements the following main functions with smart contracts and Bluetooth embedded: (1) Users can record their visited location information and personal contact history to the blockchain database. (2) Users can update their infection status. (3) The system can update location infection status. (4) The system can notify the users that had been exposed the infected people or infected locations before. (5) The system can estimate the probability of being infected for users based on his location visiting history and personal contacting records. For example, a shopping mall can use our system to detect if this building is infected and the daily infection status. The customers can also query the database to gain the mall infection record before their shopping. The status of an individual is written to the blockchain and cannot be changed.

Our system is able to protect privacy. We consider a variety of privacy that can be protected by our system. Users can regularly change their cellphone Bluetooth mac addresses and encode these addresses to virtual IDs. Then, it is hard to trace individual identity from their public information written in the blockchain. Our system will not trace personal identity or report personal health information to authorities.

We have the following contributions.

• We propose a hierarchical smart contract group in this system, to manage the infection status of each location and transportation. This design reduces the average operation cost and request processing time in the system.

• We build and merge location-based and individual person based virus contact tracing and notification system, which tracks the virus infection activity from higher dimensions. • We embed a blockchain database in the system to ensure the safety of users' data and this design avoids the problem that health information may be tampered and stolen in a centralized database. • Our system uses a weak random Bluetooth address design to generate the user's identity information. This design not only protects the user's privacy but also reduces the congestion of data transmission within the blockchain network. • We propose a mathematical formula for the possibility of user infection, which quantifies the user's contact history and traveling history from multiple dimensions and thus provides a basis for the system's notification service. • We propose an optimal equation for the operating costs of the system, simulate person-to-person contact and user check-in activities in our system, and evaluate the system performance based on the different quantity of users and smart contracts. Roadmap: This paper is organized as the following sections: Section II presents the system overview and system components. Section III formulize challenging problems for our system. Section IV describes the system design from the perspective of four layers. Section V shows how we simulate and evaluate system performance. The last two sections VI and VII present the related work in smart contract tracing and conclusion for this paper.

Our system can track the locations visited by users and the personal contact history of users with others. When a user updates himself infected, our system will notify other users who have been in direct or indirect contact with him, and provide an assessment of the probability of infection.

In a general scenario, the user may visit many public places, such as offices, restaurants, shopping centers, or gyms in one day, so he can use the designed contact tracing service to upload his visiting records including the time and location to our system. Then, our system will store the visiting records in decentralized blockchain databases. Also, users can check the infection status of a certain location before his visit to ensure safety.

When a user reports that his infected status, a smart contract group embedded in our system will update the virus infection status of the locations and transportation that the user visited and took based on his visiting records.

Our system helps users to track the history of their indirect contact with others because the virus can land on the surfaces of the objects and continue to remain active [9] , and even if the user does not have face-to-face contact with an infected patient, there is still a possibility of being infected after he touches the surface of the virus-contaminated object.

Our system uses the Bluetooth functionality in users' mobile devices to automatically detect the others and then upload their contact records to decentralized blockchain databases. The range of Bluetooth detection is relatively small, which is about 5 to 10 meters [10] . So, when the user's mobile phone detects the Bluetooth signals, it indicates that there are people nearby.

When a user reports himself as infected status, our system will broadcast his infection status and alert other users to check if they have close contact with this infected user.

It is important to trace the direct contact recorded by Bluetooth because viruses can attach to water vapor and spread through the airborne [11] , and users may be infected by other people in a close range [12] . Therefore, uploading users contact history records will help them to track the infection transmission path of the virus and assess users' probability of being infected.

Our proposed system provides users with this integrated mobile service, which contains the following functionalities: Probability of infection: According to the manual for WTO medical staff [13] [6] , healthy people could be infected directly and indirectly, where the direct factor is person-toperson contact in a close distance and the indirect factor is that the virus surviving on the surface of the object spread by the patient infects the healthy people after they touch the surface. So the system will evaluate the user's risk from these factors based on the feature data extracted from location tracing and person-to-person contact tracing, like, the length of contact time between users, the spatial distance between users, and the materials of objects in public places.

Notification of infection: After the estimation of infection probability for this user, the notification function sends a warning alert to him, which reminds him to prepare for virus infection in advance or to seek medical help, before his health condition gets worse. Another scenario is when a user reports his infected status, our system will broadcast his virtual identity to other users. Then, these users who receive the notification will query the local database to see if he has had any direct or indirect contact with the infected patient and calculate the infection probability.

In our system, three main technologies guarantee data security and personal privacy: decentralized database in the blockchain, automatic execution of smart contracts, and randomization of Bluetooth mac addresses.

(a) Data Security: Our design guarantees that user data will not be manipulated. The blockchain protocol stipulates that the current block will always use the hash value generated from the previous block, so if an attacker manipulates a transaction in a block, he must tamper with all the previous blocks data to ensure his tampering, before the next new block to be mined, verified and accepted by other users. This computing workload is extremely large, so it is almost impossible for an attacker to forcibly manipulate the blockchain data. Moreover, users in the network can detect violations of smart contracts, and such attempts to violate the contract are verified to be invalid and those malicious transactions will not be stored in the blockchain.

Our system contains a smart contract group to handle all user check-in requests for public locations and transportation. Since smart contracts have the properties of being unmodifiable, requiring no supervision, and being automatically executed, smart contracts with distributed features ensure that user data cannot be tampered with, or produce malicious results. So, this design ensures the security of user data.

Decentralized blockchain databases and smart contracts also enhance the usability of our system. Since no individual or centralized entity can control all data, there will be no smart contract or system crash due to malicious operations done by some users.

(b) Identity Privacy: We use Bluetooth technology to protect user data privacy. The mac addresses uploaded by users are randomly generated by the Bluetooth protocol [14] . Although these addresses are stored in the blockchain database, each user's mac address is random and is not fixedly bound to the mobile device. It guarantees that users will not be tracked and located by the addresses provided in the network. From another perspective, Bluetooth technology frequently replaces the user's mac address [15] , which means a user will gradually use multiple different mac addresses in a unit of time. Other people in the surroundings have no way to associate the mac address to this user through investigation. The frequent randomized mac address protects the user's privacy in real life.

In order to reduce the operating overhead and internet congestion at the system level, we choose weak randomized generation of Bluetooth mac address. Users upload their random mac addresses to the system, which is measured by Ethereum gas [8] in the system overheads. The larger quantity of random mac addresses, the better privacy protection users could have. But the larger quantity will lead to higher operating costs and network congestion. Therefore, we need to find a balance between a sufficiently large quantity of Bluetooth random addresses for privacy protection, and a relatively small quantity for lower system operating cost.

We highlight four problems: latency, throughput, operating cost, and probability estimation for our proposed COVID-19 information sharing and risk notification system and these problems are described by mathematical formulas at a highlevel.

In our system, latency is a time difference ∆t about how long the user's latest check-in request can be processed completely by smart contracts and stored in the databases. We consider that latency is affected by the following five factors: 1. the number of users |U| in the system, 2. the frequency Freq of users sending requests, 3. the size of one block |B|, 4. the height of the smart contract group SCG.height, and 5. the length of the waiting queue |Queue| of the smart contract. U includes not only users already exist in the system, but also new users who enter the system within a unit time. The total number of users and the frequency Freq of user's check-in determine the total number of user requests per unit time in the system. If the number of user check-in requests exceeds the processing capacity of the smart contract per unit time, the user's requests will enter the waiting queue of the smart contract, which increases the request processing time. We introduce the variable of block size |B|, because it is one of the bottlenecks of the blockchain's development towards high throughput and low latency [16] . The height of the smart contract group SCG.height and the length of the queue |Queue| in each contract are also important factors that affect latency. In our proposed hierarchical structure, the smart contracts at the same level will not affect the efficiency of processing requests between each other. The requests received by the smart contracts at the current level are all from the higher-level smart contracts, so the hierarchical structure we propose is a tree structure, whose height is described as lg(|SCG|). As mentioned before, the smart contract will put the requests that have not been processed in time in the waiting queue. If the number of unprocessed requests is greater than the length of the queue, these requests will be abandoned. Then the smart contract needs to wait for other nodes to synchronize the transaction operations and data. This brings a longer latency. We thus establish the latency formula:

where we have a series of transition functions δs provided to determine the latency, latency = φ(δ U,Freq , δ |B| , δ SCG.height,|Queue| ). We propose that the three polynomial δs are combined by function φ.

In our system, throughput TP refers to the number of user requests that the system can completely handle in a unit time. It can intuitively show the system's ability to process user requests. The greater the throughput, the stronger the processing capacity of the system. Throughput is limited by latency, packet loss rate Rate PL and bandwidth BW. As described in the previous section, five factors in the system can affect the latency, but the Rate PL and BW depends on the network conditions at the user end. Therefore, the throughput can be defined as follows:

where θ is the transition function with three arguments to determine the TP.

Operating cost is another important problem we consider. Reasonable operating costs determine that our system can serve users stably, and support its operation for a long time.

The operating cost in the system is measured by the Ethereum gas [8] , which includes the following five influencing factors: location-based and Bluetooth-based contact tracing services, Health tracing service, the setup and operation of smart contracts. We will explain all these services and components in the next section. Since the blockchain decentralized structure, users can query their local blockchain database without consuming gas and we do not include the cost of the database in the operating cost calculation. We consider the number of users and requests have a polynomial relationship with the cost of three tracing services. The setup cost of a smart contract is fixed, but its operating costs will increase with the increase of users. So we have the following cost formula:

where Loc represents location-based contact tracing service, Bt represents Bluetooth-based contact tracing service, Heal represents health tracing service, and Op represents all the operations in the smart contracts like adding a user checkin and getting a location infection status. We define λ to be the transition function to calculate the cost combined by the four factors. Then, we measure the average and variance values of the operating cost, which represent the system's stability in an optimal condition. Here are the formulas when the system has five factors at minimal cost:

args var = arg min var(λ(Loc, Bt, Heal, Setup, Op)) (4) args avg = arg min avg(λ(Loc, Bt, Heal, Setup, Op)) (5) Therefore, we can provide the optimal arguments with a minimal system cost, which is shown as:

args optimal = minCost(args var , args avg , ζ)

where we introduce penalty function ζ to adjust five arguments and get the global optimal sets for the cost calculation.

In the previous section, we briefly describe the functionality of estimating the infection probability in the health tracing service. Since the ground truth data contains only binary values representing infected or not, without a percentage value for the probability of infection, we introduce the statistical logistic regression analysis method with iteratively reweighted least squares (IRLS) [17] to maximum likelihood estimation and find the optimal arguments.

We assume that the data set is relatively clean and there are no outstanding outliers. Ground truth dataset contains n user data points (x i , y i ), i = 1, ..., n, where x i is the independent variable tuple with (RSSI, ∆t B , ∆t C and ms) and y i is the dependent variable with binary values {0, 1}. We conclude five elements in the tuple affecting the infection probability:

• RSSI is the received (Bluetooth) signal strength index, which represents the distance between users [18] . • ∆t B is Bluetooth contact time interval, which indicates how long users detect each other's Bluetooth signal from a short distance. • ∆t C is a overlapping time calculated based on two checkin time points t i and t j , which infers the time when two users enter the location, and ∆t C = |t it j |. • ms is a discrete value in set MS representing a virus residual active time period on a material surface [9] . So we have:

where β is the set of parameters {β 0 , β 1 , ..., β 4 } for these five arguments including the constant. Then, we can use the estimation method IRLS to get the fitted model and arguments:

args optimal [w] = IRLS(X, Y, w, µ)

where w is arguments tuple (RSSI, ∆t B , ∆t C , ms) and µ is the predicated value from formula (7).

In this section, we will define and explain our system components from the perspective of the four layers in the system, and the interactions within the contact tracing mechanisms.

Our trace and notification system contains four layers for users to trace person-to-person contact via Bluetooth, check-in locations, and lookup infection status with other users on the blockchain platform. Fig. 1 shows four layers: User Interaction Layer, Mobile Service Layer, Smart Contract Service Layer, and Data Storage Layer. This system provides two primary services for trace and notification: Bluetooth-based personal contact trace service and location-based contact trace service. Both of the two services are developed on the blockchain platform, and the data generated from these two services is stored in the distributed blockchain databases. The locationbased contact trace is coordinated by the smart contracts in the third layer and the Bluetooth-based contact trace is handled in the second layer. (a) User Interaction Layer At the user interaction layer, we have two entities: user U and location L. Users are people who hold Bluetooth-enabled mobile phones and have two health statue types: healthy users U normal and infected users U infected . Users access to Mobile Service in the second layer and update their health status in the system based on their medical reports. We assume that users always honestly upload their infection status to our system.

A location L is a public place or transportation that users often visit in their daily lives, such as office, restaurant, stadium, bus, and even airplane. Location L also has two status types, uninfected location L normal and infected location L infected . If an infected user U infected visited this location, then this location L would be marked as L infected by the system.

(b) Mobile Service Layer Mobile Service Layer is the the core handler in our system and it interacts directly with the other three layers.

Mobile Service MS is our proposed mobile phone application in this layer. Cooperating with other layers, the Mobile Service layer is an interface layer for providing users with services, including the following two aspects: contact tracing service based on Bluetooth or location, and health tracing service supported by data provided from the blockchain database.

Contact tracing services include location-based and Bluetooth-based, focusing on indirect and direct contact between users. The Bluetooth-based service is an integral part of the client's mobile phone service which embeds the Bluetooth function. It can sniff other surrounding users' Bluetooth devices, and broadcast its own Bluetooth random mac address MacAddr as a virtual identity. This Bluetooth-based service can exchange its user randomized mac address with other users via Bluetooth, and then packet received other users' mac addresses MacAddrs, time interval TimeInterval of the interaction and received signal strength index RSSI into the transaction Tx, which is broadcast to the blockchain network. In addition, when the user receives other's infection notification from the broadcast transaction Tx, our mobile APP will automatically query the local blockchain database for the infected user's Bluetooth address, check-in information, and check whether the infected user has a direct or indirect contact with current user.

The second contact tracing service is the location-based tracing. It accepts the user check-in requests Req checkin s from the User Interaction Layer and it coordinates these requests to different smart contracts in the third layer based on the sender's location. At the same time, the infection status of this location L is affected by the user's check-in request Req checkin . If the user U updates the health status as infected U infected and broadcasts it to the smart contract, the location L will be marked as infected L infected by this corresponding smart contract. These two services will be explained step by step in detail and described in mathematical formulas in the next two sections.

Health tracing service is the third sub-service in Mobile Service Layer. This service has two functions: 1. Broadcast user's infected status U infected to alert other users and update the infected status for the locations Ls where the infected user visited. 2. Estimate the probability of being infected for users Prob U (Infection).

Users Us at the first layer can update their health status through this service at the second layer, packet their health status {U normal , U infected } in a transaction Tx and send it to the smart contract responsible for the infection status at the third layer and broadcast it to other users on the network. Once the health status of the infected person has been updated as U infected , people who had contact with the infected person will be prompted with a warning alert provided by this health tracing service.

After the normal user U normal receives the warning alert, this health tracking service estimates the probability of the user being infected Prob U (Infection), based on the data collected from location-based and Bluetooth-based tracing services contact regarding the infected person U infected . We consider there is a relationship between received (Bluetooth) signal strength index RSSI and infection probability P (inf ection) with COVID-19. Similar to Apple and Google's design [2] , we use the Bluetooth sniff to detect if two users are in a close distance D, which can be measured by the Received Signal Strength Indication (RSSI) of Bluetooth [18] and the author uses Low Pass Filter (LP F ) to reduce the errors in the measurement data. To describe the content of the article without repeating, we only quote the method based on the Bluetooth signal strength index. In the following section, we will use the simplified Mathematical formulas including LP F by default to reduce errors in measured data as designed. Research and experiments made by MIT show the COVID-19 can spread by airbone [11] , which can reach 26 feet away by a sneeze [12] . So, the closer the user is to the infected person, the easier he is to be exposed to more viruses and become easier to be infected. Therefore, we correlate the strength of the Bluetooth signal strength with the possibility of being infected by a virus.

(c) Smart Contract Service Layer The smart contract service layer is the secondary core of our system. The check-in request Req checkin generated by the user's visiting location L is processed by the Mobile Service Layer and forwarded to this Smart Contract Service Layer, where it is managed by the smart contract group.

The smart contract group integrates the contracts according to the administrative hierarchy system. The top level is the smart contract at the state level Contract state , followed by the county Contract county , then the city Contract city , and finally the smallest unit location Contract location . Location smart contracts Contract location belong to the city-level contracts Contract city to manage, city-level contracts belong to counties Contract county , and county-level contracts belong to states Contract state . Each contract will only inherit from one superior contract, and will not belong to two different superior contracts at the same time.

Each location must be in one of these three states: {EmptyStatus, InfectedStatus, CleanStatus}, and the corresponding smart contract Contract location dynamically records the infection status of the location L. If an infected user U infected visits this location L, or a user who has visited this location, reports that he is infected, then this location L is considered infected by this user U infected . Only after the location is cleaned, or 14 days after being infected, the location L is considered to be in a CleanStatus.

In order to save the operating cost of the smart contract Contract location and maintain the accuracy of the location L status record, the coming requests Reqs trigger the smart contract Contract location to check and update the infection status for the location L, otherwise the smart contract Contract location will not actively check the infection status of the location L. This design ensures that users can get the latest location status for their requests while avoiding the operations of the smart contract.

(d) Data Storage Layer We have deployed a distributed blockchain database DB in the data storage layer, and every user and computing node can be synchronized in our network to get a complete database, which is consistent with the data of others. From the perspective of data storage, the traditional centralized database stores all data [19] in one data center; the traditional distributed database stores data in multiple data centers, but each center may not have global complete data [20] . From the data management perspective, traditional databases require a central node to process read and write requests to the database, but a blockchain database does not require a central node to process read and write requests [21] [22] because all users can have the same database locally, to directly query for consistent results.

In our system, the blockchain database will store all transactions in the network, including users' Bluetooth contact records, check-in information of the visited locations, and the change of the user's public health status. The three tracing services mentioned above, location-based contact tracing, Bluetooth-based contact tracing, and health tracing services, except location-based contact tracing requiring smart contracts to update and store infection status to the database, in the other two services, users can query the blockchain database directly for personal contacts and visiting records.

Current Bitcoin and Ethereum blockchain database design have problems such as high computational cost, and slow writing and querying data [22] , but there are existing thirdgeneration blockchain databases now whose performance, such as throughput, can be comparable to databases of VISA credit card companies [23] [24] . Since the third-generation blockchain database has no mature commercial development and lacks a mature platform to support the development of smart contracts, we still deploy our system on the Ethereum platform for simulation and evaluation.

In this section, we describe the location-based contact tracing service in detail: first, we show entities participating in the service, such as users, smart contracts, and locations; and then, we introduce the interaction activities between entities, including user's check-in a place while his visiting and the user's query of the infection status of a place before visiting.

As defined in previous sections, we have location L, which represents a public place or transportation, users U with normal and infected status and smart contracts, who are in a hierarchy structure to process all users' check-in requests.

In Figure 2 , we illustrate location-based contact tracing service with a simplified state machine.

{Q, δ, InitialState, CleanStatus}

where we have

InfectedUserCheckin, InfectedUserUpdate, LocationisCleaned, Wait14Days} • InitialState is the Null state before the smart contract exists • CleanStatus is the accepting state First, when a user issues a check-in request Req checkin through the location-based contact service at the second layer, the system checks whether there is a smart contract Contract location corresponding to this location at the third layer. If the contract does not exist, the smart contract of the city Contract city where the location is located will create a smart contract Contract location for the location. If the contract already exists, the system goes to the next step to process the user's check-in request. In case the coming user is infected, this location enters the next state InfectedStatus, otherwise, it enters the CleanStatus. Then, when the location is in a state InfectedStatus, either after 14 days or if it can be cleaned and disinfected, this location can transform to CleanStatus. Finally, in the state CleanStatus, this location is affected by the request of the next user. If the next user is infected U infected , or his past visit is updated to be infected, then this location will return to the previous state InfectedStatus. Otherwise, it remains in the current CleanStatus. Fig. 3 is an example of user U checking in a building in location-based contact tracing service. The check-in information about this user visiting the building, like timestamp T, geographic position GeoPos and health status {U normal , U infected }, is packaged in a transaction Tx with the help of our proposed mobile client app in the second layer. Then, the app sends the transaction Tx to the smart contract group in the third layer. According to the address of the building GeoPos, this transaction Tx is passed from the state-level Contract state to the county-level Contract county , to the city-level Contract city , and finally transferred to the smart contract Contract location corresponding to this building. Then, based on the health status U infected for example, provided by the user, the location smart contract changes the infection status to L infected for the building. In this process, the transaction Tx that records the user's check-in information will be saved by the blockchain database DB.

Also, the location-based contact tracing service can help the user to get the infection status record of the location L. We need to discuss two scenarios based on whether the user has the Contract location network address locally corresponding to the building for example. If the user has checked in this location before or has previously queried the smart contract of this location, the corresponding Contract location address should exist in his mobile APP. Therefore, the user can directly send a request to the Contract location network address through the mobile APP to get the location infection status. If the user is interacting with this location for the first time, then he needs to get the contract network address first. With the provided the geographic position GeoPos of this location, the user's mobile APP will query the statelevel Contract state in the smart contract group, who will transfer this query request from the top level to the city-level Contract city based on the provided GeoPos. If there is a corresponding Contract location for this location, the network address of this contract will be returned to the user. Otherwise, the city-level smart contract Contract city will create a new Contract location , and its address will be returned to the user.

After receiving the location infection records from Smart Contract Service Layer, the request sender can verify the response by querying his local blockchain database for the transaction record. If the infection exists in this location L infected , our proposed mobile APP will alert the user.

To encourage users to use mobile services more frequently, we have developed a check-in and query incentive mechanism for users. Whenever a user checks in a location or queries the corresponding location smart contract, this smart contract will return a slightly more amount of transaction fee to encourage the user to check-in or query more often. The additional fee given to the user is to support the user to use mobile services to broadcast his transaction that contains the Bluetooth contact data, check-in information, and update health status.

Bluetooth-based contact tracing involves all entities except the smart contract group and all layers except Smart Contract Service Layer. The mobile APP on the second layer packs the Bluetooth contact data in the transactions, broadcasts them on the blockchain network, and saves all of them in the blockchain database. Similarly, the mobile APP processes realtime transactions received about the senders' health status, matches user contact records and reminds users of the danger of contact with infected persons. In the transaction, we will record four elements: a period of users detecting each other ∆t B , the detected mac addresses MacAddress, mobile phone model AppleInc for example, and the received signal strength index RSSI. Fig.1 overviews the workflow of Bluetooth-based contact tracing. It helps users from the first layer to exchange randomized mac addresses with each other, and then packet the data with a timestamp and received (Bluetooth) signal strength index RSSI in the transaction, which is sent to the blockchain database in the Data Storage Layer. The signal strength of different Bluetooth devices will be different, so we assume that users are using the same type of Apple mobile phone, which provides assumption conditions for the next section to calculate the distance between two users through signal strength. Except that, this Bluetooth-based service will alert users when receiving transactions containing infected health status from another user. Fig. 4 shows that the mobile app in layer 2 detects surrounding users through Bluetooth, recording the time interval ∆t B of direct contact of the users, the random mac address MacAddr of the other user, the type of mobile device DeviceType, and the range of RSSI. The mobile app will packet these segments into a transaction to broadcast in this blockchain network and store in the blockchain database. And the mobile APP will store all the Bluetooth mac addresses generated locally for another service functionality health tracing, which will be discussed in the next section.

Another scenario of Bluetooth-based contact tracing is that, if the mobile APP receives a transaction containing other user's infected health status and his mac addresses, the Bluetoothbased contact tracing will query its local blockchain database based on these mac addresses, and check whether the current user has a contact record with the infected user. If they have a contact history, then the mobile APP will alert the user. Then, the mobile APP will transfer and broadcast this transaction again on the network to alert other users who may have a contact history.

We have mentioned in the previous section that there are two types of challenges: 1. The balance between the number of random mac addresses generated by Bluetooth and protecting users' privacy, 2. The balance of the number of random mac addresses and network congestion. For the first challenge, we adopt the method of changing the silent period [25] . The silent period refers to the gap time between Bluetooth device discarding the old mac address and adopting the new mac address [25] , and during this period, the Bluetooth device cannot decide to use the new or old address. The article points out that changing the length of the silent period obviously reduces the duration of the Bluetooth device being tracked, and thus the device will not be located easily [25] . This is still an open question, and it is worth our research in the future. For the second challenge, we use weak randomization, which reduces the number of random addresses generated, so fewer transactions are generated for packing these mac addresses. Then in the blockchain network, each computing node and the user can achieve data consistency without synchronizing a large number of communication requests.

Health tracing is the third service in the proposed mobile APP and it has two major functionalities: 1). Broadcast user's infection status to update contracts infection status and alert other users. 2). Estimate the probability of being infected.

Within the first functionality, users can update their infection status as U infected or U normal . When the user's status becomes infected, the mobile APP will automatically two things: 1). update all infection status among Contract location s where this user visited in the past 14 days based on his visiting records and 2). broadcast transactions containing his infected status and all the Bluetooth randomized mac addresses generated in the past 14 days to alert others who have close contacts with him.

Within the second functionality, users can estimate the probability of being infected based on the analysis of the four factors RSSI, ∆t B , ∆t C , ms. Referring to the formula (7) in section 3, we believe these parameters and P(infection) should be formalized in a logit function: where β 4 (ms) is formulized as

After accessing real medical data and investigating the public locations, we will calculate and prove this proposed formula.

We build a prototype system and evaluate its performance with the following experiments, where we simulate users' daily contact and check-in activities by the Poisson distribution equation. In the experiments, we focus on the average cost of processing requests and the total cost to operate our prototype system. First, we introduce the environment for the experiments. Then, we evaluate and analyze the system performance on stability and scalability. In the future, we may deploy our system and build benchmarks to evaluate when the real dataset is available.

We conduct experiments on the MacBook Pro with a macOS system in version 10.14.5. This machine has an Intel i5 CPU with 2.3 GHz and an 8 GB LPDDR3 memory. We use a programming language called Solidity to develop and implement the smart contract group, which are deployed on a private Ethereum blockchain simulated by a software called Ganache. Then, we use Python to code the script for data analysis.

Our experiments focus on three basic variables affecting performance: 1). The number of |U| increasing from 100 to 600, with even intervals of 100, 2). the user's contact and check-in frequency Freq following Poisson distribution, and 3). smart contract group size SCG.size. 

Based on three quantities of deployed smart contracts and six different numbers of requests increased from 100 to 600, we measure the average gas cost of all requests, and the standard deviation on the average cost of ten rounds experiments. Fig. 5 shows that as the quantity of contracts increases from 3 to 18, and the number of requests increases from 100 to 600, the average request gas consumption is reduced by a factor of 5 from 2,000,000 wei to 400,000 wei. Fig. 6 shows that with the increase of requests, the deviation of request cost is reduced by 5 times. Although the gas amount and deviation in Fig. 5 and 6 are very large, the actual overhead is very small. We know that wei is the smallest gas unit in Ethereum system and 1 ether is equal to 10 18 wei. Then, assuming 1 ether is worth $250, an 400,000 wei request is worth $10 −10 , and the deviation of 500 wei is negligible. Also, we find that in the condition of different number of contracts, the average costs trend to be a similar amount around 400,000 wei.

System overhead refers to the interaction costs between mobile services and users and operating costs for smart contracts, which are measured by Ethereum gas. Fig. 7 shows that when the number of requests increases from 50 to 250, and the number of contracts increases from 3 to 18, the overall gas consumption of the system increases linearly, considering the case of the same amount of requests with different amount of contracts, and the case of the amount of contracts with different amount of requests numbers.

Based on the three measurements, we believe that this prototype system has good stability and scalability. With the increase in the number of requests and contracts, the request cost, which is the major overhead in the system operation, has a stable approaching to a lower boundary. This trend supports the stability of the system. Similarly, the system overhead is linear growth, instead of an exponential one, which is an acceptable performance.

In the field of contact tracing, MIT [1] , Apple and Google [2] have related products and projects. However, their solutions are either a centralized database that is built in the system or incomplete privacy protection which is provided for users. Such designs cannot meet the requirements of user privacy.

In terms of data security, the smart contract guarantees the consistency of operating execution and then obtains a consistent output. There is one paper presenting a computing resource trading platform based on a smart contract-based edge computing network [26] . This design uses a similar treestructured smart contract group with ours, but their implementation focuses on how to match users and complete resource trading. And our purpose of smart contracts is to record the infection status for locations.

Regarding privacy, there are articles that use differential privacy algorithms in IoT data processing [27] , but differential privacy methods will return a relatively accurate output with noise added. This conflicts with the property of blockchain because when storing data, the latter block must verify the correctness of the data of the previous block and cannot tolerate deviations. But it could be interesting to see intersection research of these two fields.

In this paper, we design this tracing and notification system based on blockchain and smart contract, which provides three types of services: location-based contact tracing, Bluetoothbased contact tracing and health tracing services. Our system can trace the user's travel and contact history, and can remind the user about his past contacts that may cause infection. In addition, users can also estimate the probability of being infected through the health tracing service.

In order to protect users' privacy, they can anonymously send their visiting records and health status on the blockchain platform. At the same time, users can use a large number of random mac addresses provided by Bluetooth technology as a temporary identity to further protect privacy. In addition, our smart contract group embedded in the system records the infection status of each location and performs the same sequence of check-in operations to ensure that each user can get the consistent infection results of the location.

We also simulate the interaction between users and our prototype system, and then evaluate its performance, including gas consumption, operating stability, and request processing speed. In a simulated environment, our system has a good scalability and good stability. We expect to have real data about user contact records to evaluate our system in the future.

Pact: Private automated contact tracing

Apple and google partner on covid-19 contact tracing technology

Covid-19 coronavirus pandemic

Cases in the u.s

We care world covid 19 tracing

Laboratory testing for coronavirus disease 2019 (covid-19) in suspected human cases: interim guidance

Protocol for assessment of potential risk factors for coronavirus disease 2019 (covid-19) among health workers in a health care setting

Ethereum: A secure decentralised generalised transaction ledger byzantium version 7e819ec

Sustainability of coronavirus on different surfaces

Covid-19 diagnostic based on mit technology might be tested on patient samples soon

A sneeze

Assessment of risk factors for coronavirus disease 2019 (covid-19) in health workers: protocol for a case-control study

Bleb: Bluetooth low energy botnet for large scale individual tracking

Handoff all your privacy a review of apples bluetooth low energy continuity protocol

On scaling decentralized blockchains

Machine learning: a probabilistic perspective

Distance estimation of smart device using bluetooth

BioModels Database: a free, centralized database of curated, published, quantitative kinetic models of biochemical and cellular systems

Cassandra: A decentralized structured storage system

Exploring the attack surface of blockchain: A comprehensive survey

How to time-stamp a digital document

Bigchaindb: a scalable blockchain database

Operational performance data

Enhancing wireless location privacy using silent period

Smart contractbased computing resourcestrading in edge computing

A lightweight privacy-preserving data aggregation scheme for fog computing-enhanced iot