Data verification processing method and device for privacy protection, equipment and medium

Abstract

The invention relates to the technical field of security mechanisms, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a privacy protection data verification processing method, device, equipment and medium, comprising: obtaining sensitive data, processing or encrypting the sensitive data in a privacy protection execution environment, and executing training iteration based on the processed data, and generating a training abstract, updating the training log chain which cannot be tampered, and providing the training log chain for verifying the training process under the verification request. According to the method, privacy protection calculation and a non-tampering log mechanism are combined, so that model training has verifiability on the premise of not exposing sensitive data, and unification of privacy protection and training compliance auditing is realized.

Description

Technical Field

[0001] This invention relates to the field of security mechanism technology, and in particular to a data verification processing method, apparatus, device and medium for privacy protection. Background Technology

[0002] In the fintech sector, as institutions increasingly rely on data such as customer information, transaction logs, and claims records, the scale of data required for model training and risk control analysis continues to expand. However, such data typically contains a large amount of sensitive information, and its use is subject to strict privacy protection and regulatory requirements. While existing data processing and model training technologies can meet data availability requirements to some extent, significant shortcomings remain in terms of privacy protection, auditability, and verifiability. For example, while local encrypted training technology can perform computations in an encrypted state, its computational overhead is extremely high, making it difficult to support the large-scale data training tasks commonly found in financial scenarios. Trusted execution environments (TEAs) execute the training process through hardware isolation, but their limited resources make it difficult to handle training loads of high-dimensional or massive amounts of financial data. Furthermore, the internal execution processes of TEAs typically cannot provide verifiable training trajectories to external regulators, resulting in insufficient applicability in compliance audit scenarios.

[0003] In the healthcare sector, medical institutions need to handle highly sensitive and private information such as medical records, monitoring records, and diagnostic data. This data faces the dual requirements of privacy protection and auditability when used for model building and intelligent analysis. While technologies such as secure multi-party computation and federated learning can reduce the risk of centralized data exposure, these methods generally suffer from high communication overhead, complex deployment, and difficulty in verifying the training process. Especially when providing proof of the model training process to regulatory authorities or research ethics committees, existing technologies often rely solely on offline logs or manual records, which are difficult to guarantee as tamper-proof and cannot provide reliable verification of the training process. Summary of the Invention

[0004] The main objective of this invention is to provide a privacy-preserving data verification processing method, apparatus, device, and storage medium, aiming to solve the technical problem that existing technologies cannot provide an independently verifiable and tamper-proof training proof chain for the model training process while protecting sensitive data from being exposed.

[0005] To achieve the above objectives, the present invention provides a privacy-protected data verification processing method, comprising: Retrieve sensitive data to be processed; The sensitive data can be loaded into a privacy-preserving execution environment to obtain plaintext data within the environment, or the sensitive data can be encrypted to obtain encrypted data. Within the privacy-preserving execution environment, a model training process comprising multiple training iteration cycles is performed based on plaintext data within the environment, or based on encrypted data in an encrypted domain. During the model training process, for each of the plurality of training iteration cycles, the training information corresponding to the training iteration cycle is extracted, and a training summary is generated based on the training information. Update the immutable training log chain based on the training summary; In response to the verification request, provide the immutable training log chain.

[0006] Furthermore, to achieve the above objectives, the present invention provides a privacy-protected data verification processing apparatus, comprising: The sensitive data acquisition module is used to acquire sensitive data to be processed. The privacy-preserving data generation module is used to load the sensitive data into the privacy-preserving execution environment to obtain plaintext data within the environment, or to encrypt the sensitive data to obtain encrypted data. The model training execution module is used to perform a model training process including multiple training iteration cycles, either within the privacy-preserving execution environment based on plaintext data within the environment or in an encrypted domain based on encrypted data. The training summary generation module is used to extract training information corresponding to each training iteration cycle in the plurality of training iteration cycles during the model training process, and generate a training summary based on the training information. The training log chain update module is used to update the immutable training log chain according to the training summary. The verification request response module is used to respond to verification requests and provide the immutable training log chain.

[0007] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a privacy-protected data verification processing program stored in the memory and executable on the processor, wherein when the privacy-protected data verification processing program is executed by the processor, it implements the steps of the privacy-protected data verification processing method as described above.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a non-volatile computer-readable storage medium storing a privacy-protected data verification processing program, wherein the privacy-protected data verification processing program, when executed by a processor, implements the steps of the privacy-protected data verification processing method as described above.

[0009] Beneficial Effects: This invention relates to the field of security mechanism technology and can be applied to business scenarios such as fintech and healthcare. It discloses a privacy-preserving data verification processing method, apparatus, device, and medium, comprising: acquiring sensitive data; loading the sensitive data into a privacy-preserving execution environment to obtain plaintext data within the environment or performing encryption processing on the sensitive data to obtain encrypted data; executing a model training process containing multiple training iteration cycles based on the plaintext data or encrypted data within the environment; extracting training information for each training iteration cycle during the model training process and generating a training summary; updating an immutable training log chain based on the training summary; and providing the immutable training log chain to perform training process verification upon receiving a verification request. This invention achieves external verifiability of the entire model training process by performing training computation in a secure environment or encrypted domain and generating an immutable log chain based on the training summary. This allows regulators or business auditors to complete training compliance verification without accessing sensitive data, improving data privacy protection capabilities while ensuring the auditability and credibility of large-scale model training. Attached Figure Description

[0010] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a privacy-protecting data verification processing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the privacy-protecting data verification processing method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the privacy-protecting data verification and processing device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0011] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0012] The privacy-protected data verification processing method provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can obtain sensitive data from the client, load the sensitive data into a privacy-preserving execution environment to obtain plaintext data within the environment, or encrypt the sensitive data to obtain encrypted data; it then executes a model training process containing multiple training iteration cycles based on the plaintext or encrypted data within the environment; during model training, it extracts training information from each training iteration cycle and generates a training summary; it updates an immutable training log chain based on the training summary; and upon receiving a verification request, it provides an immutable training log chain to perform training process verification. This invention achieves external verifiability of the entire model training process by performing training computations in a secure environment or encrypted domain and generating an immutable log chain based on the training summary. This allows regulators or business auditors to complete training compliance verification without accessing sensitive data, improving data privacy protection capabilities while ensuring auditability and credibility of large-scale model training. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0013] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the privacy-protecting data verification processing method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0014] like Figure 2 As shown, the privacy-protected data verification processing method proposed in this invention includes the following steps: S10, Obtain the sensitive data to be processed; In this embodiment, the acquisition of sensitive data to be processed serves as the fundamental entry point in the data computing task, aiming to provide stable, controllable, and clearly sourced data input for subsequent privacy protection training processes. Sensitive data encompasses data units that can point to personal identity, behavioral patterns, financial status, physiological conditions, transaction records, or other identifiable attributes. The characteristics of this type of data dictate that it needs to maintain security, integrity, and auditability during collection, transmission, and loading. To achieve this, in actual acquisition operations, it is typically necessary to establish data input channels and manage data sources, data formats, field integrity, and data batches through preset data access strategies to ensure the legality and consistency of data loaded into the system.

[0015] During data acquisition, sensitive data can be collected through server file interfaces, database query interfaces, log capture channels, or message queue channels. Data input channels typically include a network transmission unit, a caching unit, and a data parsing unit. The network transmission unit is responsible for transferring data between different systems. An initial connection can be established via a secure handshake protocol. The secure handshake process can be based on a key exchange algorithm or a random number sequence output by a hardware security module. This exchange generates a session key, providing an encrypted foundation for subsequent sensitive data transmission. After entering the caching unit, data is temporarily stored to handle network fluctuations or source system response delays. The caching unit supports multiple batches of concurrent input and can be implemented using memory queues or disk buffer files. When data reaches the parsing unit, field mapping, type validation, and format standardization are performed based on pre-defined structural description information to generate a data structure suitable for subsequent privacy-preserving computational links.

