A federated learning method based on DAG blockchain

Abstract

The present invention relates to a federated learning method based on a distributed aggregation (DAG) blockchain, and belongs to the field of communication technology. The method includes the following steps: an external agent acts as a task initiator, an edge server undertakes model aggregation and blockchain maintenance, and a smart device performs model training tasks; the external agent initializes the global model and genesis block, and determines the birth and death of training tasks; the edge server selects tips from the distributed aggregation (DAG) blockchain; the smart device uses a local data set for local training, and after completing a round of local training, sends a status query message to the edge server to confirm whether to proceed to the next round of local training; after completing local training, the smart device uploads the updated model to the edge server for aggregation, and uploads the aggregated model to the distributed aggregation (DAG) blockchain as a transaction; the edge node is responsible for model aggregation and jointly maintains a DAG blockchain to ensure the reliability of information transmission and the anti-attack capability of the overall system.

Description

Technical Field

[0001] The present invention belongs to the field of communication technology and relates to a federated learning method based on DAG blockchain. Background Art

[0002] Natural language processing, virtual / augmented reality, and computer vision, among others. In traditional cloud computing, communication between users and cloud servers often suffers from high latency, and the influx of tasks can cause congestion and blockage on cloud servers. Given today's advanced hardware technology, various near-end devices such as roadside units (ROUs), distributed base stations, and edge gateways can provide storage, computing, and networking resources. Consequently, the concept of edge computing networks has been proposed. Its main idea is to offload computing and storage tasks to edge nodes, thereby alleviating the burden on cloud servers and enabling rapid response to user needs.

[0003] To complete a complex computational task, a single edge node often lacks sufficient data volume or computing resources. Data security concerns associated with multi-party collaboration can dampen participant enthusiasm. Federated learning, which enables collaborative model learning without sharing raw data, is increasingly attracting the attention of tech giants and privacy-conscious industries. In a federated learning framework, user device datasets do not need to be transmitted to edge nodes. Instead, users perform computations locally and transfer model parameters or gradients to edge nodes for aggregation. Since raw data is not shared between users, federated learning protects user privacy and decouples the machine learning process—data collection, training, and model storage—between edge nodes and users.

[0004] While federated learning (FL) can address data privacy concerns among data owners, its attack resistance faces significant challenges due to the frequent interactions between edge nodes and users and the single point of failure introduced by centralized aggregation. The tamper-proof nature of distributed storage and malicious node identification within blockchain technology can effectively address the issues of reliable data transmission and resistance to malicious attacks. Federated learning, as a distributed learning architecture, can provide a strong foundation for the integration of blockchain technologies. The Directed Acyclic Graph (DAG) structure, a rising star in the blockchain field, can overcome the throughput limitations of traditional chain structures and is more suitable for dense networks. The DAG blockchain's inherent asynchronous on-chain nature can significantly reduce network congestion and circumvent the fork problem inherent in traditional chain structures.

[0005] In traditional federated learning, synchronous aggregation is used. High-computing-power nodes need to wait for low-computing-power nodes to complete training, and computing resources during the waiting time are wasted. The present invention provides a semi-asynchronous aggregation method. High-computing-power nodes on the device side can perform multiple local trainings during the waiting time, making full use of effective resources. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide a federated learning method based on the DAG blockchain. This method can solve the accuracy and data security issues of federated learning models caused by the non-sharing of private data between users.

[0007] In order to solve the above technical problems, the implementation process of the present invention is as follows:

[0008] In the first step, this invention divides the network into two layers: edge servers and smart devices, based on the different responsibilities and positions of network members, to perform collaborative learning modeling. Learning tasks are initiated by external agents, and the edge servers jointly maintain a DAG blockchain. The execution process of this solution is as follows:

[0009] S1: The external agent acts as the task initiator, the edge server is responsible for model aggregation and blockchain maintenance, and the smart device performs the model training task. The external agent initializes the global model and genesis block, and determines the birth and death of the training task;

[0010] S2: The edge server selects tips (i.e., unapproved transactions) from the DAG blockchain, aggregates the model parameters within the transactions to form a base model, and sends it to the smart devices within its coverage area;

[0011] S3: The smart device performs local training using the local dataset. After completing a round of local training, it sends a status query message to the edge server to confirm whether to proceed to the next round of local training.

