A data traceability verification method of zero-knowledge proof

Abstract

The application provides a data traceability verification method of zero-knowledge proof, comprising the following steps: receiving an operation rule set and source information of each data entity, constructing a verifiable constraint circuit and generating a key; calculating data entity source commitment and building an aggregation tree, embedding a tree root hash into the constraint circuit; constructing a state tree to maintain a global state root, and managing a confirmed operation set through a cryptographic accumulator; generating a single operation proof by using a hybrid proof structure of inner STARK and outer Groth16, generating an aggregation proof by recursive folding, constructing a state root chain, and encapsulating an end-to-end compliance certificate; a data subject, a regulatory party and a system layer generate predicate proofs respectively, submit a joint verification program and verify in parallel. The application eliminates the risk of traceability chain header forgery, reduces the memory occupation of the prover to sub-linear order, and realizes the synergy of the three goals of data subject privacy protection, effective audit of the regulatory party and traceability of the audit behavior itself under the same cryptographic framework.

Description

Technical Field

[0001] This invention relates to the fields of cryptography and data security technology, specifically to a zero-knowledge proof-based data traceability and verification method, applicable to data flow scenarios that require simultaneous data privacy protection and compliance auditability. Background Technology

[0002] With the rapid development of the data element market, data flow across institutions and platforms is becoming increasingly frequent. Data traceability and verification technology aims to conduct compliance tracking and auditing of the entire lifecycle of data, from generation, flow, processing to use.

[0003] Existing data traceability and verification solutions can be mainly divided into three categories: The first category is a centralized auditing solution based on traditional database logs, which relies on a trusted central institution to store operation logs and is subject to single point of failure and internal tampering risks; the second category is a full-scale evidence storage solution based on blockchain, which records the original content or hash of each data operation on the chain, ensuring traceability credibility through on-chain immutability, and relying on smart contracts for state management and compliance verification; the third category is a privacy computing solution based on a Trusted Execution Environment (TEE), which ensures the confidentiality of the computing process through a hardware security zone, but relies on specific hardware manufacturers and has supply chain trust issues.

[0004] Taking a financial data supervision scenario as an example, when a commercial bank provides customer credit scoring datasets to partner financial institutions, it must meet the regulatory authorities' audit requirements regarding the scope of data use and operational compliance, while simultaneously prohibiting the disclosure of the original customer data content to partners or regulators. In this scenario, the dataset undergoes multi-level anonymization preprocessing and is used by multiple business departments. Each data transfer, processing, and use requires the generation of verifiable operational compliance records. However, existing solutions face the following specific technical challenges in this scenario:

[0005] On the one hand, there are bottlenecks in proof generation resources and the forgery of the traceability chain's head. Existing zk-SNARK-based provers have memory consumption that is linearly positively correlated with computational scale. In the aforementioned financial scenarios, the edge data nodes of banking departments have limited computing power and cannot generate proofs locally. Data must be uploaded to a high-performance cloud for centralized processing, creating the risk of original data leakage during transmission and a centralized bottleneck in the architecture. Simultaneously, existing traceability solutions only establish cryptographic records of the operational process, failing to incorporate data source information (original dataset identifier, de-identification preprocessing rules, authorization certificates, etc.) into a verifiable commitment structure. This allows the starting point of the traceability chain to be forged—the executor can disguise an unauthorized original dataset as an authorized, compliant dataset without altering the operational record, failing to establish an end-to-end cryptographically trusted closed loop from data generation to final use.

[0006] On the other hand, the audit structure is one-way and asymmetrical, and the audit itself is not traceable. In the aforementioned financial regulatory scenarios, regulators have a one-way information asymmetry advantage over commercial banks. When audited, banks cannot simultaneously verify the legality of the auditor's authorization documents or whether the audit scope exceeds the authorized boundaries. The boundaries of audit power lack cryptographic constraints. The audit itself is not included in any verifiable records, posing a security risk of regulators overstepping their authority without leaving a trace. Existing solutions cannot achieve the synergy of the three objectives—data subject privacy protection, effective regulatory auditing, and traceability of the audit itself—within the same cryptographic framework. Summary of the Invention

[0007] The technical problem that this invention aims to solve is that existing data traceability and verification schemes suffer from drawbacks such as bottlenecks in proof generation resources, the forgery of the head of the traceability chain, one-way asymmetry in the audit structure, and the inability to trace the audit behavior itself.

[0008] To address the aforementioned technical problems, this invention provides a data tracing and verification method for zero-knowledge proofs, comprising:

[0009] Receive the operation rule set and the source information of each data entity, establish a verifiable constraint circuit for the operation rule set and generate a proof key and a verification key, calculate the source commitment for each data entity and organize it into an aggregate tree structure, embed the constraint circuit with the root hash of the aggregate tree structure as the source root identifier, and obtain the constraint circuit set, proof key, verification key and aggregate tree structure;

[0010] Based on the set of constraint circuits, proof keys, verification keys and aggregation tree structure, a state tree is constructed by combining data content hash, operation history digest and source commitment. After each data operation, the state tree is incrementally updated and a global state root is maintained. A cryptographic accumulator is used to maintain the set of confirmed operations, resulting in the state tree, global state root and accumulator structure.

[0011] Based on the state tree, the global state root, the aggregate tree structure, and the proof key, a single operation proof carrying the state root before and after the operation and the source path hash is generated for each data operation, resulting in multiple single operation proofs;

[0012] Based on multiple single-operation proofs and the accumulator structure, a recursive folding mechanism is used to incorporate the linking relationship between the state roots before and after the operation into the folding constraints, generating an aggregate proof and constructing a state root chain. The aggregate proof, the source root identifier, and the state root chain are encapsulated into an end-to-end compliance certificate. The data subject, the regulator, and the system layer each generate corresponding predicate proofs locally and submit them to a joint verification program for parallel verification. If any predicate proof is invalid, the joint verification program rejects the verification of the end-to-end compliance certificate.

[0013] Optionally, the step of establishing a verifiable constraint circuit for the set of operating rules and generating a proof key and a verification key includes:

[0014] Based on the flow rules in the operation rule set, a constraint circuit for verifying the sender's permissions and data integrity is constructed to obtain the R1CS constraint corresponding to the flow operation.

[0015] For the usage rules in the aforementioned operation rule set, a constraint circuit is established to verify the compliance of access control policies and usage, and to generate R1CS constraints corresponding to the usage operations.

[0016] The processing rules in the operation rule set are transformed into a constraint circuit that verifies that the input-output relationship conforms to the predefined transformation rules, thereby obtaining the R1CS constraint corresponding to the processing operation;

[0017] The R1CS constraints corresponding to the transfer operation, the R1CS constraints corresponding to the use operation, and the R1CS constraints corresponding to the processing operation are processed by a trusted setting, wherein the trusted setting uses only random inputs provided by the participants and is completely decoupled from the source information to generate the proof key and the verification key.

[0018] Optionally, the step of calculating the source commitment for each data entity and organizing it into an aggregate tree structure, embedding the constraint circuit with the root hash of the aggregate tree structure as the source root identifier, includes:

[0019] Based on the dataset identifier, preprocessing step description, authorization information and operation quota counter in the source information of each data entity, a hash function is used to calculate the commitment to obtain the independent source commitment corresponding to each data entity.

[0020] In a multi-dataset scenario, based on the independent source commitments corresponding to multiple data entities, the aggregation tree structure is constructed by layer-by-layer hash aggregation. The root hash of the aggregation tree structure is used as the source root identifier, and the source root identifier is used as a public input to embed the constraint circuit, thereby obtaining the constraint circuit set and the aggregation tree structure.

[0021] In a single dataset scenario, the aggregate tree structure degenerates into a single-leaf structure. The independent source commitment corresponding to a single data entity is directly used as the source root identifier. The source root identifier is embedded as a public input into the constraint circuit to obtain the constraint circuit set and the aggregate tree structure. This adopts a unified commitment calculation and embedding method with the multi-dataset scenario.

[0022] Optionally, constructing the state tree using a combination of data content hash, operation history digest, and source commitment includes:

[0023] For processing operations involving multiple data entities, based on the path nodes corresponding to each input data entity in the aggregation tree structure, hash aggregation calculation is performed layer by layer on the path nodes to obtain the source path hash of the cross-entity processing operation, and the source path hash is used as the corresponding source commitment field value.

[0024] Based on the source commitment field value, the source commitment field value is combined with the corresponding data content hash and operation history summary, and written into the state tree as the corresponding leaf node value to obtain the leaf node carrying the cross-entity source tracing link and the state tree containing the leaf node.

[0025] Optionally, maintaining the set of confirmed operations using a cryptographic accumulator includes:

[0026] Based on the operation identifier after each data operation confirmation, the operation identifier is updated to the cryptographic accumulator to obtain the updated accumulator state;

[0027] Based on the updated accumulator state, a membership certificate is generated for the operation identifier. The generation and verification of the membership certificate are both completed within a constant time, resulting in the accumulator structure containing the accumulator state and the membership certificate, which is used by the auditor to verify the legality of the authorization certificate.

[0028] Optionally, a hybrid proof structure is used to generate the proof for each data operation, including:

[0029] Based on compliance verification calculation of a single data operation, the compliance verification calculation is expressed as an execution trace, and the execution trace is decomposed into several independent calculation blocks. Each independent calculation block only loads the state tree path node, source commitment summary and operation parameters required by the current independent calculation block, to obtain multiple independent calculation blocks and local input data corresponding to each independent calculation block;

[0030] Based on the multiple independent computation blocks and the local input data, the corresponding polynomial commitment is calculated independently for each independent computation block, and a corresponding auxiliary accumulator is generated for each independent computation block. The polynomial commitments and auxiliary accumulators corresponding to each independent computation block are organized layer by layer through a tree-shaped evaluation structure to obtain a tree-organized polynomial commitment structure.

[0031] Based on the tree-organized polynomial commitment structure, a constant-order streaming scan is used to traverse and aggregate all independent computational blocks in the polynomial commitment structure to generate the inner proof.

[0032] Based on the inner proof, the inner proof is encapsulated in the outer proof stage, and the state root before and after the operation and the source path hash are incorporated into the outer constraints to generate the single operation proof carrying the state root before and after the operation and the source path hash. The hybrid proof structure reduces the prover memory usage to the order of magnitude proportional to the square root of the number of operation steps.

[0033] Optionally, the outer proof stage of the hybrid proof structure circuitizes the verification logic of the inner proof to generate the single-operation proof of constant size, including:

[0034] Based on the inner proof, the verification logic of the inner proof is expressed as an arithmetic circuit, and the state root before and after the operation, the source path hash of the entity involved in the operation, and the operation rule type identifier are used as the public input ports of the arithmetic circuit to obtain the arithmetic circuit representation.

[0035] Based on the arithmetic circuit representation, the state roots before and after the operation, the source path hash of the entity involved in the operation, and the operation rule type identifier are used as public inputs. The proof generation algorithm is executed using the proof key to obtain a single operation proof of constant size.

[0036] Optionally, the step of employing a recursive folding mechanism to incorporate the linking relationship between the state roots before and after the operation into the folding constraints, generating an aggregate proof, and constructing a state root chain includes:

[0037] Based on two adjacent single operation proofs, the validity of the two adjacent single operation proofs is verified, and the link relationship between the post-operation state root carried by the previous operation proof and the pre-operation state root carried by the next operation proof is included in the folding constraint to obtain the intermediate aggregation proof.

[0038] Based on the intermediate aggregation proof, the operation is recursively folded layer by layer according to the operation sequence. Each fold retains the temporal integrity of the operation sequence, resulting in the aggregation proof and the state root sequence carried by each operation proof during the layer-by-layer folding process.

[0039] Based on the state root sequence, the complete evolution path from the initial state root to the final state root is recorded in the order of operation timing to form the state root chain. Each node in the state root chain serves as a locatable anchor point for subsequence auditing.

[0040] Optionally, the step of having the data subject, regulator, and system layer each locally generate corresponding predicate proofs and simultaneously submit them to a joint verification program for parallel verification, wherein the data subject locally generates compliance predicate proofs for the operation content, including:

[0041] Based on the operation record corresponding to the specified operation and the end-to-end compliance certificate, generate an operation content compliance certificate result that proves that the specified operation complies with the established operation rules and does not expose data content.

