A data element transaction whole-process trusted traceability method based on recursive zero-knowledge proof and three-receiver encryption

Abstract

This invention discloses a reliable traceability method for the entire data element transaction process based on recursive zero-knowledge proofs and three-receiver encryption, relating to the fields of knowledge base operation and maintenance and data quality governance. By constructing a knowledge dependency graph among knowledge items, distinguishing derived edges, reference edges, and co-occurrence edges, and aggregating along dependency paths based on noise or mode to calculate the propagation risk degree of each knowledge item, it is used to assess the downstream diffusion range of changes or errors. For multiple evidence paths supporting correction decisions, their path overlap is calculated to identify and reduce the evidence relevance caused by ancestor node or edge overlap, avoiding artificially high correction confidence. For loop structures existing in the dependency graph, loop detection and damping iteration mechanisms ensure the convergence of propagation risk degree calculation. Incremental update operations and error correction operations are bidirectionally triggered through asynchronous messages, forming a near real-time closed loop of detection and correction. This invention effectively improves the accuracy of knowledge base error detection and the timeliness of knowledge update response.

Description

Technical Field

[0001] This invention relates to the fields of blockchain, data element trading, zero-knowledge proof, privacy computing, and data traceability, specifically to a trusted traceability method for the entire process of data element trading based on recursive zero-knowledge proof and three-receiver encryption. Background Technology

[0002] As the data element market develops rapidly, the data chain—from collection, processing, ownership confirmation, and licensing to transaction, delivery, and secondary use—is constantly extending. Data circulation involves multiple entities, including data providers, buyers, intermediary service agencies, qualification verification agencies, and regulatory agencies. Missing records, inconsistent paths, or unverifiable evidence at any stage can lead to transaction disputes, difficulty in determining liability, and a lack of oversight. Traditional centralized platforms primarily rely on database logs, electronic signatures, and back-end audits for traceability, which suffers from problems such as records being tampered with by administrators, severe cross-platform data silos, inconsistencies between off-chain evidence and on-chain anchored information, and high auditing costs.

[0003] Blockchain possesses characteristics such as immutability, non-repudiation, and public verifiability, making it a reliable evidence carrier for data hashes, transaction states, permission credentials, and proof results. However, directly uploading all data or transaction details to the blockchain can lead to privacy leaks, on-chain storage bloat, and reduced verification efficiency. Conversely, uploading only a small amount of data can result in difficulties in quickly verifying the authenticity of off-chain data, the legality of processing procedures, and the continuity of the transaction chain. Zero-knowledge proofs enable provers to demonstrate the truth of a statement to verifiers without revealing the original data. They are suitable for verifying the existence, integrity, legality of permissions, and compliance of processing in data transactions. Related research has proposed replacing the transmission of original data with proofs, but the following shortcomings remain.

[0004] First, the efficiency of verification at each stage is low. Traditional zero-knowledge proofs are mostly generated for a single transaction or a single stage. When facing multiple rounds of processing, licensing, and transactions, multiple proofs need to be verified repeatedly. The number of verifications and the amount of computation increase linearly with the number of lifecycle stages, making it difficult to support high-concurrency data transaction scenarios.

[0005] Second, the evidence storage structures for multiple institutions and multiple stages are fragmented. Existing on-chain evidence storage solutions often only record a single hash and lack a multi-level evidence storage structure for data from multiple institutions, multiple stages, and multiple versions. It is difficult to detect in a timely manner if off-chain data is replaced or processing records are tampered with, making it difficult to verify consistency throughout the entire process.

[0006] Third, privacy delivery and regulatory verification are mutually exclusive. Buyers need to obtain data, and regulators need to verify the data content in the event of disputes or audits, but other transaction participants should not have access to sensitive plaintext. In existing schemes, regulators often rely on the cooperation of both parties after the transaction to obtain the data or credentials required for verification, making it difficult to complete verification independently. Furthermore, once regulatory verification discovers data anomalies, there is a lack of clear follow-up processing procedures.

[0007] Fourth, the existing traceability system lacks sufficient description of interface relationships and clear branch processing in the licensing review process. It fails to adequately describe the interface relationships between roles, permissions, proofs, on-chain records, off-chain encrypted data, and regulatory reports. In particular, it lacks specific mechanisms for handling abnormal paths such as failed licensing reviews and data anomalies discovered during regulatory verification, making it difficult to form a closed loop that can be practically implemented in engineering. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of existing technologies by employing a trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proofs and three-receiver encryption, comprising the following steps:

[0009] Data ownership confirmation: The data provider calculates the hash of the original data and submits the hash and related identification information to the system for storage;

[0010] S2 Data Processing: Perform at least one of the following processing operations on the data: cleaning, desensitization, standardization, feature extraction, or quality assessment, to generate the current stage output hash associated with the previous stage output hash, forming a hash chain record;

[0011] S3 Single-Step Proof Generation: Generates zero-knowledge proofs for each step of data ownership confirmation, processing, license review and uploading, to prove the existence of legal data, legal operations and legal permissions, but does not expose the original data or processing parameters themselves;

[0012] S4 License Review and Listing: The data source, processing records, and license application are submitted to a qualified institution for compliance review, and the review results are determined. If the review fails, the listing application is rejected and the listing process is terminated; if the review passes, license information is generated and written into the on-chain transaction license contract, and the data listing is completed.

[0013] S5 Recursive Proof Aggregation and Purchase Verification: The single-stage proofs of each stage described in step S3 are recursively aggregated into a final aggregate proof in the order of their lifecycles. After the buyer submits a purchase request, the final aggregate proof and license information are verified. After the verification is successful, the payment and delivery stage begins.

[0014] S6 Three-Receiver Encrypted Delivery: After payment is completed, a session key is generated and used to encrypt data or data keys. The session key is encapsulated using the buyer's public key and the public keys of the two regulators to form a three-receiver ciphertext that can be independently decrypted by the buyer and the two regulators. The relevant information of the ciphertext is written to the blockchain.

[0015] S7 Buyer Decryption Confirmation: The buyer uses their private key to decrypt the data, calculates the data hash, and compares it with the corresponding hash on the blockchain. Once they match, the delivery is confirmed to be complete.

[0016] S8 Regulatory Tracing Request: The regulator initiates a tracing request, verifies the regulator's identity and authority. If the verification fails, the tracing request is rejected and the tracing process is terminated. If the verification passes, the encrypted index and proof index of the target transaction are obtained from the blockchain.

[0017] S9 Regulatory Decryption Verification: The regulator independently decrypts the data using a private key in a local secure environment, calculates the hash of the data and compares it with the corresponding original hash on the chain, and judges the comparison result. If the comparison result is consistent, a traceability review report indicating that the data has not been tampered with is generated; if the comparison result is inconsistent, an alarm is triggered and the dispute resolution process is initiated.

[0018] S10 Report Storage: Upload the summary of the traceability report described in step S9 to the blockchain for storage.

[0019] Before step S1, there are also system initialization steps: allocating public and private key pairs, on-chain addresses and permission policies to data providers, data buyers, regulators, qualification agencies and traceability agents; deploying data ownership confirmation contracts, transaction permission contracts, Merkle root management contracts, recursive proof verification contracts, ciphertext index contracts and regulatory reporting contracts, with each step relying on the above contracts for execution.

[0020] The hash calculation method described in step S1 is as follows: ,in For collision-resistant hash functions, "Indicates series connection, This is the original data. For metadata, For the data provider's public key, For timestamps, The system will generate random numbers; Write the source audit hash set and update the corresponding Merkle root.

[0021] The generation method of the hash chain record in step S2 is as follows: if the processing function is Output data and the output hash satisfies , ,in For processing parameters, This is the output hash of the previous stage.

