Data privacy computation method in multi-agent algorithm network fusion environment

Abstract

The application discloses a data privacy computing method in a multi-agent computing network fusion environment. The method deeply couples and models the logical communication semantics of the privacy computing protocol with the physical topology characteristics of the computing network, realizes the optimal allocation of privacy computing tasks to physical resources and the congestion-free routing arrangement of ciphertext data streams through protocol dependency relationship driven graph construction and homomorphic hypergraph mapping, introduces hierarchical remote attestation and cross-domain batch cross-validation to establish an end-to-end trust link, and completes encrypted fragment collaborative operation and aggregation audit in a trusted execution enclave to form a full-link privacy computing closed loop. In this way, the communication overhead of cross-domain ciphertext data flow is significantly reduced, the global blocking risk caused by concurrent competition of protocol rounds is eliminated, and the trust establishment cost between multi-agents is reduced, thereby realizing end-to-end trusted audit of the computing process.

Description

Technical Field

[0001] This application relates to the field of data privacy computing, and more specifically, to a data privacy computing method in a multi-entity computing network fusion environment. Background Technology

[0002] As computing networks evolve towards multi-entity, cross-domain collaboration, key industries such as power, finance, and government have an increasingly urgent need for cross-organizational data joint computing. How to achieve efficient collaborative intelligent computing without allowing data from multiple entities to remain within their respective domains has become a core issue that urgently needs to be addressed in the field of computing-network convergence. Raw data from multiple entities cannot be directly aggregated due to data sovereignty, trade secrets, and legal and regulatory constraints. Without effective privacy computing mechanisms, the data silo effect will intensify, hindering the release of the combined value of multi-source data and severely restricting the large-scale deployment of distributed intelligent computing applications.

[0003] Existing data privacy computing solutions typically deploy privacy protection protocols as upper-layer applications independent of the computing network infrastructure, employing technologies such as federated learning, secure multi-party computation, and homomorphic encryption to achieve "usable but invisible" data. However, these solutions have significant shortcomings when adapting to multi-entity computing network convergence environments. On the one hand, existing solutions fail to fully utilize the heterogeneous characteristics of the computing network's physical topology during the privacy computing task scheduling phase. The lack of a deep mapping mechanism between the privacy computing logical communication relationship and the underlying physical network resources leads to high cross-domain communication overhead, redundant encrypted data flow paths, and low resource utilization. On the other hand, at the distributed trusted computing level, existing solutions often limit trust verification of computing nodes to a single domain, lacking a hierarchical remote proof and batch cross-verification system for cross-domain, multi-entity scenarios. This results in high trust establishment costs between entities, difficulty in detecting malicious nodes, and an inability to guarantee the end-to-end trustworthiness and auditability of the computing process. Furthermore, when multi-party secure computation protocols are advanced synchronously in rounds, concurrent dense data streams within the same round are prone to causing bandwidth contention on the backbone link. Existing routing plans are unaware of the coupling constraints of protocol rounds, which can easily lead to global protocol blocking or even communication deadlock, seriously affecting the reliability and real-time performance of cross-domain collaborative computing.

[0004] Therefore, we look forward to an optimized data privacy computing method in a multi-entity computing network fusion environment. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a data privacy computing method for a multi-entity computing network convergence environment.

[0006] According to one aspect of this application, a data privacy computation method is provided in a multi-entity computing network convergence environment, comprising: S1, based on protocol dependencies, feature extraction and graph construction are performed on the acquired original configuration data of the computing network privacy computing to obtain the privacy computing logical communication graph and the feature matrix of the computing network physical topology hypergraph; S2, based on the optimization objective of minimizing cross-domain communication overhead, performs homomorphic hypergraph mapping and path planning on the feature matrix of the privacy computing logical communication graph and the computing network physical topology hypergraph to obtain the cooperative scheduling allocation table and the dense data flow routing topology; S3, perform hierarchical remote proof and cross-domain batch cross-verification on each node in the collaborative scheduling allocation table to obtain a set of cross-domain trust endorsement certificates and a channel negotiation key; S4, based on the congestion-free transmission path planned by the encrypted data flow routing topology, and using the channel negotiation key and cross-domain trust endorsement certificate set, performs encrypted fragmentation and collaborative operation on the local original business data of each node in the trusted execution enclave to obtain the encrypted intermediate result stream. S5, in the highest security level trusted execution environment, aggregates, decrypts, and encapsulates the encrypted intermediate result stream with audit proof to obtain the joint computation result and trusted execution audit log.

[0007] Compared with existing technologies, this application provides a data privacy computing method in a multi-entity computing network fusion environment. It achieves optimal allocation of privacy computing tasks to physical resources and congestion-free routing and orchestration of encrypted data flows by deeply coupling the logical communication semantics of privacy computing protocols with the physical topology characteristics of the computing network through protocol dependency-driven graph construction and homomorphic hypergraph mapping. Simultaneously, it introduces hierarchical remote proofs and cross-domain batch cross-validation to establish end-to-end trust links, and completes encrypted sharding collaborative computation and aggregation auditing within a trusted execution enclave, forming a closed-loop privacy computing system. This significantly reduces the communication overhead of cross-domain encrypted data flow, eliminates the risk of global blocking caused by concurrent contention in protocol rounds, and lowers the cost of establishing trust among multiple entities, thereby achieving end-to-end trusted auditing of the computing process. Attached Figure Description

[0008] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0009] Figure 1 This is a flowchart of a data privacy computation method in a multi-entity computing network fusion environment according to embodiments of this application; Figure 2This is a schematic diagram of data flow in a data privacy computing method under a multi-entity computing network fusion environment according to an embodiment of this application; Figure 3 This is a flowchart of step S2 in the data privacy computation method in a multi-entity computing network fusion environment according to an embodiment of this application; Figure 4 This is a flowchart of step S3 in the data privacy computation method in a multi-entity computing network fusion environment according to an embodiment of this application. Detailed Implementation

[0010] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0011] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0012] While this application makes various references to certain modules of the systems according to embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0013] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0014] The technical solution of this application proposes a data privacy computing method in a multi-entity computing network fusion environment. Figure 1 This is a flowchart of a data privacy computation method in a multi-entity computing network fusion environment according to an embodiment of this application. Figure 2 This is a system architecture diagram of a data privacy computing method in a multi-entity computing network fusion environment according to embodiments of this application. Figure 1 and Figure 2As shown, the data privacy computing method in a multi-entity computing network converged environment according to an embodiment of this application includes the following steps: S1, based on protocol dependencies, performing feature extraction and graph construction on the acquired original configuration data for computing network privacy computing to obtain a privacy computing logical communication graph and a computing network physical topology hypergraph feature matrix; S2, based on the optimization objective of minimizing cross-domain communication overhead, performing homomorphic hypergraph mapping and path planning on the privacy computing logical communication graph and the computing network physical topology hypergraph feature matrix to obtain a collaborative scheduling allocation table and a dense data flow routing topology; S3, processing the collaborative scheduling allocation table... In S4, nodes within each domain perform hierarchical remote authentication and cross-domain batch cross-verification to obtain a set of cross-domain trust endorsement certificates and a channel negotiation key; based on the congestion-free transmission path planned by the encrypted data flow routing topology, and using the channel negotiation key and the set of cross-domain trust endorsement certificates, the original local business data of each node is encrypted, fragmented, and collaboratively computed within the trusted execution enclave to obtain an encrypted intermediate result stream; in S5, in the highest security level trusted execution environment, the encrypted intermediate result stream is aggregated, decrypted, and encapsulated with audit proof to obtain the joint computation result and trusted execution audit log.

[0015] Specifically, S1, based on protocol dependencies, performs feature extraction and graph construction on the acquired original configuration data of the network privacy computing to obtain a privacy computing logical communication graph and a network physical topology hypergraph feature matrix. It should be understood that in a multi-entity network convergence environment, the efficient execution of privacy computing tasks depends on the accurate modeling of two key types of information: first, the logical communication relationships of the privacy computing protocol itself, i.e., the data interaction topology formed between participating nodes based on cryptographic operator dependencies; second, the status of the underlying network physical resources carrying these logical communications, including cross-domain network connectivity and the hardware quotas of each node's trusted execution environment. Existing privacy computing schemes deploy privacy protection protocols as upper-layer applications independent of the network infrastructure. During the privacy computing task scheduling phase, they fail to fully utilize the heterogeneous feature information of the network physical topology. The lack of a deep mapping mechanism between the privacy computing logical communication relationships and the underlying physical network resources leads to a lack of accurate input for subsequent scheduling and routing planning, resulting in high cross-domain communication overhead and redundant encrypted data flow paths. Therefore, in the technical solution of this application, feature extraction and graph construction are first performed on the original configuration data of privacy computing network. The logical communication semantics of the privacy computing protocol and the multidimensional heterogeneous features of the physical topology of the computing network are modeled into structured graph representations, providing an accurate and complete two-layer input data foundation for subsequent homomorphic hypergraph mapping and path planning.

