A multi-party secure computation session failure recovery method, device and medium

Abstract

This invention discloses a method, device, and medium for recovering from failures in multi-party secure computation sessions. Belonging to the field of medical privacy computing and trusted distributed computing for large-scale medical models, it addresses the technical problems of existing multi-party secure computation systems requiring repeated computations under failure states, difficulty in data recovery in secure computing scenarios, and difficulty in joint judgment of failure detection. The method includes: performing encrypted sharding on the minimum recovery state set; performing a reverse search on the failure event records related to the most recent checkpoint; performing a trusted verification of the consistency between the recoverable state reconstructed at the recovery checkpoint and the recovery state commitment generated by the protocol context; dynamically reallocating the share of the session tasks in slow nodes into divisible subtasks; and based on the substitute verification result and the merged recovery aggregation verification result, recovering the current session task from its failure state and executing the next round of multi-party secure computation.

Description

Technical Field

[0001] This application relates to the fields of medical privacy computing and trusted distributed computing for large medical models, and in particular to a method, device and medium for recovering from failures in a multi-party secure computing session. Background Technology

[0002] In collaborative applications of healthcare data, multiple hospitals, regional healthcare platforms, medical insurance units, and research institutions typically need to complete tasks such as joint statistics, joint risk prediction, rational drug use analysis, evaluation of follow-up prescription rules, disease cohort screening, and medical research modeling without leaving their domains or exposing raw data. These tasks often rely on multi-party secure computation or federated learning platforms, where multiple participating nodes jointly execute computation protocols. Because healthcare institutions have varying network environments, in-hospital computer room resources, edge node computing power, and task execution times, any participating node experiencing a crash, network outage, restart, computation lag, or timeout can cause the entire secure computation session to fail.

[0003] Multi-party secure computation technology allows multiple participants to collaboratively complete computational tasks without revealing their individual original data. Typical solutions include secure computation based on secret sharing, secure computation based on obfuscated circuits, secure computation based on homomorphic encryption, and secure aggregation mechanisms in federated learning. These technologies have been widely used in highly sensitive data areas such as healthcare, financial risk control, and government data collaboration.

[0004] However, existing multi-party secure computing systems still have significant shortcomings in terms of task failure recovery.

[0005] On the one hand, existing secure computing sessions typically feature strong synchronization, multi-round interactions, and state dependencies. A single joint modeling or statistical task can last from tens of minutes to several hours, even involving hundreds of rounds of communication. If a participant experiences a node termination, network disconnection, process exit, or machine restart during an intermediate round, other participants, despite having completed a significant amount of intermediate computation, usually have to terminate the task and re-execute it from the initial stage because they cannot confirm whether the states of all parties were consistent before the failure. This approach results in a large amount of redundant computation, redundant communication, and queuing, which can severely impact the availability of privacy-preserving computing platforms, especially when there are many participating nodes, large data volumes, and limited computing resources.

[0006] On the other hand, simply introducing state snapshots cannot directly solve the recovery problem in secure computation scenarios. Ordinary distributed systems can save plaintext state snapshots, but intermediate states in multi-party secure computation often include sensitive information such as secret shares, random masks, multiplication triple consumption progress, gradient masks, key negotiation materials, and protocol round context. Directly saving or centrally managing these states could lead to the leakage of privacy data or protocol security parameters, undermining the security assumptions of multi-party secure computation.

[0007] On the other hand, existing task scheduling systems typically only monitor the online status of nodes, lacking a joint assessment of the progress of secure computation protocols, commitment consistency, share recoverability, and the ability of substitute nodes to take over. Even if a fault is detected, it is difficult to determine which secure state to roll back to, which intermediate states are reliable, which shares can be taken over by substitute nodes, and whether the recovered computation results are consistent with the state before the fault.

[0008] Furthermore, in multi-party secure computation tasks, the slowest node often determines the overall task progress. Existing solutions typically can only wait for the slow node to complete its current round, or treat the slow node as a faulty node and restart the entire task. They lack a mechanism to dynamically reallocate the divisible computation shares without leaking privacy states or changing the protocol's security boundaries.

[0009] Therefore, there is an urgent need for a fault recovery method for multi-party secure computing sessions that can periodically record trusted recovery points without exposing the original data and intermediate plaintext states; continue execution from the most recent valid recovery point after a node failure; securely reconstruct the necessary intermediate computing share of the failed participants when a substitute node joins; and dynamically allocate shardable computing tasks when slow nodes affect the overall progress, thereby improving the continuity, reliability, and resource utilization efficiency of the privacy computing platform. Summary of the Invention

[0010] This application provides a method, device, and medium for recovering from failures in a multi-party secure computing session, which addresses the following technical problems: existing multi-party secure computing systems require repeated computations under fault conditions, have difficulty in recovering data in secure computing scenarios, and have difficulty in jointly judging fault detection.

[0011] The embodiments of this application adopt the following technical solutions: On one hand, embodiments of this application provide a method for recovering from failures in a multi-party secure computation session, including: normalizing the local intermediate state and generating state commitments for the current protocol state of each participant based on abnormal checkpoints in the multi-party secure computation task; performing encrypted fragmentation on the minimum recovery state set extracted from the local intermediate state, and generating a global checkpoint record that meets a preset threshold based on the fragment verifiable commitment of the encrypted fragment and the state commitment; determining a recovery checkpoint for recovering the coordination node by performing a reverse search on the failure event record of the failed node related to the nearest checkpoint through the checkpoint chain associated with the global checkpoint record; and using the substitute selected by the system. The node performs a trusted verification of the consistency between the recoverable state reconstructed by the faulty participants at the recovery checkpoint and the recovery state commitment generated by the protocol context, obtaining a substitute verification result. Based on the commitment consistency result in the substitute verification result, it performs multi-party security computation on the next round of session tasks after the recovery checkpoint. The session tasks in the slow node are dynamically reallocated as shares of divisible subtasks, and the verified reallocation computation results are globally merged through the healthy node to generate a merged recovery aggregate verification result. Based on the substitute verification result and the merged recovery aggregate verification result, the current session task is restored to its fault state and the next round of multi-party security computation is executed.

[0012] This application's embodiments utilize a most recently valid commitment checkpoint recovery mechanism to enable tasks to continue computation from a trusted intermediate state, avoiding extensive repetitive computations in long-term joint modeling and statistical tasks. Furthermore, by using a recoverable state and sharing encrypted shards with threshold secrets, no single node can obtain the complete intermediate state, effectively protecting data and secure computation protocol parameters. By checking aggregate signatures, round consistency, shard validity, chain hash continuity, and state commitment verification results, malicious nodes are prevented from forging checkpoints, injecting erroneous states, or inducing the system to roll back to an inconsistent state. Simultaneously, when multiple institutions participate in a task, the anomaly of any node no longer necessarily leads to task failure, significantly improving the stability of collaborative data computation and joint scientific research modeling. Moreover, this application not only handles abnormal node termination but also addresses the issue of slow nodes slowing down the overall process. Furthermore, through a slow node scoring and splittable task redistribution mechanism, overall task throughput efficiency can be improved while ensuring privacy and security.

