Method for automatic deployment of heterogeneous hardware of privacy computing platform

Abstract

The application discloses a kind of heterogeneous hardware automation deployment methods of privacy computing platform, to solve the problems of lack of hardware capability perception, mismatch of cryptography primitives and hardware acceleration capability and lack of hardware basis in protocol negotiation when existing technology is deployed in heterogeneous hardware environment.The method comprises: starting hardware probe in each node, obtaining CPU instruction set, trusted execution environment and cryptography accelerator capability, generating hardware capability descriptor signed by digital signature;After the task is decomposed into atomic cryptography primitives, the mapping of primitives and hardware operators is modeled as a constraint satisfaction problem and solved, and the optimal execution plan of each node is generated;With the intersection of the hardware capabilities of each node as the basis for negotiation, derive the globally compatible protocol parameter set;Atomic execution deployment and forced self-check, trigger global rollback when any link fails.The application can realize the automatic, high-performance deployment of privacy computing applications in heterogeneous hardware environment.

Description

Technical Field

[0001] This invention relates to the field of privacy computing technology, and more specifically to an automated deployment method for a privacy computing platform for heterogeneous hardware environments. Background Technology

[0002] Privacy-preserving computation technologies, particularly secure multi-party computation and federated learning, offer a crucial technological path to addressing data silos and privacy protection by enabling data to be "usable but not visible" among multiple participants. However, with the diversification of the computing ecosystem, a typical privacy-preserving computation deployment cluster may simultaneously include x86 and ARM architecture central processing units (CPUs), graphics processing units (GPUs) or field-programmable gate arrays (FPGAs) accelerator cards, as well as various types of trusted execution environments (TEEs) such as Intel SGX and AMD SEV, resulting in deep heterogeneity in the underlying hardware.

[0003] Existing privacy computing platform deployment schemes can be mainly divided into three categories.

[0004] The first type is deployment based on static protocol frameworks, represented by frameworks such as SPDZ, ABY3, and MP-SPDZ. In this approach, operations personnel pre-select the security model and computation protocol according to application requirements, manually install dependent libraries on each node, and write configuration files. Its drawback is that it assumes a homogeneous hardware environment or known node capabilities, lacking adaptability to heterogeneous underlying hardware.

[0005] The second category is hardware acceleration solutions for single cryptographic primitives, such as using GPUs to accelerate homomorphic encryption of polynomial multiplication, or using FPGAs to accelerate fully homomorphic encryption operations. While this type of solution has proven the effectiveness of hardware acceleration in improving the performance of privacy computing, its acceleration logic is fixed in the design phase and cannot automatically select the optimal execution backend based on the actual hardware environment during deployment.

[0006] The third category is cloud-native deployment solutions based on general container orchestration systems. These solutions utilize platforms such as Kubernetes for resource scheduling, but their scheduling decisions are based solely on general resource metrics such as CPU, memory, and network, and cannot be aware of heterogeneous hardware capabilities such as GPUs, FPGAs, or TEE types.

[0007] The aforementioned solutions all struggle to simultaneously achieve automatic hardware capability awareness, dynamic adaptation of cryptographic primitives, and hardware-aware negotiation between nodes during the deployment phase. Therefore, this invention provides a method and system for automated deployment of heterogeneous hardware for a privacy computing platform. Summary of the Invention

[0008] (a) Purpose of the invention

[0009] This invention aims to solve the aforementioned problems in the prior art and provides a method for automated deployment of heterogeneous hardware for a privacy computing platform. The purpose of this invention is to: achieve automated perception and quantitative modeling of node hardware capabilities through mandatory hardware probes; eliminate performance mismatch by establishing a dynamic optimal mapping between cryptographic primitives and hardware accelerators; incorporate hardware capabilities as core parameters into inter-node protocol negotiation; and ultimately achieve automated and high-performance deployment of privacy computing applications in heterogeneous hardware environments.

[0010] (II) Technical Solution

