Cross-domain data collaborative computing method based on secure multi-party computation and differential privacy

Abstract

This invention relates to the field of cloud computing technology, and particularly to a cross-domain data collaborative computing method based on secure multi-party computation and differential privacy. The invention proposes the following scheme: the task initiator abstracts the collaborative task into an intent description object and compiles it into an intermediate representation with gating logic, generating a dense-state function load for joint evaluation by multiple parties; the task assisting end generates real local contributions and counterfactual comparison contributions locally based on private data, and forms a detection score according to the request trajectory, adaptively determining the mixing coefficients. The two types of contributions are then subjected to restricted mixing and direction correction processing before participating in the dense-state computation. This application, without changing the appearance of the evaluation protocol, balances task intent protection and sensitive subgroup existence protection, improving security and engineering usability in cross-domain collaborative scenarios.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a cross-domain data collaborative computing method based on secure multi-party computation and differential privacy. Background Technology

[0002] With the increasing demand for data collaboration in fields such as financial risk control, medical research, and industrial quality control, joint modeling and statistical analysis by multiple parties without sharing raw data has become a common engineering practice. Existing solutions typically rely on secure multi-party computation or differential privacy mechanisms to enable participants to complete joint evaluations without data leaving their domains. However, in actual deployments, even if the raw data is not directly accessed, the trajectory of collaborative outputs under multiple rounds of queries, different task windows, or different input perturbations can still be used by participants for counterfactual inferences. For example, by controlling their own input patterns, adjusting their participation pace, or repeatedly initiating similar tasks and statistically testing the output differences, they can indirectly determine whether a particular collaborating party contains a specific sensitive subgroup or rare events. This type of inference does not rely on plaintext data leakage but rather uses the verifiability of collaborative outputs to form profiles, thereby making an existence determination on the distribution of private data at the collaborating party within a compliance framework.

[0003] In existing technologies, multi-party computation focuses on ensuring the confidentiality of the computation process, while differential privacy focuses on limiting the leakage of individual information in a single query. However, they lack specific constraints on combined probing behaviors across rounds and windows, especially when the participation trajectory itself may constitute an attack signal. Simply relying on budget accumulation or fixed noise allocation is insufficient to block statistical significance tests based on output differences. Therefore, while ensuring the usability of joint evaluation, how to suppress the inference of the existence of sensitive objects through multiple rounds of output changes has become an urgent technical problem to be solved in cross-domain collaborative environments.

[0004] To address the above issues, this application designs a cross-domain data collaborative computation method based on secure multi-party computation and differential privacy. Summary of the Invention

[0005] The technical problem to be solved by this invention is to address the shortcomings of existing technologies by providing a cross-domain data collaborative computation method based on secure multi-party computation and differential privacy. The task initiator abstracts the collaborative task into an intent description object and compiles it into an intermediate representation with gating logic, generating a dense state function load for joint evaluation by multiple parties. The task assisting end generates real local contributions and counterfactual comparison contributions locally based on private data, forms a detection score based on the request trajectory, adaptively determines the mixing coefficient, and performs restricted mixing and direction correction processing on the two types of contributions before participating in the dense state computation.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A cross-domain data collaborative computation method based on secure multi-party computation and differential privacy is applied to the task initiator of a distributed processing system. The task initiator initiates collaborative computation tasks and obtains the results. The distributed processing system also includes multiple task assisting ends, which participate in the collaborative computation tasks based on private data configured within the task assisting end and output the collaborative computation results. The method includes: The collaborative computing task to be executed is determined, and an intent description object is generated based on the collaborative computing task. The intent description object is used to characterize the task definition of the collaborative computing task. An intermediate representation of the intent function is generated based on the intent description object, and the intermediate representation is subjected to blind encoding to generate a dense-state function payload; The encrypted function payload is distributed to the task assisting terminal, and the task assisting terminal is triggered to generate encrypted input based on its own private data and participate in joint evaluation. Differential privacy processing is introduced in the joint evaluation process to generate collaborative computation results.

[0007] Generate an intent description object based on the collaborative computing task, including: Obtain the task configuration parameters corresponding to the collaborative computing task; The task configuration parameters are structured and parsed to extract at least one type of task definition element for defining the collaborative computing task. The task definition element includes at least one of the following: target output type, target optimization preference, and attention object rule. The intent description object is constructed based on the task definition elements.

[0008] The method further includes: The intent function is determined based on the intent description object, and the intent function is compiled into an intermediate representation, wherein the intent function is used to characterize the evaluation rules of the collaborative computing task, and the intermediate representation is an intent operator graph, which includes multiple operator nodes connected by data flow and at least one gate node for controlling the execution path of the operator nodes.

[0009] Determining the intent function based on the intent description object includes: Based on the intent description object, a set of candidate task definition elements is determined, and the set of candidate task definition elements is used to characterize multiple optional evaluation methods of the collaborative computing task; A gating selection rule is constructed for the set of candidate task definition elements. The gating selection rule is used to map the candidate task definition elements to a gating vector, wherein the gating vector is used to indicate the set of operator nodes to be enabled in the intent function. The gate vector is subjected to dense state processing to generate dense state gate parameters, and the dense state gate parameters are combined with a preset basic evaluation skeleton to determine the intention function containing gate logic and evaluation logic; The basic evaluation skeleton is a general evaluation structure corresponding to the set of candidate task definition elements, and it remains consistent under different sets of candidate task definition elements.

[0010] Compiling the intent function into an intermediate representation includes: A hypergraph skeleton is constructed based on the intent function, wherein the hypergraph skeleton includes multiple template subgraphs, and the template subgraphs are used to correspond to different candidate task definition elements in the candidate task definition element set, respectively. In the hypergraph skeleton, semantic bypass components are configured for at least a portion of the template subgraphs. The semantic bypass components include a main operator node, a bypass operator node, and a synthesis node for selective synthesis between the outputs of the main operator node and the bypass operator node. The control quantity of the gate node corresponding to the semantic bypass component is determined based on the dense gating parameters, and the gate node is associated with the synthesis node; The hypergraph skeleton is bound to the semantic bypass component to generate an intermediate representation.

[0011] The intermediate representation is subjected to blind encoding to generate a dense-state function load, including: Node identifiers and connection identifiers are generated for at least some of the operator nodes and their node connection relationships in the intermediate representation, and permutation mapping is performed on the node identifiers and connection identifiers to obtain topology description information; The gating conditions associated with the gating node in the intermediate representation are subjected to dense state processing to generate dense gating conditions; The dense state function load is generated based on the topology description information and the dense state gating conditions.

[0012] A cross-domain data collaborative computation method based on secure multi-party computation and differential privacy is applied to a task assisting end of a distributed processing system. The task assisting end participates in the collaborative computation task based on private data configured within it. The distributed processing system also includes a task initiating end, which initiates the collaborative computation task and obtains the collaborative computation result. The task initiating end further includes sending a dense function payload to the task assisting end. The method includes: The cooperative session identifier corresponding to this joint evaluation is determined based on the dense state function load. A detection score is generated based on the request metadata associated with the collaborative session identifier, wherein the request metadata includes at least request frequency, request interval, and task window change information; Based on the private data, a true local contribution is generated for participating in the joint evaluation, and based on the private data, a counterfactual comparison local contribution corresponding to the true local contribution is generated; The mixing coefficient is determined based on the detection score, and the true local contribution and the counterfactual local contribution are subjected to restricted mixing based on the mixing coefficient to obtain the hedging local contribution, wherein the restricted mixing at least satisfies the preset upper bound constraint of offset and the direction consistency constraint. The hedging local contribution is converted into a dense state input, and the intermediate representation description information corresponding to the dense state function load and the dense state gating parameters are used to participate in the joint evaluation to output the collaborative calculation result.

[0013] A probe score is generated based on the request metadata associated with the collaborative session identifier, including: Obtain historical request records associated with the collaborative session identifier to generate a request metadata sequence, the request metadata sequence including at least a request timestamp, a task window identifier, and a request source identifier; Request frequency features and request interval features are calculated based on the request timestamp. The request frequency features are used to characterize the number of requests within a preset time window, and the request interval features are used to characterize the time interval distribution between adjacent requests. The task window change characteristics are calculated based on the task window identifier, and the task window change characteristics are used to characterize the number of times and the magnitude of switching of the task window identifier within a preset time window; The detection score is obtained by weighted summation of the request frequency feature, the request interval feature, and the task window change feature.

[0014] The methods for generating the true local contribution and the counterfactual comparison local contribution include: The private data is divided into sensitive subset data and non-sensitive subset data based on a preset sensitive object discrimination rule. The sensitive object discrimination rule is used to determine whether the private data belongs to a preset sensitive object. The true local contribution is generated based on the private data. The counterfactual comparison local contribution is generated based on the non-sensitive subset data. The counterfactual comparison local contribution is used to characterize the local contribution when the private data does not contain the sensitive object.

[0015] A mixing coefficient is determined based on the detection score, and a restricted mixing is performed on the true local contribution and the counterfactual control local contribution based on the mixing coefficient to obtain a hedging local contribution, including: Based on the detection score, a target mixing coefficient strategy is determined from a preset set of mixing coefficient strategies, wherein the set of mixing coefficient strategies includes at least two mixing coefficient value rules corresponding to different detection score intervals; A mixing coefficient is generated according to the target mixing coefficient strategy, wherein the mixing coefficient is a random variable driven by a random seed associated with the collaborative session identifier; The true local contribution and the counterfactual local contribution are linearly mixed based on the mixing coefficient to obtain the initial hedging local contribution; The initial hedging local contribution is subjected to offset upper bound constraint detection. The offset upper bound constraint detection is used to determine whether the offset of the initial hedging local contribution relative to the real local contribution is greater than a preset offset threshold. When the offset exceeds the preset offset threshold, the mixing coefficient is adjusted and the initial hedging local contribution is regenerated until the offset is less than or equal to the offset threshold. The initial hedging local contribution is subjected to direction correction processing to obtain the hedging local contribution. The direction correction processing includes projecting and reconstructing the initial hedging local contribution based on the true local contribution direction.

[0016] Compared with the prior art, the beneficial effects of the present invention are: Compared to existing schemes that rely solely on secure multi-party computation or differential privacy for single-point protection, this application introduces a request trajectory-based detection and scoring mechanism at the task collaboration end. Combined with counterfactual comparison contributions and a constrained hybridization strategy, this enables local contributions to have adaptive hedging capabilities at the numerical level, thereby weakening the statistical verifiability of multi-round output differences regarding the existence of sensitive subgroups. While maintaining the dense-state function load structure and joint evaluation process unchanged, numerical drift caused by hybridization is controlled through offset upper bound constraints and direction correction processing, ensuring the collaborative results remain stable within the engineering scope and avoiding the impact of excessive perturbation on convergence or statistical accuracy. Attached Figure Description

[0017] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 An exemplary application scenario diagram provided for an embodiment of this application; Figure 2 A schematic diagram of another example system architecture provided for embodiments of this application; Figure 3 A schematic diagram of a processor module provided in an embodiment of this application; Figure 4 A schematic diagram of the task initiation processing module provided in an embodiment of this application; Figure 5A schematic diagram of the task assistance terminal processing module provided in an embodiment of this application; Figure 6 A flowchart illustrating the cross-domain data collaborative computation method based on secure multi-party computation and differential privacy provided in this application embodiment; Figure 7 This is a flowchart illustrating another cross-domain data collaborative computation method based on secure multi-party computation and differential privacy, provided as an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] In real-world cross-organizational data collaboration practices, collaborative computing is often not simply an abstract algorithmic problem of making data more accurate, but rather an engineering activity constrained by business boundaries, compliance boundaries, and game theory boundaries. On the one hand, data in scenarios such as finance, healthcare, manufacturing, and the industrial internet are naturally dispersed within different entities, making data centralization difficult due to regulatory, contractual, risk isolation, and commercial interests. On the other hand, these scenarios generally have an objective need for cross-domain joint modeling or cross-domain joint statistics. The resulting collaborative computing typically has the basic characteristics of multi-party participation, data remaining within its domain, usable results, and controllable processes. Furthermore, its implementation is further pushed towards more complex real-world constraints: participants are not only concerned about the leakage of their own data, but also about ensuring that the business strategies reflected in the collaborative task itself, such as focus, risk appetite, screening criteria, and target audience, are not externally profiled.

