Full-stage Trust Guarantee Method for Federated Learning Training of AIGC Model

Abstract

The present invention discloses a full-stage trustworthy guarantee method for the federated learning training of AIGC models. Based on blockchain technology and the Nostr protocol, the present invention designs a multi-party data verification mechanism based on the Nostr protocol to ensure the trustworthiness of the data preparation stage, designs a verification strategy combining on-chain and off-chain to ensure the trustworthiness of adapter updates, designs an on-chain election, off-chain model merging, and an on-chain verification strategy to ensure the trustworthiness of model merging, aiming to ensure the trustworthiness of the entire process of federated learning training of AIGC models represented by large language models.

Description

Technical Field

[0001] The present invention belongs to the technical field of machine learning, and particularly relates to a method for ensuring the credibility of all stages of federated learning training of an AIGC model. Background Art

[0002] The increasing popularity and acceptance of ChatGPT have intensified the interest in large language models (LLMs), which are the core driving force of generative artificial intelligence. The success or failure of machine learning tasks often depends on integrating data from multiple parties, but the dispersed ownership and privacy issues of data make it extremely difficult to obtain high-quality datasets. Against this backdrop, federated learning (FL) emerged as the key to solving this problem. FL is fundamentally different from traditional centralized training models. It constructs a collaborative learning environment through iterative processing of decentralized data, cleverly addressing the issues of data privacy and ownership in machine learning. However, introducing FL into artificial intelligence-generated content (AIGC) models, i.e., generating FL-driven AIGC, gives rise to a series of trust problems.

[0003] Before the rise of large language models and AIGC models, the research focus was mainly on the credibility of FL small models. Most current patents on using blockchain to ensure the credibility of AI model training rely on the immutable record feature of blockchain. For example, key data such as parameters in the model training process are recorded on the blockchain. Such patents include "A Gradient Selection Method for UAV Federated Learning Based on Blockchain, Publication No. CN117596592A". In this method, each UAV terminal uploads the model gradient obtained from local training to the base station edge node for identity verification, then performs gradient anomaly detection, and records the legitimate gradients on the blockchain. Although this method considers the credibility of gradients, due to the limited data volume of small models, it is not applicable to the training requirements of large models.

[0004] In the research field of combining blockchain and AIGC, for example, the patent "A Multi-modal AI Model Training Method Based on a Distributed Network Architecture, CN 117196013 A" provides a decentralized AI training method. Blockchain not only serves as a trustworthy tool for recording user information but also introduces AIGC. When users utilize the AI model, AIGC can generate a visualized interpretation of the model's decision-making to facilitate the visualization of the model's behavior. Although this design realizes the distributed training of the AI model and combines the applications of AIGC and blockchain, it only uses AIGC and blockchain as auxiliary tools for verification and recording and does not fully address the challenges faced by large models in federated learning. Summary of the Invention

[0005] In view of the phased trust issues involved in the existing federated learning of AIGC models and combined with the performance issues of blockchain, the present invention first proposes the trust objectives for the three stages involved in the training of AIGC models, and gives specific solutions to the existing trust issues based on blockchain technology and the Nostr protocol.

[0006] The present invention includes the following steps:

[0007] S1: Data preparation stage

[0008] S1.1: Deposit the training data set formed after the edge node reads and processes from the sensor on the relay node;

[0009] S1.2: The relay node broadcasts a data set test request to its trusted nodes.

[0010] S1.3: The edge nodes trusted by the relay node obtain the data set to be tested on the relay node.

[0011] S1.4: The data detection node in the edge node performs local detection on the data set. If the detection passes, the edge node generates a data detection report for the data set and includes the edge node signature.

[0012] S1.5: The edge node sends the signed data detection report to the smart contract.

[0013] S1.6: The smart contract is automatically executed to deposit the data detection report on the chain.

[0014] S2: Adapter update stage

[0015] S2.1: The edge node uses the data set for local training to generate gradient updates, that is, adapter file updates.