[0022] It also includes a multi-level Merkle notarization process: different qualification institutions or different business domains maintain their own hash sets, and the leaf nodes within each set are... Layer-by-layer aggregation yields The corresponding roots of each institution are further aggregated into a global root. The verifier only needs to obtain the leaf node, the Merkle path, and the corresponding root on the chain to pass the verification. Existence verification is completed without retrieving the remaining records in the set.

[0023] The single-stage proof generation method described in step S3 is as follows: for each stage... Generate proof ,in This is non-public witness data. The input is public; the proof is used to prove that the current data digest is generated by legitimate data, legitimate metadata, and a legitimate operator; that the Merkle path of the current record can be verified to the corresponding institutional root or global root; that the operator has the authority to perform the operation at this stage; that the input hash of the current stage is equal to the output digest of the previous stage; and that if this stage is a processing stage, the output hash is generated by executing a specified processing function on the input data; and if this stage is a transaction or delivery stage, the payment status and transaction permission are consistent with the on-chain record; the verifier passes... The statement is confirmed, but it cannot be obtained. .

[0024] The specific method of recursive aggregation in step S5 is as follows: Let For the first Public commitments in stages For the front The aggregation proof of the first stage, the first Public commitments in stages Calculate the stage identifier With transaction number Binding it to the commitment chain makes recursive proof specifically correspond to the specific lifecycle sequence of data elements from ownership confirmation to transaction; the first The phase recursive proof is The verifier only needs to verify the final recursive proof. ,pass This confirms that all historical stages from data generation to the current transaction status satisfy the corresponding constraints; when a new processing or transaction stage is added, a new proof is added on the basis of the existing recursive proof, without the need to re-verify all historical records.

[0025] The specific method of encryption for the three receivers in step S6 is as follows: the session key is... Generate, symmetric encryption ciphertext is The buyer is designated as recipient DB, and the two regulators are designated as recipient RA and recipient RB, respectively. Public key encapsulation is then performed on the buyer and the two regulators. ,get , , The recipient RA and recipient RB each hold their private keys independently and complete the decryption independently. Either supervisor can perform the decryption operation described in step S9 independently without relying on the cooperation of the purchaser or another supervisor. The ciphertext index, ciphertext hash and recipient public key are committed to being on the blockchain, so that the encryption behavior itself constitutes auditable evidence.

[0026] According to the method, it is characterized by further comprising at least one of the following two implementation methods: first, the three-receiver public-key cryptosystem is a multi-receiver broadcast encryption scheme based on bilinear mapping; second, the symmetric encrypted ciphertext is not generated. Only for session keys The public key is encapsulated, and then decapsulated by the purchaser and the two regulators respectively. Subsequently, the data ontology stored in the controlled data space is accessed with the corresponding access permissions, and symmetric encryption is no longer performed on the data ontology separately.

[0027] It also includes the step of constructing traceability features: assuming the complete dataset generated during the lifecycle of a data element is... The purpose of tracing the source is Industry rules, contract terms, or regulatory rules are ,according to Filter key data, by Generate source traceability features; corresponding to the statements to be proven. Represented as ,in As part of the testimony, it will not be made public; only its commitments will be made public. The verifier only verifies the stated statements. The corresponding proof and on-chain digest do not access the original data or processing parameters.

[0028] The present invention has the following beneficial effects:

[0029] (1) This invention binds the stage identifier and transaction number into the commitment chain of recursive proof, so that the recursive proof specifically corresponds to the specific life cycle sequence of data elements from ownership confirmation to transaction. The verifier only needs to verify the final aggregated proof to confirm that all historical links meet the constraints. When adding a new link, there is no need to re-verify the historical records. For example, in Example 1, the proofs of the four stages are recursively aggregated into a single final proof. The buyer only needs to verify once to complete the verification of all links of ownership confirmation, two rounds of processing and license listing. In Example 2, the desensitized processing supplemented due to rejection only needs to generate the proof of the corresponding link and add it to the aggregation. The ownership confirmation and existing processing proofs do not need to be regenerated, which reflects the incremental reuse characteristics of recursive proof.

[0030] (2) This invention adopts a three-receiver encryption architecture in which the buyer and two regulators decrypt independently. This allows the regulators to have evidence collection capabilities at the time of data delivery without relying on the cooperation of the transaction parties afterward. At the same time, each of the two regulators holds its own private key, and either party can complete the verification independently without requiring the other party to be present at the same time. This balances the separation of responsibilities in regulatory governance with the efficiency of verification response. As in Scenario 2 of Example 3, the regulator RB completes the decryption and hash verification independently in a local secure environment without requiring any additional cooperation from the data provider or buyer.

[0031] (3) This invention sets up clear branch processing mechanisms for the licensing review stage and the regulatory verification stage to avoid the blank space of no processing path in abnormal situations. For example, in Example 2, when the qualification agency fails the review, the system rejects the listing application and records the reason for failure, so that the data provider can resubmit after rectification; in Example 3, in the comparison branch of Scenario 2, when the hash calculated by the regulator after independent decryption is inconsistent with the record on the chain, the system triggers an alarm and automatically performs preliminary attribution and investigation of the encrypted storage stage and the local processing stage of the buyer, and enters the dispute handling process, so that the regulatory verification has the ability to detect abnormalities and drive responses, rather than just confirming the normal state.

[0032] (4) This invention provides a multi-level Merkle notarization mechanism, which enables different qualified institutions or business domains to independently maintain their own hash sets, while the blockchain stores a global root as a unified trust anchor, taking into account both independent notarization by multiple institutions and global consistency verification. As in Scenario 2 of Embodiment 3, before decryption verification, the regulator first verifies the integrity of the notarization of the target transaction record itself on the chain through the Merkle path, confirming that the record has not been tampered with or inserted, and then proceeds to the decryption stage.

[0033] (5) This invention provides a mechanism for converting traceability purpose into traceability features, enabling verification scenarios that do not require delivery of plaintext but only need to prove the validity of specific facts to verify only the proof and on-chain digest without accessing the original data and processing parameters. For example, in Example 5, industry compliance auditing agencies can confirm that the dataset has completed the desensitization of personal information in accordance with the specifications, the desensitization scope covers all declared field categories, and the desensitization strength reaches the quantitative lower limit required by the specifications simply by verifying the proof, without obtaining the original data, desensitization parameters, or specific field list content. Attached Figure Description

[0034] Figure 1 A flowchart of a trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption.

[0035] Figure 2 This is a diagram illustrating the overall system architecture of a trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proofs and three-receiver encryption. Detailed Implementation

[0036] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0037] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0038] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0039] Example 1

[0040] A data service provider, DP, holds a dataset of collected and organized user shopping behavior characteristics from e-commerce platforms. The company intends to sell the system described in this invention to a marketing analytics company, DB. The two regulatory bodies involved in this transaction are the data security regulator RA and the industry regulatory body RB.

[0041] Before entering S1, the system first performs initialization: assigning public and private key pairs to DP, DB, RA, RB, and a data compliance assessment agency, QA. The system establishes on-chain address and permission policies, and deploys data ownership confirmation contracts, transaction permission contracts, Merkle root management contracts, recursive proof verification contracts, ciphertext index contracts, and regulatory reporting contracts. Subsequent steps rely on the aforementioned contracts to perform corresponding read and write operations on the chain, and it will not be repeated to explain which specific contract is involved in each step of "writing on-chain".