[0021] In some existing solutions, a combination of secure multi-party computation and differential privacy is often used to reduce the risk of data leakage: each task assisting end generates local contributions locally based on private data, such as gradients, sufficient statistics or local embeddings, and completes aggregation or joint evaluation through secure multi-party computation, and introduces differential privacy processing on the output side to limit the impact of single samples on the results. This approach can alleviate the requirement of plaintext data invisibility to some extent, but two types of dilemmas that are repeatedly encountered and difficult to handle by those skilled in the art still arise in engineering collaboration: First, collaborative tasks often require customized objective functions, constraints, rules of interest, and stopping conditions. If these task definitions are exposed to the participants in the form of plaintext configuration or resolvable structures, even if the data itself is not visible, the participants may still infer the initiator's true concerns through side signals such as task configuration, process trajectory, and noise distribution texture, thus leading to the leakage of business strategy. Second, the collaborative process is interactive and repeatable. Malicious or curious participants may manipulate their own input, participation timing, or task window variations to create comparable counterfactual experiments to make significant inferences about the existence of a certain sensitive subgroup / event in the private data of other assisting parties. Such inferences do not rely on restoring the original plaintext data and will still cause substantial privacy damage to the assisting parties.

[0022] Given the aforementioned practical constraints, the core logic of this application does not stop at simply hiding the input. In some optional specific implementations, the task initiator no longer drives collaboration with a resolvable task configuration, but instead abstracts the evaluation rules of the collaborative computation task into an intent function, and compiles this intent function into an intermediate representation that can be jointly evaluated, making it executable at the structural level. Subsequently, this intermediate representation is blind-coded to form a dense function payload, making it difficult for the task assistant to deduce the task definition elements from the payload structure even if it participates in the joint evaluation, thereby reducing the risk of intent probing based on structural fingerprints. At the same time, considering the actual situation of the assistant in the collaborative environment: it cannot be assumed that all participants are trustworthy, nor can it rely on external plaintext auditing to identify probing behavior. In other optional implementations, the task assisting end can generate a probe score based on the collaborative session request metadata without changing the dense state function load, and introduce a restricted counterfactual hedging mechanism for its own local contribution accordingly: on the one hand, it constructs a counterfactual comparative local contribution corresponding to the true local contribution to characterize the contribution form when the private data does not contain a certain sensitive object; on the other hand, under the upper bound constraint of offset and the consistency constraint of direction, it performs a restricted mixing of the true contribution and the counterfactual comparative contribution to reduce the statistical testability of the existence of sensitive objects due to the differences in outputs in multiple rounds, while avoiding the risk of non-convergence or poisoning caused by unbounded perturbations. Through the above approach, this application can further protect the task definition that is easily profiled and the existence information that is easily exploited by saliency tests in collaborative computing, without leaving the data domain, making cross-domain collaboration more in line with the comprehensive requirements of confidentiality, availability and adversarial capabilities in real engineering deployments.

[0023] It is important to emphasize that although this application employs a restricted mixing of the true local contribution and the counterfactual local contribution, which may introduce some morphological perturbation to the local contribution, this perturbation is not arbitrarily added or unboundedly altered. Instead, it is applied in a controlled manner with the premise of not degrading usability. On the one hand, the restricted mixing is constrained by a preset upper bound constraint, which limits the deviation of the offset local contribution from the true local contribution to a convergent and permissible range, thereby avoiding irreversible systematic deviations in the global evaluation results. On the other hand, the restricted mixing is constrained by a direction consistency constraint, which ensures that the offset local contribution remains consistent with the true local contribution in the main direction, ensuring that the dominant optimization direction or dominant statistical trend on which the collaborative computation depends is not changed, thereby suppressing the risk diffusion caused by targeted poisoning or malicious manipulation.

[0024] refer to Figure 1 , Figure 1 This is an exemplary application scenario diagram provided for an embodiment of this application.

[0025] like Figure 1As shown, the system includes a task initiator and multiple task assistants. The task assistants are distributed around the task initiator, and each assistant is isolated from the others at the data level, with its own independent private data resources. The task initiator initiates collaborative computation tasks, generates dense function loads, and obtains the collaborative computation results after joint evaluation. Each task assistant participates in the joint evaluation process based on the dense function loads without disclosing its private data content.

[0026] It should be noted that the private data held by each task assisting terminal can originate from different business entities or different system nodes, such as business records from different organizations, operational data collected from different devices, or feature data from different subsystems. Due to regulatory constraints, commercial interests, or data security policy limitations, the private data is not allowed to be centrally aggregated at the physical or logical level. Therefore, achieving cross-domain joint evaluation through a secure multi-party computation framework becomes a feasible technical path. In this embodiment, the task initiating terminal does not directly access the original data of each task assisting terminal, but instead triggers each task assisting terminal to generate corresponding encrypted inputs by distributing encrypted function payloads, thereby completing the calculation of the objective function during the joint evaluation process.

[0027] It is understood that the definition of the task initiator is only used to describe the logical role responsible for task definition generation, encrypted function payload construction, and result aggregation in a certain collaborative session, and should not be understood as a fixed physical device, fixed server, or fixed business entity permanently acting as the task initiator in the system. In different collaborative scenarios or different session periods, any node with corresponding computing and control capabilities can be configured as a task initiator, and its identity can be dynamically switched according to business needs, scheduling strategies, or access control. Similarly, the task assistant is also a logical role responsible for generating encrypted inputs based on local private data and participating in joint evaluation, and is not limited to a specific type of hardware terminal or fixed network node. In other words, the division between the task initiator and the task assistant in this application is a functional role division, not a structural limitation on specific physical entities in the system. Those skilled in the art can make equivalent substitutions or adjustments to the deployment form, quantity, and role allocation method of each node without departing from the technical concept of this application.

[0028] refer to Figure 2 , Figure 2 This is a schematic diagram of another example system architecture provided for an embodiment of this application.

[0029] and Figure 1 The application scenarios shown focus on different inter-device interaction relationships. Figure 2The system structure of this application is further abstracted and described from the perspective of functional components and logical deployment, so as to illustrate how the method of this application is implemented in a specific system environment.

[0030] like Figure 2 As shown, both the task initiator and the task assistant include a memory, a processor, and a communication device. The memory and processor, based on different task roles, call and execute corresponding program instructions to complete the corresponding functional flow. Specifically, the memory stores program code, model parameters, collaborative session identification information, historical request records, and configuration rules related to the method of this application. The processor, when running the program code, performs steps such as collaborative task initiation, dense state function load generation, probe score calculation, local contribution generation, and restricted hybrid processing. The communication device enables dense state function load distribution, dense state input interaction, and data transmission during the joint evaluation process between the task initiator and multiple task assistants.

[0031] It should be noted that, on the task initiating end side, when executing program instructions, the processor can generate an intent description object based on the collaborative computing task, construct an intent function and compile it into an intermediate representation, then perform blind encoding of the function to form a dense function payload, and send it to each task assisting end through the communication device; simultaneously, after the joint evaluation is completed, it receives the aggregation result and outputs the collaborative computing result. On the task assisting end side, when executing program instructions, the processor can generate true local contributions and counterfactual local contributions based on private data, generate a probe score based on the collaborative session request metadata, and perform restricted mixing processing on the local contributions under offset upper bound constraints and direction consistency constraints, and then convert the hedging local contributions into dense inputs and participate in the joint evaluation.

[0032] Furthermore, the specific forms of the memory, processor, and communication device described in this application are not limited, and they can be general-purpose servers, dedicated computing nodes, cloud computing instances, edge computing devices, or other hardware devices with computing and communication capabilities. The connection method between the above components can be bus connection, network connection, or other data interaction methods. Those skilled in the art can make equivalent substitutions for the specific implementation forms of the components according to actual deployment requirements, without affecting the implementation principle of the method at the system architecture level.

[0033] refer to Figure 3 , Figure 3 A schematic diagram of a processor module provided in an embodiment of this application.

[0034] like Figure 3 As shown, Figure 3This is a schematic diagram of a processor module provided in an embodiment of this application. The processor can be divided into different functional modules on the same hardware entity via software, or it can be physically deployed on different nodes. In this embodiment, for ease of explanation, the processor is abstractly divided into a task initiation processing module and a task assistance processing module, wherein: the task initiation processing module is used to perform functions related to the definition and control of collaborative tasks when assuming the role of task initiation. The task assistance processing module is used to perform functions related to local private data processing and anti-detection protection when assuming the role of task assistance. It should be noted that the division between the task initiation processing module and the task assistance processing module is a logical functional division. In a practical system, they can be configured on different physical devices according to the deployment strategy, or their roles can be switched on the same processor through different processes or threads. This application does not limit the specific implementation form.

[0035] refer to Figure 4 , Figure 4 A schematic diagram of the task initiation processing module provided in the embodiments of this application.

[0036] like Figure 4 As shown, the task initiation processing module can be logically further divided into a task description generation unit, an intent function generation unit, an intermediate representation generation unit, and a dense payload generation unit. These units work collaboratively in a preset execution order to construct and encapsulate the collaborative computing task. Specifically, the task description generation unit generates structured description information for the collaborative computing task based on business-side input or system scheduling strategies, forming an intent description object. The intent function generation unit determines the corresponding intent function based on the intent description object, and the intent function characterizes the evaluation rules of the collaborative computing task. The intermediate representation generation unit compiles the intent function into an intermediate representation that can be jointly evaluated and executed. In some embodiments, the intermediate representation can be in the form of an intent operator graph, including multiple operator nodes connected by data flow and gate nodes for controlling the operator execution path. By introducing structural designs such as a hypergraph skeleton and semantic bypass components, the intermediate representations generated under different candidate task definition elements maintain consistency in topology and node type distribution, thereby reducing the risk of profiled task intent based on structural fingerprints. The dense payload generation unit performs blind function encoding on the intermediate representation to generate a dense function payload. The function blinding encoding may include steps such as permutation mapping of node identifiers and connection identifiers, densification of gating conditions, and encapsulation of execution parameters, so that when the task assisting end participates in joint evaluation, it can only perform calculations based on the blinded intermediate representation, and cannot parse the key elements in the task definition.

[0037] refer to Figure 5 , Figure 5 This is a schematic diagram of a task assistance processing module provided in an embodiment of this application.

[0038] like Figure 5 As shown, the task assistance processing module can be logically divided into a probe score generation unit, a local contribution generation unit, a secret input generation unit, and a collaborative result generation unit. Each unit works collaboratively around the execution flow of the collaborative session to complete the joint evaluation without disclosing private data content, while suppressing the risk of counterfactual inference based on multi-round output differences. Specifically, the probe score generation unit generates a probe score based on request metadata associated with the collaborative session identifier. The local contribution generation unit generates true local contributions and corresponding counterfactual comparison local contributions based on private data. The secret input generation unit converts the hedging local contributions into a secret input form that conforms to the requirements of a secure multi-party computation protocol, such as a secret shared share or encrypted data block, and combines this with intermediate representation description information and secret gating parameters contained in the secret function load to participate in the joint evaluation process. The collaborative result generation unit participates in result integration after the joint evaluation is completed. In some implementations, the unit can send the intermediate results it helped generate to the task initiator or interact with other task assistants at the protocol level to complete the generation of the final result; in other implementations, the unit can also perform local consistency verification on the results or record session execution logs for subsequent auditing or policy adjustment.

[0039] Next, with reference to the accompanying drawings, the cross-domain data collaborative computation method based on secure multi-party computation and differential privacy provided in the embodiments of this application will be further elaborated. Figure 6 The method shown is applied to the task initiator of a distributed processing system. This distributed processing system can be understood as an architecture where multiple data-isolated computing nodes logically collaborate via a network. There is no centralized aggregation of raw data between the nodes; joint evaluation is achieved only through encrypted data interaction. The task initiator is used to initiate collaborative computing tasks and obtain collaborative computing results. The distributed processing system also includes multiple task assisting ends. Each task assisting end participates in the collaborative computing task based on private data configured within it and outputs the collaborative computing results. The method includes: S1: Determine the collaborative computing task to be executed, and generate an intent description object based on the collaborative computing task; The intent description object is used to characterize the task definition of the collaborative computing task; In this embodiment, collaborative computing tasks can originate from scenarios such as cross-organizational joint modeling, joint statistical analysis, or joint risk assessment. For example, multiple business entities may wish to jointly train a model to identify abnormal behavior or calculate the distribution characteristics of a certain type of rare event without exchanging original records. To avoid exposing the objects of interest or optimization preferences at the structural level in the task definition, the task initiator does not directly distribute tasks in the form of plaintext rules or explicit feature sets. Instead, it first performs structured parsing of the task configuration parameters input from the business side, extracting task definition elements such as target output type, target optimization preferences, and rules of the objects of interest, and constructs an intent description object based on this. This intent description object, as a unified expression of the abstract semantic layer, is used to carry the core constraints and evaluation direction of the collaborative task, but does not directly expose the strategy details that can be parsed by participating nodes. This can reduce the risk of task definition being profiled at the source, while providing standardized input for subsequent function compilation and blind processing.