[0016] S2.2: The edge node sends the adapter update file with the private key signature to the smart contract.

[0017] S2.3: The smart contract reads on the blockchain ledger and reads the data detection report of the edge node.

[0018] S2.4: Verify whether the edge node has sufficient data detection reports. If there are enough qualified data detection reports, then proceed to step S2.5. Otherwise, do not accept the gradient update from the edge node.

[0019] S2.5: Deposit the hash of the adapter update file on the blockchain.

[0020] S2.6: The edge node broadcasts an adapter file detection request.

[0021] S2.7: The adapter file detection node obtains the hash data of the adapter file to be detected on the chain.

[0022] S2.8: The adapter file detection node tests the adapter file update, that is, it conducts detection on the local global model copy and the data test set to check whether the adapter update is reasonable and non-malicious.

[0023] S2.9: The edge node sends the adapter file update detection report with an endorsement signature to the smart contract.

[0024] S2.10: The detection report of the adapter file is stored on the chain.

[0025] S3: Model aggregation stage

[0026] S3.1: The smart contract automatically detects the parameter aggregation conditions and selects the parameter aggregation node based on the integral level to execute the parameter aggregation task.

[0027] S3.2: The smart contract broadcasts the model merging node election result to the parameter aggregation nodes in this round.

[0028] S3.3: Obtain the adapter files in this round and the detection reports of each adapter file.

[0029] S3.4: Merge the adapter file updates of the nodes that pass the detection report.

[0030] S3.5: Send the hash of the finally merged adapter file in this round and the model score of this round to the smart contract.

[0031] S3.6: If the smart contract automatically detects that the increase or decrease range of the model score is within the limited range, then execute step S3.7; otherwise, the model of this round needs to be re-merged.

[0032] S3.7: The hash of the finally adapter file in this round is stored on the chain.

[0033] In a preferred embodiment of the present invention, the relay node is a relay node in the Nostr protocol, which is responsible for storing training data and is verified by other nodes.

[0034] In a preferred embodiment of the present invention, each relay node maintains a list of trusted edge nodes, and only the trusted edge nodes can verify the data.

[0035] In a preferred embodiment of the present invention, the local detection includes whether there is abnormal data or malicious data.

[0036] In a preferred embodiment of the present invention, during the fine-tuning process of the AIGC model, the adapter file includes the gradient update situation generated after a certain edge node training node data.

[0037] In a preferred embodiment of the present invention, the private key signature is that after the adapter file detection node detects, the signature of the detector is appended to the file to prove the validity of this detection report.

[0038] In a preferred embodiment of the present invention, the sufficient number of qualified data detection reports means that the number of data detection reports is greater than half of the total number of nodes.

[0039] In the trusted data preparation stage of the present invention: This stage gives priority to the reliability of data in the federated learning environment, ensuring its fairness and representativeness. That is, reliable data is obtained from trusted edge nodes to prevent potential exploitation of the AIGC model by malicious actors. The trusted data preparation stage mainly consists of a data collection and processing layer and a data verification layer.

[0040] In the trusted adapter update stage of the present invention: This stage ensures that the adapter updates are non-malicious and come from trusted edge nodes. They will not have a malicious impact on the final parameter results. The storage of the adapter update file involves ensuring traceability, immutability, and transparency, allowing all participants to verify the update, thereby maintaining the integrity and fairness of the model update process.

[0041] In the trusted parameter aggregation stage of the present invention: It involves the key trusted process in aggregating parameters. At this stage, it is necessary to ensure that the task of aggregating parameters is entrusted to one or more trusted nodes, thereby reducing the risk of malicious activities in the merging process from the very beginning. Subsequently, the aggregated results should be verified to ensure the rationality of the aggregated results. At the same time, the secure storage of each model update cycle is also crucial for maintaining the traceability of AIGC supported by FL.

[0042] Compared with the prior art, the beneficial effects of the present invention are:

[0043] The present invention designs a full-stage trusted guarantee scheme for the federated learning training of the AIGC model. Based on blockchain technology and the Nostr protocol, it designs a multi-party data verification mechanism based on the Nostr protocol to guarantee the trustworthiness of the data preparation stage, designs a verification strategy combining on-chain and off-chain to ensure the trustworthiness of adapter updates, designs on-chain election, off-chain model merging, and on-chain verification strategy to ensure the trustworthiness of model merging, aiming to ensure the full process trustworthiness of the federated learning training of the AIGC model represented by large language models. Brief Description of the Drawings

[0044] Figure 1 This is the flowchart of the method of the present invention. Detailed Embodiments

[0045] To make the objectives, technical solutions and advantages of the present invention clearer, the following further describes in detail the specific embodiments of the present invention with reference to the accompanying drawings. Examples of these preferred embodiments are illustrated in the accompanying drawings. The embodiments of the present invention shown in the drawings and described according to the drawings are merely exemplary, and the present invention is not limited to these embodiments.

[0046] Here, it should also be noted that in order to avoid obscuring the present invention with unnecessary details, only the structures and / or processing steps closely related to the solution of the present invention are shown in the drawings, while other details less related to the present invention are omitted.

[0047] The present invention will be further described below in combination with the accompanying drawings and specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. The operating methods without specific conditions noted in the following embodiments are generally in accordance with conventional conditions or in accordance with the conditions recommended by the manufacturer. The present invention will be further described below in combination with the accompanying drawings and specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. The operating methods without specific conditions noted in the following embodiments are generally in accordance with conventional conditions or in accordance with the conditions recommended by the manufacturer.

[0048] The following takes Hyperledger Fabric as the blockchain technology foundation and the large language model LLaMA2-7B as an example, in combination with Figure 1 , there are 10 nodes in the federated learning environment, numbered N1 to N10 respectively, to specifically illustrate the technical solution of the present application:

[0049] S1. Data Preparation Phase

[0050] To ensure data verification while maintaining data privacy, the present application proposes a multi-party cross-verification data mechanism based on Nostr protocol access control. Using the Nostr protocol, edge nodes can act as relay nodes and client nodes. As relay nodes, they mainly store the data sets trained locally at the edge nodes. As client nodes, they can either be the main body of verification, authorizing other edge nodes to verify their data, or act as data verifiers authorized by other nodes. The data quality report (DQR) generated by the data verifier will be subjected to ring signature verification before being uploaded to the blockchain by the adapter to ensure that the nodes have sufficient endorsements and are eligible for on-chain submission.

[0051] S1.1: Ten edge nodes read data from sensors or other IoT sensors, form a training data set after local data processing and cleaning, and the data set is stored on the relay node.

[0052] S1.2: Each relay node maintains a list of trusted nodes it trusts. After the data set is stored, the relay node broadcasts a data set test request to all the nodes it trusts.

[0053] S1.3: Nodes that can complete the test task respond and obtain the data set to be tested on the relay node. These nodes are also called data test nodes (DT).

[0054] S1.4: The data detection nodes in the edge nodes perform local detection on the data set. The detection includes whether there is abnormal data or malicious data in the data. If the detection passes, the edge node generates a data detection report for the data set and includes the edge node signature. If the data detection of DT1 for N1 - N9 passes, it generates a data detection report for them. If the detection report for N10 does not pass, no data detection report can be generated.

[0055] S1.5: DT1 sends the data set detection report with its own signature to the smart contract.

[0056] S1.6: The smart contract is automatically executed to store the data set detection report on the chain.

[0057] S2: adapter update phase

[0058] To ensure the integrity and consistency of the adapter update, this application proposes a verification strategy that combines on-chain and off-chain methods, aiming to confirm whether the adapter update comes from a trusted node and whether it complies with the integrity and consistency standards. Considering the storage limitations and performance bottlenecks of the blockchain, this application abandons the traditional method of directly storing the adapter update on the blockchain. Instead, this application chooses to upload the hash value of the adapter file to the blockchain, which can better meet the performance requirements of the blockchain. After receiving the adapter update file, the adapter tester performs a local hash calculation. It compares this hash value with the hash value of the node adapter update in the current round on the blockchain. If they match, it is considered that the adapter has passed the integrity check.

