A secure and scalable federated learning method based on blockchain

Abstract

The present invention discloses a secure and scalable federated learning method based on blockchain, which is characterized by separating blockchain nodes, client nodes and aggregation nodes from each other, making the responsibilities of each node clear, and requiring low computing power and storage for client nodes, thereby reducing the entry threshold for client nodes. Blockchain nodes are responsible for running smart contracts to ensure the effective and safe operation of the entire blockchain federated learning system. Client nodes are responsible for model training and model verification. Aggregation nodes are responsible for aggregating global models and storing local models of global models and client nodes. The use of hash commitments and verifiable random functions (VRFs) can effectively prevent inference attacks and Byzantine attacks.

Description

Technical Field

[0001] The present invention relates to the field of federated learning, and more particularly to a secure and scalable federated learning method based on blockchain. Background Art

[0002] Traditional machine learning frameworks usually require terminal devices to transmit collected data to a central server for model training, which increases the risk of privacy leakage.

[0003] To solve the above problems, federated learning was proposed. The main feature of federated learning is to ensure user privacy. Federated learning allows multiple terminal devices to collaboratively train a machine learning model. Unlike traditional machine learning frameworks, federated learning does not require data owners to transfer original data to a central server, but only uploads model parameters trained by local data. This can effectively prevent privacy leakage and avoid data silos. However, traditional federated learning still faces many problems such as single point failure and Byzantine attacks.

[0004] As an emerging technology, blockchain has the characteristics of decentralization, anonymity and traceability, and has been applied in many fields such as cryptocurrency, healthcare, smart cities, and the Internet of Things. In blockchain, smart contracts are low-level code scripts that run on the blockchain. As programs running on the blockchain, smart contracts can be correctly executed by a network of mutually untrusted nodes without the need for a third-party trusted institution. After each execution of a smart contract, its status can be updated on the blockchain. Smart contracts deployed on the blockchain (i.e., on-chain smart contracts) usually need to be executed and verified by each node, and all related transactions are visible to the entire blockchain network.

[0005] Recently, blockchain has also been used to address the challenges faced by federated learning. First, deploying blockchain in federated learning can achieve decentralization. However, the current blockchain federated learning system still has some problems, such as the high coupling between the federated learning system and the blockchain system. In some blockchain federated learning systems, both the blockchain system and the federated learning system run on the same network, so the client nodes in the network require more computing resources. The client nodes not only need to perform local training, but also need to verify and aggregate the global model, which increases the participation threshold of the client nodes. Summary of the invention

[0006] The purpose of the present invention is to solve the existing problems and propose a loosely coupled blockchain-based secure and scalable federated learning method. The computing and storage performance requirements of the client nodes are relatively low. At the same time, by using a penalty coefficient mechanism and some cryptographic primitives, the method can effectively prevent Byzantine attacks.

[0007] The present invention is achieved through the following technical solutions:

[0008] A secure and scalable federated learning method based on blockchain, characterized in that the method includes the following specific steps:

[0009] Step A: Deploy blockchain nodes, client nodes, and aggregation nodes; deploy smart contracts to ensure training security on blockchain nodes, deploy programs for model training on client nodes, and deploy programs for aggregation models on aggregation nodes; and deploy decentralized storage software IPFS on aggregation nodes to enable aggregation nodes to have storage functions;

[0010] Step B: The training requester stores the initial global model w0 to the aggregation node and calls the smart contract publish() to register the training task to the blockchain;

[0011] Step C: Each client node i downloads the global model w from the aggregation node t , use the local data set to train the model and obtain the local model And generate a local model The corresponding hash value is obtained, and the smart contract uploadSubModel() is called to upload the local model The metadata of the data is uploaded to the blockchain;

[0012] Step D: After all client nodes upload the metadata of the local model to the blockchain, the client node uploads the local model to the aggregation node to obtain the CID of the local model in IPFS, and then the client node uploads the CID to the metadata of the local model on the blockchain;

[0013] Step E: Call the smart contract classify() to merge all local models into several sub-models. For each sub-model, select several client nodes as verification nodes of the sub-model;

[0014] Step F: Each client node downloads the sub-model for verification from the aggregation node;

