Block chain DID data sharing credibility verification method based on zero knowledge proof

Abstract

The invention discloses a zero knowledge proof-based block chain DID data sharing credibility verification method, which comprises the following steps of completing on-chain registration to form an on-chain identity state; the method comprises the following steps: performing standardized coding and field processing on a to-be-shared data set, constructing key space mapping, constructing a Verkle tree, obtaining a data set commitment root, and determining a data set version identifier; anchoring registration is carried out, and an anchoring record and a strategy registration record which can be queried on a chain are obtained; a field set is selected from the Verkle tree, and a batch opening proof package is generated; determining a strategy constraint according to the strategy registration record, constructing a zero-knowledge proof circuit, carrying out correctness verification on the batch opening proof packets, and generating a zero-knowledge proof; generating an anti-replay identifier, and submitting the verification submission packet to the smart contract; and verifying the zero-knowledge proof, completing revocation and authorization validity verification, and outputting an event log. According to the method, the credible verification efficiency in a shared data scene is improved, and the on-chain evidence storage and verification overhead is reduced.

Description

Technical Field

[0001] This invention relates to the field of blockchain privacy computing technology, and in particular to a trusted verification method for blockchain DID data sharing based on zero-knowledge proofs. Background Technology

[0002] In the decentralized identity (DID) system, data sharing is gradually shifting from traditional centralized platforms to a distributed model based on blockchain. By registering identity identifiers, authorization status, and related policy information on the blockchain, participants can complete identity verification and data access control without relying on a centralized trusted third party. Simultaneously, zero-knowledge proof technology has been introduced into the blockchain environment, enabling data providers to prove to verifiers that they meet specific conditions without revealing the original data content, thus balancing data availability and privacy protection. In existing technologies, smart contracts are typically used to receive verification requests, invoke zero-knowledge proof verification algorithms, and record verification results to automate and audit the verification process.

[0003] However, existing blockchain verification schemes based on zero-knowledge proofs often focus on the correctness of the proof itself, neglecting the organization of submitted data on the contract side, the order of parameter loading, and the consistency constraints of the verification context. Some schemes directly receive the zero-knowledge proof and related inputs in the contract and immediately execute the verification, lacking structured parsing and verification of the integrity of the submitted data. This can easily lead to problems such as missing fields, misaligned fields, or parameter tampering, thus affecting the reliability of the verification results. In addition, existing schemes often decouple the management of verification parameters from specific policy versions. When the contract executes verification, it is difficult to ensure that the verification parameters used are consistent with the currently effective policy version, posing a risk of reusing verification parameters across policies or versions, thereby weakening the actual effectiveness of policy constraints in data sharing.

[0004] Therefore, how to provide a trusted verification method for blockchain DID data sharing based on zero-knowledge proofs is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] One objective of this invention is to propose a trusted verification method for blockchain DID data sharing based on zero-knowledge proofs. This invention employs a Verkle tree to anchor the committed root of the field-based dataset, and uses batch open proofs and zero-knowledge proofs to jointly verify the consistency of the source of shared fields and the compliance of policy constraints. At the same time, it binds the anti-replay identifier with the policy version and verification parameters to complete the on-chain verification and auditable recording of authorization validity and revocation status, thereby improving the trusted verification efficiency in shared data scenarios and reducing the overhead of on-chain storage and verification.

[0006] The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to an embodiment of the present invention includes the following steps: Generate a DID, issue a verifiable credential VC and complete on-chain registration to form an on-chain identity status; Based on the on-chain identity state, the shared dataset is normalized, fielded, and a key space mapping is constructed. A Verkle tree with vector commitment as the internal node commitment structure is constructed and field values ​​are written to obtain the dataset commitment root and determine the dataset version identifier. Anchoring is performed on the dataset commitment root and dataset version identifier to obtain on-chain queryable anchoring records and policy registration records; Based on the policy registration records, select a set of fields from the Verkle tree and generate a batch open proof package for the set of fields; Based on the policy registration record, policy constraints are determined and a zero-knowledge proof circuit is constructed. The correctness of the batch opening proof package is verified, and the policy calculation input is constrained to be consistent with the opening field value, generating a zero-knowledge proof bound to the batch opening proof package. Based on the dataset commitment root, anchor record and policy registration record, generate anti-replay identifier, and combine zero-knowledge proof and anti-replay identifier to form a verification submission package and submit it to smart contract; The smart contract verifies the validity of revocation and authorization based on the verification of the submission package and the policy registration record, and outputs the event log.

[0007] Optionally, the formation of the on-chain identity state specifically includes: The data subject generates a decentralized identity identifier (DID) and a corresponding DID document, and writes each verification public key into the corresponding verification method entry. The policy identifier is selected from the preset policy set to form a parsable DID document. The DID document fingerprint is obtained by digesting the parsable DID document. The DID and DID document fingerprint are written into the blockchain and an on-chain registration index is obtained. The authorization validity record and revocation status record are located through the on-chain registration index to form a queryable DID registration record, which serves as the identity registration part of the on-chain identity status. The issuer issues a verifiable credential VC for the DID, calculates a digest of the VC to obtain a credential digest and generates a signature, and registers the credential digest and related status information on the blockchain to form a VC status record, which together with the DID registration record forms the on-chain identity status.