[0011] To achieve the above-mentioned objectives, this invention provides a method for automated deployment of heterogeneous hardware for a privacy computing platform, comprising the following steps:

[0012] Step S1: Hardware capability detection.

[0013] During the node agent initialization phase of each target node, the hardware probe is forcibly started with the highest execution priority. This probe performs the following operations:

[0014] S1-1: The system calls ` / proc / cpuinfo`, ` / sys / class / drm / `, `lspci -v`, and ` / dev / sgx / ` are used to retrieve CPU instruction set extensions (including AES-NI, AVX-512, and SHA-NI), GPU model and memory size, and TEE device type and version. For SGX, it verifies that the Basic Input / Output System (BIOS) is enabled and that the Enclave Page Cache (EPC) size is non-zero. For SEV, it checks the firmware status in ` / sys / kernel / debug / sev`. If the above system files do not exist or reading fails, the corresponding hardware capability is marked as "not present".

[0015] S1-2: Calling dedicated application programming interfaces (APIs) to obtain hardware performance parameters: Calling the CUDA runtime API (cudaGetDeviceProperties) to obtain GPU computing power (FP32 TFLOPS) and memory bandwidth (GB / s); calling sgx_create_enclave in the Intel SGX Software Development Kit (SDK) to obtain EPC size and enclave dynamic memory management (EDMM) support; calling the xrt::device class in the Xilinx runtime library to obtain the number of FPGA logic units and digital signal processing (DSP) slices; calling the AMD ROCm System Management Interface (ROCm SMI) API to obtain GPU performance parameters. If the API call fails, the corresponding hardware capability is marked as "unavailable," and the probe continues to perform other probing tasks.

[0016] S1-3: Perform standardized micro-benchmark tests on cryptographic primitives. Tests include: polynomial multiplication using a modulus M = 2^64 - 2^32 + 1, with degree N set to 1024, 2048, and 4096 respectively, employing the number-theoretic transformation (NTT) algorithm; elliptic curve multiplication using secp256k1 and P-256 curves; and AES-GCM symmetric encryption / decryption using a 128-bit key, with block sizes of 1KB, 16KB, and 64KB respectively. Each test is executed 100 times consecutively, and the median is used as the performance metric after removing the highest and lowest 5 runs. Execution time is recorded. If the total execution time of a test exceeds a preset threshold (10 seconds), the node is considered not to support hardware acceleration for that primitive, and the performance is marked as "not applicable."

[0017] S1-4: Integrates all probe results from S1-1 to S1-3 into a standardized JavaScript Object Representation (JSON) format Hardware Capability Descriptor (HCD). The HCD includes node identifier, probe timestamp, CPU architecture and instruction set support, TEE type, version, and activation status, accelerator model and computing power parameters, micro-benchmark results, and overall probe status. The HCD is digitally signed using the node agent's private key using the Elliptic Curve Digital Signature Algorithm (ECDSA) (curve secp256r1), and the signature value is appended to the JSON. The deployment decision center verifies the signature using the public key stored during node registration upon receiving the HCD; if verification fails, the HCD is considered invalid.

[0018] If any node probe experiences any of the following, the deployment will terminate immediately and report an error: (a) the probe process crashes or times out (timeout threshold 60 seconds); (b) a critical field is missing in the generated HCD; (c) the HCD digital signature verification fails; (d) a hardware capability marked as "must support" in the HCD (specified by the minimum capability threshold in the user task description) is marked as non-existent or unavailable.

[0019] Step S2: Primitive-operator mapping based on constraint satisfaction problem.

[0020] The intelligent mapping engine in the deployment decision center receives the HCD from all nodes and the task descriptions submitted by users, and performs the following operations:

[0021] S2-1: Task Decomposition. The engine queries a predefined "task-primitive" dictionary to decompose high-level tasks into atomic cryptographic primitives (including polynomial multiplication, elliptic curve dot product, AES encryption, and secret sharing). This dictionary is stored in a tree structure, and the decomposition granularity is defined by the "smallest execution unit" rule—an operation is considered an atomic primitive when it no longer contains sub-operations that can be independently mapped to different hardware operators.