[0042] S1 data ownership confirmation. DP on the original dataset. according to Calculate the hash, where Record metadata such as the field structure, number of rows, and collection time range of the dataset. For submission timestamps, A randomly generated salt value was used for this submission to prevent cross-transaction association. For collision-resistant hash functions, existing hash algorithms such as SHA-256, SHA-3, or the Chinese national cryptographic standard SM3 can be used. This example uses... It is SHA-256. The calculation yields... (Illustrative value, actual is a 256-bit hash output) After that, DP will identify the data. Data type, source description, collection time, self-signature and Submit to the system, and the system will Write the source audit hash set and update it according to the corresponding Merkle root in a multi-level Merkle evidence storage update manner. .

[0043] S2 Data Processing. DP performs two rounds of processing on the raw data: the first round is data anonymization, which involves removing user identification fields and generalizing the geographic location field. The processing function is denoted as follows: Output , Includes a list of desensitized fields and generalization granularity parameters; the second round is feature extraction, with the processing function denoted as... Output , Includes the feature extraction algorithm number and window parameters. Each round of processing is performed according to... Calculate the output hash: First round Second round .because The calculation formula contains , The calculation formula contains The three hash values ​​are linked end-to-end to form an unbreakable hash chain—if an attempt is made later to use another set of data... Impersonating the results of the first round of processing, because The replacement will be calculated in the second round. This manifests as a hash mismatch immediately, without having to wait until the final delivery stage to discover it.

[0044] S3 Single-Step Proof Generation. The system generates zero-knowledge proofs for both the S1 rights confirmation step and the S2 two-round processing step. The zero-knowledge proof scheme itself satisfies completeness (true statements can always be proven), soundness (false statements cannot be proven true), and zero knowledge (the verifier obtains no additional information other than the statement of truth or falsehood). It can be implemented using existing zk-SNARK (such as Groth16, PLONK) or zk-STARK schemes. This example uses the PLONK scheme, and the proof circuit can be written using existing circuit description languages ​​such as Circom.

[0045] Proof through the confirmation of rights For example, its statement to be proved The circuitry details are as follows: Witness input (not disclosed) contains raw data. metadata Salinity Public input includes , , , The circuit constraint is "recalculate". And verify that the result is equal to the publicly input. This constraint is essentially a circuitized representation of a hash preimage relation—the prover must actually possess the power to generate it. raw data With salinity Only then can a circuit assignment satisfying the constraint be constructed. However, after successful verification, the verifier can only confirm that "original data satisfying the hash relationship exists," and cannot deduce it from the proof itself. Any content.

[0046] Proof of the second round of processing (correspond For example, The circuitized content is as follows: Witness input includes , , Public input includes , Processing function identifier Circuit constraints consist of two parts—the first part verifies "according to..." and right Indeed, after processing, it was obtained (The specific circuit form of this constraint depends on...) Its own operations, for example, if It is a fixed-window statistical feature extraction, and the circuit is the arithmetic expression of the statistical operation itself; the second part is verification "recalculation". Equal to the public input The first constraint is the specific circuit implementation of the statement that "the output hash is generated by performing a specified processing function on the input data", making the correctness of the processing itself a verifiable cryptographic fact, rather than just something that DP declares on its own.

[0047] S4 License Review and Listing. DP submits the aforementioned processing records and license application to QA for review. QA verifies that the anonymized fields shown in the processing records comply with the platform's established personal information protection rules, the data usage statement is consistent with DB's procurement intent, and does not involve sensitive data categories requiring additional qualifications, thus determining that the review is approved. The system generates the Merkle root corresponding to the organization hash set, and writes the data description ("user shopping behavior feature dataset after anonymization and feature extraction"), data summary, license scope (limited to marketing analysis purposes, no resale allowed) and price into the on-chain transaction license contract, completing the listing.

[0048] S5 recursive proof aggregation and purchase verification. The system will... (Confirmation of property rights) (First round of processing) (Second round of processing) (License listing) Recursively aggregated in lifecycle order. Retrieve the transaction number. The polymerization process unfolds in stages:

[0049] Initial commitment Use an empty hash placeholder;

[0050] Phase One (Confirmation of Rights) Commitment Corresponding recursive proof (No prior aggregation proof in the first stage) Take empty);

[0051] Phase Two (First Round of Processing) Commitment , ;

[0052] Phase Three (Second Round of Processing) Commitment , ;

[0053] Phase 4 (Licensing for Sale) Commitment , .

[0054] This commitment chain links each step with a stage identifier ("confirm", "process 1", etc.) and a transaction number. The significance of binding it to the hash is that, without binding it to the transaction number, an attacker could theoretically directly misappropriate a valid proof generated at a certain stage of another transaction and splice it into the recursive chain of this transaction (because looking at the proof itself, the statement "there is valid processing" is unrelated to which specific transaction it is attached to); after binding it to the transaction number, misappropriating the proof from another transaction would lead to... The recalculation result is the same as the record on the chain. Inconsistency will cause recursive verification to fail at this point. Similarly, without binding a stage identifier, an attacker could misplace proof from one stage of the transaction and use it for another (e.g., passing off a processing stage proof as a licensing stage proof). Later, misappropriation will also occur It was exposed during recalculation.

[0055] After the buyer (DB) submits the purchase request, it verifies the final recursive proof. : This single verification confirms that all four stages from ownership confirmation to listing meet their respective constraints, and that the four stages are consecutive in the order declared. The database does not need to perform further verification. , , , Verify each item individually. Once verification is successful, the scope of permission matches DB's procurement intent, and the payment terms are confirmed, proceed to S6.

[0056] S6 three-party encrypted delivery. The system generates session keys. , The key derivation function can be implemented using existing standard algorithms such as HKDF. For the final delivered data (i.e., the data after two rounds of processing)... )calculate , This is a symmetric encryption algorithm, which can be implemented using existing algorithms such as AES-256-GCM. Then, the public keys of parties DB, RA, and RB are used to encrypt the encryption. Execution encapsulation:

[0057] ;

[0058] ;

[0059] ;

[0060] This can be implemented using existing public-key encryption algorithms such as ECIES or RSA-OAEP. (Three-party ciphertext) , For integrity verification labels, the system will Ciphertext hash, ciphertext index, third-party public key commitment, and transaction number Write it onto the blockchain.

[0061] The reason why the DB, RA, and RB are each independently encapsulated with the same session key, rather than only encrypting it for the DB, is because the contradiction this invention aims to resolve is that "the buyer needs to obtain the data, the regulator needs to verify the data content in case of disputes or audits, but other transaction participants should not obtain sensitive plaintext." If the regulator requests the plaintext from the DB or DP after a dispute occurs, it relies on the cooperation of both parties and the request process itself lacks on-chain traceable evidence. By encapsulating the regulator's decryption path alongside the buyer's decryption path and putting them on the chain at the time of delivery, the regulator's evidence-gathering ability does not depend on any additional cooperation after delivery. The timing of regulatory intervention is brought forward to the moment of delivery, rather than being handled retroactively after a dispute occurs. By setting up two regulators, each holding their own private keys and decrypting independently, the separation of regulatory responsibilities is further achieved: RA and RB can correspond to different regulatory functions (such as data security regulation and industry supervisor regulation in this example). The two can independently complete the verification within their respective scope of responsibilities without relying on each other's cooperation. This avoids the risk of power concentration that may result from a single regulator monopolizing decryption authority, and also avoids the delay in regulatory response caused by requiring both regulators to be present at the same time for decryption.

[0062] The S7 purchaser decrypted and confirmed the transaction. DB used its own private key. Unlocked get ,and then Decryption yields the data body. DB recalculates the hash of the obtained data and compares it with the record on the chain. The two are compared and found to be consistent, confirming that delivery is complete and the transaction loop is closed.