[0012] S4: After the smart device completes local training, it uploads the updated model to the edge server for aggregation, and uploads the aggregated model to the DAG blockchain as a transaction;

[0013] S5: Update the edge server reputation value based on the received smart device information and the aggregation model, package it into the transaction and upload it to the DAG blockchain;

[0014] S6: The edge server uploads the transaction to the DAG blockchain. The tips pulled by the edge server are considered to be approved by the new transaction. When the cumulative weight of the tips reaches a certain threshold, it is considered confirmed.

[0015] S7: The external agent selects tips from the DAG blockchain at a fixed period and verifies whether the model has reached the expected accuracy. If the target is met, the model training task is stopped.

[0016] Second, in step S1, the external agent controls the creation and extinction of FL training tasks while maintaining a smart contract to run the DAG blockchain. When initiating a task, the external agent generates a genesis block containing the initial model parameters and a test dataset. Furthermore, as the task initiator, the external agent can monitor the DAG blockchain's operation at any time and decide whether to terminate the FL training task.

[0017] The third step, in step S2, is to provide a tips selection method. Each transaction contains its own weight and the reputation value of the node that uploaded the transaction. By calculating the weight ratio of each tip in all currently observable tips, the probability of each tip being selected can be obtained. Based on this, the edge server can select multiple tips and aggregate the model parameters to obtain a basic model for local training of smart devices within its coverage area. The probability P of Tip y being approved by x (y→x) xy It can be expressed as:

[0018]

[0019] Where κ is a parameter starting at 1, CW is the cumulative tip weight, and R is the reputation of the edge node. In a DAG blockchain, the cumulative weight of each transaction is equal to its own weight and the number of transactions that directly and indirectly validate it. When the cumulative weight reaches a threshold, the transaction is considered confirmed on the DAG blockchain.

[0020] The fourth step, in step S3, provides a semi-asynchronous local model update method. After completing a round of local training, the smart device n sends a message with its current state to the edge server. Query message. Status response message a n Will guide the smart device n to perform the corresponding operation. n =1, the smart device n enters the next round of local training. n = 0, indicating that the remaining waiting time of smart device n is insufficient to complete the next local training. Otherwise, the overall waiting time d wait Therefore, the smart device transmits the updated local model to the edge node for aggregation. This can minimize the overall waiting time and improve the training efficiency of federated learning. n Indicates the local training round count, represents the computational latency of local training, represents the communication delay between smart device n and edge node, t n Indicates the timestamp when the query message was sent.

[0021] In step S4, the edge server updates the model uploaded by the smart device and uses the federated average aggregation algorithm to obtain the aggregate model. Assume that there are M edge nodes and there are N edge nodes under the coverage of edge node m. m The e-th aggregation model of edge nodes m smart devices can be calculated as:

[0022]

[0023] Where ξ represents the global update step size, D n Indicates the size of the local data set of smart device n,