[0022] S2-2: Candidate Operator Generation. For each atomic primitive on each node, the engine generates all feasible hardware operator candidates based on its HCD and the "Primitive-Operator-Hardware" mapping library. The mapping library is stored in a relational data table, with each record containing the primitive type, hardware requirements, operator name, expected performance model parameters, and a list of compatibility tags. Each candidate operator is accompanied by its expected execution time (calculated based on computing power metrics in the HCD and micro-benchmark results) and a list of compatibility tags.

[0023] S2-3: Constraint Satisfaction Problem (CSP) Modeling. The engine models the entire deployment decision as a joint constraint satisfaction problem:

[0024] Variables: For each primitive j (j = 1, ..., n) on each node i (i = 1, ..., m), define a discrete variable x_{i,j} ∈ C_{i,j}, where C_{i,j} is the set of all candidate operators generated for the primitive in S2-2.

[0025] Hard constraints (H1-H4, all must be satisfied simultaneously):

[0026] H1 (Hardware Matching Constraint): The hardware requirements corresponding to the operator selected by x_{i,j} must be satisfied by the HCD of this node, i.e., req(x_{i,j}) ⊆ hcd_i.

[0027] H2 (Operator Compatibility Constraint): For any two primitives j and k that need to interact with each other, the nodes i and p that are selected for x_{i,j} and x_{p,k} must satisfy compat(x_{i,j}, x_{p,k}) = true. The compatibility is determined by cross-calculation of the compatibility label list of each operator.

[0028] H3 (Security Model Constraint): The protocol selected by all nodes must meet the user's preset security model requirements. security(x_{i,j}) returns the highest security level supported by this operator (semi-honest / malicious without TEE / malicious with TEE), requiring security(x_{i,j}) ≥ security_req.

[0029] H4 (Image Combination Constraint): The selected operator combination must exist in the hardware adaptation image repository as a set of composable atomic runtime images.

[0030] Objective function: Minimize the global execution cost C_total = Σ_{i=1}^{m} Σ_{j=1}^{n} t_{i,j}(x_{i,j}) + α · Σ_{i<p} d_{i,p}, where t_{i,j} is the expected execution time, d_{i,p} is the estimated communication delay between nodes, and α is the communication cost weight coefficient (default 0.1, adjustable range 0.05~0.5).

[0031] S2-4: CSP solving. A constraint satisfaction problem solver is used to solve the above CSP model, and the solving timeout is set to 30 seconds. The solver generates a unique execution plan for each node, where the execution plan is an ordered operator sequence, and each operator includes the operator name and version number, specific algorithm parameters, and the name and version number of the dependent library, and expected execution time.

[0032] If the solver does not find a feasible solution within the timeout, the constraint subset that leads to no solution is extracted, an error report containing specific failure causes is generated, and the deployment is terminated.

[0033] Step S3: Hardware-aware inter-node protocol negotiation.

[0034] Each node agent exchanges HCD digests and preliminary execution plan digests generated in S2 through an inter-node negotiation channel (based on gRPC / QUIC protocol). The negotiation process is as follows:

[0035] S3-1: Capability intersection calculation. The deployment decision center aggregates the HCD of all nodes, and calculates the intersection of TEE types, the intersection of CPU instruction sets and the intersection of accelerator types respectively.

[0036] S3-2: Global protocol parameter derivation. Based on the intersection result of S3-1, the globally compatible protocol parameter set (GPPS) is automatically derived:

[0037] Security model selection: If the TEE intersection is empty, a security model that does not rely on TEE is selected; if the TEE intersection is not empty, the highest security level supported within the intersection is selected.

[0038] Batch size determination: batch_size = min_{i=1}^{m} (mem_i / sample_mem), where mem_i is the available accelerator memory of node i (system memory if there is no accelerator), sample_mem is the average memory required for each training sample, and the result is rounded down to the nearest power of 2.

