Distributed identity credential hiding verification method and system based on zero-knowledge proof

Abstract

This invention discloses a distributed identity credential hiding verification method and system based on zero-knowledge proof. The service platform selects a signature algorithm to sign verifiable credentials according to privacy protection requirements and returns the signature to the user. The user uses the credential subject attributes and holder identity identifier as private witnesses, and the verification strategy, credential template definition, and anti-replay identifier as public inputs to generate a zero-knowledge proof within the circuit. The verifier receives the proof, obtains the verification key, executes the protocol verification, and verifies the uniqueness of the anti-replay identifier. This invention completely hides user privacy during the verification process and effectively defends against replay attacks by using user identity and credential content as private inputs to the circuit and only exposing necessary business metadata.

Description

Technical Field

[0001] This invention relates to the fields of information security and blockchain technology, and in particular to a distributed identity credential hiding verification method and system based on zero-knowledge proof. Background Technology

[0002] In distributed identity (DID) systems, users often need to present verifiable credentials (VCs) to the verifier to prove their qualifications. To protect user privacy, zero-knowledge proof (ZKP) technology has been introduced, aiming to achieve selective disclosure—that is, users can prove to the verifier that they meet certain conditions without revealing the full content of their credentials. However, existing solutions combining DID and ZKP still have fundamental privacy risks in practice. Many solutions can only achieve partial hiding; the verifier still needs to know metadata such as the credential type and issuer, and may even need to expose the user's identity at certain stages. This allows the verifier not only to obtain the verification result but also to associate and analyze the user's metadata, failing to truly achieve the goal of anonymized verification and constituting a structural vulnerability in privacy protection. Summary of the Invention

[0003] In view of this, the purpose of this invention is to propose a distributed identity credential hiding verification method and system based on zero-knowledge proof, which completely hides the user identity and credential content during the credential verification process by treating the user identity and credential attributes as private inputs of the circuit and only exposing the necessary business metadata.

[0004] To achieve the aforementioned technical objectives, in a first aspect, the technical solution adopted by this invention is: a distributed identity credential hiding verification method based on zero-knowledge proof, comprising: The service platform responds to the user's request for the issuance of verifiable credentials, selects a signature algorithm based on privacy protection requirements to sign the verifiable credentials, and returns the signed verifiable credentials to the user. Users obtain verifiable credentials, convert the credential subject attributes and holder identity into the circuit's private witness, convert the verification strategy, credential template definition and anti-replay identifier into the circuit's public input, and generate zero-knowledge proofs within the circuit based on the private witness and public input; The verifier receives the zero-knowledge proof, obtains the corresponding verification key, uses the verification key to execute the zero-knowledge proof protocol for verification, and verifies the uniqueness of the anti-replay identifier. If the verification passes, the verification is considered successful.

[0005] In some embodiments, in response to a user's request for the issuance of a verifiable credential, the service platform selects a signature algorithm based on privacy protection requirements to sign the verifiable credential, and returns the signed verifiable credential to the user, including: The service platform receives verifiable credential issuance requests initiated by users, and the verifiable credential issuance requests include privacy protection requirements; In response to a verifiable credential issuance request, the service platform queries the blockchain to obtain the credential template definition and fills in the credential body fields based on the template definition. The credential body fields include attribute names and attribute values, and the issuance time and expiration time are set as the validity period. The service platform selects the appropriate signature algorithm based on privacy protection requirements: If privacy protection requirements indicate that the credential content should be hidden, the service platform will use the EdDSA algorithm to sign the key fields of the credential. The key fields of the credential include the credential context, credential identifier, credential type, issuer's distributed identity identifier, credential template unique identifier, template name, template version and template content, issuance time, expiration time, domain hash mapping of the holder's distributed identity identifier, and the hash value of the credential body fields concatenated with the public key. If privacy protection requirements indicate that there is no need to hide the credential content, the service platform uses the SM2 algorithm to sign the key fields of the credential; The service platform will return a verifiable credential containing the corresponding signature to the user.

[0006] In some embodiments, if privacy protection requirements instruct the hiding of credential content, the service platform uses the EdDSA algorithm to sign key fields of the credential, including: When the service platform uses the EdDSA algorithm to sign key fields of a credential, it concatenates the credential context, credential identifier, credential type, issuer's distributed identity identifier, credential template unique identifier, template name, template version and template content, issuance time, expiration time, domain hash mapping of the holder's distributed identity identifier, and all fields of the credential body with the public key, and then calculates the MiMC hash digest as the signature message. The service platform uses the issuer's EdDSA private key to perform EdDSA signature on the MiMC hash digest under the Twisted Edwards curve based on the Gnark framework, generating an EdDSA signature value containing the coordinates of the R point and the S scalar. The service platform appends the EdDSA signature value to the verifiable credential.

[0007] In some embodiments, if privacy protection requirements indicate that the credential content does not need to be hidden, the service platform uses the SM2 algorithm to sign the key fields of the credential, including: The service platform adopts the traditional model, using the issuer's SM2 private key to sign the key fields of the certificate using the national cryptographic standard SM2WithSM3. The key fields of the certificate include the certificate context, certificate identifier, certificate type, issuer's distributed identity identifier, certificate template definition, issuance time, expiration time, holder's distributed identity identifier, and all fields of the certificate body. The service platform will return verifiable credentials containing an SM2 signature to the user.

[0008] In some embodiments, a user obtains a verifiable credential, converts the credential subject attributes and holder identity into a private witness of the circuit, converts the verification strategy, credential template definition, and anti-replay identifier into public inputs of the circuit, and generates a zero-knowledge proof within the circuit based on the private witness and public inputs, including: Users obtain their own distributed identity, key pair, and verifiable credentials to be displayed, and determine to adopt the zero-knowledge proof mode; The user converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity based on a preset salt value, the domain hash mapping of the presenter's distributed identity based on a preset salt value, the credential validity period consisting of the issuance time and expiration time, the issuer's EdDSA public key and EdDSA signature value, and the blacklist non-member proof data containing the values ​​of the predecessor neighbor node, the value of the successor neighbor node, the left node index, and the Merkle of both sides containing the proof path and the empty blacklist boundary status identifier into the circuit's private witness. The holder's distributed identity and the presenter's distributed identity are subject to strengthened consistency assertion constraints within the circuit. The user divides the following into blocks: credential context, credential identifier (sliced ​​into blocks according to a preset maximum number of blocks), credential type, issuer distributed identity identifier (sliced ​​into blocks according to a preset maximum number of blocks), credential template definition (containing template identifier, template name, and template version), verification strategy (containing policy identifier, policy version, and specific policy rules), root hash of the Merkle tree sorted by blacklist, current verification time, anti-replay identifier generated by hashing based on the holder's distributed identity identifier field hash value, credential identifier blocks, and session random number, and converts the one-time session random number provided by the verifier into the circuit's public input; Within the circuit, the user calculates the anti-replay identifier based on a four-parameter hash formula that includes the hash value of the holder's distributed identity field, the first block of the credential identifier, the second block of the credential identifier, and the session random number, and applies strong assertion constraints to the hash calculation process. Based on private witness and public input, the user generates a Groth16 zero-knowledge proof and the corresponding public input using the proof key corresponding to the PackedCount encoded value, and uses their own SM2 private key to perform SM2WithSM3 signature on the entire verifiable display containing the zero-knowledge proof.

[0009] In some embodiments, the user converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity based on a preset salt value, the domain hash mapping of the presenter's distributed identity based on a preset salt value, the credential validity period consisting of the issuance time and expiration time, the issuer's EdDSA public key and EdDSA signature value, and the blacklist non-member proof data containing the values ​​of the predecessor neighbor node, the successor neighbor node, the left node index, and the Merkle of both sides containing the proof path and the empty blacklist boundary status identifier into a private witness for the circuit, including: Users use the name hash value and attribute value of each attribute field in the plaintext data of the voucher body attributes as a key-value pair array, and perform padding according to the preset alignment step. Unoccupied slots are filled with zero values, so that voucher bodies with different numbers of fields can reuse the same circuit structure. Users perform domain hash mapping on the holder's distributed identity and the presenter's distributed identity using preset salt values, converting them into single finite field elements. They then apply strong consistency assertion constraints to both within the circuit to mathematically prove that the current presenter and the legitimate holder of the credential are the same entity, thus preventing credential theft and impersonation attacks. Users use the issuer's EdDSA public key and EdDSA signature value as a private witness input circuit, so that EdDSA signature verification is performed inside the circuit. The verifier cannot independently verify the signature outside the circuit, ensuring that all verification operations are securely completed within the zero-knowledge proof circuit. Users use the preceding neighbor node value, the succeeding neighbor node value, the left node index, the Merkle-containing proof path of both sides nodes, and the empty blacklist boundary status identifier in the blacklist non-member proof data as private witness input circuits, so that the circuit can complete the non-member proof verification of the sorted Merkle tree without exposing the holder's real identity hash value.

