Data provenance verification method in a trusted data space

Abstract

This application provides a data traceability verification method in a trusted data space, relating to the field of zero-knowledge proof technology. The method includes: collecting multiple operation records of target data in a trusted data space and arranging them in timestamp order to generate an operation sequence; converting these into state transition constraints; inputting the operation sequence into a pre-trained key node recognition model, outputting the position identifiers of one or more key state transition nodes in the operation sequence; constructing a zero-knowledge proof circuit based on the operation sequence, state transition constraints, and key state transition nodes, and running the zero-knowledge proof circuit to generate a composite zero-knowledge proof; providing the composite zero-knowledge proof as a data traceability credential for the target data to the verifier, completing the traceability verification of the entire target data processing process. This method solves the technical problems of privacy leakage risks and low verification efficiency in existing data traceability verification technologies.

Description

Technical Field

[0001] This invention relates to the field of zero-knowledge proofs, and more particularly to a data source tracing and verification method in a trusted data space. Background Technology

[0002] As the core carrier for ensuring the secure flow of data across entities and scenarios, the Trusted Data Space requires data to be traceable and compliant throughout its entire lifecycle, including collection, transmission, processing, and storage.

[0003] However, existing data traceability methods mostly rely on centralized log recording or blockchain evidence storage technology, which has the following drawbacks: First, centralized logs are easily tampered with, and the traceability verification process requires exposing the original data or the complete operation chain, which poses a risk of privacy leakage; Second, although blockchain evidence storage can guarantee immutability, it is inefficient in the end-to-end verification when faced with massive operation records, and it is difficult to dynamically adapt to data usage compliance rules; Third, traditional traceability methods lack the ability to accurately identify key operation nodes, resulting in redundancy in the verification process and an inability to quickly locate compliance risk points.

[0004] Meanwhile, zero-knowledge proof is a cryptographic technique that allows the prover to convince the verifier that the statement is true without revealing any information about the statement itself. This characteristic perfectly matches the need for both privacy protection and traceability verification in a trusted data space.

[0005] Therefore, there is an urgent need for a data traceability and verification method in a trusted data space, which can achieve efficient, accurate and compliant traceability throughout the entire data processing process while ensuring that data privacy is not compromised. Summary of the Invention

[0006] This invention addresses the technical problems of privacy leakage risks and low verification efficiency in existing data traceability verification technologies by providing a data traceability verification method in a trusted data space.

[0007] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0008] This invention provides a data source tracing and verification method in a trusted data space, comprising:

[0009] Multiple operation records generated during the continuous processing of target data in a trusted data space are collected, and the multiple operation records are arranged in order of timestamp to generate an operation sequence. The operation records include operation type, operation subject identity, data attributes, input data status identifier and output data status identifier.

[0010] The predefined data is transformed into state transition constraints to determine whether the state transition between adjacent operation records is legal using compliance rules.

[0011] The operation sequence is input into a pre-trained key node recognition model, which outputs the position identifiers of one or more key state transition nodes in the operation sequence.

[0012] Based on the operation sequence, the state transition constraints, and the key state transition nodes, a zero-knowledge proof circuit is constructed and run to generate a composite zero-knowledge proof.

[0013] The composite zero-knowledge proof is provided to the verifier as a data traceability certificate for the target data, thereby completing the traceability verification of the entire target data processing process.

[0014] The beneficial effects of this invention are:

[0015] Compared to existing technologies, this application first collects multiple operation records generated during the continuous processing of target data in a trusted data space, and arranges these operation records in timestamp order to generate an operation sequence, providing a traceable foundation for the data processing chain. Secondly, it transforms predefined data using compliance rules into state transition constraints to determine the legality of state transitions between adjacent operation records, achieving precise adaptation between compliance requirements and data state transition behavior. Thirdly, it inputs the operation sequence into a pre-trained key node identification model, outputting the location identifiers of one or more key state transition nodes in the operation sequence, avoiding the waste of resources in full-link redundant verification. Furthermore, based on the operation sequence, state transition constraints, and key state transition nodes, it constructs a zero-knowledge proof circuit and runs it to generate a composite zero-knowledge proof, solving the technical pain point of privacy exposure in traditional tracing verification. Finally, the composite zero-knowledge proof is provided to the verifier as a data traceability certificate for the target data, completing the traceability verification of the entire target data processing process. The verifier can quickly verify the compliance, integrity and immutability of the entire target data processing process without obtaining the original data and operation details, thus achieving a balance between privacy protection and efficient traceability verification.

[0016] Through the aforementioned technical solution, this application utilizes zero-knowledge proof technology, allowing the verifier to complete traceability verification without obtaining sensitive information such as original data or complete operation records. Verification can be completed solely through composite zero-knowledge proofs, thus protecting data privacy and trade secrets while ensuring the effectiveness of traceability. A key node identification model accurately identifies critical state transition nodes that play a decisive role in compliance determination, and a layered verification strategy avoids redundant verification across the entire chain, achieving a balance between verification efficiency and accuracy. This effectively addresses the prominent problems of traditional traceability methods, such as susceptibility to tampering, high privacy risks, low verification efficiency, and poor compliance adaptability, providing closed-loop technical support for the secure and reliable flow of data across entities and scenarios. Attached Figure Description

[0017] Figure 1 A flowchart illustrating a data tracing and verification method in a trusted data space provided by the present invention;

[0018] Figure 2 This is a flowchart illustrating the second circuit logic design in a data tracing and verification method in a trusted data space provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] In the description of this invention, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this invention is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.

[0022] Examples, such as Figure 1 As shown, this embodiment of the invention provides a data source tracing and verification method in a trusted data space, including:

[0023] S10: Collect multiple operation records generated during the continuous processing of target data in a trusted data space, and arrange the multiple operation records in the order of timestamps to generate an operation sequence. The operation records include operation type, operation subject identity, data attributes, input data status identifier and output data status identifier.

[0024] In a trusted data space, target data needs to be processed continuously by multiple entities and through multiple stages. Various operation records are stored in a scattered manner and are prone to breakage of the traceability link due to disordered processing time. The premise of data traceability verification is to restore the complete timeline and logical relationship of data processing. Therefore, it is necessary to collect the operation records of the entire process and generate an operation sequence by sorting them by timestamp to provide structured and orderly basic data support for subsequent compliance verification, state transition tracing and tamper detection.

[0025] To address the aforementioned issues, this application collects multiple operation records generated during the continuous processing of target data in a trusted data space, and arranges these multiple operation records in order of timestamps to generate an operation sequence.

[0026] Specifically, step S10 in the method includes:

[0027] Extract multiple operation records corresponding to the target data from the data processing log;

[0028] The operation type, operation subject identity, data attributes, input data status identifier and output data status identifier are parsed from the operation record. The input data status identifier includes the input data content hash value, the input operation serial number and the input timestamp. The output data status identifier includes the output data content hash value, the output operation serial number and the output timestamp.