[0039] Encryption algorithm selection: Query the intersection of CPU instruction sets and select the fastest hardware-accelerated algorithm supported by all nodes.

[0040] Polynomial Modulus Selection: Based on the microbenchmark test results of all nodes in S1-3, select the modulus that optimizes the average performance of all nodes.

[0041] S3-3: Negotiation Confirmation and Conflict Handling. GPPS is distributed to all nodes, and each node verifies the compatibility of its S2-generated execution plan with GPPS. If all nodes confirm, the negotiation is successful. If any node refuses, at most two rounds of renegotiation are performed: the first round adjusts the conflict parameters; if conflicts persist after the second round, the negotiation fails, and a diagnostic report containing the refusing node and the specific reason is generated. The total negotiation timeout is 120 seconds.

[0042] Step S4: Automated deployment execution and global atomicity control.

[0043] S4-1: Image Matching and Pulling. Based on the execution plan of each node, the corresponding atomic runtime image is matched and pulled from the hardware adaptation image repository. Each image in the image repository is stored in content-addressed mode (the storage key is the SHA-256 hash value of the image content). The matching rule is: find a combination of one or more images that contains all operators in the execution plan and whose declaration files have no dependency conflicts; if multiple combinations exist, select the image with the fewest layers. Image pulling supports breakpoint resumption and parallel downloading.

[0044] S4-2: Configuration Injection and Service Startup. GPPS and node-specific configuration information are injected into the container's environment variables and configuration files, which are encrypted during transmission. The service is started using the container runtime. The startup command includes a mandatory init process, which executes sequentially: loading hardware drivers, initializing accelerators, and verifying the versions and integrity of critical libraries.

[0045] S4-3: Post-deployment self-check. Each container is forced to execute a self-check script upon startup, including: (a) hardware accelerator driver verification; (b) key operator functionality verification—executing test cases containing the main operator types in the execution plan to verify the consistency of calculation results with expected values; and (c) network connectivity verification—measuring whether the round-trip time (RTT) between nodes is within acceptable limits (default threshold 100ms). The self-check timeout is set to 30 seconds; failure of any self-check item results in an overall failure.

[0046] S4-4: Global Atomicity Control. The deployment decision center maintains a finite state machine with states including: Wait, Probe, Map, Negotiate, Deploy, Run, and Fail. Transitions between states are triggered by success or failure events at each stage. When a state transitions to failure, the decision center immediately triggers a global rollback: a "rollback" command is broadcast to all nodes, and each node agent sequentially executes container stopping, image deletion, configuration file cleanup, and network configuration restoration. The decision center waits for all nodes to return "rollback complete" confirmations (total timeout 60 seconds), the system is restored to the pre-deployment state, and a detailed report containing the cause and stage of the failure is generated.

[0047] Global atomicity control guarantees that either all nodes successfully enter the running state, or all nodes are rolled back to their pre-deployment state. The deployment decision center uses distributed locks to ensure that only one deployment task is executed at a time; all communication between the deployment decision center and node agents uses bidirectional transport layer security (mTLS) encryption, and the inter-node negotiation channel uses the QUIC protocol.

[0048] (III) Beneficial Effects

[0049] Compared with the prior art, the present invention has the following advantages:

[0050] 1. Significantly improved deployment efficiency. Through a fully automated hardware detection, mapping, negotiation, and deployment process, the deployment time of the privacy computing platform has been reduced from hours of manual intervention in traditional solutions to minutes of automation, and the deployment success rate has also been greatly improved.

[0051] 2. Significantly improved computational performance. By dynamically selecting the optimal hardware execution backend for each node, the mismatch between cryptographic primitives and hardware acceleration capabilities is eliminated. The hardware resources of each node are fully utilized, core cryptographic primitives are significantly accelerated, and end-to-end task throughput is significantly improved.

[0052] 3. Improved cross-platform portability. By combining hardware capability descriptors and atomic images, the migration time for privacy computing applications across different hardware architectures and accelerators is significantly reduced.

