Data hosting person selection method, device, equipment and storage medium

Abstract

The application discloses a data hosting person selection method and device, equipment and a storage medium, relates to the technical field of data security, and comprises the following steps: acquiring a first hosting person candidate list of a plurality of data providers, and acquiring a second hosting person candidate list of a data user; determining a Nash equilibrium solution result corresponding to each first hosting person candidate list through a Nash equilibrium optimization strategy, and obtaining a third hosting person candidate list; and performing intersection hash value calculation on the second hosting person candidate list and the third hosting person candidate list, and determining a target data hosting person. The application can avoid single-party leading hosting person selection, further balance the strategy conflicts between the providers through the Nash equilibrium optimization strategy, improve the fairness of hosting person selection, automatically verify the consensus of both parties through intersection hash value matching, and improve the safety, efficiency and credibility of data sharing without manually comparing the hosting person qualifications one by one.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a method, apparatus, device and storage medium for selecting a data custodian. Background Technology

[0002] In the wave of digitalization, the strategic value of data is becoming increasingly prominent. Data sharing has become a key support for improving forecast accuracy, optimizing business processes, and fostering innovative business models. Especially in scenarios involving sensitive data such as personal information and trade secrets, data sharing needs to ensure security and compliance while breaking down trust barriers between participants. This has led to the emergence of data custodians as independent and neutral intermediaries. By regulating data access permissions and reviewing compliance, they can effectively reduce the risk of data misuse and legal compliance costs, becoming an important trust hub in the data sharing process.

[0003] Currently, traditional data sharing solutions mainly rely on centralized platforms or static contracts to achieve collaboration related to data custodians. Whitelisting technology is mostly based on predefined rules to fix the scope of trusted participants, and the selection process of data custodians requires manual verification of qualifications, lacking automated and dynamic collaboration mechanisms. In this model, the trust anchor of data sharing is concentrated on a single third-party institution, and the whitelist cannot be flexibly adjusted according to the actual collaboration situation, requiring manual intervention for negotiation and qualification verification throughout the process. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, device and storage medium for selecting data custodians, aiming to solve the problems of difficulty in selecting data custodians and low efficiency of manual selection in the prior art, and to improve the security, efficiency and reliability of data sharing in the data space.

[0005] To achieve the above objectives, this application proposes a method for selecting a data custodian, the method comprising: Obtain a first custodian candidate list from multiple data providers, and a second custodian candidate list from data users; By using the Nash equilibrium optimization strategy, the Nash equilibrium solution results corresponding to each of the first custodian candidate lists are determined, and the third custodian candidate list is obtained. The target data custodian is determined by calculating the intersection hash value between the second custodian candidate list and the third custodian candidate list.

[0006] In one possible implementation, obtaining a first custodian candidate list of multiple data providers and a second custodian candidate list of data users includes: Obtain the initial custodian candidate list submitted by each data provider, and determine the verifiable credentials corresponding to each provider candidate custodian in the initial custodian candidate list; By integrating a connector for lightweight blockchain nodes, the verifiable credentials are uploaded to the blockchain network, and the validity of the verifiable credentials is verified by calling the business database, filtering out candidate custodians whose verifiable credentials are invalid. Based on the historical interaction records of each provider candidate custodian after the filtering credentials are invalidated, a dynamic reputation score is calculated for each candidate custodian through a preset attenuation model, and the provider candidate custodian whose dynamic reputation score meets the preset reputation threshold is retained to form a first custodian candidate list corresponding to each data provider. Obtain the business requirement parameters submitted by the data user, and filter the user candidate custodians according to the business requirement parameters to form the second custodian candidate list. The business requirement parameters include data processing protocol type, data transmission timeliness requirements, and historical collaboration preferences.

[0007] In one possible implementation, the step of determining the Nash equilibrium solution result corresponding to each of the first custodian candidate lists through a Nash equilibrium optimization strategy to obtain the third custodian candidate list includes: Determine the intersection and similarity of the first custodian candidate lists corresponding to each data provider. If the intersection of the lists is empty or the similarity of the lists is lower than a preset threshold, it is determined that there is a strategy conflict. For any data provider, the data provider is regarded as the game player and the first custodian candidate list corresponding to the data provider is regarded as the player's strategy, and a game strategy space is constructed. Calculate the strategy matching degree between each player's strategy and the preset global benchmark strategy, and calculate the comprehensive weight and payoff of each player to construct a payoff matrix; The Nash equilibrium solution is obtained from the aforementioned payoff matrix to form the candidate list of the third custodian.

[0008] In one possible implementation, the step of solving the Nash equilibrium of the payoff matrix to form the candidate list of third custodians includes: If a pure strategy equilibrium exists in the Nash equilibrium solution, then the line-drawing method is used to screen out the strategy combinations in which all players have no incentive to deviate, forming the candidate list of the third custodian. If no pure strategy equilibrium exists in the Nash equilibrium solution, then a linear programming method is used to solve for the mixed strategy equilibrium, forming the third custodian candidate list; If multiple equilibrium results exist in the Nash equilibrium solution, the optimal equilibrium among the multiple equilibrium results is selected according to a preset priority rule to form the candidate list of the third custodian. If the equilibrium solution obtained by Nash equilibrium does not meet the preset safety threshold, the comprehensive weight of each player in the game is updated, and the Nash equilibrium solution process is re-executed. The iteration continues until the equilibrium solution converges, forming the candidate list of the third custodian.

[0009] In one possible implementation, if multiple equilibrium results exist in the Nash equilibrium solution, the optimal equilibrium among the multiple equilibrium results is selected according to a preset priority rule to form the third custodian candidate list, including: Calculate the overall payoff for each equilibrium outcome among the multiple equilibrium outcomes, and select the equilibrium outcome with the largest overall payoff as the Pareto optimal equilibrium candidate set. If the Pareto optimal equilibrium candidate set contains multiple equilibrium results, then the frequency of each equilibrium result in the historical negotiation database is counted, and the equilibrium result with the highest frequency of occurrence is taken as the Schelling point equilibrium candidate set. If the Schelling point equilibrium candidate set contains multiple equilibrium results, then the comprehensive weighted value corresponding to each equilibrium result is calculated, the equilibrium result with the highest comprehensive weighted value is determined as the optimal equilibrium, and the strategy combination corresponding to the optimal equilibrium is used as the Nash equilibrium solution result to form the third custodian candidate list.

[0010] In one possible implementation, determining the target data custodian by calculating the intersection hash value of the second custodian candidate list and the third custodian candidate list includes: The second and third candidate custodian lists are encrypted, and an off-chain computing node is invoked to perform intersection calculation on the encrypted second and third candidate custodian lists to determine the pending custodians. The identity information of the undetermined custodian is hashed to generate an intersection hash value, and the intersection hash value is returned to each of the data providers and the data users to determine the hash matching result; If the hash matching result is a match, the pending custodian will be designated as the target data custodian, and the target data custodian's identity information will be written into the blockchain contract. A pre-set deposit for the target data custodian will be frozen, and after multi-party signature confirmation, the pre-set deposit will be transferred to the target data custodian's on-chain account, completing the target data custodian determination process. In one possible implementation, after determining the target data custodian by calculating the intersection hash value of the second custodian candidate list and the third custodian candidate list, the method further includes: Obtain the data catalog access request initiated by the target data custodian, and dynamically load the context-aware strategy through the data space connector to generate the visible asset catalog corresponding to the target data custodian; The data directory access request is verified by a zero-knowledge proof permission verification circuit, and a zero-knowledge proof verification result is generated. If the zero-knowledge proof verification result is access denied, then an insufficient permission notification is returned to the target data custodian, and the access failure log is recorded to the blockchain; If the zero-knowledge proof verification result is that access is allowed, then based on the visible asset catalog, a compliant transmission protocol that conforms to the data sharing scenario is generated to complete the multi-party data sharing task.

[0011] Furthermore, to achieve the above objectives, this application also proposes a data custodian selection device, which includes: The list retrieval module is used to retrieve a first custodian candidate list from multiple data providers and a second custodian candidate list from data users. The strategy solving module is used to determine the Nash equilibrium solution results corresponding to each of the first custodian candidate lists through the Nash equilibrium optimization strategy, and to obtain the third custodian candidate list; The target determination module is used to calculate the intersection hash value between the second custodian candidate list and the third custodian candidate list to determine the target data custodian.

[0012] In addition, to achieve the above objectives, this application also proposes a data custodian selection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data custodian selection method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the data custodian selection method as described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the data custodian selection method as described above.

[0015] This application provides a method, apparatus, device, and storage medium for selecting a data custodian. The method involves obtaining a first list of candidate custodians from multiple data providers and a second list of candidate custodians from data users. Then, using a Nash equilibrium optimization strategy, the method determines the Nash equilibrium solution for each of the first candidate custodian lists, resulting in a third candidate custodian list. Based on the intersection hash value calculation of the second and third candidate custodian lists, the target data custodian is determined. By obtaining multiple candidate lists from data providers and users, the method avoids a single party dominating the custodian selection. The Nash equilibrium optimization strategy further balances policy conflicts among providers, ensuring that the result takes into account the security compliance requirements and reputation preferences of each provider, thereby improving the fairness of custodian selection. Furthermore, by combining the uniqueness and collision resistance of the hash function, the method can quickly verify that the intersection result has not been tampered with, reducing the risk of repudiation. Thus, the method automatically verifies the consensus between the two parties through intersection hash value matching, eliminating the need for manual comparison of custodian qualifications, ultimately improving the security, efficiency, and reliability of data sharing in the data space. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the method for selecting a data custodian for this application, provided in Implementation Example 1; Figure 2 A flowchart illustrating the data extraction process provided for selecting a data custodian in this application; Figure 3 A sequence diagram of contract confirmation provided for the selection of the data custodian method in this application; Figure 4 A flowchart illustrating the authentication process for selecting a data custodian for this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the data custodian selection method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or data custodian selection system capable of performing the above functions. The following description uses a data custodian selection system as an example to illustrate this embodiment and the subsequent embodiments.