[0016] The scope of sensitive data is not limited to a specific industry in the implementation. It can include transaction logs, account behavior sequences, and risk event records used for modeling in financial scenarios, as well as health monitoring data, device-collected data, vital sign records, or digital information generated during diagnosis and treatment in medical scenarios. During the acquisition process, field filtering rules can be used to load only data within specific fields or time intervals, reducing the redundant computational burden caused by irrelevant content. The data source system typically has an access control module, and access operations require authorization through an authentication mechanism, which can use access tokens, hardware signatures, or other identity verification methods.

[0017] In practice, to ensure the integrity and authenticity of the acquired data, data verification information can be attached to the transmission link. For example, hash calculations can be performed on data blocks and appended to the data header. By recalculating the hash value and comparing it during the loading phase, it can be ensured that no tampering has occurred. In business integration scenarios, sensitive data is often not loaded all at once, but arrives in batches. Each batch is assigned a batch number, timestamp, and source system tag. These identifiers allow the data to be linked to the corresponding training batch in subsequent training cycles, enabling data lifecycle tracking capabilities.

[0018] This embodiment introduces mechanisms such as secure transmission, structured parsing, and integrity verification to ensure that sensitive data remains secure, accurate, and traceable before being loaded into the privacy-preserving computation link. This lays a reliable data foundation for the subsequent privacy-preserving training, hash digest generation, and verification link construction, thereby achieving higher data credibility and training process verifiability.

[0019] S20, the sensitive data is loaded into the privacy protection execution environment to obtain plaintext data within the environment, or the sensitive data is encrypted to obtain encrypted data; In this embodiment, sensitive data is loaded into a privacy-preserving execution environment to obtain plaintext data within the environment, or the sensitive data is encrypted to obtain encrypted data, which is used to establish a trusted data input path before training. The data processing strategy determines which path to use based on the data sensitivity level, operating conditions, and security requirements. When loading into the privacy-preserving execution environment, data transmission needs to be completed through a secure communication link, and plaintext data is generated in an isolated memory area. The isolated area has the characteristic that it cannot be directly read from the outside, enabling efficient computation in plaintext state. If an encrypted path is used, a suitable encryption algorithm needs to be selected, a data encryption key needs to be established through a key generation process, and a ciphertext structure needs to be constructed for the original data, so that the data will not be leaked even in a non-isolated environment.

[0020] Plaintext data within the environment is organized into tensor structures according to internal computational requirements, which the training engine can directly consume. Encrypted data is marked as a cryptographic structure and accompanied by encryption parameters to support subsequent encrypted domain computations. Before entering any path, each data batch generates a path identifier and a batch identifier to ensure consistency during training and log chain generation. The two paths can be flexibly switched based on resource availability to ensure both privacy protection and training efficiency are maintained in different operating environments.

[0021] The implementation can employ a fully isolated path, loading all sensitive data as plaintext data within the environment when the hardware isolation environment has sufficient capacity, thereby improving training speed. Alternatively, a hybrid approach can be used, loading some key features as plaintext data within the environment while using an encrypted path for high-dimensional or cross-institutional data to balance resource consumption. Encryption processing can use symmetric algorithms for higher performance or asymmetric algorithms to meet the needs of cross-institutional data flow. For data with different structures, encrypted data can be organized using block-based, column-level, or time-slice encryption methods, making it easier for the dense-state training engine to handle. Furthermore, structural repair or anomaly filtering can be performed on the original data before loading to ensure the stability of subsequent calculations.

[0022] This embodiment enables the training pipeline to operate flexibly in different security environments by isolating and loading or encrypting sensitive data. It ensures that the data is not exposed while maintaining the executability of training, and provides a safe and stable data input foundation for subsequent iterative calculations, summary generation, and the construction of verifiable records.

[0023] S30, within the privacy protection execution environment, based on plaintext data within the environment, or in the encrypted domain, based on encrypted data, a model training process including multiple training iteration cycles is executed; In this embodiment, a model training process comprising multiple training iteration cycles is executed within a privacy-preserving execution environment based on plaintext data within the environment, or within an encrypted domain based on encrypted data. This process is used to continuously update model parameters within a trusted execution environment or a cryptographic computing environment. A training iteration cycle represents a complete loop of forward inference, loss calculation, and parameter update, serving as the basic execution unit for the model convergence process. Plaintext data within the environment directly enters the internal computation unit, forming input tensors suitable for neural networks, tree models, or other structured models, and forward inference is performed using internal computing power. Encrypted data is parsed by the cryptographic computing engine, and forward inference is performed by supporting cryptographic matrix calculations, encrypted arithmetic, or piecewise homomorphic operations, ensuring the training process remains executable without exposing data.

[0024] The process of initializing model parameters involves creating weight tensors, bias parameters, or structured mapping tables based on the model type, and constructing an initial parameter set through random initialization, distributed initialization, or cold / warm start methods. During the training iteration cycle, intermediate activation values ​​are generated based on the current model parameters and corresponding data, and the loss is calculated in a safe state. The loss calculation method can include distance difference, cross-entropy, error regression, or other structures adapted to the training objective. The calculated loss is stored in an isolated memory region or dense state register space to ensure that intermediate information is not leaked during the training process. Gradient information is generated in an internal environment or encrypted domain, and gradient propagation is achieved through automatic differential paths, dense state gradient estimation, or structured gradient transformation. When updating model parameters, parameter values ​​are adjusted based on gradient information and the learning rate strategy, enabling the training process to iteratively converge along the optimal direction.

[0025] Multiple training iterations are executed sequentially under the control of the internal scheduling module, with strict dependencies between each cycle. The execution process maintains consistency with the path identifiers and batch identifiers generated in the preceding steps, ensuring that training summary generation and log chain updates reliably correspond to each cycle. Plaintext and encrypted data paths within the environment maintain data isolation during scheduling, preventing training operations from crossing between the two environments and avoiding data leakage or algorithm conflicts.

[0026] This embodiment completes multiple training iterations in an isolated environment or encrypted domain, allowing sensitive data to participate in model training without exposure, while maintaining a continuous, recordable, and verifiable training process, providing a stable computational foundation for the subsequent generation of trusted training summaries and tamper-proof log chains.

[0027] S40, during the model training process, for each of the plurality of training iteration cycles, the training information corresponding to the training iteration cycle is extracted, and a training summary is generated based on the training information. In this embodiment, the model training process requires processing multiple training iteration cycles one by one. Each training iteration cycle corresponds to a set of data closely related to the training state, typically derived from internal variables, statistics, and structured records generated by the model in the current batch computation. A training iteration cycle represents an independent loop that updates parameters with a fixed training batch as input, originating from the scheduling control of the deep learning framework. Training information consists of key fields in the training iteration cycle, including batch input encoding, model parameter representation, loss value expression, gradient statistics, timestamps, node identifiers involved in computation, or intermediate state records generated in the execution environment. These fields originate from the training execution graph, optimizer cache, gradient pool generated by the automatic differentiation mechanism, or internal log channels. To ensure the training information has verifiability and structured characteristics, it needs to undergo unified serialization processing, converting different types of data into compressible byte structures or unified tensor representations, and performing field concatenation, byte alignment, or unified encoding to make it an input stream that can be directly processed by the digest algorithm. The training digest is constructed using a cryptographic hash function or a secure digest generation algorithm, mapping the training information to a fixed-length and irreversible hash value. When generating training summaries, the training information needs to be standardized and preprocessed, including removing redundant fields, normalizing type representations, arranging field order, and injecting possible random salt values. This ensures that the summary results are sensitive to and collision-resistant to the input. As an immutable record of training execution, the training summary reflects the computational state of the current training iteration cycle and can be used to verify whether the training process was actually executed, maintained in order, and was not tampered with or skipped.

