Cross-trust domain evidence controllable exchange method based on decentralized anonymous credentials

Abstract

The application discloses a cross-trust domain evidence controllable exchange method based on decentralized anonymous credentials, comprising: generating public parameters and keys of each cryptographic sub-protocol; under the premise of not exposing attribute plaintext, completing decentralized issuance of the credentials by a user; proving to a verifier that the user holds valid credentials and the attributes meet the access policy; and supporting efficient aggregation verification of multiple credentials. The application is established on the basis of a cryptographic infrastructure supporting bilinear pairing operation, and through design of a decentralized credential issuance architecture without signature key dependency, support of a multi-credential aggregation mechanism and an optimization strategy of verification outsourcing based on a KZG polynomial commitment, the decentralized credential issuance, the flexibility of credential verification and the high efficiency of performance are taken into account.

Description

Technical Field

[0001] This invention belongs to the technical field of credential systems, specifically relating to a method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials. Background Technology

[0002] Anonymous Credentials (AC) is an important research area in identity authentication and privacy protection, aiming to enable users to complete legitimate identity verification without revealing their real identity. In cross-domain evidence exchange scenarios, AC technology allows users to prove their attributes to different trust domains in a "minimally disclosed" manner, making it a key technical means to achieve privacy-preserving cross-domain mutual recognition. A complete AC system typically includes the following four core algorithms, executed by three types of participants in the system.

[0003] ① Institutional Key Generation: A secure initialization algorithm executed by the Issuing Authority. The institution selects security parameters. Generate a signature key pair for issuing credentials. The system will use the public key. The public key serves as a trusted identifier for the organization, while the private key... These credentials must be securely stored by the institution; any leak would cause the entire trust domain's credential system to collapse.

[0004] ② User key generation: Performed locally by the user. The user selects security parameters and generates their own master secret. (Typically a random scalar value), this secret serves as the private foundation for all subsequent user operations within the system. In a decentralized credential system, the hash or commitment value of this secret typically serves as the user's public credential identifier. .

[0005] ③ Credential Acquisition and Issuance: A one- or multi-round interaction protocol between the user and the issuing authority. First, the user, based on their own attribute vector... and the secret of the Lord Computational property commitment The data is then sent to the issuing authority via a secure channel, along with a zero-knowledge proof. This proof demonstrates to the authority that the attributes satisfy the issuance policy without exposing the plaintext attributes. Once approved by the issuing authority, it uses its signing private key. User attribute commitment Perform digital signature and generate credentials and will Returned to the user, what the user ultimately holds is This is the complete credential tuple.

[0006] ④ Credential Presentation and Verification: A non-interactive protocol between the user and the verifier. The user, as the prover, needs to prove the following compound statement to the verifier (defined in the form of a statement-witness relationship RAC).

[0007]

[0008] in, For public input: Institutional public key Access policies Valid set of credential identifiers (For set membership verification), Session context (Used to prevent replay); Witnessing the Secret: User Attributes Random blinding factor Attribute commitment Institutional signature .

[0009] Users generate proofs using zero-knowledge proof protocols. The verifier only needs to run Algorithm check The validity of the credentials is determined. Throughout the process, the verifier cannot obtain the user's specific attribute values, commitment values, signature values, nor can they associate the display with the user's identity or other display history of the credentials.

[0010] Traditional anonymous credential systems are typically built upon three cryptographic primitives:

[0011] ① Cryptographic commitment schemes (such as Pedersen commitments): used when a user "commits an attribute" to an institution, while simultaneously satisfying concealment (the institution cannot obtain the attribute from the commitment). Knowing the attribute in plaintext) and binding (the user cannot subsequently...) (Open for different attribute values).

[0012] ② Digital signature systems (such as RSA signatures and Schnorr signatures): These are used by organizations to sign user attribute commitments, ensuring the unforgeability of credentials from a cryptographic perspective. Organizations use their private keys... User attribute commitment Sign and output When the user subsequently presents the credentials, they use zero-knowledge proof to demonstrate "I know a valid signature". , making "without exposing" itself.

[0013] ③ Zero-knowledge proof system: As the core engine of the credential presentation phase, it is used to realize the statement "I know a secret witness that satisfies a certain composite relation" without revealing any information about the witness itself. In anonymous credentials, the composite relation that the user needs to prove covers three levels: signature verification, commitment verification, and attribute constraints.

[0014] Furthermore, zero-knowledge proof is a cryptographic protocol that allows a prover to demonstrate the truth of a statement to a verifier without revealing any additional information beyond the validity of the statement itself. A zero-knowledge proof protocol consists of three probabilistic multinomial-time algorithms: Setup (generate common parameters), Prove (generate proof), and Verify (verify proof).

[0015] Concise non-interactive zero-knowledge proofs (zk-SNARKs) are an important branch of modern zero-knowledge proofs. Their core advantages lie in their extremely small proof size (usually a constant number of group elements), extremely fast verification time (usually a constant number of bilinear pairing operations), and the fact that there is no interaction between the proof and verification. The construction of zk-SNARKs is usually based on the following technical path: first, the computational problem to be proven is encoded as an arithmetic circuit; then, the circuit constraints are transformed into a first-order constraint system (R1CS), and further transformed into a quadratic arithmetic procedure (QAP); finally, a non-interactive proof is constructed using polynomial commitment schemes (such as KZG commitments) and Fiat-Shamir transformations.

[0016] However, traditional zk-SNARKs can only verify the correctness of computational relations and cannot achieve independent commitments to specific parts of the witness at the cryptographic level. In 2019, Campanelli et al. proposed succinct non-interactive knowledge proofs with commitments (cc-SNARK) within the LegoSNARK framework. While retaining the simplicity and zero-knowledge nature of traditional zk-SNARKs, cc-SNARKs organically integrate the commitment mechanism into the proof generation process. In cc-SNARKs, the witness is explicitly divided into a "committed witness part" and a "non-committed witness part." The proof output includes not only the standard proof but also a Pedersen commitment to the committed part and its opening information. This feature allows external verifiers or other components of the system to independently verify the validity of the commitment and compare its consistency with commitments in other proof components, effectively preventing "commitment switching attacks" where malicious users use different secret values ​​in different proof components.