[0013] In one feasible implementation, based on anomaly checkpoints in a multi-party secure computation task, the current protocol state of each participant is normalized using local intermediate states and state commitments are generated. Specifically, this includes: receiving requests for the multi-party secure computation task through a privacy-preserving computation platform and generating session identifiers and participant registration completion information; generating checkpoint strategies based on task type, data size, estimated rounds, number of participants, and business importance; wherein the checkpoint strategies include: generation by round, generation by time, generation by stage, and generation triggered by anomalies; and completing the generation of the session identifier, registration completion information, and checkpoint strategies. Subsequently, anomaly checks are performed on each node in the multi-party secure computation task based on relevant warning thresholds to identify the anomaly checkpoints. The current protocol state corresponding to the anomaly checkpoints is normalized to obtain the local intermediate state. The local intermediate state includes: protocol round number, message sending and receiving confirmation table, unconfirmed message digest, secret share index, random number consumption counter, batch computation progress, local cache digest, and recoverable state range. A hash digest is performed on the local intermediate state, and the session identifier, round number, role number, and random salt are added to generate the state commitment. The state commitment is used for consistency proof processing.

[0014] In one feasible implementation, the minimum recoverable state set extracted from the local intermediate state is divided into encrypted fragments. Based on the fragment verifiable commitment of the encrypted fragments and the state commitment, a global checkpoint record satisfying a preset threshold is generated. Specifically, this includes: extracting the minimum recoverable state set required to extract recoverable states from the local intermediate state; wherein the minimum recoverable state set includes at least: secret share, protocol counter, random mask remaining index, local task progress, and necessary message cache digest; the minimum recoverable state set is divided into multiple encrypted fragments using a threshold secret sharing algorithm, and the encrypted fragments are sent to the recovery... In the coordination node; each encrypted fragment is appended with a fragment sequence number, session identifier, round number, and receiver identifier; based on the secret sharing polynomial, fragment value, or fragment digest of the encrypted fragment, a fragment verifiable commitment is generated; wherein, the fragment verifiable commitment is used to verify the validity of the encrypted fragment between the participants and the receiver; through each participant, the fragment verifiable commitment, state commitment round number, stage identifier, and signature are submitted to the recovery coordination node; based on the consistency and validity verification results of the recovery coordination node, a global checkpoint record that meets a preset threshold is generated, and the aggregate signature, threshold signature, or multi-signature confirmation of each participant is recorded.

[0015] In one feasible implementation, before determining the recovery checkpoint for the recovery coordination node by performing a reverse lookup of the most recent checkpoint on the failure event record of the failure node through the checkpoint chain associated with the global checkpoint record, the method further includes: judging the health status of the session node: if there is a failure to submit valid information or its status commitment is inconsistent with the protocol progress confirmed by other participants, the corresponding node is marked as the failure node; if the node can still respond but its progress is consistently lower than the global median progress or the average progress exceeds a preset threshold, the corresponding node is marked as the slow node; based on the failure node, control the recovery coordination node to send a session freeze command to other participants and suspend entering the next non-rollback protocol phase; generate the failure event record based on the currently received message digest and the most recently recognized checkpoint number submitted by each participant, and based on the failure events confirmed by the preset threshold.

[0016] In one feasible implementation, by performing a reverse lookup of the most recent checkpoint on the fault event record of the faulty node through the checkpoint chain associated with the global checkpoint record, a recovery checkpoint for the recovery coordination node is determined. Specifically, this includes: hashing the global checkpoint record with the previous checkpoint using the recovery coordination node to generate a checkpoint chain hash; saving the checkpoint chain hash to the audit log; encrypting the local intermediate state using a session key, and sealing the encrypted local intermediate state and its corresponding state commitment in the audit log; and then using the recovery coordination node... The node performs a reverse lookup and judgment on the checkpoint chain corresponding to the checkpoint chain hash using multiple types of conditions to obtain the condition judgment result of the most recent checkpoint. The multiple types of conditions include: whether the checkpoint aggregate signature is valid; whether the participant set is consistent with the current session; whether the state commitment set is complete or meets the protocol threshold; whether the sharding commitment verification passes; whether the previous checkpoint chain hash is continuous; whether rollback is allowed in the protocol phase; and whether all healthy participants have confirmed that they have not entered the irreversible commit phase after the checkpoint. If the condition judgment result is a condition-satisfied result, the checkpoint that satisfies the multiple types of conditions is determined as the recovery checkpoint.

[0017] In one feasible implementation, before performing a reliable verification of the consistency between the recoverable state reconstructed by the faulty participant at the recovery checkpoint and the recovery state commitment generated by the protocol context, the method further includes: loading a corresponding new local intermediate state and recalculating the corresponding new state commitment based on the checkpoint number of the recovery checkpoint; performing a consistency comparison between the new local intermediate state and the new state commitment and the attribute items in the global checkpoint record; if the comparison is consistent, controlling the healthy participant to enter a waiting recovery state; if the comparison is inconsistent, triggering local state anomaly handling and selecting the previous valid checkpoint according to the audit log.

[0018] In one feasible implementation, the system uses a selected substitute node to perform a reliable verification of the consistency between the recoverable state reconstructed by the faulty participant at the recovery checkpoint and the recovery state commitment generated by the protocol context, obtaining a substitute verification result. Specifically, this includes: if the faulty participant cannot re-enter online within the recovery window, a substitute node is selected and determined; wherein the substitute node is a backup node of the faulty participant's organization or an authorized managed execution node; and the substitute node does not obtain the faulty participant's original business data, only recovering the intermediate computation share necessary to complete the protocol continuation; through the substitute node, the recovery coordination node storing the encrypted fragments is... The process involves controlling the fragment recovery request to obtain the corresponding encrypted fragment; removing invalid fragments from the corresponding encrypted fragment and performing secret reconstruction to obtain the recoverable state of the faulty participant at the recovery checkpoint; using the substitute node, verifying the consistency between the recoverable state and the recovery state commitment generated by the protocol context and the original state commitment or recovery commitment of the faulty participant in the global checkpoint record; if the substitute verification result is consistent with the commitment, the substitute node is determined to be a trustworthy recovery state; if the substitute verification result is inconsistent with the commitment, the substitute node is determined to be in a refused-connection state and a manual audit process is initiated.