[0028] This embodiment extracts training information and generates a training summary in each training iteration cycle, enabling the establishment of a verifiable training execution trajectory without exposing the model's internal data structure and intermediate variables. This achieves auditability, traceability, and non-repudiation of the training process. Furthermore, even in environments lacking access rights, summary comparison can still verify whether the training has been fully executed, reducing the risk of training process tampering, skipping steps, or falsification. Thus, a stable and reliable training record system is constructed within a privacy-preserving training framework.

[0029] S50, Update the immutable training log chain according to the training summary; In this embodiment, updating the immutable training log chain based on the training summary requires consideration of the organization of the summary value, the connection mechanism of the log structure, and the formation logic of the anti-tampering attribute. The training summary is a fixed-length identifier obtained by mapping the training information generated during training execution through a summary algorithm, possessing input sensitivity and irreversibility. The log chain is a chain-like record structure arranged in the order of training iterations and combined into a whole through encrypted links. The immutability stems from the reference relationship between adjacent nodes in the log chain. Each node stores the current training summary and the summary reference value of the previous node, creating a sequential dependency relationship within the chain. If any historical node is modified, its hash value changes, and the reference values ​​of subsequent nodes will no longer match, thus immediately exposing the anomaly during verification. The core of the update operation lies in establishing a connection between the newly generated training summary and the previous node, constructing a new log node through field concatenation, structure serialization, and secondary compression using the summary algorithm, and then appending it to the end of the chain. To enhance verification capabilities, the log chain can incorporate timestamps, execution environment identifiers, cumulative counters, random salts, or key-derived values. This allows the chain to reflect not only the training order but also the training execution background and environment. The append-on update process must ensure the stability of the node write order. This can be achieved by relying on a trusted time source, a monotonically increasing counter, or a sequence lock mechanism in the execution environment, ensuring the log chain continuously reflects the training iteration trajectory. The immutability attribute also depends on the storage medium. This can be achieved using trusted storage areas that support the characteristic of being unchangeable after being written, or by implementing update persistence based on an append-only write structure, distributed witness nodes, or hardware isolation areas. The structure of the training log chain carries both the training summary and the chained reference relationships, with the update process reflecting a continuous logic from summary generation to chained appending.

[0030] This embodiment updates an immutable training log chain based on training summaries, which solidifies the state of training iterations into a chain-like trajectory in a strongly bound manner, giving the training process verifiable continuity and tamper-resistance. Any modification or jump in any link will break the chain, thus providing credible evidence for subsequent regulatory review, compliance verification, and training process review, achieving transparency and reliable recording of the training execution status.

[0031] S60, in response to the verification request, provides the immutable training log chain.

[0032] In this embodiment, responding to verification requests and providing an immutable training log chain requires consideration of the verification request parsing mechanism, the log chain retrieval method, and the transmission structure of the chained records. Verification requests are typically sent by an external verifier, carrying an identifier used to locate the training iteration cycle, indicating the training interval or specific node to be viewed. Verification requests are structured data, which may contain training cycle numbers, timestamps, or digest citation codes, and their source may be a regulatory system, audit module, or research institution. Parsing verification requests needs to be completed in a trusted execution environment or isolated service to reduce external interference and ensure that the request content has not been tampered with. The training log chain is a chained structure composed of multiple log nodes processed by a digest algorithm. Each node contains a training digest, time information, citation hash, and append order marker, exhibiting chain-like sequential characteristics to ensure that the records cannot be forged. Providing the training log chain involves locating the target sub-chain or the entire chain based on the verification request, and then serializing the log content according to the transmission format. The serialization process can use a compact binary structure, structured key-value format, or compressed encoding. Verification-specific check fields can also be added before the output to help the verifier quickly confirm the chain's continuity. Because the log chain is immutable, the provision process does not allow deletion, modification, or reordering of nodes; it can only return nodes in the natural order they were recorded. To improve verification efficiency, the provision process can select specific nodes based on the request, or return a snapshot of the entire chain's structure, allowing the verifier to perform integrity checks.

[0033] This embodiment provides a complete and verifiable training process trajectory to external verifiers by responding to verification requests and providing an immutable training log chain. This allows for a verifiable and continuous recording of the training execution status, thereby enabling reliable verification of the authenticity, sequence, and completeness of training without compromising privacy.

[0034] In one embodiment, step S20 above includes: S201, based on a preset data processing strategy, determine whether to load the sensitive data into the privacy protection execution environment; S202, if so, then establish a secure communication channel with the privacy protection execution environment, and transmit the sensitive data to the privacy protection execution environment through the secure communication channel, and treat the sensitive data located inside the privacy protection execution environment as plaintext data inside the environment; S203, if not, select an encryption algorithm type and generate a data encryption key corresponding to the encryption algorithm type; S204, use the data encryption key and the selected encryption algorithm type to encrypt the sensitive data to generate encrypted data.

[0035] In this embodiment, a preset data processing strategy is established by the system during the deployment phase to determine whether sensitive data enters the privacy protection execution environment or the encryption processing flow. The strategy can be constructed based on dimensions such as data type labels, compliance levels, training scale, computing resources, response latency requirements, or cross-domain collaboration needs. It determines the processing path of the input data through condition matching or a weighted decision model. After receiving the metadata of the sensitive data, the strategy engine outputs a path selection signal, which serves as the entry condition for subsequent loading operations.

[0036] When policy decision data enters the privacy-preserving execution environment, a secure communication channel needs to be established between the two environments. The channel establishment process may include authentication, key negotiation, and session parameter determination to ensure the transmission link is not spied on or tampered with externally. Sensitive data can undergo structure encoding or fragmentation before entering the communication channel to ensure correct recovery in a restricted environment. After data transmission is complete, it is written to an isolated memory area, forming plaintext data within the environment. This data can only be accessed by the computational logic within the execution environment. This approach is typically used in scenarios with moderate data size, strict performance requirements, or where the training process needs to process raw features.

[0037] When the policy determines that sensitive data should not enter the privacy-preserving execution environment, sensitive data needs to be encrypted in an external environment to support subsequent encrypted domain training. The encryption algorithm type specifies the encryption structure, such as a symmetric algorithm, an encryption structure with operator preservation capabilities, or a ciphertext system that supports proxy re-encryption. The selection of this type needs to balance security level, compatibility of training operators, and encryption execution efficiency. The data encryption key is generated by a key management service or secure hardware module. Key materials can be bound to task identifiers or time ranges to improve key independence. Sensitive data needs to be formatted, randomly padded, or block-splitting before encryption to increase the ciphertext entropy and reduce the risk of structure leakage. The encrypted ciphertext forms encrypted data, providing input for the training engine to perform calculations in the encrypted domain.

[0038] In summary, policy-driven path selection allows sensitive data to enter the subsequent training process in either plaintext or ciphertext form. Both paths maintain consistent interface specifications in terms of input format, execution environment, encryption dependencies, and security boundaries, enabling the training system to flexibly adapt to different privacy constraints. This provides a reliable foundation for subsequent verifiable training and log construction.

