Multi-party federal learning method, system and device, storage medium and program product

Abstract

The invention discloses a multi-party federated learning method, system and device, a storage medium and a program product, relates to the technical field of federated learning, is applied to participating nodes in a block chain network, and comprises the following steps: obtaining learning parameter information sent by a central node, and determining training generation information according to the learning parameter information, the training generation information comprises training model parameters and zero-knowledge proof corresponding to the training model parameters; acquiring installation information of the zero-knowledge proof in the block chain network, and determining node honesty according to the installation information; the training model parameters and the node honesty are sent to a center node, and the center node is used for determining an aggregation model based on the training model parameters and the node honesty and taking the aggregation model as a target federated learning model when the aggregation model converges. The technical problem of low accuracy of multi-party federation learning is solved.

Description

Technical Field

[0001] The present application relates to the field of federated learning technology, and in particular to a multi-party federated learning method, system, device, storage medium and program product. Background Art

[0002] With the continuous development of federated learning technology, it is being used more and more frequently in different fields, which also makes users put forward higher requirements on the security of multi-party federated learning.

[0003] At present, when conducting multi-party federated learning, multiple participants can use their own data to perform model training locally, and then send their respective updated model weights to the central server for aggregation to complete multi-party federated learning. However, this multi-party federated learning method will cause the central server to be interfered with by the training parameters of malicious participants due to the direct sending of the model weights of multiple participants to the central server (the central node in the embodiment) for aggregation (it cannot be guaranteed whether the multiple participants are trusted participants). Therefore, this multi-party federated learning method will cause the central server to be interfered with by the training parameters of malicious participants, which will cause the accuracy of multi-party federated learning to be low.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a multi-party federated learning method, system, storage medium and program product, aiming to solve the technical problem of low accuracy of multi-party federated learning.

[0006] To achieve the above objectives, the present application provides a multi-party federated learning method, which is applied to participating nodes in a blockchain network. The multi-party federated learning method includes:

[0007] Obtaining learning parameter information sent by the central node, and determining training generation information according to the learning parameter information, wherein the training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters;

[0008] Obtaining installation information of the zero-knowledge proof in the blockchain network, and determining node honesty based on the installation information;

[0009] The training model parameters and the node honesty are sent to the central node, wherein the central node is used to determine an aggregation model based on the training model parameters and the node honesty, and when the aggregation model converges, the aggregation model is used as a target federated learning model.

[0010] To achieve the above objectives, the present application provides a multi-party federated learning method, which is applied to a central node in a blockchain network. The multi-party federated learning method includes:

[0011] Obtaining training model parameters and node honesty generated by participating nodes based on learning parameter information, and determining an aggregation model for each participating node according to the training model parameters and the node honesty, wherein the participating node is used to determine the training model parameters and the zero-knowledge proof corresponding to the training model parameters based on the learning parameter information, and determine the node honesty according to the installation information of the zero-knowledge proof in the blockchain network;

[0012] When the aggregate model converges, the aggregate model is used as a target federated learning model.

[0013] To achieve the above objectives, the present application also provides a multi-party federated learning system, which is applied to a blockchain network and includes:

[0014] A participating node is used to obtain the learning parameter information sent by the central node, and determine the training generation information according to the learning parameter information, wherein the training generation information includes the training model parameters and the zero-knowledge proof corresponding to the training model parameters; obtain the installation information of the zero-knowledge proof in the blockchain network, and determine the node honesty according to the installation information; send the training model parameters and the node honesty to the central node;

[0015] The central node is used to obtain the training model parameters and node honesty generated by the participating nodes based on the learning parameter information, and for each participating node, determine the aggregation model according to the training model parameters and the node honesty; when the aggregation model converges, use the aggregation model as the target federated learning model.

[0016] The present application also provides a multi-party federated learning device, which includes: at least one processor and a memory communicatively connected to the at least one processor, the memory storing instructions executable by the at least one processor, and the instructions being executed by the at least one processor so that the at least one processor can perform the steps of the multi-party federated learning method as described above.

[0017] The present application also provides a storage medium, on which is stored a program for implementing the multi-party federated learning method. When the program of the multi-party federated learning method is executed by a processor, the steps of the multi-party federated learning method as described above are implemented.

[0018] The present application also provides a program product, including a multi-party federated learning program, which implements the steps of the multi-party federated learning method as described above when executed by a processor.

[0019] The multi-party federated learning method of the present application is applied to participating nodes in a blockchain network, by obtaining learning parameter information sent by a central node, and determining training generation information based on the learning parameter information, wherein the training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters; obtaining installation information of the zero-knowledge proof in the blockchain network, and determining node honesty based on the installation information; sending the training model parameters and node honesty to the central node, wherein the central node is used to determine an aggregation model based on the training model parameters and node honesty, and when the aggregation model converges, using the aggregation model as the target federated learning model.

[0020] By determining the training model parameters and the zero-knowledge proof corresponding to the training model parameters according to the learning parameter information, the node honesty is determined in the blockchain network based on the zero-knowledge proof, and the node honesty and the training model parameters are sent to the central node together, and the aggregation model is determined in the central node based on the training model parameters and the node honesty, and when the aggregation model converges, the aggregation model is used as the target federated learning model. Thus, the problem of the central server being interfered with by the training parameters of the malicious participants in the prior art due to the model weights of multiple participants being directly sent to the central server for aggregation (it is impossible to ensure whether the multiple participants are credible participants) is avoided. This multi-party federated learning method determines the training model parameters and zero-knowledge proof at the participating nodes, and then determines the node honesty in the blockchain network based on the zero-knowledge proof, and finally determines the aggregation model based on the training model parameters and the node honesty at the central node, and when the aggregation model converges, the aggregation model is used as the target federated learning model to ensure that the central node will not be interfered with by the training parameters of the malicious participants in the training, thereby improving the accuracy of multi-party federated learning. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0022] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0023] Figure 1 A flowchart of the multi-party federated learning method provided in Example 1 of the present application;