[0063] The specific values ​​of hash, key, commitment, etc. mentioned above are for illustrative purposes only. They are calculated by the corresponding cryptographic algorithms during actual deployment and do not constitute a limitation on the scope of protection of this invention.

[0064] Furthermore, it should be noted that the method described in this invention operates at... Figure 2 The system shown is divided into the following layers from top to bottom according to its functions: user interaction layer, service and business layer, verification and proof layer, blockchain core layer, and supervision and audit layer.

[0065] The user interaction layer includes the data provider's interface, the buyer's interface, and a dedicated portal for regulators. These interfaces allow the DP, DB, RA, and RB in this example to submit requests and view statuses, serving as the entry points for each role to initiate requests in the method of this invention. Steps S1 to S10 are not abstract processes detached from the specific system operation, but are executed by corresponding modules within the aforementioned five-layer architecture: S1, S2, S4, and S5 are driven by the data and transaction management module and call the smart contract group of the blockchain core layer to complete on-chain read and write operations; the proof generation and aggregation in S3 and S5 are performed by the recursive zero-knowledge proof service engine; S6 is executed by the encrypted communication module; S7 is initiated by the buyer through the user interaction layer and confirmed after verification by the service and business layer; the permission judgment in S8 is performed by the permission and qualification control module; the independent decryption in S9 is completed by the regulatory decryption service within its independent secure environment; and the report generation and archiving in S10 are completed by the traceability report generation and archiving module, with the report summary written to the blockchain core layer for on-chain storage.

[0066] Example 2

[0067] DP2, a data provider, holds a dataset derived from patient medical records collected in a collaborative project with a top-tier hospital. The proposed transaction will be conducted through the system described in this invention. DP2 has completed the data ownership confirmation for S1 and obtained... It is then written to the source audit hash set; subsequently, S2 processing is performed, which only renames and converts the data fields. The processing function is denoted as... No data masking or de-identification processing was performed; the output hash was generated. The S3 phase system has generated single-stage certificates for both the confirmation of rights and the processing of this round of goods. , .

[0068] In step S4, DP2 submits the processing records and license application to the accredited body's QA review. The QA review includes: verifying whether the de-identified field list declared in the processing records covers the sensitive field categories marked in the data source declaration; verifying whether the security classification matches the usage conditions in the license scope; and verifying whether the data source description and provider's qualifications have the corresponding authorization. In this example, QA verifies the processing records... (Corresponding to the first round of processing records) It was found that the processing type declared in this record was only "field renaming and format conversion," and the list of de-identified fields was empty. However, the data source description clearly indicated that the dataset was derived from patient medical records and contained fields that could constitute sensitive personal information, such as age, gender, department visited, and summary of past medical history. According to the established business rules of QA, datasets involving such fields must undergo irreversible de-identification processing before being uploaded, and the de-identified fields and the de-identification methods used must be clearly listed in the processing record. This processing record did not meet this requirement.

[0069] Based on this, QA determined that the license review failed. The specific record used to make the determination is as follows: Review conclusion "Failed", reason code "REJ-002: Sensitive field de-identification evidence missing", and the specific record identifier used for verification (i.e. corresponding The system will then execute the rejection branch described in step S4: reject the current listing application and terminate the current listing process; it will not generate the Merkle root corresponding to the institutional hash set, and will not write any data description, scope of permission, or price information into the on-chain transaction permission contract. In other words, the dataset will not enter the "listed" state on the chain and cannot be retrieved or a purchase request submitted by any buyer.

[0070] The system writes the review conclusion, the reason code for failure, and the record identifier on which it is based into the review record (this record itself is stored on the blockchain as part of the evidence, for DP2 or subsequent review to trace the review history, but is not equivalent to a licensed listing status), and returns a rejection notice to DP2, explaining the specific reason code and the corresponding rectification requirements (supplementing de-identification processing and listing the de-identified fields and methods in the processing record). DP2 then takes action accordingly. Supplement the desensitization process and create new processing stage records. With output hash Resubmit the license application. QA based on After a second review, it was confirmed that the list of anonymized fields covered sensitive fields such as age and summary of past medical history and that the anonymization method complied with the rules. The review was deemed successful, and the process proceeded to the approved branch in step S4. An institutional hash set and the corresponding Merkle root were generated, and the product was put on the shelves. The subsequent process was the same as S5 to S7 in Example 1, and will not be repeated.

[0071] It should be noted that this rejection did not affect the proof of ownership already obtained by DP2. With processing certificate Its own validity, , They respectively prove "the existence of legitimate data, legitimate metadata" and " Indeed by according to Since the processing yields these two facts, it is not necessary to regenerate the ownership certificate upon resubmission; only a single-step certificate needs to be generated for the supplementary desensitization processing steps. (correspond ), then , The proof for the new stage of supplementary desensitization and the new license approval proof are recursively aggregated together. The final proof after re-aggregation covers the updated lifecycle path of "rights confirmation - re-desensitization processing - license approval". This approach reflects the incremental reuse characteristic of the recursive proof: when adding or modifying a certain step, it is not necessary to re-verify the existing historical steps, but only to add or replace the proof that is directly related to the modified content on the basis of the existing recursive proof.

[0072] The above review rules, reason codes, and field categories are for illustrative purposes only. In actual deployment, they can be adjusted according to specific industry regulatory requirements, data security classification standards, and the business rules of the qualification institution itself, and do not constitute a limitation on the scope of protection of this invention.

[0073] Example 3

[0074] In practice, regulatory attribution is typically triggered by three types of events: first, disputes arising from reports by buyers or third parties that the delivered data does not conform to the permitted scope; second, routine compliance checks conducted by regulators according to established cycles; and third, compliance certificates proactively requested by data providers or buyers. Regardless of the triggering reason, regulatory attribution does not rely on the proactive cooperation of buyers or data providers—this is precisely the capability reserved in the design of the three-receiver encryption architecture: the decryption path held by the regulator is independently encapsulated at the time of data delivery, without waiting for a dispute to occur before requesting plaintext from the transacting parties or negotiating decryption methods. The complete regulatory attribution process is presented in two scenarios: Scenario 1 shows the rejection branch when permission verification fails, and Scenario 2 shows the complete verification process after permission verification is successful, further distinguishing between hash comparison consistency and inconsistency.

[0075] Scenario 1: Regulatory authority verification fails, the request is rejected, and the transaction in Implementation Example 1 is used. The transaction involved two regulators: the Data Security Registry (RA) and the Industry Supervisory Registry (RB). One day, an account claiming to represent the RA submitted a traceability request to the regulatory portal, requesting verification. The corresponding delivery data.

[0076] The system performs permission verification in step S8, which includes three aspects: First, it verifies whether the on-chain address of the requester's account corresponds to the address recorded in the RA public / private key pair and permission policy registered during the system initialization phase. In this example, the requester's account address does not match the registered address. The system finds that the account is actually a self-registered account of a branch of RA and was not officially registered as an account with regulatory decryption permissions during the system initialization phase. Second, even if the address matches, it is still necessary to verify whether the scope of regulatory functions declared in the request covers the data category and transaction scenario involved in this request. For example, if RA's registered permission scope only covers the supervision of financial data transactions, while this transaction belongs to the e-commerce behavior data category, then even if the address matches, the permission scope should still be judged to be mismatched. Third, it verifies the timeliness of the request, that is, whether the timestamp corresponding to the request signature is within the time window allowed by the permission policy, to avoid using expired signatures to replay historical authorizations.

[0077] In this example, the first verification failed. The system determined that the identity and authorization verification of the regulatory party failed and executed the rejection branch described in step S8: rejecting this tracing request, terminating this tracing process, and not obtaining data from the blockchain. The corresponding ciphertext index or proof index means that the requesting party cannot access the ciphertext of the three recipients of the transaction at any stage. Or recursive proof The system records the account address, request time, and reason for rejection ("REQ-DENY-01: The requesting account is not registered as a valid regulatory account") in the access attempt log and stores it on the blockchain. This log itself is not part of the source tracing report, but is retained as an independent audit record at the access control level for subsequent verification of whether there are abnormal access attempt patterns. The system also returns a rejection notification to the requesting account, stating that account authorization must be completed through the official RA registration channel before the request can be resubmitted.

[0078] It is important to note that this permission verification step and the subsequent S9 data layer verification are two independent checkpoints: S8 verifies whether the requester is qualified to perform this tracing, while S9 verifies whether the data itself has been tampered with. These two steps are not interchangeable. Skipping S8 and allowing any requester to directly enter the S9 verification step is tantamount to allowing unauthorized entities to obtain the verification results of the data delivery status, which in itself constitutes a breach of transaction confidentiality, even if the entity ultimately fails to complete the actual decryption of S9 due to not possessing the correct private key. Therefore, this invention sets permission verification as a pre-judgment branch independent of data verification, rather than something that only occurs when decryption fails.

[0079] Scenario 2: Regulatory authority verification passed, complete verification process, same transaction Subsequently, the RB formally submitted a traceability request. The triggering reason was that the DB discovered some statistical anomalies when using the delivery data for downstream analysis, and suspected that the delivery data was inconsistent with the processing scope stated in the license. The DB submitted a review application to the industry regulatory authority, and the RB initiated regulatory traceability accordingly.

[0080] After RB submits the request, the system verifies that the RB account address matches the registered address, that the regulatory functions cover the e-commerce data transaction category, and that the request timestamp is within the validity period. If the permission verification is successful, S8 is executed via the branch: obtaining data from the blockchain. The corresponding ciphertext index (pointing to the ciphertext of the three recipients) (storage location) and proof index (pointing to the recursive proof) and its commitment chain to ).