[0042] Based on the accumulator structure and the authorization credentials held by the auditing party initiating the audit, the legality of the authorization credentials within the confirmed operation set maintained by the accumulator structure is verified to obtain the auditing party authorization verification sub-predicate result;

[0043] The compliance proof result of the operation content and the audit authorized verification sub-predicate result are combined and encapsulated in the same zero-knowledge proof to obtain the compliance predicate proof of the operation content with the audit authorized verification sub-predicate result.

[0044] Optionally, the data subject, regulator, and system layer each generate corresponding predicate proofs locally and submit them simultaneously to a joint verification procedure for parallel verification. Selective disclosure is then made based on the auditor's authority level, including:

[0045] Based on the permission level corresponding to the authorization certificate held by the auditor, the permission level is determined to be a global supervisor, a restricted authorized auditor, or an unauthorized party, and the permission level determination result is obtained.

[0046] Based on the permission level determination result, when the permission level is a global supervisor, the verifiable confirmation of the operation execution entity type and operation type is disclosed to the global supervisor; when the permission level is a restricted authorization auditor, only the operation compliance confirmation is disclosed to the restricted authorization auditor without disclosing the identity of the execution entity; when the permission level is an unauthorized party, only the unauthorized party is allowed to verify the validity of the aggregated proof; thus obtaining a selective disclosure result matching the permission level determination result.

[0047] The beneficial technical effects of the present invention are as follows:

[0048] 1. End-to-end source trusted anchoring eliminates the risk of forgery at the head of the traceability chain. Through the source aggregation tree structure and the dual-track Merkle state leaf structure, the data source information and operation records are completely bound at the cryptographic level, realizing the full-link verifiability from the source of data generation to the final operation result, fundamentally eliminating the possibility of forgery at the head of the traceability chain.

[0049] 2. Proof generation memory is reduced to sublinear, enabling localized deployment of edge nodes. The inner sublinear spatial block streaming mechanism in the hybrid proof structure reduces the prover's memory usage from O(T) to O(…). On a scale of ) scale, edge data nodes can generate proofs locally without the need for high computing power cloud support, completely eliminating the bottleneck of centralized architecture in high-frequency data flow scenarios;

[0050] 3. Storage overhead is significantly reduced and verification efficiency is significantly improved. The recursive folding batch aggregation mechanism compresses the full evidence storage of n operations into an end-to-end compliance certificate of about 500 bytes, which reduces storage overhead compared with the traditional blockchain full evidence storage solution; the verifier only needs to complete the full-link compliance confirmation in milliseconds.

[0051] 4. The multi-party mutual verification structure breaks the asymmetry of one-way auditing. The audit behavior itself is traceable. The multi-party parallel mutual verification mechanism of compliance predicate splitting enables data subjects, regulators and system layers to constrain each other under the same cryptographic framework. Data subjects can verify the legality of the auditor's authorization while being audited. The audit behavior is forcibly included in the tamper-proof traceability record. Tiered privacy response is achieved through selective disclosure. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic diagram of the overall process of the zero-knowledge proof data tracing and verification method of the present invention;

[0054] Figure 2 This is a schematic diagram illustrating the process of establishing the constraint circuit and generating the key in this invention;

[0055] Figure 3 This is a schematic diagram of the structure of the source aggregation tree and state tree construction of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0057] Example 1

[0058] like Figure 1 As shown, this embodiment provides a data source tracing and verification method for zero-knowledge proofs, including:

[0059] Step S1: Receive the operation rule set and the source information of each data entity, establish a verifiable constraint circuit for the operation rule set and generate a proof key and a verification key, calculate the source commitment for each data entity and organize it into an aggregate tree structure, embed the constraint circuit with the root hash of the aggregate tree structure as the source root identifier, and obtain the constraint circuit set, proof key, verification key and aggregate tree structure.

[0060] Specifically, the data space management entity receives the set of operational rules and the source information of each data entity. The set of operational rules encompasses three heterogeneous categories: flow rules, usage rules, and processing rules. The source information includes dataset identifiers, preprocessing step descriptions, authorization information, and operational quota counters. Arithmetic circuit modeling is performed on the set of operational rules, transforming the three types of rules into corresponding R1CS constraint circuit sets. A proof key (pk) and a verification key (vk) are generated through trusted settings. For the source information of each data entity, an independent source commitment is calculated using a hash function. Multiple source commitments are aggregated through layer-by-layer hashing to construct an aggregation tree structure (Manifest Aggregation Tree, MAT). The root hash of the MAT, serving as the source root identifier (Manifest Root), is embedded into the constraint circuit as a public input, ensuring that it can be independently verified during proof verification, rather than being used as a trusted setting parameter, thus completely decoupled from the source information.

[0061] Step S2: Based on the set of constraint circuits, proof key, verification key and aggregation tree structure, construct a state tree by combining data content hash, operation history digest and source commitment. After each data operation, incrementally update the state tree and maintain the global state root. Use a cryptographic accumulator to maintain the set of confirmed operations to obtain the state tree, global state root and accumulator structure.

[0062] Specifically, based on key pairs, MAT structures, and source root identifiers, a Merkle tree structure is used to maintain the global state of data entities. The data entity ID serves as the leaf node index, and the leaf node value is a triple combination of the data content hash, operation history digest, and the corresponding source commitment. This single data structure simultaneously carries both operation verifiability and source binding reliability. After each data operation, the corresponding leaf nodes and affected path nodes are incrementally updated to maintain the global state root. A cryptographic accumulator is also used to maintain a compact representation of the confirmed operation set, supporting constant-time member proof generation and verification.

[0063] Step S3: Based on the state tree, the global state root, the aggregate tree structure, and the proof key, generate a single operation proof for each data operation, carrying the state root before and after the operation and the source path hash, to obtain multiple single operation proofs.

[0064] Specifically, zero-knowledge proofs are generated for each specific data operation event, using the Merkle state tree, global State Root, MAT structure, and proof key pk as inputs. A hybrid proof structure of inner STARK and outer Groth16 is adopted. The inner STARK proof generates an execution trace for compliance verification calculation of a single operation (including Merkle path verification, source commitment consistency check, and operation rule constraint verification). The outer Groth16 circuitizes the inner STARK verification logic and generates a constant-size proof. The public input of the outer circuit includes the State Root before and after the operation, the source path hash of the entity involved in the operation (taken from MAT), and the operation rule type identifier, forming a single operation proof carrying the state root before and after the operation and the source path hash.

[0065] Step S4: Based on the multiple single-operation proofs and the accumulator structure, a recursive folding mechanism is used to incorporate the linking relationship of the state roots before and after the operation into the folding constraints, generating an aggregate proof and constructing a state root chain. The aggregate proof, the source root identifier, and the state root chain are encapsulated into an end-to-end compliance certificate. The data subject, the regulator, and the system layer each generate corresponding predicate proofs locally and submit them to the joint verification program for parallel verification. If any predicate proof is invalid, the joint verification program rejects the verification of the end-to-end compliance certificate.

[0066] Specifically, taking multiple sets of single-operation proofs and the verification key vk as input, a recursive folding mechanism is used to aggregate adjacent operation proofs pairwise, folding them layer by layer until a single aggregate proof Pi is generated. agg Each fold verifies the validity of the proof from the previous layer while incorporating the linking relationships between the preceding and following State Roots into the fold constraint, ensuring the temporal integrity of the operation sequence. Simultaneously, a complete root chain is constructed from the initial state root to the final state root. The aggregated proof Pi is then used. agg The source root identifier (Manifest Root) and the Root Chain tail node are jointly encapsulated into an end-to-end compliance certificate. This certificate simultaneously covers full-chain source compliance and operational compliance within a single verification of approximately 500 bytes and milliseconds. During the audit phase, the data subject, the regulator, and the system layer independently generate operational content compliance predicate proofs, audit behavior compliance predicate proofs, and audit records included in the predicate proofs locally. All three parties submit these to the joint verification program for parallel verification. If any of the three types of predicate proofs is invalid, the joint verification program cryptographically rejects the verification of the end-to-end compliance certificate, eliminating the first-mover advantage brought by chain dependencies.

[0067] Example 2

[0068] like Figure 2As shown, in this embodiment, the step of establishing a verifiable constraint circuit for the operation rule set and generating a proof key and a verification key includes:

[0069] Step S11: Based on the flow rules in the operation rule set, construct a constraint circuit to verify the sender's permissions and data integrity, and obtain the R1CS constraint corresponding to the flow operation.

[0070] Step S12: For the usage rules in the operation rule set, establish a constraint circuit to verify the compliance of access control policies and usage, and generate R1CS constraints corresponding to the usage operations.

[0071] Step S13: Transform the processing rules in the operation rule set into a constraint circuit that verifies that the input-output relationship conforms to the predefined transformation rules, and obtain the R1CS constraint corresponding to the processing operation.

[0072] Step S14: The R1CS constraints corresponding to the transfer operation, the R1CS constraints corresponding to the use operation, and the R1CS constraints corresponding to the processing operation are processed by a trusted setting, wherein the trusted setting uses only random input provided by the participants and is completely decoupled from the source information to generate the proof key and the verification key.

[0073] Specifically, firstly, data transfer operations refer to the type of operation in which ownership or access rights of data entities are transferred between different institutions, departments, or system entities. The transfer rules stipulate a set of conditions that must be met for a legitimate transfer operation, including constraints such as the sender having legitimate authorization to operate on the target data entity, the data content not undergoing unauthorized modification during transmission, and the receiver's identity being within the authorized whitelist.

[0074] For the aforementioned flow rules, each rule is mapped to a gate circuit constraint in an arithmetic circuit. Specifically, the sender authorization verification constraint compares the sender's identity hash with the set of legitimate senders recorded in the authorization information, requiring them to satisfy an equality relationship at the circuit level; the data integrity verification constraint compares the hash of the data content before the flow with the hash of the data content recalculated when the receiver confirms receipt, requiring them to be equal at the circuit level to prevent data tampering during transmission. The above gate circuit constraints are then transformed into the R1CS (Rank-1 Constraint System) format. R1CS is the standard intermediate representation of zk-SNARKs proof systems, and its core structure is a triplet constraint. Each constraint expresses the condition that the left input vector, right input vector, and output vector satisfy a specific multiplication relationship under the current assignment. The logical judgments involved in the flow rules (such as permission enumeration matching and hash equality verification) can all be transformed into a multiplicative constraint sequence over a finite field by introducing auxiliary intermediate variables, and finally obtain the R1CS constraint set corresponding to the flow operation, where each constraint corresponds to an atomic verification unit of the flow compliance verification logic.