[0010] In some embodiments, the user calculates a replay protection identifier within the circuit based on a four-parameter hash formula comprising the holder's distributed identity field hash value, the first block of the credential identifier, the second block of the credential identifier, and a session random number, and imposes strong assertion constraints on the hash calculation process, including: Within the circuit, the user employs a circuit-friendly hash function, using the domain hash value of the holder's distributed identity identifier as the first parameter, the first block of the credential identifier as the second parameter, the second block of the credential identifier as the third parameter, and the session random number as the fourth parameter. The anti-replay identifier is calculated according to the four-parameter hash formula and submitted as a public input along with the zero-knowledge proof. Users impose strong assertion constraints on the hash calculation process of the anti-replay identifier within the circuit to ensure that the prover cannot forge a random hash value to replace the real anti-replay identifier, thus ensuring the security of the anti-replay mechanism at the circuit level. If the conventional mode is used, the session random number is fixed at zero as a public input, and the anti-replay identifier degenerates into a static value, which is suitable for single-verifier closed-loop verification scenarios. If the anti-association mode is adopted, the session random number is a non-zero one-time random number provided by the verifier, so that different sessions generate different anti-replay identifiers, preventing different verifiers from associating and tracking the user's presentation behavior, and fundamentally blocking the replay attack on the proof.

[0011] In some embodiments, the verifier receives a zero-knowledge proof, obtains the corresponding verification key, performs zero-knowledge proof protocol verification using the verification key, and verifies the uniqueness of the anti-replay identifier. If the verification passes, the verification is considered successful, including: The verifier receives verifiable demonstrations submitted by users, which include Groth16 zero-knowledge proofs and their corresponding public inputs; The verifier verifies the integrity of the SM2 signature on the outer layer of the verifiable display. After confirming that the verifiable display has not been tampered with, the verifier extracts the zero-knowledge proof and the public input. The validator extracts the template identifier and policy identifier from the public input, queries the blockchain to obtain the template definition and policy definition, and recalculates the PackedCount encoded value based on the actual number of fields. The verifier obtains the corresponding verification key from the blockchain based on the PackedCount encoded value. The verification key and the proof key are generated during the system initialization phase through the Trusted Setup of the Groth16 protocol. The verifier performs bilinear pairing operations on the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, and indirectly confirms that the five constraint blocks contained in the circuit—signature verification block, template verification block, validity period verification block, policy verification block, and blacklist verification block—are all satisfied. After the validator passes the Groth16 protocol verification, it extracts the anti-replay identifier from the public input, queries the blockchain record or local cache, and verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime. If it has not been used, it is registered as used. The verifier determines that the verification was successful and returns the verification result.

[0012] In some embodiments, the verifier performs bilinear pairing operations on the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, and indirectly confirms that the five constraint blocks contained within the circuit—signature verification block, template verification block, validity period verification block, policy verification block, and blacklist verification block—are all satisfied, including: After the verifier passes the Groth16 protocol verification, the verifier calls the smart contract or the blockchain trusted execution component, which then extracts the credential identifier, the issuer's distributed identity identifier, the policy identifier, the blacklist tree root hash, and the current verification time from the public input. The smart contract or trusted execution component calls the block splicing and restoration function to restore the credential identifier, issuer distributed identity identifier and policy identifier, which are stored in blocks in the form of a finite field element array in the public input, to the original complete string; The smart contract or trusted execution component uses the restored credential identifier and the issuer's distributed identity identifier as key-value pairs to query the on-chain credential issuance registration log, verifying whether the credential has a genuine historical issuance registration record, and preventing credentials forged out of thin air from passing verification; The smart contract or trusted execution component verifies whether the issuer of the credential is in the issuer blacklist maintained on the chain, and also verifies whether the issuer is in the trusted issuer list. The trusted issuer list is controlled by a global switch, and when it is turned off, all issuers are trusted by default. The smart contract or trusted execution component verifies whether the credential identifier is in the list of revoked credentials maintained on the chain, ensuring that invalidated credentials cannot pass privacy verification; The smart contract or trusted execution component will perform a real-time string strong consistency check between the restored policy identifier and the preset admission policy identifier associated with the current verification resource. If the two do not match, the verification will be deemed invalid. The smart contract or trusted execution component will perform a real-time strong consistency comparison between the blacklist root hash in the publicly input blacklist tree and the latest blacklist sorted Merkle root hash currently maintained by the blockchain, to prevent the prover from using a self-built forged blacklist root to bypass non-member state verification. The smart contract or trusted execution component verifies whether the absolute value deviation between the current verification time in the public input and the consensus timestamp of the current block of the blockchain is within the maximum allowed delay range, preventing attackers from bypassing the anti-replay window by exploiting expired historical proofs.

[0013] In a second aspect, the present invention also provides a distributed identity credential hiding verification system based on zero-knowledge proof, used to execute the method described in the first aspect. The system includes a service platform module, a user terminal module, a verification service module, and a blockchain module. The service platform module is used to receive a verifiable credential issuance request initiated by a user. The verifiable credential issuance request includes privacy protection requirements. In response to the verifiable credential issuance request, the module queries the blockchain to obtain the credential template definition and fills in the credential body fields and validity period based on the template definition. According to the privacy protection requirements, the module selects the corresponding signature algorithm to sign the verifiable credential and publishes the verifiable credential containing the corresponding signature. The certificate is returned to the user; the user terminal module obtains its own distributed identity, key pair, and verifiable credentials to be displayed, and determines to adopt the zero-knowledge proof mode. It converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity, the domain hash mapping of the displayer's distributed identity, the credential validity period, the issuer's public key and signature value, and the blacklist non-member proof data into the circuit's private witness. It also converts the credential context, credential identifier chunks, credential type, issuer's distributed identity chunks, template definition, verification strategy, blacklist root hash, current verification time, anti-replay identifier, and session randomness. The data is converted into the public input of the circuit. Within the circuit, a replay protection identifier is calculated using a four-parameter hash formula, and strong assertion constraints are applied to the hash calculation process. Based on the private witness and the public input, a proof key is used to generate a Groth16 zero-knowledge proof and its corresponding public input. The verification service module receives verifiable displays submitted by the user and verifies the integrity of the outer signature. It extracts the template identifier and policy identifier from the public input, queries the blockchain to obtain the template definition and policy definition, recalculates the PackedCount encoded value, and obtains the corresponding verification key from the blockchain based on the PackedCount encoded value, executing the Groth... The 16-protocol verification algorithm uses bilinear pairing operations to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, indirectly confirming that all five constraint blocks inside the circuit are satisfied. It also verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime. If it has not been used, it is registered as used and the verification is deemed successful. The blockchain module is used to store credential template definitions, verification strategy definitions, verification keys, blacklist sorting Merkle tree root hashes, credential issuance registration logs, issuer blacklists, trusted issuer lists, revoked credential lists, and records of used anti-replay identifiers, and provides on-chain qualification and status verification services.

[0014] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: The present invention provides a distributed identity credential hiding verification method and system based on zero-knowledge proof. The service platform selects a signature algorithm to sign verifiable credentials according to privacy protection requirements and returns the signature to the user. The user uses the credential subject attributes and holder identity identifier as private witnesses, and the verification strategy and anti-replay identifier as public inputs to generate a zero-knowledge proof within the circuit. The verifier receives the proof, obtains the verification key based on the strategy identifier, executes protocol verification, and verifies the uniqueness of the anti-replay identifier. The present invention, by using user identity and credential content as private inputs to the circuit and only exposing necessary business metadata, achieves complete hiding of user privacy during the verification process and effectively defends against replay attacks. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram illustrating the process by which the service platform responds to a user's request for the issuance of a verifiable credential and returns a response, as described in the specific implementation. Figure 2 This is a schematic diagram of the process for generating zero-knowledge proofs based on private witnesses and public inputs, as described in the specific implementation method. Figure 3 This is a schematic diagram of the data flow for proof generation and verification in the Groth16 protocol described in the specific implementation method; Figure 4 This is a schematic diagram illustrating the principle of segmenting the holder's DID identifier as described in the specific implementation method; Figure 5 This is a schematic diagram illustrating the calculation process of the PackedCount encoded value as described in the specific implementation method; Figure 6 This is a schematic diagram of the EdDSA signature verification process within the circuit described in the specific implementation embodiment; Figure 7 This is a schematic diagram of the non-membership proof verification process of the sorted Merkle tree described in the specific implementation method; Figure 8 This is a schematic diagram illustrating the process by which the verifier receives and performs verification of zero-knowledge proofs, as described in the specific implementation method. Figure 9 This is a flowchart illustrating the Trusted Setup process described in the specific implementation method; Figure 10This is a schematic diagram of the architecture of the distributed identity credential hiding verification system based on zero-knowledge proof as described in the specific implementation. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] In a first aspect, this embodiment provides a distributed identity credential hiding verification method based on zero-knowledge proof, including: The service platform responds to the user's request for the issuance of verifiable credentials, selects a signature algorithm based on privacy protection requirements to sign the verifiable credentials, and returns the signed verifiable credentials to the user. Users obtain verifiable credentials, convert the credential subject attributes and holder identity into the circuit's private witness, convert the verification strategy, credential template definition and anti-replay identifier into the circuit's public input, and generate zero-knowledge proofs within the circuit based on the private witness and public input; The verifier receives the zero-knowledge proof, obtains the corresponding verification key, uses the verification key to execute the zero-knowledge proof protocol for verification, and verifies the uniqueness of the anti-replay identifier. If the verification passes, the verification is considered successful.