[0024] Figure 2 A schematic diagram of a scenario of the multi-party federated learning method of this application;

[0025] Figure 3 A flowchart of the multi-party federated learning method of this application;

[0026] Figure 4 A flowchart of the multi-party federated learning method provided in Example 3 of the present application;

[0027] Figure 5 A schematic diagram of the structure of a multi-party federated learning system provided in Example 5 of the present application;

[0028] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Example 6 of the present application.

[0029] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0030] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work belong to the scope of protection of the present invention.

[0031] Embodiment 1

[0032] Although existing federated learning protects personal privacy by isolating original data, this approach still has the following security and privacy threats: 1. The iterative process of federated learning does not verify the participants. Especially when there are many participants, it is easier for individual malicious participants to replace false training data to update the local model, or provide incorrect local training model parameters or disturbed models to the central server. The unverified parameters provided by malicious nodes will greatly affect the quality of the global model after aggregation, and may even cause the model to fail to converge, ultimately leading to training failure. 2. The existing federated learning mechanism may still leak user privacy. For example, malicious federated learning participants can infer sensitive information through the parameters shared by honest users. Based on the above defects, the general solution is the following two improvements: one is that each participant uploads the local training model to the blockchain, and the participant downloads the local models uploaded by other participants from the blockchain, calculates the Euclidean distance of other local models to obtain the model similarity, and scores them based on local data to ensure that the local model will not be attacked by poisoning by attackers. The scoring results are uploaded to the blockchain. This improvement method is open to all other participants. All participants can access the model parameters of others, and there is a possibility of inferring the model details through the updated gradient, which has the risk of privacy leakage. Another improvement method is for the central server to verify the training process, and prove the correctness of the training process to the publisher without leaking the trainer's privacy data. This improvement method puts a lot of pressure on the central server because of the centralized verification process. The federated learning process involved only retains the verification process locally, which is not convenient for subsequent search and verification.

[0033] Therefore, based on the above defects of multi-party federated learning, this application proposes a new multi-party federated learning method, thereby ensuring that the central node will not be interfered with by the training parameters of malicious participants, so as to improve the accuracy of multi-party federated learning.

[0034] The present application embodiment provides a multi-party federated learning method. In the first embodiment of the multi-party federated learning method of the present application, refer to Figure 1 , Figure 1 The flowchart of the multi-party federated learning method provided in the first embodiment of the present application is as follows. The multi-party federated learning method is applied to participating nodes in the blockchain network. The multi-party federated learning method includes:

[0035] Step S10, obtaining the learning parameter information sent by the central node, and determining the training generation information according to the learning parameter information, wherein the training generation information includes the training model parameters and the zero-knowledge proof corresponding to the training model parameters;

[0036] In this embodiment, the multi-party federated learning method is applied to participating nodes, and the participating nodes can be defined as multiple, that is, there are at least three or more (on the one hand, it is related to the subsequent verification judgment, on the other hand, if there are only two, it may be a participating node itself and the central node as a participating node, that is, at this time there is only one participating node except the central node, and there is no meaning of subsequent execution process, and it can also be selected according to the actual situation). The participating node and the central node interact with data to complete multi-party federated learning. It is worth mentioning that the central node can be used as a participating node in subsequent federated learning, or it can be used only as an aggregated central node (participating nodes refer to servers, terminals, etc. participating in multi-party federated learning, and central nodes refer to servers and terminals that participate in multi-party federated learning and send and aggregate all training data), such as federated learning of image data and audio data, or federated learning of character features and sounds.

[0037] In one embodiment, when performing multi-party federated learning, the participating nodes will obtain the learning parameter information sent by the central node, that is, the central node informs each participating node how to perform training and provide training-related parameters. At this time, the learning parameter information can be obtained directly from the central node, or it can be obtained from the blockchain network, that is, the central node sends the learning parameter information on the chain to the blockchain network to avoid the time-consuming defect of sending it to the participating nodes one by one, and can also selectively send highly secure training parameters to the corresponding participating nodes to ensure data security. The learning parameter information refers to the relevant parameters for training, such as specifying a machine learning model (such as a neural network structure), an optimization algorithm (such as gradient descent), a loss function, the number of iterations, etc., which can be the initial parameters or the parameters after multiple trainings, which are not limited here. At this time, training can be performed in the participating nodes to obtain training generation information, which includes training model parameters and zero-knowledge proofs corresponding to the training model parameters, that is, training is performed based on learning parameter information and parameters inside the participating nodes, and the parameters after training convergence are used as training model parameters. At the same time, a corresponding zero-knowledge proof will be generated for each training. The information in the zero-knowledge proof can be a hash value or other key parameters obtained in each training. Among them, zero-knowledge proof (Zero Knowledge Proof) is a concept first proposed by S. Goldwasser et al. in 1985. Its core is to allow the prover to successfully convince the verifier of the authenticity of a specific assertion without revealing any substantive information to the verifier. At this time, it will be determined whether the participating node needs to conduct multi-party federated learning based on the training model parameters and zero-knowledge proof to avoid the impact of the participating node being a malicious node on the entire multi-party federated learning.

[0038] Step S20, obtaining the installation information of the zero-knowledge proof in the blockchain network, and determining the node honesty based on the installation information;

[0039] Step S30, sending the training model parameters and node honesty to the central node, wherein the central node is used to determine the aggregation model based on the training model parameters and node honesty, and when the aggregation model converges, the aggregation model is used as the target federated learning model.