[0053] 4. Enhanced system security and robustness. By using hardware capabilities as a mandatory constraint, supplemented by atomic execution and self-checking mechanisms, security degradation events caused by hardware capability mismatch are effectively avoided. Global atomic rollback ensures the consistency of system state in the event of deployment failure. Attached Figure Description

[0054] Figure 1 This is a schematic diagram of the overall architecture of the heterogeneous hardware automated deployment system of the privacy computing platform of the present invention.

[0055] Figure 2This is a flowchart illustrating the heterogeneous hardware automated deployment method of the privacy computing platform of the present invention.

[0056] Figure 3 This is a schematic diagram of the data structure of the hardware capability descriptor in this invention;

[0057] Figure 4 This is a schematic diagram of the variables and constraint relationships in the constraint satisfaction problem of this invention. Detailed Implementation

[0058] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments, but the implementation of the present invention is not limited thereto.

[0059] Example 1

[0060] like Figure 1 As shown, this embodiment uses the deployment of a privacy computing platform for joint risk control modeling on three geographically dispersed nodes by a financial institution as an application scenario. The hardware configurations of the three nodes are as follows: Node A is an Intel Xeon CPU (supporting AES-NI, AVX-512) + NVIDIA A100 GPU (FP32 computing power 50 TFLOPS) + Intel SGX v2 TEE; Node B is an AMD EPYC CPU (supporting AES-NI) + AMD SEV-SNP v1 TEE (no independent GPU); Node C is an ARM architecture CPU (supporting AES-NI) + Xilinx FPGA accelerator card (2000 DSP Slices, no TEE).

[0061] Step 1: Hardware Capability Detection (Refer to...) Figure 3 )

[0062] Data scientists submit federated learning tasks and specify the IP addresses of three nodes through the web interface of the deployment decision center. The decision center broadcasts deployment start instructions to the node agents of the three nodes via the gRPC interface.

[0063] Each node agent forcibly starts the hardware probe with the highest priority. Taking node A as an example, the probe reads the CPU model as Intel Xeon Gold 6248 through / proc / cpuinfo, detects the AES-NI and AVX-512 instruction set flags; it detects the SGX device node through / dev / sgx / , reads the EPC size as 128MB; and it detects the NVIDIA A100 GPU with 40GB of video memory through lspci -v | grep NVIDIA. Subsequently, it calls the CUDA Runtime API's cudaGetDeviceProperties to obtain the FP32 computing power as 50 TFLOPS, the video memory bandwidth as 1555 GB / s, and the CUDA version as 11.8; it calls the Intel SGX SDK to obtain EDMM support as true and the firmware version as 2.1.100.4. Then, micro-benchmarks were performed: polynomial multiplication (modulus M = 2^64 - 2^32 + 1, N = 1024) was performed 100 times and the median was taken, resulting in a time of 15.2 microseconds; AES-GCM (128-bit key, 1KB data block) was measured at 0.8 microseconds / 1KB. All micro-benchmarks were completed within 8.2 seconds.

[0064] Finally, the probes integrated all the information to generate a JSON-formatted HCD, which was then signed using the node agent's ECDSA private key and reported to the decision-making center via an mTLS encrypted channel. All three node probes completed successfully, with total times of 8.2 seconds for node A, 6.5 seconds for node B, and 9.1 seconds for node C, all within the 60-second timeout threshold.

[0065] Step 2: Primitive-operator mapping based on constraint satisfaction problem (refer to...) Figure 2 and Figure 4 )

[0066] The intelligent mapping engine in the decision center queries the "task-primitive" dictionary to decompose the federated learning task into three atomic cryptographic primitives: gradient aggregation, parameter encryption, and model training. For each primitive, the engine generates candidate operators by querying the mapping library based on the HCD of each node. For parameter encryption, node A's candidates are AES-NI hardware acceleration and software implementation, node B's candidates are the same, and node C's candidates are only AES-NI hardware acceleration and software implementation. For model training, node A's candidates are GPU training operators and CPU training operators, node B's candidates are only CPU training operators, and node C's candidates are FPGA inference operators and CPU training operators.

