A novel framework of collaborative early warning for COVID-19 based on blockchain and smart contracts.

Early warning is a vital component of emergency response systems for infectious diseases. However, most early warning systems are centralized and isolated, thus there are potential risks of single evidence bias and decision-making errors. In this paper, we tackle this issue via proposing a novel framework of collaborative early warning for COVID-19 based on blockchain and smart contracts, aiming to crowdsource early warning tasks to distributed channels including medical institutions, social organizations, and even individuals. Our framework supports two surveillance modes, namely, medical federation surveillance based on federated learning and social collaboration surveillance based on the learning markets approach, and fuses their monitoring results on emerging cases to alert. By using our framework, medical institutions are expected to obtain better federated surveillance models with privacy protection, and social participants without mutual trusts can also share verified surveillance resources such as data and models, and fuse their surveillance solutions. We implemented our proposed framework based on the Ethereum and IPFS platforms. Experimental results show that our framework has advantages of decentralized decision-making, fairness, auditability, and universality. It also has potential guidance and reference value for the early warning and prevention of unknown infectious diseases.

Introduction

Historically, the global outbreak and epidemic of acute infectious diseases have been witnessed to directly affect public health and socioeconomic development. Currently, the coronavirus disease 2019 (COVID-19) pandemic continues to spread globally. As of December 2020, it has already caused more than 70 million confirmed cases and one million deaths worldwide [58]. It is generally believed that the key to the prevention and control of infectious diseases is the long-term surveillance and rapid response of abnormal occurrences or increasing trends of infectious diseases by using early warning technologies and systems [24]. However, controlled by specific centralized organizations like national governments or Centers for Disease Control and Prevention (CDC), most of the existing early warning systems (EWSs) for infectious diseases are passive and disease-specific, resulting in numerous isolated systems lacking reliable information sharing mechanisms. As such, they inevitably have the risks of single evidence bias and decision-making errors, and can thus only haphazardly pick up currently unknown diseases such as severe acute respiratory syndrome (SARS) and COVID-19 [34].

Introducing distributed collaboration into the EWSs can give full play to the crowd intelligence to break the resource and capacity limitations of the existing centralized systems. For example, influenza and Ebola surveillance based on crowdsourced public reporting data proves to be more proactive and timely than surveillance based on diagnostic data from medical institutions [47], [28]. Since infectious disease surveillance and early warning is highly interdisciplinary, spanning a wide range of expertises, technologies, and data sources, it is widely believed that it is necessary to further integrate this collaboration of multiple contributors into the lifecycle of early warning. Therefore, there is an urgent need to establish a decentralized EWS to leverage the distributed contributions of multiple parties, support various early warning technologies, and monitor multi-source surveillance data. Furthermore, in an open, dynamic and complex environment, this EWS should be able to: 1) provide a secured and private collaboration environment for participants without mutual trust; 2) provide fair incentive mechanisms that promote sustained and effective contributions; 3) ensure the auditability, traceability, and credibility of surveillance data, models and early warning results to detect and eliminate malicious behaviors.

This research is targeted at filling in this important gap, and our contributions can be summarized as follows.

First, to break the resource constraints in centralized and semi-centralized systems, based on techniques including blockchain, smart contracts and artificial intelligence (AI), we propose a novel and decentralized framework of collaborative early warning for COVID-19 that meets the above requirements. Specifically, blockchain can help build a trustless collaborative environment, smart contracts can encapsulate and execute scalable warning rules and incentive mechanisms, and AI can enable a variety of pluggable surveillance models.

Second, to make full use of major contributing forces of medical institutions and social participants (i.e., organizations and individuals), we design two surveillance modes in a unified framework, i.e., medical federation surveillance based on federated learning and social collaboration surveillance based on learning markets. Therefore, multi-source data collected from medical channels and social channels with different data features and privacy sensitivity can be separately analyzed but collaboratively surveilled. Specifically, it is hoped that by using our framework, medical institutions can train better federated surveillance models with privacy protection, while social participants without mutual trusts can share verified surveillance resources such as data and models, and fuse their solutions. Accordingly, their combination can enhance the quality of decision-making and improve the performance of early warning.

Third, to evaluate our proposed framework, we explain our design in detail, compare it with the existing EWSs, and preliminarily implement and analyze it based on the Ethereum and Inter-Planetary File System (IPFS) platforms. An early warning scenario for COVID-19 based on open-source chest X-ray data sets is set up to comprehensively verify the functionalities of the framework, and the performance with multiple quantitative and qualitative indicators is discussed. Experiments show that the proposed framework can successfully combine the scattered medical and social surveillance forces, and provide them with fair incentives and trusted information sharing mechanisms, thereby reducing the risk of decision bias. Also, our framework with advantages of auditability and universality can further help the early warning and prevention of other unknown infectious diseases.

The remainder of this paper is organized as follows. Section 2 reviews the existing early warning technologies and systems, basic concepts of blockchain and smart contracts, as well as blockchain-based federated learning and learning markets; Section 3 elaborates our novel framework of collaborative early warning for COVID-19; Section 4 presents an illustrative implementation of our framework based on Ethereum and IPFS platforms and analyzes its performance; Section 5 discusses our future work, and Section 6 concludes.

Literature review

In this section, we briefly review the basic concepts and recent advances of existing early warning technologies and systems, blockchain and smart contracts, as well as blockchain-based federated learning and learning markets.

Early warning for infectious diseases

The major task of early warning for infectious diseases is to detect notable aberrations via analyzing surveillance data with specialized surveillance technologies, and on this basis, send out warning signals related to possible outbreaks before or at an early stage of the events to protect people from potential health risks [60]. According to the different surveillance data, the existing infectious disease EWSs can be divided into indicator-based and event-based [41]. Generally, indicator-based EWSs analyze structured data collected through routine surveillance channels including healthcare providers, diagnostic laboratories and governmental specialists, while event-based EWSs analyze unstructured data gathered from intelligence sources of any nature, such as search engine queries, social media posts, e-commerce sales trends, wearable device records and many other online big data generated outside the routine channels [18]. Therefore, the former is usually more reliable, while the latter is more timely. In order to obtain higher accuracy, most national EWSs, including the China Infectious Diseases Automated-Alert and Response System (CIDARS) [61], are indicator-based, while in order to obtain better timeliness, most web-based EWSs, such as the Influenzanet [19], HealthMap [14], ProMed-mail [42], and the Global Public Health Intelligence Network (GPHIN) [35], are event-based. Furthermore, according to different surveillance technologies, event-based EWSs can be divided into three main categories: news aggregators, automatic systems and human-moderated systems [27]. Specially, news aggregators include Influenzanet, because it only aggregates influenza activity index by collecting and screening influenza-like-illness (ILI) related questionnaires completed by volunteers, and users can not get more detailed information unless they examine each individual article [37]. Automatic systems go beyond the simple gathering task by adding a series of automatic analysis steps. HealthMap falls into this category because it uses natural language processing tools to automatically analyze Internet media reports and directly overlay warning results on interactive geographic maps [10]. Human-moderated systems additionally introduce a group of human analysts to screen for epidemiological relevance of the automatically processed information before presenting them to the users [6]. Both of ProMed-mail and GPHIN employ specialists to manually screen and aggregate their warning results to be published [66].

Obviously, the quality of surveillance data and the capability of surveillance technologies directly determine the performance of EWSs. More and more researches have showed that the utilization of multi-source surveillance data and the combination of various surveillance technologies can help promote active detection, reduce decision bias and balance the reliability and timeliness [60], [45]. To achieve this integration, specific expertise provided by worldwide participants and their well-organized distributed decision-making are necessary. However, all of the aforementioned EWSs are centralized or semi-centralized with designated participants and fixed surveillance data and technologies, which means that any expansion of them might be expensive and inefficient. Therefore, we need to establish a new decentralized EWS to support such long-term and large-scale cooperation among participants without mutual trust. The blockchain and smart contracts technology, which can provide a high degree of interoperability, fair incentive mechanisms, trusted information sharing mechanisms, and secured and private collaboration environments, has become a very promising choice.