[0008] Optionally, obtaining the dataset commitment root and determining the dataset version identifier specifically includes: Read the on-chain identity status and extract the DID, then write the DID into the input parameter set of the key space mapping; The system database of the data provider is used to obtain the dataset to be shared and determine the dataset identifier used to locate the original data. At the same time, normalization encoding is performed and the normalized dataset is output. Based on the normalized dataset, the normalized dataset is serialized and encoded in the order of field keys, and the field identifiers and field values ​​are concatenated sequentially to form a version input sequence. The version input sequence is digested to obtain a version digest, and the version digest is used as the dataset version identifier. At the same time, the normalized dataset is fielded to form a field set, and a field identifier is generated for each field in the field set and a one-to-one binding relationship between the field identifier and the field value is established. Field keys are generated based on DID, policy identifier, dataset identifier, field identifier and dataset version identifier. Field values ​​are indexed and arranged according to field keys and a set of writable key-value pairs is output. The process involves constructing a Verkle tree with vector commitments as internal node commitments, taking a set of key-value pairs as input, and writing field values ​​into the tree. A branching factor is set to determine the tree height and node capacity at each level, and branch position numbers are assigned to each level. The key-value pair set is sorted in ascending order by field key, divided into different leaf node buckets according to a preset bucket size, and a bucket number is assigned to each leaf node bucket. A bucket identifier is generated by combining the bucket number with the dataset version identifier. Field values ​​within each leaf node bucket are type-labeled and encoded according to the field identifier order, and then aligned with a fixed length to form leaf vectors. Simultaneously, the leaf vectors are loaded into the corresponding leaf node slots. Based on the common parameters of vector commitments, leaf commitments are generated element-wise from the leaf vectors, and the leaf commitments and bucket identifiers are written to the corresponding leaf nodes. The leaf node index is output. For each upper-level internal node, the commitments of all child nodes are collected, and sub-commitment vectors are formed according to branch position numbers. Based on the same common parameters of vector commitments, internal node commitments are generated from the sub-commitment vectors and written to the internal nodes. The internal node index is output. This process of set, compose, commit, and write is repeated layer by layer from the leaf layer until the root layer is generated, producing the root layer internal node commitment, which serves as the dataset commitment root and is output.

[0009] Optionally, obtaining the on-chain queryable anchoring records and policy registration records specifically includes: Load the dataset commitment root, dataset version identifier, and policy identifier as anchor registration inputs and form an anchor registration request; An anchor registration request is submitted by calling the anchor registration interface of the blockchain smart contract. When submitting, the anchor registration request is concatenated into an anchor input sequence in a preset order and the summary calculation is performed to obtain the anchor summary. The anchor summary, the dataset commitment root, the dataset version identifier and the policy identifier are written on the chain to form an anchor registration transaction. The blockchain smart contract executes the anchor registration transaction and obtains the anchor record and the strategy registration record. The anchor record includes the dataset commitment root, the dataset version identifier, the strategy identifier, and the anchor registration transaction index. The strategy registration record includes the strategy identifier and the associated strategy version information.

[0010] Optionally, the generation of the batch opening proof package for the field set specifically includes: Read the policy registration records and obtain the field identifiers from them. Then, remove duplicate field identifiers according to the preset field order and generate a field set. Read the anchor record, obtain the dataset commitment root and dataset version identifier corresponding to the shared verification, and generate field keys that correspond one-to-one with each field identifier under the key space mapping based on the field set. Arrange each field key and its corresponding field identifier to form a field key list. Based on the list of field keys, batch leaf node location is performed in the Verkle tree corresponding to the commitment root of the dataset to determine the leaf node position and branch path of each field key. The leaf node index, branch index and sibling node commitments of each field key are encapsulated in the order of field keys to form a batch open proof package.

[0011] Optionally, the generation of the zero-knowledge proof bound to the batch opening of the proof package specifically includes: Read the policy registration record and obtain the field identifier and verification parameter index corresponding to the policy identifier. Based on the policy identifier and policy version information, locate the corresponding policy constraint parameter group from the preset policy set, load the policy constraint parameter group into a policy constraint set in a preset order, and generate a field order table that corresponds one-to-one with the field identifier. Based on the field order table, perform sequential reading of the batch open proof package, read the open field value corresponding to each field identifier item by item and write it into the field value sequence, read the field key corresponding to each field identifier item by item and write it into the field key list, read the leaf node index, branch index and sibling node commitment corresponding to each field key item by item and write it, and write the dataset commitment root and dataset version identifier into the root parameter and version parameter. Based on the verification parameter index, the zero-knowledge proof circuit identifier and verification parameters that match the strategy identifier and strategy version information are retrieved from the strategy constraint parameter group of the preset strategy set. The root parameter, verification parameter, version parameter, strategy identifier, strategy version information, field key list, field value sequence, path material sequence and strategy constraint set are loaded into the zero-knowledge proof circuit in a preset loading order. In the zero-knowledge proof circuit, the correctness of the batch opening proof package is verified. Leaf nodes are located item by item in the field key list to determine the leaf node slot corresponding to each field key. The branch path corresponding to each field key is traversed layer by layer upwards. The commitments of sibling nodes in the same layer are extracted layer by layer and numbered according to the branch position to form a sub-commitment vector. Vector commitment calculation is performed on each sub-commitment vector to obtain the commitment of the node inside the current layer. The iteration continues upwards until the root layer obtains the reconstructed root commitment. The reconstructed root commitment is compared with the dataset commitment root obtained from the anchor record for consistency. Equality constraints are applied in the circuit to make the two consistent. After passing the correctness verification, policy constraints and consistency constraints are performed in the zero-knowledge proof circuit. The policy constraints take values ​​from the field value sequence as the policy calculation input, and perform range comparison, equality comparison, set membership judgment, threshold accumulation comparison and OR logic combination judgment item by item in the order of the constraint item list. The judgment result of each constraint item is written into the constraint result sequence and a satisfaction constraint is applied to make each judgment result true. The consistency constraint compares the policy calculation input with the open field value at the corresponding position in the field value sequence item by item, and applies an equality constraint in the circuit to make the two consistent item by item. After the constraints are completed, the zero-knowledge proof is generated by calling the zero-knowledge proof generator.