[0019] In one feasible implementation, the session tasks in slow nodes are dynamically reallocated as sub-tasks, and the verified reallocation calculation results are globally merged through healthy nodes to generate a merged recovery aggregation verification result. Specifically, this includes: calculating resource metrics for the detected slow nodes to obtain a slow node score; when the slow node score exceeds a first preset threshold and the current session task has sub-tasks, the incomplete local batch, matrix block, gradient sharding calculation, or intermediate share conversion tasks in the slow node are re-encoded into several sub-shares and reallocated to healthy nodes for execution, obtaining the reallocation calculation result; After the healthy node undertaking the redistribution task completes the calculation, it verifies the subtask state commitment, the original session task state commitment, and the merging rules through the recovery coordination node to obtain the verification result. If the verification result is a pass, the redistribution calculation result is merged into the global protocol state, and the newly submitted state commitment and its corresponding signature are aggregated and verified through the post-recovery checkpoint to obtain the merged recovery aggregate verification result. If the merged recovery aggregate verification result is a pass, multi-party security computation is performed on the next round of session tasks after the post-recovery checkpoint. If the merged recovery aggregate verification result is a fail, the process rolls back to the pre-recovery checkpoint and enters the anomaly audit process.

[0020] Secondly, embodiments of this application also provide a multi-party secure computing session failure recovery device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to execute a multi-party secure computing session failure recovery method as described in any of the above embodiments.

[0021] Thirdly, embodiments of this application also provide a non-volatile computer storage medium, wherein the storage medium is a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium stores at least one program, each program including instructions, and the instructions, when executed by a terminal, cause the terminal to execute a multi-party secure computing session failure recovery method described in any of the above embodiments.

[0022] This application provides a method, device, and medium for recovering from failures in a multi-party secure computing session. Compared with the prior art, the embodiments of this application have the following beneficial technical effects: 1. Significantly reduces the recalculation cost of secure computation tasks. Existing multi-party secure computation tasks often need to be executed from scratch when any participant terminates abnormally midway. This application uses a recent valid commitment checkpoint recovery mechanism to enable the task to continue computation from a trusted intermediate state, avoiding a large amount of repetitive computation in long-term joint modeling and joint statistical tasks.

[0023] 2. Avoid plaintext leakage of intermediate states. Traditional snapshot schemes may save plaintext intermediate states. This application only saves state commitments, signatures, sharding commitments, and audit indexes in the checkpoint ledger. Recoverable states are saved in encrypted shards through threshold secret sharing. No single node can obtain the complete intermediate state, effectively protecting data and secure computation protocol parameters.

[0024] 3. Improve the verifiability of fault recovery. During recovery, in addition to checking the time recentness, the aggregate signature, round consistency, shard validity, chain hash continuity, and state commitment verification results are also checked to prevent malicious nodes from forging checkpoints, injecting erroneous states, or inducing the system to roll back to an inconsistent state.

[0025] 4. Supports secure takeover by backup nodes. The failing organization can take over the protocol role through a backup node. The backup node only restores the necessary intermediate computing share and does not access the original business data of the failing organization, thus balancing task continuity and the organization's data security boundaries.

[0026] 5. Enhance the availability of multi-institutional privacy computing platforms. When multiple institutions participate in a task, an anomaly at any node no longer necessarily leads to task failure, significantly improving the stability of collaborative data computing, joint scientific research modeling, and other related tasks.

[0027] 6. Balancing fault recovery and performance optimization. This application not only handles abnormal node termination but also addresses the issue of slow nodes slowing down the overall process. Furthermore, through slow node scoring and a scalable task redistribution mechanism, it can improve overall task throughput efficiency while ensuring privacy and security.

[0028] 7. Form a complete audit evidence chain. The checkpoint chain, failure events, fragment recovery, replacement and continuation, reallocation and post-recovery confirmation of this application can all be recorded in the audit log, providing technical basis for compliance checks, responsibility determination and fault tracing of data collaborative computing.

[0029] 8. Excellent protocol adaptability. This application does not limit the specific underlying secure computing protocol and can be adapted to secret-sharing multi-party secure computing, homomorphic encrypted collaborative computing, federated learning secure aggregation, and hybrid privacy computing platforms, demonstrating strong engineering feasibility. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart of a multi-party secure computing session failure recovery method provided in this application embodiment; Figure 2 A flowchart for fault recovery of a multi-party secure computation session based on commitment checkpoints is provided in this application embodiment; Figure 3 A fault recovery flowchart based on a substitute node is provided for an embodiment of this application; Figure 4 This is a schematic diagram of a multi-party secure computing session fault recovery device provided in an embodiment of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0032] This application discloses a method for recovering from failures in multi-party secure computation sessions based on commitment checkpoints, belonging to the field of medical privacy computation and trusted distributed computing technology for large-scale medical models. Specifically, it relates to a method for recovering from failures in multi-party secure computation sessions for joint inference of large-scale medical models and collaborative computation of medical privacy data. Addressing the technical shortcomings of existing multi-party secure computation tasks in the medical field, such as the need to retry large-scale medical model training and joint analysis of medical data when participating nodes (hospitals, medical institutions, etc.) experience abnormal termination, hardware failure, network jitter, or insufficient computing power, and the potential for leakage of patient privacy data and plaintext intermediate computation states in routine snapshots, this application periodically generates commitment checkpoints that do not leak patient privacy or plaintext intermediate medical data during the operation of the medical secure computation session. Furthermore, it encrypts and fragments the intermediate computation shares of medical data and the intermediate inference shares of each medical institution through a verifiable secret sharing mechanism, and distributes them in other compliant medical participants or trusted medical recovery components.

[0033] The technical solutions of this application include: initialization of medical computing sessions and registration of medical institution participants, generation of checkpoint strategies adapted to medical large-scale model computing scenarios, commitment calculation of intermediate states of medical data and model inference, commitment aggregation and multi-party trusted signature, verifiable secret sharing sharding of medical privacy shares, writing of trusted ledgers of checkpoints, real-time health monitoring of nodes, accurate fault determination, screening of the most recently valid medical computing commitment checkpoints, restoration of intermediate privacy states of faulty medical institution nodes, succession computing of substitute medical nodes, and dynamic redistribution of medical computing shares of slow computing power nodes. Each medical participant submits only intermediate state commitment values, signature values, shard verification values, and model computation progress proofs throughout the entire process, without exposing patients' original privacy data, plaintext medical statistical results, or intermediate data for large-scale model inference. When a medical institution node fails and becomes unavailable, the system retrieves the most recent medical-specific commitment checkpoint that meets the threshold signature and consistency verification, restores the medical security computation session state, and after a compliant substitute medical node collects sufficient verifiable data shards, it reconstructs the medical data and model intermediate computation share of the failed node. From this checkpoint, it continues to complete subsequent secure computation processes such as joint training of the large-scale medical model and collaborative analysis of medical data. When it detects that a node's computing power is lagging behind and continuously falls below the preset progress threshold for medical computation, the system, without breaching the security boundary of secret sharing of medical data or leaking privacy information, recodes the divisible medical large-scale model computation subtasks and medical data statistical subtasks, and dynamically allocates them to other healthy compliant nodes for execution, preventing insufficient computing power at a single point from slowing down the overall medical collaborative computation task.