[0067] The engine models the above candidate choices as a CSP problem. Key hard constraints include: (1) Hardware matching - GPU training operators can only be assigned to node A, and FPGA inference operators can only be assigned to node C; (2) Operator compatibility - SGX encryption and SEV encryption are incompatible, forcing all nodes to uniformly choose AES-NI hardware acceleration; (3) Security model - The user specifies a malicious security model (not dependent on TEE), and all candidate operators support it; (4) Image combination - The selected operator combination exists in the image repository and has no dependency conflicts.

[0068] The CSP solver completed the solution in 18.3 seconds, outputting the optimal assignment: batch size = 128, node A selected GPU training operator, node B selected CPU training operator, and node C selected FPGA inference operator. All nodes' encryption operators were AES-NI hardware accelerated. The engine generated execution plans for each node: node A: AES-NI encryption → GPU model training → CPU gradient aggregation; node B: AES-NI encryption → CPU model training → CPU gradient aggregation; node C: AES-NI encryption → FPGA model inference → CPU gradient aggregation.

[0069] Step 3: Hardware-aware inter-node protocol negotiation

[0070] Each node agent broadcasts its HCD summary and preliminary execution plan through the QUIC negotiation channel. The decision center then aggregates these and calculates the intersection: the TEE intersection is empty (A has SGX, B has SEV, C has no TEE); the CPU instruction set intersection is {AES-NI}; the accelerator intersection is empty.

[0071] Based on the above intersection, global parameters are derived: the security model is a semi-honest model that does not rely on TEEs because the TEE intersection is empty; the batch size is determined to be 128 based on the minimum memory of the three (16GB on-chip memory of the FPGA on node C) and the memory usage per sample (128MB); the encryption algorithm selected is AES-NI hardware acceleration, which is supported by all three. GPPS is distributed to each node for verification, and all nodes confirm success, thus completing the negotiation.

[0072] Step 4: Automated Deployment Execution and Global Atomicity Control

[0073] Each node executor pulls images from the content-addressable image repository according to the execution plan. Node A pulls base-os + gpu-train-ops:v1.2 + aes-ni-lib:v3.0 (total 2.8GB, parallel download time approximately 4 minutes); Node B pulls base-os + cpu-train-ops:v2.1 + aes-ni-lib:v3.0 (time 3 minutes 20 seconds); Node C pulls base-os + fpga-infer-ops:v1.0 + aes-ni-lib:v3.0 (time 4 minutes 30 seconds).

[0074] After the image is pulled, the executor injects GPPS and node configuration into the container, starts the service using the container runtime, and the init process loads the driver. After the container starts, it performs a self-test: Node A performs a polynomial multiplication test (15.5 microseconds, deviation from HCD <5%), and sends probe messages to B / C (RTTs of 13ms and 23ms < 100ms respectively); Node C verifies that the FPGA inference operator runs normally with batch_size=128. All three nodes complete their self-tests within 20 seconds.

[0075] The decision center state machine sequentially goes through the stages of waiting, probing, mapping, negotiating, deploying, and running. After receiving self-check reports from all nodes that have passed, it sends a "start execution" command. The total time from task submission to all nodes being ready is approximately 15 minutes.

[0076] Effect verification:

[0077] Running a joint risk control modeling task (batch size=128, 10,000 samples), the GPU utilization on node A was approximately 85%, and the FPGA utilization on node C was approximately 72%. The overall training throughput reached approximately 480 samples / second, a 4-fold improvement over the traditional unified CPU solution of approximately 120 samples / second. The polynomial multiplication primitive was optimized on node A using AVX-512, reducing the time to 0.15 microseconds (a 14x speedup), and on node C using FPGA, it was further reduced to 0.04 microseconds (a 52.5x speedup).

