Federated learning methods that hide data source information based on group signatures, smart contracts, and distributed file systems.

Abstract

This invention discloses a federated learning method based on group signatures, smart contracts, and a distributed file system (DFS) to hide data source information, relating to the field of computer cryptography. This invention utilizes smart contracts to manage members of each group. Each group member completes model training using its local data to obtain model parameters. These parameters are then encrypted using group signatures and uploaded to the DFS to obtain the DFS address. The encryption key and DFS address are then encrypted and group-signed again via a smart contract and uploaded. The central server decrypts the DFS address and key to obtain the DFS address, downloads the encrypted model parameters from the DFS, and decrypts them using the key to obtain the model parameters uploaded by each group member. These parameters are then aggregated and updated to obtain the improved global model. This invention effectively protects the privacy of data providers, ensuring the protection of data source information for both parties during the federated learning process.

Description

Technical Field

[0001] This invention relates to the field of computer cryptography, and more specifically to a federated learning method based on group signatures, smart contracts, and distributed file system (DFS) for hiding data source information. Background Technology

[0002] In today's information age, machine learning, as a core technology for data analysis and pattern recognition, is profoundly changing our work and lifestyles. Its basic principle is to train algorithms to extract valuable information from massive amounts of data, thereby enabling computer systems to predict and make decisions based on new data. From simple linear regression to complex deep learning networks, these algorithms play a crucial role in various fields such as healthcare, finance, and social media.

[0003] In the medical field, for example, machine learning technology has been widely applied to disease diagnosis, disease prediction, and personalized treatment planning. However, these applications require processing large amounts of sensitive patient data, such as medical records, biometric information, and gene sequences. Similarly, in personal applications, such as smartphone apps and social networking services, machine learning technology plays a crucial role in personalized recommendations and user behavior analysis, often processing data related to users' personal preferences and behavioral habits.

[0004] However, with the increasing prominence of data privacy and confidentiality issues, how to fully utilize this data while protecting privacy has become an urgent problem to be solved. Traditional centralized machine learning methods, while offering advantages in computational efficiency, present privacy protection challenges when processing sensitive data. This is because these methods require processing large amounts of data in a single data center or server, increasing the risk of data theft or misuse, and potentially exposing private information during transmission.

[0005] To address this issue, federated learning has emerged as an emerging machine learning approach. It keeps the data on its original data source, such as a user's smartphone or a hospital's server, then sends the machine learning model to each of these local devices to learn independently. Finally, the learned model is updated (rather than the original data) and sent back to the central server. This method effectively reduces the risk of data leakage and also reduces bandwidth requirements.

[0006] However, while federated learning has made some progress in improving content privacy, it still faces challenges in hiding data source addresses. For example, in the medical field, even if a patient's specific health data is protected, if the data can be identified as originating from a specific hospital or region, it may still expose the patient's identity or health condition. In personal applications, even if a user's specific behavioral data is anonymized, the leakage of the data source's geographic location information may still reveal the user's personal habits and behavioral patterns.

[0007] Therefore, it is particularly urgent to develop a federated learning method that can simultaneously protect data content and hide the data source address. Summary of the Invention

[0008] To overcome the shortcomings and deficiencies of the existing technologies, this invention provides a federated learning method based on group signatures, smart contracts, and a distributed file system (DFS) to hide data source information. The purpose of this invention is to address the problem that existing technologies cannot hide data source information. The federated learning method based on group signatures, smart contracts, and a DFS proposed in this invention avoids direct network interactions between the data holder and the central server throughout the entire federated learning training process. Instead, it utilizes a computer cryptography-based encryption scheme using group signatures, and separately uses smart contracts and DFS to transmit data addresses and the data itself. This method protects the data provider's source information while slightly impacting efficiency, effectively protecting the data provider's privacy and ensuring the protection of the data source information for both parties during the federated learning process.

[0009] To address the problems existing in the prior art, the present invention is achieved through the following technical solution.

[0010] This invention provides a federated learning method based on hidden data source information in group signatures, smart contracts, and distributed systems. The method includes the following steps:

[0011] S1. Create a smart contract: Create a smart contract that provides a centralized platform for group signature group management, allowing each node to register and assigning a group signature and group private key to the successfully registered nodes for transmitting public keys, encrypted messages, and group signatures; wherein the nodes include a central server node and each group member node;