Blockchain and smart contracts

Originating from the widely publicized whitepaper Bitcoin: A Peer-to-Peer Electronic Cash System published by Satoshi Nakamoto in 2008 [36], blockchain is an append-only distributed ledger with chained data blocks maintained and shared by all nodes in a decentralized system [68]. According to the permission settings, blockchain can be classified into public blockchain, consortium blockchain, and private blockchain. Since blockchain is an integrated innovation based on the existing techniques, including cryptography, peer-to-peer networks, consensus algorithms, and incentive mechanisms, blockchain-based systems can achieve large-scale collaboration with privacy control by setting access permissions, as well as avoid data tampering and single point of failures through redundant storage [67]. Coined in 1994 by Nick Szabo [49] and revived by blockchain in recent years, smart contracts running on blockchain are self-enforced and self-verified computer programs with a series of pre-defined rules, which can be embedded into tangible or intangible assets, transactions and data, and then serve as a software-defined intermediary among untrusted participants to facilitate information exchange, value transfer, and asset management [54]. Since blockchain and smart contracts have such characteristics as trustlessness, autonomy, traceability, and tamper-resistance, they are widely considered as the perfect digital infrastructure for building distributed and disintermediary collaboration systems [39], [52], [26], [70], and have been preliminarily applied in the field of public health with success [22], such as electronic medical records sharing [59], [5], privacy data access control [2] and opioid prescription tracking [69].

This paper aims to establish a collaborative EWS framework for COVID-19 with the help of scalable and interoperable blockchain and smart contracts, so that our proposed EWS can not only improve the accuracy of early warning by promoting the sharing of trusted surveillance resources, the fusion of distributed decision-making, and the cooperation of untrusted contributors, but also improve the timeliness of early warning by adopting smart contracts with preset rules for real-time, automatic and continuous monitoring. Our implementation is based on two prevalent blockchain projects, i.e., Ethereum and IPFS. Ethereum is currently the most popular development platform for smart contracts [57], while IPFS is a peer-to-peer version-controlled distributed filesystem [3]. IPFS routes files according to their content hashes, aiming to share data globally without the risk of loss or tampering. In our design, the encrypted data and models to be shared are stored in IPFS, and only the obtained IPFS hashes are transmitted on the blockchain, thereby reducing the payload of data storage.

Blockchain-based federated learning and learning markets

Benefiting from its powerful data mining capabilities, the emerging AI technology has been witnessed to provide valuable solutions for many recent researches areas, including digital image processing [63], [65], natural language processing [62], [25] and multimodal analysis [16], [64]. With the revolution of Internet and mobile devices, traditional single-factor surveillance technologies commonly used in indicator-based EWSs, such as CIDARS, gradually show their insufficient capacity in dealing with multi-source big data, and more and more AI-enabled intelligent models are introduced with better performance [12], [38], [56], [51]. Considering that the surveillance data collected from medical channels and social channels has different data features and privacy sensitivity, our proposed framework is supposed to accordingly provide them with two different surveillance modes when introducing intelligent models, so as to promote their cross-end collaboration. Therefore, we combine and expand two existing works, i.e., federated learning (FL) [21] and learning markets (LM) [40].

FL is a new machine learning architecture proposed by Google in 2016 to solve the data islands problem. In FL, federation members jointly train a centralized federated model by exchanging and fusing local parameters, so as to implicitly aggregate training data and improve model performance without revealing private data. As such, FL is expected to help medical federations obtain a better federated model as their unified surveillance standard under privacy protection. However, there are two significant problems to be solved. First, the transmission and fusion of federated data based on a centralized cloud or server has potential risks of data loss, leakage, tampering, and single point of failures. Thus, Kim et al. propose a blockchainized FL architecture (BlockFL) for decentralization, in which federation members download all local updates stored in the latest block and update the global model locally [20]. Second, assuming that all members are trustworthy and reliable, FL indiscriminately accepts individual updates and shares the federated model, thus lacking the ability to exclude malicious behaviors and include fair and sustainable incentive mechanisms. Therefore, our previous work proposed a decentralized AI collaboration framework based on blockchain and smart contracts, namely, LM. LM consists of a collaboration market and a sharing market, and controls their logic through scalable market mechanisms encapsulated in programmable smart contracts. In the collaboration market, untrusted participants can realize distributed collaborative mining under dynamic incentives in ensemble learning (EL)’s “Centralized Data  + Distributed Model (CDDM)” mode or FL’s “Distributed Data  + Centralized Model (DDCM)” mode. In the secured and private decentralized sharing market, auditable, traceable and trusted AI models and data can be traded as digital assets.

In [40], we take CDDM mode as an illustrative example to implement LM and prove its advantages. This paper expands LM to establish the system. Specifically, at the Medical End, we combine the ideas of [20] to expand the collaboration market, thereby realizing the FL’s DDCM mode and completing the federated surveillance. At the Social End, we share trusted surveillance data and models in the sharing market, and complete collaborative surveillance in EL’s CDDM mode in the collaboration market. It is worth noting that whether in LM or our proposed framework, smart contracts only manage the interaction logics between distributed participants, and the training of AI models is essentially completed off the blockchain and according to the existing methods of FL and EL, which means that we do not rely on specific models, and all intelligent surveillance models suitable for FL and EL can be easily integrated into our framework. Without loss of generality, three classic and widely studied deep learning models, including convolutional neural networks (CNN), long short-term memory (LSTM) networks and bi-directional long short-term memory (BiLSTM) networks, are selected to demonstrate and analyze the proposed framework [23], [15], [46], [17].

Framework of collaborative early warning for COVID-19

In this section, we explain the framework, operation mechanisms, and detailed design of smart contracts of our proposed collaborative EWS for COVID-19.

An overview of the framework

The framework of the proposed system is shown in Fig. 1 , and Table 1 presents the description of important notations and variables in this paper. The system running on an underlying blockchain network consists of Medical End and Social End, including four roles, i.e., medical federation members, social monitors, verifiers, and miners. Its main function is enabled by five smart contracts: Authority Management Smart Contract (AMSC), Medical Federated Surveillance Smart Contract (MFSSC), Social Collaboration Surveillance Smart Contract (SCSSC), Medical & Social Fusion Warning Smart Contract (MSFWSC), Incentive Smart Contract (ISC). At the Medical End, federation members realize federated surveillance based on FL and private healthcare data. At the Social End, social monitors and verifiers realize collaboration surveillance based on EL and trusted and tradable multi-source data in LM. At last, according to the preset fusion algorithms and early warning rules, MSFWSC fuses and examines emerging cases’ monitoring results from two ends to realize automatic and real-time early warning of the new COVID-19 outbreak. In this process, the Oracle which links the off-chain verified authoritative websites is used as a trusted external data source for smart contracts to query the external states and trigger the execution. The main concepts in the system are defined as follows.

Fig. 1

The framework of proposed collaborative EWS for COVID-19.

Table 1

Notations and variables.

