Multi-party federated learning methods, systems, devices, storage media, and program products

Abstract

This application discloses a multi-party federated learning method, system, device, storage medium, and program product, relating to the field of federated learning technology and applied to participating nodes in a blockchain network. The method includes: 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 corresponding zero-knowledge proofs; obtaining installation information of the zero-knowledge proofs 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 uses the training model parameters and node honesty to determine an aggregation model, and when the aggregation model converges, uses the aggregation model as the target federated learning model. This application solves the technical problem of low accuracy in multi-party federated learning.

Description

Technical Field

[0001] This 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 Technology

[0002] With the continuous development of federated learning technology, its use in various fields is becoming more and more frequent, which has also raised higher requirements for the security of multi-party federated learning.

[0003] Currently, in multi-party federated learning, multiple participants can use their own data to train models locally, and then send their updated model weights to a central server for aggregation to complete the multi-party federated learning. However, this multi-party federated learning method suffers from the problem that the central server's training parameters can be interfered with by malicious participants because the model weights of multiple participants are directly sent to the central server (the central node in this example) for aggregation (which cannot guarantee whether the multiple participants are trustworthy). Therefore, this multi-party federated learning method suffers from the problem that the central server's training parameters can be interfered with by malicious participants, resulting in low accuracy.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is 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 in multi-party federated learning.

[0006] To achieve the above objectives, this 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] The learning parameter information sent by the central node is obtained, and the training generation information is determined 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;

[0008] Obtain the installation information of the zero-knowledge proof in the blockchain network, and determine the honesty of the node 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 the aggregate model based on the training model parameters and the node honesty, and when the aggregate model converges, the aggregate model is used as the target federated learning model.

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

[0011] The training model parameters and node honesty generated by participating nodes based on learning parameter information are obtained. For each participating node, an aggregation model is determined based on the training model parameters and node honesty. 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 to determine node honesty based on the installation information of the zero-knowledge proof in the blockchain network.

[0012] When the aggregation model converges, it is used as the target federated learning model.

[0013] To achieve the above objectives, this application also provides a multi-party federated learning system applied to a blockchain network, the multi-party federated learning system comprising:

[0014] Participating nodes are used to obtain learning parameter information sent by the central node, and determine 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; obtain installation information of the zero-knowledge proofs in the blockchain network, and determine node honesty based on the installation information; and 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. For each participating node, an aggregation model is determined according to the training model parameters and the node honesty. When the aggregation model converges, the aggregation model is used as the target federated learning model.

[0016] This application also provides a multi-party federated learning device, the multi-party federated learning device comprising: 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, the instructions being 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 as described above.

[0017] This application also provides a storage medium storing a program for implementing a multi-party federated learning method, wherein when the program for the multi-party federated learning method is executed by a processor, it implements the steps of the multi-party federated learning method as described above.

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

[0019] The multi-party federated learning method of this application is applied to participating nodes in a blockchain network. It obtains learning parameter information sent by the central node and determines training generation information based on the learning parameter information. The training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters. It obtains the installation information of the zero-knowledge proofs in the blockchain network and determines the honesty of the nodes based on the installation information. It sends the training model parameters and node honesty to the central node, whereby the central node determines the aggregation model based on the training model parameters and node honesty, and uses the aggregation model as the target federated learning model when the aggregation model converges.

[0020] By determining the training model parameters and corresponding zero-knowledge proofs based on the learning parameter information, and then determining the honesty of nodes in the blockchain network based on the zero-knowledge proofs, the node honesty and training model parameters are sent together to the central node. The central node then determines the aggregated model based on the training model parameters and node honesty, and uses the aggregated model as the target federated learning model when it converges. This avoids the problem in existing technologies where the model weights of multiple participants are directly sent to the central server for aggregation (which cannot guarantee whether the participants are trustworthy), leading to interference with the central server's training by malicious participants' training parameters. This multi-party federated learning method improves the accuracy of multi-party federated learning by ensuring that the central node is not interfered with by malicious participants' training parameters by determining the training model parameters and zero-knowledge proofs at participating nodes, determining node honesty in the blockchain network based on the zero-knowledge proofs, and finally determining the aggregated model at the central node based on the training model parameters and node honesty, and using the aggregated model as the target federated learning model when it converges. Attached Figure Description

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

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating the multi-party federated learning method provided in Embodiment 1 of this application;

[0024] Figure 2 This is a schematic diagram of a scenario for the multi-party federated learning approach in this application;

[0025] Figure 3 This is a flowchart illustrating the multi-party federated learning approach used in this application;

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

[0027] Figure 5 This is a schematic diagram of the structure of the multi-party federated learning system provided in Embodiment 5 of this application;

[0028] Figure 6 This is a schematic diagram of the structure of the electronic device provided in Embodiment Six of this application.

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

[0030] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Example 1