[0081] The system further verifies the integrity of the transaction record itself on the blockchain. The specific verification method employs the aforementioned multi-level Merkle notarization mechanism: the hash of the transaction's ownership confirmation phase... As a leaf node Included in source audit set A, the system retrieves Corresponding Merkle path (i.e., from) root of set A (recalculate the hash sequence of the sibling nodes required along the way). Aggregate layer by layer upwards, verifying that the final aggregation result equals the record on the chain. ,Right now This verification confirmed... Indeed, the information was formally included in the audit record at the time of the confirmation of ownership, rather than being added or altered afterward. Similarly, the licensing review records involved in this transaction are included in the compliance review set B, with the corresponding leaf nodes to... The path was also verified. Both institutions' roots... , With the root of the security classification set Quality assessment set root The current period has been aggregated into a global root. And by uploading it to the blockchain, RB can further verify it. , Whether it was correctly included in this period This allows the verification anchor to be traced back from a single institution root to a system-level trust anchor. This multi-level verification is not a replacement for S9 decryption verification, but rather confirms that the evidence path of the record to be verified is complete and tamper-proof before formally entering the decryption process, thus avoiding the omission that "the record itself has been tampered with, but it has not been detected because there is no verification evidence path".

[0082] Upon entering S9, RB uses the private key in a local secure environment. Decryption execution: Unseal the session key, then The data body is obtained through decryption. This decryption process is entirely completed within the RB local secure environment, using the private key. Without leaving the local environment or undergoing network transmission, the RB (Receiver Controller) does not need to request any additional information from the DP (Depositor Controller) or DB (Database Controller) – this is the key to the effectiveness of the three-receiver encryption architecture in regulated scenarios: the RB independently completes all decryption steps from ciphertext to plaintext, and its decryption capability comes from the encapsulation already completed at the time of delivery. It was obtained through negotiation afterward, rather than through prior agreement.