[0016] It is worth noting that the original configuration data for privacy computing on the network refers to the collection of all underlying configuration information required to execute privacy computing tasks. Specifically, it includes three parts: cross-domain gateway routing table data, node trusted execution environment hardware quota parameters, and multi-party secure computation protocol syntax tree. The cross-domain gateway routing table data records network-level connection status information such as route reachability, link bandwidth capacity, and cross-domain communication latency between the boundary gateways of each autonomous system. The node trusted execution environment hardware quota parameters describe the hardware resource specifications of the trusted execution environment equipped by each physical computing node, including hardware-level security capability indicators such as enclave memory capacity, cryptographic computing throughput, and remote proof support capabilities. The multi-party secure computation protocol syntax tree is a tree-like representation obtained after formally parsing the privacy computing protocol to be executed. Each node corresponds to a basic cryptographic operator (such as secret sharing and distribution, homomorphic multiplication, and obfuscated circuit evaluation), and the directed edges between nodes represent the data dependencies and execution order relationships between operators.

[0017] In practical implementation, firstly, the cryptographic operator dependency relationship parsing and data flow extraction are performed on the multi-party secure computation protocol syntax tree to obtain the privacy computation logic communication graph. Simultaneously, the cross-domain gateway routing table data and node trusted execution environment hardware quota parameters are timestamped and dimensionally concatenated to obtain the original heterogeneous state set of the computing network. In this process, firstly, the multi-party secure computation protocol syntax tree to be executed is obtained. This syntax tree formally describes all cryptographic operators and their data dependencies in the protocol. Cryptographic operator dependency relationship parsing is then performed on this syntax tree. Specifically, each cryptographic operator node in the syntax tree is traversed to identify the input data source node and output data target node of the operator, thereby determining the data flow relationship between operators. Based on the parsed data dependencies between operators, data flow extraction is performed, that is, the dependency edges involving cross-participant data transmission are extracted, and a graph structure is constructed with participants as nodes and cross-party secure data transmission requirements as directed edges. The weight of each directed edge is determined by the amount of secret data transmission involved in the dependency, including cryptographic protocol parameters such as secret sharing fragment size, homomorphic ciphertext length, and obfuscated circuit gate table size, ultimately resulting in a privacy computing logic communication graph.

[0018] Simultaneously, cross-domain gateway routing table data and node trusted execution environment hardware quota parameters are acquired. Since these two types of data originate from different acquisition systems and have different sampling frequencies and time bases, a timestamp alignment operation is first performed. This involves interpolating and aligning the sampling timestamps of the two types of data using a unified global time base to ensure that the network state data and hardware quota data of the same physical node correspond to the same time slice. After timestamp alignment, each physical node is dimensionally concatenated. This involves concatenating the node's network connection state vector (including metrics such as bandwidth, latency, and packet loss rate) with the trusted execution environment hardware quota vector (including metrics such as enclave memory capacity, encryption throughput, and supported remote proof protocol types) along the feature dimension, forming a multidimensional original state description of the node. The multidimensional original state descriptions of all physical nodes are aggregated to form the original heterogeneous state set of the computing network.

[0019] Next, a high-dimensional joint projection embedding of the network connection weights and trusted hardware quotas of each physical node in the original heterogeneous state set of the computing network is performed to obtain the high-dimensional feature tensor of the computing network. In this process, firstly, the spliced ​​state vector of each physical node in the original heterogeneous state set of the computing network is spatially transformed through a learnable linear projection matrix to achieve unified alignment of the heterogeneous feature spaces. Nonlinear activation is used to introduce nonlinear interaction capabilities between features, enabling the embedded feature vectors to implicitly encode the correlation between network connectivity and trusted hardware quotas. The high-dimensional feature vectors of all physical nodes are arranged row-by-row according to their node indices to form the high-dimensional feature tensor of the computing network. The number of rows in this tensor equals the total number of physical nodes, and the number of columns equals the target embedding dimension. Each physical node is represented as a point in the high-dimensional space, ensuring that nodes with strong network connectivity and sufficient trusted hardware quotas have similar representations in the embedding space, laying a unified feature space foundation for subsequent hypergraph structured modeling.

[0020] Furthermore, based on the network's autonomous system (AS) affiliation relationships, hyperedge partitioning and association matrix construction are performed on physical nodes belonging to the same boundary gateway in the high-dimensional feature tensor of the computing network. Multidimensional spatial normalization mapping is then performed using a hypergraph convolutional projection mechanism to obtain the computing network's physical topology hypergraph feature matrix. In this process, firstly, based on the network's AS affiliation relationships, physical nodes belonging to the same boundary gateway in the high-dimensional feature tensor of the computing network are partitioned into the same hyperedge. Assuming the computing network contains several ASs, the number of hyperedges is equal to the number of ASs, and each hyperedge contains a set of indices of all physical nodes belonging to the corresponding boundary gateway. Based on this, a hypergraph association matrix is ​​constructed. The number of rows in this matrix equals the total number of physical nodes, and the number of columns equals the number of ASs (i.e., the number of hyperedges). The matrix element assignment rule is: if a physical node belongs to an AS under the jurisdiction of a boundary gateway, the corresponding element is set to 1; otherwise, it is set to 0. This association matrix accurately encodes the affiliation relationship between physical nodes and ASs in binary form.

[0021] After completing the hyperedge partitioning and association matrix construction, the high-dimensional feature tensor of the computational network is subjected to multi-dimensional spatial normalization mapping through a hypergraph convolutional projection mechanism. Specifically, node features are first aggregated along the hyperedge direction to a hyperedge-level representation, and then the hyperedge-level representation is backpropagated back to each node, thereby realizing information interaction and feature fusion between nodes within the same hyperedge. During execution, the node degree diagonal matrix is ​​first calculated. With hyperdiagonal matrix ,in Indicates the first The number of hyperedges that each node participates in. Indicates the first The number of nodes contained in a hyperedge. The formula for calculating the hypergraph convolution projection is:

[0022] in, This is a diagonal matrix of hyperedge weights, used to distinguish the differences in importance between different autonomous regions; The feature transformation parameter matrix is ​​a learnable feature. Output feature dimension; This is a non-linear activation function. In this formula, Degree normalization is performed on node features. Aggregate node features into a hyperedge-level representation. The mean normalization was performed on the aggregation results within the hyperedge. Apply super-edge weight modulation, The hyperedge level representation is distributed back to each node in reverse order, outer layer Perform node degree normalization again. Perform a linear transformation of the feature space. Nonlinear expressive power is introduced. The final result is the feature matrix of the computational network physical topology hypergraph. Each row in the graph corresponds to a normalized feature vector of a physical node after hypergraph convolution. This vector integrates the node's own network connection weights and trusted hardware quota information, and at the same time, it incorporates the context information of other nodes in the same autonomous region through the hypergraph structure propagation mechanism, so that the final feature representation has global topology awareness.

[0023] Specifically, in S2, based on the optimization objective of minimizing cross-domain communication overhead, homomorphic hypergraph mapping and path planning are performed on the feature matrix of the privacy computing logical communication graph and the computing network physical topology hypergraph to obtain the collaborative scheduling allocation table and the encrypted data flow routing topology. It should be understood that after obtaining the privacy computing logical communication graph and the computing network physical topology hypergraph feature matrix, the logical communication requirements of the privacy computing protocol and the topological characteristics of the underlying computing network physical resources are expressed in structured graph form, but a mapping relationship has not yet been established between them. That is, logical participant nodes have not yet been assigned to specific physical computing nodes for execution, and the encrypted data transmission corresponding to the logical communication edges has not yet been planned with specific physical network paths. Without a globally optimized mapping and path planning mechanism, directly assigning privacy computing tasks randomly or based on local heuristics to physical nodes can easily lead to participants with high logical communication volumes being assigned to physical node pairs with limited cross-domain bandwidth. This results in a sharp increase in cross-domain cryptographic communication overhead, redundant congestion of encrypted data flow paths, and severely impacts the execution efficiency and latency performance of the multi-party secure computing protocol. Therefore, in the technical solution of this application, the global optimization goal is to minimize cross-domain communication overhead. Logical nodes are optimally allocated to physical nodes through homomorphic hypergraph mapping. Based on the mapping results, end-to-end congestion-free transmission paths are planned for each communication node. Finally, a collaborative scheduling allocation table and a dense data flow routing topology are obtained, providing an optimized resource scheduling and network transmission foundation for subsequent trusted verification and dense collaborative computation.

