Fair and autonomous sharing of federate learning models in mobile Internet of Things

07/21/2020
by   Xiaohan Hao, et al.
0

Federate learning can conduct machine learning as well as protect the privacy of self-owned training data on corresponding ends, instead of having to upload to a central trusted data aggregation server. In mobile scenarios, a centralized trusted server may not be existing, and even though it exists, the delay will not be manageable, e.g., smart driving cars. Thus, mobile federate learning at the edge with privacy-awareness is attracted more and more attentions. It then imposes a problem - after data are trained on a mobile terminal to obtain a learned model, how to share the model parameters among others to create more accurate and robust accumulative final model. This kind of model sharing confronts several challenges, e.g., the sharing must be conducted without a third trusted party (autonomously), and the sharing must be fair as model training (by training data)is valuable. To tackle the above challenges, we propose a smart contract and IPFS (Inter-Planetary File System) based model sharing protocol and algorithms to address the challenges. The proposed protocol does not rely on a trusted third party, where individual-learned models are shared/stored in corresponding ends. Conducted through extensive experiments, three main steps of the proposed protocol are evaluated. The average executive time of the three steps are 0.059s, 0.060s and 0.032s, demonstrating its efficiency.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

08/14/2021

Collaborative Unsupervised Visual Representation Learning from Decentralized Data

Unsupervised representation learning has achieved outstanding performanc...
01/21/2022

Blockchain-based Collaborated Federated Learning for Improved Security, Privacy and Reliability

Federated Learning (FL) provides privacy preservation by allowing the mo...
12/07/2018

Reaching Data Confidentiality and Model Accountability on the CalTrain

Distributed collaborative learning (DCL) paradigms enable building joint...
05/20/2021

A Dispersed Federated Learning Framework for 6G-Enabled Autonomous Driving Cars