[0075] Secondly, data usage operations refer to the types of operations performed by an authorized entity to read, query, or analyze data entities without transferring ownership of the data entities. The usage rules specify the access control policies that legitimate usage operations must meet (including whether the accessing entity's identity level meets the minimum authorization threshold, whether the current access time is within the authorization validity window, and whether the cumulative number of accesses exceeds the remaining quota recorded by the operation quota counter) and usage compliance constraints (i.e., whether the declared purpose of this usage operation is within the scope of the permitted uses approved by the authorization information).

[0076] To address the aforementioned usage rules, the access control policy's access subject level verification transforms this into a circuit constraint by verifying the membership of the access subject's identity against the pre-registered list of legitimate access subjects in the authorization configuration. Authorization validity verification is implemented by comparing the timestamp variable with the authorization start and end time boundaries. Operation quota verification prevents over-quota access by ensuring the difference between the current value of the operation quota counter and its updated value after the current operation is a non-negative integer. Purpose compliance constraints establish circuit constraints by matching the enumerated identifiers of declared purposes against the set of allowed purpose identifiers in the authorization information. All these constraints are converted to R1CS format. The combined logic of the access control policy and purpose compliance verification is combined using an AND relationship (implemented in an arithmetic circuit through cascading multiplication gates) to obtain the R1CS constraint set corresponding to the usage operation, ensuring that the compliance verification of the usage operation covers all conditions for access control and purpose compliance at the circuit level.

[0077] Next, data processing operations refer to operations that apply transformation processes (such as desensitization, aggregation, format conversion, derivative calculations, etc.) to one or more data entities to generate new data entities or modify the content of existing data entities. Processing rules define the input-output mapping relationship for legitimate processing operations; that is, given a specific set of input data, the output data set after predefined processing and transformation should satisfy the content constraints. The core challenge of these constraints lies in proving, in a cryptographically verifiable way, that the output data was indeed generated by compliant processing and transformation, and not arbitrarily forged by the operator, without exposing the original content of the input data.

[0078] To address the aforementioned challenges, the core idea of ​​transforming the input-output mapping relationships defined in the processing rules into arithmetic circuit constraints is as follows: The content hash values ​​of the input and output data entities are used as the circuit's private inputs. The algorithmic description of the predefined transformation rules (expanded into a sequence of arithmetic operations) serves as the circuit's constraint body, requiring that the transformation calculation results performed within the circuit match the output data content hash. For de-identification processing operations, the constraint circuit verifies that the content at specified field positions in the output data is replaced with agreed-upon de-identification placeholder values, and that the remaining fields remain consistent with the input data. For aggregation processing operations, the constraint circuit verifies that the aggregated statistical values ​​(such as summation and mean) of the output data are consistent with the arithmetic operation results of the corresponding fields of each input data entity. For format conversion processing operations, the constraint circuit verifies the content equivalence of the input and output data after removing format differences. All of the above processing rule constraints are uniformly transformed into R1CS format, resulting in the R1CS constraint set corresponding to the processing operation.

[0079] Finally, the trusted setup is a one-time initialization process that must be performed before use in zk-SNARKs proof systems based on paired-friendly elliptic curves (such as Groth16). Its purpose is to generate a Structured Reference String (SRS) bound to a specific R1CS constraint structure. The SRS is then split into a proof key (pk) and a verification key (vk). The proof key is held by the prover and used to generate a zero-knowledge proof when it possesses a witness value that satisfies the R1CS constraints. The verification key is held by the verifier and used to efficiently verify the validity of the proof without obtaining the witness value.

[0080] The trusted setup process relies on a set of secret random numbers (referred to as "toxic waste"), which must be securely destroyed after the trusted setup is complete. Otherwise, any entity holding these random numbers could forge false credentials with arbitrary content. To reduce the risk of a single point of trust, this embodiment employs a multi-party computation protocol to perform the trusted setup: multiple participants in the data space independently generate their own random inputs, and through a multi-round interaction protocol, the random inputs of each participant are securely mixed into the final set of random numbers. As long as at least one honest participant correctly destroys its share of random numbers, the security of the entire trusted setup can be guaranteed.

[0081] This embodiment emphasizes that the trusted setup uses only random inputs provided by the participants, completely decoupling it from the source information. The technical significance of this design lies in the fact that the source information (dataset identifier, preprocessing step description, authorization information, and operation quota counter) is dynamically generated and updated during data space operation. If the source information is included as a parameter in the trusted setup's SRS generation process, the trusted setup must be re-executed every time the source information changes (a computationally expensive process). Furthermore, any errors or forgeries in the source information will be permanently fixed in the SRS and cannot be corrected afterward. By completely decoupling the trusted setup from the source information—dynamically passing the source information as public input during the proof generation stage—the trusted setup only needs to be executed once for a fixed R1CS constraint structure. The updating, verification, and validation of the source information are all performed independently at the proof level, enabling the system to simultaneously possess the one-time nature of the trusted setup and the dynamic verifiability of the source information. After the trusted setup is completed, the generated proof key pk and verification key are used in subsequent proof generation and verification stages.

[0082] Example 3

[0083] like Figure 3 As shown, in this embodiment, the step of calculating the source commitment for each data entity and organizing it into an aggregate tree structure, and embedding the constraint circuit with the root hash of the aggregate tree structure as the source root identifier, includes:

[0084] Based on the dataset identifier, preprocessing step description, authorization information, and operation quota counter in the source information of each data entity, a hash function is used to calculate the commitment, resulting in an independent source commitment for each data entity.

[0085] In a multi-dataset scenario, based on the independent source commitments corresponding to multiple data entities, the aggregation tree structure is constructed through layer-by-layer hash aggregation. The root hash of the aggregation tree structure is used as the source root identifier, and the source root identifier is used as a public input to embed the constraint circuit, thereby obtaining the constraint circuit set and the aggregation tree structure.

[0086] In a single dataset scenario, the aggregate tree structure degenerates into a single-leaf structure. The independent source commitment corresponding to a single data entity is directly used as the source root identifier. The source root identifier is embedded as a public input into the constraint circuit to obtain the constraint circuit set and the aggregate tree structure. This adopts a unified commitment calculation and embedding method with the multi-dataset scenario.

[0087] Specifically, firstly, a source commitment is a cryptographic binding representation of the complete source information of a single data entity. Its core function is to compress all the original attributes of a data entity before it enters the data flow system into a fixed-length hash digest. This ensures that any subtle modification to the source information field (whether it's replacing the dataset identifier, reducing preprocessing steps, expanding the scope of authorization, or tampering with the operation quota counter) will result in a detectable change in the source commitment value. This cryptographically locks in the original source state of the data entity, preventing the source information at the head of the traceability chain from being forged or replaced afterward.

[0088] The dataset identifier is a unique marker for the original dataset, used to distinguish data entities from different sources within the data space. Its value is typically a globally unique identifier issued by the data space management authority during dataset registration. The preprocessing step description records an ordered description of all processing steps a data entity undergoes after being collected from the original dataset and before entering the circulation system. This includes, but is not limited to, data cleaning rules, desensitization algorithm types and parameters, and field filtering conditions. The preprocessing step description is represented as a serialized string of an ordered list, and differences in order are considered different preprocessing histories. The authorization information records the set of types authorized for use by the current data entity, the authorization validity period boundary, and the authorization issuer identifier. This serves as a benchmark reference for subsequent compliance verification. The operation quota counter records the maximum number of compliant operations that the current data entity can still perform. It is decremented and updated by the system after each compliant operation is confirmed. The current value of the operation quota counter participates in the source commitment calculation, ensuring that data entities whose quotas are exhausted can be distinguished at the source commitment level.

[0089] During commitment calculation, the four fields mentioned above are serialized and concatenated according to a predefined field order to form the original byte string of source information. This byte string is then used as input to a hash function for hash calculation. The output, a fixed-length hash digest, is the independent source commitment corresponding to the data entity. The hash function selected must meet the requirements of collision resistance and one-wayness, and must be consistent with the circuit-friendly hash function used by the subsequent constraint circuit (e.g., the Poseidon hash function) to ensure that the circuit size is within an acceptable range when recalculating the source commitment within the zero-knowledge proof circuit. The above commitment calculation process is performed independently for each data entity in the data space, resulting in a set of independent source commitments corresponding to each entity.

[0090] Second, the Manifest Aggregation Tree (MAT) is a Merkle tree structure that hierarchically organizes the source commitments of all participating data entities in the data space. Its design goal is to provide a single cryptographic summary anchor point for the source compliance of the entire data space while keeping the source commitments of each data entity independently verifiable. It also supports membership proofs (i.e., Merkle path proofs) for the source commitments of any single data entity, allowing subsequent proof circuits to selectively prove that the source commitment of a specific data entity does indeed belong to the set of source commitments represented by the MAT without exposing the source information of other data entities.

[0091] In multi-dataset scenarios, the independent source commitments of all data entities are arranged into an ordered list according to the registration order of the data entities in the data space, serving as the leaf node layer of MAT. Hash aggregation is performed layer by layer upwards: the hash values ​​of two adjacent leaf nodes (or intermediate nodes) are concatenated and the hash is recalculated to obtain the hash value of its parent node; if the number of nodes in a certain layer is odd, the rightmost node is concatenated with itself to calculate the parent node hash (i.e., a copy-fill strategy), ensuring that the tree structure can be constructed correctly for data entity sets of any size. This aggregation calculation is repeated layer by layer until a single root node hash value is generated, which is the root hash of MAT, also known as the source root identifier (Manifest Root). The hash value of each internal node in MAT is deterministically derived from the hash values ​​of its child nodes. Any change to a leaf node (i.e., any data entity source commitment) will propagate upwards along the tree path, eventually causing a change in the Manifest Root, thus giving MAT a cryptographic binding to the overall content of the data entity source information set.

[0092] The Manifest Root is embedded into the subsequent proof circuit as a public input (rather than as a circuit structure parameter for trusted settings). Specifically, a dedicated public input port is reserved in the input interface of the constraint circuit. At runtime, the hash value of the Manifest Root is filled into this port. Internally, when performing source consistency verification, the proof circuit requires the prover to provide the Merkle path of the target data entity (i.e., the complete path node sequence from the leaf node to the Manifest Root). The circuit internally performs path hash reconstruction calculations and applies an equivalence constraint between the reconstruction result and the Manifest Root value at the public input port. This design allows the verifier to directly check whether the Manifest Root value at the public input port matches the MAT root hash obtained independently, thus independently confirming the cryptographic anchor of source compliance without relying on a trusted third party. This yields a set of constraint circuits embedded with the source root identifier and a complete MAT structure (including the hashes of each layer's nodes and the Merkle paths corresponding to each data entity).

[0093] Third, in a single dataset scenario, there is only one participating data entity in the data space, and the leaf node layer of MAT only contains the independent source commitment corresponding to that data entity. Since there is only a single leaf node, there is no need to perform layer-by-layer hash aggregation. MAT degenerates into a single-leaf structure containing only the root node. The hash value of the root node is equal to the independent source commitment value of the data entity itself, directly serving as the source root identifier. This degenerate processing maintains the same interface structure as in the multi-dataset scenario: the source root identifier is still filled into the dedicated input port of the constraint circuit in the form of public input. The source consistency verification logic inside the proof circuit degenerates into directly comparing whether the public input port value is equal to the independent source commitment value provided by the prover in the single dataset scenario, without performing Merkle path reconstruction.

[0094] The value of using a unified commitment computation and embedding method for both single-dataset and multi-dataset scenarios lies in the fact that when the system expands from a single data entity to multiple data entities, no modifications to the constraint circuit structure, proof key, or verification logic are required. Adaptation to different scenarios can be achieved simply by adjusting the size of the MAT (Manifest Targeting Unit), resulting in seamless scalability at the architectural level. The data space manager does not need to pre-declare the number of data entities during system deployment. When adding new data entities, only new leaf nodes need to be appended to the MAT and the Manifest Root updated. The updated Manifest Root serves as new public input for the next round of proof generation, and the validity of previous proofs remains unaffected.

[0095] Example 4

[0096] In this embodiment, constructing the state tree using a combination of data content hash, operation history digest, and source commitment includes:

[0097] For processing operations involving multiple data entities, based on the path nodes corresponding to each input data entity in the aggregation tree structure, hash aggregation calculations are performed layer by layer on the path nodes to obtain the source path hash of the cross-entity processing operation, and the source path hash is used as the corresponding source commitment field value.

[0098] Based on the source commitment field value, the source commitment field value is combined with the corresponding data content hash and operation history summary, and written into the state tree as the corresponding leaf node value to obtain the leaf node carrying the cross-entity source tracing link and the state tree containing the leaf node.

[0099] Specifically, firstly, source path hashing is a cross-entity source aggregation representation defined in this invention for multi-input data entity processing operations. Its design motivation lies in the fact that when a processing operation uses multiple data entities as input (e.g., merging multiple datasets from different departments into a joint analysis dataset), the source compliance of the output data entity depends on the source compliance of each of the input data entities. If only the independent source commitment of a single input entity is recorded in the leaf nodes of the state tree, the source information of other input entities will be missing from the tracing chain; if the independent source commitments of all input entities are enumerated and recorded, the data volume of the leaf nodes will increase linearly with the number of input entities, disrupting the fixed leaf node format of the state tree. Source path hashing, by structurally aggregating the source information of multiple input entities at the MAT level, represents the joint source information of any number of input entities with a single fixed-length hash value, while preserving the hierarchical relationship of the source commitments of each input entity in the MAT. This allows the aggregation result to be independently verified in the proof circuit through Merkle path proof, fundamentally solving the problem of compact representation of source information in multi-input entity scenarios.

[0100] The specific calculation process is as follows: First, locate the leaf node corresponding to each input data entity involved in this processing operation in MAT, and collect the path node sequence extending upwards from each leaf node along the tree path to the MAT root node (each path contains the hash values ​​of all intermediate nodes from the leaf node to the root node, including the independent source commitment of the leaf node itself). Align the path node sequences of all input entities according to the order of participation of the input entities in the operation, and perform hash aggregation layer by layer starting from the leaf layer: at each layer, concatenate the hash values ​​of the path nodes corresponding to all input entities in the current layer in order and perform hash calculation to obtain the aggregate node hash value of that layer; proceed upwards layer by layer until all layers have completed the aggregation calculation, and finally obtain a source path hash value that can uniquely represent the joint source information of all input entities in this processing operation. The calculation of the source path hash only relies on the path node information already existing in MAT for each input entity, without accessing the original content of any data entity, thus maintaining the privacy protection attribute of the source information. Use this source path hash as the source commitment field value in the leaf node of the state tree corresponding to the current processing operation for subsequent steps to write into the state tree.

[0101] Next, the state tree is the core data structure that maintains the current state of all data entities in the data space using a Merkle tree structure. The leaf nodes are indexed by the data entity ID, and each leaf node contains a triplet value in a fixed format. The first field of the triplet is the data content hash, a digest obtained by hashing the current data entity content (the latest version after the current operation), used to verify the integrity of the data entity content and the cryptographic traceability of content changes before and after the operation. The second field is the operation history digest, a digest obtained by hashing all historical operation records (a chronologically ordered sequence of operation identifiers) experienced by the data entity since entering the data space, recording the complete operation trajectory of the data entity and supporting the cryptographic verifiability of operation sequences at any historical moment. The third field is the source commitment field value; for single-entity operations, the independent source commitment value corresponding to the data entity is used, while for multi-input entity processing operations, the calculated source path hash value is used.

[0102] The specific process of writing the above triplet values ​​into the corresponding leaf nodes of the state tree is as follows: After the current processing operation is completed and confirmed by the system, calculate the latest data content hash of the output data entity (based on the output data content after the operation is completed), append the operation identifier of this operation to the operation history digest, recalculate the operation history digest, take the source path hash as the source commitment field value, concatenate the three fields into the leaf node value, and write it into the leaf node position corresponding to the output data entity ID in the state tree. After writing, perform incremental hash recalculation on all path nodes affected by this leaf node update (all parent nodes from the updated leaf node along the tree path to the root node), and update the global State Root. Through the above triplet leaf structure, the state tree simultaneously carries the dual-track verifiability of the operation dimension (guaranteed by the data content hash and operation history digest) and the source dimension (anchored by the source commitment field value through the MAT path hash) within a single data structure. This enables any zero-knowledge proof for a specific data entity state to simultaneously cover the verification requirements of operation compliance and source compliance within the same proof, thus forming a complete cryptographically trusted traceability closed loop from the data generation source to the current operation result.

[0103] Example 5

[0104] In this embodiment, maintaining the set of confirmed operations using a cryptographic accumulator includes:

[0105] Based on the operation identifier after each data operation confirmation, the operation identifier is updated to the cryptographic accumulator to obtain the updated accumulator state.

[0106] Based on the updated accumulator state, a membership certificate is generated for the operation identifier. The generation and verification of the membership certificate are both completed within a constant time, resulting in the accumulator structure containing the accumulator state and the membership certificate, which is used by the auditor to verify the legality of the authorization certificate.

[0107] Specifically, firstly, a cryptographic accumulator is a cryptographic primitive capable of compressing a set of elements of arbitrary size into a single fixed-length digest value. Its core characteristic lies in supporting the generation of independently verifiable membership proofs for any set elements without expanding the complete set content, and the complexity of generating and verifying the proof is independent of the set size. In this invention, the specific responsibility of the cryptographic accumulator is to provide a compact cryptographic representation of a set of data operation events that have been confirmed by the system. This allows any auditor holding an authorization certificate to prove to the data subject within a constant time that the operation identifier corresponding to their authorization certificate indeed belongs to the confirmed legitimate operation set, without requiring the system to disclose any information about other operations in the set to the auditor.

[0108] An operation identifier is a unique cryptographic marker for a single data operation event. It is a fixed-length hash digest obtained by concatenating three fields: operation sequence number (a globally monotonically increasing integer used to identify the operation's position in time sequence), operation type identifier (an enumerated code with a value of one of three categories: circulation, use, or processing), and operation timestamp (recording the moment the operation was confirmed by the system). The hashing process of the operation identifier ensures its uniform distribution within the accumulator element space, preventing the accumulator's security from degrading due to the sequential regularity of the operation sequence number.

[0109] This embodiment employs a vector commitment cryptographic accumulator based on elliptic curve pairing. The accumulator state is represented as a group element on the elliptic curve group, initialized as the group's generator when the set is empty. Each time a new operation identifier is updated to the accumulator, the hash value of the current operation identifier is used as the update input. A scalar multiplication operation of the group element is performed internally within the accumulator, and the result is output as the new accumulator state. This update operation is incremental; that is, the new accumulator state depends only on the previous accumulator state and the current operation identifier, without reprocessing any elements in the historical operation set. This makes the update cost of the accumulator state completely independent of the historical size of the confirmed operation set. After each data operation is confirmed by the system (i.e., the operation record has been written to the state tree and the state root has been incrementally updated), the operation identifier of the operation is immediately extracted, and the above accumulator update process is executed to obtain the updated accumulator state reflecting the latest confirmed operation set. This state is persistently stored as a core field of the accumulator structure for subsequent member proof generation and audit verification.

[0110] Second, membership verification is one of the core functions provided by cryptographic accumulators. Its function is to generate a piece of auxiliary data (called witness value) for a specific element in the set, so that any verifier who has the current state of the accumulator can verify the validity of the witness value to confirm that the target element does indeed belong to the set of elements represented by the accumulator, and the verification process does not depend on the content of any other element in the set.

[0111] For a vector commitment accumulator based on elliptic curve pairing, the witness value of the membership proof for the operation identifier is a group element on the elliptic curve group. Its generation process utilizes the public parameters generated during the initialization phase (i.e., the public part of the structured reference string corresponding to the accumulator scheme), performs a specific polynomial division operation on the target operation identifier, and then evaluates the result on the elliptic curve group. The generation of the witness value only requires accessing the target operation identifier itself and the public parameters, without traversing other elements in the confirmed operation set. Therefore, the generation cost is constant time O(1), independent of the current size of the confirmed operation set. The verifier of the membership proof holds the current state of the accumulator (a single group element) and the operation identifier to be verified and its witness value. Verification is completed by performing one elliptic curve pairing operation, with a verification cost also constant time O(1).

[0112] In an auditing scenario, the accumulator structure is used as follows: When initiating an audit request, the auditor must submit the operation identifier corresponding to their authorization credential and a witness value generated by the system, declaring that the operation corresponding to the authorization credential has been confirmed in the system and included in the accumulator. Upon receiving the audit request, the data subject performs pairing verification on the operation identifier and witness value submitted by the auditor, based on the current accumulator state, and determines within a constant time whether the auditor's authorization credential belongs to the confirmed set of legitimate operations. If the verification passes, the data subject can confirm that this audit was initiated by a compliant auditor holding a legitimate authorization credential, and the auditor's authorization boundary is confirmed at the cryptographic level. If the verification fails, it indicates that the authorization credential held by the auditor does not come from the set of operations confirmed by the system, and the data subject can refuse to respond to this audit request, thereby constraining the legitimacy of the auditor's authorization at the cryptographic level and preventing expired or forged credentials from being used for unauthorized audits.

[0113] The accumulator structure comprises two core components: the current accumulator state value (reflecting a summary of all confirmed operations up to the current moment); and a pre-generated set of membership testimonies for each operation identifier included in the accumulator (generated synchronously by the system each time an accumulator update is performed and stored in association with the corresponding operation identifier). The accumulator structure is continuously and incrementally updated throughout the data space's lifecycle. Each time a new operation is confirmed, the corresponding operation identifier and membership testimonies are synchronously appended, forming a complete audit authorization verification infrastructure covering all confirmed operations throughout the entire lifecycle of the data space.

[0114] Example 6

[0115] In this embodiment, a hybrid proof structure is used to generate the single-operation proof for each data operation, including:

[0116] Based on compliance verification calculation for a single data operation, the compliance verification calculation is expressed as an execution trace, and the execution trace is decomposed into several independent calculation blocks. Each independent calculation block only loads the state tree path node, source commitment summary and operation parameters required by the current independent calculation block, resulting in multiple independent calculation blocks and local input data corresponding to each independent calculation block.

[0117] Based on the multiple independent computation blocks and the local input data, the corresponding polynomial commitment is calculated independently for each independent computation block, and a corresponding auxiliary accumulator is generated for each independent computation block. The polynomial commitments and auxiliary accumulators corresponding to each independent computation block are organized layer by layer through a tree-shaped evaluation structure to obtain a tree-organized polynomial commitment structure.

[0118] Based on the tree-structured polynomial commitment, a constant-order streaming scan is used to traverse and aggregate all independent computational blocks in the polynomial commitment structure, generating an inner-layer proof.

[0119] Based on the inner proof, the inner proof is encapsulated in the outer proof stage, and the state root before and after the operation and the source path hash are incorporated into the outer constraints to generate the single operation proof carrying the state root before and after the operation and the source path hash. The hybrid proof structure reduces the prover memory usage to the order of magnitude proportional to the square root of the number of operation steps.

[0120] Specifically, firstly, the execution trace is the core data structure of the STARK proof system for formally expressing the computation process. For the compliance verification computation of a single data operation, its complete computation process involves three interrelated sub-computations: The first is the Merkle path verification sub-computation, which starts from the corresponding leaf node of the state tree and performs hash aggregation layer by layer along the path node to verify that the final reconstruction result is consistent with the global State Root, so as to confirm that the state of the data entity involved in the operation has not been tampered with; the second is the source commitment consistency check sub-computation, which locates the path node corresponding to the entity involved in the operation in MAT, reconstructs the source path hash, and performs an equivalence comparison with the source commitment field value recorded in the leaf node to confirm that the source information of the data entity involved in the operation is still consistent with the initial source commitment when the operation occurs; the third is the operation rule constraint verification sub-computation, which substitutes the operation parameters of this operation into the R1CS constraint circuit of the corresponding operation type (transfer, use, or processing) to verify that the operation parameters meet all predefined compliance constraints.

[0121] The execution trace expands the three types of sub-computations into a step-by-step state transition sequence according to their computational dependencies. Each step records the current computational state (including a complete snapshot of the current step's input value, intermediate computation results, and output value). The total number of steps T in the execution trace is determined by the sum of the computational complexities of the three types of sub-computations. With a state tree depth of d, a MAT depth of m, and the number of R1CS constraints of c, T is directly proportional to a linear combination of d, m, and c. For high-frequency data flow scenarios (such as tens of thousands of operations per day in financial transactions), the value of T may reach hundreds of thousands. If the complete execution trace is fully loaded into the prover's memory, the memory consumption will be linearly positively correlated with T, far exceeding the local memory limit of the edge data nodes.

[0122] To address the aforementioned memory bottleneck, the complete execution trace is decomposed into several independent computational blocks based on computational dependencies. The principle for dividing these independent computational blocks is as follows: each computational block corresponds to a continuous subsequence of steps within the execution trace. Strict data dependencies exist between computational steps within this subsequence, while different computational blocks are only associated through limited interface values ​​at block boundaries (i.e., the output value of the last step in the current block and the input value of the first step in the next block). The intermediate computational states within a block are not visible to other blocks. Based on this principle, the Merkle path verification subcomputation is divided into d independent computational blocks according to the path hierarchy (each block corresponds to the reconstruction computation of a single-layer hash node on the path), the source commitment consistency check subcomputation is divided into m independent computational blocks according to the MAT path hierarchy, and the operation rule constraint verification subcomputation is divided into several independent computational blocks according to the natural grouping of R1CS constraints. Each independent computation block loads only the local input data necessary to complete its computation: for the Merkle path verification block, the local input data is the hash value of the current layer path node and the hash values ​​of its adjacent sibling nodes; for the source commitment consistency check block, the local input data is the hash value of the current MAT path layer node and the source commitment digest (a fixed-length hash compressed representation of the source commitment, not the full source information); for the operation rule constraint verification block, the local input data is a subset of the operation parameters involved in the current constraint group. This localized loading strategy ensures that the memory footprint of a single independent computation block is proportional only to the number of steps in the block, rather than proportional to the total number of steps T in the complete execution trace.

[0123] Secondly, polynomial commitments are a core tool in the STARK proof system used for cryptographically binding execution trace data. Within the STARK proof framework, each column of the execution trace (corresponding to a sequence of values ​​for a certain type of intermediate state variable as computation steps) is considered a set of values ​​for a polynomial at a specific set of evaluation points. A polynomial commitment is constructed by hashing the coefficient vector of this polynomial and organizing the hash values ​​at the evaluation points using a Merkle tree. Polynomial commitments compress the execution trace data into a fixed-size commitment value, which is cryptographically bound to the content of the execution trace: any modification to data at any position in the execution trace will cause a change in the corresponding polynomial commitment value, and a valid polynomial commitment cannot be regenerated without possessing the modified data.

[0124] The auxiliary accumulator is an auxiliary data structure introduced in this embodiment for verifying the consistency of interface values ​​between independent computation blocks. Since the disassembly of independent computation blocks disrupts the integrity and continuity of the original execution trace, a mechanism is needed to verify that the state values ​​of adjacent blocks at the interface do indeed satisfy the correct transmission relationship without fully loading adjacent computation blocks. The auxiliary accumulator records the cumulative hash state of the output value of the last step for each independent computation block. By using the output value of the auxiliary accumulator of the previous computation block as the initial input value of the auxiliary accumulator of the next computation block, the interface consistency constraints of adjacent computation blocks are folded into the state transition relationship of the auxiliary accumulator, thereby verifying the correctness of state transmission at the interface without simultaneously holding the complete data of two adjacent computation blocks.

[0125] For each independent computation block, multinomial commitment computation is performed independently based on its local input data (constructing a multinomial Merkle tree corresponding to the execution trace of this block), and the auxiliary accumulator corresponding to this block is initialized (the hash of the auxiliary accumulator output value of the previous block and the first step input value of this block is combined as the initial value of the auxiliary accumulator of this block). After completing the multinomial commitment and auxiliary accumulator computation for each block, the multinomial commitment root hash and auxiliary accumulator state values ​​of all independent computation blocks are organized layer by layer in a binary tree structure: the leaf layer is the combined hash of the multinomial commitment root hash and auxiliary accumulator state value of each independent computation block, and the parent node layer performs pairwise hash aggregation on the combined hash of adjacent child nodes in turn, advancing layer by layer until the root is formed, resulting in a tree-organized multinomial commitment structure. The depth of the tree structure is logarithmic to the base 2 of the total number of independent computation blocks, which is much smaller than the total number of independent computation blocks, laying the structural foundation for the subsequent implementation of the constant-order streaming scan strategy.

[0126] Next, the inner proof is the output of the STARK proof stage in the hybrid proof structure of this invention. Its content is a STARK proof covering the compliance of the complete execution trace (i.e., the consistency of all independent computation blocks and their interfaces), used for circuit encapsulation in the subsequent outer Groth16 stage. The generation of the inner proof requires completing the following two core verifications: first, the validity of the execution trace within each independent computation block (i.e., the computation steps within each block satisfy the predefined constraint polynomial); second, the consistency of state values ​​at the interfaces of adjacent independent computation blocks (i.e., the output value of the auxiliary accumulator of the previous block is equal to the input value of the auxiliary accumulator of the next block).

[0127] The constant-order streaming scan strategy leverages the hierarchical organization of the tree-structured polynomial commitment structure, processing layer by layer. Each scan loads only the node data of the current tree layer into memory. After completing the STARK low-degree test and constraint polynomial evaluation for that layer, the intermediate proof result of the current layer (i.e., the aggregated polynomial commitment and auxiliary accumulator aggregation state of the current layer) is written to external memory, and the memory occupied by the current layer is released before loading the next layer. Since the number of layers in the tree structure is the logarithm to the base 2 of the total number of independent computation blocks, the total number of scans in the entire traversal process is logarithmic. Each scan only needs to hold the node data of the current tree layer in memory simultaneously (the number of which is the total number of computation blocks divided by the coefficient of the current level). The peak memory usage of a single scan is on the order of the square root of the total number of independent computation blocks. After completing the traversal and constraint verification of all independent computation blocks in the tree-structured polynomial commitment structure through the above constant-order streaming scan, the intermediate proof results of each layer are combined to generate the final inner-layer STARK proof. The size of the inner-layer proof is proportional to the logarithm of the total number of independent computation blocks.

[0128] Overall, the sublinear spatial block-based streaming STARK proof generation mechanism implemented in this step, through the synergy of execution trace block division, tree-structured commitment organization, and hierarchical streaming scanning, reduces the peak memory usage of the inner STARK prover from the order of O(T), which is linearly positively correlated with the total number of execution trace steps T, to O(T). This allows memory-constrained edge data nodes (such as industrial edge computing devices with hundreds of megabytes of available memory) to generate valid inner STARK proofs locally for compliance verification calculations of complex operations with hundreds of thousands of steps, without having to upload execution trace data to a high-computing cloud for centralized processing. This fundamentally eliminates the architecture-centralized bottleneck in the proof generation process under high-frequency data flow scenarios.

[0129] Finally, the hybrid proof structure is a two-layer nested proof architecture designed in this invention to simultaneously address the dual requirements of prover memory efficiency and proof size simplicity. Its design logic is as follows: The STARK proof system possesses sublinear space proof generation capabilities, but the size of the generated proof is proportional to the logarithm of the total number of execution steps, and continues to grow with increasing operational complexity, failing to meet the requirement of fixed-size proof input format for subsequent recursive folding and aggregation; the Groth16 proof system can generate proofs of constant size (approximately 200 bytes), but its prover memory consumption is linearly positively correlated with the number of R1CS constraints, and directly applying Groth16 to the full compliance verification computation leads to a recurrence of memory bottlenecks. The hybrid proof structure achieves both memory efficiency and proof simplicity by using STARK in the inner layer (responsible for generating proofs for high-memory-efficiency full compliance verification computation) and Groth16 in the outer layer (responsible for constant-size encapsulation of the inner STARK proof).

[0130] In the outer proof phase, the verification logic of the inner STARK proof (including polynomial commitment validity check, FRI low-degree test verification, and execution trace boundary condition check) is expressed as a Groth16-processable R1CS arithmetic circuit. The pre-operation state root (the global State Root of the Merkle state tree before operation), the post-operation state root (the global State Root after operation execution and updating the state tree), and the source path hash (the joint source path hash of the data entities involved in this operation in MAT) are included in the constraints of the outer arithmetic circuit as public input ports of the circuit. In addition to the arithmetic representation of the inner STARK verification logic, the outer Groth16 circuit also includes the following additional constraints: the pre-operation and post-operation state roots must be consistent with the start and end state values ​​of the Merkle path verification sub-computation in the inner STARK execution trace, and the source path hash must be consistent with the final output value of the source commitment consistency check sub-computation in the inner STARK execution trace. The above constraints ensure that the public input values ​​in the outer Groth16 proof are cryptographically bound to the computational content covered by the inner STARK execution trace, preventing the prover from independently replacing the public input values. Using the proof key pk generated in step S2-4, the Groth16 proof generation algorithm is executed on the outer arithmetic circuit, outputting a constant-size outer zkSNARK proof, which is a single-operation proof carrying the state roots before and after the operation and the source path hash. The size of the single-operation proof is fixed at approximately 200 bytes, not changing with the increase in computational complexity of operation compliance verification, satisfying the format requirements of the fixed-size proof input for the recursive folding aggregation in subsequent step S4. The overall hybrid proof structure limits the peak memory usage of the prover to O(...). The value is on the order of magnitude ), where T is the total number of execution steps in a single operation compliance verification calculation.

[0131] Example 7

[0132] In this embodiment, the outer proof stage of the hybrid proof structure circuitizes the verification logic of the inner proof to generate the single-operation proof of constant size, including:

[0133] Based on the inner proof, the verification logic of the inner proof is expressed as an arithmetic circuit, and the state root before and after the operation, the source path hash of the entity involved in the operation, and the operation rule type identifier are used as the public input ports of the arithmetic circuit to obtain the arithmetic circuit representation.

[0134] Based on the arithmetic circuit representation, the state roots before and after the operation, the source path hash of the entity involved in the operation, and the operation rule type identifier are used as public inputs. The proof generation algorithm is executed using the proof key to obtain a single operation proof of constant size.

[0135] Specifically, firstly, the circuitization of the verification logic for the inner STARK proof is a core technical step in the outer Groth16 encapsulation stage. Essentially, it transforms the STARK verifier program into an equivalent arithmetic circuit representation. In its original form, the STARK verifier program is a deterministic algorithm with parameters including the inner STARK proof, the execution trace polynomial commitment root, and the public input. Its computation process includes hash function calls, finite field arithmetic operations, and random sampling verification. Transforming this verifier program into an arithmetic circuit requires mapping each type of basic operation in the program to arithmetic gate circuits over a finite field: hash function calls are implemented by introducing an arithmetic representation of a circuit-friendly hash function (such as the Poseidon hash function); finite field arithmetic operations are directly mapped to a combination of addition and multiplication gates; and conditional branching logic is transformed into a branchless arithmetic constraint sequence by introducing Boolean intermediate variables and corresponding selection constraints.

[0136] The FRI low-degree test verification logic in the STARK verifier program is the largest part of the circuitization process in terms of its representation in the arithmetic circuit: each round of the FRI protocol query (verifying the consistency between the value of the polynomial at a specific evaluation point and the folded polynomial) needs to be represented in the circuit as the corresponding polynomial value constraint and hash path verification constraint. The total number of constraints is proportional to the product of the number of FRI query rounds and the number of queries per round. In terms of parameter selection, the number of FRI query rounds is proportional to the logarithm of the total number of steps T in the inner STARK execution trace, and the number of queries per round is determined by the security parameter (usually 40 to 80 times to meet the 128-bit security strength requirement). Therefore, the total number of constraints in the FRI low-degree test verification circuit is on the order of O(log T), which can be completed within the constraint scale that Groth16 can handle.

[0137] The operation rule type identifier is a public marker field introduced in this invention to support the proof verifier in quickly identifying the rule type of the current operation without performing inner proof verification. Its value is one of three predefined enumerated values, corresponding to flow operations, use operations, and processing operations, respectively. The enumeration encoding method is uniformly agreed upon during the data space initialization phase. Setting the operation rule type identifier as the public input port of the outer arithmetic circuit allows the verifier, upon receiving a single operation proof, to directly read the operation rule type identifier from the public input without parsing the inner STARK proof content. This allows for quick determination of the applicable rule system for the current operation, and accordingly, selection of the corresponding verification key to execute the outer Groth16 proof verification, avoiding unnecessary logical branch overhead on the verifier's side.

[0138] In the configuration of the public input ports of the outer arithmetic circuit, the pre-operation state root, post-operation state root, source path hash, and operation rule type identifier are mapped to independent public input lines (wires). Internally, these public input lines are bound to the corresponding output lines of each submodule of the inner STARK verification logic through equivalence constraints: the pre-operation state root public input line is bound to the initial state variable output line of the inner STARK execution trace Merkle path verification sub-computation; the post-operation state root public input line is bound to the final state variable output line of the Merkle path verification sub-computation; the source path hash public input line is bound to the final output line of the source commitment consistency check sub-computation; and the operation rule type identifier public input line is bound to the type flag variable output line of the operation rule constraint verification sub-computation. These binding constraints ensure that any proof that can pass the outer Groth16 verification satisfies cryptographic consistency between its public input values ​​and the actual computational content covered by the inner STARK execution trace, resulting in a complete R1CS representation of the outer arithmetic circuit.

[0139] Second, the Groth16 proof generation algorithm takes the R1CS representation of the outer arithmetic circuit, the proof key pk, the public input vector (a finite field element representation of the pre-operation state root, post-operation state root, source path hash, and operation rule type identifier) ​​and the private input (witness value, which contains all fields of the inner STARK proof and the assignment of auxiliary intermediate variables introduced in the outer arithmetic circuit) as input, and outputs a constant-size zkSNARK proof consisting of three elliptic curve group elements, of which two group elements come from the first group G1 (approximately 48 bytes each) and one group element comes from the second group G2 (approximately 96 bytes), totaling approximately 200 bytes.

[0140] The Groth16 proof generation algorithm internally performs the following main operations: First, it performs polynomial assignment calculations on the private input (witness value) to generate a polynomial witness that satisfies all R1CS constraints of the outer arithmetic circuit. Then, based on the polynomial witness and the structured reference string encoded in the proof key pk, it performs multi-scalar multiplication (MSM) calculations on the elliptic curve group to generate three target group elements, constituting the final Groth16 proof. The computational cost of Groth16 proof generation is mainly concentrated in the multi-scalar multiplication stage, and its complexity is linearly related to the number of R1CS constraints of the outer arithmetic circuit (i.e., proportional to O(log T)). This is far lower than the computational cost of directly applying Groth16 to the complete compliance verification calculation (where the number of constraints is directly linearly related to T), making the outer proof generation within an acceptable range in terms of both memory and time overhead.

[0141] The final generated single-operation proof is presented in a constant size of approximately 200 bytes, containing three elliptic curve group elements (forming the Groth16 proof ontology) and public input fields (pre-operation state root, post-operation state root, source path hash, and operation rule type identifier). The public input fields and the Groth16 proof ontology together constitute the complete format of the single-operation proof. When performing single-operation proof verification, the verifier uses the verification key vk, the public input fields, and the Groth16 proof ontology as input, and performs one elliptic curve pairing operation (the Groth16 verification algorithm performs a fixed three pairing operations) to complete the verification. The verification cost is constant time and does not depend on the original complexity of the operation compliance verification computation. The fixed format and constant size of the single-operation proof satisfy the format consistency requirements of the batch proof input in the recursive folding aggregation stage, supporting efficient batch aggregation processing of any number of single-operation proofs.

[0142] Example 8

[0143] In this embodiment, the step of employing a recursive folding mechanism to incorporate the linking relationship between the state roots before and after the operation into the folding constraints, generating an aggregate proof, and constructing the state root chain includes:

[0144] Based on two adjacent single-operation proofs, the validity of the two adjacent single-operation proofs is verified, and the linking relationship between the post-operation state root carried by the previous operation proof and the pre-operation state root carried by the next operation proof is incorporated into the folding constraint to obtain the intermediate aggregate proof.

[0145] Based on the intermediate aggregation proof, the operation is recursively folded layer by layer according to the operation sequence. Each fold retains the temporal integrity of the operation sequence, resulting in the aggregation proof and the state root sequence carried by each operation proof during the layer-by-layer folding process.

[0146] Based on the state root sequence, the complete evolution path from the initial state root to the final state root is recorded in the order of operation timing to form the state root chain. Each node in the state root chain serves as a locatable anchor point for subsequence auditing.

[0147] Specifically, firstly, the recursive folding mechanism is the core technical means of this invention for batch compressing any number of single-operation proofs into a single aggregate proof. Its basic principle comes from the idea of ​​the Incrementally Verifiable Computation (IVC) framework: the task of verifying the full proof of an operation sequence is decomposed into a series of pairwise folding steps. Each folding step merges the currently aggregated intermediate proof with the next single-operation proof into a new intermediate aggregate proof, so that the final generated single aggregate proof can be verified by the verifier at a constant cost to confirm the full compliance of the entire operation sequence, without having to verify each single-operation proof independently.

[0148] Folding constraints are a key design feature that distinguishes recursive folding mechanisms from simple proof batch verification schemes. Simple batch verification schemes only verify the validity of each individual operation proof, failing to constrain the state consistency between adjacent operations; the temporal order of operations can be arbitrarily rearranged without being detected. Folding constraints, in addition to verifying the validity of two adjacent individual operation proofs, add a cross-proof temporal consistency constraint: the previous operation proof (denoted as Pi)... k The value of the post-operation state root field in the public input of ) must be consistent with the proof of the subsequent operation (denoted as Pi). {k+1} The values ​​of the state root fields in the public input of the operation must be completely equal before the operation. The cryptographic meaning of this constraint is that the global state of the data space after the previous operation is completed (uniquely represented by the Merkle state tree root hash) must be exactly the initial state of the data space when the next operation is initiated. Any unproven state change inserted between adjacent operations or any reordering of the operation execution order will cause the state root link relationship between adjacent proofs to not satisfy the folding constraint, thus generating invalid intermediate aggregation proofs in the folding process, which will be cryptographically detected during the verification phase.

[0149] The specific folding implementation is based on the Nova folding scheme (or its variants). The Nova folding scheme encodes the verification circuits of two Groth16 proofs and the cross-proof state root link constraint together into a single Relaxed R1CS instance. A single random linear combination operation folds the two Relaxed R1CS instances into a single new Relaxed R1CS instance. During the folding process, a random challenge value (derived from the commitment values ​​of both parties through hashing, ensuring the binding nature of the folding process) is introduced. The resulting new Relaxed R1CS instance is the intermediate aggregate proof. The size of the intermediate aggregate proof is comparable to that of a single operation proof (approximately several hundred bytes), and does not increase with the number of proofs folded, thus fixing the cost of each step in the recursive folding process. The total folding cost is linearly related to the length of the operation sequence.

[0150] During the first fold, the two earliest single-operation proofs Pi1 and Pi2 in the operation sequence are taken as fold inputs: Pi1 and Pi2 are verified to satisfy the outer Groth16 verification equation (i.e., their respective compliance verification calculations yield valid proofs). Simultaneously, it is checked whether the post-operation state root in the public input of Pi1 is equal to the pre-operation state root in the public input of Pi2. The above verification logic and state root link constraints are encoded into the folding circuit, and a Nova folding operation is performed to obtain the intermediate aggregate proof Pi representing the joint verification state of Pi1 and Pi2. agg,2 Pi agg,2 The public input inherits the pre-operation state root of Pi1 (as the starting state root of the aggregated subsequence) and the post-operation state root of Pi2 (as the current final state root of the aggregated subsequence).

[0151] Next, the intermediate aggregation obtained from the first step of folding is used to prove Pi. agg,2 Based on this, continue with the next single operation in the operation sequence to prove that Pi3 performs a second folding operation: Pi... agg,2 Considered as the aggregate state representing the processed subsequence of operations (Pi1 to Pi2), when Pi3 is folded, the folding constraint requires Pi... agg,2 The current final state root (i.e., the state root after the operation of Pi2) is equal to the state root before the operation of Pi3. After verifying that the above constraint holds, a Nova folding operation is performed to obtain the intermediate aggregation proof Pi. agg,3 The initial state root in its public input remains the pre-operation state root of Pi1, and the final state root is updated to the post-operation state root of Pi3. Following the above pattern, the operation proceeds step by step along the timing direction. At the k-th step of folding, Pi... agg,k With Pi {k+1} Perform a fold, the fold constraint requires Pi agg,k The final state root and Pi {k+1}If the root states are equal before the operation, Pi is obtained after folding. agg,{k+1} Its initial state root remains unchanged (always the pre-operation state root of Pi1), and the final state root is updated to Pi. {k+1} The root state after the operation.

[0152] The reason why temporal integrity is preserved in the above-mentioned layer-by-layer recursive folding process is that the folding constraint requires that the final state root of the current aggregate proof be exactly matched with the pre-operation state root of the folded proof at each fold. This constraint forms a strict and ordered transmission of the state root link relationship throughout the entire operation sequence. The position of any operation proof in the folded chain can only correspond to its true position in the actual operation sequence. Proofs that are out of order or skipped cannot satisfy the folding constraint in their proper positions and therefore cannot be legally included in the folded chain. Thus, at the cryptographic level, it is forcibly guaranteed that the operation subsequence represented by the final aggregate proof is completely consistent with the original operation sequence.

[0153] During the folding process, prove Pi for each single operation in the operation sequence. k (k ranges from 1 to n), extract and record the following two state root values ​​from its public input: the state root SR before the operation. {k,pre} (Pi) k The global state root of the data space before execution and the state root SR after the operation {k,post} (Pi) k The global state root of the data space after execution). Arrange the above state root values ​​in the order of operation timing (k=1 to n) to obtain a complete state root sequence containing 2n state root values, where SR {1,pre} SR is the initial state root of the entire operation sequence. {n,post} The final state root of the entire operation sequence is given, and adjacent operations are proven to satisfy SR. {k,post} equals SR {k+1,pre} The linking relationships are enforced by the folding constraint. After all n single-operation proofs have been folded layer by layer, a single aggregate proof Pi covering the compliance of the complete operation sequence is obtained. agg Its size is comparable to that of a single operation and does not increase with the increase of n.

[0154] Finally, the Root Chain is an ordered chain structure formed by organizing the state root sequence extracted during the folding process according to the operational time sequence. Each node records the global State Root value of the Merkle state tree in the data space at a certain moment, and the state transition between adjacent nodes corresponds to a cryptographically proven compliant operation event. The design goal of the Root Chain is to provide a fine-grained temporal anchor system for end-to-end compliance certificates, enabling auditors to accurately locate the audit scope to any subsequence of operations without having to replay the entire operation history.

[0155] The specific process for constructing the state root chain is as follows: The complete state root sequence (SR) obtained in step S8-2 is... {1,pre} ,SR {1,post} SR {2,pre} SR {2,post} , ..., SR {n,pre} SR {n,post} Deduplication and merging are performed, since adjacent operations satisfy SR. {k,post} equals SR {k+1,pre} After merging, a continuous sequence of state root nodes (SR) is formed. {1,pre} SR {1,post} =SR {2,pre} SR {2,post} =SR {3,pre} , ..., SR {n,post} This sequence contains n+1 nodes, and the order of the nodes strictly corresponds to the temporal order of the operation sequence. Organizing this ordered node sequence into a chain structure forms the state root chain, with the head node being the initial state root SR. {1,pre} The tail node is the final state root SR. {n,post} The value of the k-th internal node (k ranges from 1 to n-1) in the chain is SR. {k,post} Its position in the chain corresponds to the data space state time after the k-th operation in the operation sequence is completed and before the (k+1)-th operation is initiated.

[0156] The technical implementation method of using each node in the state root chain as a locating anchor point for subsequence auditing is as follows: When the auditor needs to audit a certain subsequence in the operation sequence (such as the i-th operation to the j-th operation, i≤j≤n), it only needs to locate the (i-1)-th node (with a value of SR) in the state root chain. {i,pre} ) and the j-th node (with value SR) {j,post} The data subject uses these anchor points as the start and end points for the audit of the subsequence. Based on these anchor points, the data subject performs local recursive folding only for the proofs of the i-th to j-th single operations, generating a local aggregate proof covering the subsequence of operations. At the same time, it provides the Merkle path proof of the corresponding node in the state root chain (proving that the node does indeed belong to the complete state root chain recorded in the end-to-end compliance certificate). This allows for the completion of compliance audits of the specified subsequence without disclosing operational information outside the subsequence to the auditor, achieving precise location of the audit scope and minimal disclosure of audit content.

[0157] Pi will aggregate proof aggThe Manifest Root and the State Root Chain are jointly encapsulated into an end-to-end compliance certificate. The Manifest Root ensures that the source compliance of the end-to-end compliance certificate can be traced back to the source of the data, while the State Root Chain ensures that the compliance of any subsequence of operations can be independently extracted and verified from the end-to-end compliance certificate, and the aggregated proof Pi... agg Ensuring the compliance of the entire sequence of operations is cryptographically backed by a constant-size proof, the three elements together form an end-to-end cryptographic trust loop covering the compliance of the entire data lifecycle.

[0158] Example 9

[0159] In this embodiment, the process of the data subject, the regulator, and the system layer each generating corresponding predicate proofs locally and submitting them to a joint verification program for parallel verification includes the data subject generating compliance predicate proofs for the operation content locally, which includes:

[0160] Based on the operation record corresponding to the specified operation and the end-to-end compliance certificate, a compliance certificate result is generated to prove that the specified operation complies with the established operation rules and does not expose data content.

[0161] Based on the accumulator structure and the authorization credentials held by the auditing party initiating the audit, the legality of the authorization credentials within the confirmed operation set maintained by the accumulator structure is verified to obtain the auditing party authorization verification sub-predicate result.

[0162] The compliance proof result of the operation content and the audit authorized verification sub-predicate result are combined and encapsulated in the same zero-knowledge proof to obtain the compliance predicate proof of the operation content with the audit authorized verification sub-predicate result.

[0163] Specifically, firstly, the compliance proof result of the operation content is a local zero-knowledge proof generated by the data subject for a single operation specified by the auditor. It requires cryptographically proving that the following two propositions are true simultaneously, without disclosing any original content of the data entity to the auditor or the joint verification procedure: Proposition 1 is that the specified operation does indeed exist in the operation sequence covered by the end-to-end compliance certificate, that is, the single operation proof corresponding to the operation identifier of the specified operation has been included in the aggregate proof Pi. agg In the recursive folding chain; Proposition 2 is that the operation parameters of the specified operation satisfy all the established operation rule constraints applicable to the operation type, that is, the outer Groth16 constraint circuit corresponding to the single operation proves that it is valid under the assignment of the operation parameters of the specified operation.

[0164] The proof of Proposition 1 is achieved as follows: The data subject uses the state root chain in the end-to-end compliance certificate as an index to locate the start and end anchor nodes (SRs) corresponding to the specified operation in the state root chain. {k,pre} With SR {k,post}), and then prove Pi for the single operation corresponding to the specified operation. k Perform locality verification and generate proof Pi. k A zero-knowledge proof that the pre-operation state root and the post-operation state root in the public input are consistent with the corresponding anchor node values ​​in the state root chain, and also provides Pi. k The local folding path proof at the position in the recursive folding chain (similar to the structure of the Merkle path proof, proving Pi...) k Pi was indeed included in the final aggregation proof. agg In the folded chain, the two proofs above are combined into a sub-proof of Proposition 1. The proof of Proposition 2 is achieved by reusing Pi. k Pi itself k (The proof generation phase has already proven the satisfaction of the specified operation with the applicable operation rule constraint circuit.) The data body is represented by Pi. k Using the corresponding verification key vk as input, perform Groth16 verification on the local machine to confirm Pi. k After it becomes effective, Pi k Combined with the verification result, it serves as a sub-proof of Proposition 2.