[0040] In this embodiment, after obtaining the training model parameters and zero-knowledge proof of the participating nodes, the zero-knowledge proof will be sent to the blockchain network to determine the node honesty of the zero-knowledge proof, and then the node honesty and training model parameters will be sent to the central node. The central node can determine the aggregation model based on the training model parameters and node honesty, and when the aggregation model converges, the aggregation model is used as the target federated learning model (that is, the central node learns based on the honesty of each participating node to avoid the influence of malicious participating nodes), rather than directly based on the training model parameters. Federated learning can avoid the influence of malicious participating nodes on the training results of the central node, thereby improving the accuracy of multi-party federated learning. Installation information refers to the information of the installation of the smart contract in the zero-knowledge proof of other participating nodes other than the participating node, such as the installation of the smart contract in the zero-knowledge proof of 50% of the other participating nodes. Node honesty refers to the node honesty of the smart contract in the zero-knowledge proof, which is generally verified or not verified, that is, when the verification is passed, the participating node is determined to be a trusted participating node, and multi-party federated learning can be carried out. When the verification fails, the participating node is determined to be a suspicious participating node, and multi-party federated learning cannot be carried out. It is worth noting that when determining the honesty of a node in a blockchain network, a proposal node needs to be randomly selected to distribute, receive and aggregate the zero-knowledge proofs uploaded to the blockchain network based on the proposal node. This implementation can be for this participating node, or for other participating nodes or a central node, that is, the node honesty is determined at this participating node, other participating nodes or a central node based on the installation information.

[0041] In one embodiment, referring to Figure 2 , Figure 2This is a schematic diagram of a scenario of the multi-party federated learning method of this application. The process of the entire multi-party federated learning method is that the central node publishes the federated learning task (the model needs to be distributed and initialized initially), and each participating node uses local data to train the local model. After the local model converges, the local model parameters are obtained, and a zero-knowledge proof of the model parameters is generated. After that, the updated local model parameters will be uploaded to the central node, and the zero-knowledge proof will be uploaded to the blockchain network for trusted verification. The zero-knowledge proof can calibrate the honest node according to the node honesty in the blockchain verification network, and notify the central node to aggregate the training model of the honest node this time. By judging whether the aggregated training model converges, and directly outputting it when the aggregated training model converges, if it is found that the aggregated training model has not converged, the new global model parameters will be chained to the blockchain network, so that other participating nodes can be re-trained based on the new global model parameters chained to the blockchain network, and the process of each participating node using local data and new global model parameters to train the local model will be executed again until the aggregated training model converges and the final required model is output to complete the multi-party federated learning. This multi-party federated learning method guarantees the honesty of all participants and avoids various attacks from malicious nodes such as gradient backpropagation. By designing a combination of zero-knowledge proof and blockchain for the multi-participant federated learning training process, it ensures the secure convergence of the global model of federated learning, and the process parameters are not disclosed to others, so privacy and security are effectively protected. At the same time, the decentralized (not using one node to verify malicious nodes) node verification process can reduce the transaction verification time of trusted nodes, improve the verification efficiency of trusted nodes, and use the distributed characteristics of blockchain to identify and mark malicious nodes.

[0042] As an example, the multi-party federated learning method includes, through steps S10 to S30: applied to participating nodes in the blockchain network, obtaining learning parameter information sent by the central node, and determining training generation information according to the learning parameter information, wherein the training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters; obtaining installation information of the zero-knowledge proof in the blockchain network, and determining node honesty according to the installation information; sending the training model parameters and node honesty to the central node, wherein the central node is used to determine the aggregation model based on the training model parameters and node honesty, and when the aggregation model converges, the aggregation model is used as the target federated learning model. By determining the training model parameters and the zero-knowledge proof corresponding to the training model parameters according to the learning parameter information, the node honesty is determined in the blockchain network based on the zero-knowledge proof, and the node honesty and the training model parameters are sent to the central node together, and the aggregation model is determined in the central node based on the training model parameters and node honesty, and when the aggregation model converges, the aggregation model is used as the target federated learning model. This avoids the problem in the prior art that the training parameters of the central server are interfered with by the training parameters of malicious participants due to directly sending the model weights of multiple participants to the central server for aggregation (it cannot be guaranteed whether the multiple participants are trusted participants). This multi-party federated learning method determines the training model parameters and zero-knowledge proof at the participating nodes, and then determines the node honesty in the blockchain network based on the zero-knowledge proof. Finally, the central node determines the aggregation model based on the training model parameters and node honesty, and when the aggregation model converges, the aggregation model is used as the target federated learning model to ensure that the central node will not be interfered with by the training parameters of malicious participants in training, thereby improving the accuracy of multi-party federated learning.

[0043] Embodiment 2

[0044] Further, in another embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be described in detail later. On this basis, the step of determining the training generation information according to the learning parameter information includes:

[0045] Step S11, training based on the learning parameter information and the preset local data to obtain a local training model, and generating a zero-knowledge proof corresponding to the local training model;

[0046] Step S12, when the local training model has not converged, updating the local training model based on a preset loss function, and executing the step of generating a zero-knowledge proof corresponding to the local training model based on the updated local training model;

[0047] Step S13, when the local training model converges, the local training model is used as the training model parameters, and the training model parameters and the zero-knowledge proof are used as the training generation information.