Sixth-Generation (6G)-based Internet of Everything applications (e.g. au...
06/21/2019

B-Ride: Ride Sharing with Privacy-preservation, Trust and Fair Payment atop Public Blockchain

Ride-sharing is a service that enables drivers to share their trips with...
09/12/2017

Interpreting Shared Deep Learning Models via Explicable Boundary Trees

Despite outperforming the human in many tasks, deep neural network model...
03/18/2019

Securely Trading Unverifiable Information without Trust

In future, information may become one of the most important assets in ec...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Data fusion and learning from various data sources provides more information dimensions than single data sources. For example, a bank records user property, revenue and expenditure records, and an e-commerce platform has participant browsing records, purchase records and collection records. If these two types of data can be integrated, a product recommendation system based on artificial intelligence (AI) can be realized. Accessing to various data sources, however, faces the following challenges: barriers between data sources are hard to break, and data islands exist; participants may not know the future use of models, thus less motivated to contribute data, and model transactions violate laws and regulations  [1].

Federal transfer learning effectively overcomes these challenges to a certain extent. In federated learning, a mobile terminal trains self-owned data to its individual-learned model and sent to a central trusted server. Then the server collects and summarize individual-learned models from mobile terminals to create more accurate and robust accumulative final model. During the whole training process, data are trained on each mobile terminal, which does not need to be uploaded to a centralized server, but how to securely and fairly share the model parameters to others who as well desire these parameters needs to be addressed. In general, sharing models saves time and cost of training models, and makes models widely used. For example, as a buyer, using others’ models can save the time of training new models. On the other hand, as a seller, it is more efficient to transfer parameters instead of the whole model. Existing work  

[26, 27, 28, 29] based on blockchain do not meet the requirements: (a) no trusted third parties, (b) fairness, and (c) publicly verifiable at the same time.

  • (a) In mobile scenarios, a centralized trusted server may not be existing, and even though it exists, the delay will not be manageable. Thus, the sharing must be conducted without a third trusted party (autonomously).

  • (b) The sharing must be fair as model training (by training data)is valuable. Thus, a verification mechanism after receiving it also needs to be proposed.

  • (c) Another challenge is that all data on the smart contract is publicly accessible to all, which complicates the design of privacy protection methods.

In this paper, we propose a model sharing protocol and algorithms without the need of a trusted third party. The proposed protocol is based on smart contract and IPFS (Inter-Planetary File System). We request the contracting parties to upload the model files to IPFS, and use the combination of symmetric key and public key encryption system in the process of address transfer, so as to meet the traceability and non-tamperability. In other words, our scheme can protect the privacy of the buyer and the seller. Besides, fairness is provided: the buyer obtains the model through purchasing/exchanging, and the seller obtains the token/model at the same time. Any participant can report each other’s cheating behavior. Moreover, publicly verifiable is provided via identify cheating participants due to the verification mechanism through low-quality (accuracy rate <50%) parameters. In addition to privacy protection and fairness, the scheme also realizes autonomy. The contributions of this paper are as follows:

  • We propose a model sharing scheme based on a smart contract, in which the buyer and the seller can complete the transaction independently without a third trusted party (autonomously).

  • The method can meet the requirement with fairness as model training (by training data)is valuable. We propose to classify the model according to the accuracy rate of parameters, that is, high-quality (accuracy rate >90%) parameters are used for buying and selling, low-quality (accuracy rate <50%) parameters are used for verification, so as to ensure the fairness of the transaction and avoid any fraud between the buyer and the seller.

  • The method can meet the requirement with traceability and non-tamperability, we request the contracting parties upload the model files to IPFS(Inter-Planetary File System), so as to obtain the file address, which can reduce the storage pressure of the smart contract.

The rest of the paper is organized as follows. Section II gives an overview of the relevant previous work. In Section III, we propose our system model and the corresponding adversary model. Section IV illustrates the proposal and implementation of our scheme . In Section V, we evaluate the security and performance of our scheme. Finally, Section VI concludes the paper.

Ii Related Works

Ii-a Smart Contract

Blockchain is becoming more and more popular and has many applications in a wide range of industries [2, 3]. A popular instance of blockchain is smart contract, which is also used for different settings [4, 5, 6]. Smart contract can support automatic programming execution in a distributed way. It is a kind of computer protocol that spreads, verifies or executes the contract in an autonomous way. Besides, trusted transactions can be executed without a third party through smart contract, which can also meet the requirement with traceability and non-tamperability. In addition, smart contract can run on the virtual machine of Ethereum. Each node of Ethereum provides computing power, and they also pay with the digital currency of Ether as the resource. All participants of the blockchain can see smart contract and operate transactions according to these unified protocol.

Recently, more and more people are paying attention to the research of blockchain, from designing new cipher primitives to supporting different functions, to identifying vulnerabilities in smart contracts, and so on. At the same time, due to the growing interest in artificial intelligence (AI), there are also some attempts to use AI technology for vulnerability detection in smart contracts. For example, Jiang[7], Mavridou[8], Wu[9] put forward some relevant methods. Besides, smart contract is written in a stable format and then can be sent to the blockchain in the byte code format of the Ethereum Virtual Machine (EVM). Grishchenko [10] proposed the first complete small step semantics of EVM bytecode and formalized the proof assistant. This allows them to obtain executable code which can then be used to validate against the official Ethereum test suite. Tikhomirov[11] provided code problems and implements an extensible static analysis tool, SmartCheck, which can convert reliable source code into XML based intermediate representation and check the representation according to the XPath pattern. In addition, Zhou[12] proposed a security assurance method for smart contract source code to detect potential security risks, which mainly includes two functions. One is to analyze the syntax and topology of the call relationship of the smart contract, the other is to detect and locate the logical risks that may lead to vulnerabilities, and mark the results on the topology.

Ii-B Federated Learning in Industrial IoT

With the rapid development of intelligent mobile terminals, various industrial Internet of Things applications can make full use of them to collect and share data to provide specific services [13]. However, the main challenge in Industrial IoT is that there are barriers between data sources are hard to break, and data islands exist. In addition, the security of the Internet of Things ecosystem is worth studying, such as malicious attackers, adversarial attacks and sinkhole attacks [14]. In recent years, many scholars put forward some related methods to tackle the above challenge. The concept of federated learning was put forward by Google [15, 16, 17], and their purpose is building a machine learning model on the premise of not disclosing data, that is, participants can protect the privacy of self-owned training data on corresponding ends, instead of having to upload to a central trusted data aggregation server. Zhu [18]

applied federated learning with a deep convolutional network to perform variable-length text string recognition with a large corpus. They compared two frameworks (Tensorflow Federated and PySyft) to show the federal text recognition model can achieve similar or even higher accuracy than the model trained on the deep learning frameworks. Song

[19] proposed cloud-based architecture inspired by federated learning, which enables the sharing of defense capabilities against different attacks among IIoT devices. In addition, in order to prevent private data leakage, Zhang [20] proposed two privacy-preserving asynchronous deep learning schemes and Hao [21] proposed an efficient and privacy-enhanced federated learning scheme.

Ii-C The Application of Blockchain in Federated Learning

Federate learning can conduct machine learning as well as protect the privacy of self-owned training data on corresponding ends, instead of uploading to a central trusted data aggregation server. However, there are also some challenges need to be tackled, such as how to reduce the load and how to ensure the data security and the accuracy of the model. In recent years, many scholars have mentioned the combination of blockchain and federated learning. Kim [26] proposed blockchain based federated learning scenario in order to minimize the network load, that is, blockchian can not only promise the integrity and stability, but induce participants to participate in learning and separate them into some separate nodes. Majeed [27] proposed a federated learning security architecture (FLchain) based on blockchain network which stores the local model parameters for each global iteration as blocks on a channel-specific ledger. Besides, an EOS Blockchain design and workflow was proposed by Martinez [28] in order to establish data security. They also implement a small example of their blockchain federated learning model to analyze its performance. Kim [29] proposed a blockchained federated learning (BlockFL) architecture, which can exchange and verify the update of local learning model. By taking advantage of the consensus mechanism in the blockchain, learning models on corresponding ends does not require any centralized training data or coordination. Besides, Lu [30] integrated federated learning into the consensus process of licensed blockchain, so that the calculation of consensus can be used for federated training.

Iii Problem Formulation

Iii-a System Framework

In our scheme, we assume that there are two participants: the seller (such as Alice) and the buyer (such as Bob). To reduce the workload of model sharing, we divide the scheme transaction into two parts: exchange model and transaction model. If the model is equivalent, they can exchange their models, otherwise transaction their models.

We classify models according to their parameters, low-quality (accuracy <50%) parameters are used to prove, and high-quality (accuracy >90%) parameters are used to transaction. In the process of verifying models, we use a manual verification mechanism of blockchain nodes and a random selection verification mechanism. Buyers can confirm the accuracy of the model, and sellers can ensure that the verification data provided by buyers is reliable. In order to avoid buyers deliberately providing invalid verification data sets, buyers have to provide the verification data before transactions start, and store them in plaintext on blockchain, so that both parties can confirm the validity of the data.

Fig. 1: System Framework - Trading models

In addition, the whole transaction process is completely controlled by smart contract. Alice and Bob respectively package and publish the purpose of their models to blockchain sales chain and pay deposits to smart contract. After Bob pays the token to the smart contract, Alice packages the model’s purpose, structure, parameters with accuracy higher than 90%, input and output format, and 20% test set data (which can be adjusted appropriately according to the buyer’s quotation, that is, the higher the quotation, the more training set data can be given) into a model file and uploads to IPFS to obtain corresponding address. Next, Alice sends this address to Bob. After receiving this model file, Bob checks whether the accuracy of the model meets the requirements through the received training set. If it meets the requirements, Bob triggers the confirmation receipt mechanism within the stipulated time, and Alice receives the token; otherwise, Bob triggers the verification mechanism.

After completing transaction, Alice gets the token and Bob gets the required model. During the whole transaction, any suspected cheating will be punished. The model transaction process is shown in Fig. 1, and the model exchange process is shown in Fig. 2.

Fig. 2: System Framework - Exchanging Models

Iii-B Adversary Model

There are some potential threats in transactions. We classify these threats into following categories:

Threats from a dishonest seller. The seller provides invalid or low accuracy model parameters, which will result in the inability to meet the requirements of the buyer and the fairness of the transaction. In our scheme, we adopt a verification and voting mechanism through the manual verification of blockchain nodes. If the number of confirming the correctness of the model is more than 60% of all nodes, the buyer’s deposit will be awarded to the seller and the participated nodes; otherwise, the seller’s deposit will be awarded to the buyer and the participated nodes.

The seller intentionally provides false model verification parameters, which will cause the buyer’s verification mechanism to be invalid and cannot satisfy the fairness of the transaction. In order to avoid such behavior, in the verification process, buyers can randomly select 2 or 3 parameters and provide parts of data sets for verification, so as to confirm the accuracy of the model.

The seller provides a non-existent address. Obviously, when buyers discover that the address does not exist, they can claim within the time specified by the system.

The model sold by the seller is not consistent with the advertising model. For example, the seller replaces the advertising model with another model. Due to the use of the IPFS file system, any changes in the data will cause a corresponding address change. Thus, this is evidence which can be used later.

Threats from a dishonest buyer. The buyer intentionally provides an invalid verification data set, which will result in the seller’s failure to receive payment and unable to meet the fairness of the transaction. In order to avoid such behavior, the buyer has to provide data and store in plaintext on blockchain before transactions starts, and the validity of the data is confirmed by both buyer and seller, so as to avoid the buyer’s regret during the verification. Since the submitted data is small part of real data or structured data, as a buyer, he can accept data exposure under the circumstances.

After the buyer receives the model, he refuses to trigger the confirmation receiving mechanism within a certain period of time, which will lead to the seller’s failure to receive payment and cannot meet the fairness of the transaction. Such behavior will confiscate the buyer’s deposit and blacklist the buyer (i.e., record such dishonest behavior on the blockchain).

After receiving the purchased model which the value is higher than deposit, the buyer terminates the transaction abnormally. In our scheme, the margin amount is required to be equal to or higher than the transaction amount, so the cheating motivation of terminating the transaction abnormally is eliminated.

The buyer initiates the transaction multiple times by completing any of these transactions, which will take up resources and lead to denial of service. There are many ways to avoid this behavior, for example, we can record the number of transactions initiated by the buyer and limit the number of daily transactions per participant. In other words, if the number of duplicate transactions exceeds the limit and none of these transactions are completed, the system will block further transaction service requests from the same participant for a predetermined period of time (for example, 24 hours).

Attacks from others. A man-in-the-middle attack is one in which normal network traffic is intercepted or data is tampered with or sniffed without either party knowing it. In our scheme, the attacker can act as a middleman, forming two pairs of keys between buyers and sellers, decrypting, encrypting, and forwarding the model files. In order to avoid these attacks, we use the combination of symmetric and asymmetric cryptography to encrypt the model files, so as to ensure the confidentiality and integrity of the transmitted contents.

Attackers impersonate sellers or buyers to steal data. We use address based authentication and use smart contract to mitigate these attacks.

The contract is under attack. Attackers can steal tokens in smart contracts or disrupt the normal transaction order, causing economic losses to both buyers and sellers. In this paper, we assume that the smart contract is secure.

Iii-C Design Goals

In this section, we will explain the design goals of our scheme:

  1. Fairness: after the transaction is terminated normally, Bob gets the model he needs, and Alice receives the sales revenue. Any alleged misconduct will be investigated and punished (for example, confiscating deposit or blacklisting).

  2. Autonomy: the transaction and verification process are controlled by smart contract. Smart contract has the characteristics of high timeliness and decentralization of contract formulation and it does not rely on the participation of the third-party authority or central organization, which greatly reduces the intermediate link of protocol formulation and improves the efficiency of protocol formulation. In addition, smart contract has high accuracy and does not need human participation, which eliminates mistakes and improves the accuracy of the contract.

  3. Confidentiality and non-tamperability: in the process of transmitting address, we use the combination of symmetric and asymmetric cryptography to prevent man-in-the-middle attacks and ensure the confidentiality of transactions. The seller has to upload the model file to IPFS to obtain the corresponding address. Due to the characteristics of IPFS, any change will cause the address to change, which ensures the model file can not be tampered.

  4. Time control: the transaction must be completed within the specified time. Failure to complete the specified steps within the specified time will be punished (e.g., deduct the deposit).

Iv Proposal and Implementation of the Scheme

Next, we will detail the components of our proposed solution in six modules. Table I lists the specific meanings of the symbols used.

 

Model’s data
Partial training set of the model
Bob’s symmetric key
Alice’s public key
Alice’s private key
Address of Alice’s model file in IPFS
Address of Bob’s model file in IPFS
Q A random number generated by random number generator
The price of the model
MA Address of model file

 

TABLE I: Notation

Iv-a The Process of Exchanging Models

In this section, we will elaborate the process of exchanging models, and the specific process is shown in Fig. 3.

Fig. 3: The Process of Exchanging Models
  1. Alice and Bob respectively package and publish the purpose of their models to the blockchain sales chain and pay corresponding deposit to smart contract;

  2. Bob asks Alice the price of the model which he desires. Alice views the models that Bob owns. If Bob has the model that Alice interests, go to step 3; otherwise, go to step 4;

  3. Alice packages the model’s price and sends to Bob, and then asks for the price of the model that Alice interests;

  4. Bob packages the model’s price and sends to Alice;

  5. If the prices of Alice and Bob’s models are equivalent, they can exchange models directly. Alice and Bob respectively package the model’s purpose, structure, parameters with accuracy higher than 90%, input and output format, 20% (which can be adjusted appropriately according to the buyer’s quotation) into and upload to IPFS to obtain the corresponding address;

  6. Alice and Bob obtain the address through the specific address transfer process and obtain the corresponding model file from IPFS;

  7. Inspection by both parties: check whether the accuracy of the model meets the requirements through the received training set. If it meets the requirements, triggering the confirmation receiving mechanism within the stipulated time. Otherwise, triggering verification mechanism.

Iv-B The Process of Trading Models

In this section, we will elaborate the process of trading models and the specific algorithm of smart contract processing is shown in Algorithm 1.

Input: deposit of Alice DepositA, deposit of Bob DepositB, , , Token, TimeLimit
Output: result of the transaction , time when the transaction starts TimeStart
Alice sets the amount of DepositA, DepositB and ; Alice sends the function of the model to the selling chain; Alice sends DepositA to the smart contract, TimeStart = now; if  The amount of DepositA is right then
       Alice uploads and TimeLimit to the smart contract, and the smart contract records the time now as TimeStart;
       if   then
             Bob sends DepositB to the smart contract and ask the ;
             Alice sends to Bob;
             if The amount of DepositB is right then
                   Alice sends to IPFS;
                   Alice gets from IPFS;
                   Alice sends encrypted to the smart contract;
                   if Bob receives  then
                         Bob sends Token to the smart contract;
                         if  is right then
                               Bob triggers confirm receipt mechanism;
                               Result Trans = true;
                               Bob triggers verification mechanism;
                               Result Trans = false;
                        else
                              The smart contract waits for Bob to receive ;
                              
                        
                  else
                        The smart contract refuses DepositB;
                        
                  
            else
                   Alice or Bob ends the transaction;
            
      else
            The smart contract refuses DepositA;
      
Algorithm 1 Smart Contract for Transaction
  1. The first four steps of trading models are the same as 1-4 in  IV-A;

  2. If the prices of Alice and Bob’s models are inequivalent, they have to trade models. Bob gives tokens to smart contract. Next, Alice packages the purpose of the model, (the way to use the model), structure, parameters with accuracy higher than 90%, input and output formats, 20% of the (according to the buyer offer appropriate adjustments) into a model file and upload to IPFS to obtain the corresponding address;

  3. Bob obtains the address through the specific address transfer process and downloads the corresponding model file from IPFS;

  4. Buyer’s inspection: Bob checks whether the accuracy of the model meets the requirements according to the received training set. If it meets the requirements, after triggering the confirmation receiving mechanism within the stipulated time, Alice receives Bob’s token; otherwise, Bob triggers verification mechanism.

Iv-C The Process of Transferring Address

In this section, we will elaborate the process of transferring address and the specific process is shown in Fig. 4.

Fig. 4: The Process of Transferring Address
  1. Bob uses random number generator to generate random number Q and hash it to get H(Q);

  2. Bob encrypts and H(Q) with Alice’s public key , and then sends to Alice through ’s encryption;

  3. Alice uses decryption to get . After confirming Bob’s ID, Alice decrypts through to get Bob’s symmetric keys and H(Q);

  4. Alice uses to encrypt the model file address , and sends to Bob through ’s encryption;

  5. B obtains through ’s decryption.

Iv-D Verification Mechanism

If the model’s accuracy does not meet the requirements, the buyer triggers the verification and voting mechanism through some participated nodes on blockchain, the specific steps are as follows:

  • The seller provides multiple model parameters with accuracy less than 50% to the participated nodes;

  • The buyer randomly selects two or three parameters and provides part of the data set for verification;

  • We adopt voting mechanism, that is, if the number of confirming the correctness of the model is more than 60% of all nodes, the buyer’s deposit will be awarded to the seller and the participated nodes; otherwise, the seller’s deposit will be awarded to the buyer and the participated nodes.

In this process, we adopted the model parameters with accuracy less than 50%, because if the accuracy is too high, the model will be exposed directly and buyer does not have to buy it. Besides, the purpose of the buyer’s random selection is to ensure the validity of the data provided by the verification provider, so that the buyer can confirm the accuracy of the model and the seller can ensure that the verification data provided by the buyer is reliable. In addition, in most cases, the inspection is done by the buyer. Only when the verification mechanism is triggered can the models be inspected through the node verification mechanism. In this way, the workload can be reduced to a certain extent.

In addition, in order to encourage participation in the transaction, we adopt the incentive mechanism: the part of the transaction is used to reward both buyers and sellers in equal proportion. Besides, in order to encourage nodes participating in the verification mechanism, we also give them the corresponding bonus. In order to ensure the fairness of the transaction, both buyers and sellers should pay deposits to smart contract before transactions start. During the process of the transaction, if they violate rules, the corresponding deposit will be confiscated.

Iv-E Time Control

In order to improve fairness, we set several time limits. Within each limit, Alice and Bob need to complete corresponding work. The specific definitions are as follows:

  • : Alice and Bob need to pay DepositA and DepositB respectively to smart contract within . Otherwise, if the transaction is terminated, the deposit previously paid will be refunded.

  • : In the process of exchanging model, Alice and Bob need to upload the model file to IPFS in time, otherwise the transaction will be terminated. In the process of model transaction, Alice needs to upload model files to IPFS in . At the same time, Bob needs to submit token to smart contract, otherwise the transaction will be terminated.

  • : In the process of exchanging model, Bob should transmit the encrypted symmetric key to Alice in time, and Alice should transmit the encrypted symmetric key to Bob, otherwise the transaction will be terminated. In the process of model transaction, within , Bob should pass the encrypted symmetric key to Alice, otherwise the transaction will be terminated.

  • : In the process of exchanging model, Alice and Bob should transmit the addresses of their model files to each other through key encryption within time, otherwise the transaction will be terminated. In the process of model transaction, within , Alice should pass the encrypted to Bob, otherwise the transaction will be terminated.

  • : We set a buffer time to ensure Bob has enough time to complete the inspection. At the same time, Alice can not extract the token until Bob triggers the confirmation receipt mechanism or exceeding . After time, DepositA and DepositB will be sent back to Alice and Bob through smart contract.

Iv-F Discussion

We also consider how to speed up the verification while ensuring the accuracy of the verification, so we propose reducing the number of verification nodes. Our scheme adopts incentive mechanism, which uses part of the deposit as bonus to reward the participated nodes in the verification. To reduce bonus, reducing the number of verification nodes has become an advanced scheme. However, how to ensure the fairness and accuracy while reducing the number of nodes? If the verification nodes can be randomly selected online, this goal can be achieved, and some malicious attacks can also be avoided. In the future work, we consider improving our scheme from the following aspects: reducing communication, calculation, time delay and improving security (including fault tolerance, anti node compromise rate).

V Security and Performance Analysis

V-a Fairness Analysis

If both Alice and Bob are honest, the transaction will be completed successfully, which can be regarded as the best case. However, some unexpected situations are also occurred. Thus, we need to use the record on smart contract as evidence to identify the abnormal steps or punish the offending participants. In addition, we adopt deposit mechanism, that is, the deposit of the offending party will be confiscated and paid to the other party.

The amount of deposit we set is higher than the model bid price, which will prevent Alice or Bob abnormally terminating the transaction after they obtain models.

Before transactions start, it is necessary to judge whether the models’ prices are equivalent or not. If equivalent, they can exchange models directly; otherwise, they have to trade models. In this way, the fairness of transaction can be meet and some unequal exchanges can be avoided.

Within the time period when the model is received but the confirm receipt mechanism is not triggered, both Alice and Bob can raise objections about the transaction process. Therefore, if Bob claims he does not get the address of the model file provided by Alice, he can trigger verification mechanism. The The participated nodes judge which one is lying and deducts the corresponding deposit.

In the verification mechanism, we give the buyer two or three chances to randomly select model parameters to ensure the validity of the data provided by the verification provider, so that the buyer can confirm the accuracy of the model and the seller can ensure that the verification data provided by the buyer is reliable, which meets the fairness of the transaction.

V-B Security Analysis

In this section, we will evaluate our solution from a security perspective.

Traceability and Non-tamperability: our scheme adopts IPFS and smart contract, the process of sharing model can avoid the existence of semi-honest third party and meet traceability and non-tamperability.

Confidentiality and Integrity: the confidentiality means data will not be disclosed to unauthorized participants. The integrity means data cannot be tampered with (for example, inserted, modified, deleted, and reordered) without authorization. Due to the non-tamperability of IPFS and the traceability of smart contract, our scheme can prevent unauthorized access and tampering, which meets confidentiality and integrity.

Prevent Man-in-the-middle attacks: the general process of delivering address is easy to be attacked by others. We assume that the attacker is C, the seller is A, and the buyer is B. The third party C acts as receiver B when communicating with A, or acts as B when communicating with the receiver A. In this case, both A and B negotiate a key with C, which can monitor and transmit transactions. MITM attacks are described as follows: B encrypts and H (Q) with A’s public key , and sends to A through encryption; C attempts to intercept and parse the message. C cannot get because he does not have a private key . So our scheme can effectively prevent MITM attacks.

Fig. 5: The Time Consuming of Exchanging Models

V-C Performance Analysis

We evaluate the scheme in terms of the consumed time of the major three steps in protocols. In the experimental transmission process, we use RSA and DES to ensure the confidentiality and integrity of the message. The specific system environment configuration is shown in Table II, and the specific time consumption is shown in the Fig. 5. Three lines in the figure represent three steps of exchanging models in Fig. 3. The average time of the three steps is respectively 0.059s, 0.060s and 0.032s, which shows that our scheme is feasible.

 

The project name Hardware version number or condition
Operating system Windows 10
Development environment python3.8
Programming language Python

 

TABLE II: System Environment Configuration

V-D Industrial applications

As shown in Fig. 6, the data (including images, videos, etc.) of each node in the industrial Internet of Things needs to be distributed in-stu machine learning to obtain and share relevant smart information. For example, a video camera node on a factory’s production line learns and obtains product pass rate information and shares it with another factory’s node to control the raw material supply of the product.

Fig. 6: Industrial Applications

Vi Conclusions

In this paper, we propose a scheme consisting of sharing protocol and dedicated algorithms. We implement our scheme by smart contract and IPFS (Inter-Planetary File System). The scheme we proposed ensures that the private data will not be disclosed in model sharing to implement privacy protection. In addition, we use smart contracts to avoid third party entities. In our scheme, we also introduce validation control and time control to improve the fairness and automation of sharing models. In addition, we evaluate the scheme in terms of the consumed time of the major three steps in protocols. The average time of three steps is respectively 0.059s, 0.060s and 0.032s, which justified that our scheme is feasible. In the future work, we consider improving our scheme from the following aspects: reducing communication, calculation and time delay, and improving the security (including fault tolerance, anti node compromise rate).

Data Availability statement

The [code] data used to support the findings of this study have been deposited in the [IEEE DATAPORT] repository ([10.21227/e0a4-s681]).

Acknowledgment

The research was financially supported by National Natural Science Foundation of China (No.61972366), the Foundation of Key Laboratory of Network Assessment Technology, Chinese Academy of Sciences (No. KFKT2019-003), the Foundation of Guangxi Key Laboratory of Cryptography and Information Security (No. GCIS201913), and the Foundation of Guizhou Provincial Key Laboratory of Public Big Data (No. 2018BDKFJJ009, No. 2019BDKFJJ003, No. 2019BDKFJJ011).

References

  • [1] Q. Yang, Y. Liu, T. J. Chen, and Y. X. Tong. Federated Machine Learning: Concept and Applications, ACM Transactions on Intelligent Systems and Technology, 2019, vol. 10, pp. 19.
  • [2]

    G. Bigi, A. Bracciali, G. Meacci, E. Tuosto. Validation of Decentralised Smart Contracts Through Game Theory and Formal Methods, Springer International Publishing, Cham, 2015, pp. 142-161.

  • [3] F. Hawlitschek, B. Notheisen, T. Teubner. The limits of trust-free systems: A literature review on blockchain technology and trust in the sharing economy, Electronic commerce research and applications , 2018, vol. 29, pp. 50-63.
  • [4] N. Atzei, M. Bartoletti, T. Cimoli. A survey of attacks on ethereum smart contracts (sok), Principles of Security and Trust, 2017, pp. 164-186.
  • [5] M. Bartoletti, L. Pompianu. An empirical analysis of smart contracts: Platforms, applications, and design patterns, Financial Cryptography and Data Security, 2017, pp. 494-509.
  • [6] P. Siano, G. D. Marco, A. Rolan, V. Loia. A survey and evaluation of the potentials of distributed ledger technology for peer-to-peer transactive energy exchanges in local energy markets, IEEE Systems Journal, 2019, vol. 99, pp. 1-13.
  • [7] B. Jiang, Y. Liu, W. Chan. Contractfuzzer: Fuzzing smart contracts for vulnerability detection, Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, 2018, pp. 259-269.
  • [8] A. Mavridou, A. Laszka. Designing secure ethereum smart contracts: A finite state machine based approach, International Conference on Financial Cryptography and Data Security, 2018, pp. 523-540.
  • [9] W. Fang, J. Wang, J. Liu, W. Wei. Vulnerability detection with deep learning, IEEE International Conference on Computer and Communications, 2018, pp. 1298-1302.
  • [10] I. Grishchenko, M. Maffei, C. Schneidewind. A semantic framework for the security analysis of ethereum smart contracts, International Conference on Principles of Security and Trust, 2018, pp. 243-269.
  • [11] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev, Y. Alexandrov. Smartcheck: static analysis of ethereum smart contracts, 2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), 2018.
  • [12] E. Zhou, S. Hua, B. Pi, J. Sun, Y. Nomura, K. Yamashita, H. Kurihara. Security assurance for smart contract, Mobility and Security(NTMS), 2018, pp. 1-5.
  • [13]

    C. H. Liu, Q. Lin and S. Wen. Blockchain-Enabled Data Collection and Sharing for Industrial IoT With Deep Reinforcement Learning, IEEE Transactions on Industrial Informatics, vol. 15, no. 6, pp. 3516-3526, 2019.

  • [14] Y Liu, M Ma, X Liu, N Xiong, A Liu, Y Zhu, Design and analysis of probing route to defense sink-hole attacks for Internet of Things security, IEEE Transactions on Network Science and Engineering, 2018.
  • [15] J. Konecný, H.B. McMahan, D. Ramage,et al. Federated optimization: Distributed machine learning for on-device intelligence, ArXiv preprint, 2016, vol. abs/1610.02527.
  • [16] J. Konecný, H.B. McMahan, D. Ramage,et al. Federated learning: Strategies for improving communication efficiency, ArXiv preprint, 2016, vol. abs/1610.05492.
  • [17] H. B. McMahan, E. Moore, D. Ramage,et al. Federated learning of deep networks using model averaging, ArXiv preprint, 2016, vol. abs/1602.05629 (2016).
  • [18] X. Zhu, J. Wang, Z. Hong, T. Xia and J. Xiao, Federated Learning of Unsegmented Chinese Text Recognition Model, 2019 IEEE 31st International Conference on Tools with Artificial Intelligence (ICTAI), pp. 1341-1345, 2019.
  • [19] Y. Song, T. Liu, T. Wei, X. Wang, Z. Tao and M. Chen, FDA3: Federated Defense Against Adversarial Attacks for Cloud-Based IIoT Applications, IEEE Transactions on Industrial Informatics, 2020.
  • [20] X. Zhang, X. Chen, J. K. Liu and Y. Xiang, DeepPAR and DeepDPA: Privacy Preserving and Asynchronous Deep Learning for Industrial IoT, IEEE Transactions on Industrial Informatics, vol. 16, no. 3, pp. 2081-2090, 2020.
  • [21] M. Hao, H. Li, X. Luo, G. Xu, H. Yang and S. Liu, Efficient and Privacy-Enhanced Federated Learning for Industrial Artificial Intelligence, IEEE Transactions on Industrial Informatics, vol. 16, no. 10, pp. 6532-6542, 2020.
  • [22] K. Bonawitz, V. Ivanov, B. Kreuter, A. Marcedone,et al. Practical secure aggregation for privacy-preserving machine learning, Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS’17), 2017, pp. 1175-1191.
  • [23] R. C. Geyer, T. Klein, and M. Nabi. Differentially private federated learning: A client level perspective, ArXiv preprint, 2017, vol. abs/1712.07557. arxiv:1712.07557.
  • [24] V. Smith, C. Chiang, M. Sanjabi, and A.S. Talwalkar. Federated multi-task learning, Advances in Neural Information Processing Systems 30, 2017, pp. 4424-4434.
  • [25] S. Q. Wang, T. Tuor, T. Salonidis,et al. Adaptive Federated Learning in Resource Constrained Edge Computing Systems, IEEE Journal on Selected Areas in Communications, 2019, vol. 37, no. 6, pp. 1205-1221.
  • [26] Y. J. Kim and C. S. Hong. Blockchain-based Node-aware Dynamic Weighting Methods for Improving Federated Learning Performance, 2019 20th Asia-Pacific Network Operations and Management Symposium (APNOMS), 2019, pp. 1-4.
  • [27] U. Majeed and C. S. Hong. FLchain: Federated Learning via MEC-enabled Blockchain Network, 2019 20th Asia-Pacific Network Operations and Management Symposium (APNOMS), 2019, pp. 1-4.
  • [28] I. Martinez, S. Francis and A. S. Hafid. Record and Reward Federated Learning Contributions with Blockchain, 2019 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC), 2019, pp. 50-57.
  • [29] H. Kim, J. Park, M. Bennis and S. Kim. Blockchained On-Device Federated Learning, IEEE Communications Letters, 2019, pp. 1-1.
  • [30] Y. Lu, X. Huang, Y. Dai, S. Maharjan and Y. Zhang, Blockchain and Federated Learning for Privacy-Preserved Data Sharing in Industrial IoT, IEEE Transactions on Industrial Informatics, vol. 16, no. 6, pp. 4177-4186, 2020.