Zero-knowledge proof generation method and apparatus, and device and storage medium

Abstract

Disclosed are a zero-knowledge proof (ZKP) generation method and apparatus, and a device and a storage medium, which belong to the field of data security. The method is applied to a management platform, wherein the management platform is used for managing infrastructure, the infrastructure comprises a plurality of computing resources, and each computing resource is used for generating ZKP corresponding to a plurality of types of proof protocols. The method comprises: receiving a proof generation request, which comprises proof protocol information and a circuit file, wherein the proof protocol information is used for indicating a target proof protocol used for generating target ZKP, the target proof protocol is one of the plurality of types of proof protocols, and the circuit file is used for indicating a computational model for generating the target ZKP; on the basis of the proof generation request, determining a target computing resource from among a plurality of computing resources; and generating the target ZKP by means of the target computing resource. By means of the method, the generation of ZKP using different ZKP protocol types can be supported.

Description

Zero-knowledge proof generation method, device, equipment and storage medium

[0001] This application claims priority to Chinese patent application number 202311554136.2, filed on November 17, 2023, with the invention name “Zero-knowledge proof generation method, device, equipment and storage medium”. This application also claims priority to Chinese patent application number 202410381649.6, filed on March 29, 2024, with the invention name “Zero-knowledge proof generation method, device, equipment and storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a method, apparatus, device, system, and storage medium for measuring network performance. The present application relates to the field of data security, and in particular to a method, apparatus, device, and storage medium for generating a zero-knowledge proof (ZKP). Background Art

[0003] A ZKP is a cryptographic protocol that allows a prover to prove to a verifier that a statement is correct, without revealing any additional information to the verifier beyond the statement itself. ZKPs are required in a variety of scenarios, such as blockchain, distributed storage, and privacy protection.

[0004] In related technologies, ZKPs can be generated using an online integrated development environment (IDE) or an online proof generation tool. This ZKP generation method involves the user selecting the ZKP protocol type through the IDE or online proof generation tool's user interface. The user then edits the circuit online or uploads a circuit file. The IDE or online proof generation tool then generates the ZKP based on the circuit or circuit file.

[0005] However, different ZKP protocol types and different scenarios have different resource requirements. When an IDE or online proof generation tool supports multiple ZKP protocols, the resources corresponding to different ZKP protocols are independent of each other, which may lead to insufficient resources or a large amount of idle resources, resulting in low resource utilization.

[0006] Summary of the Invention

[0007] The present application provides a ZKP generation method, apparatus, device, and storage medium. During the ZKP generation process, multiple proof protocols share resources, which can improve resource utilization.

[0008] In a first aspect, a ZKP generation method is provided, the method being applied to a management platform, the management platform being used to manage infrastructure, the infrastructure including multiple computing resources, each of the multiple computing resources being used to generate zero-knowledge proofs corresponding to multiple proof protocols. The method comprises: receiving a proof generation request, the proof generation request including proof protocol information and a circuit file, wherein the proof protocol information is used to indicate a target proof protocol used to generate a target zero-knowledge proof, the target proof protocol being one of the multiple protocol types, and the circuit file is used to indicate a computational model for generating the target zero-knowledge proof; determining a target computing resource from the multiple computing resources based on the proof generation request; and generating the target zero-knowledge proof using the target computing resource.

[0009] In this application, multiple proof protocols share the infrastructure, and the management platform allocates resources based on the proof generation request, that is, it determines the target computing resources from the multiple computing resources contained in the infrastructure, and generates the target ZKP through the target computing resources, which can effectively improve resource utilization.

[0010] Optionally, the proof generation request also includes configuration parameters, and determining the target computing resource from the multiple computing resources based on the proof generation request includes: generating a constraint system corresponding to the target proof protocol based on the circuit file and the configuration parameters; and determining the target computing resource from the multiple computing resources based on the target proof protocol and characteristic information of the constraint system, wherein the characteristic information of the constraint system includes at least one of the following information: the scale of the constraint system, the bit width of the elliptic curve, the type of hash function, and the type of polynomial commitment. Here, the characteristic information of the constraint system refers to information that has a significant impact on the overall computational complexity of the target computing task.

[0011] Different types of ZKP protocols may support different types of constraint systems, and different types of constraint systems require different amounts of computation in the process of generating ZKP. Therefore, it is necessary to first generate a constraint system corresponding to the type indicated by the proof protocol information; then, based on the target proof protocol and the characteristic information of the constraint system, allocate computing resources from the computing resource pool to the target computing task.

[0012] Optionally, determining the target computing resource from the multiple computing resources based on the characteristic information of the target proof protocol and the constraint system includes: determining the task complexity based on the characteristic information of the target proof protocol and the constraint system; and determining the target computing resource from the multiple computing resources based on the task complexity. The task complexity is used to measure the complexity of the computing task in the process of generating the ZKP. Generally, the higher the task complexity, the more computing resources are required, and the lower the task complexity, the fewer computing resources are required. The characteristic information of the constraint system has a greater impact on the overall computing amount of the target computing task. Therefore, this information can be used to measure the task complexity of the target computing task.

[0013] Optionally, in addition to considering the characteristic information of the constraint system that has a greater impact on the amount of calculation, other reference information can also be combined to determine the task complexity of the target computing task. Accordingly, the method also includes: obtaining reference information. The reference information includes at least one of the user level, the number of concurrent processing, the size of the generated proof, and the expected response time for generating the proof. The user level is used to indicate the level of the initiator of the proof generation request, and the number of concurrent processing is used to indicate the number of other proof generation requests that exist at the same time as the proof generation request. These reference information may also affect the amount of calculation per unit time, and therefore can also be used to determine the task complexity.

[0014] Optionally, each computing resource includes a worker thread, each of which is used to run an operator. The target proof protocol is associated with at least one operator. Worker threads can be allocated in the following manner: based on the complexity of the task, a target number of worker threads is determined from the multiple computing resources for each operator associated with the target proof protocol, where the target number is positively correlated with the task complexity. A higher task complexity indicates a greater number of operator operations that need to be performed, and therefore a higher target number is required to meet the requirements of the target computing task.

[0015] In some examples, each worker thread runs in a processor core, and each processor core runs only one worker thread, that is, each processor core is used to run one operator. In other examples, each processor core runs multiple worker threads, that is, each processor core is used to run one or more operators.

