A method, device and equipment for constraining the behavior of demanders and participants

Abstract

The present invention provides a method, device and equipment for constraining the behavior of demanders and participants, belonging to the field of artificial intelligence technology. The method includes: receiving a data collaboration request from a federated node as an initiator; after the initiator and the participant reach a data collaboration agreement and start the federated learning task, the notary monitors the execution of the data collaboration agreement by the initiator and the participant during the federated learning task; if the initiator and the participant have completed the federated learning task, the initiator and the participant are evaluated, the corresponding federated node reputation is updated, and the federated account is written. The alliance chain with a certain access mechanism ensures the credibility of the identity and role of participants from different organizations in the blockchain network through the member identity identification mechanism based on MSP.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to a method, device and equipment for constraining the behavior of demanders and participants. Background Art

[0002] Federated Learning is an emerging basic technology in the field of artificial intelligence. Its goal is to carry out efficient machine learning among multiple participants or multiple computing nodes while ensuring information security during big data exchange, protecting terminal data and personal data privacy, and ensuring legality and compliance.

[0003] In federated learning, establishing an effective incentive mechanism to ensure sustained participation in the data federation is a key challenge. The goal is to maximize the sustainability of the federation while minimizing unfairness among participants and dynamically allocating a given budget to each participant in the data federation. The key to achieving this goal is developing a reward system that fairly and equitably shares the profits generated by the federation with all participants.

[0004] The design of the incentive mechanism for federated learning is a problem of finding the optimal organizational and payment structure for the alliance to achieve a series of optimization goals.

[0005] Existing incentive methods include those based on revenue-sharing games and reverse auctions. When designing incentive mechanisms for federated learning, the contribution of participants to data federation is a crucial factor, while the costs of joining the data federation must also be considered. In a given market, some companies may already have a significant market share and thus have accumulated large amounts of high-quality data. Such companies are extremely valuable to data federation if high-quality federated learning models are to be built.

[0006] But this type of market leader may unintentionally help its competitors because the federated learning model will be shared among all participants, thereby incurring potentially huge opportunity costs for the market leader. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a method, device, and equipment to constrain the behavior of demanders and participants, thereby resolving the potential risk of the lack of a trusted third party in the existing federated learning training mechanism. To solve the above technical problem, the embodiments of the present invention provide the following technical solutions:

[0008] An embodiment of the present invention provides a method for constraining the behavior of a demander and a participant, the method comprising:

[0009] Receive a data collaboration request from the initiator's federation node;

[0010] After the initiator and participants reach a data collaboration agreement and initiate the federated learning task, the notary monitors the implementation of the data collaboration agreement by the initiator and participants during the federated learning task.

[0011] If both the initiator and the participant complete the federated learning task, the initiator and the participant will be evaluated, the corresponding federated node credibility will be updated, and the results will be written into the federated ledger.

[0012] In a preferred embodiment, the initiator, participants, and notary are all federated nodes; the structure of the federated node includes:

[0013] The ID of the federation node;

[0014] Federation node reputation;

[0015] The type label of the federated node, including the initiator, participant, and notary;

[0016] array of ledger entries;

[0017] The latest ledger entry, the highest known submitted ledger entry index value.

[0018] In a preferred embodiment, the initiator and the participant reach a data collaboration agreement including:

[0019] In step A, the federated node, acting as the initiator, receives a message from a participant. If the message contains the data collaboration protocol ID from the participant, step B is executed. If the message indicates that the risk exceeds the limit or the federated node's credibility is insufficient, step B is ignored.

[0020] Step B: receiving the data collaboration agreement ID and related information;

[0021] Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility is greater than a threshold, send a message to the participating party indicating that the protocol ID is approved; otherwise, send a message to the participating party indicating that the protocol ID is not approved.

[0022] Step D: Send the data collaboration agreement ID to the notary.

[0023] In a preferred embodiment, the initiator and the participant reaching a data collaboration agreement further include:

[0024] In the first step, the federated node, as a participant, receives a message from the initiator. If the message is a data collaboration request, the second step is executed. If the message is an agreement agreement ID from the initiator, the node is added to the waiting queue according to the urgency of the agreement and waits for service. If the message is a disagreement agreement ID, the data collaboration agreement ID is canceled.

[0025] The second step is to generate a data collaboration agreement ID;

[0026] The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If so, proceed to the fourth step. If not, send a "not enough credibility" message to the initiator to refuse participation;

[0027] The fourth step is to calculate the feasibility of the participant's own agreement. If the feasibility of the agreement is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

[0028] In a preferred embodiment, monitoring the execution of the data collaboration protocol by the initiator and the participants during the federated learning task includes:

[0029] As the notary party, the federated node coordinates and monitors federated learning tasks and notarizes and arbitrates data collaboration agreements. If a new protocol ID message is received from the initiator, step 2 is executed; if a "Complete Protocol ID" message is received from a participant, step 4 is executed.

[0030] Step 2: Deposit the agreement with the corresponding agreement ID into the federated ledger;

[0031] Step 3: Start coordinating and monitoring this federated learning task and set the time.

[0032] Step 4: Monitor whether the initiator and participants have successfully completed the federated learning task, and record the completion time of the initiator and participants.

[0033] In a preferred embodiment, the method further comprises:

[0034] Design a data collaboration protocol to describe the collaborative relationship between the initiator and participants in a federated learning task. The data collaboration protocol includes:

[0035] Agreement ID: data collaboration agreement number;

[0036] Initiator ID: the initiator's ID;

[0037] Participant ID: the participant's ID;

[0038] Initiator's reputation value: the initiator's current federation node reputation;

[0039] Participant reputation value: the participant's current federation node reputation;

[0040] Notary ID list: ID list of notary parties in the data collaboration agreement;

[0041] Data file summary: the ID and hash value of the file provided by the participant;

[0042] Agreed price and payment method: the data price and payment method agreed upon by the initiator and participants;

[0043] Breach of contract cost: the cost that the initiator or participant must pay for not complying with the data collaboration agreement;

[0044] Agreement period: the effective time interval of the data collaboration agreement.

[0045] In a preferred embodiment, the method further includes: designing the feasibility of the protocol based on the credibility, expected benefits, default costs of the initiator and the participants, as well as the current task queue length and the urgency of the task, wherein

[0046] The feasibility of the agreement of the initiator B

[0047] Setting a threshold μ>0 limits the feasibility of the protocol. Participants whose feasibility exceeds the threshold will be included in the list of candidate participants.

[0048] Data provider A is a participant, and the feasibility of the agreement

[0049] Where:

[0050] Tbase is the guaranteed value of the federation node’s credibility, ensuring that new participants have the opportunity to participate;

[0051] Trust(ID, A) is the federation node reputation of participant A when entering into the data collaboration agreement. Trust(ID, A) = 0 for newly joined participants.

[0052] Waiting(ID, B) is the current waiting queue length of participant A when entering into the data collaboration agreement;

[0053] Urgency(ID, B) is the urgency of the initiator B to establish a data collaboration agreement. Urgency(ID, B)∈[0,1], where 1 represents the highest urgency.

[0054] Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task. Its relationship with the value of the demand document is Gain(ID) = k∑ f∈F Value(f);

[0055] Penalty(ID, A) is the penalty for breach of contract by Party A;

[0056] w1+w2+w3=1, and w1, w2, w3∈(0, 1).

[0057] In a preferred embodiment, evaluating the initiator and the participants and updating the corresponding federation node reputations include:

[0058] After executing the data collaboration agreement, the corresponding protocol evaluation function is called to calculate the incremental credibility of the federated nodes of the initiator and the participant; the protocol evaluation function is related to the credibility of the federated nodes of the initiator and the participant before signing the data collaboration agreement, the expected benefits, the breach costs, and the mutual evaluation results between the initiator and the participant.

[0059] In a preferred embodiment, the protocol evaluation function used by participant A to calculate the incremental reputation of the federated node is:

[0060] Trust(ID, A) = MAX(0, Trust(ID′, A) + p1 × Eval(ID, B) × Gain(ID) - p2 × Penalty(ID, A)), where Trust(ID′, A) is the reputation of the federated node before A's transaction, and Eval(ID, B) is the evaluation of the initiator B on the performance of the data collaboration agreement by the participant A.

[0061] The protocol evaluation function used by initiator B to calculate the incremental reputation of the federated nodes is:

[0062] Trust(ID, B) = MAX(0, Trust(ID′, B) + q1×Eval(ID, A) - q2×Penalty(ID, B)), where Trust(ID′, B) is the credibility of the federation node after the previous transaction of initiator B, and Eval(ID, A) is participant A's evaluation of initiator B's performance of the data collaboration agreement.

[0063] In a preferred embodiment, evaluating the initiator and the participants and updating the corresponding federation node reputations further includes:

[0064] For the federated nodes that have completed the federated learning task, the federated node reputation is accumulated. The calculation formula of the federated node reputation is Among them, tj is the credit increment of the federated node that completes the federated learning task for the i-th time, Trust i It is the reputation of the federated node after the federated node completes the federated learning task for the i-th time.

[0065] In a preferred embodiment, after updating the corresponding federated node reputation and writing it into the federated ledger, the following steps are further included:

[0066] Calculate the penalty for failure to fulfill the data collaboration agreement based on the penalty function Penalty(ID, participant_ID) for the initiator or participant in the data collaboration agreement, where ID is the data collaboration agreement ID and participant_ID is the participant ID.

[0067] Penalties are imposed based on the calculated breach cost.

[0068] An embodiment of the present invention further provides a device for constraining the behavior of a demander and a participant, the device comprising:

[0069] The interaction module is used to receive data collaboration requests from the initiator federation node;

[0070] The monitoring module is used to monitor the implementation of the data collaboration agreement by the initiator and participants during the federated learning task after the initiator and participants reach a data collaboration agreement and start the federated learning task.

[0071] The evaluation module is used to evaluate the initiator and the participant if both have completed the federated learning task, update the corresponding federated node reputation, and write it into the federated ledger.

[0072] In a preferred embodiment, it also includes:

[0073] The federated node management module is used to manage the structure of federated nodes. The structure of federated nodes includes:

[0074] The ID of the federation node;

[0075] Federation node reputation;

[0076] The type label of the federated node, including the initiator, participant, and notary;

[0077] array of ledger entries;

[0078] The latest ledger entry, the largest known submitted ledger entry index;

[0079] The initiator, participants and notary are all federal nodes.

[0080] The initiator and participants execute the data collaboration agreement during the federated learning task. During this process, the initiator, participants, and notary all need to perform their respective functions. In a preferred embodiment, the federated node as the initiator executes:

[0081] Step A: Receive a message from a participant: If the message received is a data collaboration protocol ID from the participant, proceed to step B. If the message received is about risk exceeding the limit or insufficient federation node credibility, ignore it.

[0082] Step B: receiving the protocol ID and related information;

[0083] Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility of the initiator is greater than the threshold, send a message of agreement with the protocol ID to the participating parties; otherwise, send a message of disagreement with the protocol ID to the participating parties.

[0084] Step D: Send the agreement ID to the notary.

[0085] In a preferred embodiment, the federated node as a participant executes:

[0086] In the first step, if the message from the initiator is a data collaboration request message, the second step is executed; if the message is an agreement agreement ID from the initiator, the initiator is added to the waiting queue according to the urgency of the agreement and waits for service; if the message is a disagreement agreement ID, the agreement ID is cancelled;

[0087] The second step is to generate a data collaboration agreement ID;

[0088] The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If so, proceed to the fourth step. If not, send a "not enough credibility" message to refuse participation;

[0089] The fourth step is to calculate the feasibility of the participant's own agreement. If the participant's agreement feasibility is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

[0090] In a preferred embodiment, the monitoring module includes:

[0091] Monitoring unit, used to perform:

[0092] Step 1: Coordination of the federated learning process and notarization and arbitration of the data collaboration agreement. If a new protocol ID message is received from the initiator, step 2 will be executed; if a "Complete Protocol ID" message is received from the participating party, step 4 will be executed.

[0093] Step 2: Deposit the agreement with the specified agreement ID into the federated ledger;

[0094] Step 3: Start coordinating and monitoring this federated learning task and set the time.

[0095] Step 4: Monitor whether the initiator and participants have successfully completed the federated learning task, and record the completion time of the initiator and participants.

[0096] In a preferred embodiment, it also includes:

[0097] The protocol design module is used to design a data collaboration protocol that describes the collaborative relationship between the initiator and participants in a data collaboration process. The data collaboration protocol includes:

[0098] Agreement ID: data collaboration agreement number;

[0099] Initiator ID: the initiator's ID;

[0100] Participant ID: the participant's ID;

[0101] Initiator's reputation value: the initiator's current federation node reputation;

[0102] Participant reputation value: the participant's current federation node reputation;

[0103] Notary ID list: ID list of notary parties in the data collaboration agreement;

[0104] Data file summary: the ID and hash value of the file provided by the participant;

[0105] Agreed price and payment method: the data price and payment method agreed upon by the initiator and participants;

[0106] Breach of contract cost: the cost that the initiator or participant needs to pay for not complying with the agreement;

[0107] Agreement period: the effective time interval of the data collaboration agreement.

[0108] In a preferred embodiment, it also includes:

[0109] The feasibility design module is used to design the feasibility of the protocol based on the credibility of the federation nodes of the initiator and participants, the expected benefits, the default costs, the current task queue length, and the urgency of the task.

[0110] The feasibility of the agreement of the initiator B

[0111] Setting a threshold μ>0 limits the feasibility of the protocol. Only participants whose feasibility exceeds this threshold will be included in the list of candidate participants.

[0112] Data provider A is a participant, and the feasibility of the agreement

[0113] Where:

[0114] Tbase is the guaranteed value of the federation node's credibility, ensuring that new participants also have the opportunity to participate in the transaction;

[0115] Trust(ID, A) is the federation node reputation of participant A when the agreement is signed. For newly joined participants, t(ID, A) = 0;

[0116] Waiting(ID, B) is the length of the waiting queue of participant A when entering into the data collaboration agreement;

[0117] Urgency(ID, B) is the urgency of the initiator B to establish a data collaboration agreement. Urgency(ID, B)∈[0,1], where 1 represents the highest urgency.

[0118] Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task. Its relationship with the value of the demand document is Gain(ID) = k∑ f∈F Value(f);

[0119] Penalty(ID, A) is the penalty for breach of contract by Party A;

[0120] w1+w2+w3=1, and w1, w2, w3∈(0, 1). Requirement file: The data file provided by participants in federated learning. Because it is required by the initiator, it is called a "requirement file."

[0121] In a preferred embodiment, it also includes:

[0122] The federated node reputation module is used to calculate the federated node reputation increments of the initiator and participants by calling the corresponding protocol evaluation function after executing the data collaboration agreement; the protocol evaluation function is related to the federated node reputation, expected benefits, breach costs, and mutual evaluation results between the participating parties before signing the data collaboration agreement.

[0123] In a preferred embodiment, it also includes:

[0124] The protocol evaluation function module is used to implement the protocol evaluation function for participant A to calculate the incremental reputation of the federated node:

[0125] Trust(ID, A)=MAX(0, Trust(ID′, A)+p1×Eval(ID, B)×Gain(ID)-p2×Penalty(ID, A)):

[0126] Where Trust(ID′, A) is the reputation of the federated node before A’s transaction, and Eval(ID, B) is the evaluation of the initiator B on the performance of the data collaboration agreement by the participant A.

[0127] The protocol evaluation function used by initiator B to calculate the incremental reputation of the federated nodes is:

[0128] Trust(ID,B)=MAX(0,Trust(ID′,B)+q1×Eval(ID,A)-q2×Penalty(ID,B))

[0129] Where Trust(ID′, B) is the credibility of the federated node after the previous transaction of initiator B, and Eval(ID, A) is the evaluation of participant A on the performance of initiator B in the data collaboration agreement.

[0130] In a preferred embodiment, the evaluation module includes:

[0131] The federated node reputation accumulation unit is used to accumulate the federated node reputation of the federated node that has completed the federated learning task. The calculation formula of the federated node reputation is Among them, t j is the credit increment of the federated node that completes the federated learning task for the i-th time, Trust i is the reputation of the federated node after completing the federated learning task for the i-th time

[0132] In a preferred embodiment, it also includes:

[0133] The penalty module is used to calculate the penalty for failure to perform the data collaboration agreement according to the penalty function Penalty(ID, participant_ID) when the initiator or participant in the data collaboration agreement fails to perform the data collaboration agreement, where ID is the data collaboration agreement ID and participant_ID is the participant ID;

[0134] Penalties are imposed based on the calculated breach cost.

[0135] An embodiment of the present invention further provides a device for constraining the behavior of a demander and a participant, which is applied to a federated node and includes:

[0136] The initiator module is used to perform:

[0137] Step A: Receive a message from a participant: If the message received is a data collaboration protocol ID from the participant, proceed to step B. If the message received is about risk exceeding the limit or insufficient federation node credibility, ignore it.

[0138] Step B: receiving the protocol ID and related information;

[0139] Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility of the initiator is greater than the threshold, send a message of agreement with the protocol ID to the participating parties; otherwise, send a message of disagreement with the protocol ID to the participating parties.

[0140] Step D: Send the agreement ID to the notary.

[0141] An embodiment of the present invention further provides a device for constraining the behavior of a demander and a participant, which is applied to a federated node and includes:

[0142] Participant module, used to perform:

[0143] In the first step, if the message from the initiator is a data collaboration request message, the second step is executed; if the message is an agreement agreement ID from the initiator, the initiator is added to the waiting queue according to the urgency of the agreement and waits for service; if the message is a disagreement agreement ID, the agreement ID is cancelled;

[0144] The second step is to generate a data collaboration agreement ID;

[0145] The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If so, proceed to the fourth step. If not, send a "not enough credibility" message to refuse participation;

[0146] The fourth step is to calculate the feasibility of the participant's own agreement. If the participant's agreement feasibility is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

[0147] An embodiment of the present invention also provides a device for constraining the behavior of demanders and participants, including: a processor, a memory, and a program stored on the memory and runnable on the processor. When the program is executed by the processor, it implements the steps in the method of selecting a trusted third party as a coordinator for federated learning.

[0148] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the method for selecting a trusted third party as a coordinator for federated learning as described above.

[0149] The embodiments of the present invention have the following beneficial effects: a consortium blockchain with a defined access mechanism ensures the trustworthiness of the identities and roles of participants from different organizations within the blockchain network through an MSP-based member identification mechanism. Participants from different organizations are also isolated through defined channels. This, combined with the inherent decentralization, consensus mechanism, and immutability of blockchain technology, offers high security, social optimization (maximization of social metrics), robustness (independence from probability distribution knowledge), and collusion resistance (no participant can gain higher utility through fraudulent collusion). BRIEF DESCRIPTION OF THE DRAWINGS

[0150] Figure 1 A flowchart of a method for implementing shared incentives among data collaboration participants according to an embodiment of the present invention;

[0151] Figure 2 A schematic diagram of the system architecture of a federated learning technology using a hierarchical structure defined in an embodiment of the present invention;

[0152] Figure 3 This is a schematic diagram of the deployment architecture of the federated learning technology based on the alliance chain according to an embodiment of the present invention;

[0153] Figure 4 Schematic diagram of the process of signing a data collaboration agreement by the initiator of an embodiment of the present invention

[0154] Figure 5 A schematic diagram of the process for participants in an embodiment of the present invention to sign a data collaboration agreement;

[0155] Figure 6 Schematic diagram of the protocol evaluation process of the notary party in an embodiment of the present invention;

[0156] Figure 7 A schematic diagram of the interactive process for establishing and executing a collaborative agreement between parties involved in an embodiment of the present invention;

[0157] Figure 8 The present invention is a schematic diagram of a device structure for realizing shared incentives among data collaboration participants according to an embodiment of the present invention. DETAILED DESCRIPTION

[0158] In order to make the technical problems, technical solutions and advantages to be solved by the embodiments of the present invention clearer, they will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0159] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0160] The term "comprise" and any variations thereof in the specification and claims of this application are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to the process, method, product, or apparatus. In addition, the use of "and / or" in the specification and claims to indicate at least one of the connected objects, such as A and / or B, means that A alone, B alone, and both A and B are included.

[0161] In the embodiments of the present invention, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present invention should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0162] In federated learning, establishing an effective incentive mechanism to ensure sustained participation in the data federation is a key challenge. The goal is to maximize the sustainability of the federation while minimizing unfairness among participants and dynamically allocating a given budget to each participant in the data federation. Therefore, a reward system is needed to fairly and equitably share the profits generated by the federation among participants.

[0163] The negotiation mechanism in social and economic activities constrains the behavior of demanders and participants through the interest relationship and agreement between the supply and demand parties.

[0164] Therefore, the design principles of this application are: ① The demander, that is, the initiator, exchanges the consumption amount according to the contribution amount agreed in the agreement; ② Set up an agreement notary to be responsible for the evaluation of the implementation of the agreement and the third-party preservation of the agreement to reduce fraudulent behavior; ③ The participants calculate the feasibility of the agreement based on the value of the document, the reputation of the participants, the incremental income that the participants can obtain, etc. An agreement can be reached when the feasibility of the agreement between the two parties exceeds the threshold; ④ After reaching a collaborative agreement, the two parties can conduct transactions, but they must fulfill the commitments of the agreement as required before the end time of the agreement, otherwise they will be punished.

[0165] In this application, blockchain is used as an intermediary between data providers and data demanders, and a notary is added. The embodiment of the present invention provides a method for achieving shared incentives between data collaboration participants, such as Figure 1 As shown, the method includes:

[0166] Step 11: Receive a data collaboration request from the initiating federation node;

[0167] Step 12: After the initiator and participants reach a data collaboration agreement and initiate the federated learning task, the notary monitors the implementation of the data collaboration agreement by the initiator and participants during the federated learning task.

[0168] Step 13: If both the initiator and the participant have completed the federated learning task, the initiator and the participant are evaluated, the corresponding federated node reputation is updated, and the information is written into the federated ledger.

[0169] The technical solution provided in the application embodiment uses blockchain as an intermediary between data providers and data demanders on the basis of the original federated learning mechanism, and is used for the storage of evidence of agreements and transactions.

[0170] To help those skilled in the art understand the technical solutions provided in this application, Figure 2 As shown in the figure, based on the alliance chain as the carrier of data federation, the system architecture of federated learning technology is defined using a hierarchical structure:

[0171] The resource layer is used to carry data and device resources.

[0172] The entity layer hosts each organization (also called an organization member) in the data alliance. Each organization member in the data alliance can initiate a federated learning task. Organization members that participate in a federated learning task are participants, while those that do not participate are third parties. The data alliance includes multiple organizations, each of which forms a consortium chain.

[0173] The platform layer defines the core platform components of the system architecture, including the consortium chain platform and the federated learning platform. By adding a trusted third-party selection component to the consortium chain platform, a trusted third-party selection function is provided for federated learning.

[0174] The application layer defines applications provided to users and provides views corresponding to various functions based on different user roles.

[0175] It can be seen that Figure 3 As shown in the figure, a deployment architecture of a practical federated learning system based on a consortium chain is described. In the deployment architecture of the federated learning technology based on the consortium chain, there are N organizations in the data alliance, and N organizations form a consortium chain. According to the specific data collaboration situation, a series of channels are defined. Each channel corresponds to a data federation, and each organization can join multiple channels (data federation).

[0176] As shown in the figure, organizations 1, 2, and n all belong to data federation 1, while organizations 3 and n belong to data federation N. Nodes in the same data federation can participate in the same federated learning task.

[0177] In the technical solution provided in the embodiment of the present application, blockchain technology is integrated. On the basis of the original federated learning technology, blockchain is used as an intermediary between data providers and data demanders for the storage of evidence of agreements and transactions.

[0178] The federated ledger records all transactions between users, including changes in corresponding user reputation values.

[0179] Relevant business logic is implemented, compiled, and deployed in the form of smart contract code. Examples include the management of data supply and demand between users, the establishment, execution, and subsequent evaluation of collaborative agreements, the scheduling of federated learning tasks, and federated ledger operations.

[0180] The consensus mechanism is used to maintain data consistency for each node in the data federation.

[0181] To achieve this, a network architecture was designed to implement the corresponding technical solution. It consists of four layers: the data layer (shared file), the user layer (participant), the node layer (blockchain node), and the ledger layer (blockchain ledger). Participants in the user layer are data holders and are responsible for updating local models during the federated learning process. Blockchain nodes in the node layer provide secure aggregation of partial local models to participants in the user layer and receive the global model from the ledger layer. The ledger layer is responsible for storing data transactions between all users, receiving data uploaded by blockchain nodes, and aggregating the global model for federated learning.

[0182] It is also necessary to design a structure that describes the current state of the federated node and the various fields in the structure. In a preferred embodiment, the initiator, participants, and notary are all federated nodes; the structure of the federated node includes:

[0183] The ID of the federation node;

[0184] Federation node reputation;

[0185] The type label of the federated node, including the initiator, participant, and notary;

[0186] array of ledger entries;

[0187] The latest ledger entry, the highest known submitted ledger entry index value.

[0188] And, design data files:

[0189] Describes the data structure of shared data in the data federation and describes the basic information of the file from multiple dimensions, such as:

[0190] File ID: The number of the data file

[0191] File summary: A summary of the data file, including but not limited to file description, file type, file structure, field name, data type, data size, application status, etc.

[0192] File fingerprint: hash value of data file

[0193] File access path: the access path of the data file in the data federation

[0194] Data value: the calibrated or assessed value of data.

[0195] In a preferred embodiment, the initiator and the participant reach a data collaboration agreement including:

[0196] In step A, the initiator's federated node receives a message from a participant. If the message is a data collaboration protocol ID from the participant, it proceeds to step B. If the message is about risk exceeding the limit or insufficient federated node credibility, it is ignored.

[0197] Step B: receiving the protocol ID and related information;

[0198] Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility of the initiator is greater than the threshold, send a message of agreement with the protocol ID to the participating parties; otherwise, send a message of disagreement with the protocol ID to the participating parties.

[0199] Step D: Send the agreement ID to the notary.

[0200] In the corresponding application scenario, the algorithm for the initiator to sign the data collaboration agreement is implemented. Figure 4 As shown, the algorithm for signing a data collaboration agreement is as follows:

[0201] Step 41: Initiator B receives a message from participant A. If the message received is a protocol ID from the participant, proceed to step 42; otherwise, go to step 45.

[0202] Step 42: The initiator receives the protocol ID and related information from the participant.

[0203] Step 43: The initiator calculates the feasibility of its own protocol;

[0204] Step 44: If the initiator determines that the feasibility of the protocol is greater than the threshold, go to step 45; otherwise, go to step 47;

[0205] Step 45, sending a message of "agreeing to the agreement ID" to the participating parties;

[0206] Step 46: The initiator sends the agreement ID to the agreement notary, and the process ends.

[0207] Step 47: Send a message of "disagreeing with the agreement ID" to the participating party, and end.

[0208] In step 48, if the message received is "risk exceeds limit" or "creditworthiness is insufficient" from the participant, it is ignored.

[0209] In a preferred embodiment, the initiator and the participant reaching a data collaboration agreement further include:

[0210] In the first step, the federated node, as a participant, receives a message from the initiator. If the message is a data collaboration request message, the second step is executed. If the message is an agreement with the protocol ID from the initiator, the node is added to the waiting queue according to the urgency of the protocol and waits for service. If the message is a disagreement with the protocol ID, the protocol ID is canceled.

[0211] The second step is to generate a data collaboration agreement ID;

[0212] The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If so, proceed to the fourth step. If not, send a "not enough credibility" message to refuse participation;

[0213] The fourth step is to calculate the feasibility of the participant's own agreement. If the participant's agreement feasibility is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

[0214] In the corresponding application scenario, the algorithm for the participants to sign a data collaboration agreement is implemented. In the data collaboration process of the participants, such as Figure 5 As shown, the algorithm for signing a data collaboration agreement is as follows:

[0215] Step 51: The participant receives a message from the initiator. If the message received is a data collaboration request message, proceed to step 52; otherwise, go to step 59.

[0216] Step 52: The participant receives the request from the initiator and generates a data collaboration agreement ID.

[0217] Step 53: The participating parties verify whether the credibility of the initiator satisfies the basic conditions for signing the agreement. The basic condition is whether the initiator has the ability to pay the claimed agreed price. If the initiator satisfies the basic conditions, the process proceeds to step 54; if not, the process proceeds to step 58.

[0218] Step 54: If the initiator meets the basic conditions, the participants calculate their own protocol feasibility.

[0219] Step 55 , determine whether the protocol feasibility of the initiator is greater than a threshold. If so, go to step 56 ; otherwise, go to step 57 .

[0220] Step 56: Send the protocol ID to the initiator, and end.

[0221] Step 57: Send a "Risk Exceeded Limit" message to the initiator to refuse participation, and end.

[0222] Step 58: Send a "not enough credibility" message to refuse participation.

[0223] Step 59: If the message received is "Agree to the Agreement ID" from the initiator, the data collaboration agreement ID is canceled according to the weighting of the agreement urgency and added to the waiting queue to wait for service; if the message received is "Disagree to the Agreement ID" from the initiator, the data collaboration agreement ID is canceled.

[0224] In a preferred embodiment, monitoring the execution of the data collaboration protocol by the initiator and the participants during the federated learning task includes:

[0225] Step 1: As the notary party, the federated node coordinates the federated learning process and notarizes and arbitrates the data collaboration protocol. If a new protocol ID message is received from the initiator, step 2 will be executed; if a "Complete Protocol ID" message is received from a participant, step 4 will be executed.

[0226] Step 2: Deposit the agreement with the specified agreement ID into the federated ledger;

