A blockchain-based cross-domain federated learning system and method

Abstract

The application discloses a cross-domain federated learning method based on a block chain, which uses a multi-signature technology to solve the effectiveness detection of a training model of each node in a federated learning process, uses two signature nodes 1 and 2 used for signature to respectively complete a learning digital signature and an expected digital signature. The signature node 2 is used for the learning digital signature of the node completing the training model, and the learning digital signature indicates that the node has completed learning. When the node completing the training model outputs a model, the output training model of the node is compared with an expected training model range, if the expected training model range is met, the signature node 2 performs the expected digital signature on the node, and the expected digital signature indicates that the output training model of the node meets the expected training model range; if the expected training model range is not met, the expected digital signature is not performed on the node.

Description

Technical Field

[0001] This invention relates to the field of federated learning technology, and specifically to a blockchain-based cross-domain federated learning system and method. Background Technology

[0002] In the context of today's artificial intelligence era, machine learning model training relies heavily on the input of large amounts of low-level data. However, due to confidentiality and other reasons, the original data from each node cannot be transferred to other nodes to centralize the data for model training. Federated learning, however, effectively addresses this issue by using the idea of ​​transferring training data. However, the internal environment of federated learning cannot be guaranteed to be completely trustworthy. If malicious nodes output false information, it will significantly affect the model training results, and currently, it is difficult to verify the authenticity of the model output from each node. Furthermore, if there is a significant deviation between the trained model and the expected results, it can only be discovered after the federated learning process is complete and the model is output, and it is impossible to determine whether the problem lies with the datasets of each node or with flaws in the model design. In other words, existing technologies suffer from at least the following two problems:

[0003] First, in current mainstream federated learning processes, it's impossible to determine whether malicious nodes exist among the large number of nodes, and the authenticity and security of information transmission cannot be guaranteed during the federated learning process. If a malicious node outputs false information and sends an incorrect training model to the federated learning nodes, it will significantly impact the model's results. Current federated learning methods cannot verify the authenticity of the output information from each node, nor can they determine which node is malicious.

[0004] Second, the effectiveness of the training model cannot be effectively detected during the federated learning process. If there is a large deviation between the training model result and the expected result, it can only be discovered when the federated learning training model result is output. It is impossible to confirm whether the problem is due to the dataset of a certain node or a problem in the model design. If we go back to find the cause of the error, it will consume a lot of time and computing resources, resulting in resource waste and low efficiency, which prolongs the completion time of federated learning. Summary of the Invention

[0005] To address the aforementioned problems, this invention aims to provide a blockchain-based cross-domain federated learning method. It utilizes blockchain technology to solve the security issues of training model transmission between nodes in federated learning, preventing malicious nodes from outputting fake training models that negatively impact the federated learning results. Furthermore, multi-signature technology is used in the blockchain network to determine the validity of the training models output by each node, with different digital signatures applied to different nodes for different determination results. Based on this, iterative training is returned, and nodes that repeatedly output training models that do not meet expectations are identified as nodes with problems in the dataset.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A blockchain-based cross-domain federated learning system is characterized by comprising a blockchain network, a model aggregation function module, a model evaluation function module, a digital signature module, and a smart contract module.

[0008] The blockchain network is used to carry out the entire federated learning task, realize the authenticity verification of the node output model and the transmission of information between nodes without a third party's trust, and ensure the decentralization of this federated learning method.

[0009] The model aggregation function module, configured on each node, is used to aggregate the output model of the previous node with the model of the local dataset on this node to generate a new model;

[0010] The model evaluation function module is configured on the signature node of the second signature. It is used to compare and evaluate the expected result range of the model after each node outputs the model, and to determine the validity of the output model.

[0011] The digital signature module, configured on the signature node, is used to write a signature on the node after verifying the authenticity or validity of the output model of each node.

[0012] The smart contract module, configured on the blockchain network, is used to implement the response strategy after each judgment.

[0013] A blockchain-based cross-domain federated learning method for implementing federated learning in the cross-domain federated learning system includes the following steps:

[0014] S1: A federated learning task is initiated in the blockchain by a node that acts as the initiator of the federated learning task.

[0015] S2: After the training node obtains the specified federated learning task, it uses the local dataset to train the model and writes a digital signature to the training node.

[0016] S3: Perform write digital signature checks on each node in the blockchain network;

[0017] S4: Clean up all signatures of the nodes participating in the federated learning and return to S1 for the next iteration of the federated learning.

[0018] Furthermore, the specific operational steps of step S2 include:

[0019] S21: Starting from any training node, use the training function of this machine learning session to train the model;