[0165] Throughout the entire process of generating the compliance proof result for the operational content, the original content of the data entity (dataset field values, personal information, and other sensitive data) always exists as the private input of the zero-knowledge proof circuit in the local memory of the data subject and does not appear in any form in the output content of the compliance proof result for the operational content (proof ontology, public input fields, or auxiliary statements), thus satisfying the zero-knowledge requirement—that is, the joint verification procedure and the auditor, while holding the compliance proof result for the operational content, cannot extract any information about the original content of the data entity from it.

[0166] Secondly, the auditor's authorization verification of the sub-predicate result is a concrete manifestation of the cryptographic mechanism in this invention that enables data subjects to reverse-verify the legitimacy of the auditor's authorization when they are audited. In the traditional audit framework, the auditor has a one-way authorization advantage over the auditee, and the auditee cannot verify the authenticity and validity of the auditor's authorization credentials without relying on a trusted third party. This invention incorporates the verification of the legitimacy of the auditor's authorization into the predicate proof generated locally by the data subject, enabling the data subject to actively verify the auditor's authorization within the same cryptographic framework, thus eliminating the one-way asymmetry of audit power at the mechanism level.

[0167] The specific verification process is as follows: When initiating this audit request, the auditor must submit the operation identifier value of its authorization certificate and the member proof witness value pre-generated by the system when the operation identifier is included in the accumulator (accumulator member proof generation mechanism). After receiving the above information, the data subject uses the current accumulator state value, the operation identifier submitted by the auditor, and the member proof witness value as inputs to execute the accumulator member proof verification algorithm based on elliptic curve pairing (completed in constant time O(1)) to determine whether the operation identifier corresponding to the auditor's authorization certificate belongs to the confirmed operation set represented by the accumulator. If the verification passes, the data subject generates a zero-knowledge proof, which can prove to the joint verification program that the data subject has successfully verified that the auditor's authorization certificate does indeed belong to the confirmed operation set, and that the verification conclusion is valid under the condition of not exposing the specific content of the operation identifier (i.e., not exposing the plaintext information of the authorization certificate), and obtains the audit authorization verification sub-predicate result. If the verification fails, the data subject refuses to continue generating the operation content compliance proof result and directly reports the audit authorization verification failure to the joint verification program, and the joint verification program rejects this audit request accordingly.