[0032] While existing federated learning methods protect individual privacy by isolating raw data, the following security and privacy threats still exist: 1. The iterative process of federated learning does not verify the participants. Especially when there are many participants, it is easier for malicious participants to update their local models with fake training data, or provide incorrect local training model parameters or perturbed models to the central server. Unverified parameters provided by malicious nodes can 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. Existing federated learning mechanisms still have the potential to leak user privacy. For example, malicious federated learning participants can infer sensitive information from parameters shared by honest users. The common solutions to these shortcomings are the following two improvements. One approach involves each participant uploading their local trained model to the blockchain. Participants then download other participants' local models from the blockchain, calculate Euclidean distance between them to obtain model similarity, and score the models based on their local data. This ensures the local models are not vulnerable to malicious attacks. The scoring results are uploaded to the blockchain. This improvement is public to all participants, allowing them access to each other's model parameters and potentially enabling back-calculation of model details through updated gradients, thus posing a privacy risk. The other improvement involves a central server verifying the training process, proving its correctness to the publisher without disclosing the trainers' privacy data. However, this centralized verification process places significant pressure on the central server, and the federated learning process only stores the verification locally, making subsequent retrieval and verification difficult.

[0033] Therefore, based on the above-mentioned shortcomings of multi-party federated learning, this application proposes a new multi-party federated learning method to ensure that the training parameters of the central node are not interfered with by malicious participants, thereby improving the accuracy of multi-party federated learning.

[0034] This application provides a multi-party federated learning method. In the first embodiment of the multi-party federated learning method of this application, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the multi-party federated learning method provided in Embodiment 1 of this application. The multi-party federated learning method is applied to participating nodes in a blockchain network and includes:

[0035] Step S10: Obtain the learning parameter information sent by the central node, and determine the training generation information based on the learning parameter information. The training generation information includes the training model parameters and the zero-knowledge proofs corresponding to the training model parameters.

[0036] In this embodiment, the multi-party federated learning method is applied to participating nodes. There can be multiple participating nodes, meaning at least three or more exist (this is related to subsequent verification and judgment; on the other hand, if only two exist, it could be a situation where there is only one participating node and a central node as participating nodes, meaning there is only one participating node besides the central node, and there is no meaning in the subsequent execution process; the choice can be made according to the actual situation). These participating nodes interact with the central node to complete the multi-party federated learning. It is worth noting that the central node can be used as a participating node in subsequent federated learning, or it can simply be used as the aggregation central node (participating nodes refer to servers, terminals, etc., participating in multi-party federated learning; central nodes refer to servers, terminals, etc., participating in multi-party federated learning and distributing and aggregating all training data), such as federated learning of image data, audio data, or human features and voices.

[0037] In one embodiment, during multi-party federated learning, participating nodes receive learning parameter information sent by the central node. This means the central node informs each participating node how to train and provides relevant training parameters. The learning parameter information can be obtained directly from the central node or from the blockchain network. Specifically, the central node uploads the learning parameter information to the blockchain network to avoid the time-consuming process of sending it to each participating node individually. Alternatively, it can 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 the machine learning model (e.g., neural network structure), optimization algorithm (e.g., gradient descent), loss function, number of iterations, etc. These parameters can be initial or parameters obtained after multiple training iterations; no limitation is imposed here. At this point, training can be performed on the participating nodes to obtain training-generated information. This information includes the training model parameters and the corresponding zero-knowledge proofs. That is, training is performed based on the learning parameter information and the parameters within the participating nodes, and the converged parameters are used as the training model parameters. Simultaneously, a corresponding zero-knowledge proof is generated for each training iteration. The information within this proof can be the hash value or other key parameters obtained from each training iteration. Zero-knowledge proof, a concept first proposed by S. Goldwasser et al. in 1985, aims to allow the prover to successfully convince the verifier of the truth of a specific statement without revealing any substantial information to the verifier. Based on the training model parameters and the zero-knowledge proof, it is then determined whether the participating node needs to participate in multi-party federated learning to avoid the impact on the entire multi-party federated learning process if the participating node is malicious.

[0038] Step S20: Obtain the installation information of zero-knowledge proofs in the blockchain network, and determine the honesty of nodes based on the installation information;

[0039] Step S30: The training model parameters and node honesty are sent to the central node, whereby the central node is used to determine the aggregate model based on the training model parameters and node honesty, and when the aggregate model converges, it is used as the target federated learning model.