[0029] Based on the timestamp order and the correlation between the input operation serial number and the output operation serial number, the multiple operation records are concatenated to form the operation sequence.

[0030] In this embodiment, multiple operation records corresponding to the target data are first extracted from the data processing log. Specifically, each data processing node in the trusted data space records its operation behavior in real time, forming a data processing log. The data processing log contains processing records for all data. Therefore, it is necessary to filter out operation records related to the target data from the data processing log based on the unique identifier of the target data, such as data ID or data hash value, to ensure the relevance of the extraction results.

[0031] For example, based on the data processing logs of the trusted data space, a unique identifier of the target data can be input to trigger a log filtering mechanism, which can then filter out all operation records containing that identifier, thus preventing irrelevant records from interfering with subsequent processing.

[0032] Secondly, since the original format of operation records may be structured logs or semi-structured text, it is necessary to parse the operation type, operator identity, data attributes, input data status identifiers, and output data status identifiers from the operation records. The operation type refers to the specific category of data processing behavior, such as data acquisition, data cleaning, data encryption, data query, and data transmission. The operator identity refers to the unique identifier of the entity performing the operation, such as a company ID, user account, or device number, used to verify the legitimacy of the operator. Data attributes refer to information such as the category, sensitivity level, and domain of the target data, such as medical records in medical data or transaction logs in financial data.

[0033] The input data status identifier includes the input data content hash value, the input operation sequence number, and the input timestamp. The output data status identifier includes the output data content hash value, the output operation sequence number, and the output timestamp. Specifically, the input data content hash value is a unique value obtained by hashing the target data content before the operation is executed, used to uniquely identify the state of the input data and prevent data tampering; the input operation sequence number is a globally unique number of this input operation in the trusted data space, used to associate previous and subsequent operations; the input timestamp is the precise time of operation execution, such as being accurate to the millisecond level, used to determine the time sequence of operations; the output data status identifier includes the output data content hash value, the output operation sequence number, and the output timestamp, whose definition corresponds to the input data status identifier, used to identify the state of the target data after the operation is executed.

[0034] For example, if the target data is a set of enterprise customer order data, after encryption, the input data content hash value is the hash value of the original order data calculated by the SHA-256 algorithm, such as e3b0c34298fc1c149afbf4c825426fb92427…, and the output data content hash value is the SHA-256 hash value of the encrypted order data, such as 7c211433f020715977487337859d83f6…, the input operation serial number is OP-20230521-0036, the output operation serial number is OP-20230521-0037, the input timestamp is May 21, 2023, 09:43:12.531, and the output timestamp is May 21, 2023, 09:45:18.672.

[0035] Finally, based on the timestamp order and the correlation between input and output operation serial numbers, multiple operation records are concatenated to form an operation sequence. Specifically, multiple operation records are naturally related through their input and output operation serial numbers. Typically, the output operation serial number of the preceding operation record becomes the input operation serial number of the following operation record. For example, if the output operation serial number of operation A is OP-20230521-0002 and the input operation serial number of operation B is OP-20230521-0002, then operation B is processing based on the output data of operation A. Sorting the operation records according to timestamp order ensures the temporal consistency of the operation sequence; concatenating them through the correlation between input and output operation serial numbers ensures the logical continuity of the operation sequence, preventing broken links or disordered sequences.

[0036] For example, firstly, all parsed operation records are sorted in order of timestamp from earliest to latest. Then, the sorted records are traversed, and the output operation serial number of the previous record is matched with the input operation serial number of the next record. If the match is successful, an association is established, and finally a complete and ordered operation sequence is formed.

[0037] In summary, compared to existing technologies, this application collects multiple operation records generated during the continuous processing of target data in a trusted data space, and arranges these operation records in timestamp order to generate an operation sequence. This allows for the complete collection of all processing operation records of target data in the trusted data space, and the construction of an ordered operation sequence through timestamp sorting provides logically coherent and temporally clear foundational data support for subsequent state transition verification, compliance determination, and data tampering detection.

[0038] S20: Transform predefined data into state transition constraints to determine whether the state transition between adjacent operation records is legal, using compliance rules.

[0039] In scenarios where data flows across entities and multiple stages in a trusted data space, predefined data usage compliance rules often exist in unstructured forms such as natural language, industry standards, or contract terms. These rules lack computability and machine readability, and cannot be directly used to determine the legality of state transitions between adjacent operation records during data processing. However, compliance verification is a core requirement for ensuring the secure flow of data. Therefore, these rules need to be transformed into structured and logically clear state transition constraints to provide a unified standard and executable basis for automated and accurate determination of the legality of state transitions.

[0040] To address the aforementioned issues, this application transforms predefined data usage compliance rules into state transition constraints used to determine whether state transitions between adjacent operation records are legal.

[0041] Specifically, step S20 in the method includes:

[0042] Obtain a predefined data use compliance rule library, and match and load an applicable set of data use compliance rules from the data use compliance rule library based on the data attributes of the target data and the processing context in the operation sequence;

[0043] The data is expressed using each rule in the compliance rule set, and formal logic language is used to convert the rules described in natural language or policy language into computable logical expressions containing preconditions and conclusions.

[0044] For each pair of adjacent operation records in the operation sequence, the output data status identifier of the previous operation record is taken as the premise state, and the input data status identifier and operation type of the next operation record are taken as the state and operation to be verified, thus forming a state transition pair.

[0045] The computable logical expression is instantiated as a state transition constraint for the state transition pair.

[0046] In this embodiment, a predefined data usage compliance rule library is first obtained. Then, based on the data attributes of the target data and the processing context in the operation sequence, an applicable set of data usage compliance rules is matched and loaded from the data usage compliance rule library. Specifically, the data usage compliance rule library is a centralized storage medium for various types of data usage compliance rules, including general regulatory rules, industry-specific rules, and data provider-defined rules. Furthermore, different types of target data have different compliance requirements, and the compliance rules for the same target data may also differ in different processing scenarios. Therefore, rule matching is required based on the data attributes of the target data and the processing context in the operation sequence, such as sensitivity level, domain, type of operating entity, and processing scenario.

[0047] For example, the query indexing mechanism of the data usage compliance rule base can be used to input data attribute keywords and processing context keywords, such as enterprise data, sensitivity level, cross-organizational transmission, data anonymization, etc., to filter out rules applicable to the current scenario from the predefined data usage compliance rule base and form a set of data usage compliance rules.

[0048] Secondly, each rule in the data usage compliance rule set is expressed using a formal logic language, transforming the rules described in natural language or policy language into computable logical expressions containing preconditions and conclusions. Formal logic languages ​​are characterized by precision and unambiguity; examples include first-order predicate logic and linear sequential logic. In contrast, compliance rules described in natural language or policy language are ambiguous and cannot be directly used for automated machine verification; therefore, they require standardized expression using formal logic languages. Specifically, for each rule in the data usage compliance rule set, its core logic is first broken down to clarify the preconditions and conclusions, and then it is transformed into a computable logical expression using a formal logic language.