[0168] The introduction of the audit authority's authorization verification sub-predicate result enables the audit behavior itself to be incorporated into a verifiable cryptographic record: each time an audit occurs, the compliance predicate proof of the operation content generated by the data subject contains a cryptographic confirmation of the legality of the audit authority's authorization. This confirmation is submitted to the joint verification procedure record, forming a traceable credential for this audit behavior, thus realizing the cryptographic traceability of the audit behavior itself.

[0169] Finally, combination encapsulation refers to incorporating two independently generated sub-predicate proofs into the same zero-knowledge proof framework for joint constraint, making the combined predicate proof indivisible: when the joint verification procedure verifies the operation content compliance predicate proof, it must simultaneously confirm that the operation content compliance proof result and the audit-authorized verification sub-predicate result are both valid in the same proof context. Any act of submitting one of them separately or replacing and splicing the content of the two results from different audit request contexts will cause the verification of the combined predicate proof to fail.

[0170] The specific implementation of the encapsulation adopts a recursive proof combination scheme: An encapsulation circuit is constructed using the verification logic of the operation content compliance proof result and the audit authorization verification sub-predicate result as sub-circuits. The constraint condition of the encapsulation circuit is that the verification results of both sub-circuits are simultaneously true. A binding constraint is introduced into the encapsulation circuit—requiring that the two sub-circuits share the same audit request context identifier (derived from the combination of the timestamp of this audit request, the audit identity hash, and the specified operation identifier hash), ensuring that the operation content compliance proof result and the audit authorization verification sub-predicate result come from the same audit request context, preventing cross-context splicing attacks. Zero-knowledge proof generation is performed on the encapsulation circuit, and the output single proof is the operation content compliance predicate proof with the audit authorization verification sub-predicate result. This predicate proof, generated locally by the data subject, is submitted simultaneously to the joint verification program for parallel verification, along with the audit behavior compliance predicate proof generated locally by the regulator and the audit record generated locally at the system level.