[0048] In this embodiment, after receiving the learning parameter information, training will be performed in each participating node based on the learning parameter information to obtain training generation information. When training, the local training model is mainly obtained based on the learning parameter information and the preset local data, and the zero-knowledge proof corresponding to the local training model is generated at the same time, wherein the local training model obtained by training based on the learning parameter information and the preset local data can be consistent with the existing learning and training process, which is not limited here. The preset local data refers to the internal data of the participating node, such as the parameters used for training, etc. This data is unique to each participating node and is not disclosed. The zero-knowledge proof corresponding to the local training model can be the hash value and other parameters corresponding to the local training model. At this time, it will be judged whether the local training model converges to determine whether it is necessary to output the local training model as the final result. The judgment method of model convergence can be consistent with the commonly used method of judging convergence, such as a certain parameter reaching a threshold or reaching a defined number of training times. Finally, when the local training model has not converged, the local training model is updated based on the preset loss function, and the steps of generating the zero-knowledge proof corresponding to the local training model are executed based on the updated local training model. On the contrary, when the local training model converges, the local training model is used as the training model parameter, and the training model parameter and the zero-knowledge proof are used as the training generation information, where the preset loss function refers to the loss function value defined inside the participating node. For example, the participating node uses local data and downloaded learning parameter information for multiple rounds of local training, and in each round of iteration, the model is updated according to the loss function gradient of the local data set until a converged local model is finally obtained. At the same time, after each round of iteration, the participating party generates not only updated model parameters, but also zero-knowledge proofs of these updates. Subsequent federated learning is carried out by using the training model parameters and zero-knowledge proof as training generation information, because it is possible to judge whether the participating node is a malicious node based on the zero-knowledge proof, and selectively participate in federated learning based on the judgment result, thereby ensuring the accuracy of multi-party federated learning.

[0049] In one embodiment, referring to Figure 3 , Figure 3This is a flow chart of the multi-party federated learning method of this application. The central node publishes the initialization model, and each participating node uses local data to train the local model and commit to generation (zero-knowledge proof). The updated local model parameters are then uploaded to the central node, and the zero-knowledge proof is uploaded to the blockchain network for trusted verification. The zero-knowledge proof is verified on the blockchain verification network, and the central node is notified to aggregate the training model of the honest node this time. If it is found that the aggregated training model has not converged, the global parameter model will be published to each participant, and each participant will be notified to use the parameters for the next round of training, and the training process will be repeated until the model converges. The entire process is based on the verification of zero-knowledge proof to ensure the security of federated learning.

[0050] In one embodiment, the step of determining the node honesty based on the installation information includes:

[0051] Step S21, if the number of installations in the installation information is greater than a preset installation threshold, then determining verification information corresponding to the zero-knowledge proof;

[0052] Step S22, obtaining a node signature result corresponding to the zero-knowledge proof, wherein the node signature result includes a first node signature result of the central node verifying the zero-knowledge proof based on the verification information and a second node signature result of the other participating nodes verifying the zero-knowledge proof based on the verification information;

[0053] Step S23: when the first node signature result is verified, and the number of second node signature results that pass verification is greater than the first threshold, the node integrity is determined to be a preset trusted node, or,

[0054] Step S24, when the first node signature result fails the verification, and the verification pass number of the second node signature result is greater than the second threshold, the node honesty is determined to be a preset trusted node, wherein the second threshold is greater than the first threshold.

[0055] In this embodiment, after the zero-knowledge proof is determined, the zero-knowledge proof will be sent to the blockchain network, and the training model parameters will also be sent to the central node. In order to ensure the privacy of the data, a homomorphic or semi-homomorphic encryption algorithm can be selected for transmission. That is, at this time, it is necessary to prove to the central node and other participating nodes through zero-knowledge proof that the parameters that are about to be transmitted to the central node are true. When verifying the zero-knowledge proof, the participating node packages the verification logic (i.e., zero-knowledge proof) used for verification into a smart contract, puts it locally or stores it in a shared server, and publishes a message containing the smart contract address and a brief description through the blockchain network to notify other participating nodes based on the proposal node on the blockchain network. After receiving the message, other participating nodes first verify the validity of the message based on the brief description message, including the source of the message and the integrity of the content. After the verification is passed, other participating nodes download the smart contract from the address provided in the message and install and deploy it locally. After the installation and deployment is completed, other participating nodes send confirmation messages to the participating nodes through the blockchain network, indicating that the smart contract has been successfully obtained and deployed, that is, as the number of installations in the installation information, the number of installations in the installation information will be judged at this time. Only when the number of installations in the installation information is greater than the preset installation threshold, the subsequent verification reference will be executed. Otherwise, the number of installations in the installation information will be greater than the preset installation threshold. The preset installation threshold refers to the user-defined value, such as 2 / 3. That is, after the participating node receives confirmation messages from more than 2 / 3 of the other participating nodes, it will publish the verification key, the hash value h1 of the training parameter, and simple additional information through the blockchain, because at this time the participating node, as a proposal node, will directly determine the verification information corresponding to the zero-knowledge proof. The verification information refers to the verification key for signature verification of the zero-knowledge proof. At this time, after other participating nodes receive the verification key, the smart contract automatically executes the verification process. If the verification passes, it will sign to confirm the authenticity of the zero-knowledge proof. Otherwise, it will not sign, that is, it is determined that the zero-knowledge proof verification fails. At this time, the final node honesty is not directly judged based on the results of a single other participating node, but needs to be determined in combination with all nodes. At this time, due to vested interests, it is assumed that the central node is honest. The nodes owned by the central node are the only globally trusted nodes on the blockchain and have the right to publish a list of trusted (suspicious) nodes on the blockchain.That is, the node signature result at this time includes the first node signature result of the central node verifying the zero-knowledge proof based on the verification information and the second node signature result of the other participating nodes verifying the zero-knowledge proof based on the verification information, that is, the two results of the central node and the other participating nodes verifying the zero-knowledge proof, and then the node honesty is judged based on the two results. At this time, due to the nature of the central node, it can be defined that when the first node signature result is verified, and the number of verification passes of the second node signature result is greater than the first threshold, then the node honesty is determined to be a preset trusted node, or, when the first node signature result is verified unsuccessfully, and the number of verification passes of the second node signature result is greater than the second threshold, then the node honesty is determined to be a preset trusted node, wherein the second threshold is greater than the first threshold, and the second threshold and the first threshold are both two thresholds defined by the user, the preset trusted node means that the participating node is a trusted node, the verification passed means that the participating node is a trusted node, and the verification failed means that the participating node is a suspicious node. If node A is marked as a trusted node by the central node, the second node signature result can be considered valid if it exceeds 1 / 3 of the node signatures. If node A is marked as a suspicious node by the central node, the second node signature result can be considered valid only if it exceeds 2 / 3 of the node signatures. It is worth noting that according to the blockchain basic transaction validity verification rules, nodes whose transactions are verified as invalid transactions three times in a row are automatically marked as suspicious nodes, that is, nodes that are defined as invalid transactions by the blockchain network three times in a row are directly marked as suspicious nodes without the need for subsequent node signature result judgment. At the same time, it can also be defined that proofs signed by more than half of the nodes are considered valid and permanently recorded on the blockchain, and then regarded as tamper-proof and reliable records. At this time, other nodes in the blockchain network can query and confirm a certain round of zero-knowledge proofs, which can meet the needs of security audits.