[0023] Based on this, embodiments of this application provide a method for selecting a data custodian, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the method for selecting a data custodian for this application, as provided in Implementation Example 1.

[0024] In this embodiment, the data custodian selection method includes steps S11 to S13: Step S11: Obtain a first custodian candidate list from multiple data providers and a second custodian candidate list from data users; It should be noted that the data provider refers to the entity (such as an enterprise or institution) that owns the data to be shared and needs to achieve secure data sharing through a data custodian. The first custodian candidate list refers to the set of candidate custodians that meet the trust requirements of each data provider after qualification verification and reputation screening. The set records key information such as the candidate custodian's Distributed Identifier (DID), the type of compliance protocol supported, and historical collaboration records. The data user refers to the entity that has data access needs and needs to obtain shared data through a data custodian. The second custodian candidate list refers to the set of candidate custodians that the data user has selected based on its own business needs, and the core of the list includes relevant information about custodians that meet the requirements of the business scenario.

[0025] The core objective of this step is to initially screen potential custodians from a massive pool of candidates who meet both the data provider's security and trust requirements and the data user's business needs through multi-dimensional screening. This avoids inefficiencies or collaboration failures in subsequent processes due to unqualified custodians or mismatched requirements. In one possible implementation, the initial list of candidate custodians submitted by the data provider can be uploaded via the Data Space Connector, which integrates lightweight blockchain nodes and supports real-time on-chain verification of verifiable credentials. The data user's business requirements parameters can be submitted through a standardized interface, and the system automatically parses the core constraints within these parameters to ensure a precise match between the screening logic and the user's needs.

[0026] For details, please refer to steps S21-S24, which will not be elaborated here.

[0027] Step S12: Using the Nash equilibrium optimization strategy, determine the Nash equilibrium solution results corresponding to each of the first custodian candidate lists, and obtain the third custodian candidate list; It should be noted that the Nash equilibrium optimization strategy refers to a negotiation algorithm used to resolve multi-party strategy conflicts. By treating each data provider as a game player and their first custodian candidate list as the strategy space, a payoff matrix is ​​constructed and the equilibrium is solved, ultimately yielding the optimal strategy combination that balances the interests of all parties. The Nash equilibrium solution refers to the set of candidate custodians from which all data providers have no incentive to deviate after solving the strategy. The third custodian candidate list refers to the set of candidate custodians representing the consensus of multiple data providers, formed based on the solution. This resolves the strategy conflicts among multiple data providers regarding their first custodian candidate lists. Through the fairness and rationality of the Nash equilibrium, it ensures that the final third custodian candidate list balances the security needs and trust preferences of each provider, avoiding a single provider dominating the decision-making process, and improving the efficiency of trust alignment in multi-party collaboration.

[0028] For details, please refer to steps S31-S53, which will not be elaborated here.

[0029] Step S13: Calculate the intersection hash value of the second custodian candidate list and the third custodian candidate list to determine the target data custodian.

[0030] It should be noted that the intersection hash value refers to a fixed-length string obtained by hashing the intersection of the second and third candidate custodian lists. Generated using the SHA-3-256 hash algorithm, it is unique and collision-resistant, and can uniquely identify the contents of the intersection set. The target data custodian refers to the final data custodian selected from the intersection set, which simultaneously meets the consensus of the data provider and the business needs of the data user, and has passed hash verification, deposit freezing, and multi-party signature confirmation. It is the core intermediary in the data sharing process. The data sharing process can be found in [reference needed]. Figure 2 .

[0031] The core objective of this step is to quickly identify a co-custodian who aligns with the consensus of data providers and the needs of data users through intersection calculation and hash verification. At the same time, the hash property is used to ensure that the intersection result is tamper-proof and non-repudiable. Deposit freezing and multi-party signatures further strengthen the custodian's sense of responsibility and the credibility of collaboration, ultimately accurately determining the target data custodian that meets the demands of all parties.

[0032] For details, please refer to steps S61-S64, which will not be elaborated here.

[0033] This embodiment obtains a candidate list of multiple data providers and users, avoiding a single participant dominating the selection of custodians. The Nash equilibrium optimization strategy further balances the policy conflicts among providers, ensuring that the results take into account the security and compliance requirements and reputation preferences of each provider, thereby improving the fairness of custodian selection. Combined with the uniqueness and collision resistance of hash functions, it can quickly verify that the intersection results have not been tampered with, reducing the risk of result repudiation. Thus, the consensus between the two parties is automatically verified by matching the intersection hash values, eliminating the need for manual comparison of custodian qualifications one by one, ultimately improving the security, efficiency, and credibility of data sharing in the data space.

[0034] In one feasible implementation, obtaining a first custodian candidate list of multiple data providers and a second custodian candidate list of data users includes: Step S21: Obtain the initial custodian candidate list submitted by each data provider, and determine the verifiable credentials corresponding to each provider candidate custodian in the initial custodian candidate list; It should be noted that the initial custodian candidate list refers to a preliminary list containing basic information about potential data custodians, including their names, organization codes, contact information, and other fundamental identifiers. The provider candidate custodian refers to each potential custodian entity on the initial custodian candidate list. Verifiable credentials refer to digital files conforming to W3C standards that prove the validity of the provider candidate custodian's qualifications, containing key information such as Distributed Identifiers (DIDs) and enterprise qualification certifications (such as Unified Social Credit Code certificates and compliance agreement filing documents).

[0035] Specifically, the system first receives the initial custodian candidate lists submitted by each data provider through an encrypted transmission channel, and standardizes the list format (e.g., unifying the organization code format and supplementing missing basic fields). Next, it pushes credential association requests to each data provider, requiring them to upload verifiable credentials corresponding to each provider's candidate custodian, and verifies the association between the credentials and the candidate custodians (e.g., comparing the Distributed Identity Identifier (DID) in the credential with the candidate custodian's DID). Finally, it performs a preliminary check on the received list and credentials, and after confirming that there are no duplicate candidate custodians and no missing credentials, it temporarily stores the list in the system's temporary database.

[0036] Step S22: By integrating a connector for lightweight blockchain nodes, the verifiable credential is uploaded to the blockchain network, the validity of the verifiable credential is verified by calling the business database, and candidate custodians whose verifiable credentials are invalid are filtered out. It's important to note that the connector integrating lightweight blockchain nodes refers to a gateway component within the system that combines data transmission and blockchain interaction capabilities. It supports interfacing with multi-chain environments such as Ethereum and Hyperledger Fabric, enabling on-chain uploading of verifiable credentials and on-chain recording of verification results. It also boasts lightweight characteristics, avoiding excessive system resource consumption. The blockchain network refers to a distributed ledger network used to store the hashes of verifiable credentials and verification results; its immutability ensures the credibility of the credential verification results. The business registration database refers to an official database maintained by relevant authorities, storing information such as company registration and qualification filings, used to verify the authenticity of the company's qualification information in verifiable credentials.

[0037] Specifically, firstly, by integrating a connector with a lightweight blockchain node, the verifiable credential is hashed, and the hash value is uploaded to the blockchain network. Simultaneously, the original credential is sent to the business registration database verification interface via an encrypted channel. Secondly, the business registration database API is called to verify the enterprise qualification information in the credential (such as whether the unified social credit code exists and whether the compliance filing is valid), and the verification result (valid / invalid and the reason) is obtained. Then, the verification result is associated with the corresponding verifiable credential hash and written into the blockchain network to form evidence storage. Finally, based on the verification result, the provider candidate custodian with invalid verifiable credentials is filtered out from the initial custodian candidate list, and the candidate with valid verification is retained.

[0038] Step S23: Based on the historical interaction records of each provider candidate custodian after the filtering credentials are invalidated, a dynamic reputation score is calculated for each candidate custodian through a preset attenuation model, and the provider candidate custodian whose dynamic reputation score meets the preset reputation threshold is retained to form a first custodian candidate list corresponding to each data provider. It should be noted that historical interaction records refer to data related to the candidate custodian's past participation in data sharing and collaboration, including the number of data breaches, compliance scores, task completion rates, and the types and timing of violations. The preset decay model refers to the algorithm used to calculate the dynamic reputation score, employing an α-β decay mechanism (violation event weight decay coefficient α=0.85 over time, reputation update cycle β=15 minutes). This mechanism updates the custodian's reputation in real time based on the different weights of recent and long-term interaction records, avoiding the long-term excessive impact of a single historical event on reputation. The dynamic reputation score is a quantitative value calculated using the preset decay model, reflecting the candidate custodian's current level of trust; a higher score indicates a more trustworthy custodian. The preset reputation threshold is a system-set reputation cutoff value used to screen trustworthy candidate custodians; candidate custodians with scores above this threshold are considered to have sufficient trustworthiness.

[0039] The core purpose of this step is to quantify the trustworthiness of candidate custodians through dynamic reputation scoring, further screen out custodians who are not only qualified and compliant but also have a good track record of cooperation, and ensure that the candidates participating in subsequent negotiations have both qualifications and credibility, thereby improving the reliability of data sharing.

[0040] Specifically, firstly, the system extracts the historical interaction records of filtered candidate custodians from the system's historical collaboration database and blockchain evidence storage, including the number of data breaches in the past year, monthly compliance scores, and the time of occurrence of violations; secondly, based on a preset decay model ( The attenuation model calculates the dynamic reputation score: initial score. Every 15 minutes (update cycle) Detect violations (such as submitting malicious policies), and apply a decay factor. Reduce the weight of recent violations using the following formula:

[0041] Where t is the number of periods since the last update, and Penalty is the normalized value of the number of violations in the current period, the score is updated. Then, the preset reputation thresholds set by each data provider are obtained, and candidate custodians with scores higher than the thresholds are retained; finally, a first custodian candidate list is generated for each data provider, categorized by data provider.

[0042] Step S24: Obtain the business requirement parameters submitted by the data user, and filter the candidate custodians based on the business requirement parameters to form the second candidate custodian list. The business requirement parameters include data processing protocol type, data transmission timeliness requirements, and historical collaboration preferences.