[0171] The core design value of the multi-party parallel verification structure lies in the fact that the three types of predicate proof generators (data subject, regulator, and system layer) each independently generate their predicate proofs locally without exchanging private data. Furthermore, all three types of predicate proofs are simultaneously submitted to the joint verification program for parallel verification. An invalid predicate proof will cause the joint verification program to reject the end-to-end compliance certificate verification. This parallel verification structure eliminates the influence of the first verifier on subsequent verification results in chain-dependent verification models. Within a single cryptographic framework, it simultaneously achieves the synergy of three objectives: data subject privacy protection, effective regulatory auditing, and traceability of the audit process itself. This breaks the one-way information asymmetry advantage of the auditor over the auditee in traditional auditing frameworks.

[0172] Example 10

[0173] In this embodiment, the data subject, the regulator, and the system layer each locally generate corresponding predicate proofs and submit them to a joint verification procedure for parallel verification. Selective disclosure is then performed based on the auditor's authority level, including:

[0174] Based on the permission level corresponding to the authorization certificate held by the auditor, the permission level is determined to be a global supervisor, a restricted authorized auditor, or an unauthorized party, thus obtaining the permission level determination result.

[0175] Based on the permission level determination result, when the permission level is a global supervisor, the verifiable confirmation of the operation execution entity type and operation type is disclosed to the global supervisor; when the permission level is a restricted authorization auditor, only the operation compliance confirmation is disclosed to the restricted authorization auditor without disclosing the identity of the execution entity; when the permission level is an unauthorized party, only the unauthorized party is allowed to verify the validity of the aggregated proof; thus obtaining a selective disclosure result matching the permission level determination result.