[0056] In one embodiment, before the step of determining the honesty of the node according to the installation information, the multi-party federated learning method further includes:

[0057] Step S31, determining the proposal node in the blockchain network;

[0058] Step S32, when the proposing node is a participating node, the step of determining the node honesty according to the installation information is executed;

[0059] Step S33, when the proposing node is another participating node, the node honesty of the other participating node is obtained, wherein the other participating node is used to determine the node honesty according to the installation information;

[0060] Step S34, when the proposing node is a central node, the node integrity of the central node is obtained, wherein the central node is used to verify the zero-knowledge proof based on the verification information of the zero-knowledge proof, obtain the first node signature result, and use the first node signature result as the node integrity.

[0061] In this embodiment, after determining the installation information in the blockchain network, the step of determining the proposal node in the blockchain network is also performed, and then the subsequent execution process is determined based on the determination of the proposal node. For example, all nodes on the blockchain network elect (the election method includes but is not limited to random generation, rotation, etc.) proposal nodes before each block is generated. The proposal node is used to collect unverified transactions on the chain, including verification keys, hash values ​​of smart contract addresses and other information, and after verification, it is packaged into blocks for signing, and the blocks are sent to other participating nodes. After receiving the blocks, other participating nodes verify the validity of the blocks, and use the transaction information therein to verify the correctness of the proof algorithm. After verification, they sign and return the signature information to the central node so that the central node can perform subsequent federated learning. At this time, there are three situations. One is when the proposing node is a participating node, and the step of determining the node honesty according to the installation information will be directly executed; one is when the proposing node is other participating nodes, and the node honesty of other participating nodes will be obtained, wherein other participating nodes are used to determine the node honesty according to the installation information, that is, the process of determining the node honesty is executed on other participating nodes at this time, and the node honesty can also be directly sent to the central node by other participating nodes at this time, which is not limited here; one is when the proposing node is a central node, then the node honesty of the central node will be obtained, wherein the central node is used to verify the zero-knowledge proof based on the verification information of the zero-knowledge proof, obtain the first node signature result, and use the first node signature result as the node honesty. The first node signature result refers to the node honesty of the central node to the zero-knowledge proof, that is, the node honesty of the central node can be directly used as the basis at this time, and the central node can also directly obtain the determined node honesty for subsequent operations. Because the central node is often the initiator of federated learning, the nodes owned by the central node are considered to be globally trusted nodes due to vested interests. If the central node is elected as a proposal node, it verifies that the block packaged after the transaction does not contain suspicious nodes is sent to other participating nodes. Other participating nodes can only verify the signature and block validity of the central node, and can directly link to the blockchain without verifying the validity of transactions in the block. That is, the central node is elected as a proposal node, and the trusted verification of all participating nodes can be directly based on the central node, without considering the node honesty of all participating nodes. Verification can then be performed based on different proposal nodes to ensure the processing efficiency and specificity of node honesty.

[0062] Embodiment 3

[0063] Further, based on the above embodiment applied to the participating nodes, an embodiment applied to the central node is proposed, referring to Figure 4 , Figure 4 This is a flow chart of a multi-party federated learning method provided in Embodiment 3 of the present application. The multi-party federated learning method is applied to a central node. The multi-party federated learning method includes:

[0064] Step S40, obtaining the training model parameters and node honesty generated by the participating nodes based on the learning parameter information, and determining the aggregation model for each participating node according to the training model parameters and the node honesty, wherein the participating node is used to determine the training model parameters and the zero-knowledge proof corresponding to the training model parameters based on the learning parameter information, and determine the node honesty according to the installation information of the zero-knowledge proof in the blockchain network;

[0065] Step S50: When the aggregation model converges, the aggregation model is used as the target federated learning model.

[0066] In this embodiment, when the central node conducts federated learning, the training model parameters and node honesty generated by the participating nodes based on the learning parameter information are obtained, and then for each participating node, the aggregation model is determined according to the training model parameters and the node honesty, wherein the participating nodes are used to determine the training model parameters and the zero-knowledge proof corresponding to the training model parameters based on the learning parameter information, and determine the node honesty according to the installation information of the zero-knowledge proof in the blockchain network. At this time, it will be determined whether the node honesty of each participating node can determine that the participating node is trustworthy. If it is determined to be a trustworthy participating node, it will be aggregated based on the training model parameters of each trustworthy participating node to obtain an aggregation model, and when the aggregation model converges, the aggregation model is used as the target federated learning model. The target federated learning model refers to the model that needs to be finally trained. That is, each participating node in the blockchain network verifies the zero-knowledge proof submitted by each participating node based on the on-chain verification rules (such as the direct verification by the central node defined above, and the rules for joint verification by the central node and the participating nodes). After passing the verification and meeting certain conditions (such as more than half of the nodes passing the verification), the block containing the proof and the relevant hash will be added to the blockchain network, and the honest participating nodes will be marked. At the same time, as a node honesty notification, the central node can securely aggregate the model parameters received from the participating node, so that the aggregated model can be used as the target federated learning model after convergence, and then the training model parameters can be federated through node honesty verification, which can avoid the phenomenon of malicious training model parameters being added to federated learning, thereby improving the security of federated learning.