[0012] Optionally, the process of submitting the verification submission package composed of zero-knowledge proof and anti-replay identifier to the smart contract specifically includes: Read the anchoring record and policy registration record, locate the anchoring entry and policy entry corresponding to this verification, extract and solidify them into anchoring context and policy context, read the zero-knowledge proof and write it into the proof context, and merge the anchoring context, policy context and proof context to generate the anti-replay input context. Perform integrity and non-empty checks on the anti-replay input context, and simultaneously serialize and concatenate it according to the preset loading order to obtain the input sequence; Perform a digest calculation on the input sequence to generate a nullifier, and write the nullifier into the anti-replay flag empty space to obtain the anti-replay output parameter group. Write the anti-replay output parameter group into the anti-replay field, and together with the zero-knowledge proof, form a verification submission package to be submitted to the smart contract.

[0013] Optionally, the output of the event log specifically includes: The smart contract receives the verification submission packet and performs structured parsing. It writes the parsed data into the contract running parameter area according to preset fields and generates a parsing integrity flag. Under the condition that the parsing integrity mark is valid, the smart contract locates the policy entry and policy version entry corresponding to this verification, further combines the on-chain identity status to locate the authorization validity record and revocation status record, and performs consistency verification. After the verification passes, the verification parameters are loaded as the contract verification parameters for this zero-knowledge proof verification. The smart contract queries the anti-replay status mapping table based on the anti-replay identifier and contract verification parameters. If the query result is an unused state, an anti-replay pass flag is generated and zero-knowledge proof verification continues. If the query result is a used state, a verification failure state is written and a failure event log is output. After successful verification, the anti-replay identifier is written to the anti-replay status mapping table and set to the used state, and an anti-replay status update completion flag is generated.

[0014] The beneficial effects of this invention are: This invention utilizes Verkle trees for dataset commitments and combines this with a batch-opening proof approach to achieve efficient verification of field consistency and policy constraints during data sharing. This innovation not only improves verification efficiency but also optimizes the processing performance of large datasets through structured encoding and key space mapping, significantly reducing the overhead of on-chain notarization and verification.

[0015] This invention effectively prevents the abuse of verification parameters across policies and versions by tightly binding the anti-replay identifier with the policy version and verification parameters, ensuring that the correct verification parameters are used for each verification. This anti-replay mechanism not only improves the accuracy of verification but also enhances the security and reliability of data sharing.

[0016] This invention combines revocation and authorization validity verification to ensure that authorization information and revocation status are checked in a timely and accurate manner during the verification process, thereby effectively preventing illegal data sharing and abuse of permissions, and further enhancing the credibility of the blockchain DID data sharing system.

[0017] This invention achieves improved credibility and scalability of data sharing verification while ensuring privacy protection, providing a more efficient and secure solution for cross-organizational data collaboration. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 The flowchart shows the blockchain DID data sharing trusted verification method based on zero-knowledge proof proposed in this invention. Figure 2 This is a schematic diagram of the algorithm structure of the blockchain DID data sharing trusted verification method based on zero-knowledge proof proposed in this invention. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0020] refer to Figure 1-2 A trusted verification method for blockchain DID data sharing based on zero-knowledge proofs includes the following steps: Generate a DID, issue a verifiable credential VC and complete on-chain registration to form an on-chain identity status; Based on the on-chain identity state, the shared dataset is normalized, fielded, and a key space mapping is constructed. A Verkle tree with vector commitment as the internal node commitment structure is constructed and field values ​​are written to obtain the dataset commitment root and determine the dataset version identifier. Anchoring is performed on the dataset commitment root and dataset version identifier to obtain on-chain queryable anchoring records and policy registration records; Based on the policy registration records, select a set of fields from the Verkle tree and generate a batch open proof package for the set of fields; Based on the policy registration record, policy constraints are determined and a zero-knowledge proof circuit is constructed. The correctness of the batch opening proof package is verified, and the policy calculation input is constrained to be consistent with the opening field value, generating a zero-knowledge proof bound to the batch opening proof package. Based on the dataset commitment root, anchor record and policy registration record, generate anti-replay identifier, and combine zero-knowledge proof and anti-replay identifier to form a verification submission package and submit it to smart contract; The smart contract verifies the validity of revocation and authorization based on the verification of the submission package and the policy registration record, and outputs the event log.

[0021] In this embodiment, the formation of the on-chain identity state specifically includes: The data subject generates a decentralized identity identifier (DID) and a corresponding DID document. The DID document contains a set of public keys for signature verification and a set of service endpoints for interaction. Each verification public key is written into the corresponding verification method entry. A policy identifier is selected from a preset policy set to form a parsable DID document. The DID document fingerprint is obtained by digesting the parsable DID document. The DID and DID document fingerprint are written into the blockchain and an on-chain registration index is obtained. The authorization validity record and revocation status record are located through the on-chain registration index to form a queryable DID registration record, which serves as the identity registration part of the on-chain identity status. The issuer issues a verifiable credential VC for the DID, calculates a digest of the VC to obtain a credential digest and generates a signature, and registers the credential digest and related status information on the blockchain to form a VC status record, which together with the DID registration record forms the on-chain identity status.