[0020] S22: Whenever a node completes training, other nodes in the blockchain network verify the trained model. If the node information is true and valid, it is recorded in the blockchain to generate a new block, and the signing node 1 uses its private key to write "learning digital signature". If the node information is invalid, the model that is not verified is deleted, and the malicious node is traced by checking the blockchain logs and the relevant permissions of the node are deleted.

[0021] S23: Determine the fault tolerance range of the verification results of the trained model. If the verification results of the trained model are within the expected range, use signature node 2 to write the "expected digital signature" again with the private key to complete the multi-signature; if they are not within the expected range, do not sign.

[0022] S24: For each new model generated by the training node, check whether all nodes in the blockchain network have "learned digital signatures". If not, continue to execute steps S22-S23 to train the model on any unsigned node; if so, proceed to S3.

[0023] Furthermore, the specific operational steps of step S3 include:

[0024] S31: Once all nodes have "learned digital signatures", the training node uses the public keys of signing node 1 and signing node 2 to verify whether all nodes have "learned digital signatures" and "expected digital signatures". If so, the model training is complete; otherwise, proceed to S4.

[0025] S32: Use the public keys of signing node 1 and signing node 2 to check which nodes have not "learned digital signatures" and "predicted digital signatures" and record them. Sort the number of occurrences of the nodes in the record in descending order to obtain the frequency sequence. If the frequency of some nodes is in the top 10% of the frequency sequence after multiple trainings, skip these nodes in the next federated learning. If the nodes without signatures are irregular after multiple trainings, re-examine the training model.

[0026] Compared with the prior art, the beneficial effects of this invention are:

[0027] First, the federated learning of this invention is conducted on a blockchain network. The information output by each node (training model) is packaged into blocks, which are jointly verified by a majority of nodes in the network. After verification as "true," the block is submitted to the blockchain, recorded in the blockchain log, and an additional block height is added. If a malicious node outputs a fake training model, since the fake training model does not contain the block information of the models output by the previous few nodes, the block cannot pass the authenticity verification and will not be recognized by the blockchain network, becoming an "orphan block" outside the chain. Furthermore, the blockchain log can be used to view the information of malicious nodes in blocks that have failed verification, enabling effective tracing of malicious nodes and timely identification of malicious nodes, thus significantly increasing the efficiency of federated learning.

[0028] Second, this invention proposes using multi-signature technology to address the validity detection of the trained model at each node during federated learning. Two signature nodes, Node 1 and Node 2, are used to perform the "learned digital signature" and "expected digital signature," respectively. For a node that has completed model training, Node 2 performs the "learned digital signature," indicating that the node has completed learning and that selecting any subsequent node for model training will not result in the use of duplicate datasets. When a node outputs its model, the output model is compared to the expected training model range. If it meets the expected training model range, Node 2 performs the "expected digital signature," indicating that the node's output model conforms to the expected training model range; otherwise, no "expected digital signature" is performed. When a node has a "learned digital signature" but no "predicted digital signature," it indicates that the node has completed model training, but the trained model does not conform to the expected training model, suggesting a higher probability of errors in the node's dataset. This shows that in each round of federated learning, it checks whether the training model output by each node meets expectations, and if it does not meet expectations, it returns to iterative training. After multiple iterations, it can filter out nodes with problems in the dataset. If there are many cases that do not meet expectations, it indicates that there may be defects in the model design itself. Attached Figure Description

[0029] Figure 1 This is a diagram of the overall architecture of the present invention.

[0030] Figure 2 This is a flowchart of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0032] This invention proposes a blockchain-based cross-domain federated learning system, which includes a blockchain network, a model aggregation function module, a model evaluation function module, a digital signature module, and a smart contract module.

[0033] The blockchain network is used to carry the entire federated learning task, realize the authenticity verification of the node output model and the transmission of information between nodes without a third party's trust, ensure the decentralization of the federated learning method and enhance fault tolerance.

[0034] The model aggregation function module, configured on each node, is used to aggregate the output model of the previous node with the model of the local dataset on this node to generate a new model;

[0035] The model evaluation function module is configured on the signature node of the second signature. It is used to compare and evaluate the expected result range of the model after each node outputs the model, and to determine the validity of the output model.

[0036] The digital signature module, configured on the signature node, is used to write a signature on the node after verifying the authenticity or validity of the output model of each node.

[0037] The smart contract module, configured on the blockchain network, is used to implement the response strategy after each judgment. For example, if the authenticity judgment is true, it triggers the operation of writing a signature on the node.