[0015] Step G: The client node verifies the sub-model, uploads the results of the verification model to the blockchain, and shares them through verifiable random functions (VRFs) to prevent free-rider attacks;

[0016] Step H: Call the smart contract to verify the legitimacy of the sub-model and calculate the penalty coefficient of the sub-model;

[0017] Step I: The aggregation node aggregates the sub-models using the aggregation algorithm according to the penalty coefficient to obtain a new global model w t+1 ; The new global model w t+1The hash is uploaded to the blockchain through a smart contract using a verifiable random function VRFs.

[0018] Step J: If the current number of training rounds t is less than or equal to the predefined number of training rounds T in the training task, go to step C and start a new round of training; otherwise, end the training, and the current global model is the result of the final model training.

[0019] Among them, the training task is registered to the blockchain in step B, and the specific registration information includes: the public key address of the training requester, the task description, the hash value of the initial global model w0 after the sha256 operation, the content identifier CID corresponding to the initial global model w0 in IPFS, the number of training rounds T for this training task, the maximum number of verifications for each node, and the number of times each local model needs to be verified.

[0020] The local model described in step C The metadata specifically includes: the public key address of the client node i that trained the local model, the local model The hash value after sha256 operation and the current number of training rounds t.

[0021] Step E: For each sub-model, select several client nodes as verification nodes of the sub-model. The specific steps are as follows:

[0022] 4a. Randomly select a client node;

[0023] 4b. If the sub-model contains the local model of the client node or the number of verifications of the client node has reached the threshold t, return to step 4a; otherwise, add the client node to the verification node set of the sub-model until the number of verification nodes is equal to the number of times each local model needs to be verified, then end.

[0024] The specific process of step G through the verifiable random function VRFs is as follows:

[0025] 5a. The verification node calculates the loss rate of each local model, which is the verification result;

[0026] 5b. The verification node generates a pair of secret keys (PK, SK);

[0027] 5c. The verification node uses π←prove(result,SK) and h←proof_to_hash(π) to obtain the VRF proof π and h of the verification result result;

[0028] 5d. The verification node calls the smart contract and uploads the proof of the verification result (π, h, PK) to the blockchain;

[0029] 5e. After all verification nodes upload the proof of verification result (π, h, PK) to the blockchain, all verification nodes upload the verification result result to the blockchain;

[0030] 5f. Verify the legitimacy of the verification result on the blockchain, that is, execute h′←verify(result,π,PK) on the blockchain, and then compare h and h'. If they are equal, the verification result has not been tampered with.

[0031] The sub-model penalty coefficient is calculated in step H, and the calculation formula is as follows:

[0032]

[0033] Where m represents the number of nodes for detecting anomalies.

[0034] In step I, the sub-models are aggregated using an aggregation algorithm. The model aggregation algorithm is as follows:

[0035]

[0036] in, represents the weight of the model of node i in round t training, Represents the penalty coefficient of the model of node i in the tth round of training.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] 1. Realize loose coupling between the blockchain system and the federated learning system. The various training stages are clearly divided into different levels, which facilitates the expansion and upgrade of the corresponding modules of the system.

[0039] 2. Separate blockchain nodes, client nodes and aggregation nodes, make the responsibilities of each node clear, and lower the computing power and storage requirements for client nodes. Separate the aggregation nodes to perform model aggregation and storage tasks, reducing the communication volume between systems.

[0040] 3. The use of differential privacy, hash commitment and verifiable random function VRFs can effectively prevent reasoning attacks and Byzantine attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 A framework diagram for implementing the present invention;

[0042] Figure 2 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0043] The present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0044] See also Figure 1, a secure and scalable federated learning method based on blockchain of the present invention is implemented, including three devices: blockchain node, client node, and aggregation node. The following are the detailed schemes of the three devices:

[0045] 1. Blockchain Node:

[0046] Build any blockchain that supports smart contracts on the blockchain node. After completing the blockchain construction, deploy the corresponding smart contract on the blockchain.

[0047] Smart contracts include:

[0048] 1. System status module, which is used to store training task metadata, record the status of the entire federated learning process, and coordinate client nodes and aggregation nodes.

[0049] 2. Local model processing module. The metadata used to store the local model generated by the client node includes hash commitment, which is used to ensure that the local model is not stolen or tampered with, and can also be used for addressing in the IPFS network.

