A verifiable reselling imputation and dispute resolution method and system for fine-grained structured data transactions

Abstract

The application provides a verifiable resale attribution and dispute resolution method and system for fine-grained structured data transactions. In the sales stage, a unified data processing specification is established through public universe and three-state normalization processing, different buyers are allocated different column views and bit map bindings are generated, the normalized data is embedded, locally sensitive hash is discretized and minimum hash digest is generated, the buyer binding receipt leaf is organized into an authentication data structure, and the root digest is anchored to the alliance chain smart contract. In the resale stage, the sampling position is determined by the on-chain unpredictable random seed, the authentication path verification and normalization recalculation are executed by the independent committee node to confirm the authenticity of the resale object. In the dispute stage, the suspicious sample is extracted and the disclosure digest is confirmed by the committee threshold, and the dispute object is locked. The proving party generates zero-knowledge proof to compare the coincidence count between the candidate buyer digest and the disclosure digest, and outputs the accusation, exclusion or retention judgment three-state ruling result according to the preset accusation threshold and exclusion threshold. Without disclosing the plaintext delivery data, the application provides a verifiable object authenticity verification channel for legal resale, and a privacy protection attribution mechanism based on similarity detection and double threshold ruling for illegal resale or data leakage.

Description

Technical Field

[0001] This invention relates to the fields of data trading, blockchain, privacy computing and zero-knowledge proof technology, and in particular to a verifiable resale liability and dispute resolution method and system for fine-grained structured data trading scenarios. Background Technology

[0002] With the development of data element circulation and on-demand data services, more and more data products are being sold in a fine-grained view format. In typical scenarios, the same underlying data table may offer different column combinations, field granularities, or processed views to different buyers. This type of transaction facilitates tiered authorization and refined pricing, but it also brings new challenges related to trusted delivery and resale governance. On the one hand, legitimate data resale is a crucial link in the circulation of data elements, and platforms need to provide verifiable resale channels for confirmed buyers. On the other hand, unauthorized illegal resale or data breaches can harm the interests of both the original seller and the platform. Therefore, how to support both legitimate resale and verifiable accountability for illegal resale within the same technical framework is a core challenge currently facing data transaction infrastructure.

[0003] In a consortium blockchain environment, data trading platforms can utilize smart contracts to automate transaction status management, escrow release, and dispute resolution. However, existing solutions typically have the following shortcomings.

[0004] First, many systems can only record transaction behavior or payment status, but cannot simultaneously bind the actual delivered object, delivery view, and processing rules received by the buyer at the time of sale. As a result, if a dispute arises later regarding suspected resale or leakage, the seller, buyer, or reseller may change their story afterward, making it difficult to prove what the original delivery actually was.

[0005] Second, structured data, especially tabular and IoT data, often exhibits natural distortions such as changes in column order, different representations of missing values, slight numerical perturbations, and partial deletion of rows or columns. Directly relying on comparison with the original file, simple hashing, or plaintext uploading to the blockchain makes it difficult to balance privacy and cost, and also makes it difficult to retain verifiable accountability after slight distortions.

[0006] Third, many existing solutions treat human reviewers or on-chain records as the final arbiters, failing to effectively distinguish between the two types of issues: "whether the disputed party is real" and "whether they are worthy of responsibility." Relying entirely on human or committee judgments easily introduces subjectivity; relying entirely on publicly available on-chain data exposes too many plaintext details and incurs high overhead.

[0007] Fourth, in real-world transaction environments with multiple buyers and multiple views, platforms are more often faced with the question of "which of a group of candidate buyers the suspected sample comes from," rather than the static comparison problem of a single suspected object. Existing technologies lack a complete technology stack that can simultaneously bind buyer views, support resale sampling verification, and output accusations, exclusions, or reservations in a privacy-preserving manner during the dispute stage.

[0008] Therefore, a new technical solution is needed to link the delivery binding in the sales stage, the object verification in the resale stage, and the final adjudication in the dispute stage without disclosing the plaintext delivery data, so as to verify the resale liability and dispute resolution of structured data. Summary of the Invention