[0034] This application also integrates a collaborative security mechanism that includes committed checkpoints, verifiable secret sharing, backup node continuation of computation, slow node task redistribution, and consistency verification after recovery. It precisely adapts to the security requirements of collaborative computation of large medical models and cross-institutional medical data privacy computation. On the basis of strictly ensuring the privacy and security of patient medical data and the verifiability of model computation process, it realizes breakpoint continuation, anomaly fault tolerance, and adaptive scheduling of computing power in secure multi-party medical computation sessions. This significantly reduces the repetitive computation costs of cross-hospital joint medical computation and federated training of large medical models, and effectively improves the continuity of medical privacy computation tasks, data credibility, and system availability.

[0035] It should be noted that this application defines the following data structure: 1. Session ID (SID): Used to uniquely identify a multi-party secure computation session.

[0036] 2. Round number r: Used to identify the current interaction round of the secure computing protocol.

[0037] 3. The set of participants P = {P1, P2, ..., Pn} represents the set of institutions or nodes participating in the computation.

[0038] 4. Local intermediate state S_i^r: Represents the local protocol state of participant Pi after completing the r-th round, including secret share, random mask consumption position, local gradient share, message cache digest, protocol context and other necessary recovery information. The necessary recovery information is the minimum set of states extracted from the current protocol state.

[0039] 5. State commitment C_i^r: Calculated by participant Pi based on S_i^r. Preferably, a hash commitment method with random salt is used, for example: C_i^r=Hash(SID‖r‖role_i‖H(S_i^r)‖nonce_i), where Hash is a predefined collision-resistant hash function, H is a hash function that is the same as or different from Hash, ‖ represents a string concatenation operation, and nonce_i is a local random number or an unpredictable random quantity generated by the protocol.

[0040] 6. The set of shards Share_i^r = {share_i1^r, share_i2^r, ..., share_im^r} is generated by participant Pi through threshold secret sharing on the recoverable state R_i^r. It satisfies that any t valid shards can be reconstructed, and less than t shards cannot obtain valid information.

[0041] 7. Fragmentation commitment VC_i^r: Used to verify whether fragments belong to the same secret and have not been tampered with. Feldman or Pedersen is preferred for verifying secret sharing commitments, but homomorphic commitments or zero-knowledge proofs can also be used.

[0042] 8. Global checkpoint record GCP^r, including: SID, round number r, list of participants, set of state commitments, set of shard commitments, hash of the previous checkpoint, protocol phase identifier, aggregate signature and timestamp.

[0043] 9. Checkpoint Chain Hash HCP^r: Generated by Hash(GCP^r‖HCP^{rk}), used to ensure that the checkpoint sequence is immutable.

[0044] This application provides a method for fault recovery in multi-party secure computing sessions, focusing on the continuous execution and trusted recovery of secure computing sessions. Without disclosing the privacy data of participating parties or intermediate plaintext states, it provides recoverable, verifiable, and auditable breakpoint resuming capabilities for long-cycle, multi-round, multi-participant privacy computing tasks. Figure 1 As shown, the multi-party secure computation session failure recovery method specifically includes steps S101-S106: S101. Based on the anomaly checkpoints in the multi-party secure computation task, perform local intermediate state normalization processing and state commitment generation processing on the current protocol state of each participant.

[0045] Specifically, it is necessary to first receive requests for multi-party secure computing tasks through a privacy computing platform, and then generate session identifiers and registration completion information for the participating parties.

[0046] In one embodiment, Figure 2 A flowchart for fault recovery of a multi-party secure computation session based on commitment checkpoints is provided for embodiments of this application, such as... Figure 2 As shown, the privacy computing platform receives secure computing task requests from multiple parties, generates a session identifier (SID), and registers the identities of the participants, their institution certificates, node public keys, protocol types, computing task descriptions, participating roles, threshold parameters t, checkpoint interval parameters k, heartbeat timeout thresholds a, round-based no-response thresholds b, and slow node judgment thresholds. After each participant completes identity authentication and key negotiation, the platform enters the secure computing preparation phase.

[0047] Furthermore, checkpoint strategies must be generated based on task type, data scale, estimated number of rounds, number of participants, and business importance. These checkpoint strategies include: generation by round, generation by time, generation by stage, and generation triggered by exceptions.

[0048] Furthermore, after completing the session identification, registration completion information, and checkpoint policy, anomaly judgments are performed on each node in the multi-party secure computation task based on relevant warning thresholds to identify abnormal checkpoints.

[0049] In one embodiment, such as Figure 2 As shown, the system can generate checkpoint strategies based on task type, data scale, estimated number of rounds, number of participants, and business importance. Checkpoint strategies include four methods: generation by round, generation by time, generation by stage, and generation triggered by anomalies. For long-cycle joint modeling tasks, a commitment checkpoint can be generated every k rounds; for critical protocol stages, such as key negotiation completion, triplet consumption batch completion, model parameter aggregation completion, and local statistical result commitment completion, stage-specific checkpoints can be forcibly generated; when node health monitoring indicators reach a preset warning threshold, anomaly checkpoint generation is immediately triggered.

[0050] Furthermore, the current protocol state corresponding to the anomaly checkpoint is normalized to obtain the local intermediate state. The local intermediate state includes: protocol round number, message acknowledgment table, unacknowledged message digest, secret share index, random number consumption counter, batch calculation progress, local cache digest, and recoverable state range.

[0051] In one embodiment, such as Figure 2As shown, when the checkpoint trigger condition is met, i.e., after an abnormal checkpoint is triggered, each participant organizes the current protocol state into a local intermediate state S_i^r. The normalized content includes: protocol round number, message acknowledgment table, unacknowledged message digest, secret share index, random number consumption counter, batch calculation progress, local cache digest, and recoverable state range. During normalization, temporary variables that do not need to be recovered are removed to avoid excessive storage of sensitive materials.

[0052] Furthermore, a hash digest is performed on the local intermediate state, and the session identifier, round number, role number, and random salt are added to generate a state commitment. This state commitment is used for consistency proof processing.

[0053] In one embodiment, such as Figure 2 As shown, each participant performs a hash digest on its local intermediate state S_i^r and adds the session identifier, round number, role number, and random salt to generate a state commitment C_i^r. This state commitment is only used for consistency proof and does not contain reversible plaintext information; other participants cannot deduce the local intermediate state from the commitment value.

[0054] S102. The set of minimum recovery states extracted from the local intermediate state is divided into encrypted fragments, and a global checkpoint record that meets the preset threshold is generated based on the fragment verifiable commitment and state commitment of the encrypted fragments.

[0055] Specifically, the minimum set of recoverable states required to recover a state is first extracted from the local intermediate state. This minimum set of recoverable states includes at least: a secret share, a protocol counter, a random mask remaining index, local task progress, and a necessary message cache digest.