[0012] S2. Creation and Management of Federated Learning Groups: Create a federated learning group and elect a group administrator. The group administrator's computer or server is used as the oracle for the smart contract. The oracle randomly generates a group signature group and publishes the public key information of the group signature group to the network, while keeping the private key private. The oracle generates a group certificate and a group private key for each group member who joins the group signature group. After the central server role is registered, its public key used for symmetric encryption is published via the smart contract.

[0013] S3. Model Training and Model Parameter Upload: The central server distributes the global model to each group member in the group signature group. After training the model using local data through federated learning, the group members obtain the model parameters. They then encrypt the model parameters using a key to obtain encrypted parameters, upload the encrypted parameters to DFS, and obtain the DFS address. They then encrypt the key and DFS address using the central server's public key to obtain an encrypted message, and use the group certificate and group private key to perform group signature on the encrypted message. Finally, they call the smart contract to upload the encrypted message and the group signature.

[0014] S4. The central server obtains model parameters and aggregates updates: The central server listens to the smart contract, verifies the group signature using the public key of the group signature group, and obtains the encrypted message; the central server decrypts the encrypted message to obtain the key and DFS address; the central server uses the DFS address to retrieve the encrypted parameters from the DFS, and uses the key to decrypt the encrypted parameters to obtain the model parameters.

[0015] After obtaining sufficient model parameters, the central server uses a set algorithm to perform aggregation and update to improve the global model. The improved global model is then sent back to each group member in the group signature group for use in the next round of local training.

[0016] In a further preferred embodiment, in step S3, group members first randomly select a key, use the key to symmetrically encrypt the model parameters to obtain encrypted parameters, and then upload the encrypted parameters to DFS to obtain the DFS address; group members use the key and DFS address to perform asymmetric encryption using the public key of the central server to obtain an encrypted message; group members use the group certificate and group private key to perform group signature on the encrypted message, and finally, call the smart contract to upload the encrypted message and the group signature.

[0017] In a further preferred embodiment, in step S4, the central server uses the public key information of the group signature group to verify the group signature and filters out encrypted messages from the group signature group; the central server uses its own asymmetric encryption private key to decrypt the encrypted message to obtain the key and DFS address; the central server uses the DFS address to retrieve the encrypted parameters from the DFS and uses the key to decrypt them to obtain the model parameters.

[0018] Furthermore, in a more optimized approach, group members train a federated learning model using local data to obtain model parameters. Differential privacy techniques are then employed to protect the privacy of these model parameters, ensuring that data features cannot be obtained through them.

[0019] In a further preferred embodiment, in step S2, companies or organizations in the network that hold similar data or attempt to jointly train a model using federated learning form a federated learning group, and the members of the federated learning group jointly elect a trusted group administrator.

[0020] In an even more preferred scenario, the group administrator prepares a computer or server as an oracle to implement the interface required by the smart contract and listen for smart contract events. The oracle randomly selects some basic parameters to generate a group signature group, then publishes the public key information of this group signature group on the network so that everyone can query it, while keeping the private key of the group signature group privately stored.

[0021] Furthermore, when a company or organization wants to join a federated learning group's signature group to jointly train a model, the company or organization invokes the smart contract to apply to join the federated learning group and passes in its relevant information.

[0022] In an even more preferred manner, after the oracle detects a group signing event, it first verifies the eligibility of the newly joined group member. Once the verification is successful, the oracle uses the private key information of the group signing group to randomly select a parameter to generate a group certificate and a group private key for the newly joined group member, and then returns the group certificate and group private key to the newly joined group member through an encrypted channel.

[0023] More preferably, when a group member posts an incorrect model parameter, the group administrator determines the group certificate and group signature through the incorrect model parameter, and then determines the identity of the group member who signed the group signature through the group certificate and group signature.

[0024] More preferably, in step S1, the created smart contract implements the CreateGroup interface, RegisterNode interface, RegisterServer interface, RegisterReturn interface, and UploadMessage interface; wherein,

[0025] The CreateGroup interface declares a group in a smart contract, and this interface triggers the GroupCreate event; the group administrator calls this interface to create a group with a group signature.

[0026] The RegisterNode interface triggers the NodeRegister event, which is listened for by the oracle and transmits the node name, node-related information, and node public key of the registered node; this interface is called when a new group member joins the group signature group.