Notations and variables	Description
p/F/S/V	Participant/Federated members/Social monitors/Verifiers, p∈{F,S,V}
pk_p/sk_p	Public key/Private key of p
k_S_j/k_FList	Self-defined key of S_j or FList
D_p/C_p/R_p	Deposit/Credit/Reward of p
FU_A→B	Fund transferred from A to B
FList/SList/VList	Confirmed list of F/S/V
F_dep/S_dep/V_dep	Total deposits of FList/SList/VList
VSet_F_i/VSet	Validation set from F_i/FList
Model_F_i/Model_S_j	Individual surveillance model of F_i/S_j
Model_FList_F_i	Federated surveillance model from F_i
Model_FList	Agreed federated surveillance model
E_F_i/Acc_F_i	Evaluation/Accuracy of Model_F_i from F_i
E_S_j/Acc_S_j	Evaluation/Accuracy of Model_S_j from S_j
E_FList_F_i	Evaluation of Model_FList_F_i from F_i
E_FList/Acc_FList	Agreed evaluation/accuracy of Model_FList
EV_S_jk	Evaluation of solution_S_j from V_k
EV_S_jVList	Agreed evaluation of solution_S_j
E_SList/Acc_SList	Estimated evaluation/accuracy of {solution_S_j}, S_j∈sucSList
α_F_i/α_S_j	Contribution coefficient of F_i/S_j
RJ_F_i/RF_S_j	Members rejected Model_F_i/Model_S_j
RW_S_j/RP_S_j	Members reviewed/accepted Model_S_j
sucFList/puniFListsucSList/puniSListsucVList/puniVList	The list of honest/dishonest F/S/V
POS_F_i/POS_M/POS_S	Amount of positive cases detected by F_i/Medical End/Social End
PRED_S_j/PRED	Prediction of new cases from S_j/sucSList
RES_M/RES_S	Medical/Social End’s monitoring report

Participant: denoted by p, the participant who has registered in the blockchain network with assigned public key and private key .

Federation member: denoted by F, the participant from medical institutions who has private healthcare data for surveillance, and forms a federation FList with other medical participants possessing the same type of data. F deposits to smart contracts before joining the early warning project, and negotiates to determine the FL mode and communication protocol in FList before the project starts. The FL mode includes model types, fusion algorithms, iteration conditions, etc, and the communication protocol includes encryption/signature algorithms, shared key of private data , custom encrypted communication channel, etc.

Social monitor: denoted by S, the social participant who has verifiable data and models for surveillance, and forms a collaboration organization SList with other social participants possessing the same type of data. S deposits to smart contracts before joining the early warning project, publishes surveillance solutions with corresponding data and models in LM, and collects sufficient proof of solution validity from verifiers. S can also publish surveillance solutions directly based on verified data and models in the sharing market.

Verifier: denoted by V, the social participant who is responsible for verifying the validity of surveillance data, models, and solutions in LM. V deposits to smart contracts before joining the early warning project. In the same round of validation, V can only testify for the same S once and cannot testify for himself. After the project ends, V will be rewarded according to the times of honest validations, and be punished when cheating.

Miner: the participant who is responsible for the underlying consensus process, including verifying transactions, packing data blocks, and updating the blockchain. All participants can be miners.

AMSC: invoked for project and participant identity management. Project management includes setting project requirements and controlling the project process, and participant identity management includes adding/deleting p, updating p’s information, and setting interaction permissions.

MFSSC: invoked by F for federated surveillance, including constructing unified validation sets, exchanging local surveillance models, fusing federated surveillance models, and monitoring emerging cases based on the obtained federated models.

SCSSC: invoked by S and V for collaboration surveillance, including sharing verifiable data and models in the sharing market, publishing individual surveillance solutions and performance in the collaboration market, verifying and evaluating individual surveillance solutions and performance, fusing the collaborative surveillance solution set, and monitoring emerging cases based on the obtained solution set.

MSFWSC: invoked for the automatic fusion and warning of emerging cases’ monitoring results from Medical End and Social End, according to the preset fusion algorithms and early warning rules.

ISC: invoked for the calculation and implementation of the rewards and punishments of all participants, including cryptocurrency and credit scores.

Operation mechanisms

The proposed operation mechanisms can be divided into four stages, namely, project initialization, Medical End/Social End surveillance, M&S-fusion based warning, and post-warning incentivation. The detailed process in each stage is depicted as follows.

1. Project initialization:

1) All participants register for project identity p with registration deposit ;

2) Registered p applies to AMSC with the required fund for becoming confirmed F in specific FList, confirmed S in specific SList, or confirmed V in VList;

3) Confirmed , or V can apply to AMSC for deleting role and exiting project before the project starts;

4) When the amounts of , and V meet the preset thresholds, the project starts.

2. Medical End/social End surveillance:

A. Medical End surveillance

1) shares validation set sampled from privately-held data set in FList, downloads and combines all to construct a unified validation set VSet locally;

2) In each iteration, shares their local model trained on privately-held data set in FList and publishes its performance on VSet in the blockchain network. MFSSC calculates and publishes ’s contribution coefficient ;

3) verifies and evaluates local models from others, excludes false models, fuses the federated model according to , and at last, publishes ’s performance on VSet and the list of members he/she has rejected;

4) MFSSC determines the final federated model from the consensus of all and publishes ’s performance on VSet, all s, and the lists of rewards and punishments, i.e., sucFList and puniFList. This round of iteration ends and the next starts. Until the preset stop conditions are met, the training of federated surveillance is completed;

5) After the training completes, all use the obtained federated model as the unified standard to monitor their received emerging cases. MFSSC fuses their uploaded results according to the preset rules and reports to MSFWSC.

B. Social End surveillance.

1) Social participants share verifiable surveillance data and models in the sharing market, and prepare for the subsequent collaboration;

2) In each iteration, publishes surveillance solution with corresponding verifiable data and models in LM, announces their performance in the blockchain network, and requests sufficient to prove their validity;

3) verifies the validity and performance of according to the preset validation rules and publishes the evaluation ;

4) SCSSC determines the final evaluation of from the consensus of all , publishes the lists of rewards and punishments, i.e., , calculates all s, and the weighted estimated performance of the final collaborative surveillance solution set . This round of iteration ends and the next starts. Until the preset stop conditions are met, the training of collaboration surveillance is completed;

5) After the training completes, all use their verified solutions in to monitor their received emerging cases respectively. SCSSC fuses their uploaded results according to the preset rules and reports to MSFWSC.

3. M&S-Fusion based warning:

MSFWSC receives the monitoring reports from MFSSC and from SCSSC, fuses their monitoring results of emerging cases based on the preset algorithms and weights, i.e., and , and automatically alerts when the early warning conditions are met.

4. Post-warning incentivation:

ISC calculates and implements the rewards and punishments of all participants based on the lists of rewards and punishments from MFSSC and SCSSC and the comparison of system warning results with outbreak information from authoritative websites. The early warning project ends.

Design of smart contracts

The proposed collaborative EWS is realized by five smart contracts, i.e., AMSC, MFSSC, SCSSC, MSFWSC, and ISC, which are developed to inherit and monitor each other for simplicity and security. The preset project parameters and their definitions are shown in Table 2 . Note that this section is only a simple illustrative implementation for the collaboration of one medical federation and one social collaboration organization. By adjusting the contract logics and corresponding parameters, it is easy to extend our participants, authorities, incentive mechanisms, fusion algorithms, and early warning rules. The details are as follows.

Table 2

The preset project parameters.

Notations and variables	Description
C_p+/C_p-	Single credit reward/punishment of p
D_rg/D_rq/C_rw	Required deposit/credit for registration/selecting role/reviewing solution
F_lim/S_lim/V_lim	Maximum amount of F/S/V
Θ_rw/Θ_E_S/Θ_POS_S/Θ_A	Thresholds of reviewed verifiers/accepting Model_S_j/determining a positive case/alert
W_M/W_S	Fusion weight of Medical End/Social End

Fig. 2 shows a complete cycle of the EWS and the scope of smart contracts in the cycle. To distinguish with the four stages at two ends, seven bool-type status flags are set, i.e., , and endPro. As shown in Fig. 2, when these status flags are set as true, the next stage of interaction starts.