[0227] Step 3: Start coordinating and monitoring this federated learning task and set the time.

[0228] Step 4: Monitor whether the initiator and participants have successfully completed the federated learning task, and record the completion time of the initiator and participants.

[0229] In the corresponding application scenarios, such as Figure 6 As shown, the notary's agreement evaluation process is as follows:

[0230] Step 61: The notary selected by the data federation receives messages from all participating parties.

[0231] Step 62: Determine the specific source and content of the message. If the received message is a "New Agreement ID" message sent by initiator B, proceed to step 63. If the received message is a "Complete Agreement ID" message sent by participant A / initiator B, proceed to steps 65 and 66.

[0232] Step 63: The notary will store the agreement with the designated ID into the federated ledger.

[0233] In step 64, the notary begins coordinating and monitoring the federated learning task, and then counts and ends.

[0234] In step 65, the "Complete Protocol ID" message sent by participant A is received. The system monitors whether all participants have successfully completed the federated learning task and records the completion time of participant A. Then, the system goes to step 67.

[0235] In step 66, the "Complete Protocol ID" message sent by initiator B is received. The system monitors whether all participants have successfully completed the federated learning task and records the completion time of participant B. Then, the system goes to step 67.

[0236] In step 68, the notary conducts agreement evaluation.

[0237] In order to describe the collaborative relationship between the initiator and the participants in a data collaboration process, a data collaboration protocol needs to be designed. In a preferred embodiment, before receiving a data collaboration request from the initiator's federated node, the method further includes:

[0238] A data collaboration protocol is designed to describe the collaborative relationship between the initiator and participants in a data collaboration process. The data collaboration protocol includes:

[0239] Agreement ID: data collaboration agreement number;

[0240] Initiator ID: the initiator's ID;

[0241] Participant ID: the participant's ID;

[0242] Initiator's reputation value: the initiator's current federation node reputation;

[0243] Participant reputation value: the participant's current federation node reputation;

[0244] Notary ID list: ID list of notary parties in the data collaboration agreement;

[0245] Data file summary: the ID and hash value of the file provided by the participant;

[0246] Agreed price and payment method: the data price and payment method agreed upon by the initiator and participants;

[0247] Breach of Contract Cost: The cost that the initiator or participant needs to pay for not complying with the agreement, including but not limited to monetary amount, reputation value, etc.

[0248] Agreement period: the effective time interval of the data collaboration agreement.

[0249] The estimation of the possibility of achieving the agreement by both parties based on their own interests is related to the reputation value, expected benefits, breach costs of the data provider, as well as the current task queue length, the urgency of the task, etc. In a preferred embodiment, before receiving the data collaboration request from the federated node as the initiator, the method further includes: designing the feasibility of the agreement based on the reputation value, expected benefits, breach costs of the federated nodes of the initiator and the participants, as well as the current task queue length and the urgency of the task, wherein

[0250] The feasibility of the agreement of the initiator B

[0251] Setting a threshold μ>0 limits the feasibility of the protocol. Only participants whose feasibility exceeds this threshold will be included in the list of candidate participants.

[0252] Data provider A is a participant, and the feasibility of the agreement

[0253] Where:

[0254] Tbase is the guaranteed value of the federation node's credibility, ensuring that new participants also have the opportunity to participate in the transaction;

[0255] Trust(ID, A) is the federation node reputation of participant A when the agreement is signed. For newly joined participants, t(ID, A) = 0;

[0256] Waiting(ID, B) is the length of the waiting queue of participant A when entering into the data collaboration agreement;

[0257] Urgency(ID, B) is the urgency of the initiator B to establish a data collaboration agreement. Urgency(ID, B)∈[0,1], where 1 represents the highest urgency.

[0258] Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task. Its relationship with the value of the demand document is Gain(ID) = k∑ f∈F Value(f);

[0259] Penalty(ID, A) is the penalty for breach of contract by Party A;

[0260] w1+w2+w3=1, and w1, w2, w3∈(0, 1). Requirement file: The data file provided by participants in federated learning. Because it is required by the initiator, it is called a "requirement file."

[0261] As can be seen, federated learning initiator B has the right to decide which data providers' data to use. The protocol feasibility described above provides a basis for decision-making for federated learning initiators (strong data demanders). A threshold μ > 0 can be set to limit the protocol feasibility. Only parties with a protocol feasibility exceeding this threshold are included in the list of candidate participants.

[0262] Afterwards, the system can set up automatic or manual transaction execution. In automatic transactions, the system's smart contract automatically selects participants based on their agreement feasibility and signs a data collaboration agreement. In manual transactions, the initiator manually selects participants based on a combination of factors, including candidate parties screened by the smart contract (based on agreement feasibility).

[0263] Agreement evaluation is a process for determining how effectively both parties have fulfilled their agreement. After the agreement is executed, the reputation of each party is adjusted using the agreement evaluation function. This evaluation function is based on factors such as pre-agreement reputation, expected returns, breach costs, and mutual evaluations between the parties. In a preferred embodiment, evaluating the initiator and participants and updating the corresponding federated node reputations includes:

[0264] After executing the data collaboration agreement, the corresponding protocol evaluation function is called to calculate the incremental credibility of the federated nodes of the initiator and the participants; the protocol evaluation function is related to the credibility of the federated nodes, expected benefits, breach costs, and mutual evaluation results between the participating parties before signing the data collaboration agreement.

[0265] For example, the data provider (participant) A in the protocol can be evaluated by the following function to calculate the reputation increment. In a preferred embodiment, the protocol evaluation function for participant A to calculate the federated node reputation increment is:

[0266] Trust(ID, A)=MAX(0, Trust(ID′, A)+p1×Eval(ID, B)×Gain(ID)-p2×Penalty(ID, A)):

[0267] Where Trust(ID′, A) is the reputation of the federated node before A’s transaction, and Eval(ID, B) is the evaluation of the initiator B on the performance of the data collaboration agreement by the participant A.

[0268] The protocol evaluation function used by initiator B to calculate the incremental reputation of the federated nodes is:

[0269] Trust(ID,B)=MAX(0,Trust(ID′,B)+q1×Eval(ID,A)-q2×Penalty(ID,B))

[0270] Where Trust(ID′, B) is the credibility of the federated node after the previous transaction of initiator B, and Eval(ID, A) is the evaluation of participant A on the performance of initiator B in the data collaboration agreement.

[0271] In a preferred embodiment, evaluating the initiator and the participants and updating the corresponding federation node reputations further includes:

[0272] For the federated nodes that have completed the federated learning task, the federated node reputation is accumulated. The calculation formula of the federated node reputation is Among them, t j is the credit increment of the federated node that completes the federated learning task for the i-th time, Trust iis the credibility of the federated node after completing the federated learning task for the i-th time.

[0273] After reaching a collaborative agreement, both parties can conduct transactions, but must fulfill the commitments in the agreement as required before the end of the agreement, otherwise they will be punished. In a preferred embodiment, after updating the corresponding federated node reputation and writing it into the federated ledger, it also includes:

[0274] Calculate the penalty for failure to fulfill the data collaboration agreement based on the penalty function Penalty(ID, participant_ID) for the initiator or participant in the data collaboration agreement, where ID is the data collaboration agreement ID and participant_ID is the participant ID.

[0275] Penalties are imposed based on the calculated breach cost.

[0276] And, design breach costs:

[0277] Define the penalty for failure to fulfill the contract by one party in the data collaboration agreement. For example, it can be described as:

[0278] Penalty(ID, participant_ID)

[0279] ID: Data collaboration agreement ID

[0280] participant_ID: participant ID