[0040] In this embodiment, after obtaining the training model parameters and zero-knowledge proofs of the participating nodes, the zero-knowledge proofs are sent to the blockchain network to determine the node honesty of the zero-knowledge proofs. Then, the node honesty and training model parameters are sent to the central node. The central node can then determine the aggregation model based on the training model parameters and node honesty. When the aggregation model converges, it is used as the target federated learning model (i.e., the central node learns based on the honesty of each participating node, avoiding the influence of malicious participating nodes), rather than directly performing federated learning based on the training model parameters. This avoids 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 on the installation of the smart contract within the zero-knowledge proof by other participating nodes besides the current participating node. For example, if 50% of the other participating nodes have installed the smart contract within the zero-knowledge proof, node honesty refers to the honesty of the node within the smart contract. Generally, it is either verified successfully or unsuccessfully. If the verification is successful, the current participating node is determined to be a trustworthy participating node and can participate in multi-party federated learning; if the verification fails, the current participating node is determined to be a suspicious participating node and cannot participate in multi-party federated learning. 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. In this implementation, the node can be the participating node, other participating nodes, or the central node. That is, the honesty of a node is determined by the participating node, other participating nodes, or the central node based on the installation information.

[0041] In one embodiment, reference is made to Figure 2 , Figure 2This is a schematic diagram of a scenario for the multi-party federated learning method proposed in this application. The entire process of the multi-party federated learning method is as follows: the central node issues a federated learning task (initially requiring distributed model initialization); each participating node trains its local model using local data; after the local model converges, the local model parameters are obtained, and a zero-knowledge proof about the model parameters is generated; then, the updated local model parameters are uploaded to the central node, and the zero-knowledge proof is uploaded to the blockchain network for trusted verification. The zero-knowledge proof can identify honest nodes based on node honesty on the blockchain verification network, and notify the central node to aggregate the training models of the honest nodes. By judging whether the aggregated training model has converged, if the aggregated training model has converged, it is directly output; otherwise, if the aggregated training model has not converged, the new global model parameters are uploaded to the blockchain network so that other participating nodes can retrain based on the new global model parameters uploaded to the blockchain network, and the process of each participating node training its local model using local data and the new global model parameters is repeated 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 ensures the honesty of all participants and avoids various attacks by malicious nodes, such as gradient backpropagation. By designing a combination of zero-knowledge proofs and blockchain for the multi-participant federated learning training process, it guarantees the secure convergence of the global federated learning model. Process parameters are not disclosed to others, effectively protecting privacy and security. Simultaneously, the decentralized node verification process (not using a single node for malicious node verification) reduces the transaction verification time of trusted nodes, improves their verification efficiency, and leverages the distributed nature of blockchain to identify and mark malicious nodes.

[0042] As an example, the multi-party federated learning method includes steps S10 to S30: participating nodes in the blockchain network obtain learning parameter information sent by the central node and determine training generation information based on the learning parameter information, wherein the training generation information includes training model parameters and corresponding zero-knowledge proofs; obtain the installation information of the zero-knowledge proofs in the blockchain network and determine node honesty based on the installation information; send the training model parameters and node honesty to the central node, wherein the central node determines an aggregate model based on the training model parameters and node honesty, and uses the aggregate model as the target federated learning model when the aggregate model converges. The method involves determining the training model parameters and corresponding zero-knowledge proofs based on the learning parameter information, then determining node honesty in the blockchain network based on the zero-knowledge proofs, and sending the node honesty and training model parameters together to the central node. The central node then determines an aggregate model based on the training model parameters and node honesty, and uses the aggregate model as the target federated learning model when the aggregate model converges. This avoids the problem in existing technologies where the model weights of multiple participants are directly sent to the central server for aggregation (which cannot guarantee whether the participants are trustworthy), leading to interference with the central server's training parameters by malicious participants. This multi-party federated learning method determines the training model parameters and zero-knowledge proofs at the participating nodes, and then determines the honesty of the nodes in the blockchain network based on the zero-knowledge proofs. Finally, the central node determines the aggregated model based on the training model parameters and the honesty of the nodes, and when the aggregated model converges, it uses the aggregated model as the target federated learning model. This ensures that the central node is not interfered with by the training parameters of malicious participants, thereby improving the accuracy of multi-party federated learning.

[0043] Example 2

[0044] Furthermore, in another embodiment of this application, content that is the same as or similar to that in Embodiment 1 described above can be referred to the above description and will not be repeated hereafter. Based on this, the step of determining the training generated information according to the learning parameter information includes:

[0045] Step S11: Train the local training model based on the learning parameter information and the preset local data, and generate the zero-knowledge proof corresponding to the local training model.

[0046] Step S12: When the local training model has not converged, update the local training model based on the preset loss function, and perform the step of generating the zero-knowledge proof corresponding to the local training model based on the updated local training model.

[0047] Step S13: When the locally trained model converges, the locally trained model is used as the training model parameter, and the training model parameter and zero-knowledge proof are used as training generated information.