[0017] Set membership proof is a core component of anonymous credential systems. It proves that a user's credential identifier belongs to a set of legitimate credentials maintained by the issuing authority, without revealing which specific credential the user holds. Traditional implementation schemes mainly fall into two categories.

[0018] Accumulator-based schemes: These schemes accumulate all elements in the set into a fixed-size sum, and the prover generates a membership proof of constant size. Typical schemes include RSA-based accumulators and bilinear pairwise accumulators. Although these schemes provide proofs of constant size, updating the accumulator often requires recalculating the entire sum or performing complex batch processing operations.

[0019] Merkle tree-based schemes construct a Merkle tree by using the elements of the set as leaf nodes, with the root serving as a public summary of the set. The prover provides the Merkle path from the element to be proven to the root. These schemes are simple in structure and do not require trusted setups, but the proof size and verification computational cost both increase logarithmically with the set size.

[0020] To overcome the performance limitations of traditional solutions, existing technologies represent decentralized anonymous credential solutions. Their core contribution lies in using universal zero-knowledge proofs as the cornerstone of anonymous credentials, replacing the traditional blind signature paradigm. This significantly improves the system's flexibility and real-world compatibility, such as the zk-creds protocol proposed by Rosenberg et al. at the IEEE Symposium on Security and Privacy in 2023. Specific technical solutions are as follows:

[0021] (1) System Architecture: The zk-creds system includes three main participants: users, credential issuers, and validators. Unlike traditional schemes, issuers do not need to hold signing private keys. Their core responsibility is to maintain a publicly verifiable and transparent log (such as a blockchain or distributed ledger). Users hold private attributes and generate various proofs using general zk-SNARKs. Validators verify these zero-knowledge proofs to confirm that users hold valid credentials.

[0022] (2) Credential Issuance Mechanism: Trust minimization is achieved through credential issuance. Users first construct a cryptographic commitment, cred, containing secret information such as their attributes (attrs) and pseudonymous keys (nk). To prove their eligibility for the credential, users generate a zero-knowledge supporting document—this proof demonstrates, in a privacy-preserving manner, that "the user possesses a valid identity document issued by a trusted third party (such as a government), and the attributes committed in cred are consistent with the data in the document." After reviewing this zero-knowledge proof, the issuer adds the credential commitment cred to a publicly available list of credentials (instantiated as a Merkle tree). The legitimacy of the credential and its unique identifier both depend on the existence of this commitment in the list.

[0023] (3) Certificate presentation mechanism: Users can prove the validity of a certificate without presenting the original document. The presentation process consists of a complex zero-knowledge proof, which contains three sub-proofs.

[0024] Membership proof: Prove that cred exists in the issuer's Merkle tree.

[0025] Attribute proof: Proves that the attribute promised in cred satisfies specific access control logic (e.g., age greater than 18 years old).

[0026] Blind Linked Proofs: This is a core mechanism of zk-creds that can "link" the first two proofs together in a zero-knowledge manner, proving that they refer to the same unpublished cred, preventing users from mixing different credential components.

[0027] (4) Zero-knowledge proof construction: zk-creds uses a general zk-SNARK system (such as Groth16 or Plonk) to construct the above proofs. Developers can write various access control logics (such as range proofs and signature verifications) as reusable "gadget" circuits. During demonstration, the system generates an independent proof for each gadget and combines them through blinded chaining proofs.

[0028] (5) Transparent Log and Auditability: The list of public credentials is maintained on a transparent log, ensuring the immutability and auditability of the list. Any third party can verify the integrity of the list, and all issued credentials are publicly visible, effectively preventing malicious actions by the issuer.

[0029] However, while zk-creds supports cross-credential combination, in complex scenarios involving the simultaneous verification of multiple credentials, it requires generating independent Groth16 proofs for the membership proof and each attribute constraint of each credential. Even if these can be linked through chained proofs, the computational and communication overhead still increases linearly with the number of credentials. The fundamental reason is that zk-creds lacks an optimization mechanism to merge the attribute constraints of multiple independent credentials into a single arithmetic circuit for aggregate proof. Furthermore, it also has the following shortcomings:

[0030] The credential verification logic is rigid: the zk-creds system has low verification flexibility, and verifiers cannot flexibly define constraint rules.

[0031] The modularity and scalability of commitment binding are insufficient: The existing scheme zk-creds uses commitment binding, and its blinded linked proof (LinkG16) successfully implements the binding between its internal Groth16 proofs. However, this binding capability is cohesive within its specific zero-knowledge proof construction and does not abstract the binding relationship into a modular cryptographic component that can be independent of specific proof systems. This makes it impossible to perform consistency verification through a unified commitment interface when the system wants to introduce algorithms such as the SM2 national cryptographic algorithm or other novel set membership proof schemes, thus limiting its flexibility and compatibility for expansion.

[0032] Performance bottlenecks in large-scale membership proof scenarios: Existing advanced solutions for ensemble membership proof tend to use the simple Merkle tree approach. However, while Merkle forests optimize proof generation time, the computational overhead for validators in verifying membership relationships still increases logarithmically with the tree height. When the number of credentials reaches hundreds of thousands or even millions, and in scenarios with high concurrency verification requests, the logarithmic verification complexity still constitutes a performance bottleneck for the system.

[0033] Therefore, existing decentralized anonymous credentials urgently need to overcome the above problems. Summary of the Invention

[0034] The main objective of this invention is to overcome the shortcomings and deficiencies of existing technologies and provide a cross-trust domain evidence controllable method based on decentralized anonymous credentials. It is built on a cryptographic infrastructure that supports bilinear pairing operations. By designing a decentralized credential issuance architecture without signature key dependence, supporting a multi-credential aggregation mechanism, and an optimization strategy for verification outsourcing based on KZG polynomial commitments, it balances the decentralization of credential issuance, the flexibility of credential verification, and the high efficiency of performance.

[0035] To achieve the above objectives, the present invention adopts the following technical solution:

[0036] In a first aspect, the present invention provides a method for controlled exchange of evidence across trust domains based on decentralized anonymous credentials, comprising:

[0037] S1. Generate the public parameters and keys for each cryptographic sub-protocol, and make the public parameters public to all participants, including users, credential issuers, and verifiers. The credential issuers are responsible for verifying the user's qualifications and maintaining a publicly verifiable list of public credentials. ;

[0038] S2. Users issue credentials in a decentralized manner while keeping attributes hidden in plaintext. These credentials include private attribute values. and user private key ;

[0039] S3. The user proves to the verifier that they possess a valid credential, and the privacy attribute value... Satisfy cross-domain access policies;

[0040] S4. Users can show multiple credentials to the validator at once. The validator only needs to verify the aggregated proof of multiple credentials once. This is used for cross-domain display, and the displayed credentials originate from different domains.

[0041] As a preferred technical solution, step S1, in which a trusted third party or distributed multi-party secure computation is used to generate the common parameters of each sub-protocol, includes:

[0042] Generation of public reference strings for set membership proofs, i.e., selection of the bilinear group. Randomly select a trapdoor and use the cyclic group in the bilinear group and the selected trapdoor to obtain a common reference string. , for Big prime number, for Cyclic group of order 1 Non-degenerate bilinear pairing;

[0043] Generate concise, non-interactive knowledge proof and verification key pairs with commitments, i.e., attribute-constrained circuits. Generate a structured reference string, including the commitment key. Evaluation Key and verification key The attribute constraint circuit Encoding Relationship ,relation Public input is ,witness ,satisfy ,in As a credential identifier, serving as witness to the commitment. The user's private key serves as a witness to an uncommitted promise. For public session identification;

[0044] Linked subspace concise non-interactive argument key generation, i.e., based on sparse matrices. Generate evidence to demonstrate the consistency between the SMA commitment and the ccGro16 commitment;

[0045] Hash proofs the generation of common parameters, i.e., selection of cyclic groups. The generators serve as a common reference benchmark.

[0046] The user issues credentials in a decentralized manner while keeping attributes hidden in plaintext, specifically as follows:

[0047] S21. User generates private attribute values. and key Calculate the publicly committed value and random values Construct a public instance ;

[0048] S22, User-computed attribute hash commitment value ,in For a function that hashes to a scalar field, this It will serve as a unique identifier for the credential;

[0049] S23, User generates credentials request ,in It is a non-interactive zero-knowledge proof based on the Schnorr protocol, used to prove that the user knows... The discrete logarithm proves that the user does indeed possess the original attribute corresponding to the attribute hash;

[0050] S24. Verification of the credential issuer Validity: Check the equation Whether it is valid, among which In response to generators, For the promise, Challenge value, Generates a domain element; after successful verification, the issuer will... Add to the list of public credentials The credential issuer is responsible for verifying user eligibility and maintaining a publicly verifiable list of credentials. .

[0051] As a preferred technical solution, the The specific generation process is as follows: The user selects a random number. Calculate commitment Calculate the challenge value Calculate the response ,in Output hash proof x is a field element of the attribute hash attr_hash, and hash_to_Fr(·) is a function that converts the hash into a field element.

[0052] As a preferred technical solution, the list of public credentials A whitelist mechanism is adopted, which is used by the issuer. The digital signature scheme authorizes a signature for each update operation, including adding or revoking; the public credential list The current state and operation logs are persistently stored, forming an off-chain operation history chain, which is then anchored to the blockchain to ensure transparency and auditability.

[0053] As a preferred technical solution, the user proves to the verifier that they possess a valid credential, and the privacy attribute value... To comply with cross-domain access policies, specifically:

[0054] S31. Generation of knowledge proof with commitment: The user will witness Input the cc-SNARK proof generation algorithm, where The identifier of the committed credential. Output proof for the private key of the user who is not committed. ,promise and open information ,satisfy and ;

[0055] S32. Set Membership Proof Generation: Randomly Select a Trapdoor The upper bound of the set size is ,for and ;Calculate generators Users generate their credential identifiers. promise Where r is a random number, then generate the proof. ,prove ,in It is a public list of vouchers, which hides the specific vouchers.

[0056] S33. Linkage Proof Generation: Let the commitment key used for the set membership proof be... The commitment key used in the cc-SNARK proof is The link proves existence. And opening the message, making the commitment And promise Established simultaneously;

[0057] S34. The verifier performs the following verifications in sequence:

[0058] The knowledge argument verification carrying commitment is as follows: ;

[0059] The set membership proof verification is as follows: ;

[0060] Linked proof verification: Verify commitment and Does it have consistency?

[0061] If all the above verifications pass, the credentials will be accepted.

[0062] As a preferred technical solution, the user displays multiple credentials to the verifier at once, and the verifier only needs to verify the aggregated proof of multiple credentials in a single verification. This is used for cross-domain display, and the displayed credentials originate from different domains, specifically:

[0063] User side:

[0064] S41. Generate ccGro16 aggregate proof: Input K sets of witnesses into the aggregation circuit to generate the aggregate proof. Commitment Witness Vector and blinding factor ;

[0065] S42, Generation Each SMA proof: For each certificate Independently run the SMA protocol to generate SMA commitments and proofs. ;

[0066] S43. Generating Link Aggregation Proof: Constructing Witness Vectors Output Link aggregation proof ;

[0067] Validator side:

[0068] The ccGro16 aggregated verification takes about the same time as the single-document ccGro16 verification.

[0069] One SMA verification, for the public credential list Each verification is performed separately, and the verifier directly recalculates the commitment value. as well as Each needs to be done once. The multi-scalar multiplication group operation, the multi-scalar multiplication group operation, the scalar multiplication accumulation over the group domain, the computational complexity and the list of public vouchers. size The relationship is linear;

[0070] Link aggregation verification is executed only once, and the verification time is... Irrelevant.

[0071] As a preferred technical solution, the optimization of the SMA verification includes:

[0072] The user acts as the certifier, pre-calculating the commitment value. as well as It is appended to the set membership proof, and simultaneously generates the KZG evaluation proof. Prove its correctness;

[0073] The validator at a random point The evaluation is based on KZG polynomial commitments, verifying KZG pairwise equations, and using the commitment values ​​provided by the prover to complete the master verification equation.

[0074] As a preferred technical solution, an aggregation verification circuit is provided, including an aggregation circuit and a link matrix extension;

[0075] The aggregation circuit is specifically as follows:

[0076] Assuming the user holds Each individual voucher Corresponding attribute constraints ,in, , For the i-th private attribute value, For the i-th user's private key, The structure of the aggregation circuit for the i-th public session identifier is as follows:

[0077] Commitment to witness in sequence There are K declarations in total;

[0078] No commitment to witnessing, declared in sequence There are K declarations in total;

[0079] Public inputs are declared in sequence. There are a total of 2,000 declarations;

[0080] in, To add random values, the aggregation circuit is for each Add attribute constraints, all Each attribute constraint is written into the same first-order constraint system R1CS instance to generate a single aggregate proof;

[0081] The link matrix expansion is specifically as follows:

[0082] Expand the SNARK matrix in the Link subspace from 2 rows per voucher to sparse matrix;

[0083] The columns of the sparse matrix are defined as follows: ,in For the first The commitment witness value of a credential. For the first The random blinding factor of an SMA commitment, is the random blinding factor in the proof of ccGro16.

[0084] As a preferred technical solution, each row of the sparse matrix is ​​defined as follows:

[0085] OK ,and Corresponding to the SMA commitment ,exist Column placement ,exist Column placement The rest are 0; row Corresponding to ccGro16 aggregation commitment ,exist Column placement ,exist Column placement The rest are 0.

[0086] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0087] (1) This invention constructs a complete, efficient, and secure decentralized anonymous credential framework. This framework uses cc-SNARK and SMA protocols as the core of proof, and aggregated circuits and extended Link matrices as efficiency optimization methods. It balances the security of the decentralized architecture with practical performance for cross-domain mutual recognition scenarios, providing a solid technical foundation for digital identity authentication. It achieves full-chain privacy protection capabilities from cross-domain anonymous identity mutual recognition to cross-domain trusted evidence exchange, providing a complete technical solution for the cross-domain, dynamic, and secure needs of identity authentication and evidence exchange in the Web3.0 environment.

[0088] (2) Regarding the efficiency of multi-credential aggregation verification, this solution improves efficiency through aggregation circuit design. The attribute constraints of each credential are merged into a single R1CS instance, and a single aggregate proof is generated using the ccGro16 scheme; simultaneously, by expanding the dimension of the Link matrix, the verification is completed in a single pairwise validation. The binding of individual SMA commitments to aggregate commitments. This makes the most time-consuming ccGro16 verification and Link verification on the validator side... Down to Prove that the total number is from Compressed to Experiments show that the verification efficiency is improved by approximately 39% compared to independent verification, and the amount of verification data is reduced by 66%, thus solving the problem of linear growth in multi-credential verification overhead in existing schemes.

[0089] (3) Regarding the modularity of secure binding, this invention introduces the commitment mechanism of cc-SNARK to explicitly encapsulate and expose the Pedersen commitment of the credential identifier. Unlike zk-creds' LinkG16, which coheses the binding logic within its internal Groth16 proof, the commitment binding of this invention is an independent cryptographic component. Any third-party component can independently verify the validity of the commitment and perform consistency comparison through the VerC interface, significantly improving the scalability and compatibility of the system.

[0090] (4) Regarding the performance of this invention in large-scale scenarios, this solution utilizes an SMA verification outsourcing optimization strategy based on KZG polynomial commitments to optimize the verifier's end performance. The less expensive group multiscalar multiplication (MSM) operation is outsourced to the prover, and the verifier only needs to perform the operation. Lightweight scalar-domain polynomial evaluation and constant-order bilinear pairwise verification. Experiments show that with a voucher list size of 131,072, this optimization achieves an 8.73x verification speedup, reducing verification time from 791ms to 90.6ms. Moreover, this speedup increases with the list size, fundamentally solving the performance bottleneck of the Merkle tree scheme where verification overhead increases logarithmically with the list size. Attached Figure Description

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

[0092] Figure 1 This is a diagram of the architecture of a traditional anonymous credential system.

[0093] Figure 2 Build a graph for the existing zk-SNARK;

[0094] Figure 3 Here is a flowchart of the existing zk-creds system;

[0095] Figure 4 This is a diagram illustrating the anonymous credential architecture of an embodiment of the present invention.

[0096] Figure 5 This is a schematic diagram of the structure of the aggregation verification circuit in an embodiment of the present invention. Detailed Implementation

[0097] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0098] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0099] This invention provides explanations for the following abbreviations or custom terms specific to the relevant professional field:

[0100] (1) Zero-knowledge proof: A cryptographic protocol that allows a prover to prove a statement to a verifier that it is true without revealing any additional information beyond the validity of the statement itself.

[0101] (2) Decentralization: In a credential issuance and verification architecture system, control and decision-making do not rely on a single central node or authoritative institution. Instead, multiple distributed participating nodes jointly maintain the operation of the system through consensus mechanisms or cooperation protocols. The core advantage of a decentralized architecture lies in eliminating the risk of single point of failure, enhancing the system's fault tolerance and censorship resistance, and reducing the reliance on a single entity. Typical decentralized technologies include blockchain and distributed ledgers.

[0102] (3) Anonymous credential system: A privacy-protected digital identity authentication system that allows users to prove to the verifier that they hold a valid credential issued by a legitimate institution without disclosing their real identity information, and can selectively disclose some attribute information.

[0103] (4) Cross-trust domain mutual recognition: Verifiers in different trust domains can independently verify the validity of anonymous credentials issued by other domains and establish temporary trust sessions for evidence exchange based on the successful verification results.

[0104] (5) Controllable exchange of evidence: Two or more entities belonging to different trust domains exchange a set of specific digital evidence in a non-repudiable manner after completing two-way identity verification and attribute mutual recognition through decentralized anonymous credentials.

[0105] Please see Figure 4 This embodiment provides a method for controlled exchange of evidence across trust domains based on decentralized anonymous credentials, including:

[0106] S1. Generate the public parameters and keys for each cryptographic sub-protocol, and make the public parameters public to all participants, including users, credential issuers, and verifiers. The credential issuers are responsible for verifying the user's qualifications and maintaining a publicly verifiable list of public credentials. ;

[0107] S2. Users issue credentials in a decentralized manner without disclosing the plaintext of attributes. The credentials include private attribute values. and user private key ;