[0038] like Figure 1-2 As shown, this invention also proposes a learning method for a blockchain-based cross-domain federated learning system. This method places the federated learning task within a blockchain network and uses multi-signature to verify the authenticity and provide feedback on the validity of the output model. For different verification and feedback results, a smart contract module running on the blockchain network implements corresponding response strategies. The main steps include:

[0039] S1: A federated learning task is initiated in the blockchain by a node that acts as the initiator of the federated learning task.

[0040] S2: After the training node obtains the specified federated learning task, it uses the local dataset to train the model, specifically including:

[0041] S21: Starting from any training node, use the training function of this machine learning session to train the model;

[0042] S22: Whenever a node completes training, other nodes in the blockchain network verify the trained model. If the node information is true and valid, it is recorded in the blockchain to generate a new block, and the signing node 1 uses its private key to write "learning digital signature". If the node information is invalid, the model that is not verified is deleted, and the malicious node is traced by checking the blockchain logs and the relevant permissions of the node are deleted.

[0043] Ifnew_block.[Pre_Hash]=previous_block.[Hash]Then

[0044] {signaStudySignature; / }

[0045] Else

[0046] {deletethismodelandtracetothesource; / }

[0047] This step incorporates the verification of the output model's authenticity into the federated learning process. The node's output model undergoes joint verification with other nodes in the network. If verification passes, a "learned digital signature" is used as the first layer of the multi-signature algorithm and written into the node. If verification fails, the output model is deleted, and malicious nodes are traced in the blockchain log, having their related permissions revoked. This addresses the issue of not being able to guarantee the authenticity of output models when using datasets from multiple nodes for machine learning in environments with incomplete trust.

[0048] S23: Determine the fault tolerance range of the verification results of the trained model. If the verification results of the trained model are within the expected range, use signature node 2 to write the "expected digital signature" again with the private key to complete the multi-signature; if they are not within the expected range, do not sign.

[0049] If model = ExpectedRangeThen

[0050] {signaExpectedSignature; / }

[0051] Else

[0052] {Gotothenextstep; / }

[0053] This step incorporates feasibility feedback for the output model into the federated learning process. The node's output model is validated through signature node 2, comparing it to the expected range. If validation passes, a "predicted digital signature" is used as a marker and written into the node as the second layer of the multi-signature system. If validation fails, the process proceeds directly to the next step without writing a "predicted digital signature." This solves the problem of not being able to promptly confirm the validity of the federated learning output model and allows for tracing the source of errors at nodes during the federated learning process.

[0054] S24: Each time a training node generates a new model, it checks whether all nodes in the blockchain network have "learned digital signatures". If not, it continues to execute steps S22-S23, iteratively training the model in the blockchain network until it reaches any unsigned node for model training; if so, it proceeds to S3.

[0055] S3: Performs digital signature checks on each node in the blockchain network; specifically including:

[0056] S31: Once all nodes have "learned digital signatures", the training node uses the public keys of signing node 1 and signing node 2 to verify whether all nodes have "learned digital signatures" and "expected digital signatures". If so, the model training is complete; otherwise, proceed to S4.

[0057] This step incorporates error source tracing into each round of the federated learning process, performing multi-signature verification on each node in the blockchain network. Successful verification indicates that the output model of this federated learning task meets expectations and is effective; failure to verify proceeds to the next step, tracing the source of errors in the nodes and analyzing the problems encountered in this federated learning task to confirm whether the issue stems from excessive errors in the node dataset or model design flaws. This solves the problem of not being able to promptly correct the output model during federated learning, avoiding the waste of significant resources on error source tracing when the trained model does not meet expectations.

[0058] S32: Use the public keys of signing node 1 and signing node 2 to check which nodes have not "learned digital signatures" and "predicted digital signatures" and record them. Sort the nodes in the record in descending order of their occurrence frequency to obtain a frequency sequence. If the frequency of some nodes is in the top 10% of the frequency sequence after multiple training sessions, it is determined that these nodes have large dataset errors and are skipped in the next federated learning. If the nodes without signatures are irregular after multiple training sessions, it is determined that there is a problem with the training model design and the training model is re-examined.

[0059] S4: Clean up all signatures of the nodes participating in the federated learning and return to S1 for the next iteration of the federated learning.

[0060] Example

[0061] To verify the effectiveness of the method proposed in this invention, the following experiment was conducted.

[0062] 1. Network setup