[0039] This embodiment utilizes data processing strategies to dynamically select between a privacy-preserving execution environment and an encrypted processing path, converting sensitive data into plaintext or encrypted data within the environment. This ensures consistent input security during training across different compliance levels and deployment conditions. This mechanism balances performance and privacy requirements, improving operational efficiency during training in isolated environments and reducing the risk of sensitive information exposure during training in encrypted domains. It achieves a balance between security, flexibility, and scalability, laying a secure foundation for the subsequent training and verification chain.

[0040] In one embodiment, step S30 above includes: S301, if the execution is based on plaintext data within the environment, then within the privacy-preserving execution environment, the plaintext data within the environment is placed in a secure memory area; S302, If execution is based on the encrypted data, then the encrypted data is input into the training engine and executed in the encrypted domain; S303, within the privacy protection execution environment or encrypted domain, initialize the model parameters; S304, For each training iteration, determine the model loss based on the current model parameters and the plaintext or encrypted data within the environment used; S305, determine the gradient information of the model parameters based on the model loss; S306, Update the model parameters using the gradient information.

[0041] In this embodiment, when training is performed within the privacy-preserving execution environment based on plaintext data within the environment, the plaintext data passed in from the previous stage must first be bound to the training task. This plaintext data is stored in a restricted-access secure memory region. The secure memory region can be a segment of memory composed of hardware isolated pages, controlled cache space, or virtualized isolated areas, accessible only to authenticated training processes. External operating systems, monitoring programs, or debugging tools cannot directly read the contents of this region. The training service reads the plaintext data from the secure memory region upon startup, providing continuous batches for subsequent model input. Throughout the entire training lifecycle, the plaintext data does not need to leave this region.

[0042] When training on encrypted data in an encrypted domain, the encrypted data is fed into the training engine as input. The training engine can be deployed in an execution environment that supports encrypted operations, such as an execution component that relies on a homomorphic operation library, or a collaborative execution component based on a multi-party data sharing mechanism. The encrypted data enters the training engine through an interface queue buffer. The training engine selects an appropriate operation process according to its configuration, ensuring that forward propagation and gradient derivation are completed without recovering the plaintext. To adapt to different encryption structures, the training engine can internally perform block-level partitioning, computation graph rearrangement, and operation order adjustment on the encrypted data, ensuring that each training iteration is completed within the allowed set of operations.

[0043] Model parameters are a set of numerical values ​​describing the connection weights, biases, and normalization coefficients of each layer in the model structure. They are the core content that needs to be continuously updated during training. When initializing model parameters, random distribution initialization, loading pre-trained parameters, or migrating parameter sets from historical versions can be used. The initialization behavior must maintain consistent logic in both the privacy-preserving execution environment and the cryptographic domain; the only difference lies in the implementation location within the different execution environments. In the privacy-preserving execution environment, initialization is performed directly in a secure memory region or its associated register space. In the cryptographic domain, initialization can be performed in the ciphertext space or in a trusted region before being converted to encrypted form for subsequent encryption operations.

[0044] Multiple training iterations constitute the time dimension of the complete training process. Each training iteration includes one round of forward computation, error measurement, and parameter updates. The current model parameters represent a set of parameter values ​​that are in effect at the start of the current iteration, and are the results of the previous round's updates. Plaintext or encrypted data within the environment serves as the input for this round, and is organized into training batches by the data reading unit. Forward computation directly operates on the plaintext data within the privacy-preserving execution environment, and processes encrypted data through encryption operations in the encrypted domain to obtain the predicted output or intermediate representation. The model loss is a metric obtained based on the difference between the predicted output and the target label, and can employ distance metrics, log-likelihood metrics, or piecewise metric structures. In the privacy-preserving execution environment, loss calculation is performed in the plaintext space; in the encrypted domain, loss calculation needs to be mapped to encrypted-supported operation combinations, and structural equivalence is ensured through computation graph transformation.

[0045] When deriving gradient information of model parameters based on model loss, it is necessary to solve for the direction of change of loss across model parameters. Gradient information can be viewed as a direction vector covering all parameters, indicating how the parameters should be adjusted to reduce loss under the current input and model structure. In privacy-preserving execution environments, gradient derivation can be completed using an automatic differentiation framework or a manually constructed backpropagation graph; in cryptographic domains, the gradient derivation process needs to be broken down into a series of cryptographically compatible sub-operations, transforming the gradient expression into an executable form in the cryptographic domain. To reduce resource consumption, gradient information can be stored in blocks or sparsified, retaining only the most influential parts for updates.

[0046] When updating model parameters using gradient information, an update strategy needs to be selected and update rules applied to each training iteration. Update strategies can employ fixed learning rate strategies, adaptive learning rate strategies, or hierarchical update strategies. Different strategies affect convergence speed and stability by adjusting the step size and direction. In a privacy-preserving execution environment, update operations are performed directly on the model parameters within a secure memory region, keeping the parameters protected and preventing leakage. In the encrypted domain, update operations are completed in the encrypted space, or partially updated after decrypting intermediate gradients in a secure collaborative environment, and then the results are remapped back to the encrypted space. After the parameter updates are completed, a new set of model parameters is formed, becoming the current model parameters for the next training iteration, thus creating a continuous chain in the training process.

[0047] By sharing a unified training iteration process across the privacy-preserving execution environment and the encrypted domain, the plaintext data paths and encrypted data paths within the environment are unified into isomorphic training logic. Each training iteration cycle follows the same input organization method, loss measurement method, and update strategy, enabling training trajectories generated under different privacy-preserving environments to be uniformly recorded and verified, providing a structurally consistent foundation for subsequent training summary generation and log chain construction.

[0048] This embodiment performs model training across multiple training iterations within a privacy-preserving execution environment, using plaintext data within that environment, and in an encrypted domain, using encrypted data. Each training iteration sequentially completes parameter initialization, loss derivation, gradient information acquisition, and parameter updates, maintaining consistent training logic across different privacy-preserving environments. This ensures that sensitive data remains confined to a protected or encrypted space, reducing the risk of data leakage. Furthermore, iteratively updating model parameters continuously improves model performance, maintaining optimizability while meeting privacy and compliance constraints. Simultaneously, it provides a complete training process record for subsequent summary generation and log chain verification based on training iterations.

[0049] In one embodiment, step S40 above includes: S401, during the model training process, obtain the batch input data, current model parameters and model loss value corresponding to the current training iteration cycle; S402, combine the batch input data, current model parameters and model loss values ​​to form a training information set for the current training iteration cycle; S403, The training information set is processed using a cryptographic hash function to generate a corresponding training digest; S404, associate the training summary with a unique identifier for the current training iteration cycle.

[0050] In this embodiment, introducing training summaries during model training requires first clarifying the temporal structure of multiple training iteration cycles. These multiple training iteration cycles can be understood as training rounds arranged sequentially, with each round generating an independent intermediate state after forward computation and parameter updates. Constructing independent records for each training iteration cycle is crucial for accurately locating individual training actions during subsequent validation. When the training system enters a particular training iteration cycle, monitoring logic can be inserted into the control flow to collect input, parameter, and loss information related to the current round, providing the original source for constructing the training information set.

[0051] The batch input data corresponding to the current training iteration cycle can include feature vectors, target labels, mask matrices, and auxiliary context information. Batch division is typically based on the number of samples or GPU memory capacity, with each batch unit constituting a group of inputs. When loading batch input data, the training engine can read data blocks from a cache queue, file system, or remote storage via a data pipeline, encoding the raw data into tensor form or other numerical structures before it enters the model for computation. For subsequent summary generation, in addition to being used for forward computation, the batch input data can also be serialized to generate stable representations, such as extracting sample numbers, feature summary values, and label distributions into compact structures to reduce record size.