[0281] Also, design the protocol notary: that is, the trusted third party of federated learning, responsible for coordinating the federated learning process and notarizing and arbitrating the data collaboration agreement.

[0282] In an application scenario, using the technical means provided in the above embodiment, in a typical collaborative protocol interaction process, for a typical federated learning task, such as Figure 7 As shown in Figure 1, the interactive process for relevant parties to establish and execute a collaborative agreement includes:

[0283] Step 71: The federated learning initiator submits a data collaboration request to the data federation;

[0284] Step 72: Call the smart contract to filter out a list of candidate participants;

[0285] Step 73: Generate a data collaboration agreement for each candidate party in the candidate participant list;

[0286] Step 74, calculate the feasibility of the protocols in the candidate list, then use the threshold to judge, update the list and sort;

[0287] Step 75: Select the final participant based on the feasibility ranking. The initiator can choose automatic or manual transaction:

[0288] During automatic transactions, the system smart contract determines and selects the final party.

[0289] When a transaction is done manually, the initiator will sort the transactions based on feasibility and manually select the final participants based on a variety of factors.

[0290] Step 76: Call the smart contract to sign the data collaboration agreement and write it into the federated ledger;

[0291] Step 77: The parties that have reached an agreement initiate the federated learning task and execute the agreement. When there are three or more parties, the initiator signs a collaboration agreement with each party.

[0292] In step 78, the protocol notary evaluates the protocol execution, updates the node reputation, and writes it into the federated ledger. The notary is a trusted third party in federated learning and is selected through a certain mechanism.

[0293] The federated ledger in data federation is the blockchain ledger, which adopts a distributed storage structure to store transactions and agreements between all users, including changes in corresponding user reputation values.

[0294] The embodiment of the present invention also provides a device for constraining the behavior of the demander and the participant, such as Figure 8 As shown, the device includes:

[0295] An interaction module 81 is configured to receive a data collaboration request from a federated node serving as an initiator;

[0296] Monitoring module 82, which is used to monitor the execution of the data collaboration agreement by the initiator and the participants during the federated learning task after the initiator and the participants reach a data collaboration agreement and initiate the federated learning task;

[0297] The evaluation module 83 is used to evaluate the initiator and the participant if both have completed the federated learning task, update the corresponding federated node reputation, and write it into the federated ledger.

[0298] In a preferred embodiment, it also includes:

[0299] The federated node management module is used to manage the structure of federated nodes. The structure of federated nodes includes:

[0300] The ID of the federation node;

[0301] Federation node reputation;

[0302] The type label of the federated node, including the initiator, participant, and notary;

[0303] array of ledger entries;

[0304] The latest ledger entry, the largest known submitted ledger entry index;

[0305] The initiator, participants and notary are all federal nodes.

[0306] The initiator and participants execute the data collaboration agreement during the federated learning task. During this process, the initiator, participants, and notary all need to perform their respective functions. In a preferred embodiment, the federated node as the initiator executes:

[0307] Step A: Receive a message from a participant: If the message received is a data collaboration protocol ID from the participant, proceed to step B. If the message received is about risk exceeding the limit or insufficient federation node credibility, ignore it.

[0308] Step B: receiving the protocol ID and related information;

[0309] Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility of the initiator is greater than the threshold, send a message of agreement with the protocol ID to the participating parties; otherwise, send a message of disagreement with the protocol ID to the participating parties.

[0310] Step D: Send the agreement ID to the notary.

[0311] In a preferred embodiment, the federated node as a participant executes:

[0312] In the first step, if the message from the initiator is a data collaboration request message, the second step is executed; if the message is an agreement agreement ID from the initiator, the initiator is added to the waiting queue according to the urgency of the agreement and waits for service; if the message is a disagreement agreement ID, the agreement ID is cancelled;

[0313] The second step is to generate a data collaboration agreement ID;

[0314] The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If so, proceed to the fourth step. If not, send a "not enough credibility" message to refuse participation;

[0315] The fourth step is to calculate the feasibility of the participant's own agreement. If the participant's agreement feasibility is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

[0316] In a preferred embodiment, the monitoring module 82 includes:

[0317] Monitoring unit, used to perform:

[0318] Step 1: Coordination of the federated learning process and notarization and arbitration of the data collaboration agreement. If a new protocol ID message is received from the initiator, step 2 will be executed; if a "Complete Protocol ID" message is received from the participating party, step 4 will be executed.

[0319] Step 2: Deposit the agreement with the specified agreement ID into the federated ledger;

[0320] Step 3: Start coordinating and monitoring this federated learning task and set the time.

[0321] Step 4: Monitor whether the initiator and participants have successfully completed the federated learning task, and record the completion time of the initiator and participants.

[0322] In a preferred embodiment, it also includes:

[0323] The protocol design module is used to design a data collaboration protocol that describes the collaborative relationship between the initiator and participants in a data collaboration process. The data collaboration protocol includes:

[0324] Agreement ID: data collaboration agreement number;

[0325] Initiator ID: the initiator's ID;

[0326] Participant ID: the participant's ID;

[0327] Initiator's reputation value: the initiator's current federation node reputation;

[0328] Participant reputation value: the participant's current federation node reputation;

[0329] Notary ID list: ID list of notary parties in the data collaboration agreement;

[0330] Data file summary: the ID and hash value of the file provided by the participant;

[0331] Agreed price and payment method: the data price and payment method agreed upon by the initiator and participants;

[0332] Breach of contract cost: the cost that the initiator or participant needs to pay for not complying with the agreement;

[0333] Agreement period: the effective time interval of the data collaboration agreement.

[0334] In a preferred embodiment, it also includes:

[0335] The feasibility design module is used to design the feasibility of the protocol based on the credibility of the federation nodes of the initiator and participants, the expected benefits, the default costs, the current task queue length, and the urgency of the task.

[0336] The feasibility of the agreement of the initiator B

[0337] Setting a threshold μ>0 limits the feasibility of the protocol. Only participants whose feasibility exceeds this threshold will be included in the list of candidate participants.

[0338] Data provider A is a participant, and the feasibility of the agreement

[0339] Where:

[0340] Tbase is the guaranteed value of the federation node's credibility, ensuring that new participants also have the opportunity to participate in the transaction;

[0341] Trust(ID, A) is the federation node reputation of participant A when the agreement is signed. For newly joined participants, t(ID, A) = 0;

[0342] Waiting(ID, B) is the length of the waiting queue of participant A when entering into the data collaboration agreement;

[0343] Urgency(ID, B) is the urgency of the initiator B to establish a data collaboration agreement. Urgency(ID, B)∈[0,1], where 1 represents the highest urgency.

[0344] Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task. Its relationship with the value of the demand document is Gain(ID) = k∑ f∈F Value(f);

[0345] Penalty(ID, A) is the penalty for breach of contract by Party A;

[0346] w1+w2+w3=1, and w1, w2, w3∈(0, 1). Requirement file: The data file provided by participants in federated learning. Because it is required by the initiator, it is called a "requirement file."

[0347] In a preferred embodiment, it also includes:

[0348] The federated node reputation module is used to calculate the federated node reputation increments of the initiator and participants by calling the corresponding protocol evaluation function after executing the data collaboration agreement; the protocol evaluation function is related to the federated node reputation, expected benefits, breach costs, and mutual evaluation results between the participating parties before signing the data collaboration agreement.

[0349] In a preferred embodiment, it also includes:

[0350] The protocol evaluation function module is used to implement the protocol evaluation function for participant A to calculate the incremental reputation of the federated node:

[0351] Trust(ID,A)=MAX(0,Trust(ID′,A)+p1×Eval(ID,B)×Gain(ID)-p2×Penalty(ID,A)):