[0176] Specifically, firstly, the hierarchical access control is an authorization management concept introduced in this invention to achieve hierarchical and controllable disclosure of audit information. Its core design idea is that different types of auditors have different legitimate knowledge requirements for data operation information based on their roles and functions in the data space governance system. While meeting the legitimate knowledge requirements of each level, cryptographic mechanisms should be used to ensure that auditors at each level cannot obtain additional information beyond their authorized scope, thereby maximizing the protection of data subject privacy while achieving effective supervision.

[0177] The permission hierarchy is uniformly defined by the data space management during the system initialization phase, and includes three preset levels. The definitions of each level and the corresponding authorization certificate issuance rules are as follows: The global supervisory level corresponds to authoritative institutions with top-level supervisory functions for the data space (such as government regulatory agencies or industry self-regulatory organizations). Their authorization certificates are directly issued by the root trust institution of the data space (equivalent to the root CA in the PKI system). The scope of authorization covers all operation types and all data entities within the data space, and the validity period of the authorization is bound to the operating license period of the data space; The restricted authorization auditing level corresponds to institutions with auditing needs for specific business scenarios (such as compliance departments or external auditing institutions). The authorization certificate is issued by the data space management party according to specific business needs. The scope of authorization is clearly defined in the authorization certificate (including the set of operation types allowed to be audited, the time window allowed to be audited, and the subset of data entities allowed to be audited). Audit requests outside this scope will not be accepted by the joint verification procedure. The level without an authorized party corresponds to an entity that does not hold any valid audit authorization certificate. It is allowed to perform public verification of the mathematical validity of the aggregate proof (the verification key vk is a public parameter), but it is prohibited from obtaining any operation content, the identity of the executing entity, or compliance details. This level is mainly for external observer roles that conduct public transparency verification of the overall compliance of the data space.

[0178] During the authorization level determination phase of the joint verification procedure, the authorization credentials submitted by the auditor are classified according to their level through the following steps: First, the cryptographic signature of the authorization credential is verified to confirm that the authorization credential was issued by an authorized institution (root trust institution or data space manager) and has not been tampered with; second, the membership proof verification of the operation identifier corresponding to the authorization credential is performed in the accumulator structure to confirm that the authorization credential is valid within the set of legal operations already confirmed by the system (i.e., the authorization credential has not expired and has not been revoked by the system); then, the authorization level field embedded in the authorization credential is parsed, and combined with the hierarchical affiliation of the issuing institution (authorization credentials issued by the root trust institution belong to the global regulatory level, and authorization credentials issued by the data space manager belong to the restricted authorization auditor level), the authorization level determination result is obtained. If the authorization credential signature verification fails, the accumulator membership proof verification fails, or the authorization credential does not contain a valid authorization level field, the auditor is classified as an unauthorized party.

[0179] Secondly, selective disclosure is an attribute-level information disclosure mechanism based on zero-knowledge proofs. Its technical principle is as follows: the information fields contained in the end-to-end compliance certificate are organized hierarchically according to the sensitivity of the information. Corresponding selective disclosure proof circuits are constructed for auditors at different permission levels. Each circuit only sets the information fields authorized to be obtained at the current permission level as public inputs, while the remaining sensitive information fields are kept as private inputs and protected by zero-knowledge constraints. This ensures that auditors at each level can only obtain information content that matches their permission level through the public input fields of the selective disclosure proof, and cannot infer any sensitive information other than the public inputs by analyzing the proof ontology.

[0180] When the authorization level determination result is global regulator, the joint verification procedure generates a selective disclosure certificate at the global regulator level. The public input of this certificate includes an operation execution entity type field (marking which type of business entity the execution entity of this operation belongs to, such as a predefined type marker, such as a commercial bank business department or a cooperative financial institution, using type enumeration coding rather than specific identity identifiers to avoid directly exposing personal identity information that can be linked to natural persons at the regulatory level) and an operation type field (marking an enumeration code that the operation belongs to one of the three categories: circulation, use, or processing). The joint verification procedure executes the generation of the corresponding certificate circuit and outputs a verifiable confirmation result. The global regulator can verify the authenticity of the above two field values ​​by verifying this certificate (that is, the two field values ​​do come from a valid end-to-end compliance certificate, rather than being arbitrarily fabricated by the auditee). At the same time, it cannot obtain the original content of the data entity, the specific values ​​of the operation parameters, or the precise identity identifier of the operation execution entity from the certificate.