[0059] S2.1: The edge nodes use the data set locally for training to generate gradient updates, that is, adapter file updates. Adapter1 - Adapter10 respectively correspond to the adapter update files generated by 10 nodes.

[0060] S2.2: After the training of N1 to N10 is completed, the adapter update file with the private key signature is sent to the smart contract.

[0061] S2.3: The smart contract reads the data detection reports of nodes N1 to N10 on the blockchain ledger.

[0062] S2.4: Verification is required before the adapter evidence of the node is uploaded to the chain. Verify whether nodes N1 to N10 have sufficient data test reports (more than 5 copies). That is, count the number of reports owned by nodes N1 to N10 respectively. If N1 contains 8 data detection reports, the adapter file can be used for evidence storage; if N2 contains 4 data detection reports, it proves that the data provided by this node does not meet the requirements and the adapter file cannot be used for evidence storage.

[0063] The sufficient number of qualified data detection reports required in this application is more than half of the total number of nodes, that is, more than 5 data set detection reports, which is a qualified data set.

[0064] S2.5: Nodes with data meeting the requirements store the hash of the adapter update file on the blockchain.

[0065] S2.6: After the update evidence storage of the adapter files of N1 to N10 is completed, the edge node broadcasts an adapter file detection request.

[0066] S2.7: The adapter file detection node responds to the request to obtain the hash data of the adapter file to be detected on the chain.

[0067] S2.8: The adapter file detection node tests the adapter file update, that is, performs detection on the local global model copy and the data test set to check whether the adapter update is reasonable and non-malicious.

[0068] S2.9: After the detection, the detection node sends an adapter file update detection report with an endorsement signature to the smart contract. The detection report includes the detection node signature and the accuracy score of the adapter test on the global model copy.

[0069] S2.10: The detection report of the adapter file is stored on the chain.

[0070] S3: Model aggregation phase

[0071] Considering the performance bottleneck of the blockchain, this application adopts a "sandwich" strategy. This method requires competitively allocating computationally intensive tasks on the chain, executing them locally off-chain, and finally verifying the results on the blockchain. Specifically, this strategy assigns roles and tasks based on the metrics recorded on the blockchain. The edge server executes computationally intensive tasks locally and uses smart contracts on the blockchain to verify the execution results. After parameter aggregation is completed, the adapter aggregator uploads the updated adapter hash and the model score of the current round to the blockchain for storage. If the smart contract verification shows that the aggregated score of the current epoch has not decreased, or even if it has decreased, it remains within a reasonable threshold range, then the aggregated result can be considered trustworthy.

[0072] S3.1: The smart contract automatically detects the parameter aggregation condition, that is, all 10 nodes in this round have completed this round of training, and the updated adapters that meet the requirements are uploaded to the blockchain for storage. This condition flag can execute model merging.

[0073] Then, based on the scores of nodes N1 to N10, the parameter aggregation node is selected to execute the parameter aggregation task. In this example, assume that the score of N2 is the highest, and node N2 is selected as the parameter aggregation node.

[0074] S3.2: The smart contract broadcasts the election result of N2 as the parameter aggregation node to all nodes.

[0075] S3.3: Obtain the adapter files of this round and the detection reports of each adapter file.

[0076] S3.4: Node N2 merges the updated adapter files of the nodes that passed the detection report.

[0077] S3.5: Node N2 sends the hash of the finally merged adapter file of this round and the model score of this round to the smart contract.

[0078] S3.6: If the smart contract automatically detects that the model score has increased or decreased within the limited range, then execute step 3.7; otherwise, the model of this round needs to be merged again.