[0016] Optionally, the infrastructure also includes multiple storage resources, and the method further includes: determining the target storage resource from the multiple storage resources based on at least one of the scale of the constraint system, the size of the lookup table used in the polynomial commitment scheme, the bit width of the elliptic curve, and the algorithm of the computing operator.

[0017] During the execution of the target computing task, a large amount of data will be generated and needs to be stored. The above information is closely related to the amount of data that needs to be stored during the execution of the computing task. Therefore, the target storage resources can be determined based on this information to store this data.

[0018] Optionally, the proof generation request further includes first-category parameters used to convert the circuit file into a quadratic arithmetic program (QAP). The method further includes verifying the circuit file and / or the first-category parameters based on the proof protocol information. After receiving the proof generation request, at least a portion of the proof generation request is verified based on the proof protocol information to ensure the normal execution of the subsequent ZKP generation process.

[0019] Optionally, the proof generation request also includes mode information, where the mode information is used to indicate that the target ZKP mode is a recursive mode; generating the ZKP using the target computing resource includes: obtaining a historical ZKP; and generating the target ZKP using the target computing resource based on the historical ZKP. When the target ZKP mode is a recursive mode, it is necessary to first obtain the historical ZKP and then generate the target ZKP based on the historical ZKP. In other words, this application can support both non-recursive and recursive ZKP modes.

[0020] Optionally, the proof generation request also includes proof index information of the historical ZKP; and obtaining the historical ZKP includes: obtaining the historical ZKP from a cloud server based on the proof index information. The historical ZKP is stored on the cloud server, and when needed, the historical ZKP is obtained using the proof index information for recursive proof.

[0021] In a second aspect, a ZKP generation device is provided, which has the functionality to implement the method described in the first aspect or any optional embodiment of the first aspect. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functionality.

[0022] In a third aspect, a computing device cluster is provided, which includes at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method in the first aspect above.

[0023] Optionally, there are one or more processors, and the processor is a multi-core processor, and there are one or more memories.

[0024] Optionally, the memory may be integrated with the processor, or the memory may be provided separately from the processor.

[0025] In the specific implementation process, the memory can be a non-transitory memory, such as a read-only memory (ROM), which can be integrated on the same chip as the processor or be set on different chips. This application does not limit the type of memory and the setting method of the memory and the processor.

[0026] In a fourth aspect, a computer-readable storage medium is provided, wherein the storage medium stores at least one instruction, and the instruction is loaded and executed by a computing device cluster to enable the computing device cluster to implement the method in the first aspect.

[0027] In a fifth aspect, a computer program (product) is provided, which includes: computer program code. When the computer program code is executed by a computing device cluster, the computing device cluster executes the method in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] FIG1 is a schematic diagram of an application scenario of an embodiment of the present application;

[0029] FIG2 is a schematic diagram of a flow chart of a ZKP generation method provided in an embodiment of the present application;

[0030] FIG3 is a schematic diagram of the component architecture of a ZKP generation device provided in an embodiment of the present application;

[0031] FIG4 is a schematic diagram of a detailed process of a ZKP generation method provided in an embodiment of the present application;

[0032] FIG5 is a schematic structural diagram of a ZKP generation device provided in an embodiment of the present application;

[0033] FIG6 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0034] FIG7 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0035] FIG8 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0037] ZKP has three characteristics: completeness, soundness, and zero-knowledge.

[0038] ZKP has a wide range of applications, including but not limited to the following:

[0039] Blockchain systems: ZKP-based rollup solutions can effectively improve the throughput and performance of the entire Ethereum system while maintaining decentralization and security. Ethereum is the de facto standard for the underlying infrastructure of the decentralized internet (web3) running on blockchain technology and boasts the largest number of users, developers, and projects. However, Ethereum faces the limitations of the blockchain trinity (scalability, security, and decentralization), resulting in extremely low throughput and performance.

[0040] Distributed storage: ZKP can prove that files are stored correctly without revealing the file contents.

[0041] Privacy protection: ZKP can complete identity authentication while protecting sensitive information.

[0042] Security: ZKP can prove possession of a secret (such as a key) without revealing the secret itself.

[0043] Artificial intelligence (AI): ZKPs can keep the AI ​​model training process confidential while proving that the model has achieved a certain level of accuracy.

[0044] In related technologies, when generating ZKP, the resources available to different ZKP protocol types are pre-divided and independent of each other, which may lead to low resource utilization. To this end, this application proposes a ZKP generation method that supports multiple protocols.

[0045] Figure 1 is a schematic diagram of an application scenario of a ZKP generation method provided in an embodiment of the present application. As shown in Figure 1, a management platform is used to manage infrastructure.

[0046] The infrastructure includes multiple computing resources, which together form a computing resource pool. Each computing resource is used to generate ZKPs corresponding to multiple proof protocols, meaning that they are shared by multiple proof protocols. Here, shared means that there is no fixed binding between the computing resources in the computing resource pool and the type of ZKP protocol. For example, a computing resource can be used to generate a ZKP corresponding to one ZKP protocol in one time period and a ZKP corresponding to another ZKP protocol in another time period. The management platform can flexibly schedule computing resources to generate ZKPs for different proof protocols.

[0047] Optionally, the computing resources include one or more of a processor core, a thread running in a processor core, or a virtual machine.

[0048] Optionally, multiple proof protocols can be selected from the following protocol types: halo2, groth16, plonk, STARK, and supernova, etc.

[0049] Optionally, the infrastructure also includes multiple storage resources, which can form a storage resource pool. Each storage resource is used to store various data generated during the ZKP generation process. The storage resource can be storage space in a memory or other storage device.

[0050] FIG2 is a flow chart of a ZKP generation method provided in an embodiment of the present application. As shown in FIG2 , the ZKP generation method includes:

[0051] 11: Receive the certificate generation request.

[0052] The proof generation request includes proof protocol information, where the proof protocol information is used to indicate a target proof protocol used to generate a target ZKP, and the target proof protocol is one of the aforementioned multiple protocol types.

[0053] Optionally, the proof protocol information can be a number corresponding to the type of ZKP protocol. Different ZKP protocol types have different corresponding numbers. For example, the numbers corresponding to the four types of halo2, groth16, plonk, and supernova are 1, 2, 3, and 4, respectively. It should be noted that the number of protocol types and the relationship between protocol types and numbers are only examples and can be set according to actual needs. The proof protocol information can also be other identifiers, as long as they can uniquely indicate the corresponding ZKP protocol.