[0049] For example, if a natural language rule in the data compliance rule set is: medical data with a high sensitivity level is only allowed to be queried by medical institutions with Class A qualifications, it can be transformed into a first-order predicate logic expression using formal logic language: ∀x(medical data(x)∧sensitivity level(x,high)∧operation type(x,query)→qualification(operation subject(x),Class A)), where x represents the processing behavior corresponding to the operation record.

[0050] Furthermore, adjacent operation records in the operation sequence correspond to one data state transition. The output data of the previous operation is the input data of the next operation. Therefore, for each pair of adjacent operation records in the operation sequence, the output data state identifier of the previous operation record is used as the premise state, and the input data state identifier and operation type of the next operation record are used as the state and operation to be verified, forming a state transition pair. For example, if the i-th operation record in the operation sequence is denoted as OP... i And the (i+1)th operation record, denoted as OP. i+1 OP i The output data status identifier is Sout_i, OP i+1 If the input data state identifier is Sin_i+1 and the operation type is T_i+1, then the state transition pair consisting of the i-th operation record and the i+1-th operation record is: (Sout_i, Sin_i+1, T_i+1). This triple completely describes the transition process from state Sout_i to state Sin_i+1 and the corresponding operation behavior.

[0051] Finally, the computable logical expression is instantiated into state transition constraints for the state transition pair. This is because the computable logical expression is a generalized rule representation, which needs to be instantiated in conjunction with a specific state transition pair to form directly verifiable constraints. Specifically, the output data state identifier, input data state identifier, and operation type in the state transition pair are substituted into the corresponding variable positions in the computable logical expression, replacing the general variables, to obtain the specific constraints for that state transition pair.

[0052] For example, substituting the logical expression into the state transition pair (Sout_i, Sin_i+1, T_i+1), we get (Sout_1, Sin_2, query), where the target data corresponding to Sout_1 is medical data and the sensitivity level is high. Then the instantiated state transition constraint is: Medical data (OP1) ∧ Sensitivity level (OP1, high) ∧ Operation type (OP2, query) → Qualification (Operation subject (OP2), Grade A). This state transition constraint is used to determine whether the state transition from OP1 to OP2 conforms to the preset rules.

[0053] Specifically, the construction process of the "data usage compliance rule base" includes:

[0054] Define the storage structure and data schema of the data use compliance rule base, wherein the storage structure is used to store the data use compliance rules, and the data schema is used to describe the scope of application, the objects of constraint, and the logical content of the data use compliance rules;

[0055] Collect compliance rules for data use from the data provider's policy documents, data processing contracts, and domain regulatory documents;

[0056] The data is parsed, classified, and standardized according to the data pattern using compliance rule text to generate structured rule data;

[0057] The structured rule data is stored in the data usage compliance rule base, and a query index mechanism based on data attributes is established for the data usage compliance rule base.

[0058] In this embodiment, the storage structure and data schema of the data usage compliance rule base are first defined. The storage structure stores the data usage compliance rules, and the data schema describes the scope of application, constraints, and logical content of the data usage compliance rules. Specifically, the storage structure can be implemented using a distributed database, such as HBase, which supports horizontal scaling and high-concurrency queries for massive numbers of rules. The data schema must include fields such as rule ID, applicable data type, applicable operation type, sensitivity level adaptation range, precondition description, conclusion description, rule source, and effective time. The rule ID is a unique identifier for each rule and is used for rule creation, deletion, modification, and query management.

[0059] Secondly, collect data usage compliance rules from the data provider's policy documents, data processing contracts, and industry regulatory documents. The data provider's policy documents are customized rules based on their own business needs; for example, a company might stipulate that order data can only be accessed by its own employees. Data processing contracts are legally binding agreements between the data provider and the processor, clearly defining the specific requirements for data use. Industry regulatory documents include laws, regulations, and industry standards. During the collection process, the rule texts must be deduplicated to avoid duplicate rules that could lead to verification logic conflicts.

[0060] Next, the data is parsed, classified, and standardized according to the data pattern using compliance rule text to generate structured rule data. Specifically, the rule text is unstructured or semi-structured data, which needs to be parsed according to a preset data pattern to extract key information and fill it into the corresponding fields. The parsing process can be combined with natural language processing technologies, such as keyword extraction and semantic analysis, to achieve automated parsing. For ambiguous or unclear rule text, manual confirmation can be used. Classification processing refers to classifying the rules according to dimensions such as applicable data type and sensitivity level to facilitate rapid matching later. Standardization processing refers to standardizing the parsed information according to a unified format. For example, sensitivity levels are uniformly divided into high, medium, and low levels, and operation types uniformly adopt standard terms such as collection, cleaning, encryption, query, transmission, and deletion to ensure the consistency of the rules.

[0061] For example, the compliance rule text for a certain data is: Financial transaction data shall not be transmitted to overseas servers. The structured rule data generated after parsing, classification and standardization is: Rule ID=R001, Applicable data type=Financial transaction data, Applicable operation type=Transmission, Sensitivity level coverage=All levels, Precondition description=None, Conclusion description=Transmission destination ≠ Overseas server, Effective time=2024-01-01.

[0062] Finally, the structured rule data is stored in a data usage compliance rule base, and a query index mechanism based on data attributes is established for this base. This data attribute-based query index mechanism aims to improve rule matching efficiency. Query index keywords can include core attributes such as data type, sensitivity level, and operation type. Specifically, an inverted index technique can be used to create a corresponding list of rule IDs for each data attribute keyword. This serves as the query index mechanism, allowing for quick location of the corresponding rule set by the data attribute keyword when rule matching is needed, avoiding a full database scan.

[0063] For example, a query index is created for the keyword "medical data" of the data attribute, and all applicable rule IDs of the data type "medical data" are associated with it. When querying, relevant rules can be quickly extracted by simply using the keyword index of the data attribute, thus improving the speed of rule matching.

[0064] In summary, compared to existing technologies, this application transforms predefined data usage compliance rules into state transition constraints used to determine the legality of state transitions between adjacent operation records. In this way, unstructured predefined data usage compliance rules are transformed into structured, computable state transition constraints, achieving a precise mapping between compliance requirements and data processing state transition behaviors. This provides a unified and clear execution basis for automatically determining the legality of state transitions between adjacent operation records.

[0065] S30: Input the operation sequence into the pre-trained key node recognition model and output the position identifiers of one or more key state transition nodes in the operation sequence.