Fig. 2

A complete early warning cycle.

AMSC: As shown in Algorithm 1, AMSC realizes the main functions in the project initialization stage, escrows all deposits and bonuses, and is monitored and invoked by other smart contracts to query and update project and participant information. Initial participant information includes deposit and credit, recorded as , and initial can be set to be the same or proportional to initial . After selecting roles and passing the validation of qualification function joins or VList and obtains the corresponding permissions. can be customized to check whether and meet preset thresholds. We set the simplest incentive mechanisms as follows: for cryptocurrency, all honest Fs and Ss divide and respectively according to their and , all Vs divide according to their times of honest validations, and all fraudulent Fs, Ss, and Vs lose their deposits. At the same time, for credit scores, honest Fs, Ss, and Vs gain scores, while fraudulent Fs, Ss, and Vs lose scores. More specific incentive mechanisms will be detailed in the discussion of ISC and Section 4.2.3.

MFSSC: As shown in Algorithm 2, MFSSC realizes the main functions of Medical End surveillance in the Medical End/Social End surveillance stage, monitors AMSC to synchronizes permissions, and invokes MSFWSC to report medical monitoring results. Federated surveillance consists of two stages: training and monitoring. Before training starts, every needs to prepare a in their acceptable sample proportion to form a unified validation set VSet together, and subsequently take models’ performance on VSet as the evaluation standard, so as to reduce the impact of private data bias, exclude overfitting local models and maintain the training fairness. Since F are motivated to provide models that outperforms on VSet, the obtained federated model will cater to members providing more private data, thereby encouraging moderate sharing. Federations can also be built based on certain trust, but technically, both of the unified VSet and trust basis are not mandatory but for better security, privacy, and performance. Because FL adopts the homogeneous basic models, Fs only need to share, verify, and fuse the models’ weight parameters as formula (1).

To record the interactive history and ensure security and privacy, the private data transmission protocol stipulated in our design is as follows: 1) all Fs negotiate to determine the shared key , and every S generates his own symmetric key , 2) F and S upload private files encrypted by or on IPFS, 3) F and S publish the obtained IPFS hashes in the blockchain network, or transmit them to others by invoking the Send function in formula (2), S also sends the encrypted to receivers, 4) receivers download and decrypt encrypted files to obtain original files. The evaluation of models can include a variety of indicators such as accuracy, recall rate, and F1 measure. is the calculation function of that can adopt various forms. For instance, when is regarded as , it can be set inspired by AdaBoost [11], i.e., , where is the weighted classification error rate of on VSet. There is no special verifier in federated surveillance, and members are required to supervise, verify, and evaluate each other. A successful model needs the support of more than half of the other members, and the specific support ratios and consensus mechanisms can be easily extended in the future.

SCSSC: As shown in Algorithm 3, SCSSC realizes the main functions of Social End surveillance in the Medical End/Social End surveillance stage, monitors AMSC to synchronizes permissions, and invokes MSFWSC to report social monitoring results. Collaboration surveillance is realized based on our previous work LM [40]. In LM, registered participants can share or verify surveillance data and models to obtain enough credit scores for subsequent operations, and S should upload or link the corresponding data and models when publishing solutions. Since LM with credit management traces the interaction behaviors of registered participants and the historical information of surveillance data and models in the whole process, S and V without mutual trust can choose collaborators, data, and models based on these records. Besides, medical participants can also request verified surveillance resources in the sharing market to reduce the difficulty of data analysis.

Collaboration surveillance also consists of two stages: training and monitoring. S in the same SList can submit solutions for the same type of data. And when their data are not the same, similar to federated surveillance, they also need to construct a unified validation set for fairness before training and validation. Thus, for simplicity, Algorithm 3 assumes that they monitor the same trusted open-source data. V needs to consume credit scores when reviewing and evaluating solutions to increase the cost of invalid and malicious validation. S who upload invalid models or false performance will be punished, and V will be rewarded and punished according to the times of honest and dishonest validations. Only S who has been verified at least times and passed can participate in the final monitoring, i.e., . They will monitor emerging cases based on their verified solutions and weighted vote for the prediction results based on EL methods, and thus and PRED are calculated as formula (3). The calculation function of can be customized or the same as that of federated surveillance.

MSFWSC: As shown in Algorithm 4, MSFWSC realizes the main functions in the M&S-fusion based warning stage, monitors MFSSC and SCSSC to fuse their monitoring results and automatically alerts when the fusion results exceed the preset threshold. Specifically, is fused as formula (4), where m and n are the amounts of FLists and SLists. Through monitoring multiple MFSSCs and SCSSCs, MSFWSC can fuse monitoring results from multiple medical federations and social collaboration organizations. It is generally believed that the medical surveillances are more accurate, while the social surveillances are more timely. Therefore, by adjusting the fusion weights of two ends, it has the potential to enhance the accuracy and timeliness of EWS at the same time. We will discuss this in detail in Section 4.2.1.

ISC: As shown in Algorithm 4, ISC realizes the main functions in the post-warning incentivation stage and monitors AMSC, MFSSC, SCSSC and MSFWSC. settleReward is the calculation and implementation function of all rewards and punishments, and its corresponding calculation rules are depicted as formula (5). In order to restrict malicious Vs instantly, their credit scores are updated in real-time in SCSSC. After the early warning finishes, based on the atomicity of smart contracts, settleReward will reward all participants at the same time to ensure fairness and security. For cryptocurrency, we simply set up that all rewards come from deposits. However, when all Vs are honest, they may get the rewards equal to their initial deposits, which inevitably leads to the loss of their motivation for validations. And this can be easily solved when governments or other organizers provide additional bonuses for these early warning projects. For credit scores, we set up more detailed incentive mechanisms and prove the effectiveness in Section 4.2.3.Here, we discuss the effects of the preset parameters in Table 2. and are parameters determined by incentive mechanisms. The larger the and are set, the higher the costs of malicious behaviors will be. Especially, when , any malicious behavior might lead to the rapid decrease of credit scores until it is too low to exceed the preset threshold of the subsequent operations. For instance, a large will immediately prevent dishonest Vs from reviewing new solutions. Thanks to the decentralized blockchain, theoretically, have no maximum limit. However, with their increase, the payload of on-chain communications and off-chain model training will also increase, and more efficient consensus mechanisms and model fusion algorithms should be further considered. For example, in small-scale collaboration surveillance, can be set, which means should be verified by all Vs. While in the large-scale collaboration, a smaller inspired by the existing consensus mechanisms, such as Proof of Stake (POS), Delegated Proof of Stake (DPOS) and Practical Byzantine Fault Tolerance (PBFT), is also acceptable [32]. Additionally, a larger helps to limit the lower bound of ’s performance and ensure the advantages of collaborative solution sets. At Last, and are parameters set according to early warning rules. Smaller and help to improve sensitivity, and the trade-off of and help to improve accuracy and timeliness.

Table 3 is the comparison of the typical research works and our framework. First, our proposed framework is the only decentralized organization that aims to break the resource constraints of centralized and semi-centralized systems. After completing registration, identity authentication and mortgage deposit, capable participants all over the world can freely contribute to our framework by using their preferred data and models. Second, since we only use smart contracts to manage the interaction process, and do not rely on specific data and models, the modification of early warning logics and the integration of multiple data and various models can be easily realized without much cost. This feature gives us a high degree of flexibility which can support both indicator-based early warning and event-based early warning. In addition, with the help of LM, our models and data can be encapsulated as verifiable, traceable and tradable digital assets, thus enhancing their credibility and reusability, and making future early warning easier. In terms of decision-making, our framework automatically screens and fuses distributed decision-making using the preset smart contracts without manual moderation, so it can surpass news aggregators and avoid moderator bias. Third, for information access, unlike the existing systems alternatively designed as public or restricted, our framework has optional accessibility. For example, although the Send function is set to publicly record the transmission logs on blockchain for auditability, the transmitted information is custom encrypted with cryptography technology, and thus its details are only visible to the designated receivers. Further, to break the privacy restrictions of collaborative mining, two different surveillance modes are designed in MFSSC and SCSSC to respectively analyze multi-source data with different privacy sensitivity. These improvements provide some significant information sharing and utilization mechanisms for our EWS. Fourth, compared to the volunteer project Influenzanet, we use ISC to implement dynamic rewards in the form of cryptocurrency and credit scores, so as to encourage effective contributions and unite decentralized organizations.