[0054] The proof generation request also includes a circuit file, which is used to indicate the computational model for generating the target ZKP.

[0055] Among them, the circuit file is used to describe the circuit. The circuit file contains a Turing-complete business description and can implement any business logic. In the embodiment of the present application, the circuit refers to a logic program consisting of input, circuit gates (also known as logic gates), and outputs, which is used to describe and encode computing tasks. Optionally, the circuit file can be a JavaScript object notation (JSON) file, etc.

[0056] Optionally, the proof generation request also includes configuration parameters. The configuration parameters include at least first-category parameters used to perform a quadratic arithmetic program (QAP) transformation on the constraint system. For example, the first-category parameters include at least one of an elliptic curve type, a hash function type, and a polynomial commitment type. Optionally, types of elliptic curves include but are not limited to BN (Barreto-Naehrig) 254 curve, BN-381 curve, BN-512 curve, BLS (Barreto-Lynn-Scott) 12-381 curve, etc.; types of hash functions include but are not limited to Poseidon, Minimal Multiplicative Complexity (MiMC), Neptune, secure hash algorithm (SHA) 384 and SHA256, etc.; types of polynomial commitments include but are not limited to IPA (based on discrete log group), FRI (based on hash function), KZG (based on pairing group) and DARKS (based on unknown order group), etc.

[0057] The content of the first-category parameters depends on the protocol type. Different protocol types require different first-category parameters. For example, the polynomial commitment type for the zksTARKs protocol is FRI, the polynomial commitment type for the plonk protocol is KZG, the polynomial commitment type for the halo2 protocol is IPA, and the polynomial commitment type for the supersonic protocol is DARK.

[0058] Optionally, the configuration parameters further include a second type of parameters, the second type of parameters including mode information, the mode information being used to indicate a ZKP mode. The ZKP mode includes a recursive mode and a non-recursive mode.

[0059] Optionally, the second type of parameters also includes proof index information of the historical ZKP, which is used to indicate the historical ZKP required for the recursive ZKP. In some examples, when the mode information indicates that the ZKP mode is a recursive mode, the second type of parameters also includes the proof index information of the historical ZKP; and when the mode information indicates that the ZKP mode is a non-recursive mode, the second type of parameters does not include the proof index information of the historical ZKP. Exemplarily, the proof index information of the historical ZKP includes the identity (ID) of the historical ZKP. The proof index information of the historical ZKP is generated at the same time as the historical ZKP is generated, and can uniquely indicate an existing ZKP.

[0060] Optionally, the second category of parameters further includes at least one of the following information: user level, size of the generated certificate, and expected response time for generating the certificate. The user level indicates the level of the initiator of the certificate generation request. The user level, size of the generated certificate, and expected response time for generating the certificate are related to user requirements.

[0061] Optionally, the proof protocol information, circuit file, and configuration parameters are sent by a user, and the user may be any component and / or role that has computing requirements for ZKP, including but not limited to a ZK virtual machine (ZK VM), a ZK prover, etc.

[0062] Optionally, users can send a proof generation request by calling a protocol request interface. The cloud server then receives the proof generation request through the protocol request interface. This protocol request interface is an application programming interface (API). Calling the protocol request interface to send proof protocol information and task information is convenient.

[0063] For example, the protocol request interface is as follows:

[0064] "circuit" represents the circuit file, "params" represents configuration parameters, and "protocol" represents the proof protocol information. "circuit":"base64String" indicates that the circuit file is encoded as a base64 string; "protocol":"halo2 / groth16 / plonk / supernova" indicates the protocol type, supporting multiple protocols such as halo2, groth16, plonk, and supernova.

[0065] In this example, the content of the proof generation request can be transmitted simultaneously by calling the protocol request interface once. In other examples, the user can transmit the content of the proof generation request by calling the protocol interface multiple times.

[0066] In one possible implementation, a user purchases a cloud server and deploys software on it to create a service. The user who purchased the cloud server can generate a ZKP by calling the service through an API.

[0067] In another possible implementation, users generate ZKPs using a serverless API. In a serverless approach, users can purchase API calls on demand without having to purchase a server.

[0068] 12: Generate a constraint system corresponding to the target proof protocol based on the circuit file and configuration parameters.

[0069] Optionally, the constraint system may be a rank-1 constraint system (R1CS) or a plonkish constraint system, etc. By compiling the circuit file, the corresponding constraint system may be obtained.

[0070] In RICS, every variable is first-order. RICS variables can be divided into two types: public variables (public inputs) and private variables (aux inputs). Therefore, the total number of variables in RICS is the sum of the public and private variables. Depending on the logic circuit, each variable can have different values, which are called constraints. In other words, variables and constraints (assignments) are the two determining factors in constructing RICS.

[0071] Each ZKP protocol can support one or more constraint systems. For example, the Groth16 protocol supports R1CS. Another example is the Halo2 protocol, which supports both Plonkish and R1CS. Plonkish offers richer expressiveness and higher constraint efficiency, so in practice, the Halo2 protocol primarily supports Plonkish, but users can choose between them based on their needs.

[0072] In one possible implementation, when the target proof protocol supports multiple constraint systems, the constraint system type corresponding to the target proof protocol is determined based on a preconfigured mapping between ZKP types and constraint system types. In this mapping, each proof protocol corresponds to a constraint system type. Then, a constraint system of the corresponding type is generated. In another possible implementation, the constraint system type can be specified in the aforementioned configuration parameters.

[0073] Optionally, before step 12, the method may further include: verifying the circuit file and at least one of the first category parameters according to the target proof protocol, and after the verification is completed, generating a constraint system corresponding to the target proof protocol based on the circuit file and the first category parameters.

[0074] In some examples, the correspondence between each protocol type and the circuit format verification rule can be pre-stored. Based on the correspondence, the corresponding target circuit format verification rule is determined according to the target proof protocol, and then the circuit format is verified using the target circuit format verification rule. Each proof protocol supports one or more circuit formats. The circuit formats corresponding to different types of proof protocols may be completely different, partially the same, or completely the same. For example, proof protocol A corresponds to circuit format 1; proof protocol B corresponds to 2 circuit formats, namely circuit format 1 and circuit format 2; proof protocol C corresponds to circuit format 3; proof protocol D corresponds to 2 circuit formats, namely circuit format 1 and circuit format 2. It can be seen that the circuit formats corresponding to proof protocols A and B are partially the same, the circuit formats corresponding to proof protocols A and C are completely different, and the circuit formats corresponding to proof protocols B and D are completely the same. The circuit format verification rules can be extracted based on the circuit formats supported by the ZKP protocol type, and the embodiments of the present disclosure do not limit the content of the verification rules.