[0050] 3. Verification node allocation module: used to allocate a set of verification client nodes for the local model.

[0051] 4. Verification result processing module: used to verify the legitimacy of the client's verification results and process the verification results.

[0052] 5. Aggregation result processing module: used to verify the legitimacy of the aggregation results and process the aggregation results.

[0053] Furthermore, the system status module is used for the client node and the aggregation node to query the status of the entire federated learning process, and the client node and the aggregation node will perform corresponding operations according to the status.

[0054] Furthermore, the system status module constrains the client nodes and the aggregation nodes through status settings to prevent some illegal operations therein.

[0055] Furthermore, the verification node allocation module allocates corresponding verification node sets to all local models in two steps.

[0056] (1) By averaging the number of samples, the local model set is divided into several subsets, namely sub-models, and the number of samples in each sub-model is approximately the same.

[0057] (2) For each sub-model, by traversing the nodes, randomly select a node whose verification times do not exceed a preset threshold, and whose local model is not in the sub-model, and include the node in the verification node set of the sub-model.

[0058] Furthermore, the verification result processing module includes the following parts:

[0059] (1) Collect the proofs of each verification result (π, h, PK).

[0060] (2) Collect each verification result.

[0061] (3) Verify the legitimacy of the verification result in combination with the proof of the above verification result, that is, verify whether h′←verify(info,π,PK) is equal to h.

[0062] (4) For each local model, based on the verification result, when the verification result, i.e., the loss rate, is greater than a preset threshold, the verification result is regarded as an abnormal result. Each local model calculates the penalty coefficient of the local model in combination with the number of abnormal results.

[0063] Furthermore, the aggregation result processing module includes the following parts:

[0064] (1) Collect the hash proofs of the global model obtained by each aggregation node.

[0065] (2) Collect the hash values ​​of the global model obtained by each aggregation node.

[0066] (3) A voting mechanism is used to select the hash value with the highest frequency as the index of the new global model on the IPFS network of the aggregation node.

[0067] 2. Client Node:

[0068] The client node has a local dataset for federated learning. It is used to train local models based on the local dataset and verify model updates based on the local dataset.

[0069] The client node has the following modules:

[0070] 1. The query module can query the blockchain to understand the current system status and query the metadata of the global model and sub-models.

[0071] 2. Model transmission module, uploads the corresponding model and downloads the corresponding model from the aggregation node.

[0072] 3. Privacy and security module, generates hash commitments for local models and generates verifiable random function VRFs proofs for model verification results.

[0073] 4. Model training module: Use local data sets to train local models and use differential privacy technology to protect model privacy.

[0074] 5. Model verification module, using local data sets to verify sub-models.

[0075] Furthermore, in the query module, when the client node completes a stage task, that is, when it is idle, it needs to query the blockchain regularly to understand the current blockchain status.

[0076] Furthermore, in the model transmission module, the client node uploads the model to the IPFS private network, which is a star-level file system composed of aggregation nodes. The hash value of the model is the address of the model in the IPFS network, and the model can be downloaded from IPFS through the hash value.

[0077] Furthermore, in the privacy and security module, the hash commitment generated by the client node for the local model is equal to the hash value obtained when the client subsequently uploads the model to the IPFS network.

[0078] Furthermore, in the privacy security module, the client node generates a verifiable random function VRFs process for the model verification result result as follows:

[0079] (1) The client generates a pair of asymmetric keys: public key PK and private key SK;

[0080] (2) The client node calculates π←prove(result,SK) and h←proof_to_hash(π) to obtain the proof π and h of the model verification result result.

[0081] (3) (π, h, PK) constitutes the proof of the model verification result. The client node uploads (π, h, PK) to the blockchain.

[0082] Furthermore, in the model training module, the client node uses a stochastic gradient descent method to train the model.

[0083] 3. Aggregation Node:

[0084] The InterPlanetary File System (IPFS) client runs on the aggregation node to form an IPFS private network and store training models. The aggregation node is also used to aggregate sub-models.

[0085] Aggregation nodes include:

[0086] 1. The query module can query the blockchain to understand the current system status and query the metadata of the global model and sub-models.