[0052] The current model parameters are a set of values ​​that are already in effect at the start of the current training iteration, including the weights, biases, normalization coefficients, and any momentum terms or adaptive scaling factors that may exist for each layer of the network. Since the complete parameter set is usually quite large, directly writing it into the summary would impose a storage and computational burden. Therefore, the current model parameters can be dimensionality-reduced or summarized, for example, by extracting parameter hashes, parameter norms, distribution statistics, or version identifiers from some layers, treating this information as representative of the model state. After completing an update, the training framework can also assign an incrementing version number to the new parameter state, referencing this version number in subsequent training iterations to contribute to the construction of the training information set.

[0053] The model loss value represents the error metric for the current training iteration on a selected batch of input data. The loss value can be a single scalar or a combined metric consisting of multiple dimensions, such as classification error, regularization, and adversarial components. The training engine has already obtained the model loss value after forward and backward computations, and it can be added to the record without additional large-scale computations. To improve verifiability, the record can include both the original output of the loss value and its standardized form, allowing external verifiers, given the same loss function definition, to derive consistent results by replaying the training logic.

[0054] The batch input data, current model parameters, and model loss values ​​combine to form the training information set for the current training iteration. This training information set can be viewed as a structured record built around a single training action. The specific organization of the training information set can employ key-value pairs, field sequences, or hierarchical structures. The field order is fixed during design to ensure the same arrangement is generated in any execution environment. The training information set can contain metadata such as timestamps, training environment identifiers, and runtime configuration summaries, allowing verifiers to not only see the relationship between inputs and outputs but also identify the consistency of the training environment when examining the training summary.

[0055] Cryptographic hash functions are used to compress training information sets into fixed-length digest values. Cryptographic hash functions possess characteristics such as a wide input space, a uniformly distributed output space, small changes in input causing large changes in output, and difficulty in deriving the input from the output. To adapt to different regulatory requirements and security levels, an instance from a family of hash functions can be selected, and the function identifier can be recorded in the training configuration. Before participating in the hash operation, the training information set can be serialized and encoded, for example, into a byte stream, a fixed-length field sequence, or a flattened tree structure, ensuring that the same training information set receives a completely consistent input sequence across different execution nodes. After the hash operation is completed, a training digest is output. This training digest becomes a compact representation of the training iteration cycle and can be used for log chain construction and external verification.

[0056] A unique identifier for the current training iteration cycle is used to distinguish different training iteration cycles over time. It can be composed of a round number, timestamp, training phase marker, or a combination of multiple fields. This unique identifier is globally unique, ensuring that any training summary corresponds to a unique training iteration cycle. The training system generates or updates the unique identifier when starting a new training iteration cycle and binds it to the internal state of the current round. After the training summary is generated, it needs to be associated with the unique identifier of the current training iteration cycle. This association can be achieved through structured records, key-value mappings, or field pairs in log entries. The association is saved in subsequent log chain update processes. When external verifiers retrieve log records, they can locate a specific training iteration cycle using the unique identifier and then perform integrity verification using the training summary and chain structure. This allows them to determine whether the training process has executed as expected without accessing sensitive data.

[0057] This embodiment constructs a training information set by collecting batch input data, current model parameters, and model loss values ​​in each training iteration cycle. A cryptographic hash function is then applied to generate a training digest, which is associated with a unique identifier for the current training iteration. This allows for the generation of a compact and verifiable record for each training action without exposing specific data content or complete parameter details. The training process thus possesses traceability, location, and replayability. When regulators or auditors have access to the same training configuration, they can verify whether the training process was fully executed and whether it has been tampered with based on the training digest and unique identifier, thereby obtaining credible evidence supporting the training process under privacy protection constraints.

[0058] In one embodiment, step S50 above includes: S501, retrieve the training summary generated in the current training iteration cycle; S502, retrieve the root hash value of the latest record from the immutable training log chain; S503, the training summary and the root hash value are concatenated to generate a data block to be hashed; S504, Apply a hash function to the data block to be hashed to generate a new root hash value; S505, combine the new root hash value with the current timestamp to form a new log record, and write it into the immutable training log chain.

[0059] In this embodiment, the step of updating the immutable training log chain takes the training summary as input and continuously injects local proofs from the training process into a chain structure that grows chronologically. The training summary generated in the current training iteration can be understood as a fixed-length summary value obtained by cryptographically compressing the training input, model state, and loss result of this round. This summary value is usually stored in the form of a byte sequence or a hexadecimal string, originating from the output of the hash operation on the training information set in the previous step, and is the unique representative of this round of training behavior at the external recording layer. Before entering the log update logic, the training system can read the training summary generated in the current training iteration from the cache, message queue, or internal state table to ensure that the summary has been generated and will not be recalculated or replaced in subsequent iterations.

[0060] An immutable training log chain carries summary records for all training iterations and can be constructed as an append-only storage structure. In implementation, the log chain can be maintained as a sequential file, an ordered table in key-value storage, or a collection of records with a linked field. Each record contains a root hash value, a timestamp, and possible auxiliary metadata; the continuity of the entire chain is reflected through the links between records. To maintain the integrity of the entire chain when adding a new record, the root hash value corresponding to the latest record needs to be retrieved from this training log chain. The system can maintain an index pointing to the tail record, for example, by keeping a copy of the latest root hash value in memory, or by finding the last record in persistent storage through reverse scanning or offset-based location, parsing the root hash field from the record, and using it as one of the inputs for the next round of computation.

[0061] The concatenation of the training digest and the root hash value is a crucial operation in constructing the data block to be hashed. These two data points need to be combined into a single input sequence at the byte level. To ensure consistent results across different operating environments, the training system can employ fixed encoding rules to convert both the training digest and the root hash value into standardized byte sequences, which are then concatenated in a pre-defined order. For example, the bytes of the training digest can be written first, followed by the bytes of the root hash value, or a separator can be added between them. Structural information, such as length fields, version markers, and chain identifiers, can be appended during the concatenation process for parsing the data structure during subsequent auditing. The resulting byte sequence after concatenation and structuring can be considered the data block to be hashed. Logically, this data block contains evidence of new training behavior and the previous log state, which are bound together to form a chain dependency.

[0062] The process of applying a hash function to the data block is responsible for generating a new root hash value. The hash function used here should still possess cryptographic one-wayness and collision resistance, and remain consistent throughout the log chain's lifecycle to avoid increasing verification complexity. In practice, the entire data block to be hashed can be fed into the hash algorithm engine, which outputs a fixed-length hash result, which is the new root hash value. The hash algorithm can be executed locally on the training node or handled by a dedicated log service component, as long as the input data block is not modified during network transmission. Semantically, the new root hash value represents the combination of the current training digest and the historical log chain state. Any change to the training digest or historical record will result in a change to the new root hash value, thus revealing traces of chain tampering during verification.

[0063] The current timestamp records the time information when a new log record is written. It can be expressed in milliseconds or seconds using system time, or in a unified time zone (UTC). When recording the timestamp, it can be encoded as a numeric field or a formatted string, with consistent parsing ensured through field conventions. Combining the new root hash value with the current timestamp to form a new log record allows for the addition of other metadata to the single record structure, such as training iteration cycle identifiers, training node identifiers, and configuration version identifiers. This ensures that the log record reflects chain integrity while providing context for supervision and auditing. When the log chain is updated, the new log record is appended to the tail of the chain without overwriting or rewriting existing records, thus maintaining its immutability. To prevent direct tampering with lower-level storage, pre-write verification, append-only file systems, or external trusted storage services can be used at the lower level to enhance the reliability of the log chain's immutability through the limitations of the storage layer itself.