[0024] Figure 3 This is a flowchart of step S2 in the data privacy computation method under a multi-entity computing network fusion environment according to an embodiment of this application. Figure 3 As shown, in the first embodiment of this application, S2 includes: S21, constructing a joint cost space from logical nodes to physical nodes on the feature matrix of the privacy computing logical communication graph and the computing network physical topology hypergraph based on the joint cost evaluation function of node mapping computing power gap penalty and logical communication volume to physical bandwidth to obtain a homomorphic mapping joint cost tensor; S22, performing graph homomorphic optimal matching iterative solution on the homomorphic mapping joint cost tensor with the goal of minimizing global cross-domain cryptographic communication overhead to obtain a cooperative scheduling allocation table; S23, performing end-to-end congestion-free path addressing and flow table compilation on each communication node pair in the feature matrix of the computing network physical topology hypergraph to obtain a dense data flow routing topology.

[0025] Specifically, in step S21, based on the joint cost evaluation function of node mapping computing power gap penalty and logical communication throughput to physical bandwidth, a joint cost space from logical nodes to physical nodes is constructed on the feature matrix of the privacy computing logical communication graph and the computing network physical topology hypergraph to obtain a homomorphic mapping joint cost tensor. During this process, for each logical participant node in the privacy computing logical communication graph and each physical computing node represented by the feature matrix of the computing network physical topology hypergraph, the joint cost value of mapping the logical node to the physical node is calculated. The joint cost evaluation function consists of two core components. The first component is the node mapping computing power gap penalty component. This component evaluates whether the trusted execution environment hardware quota of the physical node can meet the computing resource requirements of the logical node to perform privacy computing tasks. Specifically, the computing resource requirements (including enclave memory requirements, encryption operation throughput requirements, etc.) of the cryptographic operators undertaken by each logical node are extracted from the privacy computing logical communication graph, and the trusted execution environment hardware quota (already embedded as the corresponding component of the feature vector in step S1) corresponding to each physical node is extracted from the feature matrix of the computing network physical topology hypergraph. When the hardware quota of a physical node is lower than the resource requirement of a logical node, the difference between the two is the computing power gap, and a penalty coefficient is applied to this gap as a cost. When the hardware quota of a physical node meets or exceeds the resource requirement of a logical node, this component is zero or takes a minimum value. Specifically, the calculation process of the node mapping computing power gap penalty is as follows:

[0026] in, To make logical nodes Mapped to physical nodes The computing power gap penalty value at that time; This is the penalty coefficient for the computing power gap; For the number of resource dimensions; For logical nodes In the Computational requirements across resource dimensions; For physical nodes In the Trusted execution environment hardware quotas across resource dimensions; The operation ensures that penalties are only applied when a gap exists.

[0027] The second component is the logical communication cost to physical bandwidth component. This component evaluates whether the encrypted data communication needs between a logical node and other logical nodes can be carried by the network bandwidth between the corresponding physical node pairs after a logical node is mapped to a physical node. Specifically, for all neighboring logical nodes in the privacy computing logical communication graph that have communication edges with the logical node, the weight of each communication edge (i.e., the encrypted data transmission volume) is divided by the available physical bandwidth between the corresponding physical node pairs (extracted from the network connection feature component in the feature matrix of the computing network physical topology hypergraph) to obtain the communication bandwidth ratio. The sum of the bandwidth ratios of all neighboring communication edges is the communication cost component of the mapping pair. Specifically, this process can be expressed by the formula:

[0028] in, To make logical nodes Mapped to physical nodes The communication cost component at that time; This is the communication cost weighting coefficient; For logical communication diagrams and logical nodes The set of neighboring nodes with communication edges; For logical nodes Logical nodes with neighbors The communication edge weights between them, i.e., the amount of dense-state data transmitted; Neighbor logical nodes The physical node currently being mapped (or yet to be mapped); For physical nodes With physical nodes Available physical bandwidth between; To prevent smooth minimal normal quantities with a denominator of zero.

[0029] By superimposing the two components, a joint cost evaluation function from logical nodes to physical nodes is obtained. The joint cost is calculated for each possible mapping combination between all logical nodes in the privacy-preserving computation logical communication graph and all physical nodes in the computational network physical topology. The results are organized into a three-dimensional tensor structure, resulting in the homomorphic mapping joint cost tensor. This tensor fully records the cost information of each logical node-to-physical node mapping scheme, providing a complete search space for subsequent global optimal matching solutions.

[0030] Specifically, in step S22, with the objective of minimizing the global cross-domain cryptographic communication overhead, a graph homomorphic optimal matching iteration is performed on the joint cost tensor of homomorphic mappings to obtain the cooperative scheduling allocation table. Here, the global cross-domain cryptographic communication overhead is defined as the sum of the physical communication costs corresponding to all communication edges in the privacy computation logic communication graph under a given mapping scheme. The optimization objective function is:

[0031] in, This is the mapping function from logical nodes to physical nodes, i.e., the allocation scheme to be solved. For the set of communication edges in the privacy-preserving computation logic communication graph; This represents the available bandwidth between the mapped physical node pairs; This is a cross-domain indicator function. When the two physical nodes belong to different autonomous systems, the value is an amplification factor (greater than 1), and when they belong to the same autonomous system, the value is 1, to emphasize the additional overhead of cross-domain communication.

[0032] In this process, a graph homomorphic optimal matching iterative solution strategy is adopted. The specific implementation process is as follows: First, an initial mapping scheme is generated based on the principle of minimizing the single-node cost of each logical node in the homomorphic mapping joint cost tensor. That is, each logical node independently selects the physical node that minimizes its single-node joint cost as the initial mapping target. Then, an iterative optimization loop is entered. In each iteration, each logical node is traversed sequentially. While keeping the current mapping schemes of the other logical nodes unchanged, the schemes for mapping the logical node to all candidate physical nodes are enumerated. The global cross-domain cryptographic communication overhead under each scheme is calculated, and the physical node that minimizes the global overhead is selected as the new mapping target for the logical node. This iteration is repeated until the global overhead no longer decreases or the preset maximum number of iterations is reached. Simultaneously, constraints are introduced to ensure the legality of the mapping, including that each physical node can carry at most one logical node (one-to-one mapping constraint) and that the hardware quota of the physical node must meet the minimum resource requirements of the logical node (resource feasibility constraint). After the iteration converges, the globally optimal logical node-to-physical node mapping scheme is output and recorded in tabular form as a collaborative scheduling allocation table. Each row in the table contains the identifiers of the logical participants and their corresponding assigned physical node identifiers.

[0033] Specifically, in step S23, end-to-end congestion-free path addressing and flow table compilation are performed on each communication node pair in the feature matrix of the computing network physical topology hypergraph to obtain the dense data flow routing topology. During this process, a path transmission fitness scoring formula is used, with the current static available bandwidth of the link as the evaluation criterion, to independently perform greedy optimal path finding for each pair of communication nodes. Specifically, firstly, based on the logical node-to-physical node mapping relationship determined in the cooperative scheduling allocation table, each logical communication edge in the privacy computing logical communication graph is transformed into a source node-destination node communication pair at the physical layer, obtaining a set of all physical communication node pairs for which paths need to be planned. Then, end-to-end path addressing is independently performed on each pair of physical communication nodes. The path addressing process is based on the network connection information contained in the feature matrix of the computing network physical topology hypergraph, starting from the source physical node and searching for feasible paths to the destination physical node in the physical topology. For each candidate path, its path transmission fitness score is calculated. The scoring formula uses the current static available bandwidth of each hop physical link traversed by the path as the core evaluation criterion, while also comprehensively considering the cross-domain communication delay and routing hop count of the link. The formula for calculating the path transport fitness score is as follows:

[0034] in, Candidate paths Transmission fitness score; For path The single-hop physical link in; This is the positive incentive coefficient for bandwidth on path score; For link The current static available bandwidth; For link Cross-domain communication delay; To prevent smooth minimum normal quantities with a denominator of zero; The penalty coefficient for protocol resolution overhead caused by routing hop count; For path Total number of hops through gateways or routers.