[0075] In other examples, the circuit file may be compiled by a compiler. If the circuit file can be compiled correctly, it indicates that the circuit format is correct. If the circuit file cannot be compiled correctly, it indicates that the circuit format is incorrect.

[0076] Different proof protocols correspond to different first-category parameters with different parameter formats. Here, the parameter format includes the number of parameters and parameter types. If proof protocols A and B have different parameter numbers or parameter types, then the parameter formats of the first-category parameters for proof protocols A and B are different. If proof protocols A and B have the same number of parameters and parameter types, then the parameter formats of the first-category parameters for proof protocols A and B are the same. For example, proof protocol A corresponds to two first-category parameters: elliptic curve type 1 and polynomial commitment type 1; proof protocol B corresponds to three first-category parameters: elliptic curve type 2, hash function type 2, and polynomial commitment type 2; proof protocol C corresponds to three first-category parameters: elliptic curve type 3, hash function type 3, and polynomial commitment type 3; and proof protocol D corresponds to three first-category parameters: elliptic curve type 3, hash function type 3, and polynomial commitment type 3. Proof protocols A and B have different parameter numbers, while proof protocols B and C have the same number of parameters but different parameter types. Proof protocols C and D have the same number of parameters and the same parameter types.

[0077] The correspondence between various proof protocols and parameter formats can be pre-stored. Based on the correspondence, the corresponding target parameter format is determined according to the target proof protocol, and then the target parameter format is used to verify the format of the first type of parameters.

[0078] 13: Determine a target computing resource from multiple computing resources based on the target proof protocol and characteristic information of the constraint system.

[0079] In some examples, computing resources include processor cores. Each processor core is used to compute a type of operator, and each operator corresponds to multiple processor cores. Below, the processor core is described as a central processing unit (CPU) core.

[0080] Exemplarily, multiple CPU cores each run a worker thread, that is, each CPU core runs a worker thread, and each worker thread corresponds to an operator operation. These multiple worker threads constitute a worker pool. The worker threads in the worker pool are divided into at least two categories of worker threads, and each category of worker threads includes multiple worker threads. Each category of worker thread corresponds to an operator operation, and the types of operator operations corresponding to different categories of worker threads are different. For example, the worker pool includes two types of woker threads, namely, multiple scalar multiplication (MSM) worker threads and number theoretic transform / inverse theoretic transform (NTT / INTT) worker threads. The MSM worker thread is used to perform MSM operations, and the NTT / INTT worker thread is used to perform NTT / INTT inverse transform operations. The embodiment of the present application supports worker pools of MSM and NTT operators, and can complete computing tasks of a specified scale independently of the ZKP algorithm.

[0081] It should be noted that the MSM and NTT operators are the two operator operations currently required by the ZKP protocol. Therefore, the embodiments of this application use these two operators as examples for illustration. If subsequent ZKP protocols involve other operator operations, the types of worker threads in the worker pool will also increase accordingly.

[0082] In this embodiment, each processor core runs a worker thread. Therefore, computing resources can be allocated per processor core or per worker thread, i.e., computing resources include processor cores and / or worker threads. In other embodiments, at least some processor cores can run multiple worker threads, each of which runs a different operator. In this case, computing resources can be allocated per worker thread, i.e., computing resources include worker threads.

[0083] In an embodiment of the present application, in addition to the worker pool, a prover pool is also pre-configured in the management platform. The prover pool includes multiple prover threads, each of which corresponds to a ZKP protocol, and different prover threads correspond to different ZKP protocol types. Each prover thread is used to schedule worker threads for one or more computing tasks related to the corresponding ZKP protocol. In this way, it is possible to support the parallel execution of prover threads corresponding to multiple protocols. For example, assuming that two computing tasks are received at the same time, and the type of ZKP protocol corresponding to these two computing tasks is protocol A, the prover thread supporting protocol A schedules worker threads for these two computing tasks, that is, allocates CPU cores.

[0084] The prover pool supports expansion and updates, enabling rapid release of new community algorithm libraries, support for new prover threads, and optimization and update of existing prover threads, thus adapting to the needs of various application scenarios. Therefore, the method may also include: updating the prover pool according to the operation instructions, including deleting prover threads in the prover pool; adding new prover threads to the prover pool, etc.

[0085] The following is an illustrative description of how to determine the target computing resources and the target storage resources.

[0086] CPU core:

[0087] In some examples, the following two steps can be used to allocate CPU cores:

[0088] The first step is to determine the task complexity of the target computing task based on the characteristic information of the constraint system and the target proof protocol. The second step is to determine the number of CPU cores used to generate the target ZKP based on the task complexity. Task complexity measures the computational effort of the target computing task. Higher task complexity indicates a greater computational effort, while lower task complexity indicates a smaller computational effort. The number of CPU cores allocated to the target computing task is positively correlated with the task complexity of the target computing task. Specifically, higher task complexity results in a greater number of CPU cores allocated to the target computing task; conversely, lower task complexity results in a smaller number of CPU cores allocated to the target computing task.

[0089] Optionally, in this first step, the characteristic information of the constraint system includes at least one of the following: the size of the constraint system, the bit width of the elliptic curve, the type of hash function, and the type of polynomial commitment. This information significantly impacts the overall computational complexity of the target computing task, and is therefore used to measure the task complexity of the target computing task.

[0090] The scale of a constraint system can be expressed as the number of circuit gates it contains. For example, a constraint system contains 2^23 power circuit gates. The larger the number of circuit gates, the larger the scale of the constraint system; the smaller the number of circuit gates, the smaller the scale of the constraint system. The scale of a constraint system is positively correlated with task complexity: a larger constraint system has a higher task complexity, while a smaller constraint system has a lower task complexity.

[0091] The bit width of an elliptic curve corresponds to its type, and each type of elliptic curve has a fixed bit width. For example, the bit width of BN254 is 254 bits, and the bit width of BLS12-381 is 381 bits. The bit width of an elliptic curve is positively correlated with the complexity of the task: the larger the bit width of the elliptic curve, the higher the task complexity; the smaller the bit width of the elliptic curve, the lower the task complexity.