[0066] In the entire data processing process of the trusted data space, the operation sequence often contains a large number of state transition nodes. If all nodes are fully verified with the same intensity, it will lead to redundancy, excessive resource consumption and low efficiency in the verification process. The impact of different nodes on the data compliance judgment varies significantly. The compliance of key state transition nodes directly determines the legality of the entire data processing chain. Therefore, it is necessary to rely on a pre-trained key node identification model to accurately locate key state transition nodes from the operation sequence, so as to provide the core basis for the implementation of subsequent hierarchical verification strategies, and to balance verification efficiency and judgment accuracy.

[0067] To address the aforementioned issues, this application inputs the operation sequence into a pre-trained key node recognition model and outputs the location identifiers of one or more key state transition nodes in the operation sequence.

[0068] Specifically, step S30 in the method includes:

[0069] Call the pre-trained key node recognition model;

[0070] The operation sequence is input into the key node identification model to analyze the state transition patterns and compliance risks between adjacent operation records in the operation sequence, and outputs the location identifiers of one or more key state transition nodes that have the highest impact on the compliance determination of the operation sequence.

[0071] In this embodiment, a pre-trained key node recognition model is first invoked. This key node recognition model is an intelligent recognition model trained on a large amount of historical data and deployed in the AI ​​inference module of the trusted data space, possessing the ability to rapidly process operation sequences. The invocation process can be implemented through the trusted data space interface; only the data format identifier of the operation sequence, such as JSON format, needs to be input to trigger the key node recognition model invocation.

[0072] Secondly, the operation sequence is input into the critical node identification model. The model analyzes the state transition patterns and compliance risks between adjacent operation records in the sequence, and outputs the location identifiers of one or more critical state transition nodes that have the highest impact on the compliance determination of the operation sequence. The critical node identification model operates by analyzing state transition patterns and compliance risks, quantifying the impact weight of each state transition node on overall compliance, and identifying nodes with weights exceeding a preset threshold as critical state transition nodes.

[0073] Specifically, the key node identification model first extracts the features of each state transition node in the operation sequence, such as operation type, operation subject identity, and data state change magnitude; then, based on the correlation between the features learned during pre-training and compliance risks, it calculates the compliance risk coefficient and impact weight of each state transition node; finally, it selects the N nodes with the highest impact weights and outputs their position identifiers in the operation sequence.

[0074] For example, state transition nodes in the operation sequence that involve the cross-agency transmission of highly sensitive data have a high compliance risk coefficient and significant impact weight, and are identified as key state transition nodes. The location identifier is: node number 5, timestamp: 2024-05-20 15:40:30-2024-05-20 15:40:35.

[0075] Furthermore, the training process of the "key node identification model" includes:

[0076] Obtain historical operation sequences from the trusted data space to form a sample training dataset;

[0077] Obtain the labels of the key state transition nodes corresponding to each historical operation sequence in the sample training dataset to form a sample labeled dataset;

[0078] A key node identification model is constructed based on an attention-based neural network.

[0079] The key node recognition model is trained using the sample training dataset and the sample annotation dataset until the verification convergence, thus obtaining the trained key node recognition model.

[0080] In this embodiment, historical operation sequences from the trusted data space are first obtained to form a sample training dataset. Specifically, historical operation sequences from different domains, data types, and processing scenarios are extracted from the historical log database of the trusted data space. Each historical operation sequence must contain the same complete field information as in step S10.

[0081] Secondly, labels are obtained for each historical operation sequence in the sample training dataset, corresponding to the labeled key state transition nodes, forming the sample labeled dataset. Specifically, the labeling process can employ manual labeling or machine-assisted labeling to ensure the accuracy of the labeling results. For example, firstly, domain experts label the key state transition nodes in each historical operation sequence based on compliance rules and business experience, clarifying the node's location identifier and key type; then, machine-assisted tools, such as label consistency checking tools, are used to verify the labeling results, eliminating incorrectly labeled or inconsistent samples, ultimately forming the sample labeled dataset.

[0082] Furthermore, a key node identification model is constructed based on an attention-based neural network. Specifically, the attention-based neural network can automatically focus on features in the operation sequence that have a significant impact on the result, making it suitable for key node identification tasks.

[0083] For example, a key node identification model is constructed based on an attention-based neural network. This model mainly consists of an input layer, an embedding layer, an attention layer, a fully connected layer, and an output layer. The input layer receives feature vectors derived from the fields of the operation records for the operation sequence. The embedding layer transforms discrete features, such as operation type and operator identity, into low-dimensional, dense, continuous vectors. The attention layer adaptively highlights the key features that significantly impact compliance judgment by calculating the attention weights of each feature in the state transition node identification task. The fully connected layer uses a multilayer perceptron structure to perform nonlinear transformations and high-order feature extraction on the attention-weighted fused features. The output layer uses a sigmoid activation function to output the probability value of each state transition node being a key node, used to determine whether each state transition node is a key node.

[0084] Finally, the key node recognition model is trained using the sample training dataset and the sample annotation dataset until the validation convergence, resulting in a trained key node recognition model. For example, the key node recognition model can be trained using the following technical path: 1. Data preparation: Using a random hierarchical partitioning strategy, the sample training dataset and the sample annotation dataset are split into training and validation sets in a 7:3 ratio. 2. Model Training: First, configure the core hyperparameters of the key node recognition model, including a learning rate of 0.001, batch size of 32, number of iterations of 100, and weight decay coefficient of 0.0001. The hyperparameter settings must balance training efficiency and model convergence. Then, input the training set into the key node recognition model in batches to start the training process. Use the cross-entropy loss function as the optimization objective to calculate the error between the model's output node classification prediction results and the sample labels. Update the model weights and bias parameters layer by layer through the backpropagation algorithm. After each iteration of training, use the validation set to quantitatively evaluate the model's core performance indicators, such as accuracy, recall, and F1 score. When the core performance indicators on the validation set show no significant improvement for 10 consecutive iterations, and the accuracy is not lower than 95% and the recall is not lower than 90%, the model training is considered to have reached convergence. Training is then stopped, and the current optimal model parameters are saved, resulting in the trained key node recognition model.

[0085] In summary, compared to existing technologies, this application inputs the operation sequence into a pre-trained key node identification model and outputs the location identifiers of one or more key state transition nodes in the operation sequence. Thus, the pre-trained key node identification model accurately locates the key state transition nodes that play a decisive role in compliance determination from the operation sequence and outputs their location identifiers, providing a basis for subsequent layered verification strategies, effectively reducing redundant verification, and balancing the efficiency and accuracy of traceability verification.

[0086] S40: Based on the operation sequence, the state transition constraints, and the key state transition nodes, construct a zero-knowledge proof circuit and run the zero-knowledge proof circuit to generate a composite zero-knowledge proof.

[0087] In data traceability and verification in a trusted data space, it is necessary to ensure the compliance and verifiability of the entire data processing process, while avoiding the leakage of sensitive information such as raw data and operational details. At the same time, it is necessary to adapt to a layered strategy of strict verification of key nodes and lightweight verification of non-key nodes.