[0027] The RegisterServer interface triggers the ServerRegister event, which is listened for by the oracle and transmits the server name, server-related information, and server public key of the registered central server; this interface is called when a central server role is registered.

[0028] The RegisterReturn interface triggers the ReturnRegister event, which is listened to by the central server and group members, transmitting the registrant's public key, registration result, and other information. Specifically, when the oracle hears the NodeRegister event, the group administrator will conduct a qualification review of the newly joined group member, and then call the RegisterReturn interface to report the review result. If the review fails, the result is "failed," with the reason for the failure as an additional message; if the review passes, the result is "passed," with no additional message, and the group certificate and group private key are transmitted to the newly joined group member via encrypted information.

[0029] The UploadMessage interface triggers the MessageUpload event, which is monitored by the central server and transmits the message along with its group signature. Group members call this interface when sending messages and signatures to the central server.

[0030] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0031] 1. In the entire training process of federated learning, all interactions between the data holder and the central server do not directly pass through the network. Instead, a computer cryptography-based encryption scheme is provided by using group signatures. At the same time, smart contracts and DFS are used to transmit data addresses and the data itself, which protects the source information of the data provider while slightly affecting efficiency and effectively protects the privacy information of the data provider. This ensures that the data source information of both parties is protected during the federated learning process.

[0032] 2. This invention enhances data privacy protection. By using differential privacy technology, group members ensure the privacy of their local data when uploading model parameters. This is crucial for federated learning because, in this setup, data does not leave its original storage location.

[0033] 3. This invention enables secure and efficient group management. By electing trusted group administrators and employing group signature technology, it ensures the authentication and anonymity of group members. This management mechanism helps prevent malicious behavior and can track specific members when necessary.

[0034] 4. This invention achieves decentralized model parameter storage. By uploading encrypted model parameters to a distributed file system (DFS), the risk of single point of failure is reduced, and the robustness of the system is enhanced.

[0035] 5. This invention optimizes the role of the central server. The central server receives and processes model parameters through smart contracts and DFS, reducing the complexity of its direct interaction with a large number of members and improving system efficiency.

[0036] 6. This invention enables aggregated model updates. The central server can verify and aggregate model parameters from multiple members, thereby updating the global model. This method maintains model quality while reducing the need for data centralization.

[0037] 7. In this invention, the model parameters published by each group member are traceable. Group administrators can identify members who upload incorrect model parameters when necessary, which helps maintain the overall health and credibility of the federated learning group.

[0038] 8. This invention makes reasonable use of smart contracts. By using smart contracts to manage processes such as group joining, model parameter uploading, and verification, the transparency and automation of operations are increased, while trust dependence and operational costs are reduced. Attached Figure Description

[0039] The foregoing and hereinafter detailed description of the invention becomes clearer when read in conjunction with the following drawings, in which:

[0040] Figure 1 This is a flowchart illustrating the group management function of the technical solution of this invention.

[0041] Figure 2 This is a schematic diagram of the model parameter upload DFS function and the process of the central server obtaining and aggregating model parameters for updating in the technical solution of this invention.

[0042] Figure 3 This is a flowchart illustrating the model parameter traceability function of the technical solution of this invention. Detailed Implementation

[0043] The following specific embodiments further illustrate the technical solutions for achieving the objectives of this invention. It should be noted that the technical solutions protected by this invention include, but are not limited to, the following embodiments.

[0044] Example 1

[0045] As a preferred embodiment of the present invention, this embodiment discloses a federated learning method based on group signatures, smart contracts, and hidden data source information of distributed systems. The method includes creating smart contracts, creating and managing federated learning groups, model training and uploading model parameters, and a central server obtaining model parameters and aggregating and updating them.

[0046] Refer to the instruction manual appendix Figure 1 As shown, the creation of a smart contract is as follows:

[0047] Create a centralized platform for group signature group management, allowing each node to register and assigning a group signature and group private key to the successfully registered node. This platform is used to transmit public keys, encrypted messages, and group signatures via smart contracts. The nodes include a central server node and each group member node.

[0048] In this embodiment, a system has one and only one smart contract for use by all users (group administrators, group members, and the central server).

[0049] As an example, the smart contract implements the CreateGroup interface, RegisterNode interface, RegisterServer interface, RegisterReturn interface, and UploadMessage interface; wherein,