[0067] As an example, the multi-party federated learning method includes, through steps S40 to S50: applied to the central node, by obtaining the training model parameters and node honesty generated by the participating nodes based on the learning parameter information, for each participating node, aggregating according to the training model parameters and node honesty to obtain an aggregate model, wherein the participating nodes are used to determine the training model parameters and the zero-knowledge proof corresponding to the training model parameters based on the learning parameter information, and determine the node honesty according to the installation information of the zero-knowledge proof in the blockchain network, and when the aggregate model converges, the aggregate model is used as the target federated learning model. By determining the training model parameters and the node honesty corresponding to the zero-knowledge proof according to the learning parameter information in the participating nodes, and determining the aggregate model with the node honesty and the training model parameters, and obtaining the target federated learning model when the aggregate model converges. This avoids the problem in the prior art that the model weights of multiple participants are directly sent to the central server for aggregation (there is no guarantee that the multiple participants are trusted participants), which causes the central server to be interfered with by the training parameters of malicious participants. This multi-party federated learning method obtains the training model parameters of each participating node and the node honesty corresponding to the zero-knowledge proof, determines the aggregation model based on the training model parameters and node honesty at the central node, and obtains the target federated learning model when the aggregation model converges, to ensure that the central node will not be interfered with by the training parameters of malicious participants, thereby improving the accuracy of multi-party federated learning.

[0068] Embodiment 4

[0069] Further, in another embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above description and will not be described in detail later. On this basis, for each participating node, the steps of determining the aggregation model according to the training model parameters and the node honesty include:

[0070] Step S41, for each participating node, when the node honesty is a preset trusted node, determine the node hash value of the participating node in the blockchain network, and determine the calculated hash value corresponding to the participating node;

[0071] Step S42, when the node hash value matches the calculated hash value, determining that the participating node is a trusted participating node;

[0072] Step S43, obtaining an aggregate model based on the training model parameters of each trusted participating node.

[0073] In this embodiment, when conducting federated training, each participating node will be prioritized. When the node honesty is a preset trusted node, that is, the participating node is determined to be trusted, the node hash value of the participating node will be determined in the blockchain network, that is, the information uploaded by the participating node in addition to the verification key, also has a node hash value. The node hash value refers to the hash value of the participating node when training, and the calculated hash value corresponding to the participating node is determined at the same time. The calculated hash value refers to the hash value deduced based on the training model parameters of the participating node. At this time, only when the node hash value matches the calculated hash value (such as the same), the participating node can be determined as a trusted participating node. On the contrary, when the node honesty is a preset untrustworthy node, or the node hash value does not match the calculated hash value, the participating node will not be used as a trusted participating node. If the participating node is verified to be valid after the commitment, the central node will calculate the hash value of the received parameters of the node and compare it with the hash value h1 stored on the blockchain. If the calculated hash value is exactly the same as h1, the central node can confirm the authenticity of the received parameters and the parameters used to verify the proof, and continue with subsequent processing. During the whole process, the training parameters themselves are kept confidential, and only their hash values, zero-knowledge proof verification algorithms and verification keys are disclosed, thereby ensuring the security of the internal data of the participating nodes. At this point, all the trusted participating nodes can be determined, and then the aggregated model is obtained by aggregating the training model parameters of the trusted participating nodes. For example, after the central node receives the aggregation notification, it selects an aggregation algorithm (such as FedAvg) to calculate the global model parameters for the model parameters uploaded by all the trusted participating nodes, and then evaluates whether the global model converges. If it converges, the training ends and no iteration is performed.

[0074] Further, after the step of determining the aggregation model according to the training model parameters and the node honesty, it includes:

[0075] Step S44: when the aggregation model has not converged, determine the next round of parameter information corresponding to the aggregation model, and send the next round of parameter information as learning parameter information to the participating nodes.

[0076] In this embodiment, after obtaining the aggregation model, it will be determined whether the aggregation model has converged for subsequent judgment, and when the aggregation model has not converged, the next round of parameter information corresponding to the aggregation model will be determined, and the next round of parameter information will be sent to the participating nodes as learning parameter information. The next round of parameter information at this time refers to the generation of new parameters based on the aggregation model, such as a new machine learning model (such as a neural network structure), an optimization algorithm (such as gradient descent), a loss function, the number of iterations, etc. The participating nodes can be all participating nodes or the trusted participating nodes determined last time. That is, the next round of parameter information is sent to the blockchain network as learning parameter information, and the central node broadcasts a message to each participating node, notifying them that they can download the updated global model and start the next round of training. At this time, the participating nodes download the latest global model parameters from the central node or the blockchain network, and use these parameters as the starting point for the next round of training until the final determined aggregation model converges.

[0077] Embodiment 5

[0078] The present application also provides a multi-party federated learning system. Figure 5 , Figure 5 This is a structural diagram of a multi-party federated learning system provided in Example 5 of the present application. The multi-party federated learning system is applied to a blockchain network. The multi-party federated learning system includes:

[0079] Participating node A10 is used to obtain the learning parameter information sent by the central node, and determine the training generation information according to the learning parameter information, wherein the training generation information includes the training model parameters and the zero-knowledge proof corresponding to the training model parameters; obtain the installation information of the zero-knowledge proof in the blockchain network, and determine the node honesty according to the installation information; send the training model parameters and the node honesty to the central node;