[0043] It should be noted that the business requirement parameters refer to the specific requirements that data users place on data custodians based on their own business scenarios. Among these, the data processing protocol type refers to the data sharing compliance protocols that the custodian must support (e.g., GDPR for EU data sharing, HIPAA for medical data sharing); data transmission timeliness requirements refer to the maximum allowable time for the custodian to complete the data transfer from the provider to the user (e.g., within 2 hours, within 1 business day); and historical collaboration preferences refer to the data user's preference for the custodian's past collaboration experience (e.g., prioritizing custodians with no negative feedback and excluding custodians with collaboration disputes in the past year). Candidate custodians refer to potential custodians that meet the data user's business requirement parameters, selected from all potential custodians.

[0044] The core purpose of this step is to select a suitable custodian based on the actual business scenario of the data user, ensuring that the target custodian subsequently determined not only meets the qualification and reputation requirements of the data provider, but also meets the business collaboration needs of the user, thus avoiding interruption of the data sharing process due to business mismatch.

[0045] Specifically, the system first receives business requirement parameters submitted by data users through an encrypted interface, and parses the core constraints in the parameters (such as protocol type = GDPR, timeliness requirement ≤ 3 hours, historical collaboration preference = preferred custodians). Next, it calls the system's custodian capability information database to extract capability data from all potential custodians (supported protocol types, historical transmission timeliness records, and collaboration history with data users). Then, it matches the custodian capability data with the business requirement parameters: retaining custodians that support the target protocol type, meet historical transmission timeliness requirements, and conform to collaboration preferences as candidate custodians for users. Finally, it integrates all candidate custodians for users to generate a second candidate custodian list, which is then synchronized to the intersection hash calculation module.

[0046] This embodiment ensures the authenticity and compliance of custodian qualifications by requiring candidate custodians to provide verifiable credentials and verifying them through a dual process of blockchain and business database verification. It filters out custodians with invalid qualifications, avoiding security and compliance risks caused by unqualified entities participating in data custody. A dynamic reputation score is calculated based on historical interaction records and a preset decay model to reflect the custodian's trust level in real time (e.g., violation records decay reasonably over time), retaining high-reputation custodians and reducing the risk of data leakage and collaboration failure due to custodians' past misconduct. Custodians are selected based on the data user's business needs parameters (protocol type, timeliness, collaboration preferences), ensuring a high degree of compatibility between the second custodian candidate list and the user's business scenario, avoiding rework due to custodians failing to meet business requirements. On-chain verification of credentials is achieved through a connector integrating lightweight blockchain nodes, ensuring the authenticity and traceability of qualification verification results, avoiding subjective bias caused by human intervention, and guaranteeing a fair and trustworthy selection process.

[0047] In one feasible implementation, the step of determining the Nash equilibrium solution results corresponding to each of the first custodian candidate lists through a Nash equilibrium optimization strategy to obtain the third custodian candidate list includes: Step S31: Determine the intersection and similarity of the first custodian candidate lists corresponding to each data provider. If the intersection of the lists is empty or the similarity of the lists is lower than a preset threshold, it is determined that there is a strategy conflict. For any data provider, the data provider is regarded as the game player and the first custodian candidate list corresponding to the data provider is regarded as the player strategy, and the game strategy space is constructed. It should be noted that the list intersection refers to the set of candidate custodians commonly included in the first custodian candidate lists of multiple data providers. If the set is empty, it indicates that there is no overlap between the candidate custodians initially screened by each provider, and obvious discrepancies exist. The list similarity refers to the degree of similarity between multiple first custodian candidate lists calculated through a cosine similarity algorithm. The algorithm quantifies and reflects the consistency of list content by vectorizing the lists and then calculating the cosine value of the angle between the vectors. The preset threshold refers to the similarity critical value set by the system for determining policy conflicts. A value lower than this threshold indicates that the lists differ greatly, and a conflict resolution mechanism needs to be activated. A policy conflict refers to a situation where there is no intersection or the similarity is too low between the first custodian candidate lists of multiple data providers, making it impossible to directly form a consensus candidate set. Game players refer to the respective data providers participating in policy negotiation, and each provider acts as an independent decision-making entity to pursue the maximization of its own trust demands. A player policy refers to the first custodian candidate list corresponding to each data provider, representing the custodian selection range recognized by the provider. The game policy space refers to a decision set composed of all game players and their corresponding player policies.

[0048] The core purpose of this step is to accurately identify policy discrepancies among multiple data providers through objective intersection and similarity calculation, and then convert the abstract discrepancies into quantifiable decision problems through game modeling, so as to avoid low efficiency or stagnation of subsequent processes caused by unresolved conflicts.

[0049] Specifically, first, the first custodian candidate lists of all data providers are extracted, and the list intersection is calculated through set operation. At the same time, each list is converted into a standardized policy vector, the cosine similarity algorithm is used to calculate the similarity between any two lists, and the average value is taken as the final list similarity. Secondly, the list intersection is compared with the preset threshold. If the intersection is empty or the similarity is lower than the threshold, it is determined that a policy conflict exists. Finally, each data provider is defined as a game player, and its corresponding first custodian candidate list is defined as the policy of the player. All players and policies are integrated to construct a game policy space containing player identifiers, policy contents and policy vectors, which is stored in the game analysis database of the system. For example, the first custodian candidate list of data provider enterprise A is {Jia, Yi}, that of enterprise B is {Yi, Bing}, and that of enterprise C is {Ding, Wu}; the module calculates that the list intersection is empty, converts the three lists into policy vectors (for example, the vector of A is [1,1,0,0,0], that of B is [0,1,1,0,0], and that of C is [0,0,0,1,1]), calculates that the average similarity is 0.2 (lower than the preset threshold of 0.7), and determines that a policy conflict exists; then A, B and C are taken as game players 1, 2 and 3 respectively, and their candidate lists are taken as the corresponding player policies to construct the game policy space.

[0050] Step S32: Calculate the strategy matching degree between each player's strategy and the preset global benchmark strategy, and calculate the comprehensive weight and payoff of each player to construct a payoff matrix; It should be noted that the preset global baseline strategy refers to a reference strategy constructed by the system based on historical best data custodian selection cases. This strategy incorporates characteristics of "high credibility, full compliance, and strong collaboration," specifically a list of custodian candidates who have repeatedly reached consensus historically without security or compliance issues. It serves as a reference standard for evaluating the rationality of each player's strategy. Strategy matching degree refers to the degree of similarity between each player's strategy (first custodian candidate list) and the preset global baseline strategy, calculated using a cosine similarity algorithm. It quantitatively reflects the alignment between the player's strategy and optimal practice; a higher matching degree indicates that the strategy better conforms to generally accepted trust standards. The comprehensive weight of a player refers to a quantitative value representing the player's influence in negotiations, calculated based on the player's strategy matching degree and their own dynamic reputation score. A higher weight indicates a greater weighting of their strategy in the final decision. Player payout refers to the quantitative value of the benefit gained by each player when choosing a particular strategy, comprehensively considering factors such as the strategy's matching degree with the global baseline and the security risks of strategy execution. The payout matrix is ​​a table containing all players, all possible strategy combinations, and their corresponding player payouts. Each cell in the table represents the specific payout value for a player under a given strategy combination. In one implementation, the preset global baseline strategy is updated regularly (e.g., monthly) to adjust the strategy content based on the latest compliance requirements and collaborative cases.

[0051] Specifically, each player's strategy and the baseline strategy are first transformed into standardized vectors, and then the cosine similarity algorithm is used to calculate the strategy matching degree of each player. For example, if the baseline strategy is the historically best whitelist, the strategy matching degree is calculated using the following formula:

[0052] Where i refers to the player identifier, and V... base This refers to the vectorized representation of the predefined global baseline policy, V. i It refers to the vectorized representation of a player's strategy.

[0053] Secondly, obtain the dynamic reputation score R of each player. i Refer to step S23; then define the payoff function for any strategy combination. Players The returns are:

[0054] Where AgreementScore is the percentage of the intersection between this strategy and other players' strategies, SafetyPenalty is the risk penalty for the strategy including low-reputation custodians, λ=0.1 is the penalty coefficient, and W i The overall weight is calculated using the following function: , =0.65 (strategy priority coefficient) =0.35 (historical credit rating) The strategy matching degree is calculated using cosine similarity. For dynamic reputation scoring.

[0055] Iterate through all strategy combinations and calculate the payout value for each player under each combination. Finally, with the players as rows and strategy combinations as columns, fill the payout values ​​into a table to generate a payout matrix containing player identifiers, strategy combinations, and payout values ​​for each player.

[0056] Step S33: Solve the Nash equilibrium of the payoff matrix to form the candidate list of the third custodian.

[0057] It's important to note that Nash equilibrium finding refers to identifying, based on the payoff matrix, a strategy combination (i.e., equilibrium strategy) where none of the players have an incentive to unilaterally change their strategy. Under this combination, changing any player's strategy will not improve their payoff, thus forming a stable consensus. The core objective of this step is to leverage the stability and fairness of Nash equilibrium to select a strategy combination from the payoff matrix that balances the interests of all data providers, converging the dispersed list of first custodian candidates into a unified list of third custodian candidates. This resolves the previously identified strategy conflicts and lays the foundation for consensus in cross-organizational negotiations.