[0050] The CreateGroup interface declares a group in a smart contract, and this interface triggers the GroupCreate event; the group administrator calls this interface to create a group with a group signature.

[0051] The RegisterNode interface triggers the NodeRegister event, which is listened for by the oracle and transmits the node name, node-related information, and node public key of the registered node. This interface is called when a new group member joins the group signature group of the federated learning group.

[0052] The RegisterServer interface triggers the ServerRegister event, which is listened for by the oracle and transmits the server name, server-related information, and server public key of the registered central server; this interface is called when a central server role is registered.

[0053] The RegisterReturn interface triggers the ReturnRegister event, which is listened to by the central server and group members, transmitting the registrant's public key, registration result, and other information. Specifically, when the oracle hears the NodeRegister event, the group administrator will conduct a qualification review of the newly joined group member, and then call the RegisterReturn interface to report the review result. If the review fails, the result is "failed," with the reason for the failure as an additional message; if the review passes, the result is "passed," with no additional message, and the group certificate and group private key are transmitted to the newly joined group member via encrypted information.

[0054] The UploadMessage interface triggers the MessageUpload event, which is monitored by the central server and transmits the message along with its group signature. Group members call this interface when sending messages and signatures to the central server.

[0055] As an example, the smart contract only needs to satisfy the above-mentioned interfaces and events, and the specific code can be created in Ethereum or Hyperledger Fabric.

[0056] Refer to the instruction manual appendix Figure 1 As shown, the creation and management of federated learning groups are as follows:

[0057] A federated learning group is created, and a group administrator is elected. The group administrator's computer or server is used as an oracle. The oracle randomly generates a group signature group and publishes the public key information of the group signature group to the network, while keeping the private key private. The oracle generates a group certificate and a group private key for each group member who joins the group signature group. After the central server role is registered, its public key used for symmetric encryption is published via a smart contract.

[0058] Refer to the instruction manual appendix Figure 2 As shown, model training and model parameter uploading are as follows:

[0059] The central server distributes the global model to each group member in the group signature group. After training the model using local data through federated learning, the group members obtain the model parameters. They then encrypt the model parameters using a key to obtain encrypted parameters, upload the encrypted parameters to DFS, and obtain the DFS address. They then encrypt the key and DFS address using the central server's public key to obtain an encrypted message, and use the group certificate and group private key to perform a group signature on the encrypted message. Finally, they call the smart contract to upload the encrypted message and the group signature.

[0060] The central server retrieves model parameters and aggregates and updates them, specifically as follows:

[0061] The central server listens to the smart contract, verifies the group signature using the public key of the group signature group, and obtains the encrypted message; the central server decrypts the encrypted message to obtain the key and DFS address; the central server uses the DFS address to retrieve the encrypted parameters from the DFS, and decrypts the encrypted parameters using the key to obtain the model parameters;

[0062] After obtaining sufficient model parameters, the central server uses a set algorithm to perform aggregation and update to improve the global model. The improved global model is then sent back to each group member in the group signature group for use in the next round of local training.

[0063] In this embodiment, during the entire federated learning training process, all interactions between the data holder and the central server do not directly pass through the network. Instead, a computer cryptography-based encryption scheme is provided using group signatures. At the same time, smart contracts and DFS are used to transmit the data address and the data itself, respectively. Only the central server can access the metadata. This protects the source information of the data provider while slightly affecting efficiency, effectively protecting the privacy information of the data provider, and ensuring that the data source information of both parties is protected during the federated learning process.

[0064] In this embodiment, the smart contract is used to transmit the address and encrypted information of the model parameters encrypted with the central server's public key, ensuring that only the central node can access the metadata; it also provides a centralized platform for group signature management, allowing each node to securely register its own signature. There is one and only one smart contract in a system, available to all users.

[0065] Example 2

[0066] As another preferred embodiment of the present invention, this embodiment is a further detailed supplement and explanation of the technical solution of the present invention based on the above embodiment 1.

[0067] In this embodiment, model training and model parameter uploading are further refined as follows: Group members first randomly select a key, use the key to symmetrically encrypt the model parameters to obtain encrypted parameters, and then upload the encrypted parameters to DFS to obtain the DFS address; Group members use the key and DFS address to perform asymmetric encryption using the public key of the central server to obtain an encrypted message; Group members use the group certificate and group private key to perform group signature on the encrypted message, and finally, call the smart contract to upload the encrypted message and the group signature.