[0009] To address the problems of existing technologies, this invention provides a verifiable resale liability and dispute resolution method for fine-grained structured data transactions. It aims to provide a verifiable channel for verifying the authenticity of legitimate resales while offering a privacy-protected liability mechanism based on similarity detection and dual-threshold adjudication for illegitimate resales or data breaches, without disclosing data in plaintext. The core technical approach of this invention is as follows: During the sales phase, off-chain normalization and tokenization are used to generate a buyer-bound digest signature, and key receipt items are anchored to a smart contract on the consortium blockchain; during the resale phase, on-chain random sampling and committee verification confirm the authenticity of the resale object; during the dispute resolution phase, zero-knowledge proofs are used to compare the overlap count between the leaked digest and the candidate buyer's digest, and a three-state adjudication result is output based on preset accusation and exclusion thresholds.

[0010] The technical solution of this invention is implemented as follows:

[0011] A verifiable method for resale liability and dispute resolution in fine-grained structured data transactions includes the following steps:

[0012] Step 1: Establishing the Column Universe and Processing Specifications: For the structured data product to be traded, a public, ordered, and standardized list of column names is pre-determined as the column universe. Preferably, the column universe can be represented as: For each column, define the column type and normalization parameters. For each cell, apply three-state semantic processing to distinguish between the absent state (ABSENT, where the column is not in the buyer's view), the null state (NULL, where the column has been delivered but its value is missing), and the valuable state (VALUE, where a valid value exists). This avoids confusing "the column is not sold" with "the column is null." Original values ​​of the column If it is a numerical sequence, then it is quantized according to the step size. Normalized as: If it is a timestamp column, then it is granular according to the time bucket. Normalized as: If it is a categorical column, it is converted to an integer using a preset dictionary mapping or deterministic hash backoff; if it is a Boolean column, it is uniformly mapped to... A comprehensive hash of all column types and normalization parameters yields a processing specification summary: ,in To process the set of specifications, including the quantization step size for each column, classification value mapping rules, time bucket granularity, stable record unit key, and parameters required for subsequent summary generation;

[0013] Step 2, Buyer View Assignment and Binding: On the same underlying data object, assign different sets of columns to different buyers. It is preferable to use a combination of core columns and extended columns to generate buyer views. The bitmap vectors are constructed in a fixed order according to the aforementioned column universe: ,in Indicates buyer The actual set of columns obtained can be further represented as a view summary as follows: The maskHash is used to bind the actual column view obtained by the buyer, preventing the attribution result from being affected by changing the column order, column mapping, or column set interpretation in subsequent disputes. Preferably, the buyer... The complete view is ,in A core set of columns shared by all buyers. For the extended column subsets allocated according to buyer differentiation, the extended column subsets are different for different buyers, making the bitmap vector There exists a Hamming distance difference, and the upper bound of the maximum collision probability resulting from this difference satisfies: ,in The Hamming distance between the two buyer bitmaps. To list the size of the universe, This is for the width of the subset in subsequent tokenization processing;

[0014] Step 3, Standardization and Tokenization Processing: For buyers Actual received data view After each record in the array undergoes normalization, it is grouped, aggregated, and discretized according to a preset column subset family to generate a token set. Preferably, the tokens are drawn from the column universe according to a preset width. and quantity Deterministically generate a family of column subsets, for each column subset ( Select columns from the buyer view that are numeric, boolean, or timestamp type, and map the normalized values ​​of each column into fixed-dimensional vectors using an embedding model. Subsequent aggregation is performed. Preferably, the embedding model is a time-series basic model, which converts scalar values... Expand to a fixed length constant sequence The input model is then obtained The embedded vectors are L2 normalized and fixed-point quantized for subsequent processing, and the aggregated vectors are... Through random symbol matrix Projection Bit binary hash code: Then Bit hash code by Each frequency band is segmented, and each segment The bits constitute a bucket number. ( For each record subset and frequency band Generate the final token: The tag is a token type marker (numeric or categorical). For recording identification, This is a token hash function. For category columns, a separate category token is generated, which additionally contains the column index and category summary. Therefore, the buyer... The complete set of tokens can be represented as: ,in Indicates the first Standardized record Indicates only in view Allows processing operators that generate tokens on columns;

[0015] Step 4: Buyer-linked receipt generation: For buyers... Token set MinHash processing is performed to generate a digest signature. Preferably, the MinHash digest signature is generated using a streaming accumulation method, where tokens are processed one by one and the complete token set is not stored; only a length of [length missing] is maintained. The minimum hash value array for Each independent hash function The corresponding MinHash digest signature can be defined as: For data views Hash the data itself to obtain the delivery digest: Sign the summary With random factors Make a commitment and receive a summary commitment: The current processing specification is hashed to obtain SpecHash, thereby forming a receipt element bound to the buyer. Preferably, the receipt leaf can be defined as: Where sid is the sales identifier. The buyer is identified, and SpecHash is a summary of the processing specifications. For view summary, For the purpose of abstract commitment, Random salt for buyers only. For the delivery object summary, the above seven binding items collectively fix the transaction identity, delivery view, delivery content, processing rules, and the buyer summary object on which subsequent comparisons depend;

[0016] Step 5, Transaction Anchoring and Confirmation: The preferred interaction method for the transaction phase is to first lock the transaction status, then complete off-chain delivery, and finally release it with the buyer's signature confirmation. The smart contract maintains the status of each sale, including states such as stored, confirmed, disputed, and resolved. Complete plaintext data is not publicly stored on-chain; instead, key receipt items related to the sale (including view summary, summary commitment, buyer salt, delivery summary, etc.), status bits, or their authentication data structure roots are stored. Preferably, if there exists... For a confirmed buyer receipt, the corresponding root summary can be represented as: Before confirmation, the buyer verifies whether the data view they receive is consistent with the deliveryHash, maskHash, SpecHash, and summary commitment in the on-chain or off-chain receipt; after the verification is passed, the transaction is confirmed and the subsequent status takes effect.

[0017] Step 6: Verification of the authenticity of the resale object: When a legitimate resale has been confirmed by a buyer, or when the platform receives suspicious samples suspected of being resold or leaked, the final responsibility is not immediately assigned. Instead, the platform proceeds to the object authenticity verification stage. Preferably, only the original buyer who has been confirmed is eligible to initiate a resale. The reseller needs to declare or sign the original summary of the object to be resold, the processing specification summary, the number of record units, and the sampling parameters. The smart contract deterministically generates a random seed based on the on-chain state. Where domSep is the domain separator, nonce is a monotonically increasing random number, resaleId is the resale identifier, rawRoot is the original data commitment root, timestamp is the block timestamp, and caller is the caller address. This design prevents the reseller from predicting or manipulating the sampling position. The independent verifier verifies whether the sample packet points back to the committed object through the authentication path based on the sampling position, and recalculates the normalization and tokenization processing results to confirm the consistency between the submitted object and the previous commitment. Preferably, if the object to be verified contains There are fixed recording units, and the sampling size is [number]. The sampling location can be determined as follows: Verification party for the first Each record unit performs authentication path verification, satisfying the following: In this step, the verifier does not directly determine whether a buyer should be held liable, but is only responsible for ensuring that the object brought into the dispute process is indeed the consistent object that was previously promised and can be recalculated.

[0018] Step 7, Identifying the Disputed Target: In suspected leakage scenarios, the platform generates a leakage summary for suspicious samples. The leaked summary is then verified by multiple parties to meet a threshold. Once the threshold is met, the smart contract identifies the disputed entity as a specific sales identifier (sid) and a specific potential buyer. And a fixed proof deadline is set. Preferably, the verifier is only responsible for verifying whether the object of the dispute is credible, whether it corresponds to the correct transaction and the correct summary, and does not directly decide the final guilty or innocent conclusion.

[0019] Step 8, Zero-Knowledge Proof Adjudication: Within the dispute window, the proving party opens the corresponding receipt leaf, path, and buyer summary object locally using a private witness method and generates a zero-knowledge proof, which is used to verify at least the following:

[0020] (1) A buyer's receipt leaf does indeed belong to the previously anchored root of the authentication data structure:

[0021] (2) The summary commitment in the receipt can be correctly opened to the buyer's summary signature:

[0022] (3) The summary signature of the suspicious sample is consistent with the leaked summary that has been confirmed by the threshold.

[0023] (4) The overlap count between the suspicious sample summary and the candidate buyer's receipt summary meets the preset threshold condition. For candidate buyers The overlap count between it and the suspicious sample can be defined as: Furthermore, the normalized similarity estimate is: The mathematical basis for the above estimation lies in the unbiasedness of MinHash: for two sets of tokens... and Its Jaccard similarity satisfy That is, the normalized value of the overlap count is an unbiased estimate of the Jaccard similarity. Therefore, by comparing the overlap count with a preset threshold, the similarity between two data views can be determined without disclosing the plaintext of the token set. Preferably, the decision rule can be written as: ,in The threshold for charges To eliminate the threshold, preferably, the zero-knowledge proof uses the Groth16 proof system, and the public inputs include the sales identifier (sid) and the buyer identifier. The following are data structures: SpecHash (processing specification summary), root (authentication data structure root), lid (leak report identifier), deliveryHash (delivery summary), LeakSummaryHash (leak summary binding hash), mode (proof mode flag, 1 for accusation, 0 for exclusion), and accusation threshold. Exclusion threshold With view digest maskHash. Private witnesses include authentication path elements and indexes, and digest commitments. Buyer salt Delivery hash, digest signature array Commitment random factor With leaked summary array ;

[0024] Step 9: Output dispute resolution status: After the smart contract verifies the zero-knowledge proof, it updates the dispute status to accused, excluded, or reserved judgment; if the proof window expires and no valid proof exists, the case is automatically closed as reserved judgment, thus realizing a two-layer processing logic of first authenticating the object and then making a privacy protection ruling.

[0025] As a further optimization of the above scheme, in step 3, the embedding model is a time-series basic model. After the scalar value is expanded into a fixed-length constant sequence, it is input into the model to obtain a fixed-dimensional embedding vector, which is then normalized by L2 and quantized by fixed point and used for subsequent locality-sensitive hashing processing.

[0026] As a further optimization of the above scheme, in step 4, the MinHash digest signature is generated using a streaming accumulation method. Tokens are processed one by one, and the complete token set is not stored; only a length of [length missing] is maintained. The minimum hash value array is processed, and this array is submitted as the final digest signature.

[0027] As a further optimization of the above scheme, in step 6, the verification party is a committee node independent of both the buyer and seller. The verification party is only responsible for confirming the consistency between the disputed object and the previous commitment, and does not directly participate in the final attribution decision.

[0028] As a further optimization of the above scheme, in step 5, the buyer needs to sign and confirm the key binding items in the receipt before confirming the transaction. The signature message must include at least the sales identifier, view summary, summary commitment, buyer salt and delivery summary. The smart contract restores the identity of the confirming party through the signature and releases the escrow state after the confirmation is successful.

[0029] As a further optimization of the above scheme, in step 6, the random seed sampleSeed is deterministically generated by the smart contract based on the on-chain state. Its input includes at least a domain separator, a monotonically increasing random number, a resale identifier, the original data commitment root, the block timestamp, and the caller address, so that the reseller cannot predict or manipulate the sampling position.

[0030] As a further optimization of the above scheme, the charge threshold With exclusion threshold Determined using a constrained grid search method: within a given summary dimension Below, preset Candidate set and Candidate set, for all satisfying The candidate combinations are evaluated on the validation set for false accusation rate, false exclusion rate, and correct accusation rate. The candidate combination with the highest correct accusation rate among those that satisfy the condition of zero false accusation rate and false exclusion rate not exceeding a preset upper limit is selected as the final parameter.

[0031] Compared with the prior art, the present invention achieves the following beneficial effects:

[0032] (1) The present invention binds the delivery object, delivery view, processing rules and buyer summary object simultaneously during the sale, which can effectively prevent the replacement of delivery documents, changes of view definition or changes of processing parameters after the fact, thereby significantly improving the traceability and verifiability of sales receipts.

[0033] (2) This invention is aimed at fine-grained multi-view sales scenarios. It generates buyer-bound receipts by utilizing the natural differences in column views between different buyers. Without putting plaintext data on the blockchain, it provides a verifiable anchor point for subsequent resale attribution.

[0034] (3) This invention provides a verifiable channel for confirming the authenticity of objects for legitimate resale through on-chain random sampling and committee verification mechanism, so that confirmed buyers can prove that the resale object is consistent with the previous commitment without exposing the complete plaintext data, thereby supporting the legitimate circulation of data elements while retaining the ability to hold illegal resale accountable.

[0035] (4) This invention separates the handling of "whether the object is real" and "whether it is worthy of responsibility". It first locks the credible dispute object by using sampling verification and authentication path, and then completes the final decision by zero-knowledge proof, thereby reducing the subjectivity of manual review and the privacy exposure of on-chain public decision.

[0036] (5) By disclosing the column universe, three-state normalization and view summary binding mechanism, this invention has better adaptability to common column order changes, null value representation differences and mild data disturbances in structured data, and avoids the failure of simple file hashing schemes in natural deformation scenarios.

[0037] (7) The accusation threshold and exclusion threshold of the present invention are systematically determined on the validation set by a constrained grid search method, rather than being set by human experience, which helps to obtain reproducible parameter selection under different datasets and different summary dimensions. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the overall system structure in one embodiment of the present invention.

[0039] Figure 2 This is a schematic diagram of the normalization and tokenization process in one embodiment of the present invention.

[0040] Figure 3 This is a schematic diagram of the resale verification and dispute resolution process in one embodiment of the present invention.

[0041] Figure 4 This is a schematic diagram illustrating the relationship between the buyer's receipt and the authentication data structure in one embodiment of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0043] like Figures 1 to 4 As shown, this embodiment uses two publicly available IoT datasets: the RT-IoT2022 dataset (123,117 rows, 85 columns, of which 82 are numerical columns and 3 are categorical columns) and the TON_IoTNetwork dataset (211,097 rows, 44 columns, of which 17 are numerical columns and 27 are categorical columns). There are multiple candidate buyers, and buyers are differentiated using the same core columns plus different extended columns. This embodiment includes the following steps:

[0044] Step 1: Establishing the Column Universe and Processing Specifications: Taking the RT-IoT2022 dataset as an example, the platform establishes a column universe containing 85 columns. Of these, 82 columns are numerical columns and 3 columns are categorical columns. (Regarding the temperature column...) Set quantization step size Original value Normalized as: For timestamp columns Set time bucket granularity Seconds, original timestamp Normalized as: For category columns (Device Type), Preset Dictionary The value "sensor" is mapped to the integer 0; out-of-dictionary values ​​are generated as integers through deterministic hash backoff, and the system distinguishes three semantic states for each cell of each record: ABSENT, NULL, and VALUE;

[0045] Step 2, Buyer View Assignment and Binding: Core Column Set It contains 12 columns, the extended column pool contains 73 columns, and buyer A is assigned an extended column. (10 columns), Buyer B is assigned an extended column. (10 columns), Buyer A's complete view There are 22 columns in total, and the bitmap vector is constructed in column-universe order. , Computational View Summary ;

[0046] Step 3, Normalization and Tokenization: The tokenization parameter is taken as the subset width. Number of subsets Total number of LSH bits Frequency band For each column subset Numerical columns belonging to the buyer's view are selected. Normalized values ​​are mapped to 512-dimensional vectors using an embedding model, aggregated within subsets, and then projected onto a 256-bit random hyperplane to obtain binary hash codes. These hash codes are then segmented into 8 frequency bands (32 bits per segment) to obtain bucket numbers. For each record... subset and frequency band Generate tokens: ;

[0047] Step 4: Buyer binds receipt generation: using Each independent hash function for the token set Calculate the MinHash digest signature , Calculate the delivery summary Abstract Commitment Construct the receipt sheet: The leafHash organization of multiple buyers is a Merkle tree, root summary Anchored to the chain, the chain only stores the receipt item and root, and does not disclose plaintext data. Before the buyer confirms, the transaction is confirmed after verifying that the deliveryHash, maskHash, SpecHash and summary commitment are consistent.

[0048] Step 5: Verification of the authenticity of the resale object: Only buyers who have been confirmed can initiate a resale. The smart contract generates a sampleSeed based on the on-chain state, if the total number of record units... Number of samples Then the sampling location is: The committee nodes perform authentication path verification for each selected record. The system then recalculates the consistency between the normalization and tokenization results. Once multiple verification parties reach the threshold for confirmation, the resale object proceeds to the next stage. Verification parties do not directly participate in the attribution of liability.

[0049] Step 6: Identification of the object of dispute: The platform performs normalization and abstract extraction on the suspicious samples to obtain the leaked abstract. After multiple verification parties confirm the threshold, the contract will narrow down the dispute to the specific sales SID and the potential buyer. And record the proof deadline;

[0050] Step 7, Zero-Knowledge Proof Adjudication: The proving party locally opens the receipt leaf, Merkle path, and digest signature with a private witness, generating a Groth16 zero-knowledge proof. The proof circuit verifies the Merkle membership. Promise to open 1. Ensure the consistency of the leaked digest and calculate the overlap count: The judgment rule is as follows: Exporting accusations, Output exclusion, The output retains the judgment; if the proof window expires and there is no valid proof, the output also retains the judgment.

[0051] Step 8, Threshold Parameter Selection: Charge Threshold With exclusion threshold Determined through a constrained mesh search: In Down, Candidate set is , Candidate set is For all that satisfy The combinations were evaluated on the validation set, assessing the false positive rate, false negative rate, and correct positive rate. The combination with the highest correct positive rate among those with a false positive rate of zero and a false negative rate not exceeding 5% was ultimately selected. , , The verification set showed a correct accusation rate of 95.7% for any candidate buyer. The normalized similarity estimate is ;

[0052] Step 9, Evaluation and Verification: Evaluation scenarios include direct resale (complete copying), deletion of 20% of rows, deletion of 40% of rows, small numerical perturbation, medium numerical perturbation, deletion of 1 column, and 50% row and 50% column mixed deformation. In the formal evaluation, the system maintains a 90.7% correct accusation rate for real leak samples. Samples with insufficient evidence or high degree of mixing are retained as inconclusive.

[0053] Based on the disclosure and teachings of the foregoing specification, those skilled in the art can make changes and modifications to the above embodiments. Equivalent substitutions or variations of the digest algorithm, embedding model, authentication data structure, threshold selection strategy, sampling strategy, on-chain contract implementation, and proof circuit details should all fall within the protection scope of this invention.

Claims

1. A verifiable method for resale liability and dispute resolution in fine-grained structured data transactions, characterized in that, Includes the following steps: Step 1: Establishing the Column Universe and Processing Specifications: For structured data products to be traded, pre-determine a public, ordered, and standardized list of column names as the column universe. For each column, define the column type and normalization parameters; for each cell, apply three-state semantic processing to distinguish between the absent state (ABSENT, where the column is not in the buyer's view), the null state (NULL, where the column has been delivered but the value is missing), and the value state (VALUE, where a valid value exists); perform a global hash on all column types and normalization parameters to obtain a processing specification summary. ,in To process the set of specification parameters; Step 2, Buyer View Assignment and Binding: Assign different column sets to different buyers on the same underlying data object; for each buyer... Construct bitmap vectors according to the column universe order ,in express Included in the buyer's view, This indicates that it does not contain; hashing the bitmap vector yields a view digest. ; Step 3, Standardization and Tokenization Processing: For buyers Actual received data view Each record in the database undergoes normalization, where numerical columns are normalized according to the quantization step size. Standardize to Timestamp column by time bucket granularity Standardize to Category columns are converted to integers using dictionary mapping or hash fallback, while Boolean columns are uniformly mapped to... The normalized records are grouped according to a preset family of column subsets. For each subset, the numerical columns belonging to the buyer's view are mapped to fixed-dimensional vectors using an embedding model, then aggregated within the subset, and finally discretized using locality-sensitive hashing to generate a token set. ; Step 4: Buyer binds receipt generation: using Each independent hash function for the token set Calculate the MinHash digest signature ,in , ; For data views Computational Delivery Summary Sign the summary With random factors Computational summary commitment ; Sales ID SID, Buyer ID Processing specification summary SpecHash, view summary Abstract Commitment Buyer-exclusive random salt With delivery summary Combined into a receipt leaf ; Step 5, Transaction Anchoring and Confirmation: Organize the receipts from multiple confirmed buyers into an authentication data structure and calculate the root digest. And anchored to the chain; before confirmation, the buyer verifies whether the received data view is consistent with the deliveryHash, maskHash, SpecHash and summary commitment in the on-chain receipt, and confirms the transaction after the verification is passed; Step 6: Verification of the authenticity of the resale object: When it is confirmed that a buyer has initiated a resale or the platform has received a suspected leaked sample, the sampling position is determined on-chain based on a random seed sampleSeed that cannot be selected by the reseller. , The independent verifier performs authentication path verification on the selected record units. And re-perform normalization and tokenization to confirm consistency; Step 7, Identification of Disputed Targets: Perform the same normalization and summary extraction process as in the sales stage on suspicious samples to obtain the leaked summary. Multiple verification parties confirm the threshold of the leaked summary. Once the threshold is met, the smart contract locks the disputed object to the specific sales identifier and candidate buyer, and fixes the proof deadline. Step 8, Zero-Knowledge Proof Adjudication: Within the dispute window, the proving party opens the receipt leaf, authentication path, and digest signature using a private witness method to generate a zero-knowledge proof; the zero-knowledge proof verifies that the receipt leaf belongs to the anchored authentication data structure root, the digest promise can be correctly opened to the digest signature, the leaked digest is consistent with the confirmed digest, and the overlap count between the candidate buyer's digest and the leaked digest. When the preset threshold condition is met; Output the accusation result in time. Output the exclusion results when When the time or proof window expires and no valid proof is available, output the retained judgment result; Step 9: Output Dispute Resolution Status: After the smart contract verifies the zero-knowledge proof, it updates the dispute status to "Accused," "Excluded," or "Deferred Judgment." If the proof window expires and no valid proof exists, the case is automatically closed as "Deferred Judgment." 2. The method according to claim 1, characterized in that, In step 2, the column set is generated using a combination of core columns and extended columns, wherein the core columns... Expand columns for a common set of columns shared by all buyers For a subset of columns allocated based on buyer differentiation, the buyer The complete view is The extended column subsets of different buyers are all different, making the bitmap vectors... There exists a Hamming distance difference, and the upper bound of the maximum collision probability resulting from this difference satisfies... ,in The Hamming distance between the two buyer bitmaps. To list the size of the universe, This is the width of the subset.

3. The method according to claim 1, characterized in that, In step 3, the tokenization process includes: selecting tokens from the column universe according to a preset width. and quantity Deterministically generate a family of column subsets; for each column subset that belongs to the buyer view and is of numeric, Boolean, or timestamp type, its normalized values ​​are mapped to a fixed-dimensional vector via an embedding model and then aggregated within the subset; the aggregated vector is then processed... The binary hash code is obtained by random hyperplane projection, and then... Each frequency band is segmented to obtain a bucket number; the token type tag, processing specification summary, record identifier, subset index, frequency band index and bucket number are concatenated and hashed to generate the final token.

4. The method according to claim 3, characterized in that, The embedding model is a time-series-based model. After expanding the scalar values ​​into a fixed-length constant sequence, the input to the model yields a fixed-dimensional embedding vector, which is then normalized by L2 and quantized by fixed point for subsequent locality-sensitive hashing (LSH) processing.

5. The method according to claim 1, characterized in that, In step 4, the MinHash digest signature is generated using a streaming accumulation method. Tokens are processed one by one, and the complete token set is not stored; only a length of [length missing] is maintained. The minimum hash value array is processed, and this array is submitted as the final digest signature.

6. The method according to claim 1, characterized in that, In step 6, the verifier is a committee node independent of both the buyer and seller. The verifier is only responsible for confirming the consistency between the disputed party and the previously promised party, and does not directly participate in the final attribution decision.

7. The method according to claim 1, characterized in that, In step 8, the zero-knowledge proof uses the Groth16 proof system. The public inputs include the sales identifier, buyer identifier, processing specification digest, authentication data structure root, leakage report identifier, delivery digest, leakage digest binding hash, proof mode flag, and charge threshold. With exclusion threshold View summary; Private witness includes authentication path elements and index, summary commitment, summary signature array, commitment random factor and leaked summary array.

8. A verifiable resale liability and dispute resolution system for fine-grained structured data transactions, characterized in that, include: The normalization module is used to establish a column universe and perform tri-state normalization, embedding, and locality-sensitive hashing discretization on structured data. The view allocation and binding module is used to generate differentiated column views for different buyers, construct bitmap vectors, and calculate view summaries; the receipt generation and anchoring module is used to perform MinHash digests on token sets, generate digest commitments and receipt leaves, organize authentication data structures, and anchor the root digest to the blockchain; The resale verification module is used to determine the sampling position based on the on-chain random seed, perform authentication path verification and normalization consistency recalculation; the dispute proof module is used to generate and verify accusation proofs and exclusion proofs based on zero-knowledge proofs, and output the accusation, exclusion or retention judgment results based on the overlap count and threshold.

Images