Table 3

The comparison of the proposed framework and typical researches.

Researches	Organization	Flexibility	Type-based	Decision-making	Information Access	Economic Incentive
CIDARS	Centralized	Low	Indicator	Human-moderated	Restricted	Fixed Salary
GPHIN	Centralized	Fair	Event	Human-moderated	Restricted	Fixed Salary
HealthMap	Centralized	Fair	Event	Automatic	Public	Fixed Salary
Influenzanet	Semi-centralized	Low	Event	News Aggregators	Public	Volunteers
Proposed	Decentralized	High	Hybrid	Automatic	Optional	Dynamic Rewards

Experiments

In this section, we develop the smart contracts designed in Section 3.3 to implement and examine the proposed collaborative EWS. An early warning scenario for COVID-19 based on open-source chest X-ray data sets is set up to comprehensively verify the functions of smart contracts, and we evaluate and analyze the EWS with multiple quantitative and non-quantitative indicators. Experiments show that the proposed EWS with advantages of auditability and universality can successfully unite the distributed medical and social surveillance forces to reduce the risk of decision bias and provide them with fair incentives and trusted information sharing mechanisms.

Platform and setup

Based on the development architecture Ganache + Truffle, we create a virtual Ethereum blockchain locally and develop the designed smart contracts by using Solidity programming language to implement the proposed collaborative EWS. Web3.js is used to interact with all smart contracts and verify their performance, Python + Keras is used to implement all training, prediction and fusion algorithms of AI models. And by using the library, Keras.model, models or model weights are saved as files of multiple formats and then stored or shared in IPFS. To reduce the execution costs, we extract the common functions in five smart contracts to form a Helper contract for others to call, including querying specific members and calculating contribution coefficients. Therefore, six contracts are deployed, i.e., Helper, AMSC, MFSSC, SCSSC, MSFWSC, and ISC.

The experimental scenario is assumed as follows. To surveil and monitor the emerging COVID-19, three medical institutions with privately-held chest X-ray data sets form a federation to realize medical federated surveillance. Three social monitors and three verifiers form a collaboration organization to realize social collaboration surveillance. In the training stage, social monitors submit AI models for the same trusted open-source chest X-ray data set. For these two surveillance modes, we construct a unified COVID-19 chest X-ray data set containing 203 positive samples and 406 negative samples, and then divide it in two ways as shown in Table 4 . To fairly compare the performance of individual and collaboration surveillance models, the VSet is the unified validation set sampled from all Fs, and the Test Set is invisible to all Ss and Vs. Ss and Vs are set to only train and verify solutions on the Train Set.

Table 4

The data set division at medical end and social end.

COVID-19	Complete Data Set	Medical End				Social End
		F_1	F_2	F_3	VSet	Train Set	Test Set
Positive	203	58	58	87	6 + 6+9 = 21	163	40
Negative	406	116	116	174	12 + 12 + 18 = 42	326	80

Our positive samples are collected from a open-source data set released on GitHub, which consists of chest X-ray and CT images of patients who are positive or suspected of COVID-19 or other viral and bacterial pneumonias (MERS, SARS, and ARDS) [7]. We downloaded the data set on July 28, 2020, and screened out all the positive samples of COVID-19 in posteroanterior (PA) view, which has up to 203 samples. Then, to collect the negative samples, we randomly sampled 406 samples tagged as Normal in PA view from an open chest X-ray data set on Kaggle and formed the complete data set [33]. It is worth noting that our data set is only constructed to demonstrate and analyze the proposed EWS, based on which all of the obtained models lack clinical study and can not really diagnose [29], [50]. In practical application, the EWS can choose more trustable data sets with smaller bias and more interpretable models with better clinical research.

Additionally, due to the inherently limited computing ability of Ethereum smart contracts, such as only supporting 8–256 signed or unsigned integer variables, failing to compute floating-point numbers, and lacking complete mathematical libraries, we have adopted some development strategies, including calling a verified contracts library named SafeMath for preventing overflow, expanding the parameters, and transforming logarithmic functions into polynomials, For example, . To avoid fraudulent and other malicious behaviors, all functions in contracts have strict inspection conditions, so they can only be performed when callers obtain the required authentication of identity, time, and calling mode. Finally, in order to save the execution costs, some data is recorded by triggering “Event” instead of creating new parameters.

Evaluation and discussion

Accuracy

We examine the accuracy of the proposed system from three aspects: Medical End, Social End, and fusion results.

Medical End: Assuming that all Fs train CNN models with the same structure, has twice the data of and . We tested the accuracy of local models, the average federated model, and the weighted federated model on the VSet and the complete data set. The results are shown in Fig. 3 , and all s are shown in Table 5 . On the complete data set, the performance of and is similar, both federated models are better than local models, and the weighted model has the highest accuracy. On the VSet, the performance of and has a large gap, both federated models are between and , but the weighted model is better than the average model. This shows that when local models have good and similar performance, federated collaboration is beneficial to improve federated models and thus the warning accuracy. When local models contain both good and bad models with a large gap, federated models will inevitably be affected and deteriorated, but in both cases, the weighted model can better approximate the good models. Besides, when federated models are equally shared among all members, the real contributors may fail to benefit from the cooperation and the lazy members may easily take a free ride, which means that FL without additional incentives is an unfair collaboration, leading to the loss of contribution motivation and the dissolution of the federation. For this issue, ISC sets that all Fs divide the total deposits in proportion to their , so as to provide additional economic incentives proportional to the real contribution and maintain the fairness and sustainability of cooperation.

Fig. 3

The accuracy of local models, the average federated model, and the weighted federated model on the VSet and the complete data set.

Table 5

The contribution coefficients of federation members.

Participants	F_1	F_2	F_3
α_F_i	1.3456	1.2255	1.7089

Social End: For the same trusted open-source data set, all Ss can submit heterogeneous models as their individual surveillance solutions. Assuming that three Ss submit CNN, LSTM, and BiLSTM models respectively, we discuss two cases that submits a good CNN model and ’ submits a bad CNN model. The accuracy of individual solutions, the average collaborative solution set, and the weighted collaborative solution set on the Train Set and Test Set in two cases are shown in Fig. 4 (a) (b), and all s are shown in Table 6 . Since the open-source Train Set is visible to all social participants, we do not divide a special validation set from the Train Set for Vs, and Ss may submit overfitting models. In practical application, the early warning project can be initiated by organizers with trusted surveillance data, and they can choose to prepare special validation sets to prevent strategic behaviors. Because this mechanism has been discussed and implemented in our previous work [40], for simplicity, this experiment just assumes that all submitted models are not overfitting. As shown in Fig. 4, when all individual solutions are good, social collaboration can achieve better surveillance performance, regardless of average or weighted set. When individual solutions contain bad models, the collaboration will be affected. However, similar to Medical End, the weighted set can better exclude the negative influence and approximate to good solutions.

Fig. 4

The accuracy of individual solutions, the average collaborative solution set, and the weighted collaborative solution set on the Train Set and Test Set in two cases.

