Adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method and device

Abstract

The application provides a self-adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method and device, which performs multi-level recursive decomposition on an SMPC joint computation task, constructs a feature vector for a subtask, and determines whether the subtask can be containerized; a dedicated container execution template is created for the containerizable subtask according to the feature vector, a main container is selected to execute the containerizable subtask, a first backup container is created, the same dedicated container execution template as the main container is called, and a chained hot backup mechanism is formed with the main container during the execution of the containerizable subtask by the main container; the non-containerizable subtask is prioritized and graded, and SMPC nodes are selected to execute according to the corresponding scheduling strategy; the encrypted results output after the execution of each subtask are subjected to integrity and security verification, and after the verification, the results of all subtasks are aggregated. The application improves the flexibility and scalability of SMPC scheduling, and optimizes the stability and practicality of SMPC joint computation as a whole.

Description

Technical Field

[0001] This invention belongs to the field of information technology, and in particular relates to an adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method and apparatus. Background Technology

[0002] Secure Multi-Party Computation (SMPC), as a core technology for privacy-preserving computation, enables multiple parties to complete joint computations without disclosing the original data. It is widely used in scenarios such as financial risk control and medical data sharing. Traditional SMPC node deployment schemes use physical machines or virtual machines. As the scale of computing tasks continues to expand, SMPC scheduling increasingly suffers from weaknesses such as cumbersome deployment, inconvenient expansion, and low resource utilization. Moreover, for subtasks decomposed from large-scale computing tasks, there are also problems such as computational redundancy and low execution efficiency.

[0003] The specific problems with the current SMPC scheduling are as follows: 1. Existing SMPC solutions lack the ability to identify and optimize repetitive subtasks after decomposing large-scale computing tasks, and fail to achieve dedicated and efficient execution of repetitive subtasks, resulting in computational redundancy and resource waste; 2. The containerized SMPC solution has a simple primary and backup container scheduling logic, but does not achieve chain linkage for hot standby. The reliability and efficiency of fault recovery are insufficient, and the primary and backup containers may be deployed on the same physical node, which poses a single point of failure risk. 3. It does not distinguish between containerizable and non-containerable subtasks, and adopts a unified scheduling and fault tolerance strategy for subtasks with different priorities and characteristics. This makes it difficult to adapt to diverse task requirements and to balance high reliability, high execution efficiency and low resource consumption. 4. The SMPC node load assessment uses a single metric and does not dynamically adjust it based on the node's historical failure frequency. Inappropriate node selection can easily lead to node overload or frequent failures, affecting the overall computing stability. 5. The lack of input data verification, result integrity verification, and dynamic self-learning mechanisms during subtask execution results in insufficient robustness and intelligence of the solution, making it difficult to adapt to large-scale, highly dynamic SMPC joint computing scenarios. Summary of the Invention

[0004] This invention proposes an adaptive fault-tolerant dynamic scheduling method and apparatus for multi-party secure computation (SMPC), which solves the current problems in SMPC scheduling, improves the flexibility and scalability of SMPC scheduling, and optimizes the overall stability and practicality of SMPC joint computation.

[0005] To achieve the above objectives, the technical solution of the present invention is implemented as follows: An adaptive fault-tolerant dynamic scheduling method for Multi-Party Secure Computation (SMPC) includes: S1. Perform multi-level recursive decomposition on the original large-scale SMPC joint computing task, construct feature vectors for the subtasks obtained from the decomposition, and determine whether they can be containerized. S2. Create a dedicated container execution template for each containerizable subtask based on its feature vector, select a main container from each SMPC node, and call the dedicated container execution template to execute the containerizable subtask. S3. After the main container starts execution, a first-level backup container is immediately created and the same dedicated container execution template as the main container is called. During the execution of the containerizable subtask by the main container, a chain-like hot standby mechanism is formed with the main container. S4. Prioritize non-containerable subtasks and select SMPC nodes for execution according to the corresponding scheduling policies for high, medium, and low priority non-containerable subtasks. S5. Perform integrity and security checks on the encrypted results output after each subtask is executed. After the checks pass, aggregate the results of all subtasks.

[0006] Furthermore, in steps S2 and S4, the SMPC node is selected based on the node comprehensive load assessment results. The node comprehensive load assessment results are obtained by combining the CPU and memory utilization of the SMPC node, and introducing the historical failure frequency weight of the node to perform a comprehensive load assessment of the SMPC node.

[0007] Furthermore, the SMPC node dynamically adjusts the historical failure frequency weight of the node based on historical execution logs; at the same time, it updates the node's comprehensive load assessment results in real time according to the set update cycle.