[0056] Furthermore, a threshold secret sharing algorithm is needed to divide the minimum recovery state set into multiple encrypted fragments, and these encrypted fragments are sent to the recovery coordination node. Each encrypted fragment is appended with a fragment sequence number, session identifier, round number, and receiver identifier.

[0057] In one embodiment, such as Figure 2 As shown, each participant extracts the minimum recovery state set R_i^r required for recovery from S_i^r, such as secret share, protocol counter, random mask remaining index, local task progress, and necessary message cache digest. The participants use a threshold secret sharing algorithm to divide R_i^r into multiple encrypted fragments and distribute these fragments to other participants or the recovery coordination node. Before distribution, each encrypted fragment is appended with a fragment sequence number, session identifier, round number, and receiver identifier. The receiver's public key is obtained through authentication and certificate verification during the session initialization phase, and the encrypted fragments are encrypted using the receiver's public key.

[0058] Furthermore, based on the secret sharing polynomial, fragment value, or fragment digest of the encrypted fragment, a fragment verifiable commitment is generated. This fragment verifiable commitment is used to verify the validity of the encrypted fragment between the participants and the receiver.

[0059] In one embodiment, such as Figure 2 As shown, participants generate a shard-verifiable commitment VC_i^r for the secret-shared polynomial, shard value, or shard digest, enabling the receiver to verify the shard validity without knowing the original secret. If the receiver finds a shard verification failure, it submits an anomalous proof to the recovery coordination node; if more than a preset number of shards fail, the checkpoint is not marked as a valid checkpoint.

[0060] Furthermore, each participant submits the sharded verifiable commitment, state commitment round number, phase identifier, and signature to the recovery coordination node. Then, based on the consistency and validity verification results of the recovery coordination node, a global checkpoint record that meets the preset threshold is generated, and the aggregate signature, threshold signature, or multi-signature confirmation of each participant is recorded.

[0061] In one embodiment, such as Figure 2 As shown, each participant submits its state commitment, fragment commitment, round number, phase identifier, and signature to the recovery coordination node. The recovery coordination node verifies the participant signatures, round consistency, participant set consistency, and the validity of the fragment commitments. When a preset threshold or a condition for unanimous confirmation is met, a global checkpoint record GCP^r is generated, and each participant performs aggregate signature, threshold signature, or multi-signature confirmation.

[0062] S103. By using the checkpoint chain associated with the global checkpoint record, perform a reverse lookup process on the fault event record of the faulty node for the most recent checkpoint to determine the recovery checkpoint used to recover the coordination node.

[0063] Specifically, the health status of the session nodes is first assessed: if any node fails to submit valid information or its status commitment is inconsistent with the protocol progress confirmed by other participants, the corresponding node is marked as a faulty node. If a node can still respond but its progress remains below the global median progress or its average progress exceeds a preset threshold, the corresponding node is marked as a slow node.

[0064] In one embodiment, such as Figure 2As shown, the health monitoring module continuously collects the heartbeat, round response, message confirmation, computation progress, resource utilization, and error logs of each participant. When a node fails to respond for *a* consecutive heartbeat cycles, or fails to submit a valid message for *b* consecutive protocol rounds, or its status commitment is inconsistent with the protocol progress confirmed by other participants, the system marks it as a faulty node. If a node can still respond but its progress remains below the global median progress or its average progress exceeds a preset threshold, it is marked as a slow node.

[0065] Furthermore, based on the faulty node, the control recovery coordination node needs to send a session freeze command to other participants and suspend the entry into the next non-rollback protocol phase. Then, based on the currently received message digests and the most recently approved checkpoint numbers submitted by each participant, and the fault events confirmed based on preset thresholds, a fault event record is generated.

[0066] In one embodiment, such as Figure 2 As shown, when a node is marked as a faulty node, the recovery coordinating node sends a session freeze command to the other participants, pausing the transition to the next non-rollback protocol phase. Each participant submits a digest of the messages it has received and the most recently approved checkpoint number. The recovery coordinating node confirms the fault event based on majority confirmation or a preset threshold and generates a fault event record.

[0067] Furthermore, by restoring the coordinating node, the global checkpoint record must be hashed with the previous checkpoint to generate a checkpoint chain hash. This checkpoint chain hash is then saved to the audit log.

[0068] In one embodiment, such as Figure 2 As shown, the recovery coordinating node associates GCP^r with the hash of the previous checkpoint to generate a checkpoint chain hash HCP^r, which is then saved to the checkpoint ledger or audit log. Each participant encrypts its local `S_i^r` using its session key and stores it in its local trusted storage, recording the correspondence between this state and the commitment value. The checkpoint ledger only saves commitments, signatures, verification values, and indexes; it does not save plaintext states.

[0069] Furthermore, the local intermediate state is encrypted using the session key, and the encrypted local intermediate state and its corresponding state commitments are sealed in the audit log. Then, through the recovery coordinating node, a reverse lookup of multiple conditions is performed on the checkpoint chain corresponding to the checkpoint chain hash to obtain the condition judgment result of the most recent checkpoint. These multiple conditions include: whether the checkpoint aggregate signature is valid; whether the participant set is consistent with the current session; whether the state commitment set is complete or meets the protocol threshold; whether the sharding commitment verification passes; whether the hash of the previous checkpoint chain is continuous; whether rollback is allowed in the protocol phase; and whether all healthy participants have confirmed that they have not entered the irreversible commit phase after the checkpoint. If the condition judgment result indicates that the conditions are met, the checkpoint that satisfies the multiple conditions is determined as the recovery checkpoint.

[0070] In one embodiment, such as Figure 2 As shown, the recovery coordinating node searches in reverse order in the checkpoint chain corresponding to the checkpoint chain hash for the nearest checkpoint that meets the following conditions, obtaining the condition judgment result of the nearest checkpoint. These conditions include: the checkpoint aggregate signature is valid; the participant set is consistent with the current session; the state commitment set is complete or meets the protocol threshold; the shard commitment verification is successful; the previous checkpoint chain hash is continuous; the protocol phase allows rollback; and all healthy participants confirm that no irreversible commit phase has been entered since this checkpoint. Finally, when the condition judgment result indicates that the conditions are met, the checkpoint that satisfies the above conditions is determined as the recovery checkpoint.

[0071] S104. Through the backup node selected by the system, a reliable verification of the consistency between the recoverable state reconstructed by the faulty participant at the recovery checkpoint and the recovery state commitment generated by the protocol context is performed to obtain the backup verification result.

[0072] Specifically, based on the checkpoint number of the recovery checkpoint, the corresponding new local intermediate state is loaded and the corresponding new state commitment is recalculated. Then, both the new local intermediate state and the new state commitment are compared for consistency with the attribute items in the global checkpoint record. If the comparison is consistent, the healthy participant is put into a waiting-for-recovery state. If the comparison is inconsistent, local state anomaly handling is triggered, and the previous valid checkpoint is selected based on the audit log.