[0024] In step S5, a reputation-based update method is provided. Based on the historical reputation value, all smart device information obtained during the model aggregation phase (including the number of local iterations and the size of the device's data set), the cosine similarity between the aggregated model and the base model, and the accuracy of the aggregated model, the edge server reputation value R is calculated using the entropy weight method. R is a real number ranging from 0 to 100. Represents the standardized value of the i-th indicator of edge node m, and we can get The proportion is:

[0025]

[0026] Where i = 1 represents the historical reputation value of edge node m, i = 2 represents the total number of local training rounds for smart devices under edge node m, i = 3 represents the total size of local datasets for smart devices under edge node m, i = 4 represents the cosine similarity between the aggregate model of edge node m and the base model, and i = 5 represents the accuracy of the aggregate model of edge node m. Normalization uses positive indicators, meaning that higher values are better. The calculation formula is:

[0027]

[0028] Since edge nodes in the DAG blockchain are actively training models, the difference between models can be used to represent the quality of the models. The cosine similarity is used to represent the difference between models, which can be expressed as:

[0029]

[0030] in, Represents the base model in the e-th aggregation of edge node m.

[0031] Therefore, the entropy weight of indicator i is:

[0032]

[0033] in, The larger the entropy weight of an indicator, the greater the contribution of the indicator to the reputation value of edge node m.

[0034] Therefore, the reputation value of edge node m (full score 100) is:

[0035]

[0036] In step S6, the edge server packages the aggregated model and reputation score into a single transaction and uploads it to the DAG blockchain. There are three types of transactions in the DAG blockchain: ① Confirmed transactions whose cumulative weight has reached a threshold; ② Unconfirmed transactions with at least one approved transaction; and ③ Newly arrived transactions, also known as tips. The edge server links the newly generated transaction to the tips retrieved when acquiring the base model, indicating that the new transaction has approved these tips. Transactions are connected unidirectionally through approval relationships, forming a DAG structure.

[0037] In step S7, after initializing the genesis block and model parameters, the external agent selects tips and verifies the model accuracy at regular intervals using a similar tip selection scheme as in step 3. When the model accuracy reaches the target, the external agent broadcasts a termination signal to the edge server, completing the FL training task.

[0038] In order to achieve the above object, the present invention provides the following technical solutions:

[0039] The beneficial effects of this invention are as follows: In this invention, edge nodes are responsible for model aggregation and jointly maintain a DAG blockchain to ensure information transmission reliability and the overall system's anti-attack capabilities. Smart devices use local datasets to update models. In addition, this solution's tip selection algorithm is based on reputation, which can complete tip selection faster while ensuring reliability.

[0040] Other advantages, objects, and features of the present invention will be described in part in the following description and, in part, will be apparent to those skilled in the art upon examination of the following description or may be learned from practice of the present invention. The objects and other advantages of the present invention may be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be described in detail below with reference to the accompanying drawings, in which:

[0042] Figure 1 A schematic diagram of a possible system structure involved in an embodiment of the present invention;

[0043] Figure 2Schematic diagram of interaction between an external agent and an edge server in an embodiment of the present invention;

[0044] Figure 3 Schematic diagram of interaction between a single edge server and a smart device in an embodiment of the present invention;

[0045] Figure 4 This is a schematic diagram of transaction types within the DAG blockchain in an embodiment of the present invention;

[0046] Figure 5 The following is a schematic diagram of the system flow provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0047] The following describes the embodiments of the present invention by means of specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and the following embodiments and features in the embodiments can be combined with each other without conflict.

[0048] Among them, the accompanying drawings are only for illustrative purposes and represent only schematic diagrams rather than actual pictures, and should not be understood as limiting the present invention. In order to better illustrate the embodiments of the present invention, some parts of the accompanying drawings may be omitted, enlarged or reduced, and do not represent the dimensions of actual products. For those skilled in the art, it is understandable that some well-known structures and their descriptions may be omitted in the accompanying drawings.

[0049] The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar parts; in the description of the present invention, it should be understood that if there are terms such as "upper", "lower", "left", "right", "front", "back", etc. indicating directions or positional relationships, they are based on the directions or positional relationships shown in the drawings. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operate in a specific direction. Therefore, the terms describing the positional relationship in the drawings are only used for illustrative purposes and cannot be understood as limiting the present invention. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0050] Figure 1 A possible application scenario of the embodiment of the present invention is shown. Figure 1As shown in the figure, the network comprises three types of nodes: external agents, edge servers, and smart devices. The external agent is the authority that issues tasks, controlling the creation and expiration of FL training tasks while maintaining a smart contract to run the DAG blockchain. Edge servers, with ample computing resources, are responsible for model aggregation and blockchain maintenance. Smart devices, with local datasets and limited computing resources, are responsible for local model training. The latest global model and edge node reputation are recorded in DAG blockchain transactions to ensure information security and immutability.

[0051] 1. System interaction process

[0052] The proposed algorithm includes a two-stage interaction process: ① interaction between the external agent and the edge server; ② interaction between the edge server and the smart devices within its coverage area.

[0053] 1) External Proxy and Edge Server

[0054] like Figure 2 As shown, the communication medium between the external agent and the edge server is the DAG blockchain. The external agent initializes the global model and generates a genesis block. The model training task is then autonomously executed by the edge servers. Thanks to the asynchronous nature of the DAG blockchain, the edge server can immediately upload the completed aggregation to the DAG blockchain and start the next round of training. The DAG blockchain is a consortium chain jointly maintained by edge servers. Transactions include authentication information, model parameters, reputation values, and tip approval information. Newly published but unverified transactions on the DAG are generally called tips. Publishing transactions on the DAG requires the following three steps:

[0055] Step 1: The node selects some tips according to a given algorithm or randomly;

[0056] Step 2: The node verifies the identity and content correctness of the selected tips;