[0080] The central node A20 is used to obtain the training model parameters and node honesty generated by the participating nodes based on the learning parameter information. For each participating node, the aggregation model is obtained based on the training model parameters and node honesty. When the aggregation model converges, the aggregation model is used as the target federated learning model.

[0081] Optionally, the participating node A10 is further configured to:

[0082] A local training model is obtained by training based on the learning parameter information and the preset local data, and a zero-knowledge proof corresponding to the local training model is generated;

[0083] When the local training model has not converged, the local training model is updated based on a preset loss function, and a step of generating a zero-knowledge proof corresponding to the local training model is performed based on the updated local training model;

[0084] When the local training model converges, the local training model is used as the training model parameters, and the training model parameters and zero-knowledge proof are used as training generation information.

[0085] Optionally, the participating node A10 is further configured to:

[0086] If the number of installations in the installation information is greater than a preset installation threshold, then the verification information corresponding to the zero-knowledge proof is determined;

[0087] Obtaining a node signature result corresponding to the zero-knowledge proof, wherein the node signature result includes a first node signature result of the central node verifying the zero-knowledge proof based on the verification information and a second node signature result of the other participating nodes verifying the zero-knowledge proof based on the verification information;

[0088] When the first node signature result is verified, and the number of second node signature results that pass verification is greater than the first threshold, the node honesty is determined to be a preset trusted node, or,

[0089] When the first node signature result fails the verification, and the verification pass number of the second node signature result is greater than the second threshold, the node honesty is determined to be a preset trusted node, wherein the second threshold is greater than the first threshold.

[0090] Optionally, the participating node A10 is further configured to:

[0091] Determine the proposal node in the blockchain network;

[0092] When the proposing node is a participating node, the step of determining the node’s honesty based on the installation information is executed;

[0093] When the proposing node is another participating node, the node honesty of the other participating nodes is obtained, wherein the other participating nodes are used to determine the node honesty according to the installation information;

[0094] When the proposing node is a central node, the node honesty of the central node is obtained, wherein the central node is used to verify the zero-knowledge proof based on the verification information of the zero-knowledge proof, obtain the first node signature result, and use the first node signature result as the node honesty.

[0095] Optionally, the central node A20 is further used for:

[0096] For each participating node, when the node honesty is a preset trusted node, determine the node hash value of the participating node in the blockchain network, and determine the calculated hash value corresponding to the participating node;

[0097] When the node hash value matches the calculated hash value, the participating node is determined to be a trusted participating node;

[0098] The aggregate model is obtained by aggregating the training model parameters of each trusted participating node.

[0099] Optionally, the central node A20 is further used for:

[0100] When the aggregation model has not converged, the next round of parameter information corresponding to the aggregation model is determined, and the next round of parameter information is sent to the participating nodes as learning parameter information.

[0101] The multi-party federated learning system provided by the present invention adopts the multi-party federated learning method in the above embodiment to solve the technical problem of low accuracy of multi-party federated learning. Compared with the prior art, the beneficial effects of the multi-party federated learning system provided by the embodiment of the present invention are the same as the beneficial effects of the multi-party federated learning method provided by the above embodiment, and other technical features of the multi-party federated learning system are the same as those disclosed in the above embodiment method, which will not be described in detail here.

[0102] Embodiment 6

[0103] An embodiment of the present invention provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the multi-party federated learning method in the above-mentioned embodiment 1.

[0104] Reference below Figure 6 , which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure. The electronic device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0105] like Figure 6 As shown, the electronic device may include a processing system 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which may perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage system 1003 into a random access memory (RAM) 1004. Various programs and data required for the operation of the electronic device are also stored in the RAM 1004. The processing system 1001, the ROM 1002, and the RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus.

[0106] Typically, the following systems can be connected to the I / O interface 1006: an input system 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output system 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage system 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication system 1009. The communication system can allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an electronic device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0107] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication system 1009, or installed from the storage system 1003, or installed from the ROM 1002. When the computer program is executed by the processing system 1001, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0108] The electronic device provided by the present invention adopts the multi-party federated learning method in the above embodiment to solve the technical problem that the accuracy of multi-party federated learning is not high. Compared with the prior art, the beneficial effects of the electronic device provided by the embodiment of the present invention are the same as the beneficial effects of the multi-party federated learning method provided by the above embodiment, and other technical features in the electronic device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0109] It should be understood that the various parts of the present disclosure can be implemented with hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0110] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

[0111] Embodiment 7

[0112] This embodiment provides a storage medium, which may be a computer-readable storage medium having computer-readable program instructions stored thereon, and the computer-readable program instructions are used to execute the multi-party federated learning method in the above embodiment.

[0113] The computer-readable storage medium provided in the embodiment of the present invention may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0114] The computer-readable storage medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0115] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the electronic device, the participating node of the electronic device in the blockchain network executes: obtaining the learning parameter information sent by the central node, and determining the training generation information according to the learning parameter information, wherein the training generation information includes the training model parameters and the zero-knowledge proof corresponding to the training model parameters; obtaining the installation information of the zero-knowledge proof in the blockchain network, and determining the node honesty according to the installation information; sending the training model parameters and the node honesty to the central node. The central node in the blockchain network executes: obtaining the training model parameters and the node honesty generated by the participating nodes based on the learning parameter information, and for each participating node, aggregating the training model parameters and the node honesty to obtain the aggregate model; when the aggregate model converges, the aggregate model is used as the target federated learning model.

[0116] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0117] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and program product according to various embodiments of the present invention. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0118] The modules involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of the module does not limit the unit itself in some cases.