[0008] Furthermore, step S1 specifically includes: S101. Decompose the original large-scale SMPC joint computing task into atomic-level subtasks in a hierarchical recursive manner. S102. For each atomic-level subtask, construct a multi-dimensional feature vector, including the number of times the subtask recurs (Count(T)), the computational complexity (Complexity(T)) of the subtask, the historical average execution time (Time(T)) of the subtask, the input data dimension (InputDim(T)) of the subtask, and the dependency of the subtask on other subtasks (Dep(T)). S103. Set the repetition threshold. and computational complexity threshold ; conditions are met and and The subtasks are containerizable subtasks.

[0009] Furthermore, a subtask feature library is constructed to store the multi-dimensional feature vectors of each subtask. After a subtask is executed, the subtask feature library is automatically updated; at the same time, the repetition threshold is recalibrated. and computational complexity threshold .

[0010] Furthermore, step S2 specifically includes: S201. For all containerizable subtasks, create a dedicated container execution template based on their feature vectors. The dedicated container execution template pre-configures the subtask's computing environment, encryption algorithm library, input / output interfaces, and resource requirements. S202. Real-time collection of the operating status of all available SMPC nodes, combined with CPU and memory utilization, and the weight of historical node failure frequency, to obtain the comprehensive load assessment result of the nodes. S203. Select the node with the lowest comprehensive load assessment result as the main container deployment node, call the dedicated container execution template of the subtask, quickly start the computing environment of the main container, and configure the container's privacy protection policy at the same time. S204. Using a streaming batch transmission method, the input data is written to the main container in preset batches. After each batch of data is transmitted, the main container automatically performs integrity verification on the data. The preset batch size is dynamically adjusted according to the input data dimension InputDim(T) in the subtask feature vector.

[0011] Furthermore, step S3 specifically includes: S301. After the main container starts computing, a first-level standby container is immediately created. The first-level standby container calls the same dedicated container execution template as the main container, loads the same input data, and has the same configuration as the main container. S302. Monitor the execution status of the main container in real time; S303. Based on the execution state of the main container, execute different fault-tolerant logic to form a chain-like hot standby mechanism; S304. Based on the computational complexity (T) and historical average execution time (T) in the subtask feature vector, dynamically adjust the resource quota of the standby container to ensure that the subtask computation is completed quickly after the standby container switches over.

[0012] Furthermore, step S4 specifically includes: S401. For all non-containerable subtasks, a priority score is calculated by weighted summation based on three core dimensions: task importance, data sensitivity, and latency requirements, to achieve a classification of high priority, medium priority, and low priority. S402. High-priority subtasks adopt a fault-tolerant strategy of "dual-node parallel execution + fault redistribution". S403, medium-priority subtasks adopt a single-node optimal scheduling strategy; S404. Low-priority subtasks adopt a random scheduling strategy.

[0013] Furthermore, step S5 specifically includes: S501. The integrity of the encrypted result output after the subtask is executed is verified by using a hash verification algorithm; and the encryption status of the result is checked to achieve security verification. S502. The SMPC encryption aggregation algorithm is used to aggregate the encryption results of all subtasks and finally generate the global SMPC calculation result. S503. After the global calculation results are generated, global resource reclamation is performed.

[0014] In another aspect, this invention proposes an adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling device, comprising: Task decomposition module: Performs multi-level recursive decomposition of the original large-scale SMPC joint computing task, constructs feature vectors for the decomposed subtasks, and determines whether they are containerizable. Containerizable subtask execution module: Creates a dedicated container execution template for the containerizable subtask according to its feature vector, selects a main container from each SMPC node, and calls the dedicated container execution template to execute the containerizable subtask; Hot standby module: After the main container starts execution, a first-level standby container is immediately created, and the same dedicated container execution template as the main container is called. During the execution of the containerizable subtask in the main container, a chain-like hot standby mechanism is formed with the main container. Non-containerable subtask execution module: Prioritizes non-containerable subtasks and selects SMPC nodes for execution based on the corresponding scheduling strategies for high, medium, and low priority non-containerable subtasks. Verification and aggregation module: Performs integrity and security verification on the encrypted results output after each subtask is executed. After the verification is passed, the results of all subtasks are aggregated.

[0015] Compared with the prior art, the present invention has the following beneficial effects: This invention, while retaining the core framework of SMPC, effectively addresses pain points in existing SMPC solutions such as redundant execution of repetitive subtasks, insufficient container fault tolerance and reliability, lack of targeted task scheduling, unreasonable node selection, incomplete privacy and security protection, and poor cloud-native adaptability by refining processes and adding intelligent decision-making and dynamic optimization mechanisms. This invention improves execution efficiency and saves resources through subtask feature modeling and containerization optimization, enhances fault tolerance through primary-backup container chain hot standby, adapts to diverse needs by prioritizing non-containerable subtasks, improves node scheduling rationality by combining multi-dimensional load assessment and self-learning mechanisms, ensures computational security and accuracy through multiple privacy protections and verifications, and adapts to cloud-native scenarios through containerized deployment, thereby improving the flexibility and scalability of SMPC scheduling and optimizing the overall stability and practicality of SMPC collaborative computing. Attached Figure Description