[0064] Throughout the update process, the training summary, serving as evidence of the current training activity, participates in the construction of the data block to be hashed along with the historical root hash value. A new root hash value is then generated through hash operations, and finally, combined with time information, forms a new log record and is written into the training log chain. In this way, each log update superimposes a new round of summary evidence onto the previous state, creating a continuous sequence of the training log chain from the initial state to the current state in the time dimension. Any deletion, insertion, or modification at any stage will disrupt the correspondence of subsequent new root hash values, providing external verifiers with clear evidence for integrity checks.

[0065] This embodiment obtains the latest root hash value from the training log chain by accessing the training summary generated in the current training iteration cycle. The two are then concatenated under a unified encoding rule to form a data block to be hashed. A hash operation is performed on this data block to generate a new root hash value. This new root hash value is then combined with a timestamp to form a new log record, which is written to the log chain. This allows for a strong binding between each round of training behavior and the historical log state without exposing the training data content and model parameter details, enabling the training log to accumulate continuously in a chain structure. This ensures that any tampering, deletion, or replaying of training records will result in inconsistent chain hash results, while preserving the ability to distinguish between time sequences and training rounds. Therefore, it provides a highly reliable training process record for oversight and auditing within a privacy-preserving environment.

[0066] In one embodiment, step S503 includes: S5031, convert the training summary into a first byte sequence; S5032, convert the root hash value into a second byte sequence; S5033, the first byte sequence and the second byte sequence are connected in a preset order to generate a combined byte sequence; S5034, Add data length identifier information to the beginning of the combined byte sequence to generate a structured data block; S5035, the structured data block is used as the data block to be hashed.

[0067] In this embodiment, the process of concatenating the training summary with the root hash value aims to bind the summary information generated in the current training round with the previous log state in a stable byte representation, thereby providing a clearly structured and sequentially ordered input for subsequent hash operations. The training summary typically originates from the output of batch input data, model parameters, loss values, etc., after processing by a hash function, and is generally represented as a fixed-length bit string or hexadecimal string. To avoid ambiguity caused by differences in character encoding, the training summary needs to be converted into a first-byte sequence. A unified encoding method can be agreed upon during the conversion, for example, mapping the internal storage format uniformly to a single-byte array: if the training summary is stored as hexadecimal text, each two characters can be parsed into one byte; if the training summary already exists as a memory byte array, it is directly copied to a new buffer as the first-byte sequence. Through this process, the training summary is placed in a basic representation that behaves consistently across different operating environments, facilitating subsequent serialization and combination with other data.

[0068] The root hash value represents the chained state of the previous or latest log record. It is a compressed result of the entire past log chain and also needs to be converted into a second-byte sequence using a unified encoding method. The initial form of the root hash value may be an internal bit array or hexadecimal text. The system can use the same encoding strategy as the training digest to parse it or copy it to a new buffer, obtaining a second-byte sequence whose length is independent of the first-byte sequence but whose structure is well-defined. Through this symmetrical conversion method, the training digest and the root hash value are placed at the same representation level, avoiding parsing deviations caused by differences in string encoding, endianness, or character sets.

[0069] After obtaining the first and second byte sequences, they need to be concatenated in a preset order to generate a combined byte sequence. This preset order can be fixed during the design phase; for example, it can be agreed that the bytes for the training summary are written first, followed by the bytes for the root hash value, or vice versa, as long as it remains unchanged throughout the entire lifecycle. In the implementation, a contiguous buffer can be allocated for the combined byte sequence. The first byte sequence is copied sequentially to the first half, and then the second byte sequence is appended to the second half. To enhance parsing, the length of each part can be internally agreed to be fixed or deducible from subsequent structural information. By strictly fixing the concatenation order, the combined byte sequence not only contains the content of the current training round and the historical log state but also implicitly contains their order. This makes subsequent hash operations sensitive to the order; if the order is altered, the generated hash result will change.

[0070] After the combined byte sequence is formed, data length identifier information needs to be added to the front to generate a structured data block. The data length identifier information is used to clarify the boundaries of each part in the combined byte sequence; it can include the overall length or the length information of the first and second byte sequences. In implementation, a fixed-length integer byte representation can be used, encoding the length value as an unsigned integer and writing it to the beginning of the structured data block in a uniform byte order, followed by the combined byte sequence. In this way, the structured data block has a clearly defined length header and a continuous data body. Any reader can accurately segment the training summary fragment and the root hash value fragment based on the header length information. Even if expanded to multiple data segments in the future, more length fields and data segments can be appended to the same structure. After this processing, the structured data block becomes a self-describing sequence, avoiding the unclear boundary problems caused by simple concatenation.

[0071] After the length identifier is added, the structured data block is directly used as the data block to be hashed in subsequent hash operations. Logically, the data block to be hashed encompasses the entire content of the training digest and the root hash value, and its internal structure is fixed through the length identifier and a preset connection order, ensuring that the hash input contains both content information and implicit structural information. Whether in a single-node environment or a multi-node collaborative environment, as long as the same encoding and length encoding methods are used, the byte sequence of the data block to be hashed is completely determined, thus guaranteeing a consistent root hash result across different execution environments. Throughout the process, the training digest undergoes gradual compression from a high-level structure to a low-level byte representation, while the root hash value incorporates past log chain states into the current data block. Both are combined and length-marked within a unified structure, making the next hash processing a comprehensive summary of the complete chain state and the current training evidence.

[0072] This embodiment converts the training digest and root hash value into independent byte sequences, concatenates them in a fixed order using a unified encoding method, and adds a length identifier to the beginning of the combined byte sequence to generate a structured data block. This structured data block is then directly used as the data block to be hashed. This allows for the construction of a clearly structured, well-defined, and fixed-order input object before the hash operation. This avoids inconsistencies in hash results caused by differences in string encoding and byte order across different operating environments. Furthermore, by strictly binding the current training evidence to historical root hash values ​​through the length header and byte order, any insertion, deletion, or rearrangement of the digest and root hash values ​​will be reflected as bit-level changes in the data block to be hashed. This immediately reveals anomalies in the newly generated root hash value, improving the reliability and traceability of the training log chain in cross-system and cross-institutional verification scenarios.

[0073] In one embodiment, step S60 above includes: S601, Receive a verification request from the verification party through the verification interface, the verification request containing a unique identifier for a specific training iteration period; S602, based on the unique identifier, retrieve the corresponding target training summary and the preceding log record related to the target training summary from the immutable training log chain; S603, Extract the preceding root hash value from the preceding log record; S604, verify the hash link relationship between the target training summary and the preceding root hash value, and generate a verification result; S605, the verification result is returned to the verifier through the verification interface.

[0074] In this embodiment, the verification interface is the externally exposed interaction entry point, which can be a network interface based on Hypertext Transfer Protocol (HTTP), a Remote Procedure Call (RPC) interface, or an asynchronous access channel based on a message queue. The verification party is typically a regulatory agency, partner institution, or internal audit unit with review authority. It sends verification requests through the verification interface, and the request content is encapsulated in a structured data format. For example, it can use key-value pairs, carrying fields identifying the verification target in the request body, including a unique identifier for a specific training iteration cycle. This unique identifier is used to locate a single training iteration cycle in the training trajectory. It can originate from an incrementing number, timestamp combination, or random string generated by the training scheduling module during each iteration. The unique identifier is bound to the training summary during the training process, thus forming a one-to-one correspondence. Upon receiving the verification request, the verification interface extracts the unique identifier from the request message through a parameter parsing module, checking the format, length, and character set to prevent illegal input from interfering with subsequent retrieval.