[0088] However, traditional verification methods struggle to balance privacy protection, verification efficiency, and the accuracy of compliance determination. Therefore, it is necessary to construct a zero-knowledge proof circuit that integrates layered verification logic based on the generated operation sequence, state transition constraints, and key state transition nodes. Through the operation of the circuit, the compliance verification results of the entire process can be transformed into a composite zero-knowledge proof that does not leak privacy.

[0089] To address the aforementioned issues, this application constructs a zero-knowledge proof circuit based on the operation sequence, the state transition constraints, and the key state transition nodes, and runs the zero-knowledge proof circuit to generate a composite zero-knowledge proof.

[0090] Specifically, step S40 in the method includes:

[0091] Based on the operation sequence, the state transition constraints, and the location identifiers of the key state transition nodes, a zero-knowledge proof circuit is designed.

[0092] Based on the location identifier of the critical state transition node, all state transition nodes in the operation sequence are divided into critical state transition nodes and non-critical state transition nodes.

[0093] For each critical state transition node, based on the corresponding state transition constraints, a first circuit logic is designed to verify, during the operation of the zero-knowledge proof circuit, whether the identity of the operating subject at the critical state transition node is authorized, and whether the data state represented by the output data state identifier of the previous operation record satisfies the preconditions for executing the current operation.

[0094] For each non-critical state transition node, a second circuit logic is designed to verify the hash continuity between the data state identifiers of the operation records before and after the non-critical state transition node during the operation of the zero-knowledge proof circuit.

[0095] The first and second circuit logics designed for all nodes are combined according to the order of state transition nodes in the operation sequence to complete the construction of the zero-knowledge proof circuit.

[0096] In this embodiment, a zero-knowledge proof circuit is first designed based on the operation sequence, state transition constraints, and the location identifiers of key state transition nodes. Specifically, the design of the zero-knowledge proof circuit needs to balance the integrity of the verification logic and computational efficiency. A modular design approach can be adopted, dividing the circuit into an input module, a key node verification module, a non-key node verification module, and an output module. The input module is responsible for receiving computational parameters, such as the operation sequence, state transition constraints, and key node location identifiers, and performing format conversion. The key node verification module and the non-key node verification module correspond to different verification logics. The output module is responsible for integrating the verification results and generating the proof. Simultaneously, the design of the zero-knowledge proof circuit must comply with the security requirements of zero-knowledge proofs, ensuring that the circuit logic does not leak any private information, while also meeting the requirement of controllable computational complexity to avoid low proof generation efficiency due to excessive circuit complexity.

[0097] Secondly, based on the location identifiers of key state transition nodes, all state transition nodes in the operation sequence are divided into key state transition nodes and non-key state transition nodes. The division process is based on the location identifiers output by the key node identification model. It iterates through all state transition nodes in the operation sequence, classifying nodes whose location identifiers match those output by the key node identification model as key state transition nodes, and classifying the remaining nodes as non-key state transition nodes. This enables hierarchical verification and improves overall verification efficiency.

[0098] Furthermore, for each critical state transition node, based on the corresponding state transition constraints, a first circuit logic is designed to verify, during the operation of the zero-knowledge proof circuit, whether the operator's identity at the critical state transition node is authorized, and whether the data state represented by the output data state identifier of the previous operation record meets the prerequisites for executing the current operation. Specifically, the compliance of the critical state transition node directly determines the compliance of the entire data processing chain; therefore, the first circuit logic needs to implement dual verification: operator identity authorization verification and prerequisite data state compliance verification.

[0099] For example, whether the operator's identity is authorized can be determined by verifying whether the operator's identity identifier matches the authorization list in the trusted data space, thus determining whether the operator has the authority to execute the current operation; whether the data status meets the prerequisites for executing the current operation can be determined by verifying whether the output data status identifier of the previous operation meets the prerequisite requirements in the state transition constraints, thus determining whether the input data of the current operation is valid.

[0100] For example, for critical state transition nodes in the cross-organizational transmission of highly sensitive data, the first circuit logic first verifies whether the identity of the operating entity is in the authorized transmission list, and then verifies whether the data state meets the preconditions for executing the current operation by judging whether the hash value in the output data status identifier matches the hash value of the encrypted data.

[0101] Furthermore, for each non-critical state transition node, a second circuit logic is designed to verify the hash continuity between the data state identifiers of the operation records before and after the non-critical state transition node during the operation of the zero-knowledge proof circuit. The verification requirement for non-critical state transition nodes is to ensure that the data state has not been tampered with; therefore, the second circuit logic focuses on hash continuity verification. Hash continuity means that the hash value of the output data content of the previous operation is equal to the hash value of the input data content of the next operation. If they are not equal, it indicates that the data has been tampered with during transmission or processing.

[0102] Finally, the first and second circuit logics designed for all nodes are combined according to the order of state transition nodes in the operation sequence to complete the construction of the zero-knowledge proof circuit. Specifically, the combination of the zero-knowledge proof circuit must follow the chronological order of the operation sequence to ensure consistency between the verification process and the data processing process. For example, the first or second circuit logic corresponding to each node can be chained together according to the order of the nodes in the operation sequence, with the verification result of the previous node serving as one of the input parameters for the next node, forming a complete verification chain. The combined zero-knowledge proof circuit can verify the compliance and continuity of each state transition node sequentially, ensuring the integrity and uninterrupted nature of the verification logic throughout the entire data processing chain. After the zero-knowledge proof circuit is constructed, it can be further validated using formal verification tools, such as ZK-Circuit Verifier, to ensure there are no logical errors or security vulnerabilities.

[0103] Specifically, such as Figure 2 As shown, the "second circuit logic designed for each non-critical state transition node to verify the hash continuity between the data state identifiers of the operation records before and after the non-critical state transition node during the operation of the zero-knowledge proof circuit" includes:

[0104] The first computational logic of the zero-knowledge proof circuit during operation is designed to calculate the hash value of the output data content contained in the output data status identifier of the previous operation record, as the first hash value.

[0105] The zero-knowledge proof circuit is designed with a second computational logic during operation to calculate the hash value of the input data content contained in the input data status identifier of the next operation record, as the second hash value.

[0106] The zero-knowledge proof circuit is designed to perform verification logic during operation to determine whether the first hash value and the second hash value are equal.

[0107] The first calculation logic, the second calculation logic, and the verification logic are combined to form a second circuit logic for verifying hash continuity.

[0108] In this embodiment, the first computational logic of the zero-knowledge proof circuit during operation is designed to calculate the hash value of the output data content contained in the output data status identifier of the previous operation record, which is used as the first hash value. The first computational logic can be implemented using a cryptographically secure hash algorithm to ensure the uniqueness and collision resistance of the hash value. Specifically, the first computational logic extracts the original data corresponding to the hash value of the output data content in the output data status identifier of the previous operation record from the input operation sequence, i.e., the target data content after the operation. Then, it uses a preset hash algorithm, such as SHA-256 or Keccak-256, to perform a hash operation on the original data to obtain the first hash value. Simultaneously, to ensure the security of the computation process, the original data is transmitted in encrypted form within the zero-knowledge proof circuit, and the hash operation is performed in a zero-knowledge environment, without revealing the original data content.