[0035] For each pair of communication nodes, the path with the highest transmission fitness score among all candidate paths is selected as the optimal end-to-end transmission path for that pair. This selection process is executed independently using a greedy strategy, meaning that the path selection for each pair of communication nodes is independent and does not interfere with each other; each pair selects the path with the best score for itself. After completing the optimal path selection for all pairs of communication nodes, the path planning results are compiled into flow table forwarding rules executable by the underlying SDN switch, including matching fields (source and destination node identifiers, dense data flow identifiers) and action fields (forwarding port, priority label), and encapsulated to generate a dense data flow routing topology. This routing topology records the complete physical link sequence and corresponding flow table action instructions that should be traversed for dense data transmission between each pair of communication nodes, providing network-level path guidance for the actual cross-domain transmission of dense data in subsequent step S4.

[0036] Specifically, the study found that in privacy-preserving computing scenarios within a multi-party computing network convergence environment, multi-party secure computing protocols (such as secret sharing and obfuscated circuits) possess a widely overlooked communication timing characteristic: the encrypted data interaction between nodes does not occur uniformly at any given moment, but rather proceeds synchronously according to strict protocol rounds. Specifically, multiple pairs of nodes within the same round must complete all data exchanges within the same time window; only after all round-based interactions by all nodes have been confirmed can the next round of computation begin. This strong synchronization mechanism means that data streams within the same round inherently possess concurrent burstiness—they must simultaneously compete for network bandwidth resources within an extremely short time window.

[0037] However, in the first embodiment, sub-step S23, when selecting end-to-end paths for each pair of communication nodes, uses the path transmission fitness scoring formula based on the current static available bandwidth of the link, performing greedy optimal pathfinding independently for each pair of communication nodes. This design completely ignores the crucial constraint of whether other concurrent flows within the same protocol round are also routed to the same physical link. In actual operation, due to the inherent attractiveness of high-bandwidth links, multiple concurrent dense flows belonging to the same protocol round are easily greedily allocated to the same high-bandwidth backbone link independently. When these flows execute concurrently within the same time window, they compete for the limited physical bandwidth of the link, resulting in the actual throughput of each flow being far lower than the expected value during planning. Once a flow cannot complete data transmission within the protocol round timeout window due to bandwidth contention, it will trigger global synchronization waiting for that round, thereby causing global blocking or even communication deadlock in the multi-party secure computation protocol, and in severe cases, causing the entire cross-domain collaborative computation task to fail.

[0038] In summary, the essential flaw of the first embodiment is that it fails to recognize the inherent round-synchronization coupling relationship of the privacy computing protocol. That is, the logical edges in the privacy computing logical communication graph are not independent of each other, but are grouped into specific protocol rounds according to the protocol semantics. The physical data streams corresponding to the logical edges in the same round must satisfy the time-bandwidth joint constraint that prevents concurrency from starving each other.

[0039] To address the aforementioned deficiencies, this application further proposes a second embodiment.

[0040] Specifically, firstly, based on the hierarchical analysis of data dependency depth of each logical edge in the privacy computing logical communication graph, the logical edges with the same dependency depth are grouped by protocol round and projected onto physical communication pairs using the joint collaborative scheduling allocation table to obtain a set of round-labeled concurrent flow groups. In the SDN control plane, the multi-entity computing network collaborative scheduling allocation table and the privacy computing logical communication graph are jointly queried. Since the execution sequence of the privacy computing protocol is determined by data dependencies, logical edges without predecessor-successor dependencies will necessarily execute concurrently within the same time window. Therefore, the data dependency depth of each logical edge in the logical communication graph is first calculated—that is, the longest path length from the source operator with an in-degree of zero to the starting node of that edge—and logical edges at the same dependency depth level are grouped into the same protocol round group. Subsequently, through the mapping relationship from logical nodes to physical nodes already determined in the scheduling allocation table, each logical edge is projected as a source-destination node communication pair at the physical layer, finally outputting a set of round-labeled concurrent flow groups organized by protocol round number.

[0041] This operation explicitly extracts the implicit round-synchronization coupling relationship in the cryptographic protocol into structured concurrency constraint boundary information, enabling subsequent route optimization to perceive the key premise that which flows must occur simultaneously, thereby accurately reconstructing the original flow-by-flow independent routing problem into an intra-group joint routing problem.

[0042] Secondly, a joint path game is performed on the feature matrix of the network physical topology hypergraph for each concurrent flow in the same round of the round-calibrated concurrent flow group set to obtain a contention-resistant optimal path allocation scheme. Here, it should be understood that the path selection of multiple flows in the same round is mutually coupled—any flow that chooses to pass through a certain link will crowd out the actual available share of other concurrent flows on that link. The approach of each flow independently using static available bandwidth for greedy route selection in the first embodiment is no longer applicable.

[0043] Therefore, for each round group in the set of concurrent flow groups calibrated by round, joint path game optimization is performed on the feature matrix of the physical topology hypergraph of the computing network. First, several candidate physical paths are enumerated for the k-th concurrent flow in the round group. Then, a max-min fair game function is constructed with the optimization objective of maximizing the actual throughput of the slowest flow in the round. The core improvement of this function is that for any physical link, its available bandwidth is no longer assumed to be exclusively occupied by each flow, but is instead divided by all concurrent flows passing through the link in the same round according to a fair share.

[0044] The competition correction path score for round-perception is represented as:

[0045] in, For the first Concurrent flow path selection Time-based perception, competition, path correction, and score; To be assigned to the Alternative physical paths for concurrent flows; For path The single-hop physical link in; This is the positive incentive coefficient for bandwidth on path score; For link Total physical available bandwidth; In the first In each protocol round, the current path allocation scheme passes through the links The number of concurrent streams, i.e., the contention coefficient; This represents the current round number of the protocol being planned. For link Cross-domain communication delay; To prevent smooth minimum normal quantities with a denominator of zero; The penalty coefficient for protocol resolution overhead caused by routing hop count; For path Total number of hops through gateways or routers.

[0046] It should be noted that It depends on the path selection results of all flows in that round, that is, the path selection of each flow is coupled to form a game structure. To solve this, a Nash equilibrium iterative strategy is adopted: each flow, under the condition that the path selection of other flows is fixed, greedily updates its own path to the candidate path with the highest current competitive correction score, and iterates repeatedly until the global convergence reaches a stable equilibrium state in which no single flow can improve its own score by unilaterally changing its path.

[0047] Finally, the optimal physical path selected by each concurrent flow at the game equilibrium point is output and encapsulated as an anti-contention optimal path allocation scheme. By introducing the game coupling relationship between concurrent flows, the actual throughput of each flow during actual concurrent execution of dense traffic is not lower than the protocol round synchronization timeout threshold, fundamentally eliminating the risk of protocol blocking and deadlock caused by ignoring contention.

[0048] Furthermore, based on the protocol round-by-round timing arrangement rules, the optimal path allocation scheme for contention-resistant scenarios is compiled with time window labels and encapsulated with flow table action sequences according to round numbers to obtain the dense data flow routing topology. In other words, after solving the game theory problem, the mathematical path allocation results are transformed into forwarding instructions that can be directly executed by the underlying network devices. Specifically, the optimal path planning instructions for each concurrent flow in the contention-resistant optimal path allocation scheme are time-arranged according to the protocol round numbers—paths of each flow within the same round are marked as concurrently active, and paths between different rounds are marked as having a strict sequential triggering relationship.

[0049] Finally, all path planning instructions are compiled into flow table action sequences that can be executed by the underlying routers and carry round time window labels, and encapsulated to generate a dedicated routing topology for dense data flow. Compared with the static routing rules generated in the first embodiment, the improved routing topology has dynamic scheduling capabilities in the protocol round time dimension, enabling time-division multiplexing of physical network resources between different rounds, and further improving the effective utilization rate of cross-domain backbone links in scenarios where multiple protocol rounds are executed alternately.

[0050] In summary, through the second embodiment described above, the round-based synchronization coupling constraint of cryptographic protocols is explicitly introduced into the privacy computing routing planning of a multi-entity computing network convergence environment, and the traditional flow-by-flow independent greedy pathfinding is upgraded to round-based concurrent flow joint game-theoretic routing. This ensures that during the actual concurrent transmission and execution of encrypted data, the encrypted flows within the same protocol round no longer blindly cluster on the same high-bandwidth link, leading to contention and starvation. Instead, a fair and distributed allocation of bandwidth is achieved at the game equilibrium point, ensuring that the actual throughput of each flow meets the protocol round-based synchronization timeout constraint. This fundamentally eliminates the risk of global blocking and communication deadlock in multi-party secure computing protocols caused by concurrent bandwidth contention. Simultaneously, through the round-based time window label-driven time-division multiplexing routing mechanism, physical link resources are fully reused in time across different protocol rounds, effectively improving the overall bandwidth utilization of cross-domain computing network backbone links and reducing end-to-end transmission latency for cross-domain encrypted data flow. This provides a solid network-level guarantee for the real-time performance and reliability of large-scale multi-entity privacy collaborative computing tasks.