[0352] Where Trust(ID′, A) is the reputation of the federated node before A’s transaction, and Eval(ID, B) is the evaluation of the initiator B on the performance of the data collaboration agreement by the participant A.

[0353] The protocol evaluation function used by initiator B to calculate the incremental reputation of the federated nodes is:

[0354] Trust(ID,B)=MAX(0,Trust(ID′,B)+q1×Eval(ID,A)-q2×Penalty(ID,B))

[0355] Where Trust(ID′, B) is the credibility of the federated node after the previous transaction of initiator B, and Eval(ID, A) is the evaluation of participant A on the performance of initiator B in the data collaboration agreement.

[0356] In a preferred embodiment, the evaluation module 83 includes:

[0357] The federated node reputation accumulation unit is used to accumulate the federated node reputation of the federated node that has completed the federated learning task. The calculation formula of the federated node reputation is Among them, t j is the credit increment of the federated node that completes the federated learning task for the i-th time, Trust i is the reputation of the federated node after completing the federated learning task for the i-th time

[0358] In a preferred embodiment, it also includes:

[0359] The penalty module is used to calculate the penalty for failure to perform the data collaboration agreement according to the penalty function Penalty(ID, participant_ID) when the initiator or participant in the data collaboration agreement fails to perform the data collaboration agreement, where ID is the data collaboration agreement ID and participant_ID is the participant ID;

[0360] Penalties are imposed based on the calculated breach cost.

[0361] An embodiment of the present invention further provides a device for constraining the behavior of a demander and a participant, which is applied to a federated node and includes:

[0362] The initiator module is used to perform:

[0363] Step A: Receive a message from a participant: If the message received is a data collaboration protocol ID from the participant, proceed to step B. If the message received is about risk exceeding the limit or insufficient federation node credibility, ignore it.

[0364] Step B: receiving the protocol ID and related information;

[0365] Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility of the initiator is greater than the threshold, send a message of agreement with the protocol ID to the participating parties; otherwise, send a message of disagreement with the protocol ID to the participating parties.

[0366] Step D: Send the agreement ID to the notary.

[0367] An embodiment of the present invention further provides a device for constraining the behavior of a demander and a participant, which is applied to a federated node and includes:

[0368] Participant module, used to perform:

[0369] In the first step, if the message from the initiator is a data collaboration request message, the second step is executed; if the message is an agreement agreement ID from the initiator, the initiator is added to the waiting queue according to the urgency of the agreement and waits for service; if the message is a disagreement agreement ID, the agreement ID is cancelled;

[0370] The second step is to generate a data collaboration agreement ID;

[0371] The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If so, proceed to the fourth step. If not, send a "not enough credibility" message to refuse participation;

[0372] The fourth step is to calculate the feasibility of the participant's own agreement. If the participant's agreement feasibility is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

[0373] An embodiment of the present invention also provides a device for constraining the behavior of demanders and participants, including: a processor, a memory, and a program stored on the memory and executable on the processor. When the program is executed by the processor, it implements the steps in the method of selecting a trusted third party as a coordinator for federated learning.

[0374] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the method for selecting a trusted third party as a coordinator for federated learning as described above.

[0375] The technical solution provided in the application embodiment ensures the trustworthiness of the identities and roles of participants from different organizations in the blockchain network through a member identity identification mechanism based on the certificate management of alliance chain members (MSP, Membership Service Provider). Participants from different organizations are isolated by defining channels. This, combined with the inherent decentralization, consensus mechanism, and tamper-proof technical advantages of blockchain, offers high security, social optimization (maximization of social indicators), robustness (independence from probability distribution knowledge), and collusion resistance (no participant can obtain higher utility through collusion and fraud). MSP is a foundational technical mechanism of consortium blockchains. Membership Service Providers (MSPs) are used to determine which certificate authorities (CAs) are trusted, list organizational memberships, identify the specific roles participants play within the organization, and define network and channel access permissions.

[0376] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage terminal devices to be detected, or any other non-transmission media that can be used to store information that can be accessed by the computer terminal devices to be detected. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0377] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for constraining the behavior of demanders and participants, characterized in that: The method comprises: Receiving a data coordination request from the initiator federation node; After the initiator and the participants reach a data collaboration agreement and start the federated learning task, the notary monitors the execution of the data collaboration agreement by the initiator and the participants during the federated learning task; If both the initiator and the participant have completed the federated learning task, the initiator and the participant will be evaluated, the corresponding federated node reputation will be updated, and the information will be written into the federated ledger; The data collaboration agreement reached between the initiator and the participants includes: Step A: The federation node as the initiator receives a message from a participant: if the message is a data collaboration protocol ID sent by the participant, then step B is executed; if the risk exceeds the limit or the federation node’s credibility is insufficient, then it is ignored; Step B, receiving the data collaboration agreement ID and related information; Step C, calculating the protocol feasibility of the initiator, and if the protocol feasibility is greater than a threshold, sending a message of agreeing to the protocol ID to the participating party; otherwise, sending a message of disagreeing to the protocol ID to the participating party; Step D, sending the data collaboration agreement ID to the notary; The method also includes: designing the feasibility of the protocol based on the reputation of the federation nodes of the initiator and the participants, the expected benefits, the default costs, the current task queue length, and the urgency of the task, wherein The feasibility of the protocol of the initiator B The threshold μ>0 is set to limit the feasibility of the protocol. Participants whose feasibility exceeds the threshold will be included in the list of candidate participants. Data provider A is a participant, and the feasibility of the agreement Where: Tbase is the guaranteed value of the federation node’s reputation, which ensures that new participants have the opportunity to participate; Trust(ID, A) is the federation node reputation of participant A when signing the data collaboration agreement. Trust(ID, A) of the newly joined participant = 0; Waiting(A) is the length of the current waiting queue of Party A when entering into the data collaboration agreement; Urgency(ID,B) is the urgency of the initiator B to conclude the data collaboration agreement. Urgency(ID,B)∈[0,1], where 1 represents the highest urgency. Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task; Penalty(ID,A) is the default cost of Party A; w1+w2+w3=1, and w1,w2,w3∈(0,1).

2. The method according to claim 1, characterized in that The initiator, participants and notary are all federation nodes; the structure of the federation node includes: The ID of the federation node; Federation node reputation; The type label of the federation node, including the initiator, participant, and notary; array of ledger entries; The latest ledger entry, the largest known committed ledger entry index value.

3. The method according to claim 1, characterized in that The data collaboration agreement reached between the initiator and the participants also includes: In the first step, the federated node as a participant receives a message from the initiator. If the message is a data collaboration request, the second step is executed; if the message is an agreement protocol ID from the initiator, it is added to the waiting queue according to the protocol urgency and waits for service; if the message is a disagreement protocol ID, the data collaboration protocol ID is cancelled; The second step is to generate a data collaboration agreement ID; The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If it does, proceed to the fourth step. If it does not, send a "not enough credibility" message to the initiator to refuse participation. The fourth step is to calculate the feasibility of the participant's own agreement. If the feasibility of the agreement is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds limit" message is sent to refuse participation.

4. The method according to claim 1, characterized in that: Monitoring of the execution of data collaboration agreements by the initiator and participants during the federated learning task includes: As a notary party, the federated node coordinates and monitors federated learning tasks and notarizes and arbitrates data collaboration protocols. If a new protocol ID message is received from the initiator, step 2 is executed; if a "Complete Protocol ID" message is received from a participant, step 4 is executed; Step 2: Store the protocol with the corresponding protocol ID into the federated ledger; Step 3: Start coordinating and monitoring this federated learning task and set the time. Step 4: Monitor whether the initiator and participants have successfully completed the federated learning task, and record the completion time of the initiator and participants.