Table 6

The contribution coefficients of social monitors.

Participants	S_1	S_2	S_3	S_1’
α_S_j	1.9346	1.8859	1.8859	0.5561

Both experiments on Medical End and Social End show that the collaboration can improve the performance of fusion model under certain conditions. This is because as shown in formula (1) and (3), their trainings of fusion surveillance models are essentially completed off the blockchain based on FL and EL, and smart contracts designed to control interaction do not affect models’ performance. In other words, these certain conditions that can improve the fusion performance are exactly the effective methods to improve federated models and ensemble models in FL and EL. Therefore, by learning from the recent advances of FL and EL, the advantages of our fusion models and collaborative early warning can be further ensured. In this paper, we simply adopt the above efficient weighted fusion methods to demonstrate and analyze our system.

Fusion results: We test the medical weighted federated model and the social weighted collaborative solution set on the complete data set, and get their misclassified sample sets as shown in Fig. 5 , in which the serial numbers of negative samples are less than or equal to 405, and the serial numbers of positive samples are greater than 405. Due to their different data preferences, by adjusting and , the misclassified samples outside their intersection can be identified, so as to improve the accuracy and timeliness of early warning.

Fig. 5

Misclassified sets of Medical End and Social End on the complete data set.

For instance, when and the accuracy is taken as the evaluation indicator, the formula to determine whether to alert is as formula (6). When the early warning rule is set to alert whenever a positive sample is detected at an end, the corresponding mathematical expression is as formula (7), and the solutions of , and are as formula (8). Then, if we take as the accuracy of the weighted federated model on VSet, i.e., 0.9524, and take as the weighted estimated accuracy as shown in formula (9) because of the invisibility of Test Set, i.e., 0.9782, a feasible solution is . At this time, compared with the early warning rule which is set to alert whenever a positive sample is detected at both ends, the proposed EWS can additionally give correct early warning to the samples in the misclassified set, including and , which improves the performance. When MSFWSC needs to fuse the monitoring results of multiple medical federations and social collaboration organizations, the formula (6) can be easily extended for the combinatorial optimization of weights and thresholds to obtain better accuracy and timeliness of early warning.

Collaboration costs

Any execution of programming segments in Ethereum will trigger a payment for computing resources calculated by using the unit called gas according to the preset rules [57]. The actual transaction costs , where gasPrice is the exchange rate between Ethereum’s cryptocurrency Eth and gas, and can be set arbitrarily by senders. The higher is the gasPrice, the faster will the transaction be packaged into the blockchain. The gas consumption of smart contract deployments and executions are shown in Tables 7 and 8 , respectively. Considering that the size of parameters, the number of cycles, the order of invoking, and the complexity of calculations will all affect the gas consumption, the data in Tables 7 and 8 are the average values obtained from multiple repeated experiments. Because our smart contracts focus on dealing with the cooperative relationships among all participants and most complex computations are implemented in an off-chain fashion, the operation comsuming the most gas is deploying the six smart contracts, i.e., 12,739,996 gas in sum. Taking as an example, the consumption of deployment is 0.2548 Eth, and according to Eth’s historical highest and lowest prices, and [8], the corresponding costs are and , respectively. Both of them are far cheaper than the establishment of any centralized EWS that can support the same kind of distributed collaboration. With the future upgrade of the Ethereum platform, the reduction of gas costs, and the adoption of consortium blockchain without execution costs, our costs can be expected to be further reduced.

Table 7

The deployment costs of smart contracts.

Smart contracts	Helper	AMSC	MFSSC	SCSSC	MSFWSC	ISC
Deployment costs (gas)	561988	1931692	2612793	4916691	609052	2107780

Table 8

The execution costs of smart contracts.

AMSC	1. Register	47045	2. Choose Role	67945	3. Delete Role	60841
MFSSC	1. Publish VSet_F_i	60892	2. Publish Model_F_i	103294	3. Publish Model_FList_F_i	85960
	3  + 4. Publish Last Model_FList_F_i & Merge Model_FList			220703	5. Monitor & Report RES_M	117588
MFSSC	1. Share Resources	83093	2 1). Publish Model_S_j	150063	2 2). Send k_S_j	65173
	3. Review Model_S_j	125860	3  + 4 1) 2) 3). S_j’s Last Review & Merge E_S_j			338450
	3  + 4. Last S_j’s Last Review & Merge Last E_S_j & Estimate E_SList			453995	5. Monitor & Report RES_S	94798
MSFWSC	1. Fuse M&S Monitoring Result RES_MS					74541
ISC	2. Reward Medical Federations		377964	2. Reward Social Collaboration Organizations		934826

Another collaboration cost we consider is the computational time. Besides the original model training time, the computational time includes the contract execution time to realize on-chain interactions. In the blockchain network, users send new transactions to invoke smart contracts, miners sequentially verify, execute and package these transactions to prepare a new block, and the contract execution will only take effect after the new block is added to the main chain. In other words, transactions sent asynchronously by distributed participants but packaged into the same block can be regarded as having the same computational time, namely, block time. Therefore, taking federated surveillance in MFSSC as an example, assuming that in all steps of Algorithm 2, the time differences among all Fs invoking MFSSC for the same phased operations are less than one block time, and their transactions are immediately packaged into the same added block without pending, then, the additional computational time of a model iteration (Step 2 to Step 4) is two block times because Step 3 automatically goes to Step 4 when all Fs finish. Similarly, that in SCSSC (Step 2 to Step 4 in Algorithm 3) is also two block times. Further, since Fs and Ss only simultaneously monitor emerging cases based on the trained models in the future long-term monitoring, the additional contract execution time for each later collaborative early warning is actually two block times (Step 5 in Algorithm 2/3  + Step 1 in Algorithm 4). Considering that the average block time in the virtual blockchain can be easily customized, we refer to that of the existing Ethereum, which is about 13 s, and the two block times are about 26 s, so it is still attractive to most existing EWSs [9].

Incentive mechanisms

For credit scores, our incentive mechanisms are designed as follows:

1) When social participants upload a piece of data and model, they can get 20 scores. When S publishes a , he/she should upload corresponding data and models at the same time, and then gets 20 scores in total;

2) V with credit scores greater than 10 can participate in the validation, and he/she needs to consume 10 scores to review a solution and its corresponding data and models, i.e., ;

3) If a is determined to be invalid after the consensus of all its verifiers, will be punished with 30 scores, and otherwise be rewarded with 10 scores, i.e., ;

4) Taking Vs’ consensus as the correct validation results, every V can get 20 scores for one correct validation, and lose 30 scores for one false validation, i.e., .

In this section, we carry out a numerical simulation experiment to verify the effectiveness of the above incentive mechanisms. Suppose that there are six different participants at the Social End who serve as both social monitors and verifiers. Every participant has 500 solutions, and each solution corresponds to one piece of data and model. In each iteration, they publish a random number of solutions until all their solutions are published. At the same time, they verify a random number of solutions published by other participants, but can only verify a specific solution once. Every participant’s initial credit score is 0. We divide the participants into three types: honest, malicious and lazy (or random), and their settings are as follows:

In each iteration:

Honest participants have a probability of 0.9 to publish valid solutions and give correct verification;

Lazy participants have a probability of 0.5 to publish valid solutions and give correct verification;

Malicious participants have a probability of 0.1 to publish valid solutions and give correct verification.