[0079] S3.7: The hash of the finally adapter file of this round is stored on the chain.

[0080] In addition, it should be noted that in this specification, "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0081] It should be understood that although this specification is described in terms of embodiments, not every embodiment contains only one independent technical solution. This narrative manner of the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments understandable to those skilled in the art.

Claims

1. A full-stage trustworthy guarantee method for federated learning training of AIGC models, characterized in that The method includes the following steps: S1: Data preparation stage S1.1: Archive the training data set formed after the edge nodes read and process data from sensors on the relay nodes; S1.2: The relay nodes broadcast data set test requests to their trusted nodes; S1.3: The edge nodes trusted by the relay nodes obtain the data set to be tested on the relay nodes; S1.4: The data detection nodes in the edge nodes perform local detection on the data set. If the detection passes, the edge nodes generate a data detection report for the data set and include the edge node signature; S1.5: The edge nodes send the signed data detection report to the smart contract; S1.6: The smart contract is automatically executed to archive the data detection report on the chain; S2: Adapter update stage S2.1: The edge nodes use the data set locally for training to generate gradient updates, i.e., update the adapter files; S2.2: The edge nodes send the adapter update files with private key signatures to the smart contract; S2.3: The smart contract reads from the blockchain ledger and retrieves the data detection report of the edge node; S2.4: Verify whether the edge node has sufficient data detection reports; if there are enough qualified data detection reports, proceed to step S2.5; otherwise, do not accept the gradient updates from the edge node; S2.5: Archive the hash of the adapter update file on the blockchain; S2.6: The edge nodes broadcast adapter file detection requests; S2.7: The adapter file detection nodes obtain the adapter file hash data to be detected on the chain; S2.8: The adapter file detection nodes test the adapter file updates, i.e., perform detection on the local global model copy and the data test set to check whether the adapter updates are reasonable and non-malicious; S2.9: The edge nodes send the adapter file update detection reports with endorsement signatures to the smart contract; S2.10: Archive the detection reports of the adapter files on the chain; S3: Model aggregation stage S3.1: The smart contract automatically detects the parameter aggregation conditions and selects parameter aggregation nodes based on the integral ranking to perform parameter aggregation tasks; S3.2: The smart contract broadcasts the model merging node election results to the parameter aggregation nodes in this round; S3.3: Obtain the adapter files in this round and the detection reports of each adapter file; S3.4: Merge the adapter file updates of the nodes with passed detection reports; S3.5: Send the hash of the finally merged adapter file in this round and the model scores of this round to the smart contract; S3.6: If the smart contract automatically detects that the increase or decrease range of the model scores is within the limit, execute step S3.7; otherwise, the model of this round needs to be merged again; S3.7: Archive the hash of the finally adapter file in this round on the chain.

2. The full-stage trusted guarantee method for federated learning training of the AIGC model according to claim 1, characterized in that: The relay node is a relay node in the Nostr protocol, responsible for storing training data and being verified by other nodes.

3. The full-stage trust guarantee method for federated learning training of the AIGC model according to claim 2, characterized in that: Each relay node maintains a list of trusted edge nodes, and only the edge nodes it trusts can verify the data.

4. The full-stage trusted guarantee method for federated learning training of the AIGC model according to claim 1, wherein: The local detection includes whether there is abnormal data or malicious data in the data.

5. The full-stage trusted guarantee method for federated learning training of the AIGC model according to claim 4, wherein: During the fine-tuning process of the AIGC model, the adapter file contains the gradient update situation generated after a certain edge node trains the node data.

6. The full-stage trusted guarantee method for federated learning training of the AIGC model according to claim 4, characterized in that: The private key signature is that after the adapter file detection node performs detection, it attaches the signature of the detector to the file to prove the validity of this detection report.

7. The method for ensuring the trustworthiness of all stages of the federated learning training of the AIGC model according to claim 4, wherein: The sufficient number of qualified data detection reports means that the number of data detection reports is greater than half of the total number of nodes.

Images