[0087] 2. Storage module, namely the Interstellar File System IPFS client, is used to store local models and global models.

[0088] 3. Model aggregation module: Aggregate local models stored on IPFS.

[0089] Furthermore, in the storage module, an IPFS client is installed on the aggregation node, so that an IPFS private network is formed between the aggregation nodes, and the model is stored in the network in fragments, which has better security.

[0090] Furthermore, in the model aggregation module, the aggregation node combines the local models of each client node with the penalty coefficient, and obtains a new global model by weighted averaging, thereby effectively resisting poisoning attacks.

[0091] Example

[0092] See also Figure 2 , this embodiment includes the following steps:

[0093] S1. Establish a blockchain network or use an existing blockchain network. Release smart contracts on the blockchain network.

[0094] S2. The task publisher stores the initial global model in the aggregation node and obtains the hash value of the initial model. The task metadata is stored in the blockchain network. The system enters the local model training phase.

[0095] S3: Local model training stage.

[0096] S3.1. The client node downloads the latest global model from the aggregation node, performs local model training, generates a local model, and adds Laplace noise to protect the model privacy.

[0097] S3.2. The client node calculates the hash proof of the local model and stores the local model metadata including the hash proof of the local model into the blockchain network.

[0098] S3.3. If all client nodes have uploaded local model metadata or the current model training phase has exceeded the time limit, the system state is set to the local model uploading phase and enters step S4; otherwise, the system is still in the local model training phase, that is, the system is still in step S3.

[0099] S4, local model upload stage. The client node stores the local model in the aggregation node. After storage is completed, the smart contract is called to notify the blockchain network. When all client nodes upload the local model, the system enters the verification node selection stage and enters step S5; otherwise, the system is still in the local model upload stage, that is, the system is still in step S4.

[0100] S5, verification node selection stage. The blockchain uses smart contracts to divide the local model set into d sub-models, and each sub-model will be randomly delegated to e clients for verification. A set of key-value pairs is generated on the blockchain, with the key being the index of the local model and the value being the verification client list. Enter step S6, and the system enters the sub-model verification stage.

[0101] S6, sub-model verification phase.

[0102] S6.1. Each client node queries the local model that needs to be verified on the blockchain, downloads the corresponding local model through the aggregation node, verifies the model using the local data set, and obtains the loss rate, i.e., the verification result.

[0103] S6.2. The client node uses the verifiable random function VRFs to generate a proof of the verification result and uploads the proof to the blockchain.

[0104] S6.3. If all client nodes have uploaded proof of the verification results, the system enters the verification result confirmation phase and proceeds to step S7; otherwise, the system is still in the sub-model verification phase, that is, the system is still in step S6.

[0105] S7, verification result upload stage. The client node uploads the verification result to the blockchain. The blockchain compares the verification result with the proof to see if they are consistent. If they are inconsistent, the client node is determined to be a malicious node. If all clients have uploaded the verification results, the system enters the verification result analysis stage, i.e., step S8; otherwise, the system is still in the verification result upload stage, i.e., the system is still in step S7.

[0106] S8, verification result analysis phase. The penalty coefficient of each local model is calculated on the blockchain according to the following formula. The system enters the model aggregation phase, that is, enters step S9.

[0107]

[0108] S9, model aggregation stage.

[0109] S9.1. The aggregation node downloads the penalty coefficient list corresponding to the local model list from the blockchain. Combined with the penalty coefficient, the global model w is obtained using the following formula: t+1 , and calculate the global model w t+1 The hash value of .

[0110]

[0111] S9.2. The aggregation node uses the verifiable random function VRFs to generate a proof of the hash value of the global model and uploads the proof to the blockchain.

[0112] S9.3. If all aggregation nodes have uploaded the proof of the hash value of the global model, the system enters the global model verification phase and proceeds to step S10; otherwise, the system is still in the model aggregation phase, that is, the system is still in step S9.

[0113] S10, global model verification phase. The blockchain selects the hash value with the highest frequency as the index of the new global model on the aggregation node network. If the loss rate of this round of training on the nodes of each client is less than the predefined threshold, or the number of training rounds exceeds the predefined threshold, the training ends. Otherwise, the system enters the local model training phase, i.e. step S3.