[0073] In one embodiment, Figure 3 A fault recovery flowchart based on a substitute node is provided for an embodiment of this application, such as... Figure 3As shown, the health participant can load the corresponding local intermediate state from the local trusted storage according to the recovery checkpoint number, recalculate the state commitment, and compare it with C_i^r in the global checkpoint record; when the comparison is consistent, the health participant enters the waiting recovery state; when the comparison is inconsistent, the local state anomaly handling is triggered, and the previous valid checkpoint is selected according to the audit log.

[0074] Furthermore, if the failed participant cannot come back online within the recovery window, a substitute node is selected and determined. The substitute node is either a backup node of the failed participant's organization or an authorized managed execution node; and the substitute node does not obtain the failed participant's original business data, but only restores the intermediate computing share necessary to complete the protocol continuation.

[0075] In one embodiment, such as Figure 3 As shown, if a party involved in the failure cannot come back online within the recovery window, the system selects a substitute node. The substitute node can be a backup node of the failing party's organization or an authorized managed execution node. After completing identity authentication, permission confirmation, key binding, and role authorization, the substitute node gains the qualification to take over the protocol role of the failing party. The substitute node does not obtain the original business data of the failing party; it only restores the intermediate computing share necessary to complete the protocol reconnection.

[0076] Furthermore, a substitute node is needed to control the recovery request of the recovery coordination node that stores the encrypted fragments, thereby obtaining the corresponding encrypted fragments. Invalid fragments are removed from the corresponding encrypted fragments, and secret reconstruction is performed to obtain the recoverable state of the faulty participants at the recovery checkpoint.

[0077] In one embodiment, such as Figure 3 as well as Figure 2 As shown, the substitute node initiates a fragment recovery request to the participating party that stores the encrypted fragment or the recovery coordinating node. Then, each storing party verifies the recovery event, substitute node permissions, checkpoint number, and takeover role, and returns the corresponding encrypted fragment. The substitute node decrypts and verifies the received encrypted fragment, discarding invalid fragments. When the number of valid fragments reaches a threshold t, secret reconstruction is performed to obtain the recoverable state R_f^r of the failed party at the recovery checkpoint.

[0078] Furthermore, such as Figure 2 As shown, it is also necessary to use a substitute node to verify the consistency of the recoverable state and the recovery state commitment generated by the protocol context with the original state commitment or recovery commitment of the faulty participant in the global checkpoint record. If the substitute verification result is consistent with the commitment, the substitute node is determined to be trustworthy in the recovery state. If the substitute verification result is inconsistent with the commitment, the substitute node is determined to be in a refused-connection state and a manual audit process is initiated.

[0079] In one embodiment, such as Figure 3 as well as Figure 2 As shown, the substitute node generates a recovery state commitment C_f'^r based on the recoverable state R_f^r obtained from the reconstruction and the necessary protocol context, and compares it with the original state commitment or recovery commitment of the faulty party in the checkpoint record. If the commitments match, it indicates that the recovery state of the substitute node is trustworthy; if they do not match, it refuses to continue and attempts to use the previous valid checkpoint or initiates a manual audit process.

[0080] Furthermore, based on the commitment consistency results in the substitute verification results, multi-party security computation is performed on the next round of session tasks after the checkpoint is restored.

[0081] In one embodiment, such as Figure 3 As shown, healthy participants and substitute nodes reload the protocol context starting from the recovery checkpoint and continue multi-party secure computation in the next round after the checkpoint. For messages that have been committed but not confirmed by the checkpoint, they are resent or invalidated according to the protocol rules to avoid duplicate computation and state forks.

[0082] S105. Dynamically reallocate the share of the session tasks in the slow node to the share of the subtasks, and then globally merge the verified reallocation calculation results through the healthy node to generate the merged recovery aggregate verification result.

[0083] Specifically, firstly, the detected slow nodes are scored using relevant resource metrics to obtain a slow node score. Then, when the slow node score exceeds a first preset threshold and the current session task has divisible subtasks, the incomplete local batch, matrix block, gradient sharding calculation, or intermediate share conversion tasks in the slow node are re-encoded into several sub-shares and reassigned to healthy nodes for execution, resulting in a redistribution calculation result.

[0084] In one embodiment, such as Figure 2As shown, for participants that are not completely faulty but consistently fall below a preset progress threshold, the system calculates a slow node score, Score_i. This score can be calculated by weighted summation or weighted maximum summation of indicators such as round response time, progress difference, message retransmission count, CPU or memory resource usage, and historical anomaly count. When Score_i exceeds the threshold and the current task has divisible subtasks, the system re-encodes the node's incomplete local batch, matrix block, gradient sharding calculation, or intermediate share conversion task into several sub-shares and allocates them to healthy nodes for execution. During the reassignment process, healthy nodes process subtasks using homomorphic encryption or secret sharing of sub-shares, completing the specified calculations and returning encrypted intermediate results without decrypting the original secret, ensuring that the original secret is not exposed in plaintext. After reassignment to healthy nodes for execution, the reassignment calculation results are output.

[0085] Furthermore, after the healthy node undertaking the redistribution task completes its calculations, the recovery coordination node continues to verify the subtask state commitments, the original session task state commitments, and the merging rules to obtain the verification results. If the verification result is successful, the redistribution calculation results are merged into the global protocol state, and the newly submitted state commitments and their corresponding signatures are aggregated and verified through the post-recovery checkpoint to obtain the merged recovery aggregated verification result.

[0086] In one embodiment, such as Figure 2 As shown, after the healthy node undertaking the redistribution task completes the calculation, it submits the corresponding result commitment, calculation proof, or consistency check value. Then, the recovery coordination node or protocol participant verifies the correctness of the result according to the original task commitment, sub-task commitment, and merging rules. After successful verification, the system merges the redistribution calculation result into the global protocol state and records the redistribution event in the next checkpoint.

[0087] Furthermore, if the merged recovery aggregation verification result is successful, multi-party security computation is performed on the next round of session tasks after the post-recovery checkpoint. If the merged recovery aggregation verification result is unsuccessful, the process rolls back to the pre-recovery checkpoint and enters the anomaly audit process.

[0088] In one embodiment, such as Figure 2 As shown, after the session resumes and continues for several rounds, the system needs to generate a post-recovery checkpoint. Each participant submits a new state commitment and signature. If the post-recovery checkpoint passes the aggregation verification, the fault recovery process ends; if a state fork or inconsistent commitment occurs, the system rolls back to the pre-recovery checkpoint and enters the anomaly audit process.

[0089] S106. Based on the substitute verification results and the merged recovery aggregate verification results, restore the current session task to its fault state and execute the next round of multi-party security computation.

[0090] Specifically, such as Figure 2 As shown, when the substitute verification result and the merged recovery aggregate verification result are in a verified state, the recovery of the current fault can be completed, and then the next round of multi-party security calculation can continue. If each node of each session task is normal, that is, there are no faulty nodes or slow nodes, the next round of multi-party security calculation is also executed or the multi-party security calculation is completed according to the normal processing flow.