[0078] In cross-platform migration verification, migrating the application from an x86+GPU environment to an ARM+FPGA cluster took approximately 3 hours using the proposed solution, while the traditional solution required approximately 18 days. In security and robustness verification, simulating an image pull failure scenario, the system triggered a global rollback, restoring all nodes to their pre-deployment state within 12 seconds. When setting hardware mismatch scenarios, the system clearly reported the failure reason during the negotiation phase, without any silent security degradation.

[0079] Example 2

[0080] This embodiment provides an alternative implementation based on micro-benchmarking. Unlike Embodiment 1, this embodiment does not read the hardware ID to generate an HCD during the hardware probing phase. Instead, the node agent directly executes standardized micro-benchmarks related to the task to be deployed, measuring the actual execution time of each cryptographic primitive under different parameters and generating a performance cost vector, thus replacing the HCD containing the hardware model. In the intelligent mapping phase, the engine uses the performance cost vectors of all nodes as input and runs a minimum-maximum fairness algorithm to find the mapping scheme that minimizes the total global execution cost. This alternative is suitable for scenarios where hardware capabilities cannot be obtained through static IDs.

[0081] Example 3

[0082] This embodiment provides an alternative implementation based on decentralized consensus and dynamic compilation. This embodiment eliminates the deployment of a central decision-making body; all node agents communicate directly through an improved Raft consensus protocol, jointly determining the global mapping scheme and parameter set through multiple rounds of voting. During the deployment phase, nodes dynamically compile and generate customized shared libraries locally according to the negotiated unified execution plan. This alternative is suitable for scenarios where centralized architectures are unavailable or untrusted.

[0083] Example 4

[0084] This embodiment provides an alternative implementation based on serverless function orchestration. The hardware acceleration implementation of each cryptographic primitive is encapsulated as an independent serverless function. During deployment, the orchestrator dynamically schedules each operator in the task DAG to the node currently providing the optimal acceleration function. This alternative is suitable for cloud-native and elastic computing scenarios.

Claims

1. A method for automated deployment of heterogeneous hardware in a privacy computing platform, characterized in that, include: Hardware detection steps: During the node agent initialization phase of each target node, a hardware probe is forcibly started. The probe reads hardware information through system calls, obtains hardware performance parameters by calling a dedicated application programming interface, and performs cryptographic primitive micro-benchmark tests to generate a standardized hardware capability descriptor with digital signature. If the probe of any target node fails to run successfully or the generated hardware capability descriptor does not meet the preset minimum capability threshold, the deployment is terminated. The intelligent mapping process involves: decomposing the user-submitted task into atomic cryptographic primitives; generating candidate hardware operators based on the hardware capability descriptors of each node and a predefined mapping library; modeling operator selection as a constraint satisfaction problem and solving it; generating an execution plan for each node that includes the implementation of the specific hardware operator; and terminating the deployment if no feasible solution is found. Hardware-aware negotiation steps: Each node exchanges hardware capability information, calculates the intersection of the hardware capabilities of all nodes, automatically derives a globally compatible set of protocol parameters based on the intersection, and distributes it to each node for confirmation; if a non-empty compatible set of parameters cannot be calculated or the node confirmation fails, the deployment is terminated. Automated deployment execution steps: Pull the corresponding atomic runtime image from the image repository according to the execution plan of each node, inject global protocol parameters and node configuration, start the service, and force the deployment self-check; Global atomicity control steps: If all the above steps are completed successfully, the instruction to start execution is broadcast; otherwise, a global rollback is triggered to restore all nodes to their pre-deployment state.