[0048] In this embodiment, after receiving the learning parameter information, training is performed on each participating node based on the learning parameter information to obtain training generation information. During training, a local training model is mainly trained based on the learning parameter information and preset local data. Simultaneously, a zero-knowledge proof corresponding to the local training model is generated. The process of training the local training model based on the learning parameter information and preset local data can be consistent with existing learning and training processes and is not limited here. The preset local data refers to the internal data of the participating nodes, such as the parameters used for training. This data is unique to each participating node and is not publicly disclosed. The zero-knowledge proof corresponding to the local training model can be parameters such as the hash value corresponding to the local training model. At this point, it is determined whether the local training model has converged to determine whether it needs to be output as the final result. The convergence determination method can be consistent with commonly used convergence determination methods, such as a parameter reaching a threshold or reaching a defined number of training iterations. Finally, if the locally trained model fails to converge, it is updated based on a preset loss function. The updated model then generates zero-knowledge proofs corresponding to the local training model. Conversely, if the local training model converges, it is used as the training model parameters, along with the zero-knowledge proofs, as training generation information. The preset loss function refers to the loss function value defined within the participating nodes. Participating nodes perform multiple rounds of local training using local data and downloaded learning parameters. In each iteration, the model is updated based on the gradient of the loss function on the local dataset until a converged local model is obtained. After each iteration, the participating nodes generate not only updated model parameters but also updated zero-knowledge proofs. Using the training model parameters and zero-knowledge proofs as training generation information for subsequent federated learning allows for the determination of whether participating nodes are malicious, enabling selective participation in federated learning based on the determination results, thus ensuring the accuracy of multi-party federated learning.

[0049] In one embodiment, reference is made to Figure 3 , Figure 3This is a flowchart illustrating the multi-party federated learning method proposed in this application. The central node publishes an initial model. Each participating node trains its local model using local data and generates commitments (zero-knowledge proofs). The updated local model parameters are then uploaded to the central node, and the zero-knowledge proofs are uploaded to the blockchain network for trusted verification. The zero-knowledge proofs are verified on the blockchain verification network, and the central node is notified to aggregate the trained models from the honest nodes. If the aggregated trained model fails to converge, the global parameter model is published to all participants, and they are notified to use the parameters for the next round of training. This training process is repeated until the model converges. The entire process, based on zero-knowledge proof verification, ensures the security of federated learning.

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

[0051] Step S21: If the number of installations in the installation information is greater than the preset installation threshold, then determine the verification information corresponding to the zero-knowledge proof.

[0052] Step S22: Obtain the node signature results corresponding to the zero-knowledge proof. The node signature results include the first node signature results of the central node verifying the zero-knowledge proof based on the verification information and the second node signature results of the other participating nodes verifying the zero-knowledge proof based on the verification information.

[0053] Step S23: If the first node's signature result is verified successfully, and the number of verified signatures of the second node is greater than the first threshold, then the node's honesty is determined to be a preset trusted node, or...

[0054] Step S24: When the first node's signature result is a verification failure, and the number of verification successes of the second node's signature result is greater than the second threshold, then the node's 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, it is sent to the blockchain network, and the training model parameters are also sent to the central node. To ensure data privacy, homomorphic or semi-homomorphic encryption algorithms can be selected for transmission. That is, at this point, the zero-knowledge proof is needed to demonstrate to the central node and other participating nodes that the parameters to be transmitted to the central node are genuine. When verifying the zero-knowledge proof, participating nodes package the verification logic (i.e., the zero-knowledge proof) into a smart contract, place it locally or store it on a shared server, and publish a message containing the smart contract address and a brief description through the blockchain network. This notifies other participating nodes based on the proposing nodes on the blockchain network. Upon receiving the message, other participating nodes first verify its validity based on the brief description, including the message's source and completeness. After successful verification, other participating nodes download the smart contract from the address provided in the message and install and deploy it locally. After installation and deployment, other participating nodes send confirmation messages to the participating node via the blockchain network, indicating that the smart contract has been successfully acquired and deployed. This confirmation is reflected in the installation count in the installation information. At this point, the installation count in the installation information is checked. If the installation count is greater than a preset threshold, subsequent verification is executed. Otherwise, it waits for the installation count to exceed the preset threshold, which is a user-defined value, such as 2 / 3. Once a participating node receives confirmation messages from more than 2 / 3 of the other participating nodes, it publishes the verification key, the hash value h1 of the training parameters, and simple additional information via the blockchain. Because the participating node is now the proposal node, it directly determines the verification information corresponding to the zero-knowledge proof. The verification information refers to the verification key used to sign and verify the zero-knowledge proof. When other participating nodes receive the verification key, the smart contract automatically executes the verification process. If the verification passes, it signs to confirm the authenticity of the zero-knowledge proof; otherwise, it does not sign, indicating that the zero-knowledge proof verification has failed. The final node honesty is not determined solely by the results of a single participating node, but rather by considering the results of all participating nodes. At this point, due to conflicting interests, it is assumed that the central node is honest. The nodes owned by the central node, as the only globally trusted nodes on the blockchain, have the right to publish a list of trusted (or suspicious) nodes on the blockchain.In other words, the node signature results at this time include 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, there are two results of the central node and other participating nodes verifying the zero-knowledge proof. Then, the honesty of the node 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 as passed and the number of verified second node signature results is greater than a first threshold, the node is determined to be a preset trusted node. Alternatively, when the first node signature result is verified as failed and the number of verified second node signature results is greater than a second threshold, the node is determined to be a preset trusted node. The second threshold is greater than the first threshold. The second threshold and the first threshold are two thresholds defined by the user. The preset trusted node means that the participating node is a trusted node. Verification passed means that the participating node is a trusted node. Verification failed means that the participating node is a suspicious node. If node A is marked as a trusted node by the central node, its second node signature is considered valid if it exceeds one-third of the node signatures. If node A is marked as a suspicious node by the central node, its second node signature is considered valid only if it exceeds two-thirds of the node signatures. It's worth noting that, according to the basic blockchain transaction validity verification rules, a node whose transaction is verified as invalid three times consecutively is automatically marked as a suspicious node. That is, a node whose transaction is defined as invalid three times consecutively by the blockchain network is directly marked as a suspicious node without further judgment of the node signature results. Furthermore, a proof with more than half of the node signatures can be defined as valid and permanently recorded on the blockchain, thus being considered an immutable and reliable record. In this case, other nodes in the blockchain network can query and confirm the zero-knowledge proof in a certain round, meeting the needs of security auditing.

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