[0040] S2: Generate an intermediate representation of the intent function based on the intent description object, and perform blind encoding on the intermediate representation to generate a dense-state function payload; In this embodiment, the intermediate representation can take the form of an intent operator graph, including multiple operator nodes connected by data flow and gate nodes for controlling the execution path. To avoid identifiable differences in structure between different task calibers, a unified basic evaluation skeleton is introduced during compilation, ensuring that different candidate task definition elements maintain consistency in topology and node type distribution, distinguishing the actual enabled path only through dense gating parameters. Subsequently, the intermediate representation undergoes blind encoding processing of the execution function, including permutation mapping of node identifiers and connection relationships, dense encapsulation of gating conditions, and abstract encapsulation of execution parameters, thereby generating a dense function payload. This allows the task assisting end to perform calculations only based on the blinded structure when participating in joint evaluation, and to be unable to infer task definition elements from the payload appearance or execution trajectory, thus helping to solve the technical problem of task intent leakage.

[0041] S3: Distribute the dense function payload to the task assisting end, and trigger the task assisting end to generate dense input based on its own private data and participate in joint evaluation, and introduce differential privacy processing in the joint evaluation process to generate collaborative computing results; In this embodiment, cross-node computation can be performed using methods such as secret sharing or homomorphic operations during the joint evaluation process. Differential privacy processing is introduced at the output stage, for example, adding noise conforming to a preset privacy budget or performing pruning and perturbation operations on the aggregation result to limit the impact of a single data sample on the result. It should be noted that those skilled in the art can choose appropriate secure multi-party computation protocols and differential privacy mechanisms based on the actual deployment environment, as long as the original data is not exposed during the joint evaluation process and controllable privacy protection capabilities are provided at the result level. This application does not impose further limitations. By combining intent blinding mechanisms with differential privacy processing, it is possible to simultaneously suppress the parsing of task definitions and the use of output differences for significance testing, without leaving the data domain, thereby improving the security and deployability of cross-domain collaborative computing in real-world engineering scenarios.

[0042] Before detailing the specific technical aspects of the steps, this application's embodiments need to reiterate: Cross-domain collaboration, in most implementation scenarios, is not a one-time offline computation, but a continuous interactive process carried out through sessions. The same type of task often needs to be triggered repeatedly under different data windows, different participant sets, and different strategy preferences. The computation process must not only meet the protocol constraints of secure multi-party computation, but also ensure the consistency of execution among all participants under conditions such as network jitter, node asynchrony, and resource differences. In such an environment, the key challenge faced by the task initiator is not just initiating a task, but how to transform the abstract business objective into an executable carrier that can be stably executed by multiple parties, reused in multiple rounds, and does not introduce additional leakage surfaces, so that collaborative computation can maintain consistency, clear boundaries, and controllable output in multiple rounds of operation.

[0043] It should be noted that the task initiator does not directly issue parsable rules to express collaborative tasks, but rather encapsulates the task definition into an executable form. The core of this executable approach lies not in expanding expressive power, but in breaking down the task definition into several composable evaluation components and organizing them into an evaluateable structure with a unified framework. This allows the same type of collaborative task to switch evaluation paths without altering its appearance when switching between different definitions.

[0044] Those skilled in the art will understand that common target preferences, constraints, and rules of interest in collaborative tasks often correspond to different branch calculations, different data selections, or different aggregation methods in engineering implementation. Directly mapping these differences to structural differences not only increases deployment complexity but also easily creates observable fingerprint information in cross-domain interactions. Therefore, when encapsulating the task definition, the task initiator converges the differential elements into gating selections and parameterized calls, and uses a unified evaluation skeleton to carry its execution flow. This ensures that task switching is more of an internal selection change than an external structural change, facilitating consistent execution behavior in subsequent multi-party joint evaluations.

[0045] Furthermore, the task initiator further blinds and encapsulates the executable carrier to reduce the possibility of participating nodes inferring the task definition from the carrier's appearance. Blinding is not simply hiding certain fields, but rather processing the executable structure to ensure the carrier retains its evaluable capabilities while minimizing explicit clues that can be exploited by structural analysis, node pattern statistics, or connection relationship parsing. For example, node identifiers and connection relationships can be recoded using permutation mapping, and gating conditions can be made unparseable through encrypted encapsulation and selection parameter binding. This ensures that participating nodes, during execution, can only perform the action of evaluating according to the path specified by the carrier, making it difficult to establish an interpretable correspondence between that path and specific business meaning. Therefore, the focus of processing on the task initiator side is on enabling the task definition to be reused across domains in an executable but unparseable form, rather than requiring participating nodes to understand or confirm the task semantics. From an engineering perspective, this aligns better with the interaction boundary in cross-domain collaboration where only executable functionality is required.

[0046] It should be noted that the encapsulation method described above at the task initiation end does not depend on a specific business domain or a specific data type. The operational data involved in collaborative tasks can be collected according to the actual situation. The specific types can be transaction record characteristics, equipment operating parameters, business behavior logs, or other data representations that can at least support the evaluation of the target. The specific granularity of the task definition elements can also be adjusted according to the business side configuration, as long as they can be mapped to a unified evaluation skeleton and form an evaluable carrier.

[0047] Next, we will further elaborate on the technical content of the method of this application regarding the object of intent description.

[0048] In this embodiment, the collaborative computing task exists as task configuration parameters before entering the executable encapsulation process. These parameters can originate from business-side input, policy engine output, or structured descriptive information generated by the scheduling module. They typically include output metric types (e.g., classification probability, risk score, aggregate statistics), optimization objectives (e.g., minimizing the loss function, maximizing accuracy, finding the optimal solution that satisfies constraints), and attention rules for specific sample sets or feature sets. To avoid semantic ambiguity or structural overflow during subsequent compilation, this embodiment performs structured parsing on the task configuration parameters. Structured parsing is not simply reading fields; it maps the task configuration parameters to an internally unified data structure, such as a key-value pair set, rule tree structure, or abstract syntax tree, transforming task objectives, constraints, and filtering conditions into traversable and composable intermediate semantic units. This method reorganizes business constraints, originally scattered across different fields, into a set of task definition elements with clear semantic boundaries, providing precise input for subsequent function construction and structure encapsulation.

[0049] Furthermore, in the process of extracting task definition elements, this embodiment adopts a hierarchical classification strategy for different types of elements. For example, the target output type usually corresponds to the numerical form or distribution form of the final result, which can be converted into a unified output interface description through a preset output mapping table; the target optimization preference can be parsed into a loss function form or a constraint function form, and further standardized into an internally callable evaluation template; the rules of interest can be abstracted into sample selection operators or feature selection operators, and converted into filtering nodes that can be attached to the subsequent operator graph through rule expressions. Through this hierarchical parsing and template mapping mechanism, task configuration parameters from different sources and in different forms of expression have been organized into basic components under a unified semantic framework before entering the intent description object construction stage. Those skilled in the art will understand that the above template mapping and rule abstraction can be extended or replaced according to specific business scenarios, as long as the task configuration parameters can be converted into a set of definition elements with a clear structure and well-defined semantic boundaries. This embodiment does not limit the specific expression form.

[0050] Furthermore, when constructing the intent description object, this embodiment does not directly retain the original task configuration fields. Instead, it encapsulates the parsed task definition elements into internal data structure instances, such as a combined object containing output description units, optimization description units, and filtering description units. A unique identifier and version identification information are attached to each type of element. This intent description object can fully express the evaluation direction and constraint boundaries of the collaborative computing task while avoiding exposing the naming conventions or organizational forms of the original business-side fields, thus achieving a semantically complete yet visually abstract effect.

[0051] It should be noted that the specific generation method of the intent description object in this application does not depend on any particular implementation framework. Those skilled in the art can refer to existing rule engine modeling techniques, abstract syntax tree construction techniques, or Domain Specific Language (DSL) parsing techniques to convert task configuration parameters into internal semantic structures. For example, lexical and syntactic analysis of configuration parameters can be performed using predefined task syntax templates to generate corresponding syntax tree node sets; or pattern matching of the target function and constraint expression can be performed using a rule engine to map them to instances of preset operator templates; or a configuration-driven parameter mapping table can be used to establish a one-to-one correspondence between business fields and internal function templates. The key to this embodiment is not the selection of any specific parsing tool, but rather that through semantic normalization, the task definition elements are standardized into composable, replaceable, and identifiable components before entering the subsequent function generation stage, thereby ensuring that the intent description object has clear semantic boundaries and a stable structural form. This application does not further limit the specific parsing algorithm or modeling tool, as long as it can achieve the mapping of task configuration parameters to a unified semantic object.

[0052] Next, we will further elaborate on the technical content of the method of this application regarding the dense state function load.

[0053] The specific steps of S2 are as follows: S2.1: Determine an intent function based on the intent description object, wherein the intent function is used to characterize the evaluation rules of the collaborative computing task; Specifically, although the intent description object has completed the semantic normalization of task configuration parameters, it is still at the definition layer and cannot be directly used for multi-party joint evaluation. In engineering implementation, the input-output boundaries, computation path boundaries, and reusable operator granularity required for secure multi-party computation all need to be solidified in the form of executable rules. Otherwise, differences in understanding of the same task by different participating nodes can easily occur, leading to misalignment in joint evaluation or drift in interpretation across multiple rounds of sessions. Based on this, the intent function is responsible for bringing the set of task definition elements into a set of executable evaluation rules, enabling elements such as target output type, optimization preferences, and rules of interest to be invoked and combined within the same evaluation framework, while avoiding the direct spillover of appearance information such as business field naming and rule text into the executable structure.

[0054] In one example, determining the intent function based on the intent description object includes: S2.1.1: Determine a set of candidate task definition elements based on the intent description object, wherein the set of candidate task definition elements is used to characterize multiple optional evaluation methods of the collaborative computing task; Specifically, in the definition of cross-domain collaborative tasks, many elements are not single, fixed values, but rather represent engineering realities with optional interpretations or assumptions. For example, the same risk assessment task may simultaneously have multiple output interpretations (probability, score, level), multiple optimization preferences (robustness, sensitivity, different cost weights), and multiple rules for the objects of focus (by population, by event, by window). If a certain interpretation is directly fixed as the only execution path during the intent function determination stage, subsequent changes in interpretation can easily lead to additions or deletions of executable structures. This increases the management cost of multiple rounds of reuse and also introduces observable clues due to differences in appearance.

[0055] In this embodiment, the determination of the candidate task definition element set can be processed in three steps: element domain partitioning, candidate option enumeration, and compatibility constraints. Element domain partitioning decomposes the task definition in the intent description object into several element domains, including at least the output domain, optimization domain, focus domain, and constraint domain. Candidate option enumeration extracts options within each element domain. For example, in the output domain, scalar score output, vector probability output, and segmented level output can be enumerated; in the optimization domain, standard loss template, robust pruning template, and cost-sensitive template can be enumerated; in the focus domain, full sample, rule-based sample selection, and window-aggregated sample selection can be enumerated; and in the constraint domain, unconstrained, threshold constraints, interval constraints, and penalty term constraints can be enumerated. Compatibility constraints are used to eliminate candidate option combinations that cannot be simultaneously valid or cannot be combined. For example, when segmented level output is selected for the output domain, certain templates related to continuous variables in the optimization domain can be replaced with templates consistent with segmentation; when window aggregation is selected for the focus domain, sample-level constraints in the constraint domain are mapped to window-level constraints. The aforementioned candidate set can be organized in the data structure as a candidate list with version numbers. Each candidate must record at least: candidate identifier, its associated feature domain, dependent preconditions, mapping number to the operator template, and default activation priority.