[0092] Each hash function, when converted into a circuit, corresponds to a different gate size. For example, it may contain a different number of multiplication gates. The more multiplication gates, the higher the computational complexity, and therefore the higher the task complexity. For example, using the common Poseidon and SHA256 as examples, the computational complexity of Poseidon for zero-knowledge proofs is lower than that of SHA256.

[0093] Different polynomial commitment types have different computational complexities during ZKP generation. Higher computational complexity means longer proof generation time. Therefore, by testing the proof generation time corresponding to different polynomial commitments, we can determine the impact of different polynomial commitment types on computational complexity. For example, the proof generation time for KZG, IPA, and DARK is constant, while the proof generation time for FRI increases exponentially with the polynomial series. Therefore, the task complexity corresponding to KZG, IPA, and DARK is lower than that of FRI.

[0094] In addition to the characteristic information of the constraint system, the following reference information may affect the computational effort per unit time of the target computing task, such as user level, number of concurrent processes, size of the generated proof, and expected response time for proof generation. The user level indicates the level of the initiator of the proof generation request. A higher user level means that the user has certain priority access to computing resources, thereby ensuring service reliability and stability. The number of concurrent processes indicates the number of other proof generation requests concurrently with the proof generation request. A high number of concurrent processes may limit the amount of resources allocated to each user. A larger proof size indicates a higher security level desired by the user for the generated proof. A shorter expected response time for proof generation indicates a faster ZKP proof generation time. Therefore, this information can also be combined to determine task complexity.

[0095] If the task complexity needs to be calculated based on reference information, the method also includes obtaining the reference information. The user level, the size of the generated certificate, and the expected response time for generating the certificate can be included in the certificate generation request; the number of concurrent processes can be obtained from statistics on the management platform.

[0096] During implementation, a task complexity calculation model can be pre-established and stored. This calculation model is used to calculate task complexity. The input of this calculation model is one or more of the aforementioned information, which can be selected as needed.

[0097] In some examples, task complexity is calculated based on the following information:

[0098] Number of concurrent processing (or concurrent request users): N

[0099] The parameters for each user are as follows:

[0100] Circuit size constraints: C0, C1, …, C N-1

[0101] ZKP protocol type: P0, P1, ..., P N-1

[0102] User level: R0, R1, ..., R N-1

[0103] F i＝ f(C i ,P i ,R i ), i∈{0,N-1}

[0104] Among them, f(C i ,P i ,R i ) is the aforementioned calculation model.

[0105] In other examples, task complexity is calculated based on the following information:

[0106] Number of concurrent processing (or concurrent request users): N;

[0107] The parameters for each user are as follows:

[0108] Circuit size constraints: C0, C1, …, C N-1

[0109] ZKP protocol types: P0, P1, P2…

[0110] Hash function types: H0, H1, H2, ...

[0111] Polynomial commitment types: PC0, PC1, PC2, ...

[0112] Elliptic curves: EC0, EC1, EC2, ...

[0113] Proof size: S0, S1, S2…

[0114] User level: R0, R1, ..., R N-1

[0115] Expected response time range: T0, T1, …, T N-1

[0116] F i＝ f(C i ,P i ,H i ,PC i ,EC i ,S i ,R i ,T i ), i∈{0,N-1}

[0117] Among them, F(C i ,P i ,H i ,PC i ,EC i ,S i ,R i ,T i ) is the aforementioned calculation model.

[0118] Optionally, in the second step, based on the task complexity, a target number of processor cores is determined for each operator associated with the target proof protocol from multiple computing resources, and the target number is positively correlated with the task complexity.

[0119] In an embodiment of the present application, each ZKP protocol is associated with one or more operators, that is, in the process of generating a proof for each ZKP protocol, one or more operator operations are required. The association between various proof protocols and operator types can be pre-set. For example, halo2, groth 16, and plonk all correspond to two operator operations, MSM and NTT / INTT, while supernova corresponds to one operator operation, NTT / INTT. Since the number of processor cores corresponds to the number of worker threads, determining a target number of processor cores for each determined operator operation is equivalent to allocating a target number of worker threads to each operator. For ZKP protocols that require multiple operator operations, the total operator operation amount can be first determined based on the task complexity; then, the number of CPU cores corresponding to each operator can be determined based on the proportion of the operation amount of each operator operation in the total operator operation amount. For example, the plonk protocol supports both MSM and NTT / INTT operations. The total operator workload is first determined based on task complexity. The number of CPU cores corresponding to each operator is then determined based on the contribution of each operator workload to the total. For any protocol type, the contribution of each operator workload to the total is pre-set.

[0120] In one possible implementation, the F i Sort the concurrent computing tasks and then calculate them according to F i Allocate computing resources to computing tasks. For example, according to F i Computing resources are allocated to each computing task in order from large to small.

[0121] It should be noted that, in addition to task complexity, factors such as the number of idle resources in the computing resource pool may also be considered to allocate computing resources to the target computing task.

[0122] Storage resources:

[0123] The target storage resource is determined based on at least one of the number of circuit gates in the constraint system (ie, the size of the constraint system), the size of a lookup table used in the polynomial commitment scheme, the bit width of the elliptic curve, and the algorithm of the computation operator.

[0124] For example, the amount of computational data can be determined based on at least one of the scale of the constraint system, the size of the lookup table used in the polynomial commitment scheme, the bit width of the elliptic curve, and the algorithm of the computational operator; and then the target size of storage resources can be determined, where the target size is positively correlated with the amount of computational data.

[0125] The number of circuit gates is positively correlated with the amount of allocated memory, that is, the more circuit gates there are, the larger the storage space required; and the fewer circuit gates there are, the larger the storage space required.

[0126] A lookup table is a data structure that stores the mapping between inputs and outputs. In a lookup table, inputs and outputs correspond to the secret inputs to be hidden and the public inputs to be proven in a zero-knowledge proof, respectively. Inputs and outputs can be of any data type, such as numbers, strings, or other complex objects. In a lookup table, each input corresponds to an output, allowing for quick lookup of the corresponding output value for a given input value. The input-output mapping can be derived from pre-calculations or complex functions. By pre-calculating and storing complex calculations or function mappings in a lookup table, which serves as proof of the validity of statements in the proof, proof generation efficiency can be improved. A larger lookup table requires more data to be stored, and consequently, more storage space is required. Conversely, a smaller lookup table requires less data to be stored, and consequently, less storage space is required.