[0019] In this embodiment, the verifiable credential issuance request includes the user's intention regarding whether the credential content needs to be hidden in the subsequent verification process, i.e., a privacy protection requirement. The service platform parses this privacy protection requirement from the request and selects a matching signature algorithm accordingly: when the privacy protection requirement indicates that the credential content needs to be hidden, a zero-knowledge proof-friendly signature algorithm is selected to sign the verifiable credential; when the privacy protection requirement indicates that the credential content does not need to be hidden, a conventional signature algorithm is selected. As a data carrier in the distributed identity system, the verifiable credential contains elements such as the credential subject, issuer, validity period, and signature. After signing, its integrity and source credibility are guaranteed.

[0020] After obtaining a signed and verifiable credential, the user enters the zero-knowledge proof generation stage. The credential subject attribute is the specific information field about the user recorded in the verifiable credential, and the holder's identity identifier is the user's unique identity code in the distributed identity system. Both are private data that needs to be protected during the verification process. The user encodes this private data into a finite-field element that the circuit can process and marks it as a private witness, ensuring it is held locally by the user and not disclosed to the verifier. The verification strategy defines the verification conditions that the user must meet. The anti-replay identifier is used to uniquely identify this proof presentation to prevent the proof from being reused. Both are public inputs disclosed to the verifier during the verification process to execute the verification logic. The circuit defines the constraint relationships between all input data, strictly distinguishing between private witnesses and public inputs for management, thus clearly defining the verification boundaries while protecting privacy. This step, by separating private data from public data and inputting them into the circuit, enables the generation of a verifiable proof without revealing the credential subject attribute and holder's identity identifier.

[0021] The verification key and proof key are generated during the system initialization phase through the trust setting process of the zero-knowledge proof protocol, and they are paired. The verifier uses the obtained verification key to execute the verification algorithm of the zero-knowledge proof protocol, verifying the correctness of the proof through mathematical operations and confirming that the public input and private witness in the proof together satisfy all the preset constraints within the circuit. Verifying the uniqueness of the anti-replay identifier involves checking whether the identifier has been used within the valid time window or session period; if not, it is registered as used. When both the zero-knowledge proof verification and the anti-replay identifier uniqueness verification pass, the verifier considers the verification successful. This step, through a dual mechanism of verification key verification and anti-replay identifier deduplication verification, ensures the validity of the proof while defending against replay attacks.

[0022] This embodiment constructs a complete privacy protection chain for credential issuance, proof generation, and proof verification. This chain involves the service platform selecting signature algorithms based on privacy protection requirements, the user separating private data from public data and inputting it into the circuit to generate a zero-knowledge proof, and the verifier using the verification key to verify the proof and the uniqueness of the anti-replay identifier.

[0023] Please see Figure 1 In some embodiments, the service platform responds to a user's request for the issuance of a verifiable credential, selects a signature algorithm based on privacy protection requirements to sign the verifiable credential, and returns the signed verifiable credential to the user, including: The service platform receives verifiable credential issuance requests initiated by users, and the verifiable credential issuance requests include privacy protection requirements; In response to a verifiable credential issuance request, the service platform queries the blockchain to obtain the credential template definition and fills in the credential body fields based on the template definition. The credential body fields include attribute names and attribute values, and the issuance time and expiration time are set as the validity period. The service platform selects the appropriate signature algorithm based on privacy protection requirements: If privacy protection requirements indicate that the credential content should be hidden, the service platform will use the EdDSA algorithm to sign the key fields of the credential. The key fields of the credential include the credential context, credential identifier, credential type, issuer's distributed identity identifier, credential template unique identifier, template name, template version and template content, issuance time, expiration time, domain hash mapping of the holder's distributed identity identifier, and the hash value of the credential body fields concatenated with the public key. If privacy protection requirements indicate that there is no need to hide the credential content, the service platform uses the SM2 algorithm to sign the key fields of the credential; The service platform will return a verifiable credential containing the corresponding signature to the user.

[0024] In this embodiment, the privacy protection requirements in the verifiable credential issuance request are expressed through Boolean flags, enumeration values, or custom parameters, indicating whether the user needs to hide the credential content in subsequent verification stages (i.e., whether to use a zero-knowledge proof mode). After receiving the request through an application programming interface or communication protocol, the service platform parses out the privacy protection requirements as the basis for selecting the subsequent signature algorithm.

[0025] The voucher template definition is pre-stored on the blockchain. Its data structure includes a list of supported field names, data types for each field, required attribute identifiers, and constraints between fields. The service platform retrieves the voucher template definition by calling a smart contract or on-chain query interface. Based on the specified field structure, it fills the user-provided attribute values ​​into the corresponding voucher body fields. Each voucher body field consists of an attribute name and an attribute value. The service platform sets the current system time as the issuance time and calculates the expiration time based on business rules or the preset validity period in the template definition. Both together constitute the voucher's validity period.

[0026] When privacy protection requirements necessitate hiding the credential content, the service platform uses the EdDSA algorithm to sign the key fields of the credential. The EdDSA algorithm is zero-knowledge proof friendly, and its generated signature can be verified within the circuit with a small number of constraints, making it suitable for privacy protection scenarios where subsequent zero-knowledge proof generation is required. When privacy protection requirements do not require hiding the credential content, the service platform uses the SM2 algorithm to sign the key fields of the credential. The SM2 algorithm conforms to national cryptographic standards and is suitable for traditional verification scenarios that do not involve zero-knowledge proofs. In the key fields of the credential, the domain hash mapping of the holder's distributed identity is the result of converting the holder's distributed identity into finite field elements using a domain hash function. The hash value obtained by concatenating all fields of the credential body with the public key is the digest value calculated by concatenating all fields of the credential body with the issuer's public key and then using a hash function. Both serve as components of the signed message to ensure the integrity of the security content and the public key. Preferably, in addition to the EdDSA algorithm, other zero-knowledge proof friendly signature algorithms can be used as alternatives, such as variants based on Schnorr signatures or the BLS signature algorithm. The verification strategy and the current verification time are excluded from the signature coverage because they are dynamically passed in during verification and set during proof generation, rather than determined during issuance. This is to maintain the decoupling of credential issuance and verification strategy, as well as the flexibility of verification time.

[0027] The service platform will return a verifiable credential containing the original credential content and a signature value generated by a signature algorithm selected according to privacy protection requirements to the user via a secure communication channel. This verifiable credential includes the credential subject field, validity period, issuer information, and a digital signature used to ensure its integrity and source credibility. Based on this, the user can participate in subsequent zero-knowledge proof generation or traditional verification processes.

[0028] This embodiment uses a service platform to parse privacy protection requirements from requests, query the blockchain to obtain credential template definitions and fill in the credential subject fields and validity period, and select either EdDSA or SM2 algorithm to sign the key credential fields that cover the complete content of the credential based on privacy protection requirements. This enables dual-mode credential issuance support for both privacy protection scenarios and traditional scenarios, providing a credential foundation adapted to the privacy protection level for subsequent verification stages.

[0029] In some embodiments, if privacy protection requirements instruct the hiding of credential content, the service platform uses the EdDSA algorithm to sign key fields of the credential, including: When the service platform uses the EdDSA algorithm to sign key fields of a credential, it concatenates the credential context, credential identifier, credential type, issuer's distributed identity identifier, credential template unique identifier, template name, template version and template content, issuance time, expiration time, domain hash mapping of the holder's distributed identity identifier, and all fields of the credential body with the public key, and then calculates the MiMC hash digest as the signature message. The service platform uses the issuer's EdDSA private key to perform EdDSA signature on the MiMC hash digest under the Twisted Edwards curve based on the Gnark framework, generating an EdDSA signature value containing the coordinates of the R point and the S scalar. The service platform appends the EdDSA signature value to the verifiable credential.

[0030] In this embodiment, the concatenation result is used to calculate the MiMC hash digest as the signature message. The MiMC hash function has zero-knowledge proof friendly characteristics. When it is implemented in the circuit, the number of constraints required is far less than that of traditional hash functions such as SHA-256, which can significantly reduce the computational overhead of the subsequent zero-knowledge proof generation process.

[0031] The issuer's EdDSA private key is generated and securely stored by the issuer during system initialization using a key generation algorithm. The Gnark framework, as a zero-knowledge proof development framework, incorporates a circuit implementation of EdDSA signatures, supporting efficient signature verification within the circuit. The Twisted Edwards curve is the elliptic curve form used by the EdDSA algorithm, where point addition and scalar multiplication operations are computationally efficient. The EdDSA signature value is generated through the above signature process, where point R is a point on the elliptic curve, and the scalar S is a finite field element; together, they constitute a complete EdDSA signature.

[0032] The service platform appends the EdDSA signature value to a specified field or additional area of ​​the verifiable credential, so that the verifiable credential contains both the original credential content and the EdDSA signature value. After obtaining it, the user can use it to complete signature verification in subsequent zero-knowledge proof circuits.

[0033] This embodiment uses the MiMC hash function of the service platform to calculate the digest of the concatenated key fields of the credential as the signature message, and uses the issuer's EdDSA private key to generate an EdDSA signature value containing the coordinates of the R point and the S scalar under the Twisted Edwards curve based on the Gnark framework. This achieves zero-knowledge proof-friendly signature of the key fields of the credential, and provides a signature foundation for efficient signature verification in the circuit.

[0034] In some embodiments, if privacy protection requirements indicate that the credential content does not need to be hidden, the service platform uses the SM2 algorithm to sign the key fields of the credential, including: The service platform adopts the traditional model, using the issuer's SM2 private key to sign the key fields of the certificate using the national cryptographic standard SM2WithSM3. The key fields of the certificate include the certificate context, certificate identifier, certificate type, issuer's distributed identity identifier, certificate template definition, issuance time, expiration time, holder's distributed identity identifier, and all fields of the certificate body. The service platform will return verifiable credentials containing an SM2 signature to the user.