[0075] An immutable training log chain is a chain-like data structure that sequentially records training process summary information. Each log record contains at least a training summary, a root hash value, and time information, and adjacent records are linked together using hash links. The log chain can be stored in a persistent database, distributed ledger, or dedicated immutable storage medium, and supports retrieval by unique identifiers through an index structure. In the current processing stage, a lookup operation is initiated in the index area of ​​the log chain based on the unique identifier of the training iteration cycle extracted from the verification request. The index area can use a key-value database, inverted index, or skip list structure to map the unique identifier to the target position in the log chain. After the query is completed, the log record corresponding to the training iteration cycle is retrieved from the log chain, and the target training summary is read from the record. To complete the hash link verification, it is also necessary to obtain the preceding log record related to the target training summary. The preceding log record is the record of the target training summary at the previous position on the chain, which can be located using a chain pointer, a preceding hash reference, or a sequential number. The data access module reads the preceding root hash value from the preceding log record and uses it as a compressed representation of the historical chain state.

[0076] The preceding root hash value is typically the output obtained by performing a hash function on the data block to be hashed during the previous round of updating the immutable training log chain. The storage format can be a binary array or a hexadecimal string. When extracting the preceding root hash value from the preceding log record, the encoding method must be completely consistent with the generation stage to avoid deviations in the verification results due to encoding differences. After extraction, the target training digest and the preceding root hash value are simultaneously sent to the hash linking verification module. The task of the hash linking verification module is to determine whether the target training digest can form a valid connection with the preceding root hash value in the chain structure. The verification process can be performed by replaying the chain update logic: on the one hand, constructing a data block to be hashed consistent with the chain update stage from the target training digest and the preceding root hash value, using the same byte sequence concatenation and length marking method as the log chain update stage; on the other hand, calling the same hash function to operate on this data block to obtain the calculated hash value. Subsequently, the calculated hash value is compared with the root hash value stored in the target log record. If the two values ​​are completely consistent, it means that the hash link relationship between the target training summary and the preceding root hash value is complete and has not been destroyed; if they are inconsistent, it can be determined that there are signs of insertion, replacement or tampering on the chain.

[0077] After the hash linking relationship verification is completed, a verification result is generated. The verification result is a structured output of this verification process, including at least the verification status and related metadata. The verification status can use a boolean value to indicate pass or fail, or a status code to mark multiple anomaly types, such as missing links, hash mismatch, or missing log records. Metadata may include a unique identifier for the training iteration cycle participating in the verification, the digest value of the target training summary, a truncation of the preceding root hash value, the verification time, and the verification strategy version. The result generation module organizes this information according to a predefined format, constructing a response message suitable for network transmission. Finally, the verification result is returned to the verifier through the verification interface. In a network interface scenario, a synchronous response message can be used; in a message queue scenario, a message can be sent to the response queue subscribed to by the verifier. During the return process, transport layer encryption and authentication mechanisms can be superimposed to prevent the verification result from being spied on or replaced during transmission, allowing external entities to verify the integrity and continuity of the training process without accessing sensitive data and internal model parameters.

[0078] This embodiment receives a verification request containing a unique identifier for the training iteration cycle through an access verification interface. It locates the target training summary and its preceding log records in the immutable training log chain, extracts the preceding root hash value from the preceding log records, and reconstructs the data block to be hashed according to the construction rules of the log chain update stage. It verifies the hash link relationship between the target training summary and the preceding root hash value, and then feeds back the structured verification results to the verification party through the same verification interface. This can provide external regulators or partners with an independently executable training process consistency verification capability without exposing sensitive data and internal model parameters. It improves the transparency and credibility of the model training process in cross-institutional audits, compliance checks, and multi-party collaboration scenarios, and promptly exposes the risk of tampering when log chain anomalies occur.

[0079] In one embodiment, a privacy-preserving data verification processing apparatus is provided, which corresponds one-to-one with the privacy-preserving data verification processing method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the privacy-protected data verification processing device of the present invention. The modules include a sensitive data acquisition module 10, a privacy-protected data generation module 20, a model training execution module 30, a training summary generation module 40, a training log chain update module 50, and a verification request response module 60. Detailed descriptions of each functional module are as follows: Sensitive data acquisition module 10 is used to acquire sensitive data to be processed; The privacy-protected data generation module 20 is used to load the sensitive data into the privacy-protected execution environment to obtain plaintext data within the environment, or to encrypt the sensitive data to obtain encrypted data. The model training execution module 30 is used to execute a model training process including multiple training iteration cycles based on plaintext data within the privacy-preserving execution environment or based on encrypted data in an encrypted domain. The training summary generation module 40 is used to extract training information corresponding to each training iteration cycle in the plurality of training iteration cycles during the model training process, and generate a training summary based on the training information. The training log chain update module 50 is used to update the immutable training log chain according to the training summary. The verification request response module 60 is used to respond to verification requests and provide the immutable training log chain.

[0080] In one embodiment, the privacy-preserving data generation module 20 is specifically used for: Based on a preset data processing strategy, determine whether to load the sensitive data into the privacy-preserving execution environment; If so, a secure communication channel is established with the privacy protection execution environment, and the sensitive data is transmitted to the privacy protection execution environment through the secure communication channel, and the sensitive data located inside the privacy protection execution environment is treated as plaintext data inside the environment; If not, select an encryption algorithm type and generate a data encryption key corresponding to the encryption algorithm type; The sensitive data is encrypted using the data encryption key and the selected encryption algorithm type to generate encrypted data.

[0081] In one embodiment, the model training execution module 30 is specifically used for: If execution is based on plaintext data within the environment, then within the privacy-preserving execution environment, the plaintext data within the environment is placed in a secure memory area; If execution is based on the encrypted data, then the encrypted data is input into the training engine and executed in the encrypted domain; Within the privacy-preserving execution environment or encrypted domain, initialize the model parameters; For each training iteration, the model loss is determined based on the current model parameters and the plaintext or encrypted data within the environment used. The gradient information of the model parameters is determined based on the model loss. The model parameters are updated using the gradient information.

[0082] In one embodiment, the training summary generation module 40 is specifically used for: During the model training process, the batch input data, current model parameters, and model loss value corresponding to the current training iteration cycle are obtained; The batch input data, current model parameters, and model loss values ​​are combined to form the training information set for the current training iteration cycle; The training information set is processed using a cryptographic hash function to generate a corresponding training digest; Associate the training summary with a unique identifier for the current training iteration cycle.

[0083] In one embodiment, the training log chain update module 50 is specifically used for: Get the training summary generated in the current training iteration cycle; Retrieve the root hash of the latest record from the immutable training log chain; The training summary is concatenated with the root hash value to generate a data block to be hashed. The data block to be hashed is processed by applying a hash function to generate a new root hash value; The new root hash value is combined with the current timestamp to form a new log record, which is then written into the immutable training log chain.

[0084] In one embodiment, the training log chain update module 50 is specifically used for: Convert the training summary into a first byte sequence; Convert the root hash value into a second byte sequence; The first byte sequence and the second byte sequence are concatenated in a preset order to generate a combined byte sequence; Add data length identifier information to the beginning of the combined byte sequence to generate a structured data block; The structured data block is used as the data block to be hashed.