[0022] In this embodiment, obtaining the dataset commitment root and determining the dataset version identifier specifically includes: Read the on-chain identity status and extract the DID, then write the DID into the input parameter set of the key space mapping; The system database of the data provider is used to obtain the dataset to be shared and determine the dataset identifier used to locate the original data. At the same time, normalization encoding is performed. The normalization encoding process includes unifying the string fields to a preset character set and removing invisible characters, normalizing the field names according to the field dictionary, converting and rounding the numerical fields according to the preset unit of measurement, converting the time fields to the standard time format of the preset time zone, converting the missing values ​​to the preset placeholder representation according to the null value filling rules and recording the original missing value markers, and outputting the normalized dataset. Based on the normalized dataset, the normalized dataset is serialized and encoded in the order of field keys, and the field identifiers and field values ​​are concatenated sequentially to form a version input sequence. The version input sequence is digested to obtain a version digest, and the version digest is used as the dataset version identifier. At the same time, the normalized dataset is fielded to form a field set, and a field identifier is generated for each field in the field set and a one-to-one binding relationship between the field identifier and the field value is established. Field keys are generated based on DID, policy identifier, dataset identifier, field identifier and dataset version identifier. Field values ​​are indexed and arranged according to field keys and a set of writable key-value pairs is output. The process involves constructing a Verkle tree with vector commitments as internal node commitments, taking a set of key-value pairs as input, and writing field values ​​into the tree. A branching factor is set to determine the tree height and node capacity at each level, and branch position numbers are assigned to each level. The key-value pair set is sorted in ascending order by field key, divided into different leaf node buckets according to a preset bucket size, and a bucket number is assigned to each leaf node bucket. A bucket identifier is generated by combining the bucket number with the dataset version identifier. Field values ​​within each leaf node bucket are type-labeled and encoded according to the field identifier order, and then aligned with a fixed length to form leaf vectors. Simultaneously, the leaf vectors are loaded into the corresponding leaf node slots. Based on the common parameters of vector commitments, leaf commitments are generated element-wise from the leaf vectors, and the leaf commitments and bucket identifiers are written to the corresponding leaf nodes. The leaf node index is output. For each upper-level internal node, the commitments of all child nodes are collected, and sub-commitment vectors are formed according to branch position numbers. Based on the same common parameters of vector commitments, internal node commitments are generated from the sub-commitment vectors and written to the internal nodes. The internal node index is output. This process of set, compose, commit, and write is repeated layer by layer from the leaf layer until the root layer is generated, producing the root layer internal node commitment, which serves as the dataset commitment root and is output.

[0023] This invention maps on-chain DIDs to the key space and performs unified normalization and version digest generation on the dataset to be shared, so that the field key is simultaneously bound to identity, policy and dataset version. Then, a Verkle tree is constructed with vector commitment as the internal node commitment structure, and field-level indexing and commitment root output are achieved by writing fixed-length aligned leaf vectors. Compared with Merkle tree, Verkle tree can obtain more compact opening and verification materials in multi-field scenarios to reduce proof and on-chain overhead. DID, policy identifier, dataset identifier and version identifier are jointly encoded into the field key and coupled with the vector commitment Verkle structure to form an auditable, batch-verifiable and cross-version distinguishable dataset commitment system.

[0024] In this embodiment, obtaining the on-chain queryable anchor records and policy registration records specifically includes: Load the dataset commitment root, dataset version identifier, and policy identifier as anchor registration inputs and form an anchor registration request; An anchor registration request is submitted by calling the anchor registration interface of the blockchain smart contract. When submitting, the anchor registration request is concatenated into an anchor input sequence in a preset order and the summary calculation is performed to obtain the anchor summary. The anchor summary, the dataset commitment root, the dataset version identifier and the policy identifier are written on the chain to form an anchor registration transaction. The blockchain smart contract is a computer program that automatically executes, controls or documents legal and commercial agreements, runs on the blockchain, and automatically completes transactions or operations without third-party intervention according to preset conditions. The blockchain smart contract executes the anchor registration transaction and obtains the anchor record and the strategy registration record. The anchor record includes the dataset commitment root, the dataset version identifier, the strategy identifier, and the anchor registration transaction index. The strategy registration record includes the strategy identifier and the associated strategy version information.

[0025] In this embodiment, the generation of the batch opening proof package for the field set specifically includes: Read the policy registration records and obtain the field identifiers from them. Then, remove duplicate field identifiers according to the preset field order and generate a field set. Read the anchor record, obtain the dataset commitment root and dataset version identifier corresponding to the shared verification, and generate field keys that correspond one-to-one with each field identifier under the key space mapping based on the field set. Arrange each field key and its corresponding field identifier to form a field key list. Based on the list of field keys, batch leaf node location is performed in the Verkle tree corresponding to the commitment root of the dataset to determine the leaf node position and branch path of each field key. The leaf node index, branch index and sibling node commitments of each field key are encapsulated in the order of field keys to form a batch open proof package.