[0051] Specifically, in step S3, hierarchical remote authentication and cross-domain batch cross-validation are performed on nodes within each domain of the collaborative scheduling allocation table to obtain a set of cross-domain trust endorsement certificates and a channel negotiation key. It should be understood that in a multi-entity computing network convergence environment, the physical nodes participating in collaborative computing belong to different autonomous systems and management entities. These entities exhibit high data heterogeneity, inconsistent interests, and untraceable behavior, leading to high trust establishment costs and difficulties in detecting malicious nodes during collaborative computing. If privacy-preserving computation tasks are executed directly on nodes without trusted verification, malicious nodes may steal encrypted data, tamper with computation results, or forge the execution environment, fundamentally undermining the security of privacy-preserving computation. Therefore, in the technical solution of this application, hierarchical remote authentication is performed on nodes within each domain of the collaborative scheduling allocation table before data flow to verify the integrity of their trusted execution environment. Cross-domain batch cross-validation establishes mutual trust relationships between different autonomous systems, ultimately generating a set of cross-domain trust endorsement certificates as identity credentials for subsequent cross-domain communication. Simultaneously, a channel negotiation key is negotiated as the encryption protection basis for encrypted data transmission.

[0052] Figure 4 This is a flowchart of step S3 in the data privacy computation method under a multi-entity computing network fusion environment according to an embodiment of this application. Figure 4 As shown, S3 includes: S31, sending dynamic random challenge numbers to each target node in the collaborative scheduling allocation table through the data processing unit, driving the trusted execution environment hardware of each node to authenticate the code metric value and the running status metric value by signing the private key to obtain the hardware metric report set of the node in the domain; S32, using the signature aggregation acceleration engine built into the data processing unit, performing algebraic compression aggregation on each node-level signature in the hardware metric report set of the node in the domain to generate a domain-level single signature, and performing batch cross-signature mutual recognition with each cross-domain gateway to obtain a cross-domain trust endorsement certificate set; S33, based on the cross-domain mutual trust foundation established by the cross-domain trust endorsement certificate set, generating a temporary public key pair through the elliptic curve temporary key exchange protocol, and performing symmetric session key negotiation by mixing the global synchronization timestamp anti-counterfeiting factor into the key derivation function to obtain the channel negotiation key.

[0053] Specifically, in step S31, the data processing unit sends dynamic random challenge numbers to the target nodes in each domain of the collaborative scheduling allocation table, driving the trusted execution environment hardware of each node to perform authentication private key signing on the code metric value and the runtime status metric value to obtain the hardware metric report set of the nodes in the domain. In this process, firstly, the list of physical computing nodes assigned to logical participant nodes in each autonomous system is extracted from the collaborative scheduling allocation table to determine the set of target nodes requiring remote proof in each autonomous system. Then, the data processing unit deployed in each autonomous system acts as the verification initiator, sending dynamic random challenge numbers to each target node in its domain. These dynamic random challenge numbers are generated in real-time by a hardware true random number generator built into the data processing unit, and a different random challenge number is used for each remote proof session to prevent replay attacks.

[0054] Upon receiving a dynamic random challenge number, the trusted execution environment (TEX) hardware of each target node performs the following measurement and signing operations: First, the TEX hardware performs a cryptographic hash operation on all currently loaded code within the enclave to obtain a code metric value, which uniquely identifies the integrity status of the running code within the enclave. Then, the TEX hardware performs a cryptographic hash operation on the current runtime security configuration of the enclave (including enclave configuration parameters, security version number, debug mode flag, allowed signer identities, etc.) to obtain a runtime status metric value. Finally, the TEX hardware concatenates the code metric value, the runtime status metric value, and the received dynamic random challenge number into a message body to be signed, and performs a digital signature operation on the message body using the authentication private key built into the hardware.

[0055] Each target node encapsulates its code metric, runtime status metric, received dynamic random challenge count, and digital signature value into a hardware metric report and sends it back to the data processing unit of its domain. After collecting the hardware metric reports of all target nodes within the domain, the data processing unit first verifies the signature in each report using the public key corresponding to each node's authentication private key. Once the signature is confirmed to be valid and the metric is consistent with the expected baseline value, all verified reports are aggregated into a domain-wide node hardware metric report set.

[0056] Specifically, in step S32, the data processing unit utilizes its built-in signature aggregation acceleration engine to perform algebraic compression aggregation on the node-level signatures in the hardware metric report set of nodes within the domain to generate a domain-level single signature. This single signature is then cross-signed and mutually recognized with each cross-domain gateway to obtain a cross-domain trust endorsement certificate set. In this process, the data processing unit first uses its built-in signature aggregation acceleration engine to perform algebraic compression aggregation on the node-level signatures in the hardware metric report set of nodes within the domain. The signature aggregation uses a bilinear pairing mapping-based aggregation signature scheme to compress the elliptic curve digital signatures independently generated by multiple nodes within the same autonomous system into a single domain-level single signature through elliptic curve point addition operations. This aggregated signature has batch verification capabilities, meaning that the verifier only needs one verification operation to confirm that the metric reports of all nodes within the domain are authentic and valid. After aggregation, the data processing unit encapsulates the domain-level aggregated signature along with metadata such as the list of metric values ​​of all nodes within the domain and the dynamic random challenge number into a domain-level remote proof digest.

[0057] Secondly, the border gateway of each autonomous system sends its domain-level remote proof digest (including the domain-level aggregate signature) to the border gateways of all other autonomous systems. Each receiving border gateway performs batch verification on the received domain-level aggregate signature. The verification process uses the authentication public keys of all nodes in the sending domain to perform a bilinear pairing verification operation with the aggregate signature to confirm that the aggregate signature was indeed jointly generated by all the claimed nodes and that the corresponding metric value has not been tampered with.

[0058] Subsequently, after successful verification, the receiving boundary gateway uses its own domain-level management private key to cross-sign the sender's domain-level remote proof digest, indicating that its domain recognizes the trusted state of all nodes within the sender's domain. Once all autonomous systems (AS) have completed pairwise batch cross-signature mutual recognition, each AS collects the cross-signatures of its own domain-level remote proof digest from all other ASs, and encapsulates its own domain-level remote proof digest along with all received cross-signatures into a cross-domain trust endorsement certificate. The cross-domain trust endorsement certificates from all ASs converge to form a cross-domain trust endorsement certificate set. Each certificate in this set contains the holding domain's domain-level aggregate signature, a list of metrics, and cross-signature recognition from all other domains, thus establishing a cross-domain mutual trust relationship between multiple parties at the cryptographic level.

[0059] Specifically, in step S33, based on the cross-domain mutual trust foundation established by the cross-domain trust endorsement certificate set, a temporary public key pair is generated through the elliptic curve temporary key exchange protocol. A symmetric session key negotiation is then performed using a key derivation function mixed with a globally synchronized timestamp anti-counterfeiting factor to obtain the channel negotiation key. In this process, firstly, both parties of each communication node pair verify the validity of the cross-domain trust endorsement certificate held by the other party, confirming that the other party node has indeed passed hierarchical remote proof and obtained cross-domain mutual trust recognition, which serves as a trust prerequisite for key exchange. Specifically, the communication initiator checks whether the domain-level aggregate signature and cross-signature in the other party's certificate are valid, confirming that the trusted execution environment of the other party node is in the expected secure state. Secondly, after confirming the trustworthiness of the other party, both parties execute the elliptic curve temporary key exchange protocol. Each communicating party generates a temporary elliptic curve key pair locally, including a temporary private key and a temporary public key. Specifically, the trusted execution environment hardware of each node uses a built-in true random number generator to generate a random scalar as a temporary private key, and then performs a scalar multiplication operation between this temporary private key and the base point of the elliptic curve to obtain the temporary public key. Subsequently, after exchanging their respective temporary public keys through a verified secure channel, each party uses its own temporary private key to perform an elliptic curve multiplication operation with the other party's temporary public key to obtain the same shared secret point.

[0060] After obtaining the shared secret point, it is transformed into fixed-length key material suitable for symmetric encryption algorithms. At this point, a global synchronization timestamp anti-counterfeiting factor is introduced as an additional input for key derivation. This timestamp is provided by the global time synchronization service of the computing network, and all participating nodes share the same time base. By binding the key negotiation process to a specific time point, it prevents attackers from replaying intercepted temporary public keys in different time windows to perform man-in-the-middle attacks. Specifically, the coordinates of the shared secret point are concatenated with the global synchronization timestamp anti-counterfeiting factor and input into the key derivation function, outputting a fixed-length symmetric session key. The above temporary key exchange and key derivation process is executed one by one for all communication node pairs determined in the collaborative scheduling allocation table, and each pair of communication nodes obtains its own independent channel negotiation key.