[0108] S3. The user proves to the verifier that they possess a valid credential, and the privacy attribute value... Satisfy cross-domain access policies;

[0109] S4. Users can show multiple credentials to the validator at once. The validator only needs to verify the aggregated proof of multiple credentials once. This is used for cross-domain display, and the displayed credentials originate from different domains.

[0110] To clearly illustrate the participants in this application, this embodiment presents an anonymous credential architecture, such as... Figure 4As shown. Users have privacy attribute values. and private key The credential issuer is the holder of the credential and the generator of the proof; the credential issuer is responsible for verifying the user's eligibility and maintaining a publicly verifiable list of credentials. However, the verifier does not need to hold any signing private key; it is only responsible for maintaining the integrity and correctness of the list. The verifier is responsible for proposing cross-domain access policies to users and verifying whether users possess legitimate credentials and whether their attributes meet the requirements by verifying the zero-knowledge proofs submitted by users. The core interactions between the three parties include the credential request and issuance phase, and the credential presentation and verification phase. This architecture ensures that credential issuance is transparent and auditable, verification is efficient and privacy is protected, and it is the technical foundation for trusted cross-domain exchange and mutual recognition of evidence. It is worth explaining that the cross-domain access policy can be understood as the verifier being able to access public credential lists from different domains.

[0111] Preferably, step S1 executes the steps of the system initialization phase, which are as follows:

[0112] During the system initialization phase, a trusted third party or distributed multi-party secure computation is used to generate the common parameters of each sub-protocol, and the generated parameters are made public to all participants.

[0113] S11. Generation of the Common Reference String (CRS) for Set Membership Proof (SMA): Selecting the Bilinear Group ,in for Big prime number, for Cyclic group of order 1 Non-degenerate bilinear pairing. Trapdoors are randomly selected. ,for and ,calculate ;for ,calculate ,in for Generator, for Generator, output .Should A set membership proof protocol designed to support constant-level verification complexity.

[0114] S12. Concise non-interactive knowledge proof with commitment (ccGro16) proof and verification key pair generation: attribute-constrained circuits Generate a structured reference string containing the commitment key. Evaluation Key and verification key Circuit Relationships are encoded Its public input is ,witness ,satisfy .in It serves as a credential identifier, acting as witness to the commitment; Use the user's private key as a witness to an uncommitted promise; This is a public session identifier.

[0115] S13. Link Subspace Concise Non-Interactive Argumentation Key Generation: Based on Sparse Matrices This is generated to prove the consistency between SMA commitments and ccGro16 commitments. The dimension of matrix M is dynamically expanded based on the number of aggregated vouchers.

[0116] S14. Generation of common parameters for hash proof: Select Group generator As a public reference benchmark.

[0117] Preferably, step S2 is performed during the credential request and issuance phase, and the specific steps are as follows:

[0118] This stage is the core step for users to obtain legitimate anonymous credentials. The core security objective of this process is: users can prove to the issuer that their attributes meet the issuance policy without disclosing the plaintext of their attributes; after the issuer verifies the credentials, it only writes the attribute hash commitment into the public credential list, completing the decentralized issuance of the credentials, and never accesses the user's sensitive attribute information throughout the entire process. The specific process is as follows:

[0119] S21. User generates private attribute values. and key Calculate the publicly committed value and random values Construct a public instance .

[0120] S22, Calculate the attribute hash commitment value ,in For a function that hashes to a scalar field, this It will serve as a unique identifier for the credential.

[0121] S23, User generates credentials request ,in It is a non-interactive zero-knowledge proof based on the Schnorr protocol (converting the interactive Schnorr protocol into a non-interactive version through the Fiat-Shamir transformation), used to prove that the user knows... The discrete logarithm proves that the user indeed owns the original attribute corresponding to the attribute hash. The specific generation process is as follows: The user selects a random number. Calculate commitment Calculate the challenge value ; Calculate the response ,in Output hash proof x is a field element of the attribute hash attr_hash, and hash_to_Fr(·) is a function that converts the hash into a field element.

[0122] S24, Issuer Verification Validity: Check the equation Is it valid? Once verified, the issuer will... Add to the list of public credentials .

[0123] List of public certificates A whitelist mechanism is used, which is controlled by the issuer. The digital signature scheme authorizes the signing of each update operation (addition or revocation). The current state of the list and the operation log are persistently stored, forming an off-chain operation history chain, which can be anchored to the blockchain when necessary to ensure transparency and auditability.

[0124] Preferably, the credential display and verification module 13 and the aggregated verification mechanism module 14 collaboratively execute the credential display and verification stage, as follows:

[0125] When a user needs to present evidence to the verifier, the single credential presentation and verification phase begins. The user must prove to the verifier that they possess a valid credential with attributes that meet the access policy, while simultaneously concealing the credential's content, unique identifier, and user identity information. The presentation of proof consists of proofs from three sub-protocols:

[0126] S31, Knowledge Proof with Commitment (ccGro16) Generation: The user will witness Input the cc-SNARK proof generation algorithm, where The witness portion of the commitment (credential identifier). This is the uncommitted witness portion (user's private key). The algorithm outputs the proof. ,promise and open information ,satisfy and .

[0127] The construction of the ccGro16 proof is based on the Groth16 protocol, and is modified as follows: [Extensions] An additional Pedersen commitment key set is added to generate the commitment witness portion. The commitment; modifying proof generation, generating additional proofs along with Groth16 proofs. Pedersen commitment To enhance simulation extractability, an additional randomization factor is introduced during challenge generation, ensuring the scheme maintains knowledge integrity even in the presence of a simulation proof oracle. The proof consists of 3... Group elements and 2 The group consists of elements, with a total size of approximately 229 bytes on the BN254 elliptic curve. Verification requires only one iteration. The group exponentiation operation and four bilinear pairing operations have a verification time in the millisecond range and are constant, independent of the circuit size.

[0128] Furthermore, ccGroth16's commitment-carrying feature allows verifiers to flexibly combine multiple independent proofs at runtime, implementing complex composite access rules by verifying commitment consistency. In other words, verifiers can flexibly combine and define verification rules, significantly improving system flexibility while maintaining performance advantages.

[0129] S32. Set Membership Proof (SMA) generation: Randomly select a trapdoor. (In actual deployment, it is generated in a distributed manner via the MPC protocol), and the upper bound of the set size is... (i.e., the maximum number of valid credentials supported by the system), for and ; Calculate generators Users generate their credential identifiers. promise Where r is a random number, then generate the proof. ,prove ,in It provides a list of publicly available credentials, but does not reveal which specific credential it is.

[0130] The core idea behind the SMA protocol is to transform "set membership relations" into "vector inner product relations": the user-constructed length is... One-hot vector ,in The rest are 0. This vector satisfies three algebraic properties: duality ( That is, all elements are 0 or 1), unique heat ( That is, exactly one 1 and located in front. (bit), element extraction ( That is, the inner product of a vector and a set equals the secret value. This proof has a constant size (containing only 4...). Group elements and 3 (group elements), and set size Irrelevant, prove the output of the generation algorithm Each component verifies the above three properties using bilinear pairing equations, with the following meanings:

[0131] : For one-hot vector The promise;

[0132] : For vectors The promise, among which It is a challenge vector generated by a random oracle;

[0133] An aggregate proof that compresses the proofs of the following six subrelations into a single group element through a random linear combination. (prove Yes (the correct commitment) (prove (It is a binary vector, meaning each component is either 0 or 1). (prove It is a one-hot vector, meaning it has exactly one 1 and is located in front. Bit), (prove That is, the element to be proved belongs to the set. ), and (Separately binding commitments) (The exponent of a certain higher-order term is zero to ensure its formal correctness). Let... Let the aggregation coefficients be generated by a random oracle. The verifier can verify the correctness of all the above sub-relations simultaneously using a single pairing equation;

[0134] The commitments pre-calculated for outsourced verification correspond to certain polynomials in the verification equation that are determined by publicly available information at the secret point. The value at;

[0135] :one The assessment serves to ensure the fulfillment of the aforementioned outsourcing commitments. The correctness of the statement.

[0136] S33, Link generation: To prove the ccGro16 commitment and SMA commitment Bind to the same Value, user-generated link proof Let the commitment key used for the set membership proof be... The commitment key used in the cc-SNARK proof is Link proves existence And opening the message, making and This is established simultaneously. This fundamentally eliminates the possibility of "commitment switching attacks" where malicious users use different secret values ​​in different proof components.

[0137] The verifier performs the following verifications in sequence: ccGro16 verification ( SMA verification () Link verification (verifies the consistency of the two commitments, i.e., the attribute commitment values ​​in the SMA and cc-SNARK proofs are the same, to prevent "commitment switching attacks"). If all the above verifications pass, the credential is accepted; otherwise, it is rejected. Set membership proof proves the validity of the credential; private attributes satisfying cross-domain access policies do not require proof.

[0138] In some specific embodiments, this implementation employs an aggregated verification mechanism (multi-credential aggregation display and verification). In real-world Web3.0 applications and complex business scenarios involving cross-domain evidence exchange and mutual recognition, users often need to simultaneously prove multiple independent attribute declarations. If a single credential is used for sequential display, the computational and communication overhead increases linearly with the number of credentials. This invention designs an aggregated verification mechanism, the core idea of ​​which is to merge the constraint circuits of multiple credentials into a single aggregated circuit, reducing the core verification overhead from... Down to .like Figure 5 As shown, the specific technical solution includes:

[0139] Aggregator circuit design: Assuming the user holds Each individual voucher ( Corresponding attribute constraints The structure of the aggregated circuit is as follows: commitment witnesses are declared in sequence. (common (Number of items); those not committed to witnessing will be declared in sequence. (common (number of items); public inputs are declared in sequence. (common (number), of which To add random values. The circuit is for each Add multiplication constraints ,all All constraints are written into the same first-order constraint system (R1CS) instance. Since the verification time of the ccGro16 scheme is constant (independent of the number of multiplication gates), the time to verify an aggregate proof is almost the same as the time to verify a single-document proof.

[0140] Link matrix extension design: In multi-document aggregation scenarios, the matrix of the Link subspace SNARK is expanded from 2 rows for a single document to... A sparse matrix. Column layout: ,in For the first The commitment witness value of a credential. For the first The random blinding factor of an SMA commitment, Let be the randomized blinding factor in the ccGro16 proof. The rows of the matrix are defined as follows: row ,and Corresponding to the SMA commitment ,exist Column placement ,exist Column placement The rest are 0; row Corresponding to ccGro16 aggregation commitment ,exist Column placement ,exist Column placement The rest are 0. The verifier only needs to check the commitment vector. Whether something belongs to the column space of the matrix can be verified by only a constant number of pairing operations. Irrelevant.

[0141] Based on the aggregate circuit design and the link matrix extension design, the aggregate proof generation and verification process is executed as follows:

[0142] Voucher aggregation and display process (user side):

[0143] The first step is to generate a ccGro16 aggregated proof. K sets of witnesses are input into the aggregation circuit, which outputs the aggregated proof. Commitment Witness Vector and blinding factor ;

[0144] The second step is to generate... Each SMA certificate. Independently run the SMA protocol to generate SMA commitments and proofs. ;

[0145] The third step is to generate the Link aggregation proof. This involves constructing the witness vector. Output Link aggregation proof .

[0146] Credential aggregation and verification process (verifier side):

[0147] ccGro16 aggregate verification only needs to be executed once, and the verification time is comparable to that of single-document ccGro16 verification.

[0148] Each SMA validation requires execution because each credential list is independent. Second-rate;

[0149] Link aggregation verification only needs to be executed once, and the verification time is similar to... Irrelevant.

[0150] Through the above aggregation mechanism, the verifier's expensive cryptographic operations (ccGro16 verification and Link verification, both involving multiple bilinear pairing operations) are reduced. Down to Prove that the total number is from Compressed to This significantly improves verification and communication efficiency in multi-credential scenarios.

[0151] This invention designs a verification scheme based on circuit aggregation and matrix expansion to address the need for users to simultaneously present credentials from multiple different trust domains in cross-domain mutual recognition scenarios. This is achieved by constraining the attributes of K independent credentials (which may come from different issuing domains). All are merged into a single aggregate arithmetic circuit. The multiplication constraints are written into the same R1CS instance, and a single aggregation proof is generated using the ccGro16 scheme; at the same time, the SNARK matrix in the Link subspace is expanded from 2 rows to... The sparse matrix is ​​completed in a single verification. Each SMA commitment is bound to a single aggregated ccGro16 commitment for consistency. While existing zk-creds schemes support cross-credential composite verification, they require generating independent Groth16 proofs for each credential's membership proof and each attribute constraint. Even if association is achieved through internal blinded linking proofs (LinkG16), the core cryptographic operations in the verification process (multiple bilinear pairing operations) still increase with the number of credentials. Linear growth. The essential difference between the two lies in the fact that zk-creds' linking mechanism is for ex-post association of independent proofs, lacking an optimized design to merge multiple sets of witnesses into the same circuit for aggregated proofs; this invention, through aggregated circuit design, integrates ccGro16 verification from... The number of steps is reduced to one by extending the Link matrix design, thus reducing the link proof verification from... The number of verifications has been reduced from one to two, and the core verification overhead has decreased from [previous level]. Downgraded to .

[0152] In some embodiments, for SMA verification, the present invention provides a scheme for SMA verification outsourcing optimization based on KZG polynomial commitment.

[0153] Although the SMA protocol has compressed the proof size to a constant, the validator's verification equation still contains multiple exponential operations, and its computational complexity varies with the size of the list of credentials. Linear growth. This invention utilizes the constant verification property of KZG polynomial commitments to outsource this part of the calculation to the prover. The optimization principle is as follows.

[0154] Non-optimized verification: The verifier directly recalculates the commitment value. Each needs to be done once. Multiscalar multiplication (MSM) group operations. MSM is a scalar multiplication and accumulation over a group domain, with computational complexity proportional to the size of the voucher list. The linear relationship is the performance bottleneck at the verification end.

[0155] Optimized verification: The prover pre-calculates the above commitment values ​​and appends them to the set membership proof, while simultaneously generating a KZG evaluation proof. Prove its correctness. The verifier only needs to: at a random point Evaluation polynomial ( (Scalar field operations are much faster than group operations); verify the KZG pairing equation (constant-order pairing); complete the main verification equation using the commitment value provided by the prover.

[0156] Through the above optimizations, the expensive cryptographic operations required by the verifier (group exponentiation and bilinear pairing) are reduced to a value equal to the size of the set. Irrelevant constant level.

[0157] This is a typical architectural optimization that trades computing power on the proving side for efficiency on the verifying side: the prover is the user terminal, which usually has sufficient computing resources; while the verifier is mostly a resource-constrained node such as on-chain smart contracts and IoT gateways, and needs to handle a large number of concurrent verification requests. Experiments show that when the size of the credential list reaches 131,072, the verification speedup reaches 8.73 times, and the verification time decreases from 791ms to 90.6ms. Moreover, the speedup increases with the increase of the list size, significantly enhancing the system's high-concurrency processing capability in scenarios with massive numbers of users.

[0158] This invention constructs a complete, efficient, and secure decentralized anonymous credential framework through the four core steps described above. This framework uses cc-SNARK and SMA protocols as its core proofs, and aggregated circuits and extended Link matrices as efficiency optimization methods. It balances the security of a decentralized architecture with practical performance for cross-domain mutual recognition scenarios, providing a solid technical foundation for digital identity authentication. While existing technology zk-creds binds membership and attribute proofs of the same credential through its internal LinkG16 protocol, this binding capability is cohesive within its internal Groth16 proof construction and does not abstract the commitment relationship into a modular cryptographic component independent of a specific proof system. The essential difference lies in the fact that the cc-SNARK of this invention explicitly and modularly encapsulates and exposes the commitment of the credential identifier, enabling other components within the system and even third-party components to verify the binding relationship with the same subject through a unified interface. This surpasses zk-creds' cohesive binding scheme in terms of scalability and multi-component compatibility.

[0159] By using the aforementioned decentralized anonymous credential system as a cross-domain trust anchor, a controllable evidence exchange mechanism across trust domains is further implemented. This allows users and verifiers belonging to different trust domains to first mutually confirm each other's anonymized credentials through zero-knowledge proofs without intermediaries. Subsequently, within the same secure session, based on preset access control policies, they can exchange multi-source digital evidence in a controllable manner. This exchange process follows the principle of minimal disclosure, achieving controllable exchange; neither party can obtain the other's evidence without holding valid credentials, and the exchanged content is cryptographically bound to the credential proof, making it indivisible and undeniable. Through further adaptation of aggregation circuits and extended Link matrices, this system supports batch aggregation and exchange of multi-source cross-trust domain evidence. Users can simultaneously prove to verifiers that they hold legitimate credentials from multiple heterogeneous trust domains and exchange multiple pieces of evidence from different data sources at once. In summary, this invention achieves end-to-end privacy protection capabilities from cross-domain anonymous identity mutual recognition to cross-domain trusted evidence exchange, providing a complete technical solution for the cross-domain, dynamic, and secure requirements of identity authentication and evidence exchange in the Web3.0 environment.

[0160] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0161] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.

Claims

1. A method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials, characterized in that, include: S1. Generate the public parameters and keys for each cryptographic sub-protocol, and make the public parameters public to all participants, including users, credential issuers, and verifiers. The credential issuers are responsible for verifying the user's qualifications and maintaining a publicly verifiable list of public credentials. ; Configure the aggregation verification circuit, including the aggregation circuit and link matrix expansion; The aggregation circuit is specifically as follows: Assuming the user holds Each individual voucher Corresponding attribute constraints ,in, , For the i-th private attribute value, For the i-th user's private key, The structure of the aggregation circuit for the i-th public session identifier is as follows: Commitment to witness in sequence There are K declarations in total; No commitment to witnessing, declared in sequence There are K declarations in total; Public inputs are declared in sequence. There are a total of 2,000 declarations; in, To add random values, the aggregation circuit is for each Add attribute constraints, all Each attribute constraint is written into the same first-order constraint system R1CS instance to generate a single aggregate proof; The link matrix expansion is specifically as follows: Expand the SNARK matrix in the Link subspace from 2 rows per voucher to sparse matrix; The columns of the sparse matrix are defined as follows: ,in For the first The commitment witness value of a credential. For the first The random blinding factor of an SMA commitment, For the random blinding factor in the ccGro16 proof; Each row of the sparse matrix is ​​defined as follows: OK ,and Corresponding to the SMA commitment ,exist Column placement ,exist Column placement The rest are 0; row Corresponding to ccGro16 aggregation commitment ,exist Column placement ,exist Column placement The rest are 0; S2. Users issue credentials in a decentralized manner while keeping attributes hidden in plaintext. These credentials include private attribute values. and user private key ; S3. The user proves to the verifier that they possess a valid credential, and the privacy attribute value... Satisfy cross-domain access policies; S4. A user displays multiple credentials to a validator at once. The validator only needs to verify the aggregated proof of the multiple credentials in a single verification. This is for cross-domain display, and the displayed credentials originate from different domains. Specifically, the user displays multiple credentials to the validator at once, and the validator only needs to verify the aggregated proof of the multiple credentials in a single verification. This is for cross-domain display, and the displayed credentials originate from different domains. User side: S41. Generate ccGro16 aggregate proof: Input K sets of witnesses into the aggregation circuit to generate the aggregate proof. Commitment Witness Vector and blinding factor ; S42, Generation Each SMA proof: For each certificate Independently run the SMA protocol to generate SMA commitments and proofs. ; S43. Generating Link Aggregation Proof: Constructing Witness Vectors Output Link aggregation proof ; Validator side: The ccGro16 aggregated verification takes about the same time as the single-document ccGro16 verification. One SMA verification, for the public credential list Each verification is performed separately, and the verifier directly recalculates the commitment value. as well as Each needs to be done once. The multi-scalar multiplication group operation, the multi-scalar multiplication group operation, the scalar multiplication accumulation over the group domain, the computational complexity and the list of public vouchers. size The relationship is linear; Link aggregation verification is executed only once, and the verification time is... Irrelevant.

2. The method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials according to claim 1, characterized in that, Step S1 involves generating common parameters for each sub-protocol through a trusted third party or distributed multi-party secure computation, including: Generation of public reference strings for set membership proofs, i.e., selection of the bilinear group. Randomly select a trapdoor, and use the cyclic group in the bilinear group and the selected trapdoor to obtain a common reference string. , for Big prime number, for Cyclic group of order 1 Non-degenerate bilinear pairing; Generate concise, non-interactive knowledge proof and verification key pairs with commitments, i.e., attribute-constrained circuits. Generate a structured reference string, including the commitment key. Evaluation Key and verification key The attribute constraint circuit Encoding Relationship ,relation Public input is ,witness ,satisfy ,in As a credential identifier, serving as witness to the commitment. The user's private key serves as a witness to an uncommitted promise. For public session identification; Linked subspace concise non-interactive argument key generation, i.e., based on sparse matrices. Generate evidence to demonstrate the consistency between the SMA commitment and the ccGro16 commitment; Hash proofs the generation of common parameters, i.e., selection of cyclic groups. The generators serve as a common reference benchmark.

3. The method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials according to claim 1, characterized in that, The user issues credentials in a decentralized manner while keeping attributes hidden in plaintext, specifically as follows: S21. User generates private attribute values. and key Calculate the publicly committed value and random values Construct a public instance ; S22, User-computed attribute hash commitment value ,in For a function that hashes to a scalar field, this It will serve as a unique identifier for the credential; S23, User generates credentials request ,in It is a non-interactive zero-knowledge proof based on the Schnorr protocol, used to prove that the user knows... The discrete logarithm of the attribute hash promise is used to prove that the user does indeed possess the original attribute corresponding to the attribute hash promise value. S24. Verification of the credential issuer Validity: Check the equation Whether it is valid, among which In response to generators, For the promise, Challenge value, Generates a meta-element for the domain element; after successful verification, the issuer will... Add to the list of public credentials The credential issuer is responsible for verifying user eligibility and maintaining a publicly verifiable list of credentials. .

4. The method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials according to claim 3, characterized in that, The The specific generation process is as follows: The user selects a random number. Calculate commitment Calculate the challenge value Calculate the response ,in Output hash proof x is a field element of the attribute hash attr_hash, and hash_to_Fr(·) is a function that converts the hash into a field element.

5. The method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials according to claim 3, characterized in that, The list of public credentials A whitelist mechanism is adopted, which is used by the issuer. The digital signature scheme authorizes a signature for each update operation, including adding or revoking; the public credential list The current state and operation logs are persistently stored, forming an off-chain operation history chain, which is then anchored to the blockchain to ensure transparency and auditability.

6. The method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials according to claim 1, characterized in that, The user proves to the verifier that they possess valid credentials, and the privacy attribute value... To comply with cross-domain access policies, specifically: S31. Generation of knowledge proof with commitment: The user will witness Input the cc-SNARK proof generation algorithm, where The identifier of the committed credential. Output proof for the private key of the user who is not committed. ,promise and open information ,satisfy and ; S32. Set Membership Proof Generation: Randomly Select a Trapdoor The upper bound of the set size is ,for and ;Calculate generators Users generate their credential identifiers. promise Where r is a random number, then generate the proof. ,prove ,in It is a public list of vouchers, which hides the specific vouchers. S33. Linkage Proof Generation: Let the commitment key used for the set membership proof be... The commitment key used in the cc-SNARK proof is The link proves existence. And opening the message, making the commitment And promise Established simultaneously; S34. The verifier performs the following verifications in sequence: The knowledge argument verification carrying commitment is as follows: ; The set membership proof verification is as follows: ; Linked proof verification: Verify commitment and Does it have consistency? If all the above verifications pass, the credentials will be accepted.

7. The method for controllable exchange of evidence across trust domains based on decentralized anonymous credentials according to claim 1, characterized in that, The optimization of the SMA verification includes: The user acts as the certifier, pre-calculating the commitment value. as well as It is appended to the set membership proof, and simultaneously generates the KZG evaluation proof. Prove its correctness; The validator at a random point The evaluation is based on KZG polynomial commitments, verifying KZG pairwise equations, and using the commitment values ​​provided by the prover to complete the master verification equation.

Images