[0026] In this embodiment, the generation of the zero-knowledge proof bound to the batch opening of the proof package specifically includes: Read the policy registration record, obtain the policy identifier and policy version information, and obtain the field identifier and verification parameter index corresponding to the policy identifier. Based on the policy identifier and policy version information, locate the corresponding policy constraint parameter group from the preset policy set, load the policy constraint parameter group into a policy constraint set in a preset order, and generate a field order table that corresponds one-to-one with the field identifier. The batch opening proof package is sequentially read according to the field order table. The opening field value corresponding to each field identifier is read item by item and written into the field value sequence. The field key corresponding to each field identifier is read item by item and written into the field key list. The leaf node index, branch index and sibling node commitment corresponding to each field key are read item by item and written into the list. The dataset commitment root and dataset version identifier are written into the root parameter and version parameter. The path material sequence refers to the sequence formed by writing the path material required for opening verification corresponding to each field key in the order of field keys. Based on the verification parameter index, the zero-knowledge proof circuit identifier and verification parameters that match the strategy identifier and strategy version information are retrieved from the strategy constraint parameter group of the preset strategy set. The root parameter, verification parameter, version parameter, strategy identifier, strategy version information, field key list, field value sequence, path material sequence and strategy constraint set are loaded into the zero-knowledge proof circuit in a preset loading order. The loading result is subjected to consistency verification and an intermediate buffer required for circuit operation is generated after the verification is passed. In the zero-knowledge proof circuit, the correctness verification of the batch opening proof package is performed. Leaf nodes are located item by item in the field key list to determine the leaf node slot corresponding to each field key. The branch path corresponding to each field key is traversed layer by layer upwards. The commitments of sibling nodes in the same layer are extracted layer by layer and numbered according to the branch position to form a sub-commitment vector. Vector commitment calculation is performed on each sub-commitment vector to obtain the commitment of the node in the current layer. The iteration continues upwards until the root layer obtains the reconstructed root commitment. The reconstructed root commitment is compared with the dataset commitment root obtained from the anchor record. Equality constraints are applied in the circuit to make the two consistent, thereby completing the correctness verification of the batch opening proof package relative to the dataset commitment root. After passing the correctness verification, policy constraints and consistency constraints are performed in the zero-knowledge proof circuit. The policy constraints take values ​​from the field value sequence as policy calculation inputs and perform range comparison, equality comparison, set membership judgment, threshold accumulation comparison, and OR logic combination judgment item by item in the order of the constraint item list. The judgment result of each constraint item is written into the constraint result sequence and a satisfaction constraint is applied to make each judgment result true. The consistency constraints compare the policy calculation input with the open field values ​​at the corresponding positions in the field value sequence item by item and apply an equality constraint in the circuit to make the two consistent item by item. After the constraints are completed, the zero-knowledge proof generation is called to obtain the generated zero-knowledge proof. The zero-knowledge proof generation refers to calculating the loaded zero-knowledge proof circuit, public input, and generated witness together with the corresponding proof parameters according to the preset generation process, and outputting a zero-knowledge proof that is bound to the public input and can be verified by the verification parameters.

[0027] This invention, through a policy registration record-driven circuit and verification parameter loading, writes the field keys, field values, and path materials of batch-opened proof packages into the circuit in a defined order, and reconstructs the root commitment and anchored dataset commitment root within the circuit, applying equality constraints. Simultaneously, it applies consistency constraints to the policy calculation input and the opened field values, and executes policy constraints such as range, equivalence, set membership, and logical combination, generating zero-knowledge proofs that are strongly bound to the public input and can be verified by the corresponding verification parameters. This achieves joint proof of the correctness of the shared field source and policy compliance, improving the verification credibility and efficiency in large-scale field sharing scenarios and reducing on-chain verification costs.

[0028] In this embodiment, the process of submitting the verification submission package composed of zero-knowledge proof and anti-replay identifier to the smart contract specifically includes: Read the anchoring record and policy registration record, locate the anchoring entry and policy entry corresponding to this verification, extract and solidify them into anchoring context and policy context, read the zero-knowledge proof and write it into the proof context, and merge the anchoring context, policy context and proof context to generate the anti-replay input context. Perform integrity and non-empty checks on the anti-replay input context, and simultaneously serialize and concatenate it according to the preset loading order to obtain the input sequence; A digest calculation is performed on the input sequence to generate a nullifier, which is then written into the anti-replay identifier empty space to obtain an anti-replay output parameter group. The anti-replay output parameter group is written into the anti-replay field and together with the zero-knowledge proof constitutes a verification submission package and is submitted to the smart contract. The nullifier refers to a unique anti-replay identifier generated by calculating a preset digest from the anchor context, policy context, and public input digest of the zero-knowledge proof corresponding to this verification. It is used to perform a used-update check on the verification submission package on the smart contract side to prevent the same verification submission package from being submitted repeatedly.

[0029] This invention solidifies anchor records, policy registration records, and zero-knowledge proof public input summaries into a unified anti-replay input context. After integrity verification, a nullifier strongly bound to the verification context is generated. This enables smart contracts to reliably determine the usability of verification submission packages based on this unique identifier, thereby effectively preventing duplicate submissions and cross-context misappropriation of the same verification submission package. This improves the security and auditability of trusted verification of data sharing and reduces the overhead of on-chain verification and state maintenance caused by replay attacks.

[0030] In this embodiment, the output of the event log specifically includes: The smart contract receives the verification submission packet and performs structured parsing, extracting the zero-knowledge proof, anti-replay identifier, index information for locating anchor records, strategy information for locating strategy registration records, and index information for locating verification parameters in sequence. The parsed data is written into the contract running parameter area according to preset fields, and a parsing integrity mark is generated to indicate that the verification submission packet has been parsed. Under the condition that the parsing integrity mark is valid, the smart contract locates the policy entry and policy version entry corresponding to this verification, further combines the on-chain identity status to locate the authorization validity record and revocation status record, and performs consistency verification. After the verification is passed, the verification parameters are loaded as the contract verification parameters for this zero-knowledge proof verification. The contract verification parameters are used to instruct the smart contract to use the verification key and verification configuration corresponding to this policy version, and to limit the public input structure required for zero-knowledge proof verification, thereby realizing the correct verification of zero-knowledge proof and the constraint on cross-policy misappropriation. The smart contract queries the anti-replay status mapping table based on the anti-replay identifier and contract verification parameters. If the query result is an unused state, an anti-replay pass flag is generated and zero-knowledge proof verification continues. If the query result is a used state, a verification failure state is written and a failure event log is output. After successful verification, the anti-replay identifier is written to the anti-replay status mapping table and set to the used state, and an anti-replay status update completion flag is generated.