[0119] The computer-readable storage medium provided by the present invention stores computer-readable program instructions for executing the above-mentioned multi-party federated learning method, which solves the technical problem that the accuracy of multi-party federated learning is not high. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the embodiment of the present invention are the same as the beneficial effects of the multi-party federated learning method provided by the above-mentioned embodiment, and are not described in detail here.

[0120] Embodiment 8

[0121] The present application also provides a program product, including a computer program, which implements the steps of the multi-party federated learning method as described above when executed by a processor.

[0122] The program product provided by this application solves the technical problem of low accuracy of multi-party federated learning. Compared with the prior art, the beneficial effects of the program product provided by the embodiment of the present invention are the same as the beneficial effects of the multi-party federated learning method provided by the above embodiment, which will not be repeated here.

[0123] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A multi-party federated learning method, characterized in that: The multi-party federated learning method is applied to participating nodes in a blockchain network, and the multi-party federated learning method includes: Obtaining learning parameter information sent by the central node, and determining training generation information according to the learning parameter information, wherein the training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters; Obtaining installation information of the zero-knowledge proof in the blockchain network, and determining node honesty based on the installation information; The training model parameters and the node honesty are sent to the central node, wherein the central node is used to determine an aggregation model based on the training model parameters and the node honesty, and when the aggregation model converges, the aggregation model is used as a target federated learning model.

2. The multi-party federated learning method according to claim 1, characterized in that: The step of determining the training generation information according to the learning parameter information comprises: Performing training based on the learning parameter information and preset local data to obtain a local training model, and generating a zero-knowledge proof corresponding to the local training model; When the local training model has not converged, updating the local training model based on a preset loss function, and performing the step of generating a zero-knowledge proof corresponding to the local training model based on the updated local training model; When the local training model converges, the local training model is used as a training model parameter, and the training model parameter and the zero-knowledge proof are used as training generation information.

3. The multi-party federated learning method according to claim 1, characterized in that: The step of determining the node honesty according to the installation information comprises: If the number of installations in the installation information is greater than a preset installation threshold, determining verification information corresponding to the zero-knowledge proof; Obtaining a node signature result corresponding to the zero-knowledge proof, wherein the node signature result includes a first node signature result of the central node verifying the zero-knowledge proof based on the verification information and a second node signature result of other participating nodes verifying the zero-knowledge proof based on the verification information; When the first node signature result is verified, and the number of verification passes of the second node signature result is greater than a first threshold, the node honesty is determined to be a preset trusted node, or, When the first node signature result fails the verification, and the number of verification passes of the second node signature result is greater than a second threshold, the node honesty is determined to be a preset trusted node, wherein the second threshold is greater than the first threshold.

4. The multi-party federated learning method according to claim 1, characterized in that: Before the step of determining the node honesty according to the installation information, the multi-party federated learning method further includes: Determining a proposal node in the blockchain network; When the proposing node is the participating node, a step of determining the node honesty according to the installation information is performed; When the proposal node is another participating node, the node honesty of the other participating node is obtained, wherein the other participating node is used to determine the node honesty according to the installation information; When the proposing node is the central node, the node honesty of the central node is obtained, wherein the central node is used to verify the zero-knowledge proof based on the verification information of the zero-knowledge proof, obtain a first node signature result, and use the first node signature result as the node honesty.

5. A multi-party federated learning method, characterized in that: The multi-party federated learning method is applied to a central node in a blockchain network, and the multi-party federated learning method includes: Obtaining training model parameters and node honesty generated by participating nodes based on learning parameter information, and determining an aggregation model for each participating node according to the training model parameters and the node honesty, wherein the participating node is used to determine the training model parameters and the zero-knowledge proof corresponding to the training model parameters based on the learning parameter information, and determine the node honesty according to the installation information of the zero-knowledge proof in the blockchain network; When the aggregate model converges, the aggregate model is used as a target federated learning model.

6. The multi-party federated learning method according to claim 5, characterized in that: The step of determining the aggregation model for each of the participating nodes according to the training model parameters and the node honesty includes: For each of the participating nodes, when the node honesty is a preset trusted node, determining the node hash value of the participating node in the blockchain network, and determining the calculated hash value corresponding to the participating node; When the node hash value matches the calculated hash value, determining that the participating node is a trusted participating node; The training model parameters of each of the trusted participating nodes are aggregated to obtain an aggregate model.

7. The multi-party federated learning method according to claim 5, characterized in that: After the step of determining the aggregation model according to the training model parameters and the node honesty, the method further comprises: When the aggregation model has not converged, next round parameter information corresponding to the aggregation model is determined, and the next round parameter information is sent to the participating nodes as learning parameter information.

8. A multi-party federated learning system, characterized in that: The multi-party federated learning system is applied to a blockchain network, and the multi-party federated learning system includes: A participating node is used to obtain the learning parameter information sent by the central node, and determine the training generation information according to the learning parameter information, wherein the training generation information includes the training model parameters and the zero-knowledge proof corresponding to the training model parameters; obtain the installation information of the zero-knowledge proof in the blockchain network, and determine the node honesty according to the installation information; send the training model parameters and the node honesty to the central node; The central node is used to obtain the training model parameters and node honesty generated by the participating nodes based on the learning parameter information, and for each participating node, determine the aggregation model according to the training model parameters and the node honesty; when the aggregation model converges, use the aggregation model as the target federated learning model.

9. A multi-party federated learning device, characterized in that: The multi-party federated learning device includes: at least one processor; a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the multi-party federated learning method described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a program for implementing the multi-party federated learning method, and the program for implementing the multi-party federated learning method is executed by a processor to implement the steps of the multi-party federated learning method as described in any one of claims 1 to 7.

11. A program product, characterized in that The program product includes a multi-party federated learning program, which, when executed by a processor, implements the steps of the multi-party federated learning method according to any one of claims 1 to 7.

Images