[0057] Step S31: Identify the proposal nodes in the blockchain network;

[0058] Step S32: When the proposing node is a participating node, the step of determining the honesty of the node based on the installation information is executed.

[0059] Step S33: When the proposal 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 based on the installation information.

[0060] Step S34: When the proposal node is the central node, the node honesty of the central node is obtained. 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.

[0061] In this embodiment, after determining the installation information in the blockchain network, the step of determining the proposal nodes in the blockchain network is also executed, and the subsequent execution process is determined based on the determination of the proposal nodes. For example, all nodes on the blockchain network elect (election methods include but are not limited to random generation, round-robin, etc.) proposal nodes before each block is generated. The proposal nodes are used to collect unverified transactions on the chain, including verification keys, hash values ​​of smart contract addresses, etc. After verification, they are packaged into blocks, signed, and sent to other participating nodes. After receiving the block, the other participating nodes verify the validity of the block and use the transaction information in it to verify the correctness of the proof algorithm. After successful verification, they sign the block and return the signature information to the central node so that the central node can perform subsequent federated learning. At this point, three scenarios emerge. First, if the proposing node is a participating node, the step of determining node honesty based on installation information is executed directly. Second, if the proposing node is another participating node, the node honesty of that other participating node is obtained. In this scenario, the other participating nodes determine node honesty based on installation information; the process of determining node honesty is executed on the other participating nodes. Alternatively, the other participating nodes can directly send their node honesty information to the central node, which is not limited here. Third, if the proposing node is the central node, the node honesty of the central node is obtained. In this scenario, the central node verifies the zero-knowledge proof based on the verification information, obtains the first node's signature result, and uses this first node's signature result as the node honesty. The first node's signature result refers to the central node's node honesty regarding the zero-knowledge proof; in this scenario, the central node's node honesty can be used directly as the basis. Alternatively, the central node can directly obtain and determine the node honesty for subsequent operations. Because the central node is often the initiator of federated learning, due to their shared interests, the nodes owned by the central node are considered globally trusted nodes. If the central node is elected as a proposal node, its verification, excluding transactions from suspicious nodes, is packaged into a block and sent to other participating nodes. These other participating nodes can then directly link to the blockchain by verifying only the central node's signature and block validity, without verifying the validity of transactions within the block. In other words, when the central node is elected as a proposal node, the trusted verification of all participating nodes can be directly based on the central node, without needing to consider the honesty of all participating nodes. This allows verification to be performed based on different proposal nodes, ensuring the efficiency and specificity of node honesty processing.

[0062] Example 3

[0063] Furthermore, based on the above embodiments applied to participating nodes, an embodiment applied to the central node is proposed, with reference to... Figure 4 , Figure 4 This is a flowchart illustrating the multi-party federated learning method provided in Embodiment 3 of this application. The multi-party federated learning method is applied to the central node and includes:

[0064] Step S40: Obtain the training model parameters and node honesty generated by the participating nodes based on the learning parameter information. For each participating node, determine the aggregation model based on the training model parameters and node honesty. The participating nodes are used to determine the training model parameters and the zero-knowledge proofs corresponding to the training model parameters based on the learning parameter information, and determine the node honesty based on the installation information of the zero-knowledge proofs 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 performing federated learning at the central node, the training model parameters and node honesty generated by participating nodes based on learning parameter information are obtained. Then, for each participating node, an aggregate model is determined based on the training model parameters and node honesty. Participating nodes are used to determine the training model parameters and the corresponding zero-knowledge proofs based on the learning parameter information, and to determine node honesty based on the installation information of the zero-knowledge proofs in the blockchain network. At this point, it is 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, an aggregate model is obtained by aggregating the training model parameters of each trustworthy participating node. When the aggregate model converges, the aggregate model is used as the target federated learning model, which is the model that needs to be finally trained. This involves verifying the zero-knowledge proofs submitted by each participating node in the blockchain network based on on-chain verification rules (such as direct verification by the central node as defined above, and joint verification by the central node and participating nodes). After verification and meeting certain conditions (such as more than half of the nodes passing verification), a block containing the proof and related hashes is added to the blockchain network, and honest participating nodes are marked. At the same time, as a notification of node honesty, the central node can securely aggregate the model parameters received from the participating node. After convergence, the aggregated model is used as the target federated learning model. Thus, federated learning of the training model parameters can be performed through node honesty verification, which can prevent malicious training model parameters from being added to the federated learning process, thereby improving the security of federated learning.