[0031] This invention achieves correct verification of zero-knowledge proofs and cross-policy misappropriation constraints by performing structured parsing of verification submission packets on the smart contract side and forming parsing integrity markers. It combines on-chain identity status to locate authorization validity records and revocation status records and completes consistency verification. The verification key and verification configuration corresponding to the policy version are loaded as contract verification parameters to limit the public input structure required for zero-knowledge proofs. Furthermore, the anti-replay flag is used in conjunction with the contract verification parameters for anti-replay status query and update. While ensuring the output of auditable event logs, this invention improves the determinism and security of on-chain trusted verification and reduces the verification overhead caused by parameter mismatch and replay abuse.

[0032] Example 1: To verify the feasibility of this invention in practice, it was applied to a multi-party data sharing and verification scenario. In this scenario, there are data providers, data users, and a smart contract verification system deployed on a blockchain. The data provider registers its identity on the blockchain based on a decentralized identity (DID) and obtains the corresponding on-chain identity status. The data user needs to verify, without obtaining the original plaintext data, whether the shared data truly originates from the specified dataset, whether it meets the pre-agreed policy constraints, and whether the data sharing authorization is still valid and has not been revoked.

[0033] In this scenario, the data provider holds a large-scale structured dataset containing hundreds of fields, including strings, numbers, timestamps, and optional fields. Some fields involve sensitive information that cannot be directly exposed during sharing. Existing technologies typically use a method of calculating a single hash value for the entire dataset and uploading it to the blockchain for anchoring. When the data user only needs to verify whether a few fields meet specific policy constraints, they still need to provide the entire dataset or a complete proof path. This results in a large amount of verification data, a high risk of privacy exposure, and high on-chain verification costs. In addition, existing solutions lack a binding mechanism for the verification context in multiple verification scenarios, which can easily lead to the same verification material being submitted repeatedly or reused across policies.

[0034] In this embodiment, the data provider first reads its on-chain identity status and extracts the corresponding DID, using this DID as one of the basic inputs for key space mapping. Then, it retrieves the dataset to be shared from the local system database and performs normalization encoding on the dataset. This includes unifying the character set and removing invisible characters from string fields, normalizing field names using aliases, performing unit conversion and rounding on numeric fields, converting time fields to a standard time format, and marking missing values ​​as placeholders according to preset rules, thus obtaining a normalized dataset. After normalization, the dataset is serialized and encoded according to the field keys, and a digest is calculated to generate a dataset version identifier, ensuring that different versions of data can be accurately distinguished subsequently.

[0035] Based on the normalized dataset, the system further performs fieldization processing, generating a unique field identifier for each field. This identifier, combined with the DID, policy identifier, dataset identifier, and dataset version identifier, generates a field key. A writable key-value pair set is formed by binding each field key to its value. Then, a Verkle tree construction algorithm, using vector commitments as the internal node commitment structure, is employed to write the key-value pair set into the Verkle tree. During construction, the tree height and node capacity are determined based on a preset branching factor. Field values ​​are then encoded with fixed-length alignment to form leaf vectors. Leaf node commitments and internal node commitments are generated layer by layer, ultimately yielding the dataset commitment root. This dataset commitment root is written to the blockchain as an anchor record, allowing any subsequent verification to determine the consistency of the data source.

[0036] When data sharing verification is required, the data provider selects a set of fields related to the sharing strategy from the Verkle tree based on the data user's needs, generating a corresponding batch open proof package. Subsequently, based on the policy constraints defined in the on-chain policy registration record, a zero-knowledge proof circuit is constructed. This circuit verifies the correctness of the batch open proof package, ensuring that the opened fields indeed originate from the anchored dataset commitment root. Simultaneously, policy constraint calculations are performed within the circuit, including range checks, equivalence checks, and set membership checks, and consistency constraints are applied to ensure that the field values ​​participating in the policy calculation are consistent with the actual opened field values. After completing the above calculations, a zero-knowledge proof is generated.

[0037] To prevent the same verification material from being reused or misappropriated across policies, this embodiment serializes and concatenates the anchor context, policy context, and public input digest of the zero-knowledge proof before submitting the verification request, calculates the digest, generates a unique anti-replay identifier, and encapsulates this anti-replay identifier along with the zero-knowledge proof into a verification submission package and submits it to the smart contract. Upon receiving the verification submission package, the smart contract first performs structured parsing to generate a parsing integrity marker, then locates the corresponding policy entry, policy version, and on-chain identity status, completes authorization validity and revocation status verification, and loads contract verification parameters matching the policy version. Based on this, it performs a usage verification on the anti-replay identifier, performing zero-knowledge proof verification and updating the anti-replay status only if the identifier is unused.

[0038] To verify the beneficial effects of this invention, under the same data scale and policy constraints, the proposed solution was compared with a solution using a traditional Merkle tree structure and directly verifying hash paths on the blockchain. The traditional Merkle tree structure uses the hashes of each field in the dataset as leaf nodes, merging them layer by layer to generate the parent node hash and finally obtaining the root hash. Verification is performed by submitting the hash path from the leaf to the root to prove that a certain field belongs to the current dataset. Specific comparison data is shown in the table below: Table 1. Performance Comparison of Different Schemes in DID Data Sharing Trusted Verification Scenarios