[0061] Specifically, in step S4, based on the congestion-free transmission path planned by the encrypted data flow routing topology, and utilizing the channel negotiation key and cross-domain trust endorsement certificate set, the original business data locally of each node is encrypted, fragmented, and collaboratively computed within a trusted execution enclave to obtain an encrypted intermediate result stream. It should be understood that after obtaining the cross-domain trust endorsement certificate set and channel negotiation key in step S3, the cross-domain trust relationship between participating nodes has been established, and the encryption protection key for the communication channel has been negotiated and is ready. However, the original business data held locally by each node (such as power load data, user electricity consumption behavior data, equipment operating parameters, etc.) is still stored in plaintext locally and has not yet been converted into an encrypted form that can be securely transferred in the cross-domain network, nor has actual privacy-preserving collaborative computation been performed. In a multi-entity computing network convergence environment, the original data of each participating party is subject to data sovereignty, trade secrets, and legal and regulatory constraints and cannot leave the local domain in plaintext form. Cross-entity collaborative computation must be achieved under the premise that the data does not leave the domain. Therefore, in the technical solution of this application, the original business data is transformed into a cryptic fragment form within the trusted execution enclave of each node. Collaborative operations are performed on the cryptic fragments to obtain cryptic calculation results. Then, the cryptic results are encrypted and encapsulated using the channel negotiation key. Based on the congestion-free transmission path planned by the cryptic data flow routing topology, the cryptic intermediate results are securely pushed to the collaborative nodes, ultimately forming a cryptic intermediate result stream that continuously flows in the cross-domain network, achieving dual protection of data "usable but invisible" and the calculation process "trustworthy and verifiable".

[0062] In practice, firstly, after authenticating the peer using a cross-domain trust endorsement certificate set, the original local business data of each node is embedded as a constant term within the trusted execution enclave, and secretly segmented at each independent evaluation point to obtain local encrypted data fragments for the computing network nodes. In this process, the peer is first authenticated using the cross-domain trust endorsement certificate set. Specifically, the communication initiator extracts the cross-domain trust endorsement certificate of the autonomous system to which the peer node belongs from the cross-domain trust endorsement certificate set, verifies the validity of the domain-level aggregate signature in the certificate (using bilinear verification using the authentication public keys of each node within the peer domain), and simultaneously verifies whether the cross-signature of the certificate in this domain is generated by the domain-level management private key of this domain. If both verifications pass, the peer's identity is confirmed to be legitimate and its trusted execution environment is in a secure state, allowing subsequent data interaction operations.

[0063] After authentication, the original business data is secretly partitioned within the local trusted execution enclave. Specifically, this is achieved using a polynomial evaluation mechanism based on the Shamir secret sharing scheme: First, within the trusted execution enclave, the node's local original business data (such as a numerical business metric) is embedded as a constant term of a random polynomial over a finite field, i.e., a polynomial of degree 1 is constructed. The random polynomial, where To reconstruct the threshold, the constant term of the polynomial is set to the original business data value, while the remaining coefficients are independently generated by a true random number generator within the enclave. The construction process of the random polynomial is as follows:

[0064] in, For the constructed random polynomial; The original business data value (i.e., embedded as a constant term); The coefficients are independently and uniformly generated randomly over a finite field by a trusted execution enclave true random number generator; To reconstruct the threshold, it means that at least... Only by reconstructing these fragments can the original secret be reconstructed.

[0065] Then, select distinct evaluation points on the finite field, equal in number to the number of participants, and evaluate the polynomial at each point. Each evaluation result is a secret data slice assigned to the corresponding participant. The formula for calculating secret partitioning is:

[0066] in, To be assigned to the Data fragmentation of each participant's encrypted data; For the first Each participant has an independent evaluation point (which is publicly agreed upon in advance among all participants and is distinct from each other); The total number of participants.

[0067] After each node completes polynomial evaluation within the trusted execution enclave, it obtains a set of encrypted data fragments for all participants. The fragments allocated to the node itself are retained locally, while the fragments allocated to other collaborating nodes (i.e., auxiliary fragments) will be sent to the corresponding collaborating nodes subsequently via a secure channel. After all participating nodes have performed the aforementioned secret partitioning operation, each node holds a local fragment from its own original data and auxiliary fragments received from other nodes. These two fragments together constitute the complete set of encrypted data fragments for the node's participation in subsequent collaborative computations; that is, the local encrypted data fragments of the computing network node.

[0068] Next, the local encrypted data fragments of the computing network node are unloaded from the host memory and dumped into the hardware-accelerated pipeline of the cryptographic arithmetic logic unit in the data processing unit. Masked algebraic logic operations and message authentication codes are then performed on the local fragments and the auxiliary fragments passed in from the collaborating nodes to obtain the single-node encrypted computation result. In this process, the local encrypted data fragments of the computing network node are first unloaded from the host memory of the trusted execution enclave and dumped into the hardware-accelerated pipeline of the cryptographic arithmetic logic unit in the data processing unit. The data unloading and dumping process is completed through a secure direct memory access channel between the data processing unit and the host. The encrypted fragment data within the enclave is encrypted and encapsulated before being transmitted through this channel to the on-chip secure memory of the data processing unit. The entire transmission process is protected by hardware encryption to prevent privileged software on the host side from eavesdropping on or tampering with the data during transmission.

[0069] After the encrypted data fragments arrive at the cryptographic arithmetic logic unit of the data processing unit, they enter the hardware-accelerated pipeline to perform masked algebraic logic operations. Specifically, firstly, a random mask value is introduced to mask the local fragment, that is, the local fragment is added to a random mask value generated in real time by a hardware true random number generator of the data processing unit in a finite field, to obtain the masked local fragment; then, the masked local fragment is combined with the auxiliary fragment received from the cooperating node to perform finite field algebraic logic operations (including finite field addition and finite field multiplication). The specific operation type depends on the computation logic required by the privacy computation protocol (e.g., share addition in the secret sharing scheme corresponds to joint summation, and share multiplication corresponds to joint product); finally, after the operation is completed, the influence of the mask is removed to obtain the correct encrypted computation result.

[0070] After completing the mask algebraic logic operations, a message authentication code fusion operation is performed on the encrypted operation output. This involves using the channel negotiation key as the message authentication code key, calculating the message authentication code on the encrypted operation output, and binding and encapsulating it with the output. Specifically, the calculation formula for message authentication code fusion is as follows:

[0071] in, For the first The message authentication code output by the secret state operation of each node; It is a hash-based message authentication code algorithm; The channel negotiation key obtained in step S3; Output for dense state operations; The identifier for the current privacy-preserving computation session; This is the sequence number of the current computation round; This is a bit string concatenation operation. It is performed by outputting the dense state operation. With the corresponding message authentication code The binding and encapsulation process yields a single-node encrypted computation result. This result includes both the numerical output of the encrypted computation and an integrity verification credential. The receiver can confirm that the result has not been tampered with during transmission by recalculating the message authentication code and comparing it with the attached value.

[0072] Furthermore, based on the channel negotiation key, the single-node encrypted calculation result is symmetrically encrypted and integrity-tagged and encapsulated. Then, according to the congestion-free end-to-end path identifier assigned to the current node in the encrypted data flow routing topology, outer protocol headers are concatenated and cross-domain concurrent push is performed to obtain the encrypted intermediate result stream. In this process, firstly, the single-node encrypted calculation result is symmetrically encrypted using the channel negotiation key obtained in step S3. Specifically, an authentication encryption mode is adopted, generating an authentication tag during encryption to achieve both confidentiality protection and integrity verification in one step. After encryption, the encrypted ciphertext, authentication tag, and additional authentication data are combined and encapsulated into an integrity-tagged encrypted data packet. Any tampering with this data packet during transmission will cause the receiver's authentication tag verification to fail and be detected.