[0016] Figure 1 This is a flowchart of Embodiment 1 of the present invention.

[0017] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the present invention. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0019] To make the purpose and features of this invention patent more apparent and understandable, the invention will be further described below in conjunction with the accompanying drawings and specific embodiments.

[0020] Example 1: The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method applied in Example 1 is as follows: Figure 1 As shown, it includes: Step 1: Multi-level recursive decomposition of tasks and feature modeling of subtasks.

[0021] Step 1.1: Multi-level recursive decomposition of the task; The original large-scale SMPC joint computing task is recursively decomposed into a hierarchy of "total task → first-level subtask → second-level subtask → atomic subtask". This ensures that each atomic subtask has a uniform granularity, can be executed independently, and that the data dependencies between subtasks are clear and traceable. This avoids the low execution efficiency caused by overly coarse subtask decomposition or the interactive redundancy caused by overly fine decomposition.

[0022] The basic requirements for recursive decomposition are: start from the SMPC main task and decompose layer by layer, with each layer of subtasks further decomposed until all subtasks become atomic tasks with uniform granularity that can be executed independently, and clarify data dependencies in a synchronized manner during the decomposition process.

[0023] For example, if the overall task is to jointly calculate the credit score of users in a region by multiple parties, it is first broken down into three primary sub-tasks: data preprocessing, feature calculation, and scoring model operation; then feature calculation is broken down into three secondary sub-tasks: income, debt, and performance feature calculation; finally, income feature calculation is broken down into atomic sub-tasks such as multi-party income data alignment, income mean calculation, and income stability verification, while also indicating that the mean calculation depends on the output of data alignment.

[0024] Step 1.2: Subtask feature vector construction; For each atomic subtask, a multi-dimensional feature vector is constructed to comprehensively characterize the core attributes of the subtask, providing data support for subsequent containerization determination and scheduling strategy selection. The feature vector is defined as follows: F(T)=(Count(T),Complexity(T),Time(T),InputDim(T),Dep(T)); F(T): Eigenvector; Count(T): The number of times the subtask is repeated; it is obtained by counting the number of times the subtask is repeated in the entire SMPC calculation process. Complexity(T): The computational complexity of the subtask (values ​​from 0 to 1, the larger the value, the greater the computational cost); it is obtained by normalizing the computational logic complexity of the subtask to 0 to 1. For example, if it is only a simple addition and subtraction calculation, take 0.1; if it is a complex encryption operation, take 0.9. Time(T): The historical average execution time of the subtask (unit: ms); it is obtained by retrieving the historical execution record of the subtask and calculating the average time of multiple runs, with the unit being milliseconds. InputDim(T): The dimension of the input data for the subtask; it is obtained by counting the number of dimensions of the input data for the subtask. For example, if the input feature vector is 100-dimensional, the value is 100. Dep(T): The dependency of a subtask on other subtasks (value from 0 to 1, the larger the value, the stronger the dependency on other subtasks); it is obtained by normalizing to 0 to 1 based on the number of other subtasks the subtask depends on, the amount of data transmission, etc. For example, if it depends on only 1 other subtask, the value is 0.2; if it depends on multiple other subtasks, the value is 0.8.

[0025] The system constructs a subtask feature library to store the multi-dimensional feature vectors of each subtask.

[0026] Step 1.3: Determining if a task is containerizable; Two core decision thresholds are set: (1) Repetition threshold It can be dynamically adjusted according to the task size. For example, the default value is... ; The core of dynamic adjustment revolves around bidirectional adaptation between the overall task scale and the system container resource status, flexibly changing based on default values: the larger the task scale, the more resources are wasted by containerizing low-repetition subtasks. The limit will be increased appropriately; when the system has sufficient idle container resources, it can be reduced moderately. To make full use of idle resources, and to increase efficiency when resources are scarce. Prioritize the containerization benefits of highly repetitive subtasks.

[0027] (2) Calculate the complexity threshold For example, by default ; It serves as a benchmark for balancing containerized execution efficiency and resource overhead, adapting to regular SMPC tasks. This threshold supports dynamic adjustment, primarily based on the system's computing resources and the overall computational complexity distribution of subtasks: it should be appropriately increased when computing power is sufficient. To improve efficiency, more medium-complexity subtasks are containerized; when computing power is limited / the proportion of high-complexity subtasks is high, reduce... Only containerize low-complexity subtasks to avoid containers carrying excessive computational loads, which could lead to lag and resource consumption.