[0056] S2.1.2: Construct a gating selection rule for the candidate task definition element set, wherein the gating selection rule is used to map the candidate task definition elements to a gating vector, and wherein the gating vector is used to indicate the set of operator nodes to be enabled in the intent function; Specifically, once the set of candidate task definition elements is determined, it is still necessary to transform which candidate to select into an executable control variable. Otherwise, the candidate set is merely a static list and cannot drive the intent function to form stable evaluation rules. A common engineering mistake is to issue selection rules directly as plaintext conditions or plaintext fields, allowing participating nodes to infer the task scope from the rule text or parameter distribution. The introduction of gating selection rules constrains the selection process to make choices at predetermined positions and expresses the selection results as gating vectors, thereby converging the scope differences into a fixed form of control variable, providing a clear entry point for subsequent encrypted encapsulation.

[0057] In this embodiment, the gating selection rules can be constructed using rule templates, conflict resolution, and normalized encoding. Rule templates define the selection method for each feature domain; for example, the output domain uses single-selection rules, the optimization domain uses single-selection or multi-selection rules, the focus domain uses single-selection rules, and the constraint domain uses multi-selection rules. Conflict resolution handles the mutual exclusion and dependency relationships between candidate options. For example, when the focus domain selects window aggregation, some sample-level candidate constraints in the constraint domain are automatically downgraded to window-level candidate constraints. When the optimization domain selects robust pruning, the weight range in the cost-sensitive template is limited to a preset interval to avoid numerical drift. Normalized encoding converts the above selection results into gating vectors: the gating vectors can be segmented and encoded by feature domain, with each segment corresponding to a set of candidate options for one feature domain. One-hot or multi-hot encoding is used within each segment to indicate the enabled state. To facilitate the execution end's location of the gating vectors, the segment boundaries and intra-segment positional order of the gating vectors remain fixed within the session, and the corresponding positional index table is recorded in the intent description object. The positional index table should include at least: feature domain number, mapping relationship from candidate identifier to gate position, mutual exclusion group number, and dependency group number.

[0058] For example, the following is a specific example of gating vector mapping. For ease of explanation, assume that the candidate task definition feature set is divided into four segments according to the feature domain: output domain, optimization domain, focus domain, and constraint domain. The segment length and position index are pre-fixed for each segment in the intent description object, so that the position order of the gating vectors within the same collaborative session remains consistent and can be stably referenced by the gating nodes. Specifically, the output domain is set as a single-selection segment, containing three candidate output types: candidate O1 is "scalar score output", candidate O2 is "vector probability output", and candidate O3 is "segmented level output", with a fixed segment length of 3 bits and a corresponding bit order of [01, 02, 03]; the optimization domain is set as a single-selection segment, containing four candidate optimization preferences: candidate P1 is "standard evaluation template", candidate P2 is "cost-sensitive template", candidate P3 is "robust pruning template", and candidate P4 is "constraint priority template", with a fixed segment length of 4 bits and a corresponding bit order of [P1, P2, P3, P4]; the attention domain is set as a single-selection segment, containing three candidate... The selection rules are as follows: Candidate F1 is "All objects participate", candidate F2 is "Select objects according to rules", and candidate F3 is "Aggregate objects by window". The segment length is fixed at 3 bits, and the corresponding bit order is [F1, F2, F3]. The constraint domain is set to a multi-select segment, containing four types of candidate constraint items: Candidate C1 is "No additional constraints", candidate C2 is "Threshold constraints", candidate C3 is "Interval constraints", and candidate C4 is "Penalty constraints". The segment length is fixed at 4 bits, and the corresponding bit order is [C1, C2, C3, C4]. C1 is mutually exclusive with the other constraint items and is used to represent a placeholder state where no additional constraints are enabled. Through the above fixed bit order design, the total length of the complete gating vector is fixed at 14 bits, and each bit has a stable meaning within the session.

[0059] In this embodiment, the gating selection rule can be executed in the order of "selection within the domain first, cross-domain resolution second, and encoding output last". Specifically, among the task definition elements obtained after the task configuration parameters are structured and parsed, if the target output type is risk scoring, then O1 is selected in the output domain; if the target output is category probability, then O2 is selected; if the business side requires output in the form of levels, then O3 is selected. The selection within the optimization domain is related to the target optimization preference. For example, when the task definition element contains cost weight or misjudgment cost preference, P2 is selected first; when the task definition element contains robustness preference or outlier suppression preference, P3 is selected; when the task definition element explicitly requires constraints to be satisfied first, P4 is selected; otherwise, P1 is selected by default. The selection within the attention domain is related to the attention object rule. For example, when the rule points to a specific group of people or event set, F2 is selected; when the rule points to a sliding window or time aggregation caliber, F3 is selected; otherwise, F1 is selected. Multiple-select encoding is used within the constraint domain: if the task definition elements include "upper limit threshold" type constraints, then select C2; if they include "upper and lower bound range" type constraints, then select C3; if they include "soft constraint penalty" type preferences, then select C4; when C2, C3, and C4 are not selected, C1 is automatically set as a placeholder. After the above selections are completed, conflict resolution is performed based on the mutual exclusion group and dependency group. For example, when the domain of concern is F3, if there is a sample-level threshold constraint in the constraint domain, its scope is mapped to a window-level threshold constraint and C2 is kept set, but at the same time, the set is marked as "window scope" in the position index table; when the optimization domain is P3, if the cost weight belongs to one of the optional intervals given by the business side, the interval level identifier is recorded in the position index table, and the level is mapped to the parameter slot inside the P3 template, without adding an additional gate position, to avoid the gate vector length changing with the parameter level.

[0060] S2.1.3: Perform dense state processing on the gate vector to generate dense state gate parameters, and combine the dense state gate parameters with a preset basic evaluation skeleton to determine an intent function containing gate logic and evaluation logic; The basic evaluation skeleton is a general evaluation structure corresponding to the set of candidate task definition elements, and it remains consistent under different sets of candidate task definition elements.

[0061] Specifically, once a gating vector exists in plaintext, even without containing intuitive semantic text, it can still reveal the selection trend of the task caliber through bitmap patterns, activation ratios, or cross-round variation patterns. Therefore, gating vectors need to be decrypted so that participating nodes can use this control quantity to complete branch selection and composition during joint evaluation, but the specific bit values ​​of the gating vector cannot be recovered locally. Furthermore, if the introduction of gating logic is implemented by adding / removing operator modules, the intent function structure will change with the caliber, which is detrimental to consistent execution across multiple rounds.

[0062] In this embodiment, the encryption of the gated vector can be implemented according to the secure multi-party computation mechanism adopted: if secret sharing is used for joint evaluation, encryption can split the gated vector into multiple shares bit by bit and allocate each share to different participating nodes, so that a single node cannot obtain the complete gated bits; if encrypted encapsulation is used for joint evaluation, encryption can encapsulate the gated vector into an encrypted control block and attach an interface description for execution by the gated nodes, so that participating nodes can only call the selection / composition operation and cannot parse the content of the control block. To ensure the feasibility of gated node execution, the encrypted gating parameters can also include gated bit length information, segment boundary information, and a binding table with the gated node identifier, so that the execution end can correctly route the encrypted gating parameters to the corresponding gated node. Subsequently, the encrypted gating parameters are combined with the basic evaluation skeleton: the basic evaluation skeleton can be defined as a fixed evaluation process framework, including a sequence of nodes such as input preprocessing, candidate module placeholders, branch composition, and output shaping, wherein the actual output of the candidate module is selected by the gated node. The skeleton node sequence is not changed during assembly. Instead, the dense gating parameters are injected into the gating sites of the skeleton as runtime control variables.

[0063] It should be noted that the specific form of the basic evaluation skeleton in this application is not limited to the description of operators or operator nodes. It can be represented as a set of predefined computational unit arrangements, a evaluation flow template with a fixed calling order and fixed data interface, or an execution script description or instruction sequence description oriented towards a joint evaluation protocol. Those skilled in the art will understand that the so-called basic evaluation skeleton emphasizes a evaluation framework with a stable structural appearance, fixed calling interface, and repeatable execution, and does not limit it to adopting a specific graph structure.

[0064] Taking the evaluation process template as an example, the basic evaluation skeleton is constructed as follows: The task initiator predefines a set of general process segments, each corresponding to a fixed functional step, and configures a unified data input / output interface and parameter slots for each process segment. For example, a process segment may include: an input normalization segment, used to perform format alignment and necessary range constraints on the dense inputs submitted by participating nodes; a candidate logic segment, used to carry calculation branches corresponding to multiple optional evaluation calibers, with several branch slots reserved within this segment, the number and position of which remain fixed within the session; a result synthesis segment, used to select, merge, or bypass multiple branch outputs generated by the candidate logic segment according to control variables, and output a single-path result; and an output shaping segment, used to perform type shaping, dimension alignment, or format encapsulation of the result to meet the target output type. The process segments are concatenated in a fixed order within the template, forming a compileable and blindable basic structure through segment identifiers and interface description files.

[0065] S2.2: Compile the intent function into an intermediate representation, the intermediate representation being an intent operator graph, the intent operator graph including multiple operator nodes connected by data flow and at least one gate node for controlling the execution path of the operator nodes; Specifically, while intent functions, as a set of rules, are closer to the logic layer in their expression, they are still insufficient to directly drive the joint evaluation process of secure multi-party computation. Joint evaluation typically requires breaking down the computation process into a sequence of operators that can be executed step-by-step under a multi-party protocol, and clearly defining the data dependencies and execution order between operators. If execution is directly driven by branch rules or dynamic configuration, different communication and computation paths can easily arise at the protocol interaction layer, leading to observable differences for participating nodes and increasing implementation and scheduling complexity.

[0066] In one example, compiling the intent function into an intermediate representation includes: S2.2.1: Construct a hypergraph skeleton based on the intent function, wherein the hypergraph skeleton includes multiple template subgraphs, and the template subgraphs are used to correspond to different candidate task definition elements in the candidate task definition element set respectively; Specifically, while intent functions already possess evaluation rules at the logical level, when directly expanded into a conventional data flow structure according to these rules, different calibers will naturally exhibit different structural fingerprints. For example, some calibers may exhibit additional filtering branches, additional constraint checking links, or additional specific preprocessing or post-processing stages. These structural differences are indirectly perceived by participating parties in cross-domain collaboration through dimensions such as protocol interaction, message length, execution rounds, and node in-degree and out-degree, thus forming extrapolation clues for task definitions. Therefore, this embodiment prioritizes the construction of the intermediate representation as the construction of the hypergraph skeleton: the hypergraph skeleton is not simply a matter of piecing together all calibers, but rather a predefined, stable combination framework, ensuring that any subsequent changes in calibers can only be completed within the slots reserved in the skeleton, avoiding the creation of new structures outside the skeleton. The so-called template subgraph is not a direct representation of a particular caliber, but rather a replaceable fragment abstracted from the computational form of candidate elements, ensuring that the fragments have a unified interface and a unified appearance scale.

[0067] In this embodiment, the construction of the hypergraph skeleton can be completed according to the process of skeleton partitioning - subgraph templated formatting - interface constraint solidification. Skeleton partitioning refers to decomposing the evaluation process of the intent function into several fixed partitions, such as input normalization partitions, candidate feature calculation partitions, constraint processing partitions, and composite output partitions, and setting fixed input and output interfaces for each partition, such as dividing into data types, dimensions, sequence numbers, and the number of optional parameter slots. Subgraph templated formatting refers to generating a template subgraph for each type of candidate feature in the candidate task definition feature set. The template subgraph contains the arrangement of the calculation units corresponding to the candidate feature, but its entry and exit interfaces are strictly aligned with the partition interfaces; for example, for candidate features with different output calibers, the template subgraphs all output a "unified output carrier" of the same dimension, and the difference lies only in the different ways of filling the carrier inside the template subgraph; for candidate features with different optimization preferences, the template subgraphs all output the same type of preference adjustment carrier, and the difference lies in the different internal adjustment strategies. Interface constraint solidification refers to writing the interface descriptions of the above-mentioned entry and exit points into the intent description object or compilation configuration, and making whitelist constraints on the intermediate data types allowed to appear inside the template subgraph and the set of basic operations that can be called, so as to avoid the difference in execution cost or interaction rounds caused by the introduction of special operations for a certain candidate element.