[0058] Specifically, the payoff matrix is ​​first tested using a line-drawing method to detect pure strategy equilibria. For each player, with other players' strategies fixed, the strategy that maximizes that player's payoff is marked. If a strategy combination exists that is marked by all players, it is considered a pure strategy equilibrium. If no pure strategy equilibrium exists, a linear programming approach is used to construct the objective function (maximizing minimum payoff) and constraints (the sum of strategy selection probabilities equals 1), solving for the probability of each player choosing different strategies to determine the mixed strategy equilibrium. If multiple equilibria exist, the overall payoff of each equilibrium (the sum of all players' payoffs) is calculated, and the Pareto optimal equilibrium is selected. If multiple equilibriums still exist, the historical negotiation database is queried, and the Schelling point equilibrium with the highest frequency is selected. If multiple equilibriums still exist, the comprehensive weighted value of each equilibrium (the sum of the product of player weight and payoff) is calculated, and the equilibrium with the highest weighted value is selected. Finally, common candidate custodians are extracted from the equilibrium strategy combinations and integrated to form a third custodian candidate list.

[0059] This embodiment constructs a fair game strategy space to ensure that the trust preferences of each provider are incorporated into the decision-making process, avoiding a single provider dominating the selection of the custodian. By solving for the Nash equilibrium, it obtains a strategy combination in which all providers have no incentive to deviate, ensuring that the third custodian candidate list takes into account the security needs of all parties, avoiding negotiation deadlocks caused by imbalance of interests, and improving the efficiency of multi-party trust alignment. Furthermore, from conflict detection and game modeling to equilibrium solution, the entire process is executed according to standardized logic, without the need for manual intervention in negotiation. Compared with traditional manual coordination, this significantly shortens the time and avoids decision-making biases caused by subjective factors.

[0060] In one feasible implementation, the step of solving the payoff matrix for Nash equilibrium to form the candidate list of third custodians includes: Step S41: If a pure strategy equilibrium exists in the Nash equilibrium solution, the line-drawing method is used to screen out the strategy combinations in which all players have no motivation to deviate, forming the candidate list of the third custodian. It's important to note that pure strategy equilibrium refers to a strategy combination within the payoff matrix where each player's payoff is the maximum payoff assuming all other players' strategies remain constant. This means that unilaterally changing a player's strategy will not improve their own payoff, thus forming a stable strategic consensus. The line-drawing method is an intuitive algorithm used to filter pure strategy equilibria. By marking each player's maximum payoff under different strategy combinations in the payoff matrix, the algorithm finds the strategy combination that all players have marked, which is the pure strategy equilibrium. A strategy combination that all players have no incentive to deviate from is a strategy combination that satisfies the definition of pure strategy equilibrium; this combination represents the "optimal response" for each player. In one possible implementation, the line-drawing operation is performed automatically in the system's visual interface, which displays the payoff marking process for each player in real time. Data providers can view the marking logic, improving the transparency of the results.

[0061] Specifically, firstly, the payoff matrix constructed in step S32 is extracted. The rows of the matrix represent each player, the columns represent all possible strategy combinations, and the cells represent the payoff value of the corresponding player under that combination. Secondly, for each player, the strategies of other players are fixed, and the maximum payoff value is marked (e.g., marked with an underline) among all possible payoff values ​​of that player's strategies. Then, the payoff matrix is ​​traversed to find the strategy combination where the payoff values ​​of all players are marked. This combination is the pure strategy equilibrium. Finally, the common candidate custodians of all player strategies (first custodian candidate list) in this strategy combination are extracted, integrated and deduplicated to form the third custodian candidate list, and synchronized to the subsequent intersection matching module.

[0062] Step S42: If no pure policy equilibrium exists in the Nash equilibrium solution, then a linear programming method is used to solve the mixed policy equilibrium to form the third custodian candidate list; It's important to note that the absence of a pure strategy equilibrium means that there is no strategy combination in the payoff matrix where all players have no incentive to deviate; that is, for any strategy combination, at least one player can improve their payoff by changing their strategy. A mixed strategy equilibrium refers to a situation where players choose all possible strategies with a certain probability distribution. Under this probability distribution, each player's expected payoff is maximized when the probability distributions of other players are fixed, and the expected payoffs of all strategies are equal (no strictly dominant strategies). Linear programming is a mathematical optimization method used to solve mixed strategy equilibria. It calculates the optimal probabilities for each player to choose different strategies by constructing an objective function (e.g., maximizing the player's minimum expected payoff) and constraints (the sum of strategy choice probabilities is 1, expected payoff is non-negative, etc.).

[0063] In one possible implementation, the linear programming solution calls the system-integrated optimization algorithm library (such as Gurobi, GLPK) to support efficient computation in multi-variable and multi-constraint scenarios; during probability sampling, the Monte Carlo simulation method is used to randomly generate 1000 sampling results according to the probability of each strategy, and the strategy combination with the highest frequency is taken as the final basis to improve the reliability of the results.

[0064] Specifically, a linear programming model is first constructed based on the payoff matrix. Taking player 1 as an example, let the probabilities of choosing each strategy be p1, p2, ..., p n ( The objective function is to maximize the minimum expected return of player 1, with the constraint that player 1's expected return for each strategy of player 2 is equal and the probability is non-negative. Similarly, a linear programming model is constructed for other players, and the optimal strategy probability distribution for each player is solved through an optimization algorithm. Then, the final strategy is determined based on the probability distribution: if the probability of a certain strategy is ≥ a preset probability threshold (e.g., 0.6), then the strategy is directly selected; otherwise, a strategy combination is selected by probability sampling, or the intersection of all strategies is taken (ensuring coverage of common custodians of high-probability strategies). Finally, candidate custodians are extracted from the determined strategies and integrated to form a third custodian candidate list.

[0065] Step S43: If multiple equilibrium results exist in the Nash equilibrium solution, the optimal equilibrium among the multiple equilibrium results is selected according to a preset priority rule to form the third custodian candidate list. It should be noted that multiple equilibrium outcomes refer to multiple policy combinations that satisfy the definition of equilibrium obtained after solving the Nash equilibrium. These combinations all ensure that all players have no incentive to deviate, but they differ in overall payoff, historical consensus, etc. Preset priority rules refer to the decision rules pre-set by the system to select the optimal outcome from multiple equilibria. These rules are executed in the order of "Pareto optimality → Schelling point → weighted average," ensuring that the selection logic is fair and aligns with the interests of all parties. The optimal equilibrium refers to the equilibrium outcome selected through the preset priority rules that is best in terms of overall payoff, historical consensus, or player weight suitability. This resolves the uncertainty of outcomes caused by multiple equilibria, avoids negotiation stagnation due to player disagreements through clear priority rules, and prioritizes the equilibrium that is most beneficial to the whole, best aligns with historical consensus, or the demands of high-weight players, thus balancing individual and collective interests.

[0066] Specifically, firstly, the overall payoff (the sum of the payoffs of all players) of all multiple equilibrium outcomes is calculated, and the equilibrium outcome with the largest overall payoff is selected to form a Pareto optimal equilibrium candidate set. If the candidate set contains only one outcome, it is directly determined as the optimal equilibrium. If it contains multiple outcomes, the historical negotiation database is queried to count the frequency of each equilibrium outcome in the past year's negotiations, and the outcome with the highest frequency is selected to form a Schelling point equilibrium candidate set. If the candidate set still contains multiple outcomes, the comprehensive weighted value of each equilibrium outcome is calculated (the sum of the comprehensive weight of each player and the product of that player's payoff in the equilibrium), and the outcome with the highest weighted value is selected as the optimal equilibrium. Finally, common candidate custodians are extracted from the strategy combinations corresponding to the optimal equilibrium, and integrated to form a third custodian candidate list.

[0067] Step S44: If the equilibrium solution result of the Nash equilibrium does not meet the preset safety threshold, then update the comprehensive weight of each of the game players, and re-execute the Nash equilibrium solution process, iterating until the equilibrium solution result converges, forming the third custodian candidate list.

[0068] It should be noted that if the equilibrium solution does not meet the preset safety threshold, it means that the strategy combination corresponding to the Nash equilibrium has a safety risk. Specifically, this manifests as a player's payoff being negative (representing a risk of loss from strategy execution), the strategy combination containing candidate custodians with dynamic reputation scores below the safety threshold, or the absolute value of the overall safety constraint exceeding a preset upper limit (e.g., 0.5). The preset safety threshold refers to the critical criteria set by the system to judge the safety of the equilibrium result, including indicators such as non-negative payoff, a lower limit for custodian reputation, and an upper limit for safety constraints. Updating the overall weight of each player refers to adjusting the player's overall weight W. iThis changes the player's influence in negotiations. Equilibrium solution convergence means that the difference between the equilibrium results (strategy combinations, payoffs) obtained in two consecutive iterations is less than a preset convergence threshold, and both meet a safety threshold, ensuring result stability.

[0069] The core objective of this step is to eliminate equilibrium results with security vulnerabilities through security threshold verification and iterative optimization. This avoids risks such as data sharing leaks and compliance violations caused by insecure equilibrium results. Simultaneously, weight adjustments guide the game to converge towards a safer direction, ensuring that the final list of third-party custodian candidates possesses both stability and security. In one possible implementation, weight updates employ an adaptive adjustment algorithm, optimizing parameters based on the security risk type of the previous equilibrium result (e.g., increasing β to 0.4 and adding credit score weight if risk arises from a low-reputation custodian). The maximum number of iterations is set to 5. If convergence is still not achieved after 5 iterations, a third-party arbitration node (such as a regulatory agency) is introduced to adjust the strategy space and force the generation of a safe equilibrium result.

[0070] Specifically, firstly, the Nash equilibrium solution results (strategy combination, payoff value, custodian reputation) are extracted and compared with a preset safety threshold. If there are negative payoffs, custodian reputation values ​​below 0.3, or safety constraint values ​​<-0.5, the safety threshold is not met. Secondly, the causes of risk are analyzed. If the risk is due to low strategy matching, α is adjusted from 0.65 to 0.7, and the strategy matching degree and overall weight of each player are recalculated. If the risk is due to low player reputation, β is adjusted from 0.35... The score is adjusted to 0.4, and the dynamic reputation score and comprehensive weight are recalculated. Then, based on the updated comprehensive weight, steps S32 (constructing a new profit matrix), S33 (equilibrium solution), and S41 / S42 / S43 (equilibrium screening) are re-executed to obtain a new equilibrium result. Finally, the difference between the new result and the previous result is compared. If the difference is less than the convergence threshold and the safety threshold is met, convergence is determined, a list of third-party custodian candidates is extracted, and the equilibrium result is written into the blockchain smart contract to ensure that the execution is immutable. If convergence does not occur, the weight update and iteration process is repeated until convergence or the maximum number of iterations is reached.

[0071] In one embodiment, a fault-tolerance and optimization mechanism is constructed, including fault handling: if negotiation times out or there is no equilibrium, a degradation strategy (such as weighted degradation) is enabled. (Sorting, selecting the intersection of strategies from the Top-K providers); introducing a third-party arbitration node (such as a regulatory agency) to force a cooperative equilibrium; dynamic parameter adjustment: adaptively adjusting based on historical negotiation results. etc., without restriction.

[0072] This embodiment employs targeted solution methods such as the line drawing method, linear programming, and priority rules for different scenarios including pure strategy equilibrium, mixed strategy equilibrium, and multiple equilibrium. This avoids the omission of equilibrium due to the limitations of a single solution method and covers various situations of policy conflicts among multiple data providers. In the pure strategy equilibrium scenario, the line drawing method is used, which can quickly locate the policy combinations of all players without deviation motivation without complex algorithms. Compared with general solution methods, it significantly shortens the calculation time and improves process efficiency. When there is no pure strategy equilibrium, linear programming is used to solve the mixed strategy (determine the probability of each policy selection), avoiding the failure of solution due to the complete lack of overlap between policies. This ensures that even if the demands of multiple players are very different, feasible equilibrium results can still be generated.

[0073] In one feasible implementation, if multiple equilibrium results exist in the Nash equilibrium solution, the optimal equilibrium among the multiple equilibrium results is selected according to a preset priority rule to form the third custodian candidate list, including: Step S51: Calculate the overall payoff corresponding to each equilibrium result in the multiple equilibrium results, and take the equilibrium result with the largest overall payoff as the Pareto optimal equilibrium candidate set. It should be noted that multiple equilibrium outcomes refer to multiple strategy combinations obtained after solving the Nash equilibrium, satisfying the condition that "no player has an incentive to deviate." These combinations may differ in individual payoff distribution, but all conform to the definition of equilibrium. Overall payoff refers to the total benefit obtained by summing the payoffs of all players under each equilibrium outcome, reflecting the scale of collective benefit brought by this equilibrium outcome through multi-party cooperation. Pareto optimal equilibrium refers to the equilibrium with the maximum overall payoff among all equilibrium outcomes, where adjusting strategy combinations cannot increase the payoff of one player without decreasing the payoffs of other players; it represents a stable state with optimal collective benefit. The Pareto optimal equilibrium candidate set refers to the set of all equilibrium outcomes with the maximum overall payoff. If only one equilibrium with the maximum overall payoff exists, the candidate set contains only that outcome; if multiple equilibria have the same maximum overall payoff, the candidate set includes these outcomes. The core purpose of this step is to prioritize the outcome with the optimal collective benefit from multiple equilibria, avoiding the loss of overall cooperation efficiency due to excessive focus on individual interests, and ensuring that the subsequent third-party custodian candidate list conforms to the principle of "win-win for all parties." In one possible implementation, the overall profit calculation excludes outliers (such as extreme profits for a player due to data errors) and uses a "trimmed average" (suming the highest and lowest profit values ​​after removing the highest and lowest) to ensure the objectivity of the calculation results. If the overall profit difference of all equilibrium results is less than a preset small threshold (such as 0.02), it is determined that the overall profits are the same and all are included in the Pareto optimal equilibrium candidate set.

[0074] Specifically, firstly, the payoff values ​​of all players corresponding to each equilibrium are extracted from the multiple equilibrium results, and the payoff values ​​are derived from the payoff matrix; secondly, for each equilibrium result, the payoff values ​​of all players are added together to obtain the overall payoff of the equilibrium (e.g., equilibrium 1 includes player 1 with a payoff of 0.8 and player 2 with a payoff of 0.75, the overall payoff = 0.8 + 0.75 = 1.55); then, the overall payoffs of all equilibrium results are iterated to determine the maximum overall payoff value (e.g., 1.55); finally, all equilibrium results whose overall payoff is equal to this maximum value are selected to form a Pareto optimal equilibrium candidate set.

[0075] Step S52: If the Pareto optimal equilibrium candidate set contains multiple equilibrium results, then the frequency of occurrence of each equilibrium result in the historical negotiation database is counted, and the equilibrium result with the highest frequency of occurrence is taken as the Schelling point equilibrium candidate set. It should be noted that the historical negotiation database refers to a database in the system that stores data such as the frequency of occurrence of each equilibrium result, negotiation scenarios, and participant information in past data custodian selection cases. This data is immutable (stored via blockchain). Frequency of occurrence refers to the number of times each equilibrium result appears in the historical negotiation database in cases similar to the current negotiation scenario (e.g., number of participants, data type, compliance requirements). A higher frequency indicates that the equilibrium result is more easily accepted by multiple parties, possessing "consensus inertia." Schelling points refer to the consensus points that multiple parties naturally tend to choose in the absence of explicit communication; here, it represents the equilibrium result with the highest historical frequency. The core logic is that "past consensus is more likely to become current consensus." The Schelling point equilibrium candidate set refers to the set of all equilibrium results with the highest frequency of occurrence. If there is only one equilibrium with the highest frequency, the candidate set contains only that result; if multiple equilibria have the same frequency and are all the highest, the candidate set includes all of these results.

[0076] The core objective of this step is to quickly narrow down the candidate pool by leveraging historical consensus experience when collective interests cannot be distinguished, thereby reducing communication costs and decision-making time in current negotiations. Simultaneously, the rationality of historical cases ensures the feasibility of the current equilibrium choice, avoiding subsequent collaboration risks caused by subjective decisions. In one possible implementation, historical scenario similarity is calculated using the "cosine similarity of scenario feature vectors." Only when the similarity between the current scenario features (two providers, commercial data, GDPR compliance) and historical scenario features is ≥0.8 is the scenario included in the frequency statistics. If there is no similar scenario data in the historical negotiation database, this step is automatically skipped, and the process proceeds directly to the weighted filtering in step S53.

[0077] Specifically, the feature vector of the current negotiation scenario is extracted (such as the number of participating data providers, data sensitivity level, and the type of compliance protocol to be supported). Historical cases with scenario feature similarity ≥ a preset threshold are retrieved from the historical negotiation database. Next, for each equilibrium result in the Pareto optimal equilibrium candidate set, the number of times it appears in the retrieved historical cases is counted (e.g., equilibrium 1 appears 12 times in 20 similar cases, and equilibrium 2 appears 8 times). Then, the maximum frequency of occurrence is determined (e.g., 12 times). Finally, all equilibrium results with a frequency of occurrence equal to this maximum value are selected to form the Schelling point equilibrium candidate set.

[0078] Step S53: If the Schelling point equilibrium candidate set contains multiple equilibrium results, calculate the comprehensive weighted value corresponding to each equilibrium result, determine the equilibrium result with the highest comprehensive weighted value as the optimal equilibrium, and use the strategy combination corresponding to the optimal equilibrium as the Nash equilibrium solution result to form the third custodian candidate list.

[0079] It's important to note that the comprehensive weighted value refers to the sum of the products obtained by multiplying each player's comprehensive weight by their payoff under that equilibrium outcome for each equilibrium result. This value reflects how well the equilibrium fits high-influence players—a higher weighted value indicates that the equilibrium better aligns with the demands of players with high credibility and high strategy matching. The optimal equilibrium refers to the equilibrium result that best fits high-influence players, selected through the comprehensive weighted value calculation. Its core logic is that "the demands of highly credible players should receive higher decision-making weight." The Nash equilibrium solution refers to the strategy combination corresponding to this optimal equilibrium, which is the consensus strategy reached by multiple data providers.

[0080] In one possible implementation, when calculating the overall weighted value, the player's reward value is standardized (mapped to the 0-1 range) to avoid distortion of the weighted value due to differences in the range of reward values; if the difference between multiple balanced weighted values ​​is less than a preset small threshold (such as 0.01), a third-party arbitration node (such as an industry regulatory agency) is introduced to make the final decision.

[0081] Specifically, firstly, the payoff values ​​of each player corresponding to each equilibrium outcome in the Schelling point equilibrium candidate set are extracted. And the overall weight of each player calculated in step S32. Secondly, for each equilibrium outcome, according to Calculate the comprehensive weighted value; then select the equilibrium result with the highest weighted value and determine it as the optimal equilibrium; finally, extract the strategy combination corresponding to the optimal equilibrium (the first custodian candidate list for each player), calculate the intersection of these lists to obtain the common custodian candidate, and integrate and remove duplicates to form the third custodian candidate list.

[0082] This embodiment uses overall benefits, historical frequency, and comprehensive weight to correspond to the three dimensions of "interest matching", "cooperation stability" and "player fairness" respectively. The optimal balance selected not only meets the current interest demands, but also has a historical cooperation foundation and fairness, reducing the cooperation risks of subsequent data sharing.

[0083] In one feasible implementation, the step of determining the target data custodian by calculating the intersection hash value of the second custodian candidate list and the third custodian candidate list includes: Step S61: Encrypt the second custodian candidate list and the third custodian candidate list, and call the off-chain computing node to perform intersection calculation on the encrypted second custodian candidate list and the third custodian candidate list to determine the pending custodian; It's important to note that off-chain computing nodes refer to computing entities independent of the main blockchain, possessing trusted qualifications and high computing power (typically operated by consortium blockchain audit nodes or authoritative third-party institutions). Their role is to perform complex logic such as intersection calculations off-chain, avoiding the consumption of on-chain resources and preventing process delays. Intersection calculation refers to performing set operations on two decrypted lists to filter out candidate custodians that simultaneously exist in both the second and third custodian candidate lists. This process must ensure that the filtering dimensions (such as custodian identity and qualification validity) of the two lists are consistent. A pending custodian refers to a single candidate custodian selected through intersection calculation that simultaneously meets the business needs of the data user and the consensus of the data provider.

[0084] The core objective of this step is to accurately identify potential custodians who meet the needs of multiple parties while ensuring data privacy and computational efficiency. Sensitive information such as the custodians' qualifications and business requirements in the list is protected through encryption. Off-chain computing nodes perform intersection calculations to reduce on-chain computational pressure, avoiding process delays caused by limited on-chain resources. This also ensures the accuracy and reliability of the intersection results, laying the foundation for subsequent hash verification. In one possible implementation, the off-chain computing nodes are not single nodes, but a computing cluster composed of three or more trusted nodes. Each node must independently perform the intersection calculation and return the result. Only when the calculation results of more than two-thirds of the nodes are consistent is the final potential custodian determined, further reducing the risk of errors or malicious tampering by a single node.

[0085] Specifically, firstly, the second and third candidate custodian lists are extracted from the system database, ensuring that the lists contain unique identifiers (such as DIDs) and core qualification information of the candidate custodians. Secondly, the two lists are encrypted separately to generate encrypted ciphertext and corresponding message authentication codes. Simultaneously, a decryption key is generated and split into multiple key fragments according to the Secure Multi-Party Computation (SMPC) protocol, as a single fragment cannot complete the decryption. Then, a pre-set off-chain computing cluster is called through the smart contract interface to synchronize the encrypted ciphertext, message authentication codes, and corresponding key fragments to each node. Each off-chain computing node reassembles the complete decryption key using the key fragments, decrypts the encrypted ciphertext, and verifies the message authentication code (if verification fails, the data is determined to have been tampered with, and a new computation request is initiated). Subsequently, the intersection calculation is performed on the two decrypted lists to filter out the candidate custodians that exist simultaneously. Finally, the computing cluster performs consensus verification on the computation results of each node. If more than 2 / 3 of the nodes identify the same candidate custodian, then that candidate custodian is determined as a pending custodian.

[0086] Furthermore, if there are multiple candidate custodians, the latest dynamic credit scores of each candidate custodian in the candidate set are extracted from the system credit score database, the current business suitability of each candidate custodian is extracted from the business demand matching database, and then the comprehensive score of each candidate custodian is calculated according to a preset weighting formula; finally, the candidate custodian with the highest comprehensive score is selected and determined as the target data custodian.

[0087] Step S62: Perform hash calculation on the identity information of the pending custodian to generate an intersection hash value, and return the intersection hash value to each of the data providers and the data users to determine the hash matching result; It should be noted that the identity information of the pending custodian refers to the core data that uniquely identifies the pending custodian, including but not limited to the pending custodian's Distributed Identity Identifier (DID), full name of the enterprise, unified social credit code, and on-chain account address. This information is the original input for hash calculation and is also the key content for subsequent on-chain evidence storage. Hash calculation refers to processing the identity information of the pending custodian using a cryptographic hash algorithm, converting identity information of arbitrary length into a fixed-length (256-bit) string. This process has three main characteristics: "determinism" (the same set of identity information corresponds to only one unique hash value), "collision resistance" (different identity information is almost impossible to generate the same hash value), and "one-wayness" (the original identity information cannot be deduced from the hash value). The intersection hash value refers to the fixed-length string obtained after hash calculation, which is the "digital fingerprint" of the pending custodian's identity information. It can uniquely identify the custodian's identity and prevent the identity information from being tampered with without being detected. The hash matching result refers to the comparison between the intersection hash value generated by the system and the local hash value generated by the data provider and the data user based on their expected identity information of the custodian. If the three are completely consistent, it is determined as "hash matching is consistent", indicating that the identity of the custodian is real, has not been tampered with, and meets the expectations of all parties. If there is any difference in hash value, it is determined as "hash matching is inconsistent", and it is necessary to investigate whether the identity information has been tampered with or whether there is a deviation in the expectations.

[0088] The core purpose of this step is to verify the authenticity and integrity of the prospective custodian's identity information through the characteristics of hash algorithms. This prevents off-chain computing nodes or other unauthorized entities from tampering with the identity information, while also allowing data providers and users to confirm that the prospective custodian's identity meets their initial screening requirements, avoiding subsequent collaboration disputes due to identity discrepancies. In one possible implementation, when generating local hash values, data providers and users must strictly adhere to the same identity information sorting rules as the system (e.g., concatenating information in the order of "DID → Full Name of Enterprise → Unified Social Credit Code") and hash algorithm to ensure the comparability of the calculation results. If the hash matches are inconsistent, the system will automatically trigger a supplementary credential process, notifying the data provider to supplement the prospective custodian's qualification certificates and the data user to confirm their business needs. The intersection calculation and hash verification will then be re-executed, supporting up to three retries to ensure that negotiations can proceed in an orderly manner even when disagreements arise. This achieves automatic alignment of multi-party trust without relying on a central authority.

[0089] Specifically, the identity information of the prospective custodian is extracted and concatenated into a string in a preset order (such as DID, full name of the enterprise, unified social credit code, and on-chain account address). Next, a hash algorithm is used to perform hash calculations on the concatenated string to generate an intersection hash value. Then, through the smart contract's message push interface, the intersection hash value is sent to each data provider and data user, along with the identity information concatenation rules and hash algorithm descriptions, requesting both parties to return their local hash values ​​generated based on their expected identity information within a specified time. Subsequently, the local hash values ​​returned by the data providers and data users are received and compared one by one with the intersection hash value generated by the system. The hash matching result is determined based on the comparison results: if all three match successfully, "hash matching is consistent" is recorded; if any hash value differs, "hash matching is inconsistent" is recorded, and a difference report (marking the source of the inconsistent hash value) is generated.

[0090] Step S63: If the hash matching result is a hash match, then the pending custodian is designated as the target data custodian, the identity information of the target data custodian is written into the blockchain contract, and the preset deposit of the target data custodian is frozen. After multi-party signature confirmation, the preset deposit is transferred to the on-chain account of the target data custodian, thus completing the target data custodian determination process. It's important to note that blockchain contracts refer to smart contracts deployed on consortium blockchains (such as Hyperledger Fabric) or public blockchains (such as Ethereum). These contracts are immutable, automatically executed, and traceable, used to store the identity information of the target data custodian and execute deposit-related logic. The pre-set deposit refers to on-chain assets (usually compliant digital tokens) that the target data custodian must pay in advance. The amount is dynamically adjusted based on the data sensitivity (e.g., 1000 tokens for sensitive personal data scenarios, 500 tokens for ordinary commercial data scenarios). Its purpose is to constrain the custodian to fulfill their security and compliance responsibilities. If the custodian engages in data leakage, unauthorized transmission, or other misconduct, the deposit will be automatically deducted by the smart contract. Freezing the pre-set deposit means that the smart contract calls the target data custodian's on-chain account to lock the pre-set amount of assets. During the freeze period, the custodian cannot transfer or use these assets. Multi-party signature confirmation refers to the joint signature generated by the data provider, data user, and target data custodian using the Schnorr aggregation signature algorithm. This algorithm aggregates multiple fragmented signatures into a unified signature, ensuring both signing efficiency and non-repudiation. A successful signature signifies that all three parties acknowledge the identity and responsibilities of the target data custodian. An on-chain account refers to an account opened by the target data custodian on the blockchain network to receive the pre-set deposit after it is unfrozen. The account address is bound to the custodian's identity information to ensure traceability of fund flows.

[0091] The core objective of this step is to ensure the traceability of the target custodian's identity information through the immutability of the blockchain, strengthen the custodian's sense of responsibility through the deposit freezing and transfer mechanism, and form an irrefutable consensus through multi-party signatures. In one possible implementation, if the multi-party signature confirmation times out, the smart contract will automatically trigger the deposit unfreezing process, returning the frozen deposit to the target data custodian's account and re-triggering the intersection calculation process in step S61, avoiding the overall process from stalling due to delays by one party; if the target data custodian violates regulations in subsequent collaborations, the smart contract can automatically deduct part or all of the deposit based on on-chain audit records to compensate the data provider or user for losses.

[0092] Specifically, firstly, after confirming a consistent hash match, the pending custodian is officially designated as the target data custodian, and a confirmation notification is generated and pushed to the three users who need to share the data. Secondly, the information writing interface of the blockchain contract is called to write the identity information of the target data custodian into the contract storage area. The contract generates an immutable notarized hash and synchronizes it to the blockchain explorer for public query. Then, through the asset freezing interface of the contract, a preset deposit freezing request is initiated to the on-chain account of the target data custodian. After the contract verifies that the account balance is sufficient, the corresponding amount of assets is locked, and a successful freezing certificate is returned. Subsequently, a signature request is pushed to the data provider, data user, and target data custodian. The three parties generate sharded signatures using their respective private keys and submit them to the contract. The contract uses Schnorr... The aggregated signature algorithm combines fragmented signatures into a joint signature and verifies its validity (e.g., verifying the binding relationship between the private key and identity information). Finally, after successful joint signature verification, the contract automatically executes the deposit unfreezing and transfer logic, transferring the frozen, pre-set deposit to the target data custodian's on-chain account and pushing a process completion notification to all three parties. Simultaneously, the contract records the process completion time and fund flow, signifying the completion of the process with the target data custodian. (See reference...) Figure 3 .

[0093] This embodiment encrypts the two candidate lists, which can only be decrypted by off-chain computing nodes. This prevents sensitive information such as the custodian's qualifications and business needs from being leaked during transmission and computation, thus protecting the data privacy of multiple parties. Binbin writes the target custodian's information into the blockchain contract to ensure that the identity cannot be tampered with. The deposit is frozen and transferred after being signed by multiple parties, which restricts the custodian's performance and provides traceable on-chain evidence for subsequent disputes.

[0094] In one feasible implementation, after determining the target data custodian by calculating the intersection hash value of the second custodian candidate list and the third custodian candidate list, the method further includes: Step S71: Obtain the data directory access request initiated by the target data custodian, and dynamically load the context-aware strategy through the data space connector to generate the visible asset directory corresponding to the target data custodian; It should be noted that a data catalog access request refers to a request initiated by the target data custodian to the data space to obtain a list of accessible data assets. This request includes key information such as the custodian's distributed identity identifier, request timestamp, and data type tags to be accessed (e.g., "user behavior data," "financial statement data"). The data space connector refers to the gateway component within the data space, possessing functions such as data transmission, policy loading, and permission filtering. It is the core interface connecting the data space with external entities. Context-aware policies refer to dynamically adjusted permission control rules based on the access scenario. Scenario dimensions include access time (e.g., working hours 9:00-18:00), data sensitivity (e.g., top-secret data visible only in specific scenarios), and the custodian's current collaboration status (e.g., whether deposit freezing has been completed). The policy content is updated in real-time as the scenario changes. The visible asset catalog refers to a list of assets that the target data custodian is currently authorized to access, selected by the data space connector from the full data asset catalog according to the context-aware policy. This list only contains asset metadata that the custodian can view (e.g., asset name, data format, update time) and does not contain sensitive data content.

[0095] The core objective of this step is to achieve "scenario-based precise control" of data asset access by dynamically loading context-aware policies. This avoids excessive or insufficient permissions caused by static policies, while clearly defining the custodian's access scope through a visible asset catalog. In one implementation, context-aware policies are stored in a policy library within the data space. The policy library supports retrieval by scenario dimension (time, data type, custodian role), and the data space connector can call the latest policies in real time via API. If the target data custodian initiates multiple access requests of different types simultaneously, the connector will load the corresponding policy for each request separately, generating multiple visible asset catalogs to ensure granular access control.

[0096] Specifically, the process first receives a data directory access request initiated by the target data custodian through an encrypted interface, verifying the validity of the custodian's DID in the request (matching the target custodian's identity as evidenced on the blockchain); secondly, it calls the data space connector, passing key information from the access request (request timestamp, data type tag) to the connector, which then loads the corresponding context-aware policy from the policy library (e.g., "Hide sensitive financial data during non-working hours 18:00-9:00 the next day" and "Only allow access to user behavior data related to the current collaborative task"); then, based on the loaded policy, the connector filters the entire data asset directory in the data space, removing assets that do not conform to the policy (e.g., removing financial data during non-working hours and removing assets unrelated to the task); finally, it generates a visible asset directory containing only the assets currently accessible to the target data custodian, with basic metadata of the assets attached (excluding sensitive content).

[0097] Step S72: The data directory access request is verified through the zero-knowledge proof permission verification circuit to generate a zero-knowledge proof verification result; It should be noted that a zero-knowledge proof access control circuit refers to a cryptographic circuit developed based on the Circom language, used to verify the access rights of a custodian of target data. It includes three core constraint logics: signature verification, time window checking, and tag matching. It can prove whether a custodian has access rights without exposing sensitive information (such as the custodian's private key or plaintext data tags). The zero-knowledge proof verification result refers to the Boolean value output by the circuit after verification: "1" represents access is allowed (the custodian's permissions meet all constraints), and "0" represents access is denied (at least one constraint is not met). The result is immutable and verifiable.

[0098] The core objective of this step is to accurately verify the custodian's access permissions while protecting privacy. On one hand, zero-knowledge proofs do not expose sensitive information such as private keys and data tags, avoiding privacy leaks. On the other hand, the circuit's constraint logic ensures that only requests meeting all conditions (such as valid signature, within the allowed time, and matching access tags) can pass verification, enhancing the security of access control. In one possible implementation, the zero-knowledge proof verification circuit is deployed in an off-chain Trusted Execution Environment (TEE), with the verification process completely isolated to prevent tampering with the circuit logic. After verification, the circuit generates a verification credential (containing the verification result and circuit hash), which can be uploaded to the blockchain for subsequent auditing.

[0099] Specifically, the system first extracts the necessary verification information from the data directory access request, including the target data custodian's private key signature, the request timestamp, and the hash of the data tag to be accessed. Second, this information is converted into an input format recognizable by the zero-knowledge proof circuit (e.g., converting the timestamp to a Unix timestamp value and the signature to binary data), while simultaneously inputting preset constraint parameters (e.g., allowed access time windows startHour=9, endHour=18, and the target data tag hash). Then, the zero-knowledge proof circuit deployed in the TEE is invoked to execute the verification logic: ① verifying the validity of the private key signature (matching the public key corresponding to the custodian's DID), ② checking if the request timestamp is within the allowed time window, and ③ comparing the hash of the data tag to be accessed with the target tag hash. Finally, the circuit outputs a boolean verification result (1 = access allowed, 0 = access denied). The module associates and stores the result with the verification credentials (including the circuit execution log hash) and synchronizes it to subsequent decision-making modules. Figure 4 .