[0028] A subtask is marked as containerizable if it meets all of the following conditions; otherwise, it is marked as non-containerable: and and ; The determination of Dep(T) is based on the fact that highly dependent subtasks (Dep(T)>0.3) need to be executed in conjunction with other subtasks, and containerization would increase the interaction overhead, so they are not included in the scope of containerization.

[0029] Step 2: Create dedicated container templates for containerizable subtasks and schedule the main container.

[0030] Step 2.1: Building a dedicated template for containerizable subtasks; For all subtasks marked as containerizable, a dedicated container execution template is created based on their feature vector F(T). The template pre-configures the subtask's computing environment, encryption algorithm library, input / output interfaces, and resource requirements (CPU, memory quota), so that one type of subtask corresponds to one dedicated template, avoiding the repeated creation of container environments for each execution and improving deployment efficiency.

[0031] Step 2.2: Node-wide load assessment; The system collects the operating status of all available physical nodes in real time, constructs a comprehensive node load assessment model, and combines CPU and memory utilization rates with the weight of historical node failure frequency to achieve accurate node load assessment. The assessment formula is as follows: ; : The total load of the i-th node; : Current CPU usage of the i-th node; : Current memory usage of the i-th node; : Historical failure frequency of the i-th node (unit: times / hour); k: Fault frequency weighting coefficient. For example, the default k=0.2. The higher the fault frequency, the higher the node's overall load score, and the less likely it is to be selected. k has a default baseline value of 0.2. The core is obtained and adjusted through node historical fault log statistics and dynamic adaptation to system operating status: First, extract the number of faults per unit time for each node from the system to form basic fault frequency data; then, dynamically adjust k according to the overall node fault distribution and system computing power pressure. Increase k for nodes with high fault incidence and appropriately decrease k for nodes with low fault incidence, thereby accurately controlling the impact weight of fault frequency on node load assessment.

[0032] Step 2.3: Selection and Deployment of the Main Container Node; Based on the overall load assessment results, the node with the lowest overall load is selected as the main container deployment node to ensure the high efficiency of the main container execution. The node selection formula is as follows: ;in Indicates the main container deployment node; When the main container is deployed, the dedicated container execution template for this subtask is invoked to quickly start the container environment. At the same time, the container's privacy protection policy is configured: disk encryption within the container, encrypted transmission of input and output data, and automatic clearing of sensitive memory data after execution, ensuring the privacy and security of SMPC computing.

[0033] Step 2.4: Subtask input data streaming transmission and verification; After the subtask starts, it uses a streaming batch transmission method to write the input data into the main container in preset batches (the batch size is dynamically adjusted according to InputDim(T)), rather than loading it all at once, to avoid container lag caused by excessive input data volume. After each batch of data is transmitted, the main container automatically performs integrity verification (checksum comparison). If the verification of a batch of data fails, a retransmission mechanism is immediately triggered to ensure the accuracy of the input data. The verification formula is as follows: ; when At that time, the data was complete; Hash(⋅): A lightweight hash verification algorithm; : Single batch input data; : Preset verification code.

[0034] Once all batch data transfers are complete and verification is successful, the main container officially starts the SMPC computing task.

[0035] Step 3: Container primary-standby chain hot standby mechanism.

[0036] Step 3.1: Creation and deployment of the primary backup container; After the main container officially starts computing, the system immediately creates a first-level standby container. The first-level standby container calls the same dedicated container execution template as the main container to perform the following preprocessing operations (without starting computing, maintaining a hot standby state): (1) Load input data that is completely identical to the main container. The purpose is to synchronize the streaming input progress of the main container and ensure data consistency. (2) Configure the same resource quotas, encryption environment, and privacy protection policies as the main container; (3) The environment initialization before calculation is completed and the system is ready to start calculation at any time.

[0037] The selection of nodes for the primary standby container follows the principle of physical node isolation. The node with the lowest overall load, excluding the node containing the primary container, is selected to prevent simultaneous failure of the primary and standby containers due to the same node. The node selection formula is as follows: ;in This represents a first-level standby container node, where j represents the j-th node.

[0038] Step 3.2: Real-time monitoring of the main container's execution status; The system collects status data every 50ms using a container health monitoring probe to monitor the execution status of the main container in real time. The monitoring indicators include: computation progress, CPU / memory utilization, encryption algorithm execution status, and network connectivity. The monitoring results are fed back to the scheduling center in real time to form the main container status log.