[0109] Secondly, a second computational logic is designed for the zero-knowledge proof circuit during operation. This logic calculates the hash value of the input data content contained in the input data status identifier of the subsequent operation record, serving as the second hash value. The design of this second computational logic is consistent with the first logic, ensuring the uniformity of the hash algorithm and the comparability of the calculation results. Specifically, the second computational logic extracts the original data corresponding to the hash value of the input data content in the input data status identifier of the subsequent operation record—that is, the target data content before the operation—and performs a hash operation using the same hash algorithm as the first logic to obtain the second hash value. If the target data before and after the operations has not been tampered with, the second hash value should be completely consistent with the first hash value.

[0110] Next, the verification logic of the zero-knowledge proof circuit during runtime is designed to determine whether the first hash value and the second hash value are equal. This verification logic can be implemented using an equality check circuit. It compares each bit of the first and second hash values ​​to see if they are the same. For example, the equality check circuit performs an XOR operation on each bit of the first and second hash values. If all XOR results are 0, the two hash values ​​are equal, and the verification passes. If there is a bit with an XOR result of 1, the hash values ​​are not equal, and the verification fails. The equality check circuit has low computational complexity, can quickly complete hash continuity verification, and is suitable for lightweight verification requirements of non-critical nodes.

[0111] Finally, the first calculation logic, the second calculation logic, and the verification logic are combined to form the second circuit logic for verifying hash continuity. The combination process can employ parallel computation and serial verification to improve circuit efficiency. Specifically, the first and second calculation logics are executed in parallel, simultaneously calculating the first and second hash values ​​to reduce computation time. After the two hash values ​​are calculated, the verification logic is executed serially to compare the two hash values. The combined second circuit logic can quickly complete the hash continuity verification of non-critical nodes, ensuring that the data state has not been tampered with, without adding excessive computational overhead.

[0112] Furthermore, the phrase "running the zero-knowledge proof circuit to generate a composite zero-knowledge proof" includes:

[0113] Input computational parameters into the constructed zero-knowledge proof circuit, wherein the computational parameters include the operation sequence, the state transition constraints, and the position identifiers of the key state transition nodes;

[0114] The zero-knowledge proof circuit is triggered to run, and the first circuit logic and the second circuit logic are executed sequentially to generate the corresponding verification result.

[0115] The verification result is cryptographically compiled to generate a composite zero-knowledge proof.

[0116] In this embodiment, computational parameters are first input into the constructed zero-knowledge proof circuit. These parameters include an operation sequence, state transition constraints, and location identifiers of key state transition nodes. The operation sequence contains complete information for all fields, the state transition constraints are instantiated computable logical expressions, and the location identifiers of key state transition nodes are explicit node numbers or timestamp ranges. The input of these computational parameters can be encrypted and transmitted to the circuit input module via a secure channel in a trusted data space to prevent the parameters from being stolen or tampered with.

[0117] Secondly, the zero-knowledge proof circuit is triggered to run, sequentially executing the first and second circuit logics to generate corresponding verification results. Specifically, the zero-knowledge proof circuit executes according to the order of nodes in the operation sequence. First, it reads the position identifier of the state transition node and determines the current node type. If it is a critical state transition node, the first circuit logic is executed to verify the compliance of the operation subject's identity authorization status and the premise data status, generating a first verification result of pass or fail. If it is a non-critical state transition node, the second circuit logic is executed to verify hash continuity, generating a second verification result of pass or fail. After all nodes have been verified, all first and second verification results are integrated to form an overall verification result. If even one node fails to verify, the overall verification result is a failure.

[0118] Finally, the verification result is cryptographically compiled to generate a composite zero-knowledge proof. The cryptographic compilation process can be implemented using mainstream zero-knowledge proof protocols, such as ZK-SNARKs and ZK-STARKs, transforming the overall verification result into a compact and rapidly verifiable composite zero-knowledge proof. Specifically, first, the verification result is converted into a cryptographic commitment to ensure its immutability; then, based on the zero-knowledge proof protocol, a prover is generated—a trusted data space that can convince the verifier that the verification result is true. This prover does not contain any details of the original data or operation records; finally, the generated prover is encoded to form a standard-format composite zero-knowledge proof, facilitating parsing and verification by the verifier.

[0119] For example, cryptographic compilation using the ZK-SNARKs protocol generates a composite zero-knowledge proof of approximately 200 bytes in size, ensuring efficient transmission and verification.

[0120] Specifically, the phrase "triggering the zero-knowledge proof circuit to run, sequentially executing the first circuit logic and the second circuit logic, and generating the corresponding verification result" includes:

[0121] The zero-knowledge proof circuit is triggered, and each first circuit logic is executed sequentially to generate a first verification result for the compliance of the operation subject's identity authorization status and the prerequisite data status at each key state transition node.

[0122] The zero-knowledge proof circuit is triggered, and each second circuit logic is executed sequentially to generate a second verification result for the continuity of data state hash at each non-critical state transition node.

[0123] In this embodiment, the zero-knowledge proof circuit is first triggered, and each first circuit logic is executed sequentially to generate a first verification result for the compliance of the operation subject's identity authorization status and the prerequisite data status at each key state transition node. Specifically, for the operation subject's identity authorization status verification, the zero-knowledge proof circuit can query the authorized subject database in the trusted data space and compare the operation subject's identity identifier with the authorization list. If a match is found, the circuit outputs "authorization passed"; otherwise, it outputs "authorization failed." For the prerequisite data status compliance verification, the zero-knowledge proof circuit can verify whether the output data status identifier of the previous operation meets the prerequisite requirements in the state transition constraint. For example, if the constraint requires the input data to be in an encrypted state, the zero-knowledge proof circuit verifies whether the hash value in the output data status identifier is the hash value of the encrypted data. If it does, the circuit outputs "premise compliant"; otherwise, it outputs "premise non-compliant," thus obtaining a first verification result that includes both the operation subject's identity authorization status verification and the prerequisite data status compliance verification, such as "authorization passed" and "premise compliant."

[0124] Secondly, the zero-knowledge proof circuit is triggered, and each second circuit logic is executed sequentially to generate a second verification result for the continuity of the data state hash at each non-critical state transition node. Specifically, the zero-knowledge proof circuit first calculates the hash value of the output data content of the previous operation and the hash value of the input data content of the next operation through the first and second computation logics, respectively. Then, the verification logic compares whether the two hash values ​​are equal. If they are equal, it indicates that the data state has not been tampered with, the output hash is continuous, and the verification passes. If they are not equal, it indicates that the data state has been tampered with, the output hash is discontinuous, and the verification fails, thus obtaining the second verification result. The second verification result directly reflects the data integrity of the non-critical nodes.