[0068] In this embodiment, the central server obtains model parameters and aggregates updates, which is further implemented as follows: the central server uses the public key information of the group signature group to verify the group signature and filters out encrypted messages from the group signature group; the central server uses its own asymmetric encryption private key to decrypt the encrypted messages to obtain the key and DFS address; the central server uses the DFS address to retrieve the encrypted parameters from the DFS and uses the key to decrypt them to obtain the model parameters.

[0069] In the above implementation scheme, group members train the federated learning model using local data to obtain model parameters. Differential privacy technology is used to protect the privacy of these model parameters, preventing the data features from being obtained through them. By using differential privacy, group members ensure the privacy of their local data when uploading model parameters, which is crucial for federated learning because the data does not leave its original storage location in this setup.

[0070] Example 3

[0071] As another preferred embodiment of the present invention, this embodiment is a further detailed supplement and explanation of the technical solution of the present invention based on the above embodiment 1 or embodiment 2.

[0072] In this embodiment, the creation and management of federated learning groups are specifically implemented as follows:

[0073] Companies or organizations that hold similar data or attempt to jointly train a model using federated learning form a federated learning group. Members of the federated learning group jointly elect a trusted group administrator.

[0074] The group administrator prepares a computer or server as an oracle to implement the interface required by the smart contract and listen for smart contract events. The oracle randomly selects some basic parameters to generate a group signature group, and then publishes the public key information of this group signature group on the network so that everyone can query it, while keeping the private key of the group signature group private.

[0075] When a company or organization wants to join a federated learning group's signature group to jointly train a model, the company or organization invokes the smart contract to apply to join the signature group and passes in its relevant information.

[0076] After the oracle detects a group signing event, it first verifies the eligibility of the new group member. Once the verification is successful, the oracle uses the private key information of the group signing group to randomly select a parameter to generate a group certificate and a group private key for the new group member, and then returns the group certificate and group private key to the new group member through an encrypted channel.

[0077] Furthermore, federated learning typically requires the use of massive amounts of data from numerous nodes, thus inevitably leading to anomalies. If incorrect model parameters are published due to unintentional or malicious operation, the group administrator can, under certain conditions, determine the group certificate and group signature through the incorrect model parameters, identify the group member who signed the group signature through the group certificate and group signature, and take appropriate measures (such as warnings, member removal, etc.) to maintain the overall reputation of the group.

[0078] Example 4

[0079] As another preferred embodiment of the present invention, this embodiment provides an encryption scheme based on computer cryptography by means of group signature, and at the same time uses the addresses and data itself transmitted by smart contracts and DFS respectively, which protects the source information of the data provider with a slight impact on efficiency and effectively protects the privacy information of the data provider.

[0080] In this embodiment, the federated learning method based on group signatures, smart contracts, and distributed file systems hides the data source information. During the entire training process of federated learning, all interactions between the data holder and the central server do not go directly through the network. Instead, the data address and the data itself are transmitted through smart contracts and DFS, respectively. In this process, the data source information of both parties is protected.

[0081] Specifically, it includes the following:

[0082] S1. Create a smart contract: Create a smart contract that provides a centralized platform for group signature group management, allowing each node to register and assigning a group signature and group private key to the successfully registered nodes for transmitting public keys, encrypted messages, and group signatures; wherein the nodes include a central server node and each group member node;

[0083] The created smart contract implements the CreateGroup, RegisterNode, RegisterServer, RegisterReturn, and UploadMessage interfaces;

[0084] S2, Creation and Management of Federated Learning Groups

[0085] 1) Prepare to create a group. A federated learning group N is formed by companies or organizations n in the network that hold similar data or attempt to jointly train a model using federated learning. The group members in the federated learning group jointly elect a trusted group administrator A.

[0086] 2) Create a group signature group. Group administrator A prepares a computer (or server) as the oracle O for the smart contract, implements the interface required by the smart contract, and listens for smart contract events.

[0087] Oracle O randomly selects some basic parameters b to generate a group signature group G, and calls the CreateGroup interface of the smart contract, passing in the group name and group description, to form a GroupCreate event.