[0181] When the authorization level determination result is a restricted authorization auditor, the joint verification procedure generates a selective disclosure proof at the restricted authorization auditor level. The public input of this proof only includes the operation compliance confirmation field (a Boolean value indicating whether the specified operation meets the applicable operation rules constraints within the scope of the restricted authorization auditor's authorization). Simultaneously, the operation execution entity type field and the operation type field are forcibly masked (reserved as private inputs of the proof circuit and protected with zero knowledge). Internally, when generating the operation compliance confirmation field value, the selective disclosure proof circuit additionally verifies whether the specified operation is within the set of authorized operation types specified by the restricted authorization auditor's authorization certificate (if not within the authorized range, the operation compliance confirmation field value is forcibly output as an unavailable flag, rejecting the unauthorized audit request). This ensures that the restricted authorization auditor cannot infer operation information beyond its authorized scope by repeatedly initiating audit requests of different scopes. The restricted authorization auditor can only obtain a binary conclusion of whether the specified operation is compliant from the operation compliance confirmation field and cannot obtain any information about the identity of the operation execution entity or the data content.

[0182] When the permission level determination result is "no authorized party," the federated verification process does not generate any selective disclosure proofs, but only opens access to the aggregate proof Pi to the unauthorized party. agg Standard Groth16 validity verification interface: No authorized party uses a public verification key vk and aggregate proof Pi agg The public inputs (initial state root and final state root, both Merkle tree root hash values, not containing data entity content information) and Pi agg The ontology is taken as input, and the standard Groth16 verification algorithm is executed. The verification result is a binary confirmation of the mathematical validity of the aggregate proof (valid or invalid), without carrying any operation content, execution subject or compliance details.

[0183] The selective disclosure results at all three levels are provided in the form of zero-knowledge proofs, possessing cryptographic verifiability (the recipient can independently verify the authenticity of the disclosed content without trusting the disclosing party). Simultaneously, the boundaries of information accessible at each level are strictly limited, ensuring at the cryptographic level that the scope of selective disclosure cannot be unilaterally expanded by the recipient. The generation of selective disclosure proofs at all three levels is automatically executed by a joint verification procedure after receiving and verifying the three types of predicate proofs from the data subject, regulator, and system layer in parallel. The entire process does not rely on the active cooperation of the data subject (i.e., the data subject cannot prevent compliance auditing by refusing to cooperate). Furthermore, the data subject confirms the legality of the auditor's authorization by verifying the sub-predicate result of the auditor's authorization in the compliance predicate proof of the operation content. This forms a complete closed loop of multi-party parallel mutual verification, where the data subject, regulator, and system layer mutually constrain each other within the same cryptographic framework.

[0184] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0185] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0186] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various aspects of the invention, in the above description of exemplary embodiments of this application, various features of the embodiments of this application are sometimes grouped together into a single embodiment, figure, or description thereof.

[0187] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying abstract and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying abstract and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0188] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can design alternative embodiments without departing from the scope. Unless otherwise specified, the steps in the above embodiments should not be construed as limiting the order of execution.

[0189] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data source tracing and verification method for zero-knowledge proof, characterized in that, include: Receive the operation rule set and the source information of each data entity, establish a verifiable constraint circuit for the operation rule set and generate a proof key and a verification key, calculate the source commitment for each data entity and organize it into an aggregate tree structure, embed the constraint circuit with the root hash of the aggregate tree structure as the source root identifier, and obtain the constraint circuit set, proof key, verification key and aggregate tree structure; Based on the set of constraint circuits, proof keys, verification keys and aggregation tree structure, a state tree is constructed by combining data content hash, operation history digest and source commitment. After each data operation, the state tree is incrementally updated and a global state root is maintained. A cryptographic accumulator is used to maintain the set of confirmed operations, resulting in the state tree, global state root and accumulator structure. Based on the state tree, the global state root, the aggregate tree structure, and the proof key, a single operation proof carrying the state root before and after the operation and the source path hash is generated for each data operation, resulting in multiple single operation proofs; Based on multiple single-operation proofs and the accumulator structure, a recursive folding mechanism is used to incorporate the linking relationship between the state roots before and after the operation into the folding constraints, generating an aggregate proof and constructing a state root chain. The aggregate proof, the source root identifier, and the state root chain are encapsulated into an end-to-end compliance certificate. The data subject, the regulator, and the system layer each generate corresponding predicate proofs locally and submit them to a joint verification program for parallel verification. If any predicate proof is invalid, the joint verification program rejects the verification of the end-to-end compliance certificate.

2. The method according to claim 1, characterized in that, The step of establishing a verifiable constraint circuit for the set of operating rules and generating a proof key and a verification key includes: Based on the flow rules in the operation rule set, a constraint circuit for verifying the sender's permissions and data integrity is constructed to obtain the R1CS constraint corresponding to the flow operation. For the usage rules in the aforementioned operation rule set, a constraint circuit is established to verify the compliance of access control policies and usage, and to generate R1CS constraints corresponding to the usage operations. The processing rules in the operation rule set are transformed into a constraint circuit that verifies that the input-output relationship conforms to the predefined transformation rules, thereby obtaining the R1CS constraint corresponding to the processing operation; The R1CS constraints corresponding to the transfer operation, the R1CS constraints corresponding to the use operation, and the R1CS constraints corresponding to the processing operation are processed by a trusted setting, wherein the trusted setting uses only random inputs provided by the participants and is completely decoupled from the source information to generate the proof key and the verification key.

3. The method according to claim 1, characterized in that, The step of calculating the source commitment for each data entity and organizing it into an aggregate tree structure, embedding the constraint circuit with the root hash of the aggregate tree structure as the source root identifier, includes: Based on the dataset identifier, preprocessing step description, authorization information and operation quota counter in the source information of each data entity, a hash function is used to calculate the commitment to obtain the independent source commitment corresponding to each data entity. In a multi-dataset scenario, based on the independent source commitments corresponding to multiple data entities, the aggregation tree structure is constructed by layer-by-layer hash aggregation. The root hash of the aggregation tree structure is used as the source root identifier, and the source root identifier is used as a public input to embed the constraint circuit, thereby obtaining the constraint circuit set and the aggregation tree structure. In a single dataset scenario, the aggregate tree structure degenerates into a single-leaf structure. The independent source commitment corresponding to a single data entity is directly used as the source root identifier. The source root identifier is embedded as a public input into the constraint circuit to obtain the constraint circuit set and the aggregate tree structure. This adopts a unified commitment calculation and embedding method with the multi-dataset scenario.

4. The method according to claim 1, characterized in that, The construction of the state tree using a combination of data content hash, operation history digest, and source commitment includes: For processing operations involving multiple data entities, based on the path nodes corresponding to each input data entity in the aggregation tree structure, hash aggregation calculation is performed layer by layer on the path nodes to obtain the source path hash of the cross-entity processing operation, and the source path hash is used as the corresponding source commitment field value. Based on the source commitment field value, the source commitment field value is combined with the corresponding data content hash and operation history summary, and written into the state tree as the corresponding leaf node value to obtain the leaf node carrying the cross-entity source tracing link and the state tree containing the leaf node.

5. The method according to claim 1, characterized in that, The method of maintaining the set of confirmed operations using a cryptographic accumulator includes: Based on the operation identifier after each data operation confirmation, the operation identifier is updated to the cryptographic accumulator to obtain the updated accumulator state; Based on the updated accumulator state, a membership certificate is generated for the operation identifier. The generation and verification of the membership certificate are both completed within a constant time, resulting in the accumulator structure containing the accumulator state and the membership certificate, which is used by the auditor to verify the legality of the authorization certificate.

6. The method according to claim 1, characterized in that, The single-operation proof is generated using a hybrid proof structure for each data operation, including: Based on compliance verification calculation of a single data operation, the compliance verification calculation is expressed as an execution trace, and the execution trace is decomposed into several independent calculation blocks. Each independent calculation block only loads the state tree path node, source commitment summary and operation parameters required by the current independent calculation block, to obtain multiple independent calculation blocks and local input data corresponding to each independent calculation block; Based on the multiple independent computation blocks and the local input data, the corresponding polynomial commitment is calculated independently for each independent computation block, and a corresponding auxiliary accumulator is generated for each independent computation block. The polynomial commitments and auxiliary accumulators corresponding to each independent computation block are organized layer by layer through a tree-shaped evaluation structure to obtain a tree-organized polynomial commitment structure. Based on the tree-organized polynomial commitment structure, a constant-order streaming scan is used to traverse and aggregate all independent computational blocks in the polynomial commitment structure to generate the inner proof. Based on the inner proof, the inner proof is encapsulated in the outer proof stage, and the state root before and after the operation and the source path hash are incorporated into the outer constraints to generate the single operation proof carrying the state root before and after the operation and the source path hash. The hybrid proof structure reduces the prover memory usage to the order of magnitude proportional to the square root of the number of operation steps.

7. The method according to claim 6, characterized in that, The outer proof stage of the hybrid proof structure circuitizes the verification logic of the inner proof, generating the single-operation proof of constant size, including: Based on the inner proof, the verification logic of the inner proof is expressed as an arithmetic circuit, and the state root before and after the operation, the source path hash of the entity involved in the operation, and the operation rule type identifier are used as the public input ports of the arithmetic circuit to obtain the arithmetic circuit representation. Based on the arithmetic circuit representation, the state roots before and after the operation, the source path hash of the entity involved in the operation, and the operation rule type identifier are used as public inputs. The proof generation algorithm is executed using the proof key to obtain a single operation proof of constant size.

8. The method according to claim 1, characterized in that, The recursive folding mechanism incorporates the linking relationship of the state roots before and after the operation into the folding constraints, generates an aggregate proof, and constructs the state root chain, including: Based on two adjacent single operation proofs, the validity of the two adjacent single operation proofs is verified, and the link relationship between the post-operation state root carried by the previous operation proof and the pre-operation state root carried by the next operation proof is included in the folding constraint to obtain the intermediate aggregation proof. Based on the intermediate aggregation proof, the operation is recursively folded layer by layer according to the operation sequence. Each fold retains the temporal integrity of the operation sequence, resulting in the aggregation proof and the state root sequence carried by each operation proof during the layer-by-layer folding process. Based on the state root sequence, the complete evolution path from the initial state root to the final state root is recorded in the order of operation timing to form the state root chain. Each node in the state root chain serves as a locatable anchor point for subsequence auditing.

9. The method according to claim 1, characterized in that, The process involves the data subject, regulator, and system layer each generating corresponding predicate proofs locally and submitting them to a joint verification program for parallel verification. The data subject's local generation of compliance predicate proofs includes: Based on the operation record corresponding to the specified operation and the end-to-end compliance certificate, generate an operation content compliance certificate result that proves that the specified operation complies with the established operation rules and does not expose data content. Based on the accumulator structure and the authorization credentials held by the auditing party initiating the audit, the legality of the authorization credentials within the confirmed operation set maintained by the accumulator structure is verified to obtain the auditing party authorization verification sub-predicate result; The compliance proof result of the operation content and the audit authorized verification sub-predicate result are combined and encapsulated in the same zero-knowledge proof to obtain the compliance predicate proof of the operation content with the audit authorized verification sub-predicate result.

10. The method according to claim 1, characterized in that, The data subject, regulator, and system layer each generate corresponding predicate proofs locally and submit them simultaneously to a joint verification procedure for parallel verification. Disclosure is selective based on the auditor's authority level, including: Based on the permission level corresponding to the authorization certificate held by the auditor, the permission level is determined to be a global supervisor, a restricted authorized auditor, or an unauthorized party, and the permission level determination result is obtained. Based on the permission level determination result, when the permission level is a global supervisor, the verifiable confirmation of the operation execution entity type and operation type is disclosed to the global supervisor; when the permission level is a restricted authorization auditor, only the operation compliance confirmation is disclosed to the restricted authorization auditor without disclosing the identity of the execution entity; when the permission level is an unauthorized party, only the unauthorized party is allowed to verify the validity of the aggregated proof; thus obtaining a selective disclosure result matching the permission level determination result.

Images