2. The method according to claim 1, characterized in that, The system calls executed by the hardware probe include reading ` / proc / cpuinfo` to obtain the CPU instruction set flags, reading ` / dev / sgx / ` to detect trusted execution environment devices, and executing `lspci` to detect graphics processors and field-programmable gate array devices. The dedicated application programming interfaces include the Unified Computing Device Architecture Runtime API, `sgx_create_enclave` from the Intel SGX software development kit, the `xrt::device` class from the Xilinx runtime library, and the AMD ROCm system management interface API. The micro-benchmarks include polynomial multiplication, elliptic curve dot product, and AES-GCM encryption / decryption, with each test executed 100 times and the median used as the performance metric. The hardware capability descriptor is in JSON format and includes node identifier, CPU architecture and instruction set support, trusted execution environment type and version and activation status, accelerator model and computing power parameters, and micro-benchmark results. The digital signature uses the elliptic curve digital signature algorithm.

3. The method according to claim 1, characterized in that, The constraints satisfying the problem are the operators selected by each primitive on each node; hard constraints include: hardware matching constraints, requiring that the hardware capabilities required by the operators are included in the node's hardware capability descriptor; inter-operator compatibility constraints, requiring that two operators with data interaction satisfy predefined compatibility conditions; security model constraints, requiring that all operators selected by all nodes support a security level no lower than the user-preset security model; and mirror combination constraints, requiring that the selected operator combination can find an atomic mirror combination without dependency conflicts in the mirror repository; the objective function is to minimize the global execution cost, which is the sum of the execution times of all primitives on all nodes and the weighted sum of the communication delays between nodes.

4. The method according to claim 1, characterized in that, The derivation method of the global compatibility protocol parameter set is as follows: if the intersection of the trusted execution environment types of all nodes is empty, then a security model that does not depend on the trusted execution environment is selected; otherwise, the highest security level supported within the intersection is selected. The batch size is determined by dividing the minimum of all node accelerator or memory limits by the memory usage per sample, and the result is rounded down to a power of 2; the encryption algorithm is selected as the fastest hardware acceleration algorithm supported by the intersection of all node CPU instruction sets; the polynomial modulus is determined by the modulus that maximizes the median performance in all node micro-benchmark tests; in the hardware-aware negotiation step, if a node fails to confirm the global protocol parameter set, at most two rounds of renegotiation are performed, and if there are still conflicts after renegotiation, the deployment is terminated.

5. The method according to claim 1, characterized in that, The post-deployment self-test includes verifying whether the hardware accelerator driver is loaded, executing test cases containing the main operator types in the execution plan and verifying the consistency of the results, and verifying network connectivity through the inter-node negotiation channel. The self-test timeout is preset to 30 seconds, and a global rollback is triggered if any self-test item of any node fails.

6. The method according to claim 1, characterized in that, The atomic runtime images in the image repository are stored using the SHA-256 hash value of the image content as the storage key for content addressing. The image matching rule is to find a combination of one or more images that contains all operators in the execution plan and that the declaration files of all images have no dependency conflicts. When multiple combinations exist, the one with the fewest image layers is selected. Mirroring supports resume download and parallel download.

7. The method according to claim 1, characterized in that, The global atomicity control is executed by a finite state machine maintained by the deployment decision center. The states include waiting, probing, mapping, negotiating, deploying, running, and failing. State transitions are triggered by success or failure events at each stage. During a global rollback, the decision center broadcasts a rollback instruction to all nodes. Each node executes container stopping, image deletion, configuration file cleanup, and network configuration restoration in sequence. The decision center waits for confirmation from all nodes that the rollback is complete, with a total timeout of 60 seconds.

8. The method according to claim 1, characterized in that, The deployment decision center uses a distributed lock to ensure that only one deployment task is executed at a time; all communication between the deployment decision center and the node agent is encrypted with bidirectional transport layer security, and the negotiation channel between nodes uses the QUIC protocol.

9. A heterogeneous hardware automated deployment system for a privacy computing platform, characterized in that, include: The deployment decision center is used to receive user-submitted tasks, coordinate the deployment process of each node, execute intelligent mapping and global parameter derivation, and control global atomicity. Node agents, deployed on each target node, include a hardware probe module, a negotiation module, and a deployment execution module; The hardware adaptation image repository is used to store atomic runtime images organized by hardware type and operator type; The system performs the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 8.

Images