[0127] The larger the bit width of the elliptic curve, the larger the amount of data that needs to be stored, and accordingly, the larger the storage space required; and the smaller the bit width of the elliptic curve, the smaller the amount of data that needs to be stored, and accordingly, the smaller the storage space required.

[0128] Each operator operation can use a different algorithm (i.e., calculation method) to calculate the operator. For the same operator, different algorithms may generate different amounts of intermediate data. Therefore, the size of the storage resource can be determined based on the algorithm used to calculate the operator.

[0129] During the ZKP generation process, a large amount of data will be generated and needs to be stored. The above information is closely related to the amount of data that needs to be stored during the ZKP generation process. Therefore, the target storage resources can be determined based on this information.

[0130] Optionally, if the configuration parameters further include second-category parameters, and the second-category parameters further include attestation index information, then before step 13, the method further includes: obtaining a historical ZKP based on the attestation index information. Exemplarily, the attestation index information is used to indicate a generated historical ZKP, such as the ID of the historical ZKP.

[0131] In some examples, the historical ZKP and the corresponding proof index information may be stored in the cloud (eg, a cloud server). Obtaining the historical ZKP according to the proof index information includes: obtaining the historical ZKP from the cloud.

[0132] It can be seen that the method provided in the embodiment of the present application supports users to use cloud storage data (such as historical proof files and other data files, etc.) as input to generate zero-knowledge proofs, and is cost-effectively adapted to web3 distributed storage scenario services such as the interplanetary file system (IPFS).

[0133] 14: Generate the target ZKP using the target computing resources.

[0134] If the historical ZKP has been obtained based on the proof index information, then in step 14, the target ZKP needs to be generated based on the historical ZKP using the target computing resources. As can be seen, in this embodiment of the application, the prover thread supports one or more levels of recursive zero-knowledge proof generation, and the intermediate proof (i.e., the aforementioned historical ZKP) can be stored in cloud storage and used through the proof index information.

[0135] After the target ZKP is generated, the target ZKP can be returned to the user. When the target ZKP is returned to the user, the corresponding certification index information of the target ZKP can also be returned.

[0136] Optionally, if the mode information in the aforementioned second category of parameters indicates that the ZKP mode is a recursive mode, the method further includes: storing the generated target ZKP and corresponding index information, for example, storing the generated target ZKP and corresponding index information in the cloud so as to be called in the subsequent ZKP generation process, i.e., for recursive proof.

[0137] In the embodiment of the present application, the generated target ZKP and the historical ZKP may both refer to proof information, and the proof information may be in any form, such as a number.

[0138] Figure 3 is a component architecture diagram of a proof generation device provided by an embodiment of the present application. As shown in Figure 3, the device includes a verifier, an adapter, a scheduler, a prover pool and a worker pool (i.e., a multi-core CPU pool). Figure 4 is a detailed process diagram of a proof generation method provided by an embodiment of the present application. In conjunction with Figures 3 and 4, the verifier is used to implement verification of at least one of the circuit file and the first type of parameters based on the proof protocol information. The adapter is used to generate a constraint system corresponding to the target proof protocol, that is, to execute step 12. That is, through the pre-verifier and the adapter, parameter verification, circuit and back-end protocol matching verification and corresponding adaptation work are completed, and the adapter will perform different arithmetic and constraint generation on the input circuit according to the protocol type. The scheduler is used to execute step 13.

[0139] As can be seen, the embodiment of the present application implements zero-knowledge proofs that support multiple protocols and multiple modes based on an API, eliminating the need for businesses to worry about computing resources. Furthermore, the NTT and MSM operator worker pools are implemented based on multi-core CPUs (or even multi-core CPUs), shielding protocol changes and supporting the generation of proofs for multiple protocols in parallel. Furthermore, the embodiment of the present application can also be equipped with a cloud storage module to support proof query, download, and recursive proof generation. It supports an unlimited recursive proof mode and can generate zero-knowledge proofs based on multiple stored proofs, further compressing the proof size.

[0140] The embodiments of the present application are particularly applicable to the following two scenarios:

[0141] 1. It can be widely used in Web3 layer2 zkrollup scenarios. Through cloud services, it provides interfaces to components and roles that have computing requirements for zero-knowledge proofs, such as the zero-knowledge virtual machine (zkVM) and zk prover, to complete fast proof generation that is adaptable to multiple protocols.

[0142] 2. It can be applied to web3 distributed storage scenarios, helping project owners to migrate internet data centers (IDCs) to the cloud, deploying packaging, proof generation, and storage on the cloud. Storage proof generation is accomplished through interface calls.

[0143] Of course, in addition to these two scenarios, it can also be applied to any scenario that requires computing and accelerating zero-knowledge proof.

[0144] In summary, the embodiments of this application provide a proof generation method that supports multiple protocols. This allows users to focus on their business without having to worry about the zero-knowledge protocol itself. When protocols change or when they wish to use a more advanced or efficient protocol, they can adapt and switch relatively quickly. Furthermore, users do not need to worry about the high resource consumption and performance issues associated with ZKP calculations, such as slow computations.

[0145] The embodiment of the present application also provides a ZKP generation device. FIG5 is a schematic diagram of the structure of a ZKP generation device provided by the embodiment of the present application. The device is applied to the aforementioned management platform. As shown in FIG5 , the device 400 includes: a receiving module 401, a determining module 402, and a generating module 403. The receiving module 401 is used to receive a proof generation request, and the proof generation request includes proof protocol information and a circuit file, wherein the proof protocol information is used to indicate the target proof protocol used to generate the target zero-knowledge proof, and the target proof protocol is one of the multiple protocol types, and the circuit file is used to indicate the computing model for generating the target zero-knowledge proof; the determining module 402 is used to determine the target computing resource from the multiple computing resources according to the proof generation request; the generating module 403 is used to generate the target ZKP through the target computing resource.

[0146] Optionally, determination module 402 includes: a system generation submodule and a determination submodule. The system generation submodule is configured to generate a constraint system corresponding to the target proof protocol using the circuit file and the configuration parameters; and the determination submodule is configured to determine a target computing resource from the plurality of computing resources based on the target proof protocol and characteristic information of the constraint system, wherein the characteristic information of the constraint system includes at least one of the following information: the scale of the constraint system, the bit width of the elliptic curve, the type of the hash function, and the type of the polynomial commitment.