[0100] Step S73: If the zero-knowledge proof verification result is access denied, then return an insufficient permission notification to the target data custodian and record the access failure log to the blockchain; It should be noted that "Access Denied" refers to a Boolean value of "0" output by the circuit, indicating that the target data custodian's access request did not meet at least one constraint condition (such as invalid signature, time out of range, or tag mismatch), and therefore does not have the current access permission. "Insufficient Permissions Notification" refers to a notification pushed by the system to the target data custodian, containing the reason for the access denial (anonymized, such as "request time is not within the allowed range" or "data tag mismatch"), transmitted through an encrypted channel to ensure information is not stolen. The access failure log refers to structured data recording key information about the access denial event, including the access subject (target data custodian DID), access time, request content (data tag), reason for denial, verification credential hash, etc. The log content must be complete and immutable.

[0101] The core purpose of this step is to promptly inform the custodian of the reason for the access failure, and to fix the failure record through on-chain notarization. This helps the custodian quickly locate the problem (such as adjusting the access time, confirming the data label), constrains the custodian's access behavior to regulate and prevent malicious repeated requests, and provides credible evidence for subsequent dispute resolution. In one possible implementation, the insufficient permissions notification will include "suggested solutions" (such as "Please initiate access between 9:00-18:00" or "Confirm whether the data label is XXX"), improving the efficiency of problem resolution. When the access failure log is written to the blockchain, it will be associated with the corresponding zero-knowledge proof verification credential hash to ensure the correlation between the log and the verification process, facilitating subsequent traceability and verification.