[0035] In this embodiment, the traditional mode refers to a verification method that does not involve zero-knowledge proofs and allows the verifier to directly view the complete content of the verifiable credential. This is suitable for filing or archiving scenarios where privacy protection is not required. The issuer's SM2 private key is generated and securely stored by the issuer during system initialization using the national cryptographic standard key generation algorithm. The national cryptographic standard SM2WithSM3 signature is a combination of the SM2 elliptic curve signature algorithm and the SM3 cryptographic hash algorithm. First, the SM3 hash function calculates a digest of the key fields of the credential, and then the SM2 signature algorithm signs the digest using the issuer's SM2 private key, conforming to the commercial cryptographic standards issued by the State Cryptography Administration.

[0036] The list of key fields for the credential is adapted to the characteristics of the traditional model: the credential template definition includes the complete data structure of the template; the holder's distributed identity is the original distributed identity string rather than the domain hash mapping result; and all fields in the credential body are the original field values ​​rather than hash values ​​concatenated with the public key. This is because in the traditional model, the verifier can directly view the credential content without needing to prepare a specific formatted signature message for the subsequent zero-knowledge proof circuit. The service platform returns the verifiable credential to the user through a secure communication channel. Upon receiving it, the verifier can verify the integrity and source credibility of the credential through SM2 signature verification.

[0037] This embodiment uses the traditional mode of the service platform and the issuer's SM2 private key to sign the key fields of the credential using the national cryptographic standard SM2WithSM3. This enables credential issuance support for verification scenarios that do not require privacy protection. Together with the zero-knowledge proof mode using EdDSA signature, it constitutes a dual-mode credential issuance system.

[0038] Please see Figures 2 to 5 In some embodiments, the user obtains a verifiable credential, converts the credential subject attributes and holder identity into a private witness for the circuit, converts the verification strategy, credential template definition, and anti-replay identifier into public inputs for the circuit, and generates a zero-knowledge proof within the circuit based on the private witness and public inputs, including: Users obtain their own distributed identity, key pair, and verifiable credentials to be displayed, and determine to adopt the zero-knowledge proof mode; The user converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity based on a preset salt value, the domain hash mapping of the presenter's distributed identity based on a preset salt value, the credential validity period consisting of the issuance time and expiration time, the issuer's EdDSA public key and EdDSA signature value, and the blacklist non-member proof data containing the values ​​of the predecessor neighbor node, the value of the successor neighbor node, the left node index, and the Merkle of both sides containing the proof path and the empty blacklist boundary status identifier into the circuit's private witness. The holder's distributed identity and the presenter's distributed identity are subject to strengthened consistency assertion constraints within the circuit. The user divides the following into blocks: credential context, credential identifier (sliced ​​into blocks according to a preset maximum number of blocks), credential type, issuer distributed identity identifier (sliced ​​into blocks according to a preset maximum number of blocks), credential template definition (containing template identifier, template name, and template version), verification strategy (containing policy identifier, policy version, and specific policy rules), root hash of the Merkle tree sorted by blacklist, current verification time, anti-replay identifier generated by hashing based on the holder's distributed identity identifier field hash value, credential identifier blocks, and session random number, and converts the one-time session random number provided by the verifier into the circuit's public input; Within the circuit, the user calculates the anti-replay identifier based on a four-parameter hash formula that includes the hash value of the holder's distributed identity field, the first block of the credential identifier, the second block of the credential identifier, and the session random number, and applies strong assertion constraints to the hash calculation process. Based on private witness and public input, the user generates a Groth16 zero-knowledge proof and the corresponding public input using the proof key corresponding to the PackedCount encoded value, and uses their own SM2 private key to perform SM2WithSM3 signature on the entire verifiable display containing the zero-knowledge proof.

[0039] In this embodiment, after obtaining their own distributed identity identifier as the current presenter's identity, the corresponding SM2 key pair, and the verifiable credential to be displayed, the user determines to adopt the zero-knowledge proof mode. The determination of the zero-knowledge proof mode is based on the signature type used when the verifiable credential was issued: if the credential uses an EdDSA signature, then the zero-knowledge proof mode must be used for verification; if the credential uses an SM2 signature, then the credential content can be directly displayed using the traditional mode.

[0040] The plaintext data of the credential's main attributes consists of the original values ​​of the user's specific information fields recorded in the verifiable credential. The holder's distributed identity, based on a preset salt value, is mapped using a domain hash function. This involves concatenating the holder's distributed identity with a preset salt value in big-endian string format, then converting it into a single finite field element. The preset salt value is pre-set and publicly available by the system to prevent rainbow table attacks. The presenter's distributed identity, also based on a preset salt value, is processed in the same way. The issuance time and expiration time constitute the credential's validity period, used for timeliness verification within the circuit. The issuer's EdDSA public key and EdDSA signature value are used to verify the correctness of the credential signature within the circuit. Blacklist non-member proof data (including predecessor / successor neighbor node values ​​and their Merkle inclusion proof paths, etc.) is used to prove within the circuit that the holder is not on the blacklist. The holder's and presenter's distributed identities mathematically prove that the current presenter and the legitimate credential holder are the same entity, preventing credential theft and impersonation attacks.

[0041] Because the finite field capacity of the BN254 elliptic curve is limited to 254 bits (approximately 32 bytes, with a secure usable range of 31 bytes), while the plaintext strings of conventional distributed identity identifiers are typically 50-62 bytes long, direct storage would exceed the representation range of a single finite field element. This embodiment slices large fields exceeding the 31-byte limit into 31-byte segments and represents them with a fixed length according to a preset maximum number of blocks. The preset maximum number of blocks is preset based on business requirements. In an implementation suitable for 50-62 byte distributed identity identifiers, the preset maximum number of blocks can be set to 2; when the business identifier is longer, the preset maximum number of blocks can be extended to 3 or more blocks. Slicing is done in 31-byte segments, with insufficient portions padded with zero bytes for alignment. When converting to finite field elements, the highest-order byte is set to zero to prevent overflow. Within the constraint system, the circuit assigns independent witness variable arrays to each segment for constraint, enabling it to participate in signature hash verification within the circuit. The original logical whole of the large field is equivalently restored by calling the segment concatenation and restoration function outside the circuit. The distributed identity identifier of the issuer is sliced ​​according to the preset maximum number of blocks, and the finite field element array after the blocks are processed in the same way.

[0042] The credential template definition includes a template identifier, template name, and template version, used within the circuit to verify whether the credential body field structure conforms to the template requirements. The verification strategy includes a strategy identifier, strategy version, and specific strategy rules, used within the circuit to verify whether user attributes meet the verification conditions. The root hash of the Merkle tree used for blacklist sorting is used within the circuit to verify the correctness of proofs from non-members on the blacklist. The current verification time is used for validity verification within the circuit. The anti-replay identifier is generated by hashing the holder's distributed identity domain hash value, credential identifier blocks, and session random number, used to defend against replay attacks on proofs. The session random number is a one-time random number provided by the verifier, used to prevent association attacks. Within the circuit, the anti-replay identifier is calculated using a four-parameter hash formula, and strong assertion constraints are applied to the hash calculation process to ensure that the prover cannot forge a random hash value to replace the real anti-replay identifier, thus ensuring the security of the anti-replay mechanism at the circuit level.

[0043] The PackedCount encoding value is obtained through bitwise operations. Its lower 16 bits store the aligned number of verifiable credential fields, and its higher 16 bits store the aligned number of policy rules. The encoding formula is: PackedCount equals the aligned number of policy rules shifted left by 16 bits, then bitwise ORed with the aligned number of credential fields. The aligned number of credential fields is the maximum of the template field number and the credential body field number, aligned upwards to a multiple of 5. The aligned number of policy rules is the actual number of rules, aligned upwards to a multiple of 5. Unoccupied slots are filled with zero values, and zero-value slots are ignored internally by a conditional skipping mechanism. This encoding value uniquely identifies a circuit configuration. Users obtain the corresponding proof key from local storage or the blockchain based on this encoding value. Users, based on private witnesses and public inputs, use the proof key to calculate the zero-knowledge proof and the corresponding public input using the proof generation algorithm of the Groth16 protocol. Verifiable display is the outer container of verifiable credential. It does not participate in the zero-knowledge proof circuit itself and is not subject to the constraint that the Gnark framework only supports EdDSA. Moreover, SM2 complies with the national cryptographic standard and is more suitable for protecting the integrity of verifiable display in the domestic blockchain environment. Therefore, the outer layer of verifiable display adopts SM2WithSM3 signature.

[0044] This embodiment uses sensitive information such as plaintext data of credential subject attributes, domain hash mapping of the holder's distributed identity identifier, and blacklist non-member proof data as private witnesses, and public information such as credential identifier block, verification strategy, blacklist root hash, and anti-replay identifier as public inputs. The anti-replay identifier is calculated within the circuit based on a four-parameter hash formula, and a Groth16 zero-knowledge proof is generated using the proof key corresponding to the PackedCount encoded value. This achieves the generation of verifiable zero-knowledge proofs without disclosing credential subject attributes and holder identity identifiers. At the same time, the security and integrity of the proof are ensured through the anti-replay identifier mechanism and the verifiable outer signature.