[0125] In summary, compared to existing technologies, this application constructs a zero-knowledge proof circuit based on operation sequences, state transition constraints, and key state transition nodes, and then runs the zero-knowledge proof circuit to generate a composite zero-knowledge proof. Thus, by constructing a zero-knowledge proof circuit that integrates layered verification logic based on operation sequences, state transition constraints, and key state transition nodes, and completing the entire process of compliance verification and generating a composite zero-knowledge proof through circuit operation, the privacy of original data and operational details is protected, while ensuring the accuracy and efficiency of verification, providing secure and reliable credentials for traceability verification.

[0126] S50: Provide the composite zero-knowledge proof as a data traceability certificate for the target data to the verifier to complete the traceability verification of the entire target data processing process.

[0127] The aforementioned steps obtain a composite zero-knowledge proof that integrates the compliance verification results of the entire target data processing process and the state transition continuity verification information without disclosing the original data and operational details. This proof can provide the verification party with an authoritative and rapidly verifiable traceability basis while protecting data privacy and trade secrets. It enables secure and efficient traceability verification of the compliance, integrity and immutability of the entire target data processing process, which meets the core traceability requirements of cross-entity data circulation in the trusted data space.

[0128] Therefore, this application provides composite zero-knowledge proofs as data traceability credentials for the target data to the verifier, completing the traceability verification of the entire target data processing process. The composite zero-knowledge proof integrates the proof documents of the full-link verification results of the target data operation sequence, including compliance verification conclusions for key state transition nodes and data hash continuity verification results for non-key nodes. The trusted data space can prove a statement to the verifier as true without revealing any information about the statement itself. The data traceability credential refers to the basis used to prove the compliance and integrity of the data processing process. Because composite zero-knowledge proofs possess the characteristics of immutability, rapid verification, and strong privacy protection, they become a suitable traceability credential for the trusted data space. The verifier refers to the entity that needs to confirm whether the target data processing process is compliant, which may be a data provider, regulatory agency, or data collaborator.

[0129] Specifically, the Trusted Data Space will transmit the generated composite zero-knowledge proof to the verifier via a secure channel, such as an encrypted API interface. The verifier does not need to obtain sensitive information such as the original content of the target data or the complete operation record. It only needs to use the corresponding zero-knowledge proof verification tool, such as an open-source verification component based on the ZK-SNARKs protocol, to verify the validity of the composite zero-knowledge proof. If the proof is valid, it directly confirms that the entire processing of the target data from the initial state to the current state complies with the preset data use compliance rules and that no data tampering has occurred, i.e., the operation sequence is continuous and the state transition is legal. If the proof is invalid or the verification fails, the verifier can request the Trusted Data Space to supplement the explanation of the abnormal link or trigger a further precise verification process.

[0130] For example, if the target data is customer credit approval data of a financial institution, containing sensitive information such as customer credit history and income verification, the trusted data space generates a corresponding composite zero-knowledge proof after completing the collection of operation sequences, identification of key state transition nodes, and operation of the zero-knowledge proof circuit. In this case, the verifier is the regulatory system. The regulatory system does not need to retrieve the customer's original credit data or the financial institution's internal operation logs; it can quickly complete the verification simply by loading the composite zero-knowledge proof using a zero-knowledge proof verification tool. If the proof is valid, the entire process of collecting, transmitting, approving, and storing the customer's credit data is deemed compliant. If the proof is invalid, a compliance risk is indicated for a key state transition node, and the regulator then specifically requests the financial institution to provide supplementary explanations for that node. This approach protects customer privacy while improving regulatory efficiency.

[0131] Thus, this application provides the verifier with a composite zero-knowledge proof as a data traceability credential for the target data, completing the traceability verification of the entire target data processing process. By providing the verifier with a composite zero-knowledge proof that integrates the compliance verification results of the entire target data processing process with state transition continuity verification information, the verifier can quickly verify the compliance, integrity, and immutability of the entire target data processing process without obtaining the original data and operational details, achieving a balance between privacy protection and efficient traceability verification.

[0132] In summary, the embodiments of this application have at least the following technical effects:

[0133] Compared to existing technologies, this application first collects multiple operation records generated during the continuous processing of target data in a trusted data space, and then arranges these operation records in timestamp order to generate an operation sequence. In this way, it can completely collect the entire process of target data processing operation records in the trusted data space, and construct an ordered operation sequence through timestamp sorting, providing logically coherent and temporally clear basic data support for subsequent state transition verification, compliance determination, and data tampering detection.

[0134] Secondly, this application inputs the operation sequence into a pre-trained key node identification model, which outputs the location identifiers of one or more key state transition nodes in the operation sequence. In this way, the pre-trained key node identification model accurately locates the key state transition nodes that play a decisive role in compliance determination from the operation sequence and outputs their location identifiers, providing a basis for subsequent layered verification strategies, effectively reducing redundant verification, and balancing the efficiency and accuracy of traceability verification.

[0135] Furthermore, this application constructs a zero-knowledge proof circuit based on the operation sequence, state transition constraints, and key state transition nodes, and runs the zero-knowledge proof circuit to generate a composite zero-knowledge proof. Thus, by constructing a zero-knowledge proof circuit that integrates layered verification logic based on the operation sequence, state transition constraints, and key state transition nodes, and completing the entire process compliance verification and generating a composite zero-knowledge proof through circuit operation, the privacy of original data and operational details is protected, while ensuring the accuracy and efficiency of verification, providing secure and reliable credentials for traceability verification.

[0136] Finally, this application provides the verification party with a composite zero-knowledge proof as a data traceability credential for the target data, completing the traceability verification of the entire target data processing process. In this way, by providing the verification party with a composite zero-knowledge proof that integrates the compliance verification results of the entire target data processing process with state transition continuity verification information, the verification party can quickly verify the compliance, integrity, and immutability of the entire target data processing process without obtaining the original data and operational details, achieving a balance between privacy protection and efficient traceability verification.

[0137] Through the aforementioned technical solution, this application utilizes zero-knowledge proof technology, allowing the verifier to complete traceability verification without obtaining sensitive information such as original data or complete operation records. Verification can be completed solely through composite zero-knowledge proofs, thus protecting data privacy and trade secrets while ensuring the effectiveness of traceability. A key node identification model accurately identifies critical state transition nodes that play a decisive role in compliance determination, and a layered verification strategy avoids redundant verification across the entire chain, achieving a balance between verification efficiency and accuracy. This effectively addresses the prominent problems of traditional traceability methods, such as susceptibility to tampering, high privacy risks, low verification efficiency, and poor compliance adaptability, providing closed-loop technical support for the secure and reliable flow of data across entities and scenarios.