[0039] Step 3.3: Primary / standby container switching and chained hot standby linkage; Based on the execution state of the main container, different fault-tolerant logic is executed to form a chain-like hot standby mechanism, ensuring that the task always has real-time fault tolerance capabilities: (1) If the main container completes execution normally and the output results pass the integrity check, the scheduling center immediately sends an instruction to destroy the first-level backup container, release node resources, and complete the containerized execution of the subtask; (2) If the main container fails, such as computation timeout, process crash, network interruption, etc., the scheduling center will immediately trigger the switching mechanism to upgrade the first-level backup container to the new main container and start the computation task. (3) After the new primary container starts, the scheduling center immediately selects the node with the lowest overall load after excluding the node where the new primary container is located, creates a secondary standby container, repeats the preprocessing operation of subdivided step 3.1, and maintains the hot standby status. (4) By analogy, a chain of hot standby is formed, which is “main container → first-level standby → second-level standby → … → N-level standby”. The hot standby chain length is always kept at 1, which ensures high reliability while minimizing resource waste.

[0040] Step 3.4: Dynamic adjustment of backup container resources; Based on the computational complexity (T) and execution time (T) of the subtask, the resource quota of the standby container is dynamically adjusted. For example, it can be dynamically adjusted as follows: When Complexity(T)≥0.4 or Time(T)≥500ms, appropriately increase the CPU / memory quota of the standby container to ensure that the calculation can be completed quickly after the standby container is switched over; When Complexity(T) < 0.4 and Time(T) < 500ms, reduce the resource quota of the standby container to save resources.

[0041] Step 4: Priority-adaptive scheduling and fault tolerance for non-containerable subtasks.

[0042] Step 4.1: Prioritize non-containerable subtasks; For all subtasks marked as non-containerable, a priority score is calculated using a weighted summation method, combining three core dimensions: task importance, data sensitivity, and latency requirements, to achieve precise priority classification. The scoring formula is as follows: ; Importance: Task importance, ranging from 0 to 1. The higher the value, the more important the task. Combined with the coreness of the subtask in the overall SMPC computation, core subtasks (such as final result aggregation, core feature calculation, etc.) take a high value of 0.7 to 1, auxiliary subtasks (such as redundancy verification, log recording, etc.) take a low value of 0 to 0.4, and intermediate subtasks take a middle value of 0.4 to 0.7. Sensitivity: Data sensitivity, ranging from 0 to 1. The higher the value, the higher the data privacy requirement. It is determined based on the privacy level of the data processed by the sub-task. For processing core privacy data (such as core user information), a high value of 0.7 to 1 is used; for processing de-identified / non-privacy data, a low value of 0 to 0.4 is used; and for processing semi-de-identified data, a middle value of 0.4 to 0.7 is used. DelayRequire: Delay requirement, ranging from 0 to 1. The larger the value, the stricter the requirement for execution delay. It is determined according to the rigid requirements of the subtask for execution timeliness. Subtasks that need to be completed in real time / near real time (such as key connection nodes in the process) take a high value of 0.7 to 1, subtasks without strict timeliness requirements take a low value of 0 to 0.4, and subtasks with normal timeliness requirements take a middle value of 0.4 to 0.7. The weighting coefficients satisfy w1+w2+w3=1. For example, the default values ​​are w1=0.4, w2=0.3, and w3=0.3, which can be dynamically adjusted according to the business scenario.

[0043] Based on the priority score P(T), non-containerable subtasks are divided into three levels: High priority: P(T) ≥ 0.8; Medium priority: 0.5 ≤ P(T) < 0.8; Low priority: P(T) < 0.5.

[0044] Step 4.2: Fault-tolerant scheduling of high-priority non-containerable subtasks; High-priority subtasks (such as core computing and privacy-sensitive data processing) employ a fault-tolerant strategy of dual-node parallel execution plus fault reassignment to ensure high task reliability. Specifically: (1) Based on the overall load assessment results of the nodes, the scheduling center selects two nodes with low overall load and independent physical nodes to deploy the subtask simultaneously. The node selection formula is as follows: ; ; in Indicates the first node of a high-priority subtask; This indicates the second node of a high-priority subtask.

[0045] (2) The two nodes start the subtask execution at the same time, synchronize the execution progress in real time, and the scheduling center monitors the status of the two nodes in real time; (3) If any node completes execution normally and the output results pass the integrity check, the scheduling center immediately sends an instruction to terminate the execution of the other node and release the node's resources; (4) If any node fails, the scheduling center will immediately select two new independent nodes to redeploy the subtask for parallel execution, repeat the above process until the task is successfully completed, ensuring that high-priority tasks are not interrupted.

[0046] Step 4.3: Scheduling of medium-priority non-containerable subtasks; Medium-priority subtasks employ a single-node optimal scheduling strategy, balancing execution efficiency and resource overhead. (1) Based on the overall load assessment results of the nodes, the scheduling center selects the node with the lowest overall load to deploy the subtask. The node selection formula is as follows: ;in This indicates a medium-priority subtask node.