[0091] As a feasible implementation method, the multi-party secure computing session fault recovery system of this application further includes the following modules: 1) Session management module: used to create secure computing sessions, register participant identities, assign session identifiers, protocol types, task rounds, role numbers, and permission scopes. 2) Commitment checkpoint generation module: used to generate intermediate state commitments and global checkpoint proofs for each participant at specified rounds, specified time intervals, or specified computing progress points according to the checkpoint strategy. 3) Verifiable secret sharing module: used to perform threshold sharding, encrypted storage, and validity verification of the intermediate computing shares required for recovery. 4) Health monitoring module: used to collect participant heartbeats, round response times, message confirmation status, computing progress, resource usage, and anomaly logs to determine whether a node is in an unavailable state or continuously below a preset progress threshold. 5) Fault recovery module: used to select the most recent valid commitment checkpoint, coordinate all participants to roll back to that checkpoint, restore the necessary state of the faulty party, and start a substitute node to continue computing. 6) Slow Node Reassignment Module: Used to identify nodes that consistently fall below a preset progress threshold, dynamically allocate shardable local tasks or computational shares to other healthy nodes, and perform commitment verification on the reassignment results. 7) Audit and Consistency Verification Module: Used to record checkpoint chains, failure events, recovery events, substitute node takeover events, shard recovery events, and reassignment events, forming traceable audit evidence.

[0092] In addition, embodiments of this application also provide a multi-party secure computing session failure recovery device, such as... Figure 4 As shown, the multi-party secure computing session failure recovery device 400 specifically includes: At least one processor 401; and a memory 402 communicatively connected to the at least one processor 401; wherein the memory 402 stores instructions executable by the at least one processor 401 to enable the at least one processor 401 to execute: Based on the anomaly checkpoints in the multi-party secure computation task, the current protocol state of each participant is normalized to a local intermediate state and a state commitment is generated. The set of minimum recovery states extracted from the local intermediate state is divided into encrypted fragments, and based on the fragment verifiable commitment and state commitment of the encrypted fragments, a global checkpoint record that meets the preset threshold is generated. By performing a reverse lookup of the fault event records of the faulty node in relation to the nearest checkpoint through the checkpoint chain associated with the global checkpoint record, the recovery checkpoint used to recover the coordination node is determined. The system uses the selected backup node to perform a trusted verification of the consistency between the recoverable state reconstructed by the faulty participants at the recovery checkpoint and the recovery state commitment generated by the protocol context, thus obtaining the backup verification result. Based on the consistency of commitment in the backup verification result, multi-party security computation is performed on the next round of session tasks after the recovery checkpoint. The session tasks in the slow node are dynamically redistributed as shares of divisible subtasks, and the verified redistribution calculation results are globally merged through the healthy node to generate a merged recovery aggregate verification result. Based on the substitute verification results and the merged recovery aggregate verification results, the current session task is restored to its fault state and the next round of multi-party security computation is performed.

[0093] This application's embodiments utilize a most recently valid commitment checkpoint recovery mechanism to enable tasks to continue computation from a trusted intermediate state, avoiding extensive repetitive computations in long-term joint modeling and statistical tasks. Furthermore, by using a recoverable state and sharing encrypted shards with threshold secrets, no single node can obtain the complete intermediate state, effectively protecting data and secure computation protocol parameters. By checking aggregate signatures, round consistency, shard validity, chain hash continuity, and state commitment verification results, malicious nodes are prevented from forging checkpoints, injecting erroneous states, or inducing the system to roll back to an inconsistent state. Simultaneously, when multiple institutions participate in a task, the anomaly of any node no longer necessarily leads to task failure, significantly improving the stability of collaborative data computation and joint scientific research modeling. Moreover, this application not only handles abnormal node termination but also addresses the issue of slow nodes slowing down the overall process. Furthermore, through a slow node scoring and splittable task redistribution mechanism, overall task throughput efficiency can be improved while ensuring privacy and security.

[0094] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0095] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0096] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0097] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0098] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0099] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0100] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0101] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0102] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0103] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0104] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of this specification.

Claims

1. A method for recovering from failures in a multi-party secure computing session, characterized in that, The method includes: Based on the anomaly checkpoints in the multi-party secure computation task, the current protocol state of each participant is normalized to a local intermediate state and a state commitment is generated. The set of minimum recovery states extracted from the local intermediate states is divided into encrypted fragments, and a global checkpoint record that meets a preset threshold is generated based on the fragment verifiable commitment of the encrypted fragments and the state commitment. By performing a reverse lookup of the most recent checkpoints on the fault event records of the faulty node through the checkpoint chain associated with the global checkpoint record, the recovery checkpoint for the recovery coordination node is determined. Using the backup node selected by the system, a reliable verification of the consistency between the recoverable state reconstructed by the faulty participants at the recovery checkpoint and the recovery state commitment generated by the protocol context is performed to obtain the backup verification result; and based on the commitment consistency result in the backup verification result, multi-party security computation is performed on the next round of session tasks after the recovery checkpoint. The session tasks in the slow node are dynamically redistributed as shares of divisible subtasks, and the verified redistribution calculation results are globally merged through the healthy node to generate a merged recovery aggregate verification result. Based on the substitute verification result and the merged recovery aggregate verification result, the current session task is restored to its fault state and the next round of multi-party security computation is performed.

2. The method for recovering from a multi-party secure computing session failure according to claim 1, characterized in that, Based on anomaly checkpoints in multi-party secure computation tasks, the current protocol state of each participant is normalized to a local intermediate state and state commitments are generated. Specifically, this includes: The privacy computing platform receives requests for secure computing tasks from multiple parties and generates session identifiers and registration completion information for participating parties. Based on task type, data scale, estimated number of rounds, number of participants, and business importance, checkpoint strategies are generated; wherein, the checkpoint strategies include: generation by round, generation by time, generation by stage, and generation triggered by anomalies. After completing the session identifier, the registration completion information, and the checkpoint policy, anomaly judgments related to warning thresholds are performed on each node in the multi-party secure computation task to determine the abnormal checkpoints. The current protocol state corresponding to the anomaly checkpoint is normalized to obtain the local intermediate state; wherein, the local intermediate state includes: protocol round number, message send and receive confirmation table, unconfirmed message digest, secret share index, random number consumption counter, batch calculation progress, local cache digest, and recoverable state range; A hash digest is performed on the local intermediate state, and the session identifier, round number, role number, and random salt are added to generate the state commitment; wherein, the state commitment is used for consistency proof processing.