[0045] Please see Figures 6 to 7 In some embodiments, the user converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity based on a preset salt value, the domain hash mapping of the presenter's distributed identity based on a preset salt value, the credential validity period consisting of the issuance time and expiration time, the issuer's EdDSA public key and EdDSA signature value, and the blacklist non-member proof data including the values ​​of the predecessor neighbor node, the successor neighbor node, the left node index, and the Merkle of both sides containing the proof path and the empty blacklist boundary status identifier into a private witness for the circuit, including: Users use the name hash value and attribute value of each attribute field in the plaintext data of the voucher body attributes as a key-value pair array, and perform padding according to the preset alignment step. Unoccupied slots are filled with zero values, so that voucher bodies with different numbers of fields can reuse the same circuit structure. Users perform domain hash mapping on the holder's distributed identity and the presenter's distributed identity using preset salt values, converting them into single finite field elements. They then apply strong consistency assertion constraints to both within the circuit to mathematically prove that the current presenter and the legitimate holder of the credential are the same entity, thus preventing credential theft and impersonation attacks. Users use the issuer's EdDSA public key and EdDSA signature value as a private witness input circuit, so that EdDSA signature verification is performed inside the circuit. The verifier cannot independently verify the signature outside the circuit, ensuring that all verification operations are securely completed within the zero-knowledge proof circuit. Users use the preceding neighbor node value, the succeeding neighbor node value, the left node index, the Merkle-containing proof path of both sides nodes, and the empty blacklist boundary status identifier in the blacklist non-member proof data as private witness input circuits, so that the circuit can complete the non-member proof verification of the sorted Merkle tree without exposing the holder's real identity hash value.

[0046] In this embodiment, the name hash value is calculated from the attribute field name using a hash function and is used to locate the target field within the circuit through hash matching. The preset alignment step size is 5. Padding is performed on the key-value pair array to align the array length upwards to a multiple of 5. Unoccupied slots are filled with zero values. The circuit internally ignores zero-value slots through a conditional skipping mechanism, allowing credentials with different numbers of fields to reuse the same circuit structure. The issuer's EdDSA public key and EdDSA signature value are used as a private witness input circuit to prevent the verifier from independently verifying the signature and obtaining the credential content outside the circuit, ensuring that all verification operations are securely completed within the zero-knowledge proof circuit.

[0047] The construction method of the blacklist sorted Merkle tree is as follows: the distributed identity identifiers of blacklisted accounts are converted into domain elements as identity hash values ​​using a finite field hash mapping algorithm based on a specific salt value. After being sorted in ascending order of numerical value, a static sorted Merkle tree is constructed using the zero-knowledge proof-friendly Poseidon2 hash function. Off-chain services or maintenance nodes store the complete sorted tree and generate predecessor nodes, successor nodes, and their containing path materials for the prover. The blockchain smart contract maintains and publishes the current trusted tree root. When a user requests proof, the service locates the position of the domain element of the user's distributed identity identifier after domain hash mapping in the local tree, finds its left nearest node as the predecessor nearest node value, and its right nearest node as the successor nearest node value, and generates the containing path of these two nodes in the tree.

[0048] Preferably, the circuit internally performs three strong constraint checks: reconstructing the root hash of the predecessor node through the Merkle inclusion proof path and asserting that it is equal to the root hash of the blacklist tree in the public input; reconstructing the root hash of the successor node through the Merkle inclusion proof path and asserting that it is equal to the root hash of the blacklist tree; and asserting that the holder's identity hash value is strictly greater than the value of the predecessor's neighboring node and strictly less than the value of the successor's neighboring node. If all three constraints are satisfied simultaneously, it proves that the holder is not in the blacklist tree.

[0049] The empty blacklist boundary state flag is used to identify the special state where the blacklist is empty or the identity to be verified is located at the boundary. When the blacklist is empty, the root hash of the empty tree is initialized to the deterministic root value obtained by the Poseidon2 hash function through the cascading of all zero leaf nodes. The values ​​of the predecessor neighbor node and the successor neighbor node are both mapped to zero elements. The sibling nodes at each level of the two inclusive paths are also all configured to zero elements. At this time, the boundary state flag is set at the same time. The circuit skips the size comparison constraints on the left and right sides according to this flag, so that the empty blacklist state can successfully pass the non-membership proof verification.

[0050] This embodiment achieves complete preparation and conversion of private witness data by having the user fill in the plaintext data of the credential subject attributes according to a preset alignment step size, using the issuer's public key and signature value as the private witness input circuit to ensure that the signature verification is performed within the circuit, and inputting the blacklist non-member proof data into the circuit to complete the privacy blacklist verification. This provides the necessary private input data for the subsequent generation of zero-knowledge proofs.

[0051] In some embodiments, the user calculates a replay protection identifier within the circuit based on a four-parameter hash formula comprising the holder's distributed identity field hash value, the first block of the credential identifier, the second block of the credential identifier, and a session random number, and imposes strong assertion constraints on the hash calculation process, including: Within the circuit, the user employs a circuit-friendly hash function, using the domain hash value of the holder's distributed identity identifier as the first parameter, the first block of the credential identifier as the second parameter, the second block of the credential identifier as the third parameter, and the session random number as the fourth parameter. The anti-replay identifier is calculated according to the four-parameter hash formula and submitted as a public input along with the zero-knowledge proof. Users impose strong assertion constraints on the hash calculation process of the anti-replay identifier within the circuit to ensure that the prover cannot forge a random hash value to replace the real anti-replay identifier, thus ensuring the security of the anti-replay mechanism at the circuit level. If the conventional mode is used, the session random number is fixed at zero as a public input, and the anti-replay identifier degenerates into a static value, which is suitable for single-verifier closed-loop verification scenarios. If the anti-association mode is adopted, the session random number is a non-zero one-time random number provided by the verifier, so that different sessions generate different anti-replay identifiers, preventing different verifiers from associating and tracking the user's presentation behavior, and fundamentally blocking the replay attack on the proof.