[0047] (2) During the execution of the subtask, the scheduling center monitors the node status in real time. If a node fails, the node with the lowest overall load is immediately selected and the subtask is redeployed without the need to configure a backup node, thus balancing efficiency and resources.

[0048] Step 4.4: Scheduling of low-priority, non-containerable subtasks; Low-priority subtasks employ a random scheduling strategy to maximize overall scheduling efficiency and reduce scheduling overhead. (1) The scheduling center randomly selects one node from all available nodes to deploy the subtask, without the need for load optimization; (2) If a node fails, the scheduling center will randomly select an available node to redeploy without additional fault tolerance configuration, prioritizing the overall task progress speed.

[0049] Step 5: Dynamic adjustment and self-learning optimization of node load.

[0050] Step 5.1: Real-time update of node load and adjustment of weight; The system updates the overall load Load(i) of all nodes every 100ms. At the same time, it dynamically adjusts the fault frequency weight coefficient k based on the historical execution logs of the nodes: for nodes with a high historical fault frequency (e.g., FaultRate(i) ≥ 0.5 times / hour), k is adjusted to 0.3~0.4 to further reduce the probability of the node being selected; for nodes with a low historical fault frequency (e.g., FaultRate(i) < 0.1 times / hour), k is adjusted to 0.1~0.2 to increase the scheduling priority of the node, thereby achieving self-optimization of node selection.

[0051] Step 5.2: Dynamically update the subtask feature library; After all subtasks are completed, the system automatically updates the subtask feature library. The updates include: the actual execution time of the subtask, the number of recurrences, the computational complexity, and the failure status. At the same time as updating the subtask feature library, the containerization judgment threshold is recalibrated. and Priority scoring weight coefficients provide more accurate data support for the decomposition, scheduling, and fault tolerance of the next round of tasks, forming a closed-loop self-learning mechanism.

[0052] Step 6: Subtask result verification, trusted aggregation, and global resource reclamation.

[0053] Step 6.1: Verification of the integrity and security of subtask results; After each subtask (containerable / non-containerable) is completed, the encrypted calculation result is output, and the scheduling center performs double verification on the result: (1) Integrity verification: The result check code is compared with the preset check code by a hash check algorithm to ensure that the result has not been tampered with; (2) Security verification: Check the encryption status of the results to ensure that the results exist in ciphertext form and that no privacy has been leaked.

[0054] If the verification fails, the subtask will be re-executed immediately according to the corresponding scheduling policy.

[0055] Step 6.2: SMPC Trusted Aggregation; After all subtask results have been verified, the SMPC encryption aggregation algorithm is used to aggregate the encrypted results of all subtasks. During the aggregation process, the original results and intermediate data of any subtask are not disclosed, ensuring the data privacy and security of multiple participants, and finally generating the global SMPC calculation result.

[0056] Step 6.3: Global resource reclamation; After the global calculation results are generated, the scheduling center sends an instruction to uniformly reclaim the main and backup containers of all containerizable subtasks, and release the CPU and memory resources occupied by the containers. At the same time, it releases the computing resources of all subtask deployment nodes, updates the node load status, clears the task execution log (retaining the data required for feature library updates), and completes the entire SMPC calculation process.

[0057] This embodiment improves execution efficiency and saves resources through subtask feature modeling and containerization optimization, strengthens fault tolerance by adopting primary and backup container chain hot standby, adapts non-containerable subtasks to diverse needs by scheduling them according to priority, improves the rationality of node scheduling by combining multi-dimensional load assessment and self-learning mechanism, ensures computing security and accuracy through multiple privacy protections and verifications, adapts to cloud-native scenarios by relying on containerized deployment, improves deployment flexibility and scalability, and optimizes the stability and practicality of SMPC joint computing as a whole.

[0058] Example 2: This embodiment proposes an adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling device, such as... Figure 2 As shown, it includes: Task decomposition module: Performs multi-level recursive decomposition of the original large-scale SMPC joint computing task, constructs feature vectors for the decomposed subtasks, and determines whether they are containerizable. Containerizable subtask execution module: Creates a dedicated container execution template for the containerizable subtask according to its feature vector, selects a main container from each SMPC node, and calls the dedicated container execution template to execute the containerizable subtask; Hot standby module: After the main container starts execution, a first-level standby container is immediately created, and the same dedicated container execution template as the main container is called. During the execution of the containerizable subtask in the main container, a chain-like hot standby mechanism is formed with the main container. Non-containerable subtask execution module: Prioritizes non-containerable subtasks and selects SMPC nodes for execution based on the corresponding scheduling strategies for high, medium, and low priority non-containerable subtasks. Verification and aggregation module: Performs integrity and security verification on the encrypted results output after each subtask is executed. After the verification is passed, the results of all subtasks are aggregated.