We set up two experimental scenarios. In both scenarios, 1, 2, 3, 4 are honest participants, and 5 is a lazy participant (baseline). 1) 6 is a malicious participant. As shown in Fig. 6 (a), the credit scores of 1, 2, 3 and 4 gradually increase until all solutions are published. The credit score of 5 fluctuates around 0 and is much lower than honest participants. The credit score of 6 is negative, indicating that he/she has been punished. This shows that the above incentive mechanisms can effectively encourage honest contribution, and reduce motivations for malicious behaviors. 2) 6 is honest in the first three iterations and becomes malicious from the fourth iteration. As shown in Fig. 6 (b), the credit score of 6 increases in the first three iterations, declines sharply in the fourth iteration, and finally stabilizes to negative much lower than the lazy participant. This shows that the above incentive mechanisms can help detect malicious behaviors and punish malicious participants in time. Hence, the proposed EWS can obtain certain anti-attack ability by restricting operation authorities based on credit scores. These experimental results are consistent with our discussion of and in Section 3.3.

Fig. 6

The numerical analysis of incentive mechanisms.

Considering that infectious disease surveillance and early warning usually requires the long-term collaboration of a large number of geographically distributed contributors with different expertise knowledge, EWS with built-in incentive mechanisms based on blockchain, smart contracts and token economics are conducive to fairly quantifying the contribution, accurately evaluating the shared information, and continuously promoting the collaboration of global capable individuals, institutions and organizations.

Traceability and auditability

In our proposed framework, all participants realize collaborative early warning by invoking smart contracts, and their interactive records will be publicly stored on the blockchain, which enables its traceability and auditability. The process of forward fusion and reverse tracing for early warning information is illustrated in Fig. 7 . The black arrow indicates the forward fusion of distributed early warning information described in Section 3.2. Whenever the final fusion results exceed the preset thresholds, the EWS sends out an early warning signal. Then, according to the red arrow, the monitoring results leading to the early warning and their corresponding hospitals, participants, surveillance data, and models can be traced back, and thus the associated suspected cases can be located. Finally, epidemiologists can conduct strict epidemiological investigations or clinical diagnosis on these cases to formally determine the confirmed cases and issue official early warning signals. This traceability and auditability can not only help to quickly locate suspected cases and enrich decision-making information, but also help detect and exclude unreliable cooperators in advance.

Fig. 7

The forward fusion and reverse tracing process of early warning information.

Trusted information sharing and decentralized decision-making

Considering the privacy, unreliability, and fragmentation of multi-source surveillance resources, it is difficult for traditional EWSs to share significant information, solidify decision-making basis, and incorporate untrusted participants. Therefore, in the sharing market at the Social End, the proposed EWS certifies, verifies, and traces all participants, data, models, and solutions in the long-term collaboration, so as to enhance the reliability of shared resources and the credibility of distributed decision-making. Also, smart contracts with preset rules serve as decentralized software-defined agents to monitor, verify, screen out, and fuse multi-party decisions in a real-time fashion and automatically alert, thereby avoiding the decision bias. For private data such as medical records, the proposed EWS adopts a privacy computing architecture, i.e., blockchain-based FL, to improve the performance with privacy protection. And for significant information sharing, it adopts cryptography technology and authority management to encrypt transmission and limit permissions, and thus can achieve private cooperation.

Flexibility and universality

Although we take an early warning scenario for COVID-19 based on open-source chest X-ray data sets as an example to implement our proposed EWS, the system is flexible and universal. By replacing the surveillance data and models, it can monitor various infectious diseases from multiple aspects. For instance, for the known diseases, their symptom surveillance models’ training sets can adopt CT images, electronic medical records, and infectious disease notifications according to their characteristics. While for unknown diseases, semi-supervised or unsupervised models such as clustering [30], principal component analysis (PCA) [55] and generative adversarial networks (GAN) [43], [53] can be adopted for anomaly detection. Additionally, by modifying the fusion algorithms, early warning rules, and incentive mechanisms in the smart contracts, the system can support more collaboration modes, and the design of smart contracts is applicable to different types of blockchain.

Future work

In the future, our work can be extended from the following three aspects:

First, expanding the system to monitor more infectious diseases, support more collaboration modes, and attract more distributed contributors. In this paper, we have demonstrated that smart contracts can encapsulate and execute rules and mechanisms. Therefore, authoritative organizations such as the CDC can similarly define the formal early warning process with different collaborative modes and incentive mechanisms by developing and issuing a variety of formally verified standardized smart contracts, so as to give full play to the crowd intelligence of the society. In addition, the traceable credit and quality records in LM can help participants with limited capability choose honest collaborators and trade high-quality resources, thereby breaking the barriers of surveillance and early warning. And based on these credit and quality records, the fusion weights can also be calculated quantitatively and updated in real-time.

Second, improving security and privacy based on homomorphic encryption [1], trusted computing, and future smart contracts with better performance. Due to the limited capabilities of the current smart contracts, we introduce additional verifiers for off-chain validation at Social End. Whenever verifiers can obtain complete data and models, there is a possibility of leaking and stealing private information. Although effective incentive mechanisms can greatly reduce such motivation, the on-chain model validation and fusion in smart contracts based on homomorphic encryption and trusted computing is still an attractive solution. Homomorphic encryption can maintain parameter privacy when fusing weights, but it requires a series of conversions before being used in complex models such as neural networks. Mendis et al. has made a preliminary attempt. The results show that this method needs complex computation and depends on specific models and homomorphic encryption algorithms, which inevitably lead to the loss of universality [31]. Similar to the idea of Ethereum Layer 2 initiative [48], specialized machine clusters can be built based on the trusted execution environment (TEE) [44] to encapsulate standard algorithms for validation and fusion, complete all the calculations off chain, and only upload the results back to smart contracts, thereby reducing the on-chain computing payload.

Third, enhancing the public’s prevention of unknown diseases based on recommendation algorithms [4] and search engine systems [13]. With the development of unsupervised learning algorithms, the proposed EWS is expected to detect abnormal phenomena in the early stage of unknown diseases, such as the sharp increase of abnormal chest X-ray images at Medical End before the outbreak of COVID-19, which is an important indicator of both COVID-19 and SARS. Although the system can not make a clinical diagnosis, it can be further combined with recommendation and search engine algorithms to determine the disease category according to the characteristics of indicator data, and finally recommend the corresponding universal health suggestions. For example, for the unknown respiratory diseases characterized by a pulmonary infection such as COVID-19 and SARS, the system can automatically issue early warning signals to the public as well as some practical prevention advice for respiratory diseases, such as wearing masks, washing hands and keeping social distance, and thus realize early prevention of unknown diseases.

Conclusion

Aiming at reducing the risk of decision-making errors and improving the performance of early warning, this article proposes a novel framework of collaborative early warning for COVID-19 based on blockchain and smart contracts. This framework features blockchain-based secured and private collaboration environments, scalable warning and incentive mechanisms executed in smart contracts, as well as a variety of encapasulated AI models for early warning. In order to fully combine distributed surveillance forces and integrate multi-source surveillance resources, our proposed system supports two different surveillance modes and fuses their monitoring results on emerging cases to alert, which includes medical federation surveillance based on FL and social collaboration surveillance based on LM. We preliminarily implement and analyze our proposed system based on Ethereum and IPFS. The results show that it has the advantages of decentralized decision-making, fairness, auditability and universality, and also has the potential to further help the early warning and prevention of unknown infectious diseases.

CRediT authorship contribution statement