[0052] In this embodiment, a circuit-friendly hash function is selected, such as MiMC or Poseidon2, a zero-knowledge proof-friendly hash algorithm. These algorithms require far fewer constraints when implemented within the circuit than traditional hash functions like SHA-256, reducing the computational overhead of proof generation. The four-parameter hash formula is: the anti-replay identifier equals Hash(Hash value of the holder's distributed identity field, the first block of the credential identifier, the second block of the credential identifier, and a session random number). The calculated anti-replay identifier is submitted as public input along with the zero-knowledge proof, and the verifier uses it for deduplication verification. Strong assertion constraints are applied to the hash calculation process within the circuit to ensure that the prover cannot forge a random hash value to replace the genuine anti-replay identifier, thus guaranteeing the security of the anti-replay mechanism at the circuit level.

[0053] In normal mode, the session random number is fixed at zero as a public input, and the anti-replay identifier degenerates into a static value Hash (the hash value of the holder's distributed identity identifier field, the first block of the credential identifier, the second block of the credential identifier, 0), which is suitable for single-party closed-loop verification scenarios. In this mode, the same credential can only be verified once within the same window, and the verifier deduplicates the used anti-replay identifier within a limited short-time sliding window.

[0054] In the anti-association mode, the session random number is a non-zero, one-time random number provided by the verifier. This allows different sessions to generate different anti-replay identifiers, preventing different verifiers from associating and tracking user presentation behavior, and fundamentally blocking replay attacks on proofs. The verifier only needs to perform a single verification and deduplication of this one-time anti-replay identifier within the session's lifecycle. The anti-replay identifier itself is a one-way hash value, and in both modes, it does not reveal the true plaintext information of the holder's distributed identity identifier or credential identifier, achieving a balance between privacy protection against detection and replay attacks.

[0055] This embodiment achieves effective defense against replay attacks by having the user calculate the anti-replay identifier using a circuit-friendly hash function according to a four-parameter hash formula and apply strong assertion constraints within the circuit. It also adapts to single-verifier closed-loop verification scenarios and multi-verifier distributed verification scenarios through two working modes: normal mode and anti-association mode, respectively. This ensures the privacy of the user's presentation behavior.

[0056] Please see Figures 8 to 9 In some embodiments, the verifier receives a zero-knowledge proof, obtains the corresponding verification key, performs zero-knowledge proof protocol verification using the verification key, and verifies the uniqueness of the anti-replay identifier. If the verification passes, the verification is considered successful, including: The verifier receives verifiable demonstrations submitted by users, which include Groth16 zero-knowledge proofs and their corresponding public inputs; The verifier verifies the integrity of the SM2 signature on the outer layer of the verifiable display. After confirming that the verifiable display has not been tampered with, the verifier extracts the zero-knowledge proof and the public input. The validator extracts the template identifier and policy identifier from the public input, queries the blockchain to obtain the template definition and policy definition, and recalculates the PackedCount encoded value based on the actual number of fields. The verifier obtains the corresponding verification key from the blockchain based on the PackedCount encoded value. The verification key and the proof key are generated during the system initialization phase through the Trusted Setup of the Groth16 protocol. The verifier performs bilinear pairing operations on the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, and indirectly confirms that the five constraint blocks contained in the circuit—signature verification block, template verification block, validity period verification block, policy verification block, and blacklist verification block—are all satisfied. After the validator passes the Groth16 protocol verification, it extracts the anti-replay identifier from the public input, queries the blockchain record or local cache, and verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime. If it has not been used, it is registered as used. The verifier determines that the verification was successful and returns the verification result.

[0057] In this embodiment, the verifiable data is generated and submitted by the user, containing a Groth16 zero-knowledge proof and its corresponding public input. The public input includes the credential context, credential identifier, credential type, issuer's distributed identity identifier, template, policy, current verification time, blacklist root hash, anti-replay identifier, and session random number, among other verification-required data.

[0058] The verifier verifies the SM2 signature on the outer layer of the verifiable display using the SM2 public key. After confirming that the verifiable display has not been tampered with during transmission, the verifier extracts the zero-knowledge proof and public input from it.

[0059] The verifier extracts the template identifier and policy identifier from the public input, queries the credential template definition and verification policy definition stored on the blockchain, obtains the actual number of credential fields from the template definition, and obtains the actual number of policy rules from the policy definition. The verifier then recalculates the PackedCount encoded value according to the same alignment rule as the proof generator (aligning upwards to a multiple of 5) and encoding formula (the aligned policy rule number is shifted left by 16 bits and then bitwise ORed with the aligned credential field number).

[0060] The verifier uses the recalculated PackedCount encoding value as the key to retrieve the corresponding verification key from the blockchain smart contract. This verification key and the proof key are generated during the system initialization phase through the Trusted Setup process of the Groth16 protocol. The proof key is stored locally for the verifier's use, while the verification key is stored on-chain with the key "circuit name_PackedCount".

[0061] The verifier uses the acquired verification key to execute the Groth16 protocol verification algorithm, verifying the mathematical correctness of the zero-knowledge proof through bilinear pairing operations and confirming the binding relationship between the public input and the proof. The circuit internally includes five constraint blocks: a signature verification block, a template verification block, an expiration verification block, a policy verification block, and a blacklist verification block. The signature verification block verifies the correctness of the EdDSA credential signature within the circuit, proving that the credential content was indeed issued by the issuer corresponding to the issuer's private key. The template verification block and the expiration verification block verify the validity period of the credential, using the constraint that issuance time ≤ current verification time ≤ expiration time. The policy verification block verifies the compliance of the policy rules, including mandatory field checks, enumerated value verification, and numerical range squeeze comparison. The blacklist verification block verifies that the holder is not on the blacklist, performing two path reconstructions and sorting squeeze range checks through a non-member proof circuit using a Merkle tree sorted by the blacklist. These five constraint blocks are executed and embedded in the proof during the proof generation phase, and the verification phase indirectly confirms that all circuit constraints are satisfied through mathematical verification using bilinear pairing operations. The time complexity of Groth16 verification is constant O(1), independent of circuit size, and the verification computation involves only a small number of bilinear pairing operations.

[0062] After successful verification using the Groth16 protocol, the validator extracts the anti-replay identifier from the public input, queries the blockchain record or local cache, and verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime. In the conventional mode without session randomness, the anti-replay identifier is a static value. The validator verifies it using either on-chain global deduplication (setting a sliding window based on the current verification time) or local deduplication (each validator maintains its own local record). This conventional mode is only suitable for single-validator closed-loop verification scenarios. In the anti-association mode with session randomness, the anti-replay identifier is a dynamic value bound to the session. The validator only needs to perform a single verification and deduplication of this one-time anti-replay identifier within the session's lifetime. Due to the one-time nature of session randomness, the anti-replay identifier can only be successfully verified once, naturally preventing cross-session replay attacks. If the anti-replay identifier has not been used, it is registered as used.

[0063] Preferably, after the Groth16 protocol verification is passed, on-chain qualification and status verification can be further performed by smart contracts or blockchain trusted execution components, including credential issuance registration verification, issuer blacklist verification, issuer trusted status verification, credential revocation status verification, admission policy consistency verification, blacklist root consistency verification, and proof generation timeliness verification.

[0064] This embodiment verifies the integrity of the outer SM2 signature by verifying the verifier, recalculates the PackedCount encoded value to obtain the corresponding verification key, indirectly confirms that all five constraint blocks are satisfied by performing Groth16 bilinear pairing operations, and verifies the uniqueness of the anti-replay identifier. It realizes a complete verification process for zero-knowledge proof and effectively defends against replay attacks by adapting different deduplication verification strategies to the normal mode and the anti-association mode respectively.

[0065] In some embodiments, the verifier performs bilinear pairing operations on the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, and indirectly confirms that the five constraint blocks contained within the circuit—signature verification block, template verification block, validity period verification block, policy verification block, and blacklist verification block—are all satisfied, including: After the verifier passes the Groth16 protocol verification, the verifier calls the smart contract or the blockchain trusted execution component, which then extracts the credential identifier, the issuer's distributed identity identifier, the policy identifier, the blacklist tree root hash, and the current verification time from the public input. The smart contract or trusted execution component calls the block splicing and restoration function to restore the credential identifier, issuer distributed identity identifier and policy identifier, which are stored in blocks in the form of a finite field element array in the public input, to the original complete string; The smart contract or trusted execution component uses the restored credential identifier and the issuer's distributed identity identifier as key-value pairs to query the on-chain credential issuance registration log, verifying whether the credential has a genuine historical issuance registration record, and preventing credentials forged out of thin air from passing verification; The smart contract or trusted execution component verifies whether the issuer of the credential is in the issuer blacklist maintained on the chain, and also verifies whether the issuer is in the trusted issuer list. The trusted issuer list is controlled by a global switch, and when it is turned off, all issuers are trusted by default. The smart contract or trusted execution component verifies whether the credential identifier is in the list of revoked credentials maintained on the chain, ensuring that invalidated credentials cannot pass privacy verification; The smart contract or trusted execution component will perform a real-time string strong consistency check between the restored policy identifier and the preset admission policy identifier associated with the current verification resource. If the two do not match, the verification will be deemed invalid. The smart contract or trusted execution component will perform a real-time strong consistency comparison between the blacklist root hash in the publicly input blacklist tree and the latest blacklist sorted Merkle root hash currently maintained by the blockchain, to prevent the prover from using a self-built forged blacklist root to bypass non-member state verification. The smart contract or trusted execution component verifies whether the absolute value deviation between the current verification time in the public input and the consensus timestamp of the current block of the blockchain is within the maximum allowed delay range, preventing attackers from bypassing the anti-replay window by exploiting expired historical proofs.

[0066] In this embodiment, the smart contract is deployed on the blockchain, and the execution status is queried and verified through on-chain code. The blockchain trusted execution component provides hardware-level secure computing services based on the trusted execution environment. Both can respond to the verifier's call requests. After the verifier passes the Groth16 protocol verification, the verifier triggers the smart contract or the blockchain trusted execution component through cross-chain calls or on-chain messaging mechanisms. The component then extracts the credential identifier, the issuer's distributed identity identifier, the policy identifier, the blacklist tree root hash, and the current verification time from the public input.

[0067] Both the issuer blacklist and the trusted issuer list are on-chain lists of issuer statuses. The former records issuers that are blacklisted, while the latter records issuers that are considered trusted. The trusted issuer list is enabled by a global switch. When disabled, all issuers are trusted by default. During verification, the system first checks whether the issuer is in the issuer blacklist. If not, it continues to check whether the issuer is in the trusted issuer list.

[0068] The revoked credential list records the identifiers of revoked credentials. A mapping query is used to verify whether a credential identifier is in this list. A preset admission policy identifier is bound to the current verification resource. The zero-value placeholder at the end of the restored policy identifier is removed, and a direct string comparison is performed with the preset admission policy identifier.

[0069] The latest blacklist sorting Merkle root hash is deterministically updated by the blockchain based on blacklist status changes. The blacklist root hash in the publicly input is directly compared with this latest root hash. The current block consensus timestamp is taken from the blockchain block header. The absolute difference between the current verification time and the block consensus timestamp is calculated, and it is verified whether this difference is less than or equal to the maximum allowed delay range.

[0070] This embodiment utilizes smart contracts or blockchain trusted execution components to perform seven on-chain verifications after Groth16 protocol verification: credential issuance registration verification, issuer blacklist and trusted status verification, credential revocation status verification, admission policy consistency verification, blacklist tree root consistency verification, and proof generation timeliness verification. This achieves dual collaboration between zero-knowledge proof verification and on-chain status verification. While ensuring the privacy and anonymity of user credential content, it prevents revoked or invalidated credentials, credentials forged by malicious and untrustworthy issuers, credentials with altered policy identifiers, and credentials with self-built fake blacklist trees from passing zero-knowledge verification, thus enhancing the security defense depth of the verification system.

[0071] Please see Figure 10In a second aspect, this embodiment also provides a distributed identity credential hiding verification system based on zero-knowledge proof, used to execute the method described in the first aspect. The system includes a service platform module, a user terminal module, a verification service module, and a blockchain module. The service platform module is used to receive a verifiable credential issuance request initiated by a user. The verifiable credential issuance request includes privacy protection requirements. In response to the verifiable credential issuance request, the module queries the blockchain to obtain the credential template definition and fills in the credential subject fields and validity period based on the template definition. According to the privacy protection requirements, the module selects the corresponding signature algorithm to sign the verifiable credential and generates a verifiable credential containing the corresponding signature. The credential is returned to the user; the user terminal module obtains its own distributed identity, key pair, and verifiable credential to be displayed, and determines to use the zero-knowledge proof mode. It converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity, the domain hash mapping of the displayer's distributed identity, the credential validity period, the issuer's public key and signature value, and the blacklist non-member proof data into the circuit's private witness. It also converts the credential context, credential identifier chunks, credential type, issuer's distributed identity chunks, credential template definition, verification strategy, blacklist root hash, current verification time, anti-replay identifier, and session information. Random numbers are converted into the circuit's public input. Within the circuit, a replay protection identifier is calculated using a four-parameter hash formula, and strong assertion constraints are applied to the hash calculation process. Based on the private witness and the public input, a proof key is used to generate a Groth16 zero-knowledge proof and its corresponding public input. The verification service module receives verifiable displays submitted by users and verifies the integrity of the outer signature. It extracts the template identifier and policy identifier from the public input, queries the blockchain to obtain the template definition and policy definition, recalculates the PackedCount encoded value, and obtains the corresponding verification key from the blockchain based on the PackedCount encoded value, executing Groth16 zero-knowledge proof. The h16 protocol verification algorithm uses bilinear pairing operations to verify the mathematical correctness of zero-knowledge proofs and their binding relationship with public inputs, indirectly confirming that all five constraint blocks within the circuit are satisfied. It also verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime; if not, it is registered as used and the verification is deemed successful. The blockchain module stores credential template definitions, verification strategy definitions, verification keys, Merkle root hashes for blacklist sorting, credential issuance registration logs, issuer blacklists, trusted issuer lists, revoked credential lists, and records of used anti-replay identifiers, and provides on-chain qualification and status verification services.

[0072] In this embodiment, the service platform module maintains the issuer's SM2 key pair and EdDSA key pair, used to sign verifiable credentials using the SM2 private key in traditional mode and the EdDSA private key in zero-knowledge proof mode. The user terminal module maintains the holder's SM2 key pair, used to sign the generated verifiable display as a whole to protect its integrity. The verification service module does not need to maintain keys; it only needs to receive zero-knowledge proofs and public input to complete verification. The blockchain module stores credential template definitions, verification policy definitions, verification keys, blacklist sorting Merkle tree root hashes, credential issuance registration logs, issuer blacklists, trusted issuer lists, revoked credential lists, and records of used anti-replay identifiers, and provides on-chain qualification and status verification services.

[0073] Preferably, this system adopts a layered architecture, comprising a service layer, a protocol layer, a circuit layer, and a blockchain layer from top to bottom. The service platform module and the verification service module both belong to the service layer. The service platform module provides key generation and verifiable credential issuance services, while the verification service module provides verifiable display verification services. The user terminal module spans the service layer and the protocol layer; its business logic belongs to the service layer, while its zero-knowledge proof generation part belongs to the protocol layer. The circuit layer provides the underlying circuit constraint definitions for the protocol layer and is invoked by the protocol layer. The blockchain module corresponds to the blockchain layer, providing distributed identity identification contract management, verification key storage, and on-chain qualification and verification services. This layered architecture decouples the service logic, proof protocol, circuit logic, and blockchain storage, allowing each layer to evolve and be replaced independently.

[0074] This embodiment fully realizes the entire process of certificate issuance, proof generation, proof verification, and on-chain verification through the division of labor and cooperation of the service platform module, user terminal module, verification service module, and blockchain module. The hierarchical architecture design clarifies the hierarchical affiliation of each module, improving the scalability and maintainability of the system.

[0075] By adopting the above technical solutions, this invention differs from existing technologies and has the following beneficial effects: The service platform selects signature algorithms based on privacy protection needs, providing zero-knowledge proof-friendly signatures for privacy-protected scenarios and national cryptographic standard signatures for traditional scenarios, thus achieving dual-mode credential issuance; the user uses the credential subject attributes and holder identity as private witnesses, and the verification strategy and anti-replay identifier as public input circuits, generating Groth16 zero-knowledge proofs based on the PackedCount encoding multiplexing circuit structure, completing the generation of verifiable proofs without disclosing the credential content and holder identity, and further enhancing the verification through large field segmentation and domain hashing. The Hierarchical mapping overcomes the finite field capacity limitation; the verifier obtains the verification key based on the policy identifier and performs bilinear pairing operations to indirectly confirm that the five constraint blocks of signature, template, validity period, policy and blacklist are all satisfied. Combined with the sliding window of the anti-replay identifier or the session deduplication mechanism, it defends against replay attacks. Furthermore, through smart contracts, it performs multiple verifications on the chain of credential registration, issuer trust status, credential revocation status, policy consistency, blacklist root consistency and proof timeliness. Thus, under the premise of completely hiding the user's identity and credential privacy information, it realizes the validity verification of credentials and the trust verification of user qualifications, and significantly improves the flexibility, security and scalability of the verification system.

[0076] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0077] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0078] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A distributed identity credential hiding verification method based on zero-knowledge proof, characterized in that, include: The service platform responds to the user's request for the issuance of verifiable credentials, selects a signature algorithm based on privacy protection requirements to sign the verifiable credentials, and returns the signed verifiable credentials to the user. Users obtain verifiable credentials, convert the credential subject attributes and holder identity into the circuit's private witness, convert the verification strategy, credential template definition and anti-replay identifier into the circuit's public input, and generate zero-knowledge proofs within the circuit based on the private witness and public inputs. The verifier receives the zero-knowledge proof, obtains the corresponding verification key, uses the verification key to execute the zero-knowledge proof protocol verification, and verifies the uniqueness of the anti-replay identifier. If the verification passes, the verification is considered successful.

2. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 1, characterized in that, In response to a user's request for the issuance of a verifiable credential, the service platform selects a signature algorithm based on privacy protection requirements to sign the verifiable credential, and returns the signed verifiable credential to the user, including: The service platform receives a verifiable credential issuance request initiated by a user, and the verifiable credential issuance request includes privacy protection requirements; In response to the verifiable credential issuance request, the service platform queries the blockchain to obtain the credential template definition and fills the credential body field based on the template definition. The credential body field includes attribute name and attribute value, and sets the issuance time and expiration time as the validity period. The service platform selects the corresponding signature algorithm based on the aforementioned privacy protection requirements: If the privacy protection requirement indicates that the credential content be hidden, the service platform uses the EdDSA algorithm to sign the key fields of the credential. The key fields of the credential include the credential context, credential identifier, credential type, issuer's distributed identity identifier, credential template unique identifier, template name, template version and template content, issuance time, expiration time, domain hash mapping of the holder's distributed identity identifier, and the hash value of the credential body's fields concatenated with the public key. If the privacy protection requirement indicates that the credential content does not need to be hidden, the service platform uses the SM2 algorithm to sign the key fields of the credential. The service platform will return a verifiable credential containing the corresponding signature to the user.

3. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 2, characterized in that, If the privacy protection requirement indicates that the credential content be hidden, the service platform uses the EdDSA algorithm to sign the key fields of the credential, including: When the service platform uses the EdDSA algorithm to sign key fields of a credential, it concatenates the credential context, credential identifier, credential type, issuer's distributed identity identifier, credential template unique identifier, template name, template version and template content, issuance time, expiration time, domain hash mapping of the holder's distributed identity identifier, and all fields of the credential body with the public key, and calculates the MiMC hash digest as the signature message. The service platform uses the issuer's EdDSA private key to perform EdDSA signing on the MiMC hash digest under the Twisted Edwards curve based on the Gnark framework, generating an EdDSA signature value containing the coordinates of the R point and the S scalar. The service platform appends the EdDSA signature value to the verifiable credential.

4. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 2, characterized in that, If the privacy protection requirement indicates that the credential content does not need to be hidden, the service platform uses the SM2 algorithm to sign the key fields of the credential, including: The service platform adopts the traditional mode, using the issuer's SM2 private key to sign the key fields of the certificate using the national cryptographic standard SM2WithSM3. The key fields of the certificate include certificate context, certificate identifier, certificate type, issuer's distributed identity identifier, certificate template definition, issuance time, expiration time, holder's distributed identity identifier, and all fields of the certificate body. The service platform will return verifiable credentials containing an SM2 signature to the user.

5. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 3, characterized in that, The user obtains a verifiable credential, converts the credential subject attributes and holder identity into a private witness for the circuit, converts the verification strategy, credential template definition, and anti-replay identifier into public inputs for the circuit, and generates a zero-knowledge proof within the circuit based on the private witness and public inputs, including: Users obtain their own distributed identity identifier, key pair, and verifiable credentials to be displayed, and determine to adopt the zero-knowledge proof mode; The user converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity based on a preset salt value, the domain hash mapping of the presenter's distributed identity based on a preset salt value, the credential validity period consisting of the issuance time and expiration time, the issuer's EdDSA public key and EdDSA signature value, and the blacklist non-member proof data including the values ​​of the predecessor neighbor node, the value of the successor neighbor node, the left node index, and the Merkle of both sides containing the proof path and the empty blacklist boundary status identifier into the circuit's private witness. The holder's distributed identity and the presenter's distributed identity are subject to a strong consistency assertion constraint within the circuit. The user divides the following into blocks: credential context, credential identifier (sliced ​​into blocks according to a preset maximum number of blocks), credential type, issuer distributed identity identifier (sliced ​​into blocks according to a preset maximum number of blocks), credential template definition (containing template identifier, template name, and template version), verification strategy (containing policy identifier, policy version, and specific policy rules), root hash of the Merkle tree sorted by blacklist, current verification time, anti-replay identifier generated by hashing based on the holder's distributed identity identifier field hash value, credential identifier blocks, and session random number, and converts the one-time session random number provided by the verifier into the circuit's public input; Within the circuit, the user calculates the anti-replay identifier based on a four-parameter hash formula that includes the hash value of the holder's distributed identity identifier field, the first block of the credential identifier, the second block of the credential identifier, and the session random number, and applies strong assertion constraints to the hash calculation process. Based on the private witness and public input, the user generates a Groth16 zero-knowledge proof and the corresponding public input using the proof key corresponding to the PackedCount encoded value, and uses their own SM2 private key to perform SM2WithSM3 signature on the entire verifiable display containing the zero-knowledge proof.

6. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 5, characterized in that, The user converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity based on a preset salt value, the domain hash mapping of the presenter's distributed identity based on a preset salt value, the credential validity period consisting of the issuance time and expiration time, the issuer's EdDSA public key and EdDSA signature value, and the blacklist non-member proof data containing the values ​​of the predecessor neighbor node, the successor neighbor node, the left node index, and the Merkle of both sides containing the proof path and the empty blacklist boundary status identifier into a private witness for the circuit, including: Users use the name hash value and attribute value of each attribute field in the plaintext data of the voucher body attributes as a key-value pair array, and perform padding according to the preset alignment step. Unoccupied slots are filled with zero values, so that voucher bodies with different numbers of fields can reuse the same circuit structure. Users perform domain hash mapping on the holder's distributed identity and the presenter's distributed identity using preset salt values, converting them into single finite field elements. They then apply strong consistency assertion constraints to both within the circuit to mathematically prove that the current presenter and the legitimate holder of the credential are the same entity, thus preventing credential theft and impersonation attacks. Users use the issuer's EdDSA public key and EdDSA signature value as a private witness input circuit, so that EdDSA signature verification is performed inside the circuit. The verifier cannot independently verify the signature outside the circuit, ensuring that all verification operations are securely completed within the zero-knowledge proof circuit. Users use the preceding neighbor node value, the succeeding neighbor node value, the left node index, the Merkle-containing proof path of both sides nodes, and the empty blacklist boundary status identifier in the blacklist non-member proof data as private witness input circuits, so that the circuit can complete the non-member proof verification of the sorted Merkle tree without exposing the holder's real identity hash value.

7. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 5, characterized in that, Within the circuit, the user calculates the anti-replay identifier using a four-parameter hash formula comprising the holder's distributed identity field hash value, the first block of the credential identifier, the second block of the credential identifier, and a session random number, and applies strong assertion constraints to the hash calculation process, including: Within the circuit, the user employs a circuit-friendly hash function, using the domain hash value of the holder's distributed identity identifier as the first parameter, the first block of the credential identifier as the second parameter, the second block of the credential identifier as the third parameter, and the session random number as the fourth parameter, to calculate the anti-replay identifier according to the four-parameter hash formula. The anti-replay identifier is then submitted as a public input along with the zero-knowledge proof. Users impose strong assertion constraints on the hash calculation process of the anti-replay identifier within the circuit to ensure that the prover cannot forge a random hash value to replace the real anti-replay identifier, thus ensuring the security of the anti-replay mechanism at the circuit level. If the conventional mode is used, the session random number is fixed at zero as a public input, and the anti-replay identifier degenerates into a static value, which is suitable for single-verifier closed-loop verification scenarios. If the anti-association mode is adopted, the session random number is a non-zero one-time random number provided by the verifier, so that different sessions generate different anti-replay identifiers, preventing different verifiers from associating and tracking the user's presentation behavior, and fundamentally blocking the replay attack of the proof.

8. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 1, characterized in that, The verifier receives the zero-knowledge proof, obtains the corresponding verification key, executes the zero-knowledge proof protocol verification using the verification key, and verifies the uniqueness of the anti-replay identifier. If the verification passes, the verification is considered successful, including: The verifier receives a verifiable demonstration submitted by the user, which includes a Groth16 zero-knowledge proof and the corresponding public input. The verifier verifies the integrity of the SM2 signature on the outer layer of the verifiable display, and after confirming that the verifiable display has not been tampered with, extracts the zero-knowledge proof and the public input; The verifier extracts the template identifier and policy identifier from the public input, queries the blockchain to obtain the template definition and policy definition, and recalculates the PackedCount encoded value based on the actual number of fields. The verifier obtains the corresponding verification key from the blockchain based on the PackedCount encoded value. The verification key and the proof key are generated during the system initialization phase through the Trusted Setup of the Groth16 protocol. The verifier performs bilinear pairing operations on the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, and indirectly confirms that the five constraint blocks contained in the circuit—signature verification block, template verification block, validity period verification block, policy verification block, and blacklist verification block—are all satisfied. After the verifier passes the Groth16 protocol verification, it extracts the anti-replay identifier from the public input, queries the blockchain record or local cache, and verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime. If it has not been used, it is registered as used. The verifier determines that the verification was successful and returns the verification result.

9. The distributed identity credential hiding verification method based on zero-knowledge proof according to claim 8, characterized in that, The verifier performs bilinear pairing operations on the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input. This indirectly confirms that all five constraint blocks within the circuit—signature verification block, template verification block, validity period verification block, policy verification block, and blacklist verification block—are satisfied, including: After the verifier passes the Groth16 protocol verification, the verifier calls the smart contract or the blockchain trusted execution component, which then extracts the credential identifier, the issuer's distributed identity identifier, the policy identifier, the blacklist tree root hash, and the current verification time from the public input. The smart contract or trusted execution component calls the block splicing and restoration function to restore the credential identifier, issuer distributed identity identifier and policy identifier, which are stored in blocks in the form of a finite field element array in the public input, to the original complete string; The smart contract or trusted execution component uses the restored credential identifier and the issuer's distributed identity identifier as key-value pairs to query the on-chain credential issuance registration log, verifying whether the credential has a genuine historical issuance registration record, and preventing credentials forged out of thin air from passing verification; The smart contract or trusted execution component verifies whether the issuer of the verifiable credential is in the issuer blacklist maintained on the chain, and also verifies whether the issuer is in the trusted issuer list. The trusted issuer list is controlled by a global switch, and when it is turned off, all issuers are trusted by default. The smart contract or trusted execution component verifies whether the credential identifier is in the list of revoked credentials maintained on the chain, ensuring that invalidated credentials cannot pass privacy verification; The smart contract or trusted execution component will perform a real-time string strong consistency check between the restored policy identifier and the preset admission policy identifier associated with the current verification resource. If the two do not match, the verification will be deemed invalid. The smart contract or trusted execution component will perform a real-time strong consistency comparison between the blacklist root hash in the publicly input blacklist tree and the latest blacklist sorted Merkle root hash currently maintained by the blockchain, to prevent the prover from using a self-built forged blacklist root to bypass non-member state verification. The smart contract or trusted execution component verifies whether the absolute value deviation between the current verification time in the public input and the consensus timestamp of the current block of the blockchain is within the maximum allowed delay range, preventing attackers from bypassing the anti-replay window by exploiting expired historical proofs.

10. A distributed identity credential hiding verification system based on zero-knowledge proof, characterized in that, The system for performing the method according to any one of claims 1 to 9, the system comprising: The service platform module is used to receive a verifiable credential issuance request initiated by a user. The verifiable credential issuance request includes privacy protection requirements. In response to the verifiable credential issuance request, the module queries the blockchain to obtain the credential template definition and fills in the credential subject field and validity period based on the template definition. According to the privacy protection requirements, the module selects the corresponding signature algorithm to sign the verifiable credential and returns the verifiable credential containing the corresponding signature to the user. The user terminal module is used to obtain its own distributed identity, key pair, and verifiable credentials to be displayed, and determine to adopt the zero-knowledge proof mode. It converts the plaintext data of the credential subject attributes, the domain hash mapping of the holder's distributed identity, the domain hash mapping of the displayer's distributed identity, the credential validity period, the issuer's public key and signature value, and the blacklist non-member proof data into the circuit's private witness. It converts the credential context, credential identifier blocks, credential type, issuer's distributed identity blocks, credential template definition, verification strategy, blacklist root hash, current verification time, anti-replay identifier, and session random number into the circuit's public input. Within the circuit, it calculates the anti-replay identifier according to the four-parameter hash formula and applies strong assertion constraints to the hash calculation process. Based on the private witness and public input, it uses the proof key to generate a Groth16 zero-knowledge proof and the corresponding public input. The verification service module is used to receive verifiable displays submitted by users and verify the integrity of the outer signature. It extracts template identifiers and policy identifiers from the public input, queries the blockchain to obtain template definitions and policy definitions, and recalculates the PackedCount encoding value. Based on the PackedCount encoding value, it obtains the corresponding verification key from the blockchain, executes the bilinear pairing operation of the Groth16 protocol verification algorithm to verify the mathematical correctness of the zero-knowledge proof and its binding relationship with the public input, and indirectly confirms that all five constraint blocks inside the circuit are satisfied. It also verifies whether the anti-replay identifier has been used within the sliding time window or session lifetime. If it has not been used, it is registered as used and the verification is deemed successful. The blockchain module is used to store credential template definitions, verification strategy definitions, verification keys, Merkle tree root hashes for blacklist sorting, credential issuance registration logs, issuer blacklists, trusted issuer lists, revoked credential lists, and records of used anti-replay identifiers, and provides on-chain qualification and status verification services.

Images