[0085] In one embodiment, the verification request-response module 60 is specifically used for: The verification interface receives verification requests from the verification party, and the verification requests contain a unique identifier for a specific training iteration period. Based on the unique identifier, retrieve the corresponding target training summary and the preceding log records related to the target training summary from the immutable training log chain; Extract the preceding root hash value from the preceding log record; Verify the hash link relationship between the target training summary and the preceding root hash value, and generate verification results; The verification result is returned to the verifier through the verification interface.

[0086] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements a privacy-preserving data verification processing method on the server side, fulfilling its functions or steps.

[0087] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a privacy-preserving data verification processing method.

[0088] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Retrieve sensitive data to be processed; The sensitive data can be loaded into a privacy-preserving execution environment to obtain plaintext data within the environment, or the sensitive data can be encrypted to obtain encrypted data. Within the privacy-preserving execution environment, a model training process comprising multiple training iteration cycles is performed based on plaintext data within the environment, or based on encrypted data in an encrypted domain. During the model training process, for each of the plurality of training iteration cycles, the training information corresponding to the training iteration cycle is extracted, and a training summary is generated based on the training information. Update the immutable training log chain based on the training summary; In response to the verification request, provide the immutable training log chain.

[0089] In one embodiment, a non-volatile computer-readable storage medium is provided, which may be non-volatile or volatile, and stores a computer program thereon. When the computer program is executed by a processor, it performs the following steps: Retrieve sensitive data to be processed; The sensitive data can be loaded into a privacy-preserving execution environment to obtain plaintext data within the environment, or the sensitive data can be encrypted to obtain encrypted data. Within the privacy-preserving execution environment, a model training process comprising multiple training iteration cycles is performed based on plaintext data within the environment, or based on encrypted data in an encrypted domain. During the model training process, for each of the plurality of training iteration cycles, the training information corresponding to the training iteration cycle is extracted, and a training summary is generated based on the training information. Update the immutable training log chain based on the training summary; In response to the verification request, provide the immutable training log chain.

[0090] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0091] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0092] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

[0093] The user personal information involved in this application embodiment is all authorized (knowing and consenting) by the relevant parties or fully authorized by all parties, and the executing entity can obtain it through various open, legal and compliant means. The collection, storage, use, processing, transmission, provision and disclosure of the information, data and signals involved all comply with the relevant laws and regulations of the relevant countries and regions, and do not violate public order and good morals.

Claims

1. A privacy-preserving data verification processing method, characterized in that, Includes the following steps: Retrieve sensitive data to be processed; The sensitive data can be loaded into a privacy-preserving execution environment to obtain plaintext data within the environment, or the sensitive data can be encrypted to obtain encrypted data. Within the privacy-preserving execution environment, a model training process comprising multiple training iteration cycles is performed based on plaintext data within the environment, or based on encrypted data in an encrypted domain. During the model training process, for each of the plurality of training iteration cycles, the training information corresponding to the training iteration cycle is extracted, and a training summary is generated based on the training information. Update the immutable training log chain based on the training summary; In response to the verification request, provide the immutable training log chain.

2. The privacy-protected data verification processing method as described in claim 1, characterized in that, Loading the sensitive data into a privacy-preserving execution environment to obtain plaintext data within the environment, or encrypting the sensitive data to obtain encrypted data, including: Based on a preset data processing strategy, determine whether to load the sensitive data into the privacy-preserving execution environment; If so, a secure communication channel is established with the privacy protection execution environment, and the sensitive data is transmitted to the privacy protection execution environment through the secure communication channel, and the sensitive data located inside the privacy protection execution environment is treated as plaintext data inside the environment; If not, select an encryption algorithm type and generate a data encryption key corresponding to the encryption algorithm type; The sensitive data is encrypted using the data encryption key and the selected encryption algorithm type to generate encrypted data.

3. The privacy-protected data verification processing method as described in claim 1, characterized in that, Within the privacy-preserving execution environment, based on plaintext data within the environment, or based on encrypted data in an encrypted domain, a model training process comprising multiple training iteration cycles is executed, including: If execution is based on plaintext data within the environment, then within the privacy-preserving execution environment, the plaintext data within the environment is placed in a secure memory area; If execution is based on the encrypted data, then the encrypted data is input into the training engine and executed in the encrypted domain; Within the privacy-preserving execution environment or encrypted domain, initialize the model parameters; For each training iteration, the model loss is determined based on the current model parameters and the plaintext or encrypted data within the environment used. The gradient information of the model parameters is determined based on the model loss. The model parameters are updated using the gradient information.

4. The privacy-protected data verification processing method as described in claim 1, characterized in that, During the model training process, for each of the plurality of training iteration cycles, training information corresponding to the training iteration cycle is extracted, and a training summary is generated based on the training information, including: During the model training process, the batch input data, current model parameters, and model loss value corresponding to the current training iteration cycle are obtained; The batch input data, current model parameters, and model loss values ​​are combined to form the training information set for the current training iteration cycle; The training information set is processed using a cryptographic hash function to generate a corresponding training digest; Associate the training summary with a unique identifier for the current training iteration cycle.

5. The privacy-protected data verification processing method as described in claim 1, characterized in that, Based on the training summary, update the immutable training log chain, including: Get the training summary generated in the current training iteration cycle; Retrieve the root hash of the latest record from the immutable training log chain; The training summary is concatenated with the root hash value to generate a data block to be hashed. The data block to be hashed is processed by applying a hash function to generate a new root hash value; The new root hash value is combined with the current timestamp to form a new log record, which is then written into the immutable training log chain.

6. The privacy-protected data verification processing method as described in claim 5, characterized in that, The training summary and the root hash value are concatenated to generate a data block to be hashed, including: Convert the training summary into a first byte sequence; Convert the root hash value into a second byte sequence; The first byte sequence and the second byte sequence are concatenated in a preset order to generate a combined byte sequence; Add data length identifier information to the beginning of the combined byte sequence to generate a structured data block; The structured data block is used as the data block to be hashed.

7. The privacy-protected data verification processing method as described in claim 1, characterized in that, In response to the verification request, provide the immutable training log chain, including: The verification interface receives verification requests from the verification party, and the verification requests contain a unique identifier for a specific training iteration period. Based on the unique identifier, retrieve the corresponding target training summary and the preceding log records related to the target training summary from the immutable training log chain; Extract the preceding root hash value from the preceding log record; Verify the hash link relationship between the target training summary and the preceding root hash value, and generate verification results; The verification result is returned to the verifier through the verification interface.

8. A privacy-protected data verification processing device, characterized in that, The privacy-protected data verification processing device includes: The sensitive data acquisition module is used to acquire sensitive data to be processed. The privacy-preserving data generation module is used to load the sensitive data into the privacy-preserving execution environment to obtain plaintext data within the environment, or to encrypt the sensitive data to obtain encrypted data. The model training execution module is used to perform a model training process including multiple training iteration cycles, either within the privacy-preserving execution environment based on plaintext data within the environment or in an encrypted domain based on encrypted data. The training summary generation module is used to extract training information corresponding to each training iteration cycle in the plurality of training iteration cycles during the model training process, and generate a training summary based on the training information. The training log chain update module is used to update the immutable training log chain according to the training summary. The verification request response module is used to respond to verification requests and provide the immutable training log chain.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a privacy-protected data verification processing program stored in the memory and executable on the processor. When executed by the processor, the privacy-protected data verification processing program implements the steps of the privacy-protected data verification processing method as described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The storage medium stores a privacy-protected data verification processing program, which, when executed by a processor, implements the steps of the privacy-protected data verification processing method as described in any one of claims 1-7.

Images