[0147] Optionally, the determination submodule is used to determine the task complexity based on the target certification protocol and the characteristic information of the constraint system; and determine the target computing resource from the multiple computing resources based on the task complexity.

[0148] Optionally, the device also includes: an acquisition module for acquiring reference information, the reference information including at least one of a user level, a number of concurrent processing, a size of the generated proof, and an expected response time for generating the proof, the user level being used to indicate the level of the initiator of the proof generation request, and the number of concurrent processing being used to indicate the number of other proof generation requests that exist simultaneously with the proof generation request; the determination submodule being used to determine the task complexity based on the target proof protocol, the characteristic information of the constraint system, and the reference information.

[0149] Optionally, each computing resource includes a worker thread, which is used to run an operator, and the target proof protocol is associated with at least one operator. The determination submodule is used to determine a target number of worker threads for each operator associated with the target proof protocol from the multiple computing resources based on the task complexity, and the target number is positively correlated with the task complexity.

[0150] Optionally, the infrastructure also includes multiple storage resources, and the device also includes: a second determination module, used to determine the target storage resource from the multiple storage resources based on at least one of the scale of the constraint system, the size of the lookup table used in the polynomial commitment scheme, the bit width of the elliptic curve, and the algorithm of the calculation operator.

[0151] Optionally, the proof generation request also includes first-category parameters, which are used to convert the circuit file into a quadratic arithmetic program QAP; the device also includes: a verification module 404, which is used to verify the circuit file and / or the first-category parameters according to the proof protocol information after receiving the proof generation request.

[0152] Optionally, the task information also includes mode information, where the mode information is used to indicate that the target ZKP mode is a recursive mode. The generation module 403 includes: an acquisition submodule for acquiring historical zero-knowledge proofs; and a proof generation submodule for generating the target zero-knowledge proof based on the historical zero-knowledge proofs using the computing resources.

[0153] The system generation submodule is used to implement the function of the adapter in Figures 3 and 4, the determination submodule is used to implement the function of the scheduler in Figures 3 and 4, and the verification module 404 is used to implement the function of the verifier in Figures 3 and 4.

[0154] The acquisition module, determination module, and generation module can all be implemented in software or hardware. For example, the implementation of the acquisition module will be described below using the acquisition module as an example. Similarly, the implementation of the determination module and generation module can refer to the implementation of the acquisition module.

[0155] As an example of a software functional unit, the module acquisition module may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the acquisition module may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0156] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0157] As an example of a hardware functional unit, the acquisition module may include at least one computing device, such as a server. Alternatively, the acquisition module may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0158] The multiple computing devices included in the acquisition module can be distributed in the same region or in different regions. The multiple computing devices included in the acquisition module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the acquisition module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0159] It should be noted that, in other embodiments, the acquisition module can be used to execute any step in the ZKP generation method, the determination module can be used to execute any step in the ZKP generation method, and the generation module can be used to execute any step in the ZKP generation method. The steps that the acquisition module, the determination module, and the generation module are responsible for implementing can be specified as needed. The full functions of the ZKP generation device are realized by respectively implementing different steps in the ZKP generation method through the acquisition module, the determination module, and the generation module.

[0160] The descriptions of the processes corresponding to the above figures have different focuses. For parts that are not described in detail in a certain process, please refer to the relevant descriptions of other processes.

[0161] This application also provides a computing device 100. As shown in FIG6 , computing device 100 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. Processor 104, memory 106, and communication interface 108 communicate with each other via bus 102. Computing device 100 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 100.

[0162] Bus 102 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG5 shows a single line, but this does not imply a single bus or type of bus. Bus 102 may include a path for transmitting information between various components of computing device 100 (e.g., memory 106, processor 104, and communication interface 108).

[0163] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0164] The memory 106 may include volatile memory, such as random access memory (RAM). The processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0165] The memory 106 stores executable program code, and the processor 104 executes the executable program code to implement the functions of the aforementioned acquisition module, determination module, and generation module, thereby implementing the ZKP generation method. In other words, the memory 106 stores instructions for executing the ZKP generation method.

[0166] The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0167] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0168] As shown in Figure 7, the computing device cluster includes at least one computing device 100. The memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the ZKP generation method.

[0169] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the ZKP generation method. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for executing the ZKP generation method.

[0170] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions, each for executing a portion of the functions of the ZKP generation apparatus. That is, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more of the acquisition module, determination module, and generation module.

[0171] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network (WAN) or a local area network (LAN), among others. FIG. 8 illustrates a possible implementation. As shown in FIG. 8 , two computing devices 100A and 100B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the functions of the acquisition module. Simultaneously, the memory 106 in the computing device 100B stores instructions for executing the functions of the determination module and the generation module.

[0172] The connection method between the computing device clusters shown in Figure 8 can be considered to be that the ZKP generation method provided in this application requires unified management of computing resources, so it is considered to entrust the functions implemented by the determination module and the generation module to the computing device 100B for execution.

[0173] It should be understood that the functions of the computing device 100A shown in FIG8 may also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 100.

[0174] Embodiments of the present application also provide a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the aforementioned ZKP generation method.

[0175] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned ZKP generation method.

[0176] In the embodiments of the present application, A and / or B indicates that there are three situations: A, B, and A and B.

[0177] The above description is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A zero - knowledge proof generation method, characterized in that, The method is applied to a management platform for managing infrastructure, where the infrastructure includes multiple computing resources, and each of the multiple computing resources is used to generate zero-knowledge proofs corresponding to multiple proof protocols. The method includes: Receiving a proof generation request, where the proof generation request includes proof protocol information and a circuit file. Among them, the proof protocol information is used to indicate the target proof protocol used to generate the target zero-knowledge proof, the target proof protocol being one of the multiple proof protocols, and the circuit file is used to indicate the computing model for generating the target zero-knowledge proof; Determining a target computing resource from the multiple computing resources according to the proof generation request; Generating the target zero-knowledge proof through the target computing resource.

2. The method according to claim 1, wherein The proof generation request further includes configuration parameters. The determining of the target computing resource from the multiple computing resources according to the proof generation request includes: Generating a constraint system corresponding to the target proof protocol according to the circuit file and the configuration parameters; Determining a target computing resource from the multiple computing resources according to the target proof protocol and the characteristic information of the constraint system, where the characteristic information of the constraint system includes at least one of the following information: the scale of the constraint system, the bit width of the elliptic curve, the type of the hash function, and the type of the polynomial commitment.