[0073] Furthermore, each node, based on the congestion-free end-to-end path identifier assigned to it in the encrypted data flow routing topology, appends network protocol header information to the outer layer of the encrypted data packet. The outer protocol header includes: the source node's physical address, the destination node's physical address (i.e., the aggregation node's address), the congestion-free end-to-end path identifier (used by the SDN switch to identify which pre-planned path the data packet should follow for forwarding), the protocol round time window label (identifying which protocol round the data packet belongs to, used by the receiver for ordered reassembly according to round), the data packet sequence number (used by the receiver to detect packet loss and out-of-order delivery), and the data packet length field. The logical structure of the outer protocol header appending is as follows:

[0074] in, For the first The complete cryptic data packet output by each node; Construct the outer protocol header constructor; For the first The physical address of each node; The physical address of the destination aggregation node; In the routing topology for dense data flow, the first... Each node is assigned a congestion-free end-to-end path identifier; This is the current round number of the protocol. This is the data packet sequence number; This is a encrypted and encapsulated data packet.

[0075] After the outer protocol header is assembled, each node submits the encapsulated encrypted data packet to the sending queue of the local SDN switch. The SDN switch looks up the pre-installed flow table rules based on the congestion-free end-to-end path identifier in the data packet and forwards the data packet hop-by-hop along the pre-planned congestion-free path. Since the encrypted data flow routing topology has ensured that there is no bandwidth congestion on the paths of each communication node pair in step S2, all nodes can concurrently push their respective encrypted data packets within the same time window without link contention or transmission blockage. The encrypted data packets pushed concurrently by all participating nodes continuously flow in the cross-domain network, forming an encrypted intermediate result stream that converges from each computing node to the aggregation node. This data stream is protected by symmetric encryption of the channel negotiation key and the integrity guarantee of the authentication tag throughout the entire transmission process, providing a secure, complete, and orderly encrypted input for aggregation decryption and audit proof encapsulation in the subsequent step S5.

[0076] Specifically, in step S5, within the highest security level trusted execution environment, the encrypted intermediate result stream is aggregated, decrypted, and encapsulated with audit proof to obtain the joint computation result and trusted execution audit log. It should be understood that in a multi-entity computing network convergence environment, multiple participants (such as different cloud service providers, edge nodes, and data centers) complete cross-domain encrypted data collaborative computation through privacy computing protocols. The encrypted intermediate result streams output by each node have converged to the master node or the highest security level computing domain along a congestion-free transmission path. However, these intermediate results are still in a state of fragmented encryption or secret sharing, and cannot be directly presented as usable joint computation results. Therefore, to establish an end-to-end verifiable high-security computing link, ensure that critical computing operations are executed in a trusted environment, effectively defend against internal and external security threats, and achieve secure provability and auditability of the computing process, the technical solution of this application aggregates and decrypts the encrypted intermediate result stream to restore the final joint computation result, and generates an immutable trusted execution audit log through audit proof encapsulation, providing traceable and verifiable integrity evidence for the entire cross-domain privacy computing task.

[0077] In practice, firstly, each data packet in the encrypted intermediate result stream is parsed and its integrity is verified to obtain a valid encrypted fragment set. During this process, the aggregation node's network interface continuously receives encrypted data packets pushed by participating nodes through the cross-domain network. The received raw byte stream is first parsed. The parsing process follows the data packet format defined in step S4, extracting metadata such as the source node address, path identifier, protocol round number, and sequence number from the outer protocol header, as well as the inner encrypted ciphertext, authentication tag, and additional authentication data. Data packets belonging to the same protocol round are sorted and reassembled according to their sequence numbers. Packet loss (discontinuous sequence numbers) or duplicate packets (repeated sequence numbers) are detected. Duplicate packets are deduplicated, and packet loss is recorded and marked.

[0078] After data parsing is complete, integrity verification is performed on each data packet. Integrity verification has two levels: The first level is authentication encryption tag verification. The authentication tag is recalculated using the channel negotiation key and the additional authentication data. The calculated tag is compared with the authentication tag attached to the data packet. If they match, it confirms that the data packet has not been tampered with during network transmission; if they do not match, the data packet is determined to be corrupted or tampered with by an attacker, marked as invalid, and discarded. The second level is message authentication code verification. The single-node encrypted calculation result obtained after decryption is verified against the message authentication code. The message authentication code output from the encrypted operation is recalculated using the channel negotiation key according to the message authentication code calculation method defined in step S4. The calculation result is compared with the message authentication code attached to the data packet. If they match, it confirms that the encrypted operation output has not been tampered with during the calculation process in step S4.

[0079] After two levels of integrity verification and filtering, all verified encrypted fragments are retained and aggregated into a valid encrypted fragment set. Each fragment in this set has been confirmed to have a trustworthy source, an intact transmission process, and an unaltered computation process, and can be safely used for subsequent fault-tolerant threshold algebra reconstruction.

[0080] Next, within the highest-security-level trusted execution environment (TEX) enclave, the verified valid encrypted fragment set undergoes fault-tolerant threshold algebra reconstruction and decryption restoration to obtain the joint computation result. Simultaneously, a hardware monitor captures instruction snapshots during the trajectory generation and aggregation process. In this process, the verified valid encrypted fragment set is first loaded into the secure memory region of the highest-security-level TEX enclave. This loading process is executed through the enclave's secure entry point, ensuring that the fragment data is protected by hardware-level confidentiality and integrity after entering the enclave. While the fragment data is loaded into the enclave's secure memory, the hardware monitor is activated to begin trajectory recording. The hardware monitor captures the trajectory information of each instruction executed by the processor within the enclave, as well as the state changes of critical memory regions, in a non-intrusive manner.

[0081] Perform a fault-tolerant threshold algebraic reconstruction operation within the enclave. First, check whether the number of valid fragments in the verified valid dense-state fragment set reaches the preset reconstruction threshold. If the number of effective fragments (in The number of valid fragments that pass the integrity check. If the fault tolerance threshold is met (i.e., if the number of valid fragments is insufficient to meet the threshold), then reconstruction can be performed; if the number of valid fragments is insufficient, an exception handling process (such as requesting retransmission of missing fragments) is triggered. If the fault tolerance threshold is met, fragments are selected from the set of valid fragments. Each segment performs Lagrange interpolation reconstruction. The fault-tolerant threshold algebra reconstruction is based on the Lagrange interpolation formula of the Shamir secret sharing scheme, applied over a finite field according to... The original polynomial at its zeros (i.e., the original secret value) is reconstructed by a linear combination of Lagrange polynomials using each piecewise value and its corresponding evaluation point. Specifically, the calculation formula for the fault-tolerant threshold algebraic reconstruction is:

[0082]

[0083] in, The joint computation result obtained from the reconstruction; For the first The value of each effective dense state segment (i.e., the single-node dense state calculation result of each node); For the first Lagrange interpolation coefficients corresponding to each segment; For the first Each piece corresponds to an evaluation point; For the first Each piece corresponds to an evaluation point. All the above operations are performed over a finite field, with division implemented using the multiplicative inverse of the finite field. Because the design of the multi-party secure computation protocol guarantees that each node's secret computation result piece corresponds to a secret shared share of the joint computation function's output, the reconstructed result... This is the correct joint calculation result after executing the target calculation function on the original business data of all participants.

[0084] Throughout the entire process of fault-tolerant threshold algebraic reconstruction, the hardware monitor continuously captures the instruction execution trajectory and memory state changes within the enclave, including the operands and results of each finite field multiplication operation, intermediate values ​​of the Lagrange coefficients, and the time and location at which the final reconstruction result is written to secure memory. After the reconstruction operation is completed, the hardware monitor summarizes all captured trajectory information and the state of key memory regions to generate an aggregated process memory state snapshot. This snapshot is stored cryptographically in a dedicated audit area of ​​the enclave's secure memory, and cannot be accessed or tampered with by any software outside the enclave, providing complete execution evidence for subsequent audit proof encapsulation.

[0085] Furthermore, using the highest-level hardware authentication private key of the master node, the memory state snapshot of the aggregation process and the hash value of the joint computation result are concatenated and bound, and a global anti-counterfeiting timestamp is added for cryptographic signing to obtain a trusted execution audit log. In this process, firstly, within the highest-security trusted execution environment enclave, a cryptographic hash operation is performed on the joint computation result to obtain its hash value. Then, the memory state snapshot of the aggregation process and the hash value of the joint computation result are concatenated and bound to inseparably link the "evidence of the computation process execution" with the "digital fingerprint of the computation result," allowing auditors to simultaneously confirm during verification that the result was produced by a specific execution process and that the execution process was indeed correctly completed in a trusted environment. After the concatenation operation, a global anti-counterfeiting timestamp is added as a time binding factor. This timestamp, provided by the global time synchronization service of the computing network, is accurate to the millisecond level. Its purpose is to prevent attackers from replaying intercepted audit logs at different times and impersonating the current audit result. Finally, the concatenated complete audit content is cryptographically signed using the highest-level hardware authentication private key of the master node. The signature operation is performed within the hardware signature engine of the highest-security trusted execution environment enclave. The highest-authority hardware authentication private key never leaves the hardware security boundary, ensuring the signature's unforgeability. After signing, the signature value, the memory state snapshot of the aggregation process, the hash value of the joint calculation result, the global anti-counterfeiting timestamp, and the public key certificate chain corresponding to the highest-authority hardware authentication private key of the master node are collectively encapsulated into a complete trusted execution audit log.

[0086] Any participant or third-party auditor holding the master node hardware authentication public key (whose authenticity can be verified through the hardware vendor's certificate chain) can verify the authenticity of the audit log through the following verification process: extract the signature value, the memory state snapshot of the aggregation process, the hash value of the joint computation result, and the global anti-counterfeiting timestamp from the audit log. Concatenate the latter three and calculate the hash value. Use the public key to perform an elliptic curve digital signature verification operation on the signature value. If the verification passes, it confirms that the audit log was indeed generated by the master node's highest security level trusted execution environment hardware and has not been tampered with, thus proving that the joint computation result was produced by the correct aggregation process in a trusted environment.

[0087] In summary, the data privacy computing method in a multi-entity computing network fusion environment according to the embodiments of this application is explained. It achieves optimal allocation of privacy computing tasks to physical resources and congestion-free routing and orchestration of encrypted data flows by deeply coupling the logical communication semantics of the privacy computing protocol with the physical topology characteristics of the computing network through protocol dependency-driven graph construction and homomorphic hypergraph mapping. Simultaneously, it introduces hierarchical remote proof and cross-domain batch cross-validation to establish an end-to-end trust link, and completes encrypted sharding collaborative computation and aggregation auditing within a trusted execution enclave, forming a closed-loop privacy computing process. This significantly reduces the communication overhead of cross-domain encrypted data flow, eliminates the risk of global blocking caused by concurrent contention in protocol rounds, reduces the cost of establishing trust among multiple entities, and thus achieves end-to-end trusted auditing of the computing process.

[0088] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A data privacy computation method in a multi-entity computing network fusion environment, characterized in that, include: S1, based on protocol dependencies, feature extraction and graph construction are performed on the acquired original configuration data of the computing network privacy computing to obtain the privacy computing logical communication graph and the feature matrix of the computing network physical topology hypergraph; S2, based on the optimization objective of minimizing cross-domain communication overhead, performs homomorphic hypergraph mapping and path planning on the feature matrix of the privacy computing logical communication graph and the computing network physical topology hypergraph to obtain the cooperative scheduling allocation table and the dense data flow routing topology; S3, perform hierarchical remote proof and cross-domain batch cross-verification on each node in the collaborative scheduling allocation table to obtain a set of cross-domain trust endorsement certificates and a channel negotiation key; S4, based on the congestion-free transmission path planned by the encrypted data flow routing topology, and using the channel negotiation key and cross-domain trust endorsement certificate set, performs encrypted fragmentation and collaborative operation on the local original business data of each node in the trusted execution enclave to obtain the encrypted intermediate result stream. S5, in the highest security level trusted execution environment, aggregates, decrypts, and encapsulates the encrypted intermediate result stream with audit proof to obtain the joint computation result and trusted execution audit log.

2. The data privacy computation method in a multi-entity computing network fusion environment according to claim 1, characterized in that, The raw configuration data for privacy computing on the network includes cross-domain gateway routing table data, node trusted execution environment hardware quota parameters, and multi-party secure computation protocol syntax tree.

3. The data privacy computation method in a multi-entity computing network fusion environment according to claim 2, characterized in that, Step S1 includes: Cryptographic operator dependency parsing and data flow extraction are performed on the syntax tree of the multi-party secure computation protocol to obtain the privacy computation logic communication graph. Simultaneously, the cross-domain gateway routing table data and node trusted execution environment hardware quota parameters are timestamped and dimensionally concatenated to obtain the original heterogeneous state set of the computing network. A high-dimensional spatial joint projection embedding is performed on the network connection weights and trusted hardware quotas of each physical node in the original heterogeneous state set of the computing network to obtain the high-dimensional feature tensor of the computing network. Based on the network autonomous domain affiliation relationship, the physical nodes belonging to the same boundary gateway in the high-dimensional feature tensor of the computing network are partitioned into hyperedges and associated matrices are constructed. Then, multi-dimensional spatial normalization mapping is performed through the hypergraph convolution projection mechanism to obtain the feature matrix of the computing network physical topology hypergraph.

4. The data privacy computation method in a multi-entity computing network fusion environment according to claim 1, characterized in that, Step S2 includes: Based on the joint cost evaluation function of node mapping computing power gap penalty and logical communication volume ratio to physical bandwidth, the joint cost space from logical node to physical node is constructed on the feature matrix of privacy computing logical communication graph and computing network physical topology hypergraph to obtain the homomorphic mapping joint cost tensor. With the goal of minimizing the global cross-domain cryptographic communication overhead, the cooperative scheduling allocation table is obtained by iteratively solving the graph homomorphic optimal matching solution of the joint cost tensor of homomorphic mapping. End-to-end congestion-free path addressing and flow table compilation are performed on each communication node pair in the feature matrix of the physical topology hypergraph of the computing network to obtain the dense data flow routing topology.

5. The data privacy computation method in a multi-entity computing network fusion environment according to claim 1, characterized in that, Step S3 includes: The data processing unit sends dynamic random challenge numbers to each target node in the collaborative scheduling allocation table, driving the trusted execution environment hardware of each node to authenticate and sign the code metric value and the running status metric value with private keys to obtain the hardware metric report set of the node in the domain. Using the signature aggregation acceleration engine built into the data processing unit, the signatures of each node in the hardware metric report set of the node in the domain are algebraically compressed and aggregated to generate a domain-level single signature, and then batch cross-signature mutual recognition is performed with each cross-domain gateway to obtain a set of cross-domain trust endorsement certificates. Based on the cross-domain mutual trust foundation established by the cross-domain trust endorsement certificate set, a temporary public key pair is generated through the elliptic curve temporary key exchange protocol, and a symmetric session key negotiation is performed by inputting the global synchronization timestamp anti-counterfeiting factor into the key derivation function to obtain the channel negotiation key.

6. The data privacy computation method in a multi-entity computing network fusion environment according to claim 1, characterized in that, Step S4 includes: After authenticating the identity of the interactive peer using a cross-domain trust endorsement certificate set, the original local business data of each node is embedded as a constant term within the trusted execution enclave and secretly segmented at each independent evaluation point to obtain local secret state data fragments of the computing network node. The local encrypted data fragments of the computing network node are unloaded from the host memory and moved to the hardware acceleration pipeline of the cryptographic arithmetic logic unit of the data processing unit. The local fragments and the auxiliary fragments passed in by the cooperative nodes are fused with mask algebra logic operations and message authentication codes to obtain the encrypted calculation result of a single node. Based on the channel negotiation key, the single-node encrypted calculation result is symmetrically encrypted and integrity-labeled and encapsulated. Then, based on the congestion-free end-to-end path identifier assigned to the current node in the encrypted data flow routing topology, the outer protocol header is concatenated and cross-domain concurrent push is performed to obtain the encrypted intermediate result stream.

7. The data privacy computation method in a multi-entity computing network fusion environment according to claim 1, characterized in that, Step S5 includes: The data packets in the encrypted intermediate result stream are parsed and their integrity is verified and filtered to obtain a valid encrypted fragment set after verification. Within the highest security level trusted execution environment enclave, the valid encrypted fragment set after verification is reconstructed by fault-tolerant threshold algebra and decrypted to obtain joint calculation results. Simultaneously, the hardware monitor captures the memory state snapshot of the trajectory generation aggregation process by capturing the instructions. By using the highest-level hardware authentication private key of the master node, the memory state snapshot of the aggregation process and the hash value of the joint calculation result are concatenated and bound, and a global anti-counterfeiting timestamp is added for cryptographic signature to obtain a trusted execution audit log.

8. The data privacy computation method in a multi-entity computing network fusion environment according to claim 1, characterized in that, End-to-end congestion-free path addressing and flow table compilation are performed on each communication node pair in the feature matrix of the physical topology hypergraph of the computing network to obtain the dense data flow routing topology, including: Based on the hierarchical analysis of the data dependency depth of each logical edge in the privacy computing logic communication graph, the logical edges with the same dependency depth are grouped by protocol round and projected onto physical communication pairs by the joint collaborative scheduling allocation table to obtain the round-marked concurrent flow group set. For each concurrent flow in the same round of the round-calibrated concurrent flow group set, a joint path game is performed on the feature matrix of the computing network physical topology hypergraph to obtain the optimal path allocation scheme against contention. Based on the protocol round-by-round timing arrangement rules, the optimal path allocation scheme for adversarial contention is compiled with time window labels and encapsulated with flow table action sequences according to round number to obtain the dense data flow routing topology.

Images