[0067] As an example, the multi-party federated learning method includes steps S40 to S50: applying to the central node, obtaining the training model parameters and node honesty generated by participating nodes based on learning parameter information; for each participating node, aggregating based on the training model parameters and node honesty to obtain an aggregated model, wherein participating nodes are used to determine the training model parameters and the corresponding zero-knowledge proofs based on the learning parameter information, and to determine node honesty based on the installation information of the zero-knowledge proofs in the blockchain network; when the aggregated model converges, the aggregated model is used as the target federated learning model. By determining the training model parameters and the node honesty corresponding to the zero-knowledge proofs in the participating nodes based on the learning parameter information, and determining the aggregated model by combining node honesty and training model parameters, the target federated learning model is obtained when the aggregated model converges. This avoids the problem in existing technologies where the model weights of multiple participants are directly sent to the central server for aggregation (which cannot guarantee whether the participants are trustworthy), leading to interference with the training parameters of malicious participants. This multi-party federated learning method obtains the training model parameters and zero-knowledge proofs of each participating node to determine the aggregation model at the central node based on the training model parameters and node honesty. When the aggregation model converges, the target federated learning model is obtained, ensuring that the central node is not interfered with by the training parameters of malicious participants, thereby improving the accuracy of multi-party federated learning.

[0068] Example 4

[0069] Furthermore, in another embodiment of this application, content that is the same as or similar to that in Embodiment 1 described above can be referred to the above description and will not be repeated hereafter. Based on this, the step of determining the aggregation model for each participating node according to the training model parameters and node honesty includes:

[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, the participating node is determined to be a trusted participating node;

[0072] Step S43: Aggregate the training model parameters of each trusted participating node to obtain an aggregated model.

[0073] In this embodiment, during federated training, each participating node is prioritized. If the node's honesty is a preset trusted node, it is determined to be trustworthy. The node's hash value is then determined in the blockchain network. This means that subsequent information uploaded by the participating node includes not only the verification key but also the node hash value (the hash value used during training). Simultaneously, a calculated hash value is determined, derived from the training model parameters. Only when the node hash value matches the calculated hash value (e.g., they are the same) can the participating node be considered a trustworthy node. Conversely, if the node's honesty is a preset untrustworthy node, or if the node hash value and calculated hash value do not match, the participating node will not be considered a trustworthy node. After a participating node's commitment is verified, the central node calculates the hash value of the received parameters and compares it with the hash value h1 stored on the blockchain. If the calculated hash value is identical to h1, the central node confirms the authenticity of the received parameters and the parameters used for verification, and continues with subsequent processing. Throughout the process, the training parameters themselves remain confidential; only their hash values, zero-knowledge proof verification algorithms, and verification keys are disclosed, thus ensuring the security of data within the participating nodes. At this point, all trusted participating nodes can be identified. Then, based on the training model parameters of these trusted nodes, an aggregated model is obtained. If the central node receives the aggregation notification, it selects an aggregation algorithm (such as FedAvg) to calculate the global model parameters from the model parameters uploaded by all trusted participating nodes, and then evaluates whether the global model has converged. If it has converged, the current training session ends, and no further iterations are performed.

[0074] Furthermore, after determining the aggregation model based on the trained model parameters and node honesty, the steps include:

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

[0076] In this embodiment, after obtaining the aggregated model, it is determined whether the aggregated model has converged for further evaluation. If the aggregated model has not converged, the next round of parameter information corresponding to the aggregated model is determined and sent as learning parameter information to the participating nodes. The next round of parameter information refers to new parameters generated based on the aggregated model, such as a new machine learning model (e.g., neural network structure), optimization algorithm (e.g., gradient descent), loss function, number of iterations, etc. The participating nodes can be all participating nodes or the previously determined trusted participating nodes. The next round of parameter information is then sent as learning parameter information to the blockchain network. The central node broadcasts a message to each participating node, notifying them that they can download the updated global model and begin 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 finally determined aggregated model converges.

[0077] Example 5

[0078] This application also provides a multi-party federated learning system, referring to... Figure 5 , Figure 5 This is a schematic diagram of the structure of the multi-party federated learning system provided in Embodiment 5 of this application. The multi-party federated learning system is applied to a blockchain network and includes:

[0079] Participating node A10 is used to obtain learning parameter information sent by the central node, and determine training generation information based on the learning parameter information. The training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters; obtain the installation information of the zero-knowledge proofs in the blockchain network, and determine node honesty based on the installation information; and send the training model parameters and 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 aggregated model is obtained by aggregating the training model parameters and node honesty. When the aggregated model converges, the aggregated model is used as the target federated learning model.

[0081] Optionally, participating node A10 is also used for:

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

[0083] When the local training model fails to converge, the local training model is updated based on a preset loss function, and the step of generating a zero-knowledge proof corresponding to the local training model is executed based on the updated local training model.

[0084] When the locally trained model converges, the locally trained model is used as the training model parameter, and the training model parameter and zero-knowledge proof are used as training generated information.

[0085] Optionally, participating node A10 is also used for:

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

[0087] Obtain the node signature results corresponding to the zero-knowledge proof, wherein the node signature results include the first node signature results of the central node verifying the zero-knowledge proof based on the verification information and the second node signature results of the other participating nodes verifying the zero-knowledge proof based on the verification information.

[0088] If the signature of the first node passes verification, and the number of successful signatures of the second node exceeds the first threshold, then the node is determined to be a pre-defined trusted node, or...

[0089] If the signature result of the first node fails verification, and the number of signature results of the second node that pass verification is greater than the second threshold, then the node is determined to be a preset trusted node, where the second threshold is greater than the first threshold.

[0090] Optionally, participating node A10 is also used for:

[0091] Identify the proposal nodes 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 proposal node is another participating node, the node honesty of the other participating nodes is obtained, where the other participating nodes are used to determine node honesty based on the installation information.

[0094] When the proposal node is the central node, the node honesty of the central node is obtained. 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 also used for:

[0096] For each participating node, when the node's honesty is a preset trusted node, the node hash value of the participating node is determined in the blockchain network, and the calculated hash value corresponding to the participating node is also determined.

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

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

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

[0100] If the aggregation model fails to converge, determine the parameter information for the next round of aggregation model and send the parameter information for the next round as learning parameter information to the participating nodes.

[0101] The multi-party federated learning system provided by this invention employs the multi-party federated learning method described in the above embodiments, thus solving the technical problem of low accuracy in multi-party federated learning. Compared with the prior art, the beneficial effects of the multi-party federated learning system provided by this invention are the same as those of the multi-party federated learning method described in the above embodiments, and other technical features of this multi-party federated learning system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0102] Example 6