[0102] Specifically, after confirming that the zero-knowledge proof verification result is access denied, the reason for the denial is analyzed (extracted from the constraint failure information returned by the verification circuit, such as "time window constraint failure"), and a de-identified permission deficiency notification is generated (including the reason for the denial and suggested solutions). Next, the notification is pushed to the target data custodian's system account via an encrypted message interface to ensure the custodian receives it in real time. Then, an access failure log is constructed, filled with information such as the access subject DID, access time (accurate to milliseconds), requested data tag (hash form), reason for denial, and verification credential hash according to a preset format. Finally, the log writing interface of the blockchain contract is called to convert the access failure log into structured data that the contract can store, upload it to the blockchain network, the contract records the log and generates a notarization hash, and returns a notarization success certificate to the module. The module then associates and stores the notarization hash with the log.

[0103] Step S74: If the zero-knowledge proof verification result is that access is allowed, then based on the visible asset catalog, a compliant transmission protocol that conforms to the data sharing scenario is generated to complete the multi-party data sharing task.

[0104] It should be noted that "access allowed" refers to a Boolean output value of "1" from the circuit, indicating that the target data custodian's access request meets all constraints (valid signature, time within the allowed window, and matching tag) and has the current access permissions. A compliant transmission protocol for data sharing scenarios refers to a transmission specification document automatically generated based on the data type and sharing scenario, conforming to industry regulations and multi-party agreements. The protocol content includes the data transmission scope (based on the visible asset catalog), transmission encryption standards, compliance responsibility allocation, and data usage restrictions. A multi-party data sharing task refers to the secure transmission and delivery of data from the data provider to the custodian and then to the user. Completion of this task marks the closure of the data sharing process.