[0088] Then, the public key information (gpk) of this group is made public on the network so that anyone can query it, while the private key (gmsk) is kept secret to ensure that no one can obtain this private key.

[0089] When a group member wants to join the group signature group as a central server, the RegisterServer interface of the smart contract is called, triggering the ServerRegister event. After the smart contract's oracle O listens for the ServerRegister event, it reviews the information of the group member who is registering as the central server. After the review is approved, the node name, node-related information and node public key of the registered node of the group member are managed, and the public key pubKey used by the central server for symmetric encryption is made public through the smart contract.

[0090] 3) Joining a group. When a company or organization i wants to join a federated learning group signature group to jointly train a model, the company or organization calls the smart contract method to apply to join the group signature group and passes in its relevant information.

[0091] When a user wants to join a group signature group as a data holder, the RegisterNode interface of the smart contract is called, triggering the NodeRegister event. After oracle O detects the NodeRegister event for joining the group, it first performs a qualification check on the company or organization. After the check, the oracle calls the RegisterReturn interface of the smart contract, triggering the ReturnRegister event, and returns the check result to member i. If the check fails, the result is "failed," with the reason for the failure as an additional message. If the check passes, the result is "passed," with no additional message. Oracle O then uses the group private key gmsk and selects a random parameter r to generate a group certificate σ and a group private key x for this group member i. i and the group certificate σ and group private key x i The group certificate σ is returned to member i via an encrypted channel and is unique to each member.

[0092]

[0093] S3, Model Training and Model Parameter Upload

[0094] 1) Model Training. The central server C transmits model m to each member i. After training the model using local data data through federated learning, member i obtains the model parameters θ. Group member i can use differential privacy and other techniques to ensure that the features of the data cannot be obtained through the model parameters θ, thereby protecting data privacy;

[0095]

[0096] 2) Upload model parameters to DFS. Group member i first randomly selects a key, uses the key to symmetrically encrypt the model parameters to obtain encrypted parameters θ', and then uploads the encrypted parameters θ' to DFS to obtain the address addr;

[0097] Subsequently, member i uses the public key pubKey of the central server C to perform asymmetric encryption on the key key and address addr to obtain the encrypted message m′. Afterwards, member i uses the group certificate σ and the group private key x i Perform a group signature on the encrypted message m′ to obtain the signature sig, and finally call the smart contract to upload the encrypted message m′ and the signature sig.

[0098]

[0099] When member i sends the encrypted message m′ and signature sig to the central server, it calls the UploadMessage interface of the smart contract, triggering the MessageUpload event.

[0100] S4. The central server retrieves model parameters and aggregates and updates them.

[0101] 1) Obtain model parameters. The central server C listens to the smart contract. After the central server hears the MessageUpload event, it uses the group public key gpk to verify the signature sig and filters out the encrypted message m′ from this group;

[0102] Subsequently, the central server C decrypts the encrypted message m′ using its own asymmetric encryption private key secKey, obtaining the key key and address addr. The central server C then uses the address addr to retrieve the encrypted parameter θ' from the DFS and decrypts it using the key key to obtain the model parameter θ.

[0103]

[0104] 2) Aggregated model update. After obtaining sufficient model parameters θ, the central server C uses a specific algorithm (e.g., weighted averaging) to aggregate and update the global model m, thereby achieving an effect close to that of traditional centralized machine learning. The improved global model m′ is then sent back to swarm member i for use in the next round of local training.

[0105] Model parameter sourcing: Federated learning typically requires massive amounts of data from numerous nodes, making exceptions inevitable. If an incorrect model parameter θ is published due to unintentional or malicious operation, group administrator A can, under specific conditions (such as multiple incorrect publications, member requests, etc.), open (σ,θ,s) to verify the identity of group member i who signed the signature. And take appropriate measures (such as warnings, removing members, etc.) to maintain the overall reputation of the group.

Claims