3. The method for recovering from a multi-party secure computing session failure according to claim 1, characterized in that, The set of minimum recoverable states extracted from the local intermediate states is subjected to encrypted fragmentation. Based on the fragmented verifiable commitment of the encrypted fragments and the state commitment, a global checkpoint record that meets a preset threshold is generated, specifically including: The minimum set of recoverable states required to extract recoverable states from the local intermediate states; wherein the minimum set of recoverable states includes at least: secret share, protocol counter, random mask remaining index, local task progress, and necessary message cache digest; The minimum recovery state set is divided into multiple encrypted fragments using a threshold secret sharing algorithm, and the encrypted fragments are sent to the recovery coordination node; wherein each encrypted fragment is appended with a fragment sequence number, session identifier, round number, and receiver identifier; Based on the secret sharing polynomial, fragment value, or fragment digest of the encrypted fragment, a fragment verifiable commitment is generated; wherein, the fragment verifiable commitment is used to verify the validity of the encrypted fragment between the participants and the receiver; Each participating party submits the sharded verifiable commitment, state commitment round number, phase identifier, and signature to the recovery coordination node. Based on the verification results of the consistency and validity of the recovery coordination node, a global checkpoint record that meets the preset threshold is generated, and the aggregate signature, threshold signature or multi-signature confirmation of each participant is recorded.

4. The method for recovering from a multi-party secure computing session failure according to claim 1, characterized in that, Before determining the recovery checkpoint for restoring the coordination node by performing a reverse lookup of the fault event records of the faulty node in relation to the nearest checkpoint through the checkpoint chain associated with the global checkpoint record, the method further includes: The health status of the session node is assessed and processed. If there is a node that has not submitted valid information or whose status commitment is inconsistent with the agreement progress confirmed by other participants, the corresponding node will be marked as the fault node. If a node is still responsive but its progress is consistently lower than the global median progress or its average progress exceeds a preset threshold, then the corresponding node is marked as the slow node. Based on the faulty node, the control recovery coordination node sends a session freeze command to other participants and suspends the entry into the next non-rollback protocol phase. The fault event record is generated based on the currently received message digest and the most recently approved checkpoint number submitted by each participant, and the fault events confirmed based on preset thresholds.

5. The method for recovering from a multi-party secure computing session failure according to claim 4, characterized in that, By performing a reverse lookup of the most recent checkpoints on the fault event records of the faulty node using the checkpoint chain associated with the global checkpoint record, the recovery checkpoint for restoring the coordination node is determined, specifically including: By restoring the coordinating node, the global checkpoint record is hashed with the previous checkpoint to generate a checkpoint chain hash; and the checkpoint chain hash is saved to the audit log. The local intermediate state is encrypted using a session key, and the encrypted local intermediate state and the corresponding state commitment are both stored in the audit log. Through the recovery coordination node, the checkpoint chain corresponding to the checkpoint chain hash is subjected to a reverse search and judgment of multiple types of conditions to obtain the condition judgment result of the nearest checkpoint. The multi-type conditions include: whether the checkpoint aggregate signature is valid; whether the participant set is consistent with the current session; whether the state commitment set is complete or meets the protocol threshold; whether the shard commitment verification is successful; whether the hash of the previous checkpoint chain is continuous; whether rollback is allowed in the protocol phase; and whether all healthy participants have confirmed that they have not entered the irreversible commit phase after the checkpoint. If the condition judgment result is a condition satisfied result, then the checkpoint that satisfies multiple types of conditions is determined as the recovery checkpoint.

6. The method for recovering from a multi-party secure computing session failure according to claim 1, characterized in that, Before performing a trusted verification of the consistency between the recoverable state reconstructed by the faulty participants at the recovery checkpoint and the recovery state commitment generated by the protocol context, the method further includes: Based on the checkpoint number of the restored checkpoint, load the corresponding new local intermediate state and recalculate the corresponding new state commitment; perform consistency comparison between the new local intermediate state and the new state commitment and the attribute items in the global checkpoint record. If the comparison is consistent, the healthy participant will be put into a waiting recovery state. If the comparison is in an inconsistent state, local state exception handling is triggered, and the previous valid checkpoint is selected based on the audit log.

7. The method for recovering from a multi-party secure computing session failure according to claim 1, characterized in that, By using the backup node selected by the system, a reliable verification of the consistency between the recoverable state reconstructed by the faulty participant at the recovery checkpoint and the recovery state commitment generated by the protocol context is performed to obtain the backup verification result, which specifically includes: If the failed participant cannot come back online within the recovery window, a substitute node is selected and determined; wherein, the substitute node is a backup node of the failed participant's organization or an authorized managed execution node; and the substitute node does not obtain the original business data of the failed participant, but only restores the intermediate computing share necessary to complete the protocol continuation. Through the substitute node, the recovery coordination node that stores the encrypted fragments controls the fragment recovery request to obtain the corresponding encrypted fragments; The corresponding encrypted fragments are processed to remove invalid fragments, and secret reconstruction is performed to obtain the recoverable state of the faulty participant at the recovery checkpoint; Through the substitute node, the recovery state commitment generated by the recoverable state and the protocol context is compared with the original state commitment or recovery commitment of the faulty participant in the global checkpoint record for consistency verification. If the verification result of the substitute node is a consistent result, then the substitute node is determined to be trustworthy in the restored state; If the verification result of the substitute node is inconsistent with the commitment, the substitute node will be determined to be in a state of refusal to continue and a manual audit process will be initiated.

8. The method for recovering from a multi-party secure computation session failure according to claim 1, characterized in that, The session tasks in slow nodes are dynamically reallocated as shares of divisible subtasks. Then, through healthy nodes, the verified reallocation calculation results are globally merged to generate a merged recovery aggregate verification result, specifically including: The detected slow nodes are scored using relevant resource indicators to obtain a score for the slow node. When the score of the slow node exceeds the first preset threshold and the current session task has divisible subtasks, the unfinished local batch, matrix block, gradient sharding calculation or intermediate share conversion tasks in the slow node are re-encoded into several sub-shares and reassigned to healthy nodes for execution, thus obtaining the reassignment calculation result. After the healthy node undertaking the redistribution task completes the calculation, the coordinating node is restored to verify the subtask state commitment, the original session task state commitment, and the merging rules, and obtain the verification results. If the verification result is a successful verification result, the redistribution calculation result is merged into the global protocol state, and the newly submitted state commitment and corresponding signature are aggregated and verified through the post-recovery checkpoint to obtain the merged recovery aggregated verification result; If the merged recovery aggregation verification result is a pass result, then multi-party security computation is performed on the next round of session tasks after the recovery checkpoint; If the merged recovery aggregation verification result is a failure, then rollback to the pre-recovery checkpoint and enter the anomaly audit process.

9. A multi-party secure computing session failure recovery device, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor to enable the at least one processor to perform a multi-party secure computing session failure recovery method according to any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that, The storage medium is a non-volatile computer-readable storage medium that stores at least one program, each program including instructions that, when executed by a terminal, cause the terminal to perform a multi-party secure computing session failure recovery method according to any one of claims 1-8.

Images