Liwei Ouyang: Conceptualization, Methodology, Software, Writing - original draft, Writing - review & editing. Yong Yuan: Conceptualization, Writing - original draft, Writing - review & editing, Supervision. Yumeng Cao: Writing - original draft, Writing - review & editing. Fei-Yue Wang: Conceptualization, Supervision, Writing - review & editing.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Algorithm 1. Authority Management Smart Contract.
Input:startPro=False; D_rg, D_rq, FU_p→AMSC, F_lim, S_lim, V_lim, role;
Output:startPro=True; FList, SList, VList, F_dep, S_dep, V_dep;
1: p deposits D_rg to AMSC and registers in project, p←{D_p:D_rg,C_p:0};
2: Before project starts, registered p applies to be F/S/V by executing checkQualifications(p,role) to check:
1) apply with required fund FU_p→AMSC⩾D_rq-D_p; 2) len(FList/SList/VList)⩽F_lim/S_lim/V_lim. If returns True, D_p=D_p+FU_p→AMSC, whenrole=1, FList=FList∪p, F_dep=F_dep+D_p; whenrole=2, SList=SList∪p, S_dep=S_dep+D_p; whenrole=3, VList=VList∪p, V_dep=V_dep+D_p; else throws;
3: Before project starts, confirmed F/S/V applies to delete role and exit project:
whenrole=1, FList=FList⧹p, F_dep=F_dep-D_p; whenrole=2, SList=SList⧹p, S_dep=S_dep-D_p; whenrole=3, VList=VList⧹p, V_dep=V_dep-D_p; at last, AMSC returns FU_AMSC→p=D_p, D_p=0;
4: If the length of FList, SList, and VList are equal to F_lim, S_lim, and V_lim, respectively, project starts, sets startPro=True, and goes to step 5; else goes to step 2 and waits for more F/S/V;
5: returnFList, SList, VList, F_dep, S_dep, V_dep;

Algorithm 2. Medical Federated Surveillance Smart Contract.
Input:{startPro,endMTrain,MFini}={True,False,False}; FList;
Output:{startPro,endMTrain,MFini}={True,True,True}; α_F_i, sucFList, puniFList, RES_M;
1: All F_i∈FList construct a unified VSet:
for each F_i: 1) encrypts VSet_F_i with k_FList, 2) uploads encrypted VSet_F_i on IPFS, and publishes the obtained hash IPFS{Enc{VSet_F_i}_k_FList}, 3) downloads all other VSet_F_i to form VSet locally;
2: All F_i∈FList train Model_F_i on private data sets and publish E_F_i and IPFS{Enc{Model_F_i}_k_FList}. MFSSC computes α_F_i=getContri(E_F_i);
3: All F_i∈FList examine other local models, fuse federated model Model_FList_F_i excluding false models and publish E_FList_F_i. IfF_i rejects F_j, RJ_F_j.push(F_i). When all members finish, goes to step 4;
4: MFSSC obtains the consensus of Model_FList and determines the final sucFList and puniFList: 1) finds consistent E_FList to determine the agreed Model_FList, 2) for each F_i∈FList: ifE_FList_F_i≠E_FList or len(RJ_F_i)⩾(len(FList)-1)/2, puniFList.push(F_i), α_F_i=0; elsesucFList.push(F_i). When finishes, sets endMTrain=True, goes to step 5;
5: If{endMTrain,MFini}={True,False}, all F_i∈sucFList work together to monitor emerging cases based on Model_FList: for each F_i: 1) uploads the amount of positive cases POS_F_i, 2) MFSSC counts the sum POS_M=∑_sucFListPOS_F_i, and publishes the final report RES_M={E_FList,POS_M} to MSFWSC, when finishes, sets MFini=True, goes to step 6;
6: returnα_F_i, sucFList, puniFList, RES_M;

Algorithm 3. Social Collaboration Surveillance Smart Contract.
Input:{startPro,endSTrain,SFini}={True,False,False}; SList, VList, k_S_j, C_rw, C_V+, C_V-;
Output:{startPro,endSTrain,SFini}={True,True,True}; C_S_j, C_V_k, sucSList, puniSList, sucVList, puniVList, RES_S;
1: Social participates share trusted data or models to obtain adequate credit scores for subsequent operations;
2: For the same data set, every S_j∈SList: 1) publishes encrypted solution_S_j’s hash, IPFS{Enc{Model_S_j}_k_S_j}, and E_S_j, 2) calls Send(S_j,V_k,k_S_j) to send k_S_j to sufficient honest verifiers for validation;
3: V_k∈VList⧹(puniVList∪RW_S_j) & S_j≠V_k & C_V_k>C_rw verifies Model_S_j and publishes evaluation EV_S_jk: 1) every review costs credit scores C_rw, C_V_k=C_V_k-C_rw, RW_S_j.push(V_k), 2) ifModel_S_j is invalid, RF_S_j.push(V_k), elseRP_S_j.push(V_k); whenlen(RW_S_j)=Θ_rw, goes to step 4;
4: SCSSC obtains the consensus evaluation of every Model_S_j, determines the collaborative solution set and the sucSList, puniSList and sucVList, puniVList:
1) determines the validity of Model_S_j:
iflen(RP_S_j)⩽len(RF_S_j), Model_S_j is invalid, puniSList.push(S_j), clears E_S_j, α_S_j=0, for each V_k∈RP_S_j, puniVList.push(V_k), C_V_k=C_V_k-C_V-, for each V_k∈RF_S_j, sucVList.push(V_k), C_V_k=C_V_k+C_V+, goes to step 4); elseModel_S_j is valid, goes to step 2),
2) finds consistent EV_S_jVList from all EV_S_jk:
for each V_k∈RW_S_j, ifEV_S_jk=EV_S_jVList & V_k∈RP_S_j, sucVList.push(V_k), C_V_k=C_V_k+C_V+, elsepuniVList.push(V_k), C_V_k=C_V_k-C_V-,
3) compares E_S_j with EV_S_jVList, ifE_S_j=EV_S_jVList and E_S_j>θ_E_S, sucSList.push(S_j), α_S_j=getContri(E_S_j), elsepuniSList.push(S_j), α_S_j=0;
4) iflen(sucSList)+len(puniSList)=len(SList), sets endSTrain=True, SCSSC computes estimated E_SList, goes to step 5; else returns;
5: If{endSTrain,SFini}={True,False}, all S_j∈sucSList work together to monitor emerging cases through a weighted vote: for each S_j∈sucSList: 1) uploads PRED_S_j, 2) MFSSC computes PRED, POS_S=Count(PRED⩾θ_POS_S), and publishes the final report RES_S={E_SList,POS_S} to MSFWSC, when finishes, SFini=True, goes to step 6;
6: returnC_S_j, C_V_k, sucSList, puniSList, sucVList, puniVList, RES_S

Algorithm 4. Medical & Social Fusion Warning Smart Contract  + Incentive Smart Contract
Input:{MFini,SFini,MSFini,endPro}={True,True,False,False}; W_M, W_S, RES_M, RES_S; FList, SList, VList, F_dep, S_dep, V_dep, C_F+, C_F-, C_S+, C_S-; C_F_i, α_F_i, sucFList, puniFList; C_S_j, C_V_k, α_S_j, sucSList, puniSList, sucVList, puniVList;
Output:{MFini,SFini,MSFini,endPro}={True,True,True,True}; R_F_i, C_F_i, R_S_j, C_S_j, R_V_k, C_V_k;
1: MSFWSC fuses the monitoring results RES_MS of all FLists and SLists to alert, ifRES_MS⩾Θ_A, the system alerts; else the system does not alert, when finishes, MSFini=True, goes to step 2;
2: If{MSFini,endPro}={True,False}, ISC compares warning results with authoritative websites, computes and implements participates’ rewards and credits: R_F_i,C_F_i,R_S_j,C_S_j,R_V_k,C_V_k=settleReward(FList,SList,
VList,F_dep,S_dep,V_dep,C_F+,C_F-,C_S+,C_S-,C_F_i,α_F_i,sucFList,puniFList,C_S_j,C_V_k,α_S_j,sucSList,puniSList,
sucVList,puniVList), when finishes, sets endPro=True, goes to step 3;
3: returnR_F_i, C_F_i, R_S_j, C_S_j, R_V_k, C_V_k;