[0068] S2.2.2: In the hypergraph skeleton, a semantic bypass component is configured for at least a portion of the template subgraphs, the semantic bypass component including a main operator node, a bypass operator node, and a synthesis node for selective synthesis between the outputs of the main operator node and the bypass operator node; Specifically, the hypergraph skeleton alone is insufficient to resolve execution trajectory clues. In multi-party joint evaluation, even with a fixed topology, if inactive candidate branches are not executed at all or the execution path is significantly shortened, there may still be alignable differences in communication interaction counts, execution time distribution, and message packet size. Semantic bypass components are used to ensure that the computational path corresponding to each candidate element always has an executable output without changing the skeleton's appearance, and converges uniformly into a single path at the output synthesis point. This allows participating parties to only see consistent execution, consistent output generation, and consistent use of the same synthesis entry point, making it difficult to infer the choice of approach based on whether a path is executed. The key to semantic bypass is that the bypass output is not an arbitrary constant, but rather maintains compatibility with the main path output in terms of interface, scale, and numerical range, ensuring that the synthesis behavior is stable and executable in engineering.

[0069] In this embodiment, semantic bypass components are configured at the exit points of at least some template subgraphs, and different bypass implementation methods can be selected according to the type of template subgraph. The main node carries the output of the regular computation path of the template subgraph, bypass nodes generate bypass outputs, and synthesis nodes complete a unified selection or merging between the main output and bypass outputs. The bypass nodes can be implemented using three methods: equivalent pass-through, empty carrier filling, and scale alignment mapping. When the template subgraph itself filters or transforms the input, the bypass node can output the pass-through result of the input and format it in the same way as the main output. When the template subgraph itself generates a certain type of supplementary information, the bypass node can generate an empty carrier of the same dimension and fill it with a preset filling value, which can be taken from the default safe value or historical statistical average of that dimension. When the template subgraph itself involves range pruning or scale adjustment, the bypass node can first perform the same scale alignment processing, and then output a bypass result with the same distribution scale as the main output, to avoid abnormal distribution of the synthesis node in the numerical range. The behavior of the composition node is fixed within the session, such as being fixed as a binary output or a weighted merge output, and the input and output interfaces of the composition node are aligned with the skeleton partition interface to ensure that there are no appearance differences due to changes in the composition node type.

[0070] S2.2.3: Determine the control quantity of the gate node corresponding to the semantic bypass component based on the dense gating parameters, and associate the gate node with the synthesis node; Specifically, the composition behavior of semantic bypass components requires control variables to drive it; otherwise, it can only output a fixed main path or a fixed bypass path, failing to support caliber switching. Furthermore, if the control variables exist in plaintext, the caliber selection may still be revealed through bitmap patterns and variation rules. Therefore, the control variables must be derived from dense gating parameters and bound to the composition node in a form that is "available at the execution end but semantically unsolvable," ensuring that the composition node only performs the selection action during execution without obtaining the selection basis. The association in this application is not equivalent to writing resolvable rules into the payload, but rather establishes a binding relationship: which composition entry point the control variable corresponds to, which template subgraphs its scope covers, and the session boundaries where the control variable takes effect are all clearly defined.

[0071] In this embodiment, the dense gating parameters may include the dense representation of the gating vector and the dense reference identifier of the gating bit order index table. The process of determining the control quantity of the gating node may include: reading the gating bit position identifier corresponding to the current template subgraph in the dense gating parameters; extracting the corresponding dense control segment from the dense gating vector according to the position identifier; and encapsulating the dense control segment into a control quantity handle that can be directly used by the synthesis node. The control quantity handle may be a control flag, a dense selection index, or a set of dense weight shares, the specific form of which depends on the support method of the joint evaluation protocol for the "selection / synthesis" operation. Subsequently, the control quantity handle is associated with the synthesis node: the association information includes at least the synthesis node identifier, the main input port identifier, the bypass input port identifier, and the control quantity handle identifier, so that when the execution end runs to the synthesis node, it can bind the control quantity handle to the corresponding port, thereby completing the selection synthesis of the main / bypass output. This association information may be encoded as part of the intermediate representation, but does not contain gating condition semantics, only the binding relationship between the control quantity and the node port.

[0072] S2.2.4: Bind the hypergraph skeleton to the semantic bypass component to generate an intermediate representation; Specifically, the process of binding the hypergraph skeleton with semantic bypass components determines the executable boundary and appearance consistency boundary of the final intermediate representation. If the binding method is not standardized, for example, different candidate features are added to the skeleton at different insertion positions or with different port specifications, it will lead to differences in field arrangement, connection density, and execution order hints in the intermediate representation. On the other hand, if the binding is too coarse, resulting in misaligned interface conversions between the bypass components and the skeleton, it will also introduce additional format adjustment paths during execution, causing inconsistent execution overhead. Therefore, the binding process needs to accomplish two things simultaneously: first, strictly align the entry and exit points of each template subgraph with the skeleton partitioning interface; second, insert the semantic bypass components at fixed positions and with fixed ports at the connection points between the template subgraph and the skeleton, so that the final intermediate representation has a stable appearance at both the topology and encoding levels.

[0073] In this embodiment, the binding process can be completed by interface alignment, component insertion, and execution sequence solidification. Interface alignment includes checking whether the ingress data format of each template subgraph is consistent with the skeleton partition ingress and whether the egress format is consistent with the composite node ingress. If there are differences, a fixed-format shaping unit is added inside the template subgraph to make the shaping path consistent across all candidate features. Component insertion includes inserting a semantic bypass component at the template subgraph egress and connecting the composite node output to a fixed input port of the downstream partition of the skeleton. The insertion position is consistent within the same feature domain. For example, all template subgraphs in the output domain insert bypass components at the output shaping partition egress, and all template subgraphs in the optimization domain insert bypass components at the "preference adjustment partition" egress. Execution sequence solidification includes generating a session-fixed execution plan description for the final intermediate representation. For example, it lists the executable units in partition order, lists the dependency readiness conditions and data buffer locations, so that the execution end can complete the joint evaluation in a unified order. The above execution plan description does not need to expose semantics; it only needs to provide the information required for scheduling.

[0074] For example, the following is an easy-to-understand example illustrating how intent functions are compiled into intermediate representations and form a carrier structure that can be jointly evaluated and executed. This example is only used to explain the mapping methods of orchestration links, interface alignment, and gating control; the selected parameters and values ​​are illustrative and do not represent actual calibration results or engineering recommendations.

[0075] Specifically, assuming that in the intent description object of a certain collaborative computing task, the target output type is normalized to a scalar score, there are two optional approaches to target optimization preferences: one is a robust pruning approach, and the other is a cost-sensitive approach; there are two optional approaches to the rules for the objects of interest: one is full object participation, and the other is object selection according to rules; there are two optional approaches to the constraints: one is no additional constraints, and the other is threshold constraints. To ensure the stability of the subsequent carrier appearance, the intent function is logically organized into a fixed evaluation process template: input normalization segment - candidate feature calculation segment - constraint processing segment - synthetic output segment, where the input and output interfaces of each segment are fixed within the session. For example, the input normalization segment outputs a unified input carrier U, which is defined as a feature vector of length 8; the candidate feature calculation segment outputs a unified intermediate carrier V, which is defined as an intermediate vector of length 4; the constraint processing segment outputs a unified constraint carrier W, which is defined as a constraint vector of length 2; and the synthetic output segment outputs a scalar score S. Therefore, although the internal processing differs for different apertures, the carrier type and length presented externally by the template remain consistent, ensuring that the interface of subsequent intermediate representations does not change due to aperture differences.

[0076] In this example, the hypergraph skeleton is first constructed during the compilation phase. The hypergraph skeleton is organized into four fixed partitions, and three template subgraph slots are reserved within the candidate feature calculation segment, corresponding to optimization preference candidate slots, attention rule candidate slots, and constraint candidate slots, respectively. Taking the optimization preference candidate slot as an example, this slot contains two template subgraphs: one template subgraph corresponds to the robust pruning caliber, internally mapping the input carrier U to the intermediate carrier V1; the other template subgraph corresponds to the cost-sensitive caliber, internally mapping the input carrier U to the intermediate carrier V2. Both have an input carrier U of length 8 and an output carrier V of length 4, with the output fields in the same order. For example, the four components of V are defined as the main scoring component, preference correction component, stability component, and retention component, respectively. The only difference between the different template subgraphs is how these components are filled. The candidate slots for the focus rules also contain two template subgraphs: a full-caliber output intermediate carrier V3 and a filtered-caliber output intermediate carrier V4, both with an output of length 4 (V). The candidate slots for constraints contain two template subgraphs: an unconstrained-caliber output constraint carrier W1 and a threshold-constrained-caliber output constraint carrier W2, both with an output of length 2 (W). For ease of explanation, a set of illustrative input carriers U can be given, for example, U=[2.0, 1.5, 0.3, 4.0, 0.8, 1.2, 3.3, 0.6]. This carrier is only used to illustrate interface alignment and branch orchestration and does not limit its business semantics.

[0077] Furthermore, semantic bypass components are configured for the aforementioned template subgraph slots in the hypergraph skeleton. Taking the optimization preference candidate slot as an example, after robustly pruning the template subgraph output V1, the bypass component simultaneously prepares a bypass output B1. The bypass output B1 is compatible with V1 in terms of interface and scale. For example, B1 can be obtained from the input carrier U through fixed shaping to a carrier of length 4, illustrated as B1=[0, 0, 0, 0] or B1=[mean fill, mean fill, 0, 0]. Its fill value can be taken from the median level of the historical carrier V. After the cost-sensitive template subgraph output V2, the bypass component similarly prepares a bypass output B2 and sends the main output and bypass output to the synthesis node to form a single-path output. The same applies to the attention rule candidate slots and constraint candidate slots; each template subgraph output is configured with a bypass output and a synthesis node, ensuring that even if a certain caliber is not enabled, the slot still produces a consistent output and participates in subsequent synthesis links, avoiding significant differences in execution rounds or message bodies. To visually demonstrate the behavior of "bypass output compatibility," an illustrative bypass padding strategy can be given: When the carrier length is 4, the bypass output adopts the method of "taking the historical median value for the first two dimensions and zero for the last two dimensions." Assuming the historical median value is 1.0, the bypass output can be represented as [1.0, 1.0, 0, 0]. When the carrier length is 2, the bypass output adopts the method of maintaining a safe default range when threshold constraints are not enabled, represented as [0, 0]. The above values ​​are only used to illustrate the consistency constraints between the bypass output and the main output in terms of dimensions, field order, and scale.

[0078] Based on this, dense gating parameters are used to derive control variables and establish binding relationships for each synthesized node. For example, the gating vector is segmented and encoded by feature domain and its position is fixed within the session: the optimization preference segment is 2 bits, corresponding to [robust pruning, cost-sensitive]; the attention rule segment is 2 bits, corresponding to [full range, filtering]; and the constraint segment is 2 bits, corresponding to [no constraint, threshold constraint]. Assuming the current session selects robust pruning, filtering, and threshold constraints, the gating vector can be understood semantically as [1, 0 | 0, 1 | 0, 1], but in the intermediate representation, it only represents a dense control segment. The plaintext semantics are only for illustrative purposes; in this application, it can be specifically understood as a Boolean value expression. The dense gating parameters record the gating position index, binding the synthesized node in the optimization preference slot to the first gating control segment, the synthesized node in the attention rule slot to the second gating control segment, and the synthesized node in the constraint slot to the third gating control segment. This binding relationship is written into an intermediate representation in the form of a synthesis node identifier - main input port - bypass input port - control variable handle. This allows the execution end to select and synthesize the main / bypass output without parsing the gating semantics when running to the corresponding synthesis node. For ease of understanding, this binding relationship can be schematically described as follows: the optimization preference synthesis node A_P receives (V1, B1) and outputs V according to the control variable handle K_P; the attention rule synthesis node A_F receives (V3, B3) or (V4, B4) and outputs V' according to the control variable handle K_F; the constraint synthesis node A_C receives (W2, B5) and outputs W according to the control variable handle K_C. The above handles only represent references to control variables and do not contain readable gating bit values. It is understood that the aforementioned received content, such as (V1, B1), all represent the corresponding nodes. This application is only an exemplary description.