[0059] In both the containerizable and non-containerable subtask execution modules, SMPC nodes are selected based on the comprehensive node load assessment results. These results combine the CPU and memory utilization of the SMPC node with historical failure frequency weights to comprehensively evaluate its load. The SMPC node dynamically adjusts its historical failure frequency weights based on historical execution logs and updates the comprehensive node load assessment results in real time according to a set update cycle.

[0060] The task decomposition module includes: The original large-scale SMPC joint computing task is recursively decomposed into atomic-level subtasks in a hierarchical manner. For each atomic-level subtask, construct a multi-dimensional feature vector, including the number of times the subtask recurs (Count(T)), the computational complexity (Complexity(T)), the historical average execution time (Time(T)), the input data dimension (InputDim(T)), and the dependency of the subtask on other subtasks (Dep(T)). Set a threshold for the number of repetitions and computational complexity threshold ; conditions are met and and The subtasks are containerizable subtasks.

[0061] A subtask feature library is constructed to store the multi-dimensional feature vectors of each subtask. After a subtask is executed, the subtask feature library is automatically updated; at the same time, the repetition threshold is recalibrated. and computational complexity threshold .

[0062] Containerable subtask execution modules include: For all containerizable subtasks, a dedicated container execution template is created based on their feature vectors. The dedicated container execution template pre-configures the subtask's computing environment, encryption algorithm library, input / output interfaces, and resource requirements. The running status of all available SMPC nodes is collected in real time, and combined with CPU and memory utilization, as well as the historical failure frequency weight of the nodes, to obtain the comprehensive load assessment result of the nodes. Select the node with the lowest overall load assessment result as the main container deployment node, call the dedicated container execution template of the subtask, quickly start the main container's computing environment, and configure the container's privacy protection policy at the same time. The input data is written to the main container in preset batches using a streaming batch transmission method. After each batch of data is transmitted, the main container automatically performs integrity verification on the data. The preset batch size is dynamically adjusted according to the input data dimension InputDim(T) in the subtask feature vector.

[0063] The hot standby module includes: After the main container starts computing, a first-level standby container is immediately created. The first-level standby container calls the same dedicated container execution template as the main container, loads the same input data, and has the same configuration as the main container. Monitor the execution status of the main container in real time; Based on the execution state of the main container, different fault-tolerant logic is executed to form a chain-like hot standby mechanism; Based on the computational complexity (T) and historical average execution time (T) in the subtask feature vector, the resource quota of the standby container is dynamically adjusted to ensure that the subtask computation is completed quickly after the standby container switches over.

[0064] The non-containerable subtask execution module includes: For all non-containerable subtasks, a priority score is calculated using a weighted summation method, taking into account three core dimensions: task importance, data sensitivity, and latency requirements, to achieve a classification of high priority, medium priority, and low priority. High-priority subtasks employ a fault-tolerant strategy of "dual-node parallel execution + fault reassignment"; Medium-priority subtasks employ a single-node optimal scheduling strategy; Low-priority subtasks are scheduled using a random scheduling strategy.

[0065] The verification aggregation module includes: The integrity of the encrypted results output after the subtask is executed is verified by using a hash verification algorithm; and the encryption status of the results is checked to achieve security verification. The SMPC encryption aggregation algorithm is used to aggregate the encryption results of all subtasks and finally generate the global SMPC calculation result. After the global calculation results are generated, global resource reclamation is performed.

[0066] The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling device proposed in this embodiment can realize the adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method described in Embodiment 1, and has the same technical effect as Embodiment 1.

[0067] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method, characterized in that, include: S1. Perform multi-level recursive decomposition on the original large-scale SMPC joint computing task, construct feature vectors for the subtasks obtained from the decomposition, and determine whether they can be containerized. S2. Create a dedicated container execution template for each containerizable subtask based on its feature vector, select a main container from each SMPC node, and call the dedicated container execution template to execute the containerizable subtask. S3. After the main container starts execution, a first-level backup container is immediately created and the same dedicated container execution template as the main container is called. During the execution of the containerizable subtask by the main container, a chain-like hot standby mechanism is formed with the main container. S4. Prioritize non-containerable subtasks and select SMPC nodes for execution according to the corresponding scheduling policies for high, medium, and low priority non-containerable subtasks. S5. Perform integrity and security checks on the encrypted results output after each subtask is executed. After the checks pass, aggregate the results of all subtasks.

2. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 1, characterized in that, In steps S2 and S4, SMPC nodes are selected based on the node comprehensive load assessment results. The node comprehensive load assessment results are obtained by combining the CPU and memory utilization of SMPC nodes and introducing the weight of the node's historical failure frequency to conduct a comprehensive load assessment of SMPC nodes.

3. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 2, characterized in that, The SMPC node dynamically adjusts the historical failure frequency weight based on historical execution logs; at the same time, it updates the node's comprehensive load assessment results in real time according to the set update cycle.

4. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 1, characterized in that, Step S1 specifically includes: S101. Decompose the original large-scale SMPC joint computing task into atomic-level subtasks in a hierarchical recursive manner. S102. For each atomic-level subtask, construct a multi-dimensional feature vector, including the number of times the subtask recurs (Count(T)), the computational complexity (Complexity(T)) of the subtask, the historical average execution time (Time(T)) of the subtask, the input data dimension (InputDim(T)) of the subtask, and the dependency of the subtask on other subtasks (Dep(T)). S103, Set the repetition threshold and computational complexity threshold ; conditions are met and and The subtasks are containerizable subtasks.

5. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 4, characterized in that, A subtask feature library is constructed to store the multi-dimensional feature vectors of each subtask. After a subtask is executed, the subtask feature library is automatically updated; at the same time, the repetition threshold is recalibrated. and computational complexity threshold .

6. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 1, characterized in that, Step S2 specifically includes: S201. For all containerizable subtasks, create a dedicated container execution template based on their feature vectors. The dedicated container execution template pre-configures the subtask's computing environment, encryption algorithm library, input / output interfaces, and resource requirements. S202. Real-time collection of the operating status of all available SMPC nodes, combined with CPU and memory utilization, and the weight of historical node failure frequency, to obtain the comprehensive load assessment result of the nodes. S203. Select the node with the lowest comprehensive load assessment result as the main container deployment node, call the dedicated container execution template of the subtask, quickly start the computing environment of the main container, and configure the container's privacy protection policy at the same time. S204. Using a streaming batch transmission method, the input data is written to the main container in preset batches. After each batch of data is transmitted, the main container automatically performs integrity verification on the data. The preset batch size is dynamically adjusted according to the input data dimension InputDim(T) in the subtask feature vector.

7. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 1, characterized in that, Step S3 specifically includes: S301. After the main container starts computing, a first-level standby container is immediately created. The first-level standby container calls the same dedicated container execution template as the main container, loads the same input data, and has the same configuration as the main container. S302. Monitor the execution status of the main container in real time; S303. Based on the execution state of the main container, execute different fault-tolerant logic to form a chain-like hot standby mechanism; S304. Based on the computational complexity (T) and historical average execution time (T) in the subtask feature vector, dynamically adjust the resource quota of the standby container to ensure that the subtask computation is completed quickly after the standby container switches over.

8. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 1, characterized in that, Step S4 specifically includes: S401. For all non-containerable subtasks, a priority score is calculated by weighted summation based on three core dimensions: task importance, data sensitivity, and latency requirements, to achieve a classification of high priority, medium priority, and low priority. S402. High-priority subtasks adopt a fault-tolerant strategy of "dual-node parallel execution + fault reassignment". S403, medium-priority subtasks adopt a single-node optimal scheduling strategy; S404. Low-priority subtasks adopt a random scheduling strategy.

9. The adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling method according to claim 1, characterized in that, Step S5 specifically includes: S501. The integrity of the encrypted result output after the subtask is executed is verified by using a hash verification algorithm; and the encryption status of the result is checked to achieve security verification. S502. The SMPC encryption aggregation algorithm is used to aggregate the encryption results of all subtasks and finally generate the global SMPC calculation result. S503. After the global calculation results are generated, global resource reclamation is performed.

10. An adaptive fault-tolerant multi-party secure computation (SMPC) dynamic scheduling device, characterized in that, include: Task decomposition module: Performs multi-level recursive decomposition of the original large-scale SMPC joint computing task, constructs feature vectors for the decomposed subtasks, and determines whether they are containerizable. Containerizable subtask execution module: Creates a dedicated container execution template for the containerizable subtask according to its feature vector, selects a main container from each SMPC node, and calls the dedicated container execution template to execute the containerizable subtask; Hot standby module: After the main container starts execution, a first-level standby container is immediately created, and the same dedicated container execution template as the main container is called. During the execution of the containerizable subtask in the main container, a chain-like hot standby mechanism is formed with the main container. Non-containerable subtask execution module: Prioritizes non-containerable subtasks and selects SMPC nodes for execution based on the corresponding scheduling strategies for high, medium, and low priority non-containerable subtasks. Verification and aggregation module: Performs integrity and security verification on the encrypted results output after each subtask is executed. After the verification is passed, the results of all subtasks are aggregated.

Images