[0063] A blockchain network carrying federated learning tasks is built using the Hyperledger Fabric consortium blockchain network framework; a horizontal federated learning algorithm under the FATE framework is constructed for model training; each node in the blockchain network uses the Federated-MNIST dataset from the CV dataset as its local dataset; the Elliptic Curve Digital Signature Algorithm (ECSDA) is used to implement digital signatures for signing node 1 and signing node 2; and smart contracts in the blockchain network are written to implement various applications, including automatically verifying whether the trained model meets the expected training model range.

[0064] 2. Experimental Results

[0065] Launch the Hyperledger Fabric consortium blockchain network, configure all nodes and the initial environment, and import the pre-set dataset into the local databases of each node. Select any node to begin publishing the horizontal federated learning task, and then randomly select another node to train the model. After the node completes model training, it outputs its training model and packages it into a block. Other nodes in the blockchain network will verify its authenticity. If it is genuine, the block is recorded in the blockchain log, and signing node 1 writes "learning digital signature" to that node. After the first signature is completed, automatically compare whether the output training model meets the expected training. If the model meets the expected training model criteria, signing node 2 will write the "expected digital signature" on that node. After each training model is output, signing node 1 will iterate through the nodes in the blockchain network to verify if all nodes have completed model training. If not, the model will be passed to the next randomly selected node for the next training iteration. If so, the public keys of signing nodes 1 and 2 will be used to perform multi-signature verification on all nodes in the blockchain network. Nodes whose output training models do not meet the expected training model will be identified and recorded. All digital signatures on all participating nodes will be cleared before proceeding to the next federated learning task. After multiple training iterations, these nodes will be analyzed to determine whether the problem lies in the dataset or the model design, and solutions will be implemented to address the identified issues.

[0066] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based cross-domain federated learning method, characterized in that, Includes the following steps: S1: A federated learning task is initiated in the blockchain by a node that acts as the initiator of the federated learning task. S2: After the training node obtains the specified federated learning task, it uses the local dataset to train the model and writes a digital signature to the training node. S3: Perform write digital signature checks on each node in the blockchain network; S4: Clean up all signatures of the nodes participating in the federated learning and return to S1 for the next iteration of the federated learning; The specific steps of step S2 include: S21: Starting from any training node, use the training function of this machine learning session to train the model; S22: Whenever a node completes training, other nodes in the blockchain network verify the trained model. If the node information is true and valid, it is recorded in the blockchain to generate a new block, and the signing node 1 uses its private key to write "learning digital signature". If the node information is invalid, the model that is not verified is deleted, and the malicious node is traced by checking the blockchain logs and the relevant permissions of the node are deleted. S23: Determine the fault tolerance range of the verification results of the trained model. If the verification results of the trained model are within the expected range, use signature node 2 to write the "expected digital signature" again using the private key to complete the multi-signature; if they are not within the expected range, do not sign. S24: For each new model generated by the training node, check whether all nodes in the blockchain network have "learned digital signatures". If not, continue to execute steps S22-S23 to train the model on any unsigned node; if so, proceed to S3. The specific steps of step S3 include: S31: Once all nodes have "learned digital signature", the training node uses the public keys of signing node 1 and signing node 2 to verify whether all nodes have "learned digital signature" and "expected digital signature". If so, the model training is complete; otherwise, proceed to S4. S32: Use the public keys of signing node 1 and signing node 2 to check which nodes have not "learned digital signatures" and "predicted digital signatures" and record them. Sort the nodes in the record in descending order to obtain the frequency sequence. If the frequency of some nodes is in the top 10% of the frequency sequence after multiple trainings, skip these nodes in the next federated learning. If the nodes without signatures are irregular after multiple trainings, re-examine the training model.

2. A blockchain-based cross-domain federated learning system, characterized in that, The method for implementing a blockchain-based cross-domain federated learning method as described in claim 1 includes: a blockchain network, a model aggregation function module, a model evaluation function module, a digital signature module 1, a digital signature module 2, and a smart contract module. The blockchain network is used to carry out the entire federated learning task, realize the authenticity verification of the node output model and the transmission of information between nodes without a third party's trust, and ensure the decentralization of this federated learning method. The model aggregation function module, configured on each node, is used to aggregate the output model of the previous node with the model of the local dataset on this node to generate a new model; The model evaluation function module is configured on the signature node of the second signature. It is used to compare and evaluate the expected result range of the model after each node outputs the model, and to determine the validity of the output model. Digital signature module 1, configured on signature node 1, is used to write a signature on the node after verifying the authenticity of the output model of each node. Digital signature module 2, configured on signature node 2, is used to write a signature on the node after validating the output model of each node; The smart contract module, configured on the blockchain network, is used to implement the response strategy after each judgment.

Images