[0039] As shown in Table 1, with a total of 512 fields in the dataset and 16 fields actually involved in the verification, the data volume required for a single verification in this invention is reduced from approximately 48KB in the traditional Merkle tree scheme to approximately 9KB. The average on-chain verification time is reduced from approximately 180ms to approximately 65ms. At the same time, the high complexity of the "on-chain calculation steps for a single verification" caused by multi-path verification is reduced to the low complexity of batch vector commitment verification. In multiple verification scenarios, this invention achieves a high interception rate through on-chain use verification based on anti-replay identifiers, while traditional schemes have lower interception capabilities due to their greater reliance on external logic. In addition, this invention only exposes public inputs and proofs, reducing the risk of privacy leakage from medium to low. Thus, it demonstrates the comprehensive beneficial effects of improved trusted verification efficiency and reduced on-chain notarization and verification overhead in shared data scenarios.

[0040] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A trusted verification method for blockchain DID data sharing based on zero-knowledge proof, characterized in that, Includes the following steps: Generate a DID, issue a verifiable credential VC and complete on-chain registration to form an on-chain identity status; Based on the on-chain identity state, the shared dataset is normalized, fielded, and a key space mapping is constructed. A Verkle tree with vector commitment as the internal node commitment structure is constructed and field values ​​are written to obtain the dataset commitment root and determine the dataset version identifier. Anchoring is performed on the dataset commitment root and dataset version identifier to obtain on-chain queryable anchoring records and policy registration records; Based on the policy registration records, select a set of fields from the Verkle tree and generate a batch open proof package for the set of fields; Based on the policy registration record, policy constraints are determined and a zero-knowledge proof circuit is constructed. The correctness of the batch opening proof package is verified, and the policy calculation input is constrained to be consistent with the opening field value, generating a zero-knowledge proof bound to the batch opening proof package. Based on the dataset commitment root, anchor record and policy registration record, generate anti-replay identifier, and combine zero-knowledge proof and anti-replay identifier to form a verification submission package and submit it to smart contract; The smart contract verifies the validity of revocation and authorization based on the verification of the submission package and the policy registration record, and outputs the event log.

2. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The formation of the on-chain identity state specifically includes: The data subject generates a decentralized identity identifier (DID) and a corresponding DID document, and writes each verification public key into the corresponding verification method entry. The policy identifier is selected from the preset policy set to form a parsable DID document. The DID document fingerprint is obtained by digesting the parsable DID document. The DID and DID document fingerprint are written into the blockchain and an on-chain registration index is obtained. The authorization validity record and revocation status record are located through the on-chain registration index to form a queryable DID registration record, which serves as the identity registration part of the on-chain identity status. The issuer issues a verifiable credential VC for the DID, calculates a digest of the VC to obtain a credential digest and generates a signature, and registers the credential digest and related status information on the blockchain to form a VC status record, which together with the DID registration record forms the on-chain identity status.

3. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The specific steps for obtaining the committed root of the dataset and determining the dataset version identifier include: Read the on-chain identity status and extract the DID, then write the DID into the input parameter set of the key space mapping; The system database of the data provider is used to obtain the dataset to be shared and determine the dataset identifier used to locate the original data. At the same time, normalization encoding is performed and the normalized dataset is output. Based on the normalized dataset, the normalized dataset is serialized and encoded in the order of field keys, and the field identifiers and field values ​​are concatenated sequentially to form a version input sequence. The version input sequence is digested to obtain a version digest, and the version digest is used as the dataset version identifier. At the same time, the normalized dataset is fielded to form a field set, and a field identifier is generated for each field in the field set and a one-to-one binding relationship between the field identifier and the field value is established. Field keys are generated based on DID, policy identifier, dataset identifier, field identifier and dataset version identifier. Field values ​​are indexed and arranged according to field keys and a set of writable key-value pairs is output. The process involves constructing a Verkle tree with vector commitments as internal node commitments, taking a set of key-value pairs as input, and writing field values ​​into the tree. A branching factor is set to determine the tree height and node capacity at each level, and branch position numbers are assigned to each level. The key-value pair set is sorted in ascending order by field key, divided into different leaf node buckets according to a preset bucket size, and a bucket number is assigned to each leaf node bucket. A bucket identifier is generated by combining the bucket number with the dataset version identifier. Field values ​​within each leaf node bucket are type-labeled and encoded according to the field identifier order, and then aligned with a fixed length to form leaf vectors. Simultaneously, the leaf vectors are loaded into the corresponding leaf node slots. Based on the common parameters of vector commitments, leaf commitments are generated element-wise from the leaf vectors, and the leaf commitments and bucket identifiers are written to the corresponding leaf nodes. The leaf node index is output. For each upper-level internal node, the commitments of all child nodes are collected, and sub-commitment vectors are formed according to branch position numbers. Based on the same common parameters of vector commitments, internal node commitments are generated from the sub-commitment vectors and written to the internal nodes. The internal node index is output. This process of set, compose, commit, and write is repeated layer by layer from the leaf layer until the root layer is generated, producing the root layer internal node commitment, which serves as the dataset commitment root and is output.

4. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The specific methods for obtaining the on-chain queryable anchor records and policy registration records include: Load the dataset commitment root, dataset version identifier, and policy identifier as anchor registration inputs and form an anchor registration request; An anchor registration request is submitted by calling the anchor registration interface of the blockchain smart contract. When submitting, the anchor registration request is concatenated into an anchor input sequence in a preset order and the summary calculation is performed to obtain the anchor summary. The anchor summary, the dataset commitment root, the dataset version identifier and the policy identifier are written on the chain to form an anchor registration transaction. The blockchain smart contract executes the anchor registration transaction and obtains the anchor record and the strategy registration record. The anchor record includes the dataset commitment root, the dataset version identifier, the strategy identifier, and the anchor registration transaction index. The strategy registration record includes the strategy identifier and the associated strategy version information.

5. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The generation of the batch opening proof package for the field set specifically includes: Read the policy registration records and obtain the field identifiers from them. Then, remove duplicate field identifiers according to the preset field order and generate a field set. Read the anchor record, obtain the dataset commitment root and dataset version identifier corresponding to the shared verification, and generate field keys that correspond one-to-one with each field identifier under the key space mapping based on the field set. Arrange each field key and its corresponding field identifier to form a field key list. Based on the list of field keys, batch leaf node location is performed in the Verkle tree corresponding to the commitment root of the dataset to determine the leaf node position and branch path of each field key. The leaf node index, branch index and sibling node commitments of each field key are encapsulated in the order of field keys to form a batch open proof package.

6. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The generation of zero-knowledge proofs bound to the batch opening of proof packages specifically includes: Read the policy registration record and obtain the field identifier and verification parameter index corresponding to the policy identifier. Based on the policy identifier and policy version information, locate the corresponding policy constraint parameter group from the preset policy set, load the policy constraint parameter group into a policy constraint set in a preset order, and generate a field order table that corresponds one-to-one with the field identifier. Based on the field order table, perform sequential reading of the batch open proof package, read the open field value corresponding to each field identifier item by item and write it into the field value sequence, read the field key corresponding to each field identifier item by item and write it into the field key list, read the leaf node index, branch index and sibling node commitment corresponding to each field key item by item and write it, and write the dataset commitment root and dataset version identifier into the root parameter and version parameter. Based on the verification parameter index, the zero-knowledge proof circuit identifier and verification parameters that match the strategy identifier and strategy version information are retrieved from the strategy constraint parameter group of the preset strategy set. The root parameter, verification parameter, version parameter, strategy identifier, strategy version information, field key list, field value sequence, path material sequence and strategy constraint set are loaded into the zero-knowledge proof circuit in a preset loading order. In the zero-knowledge proof circuit, the correctness of the batch opening proof package is verified. Leaf nodes are located item by item in the field key list to determine the leaf node slot corresponding to each field key. The branch path corresponding to each field key is traversed layer by layer upwards. The commitments of sibling nodes in the same layer are extracted layer by layer and numbered according to the branch position to form a sub-commitment vector. Vector commitment calculation is performed on each sub-commitment vector to obtain the commitment of the node inside the current layer. The iteration continues upwards until the root layer obtains the reconstructed root commitment. The reconstructed root commitment is compared with the dataset commitment root obtained from the anchor record for consistency. Equality constraints are applied in the circuit to make the two consistent. After passing the correctness verification, policy constraints and consistency constraints are performed in the zero-knowledge proof circuit. The policy constraints take values ​​from the field value sequence as the policy calculation input, and perform range comparison, equality comparison, set membership judgment, threshold accumulation comparison and OR logic combination judgment item by item in the order of the constraint item list. The judgment result of each constraint item is written into the constraint result sequence and a satisfaction constraint is applied to make each judgment result true. The consistency constraint compares the policy calculation input with the open field value at the corresponding position in the field value sequence item by item, and applies an equality constraint in the circuit to make the two consistent item by item. After the constraints are completed, the zero-knowledge proof is generated by calling the zero-knowledge proof generator.

7. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The process of submitting a verification submission package consisting of zero-knowledge proofs and anti-replay identifiers to the smart contract specifically includes: Read the anchoring record and policy registration record, locate the anchoring entry and policy entry corresponding to this verification, extract and solidify them into anchoring context and policy context, read the zero-knowledge proof and write it into the proof context, and merge the anchoring context, policy context and proof context to generate the anti-replay input context. Perform integrity and non-empty checks on the anti-replay input context, and simultaneously serialize and concatenate it according to the preset loading order to obtain the input sequence; Perform a digest calculation on the input sequence to generate a nullifier, and write the nullifier into the anti-replay flag empty space to obtain the anti-replay output parameter group. Write the anti-replay output parameter group into the anti-replay field, and together with the zero-knowledge proof, form a verification submission package to be submitted to the smart contract.

8. The blockchain DID data sharing trusted verification method based on zero-knowledge proof according to claim 1, characterized in that, The output of the event log specifically includes: The smart contract receives the verification submission packet and performs structured parsing. It writes the parsed data into the contract running parameter area according to preset fields and generates a parsing integrity flag. Under the condition that the parsing integrity mark is valid, the smart contract locates the policy entry and policy version entry corresponding to this verification, further combines the on-chain identity status to locate the authorization validity record and revocation status record, and performs consistency verification. After the verification passes, the verification parameters are loaded as the contract verification parameters for this zero-knowledge proof verification. The smart contract queries the anti-replay status mapping table based on the anti-replay identifier and contract verification parameters. If the query result is an unused state, an anti-replay pass flag is generated and zero-knowledge proof verification continues. If the query result is a used state, a verification failure state is written and a failure event log is output. After successful verification, the anti-replay identifier is written to the anti-replay status mapping table and set to the used state, and an anti-replay status update completion flag is generated.

Images