Zero-knowledge proof generation and verification method and device
By decrypting in a trusted execution environment and generating zero-knowledge proofs using a specially designed pre-designed proof circuit, the problem of low efficiency in generating zero-knowledge proofs is solved, enabling fast and secure credit data queries.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- QIANTANG CREDIT INFORMATION CO LTD
- Filing Date
- 2026-01-22
- Publication Date
- 2026-07-14
AI Technical Summary
In existing technologies, the generation efficiency of zero-knowledge proofs is low, which cannot meet the real-time query requirements of credit data, and the large scale of general proof circuits leads to a slow generation rate.
In a trusted execution environment, the encrypted data of the target credit information is decrypted using an encryption key to generate a preset proof circuit specifically designed for the target verification conditions. The plaintext data and verification conditions are then processed to generate a zero-knowledge proof of the target.
It improves the generation speed and efficiency of zero-knowledge proofs, ensures data security, reduces circuit size, and enhances generation efficiency.
Smart Images
Figure CN121567340B_ABST
Abstract
Description
Technical Field
[0001] This specification relates to one or more embodiments in the field of zero-knowledge proof technology, and in particular to a method and apparatus for generating and verifying zero-knowledge proofs. Background Technology
[0002] With increasingly stringent requirements for the confidentiality of credit data, the traditional model of directly sharing all target credit data is no longer feasible.
[0003] Currently, in related technologies, zero-knowledge proofs are generally used to verify and query various credit data. However, most of these technologies use a general zero-knowledge proof development framework to generate a general proof circuit, and then generate a zero-knowledge proof based on the general proof circuit. Due to the large scale of the general proof circuit, the rate of generating zero-knowledge proofs in these technologies is slow, which cannot meet the real-time query requirements of credit data. Summary of the Invention
[0004] In view of this, one or more embodiments of this specification provide a method and apparatus for generating and verifying zero-knowledge proofs.
[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:
[0006] According to a first aspect of one or more embodiments of this specification, a zero-knowledge proof generation method is proposed, comprising:
[0007] The encrypted data of the target credit data of the target certifier and the target verification conditions corresponding to the target credit data are obtained; the encrypted data is obtained by encrypting the plaintext data of the target credit data with an encryption key;
[0008] In a trusted execution environment, the encrypted data is decrypted based on the encryption key to obtain the plaintext of the target credit data. A target preset proof circuit corresponding to the target verification condition is determined from multiple preset proof circuits. The plaintext data and the target verification condition are processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data. The target zero-knowledge proof is used to indicate whether the target credit data meets the target verification condition under the verification of a proof verification algorithm that matches the target preset proof circuit.
[0009] According to a second aspect of one or more embodiments of this specification, a zero-knowledge proof verification method is proposed, comprising:
[0010] A target zero-knowledge proof is obtained from the target credit data. This target zero-knowledge proof is generated in a trusted execution environment by processing the plaintext of the target credit data and the target verification conditions corresponding to the target credit data using a target preset proof circuit. The target preset proof circuit is a preset proof circuit corresponding to the target verification conditions among multiple preset proof circuits. The plaintext data is obtained by decrypting the ciphertext of the target credit data using an encryption key in the trusted execution environment.
[0011] Obtain a proof verification algorithm that matches the target preset proof circuit, and verify the target zero-knowledge proof based on the proof verification algorithm that matches the target preset proof circuit.
[0012] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising:
[0013] processor;
[0014] Memory used to store processor-executable instructions;
[0015] The processor implements the method as described in the first aspect or the second aspect by running the executable instructions.
[0016] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first or second aspect.
[0017] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising: a computer program / instructions that, when executed by a processor, implement the method as described in the first aspect or the second aspect.
[0018] As can be seen from the above embodiments, the zero-knowledge proof generation and verification method and apparatus provided in one or more embodiments of this specification obtains the encrypted data of the target credit data of the target prover, and the target verification conditions corresponding to the target credit data. The encrypted data is obtained by encrypting the plaintext data of the target credit data with an encryption key. The encrypted data better ensures the security of the target credit data during transmission and prevents leakage due to interception. After obtaining the encrypted data and the target verification conditions, the encrypted data is decrypted based on the encryption key in a trusted execution environment to obtain the plaintext data of the target credit data. Since the decryption process takes place in a trusted execution environment, it can prevent the plaintext data from being leaked while enabling the direct generation of zero-knowledge proofs from the plaintext data, thereby improving the generation speed of zero-knowledge proofs. Meanwhile, to further improve the generation efficiency of zero-knowledge proofs, multiple preset proof circuits are pre-deployed in the trusted execution environment. Each preset proof circuit is used to generate a zero-knowledge proof of a specific type. After obtaining the target verification condition, the target preset proof circuit corresponding to the target verification condition can be determined from the multiple preset proof circuits. The plaintext data and the target verification condition are then processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data. Since the target preset proof circuit is specifically designed for the proof type corresponding to the target verification condition, it is smaller in scale and faster in execution compared to a general circuit applicable to all proof types, thus significantly improving the generation efficiency of zero-knowledge proofs. Attached Figure Description
[0019] Figure 1 This is an exemplary embodiment of the architecture diagram of an application scenario for a zero-knowledge proof generation method.
[0020] Figure 2 This is a flowchart illustrating a zero-knowledge proof generation method provided in an exemplary embodiment.
[0021] Figure 3 This is a flowchart illustrating another zero-knowledge proof generation method provided in an exemplary embodiment.
[0022] Figure 4 This is a flowchart illustrating a zero-knowledge proof verification method provided in an exemplary embodiment.
[0023] Figure 5 This is a flowchart illustrating a zero-knowledge generation and verification process provided in an exemplary embodiment.
[0024] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.
[0025] Figure 7 This is a block diagram of a zero-knowledge proof generation apparatus provided in an exemplary embodiment.
[0026] Figure 8 This is a block diagram of a zero-knowledge proof verification apparatus provided in an exemplary embodiment. Detailed Implementation
[0027] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.
[0028] The organizational information (including but not limited to organizational equipment information, organizational personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this manual are all information and data authorized by the organization or fully authorized by all parties. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for the organization to choose to authorize or refuse.
[0029] For privacy reasons, users want their personal data, such as credit information, to remain confidential. Zero-knowledge proofs consist of two parts: a prover who declares a proposition true and a verifier who confirms that the proposition is indeed true. The prover can convince the verifier that a statement is correct without providing any useful information.
[0030] Zero-knowledge proof is essentially a protocol involving two or more parties, outlining a series of steps required for them to complete a task. The proving party proves and convinces the verifying party of a certain piece of information they possess, but the proof process cannot reveal any information about the proven information to the verifying party, thus avoiding the leakage of the proving party's privacy. For example, regarding credit data, the proving party might use zero-knowledge proof to demonstrate and convince the verifying party that a certain piece of their credit data meets a certain requirement, but the proof process cannot reveal any information about the proving party's credit data to the verifying party.
[0031] As described in the background section, most current related technologies employ a general zero-knowledge proof development framework to generate a general proof circuit, and then generate zero-knowledge proofs based on this general proof circuit. Since the general proof circuit needs to generate all types of zero-knowledge proofs, its design requires consideration of circuit constraints applicable to various proof types. Furthermore, it necessitates various logical judgments to ensure that the general proof circuit outputs a proof result matching the current proof type each time. Consequently, the general proof circuits used in these technologies are large in scale and operate slowly, resulting in low efficiency in generating zero-knowledge proofs and failing to meet the real-time query requirements of credit data.
[0032] Furthermore, to prevent the leakage of credit data during the generation of zero-knowledge proofs, related technologies typically encrypt the credit data to be used for generating zero-knowledge proofs and then complete the generation of zero-knowledge proofs in the encrypted state. However, processing the encrypted credit data during the generation of zero-knowledge proofs undoubtedly increases computation time and cost, thereby affecting the generation rate of zero-knowledge proofs.
[0033] In summary, to address the low efficiency of zero-knowledge proofs for credit data in related technologies, this specification provides a method for generating zero-knowledge proofs. First, the method obtains the ciphertext of the target credit data of the target prover, along with the corresponding target verification conditions. The ciphertext is obtained by encrypting the plaintext of the target credit data using an encryption key. This encryption enhances the security of the target credit data during transmission, preventing leakage due to interception. After obtaining the ciphertext and the target verification conditions, the ciphertext is decrypted using the encryption key in a trusted execution environment to obtain the plaintext of the target credit data. Since the decryption process occurs within a trusted execution environment, it prevents the plaintext from being leaked while simultaneously enabling the direct generation of zero-knowledge proofs from the plaintext, thereby improving the generation speed of zero-knowledge proofs. Meanwhile, to further improve the generation efficiency of zero-knowledge proofs, multiple preset proof circuits are pre-deployed in the trusted execution environment. Each preset proof circuit is used to generate a zero-knowledge proof of a specific type. After obtaining the target verification condition, the target preset proof circuit corresponding to the target verification condition can be determined from the multiple preset proof circuits. The plaintext data and the target verification condition are then processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data. Since the target preset proof circuit is specifically designed for the proof type corresponding to the target verification condition, it is smaller in scale and faster in execution compared to a general circuit applicable to all proof types, thus significantly improving the generation efficiency of zero-knowledge proofs.
[0034] Figure 1 This is an exemplary embodiment illustrating an application scenario for a zero-knowledge proof generation method involving target credit data. For example... Figure 1 As shown, the method may include a server 11, a network 12, and several electronic devices, such as a PC (Personal Computer) 13, a mobile phone 14, etc.
[0035] Server 11 can be a physical server containing an independent host, or it can be a virtual server hosted in a host cluster. During operation, server 11 can run server-side programs for a certain application to implement the relevant functions of that application. For example, when server 11 runs a zero-knowledge proof generation program, it can act as a carrier for generating zero-knowledge proofs.
[0036] PC13 and mobile phone14 are just some of the types of electronic devices that organizations can use. In reality, organizations can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and one or more embodiments in this specification do not limit this. During operation, the electronic device can run a client-side program of an application to implement the relevant functions of that application. For example, when the electronic device runs the program service of the aforementioned zero-knowledge proof generation method, it can act as a prover serving the program; that is, the electronic device can act as a prover to send a request to the server to generate a zero-knowledge proof and provide the corresponding raw data. In some embodiments, the aforementioned electronic device can also run a program service of a zero-knowledge proof verification method. In this case, the electronic device can act as a verifier verifying the zero-knowledge proof. The client application of the aforementioned program service can be launched and run on the electronic device. The client-side program can be a native application installed on the electronic device, or it can be a mini-program, quick app, or other similar form. Of course, when using web technologies such as HTML5 or similar, the relevant functions can be achieved through the page displayed by the browser. The browser here can be a standalone browser application or a browser module embedded in some applications.
[0037] As for the network 12 that enables interaction between electronic devices such as PC13 and mobile phone 14 and server 11, wired or wireless networks can be selected for communication based on the communication methods supported by the respective electronic devices. This specification does not impose any restrictions on this. For example, PC13 can support both wired and wireless communication, so it can use either wired or wireless networks as needed. Mobile phone 14 typically only supports wireless communication, so it can use a wireless network for communication.
[0038] refer to Figure 2 Here is a flowchart of a zero-knowledge proof generation method provided in this specification, which includes the following steps:
[0039] S202, obtain the encrypted data of the target credit data of the target certifier, and the target verification conditions corresponding to the target credit data; the encrypted data is obtained by encrypting the plaintext data of the target credit data with an encryption key.
[0040] The target prover can be any prover that needs to provide a zero-knowledge proof. For example, the target prover could be a user who needs to prove to a bank that their credit score is greater than 650. The target credit data is the original data that the target prover wants to use to generate the zero-knowledge proof. For example, in the credit score example above, the target credit data could be the original data used to characterize the user's credit score. This target credit data is generally considered private input data in zero-knowledge proofs, meaning it cannot be obtained by the verifier. In some embodiments, the target credit data obtained from the target prover can be obtained directly from the target prover or from the corresponding credit reporting platform; there is no limitation on this. In some embodiments, to prevent the target credit data from being intercepted during transmission and thus leaked, the plaintext of the target credit data can be encrypted using an encryption key before transmission to obtain the ciphertext. Then, when the credit data needs to be transmitted, only the ciphertext of the target credit data is transmitted.
[0041] In order to accurately generate zero-knowledge proofs of target credit data, it is necessary to obtain the target verification conditions corresponding to the target credit data along with the target credit data. These target verification conditions are generally provided by the target proof party. For example, when the target credit party wants to prove that its credit score is greater than 650, the target verification condition can be set to prove that the credit score is greater than 650.
[0042] S204, in a trusted execution environment, the encrypted data is decrypted based on the encryption key to obtain the plaintext of the target credit data, and a target preset proof circuit corresponding to the target verification condition is determined from a plurality of preset proof circuits. The plaintext data and the target verification condition are processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data. The target zero-knowledge proof is used to indicate whether the target credit data meets the target verification condition under the verification of a proof verification algorithm that matches the target preset proof circuit.
[0043] A Trusted Execution Environment (TEE) is a secure extension of the CPU hardware, completely isolated from the external environment. Originally proposed by Global Platform, TEE aims to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications, operating parallel to the operating system. ARM's Trust Zone technology was the first to implement truly commercially viable TEE technology.
[0044] With the rapid development of the internet, security demands are increasing, not only for mobile devices but also for cloud devices and data centers, placing greater emphasis on TEE (Transparent Equipment). The concept of TEE has also evolved and expanded rapidly. The TEE we refer to today is much broader than its initial concept. For example, server chip manufacturers like Intel and AMD have launched hardware-assisted TEEs, enriching the concept and features of TEEs and gaining widespread acceptance in the industry. Now, TEE usually refers more to this type of hardware-assisted TEE technology. Unlike mobile devices, cloud access requires remote access, and the end user cannot see the hardware platform. Therefore, the first step in using a TEE is to verify its authenticity and trustworthiness. Thus, current TEE technologies incorporate remote authentication mechanisms, endorsed by hardware manufacturers (mainly CPU manufacturers) and using digital signature technology to ensure user verification of the TEE's status. Furthermore, secure resource isolation alone cannot meet security needs; further data privacy protection has been proposed. Commercial TEEs, including Intel SGX and AMD SEV, also provide memory encryption technology, confining trusted hardware within the CPU, with bus and memory data encrypted to prevent malicious users from spying. For example, TEE technologies such as Intel's Software Protection Extensions (SGX) isolate code execution, remote proofs, secure configuration, secure data storage, and trusted paths for code execution. Therefore, applications running in a TEE and the data stored therein are securely protected and virtually inaccessible to third parties. In the embodiments of this specification, the generation process of zero-knowledge proofs is completed within a Trusted Execution Environment (TEE), thereby enabling the direct generation of zero-knowledge proofs using the plaintext of target credit data without concern for the leakage of the plaintext.
[0045] To accurately reconstruct the plaintext corresponding to the ciphertext of the target credit information data, in some embodiments, the encryption key used to encrypt the plaintext can be directly deployed in a trusted execution environment. This allows for decryption of the ciphertext within the trusted execution environment, based on the encryption key, to obtain the plaintext of the target credit information data. In some embodiments, when decrypting the ciphertext, the encryption key used to encrypt the plaintext can be obtained externally first. Considering the confidentiality of credit information data, the encryption key can be obtained from the party encrypting the credit information data and can be transmitted separately from the encrypted ciphertext, preventing the ciphertext from being directly cracked based on the encryption key after interception.
[0046] In a trusted execution environment, after decrypting the encrypted data to obtain the plaintext of the target credit data, to further improve the generation efficiency of zero-knowledge proofs, in this embodiment, multiple preset proof circuits are pre-deployed in the trusted execution environment according to different proof types of zero-knowledge proofs. Each preset proof circuit is specifically designed for generating a zero-knowledge proof of a particular proof type. For example, when a user wants to prove that their credit score is within a certain range, one preset proof circuit can generate a zero-knowledge proof of the credit score; when a user wants to prove that their debt ratio meets a certain range, another preset proof circuit can generate a zero-knowledge proof of the debt ratio. This makes the design of each preset proof circuit more targeted, minimizes the size of each circuit, and further improves the execution speed. Therefore, after obtaining the plaintext of the target credit data, a target preset proof circuit corresponding to the target verification condition can be determined from the multiple preset proof circuits based on the target verification condition. The plaintext data and the target verification condition are then processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data.
[0047] It should be noted that since the verification conditions include the proof conditions for the zero-knowledge proof that the prover wants to achieve, such as whether the credit score is greater than a certain threshold or whether the debt ratio is less than a certain threshold, the proof type of the zero-knowledge proof to be generated can be directly determined through the verification conditions. In some embodiments, keywords for filtering preset proof circuits can be directly identified from the verification conditions through semantic recognition, such as the credit score and debt ratio in the above example, and then preset proof circuits that match these keywords can be filtered out. In some embodiments, the proof type of the zero-knowledge proof to be generated can be determined first through the verification conditions, and then the preset proof circuit that matches the current proof type can be determined from multiple preset proof circuits based on this proof type.
[0048] It should be noted that zero-knowledge proof technology includes a proof generation algorithm and a proof verification algorithm. The proof generation algorithm generates a zero-knowledge proof corresponding to the prover's private data. This zero-knowledge proof indicates that the prover's private data meets the verification conditions set for that private data. This zero-knowledge proof can then be verified using a proof verification algorithm that matches the proof generation algorithm to determine whether the content indicated by the zero-knowledge proof is correct. In short, in the processes of credit data collection, proof generation, and proof verification, the proof generation algorithm and proof verification algorithm included in zero-knowledge proof technology are mutually corresponding. In the embodiments of this specification, the proof generation algorithm is implemented through a preset proof circuit. Therefore, the proof verification algorithm used by the verifier to verify the zero-knowledge proof matches the preset proof circuit that generated the zero-knowledge proof. That is, in the above embodiments, after a target zero-knowledge proof is generated through the target preset proof circuit, the verifier can use the proof verification algorithm that matches the target preset proof circuit to verify whether the target credit data meets the target verification conditions.
[0049] In some embodiments of this specification, the target zero-knowledge proof of the target credit data is generated by processing the plaintext data and the target verification conditions based on the target preset proof circuit, including:
[0050] Based on the plaintext data and the target verification condition, the circuit constraints of the target preset proof circuit are executed to obtain a set of mathematical constraint equations corresponding to the plaintext data and the target verification condition; the circuit constraints of the target preset proof circuit are set by the proof type corresponding to the target verification condition.
[0051] The mathematical constraint equations are transformed into the zero-knowledge proof of the target based on the proof key of the target preset proof circuit.
[0052] In the embodiments of this specification, the preset proof circuit includes circuit constraints and a proof key. The circuit constraints are used to transform abstract propositions into mathematically computable constraints through a series of execution processes, realizing the transformation of plaintext credit data and verification conditions into a set of mathematical constraint equations. The proof key is used to transform the set of mathematical constraint equations into a zero-knowledge proof. It should be noted that the set of mathematical constraint equations transforms verification conditions into data expressions that can be used to generate zero-knowledge proofs, and obtains the data required to generate zero-knowledge proofs from the credit data, filling it into the data expressions, ultimately obtaining the set of mathematical constraint methods. Since the set of data constraint methods includes the original data of the credit data, it cannot be used as a zero-knowledge proof. Therefore, it is necessary to further encrypt the set of mathematical constraint equations using the proof key to obtain a zero-knowledge proof that can only be verified but whose original data cannot be obtained. It should be noted that in the embodiments of this specification, since different proof types of zero-knowledge proofs correspond to different preset proof circuits, the circuit constraints of the target preset proof circuit are set according to the proof type corresponding to the target verification conditions. This ensures that the circuit constraints in each preset proof circuit are specifically used to execute data of one type of proof, reducing many redundant circuit constraints and improving the execution speed of the preset proof circuit.
[0053] It should be noted that, in order for the verifier to accurately verify the zero-knowledge proof using the proof verification algorithm, the proof verification algorithm includes a verification key corresponding to the proof key. This verification key is generally a subset of the corresponding proof key, retaining only the constraint parameters necessary for verification, to help the verifier verify whether the content stated by the zero-knowledge proof is correct. In some embodiments, the aforementioned proof key (PK) and verification key (VK) can be set according to the specific zero-knowledge proof development framework selected. For example, the corresponding proof key (PK) and verification key (VK) can be set according to the specific requirements of development frameworks such as STARK (Scalable Transparent Argument of Knowledge) or Groth16 (Efficient Zero-Knowledge Proof), and there is no limitation on this.
[0054] In some embodiments of this specification, the plurality of preset proof circuits include: a first preset proof circuit for proving that the output result of the scoring model is within a first preset range, and / or a second preset proof circuit for proving that the ratio of two values is within a second preset range, and / or a third preset proof circuit for proving that the time limit is within a third preset range.
[0055] It should be noted that, in some embodiments, the scoring model corresponding to the first preset proof circuit mentioned above can be a credit scoring model, a risk scoring model, a return scoring model, etc. The ratio of the two values mentioned above can be the user's debt-to-equity ratio, cash flow coverage ratio, asset turnover ratio, etc. The term mentioned above can include overdue days, repayment period, account holding period, etc. The first, second, and third preset ranges mentioned above represent preset ranges that can be replaced according to verification conditions during the zero-knowledge proof generation process. For example, when a target verification condition is to prove a credit score greater than 650, the first preset range can be replaced with greater than 650.
[0056] In some embodiments of this specification, the first preset proof circuit includes a first circuit constraint and a first proof key;
[0057] The first circuit constraint is used to transform the linear calculation process of the scoring model and the process of determining that the result of the linear calculation is within the first preset range into a first set of mathematical constraint equations;
[0058] The first proof key is used to transform the first set of mathematical constraint equations into a zero-knowledge proof.
[0059] The aforementioned first preset proof circuit is used to prove that the output result of the scoring model is within a first preset range. To improve the efficiency and quality of zero-knowledge proofs generated by the first preset proof circuit, in this embodiment, the first circuit constraint of the first preset proof circuit does not directly use the output result of the scoring model as the circuit input. Instead, it uses the various credit feature data from the linear calculation of the scoring model as the circuit input. Therefore, while the first preset proof circuit transforms the process of determining that the result of the linear calculation is within the first preset range (i.e., the content corresponding to the target verification condition) into a set of mathematical constraint equations, it also transforms the linear calculation process of the scoring model into a set of mathematical constraint equations. This provides a more convincing zero-knowledge proof for the verifier. The set of mathematical constraint schemes corresponding to the linear calculation of the scoring model can fully demonstrate that a certain score of the prover is true. Moreover, since the final score result is split into multiple feature data, the difficulty of cracking the true score is further increased. In some embodiments, the above transformation process can be completed using R1CS (Rank-1 Constraint System, a method for transforming computational problems into arithmetic circuit representations that can be processed by zero-knowledge proofs), or directly through other methods, without limitation.
[0060] In some embodiments of this specification, the second preset proof circuit includes a second circuit constraint and a second proof key;
[0061] The second circuit constraint is used to convert the division operation in the process of judging that the ratio of two numerical values is within the second preset range into a multiplication operation through mathematical equivalent transformation, obtain an equivalent judgment process converted into a multiplication operation, and convert the equivalent judgment process into a first binary bit-by-bit comparison calculation through Boolean constraints, and convert the first binary bit-by-bit comparison calculation into a second mathematical constraint equation set;
[0062] The second proof key is used to convert the second mathematical constraint equation set into a zero-knowledge proof.
[0063] In the process of generating a zero-knowledge proof, a division operation is much more expensive than a multiplication operation. Therefore, in order to further improve the execution efficiency of the circuit and avoid expensive division operations, in the implementation of this specification, when setting the second circuit constraint of the second preset proof circuit, the division operation in the process of judging that the ratio of two numerical values is within the second preset range is converted into a multiplication operation, obtaining an equivalent judgment process converted into a multiplication operation. For example, D / I < 0.5 can be converted into 2D < I. At the same time, in some embodiments, in order to meet the calculation scale of credit investigation data, when converting the division operation in the process of judging that the ratio of two numerical values is within the second preset range into a multiplication operation, the decimal numbers therein can be converted into integers. In addition, in the embodiments of this specification, the equivalent judgment process is converted into a first binary bit-by-bit comparison calculation through Boolean constraints, further ensuring the accuracy of the comparison result.
[0064] In some embodiments of this specification, the third preset proof circuit includes a third circuit constraint and a third proof key;
[0065] The third circuit constraint is used to convert the process of judging that the judgment period within each period of multiple periods is within the third preset range into a second binary bit-by-bit comparison calculation through Boolean constraints, perform a logical AND operation on the results of the second binary bit-by-bit comparison calculations within the multiple periods, and convert the logical AND operation and the second binary bit-by-bit comparison calculation corresponding to each period into a third mathematical constraint equation set;
[0066] The third proof key is used to convert the third mathematical constraint equation set into a zero-knowledge proof.
[0067] The third circuit constraint of the third preset proof circuit transforms the process of determining whether the time limit in each of the multiple cycles falls within the third preset range into a bit-by-bit comparison calculation using Boolean constraints. This allows the determination process within each cycle to be processed in parallel, and the bit-by-bit comparison calculation further improves the accuracy of the comparison results. Simultaneously, performing a logical AND operation on the results of the bit-by-bit comparison calculation within the multiple cycles further ensures that the aforementioned time limit falls within the third preset range in each cycle.
[0068] refer to Figure 3 This diagram illustrates a flowchart of a zero-knowledge proof generation method according to an embodiment of this specification. The encrypted target credit data and target verification conditions are input into a trusted execution environment. Within the trusted execution environment, the encrypted target credit data is decrypted to obtain the plaintext target credit data. Simultaneously, based on the target verification conditions, a target preset proof circuit matching the target verification conditions is determined from multiple preset proof circuits deployed in the trusted execution environment, such as credit score range proof circuits, overdue record range proof circuits, and debt ratio range proof circuits. For example, when the target verification condition is that the credit score of the party verifying the proof is greater than 650, the corresponding target preset proof circuit matching the target verification condition is a credit score range proof circuit. After determining the target preset proof circuit, the plaintext target credit data and target verification conditions are processed through this target preset proof circuit to generate a target zero-knowledge proof of the target credit data, which is then output through the trusted execution environment.
[0069] In some embodiments of this specification, the zero-knowledge proof generation method further includes:
[0070] Identify the target verifier corresponding to the target zero-knowledge proof, and obtain multiple zero-knowledge proofs to be sent that correspond to the target verifier, in addition to the target zero-knowledge proof.
[0071] Generate the target zero-knowledge proof and the proof set of the plurality of zero-knowledge proofs to be sent;
[0072] The proof set is sent to the target verifier so that the target verifier can verify the proof set through batch processing.
[0073] Considering that in the field of credit data, the verifiers of zero-knowledge proofs are relatively concentrated—for example, when banks issue credit resources, they need to verify whether the credit scores of multiple users meet the requirements—sending each generated zero-knowledge proof to the verifier would not only increase the number of transmissions but also prevent the verifier from batch processing multiple zero-knowledge proofs. Therefore, in this embodiment, when sending the target zero-knowledge proof to the target verifier corresponding to the target zero-knowledge proof, it first obtains multiple zero-knowledge proofs to be sent corresponding to the target verifier, excluding the target zero-knowledge proof itself. Then, it generates a proof set consisting of the target zero-knowledge proof and the multiple zero-knowledge proofs to be sent, and sends this proof set to the target verifier so that the target verifier can batch verify the proof set, i.e., the verifier can process multiple zero-knowledge proofs in parallel. It should be noted that in some embodiments, the target zero-knowledge proof can also be sent directly to the target verifier after generation; this is not limited.
[0074] To accurately determine the timing of sending the proof set to the target verifier, in some embodiments of this specification, sending the proof set to the target verifier includes:
[0075] Determine the total number of zero-knowledge proofs in the set of proofs;
[0076] In response to determining that the total number is greater than a preset number, the proof set is sent to the target verifier.
[0077] It should be noted that the preset number can be set as needed and is not limited thereto. In some embodiments, the preset number can be determined based on the maximum number of parallel processes of the verifier and the generation rate of zero-knowledge proofs in the trusted execution environment.
[0078] In some embodiments of this specification, sending the proof set to the target verifier includes:
[0079] In response to determining that the generation time of any zero-knowledge proof in the proof set is greater than the preset time, the proof set is sent to the target verifier.
[0080] To improve the verifier's experience and prevent excessive waiting time for a zero-knowledge proof, the proof set can be sent directly to the target verifier when the generation time of any zero-knowledge proof in the proof set exceeds the preset time. It should be noted that the preset time can be set as needed and is not limited thereto.
[0081] In some embodiments of this specification, the zero-knowledge proof generation method further includes:
[0082] Obtain the target priority corresponding to the zero-knowledge proof of the target;
[0083] In response to determining that the target priority is greater than a preset priority, the zero-knowledge proof of the target is sent to the target verifier.
[0084] Considering that when a zero-knowledge proof of a certain credit data is of high importance, the verifier may need to obtain the zero-knowledge proof as soon as possible for verification, different zero-knowledge proofs can be assigned different priorities. Then, when it is determined that the target priority of the target zero-knowledge proof is greater than the preset priority, the target zero-knowledge proof is directly sent to the target verifier without needing to form a proof set. It should be noted that the preset priority can be set as needed and is not limited thereto.
[0085] To ensure that the verifier can accurately verify the received zero-knowledge proof, in some embodiments of this specification, the zero-knowledge proof generation method further includes:
[0086] Obtain a proof verification algorithm that matches the target preset proof circuit;
[0087] The proof verification algorithm is sent to the target verifier.
[0088] It should be noted that zero-knowledge proof technology includes a proof generation algorithm and a proof verification algorithm. The proof generation algorithm generates a zero-knowledge proof corresponding to the credit data of the proving party. This zero-knowledge proof indicates that the credit data of the proving party meets the verification conditions set for that credit data. The zero-knowledge proof can then be verified using a proof verification algorithm that matches the proof generation algorithm to determine whether the content indicated by the zero-knowledge proof is correct. In the embodiments of this specification, the proof generation algorithm is mainly implemented through a preset proof circuit. Therefore, when the preset proof circuit is generated in advance, a proof verification algorithm matching the preset proof circuit can be configured according to the proof generation algorithm implemented by the preset proof circuit. In some embodiments, the proof verification algorithms matching each preset proof circuit can be saved in a trusted execution environment in advance. Therefore, after the target zero-knowledge proof is generated, the proof verification algorithm matching the target preset proof circuit can be directly obtained from the trusted execution environment and sent to the target verifier to help the target verifier complete the verification of the target zero-knowledge proof.
[0089] In order to preserve the target credit data, in some embodiments of this specification, the zero-knowledge proof generation method further includes:
[0090] Based on the encrypted data, a notarization transaction is initiated with the blockchain system so that the blockchain system can notarize the encrypted data.
[0091] In order to store credit data on the blockchain and prevent the target credit data from being tampered with, the embodiments of this specification will initiate a storage transaction with the blockchain system based on the encrypted data of the target credit data before generating a zero-knowledge proof of the target credit data. The blockchain system will then save the encrypted data through hash calculation and other means, so that the encrypted data is immutable.
[0092] The zero-knowledge proof generation method provided in this specification first obtains the encrypted data of the target credit data of the target prover, as well as the target verification conditions corresponding to the target credit data. The encrypted data is obtained by encrypting the plaintext data of the target credit data using an encryption key. This encryption enhances the security of the target credit data during transmission, preventing leakage due to interception. After obtaining the encrypted data and the target verification conditions, the encrypted data is decrypted using the encryption key in a trusted execution environment to obtain the plaintext data of the target credit data. Because the decryption process occurs within a trusted execution environment, it prevents the plaintext data from being leaked while enabling the direct generation of zero-knowledge proofs from the plaintext data, thereby improving the generation speed of zero-knowledge proofs. Meanwhile, to further improve the generation efficiency of zero-knowledge proofs, multiple preset proof circuits are pre-deployed in the trusted execution environment. Each preset proof circuit is used to generate a zero-knowledge proof of a specific type. After obtaining the target verification condition, the target preset proof circuit corresponding to the target verification condition can be determined from the multiple preset proof circuits. The plaintext data and the target verification condition are then processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data. Since the target preset proof circuit is specifically designed for the proof type corresponding to the target verification condition, it is smaller in scale and faster in execution compared to a general circuit applicable to all proof types, thus significantly improving the generation efficiency of zero-knowledge proofs.
[0093] refer to Figure 4 Here is a flowchart of a zero-knowledge proof verification method provided in this specification. The method includes the following steps:
[0094] S402, Obtain the target zero-knowledge proof of the target credit data; the target zero-knowledge proof is generated in a trusted execution environment by processing the plaintext of the target credit data and the target verification condition corresponding to the target credit data based on the target preset proof circuit; the target preset proof circuit is a preset proof circuit corresponding to the target verification condition among multiple preset proof circuits; the plaintext is obtained by decrypting the ciphertext of the target credit data based on the encryption key in the trusted execution environment.
[0095] S404, Obtain a proof verification algorithm that matches the target preset proof circuit, and verify the target zero-knowledge proof based on the proof verification algorithm that matches the target preset proof circuit.
[0096] After receiving the zero-knowledge proof of the target credit data, the target verifier can first obtain a proof verification algorithm that matches the target preset proof circuit, and then verify the target zero-knowledge proof according to the proof verification algorithm that matches the target preset proof circuit. In some embodiments, the verification result can be pass or fail, which is not limited. It should be noted that, in the embodiments of this specification, the target zero-knowledge proof of the target credit data received by the target verifier is generated in the aforementioned trusted execution environment based on the target preset proof circuit processing the plaintext of the target credit data and the target verification conditions corresponding to the target credit data; the target preset proof circuit is a preset proof circuit corresponding to the target verification conditions among multiple preset proof circuits; the plaintext data is obtained by decrypting the ciphertext of the target credit data based on the encryption key in the trusted execution environment. The specific process of generating the target zero-knowledge proof in the trusted execution environment can be referred to the specific steps of the above embodiments of the zero-knowledge proof generation method, which will not be repeated here.
[0097] In some embodiments of this specification, the zero-knowledge proof verification method further includes:
[0098] Obtain a set of proofs; the set of proofs includes the target zero-knowledge proof and multiple zero-knowledge proofs to be sent corresponding to the target verifier;
[0099] Each zero-knowledge proof in the proof set is verified by comparison processing.
[0100] In some embodiments of this specification, the total number of zero-knowledge proofs in the proof set is greater than a preset number.
[0101] In some embodiments of this specification, the generation time of any zero-knowledge proof in the proof set is less than or equal to a preset time.
[0102] In some embodiments of this specification, the plurality of preset proof circuits include: a first preset proof circuit for proving that the output result of the scoring model is within a first preset range, and / or a second preset proof circuit for proving that the ratio of two values is within a second preset range, and / or a third preset proof circuit for proving that the time limit is within a third preset range.
[0103] In some embodiments of this specification, the first preset proof circuit includes a first circuit constraint and a first proof key;
[0104] The first circuit constraint is used to transform the linear calculation process of the scoring model and the process of determining that the result of the linear calculation is within the first preset range into a first set of mathematical constraint equations;
[0105] The first proof key is used to transform the first set of mathematical constraint equations into a zero-knowledge proof.
[0106] In some embodiments of this specification, the second preset proof circuit includes a second circuit constraint and a second proof key;
[0107] The second circuit constraint is used to transform the division operation in the process of judging whether the ratio of two values is within the second preset range into a multiplication operation through mathematical equivalence transformation, thereby obtaining an equivalent judgment process that is transformed into a multiplication operation. The equivalent judgment process is then transformed into a first binary bit-by-bit comparison calculation through Boolean constraints, and the first binary bit-by-bit comparison calculation is transformed into a second set of mathematical constraint equations.
[0108] The second proof key is used to transform the second set of mathematical constraint equations into a zero-knowledge proof.
[0109] In some embodiments of this specification, the third preset proof circuit includes a third circuit constraint and a third proof key;
[0110] The third circuit constraint is used to convert the process of determining whether the judgment period in each of the multiple cycles is within the third preset range through Boolean constraints into a bit-by-bit comparison calculation of the second binary bits, and to perform a logical AND operation on the result of the bit-by-bit comparison calculation of the second binary bits in the multiple cycles, and to convert the logical AND operation and the bit-by-bit comparison calculation of the second binary bits corresponding to each cycle into a third set of mathematical constraint equations.
[0111] The third proof key is used to transform the third set of mathematical constraint equations into a zero-knowledge proof.
[0112] refer to Figure 5This specification provides an overall flowchart illustrating a zero-knowledge generation and verification process. When the proving party needs to provide a zero-knowledge proof to the verifying party, they can first send encrypted data and verification conditions to a TEE (Trusted Execution Environment). Upon receiving the encrypted data and verification conditions, the TEE first decrypts the encrypted data to obtain the plaintext data. Then, it executes a proof circuit matching the verification conditions using the plaintext data and the verification conditions. To improve the efficiency of zero-knowledge proof generation, multiple proof circuits are pre-deployed in the TEE, each handling the generation of a single type of zero-knowledge proof. After receiving the verification conditions from the proving party, the proving party can determine the matching proof circuit from among the multiple circuits based on these conditions. The zero-knowledge proof is then generated using this matching circuit and finally sent to the verifying party for verification.
[0113] Figure 6 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 6 As shown, device 600 mainly consists of a communication interface 602, a mechanism interface 604, a processor 606, and a data storage 608. These components are interconnected and communicate with each other via a method bus, network, or other connection mechanism 610. The communication interface 602 enables device 600 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 602 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 602 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 602 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 602 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.
[0114] Mechanism interface 604 includes receiving mechanism input and providing output to the mechanism. Therefore, mechanism interface 604 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. Mechanism interface 604 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, mechanism interface 604 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external mechanism input / output devices. Additionally or alternatively, device 600 may support remote access from other devices via communication interface 602 or another physical interface (not shown). Mechanism interface 604 may be configured to receive mechanism input, the position and movement of which may be indicated by an indicator or cursor described herein. Mechanism interface 604 may also be configured as a display device for rendering or displaying text fragments.
[0115] Processor 606 may contain one or more general-purpose processors and / or special-purpose processors.
[0116] Data storage 608 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 606. Data storage 608 may include removable and non-removable components.
[0117] Processor 606 is capable of executing program instructions 618 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 608 to perform the various functions described herein. Data storage 608 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 600, enable device 600 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 618 by processor 606 may result in processor 606 using data 612.
[0118] For example, program instructions 618 may include an operation method 622 (e.g., an operation method kernel, device driver, and / or other modules) installed on device 600 and one or more applications 620 (e.g., a browser, social application, or game application). Similarly, data 612 may include operation method data 416 and application data 614. Operation method data 416 is primarily accessible to operation method 622, while application data 614 is primarily accessible to one or more applications 620. Application data 614 may reside in file methods visible or hidden from the device 600 mechanism.
[0119] Application 620 can communicate with operation method 622 through one or more application programming interfaces (APIs). These APIs help application 620 read and / or write application data 614, transmit or receive information via communication interface 602, receive or display information on mechanism interface 604, etc.
[0120] In some terminology, application 620 may be simply referred to as "app". Furthermore, application 620 can be downloaded to device 600 through one or more online app stores or app markets. However, applications can also be installed on device 600 in other ways, such as through a web browser or a physical interface on device 600 (e.g., a USB port).
[0121] Please refer to Figure 7 In some embodiments, the zero-knowledge proof generation apparatus can be applied to, for example... Figure 6 The device shown is used to implement the technical solution of this specification. This zero-knowledge proof generation apparatus may include:
[0122] The first acquisition module 702 acquires the encrypted data of the target credit data of the target certifier, and the target verification conditions corresponding to the target credit data; the encrypted data is obtained by encrypting the plaintext data of the target credit data with an encryption key;
[0123] The proof generation module 704, in a trusted execution environment, decrypts the ciphertext of the data based on the encryption key to obtain the plaintext of the target credit data, and determines a target preset proof circuit corresponding to the target verification condition from multiple preset proof circuits. Based on the target preset proof circuit, it processes the plaintext of the data and the target verification condition to generate a target zero-knowledge proof of the target credit data. The target zero-knowledge proof is used to indicate whether the target credit data meets the target verification condition under the verification of a proof verification algorithm that matches the target preset proof circuit.
[0124] Please refer to Figure 8 In some embodiments, the zero-knowledge proof verification apparatus can be applied to, for example... Figure 6 The device shown is used to implement the technical solution described in this specification. This zero-knowledge proof verification apparatus may include:
[0125] The second acquisition module 802 acquires a target zero-knowledge proof of the target credit data. The target zero-knowledge proof is generated in a trusted execution environment by processing the plaintext of the target credit data and the target verification conditions corresponding to the target credit data using a target preset proof circuit. The target preset proof circuit is a preset proof circuit corresponding to the target verification conditions among multiple preset proof circuits. The plaintext is obtained by decrypting the ciphertext of the target credit data using an encryption key in the trusted execution environment.
[0126] The proof verification module 804 acquires a proof verification algorithm that matches the target preset proof circuit, and verifies the target zero-knowledge proof based on the proof verification algorithm that matches the target preset proof circuit.
[0127] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another method, or some features may be ignored or not executed.
[0128] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor executes the executable instructions to implement the steps of the zero-knowledge proof generation or verification method as described in any of the above embodiments.
[0129] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the zero-knowledge proof generation or verification method as described in any of the above embodiments.
[0130] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the zero-knowledge proof generation or verification method as described in any of the above embodiments.
[0131] What those skilled in the art will understand is:
[0132] In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.
[0133] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.
[0134] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.
[0135] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.
[0136] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.
[0137] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.
[0138] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.
Claims
1. A method for generating zero-knowledge proofs, comprising: Obtain the encrypted data of the target credit information of the target certifier, and the target verification conditions corresponding to the target credit information; The encrypted data is obtained by encrypting the plaintext of the target credit data using an encryption key; In a trusted execution environment, the encrypted data is decrypted based on the encryption key to obtain the plaintext of the target credit data. A target preset proof circuit corresponding to the target verification condition is determined from multiple preset proof circuits. The plaintext data and the target verification condition are processed based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data. The target zero-knowledge proof is used to indicate whether the target credit data meets the target verification condition under the verification of a proof verification algorithm that matches the target preset proof circuit. The trusted execution environment is pre-deployed with multiple preset proof circuits, each of which is dedicated to generating zero-knowledge proofs of a specific type. The plurality of preset proof circuits include: a first preset proof circuit for proving that the output result of the scoring model is within a first preset range, and / or a second preset proof circuit for proving that the ratio of two values is within a second preset range, and / or a third preset proof circuit for proving that the time limit is within a third preset range; The process of processing the plaintext data and the target verification conditions based on the target preset proof circuit to generate a target zero-knowledge proof of the target credit data includes: Based on the plaintext data and the target verification condition, the circuit constraints of the target preset proof circuit are executed to obtain a set of mathematical constraint equations corresponding to the plaintext data and the target verification condition; the circuit constraints of the target preset proof circuit are set by the proof type corresponding to the target verification condition. The mathematical constraint equations are transformed into the zero-knowledge proof of the target based on the proof key of the target preset proof circuit.
2. The method according to claim 1, further comprising: Identify the target verifier corresponding to the target zero-knowledge proof, and obtain multiple zero-knowledge proofs to be sent that correspond to the target verifier, in addition to the target zero-knowledge proof. Generate the target zero-knowledge proof and the proof set of the plurality of zero-knowledge proofs to be sent; The proof set is sent to the target verifier so that the target verifier can verify the proof set through batch processing.
3. The method according to claim 2, sending the proof set to the target verifier, comprising: Determine the total number of zero-knowledge proofs in the set of proofs; In response to determining that the total number is greater than a preset number, the proof set is sent to the target verifier.
4. The method according to claim 2, sending the proof set to the target verifier, comprising: In response to determining that the generation time of any zero-knowledge proof in the proof set is greater than a preset time, the proof set is sent to the target verifier.
5. The method according to claim 2, further comprising: Obtain the target priority corresponding to the zero-knowledge proof of the target; In response to determining that the target priority is greater than a preset priority, the zero-knowledge proof of the target is sent to the target verifier.
6. The method according to claim 1, wherein the first preset proof circuit includes a first circuit constraint and a first proof key; The first circuit constraint is used to transform the linear calculation process of the scoring model and the process of determining that the result of the linear calculation is within the first preset range into a first set of mathematical constraint equations; The first proof key is used to transform the first set of mathematical constraint equations into a zero-knowledge proof.
7. The method according to claim 1, wherein the second preset proof circuit includes a second circuit constraint and a second proof key; The second circuit constraint is used to transform the division operation in the process of judging whether the ratio of two values is within the second preset range into a multiplication operation through mathematical equivalence transformation, thereby obtaining an equivalent judgment process that is transformed into a multiplication operation. The equivalent judgment process is then transformed into a first binary bit-by-bit comparison calculation through Boolean constraints, and the first binary bit-by-bit comparison calculation is transformed into a second set of mathematical constraint equations. The second proof key is used to transform the second set of mathematical constraint equations into a zero-knowledge proof.
8. The method according to claim 1, wherein the third preset proof circuit includes a third circuit constraint and a third proof key; The third circuit constraint is used to convert the process of determining whether the judgment period in each of the multiple cycles is within the third preset range through Boolean constraints into a bit-by-bit comparison calculation of the second binary bits, and to perform a logical AND operation on the result of the bit-by-bit comparison calculation of the second binary bits in the multiple cycles, and to convert the logical AND operation and the bit-by-bit comparison calculation of the second binary bits corresponding to each cycle into a third set of mathematical constraint equations. The third proof key is used to transform the third set of mathematical constraint equations into a zero-knowledge proof.
9. The method according to claim 1, further comprising: Obtain a proof verification algorithm that matches the target preset proof circuit; The proof verification algorithm is sent to the target verifier.
10. The method according to claim 1, further comprising: Based on the encrypted data, a notarization transaction is initiated with the blockchain system so that the blockchain system can notarize the encrypted data.
11. A zero-knowledge proof verification method, comprising: Zero-knowledge proof for obtaining target credit data; The target zero-knowledge proof is generated in a trusted execution environment based on the target preset proof circuit processing the plaintext of the target credit data and the target verification conditions corresponding to the target credit data. The target preset proof circuit is a preset proof circuit that corresponds to the target verification condition among a plurality of preset proof circuits; The plaintext data is obtained by decrypting the ciphertext of the target credit data using an encryption key in a trusted execution environment; The trusted execution environment is pre-deployed with multiple preset proof circuits, each of which is dedicated to generating zero-knowledge proofs of a specific type. The plurality of preset proof circuits include: a first preset proof circuit for proving that the output result of the scoring model is within a first preset range, and / or a second preset proof circuit for proving that the ratio of two values is within a second preset range, and / or a third preset proof circuit for proving that the time limit is within a third preset range; Obtain a proof verification algorithm that matches the target preset proof circuit, and verify the target zero-knowledge proof based on the proof verification algorithm that matches the target preset proof circuit; The step of processing the plaintext of the target credit data and the target verification conditions corresponding to the target credit data based on the target preset verification circuit includes: Based on the plaintext data and the target verification condition, the circuit constraints of the target preset proof circuit are executed to obtain a set of mathematical constraint equations corresponding to the plaintext data and the target verification condition; the circuit constraints of the target preset proof circuit are set by the proof type corresponding to the target verification condition. The mathematical constraint equations are transformed into the zero-knowledge proof of the target based on the proof key of the target preset proof circuit.
12. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor executes the executable instructions to implement the method as described in any one of claims 1-11.
13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-11.
14. A computer program product comprising: A computer program / instruction that, when executed by a processor, implements the method as described in any one of claims 1-11.