[0103] This 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, which are executed by the at least one processor to enable the at least one processor to perform the multi-party federated learning method in Embodiment 1 above.

[0104] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of the present disclosure. The electronic devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0105] like Figure 6 As shown, the electronic device may include a processing system 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage system 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing system 1001, ROM 1002, and RAM 1004 are interconnected 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 I / O interface 1006: input systems 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output systems 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage systems 1003 including, for example, magnetic tapes, hard disks, etc.; and communication systems 1009. The communication system allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although electronic devices with various systems are shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0107] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication system 1009, or installed from storage system 1003, or installed from ROM 1002. When the computer program is executed by processing system 1001, it performs the functions defined above in the methods of embodiments of this disclosure.

[0108] The electronic device provided by this invention employs the multi-party federated learning method described in the above embodiments, thus solving the technical problem of low accuracy in multi-party federated learning. Compared with the prior art, the beneficial effects of the electronic device provided by this invention are the same as those of the multi-party federated learning method described in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

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

[0110] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0111] Example 7

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

[0113] The computer-readable storage medium provided in this embodiment of the invention may be, for example, a USB flash drive, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction 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 aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0115] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by an electronic device, they cause participating nodes in the blockchain network to perform the following actions: acquiring learning parameter information sent by the central node and determining training generation information based on the learning parameter information, wherein the training generation information includes training model parameters and corresponding zero-knowledge proofs; acquiring installation information of the zero-knowledge proofs in the blockchain network and determining node honesty based on the installation information; and sending the training model parameters and node honesty to the central node. The central node in the blockchain network performs the following actions: acquiring the training model parameters and node honesty generated by participating nodes based on the learning parameter information; for each participating node, aggregating the training model parameters and node honesty to obtain an aggregated model; and when the aggregated model converges, using the aggregated model as the target federated learning model.

[0116] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone 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 remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0117] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0118] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0119] The computer-readable storage medium provided by this invention stores computer-readable program instructions for executing the aforementioned multi-party federated learning method, thus solving the technical problem of low accuracy in multi-party federated learning. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this invention are the same as those of the multi-party federated learning method provided in the above embodiments, and will not be repeated here.

[0120] Example 8

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

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