3. The method according to claim 2, wherein The determining of the target computing resource from the multiple computing resources according to the target proof protocol and the characteristic information of the constraint system includes: Determining the task complexity according to the target proof protocol and the characteristic information of the constraint system; Determining the target computing resource from the multiple computing resources according to the task complexity.

4. The method according to claim 3, characterized in that The method further includes: obtaining reference information, where the reference information includes at least one of the user level, the number of concurrent processes, the size of the generated proof, and the expected response time for generating the proof. The user level is used to indicate the level of the initiator of the proof generation request, and the number of concurrent processes is used to indicate the number of other proof generation requests existing simultaneously with the proof generation request; The determining of the task complexity according to the target proof protocol and the characteristic information of the constraint system includes: Determining the task complexity according to the target proof protocol, the characteristic information of the constraint system, and the reference information.

5. The method according to claim 3 or 4, characterized in that, Each computing resource includes a worker thread, and the worker thread is used to run an operator. The target proof protocol is associated with at least one operator. The determining of the target computing resource from the multiple computing resources according to the task complexity includes: Determining a target number of worker threads for each operator associated with the target proof protocol from the multiple computing resources according to the task complexity, where the target number is positively correlated with the task complexity.

6. The method according to any one of claims 2 to 5, characterized in that The infrastructure further includes multiple storage resources. The method further includes: Determining a target storage resource from the multiple storage resources according to at least one of the scale of the constraint system, the size of the lookup table used in the polynomial commitment scheme, the bit width of the elliptic curve, and the algorithm of the computing operator.

7. The method according to any one of claims 1 to 6, characterized in that, The proof generation request further includes a first type of parameter, which is used to convert the circuit file into a Quadratic Arithmetic Program (QAP). After receiving the proof generation request, the method further includes: Verifying the circuit file and / or the first type of parameter according to the proof protocol information.

8. The method according to any one of claims 1 to 7, characterized in that, The proof generation request further includes mode information, which is used to indicate that the mode of the target zero-knowledge proof is a recursive mode. Generating the target zero-knowledge proof by the target computing resource includes: Obtaining a historical zero-knowledge proof; Generating the target zero-knowledge proof based on the historical zero-knowledge proof by the target computing resource.

9. A zero-knowledge proof generation device, characterized in that, The device is applied to a management platform, which is used to manage infrastructure. The infrastructure includes multiple computing resources, and each computing resource in the multiple computing resources is used to generate zero-knowledge proofs corresponding to multiple proof protocols. The device includes: A receiving module, configured to receive a proof generation request, where the proof generation request includes proof protocol information and a circuit file. The proof protocol information is used to indicate a target proof protocol used to generate the target zero-knowledge proof, and the target proof protocol is one of the multiple proof protocols. The circuit file is used to indicate a computing model for generating the target zero-knowledge proof. A determining module, configured to determine a target computing resource from the multiple computing resources according to the proof generation request. A generating module, configured to generate the target zero-knowledge proof by the target computing resource.

10. The device according to claim 9, characterized in that, The proof generation request further includes configuration parameters. The determining module includes: A system generation sub-module, configured to generate a constraint system corresponding to the target proof protocol according to the circuit file and the configuration parameters. A determining sub-module, configured to determine a target computing resource from the multiple computing resources according to the target proof protocol and characteristic information of the constraint system. The characteristic information of the constraint system includes at least one of the following information: the scale of the constraint system, the bit width of the elliptic curve, the type of the hash function, and the type of the polynomial commitment.

11. The device according to claim 10, characterized in that, The determining sub-module is configured to determine the task complexity according to the target proof protocol and the characteristic information of the constraint system; and determine the target computing resource from the multiple computing resources according to the task complexity.

12. The apparatus according to claim 11, wherein The device further includes: An obtaining module, configured to obtain reference information, where the reference information includes at least one of a user level, the number of concurrent processes, the size of the generated proof, and the expected response time for generating the proof. The user level is used to indicate the level of the initiator of the proof generation request, and the number of concurrent processes is used to indicate the number of other proof generation requests existing simultaneously with the proof generation request. The determining sub-module is configured to determine the task complexity according to the target proof protocol, the characteristic information of the constraint system, and the reference information.

13. The device according to claim 11 or 12, characterized in that, Each computing resource includes a worker thread, and the worker thread is used to run an operator. The target proof protocol is associated with at least one operator. The determining sub-module is configured to determine, according to the task complexity, a target number of worker threads for each operator associated with the target proof protocol from the multiple computing resources, where the target number is positively correlated with the task complexity.

14. The device according to any one of claims 10 to 13, characterized in that The infrastructure further includes a plurality of storage resources, and the apparatus further includes: a second determining module, configured to determine target storage resources from the plurality of storage resources according to at least one of the scale of the constraint system, the size of the lookup table used in the polynomial commitment scheme, the bit width of the elliptic curve, and the algorithm of the computing operator.

15. The device according to any one of claims 9 to 14, characterized in that, The proof generation request further includes a first type of parameter, which is used to convert the circuit file into a quadratic arithmetic program (QAP). The apparatus further includes: a verification module, configured to verify the circuit file and / or the first type of parameter according to the proof protocol information after receiving the proof generation request.

16. The device according to any one of claims 9 to 15, characterized in that, The proof generation request further includes mode information, which is used to indicate that the mode of the target zero-knowledge proof is a recursive mode. The generation module includes: an obtaining sub-module, configured to obtain a historical zero-knowledge proof; a proof generation sub-module, configured to generate the target zero-knowledge proof by using the computing resources based on the historical zero-knowledge proof.

17. A cluster of computing devices, characterized in that, including at least one computing device, each computing device includes a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the zero-knowledge proof generation method according to any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that, At least one instruction is stored in the computer storage medium, and the at least one instruction is loaded and executed by the computing device cluster, so that the computing device cluster implements the zero-knowledge proof generation method according to any one of claims 1 to 8.

19. A computer program product, characterized in that, The computer program product includes: computer program code, and the computer program code is loaded and executed by the computing device cluster, so that the computing device cluster implements the zero-knowledge proof generation method according to any one of claims 1 to 8.

Images