[0079] S2.3: Generate node identifiers and connection identifiers for at least some of the operator nodes and their node connection relationships in the intermediate representation, and perform permutation mapping processing on the node identifiers and connection identifiers to obtain topological description information; Specifically, the intent operator Figure 1 Once distributed in plaintext topology, even if participating nodes cannot resolve the gating conditions, they may still structurally profile the task caliber through node types, connection patterns, and subgraph structure patterns. To reduce the risk of such profiling without affecting joint evaluation, the interpretable appearance of the operator graph needs to be processed so that the externally visible node numbers, connection relationships, and subgraph boundaries no longer maintain a stable correspondence with the real semantic modules. Permutation mapping is an engineering-feasible and cost-controllable blinding method. Its key is that the executor can still complete the correct data flow scheduling based on the blinded topology description, while the observer cannot restore the blinded identification system to the original semantic modules.

[0080] In this embodiment, node identifiers and connection identifiers can be generated using a hierarchical numbering method: First, an internal node identifier is assigned to each operator node, which can be generated based on the node type, creation order, and the subgraph number to which it belongs; then, a connection identifier is assigned to each data flow edge, which can be generated based on the source node identifier, target node identifier, and port number. After the initial identifiers are completed, a permutation mapping process is performed on the node identifiers and connection identifiers: the permutation mapping can be driven by a session random seed to generate a set of bijective mapping tables, which are applied to the node identifier set and the connection identifier set respectively; constraints can be introduced when generating the mapping table to ensure that the same node type still falls into the same type domain after permutation, so as to ensure that the executor can quickly locate the operator implementation during scheduling, while avoiding execution errors caused by cross-type mapping. After the permutation mapping is completed, topology description information is formed, which includes at least: a list of nodes after permutation, a list of connections after permutation, port definitions for each node, and execution order hints.

[0081] S2.4: Perform dense state processing on the gating conditions associated with the gating node in the intermediate representation to generate dense state gating conditions; Specifically, gating nodes carry the selection logic among the elements defining candidate tasks, and their gating conditions often directly reflect the rules of interest, preference switching, or caliber selection. If the gating conditions are expressed in plaintext or exist in an inferable encoded form, even if the operator graph topology has been replaced, it is still possible to infer the task caliber from the content of the gating conditions.

[0082] In this embodiment, the densification of gating conditions can be divided into two stages: condition normalization and condition encapsulation. The condition normalization stage normalizes the diverse expressions of the gating conditions, such as rule trees, Boolean expressions, threshold judgments, and set inclusion relationships, into a unified gating input form, for example, a set of gating bit vectors or gating selection indices. Each bit in the gating bit vector corresponds to the enabled state of a candidate subgraph, and the gating selection index is used to select one from multiple candidate outputs. The condition encapsulation stage densifies the gating bit vectors or selection indices: it can use a secret sharing method to decompose the gating bits into multiple shares, or it can use an encrypted encapsulation method to hide the gating bits in an encrypted payload, and provide an evaluation interface matching the gating node. To ensure the gating node is executable, the densified gating conditions also carry input / output interface constraints for the gating node, such as dimensional consistency specifications for candidate outputs and specifications for the composition operator type of the composition node, such as selection composition, weighted composition, or bypass composition, so that the task assistant can complete the composition calculation according to the payload.

[0083] S2.5: Generate the dense state function load based on the topology description information and the dense state gating condition; Specifically, dense function payloads are used to carry executable blinded operator graphs and non-resolvable gating control variables, enabling task assistants to perform joint evaluation without understanding the task definition. If the payload encoding lacks a unified structure, differences in payload size, field arrangement, or metadata distribution among different task instances can easily arise, leading to issues with inferability of appearance and protocol compatibility. Therefore, a fixed encapsulation format is needed when generating payloads to combine topology description information, dense gating conditions, and execution parameters into a directly resolvable execution package, ensuring that the payload is reusable within a session and isolated across sessions.

[0084] In this embodiment, the encapsulation of the dense function payload can include three types of fields: First, a topology description field, used to carry the permuted node list, connection list, port definitions, and execution order hints, and may include an index table of node types to operator implementations, enabling the task assistant to construct an execution plan accordingly; second, a gating encapsulation field, used to carry the dense gating conditions and their binding relationship with gating nodes, such as a correspondence table between gating condition identifiers and gating node identifiers, and a mapping table from candidate output ports to gating bits; third, an execution parameter field, used to describe the protocol parameters required for joint evaluation, such as session identifier, round count, message format version, fault tolerance retry boundary, and differential privacy processing call entry identifier. After encapsulation, the payload can be further supplemented with integrity verification information, such as payload digest and version number, so that the task assistant can determine whether the payload has been replaced or truncated after receiving it. This integrity verification does not require the disclosure of payload content, but is only used to ensure execution consistency.

[0085] Next, with reference to the accompanying drawings, we will further elaborate on another cross-domain data collaborative computation method based on secure multi-party computation and differential privacy provided in the embodiments of this application. Figure 7 The method shown is applied to a task assisting end of a distributed processing system. The task assisting end participates in collaborative computing tasks based on private data configured within it. The distributed processing system also includes a task initiating end, which initiates collaborative computing tasks and obtains collaborative computing results. The task initiating end further includes sending a dense function payload to the task assisting end. The method includes: A1: Determine the cooperative session identifier corresponding to this joint evaluation based on the dense state function load; Specifically, during multi-round joint evaluation, the task assisting end simultaneously receives encrypted function payloads from different tasks. Without stable session identifier binding, mismatches between request metadata and execution context can easily occur, leading to deviations in subsequent probing scores, blending coefficients, and execution plan references. Since encrypted function payloads contain executable structures and gating binding information, they inherently possess session-level consistency characteristics, making them suitable as a source of session identifiers. However, these identifiers need to be generated without exposing task semantics and must remain consistent when repeatedly receiving the same session payload.

[0086] In this embodiment, the collaborative session identifier is derived from fixed fields of the dense function payload. These fixed fields include at least the payload format version number, a digest field for topology description information, a digest field for gating binding information, and a session random number fragment provided by the initiator. The task assistant can concatenate these fields in a preset order and perform a digest operation to obtain the session identifier. The digest operation can be implemented using existing digest algorithms, with a fixed output length for easy index management. To avoid duplicate identifiers between different sessions, the session random number fragment can be generated by the initiator during session initialization and written into the fixed payload fields. The task assistant only uses it to derive the identifier and does not need to parse its source. After generation, the session identifier can be used to associate historical request records, cache execution plans, and locate index entries for gating binding information, thereby ensuring that subsequent steps are consistently executed within the same session context.

[0087] A2: Generate a detection score based on the request metadata associated with the collaborative session identifier, wherein the request metadata includes at least request frequency, request interval, and task window change information; Specifically, multi-party joint evaluation in engineering deployments typically allows for repeated task triggering, window scrolling, and participation in set changes. These operations themselves are not necessarily abnormal, but when the request trajectory exhibits patterns such as high frequency, short intervals, and rapid window switching, it is easy to create probing conditions for statistically comparing output differences. The task assistance end cannot rely on plaintext auditing to identify such patterns; therefore, it is necessary to extract features that can characterize the probing intensity from the request metadata trajectory locally, and form a scoring quantity at the session level that can be used for subsequent hybrid control.

[0088] In one example, a probe score is generated based on the request metadata associated with the collaborative session identifier, including: Obtain historical request records associated with the collaborative session identifier to generate a request metadata sequence, the request metadata sequence including at least a request timestamp, a task window identifier, and a request source identifier; Request frequency features and request interval features are calculated based on the request timestamp. The request frequency features are used to characterize the number of requests within a preset time window, and the request interval features are used to characterize the time interval distribution between adjacent requests. The task window change characteristics are calculated based on the task window identifier, and the task window change characteristics are used to characterize the number of times and the magnitude of switching of the task window identifier within a preset time window; The detection score is obtained by weighted summation of the request frequency feature, the request interval feature, and the task window change feature.

[0089] In this embodiment, the generation of the request metadata sequence is not a simple listing of historical requests, but rather the establishment of a structured trajectory around the collaborative session identifier that can be used for time statistics. The task assistance end can maintain a session index table locally. The session index table uses the collaborative session identifier as the key to associate and store several historical request records. Each historical request record includes at least a request timestamp, a task window identifier, and a request source identifier, and may also include auxiliary fields such as round number, payload summary fragment, and communication channel identifier for subsequent verification. The request timestamp can use a unified time base of milliseconds or seconds. The task window identifier can be a window number, a time window start and end time pair, or a sliding window cursor. This embodiment does not limit its specific encoding method, as long as it can reflect whether adjacent requests fall in the same window and the relative distance of window switching. To ensure the stability of the statistical caliber, the request metadata sequence can be deduplicated and aligned during generation: for example, repeated resent requests with the same source identifier within a short period of time are merged, retaining only the first arrival timestamp; requests with jittery timestamps are stably sorted according to their arrival order to avoid statistical distortion of intervals caused by network jitter.

[0090] Furthermore, the calculation of request frequency and request interval features can employ a sliding statistical approach to continuously update the probe score within a session. For example, the task assistance end can set a preset time window T of 10 minutes, and upon receiving a new request, extract a subsequence of records within the range of "10 minutes prior to the current time" from the request metadata sequence as a statistical sample. The request frequency feature can directly take the number of requests within this subsequence, and can further distinguish between total frequency and single-source frequency: for example, simultaneously calculating the number of requests from all sources and the upper limit of the number of requests from a single source within this time window, used to identify concentrated probes. The request interval feature can be calculated by sorting the subsequence by time and calculating the time difference set of adjacent requests, and extracting stable statistics from this set to reduce the impact of occasional fluctuations, such as extracting the median interval, lower quartile interval, and the proportion of short intervals. The proportion of short intervals can be defined as the percentage of intervals less than 30 seconds, where 30 seconds is an example threshold. This threshold can be determined based on the quantiles of the interval distribution of historical normal sessions. For example, the median interval of similar tasks over the past 7 days can be used as the 0.2 quantile as the short interval threshold. If this threshold is 30 seconds, then 30 seconds is used as the short interval discrimination threshold. By using statistical measures such as the median, quantiles, and proportions, it is possible to characterize whether the request rhythm exhibits a dense, probing characteristic without relying on a single extreme value.

[0091] Furthermore, the calculation of task window change characteristics can simultaneously cover the number of switches and the switch magnitude to distinguish between normal scrolling and deliberate jumps. The task assistance end can extract the task window identifier sequence within the same preset time window T, calculate the number of times the window identifier changes as the number of switches; for each switch, calculate the difference in window identifiers between two adjacent requests as the switch magnitude, and extract the mean, maximum, or high quantile value from the magnitude set to reflect whether there are cross-window jump requests. If the task window identifier is represented by a number, the magnitude can be the absolute value of the number difference; if it is represented by the start and end of a time window, the magnitude can be the start time difference converted to minutes. Subsequently, the request frequency characteristics, request interval characteristics, and task window change characteristics are normalized and weighted to obtain a detection score. Normalization can be achieved using interval mapping: for example, frequency can be mapped to values ​​within the range of 0-1, with 0-6 times considered low, 7-12 times medium, and more than 12 times high; median interval can be mapped to values ​​within the range of 0-1, with greater than 120 seconds considered low risk, 60-120 seconds medium risk, and less than 60 seconds high risk; and window switching frequency can be mapped to values ​​within the range of 0-1, with 0-2 times considered low, 3-5 times medium, and more than 6 times high. Weights can be determined based on the contribution of features from historical normal sessions: for example, by statistically analyzing the fluctuation range of each feature in historical sessions, features with smaller fluctuations but stronger anomaly indicative power can be assigned higher weights; for instance, window change weight can be set to 0.4, frequency weight to 0.35, and interval weight to 0.25, and these weights can be fixed in the local configuration. Those skilled in the art can implement a reproducible calculation process for detection scoring based on the above-described record structure, statistical criteria, threshold derivation, and normalization combination.

[0092] A3: Generate a true local contribution for participating in the joint evaluation based on the private data, and generate a counterfactual comparison local contribution corresponding to the true local contribution based on the private data; Specifically, the local contributions output by the task-assisting end during joint evaluation can often be used for multiple rounds of comparison to infer the existence of a certain type of sensitive object in the private data. Simply adding uniform noise to the output is insufficient to cover the trajectory probing for existence inference, because the probe can form comparable samples through repeated triggering and window fine-tuning. Therefore, a control contribution needs to be constructed to characterize the form of the contribution that should be generated locally if the private data does not contain sensitive objects, and the two should be offset by restricted mixing in the subsequent process, thereby weakening the testability of the hypothesis of whether sensitive objects are contained on the output side.