[0105] The core objective of this step is to automatically generate a compliant protocol and complete data transmission based on verified permissions and a clearly defined asset scope. This ensures the protocol complies with regulatory requirements, avoids compliance risks, and shortens the protocol drafting and data sharing cycle through automation, thereby improving the efficiency of multi-party collaboration. In one possible implementation, after the compliant transmission protocol is generated, it is automatically uploaded to IPFS (InterPlanetary File System) storage, generating an immutable IPFS hash. The hash value is then written into a blockchain contract, facilitating multi-party querying and verification of the protocol's integrity. During data transmission, the system monitors the transmission progress and security in real time, and automatically triggers a resume mechanism if transmission is interrupted.

[0106] Specifically, after confirming that the zero-knowledge proof verification result allows access, the system first extracts the asset types (such as "de-identified user behavior data") and sharing scenarios (such as "business cooperation data sharing") from the visible asset catalog. It then calls the corresponding templates from the protocol template library (such as GDPR compliance templates) to automatically fill in the protocol content (transfer asset list, encryption standards, liability clauses, etc.) and generate a compliant transmission protocol. Next, the protocol is uploaded to IPFS storage, the IPFS hash is obtained, and the hash value is written into the blockchain contract to complete protocol notarization. Then, the data provider is notified to encrypt the data in the visible asset catalog according to the encryption standards agreed upon in the protocol and transmit it to the designated storage address of the target data custodian. The target data custodian receives the data and verifies its integrity (comparing the data hash with the hash provided by the provider), and then transmits the data to the data user according to the protocol requirements. Finally, after the data user receives the data and confirms that it is correct, it sends a successful reception notification to the system. The module integrates the confirmation information from all three parties, marks the completion of the multi-party data sharing task, and simultaneously writes the task completion record (including transmission time, data volume, and protocol IPFS hash) into the blockchain contract.

[0107] This embodiment loads context-aware strategies (such as time and scenario constraints) through a data space connector, generating only a visible asset catalog that matches the current scenario for the target custodian (such as hiding sensitive data outside of working hours). This avoids the exposure of irrelevant assets, reduces the risk of misoperation, and uses a zero-knowledge proof circuit to verify access permissions. It can confirm the validity of permissions without exposing sensitive information such as data tags and custodian private keys, ensuring the credibility of verification while preventing privacy leaks. When access is denied, the failure log is written to the blockchain, and the immutability of the blockchain is used to record the access subject, time, and reason, providing a reliable basis for subsequent auditing and dispute tracing, and strengthening the constraints on the custodian's behavior.