5. The method according to claim 1, characterized in that: The method also includes: Design a data collaboration protocol to describe the collaborative relationship between the initiator and participants in the federated learning task. The data collaboration protocol includes: Agreement ID: data collaboration agreement number; Initiator ID: the number of the initiator; Participant ID: the number of the participant; Initiator reputation value: the initiator's current federation node reputation; Participant reputation value: the participant's current federation node reputation; Notarization party ID list: ID list of notarization parties of data collaboration agreement; Data file summary: ID and hash value of the file provided by the participant; Agreed price and payment method: the data price and payment method agreed upon by the initiator and participants; Breach of contract cost: the cost that the initiator or participant needs to pay for not complying with the data collaboration agreement; Protocol period: the effective time interval of the data collaboration protocol.

6. The method according to claim 1, characterized in that Evaluate the initiator and participants, and update the corresponding federation node reputation including: After executing the data collaboration agreement, the incremental reputation of the federated nodes of the initiator and the participants is calculated by calling the corresponding protocol evaluation function; the protocol evaluation function is related to the federated node reputation, expected benefits, default costs, and mutual evaluation results between the initiator and the participants before signing the data collaboration agreement.

7. The method according to claim 6, characterized in that The protocol evaluation function used by participant A to calculate the incremental reputation of the federated node is: Trust(ID,A)=MAX(0,Trust(ID ′ ,A)+p1×Eval(ID,B)×Gain(ID)-p2× Penalty(ID,A)), Trust(ID ′ ,A) is the reputation of the federated node of participant A before the transaction, and Eval(ID,B) is the evaluation of the initiator B on the performance of the data collaboration agreement by participant A; The protocol evaluation function used by initiator B to calculate the incremental reputation of the federated node is: Trust(ID,B)= MAX(0,Trust(ID ′ ,B)+q1×Eval(ID,A)-q2×Penalty(ID,B)),Trust(ID ′ ,B) is the reputation of the federated node after the previous transaction of the initiator B, Eval(ID,A) is the evaluation of the participant A on the performance of the data collaboration agreement by the initiator B, and p1, p2, q1, and q2 are coefficients.

8. The method according to claim 7, characterized in that Evaluate the initiator and participants, and update the corresponding federation node reputation, including: For the federated nodes that have completed the federated learning task, the federated node reputation is accumulated. The calculation formula of the federated node reputation is Among them, t j is the credit increment of the federated node that completes the federated learning task for the jth time, Trust i It is the reputation of the federated node after the federated node completes the federated learning task for the i-th time.

9. The method according to claim 6, characterized in that After updating the corresponding federated node reputation and writing it into the federated ledger, it also includes: Calculate the penalty for failure to perform the data collaboration agreement according to the penalty function Penalty(ID, participant_ID) of the initiator or participant in the data collaboration agreement, where ID is the data collaboration agreement ID and participant_ID is the participant ID; Penalties are imposed based on the calculated breach cost.

10. A device for implementing the method for constraining the behavior of a demander and a participant as claimed in claim 1, characterized in that: The device includes: An interaction module, used to receive a data collaboration request from a federation node as an initiator; A monitoring module is used for monitoring the execution of the data collaboration agreement by the initiator and the participants during the federated learning task by the notary after the initiator and the participants reach a data collaboration agreement and start the federated learning task; The evaluation module is used to evaluate the initiator and the participant if they have completed the federated learning task, update the corresponding federated node reputation, and write it into the federated ledger.

11. A device for implementing the method for constraining the behavior of a demander and a participant as claimed in claim 1, applied to a federation node, the device comprising: The initiator module is used to perform: Step A, receiving a message from a participant: If the message received is a data collaboration protocol ID from a participant, then proceed to step B; if the message received is that the risk exceeds the limit or the federation node’s credibility is insufficient, then ignore it; Step B, receiving the protocol ID and related information; Step C: Calculate the protocol feasibility of the initiator. If the protocol feasibility of the initiator is greater than the threshold, send a message to the participants to agree to the protocol ID; otherwise, send a message to the participants to disagree with the protocol ID. Step D, sending the agreement ID to the notary; The feasibility of the protocol is determined by the following methods: The feasibility of the protocol is designed based on the reputation of the federation nodes of the initiator and the participants, the expected benefits, the default costs, the current task queue length, and the urgency of the task. The feasibility of the protocol of the initiator B The threshold μ>0 is set to limit the feasibility of the protocol. Participants whose feasibility exceeds the threshold will be included in the list of candidate participants. Data provider A is a participant, and the feasibility of the agreement Where: Tbase is the guaranteed value of the federation node’s reputation, which ensures that new participants have the opportunity to participate; Trust(ID, A) is the federation node reputation of participant A when signing the data collaboration agreement. Trust(ID, A) of the newly joined participant = 0; Waiting(A) is the length of the current waiting queue of Party A when entering into the data collaboration agreement; Urgency(ID,B) is the urgency of the initiator B to conclude the data collaboration agreement. Urgency(ID,B)∈[0,1], where 1 represents the highest urgency. Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task; Penalty(ID,A) is the default cost of Party A; w1+w2+w3=1, and w1,w2,w3∈(0,1).

12. A device for implementing the method for constraining the behavior of a demander and a participant as claimed in claim 1, applied to a federation node, the device comprising: Participant module, used to perform: In the first step, a message is received from the initiator. If the message is a data collaboration request message, the second step is executed. If the message is from the initiator's agreement agreement ID, it will be added to the waiting queue according to the agreement urgency and wait for service; If the message is that the protocol ID is not agreed to, the protocol ID is cancelled; The second step is to generate a data collaboration agreement ID; The third step is to verify whether the credibility of the initiator's federation node meets the basic conditions for signing the agreement. If it does, go to the fourth step. If it does not, send a "not enough credibility" message to refuse participation. The fourth step is to calculate the feasibility of the agreement of the participant. If the feasibility of the agreement of the participant is greater than the threshold, the data collaboration agreement ID is sent to the initiator; otherwise, a "risk exceeds the limit" message is sent to refuse participation; The feasibility of the protocol is determined by the following methods: The feasibility of the protocol is designed based on the reputation of the federation nodes of the initiator and the participants, the expected benefits, the default costs, the current task queue length, and the urgency of the task. The feasibility of the protocol of the initiator B The threshold μ>0 is set to limit the feasibility of the protocol. Participants whose feasibility exceeds the threshold will be included in the list of candidate participants. Data provider A is a participant, and the feasibility of the agreement Where: Tbase is the guaranteed value of the federation node’s reputation, which ensures that new participants have the opportunity to participate; Trust(ID, A) is the federation node reputation of participant A when signing the data collaboration agreement. Trust(ID, A) of the newly joined participant = 0; Waiting(A) is the length of the current waiting queue of Party A when entering into the data collaboration agreement; Urgency(ID,B) is the urgency of the initiator B to conclude the data collaboration agreement. Urgency(ID,B)∈[0,1], where 1 represents the highest urgency. Gain(ID) is the maximum incremental benefit that participant A can obtain after completing the federated learning task; Penalty(ID,A) is the default cost of Party A; w1+w2+w3=1, and w1,w2,w3∈(0,1).

13. A device for constraining the behavior of demanders and participants, characterized in that: include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, the steps of the method according to any one of claims 1 to 9 are implemented.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps in the method for constraining the behavior of the demander and the participant as described in any one of claims 1 to 9 are implemented.

Images