[0093] In one example, the generation methods for the true local contribution and the counterfactual local contribution include: The private data is divided into sensitive subset data and non-sensitive subset data based on a preset sensitive object discrimination rule. The sensitive object discrimination rule is used to determine whether the private data belongs to a preset sensitive object. The true local contribution is generated based on the private data. The counterfactual comparison local contribution is generated based on the non-sensitive subset data. The counterfactual comparison local contribution is used to characterize the local contribution when the private data does not contain the sensitive object.

[0094] In this embodiment, the sensitive object discrimination rule is used to form an executable partitioning criterion locally on the task assistance end, enabling private data to be consistently split into sensitive and non-sensitive subsets, thereby providing a basis for the generation of true local contributions and counterfactual comparison local contributions along the same path. The sensitive object discrimination rule can be defined using field conditions, event labels, rare pattern identifiers, threshold ranges, or combinations of multiple conditions, and this rule remains stable throughout the session to avoid introducing additional uncertainty due to changes in the partitioning criterion as the request trajectory changes. For example, if the private data contains sample-level attribute fields and event fields, a sensitive object can be defined as a sample whose event type belongs to a rare event set or whose risk label is high-risk and occurs within a specific window; if the private data is a time series, a sensitive object can be defined as a sequence segment whose occurrence frequency of a certain type of abnormal segment is less than a threshold. The rare event set or threshold can be determined based on local historical statistics: for example, counting the frequency of event types over the past 90 days and adding event types with fewer than 50 occurrences to the rare set; or, statistically analyzing the risk score distribution and using the 95th percentile as the high-risk threshold, for example, a threshold of 0.9, where samples with scores exceeding 0.9 are marked as sensitive objects. Both the thresholds and sets mentioned above are derived locally and stored permanently by the task assistance terminal. Those skilled in the art can configure corresponding rules based on the actual data structure, making the partitioning process feasible and reproducible.

[0095] Furthermore, the true local contribution and the counterfactual local contribution need to adopt a consistent generation path and interface constraints to ensure that they can be directly aligned in terms of dimension, field order, and scale, thereby supporting subsequent restricted mixing. The generation of the true local contribution can be based on the input interface and session execution plan described by the dense function load. For example, when the joint evaluation corresponds to the model training task, the true local contribution can be the local gradient vector, parameter increment, or local loss statistics; when the joint evaluation corresponds to the statistical summary task, the true local contribution can be the count vector, quantile statistics, or cross-tabulation statistics; when the joint evaluation corresponds to the scoring calculation task, the true local contribution can be the local score component or the local feature aggregation result. The counterfactual local contribution is generated based on the non-sensitive subset data using the same generation path, that is, using the same data preprocessing, the same feature extraction caliber, and the same aggregation and shaping methods, only the input data range is replaced by non-sensitive subset data instead of the full private data. To avoid abrupt changes in contribution scale due to variations in sample size, this embodiment allows for scale compensation when generating counterfactual control local contributions. For example, sampling a non-sensitive subset at a fixed ratio to maintain a sample size close to the full size, or performing uniform normalization during contribution output to ensure the output dimensions are consistent with the true local contributions. This compensation does not alter the structure of the generation path; it only maintains alignment between the two, preventing subsequent mixing from exhibiting abnormal shifts due to scale mismatch.

[0096] Furthermore, to ensure that the counterfactual comparison local contribution can accurately represent the contribution pattern that does not include sensitive objects, this embodiment can also incorporate consistency verification and boundary processing during the partitioning and generation process. When the sensitive subset data is empty, the counterfactual comparison local contribution and the true local contribution should theoretically be consistent. In this case, the counterfactual comparison local contribution can be directly set as a copy or pass-through result of the true local contribution, and the flag indicating that the sensitive subset is empty in this round is recorded so that the subsequent mixing coefficient can be rolled back or the minimum mixing intensity can be maintained. When the non-sensitive subset data is too small, causing the counterfactual contribution to be unstable, a minimum sample size protection strategy can be triggered: for example, requiring the number of non-sensitive subset samples to be no less than 20% of the total number of samples. If it is insufficient, it can be supplemented with non-sensitive samples that are close in time or with historical non-sensitive sample caches, and a validity period, such as 24 hours, is set for the supplementation source to avoid long-term drift. This minimum proportion threshold can be determined through historical stability statistics: for example, looking back at the relationship between the proportion of non-sensitive subsets and contribution fluctuations in the past 30 rounds, the lowest proportion that keeps the fluctuation within an acceptable range is selected as the threshold, for example, 0.2.

[0097] A4: Determine the mixing coefficient based on the detection score, and perform a restricted mixing of the true local contribution and the counterfactual local contribution based on the mixing coefficient to obtain the hedging local contribution, wherein the restricted mixing at least satisfies the preset upper bound constraint of offset and the direction consistency constraint. Specifically, the constrained mixing of the true local contribution and the counterfactual local contribution is not arbitrary interpolation, but rather requires a controllable balance between availability and hedging strength: an excessively large mixing coefficient may cause the local contribution to deviate too much from the true contribution, affecting the stability of the joint evaluation; an excessively small mixing coefficient makes it difficult to reduce the space for the probe trajectory to utilize the output difference. Therefore, the probe score is used to provide an interpretable adjustment basis for the mixing coefficient, so that the mixing strength adapts to the degree of anomaly of the requested trajectory, while suppressing the unexpected offset caused by the mixing through offset upper bound constraints and direction consistency constraints.

[0098] In one example, a mixing coefficient is determined based on the detection score, and a constrained mixing of the true local contribution and the counterfactual control local contribution is performed based on the mixing coefficient to obtain a hedging local contribution, including: A4.1: Based on the detection score, a target mixing coefficient strategy is determined from a preset set of mixing coefficient strategies, wherein the set of mixing coefficient strategies includes at least two mixing coefficient value rules corresponding to different detection score intervals; Specifically, the detection score reflects the density of the requested trajectory and the degree of window jumps, while the mixing intensity directly affects the deviation of the hedging contribution from the true contribution. If the mixing coefficient is set to a fixed value, two types of engineering risks may easily occur: first, under normal request conditions, excessive hedging may lead to fluctuations in the joint evaluation results; second, when the trajectory exhibits exploratory characteristics, insufficient hedging may result in the exploitation of differences in outputs across multiple rounds.

[0099] In this embodiment, the set of hybrid coefficient strategies is organized into several strategy items, each strategy item including at least: the applicable detection scoring range, the value range of the hybrid coefficient, the random fluctuation amplitude, the backoff rule, and the adjustment step size linked to the offset threshold. For example, three strategies can be set: a low-level strategy is suitable for detection scores in the range of [0, 0.3], with a mixing coefficient range of [0.05, 0.10]; a medium-level strategy is suitable for detection scores in the range of [0.3, 0.7], with a mixing coefficient range of [0.12, 0.22]; and a high-level strategy is suitable for detection scores in the range of (0.7, 1.0], with a mixing coefficient range of [0.25, 0.35]. The boundaries of these ranges can be derived from the distribution of detection scores in historical normal sessions: for example, by statistically analyzing the detection scores of similar tasks over the past 7 days, the 30th percentile value is taken as the 0.3 boundary, and the 70th percentile value is taken as the 0.7 boundary. When each session round arrives, the task assistance end retrieves the strategy item based on the range into which the current detection score falls, determines the target mixing coefficient strategy, and caches the strategy item within the session for subsequent rollback iterations.

[0100] A4.2: Generate mixing coefficients according to the target mixing coefficient strategy, wherein the mixing coefficients are random variables driven by a random seed associated with the collaborative session identifier; Specifically, if the mixing coefficients take fixed endpoint values ​​within the policy range, a fixed offset pattern that can be aligned will be formed in multiple rounds of output. However, if randomness is introduced within the range, the hedging amplitude under the same policy can fluctuate at the micro level, reducing the possibility of externally fitting the differences in multiple rounds precisely. But this randomness must be controllable in engineering: on the one hand, it must be reproducible within the session to support retry and consistency verification; on the other hand, it must be constrained by the policy range to avoid random values ​​going out of bounds, causing the offset to exceed the limit or the direction to be distorted.

[0101] In this embodiment, the random seed can be derived from the collaborative session identifier and the local secret salt value. The local secret salt value is securely stored by the task assistance terminal and is not exposed externally. During derivation, the session identifier and the salt value are concatenated and a digest operation is performed to obtain the seed. The seed length is fixed, for example, 16 bytes or 32 bytes. The random value of the mixing coefficient can be generated within the range specified by the target mixing coefficient strategy, for example, using uniform sampling or truncated normal sampling: when uniform sampling is used, a random value is taken within the range of [upper bound, lower bound]; when truncated normal sampling is used, a random value is generated with the midpoint of the range as the center and truncated within the range to reduce the probability of obtaining boundary extreme values. For example, if the selected range of the medium strategy is [0.12, 0.22], the mixing coefficient can be obtained by seed-driven 0.18; if the selected range of the high strategy is [0.25, 0.35], the mixing coefficient can be obtained by seed-driven 0.29. The generated mixing coefficients, along with the session identifier and round number, are recorded in the local session context for controlled rollback in case of subsequent offset detection failures.

[0102] A4.3: Based on the mixing coefficient, the true local contribution and the counterfactual control local contribution are linearly mixed to obtain the initial hedging local contribution; Specifically, the true local contribution and the counterfactual local contribution represent the "contribution form containing sensitive objects" and the "contribution form not containing sensitive objects," respectively. While they are consistent in their interface dimension, they may differ in their numerical distribution. Linearly mixing the two introduces a hedging component at the numerical level while maintaining the contribution structure, thus ensuring that the output of the subsequent joint evaluation no longer completely corresponds to the existence of sensitive objects. Linear mixing is used instead of structural transformation because it has lower requirements for execution path and interface constraints, can be completed locally, and does not require modification of the dense-state function load description or the joint evaluation protocol.

[0103] In this embodiment, linear mixing is performed locally on the task assistance end, field by field, on the contribution data structure. Fields can be vector components, matrix elements, statistical counts, or other quantifiable units. To ensure that the mixed contribution still meets the input range requirements for joint evaluation, range normalization can be performed on the true local contribution and the counterfactual local contribution before mixing. For example, upper and lower bound pruning can be applied to each field, nonnegation processing can be performed on count-type fields, and normalization and alignment can be performed on probability-type fields, so that both are on the same dimension and numerical scale. After mixing, an initial counterfactual local contribution is obtained, retaining the same field order, dimension identifier, and interface label as the true contribution, so that it can directly enter the dense input conversion process later. For example, if the contribution is a vector structure of length 100, then the 100 components are mixed one by one; if the contribution is a composite structure of a count vector and a mean vector, then mixing is performed on the count segment and the mean segment respectively with the same mixing coefficient, while keeping the segment boundaries of the composite structure unchanged.

[0104] A4.4: Perform offset upper bound constraint detection on the initial hedging local contribution. The offset upper bound constraint detection is used to determine whether the offset of the initial hedging local contribution relative to the real local contribution is greater than a preset offset threshold. When the offset exceeds the preset offset threshold, adjust the mixing coefficient and regenerate the initial hedging local contribution until the offset is less than or equal to the offset threshold. Specifically, the hedging component introduced in the hybrid process needs to be controlled; otherwise, the initial hedging local contribution may deviate excessively from the true local contribution, leading to unstable joint evaluation, result drift, or triggering abnormal protocol boundaries. Offset upper bound constraint detection provides a local self-verification mechanism: the task assisting end does not need to know the global evaluation rules; it only needs to use the true local contribution as a reference to measure the degree of deviation of the initial hedging local contribution and compare it with a preset threshold. When the deviation exceeds the threshold, the hybrid coefficients are recalculated by backtracking until the deviation falls within an acceptable range, thus forming a closed-loop control between hedging strength and stability.