1. A federated learning method based on hidden data source information in group signatures, smart contracts, and distributed systems, characterized by: The method includes the following steps: S1. Create a smart contract: Create a smart contract that provides a centralized platform for group signature group management, allows each node to register, and assigns a group signature and group private key to the successfully registered nodes for transmitting public keys, encrypting messages, and group signatures; wherein the nodes include a central server node and each group member node; S2. Creation and Management of Federated Learning Groups: Create a federated learning group and elect a group administrator. Use the group administrator's computer or server as an oracle. The oracle randomly generates a group signature group and publishes the public key information of the group signature group to the network, while keeping the private key private. The oracle generates a group certificate and a group private key for each group member who joins the group signature group. After the central server role is registered, its public key used for symmetric encryption is published via a smart contract. S3. Model Training and Model Parameter Upload: The central server distributes the global model to each group member in the group signature group. After training the model using local data through federated learning, the group members obtain the model parameters. The group members first randomly select a key and use the key to symmetrically encrypt the model parameters to obtain encrypted parameters. Then, they upload the encrypted parameters to DFS to obtain the DFS address. The group members use the key and DFS address to perform asymmetric encryption using the central server's public key to obtain the encrypted message. The group members use the group certificate and group private key to perform group signature on the encrypted message. Finally, they call the smart contract to upload the encrypted message and the group signature. S4. The central server obtains model parameters and aggregates updates: The central server listens to the smart contract, verifies the group signature using the public key of the group signature group, and obtains the encrypted message; the central server decrypts the encrypted message to obtain the key and DFS address; the central server uses the DFS address to retrieve the encrypted parameters from the DFS, and uses the key to decrypt the encrypted parameters to obtain the model parameters. After obtaining sufficient model parameters, the central server uses a set algorithm to perform aggregation and update to improve the global model. The improved global model is then sent back to each group member in the group signature group for use in the next round of local training.

2. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 1, characterized in that: In step S4, the central server uses the public key information of the group signature group to verify the group signature and filters out encrypted messages from the group signature group; the central server uses its own asymmetric encryption private key to decrypt the encrypted message to obtain the key and DFS address; the central server uses the DFS address to retrieve the encrypted parameters from the DFS and uses the key to decrypt them to obtain the model parameters.

3. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 1 or 2, characterized in that: After group members train the federated learning model using local data, they obtain the model parameters. Differential privacy technology is used to protect the privacy of the model parameters, making it impossible to obtain the features of the data through the model parameters.

4. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 1 or 2, characterized in that: In step S2, companies or organizations in the network that hold similar data or attempt to jointly train a model using federated learning form a federated learning group. The members of the federated learning group jointly elect a trusted group administrator.

5. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 1 or 2, characterized in that: The group administrator prepares a computer or server as an oracle to implement the interface required by the smart contract and listen for smart contract events. The oracle randomly selects some basic parameters to generate a group signature group, and then publishes the public key information of this group signature group on the network so that everyone can query it, while keeping the private key of the group signature group private.

6. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 5, characterized in that: When a company or organization wants to join a federated learning group to jointly train a model, the company or organization calls the smart contract to apply to join the group signature group of the federated learning group and passes in its relevant information.

7. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 6, characterized in that: After the oracle detects a group signing event, it first verifies the eligibility of the new group member. Once the verification is successful, the oracle uses the private key information of the group signing group to randomly select a parameter to generate a group certificate and a group private key for the new group member, and then returns the group certificate and group private key to the new group member through an encrypted channel.

8. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 1 or 2, characterized in that: When a group member posts incorrect model parameters, the group administrator uses these incorrect model parameters to determine the group certificate and group signature, and then uses the group certificate and group signature to identify the group member who signed the group signature.

9. The federated learning method based on hidden data source information of group signatures, smart contracts, and distributed systems as described in claim 1 or 2, characterized in that: In step S1, the created smart contract implements the CreateGroup interface, RegisterNode interface, RegisterServer interface, RegisterReturn interface, and UploadMessage interface; among which, The CreateGroup interface declares a group in a smart contract, and this interface triggers the GroupCreate event; the group administrator calls this interface to create a group with a group signature. The RegisterNode interface triggers the NodeRegister event, which is listened for by the oracle and transmits the node name, node-related information, and node public key of the registered node; this interface is called when a new group member joins the group signature group. The RegisterServer interface triggers the ServerRegister event, which is listened for by the oracle and transmits the server name, server-related information, and server public key of the registered central server; this interface is called when a central server role is registered. The RegisterReturn interface triggers the ReturnRegister event, which is listened to by the central server and group members, transmitting the registrant's public key, registration result, and other information. The UploadMessage interface triggers the MessageUpload event, which is monitored by the central server and transmits the encrypted message along with its group signature. Group members call this interface when sending the encrypted message and group signature to the central server.

Images