[0057] Step 3: Construct a new transaction based on the selected tips and publish it on the DAG.

[0058] Through the above three steps, the voting results are stored in the published transactions, and one-way connections are established between transactions through verification relationships, forming a DAG architecture.

[0059] 2) Edge servers and smart devices

[0060] like Figure 3As shown, a single edge server and the smart devices within its coverage area form the FL architecture. The edge server is responsible for uploading and downloading model parameters within its coverage area. For each edge server and its associated smart devices, the edge server selects tips from the DAG blockchain and aggregates them to form a base model. Smart devices obtain the global model from their edge server and perform training tasks based on their local datasets. The training process of each smart device remains independent to ensure data privacy. Local training on smart devices uses a semi-asynchronous approach to improve FL efficiency. After completing a local update round with a fixed number of iterations, the smart device sends a query message containing its current status to the edge server. The status response message instructs the smart device to perform the corresponding action. The smart device then determines the next action based on the action instructions. After local training is complete, the edge server collects the updated local models within its coverage area, aggregates them using the federated averaging algorithm, and uploads them to the DAG blockchain.

[0061] 2. Computational Model

[0062] The time required for edge server m to complete a round of local training is:

[0063]

[0064] Among them, c n represents the number of CPU cycles required to train a data sample in smart device n; D n represents the number of data samples in the local dataset of smart device n; f n Indicates the CPU cycle frequency that the smart device n can provide; r n represents the number of local training rounds of smart device n; ò represents the expected model accuracy achieved by local training; N m represents the number of smart devices within the coverage of edge server m; μ is a constant that depends on the data size and training task. The number of CPU cycles required for smart device n to train the local model can be expressed as c k D k , the CPU energy consumption of edge server m in one round of local training is:

[0065]

[0066] Among them, n It is the effective capacitance coefficient of the chip of the smart device n computer group.

[0067] The time required for edge server m to complete a model aggregation is:

[0068]

[0069] Among them, f mrepresents the CPU cycle frequency that edge server m can provide. The energy consumption of edge server m-global round model aggregation is:

[0070]

[0071] Among them, m is the effective capacitance coefficient of the chip of the edge server m computer group.

[0072] 3. Communication model

[0073] In this network scenario, consider the time overhead of smart device n uploading the model update to edge server m. The data transmission rate (bits / s) of smart device n can be expressed using the Shannon formula:

[0074]

[0075] Where B represents bandwidth, p n represents the transmission power of mechanism k, g n,m represents the channel gain from smart device n to edge server m, and N0 represents the noise power. Therefore, the communication delay of smart devices within the coverage of edge server m is:

[0076]

[0077] Among them, s n is the updated model size of smart device n. The communication energy consumption of smart devices under the coverage of edge server m is:

[0078]

[0079] 3.DAG blockchain transaction types

[0080] like Figure 4 As shown, a DAG blockchain is a distributed ledger in which transactions are connected unidirectionally via approval information. When an edge server generates a new transaction, it must link it to the tips it has chosen to approve. Due to the asynchronous nature of the DAG blockchain and the time window during which edge servers observe the current number of tips, the same tip may be approved by multiple new transactions. Each transaction has both an individual weight and a cumulative weight. The cumulative weight is equal to the transaction's own weight plus the sum of the weights of all transactions that directly or indirectly approve it. When the cumulative weight reaches the weight threshold, it is considered confirmed, achieving consensus.

[0081] 4. Transaction confirmation delay

[0082] The confirmation delay is defined as the time when the cumulative weight of tips reaches the threshold. Assume that when h is small enough, the number of tips remains constant within the time interval (t, t+h). The probability that at least one tip is approved by the new transaction is:

[0083] 1-[1-P xy (t)] 2 =2P xy (t)-[P xy (t)] 2 (15) Assuming that the generation rate of new transactions is a Poisson distribution with an arrival rate of λ, the growth rate of its cumulative weight can be expressed as:

[0084] ΔCW(t)=λ{2P y (t)-[P y (t)] 2}. (16)

[0085] Therefore, given the weight threshold CW0, the transaction confirmation delay is:

[0086]

[0087] 5. Optimization target modeling

[0088] This paper proposes a federated learning algorithm based on the DAG blockchain. To minimize the total latency, including the computational latency between the edge server and the smart device, the communication latency between the computing device, and the transaction confirmation latency of the DAG blockchain, the optimization problem can be modeled as follows:

[0089]

[0090] Among them, constraint C1 indicates that the model upload delay cannot exceed the maximum tolerable delay; constraints C2 and C3 are the energy consumption limits for local training and model aggregation, respectively; constraint C4 indicates that the total allocated smart device transmission bandwidth cannot exceed the bandwidth limit of the edge server; constraints C5, C6, and C7 represent the limits on transmission power, local training computing frequency, and model aggregation computing frequency, respectively.

[0091] 6. Flowchart of the Federated Learning Algorithm Empowered by DAG Blockchain

[0092] Figure 5 This is the flowchart of the federated learning based on the DAG blockchain proposed in this invention. The specific steps are:

[0093] S501: System initialization;

[0094] S502: The external agent initializes the model parameters and generates the genesis block of the DAG blockchain;

[0095] S503: The edge server constructs a basic model;

[0096] S504: The edge server pulls tips from the DAG blockchain based on the tips selection probability;

[0097] S505: The edge server authenticates the transaction and confirms that the selected transaction is not a conflicting transaction or a conflicting transaction that has been directly or indirectly verified;

[0098] S506: The edge server aggregates the model parameters in the selected tips using a federated averaging algorithm to form a basic model;

[0099] S507: The edge server sends the basic model to smart devices within its coverage area;

[0100] S508-S510: The smart device performs local training;

[0101] S508: The smart device obtains the basic model from its own edge server;

[0102] S509: The smart device updates the basic model using the local data set;

[0103] S510: After completing a round of local updates, the smart device sends a query to the edge server, requesting the next action. If the returned action information is 0, the model aggregation phase is entered. If the returned action information is 1, the process returns to step S509.

[0104] S511: The edge server collects updated models from smart devices and aggregates them using the federated averaging algorithm to obtain an updated global model.

[0105] S512: Based on the received smart device information and the updated global model, the edge servers communicate with each other to share the reputation index information to update their own reputation values;

[0106] S513: The edge server packages the latest global model and the updated reputation value into one transaction;

[0107] S514: The edge server establishes a one-way connection between the new transaction and the selected tips, approves these tips, and returns to step S503;

[0108] S515: The external agent selects tips from the DAG blockchain based on the tip selection probability;

[0109] S516: The external agent authenticates the tips and confirms the validity of the transaction;

[0110] S517: The external agent aggregates model parameters using the federated averaging algorithm to obtain the validation model;

[0111] S518: Determine whether the verification model reaches the expected accuracy. If it does, proceed to the next step; otherwise, return to step S515.

[0112] S519: The external agent broadcasts a task termination signal to the edge server, and the algorithm ends.

[0113] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0114] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course, by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD-ROM), and includes a number of instructions for enabling a terminal (which can be a computer, server, or network-side device, etc.) to execute the method for jointly establishing a model between institutions in a privacy and confidentiality environment as described in the embodiment of the present invention.

[0115] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention can be modified or replaced by equivalents without departing from the purpose and scope of the technical solutions, which should all be included in the scope of the claims of the present invention.

Claims