[0083] RB calculates the hash of the decrypted data and compares it with the hash recorded on the chain. A comparison is performed. In this example, the hash calculated independently by RB is compared with the hash on the chain. Completely consistent, the comparison results are determined to be consistent. Based on this, the system executes the consistency branch of S9: generating a source tracing review report, marked "data has not been tampered with." The report content, as described in step S10, includes at least the following items: request number (a unique number for this RB request), regulatory identity commitment (RB's identity identifier hash, not the plaintext of the RB's specific institutional name, so that unnecessary identity information is not exposed when the report needs to be transferred across institutions), target transaction hash (…). The corresponding transaction record hash), and the data flow path (listing the stage identifiers and corresponding hashes for each of the four stages: confirmation of rights, two rounds of processing, licensing and listing, and delivery, respectively). to The four stages corresponding to the commitment chain), and the recursive proof verification results ( The report includes the following: verification conclusion, ciphertext decryption result (RB has been successfully and independently decrypted, with no decryption failure or anomaly recorded), hash comparison result (consistent), verification conclusion (the delivered data matches the on-chain evidence record, and the statistical anomalies reflected by DB should be attributed to the downstream analysis method or data usage itself, rather than the delivered data being tampered with or inconsistent with the permitted scope), and timestamp. The report summary is stored on the blockchain for DB, DP, and any subsequent potential reviewers to review the verification conclusion. However, the report itself does not contain plaintext data and its circulation does not expand the scope of plaintext access.

[0084] And the corresponding branch for scenario two, specifically, hash mismatch triggers alarms and dispute resolution; to demonstrate the complete triggering process of another branch of S9, another independent transaction is shown. The data provider is DP3, the buyer is DB3, and the regulators remain RA and RB. The transaction was also completed and delivered in full according to S1 to S7, with the output hash recorded on-chain at the time of delivery being... Approximately three weeks after delivery, DB3 reported to the regulatory authorities that the distribution of values ​​in specific fields of the data obtained deviated significantly from the data range agreed upon in the contract, suspecting that the actual delivered content did not match the processing results of the on-chain evidence declaration. Based on this, RA initiated a source tracing.

[0085] The RA's permission verification is completed in the same way as the RB scenario described above. It retrieves the ciphertext index and proof index of the transaction from the blockchain and completes the corresponding multi-level Merkle path verification (verification passes, and the on-chain evidence path itself is complete). Entering S9, the RA uses its private key. Unlocked Obtain the session key and decrypt. Obtain the data ontology ,calculate After comparison, The comparison results are inconsistent.

[0086] The system executes the inconsistent branch of S9: an alarm is immediately triggered, and the alarm content includes the transaction number. Compare the hash values ​​(on-chain record values) of both parties. Compared with the independently decrypted calculation value The alarm includes the trigger time and the identifier of the regulatory body initiating the verification. The alarm is simultaneously pushed to the QA (Quality Assurance) institution associated with the transaction, the system maintenance party, and the other regulatory body (RB) (so that the two regulatory bodies are aware of the anomaly, without requiring both of them to participate in the discovery of the anomaly - the discovery of the anomaly can still be completed independently by either regulatory body, but the alarm notification after the discovery will be synchronized to the other party for possible joint handling in the future).

[0087] After entering the dispute resolution process, the system first automatically performs a preliminary attribution check, verifying the following possibilities in sequence: First, verifying the encrypted messages of the three recipients corresponding to the transaction. The first step is to verify whether the ciphertext hash recorded on-chain matches the ciphertext hash actually retrieved from storage. If the ciphertext itself is replaced or corrupted during storage, even if the decryption process is executed correctly, the decryption result will naturally differ from the original statement. In this case, the root cause lies in the off-chain ciphertext storage, not the legitimacy of the delivered content itself. In this example, verifying that the ciphertext hash matches the on-chain record eliminates the possibility of storage replacement. Secondly, verify whether the locally retained copy of the delivered data in DB3 (if the buyer has performed any secondary processing or storage migration on the local data copy after the decryption confirmation process) matches the original delivery data. The issues are consistent because this anomaly feedback stemmed from observations after DB3 used the data. It's necessary to rule out that the anomaly was introduced by DB3's subsequent processing steps rather than a problem with the delivered content itself. In this case, the local copy provided by DB3 matched the initial delivery record via hash comparison, further ruling out this possibility. After ruling out these two scenarios, the problem points to the time of delivery. The generation process itself may contain anomalies, for example, DP3 may have issues during generation. Previously held The witness data used in the previous single-stage proof is not the same data, or there are additional modifications in the processing stage that are not covered by the proof.

[0088] The system will include the preliminary investigation process and conclusions in the regulatory report: the report will indicate the verification conclusion as "data anomaly, hash comparison inconsistency," and the anomaly attribution investigation record will be included (the encrypted storage stage and the buyer's local processing stage have been ruled out; the problem points to the delivery content generation stage). The transaction will be marked as "dispute resolution requiring manual intervention." Subsequent processing will be transferred to an offline or semi-automatic dispute resolution mechanism: jointly handled by RA and RB or QA, DP3 will be required to provide the content generated at the time of delivery. Used The complete retention record was compared and verified with the witness data of the previous single-stage proof in the S3 phase. If it was confirmed that the DP3 delivery content was inconsistent with its proof statement, it was handled in accordance with the breach of contract clauses stipulated in the transaction license agreement, and the final determination and handling results were added to this regulatory report to form a complete closed-loop record of dispute resolution. Throughout the investigation and handling process, the original data ontology involved in the previous delivery stages between DP3 and DB3 was not further disseminated to any third party other than RA, RB, and QA due to this dispute resolution. The core evidence on which the dispute resolution was based was always the comparison relationship between the on-chain hash record and the result obtained by the regulator through independent decryption, rather than requiring all parties to re-disclose the original data to each other.

[0089] The above-mentioned permission verification rules, reporting fields, and anomaly attribution and troubleshooting steps are for illustrative purposes only. In actual deployment, they can be adjusted according to the functional division of specific regulatory agencies, dispute resolution procedures, and industry regulatory requirements, and do not constitute a limitation on the scope of protection of this invention.

[0090] Example 4

[0091] This example constructs specific scenarios for the two alternative implementation methods described above.

[0092] Variant 1 is a multi-receiver broadcast encryption scheme based on bilinear mapping. In some embodiments, in a cross-regional data transaction, the buyer DB4 is determined, but the specific handling points corresponding to the two regulatory parties are not yet determined at the time of the transaction. The data security supervision function of this region is handled by multiple local regulatory points on a rotating basis, and it can only be determined which point's personnel will perform the verification when the traceability request is actually initiated. If the standard scheme of Embodiment 1 is still used, the public keys of RA and RB must be determined during the S6 encryption delivery. , Encapsulation is performed separately for each location, but the specific public key of the rotating branch is not determined at the time of delivery. If a rotation change occurs after delivery, the encapsulated key, which is already complete under the standard scheme, will be lost. It cannot be decrypted by the private key of the new rotating branch and must be re-encrypted.

[0093] For this scenario, this variant uses a multi-receiver broadcast encryption scheme based on bilinear mapping. The basic structure of this type of scheme is as follows: the system pre-generates a set of public parameters and assigns a private key to each member of the "authorized receiver set" according to their membership in the set; the encryptor generates a broadcast ciphertext header for the entire authorized set during encapsulation, the size and content of which header do not depend on which specific member in the set will actually perform decryption; any member in the set holding a valid private key can recover the session key using their own private key and the broadcast ciphertext header through a single bilinear mapping operation, without needing to have their specific public key individually specified at the time of encryption. This type of scheme can be implemented using the existing Boneh-Gentry-Waters broadcast encryption scheme or its subsequent improvements; its specific algebraic construction belongs to existing technology in the field of broadcast encryption, and will not be elaborated upon in this example.

[0094] In this specific example, the system performs the following upon delivery: generating a session key. The data ontology is calculated in the same manner as in Example 1. Subsequently, independent execution was no longer performed on DB4, RA, and RB individually. Instead of encapsulation, a broadcast ciphertext header is generated for "the buyer's DB4" and "the set of regulatory bodies authorized for this transaction" (this set is predefined at the system level as all rotating branches covering data security regulatory functions in this region; the specific person in charge does not need to be determined at this time). , and The integrity verification tag together constitutes the encrypted message delivered in this transaction. ,in The message is still encapsulated separately for DB4 using the standard method (the buyer's identity is determined and unique at the time of delivery, so standard public key encapsulation is still used), with only the supervisor's side using a broadcast ciphertext header. The system will... The ciphertext hash, ciphertext index, and authorized set identifier are written onto the chain.

[0095] When a subsequent tracing request is actually initiated, assuming it is handled by RB3, the on-duty personnel at the third branch in that area, RB3 performs an authorization verification to confirm that they belong to the pre-registered supervisory authorization set for that area. After successful verification, RB3 uses their private key, which is assigned according to their set member status, combined with the broadcast ciphertext header obtained on-chain. The session key is recovered through a single bilinear mapping operation. ,and then The data body is decrypted, and the subsequent hash comparison process is the same as in Example 1 (S7) and Example 3 (S9). If the rotation of the regulatory outlets in the area changes after delivery but before the tracing is initiated, as long as the new handler is still a member of the authorized set registered in the system, they can directly use their own private key to decrypt the same data. This variant differs from the standard scheme of Implementation 1 in addressing scenarios involving the movement of members within the recipient set, as it eliminates the need for the data provider or system to re-encrypt the delivered ciphertext.

[0096] Variant 2 does not generate symmetric ciphertext; it only encapsulates the session key and stores the data body in a controlled data space. A data provider, DP5, holds a large dataset of high-frequency trading logistic derivatives, with the total data body reaching several hundred gigabytes. If the standard scheme of Example 1 is still used to generate symmetric encryption for the entire data body... Then As it flows along with transactions, it will bring significant cryptographic computation overhead and storage and transmission costs, and once generated... When the copy is transferred to the buyer's local environment, the data ontology generates an actual copy that is outside the scope of DP5 control. For highly sensitive scenarios where the data ontology should not be disseminated (such as the transaction log data involved in this example), the generation of this copy itself constitutes an additional compliance and security management burden.

[0097] The processing method for this variant is: data body It always remains within DP5's own controlled data space and does not generate overall symmetric encrypted ciphertext. The essence of delivery changes from "delivering a encrypted copy" to "delivering authorized access." The specific process is as follows:

[0098] DP5 sets the access endpoint identifier for this dataset in the controlled data space. And the corresponding access control policy (recording the list of public key commitments of allowed recipients). The system generates session keys. In this variant, the session key no longer serves as a symmetric encryption key, but rather as a seed for a one-time access credential.

[0099] Public key encapsulation was performed on DB5 and the two regulatory bodies respectively:

[0100] , ;

[0101] In the encapsulated content This refers to the location information of the access interface to the controlled data space, not the data itself. The system does not generate this information. The content written on the chain will be adjusted accordingly to: three encapsulations. , , Each has its own hash, access endpoint commitment (not a data ciphertext index), recipient public key commitment, and transaction number.

[0102] When the receiver performs an access operation, for example, DB5 uses a private key. Unlocked get Then based on Towards The corresponding controlled data space initiates an access request; the controlled data space verifies the information carried in this request. It matches the authorization credentials recorded in its own access control policy (the specific verification method can be adopted). As a one-time token or based on The derived signature method (which is an existing implementation in the field of access control) returns the data body to DB5 after successful verification. DB5 calculates the hash of the data, and obtains it simultaneously with the data obtained during unsealing. The comparison is performed, and delivery is confirmed upon agreement. This verification method is consistent with the verification logic of calculating hashes and comparing them with on-chain records, except that the data acquisition path changes from "decrypting local ciphertext" to "authorized access to controlled space." The data ontology exists only in DP5's own controlled data space throughout the entire process, without generating any additional copies that are transferred to the buyer's or regulator's local environment. The access logs of the controlled data space itself (recording when, by which recipient, and with what authorization the data was accessed) can also serve as an independent audit basis for the access behavior, which, together with the on-chain stored ciphertext hash and the access endpoint commitment, constitutes a complete chain of evidence for this delivery.

[0103] Example 5

[0104] This example is for routine audits or special verification scenarios that do not require touching the data ontology and only need to prove whether a certain compliance fact is true.

[0105] A compliance audit firm (CB) conducts routine compliance checks on a batch of uploaded datasets. The purpose of the check is not related to transaction disputes; it only needs to confirm whether the dataset has undergone personal information anonymization. The CB is not required to obtain transaction details, processing records, or the data ontology. The DP approach used in Example 1 is applied to the original dataset. Processing records: The first round of processing was for desensitization; processing function Output Output hash .

[0106] Let the purpose of this source tracing be... "Proof Dataset" The first round of processing has completed the personal information anonymization, covering all personal information field categories marked in the source statement. The anonymization method complies with industry anonymization specification version V2.3, and the size of the equivalence classes after anonymization is not less than the minimum value required by the specification. ".

[0107] according to From the full record, a subset directly related to the de-identified facts is selected: a list of personal information field categories in the source statement during the rights confirmation stage (denoted as the public set). First round of processing stage records (list of de-sensitized fields) Desensitization method parameters Generalized equivalence class size statistics ) and the corresponding single-stage proof for this stage. Generate Its structure is the same as the previous version and will not be repeated.

[0108] Zero-knowledge proof circuits are typically represented as a set of arithmetic constraint systems, namely rank-1 constraint systems (R1CS): given a set of variable assignment vectors (Including both public input and witnesses), the constraint system consists of several forms such as The multiplication constraints are constituted, where , , For the constraint matrix, For element-wise multiplication; the prover provides a product that satisfies all constraints. The verifier only needs to verify the certificate itself and does not need to resubmit it. The constraints are calculated one by one. The general compilation and solution mechanism of this constraint system belongs to the existing technology in the zk-SNARK field. Existing toolchains such as circom and arkworks can be used to compile the high-level statements into R1CS. This example does not go into the details of the compiler implementation, but gives the constraint content corresponding to each of the three conditions, so that those skilled in the art can construct specific circuits based on this.

[0109] Condition one is as follows: ;

[0110] The corresponding constraints are: ;

[0111] in For the first Brother node hash of layer, For the direction bit (indicating whether the current node is a left or right child node), constraints are recursively applied layer by layer: ;right ,like but ,like but Final constraint This recursion can be equivalently represented as a set of selection constraints. , and The sequence serves as the witness input. As public input.

[0112] Condition 2 is ;

[0113] The corresponding constraints are divided into two parts: the first part is Arithmeticization of itself—in this example It consists of two sub-operations: generalization of the geographic location field (binning aggregation, which can be represented as a combination of several comparison constraints and selection constraints: comparing continuous coordinate values ​​with preset bin boundaries one by one and outputting the bin number) and hash replacement of the identity field (directly calling hash constraints). , As witness inputs, construct corresponding constraints one by one, and output... The internal circuit representation; the second part is This hash constraint itself, , As public input.

[0114] Condition three It is further broken down into two independent sub-proofs, corresponding to field coverage verification and equivalence class size verification, respectively. The specific circuit construction is described in the following two sections.

[0115] List of fields to be de-identified Does it cover the set of public field categories in the source declaration? This verification is essentially a proof of the coverage of a private set over a public set, which requires proof. Each element in belongs to At the same time, without disclosing Except What other elements are included besides these?

[0116] This invention employs a private set membership proof based on a Merkle tree to implement this verification: the system will... Each element (field category identifier) ​​in the data is used as a leaf node to construct a Merkle tree, resulting in the root. , The promise (not) itself) as Partially disclosed; Each element in ( The prover provides the circuit diagram. Path in the Merkle tree ;

[0117] Constraints Its construction method is the same as the Merkle path constraint in condition one above. All By applying the constraint to each element one by one, and having these constraints executed in parallel within the same circuit and sharing a single verification by the same verifier, it is possible to achieve this without leaking information. What other fields are included (without disclosure)? Given the total size, prove Every element is indeed covered.

[0118] Is the size of the generalized equivalence class not less than [the size of the generalized equivalence class]? The verification of " uses bit decomposition range proof: for each Decompose its binary bits ( For example, a bit width sufficient to represent the expected maximum equivalence class size ), each Must meet This constraint (forcing its value to be only 0 or 1) is the most basic constraint form in the proof of bit decomposition range, used to guarantee... It is indeed a bit (not an arbitrary field element), and the bit-weighted sum is constrained. Established. Based on this, it is proven... Equivalent to proof ,Right now It can be represented as the bitwise decomposition of a nonnegative number—construct a new variable. ,right Similarly, apply bit decomposition constraints (all bits are 0 or 1, and the weighted sum of bits equals 0). ),like Can be legally decomposed into The weighted sum of non-negative numbers means that the constraint system itself excludes... The possibility of being negative (negative numbers in finite field arithmetic, if unconstrained, would be represented as a large number within the field; the bit width limitation of bit decomposition constraints is key to eliminating this "wrap-around" representation). For By applying the above constraints one by one, it can be proven that the minimum value satisfies the lower bound requirement without disclosing the specific size of each equivalence class.

[0119] It should be noted that the conditions mentioned in conditions one and two... If the hash function is recalculated within the zero-knowledge proof circuit, the choice of the specific hash algorithm will significantly affect the circuit size and computational overhead of the proof generation. If a hash function such as SHA-256, optimized for general-purpose processor instruction sets, is used, the number of constraints after expanding the bitwise and modular addition operations within the arithmetic circuit will be enormous, significantly increasing the proof generation time and the size of the proof circuit. Therefore, in the specific implementation involving hash calculation within the circuit, this invention preferably uses hash functions such as Poseidon and Rescue, which are designed specifically for arithmetic circuits, to replace SHA-256 in executing the hash constraints within the circuit. The internal operations of such hash functions are based on exponentiation and linear transformations over finite fields, naturally adapting to the expression methods of constraint systems such as R1CS, which can significantly reduce the size of the circuit constraints. In cases where recalculation within the circuit is not required and the proof is only used for on-chain storage and external data integrity verification (as in the aforementioned embodiments of this invention), the hash function can effectively reduce the size of the circuit constraints. , (For the calculation of on-chain digests, SHA-256, SHA-3, or the national cryptographic SM3 can still be used. The two do not conflict. The appropriate algorithm can be selected based on whether the hash value needs to enter the proof circuit to participate in the constraint calculation.)

[0120] DP used locally , , , Wait for witness data, construct a complete circuit according to the above constraints, and generate a proof. ; Include , , , Commitment, Algorithm ID, Specification Version Number Threshold CB, as the validator, only needs to obtain... And the aforementioned publicly available digest that has been stored on the blockchain, execute Once verified, it can be confirmed that: the de-identified processing records are indeed stored on the blockchain; the de-identification operation was indeed generated from the declared original data according to the declared method; the scope of the de-identified fields indeed covers all field categories required by the source declaration; and the size of the equivalence classes after de-identification indeed reaches the minimum value required by the specification, without obtaining the original data throughout the process. Desensitization parameters Field list Specific content or specific numerical values ​​of the size of each equivalence class.

[0121] In the traditional approach, the CB requires the DP or data platform to provide data samples or plaintext processing logs for manual review. This review process itself constitutes an additional step of accessing sensitive information. This invention transforms the two verification conclusions that originally required manual review of specific fields and values—namely, the coverage of the desensitization scope and the quantification threshold of the desensitization strength—into cryptographic verifications that can be automatically completed by two types of standard circuit components (private set membership proof and bit decomposition range proof). This completely decouples the CB's verification capability from its access to the original data, processing parameters, and the specific strength values ​​of the desensitization.

[0122] The above descriptions of purpose, algorithm number, specification version number, bit width, threshold, and other specific details are for illustrative purposes only. In actual deployment, the purpose of tracing and the corresponding feature construction method can be redefined according to specific industry desensitization standards, regulatory requirements, and audit scenarios, and do not constitute a limitation on the scope of protection of this invention.

Claims

1. A trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption, characterized in that, Includes the following steps: S1 Data Ownership Confirmation: The data provider calculates a hash of the original data and submits the hash and related identification information to the system for storage; S2 Data Processing: Perform at least one of the following processing operations on the data: cleaning, desensitization, standardization, feature extraction, or quality assessment, to generate the current stage output hash associated with the previous stage output hash, forming a hash chain record; S3 Single-Step Proof Generation: Generates zero-knowledge proofs for each step of data ownership confirmation, processing, license review and uploading, to prove the existence of legal data, legal operations and legal permissions, but does not expose the original data or processing parameters themselves; S4 License Review and Listing: The data source, processing records, and license application are submitted to a qualified institution for compliance review, and the review results are determined. If the review fails, the listing application is rejected and the listing process is terminated; if the review passes, license information is generated and written into the on-chain transaction license contract, and the data listing is completed. S5 Recursive Proof Aggregation and Purchase Verification: The single-stage proofs of each stage described in step S3 are recursively aggregated into a final aggregate proof in the order of their lifecycles. After the buyer submits a purchase request, the final aggregate proof and license information are verified. After the verification is successful, the payment and delivery stage begins. S6 Three-Receiver Encrypted Delivery: After payment is completed, a session key is generated and used to encrypt data or data keys. The session key is encapsulated using the buyer's public key and the public keys of the two regulators to form a three-receiver ciphertext that can be independently decrypted by the buyer and the two regulators. The relevant information of the ciphertext is written to the blockchain. S7 Buyer Decryption Confirmation: The buyer uses their private key to decrypt the data, calculates the data hash, and compares it with the corresponding hash on the blockchain. Once they match, the delivery is confirmed to be complete. S8 Regulatory Traceability Request: The regulator initiates a traceability request, verifies the regulator's identity and authority, and if the verification fails, the traceability request is rejected and the traceability process is terminated. If the verification passes, the ciphertext index and proof index of the target transaction are retrieved from the blockchain. S9 Regulatory Decryption Verification: The regulator independently decrypts the data using a private key in a local secure environment, calculates the hash of the data and compares it with the corresponding original hash on the chain, and judges the comparison result. If the comparison result is consistent, a traceability review report indicating that the data has not been tampered with is generated; if the comparison result is inconsistent, an alarm is triggered and the dispute resolution process is initiated. S10 Report Storage: Upload the summary of the traceability report described in step S9 to the blockchain for storage.

2. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, Before step S1, there are also system initialization steps: allocating public and private key pairs, on-chain addresses and permission policies to data providers, data buyers, regulators, qualification agencies and traceability agents; deploying data ownership confirmation contracts, transaction permission contracts, Merkle root management contracts, recursive proof verification contracts, ciphertext index contracts and regulatory reporting contracts, with each step relying on the above contracts for execution.

3. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, The hash calculation method described in step S1 is as follows: ,in For collision-resistant hash functions, "Indicates series connection, This is the original data. For metadata, For the data provider's public key, For timestamps, The system will generate random numbers; Write the source audit hash set and update the corresponding Merkle root.

4. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, The generation method of the hash chain record in step S2 is as follows: if the processing function is Output data and the output hash satisfies , ,in For processing parameters, This is the output hash of the previous stage.

5. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, It also includes a multi-level Merkle notarization process: different qualification institutions or different business domains maintain their own hash sets, and the leaf nodes within each set are... Layer-by-layer aggregation yields The corresponding roots of each institution are further aggregated into a global root. The verifier only needs to obtain the leaf node, the Merkle path, and the corresponding root on the chain to pass the verification. Existence verification completed.

6. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, The single-stage proof generation method described in step S3 is as follows: for each stage... Generate proof ,in This is non-public witness data. The input is public; the proof is used to prove that the current data digest is generated by legitimate data, legitimate metadata, and a legitimate operator; that the Merkle path of the current record can be verified to the corresponding institutional root or global root; that the operator has the authority to perform the operation at this stage; that the input hash of the current stage is equal to the output digest of the previous stage; and that if this stage is a processing stage, the output hash is generated by executing a specified processing function on the input data; and if this stage is a transaction or delivery stage, the payment status and transaction permission are consistent with the on-chain record; the verifier passes... The statement is confirmed, but no confirmation is obtained. .

7. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, The specific method of recursive aggregation in step S5 is as follows: Let For the first Public commitments in stages For the front The aggregation proof of the first stage, the first Public commitments in stages Calculate the stage identifier With transaction number It is bound to the commitment chain to make the recursive proof specifically correspond to the specific lifecycle sequence of data elements from ownership confirmation to transaction; No. The phase recursive proof is The verifier only verifies the final recursive proof. ,pass Confirm that all historical stages from data generation to the current transaction status satisfy the corresponding constraints; when a new processing or transaction stage is added, add a new proof based on the existing recursive proof.

8. The trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, The specific method of encryption for the three receivers in step S6 is as follows: the session key is... Generate, symmetric encryption ciphertext is The buyer is designated as recipient DB, and the two regulators are designated as recipient RA and recipient RB, respectively. Public key encapsulation is then performed on the buyer and the two regulators. ,get , , The recipient RA and recipient RB each hold their private keys independently and complete the decryption independently. Either the regulator can perform the decryption operation described in step S9 independently without relying on the cooperation of the purchaser or another regulator. The ciphertext index, ciphertext hash and recipient public key are committed to being put on the chain to make the encryption behavior itself constitute auditable evidence.

9. A trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 8, characterized in that, It also includes at least one of the following two implementation methods: first, the three-receiver public-key cryptosystem is a multi-receiver broadcast encryption scheme based on bilinear mapping; second, the symmetric encrypted ciphertext is not generated. Only for session keys The public key is encapsulated, and then decapsulated by the purchaser and the two regulators respectively. Subsequently, the data ontology stored in the controlled data space is accessed with the corresponding access permissions, and symmetric encryption is no longer performed on the data ontology separately.

10. A trusted traceability method for the entire data element transaction process based on recursive zero-knowledge proof and three-receiver encryption as described in claim 1, characterized in that, It also includes the step of constructing traceability features: assuming the complete dataset generated during the lifecycle of a data element is... The purpose of tracing the source is Industry rules, contract terms, or regulatory rules are ,according to Filter key data, by Generate source traceability features; corresponding to the statements to be proven. Represented as ,in As part of the testimony, it will not be made public; only its commitments will be made public. The verifier only verifies the stated statements. The corresponding proof and on-chain digest.

Images