[0108] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0109] This application also provides a data custodian selection device, please refer to... Figure 5 The data custodian selection device includes: The list retrieval module is used to retrieve a first custodian candidate list from multiple data providers and a second custodian candidate list from data users. The strategy solving module is used to determine the Nash equilibrium solution results corresponding to each of the first custodian candidate lists through the Nash equilibrium optimization strategy, and to obtain the third custodian candidate list; The target determination module is used to calculate the intersection hash value between the second custodian candidate list and the third custodian candidate list to determine the target data custodian.

[0110] The data custodian selection device provided in this application, employing the data custodian selection method described in the above embodiments, can solve the technical problems in the background art. Compared with the prior art, the beneficial effects of the data custodian selection device provided in this application are the same as those of the data custodian selection method provided in the above embodiments, and other technical features in the data custodian selection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0111] This application provides a data custodian selection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the data custodian selection method in Embodiment 1 above.

[0112] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing the data custodian selection device in the embodiments of this application. The data custodian selection device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The data custodian's choice of device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0113] like Figure 5As shown, the data custodian selection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the data custodian selection device. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the data custodian to choose devices to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows data custodian selection devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0114] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0116] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the data custodian selection method provided by the methods described above.

[0117] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0119] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for selecting a data custodian, characterized in that, include: Obtain a first custodian candidate list from multiple data providers, and a second custodian candidate list from data users; By using the Nash equilibrium optimization strategy, the Nash equilibrium solution results corresponding to each of the first custodian candidate lists are determined, and the third custodian candidate list is obtained. The target data custodian is determined by calculating the intersection hash value between the second custodian candidate list and the third custodian candidate list. The process of determining the Nash equilibrium solution results corresponding to each of the first candidate custodian lists through the Nash equilibrium optimization strategy, and obtaining the third candidate custodian list, includes: Determine the intersection and similarity of the first custodian candidate lists corresponding to each data provider. If the intersection of the lists is empty or the similarity of the lists is lower than a preset threshold, it is determined that there is a strategy conflict. For any data provider, the data provider is regarded as the game player and the first custodian candidate list corresponding to the data provider is regarded as the player's strategy, and a game strategy space is constructed. Calculate the strategy matching degree between each player's strategy and the preset global benchmark strategy, and calculate the comprehensive weight and payoff of each player to construct a payoff matrix; The Nash equilibrium solution is obtained by performing a Nash equilibrium on the aforementioned payoff matrix to form the candidate list of the third custodian; The preset global benchmark strategy is a reference strategy constructed by the system based on historical best data custodian selection cases. The strategy matching degree is calculated using the cosine similarity algorithm, which quantifies the similarity between each player's strategy and the preset global benchmark strategy, reflecting the degree of alignment between the player's strategy and optimal practice. The comprehensive weight of the player is calculated based on the player's strategy matching degree and the player's own dynamic reputation score, representing the quantitative value of the player's influence in negotiations. The payoff is the quantitative value of the benefit obtained by each player when choosing a certain strategy, taking into account factors such as the matching degree between the strategy and the global benchmark, and the security risks of strategy execution. The payoff matrix is ​​a table containing all players, all possible strategy combinations, and the corresponding player payoffs. Each cell in the table represents the specific payoff value of the corresponding player under a certain strategy combination.

2. The data custodian selection method as described in claim 1, characterized in that, The process of obtaining a first custodian candidate list from multiple data providers and a second custodian candidate list from data users includes: Obtain the initial custodian candidate list submitted by each data provider, and determine the verifiable credentials corresponding to each provider candidate custodian in the initial custodian candidate list; By integrating a connector for lightweight blockchain nodes, the verifiable credentials are uploaded to the blockchain network, and the validity of the verifiable credentials is verified by calling the business database, filtering out candidate custodians whose verifiable credentials are invalid. Based on the historical interaction records of each provider candidate custodian after the filtering credentials are invalidated, a dynamic reputation score is calculated for each candidate custodian through a preset attenuation model, and the provider candidate custodian whose dynamic reputation score meets the preset reputation threshold is retained to form a first custodian candidate list corresponding to each data provider. Obtain the business requirement parameters submitted by the data user, and filter the user candidate custodians according to the business requirement parameters to form the second custodian candidate list. The business requirement parameters include data processing protocol type, data transmission timeliness requirements, and historical collaboration preferences.

3. The data custodian selection method as described in claim 1, characterized in that, The process of solving the payoff matrix using Nash equilibrium to form the candidate list of third custodians includes: If a pure strategy equilibrium exists in the Nash equilibrium solution, then the line-drawing method is used to screen out the strategy combinations in which all players have no incentive to deviate, forming the candidate list of the third custodian. If no pure strategy equilibrium exists in the Nash equilibrium solution, then a linear programming method is used to solve the mixed strategy equilibrium to form the third custodian candidate list; If multiple equilibrium results exist in the Nash equilibrium solution, the optimal equilibrium among the multiple equilibrium results is selected according to a preset priority rule to form the candidate list of the third custodian. If the equilibrium solution obtained by Nash equilibrium does not meet the preset safety threshold, the comprehensive weight of each player in the game is updated, and the Nash equilibrium solution process is re-executed. The iteration continues until the equilibrium solution converges, forming the candidate list of the third custodian.

4. The data custodian selection method as described in claim 3, characterized in that, If multiple equilibrium results exist in the Nash equilibrium solution, the optimal equilibrium among the multiple equilibrium results is selected according to a preset priority rule to form the third custodian candidate list, including: Calculate the overall payoff for each equilibrium outcome among the multiple equilibrium outcomes, and select the equilibrium outcome with the largest overall payoff as the Pareto optimal equilibrium candidate set. If the Pareto optimal equilibrium candidate set contains multiple equilibrium results, then the frequency of each equilibrium result in the historical negotiation database is counted, and the equilibrium result with the highest frequency of occurrence is taken as the Schelling point equilibrium candidate set. If the Schelling point equilibrium candidate set contains multiple equilibrium results, then the comprehensive weighted value corresponding to each equilibrium result is calculated, the equilibrium result with the highest comprehensive weighted value is determined as the optimal equilibrium, and the strategy combination corresponding to the optimal equilibrium is used as the Nash equilibrium solution result to form the third custodian candidate list.

5. The data custodian selection method as described in claim 1, characterized in that, The step of determining the target data custodian by calculating the intersection hash value of the second custodian candidate list and the third custodian candidate list includes: The second and third candidate custodian lists are encrypted, and an off-chain computing node is invoked to perform intersection calculation on the encrypted second and third candidate custodian lists to determine the pending custodians. The identity information of the undetermined custodian is hashed to generate an intersection hash value, and the intersection hash value is returned to each of the data providers and the data users to determine the hash matching result; If the hash matching result is a hash match, the pending custodian will be designated as the target data custodian, the identity information of the target data custodian will be written into the blockchain contract, and the preset deposit of the target data custodian will be frozen. After confirmation by multiple parties, the preset deposit will be transferred to the on-chain account of the target data custodian, thus completing the target data custodian determination process.

6. The data custodian selection method as described in claim 1, characterized in that, After determining the target data custodian by calculating the intersection hash value of the second custodian candidate list and the third custodian candidate list, the process further includes: Obtain the data catalog access request initiated by the target data custodian, and dynamically load the context-aware strategy through the data space connector to generate the visible asset catalog corresponding to the target data custodian; The data directory access request is verified by a zero-knowledge proof permission verification circuit, and a zero-knowledge proof verification result is generated. If the zero-knowledge proof verification result is access denied, then an insufficient permission notification is returned to the target data custodian, and the access failure log is recorded to the blockchain; If the zero-knowledge proof verification result indicates that access is allowed, then based on the visible asset catalog, a compliant transmission protocol that conforms to the data sharing scenario is generated to complete the multi-party data sharing task.

7. A data custodian selection device, characterized in that, include: The list retrieval module is used to retrieve a first custodian candidate list from multiple data providers and a second custodian candidate list from data users. The strategy solving module is used to determine the Nash equilibrium solution results corresponding to each of the first custodian candidate lists through the Nash equilibrium optimization strategy, and to obtain the third custodian candidate list; The target determination module is used to calculate the intersection hash value between the second candidate custodian list and the third candidate custodian list to determine the target data custodian; The strategy solving module is also used to determine the intersection and similarity of the first custodian candidate lists corresponding to each data provider. If the intersection of the lists is empty or the similarity of the lists is lower than a preset threshold, it is determined that there is a strategy conflict. For any data provider, the data provider is regarded as the game player and the first custodian candidate list corresponding to the data provider is regarded as the player's strategy, and the game strategy space is constructed. Calculate the strategy matching degree between each player's strategy and the preset global benchmark strategy, and calculate the comprehensive weight and payoff of each player to construct a payoff matrix; The Nash equilibrium solution is obtained by performing a Nash equilibrium on the aforementioned payoff matrix to form the candidate list of the third custodian; The preset global benchmark strategy is a reference strategy constructed by the system based on historical best data custodian selection cases. The strategy matching degree is calculated using the cosine similarity algorithm, which quantifies the similarity between each player's strategy and the preset global benchmark strategy, reflecting the degree of alignment between the player's strategy and optimal practice. The comprehensive weight of the player is calculated based on the player's strategy matching degree and the player's own dynamic reputation score, representing the quantitative value of the player's influence in negotiations. The payoff is the quantitative value of the benefit obtained by each player when choosing a certain strategy, taking into account factors such as the matching degree between the strategy and the global benchmark, and the security risks of strategy execution. The payoff matrix is ​​a table containing all players, all possible strategy combinations, and the corresponding player payoffs. Each cell in the table represents the specific payoff value of the corresponding player under a certain strategy combination.

8. A data custodian selection device, characterized in that, The data custodian selection device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the data custodian selection method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the data custodian selection method as described in any one of claims 1 to 6.

Images