[0123] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this 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, wherein there are at least three participating nodes, and the multi-party federated learning method includes: The learning parameter information sent by the central node is obtained, and the training generation information is determined based on the learning parameter information. The training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters. The zero-knowledge proofs include hash values ​​corresponding to the training model parameters. Obtaining the installation information of the zero-knowledge proof in the blockchain network, and determining node honesty based on the installation information, wherein, prior to the step of determining node honesty based on the installation information, the multi-party federated learning method further includes: The following steps are performed: First, a proposal node is identified in the blockchain network. If the proposal node is a participating node, the step of determining node honesty based on the installation information is executed. If the proposal node is another participating node, the node honesty of that other participating node is obtained, wherein the other participating node is used to determine node honesty based on the installation information. If the proposal 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 node honesty. The training model parameters and the node honesty are sent to the central node, wherein the central node is used to determine the aggregate model based on the training model parameters and the node honesty, and when the aggregate model converges, the aggregate model is used as the target federated learning model.

2. The multi-party federated learning method as described in claim 1, characterized in that, The step of determining the training-generated information based on the learning parameter information includes: A local training model is obtained by training based on the learning parameter information and preset local data, and a zero-knowledge proof corresponding to the local training model is generated. When the local training model fails to converge, the local training model is updated based on a preset loss function, and the step of generating the zero-knowledge proof corresponding to the local training model is performed based on the updated local training model. When the locally trained model converges, the locally trained model is used as the training model parameters, and the training model parameters and the zero-knowledge proof are used as training generation information.

3. The multi-party federated learning method as described in claim 1, characterized in that, The step of determining node honesty based on the installation information includes: 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. Obtain the node signature result corresponding to the zero-knowledge proof, wherein the node signature result 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 participating nodes verifying the zero-knowledge proof based on the verification information; If the signature result of the first node passes verification, and the number of successful signature results of the second node exceeds a first threshold, then the node is determined to be a preset trusted node in terms of honesty. If the signature result of the first node fails verification, and the number of signature results of the second node that pass verification is greater than the second threshold, then the node is determined to be a preset trusted node, wherein the second threshold is greater than the first threshold.

4. A multi-party federated learning method, characterized in that, The multi-party federated learning method is applied to the central node in a blockchain network, and the multi-party federated learning method includes: The method involves obtaining training model parameters and node honesty generated by participating nodes based on learning parameter information. For each participating node, an aggregation model is determined based on the training model parameters and node honesty. The participating node is used to determine the training model parameters and corresponding zero-knowledge proofs based on the learning parameter information. The zero-knowledge proofs include hash values ​​corresponding to the training model parameters. Node honesty is determined based on the installation information of the zero-knowledge proofs in the blockchain network. The multi-party federated learning method further includes: The following steps are performed: First, a proposal node is identified in the blockchain network. If the proposal node is a participating node, the step of determining node honesty based on the installation information is executed. If the proposal node is another participating node, the node honesty of that other participating node is obtained, wherein the other participating node is used to determine node honesty based on the installation information. If the proposal 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 node honesty. When the aggregation model converges, it is used as the target federated learning model.

5. The multi-party federated learning method as described in claim 4, characterized in that, The step of determining the aggregation model for each participating node based on the training model parameters and the node honesty includes: For each participating node, when the node's honesty is a preset trusted node, the node hash value of the participating node is determined in the blockchain network, and the calculated hash value corresponding to the participating node is determined. When the node hash value matches the calculated hash value, the participating node is determined to be a trusted participating node; An aggregated model is obtained by aggregating the training model parameters of each trusted participating node.

6. The multi-party federated learning method as described in claim 4, characterized in that, Following the step of determining the aggregation model based on the trained model parameters and the node honesty, the following steps are included: When the aggregation model fails to converge, the next round parameter information corresponding to the aggregation model is determined, and the next round parameter information is sent to the participating node as learning parameter information.

7. 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: Participating nodes are configured to acquire learning parameter information sent by the central node and determine training generation information based on the learning parameter information. The training generation information includes training model parameters and zero-knowledge proofs corresponding to the training model parameters, wherein the zero-knowledge proofs include hash values ​​corresponding to the training model parameters. The method also acquires installation information of the zero-knowledge proofs in the blockchain network and determines node honesty based on the installation information. Before the step of determining node honesty based on the installation information, the multi-party federated learning method further includes: identifying proposal nodes in the blockchain network; when the proposal node is a participating node, performing the step of determining node honesty based on the installation information; when the proposal node is another participating node, acquiring the node honesty of the other participating nodes, wherein the other participating nodes are used to determine node honesty based on the installation information; when the proposal node is the central node, acquiring the node honesty of the central node, 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 node honesty; and sending 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. For each participating node, an aggregation model is determined according to the training model parameters and the node honesty. When the aggregation model converges, the aggregation model is used as the target federated learning model.

8. A multi-party federated learning device, characterized in that, The multi-party federated learning device includes: At least one processor; A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be 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 according to any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a program that implements a multi-party federated learning method, which 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 6.

10. 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 as described in any one of claims 1 to 6.

Images