Claims

1. A secure and scalable federated learning method based on blockchain, characterized in that: The method comprises the following specific steps: Step A: Deploy blockchain nodes, client nodes, and aggregation nodes; deploy smart contracts to ensure training security on blockchain nodes, deploy programs for model training on client nodes, and deploy programs for aggregation models on aggregation nodes; and deploy decentralized storage software IPFS on aggregation nodes to enable aggregation nodes to have storage functions; Step B: The training requester stores the initial global model w0 to the aggregation node and calls the smart contract publish() to register the training task to the blockchain; Step C: Each client node i downloads the global model w from the aggregation node t , use the local data set to train the model and obtain the local model And generate a local model The corresponding hash value is obtained, and the smart contract uploadSubModel() is called to upload the local model The metadata of the data is uploaded to the blockchain; Step D: After all client nodes upload the metadata of the local model to the blockchain, the client node uploads the local model to the aggregation node to obtain the CID of the local model in IPFS, and then the client node uploads the CID to the metadata of the local model on the blockchain; Step E: Call the smart contract classify() to merge all local models into several sub-models. For each sub-model, select several client nodes as verification nodes of the sub-model; Step F: Each client node downloads the sub-model for verification from the aggregation node; Step G: The client node verifies the sub-model, uploads the results of the verification model to the blockchain, and shares them through verifiable random functions (VRFs) to prevent free-rider attacks; Step H: Call the smart contract to verify the legitimacy of the sub-model and calculate the penalty coefficient of the sub-model; Step I: The aggregation node aggregates the sub-models using the aggregation algorithm according to the penalty coefficient to obtain a new global model w t+1 ; The new global model w t+1 The hash is uploaded to the blockchain through a smart contract using a verifiable random function VRFs. Step J: If the current number of training rounds t is less than or equal to the predefined number of training rounds T in the training task, go to step C and start a new round of training; otherwise, end the training, and the current global model is the result of the final model training.

2. The federated learning method according to claim 1, characterized in that: In step B, the training task is registered with the blockchain. The specific registration information includes: the public key address of the training requester, the task description, the hash value of the initial global model w0 after the sha256 operation, the content identifier CID corresponding to the initial global model w0 in IPFS, the number of training rounds T for this training task, the maximum number of verifications for each node, and the number of verifications required for each local model.

3. The federated learning method according to claim 1, characterized in that: The local model described in step C The metadata specifically includes: the public key address of the client node i that trained the local model, the local model The hash value after sha256 operation and the current number of training rounds t.

4. The federated learning method according to claim 1, characterized in that: Step E: For each sub-model, select several client nodes as verification nodes of the sub-model. The specific steps are as follows: 4a. Randomly select a client node; 4b. If the sub-model contains the local model of the client node or the number of verifications of the client node has reached the threshold t, return to step 4a; otherwise, add the client node to the verification node set of the sub-model until the number of verification nodes is equal to the number of times each local model needs to be verified, then end.

5. The federated learning method according to claim 1, characterized in that: The specific process of step G through the verifiable random function VRFs is as follows: 5a. The verification node calculates the loss rate of each local model, which is the verification result; 5b. The verification node generates a pair of secret keys (PK, SK); 5c. The verification node uses π←prove(result,SK) and h←proof_to_hash(π) to obtain the VRF proof π and h of the verification result result; 5d. The verification node calls the smart contract and uploads the proof of the verification result (π, h, PK) to the blockchain; 5e. After all verification nodes upload the proof of verification result (π, h, PK) to the blockchain, all verification nodes upload the verification result result to the blockchain; 5f. Verify the legitimacy of the verification result on the blockchain, that is, execute h′←verify(result,π,PK) on the blockchain, and then compare h and h'. If they are equal, the verification result has not been tampered with.

6. The federated learning method according to claim 1, characterized in that: The sub-model penalty coefficient is calculated in step H, and the calculation formula is as follows: Where m represents the number of nodes for detecting anomalies.

7. The federated learning method according to claim 1, characterized in that: In step I, the sub-models are aggregated using an aggregation algorithm. The model aggregation algorithm is as follows: in, represents the weight of the model of node i in round t training, Represents the penalty coefficient of the model of node i in the tth round of training.

Images