[0138] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

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

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

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

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

[0143] Although preferred embodiments of the invention have been described, those skilled in the art, once they have learned the basic inventive concept, can make other changes and modifications to these embodiments.

[0144] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of this invention and its equivalents, this invention also intends to include these modifications and variations.

Claims

1. A data source tracing and verification method in a trusted data space, characterized in that, The method includes: Multiple operation records generated during the continuous processing of target data in a trusted data space are collected, and the multiple operation records are arranged in order of timestamp to generate an operation sequence. The operation records include operation type, operation subject identity, data attributes, input data status identifier and output data status identifier. The predefined data is transformed into state transition constraints to determine whether the state transition between adjacent operation records is legal using compliance rules. The operation sequence is input into a pre-trained key node recognition model, which outputs the position identifiers of one or more key state transition nodes in the operation sequence. Based on the operation sequence, the state transition constraints, and the key state transition nodes, a zero-knowledge proof circuit is constructed and run to generate a composite zero-knowledge proof. The composite zero-knowledge proof is provided to the verifier as a data traceability certificate for the target data, thereby completing the traceability verification of the entire target data processing process; This involves transforming predefined data into state transition constraints used to determine the legality of state transitions between adjacent operation records, using compliance rules. Obtain a predefined data use compliance rule library, and match and load an applicable set of data use compliance rules from the data use compliance rule library based on the data attributes of the target data and the processing context in the operation sequence; The data is expressed using each rule in the compliance rule set, and formal logic language is used to convert the rules described in natural language or policy language into computable logical expressions containing preconditions and conclusions. For each pair of adjacent operation records in the operation sequence, the output data status identifier of the previous operation record is taken as the premise state, and the input data status identifier and operation type of the next operation record are taken as the state and operation to be verified, thus forming a state transition pair. Instantiate the computable logical expression into state transition constraints for the state transition pair; Specifically, the operation sequence is input into a pre-trained key node recognition model, which outputs the location identifiers of one or more key state transition nodes in the operation sequence, including: Call the pre-trained key node recognition model; The operation sequence is input into the key node identification model to analyze the state transition patterns and compliance risks between adjacent operation records in the operation sequence, and outputs the location identifiers of one or more key state transition nodes that have the greatest impact on the compliance determination of the operation sequence. The zero-knowledge proof circuit is constructed based on the operation sequence, the state transition constraints, and the key state transition nodes, including: Based on the operation sequence, the state transition constraints, and the location identifiers of the key state transition nodes, a zero-knowledge proof circuit is designed. Based on the location identifier of the critical state transition node, all state transition nodes in the operation sequence are divided into critical state transition nodes and non-critical state transition nodes. For each critical state transition node, based on the corresponding state transition constraints, a first circuit logic is designed to verify, during the operation of the zero-knowledge proof circuit, whether the identity of the operating subject at the critical state transition node is authorized, and whether the data state represented by the output data state identifier of the previous operation record satisfies the preconditions for executing the current operation. For each non-critical state transition node, a second circuit logic is designed to verify the hash continuity between the data state identifiers of the operation records before and after the non-critical state transition node during the operation of the zero-knowledge proof circuit. The first and second circuit logics designed for all nodes are combined according to the order of state transition nodes in the operation sequence to complete the construction of the zero-knowledge proof circuit. Specifically, for each non-critical state transition node, a second circuit logic is designed to verify the hash continuity between the data state identifiers of the operation records before and after the non-critical state transition node during the operation of the zero-knowledge proof circuit, including: The first computational logic of the zero-knowledge proof circuit during operation is designed to calculate the hash value of the output data content contained in the output data status identifier of the previous operation record, and use it as the first hash value. The zero-knowledge proof circuit is designed with a second computational logic during operation to calculate the hash value of the input data content contained in the input data status identifier of the next operation record, as the second hash value. The zero-knowledge proof circuit is designed to perform verification logic during operation to determine whether the first hash value and the second hash value are equal. The first calculation logic, the second calculation logic, and the verification logic are combined to form a second circuit logic for verifying hash continuity. The process of running the zero-knowledge proof circuit to generate a composite zero-knowledge proof includes: Input computational parameters into the constructed zero-knowledge proof circuit, wherein the computational parameters include the operation sequence, the state transition constraints, and the position identifiers of the key state transition nodes; The zero-knowledge proof circuit is triggered to run, and the first circuit logic and the second circuit logic are executed sequentially to generate the corresponding verification result. The verification result is cryptographically compiled to generate a composite zero-knowledge proof.

2. The data source tracing and verification method in a trusted data space according to claim 1, characterized in that, Multiple operation records generated during the continuous processing of target data in a trusted data space are collected, and these multiple operation records are arranged in timestamp order to generate an operation sequence, including: Extract multiple operation records corresponding to the target data from the data processing log; The operation type, operation subject identity, data attributes, input data status identifier and output data status identifier are parsed from the operation record. The input data status identifier includes the input data content hash value, the input operation serial number and the input timestamp. The output data status identifier includes the output data content hash value, the output operation serial number and the output timestamp. Based on the timestamp order and the correlation between the input operation serial number and the output operation serial number, the multiple operation records are concatenated to form the operation sequence.

3. The data source tracing and verification method in a trusted data space according to claim 1, characterized in that, The process of building a data compliance rule base includes: Define the storage structure and data schema of the data use compliance rule base, wherein the storage structure is used to store the data use compliance rules, and the data schema is used to describe the scope of application, the objects of constraint, and the logical content of the data use compliance rules; Collect compliance rules for data use from the data provider's policy documents, data processing contracts, and domain regulatory documents; The data is parsed, classified, and standardized according to the data pattern using compliance rule text to generate structured rule data; The structured rule data is stored in the data usage compliance rule base, and a query index mechanism based on data attributes is established for the data usage compliance rule base.

4. The data source tracing and verification method in a trusted data space according to claim 1, characterized in that, The training process of the key node identification model includes: Obtain historical operation sequences from the trusted data space to form a sample training dataset; Obtain the labels of the key state transition nodes corresponding to each historical operation sequence in the sample training dataset to form a sample labeled dataset; A key node identification model is constructed based on an attention-based neural network. The key node recognition model is trained using the sample training dataset and the sample annotation dataset until the verification convergence, thus obtaining the trained key node recognition model.

5. The data source tracing and verification method in a trusted data space according to claim 1, characterized in that, The zero-knowledge proof circuit is triggered to run, sequentially executing the first circuit logic and the second circuit logic to generate corresponding verification results, including: The zero-knowledge proof circuit is triggered, and each first circuit logic is executed sequentially to generate a first verification result for the compliance of the operation subject's identity authorization status and the prerequisite data status at each key state transition node. The zero-knowledge proof circuit is triggered, and each second circuit logic is executed sequentially to generate a second verification result for the continuity of data state hash at each non-critical state transition node.

Images