1. A federated learning method based on DAG blockchain, characterized by: The method comprises the following steps: S1: The external agent acts as the task initiator, the edge server is responsible for model aggregation and blockchain maintenance, and the smart device performs the model training task; the external agent initializes the global model and genesis block, and determines the birth and death of the training task; S2: The edge server selects tips (i.e., unapproved transactions) from the DAG blockchain, aggregates the model parameters within the transactions to form a base model, and sends it to the smart devices within its coverage area. S3: The smart device performs local training using the local dataset. After completing a round of local training, it sends a status query message to the edge server to confirm whether to proceed to the next round of local training. S4: After the smart device completes local training, it uploads the updated model to the edge server for aggregation, and uploads the aggregated model to the DAG blockchain as a transaction; S5: Update the edge server reputation value based on the received smart device information and the aggregation model, package it into the transaction and upload it to the DAG blockchain; S6: The edge server uploads the transaction to the DAG blockchain. The tips pulled by the edge server are considered to be approved by the new transaction. When the cumulative weight of the tips reaches a certain threshold, it is considered confirmed. S7: The external agent pulls tips from the DAG blockchain at a fixed period and verifies whether the model has reached the expected accuracy. If the target is met, the model training task is stopped. In S2, a tips selection method is provided. Each transaction contains its own weight and the reputation value of the node that uploaded the transaction. By calculating the weight ratio of each tip in all currently observable tips, the probability of each tip being selected is obtained. The edge server selects multiple tips and aggregates the model parameters to obtain a basic model for local training of smart devices within its coverage area. The probability of Tipy being approved by x to y→x is Expressed as: Where κ is a parameter starting from 1, CW is the cumulative weight of the tip, is the reputation value of the edge node; in the DAG blockchain, the cumulative weight of each transaction is equal to its own weight and the number of transactions that directly and indirectly verify it; when the cumulative weight increases to a threshold, the transaction is considered confirmed on the DAG blockchain; In said S5, a reputation value update method is provided; based on the historical reputation value, all the smart device information obtained in the model aggregation stage, including the number of local iterations and the size of the device data set, the cosine similarity between the aggregated model and the basic model, and the accuracy of the aggregated model, the edge server reputation value is calculated using the entropy weight method. is a real number from 0 to 100; Represents the standardized value of the i-th indicator of edge node m, and we get The proportion is: Where i = 1 represents the historical reputation value of edge node m, i = 2 represents the total number of local training rounds of smart devices under edge node m, i = 3 represents the total size of local data sets of smart devices under edge node m, i = 4 represents the cosine similarity between the aggregate model of edge node m and the basic model, and i = 5 represents the accuracy of the aggregate model of edge node m. Normalization uses positive indicators, that is, the higher the value, the better. The calculation formula is: Since edge nodes in the DAG blockchain are actively training models, the difference between models is used to represent the quality of the models. The cosine similarity is used to represent the difference between models, which is expressed as: in, Represents the basic model in the e-th aggregation of edge node m; Therefore, the entropy weight of indicator i is: in, The larger the entropy weight of an indicator, the greater the contribution of the indicator to the reputation value of edge node m; The reputation value of edge node m is: The maximum credit score is 100.

2. The DAG blockchain-based federated learning method according to claim 1, characterized in that: In S1, the external agent controls the birth and death of FL training tasks while maintaining a smart contract to run the DAG blockchain. When initiating a task, the external agent generates a genesis block containing the initial model parameters and a test dataset. As the task initiator, the external agent monitors the operation of the DAG blockchain at any time and decides whether to terminate the FL training task.

3. The DAG blockchain-based federated learning method according to claim 1, characterized in that: In S3, a semi-asynchronous local model update method is provided; after completing a round of local training, the smart device n sends a message with its current state to the edge server. Query message; status response message a n Will guide the smart device n to perform the corresponding operation; if a n =1, the smart device n enters the next round of local training; when a n = 0, indicating that the remaining waiting time of smart device n is insufficient to complete the next local training. Otherwise, the overall waiting time d wait It will increase, the smart device transmits the updated local model to the edge node for aggregation; minimize the overall waiting time, where n represents the smart device n, r n Indicates the local training round count, represents the computational latency of local training, represents the communication delay between smart device n and edge node, t n Indicates the timestamp when the query message was sent.

4. The DAG blockchain-based federated learning method according to claim 3, characterized in that: In S4, the edge server updates the model uploaded by the smart device and uses the federated average aggregation algorithm to obtain the aggregate model; assuming there are M edge nodes, there are N edge nodes under the coverage of edge node m. m The e-th aggregation model of edge nodes m smart devices can be calculated as: Where ξ represents the global update step size, D n Indicates the size of the local data set of smart device n, 5. The DAG blockchain-based federated learning method according to claim 1, characterized in that: In S6, the edge server packages the aggregate model and reputation value into a transaction and uploads it to the DAG blockchain. There are three types of transactions in the DAG blockchain: ① Confirmed transactions whose cumulative weight has reached a threshold; ② Unconfirmed transactions with at least one approval; and ③ Newly arrived transactions, also known as tips. The edge server will point the newly generated transaction to the tips pulled when obtaining the basic model, indicating that the new transaction approves these tips. Transactions are connected unidirectionally through approval relationships, forming a DAG structure.

6. The DAG blockchain-based federated learning method according to claim 5, characterized in that: In S7, after initializing the genesis block and model parameters, the external agent selects tips according to the tips selection scheme in S2 at fixed time intervals and verifies the accuracy of the model; when the model accuracy reaches the expected target, the external agent broadcasts a termination signal to the edge server to complete the FL training task.

Images