[0105] In this embodiment, the offset measurement can be adapted according to the contribution structure: for vector structures, a combination of "maximum component offset" and "overall scale offset" can be used; for count-type structures, "relative offset ratio" can be used; and for distribution-type structures, "high quantile of the difference between each component" can be used as the measurement. For example, the following can be calculated simultaneously: the absolute difference between the initial hedging contribution and the true contribution in each field, with the maximum value taken as the maximum component offset; and the change ratio of the overall scale of the initial hedging contribution relative to the true contribution as the overall scale offset. A rollback is triggered when any measurement exceeds a threshold. The threshold can be determined based on historical normal fluctuation statistics: the task assistance end maintains the fluctuation level of the true contribution in the most recent M rounds, for example, M=50, statistically analyzes the distribution of the natural fluctuation difference of each field in adjacent rounds, and takes the 95th quantile as the field offset threshold; simultaneously, statistically analyzes the distribution of the natural fluctuation ratio of the overall scale, and takes the 95th quantile as the ratio threshold. For example, if the 95th quantile of the field offset is 0.12, then the offset threshold is set to 0.12; if the 95th quantile of the overall scale ratio is 15%, then the ratio threshold is set to 15%. When the detection exceeds the limit, the mixing coefficient is rolled back according to the preset step size in the strategy, for example, the step size is 0.03, and the initial hedging contribution is regenerated. If the limit is still exceeded after more than 5 consecutive rollbacks, the lower bound of the strategy interval is directly used as the mixing coefficient and the rollback is stopped to avoid infinite loop.

[0106] A4.5: The initial hedging local contribution is subjected to direction correction processing to obtain the hedging local contribution. The direction correction processing includes projecting and reconstructing the initial hedging local contribution based on the true local contribution direction. Specifically, even if the offset is controlled within a threshold, the initial hedging local contribution may still exhibit directional deviations, such as sign reversal, changes in the order of dominant fields, or reversals in the dominant direction on key fields. Such directional changes may cause undesirable optimization or statistical trends during joint evaluation, and may even lead to the hedging behavior being mistakenly identified as anomalous input. The direction correction process uses the true local contribution as a reference to project and reconstruct the initial hedging contribution, ensuring its overall direction aligns with the true contribution while preserving the existence information weakening effect of the hedging. This process is a local numerical shaping technique that does not alter the contribution structure interface and does not rely on external plaintext auditing.

[0107] In this embodiment, the direction alignment can be achieved through a process of dominant field consistency verification, projection reconstruction, and boundary repair. Dominant field consistency verification selects a set of dominant fields from the true local contributions, for example, selecting the top K fields by absolute value, where K can be 10 or determined by contribution sparsity. It verifies whether the signs of the initial hedging contributions on these fields are consistent with the true contributions and whether the relative order crosses boundaries. If inconsistencies in signs or order crosses are found, projection reconstruction is triggered: projection reconstruction retains the directional components of the initial hedging contributions along the true contribution direction and compresses or replaces components that deviate from the true direction with equal components along the true direction, aligning the dominant direction of the final hedging contribution with the true contribution. After processing, boundary repair is performed: range normalization and offset upper bound verification are performed again on the adjusted fields to prevent the offset from exceeding the limit again during alignment. For example, when it is found that the signs of 2 fields in the first 10 dominant fields are flipped, the values ​​of these 2 fields can be replaced with the "nearest neighbor value between the true field value and the initial hedging field value". The nearest neighbor value can be the side that is closer to the true value between the two. When it is found that the overall direction is deviated too much, the entire vector can be oriented and scaled to make it consistent with the true vector direction and keep it within the offset threshold.

[0108] A5: Convert the hedging local contribution into a dense state input, and participate in the joint evaluation based on the intermediate representation description information corresponding to the dense state function load and the dense state gating parameters to output the collaborative calculation result; Specifically, the local contribution to the hedging mechanism remains within the plaintext data structure after local generation. Directly participating in joint evaluation would violate the security boundaries of multi-party computation. Therefore, it needs to be converted into the encrypted input form required by the joint evaluation protocol and matched with the execution plan of the intermediate representation described by the encrypted function payload. Meanwhile, since the intermediate representation includes gating bindings and execution sequence hints, the task assistant should complete input alignment, partition filling, and buffer mapping based on the payload description to avoid additional interactions or abnormal retries during the execution phase due to interface inconsistencies.

[0109] In this embodiment, the generation of the encrypted input can be implemented according to the protocol type used: if secret sharing is used, the hedging local contribution is split into multiple shares and distributed according to the participant list; if encrypted encapsulation is used, the hedging local contribution is encoded as an encrypted data block with necessary interface tags. Regardless of the method used, the encrypted input must carry the same field order and dimension identifier as the intermediate representation description information, so that it can be correctly routed to the corresponding execution unit entry. After receiving the encrypted function payload, the task assist end can parse the dimension definition and port number of the input carrier from the topology description information, and write the hedging local contribution into the corresponding port buffer accordingly; then, according to the gating binding information, the encrypted gating parameters are referenced to the control variable handle position of the synthesis entry, and the partition-level step-by-step evaluation interaction is completed according to the execution plan description. After the joint evaluation is completed, the task assist end outputs the result share or intermediate result corresponding to its protocol role, which is then summarized by the initiating end to obtain the collaborative calculation result.

[0110] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A cross-domain data collaborative computation method based on secure multi-party computation and differential privacy, applied to the task initiation end of a distributed processing system, characterized in that: The task initiator is used to initiate collaborative computing tasks and obtain collaborative computing results. The distributed processing system also includes multiple task assisting ends. Each task assisting end participates in the collaborative computing task based on private data configured within it and outputs the collaborative computing results. The method includes: The collaborative computing task to be executed is determined, and an intent description object is generated based on the collaborative computing task. The intent description object is used to characterize the task definition of the collaborative computing task. An intermediate representation of the intent function is generated based on the intent description object, and the intermediate representation is blind-coded to generate a dense-state function payload. The encrypted function payload is distributed to the task assisting terminal, and the task assisting terminal is triggered to generate encrypted input based on its own private data and participate in joint evaluation. Differential privacy processing is introduced in the joint evaluation process to generate collaborative computation results.

2. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy as described in claim 1, characterized in that, Generate an intent description object based on the collaborative computing task, including: Obtain the task configuration parameters corresponding to the collaborative computing task; The task configuration parameters are structured and parsed to extract at least one type of task definition element for defining the collaborative computing task. The task definition element includes at least one of the following: target output type, target optimization preference, and attention object rule. The intent description object is constructed based on the task definition elements.

3. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy as described in claim 1, characterized in that, The method further includes: The intent function is determined based on the intent description object, and the intent function is compiled into an intermediate representation, wherein the intent function is used to characterize the evaluation rules of the collaborative computing task, and the intermediate representation is an intent operator graph, which includes multiple operator nodes connected by data flow and at least one gate node for controlling the execution path of the operator nodes.

4. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy as described in claim 3, characterized in that, Determining the intent function based on the intent description object includes: Based on the intent description object, a set of candidate task definition elements is determined, and the set of candidate task definition elements is used to characterize multiple optional evaluation methods of the collaborative computing task; A gating selection rule is constructed for the set of candidate task definition elements. The gating selection rule is used to map the candidate task definition elements to a gating vector, wherein the gating vector is used to indicate the set of operator nodes to be enabled in the intent function. The gate vector is subjected to dense state processing to generate dense state gate parameters, and the dense state gate parameters are combined with a preset basic evaluation skeleton to determine the intention function containing gate logic and evaluation logic; The basic evaluation skeleton is a general evaluation structure corresponding to the set of candidate task definition elements, and it remains consistent under different sets of candidate task definition elements.

5. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy as described in claim 4, characterized in that, Compiling the intent function into an intermediate representation includes: A hypergraph skeleton is constructed based on the intent function, wherein the hypergraph skeleton includes multiple template subgraphs, and the template subgraphs are used to correspond to different candidate task definition elements in the candidate task definition element set, respectively. In the hypergraph skeleton, semantic bypass components are configured for at least a portion of the template subgraphs. The semantic bypass components include a main operator node, a bypass operator node, and a synthesis node for selective synthesis between the outputs of the main operator node and the bypass operator node. The control quantity of the gate node corresponding to the semantic bypass component is determined based on the dense gating parameters, and the gate node is associated with the synthesis node; The hypergraph skeleton is bound to the semantic bypass component to generate an intermediate representation.

6. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy as described in claim 5, characterized in that, The intermediate representation is subjected to blind encoding to generate a dense-state function load, including: Node identifiers and connection identifiers are generated for at least some of the operator nodes and their node connection relationships in the intermediate representation, and permutation mapping is performed on the node identifiers and connection identifiers to obtain topology description information; The gating conditions associated with the gating node in the intermediate representation are subjected to dense state processing to generate dense gating conditions; The dense state function load is generated based on the topology description information and the dense state gating conditions.

7. A cross-domain data collaborative computation method based on secure multi-party computation and differential privacy, applied to the task assistance end of a distributed processing system, characterized in that... The task assisting terminal participates in collaborative computing tasks based on private data configured within it. The distributed processing system also includes a task initiating terminal, which initiates collaborative computing tasks and obtains collaborative computing results. The task initiating terminal further includes sending a dense function payload to the task assisting terminal. The method includes: The cooperative session identifier corresponding to this joint evaluation is determined based on the dense state function load. A detection score is generated based on the request metadata associated with the collaborative session identifier, wherein the request metadata includes at least request frequency, request interval, and task window change information; Based on the private data, a true local contribution is generated for participating in the joint evaluation, and based on the private data, a counterfactual comparison local contribution corresponding to the true local contribution is generated; The mixing coefficient is determined based on the detection score, and the true local contribution and the counterfactual local contribution are subjected to restricted mixing based on the mixing coefficient to obtain the hedging local contribution, wherein the restricted mixing at least satisfies the preset upper bound constraint of offset and the direction consistency constraint. The hedging local contribution is converted into a dense state input, and the intermediate representation description information corresponding to the dense state function load and the dense state gating parameters are used to participate in the joint evaluation to output the collaborative calculation result.

8. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy according to claim 7, characterized in that, A probe score is generated based on the request metadata associated with the collaborative session identifier, including: Obtain historical request records associated with the collaborative session identifier to generate a request metadata sequence, the request metadata sequence including at least a request timestamp, a task window identifier, and a request source identifier; Request frequency features and request interval features are calculated based on the request timestamp. The request frequency features are used to characterize the number of requests within a preset time window, and the request interval features are used to characterize the time interval distribution between adjacent requests. The task window change characteristics are calculated based on the task window identifier, and the task window change characteristics are used to characterize the number of times and the magnitude of switching of the task window identifier within a preset time window; The detection score is obtained by weighted summation of the request frequency feature, the request interval feature, and the task window change feature.

9. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy as described in claim 7, characterized in that, The methods for generating the true local contribution and the counterfactual comparison local contribution include: The private data is divided into sensitive subset data and non-sensitive subset data based on a preset sensitive object discrimination rule. The sensitive object discrimination rule is used to determine whether the private data belongs to a preset sensitive object. The true local contribution is generated based on the private data. The counterfactual comparison local contribution is generated based on the non-sensitive subset data. The counterfactual comparison local contribution is used to characterize the local contribution when the private data does not contain the sensitive object.

10. The cross-domain data collaborative computation method based on secure multi-party computation and differential privacy according to claim 9, characterized in that, A mixing coefficient is determined based on the detection score, and a restricted mixing is performed on the true local contribution and the counterfactual control local contribution based on the mixing coefficient to obtain a hedging local contribution, including: Based on the detection score, a target mixing coefficient strategy is determined from a preset set of mixing coefficient strategies, wherein the set of mixing coefficient strategies includes at least two mixing coefficient value rules corresponding to different detection score intervals; A mixing coefficient is generated according to the target mixing coefficient strategy, wherein the mixing coefficient is a random variable driven by a random seed associated with the collaborative session identifier; The true local contribution and the counterfactual local contribution are linearly mixed based on the mixing coefficient to obtain the initial hedging local contribution; The initial hedging local contribution is subjected to offset upper bound constraint detection. The offset upper bound constraint detection is used to determine whether the offset of the initial hedging local contribution relative to the real local contribution is greater than a preset offset threshold. When the offset exceeds the preset offset threshold, the mixing coefficient is adjusted and the initial hedging local contribution is regenerated until the offset is less than or equal to the offset threshold. The initial hedging local contribution is subjected to direction correction processing to obtain the hedging local contribution. The direction correction processing includes projecting and reconstructing the initial hedging local contribution based on the true local contribution direction.

Images