Method for reviewing zero-knowledge-proof circuit, and computing device

Abstract

The embodiments of the present description relate to a method for reviewing a zero-knowledge-proof circuit, and a computing device. The zero-knowledge-proof circuit comprises a group of circuit constraints, wherein circuit constraints comprise a gate constraint and a lookup constraint, and variables in the circuit constraints correspond to parameters in a target model, the target model being used for performing prediction on the basis of input data, and the value of a specific variable in the group of circuit constraints being determined on the basis of the input data. The method comprises: first, converting each circuit constraint in a group of circuit constraints into a corresponding constraint solving language; then, on the basis of the constraint solving languages, solving the group of circuit constraints; when no solution that satisfies the group of circuit constraints can be found, enabling a review result to include an over-constrained vulnerability; and when one or more solutions that satisfy the group of circuit constraints are found, enabling the review result to contain an under-constrained vulnerability.

Description

Zero-knowledge proof circuit review methods and computing devices

[0001] This application claims priority to Chinese patent application filed on December 27, 2024, with application number 202411969045X and entitled "Zero-knowledge proof circuit examination method and computing device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] The embodiments in this specification belong to the field of privacy computing technology, and in particular relate to zero-knowledge proof circuit review methods and computing devices. Background Technology

[0003] Zero-knowledge proof (ZKP), as an important cryptographic technique, has been widely applied in fields such as blockchain, digital identity authentication, and privacy computing. Its core principle lies in allowing the prover to demonstrate the correctness of a proposition to the verifier without revealing any additional information. This characteristic makes it a crucial cornerstone for building trustworthy and privacy-preserving systems.

[0004] For example, in a machine learning application scenario, there are two participants: a data holder and a model holder. The data holder sends the data to be predicted to the model holder, who then uses its model to make a prediction and sends the result back to the data holder. Because the model is often privately owned by the model holder, the data user cannot directly know the specific prediction process and therefore cannot know whether the prediction result they receive was actually predicted by that model.

[0005] At this point, the model holder can act as a prover, using zero-knowledge proof techniques to demonstrate the correctness of the prediction process to the data holder, including that the correct model was used to make the correct prediction, without disclosing the details of the model or the prediction process. The data holder, as a verifier, can verify the proof provided by the model holder to ascertain the correctness of the prediction process.

[0006] However, the security of zero-knowledge proof systems heavily relies on the correct implementation of their underlying zero-knowledge proof circuits. As the foundational architecture of the entire system, vulnerabilities or defects in these circuits can lead to serious security risks. Malicious attackers could exploit these vulnerabilities to construct false proofs, thereby bypassing system verification and potentially interfering with or manipulating the system, resulting in severe consequences such as financial losses and data tampering.

[0007] Currently, the verification of the correctness of zero-knowledge proof circuits mainly relies on manual review by professionals. This not only requires a large amount of manpower but is also susceptible to human negligence, lack of experience, or misjudgment, leading to incorrect judgments or the omission of certain potential risks.

[0008] Therefore, a method is needed to automate the review of zero-knowledge proof circuits, thereby improving the efficiency and accuracy of the review. Summary of the Invention

[0009] The purpose of this specification is to provide a method and computing device for examining zero-knowledge proof circuits, with the aim of automating the examination of zero-knowledge proof circuits.

[0010] This specification provides a method for examining zero-knowledge proof circuits, wherein the zero-knowledge proof circuit includes a set of circuit constraints, the circuit constraints including gate constraints and lookup table constraints, and the variables in the circuit constraints correspond to the parameters in a target model; the target model is used to make predictions based on input data; the values ​​of specific variables in the set of circuit constraints are determined by the input data; the method includes:

[0011] Convert each circuit constraint in the circuit constraint group into the corresponding constraint solving language;

[0012] The circuit constraint set is solved according to the constraint solving language; when no solution can be found that satisfies the circuit constraint set, the review result is made to contain over-constraint vulnerabilities; when the number of solutions that satisfy the circuit constraint set is greater than one set, the review result is made to contain under-constraint vulnerabilities.

[0013] In some possible implementations, the target model is a tree model, and each circuit constraint in the circuit constraint group corresponds to a split node and a leaf node in the tree model.

[0014] In some possible implementations, the input data is text data.

[0015] In some possible implementations, the circuit constraint set is solved according to the constraint solving language, including:

[0016] The circuit constraint set is solved using a solver;

[0017] When the solver finds a first target solution, it determines the corresponding first target circuit constraint based on the first target solution and adds it to the circuit constraint group; the first target circuit constraint is used to ensure that each variable in the circuit constraint group is not equal to the value in the first target solution.

[0018] The solver is used to solve the updated set of circuit constraints. When the solver finds a second objective solution, the number of solutions that satisfy the set of circuit constraints is greater than one.

[0019] A second aspect of this specification provides a method for examining zero-knowledge proof circuits, wherein the zero-knowledge proof circuit includes a set of circuit constraints, the circuit constraints including gate constraints and lookup table constraints, and the method includes:

[0020] Convert each circuit constraint in the circuit constraint group into the corresponding constraint solving language;

[0021] The circuit constraint set is solved according to the constraint solving language; when no solution can be found that satisfies the circuit constraint set, the review result is made to contain over-constraint vulnerabilities; when the number of solutions that satisfy the circuit constraint set is greater than one set, the review result is made to contain under-constraint vulnerabilities.

[0022] In some possible implementations, the conversion includes:

[0023] If any first circuit constraint is a gate constraint that always holds true, then the first circuit constraint is not transformed.

[0024] In some possible implementations, the conversion includes:

[0025] When any second circuit constraint is a lookup table constraint, and the lookup table constraint is within the second value range, then the second circuit constraint is converted into a constraint solving language in the form of the second value range.

[0026] In some possible implementations, the conversion includes:

[0027] When any third circuit constraint is a gate constraint, the third polynomial corresponding to the third circuit constraint is simplified, and the third circuit constraint is converted into the corresponding constraint solving language based on the simplified third polynomial.

[0028] In some possible implementations, the circuit constraint set is solved according to the constraint solving language, including:

[0029] The circuit constraint set is solved using a solver;

[0030] When the solver finds a first target solution, it determines the corresponding first target circuit constraint based on the first target solution and adds it to the circuit constraint group; the first target circuit constraint is used to ensure that each variable in the circuit constraint group is not equal to the value in the first target solution.

[0031] The solver is used to solve the updated set of circuit constraints. When the solver finds a second objective solution, the number of solutions that satisfy the set of circuit constraints is greater than one.

[0032] In some possible implementations, it also includes:

[0033] When any fourth circuit constraint in the circuit constraint group is a gate constraint, determine whether the fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial; if so, let the review result include unused gate vulnerabilities.

[0034] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the method further includes:

[0035] For any target column in the circuit table, if the target column does not appear in any circuit constraint, then make the review result include unused column vulnerabilities.

[0036] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the method further includes:

[0037] For any target cell in the circuit table, if the target cell does not appear in any of the non-zero gate constraints and does not appear in any of the lookup table constraints, then let the inspection result contain unconstrained cell vulnerabilities.

[0038] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods described in the first or second aspect.

[0039] A fourth aspect of this specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the first or second aspect.

[0040] This specification provides a computer program product in a fifth aspect, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first or second aspect.

[0041] The zero-knowledge proof circuit review method and computing device proposed in the embodiments of this specification involve converting a set of circuit constraints into a circuit constraint language and solving the set of circuit constraints according to the circuit constraint language. If no solution is found, an over-constrained vulnerability is reported; if more than one solution is found, an under-constrained vulnerability is reported. By automating the solution of the circuit constraint set, potential vulnerabilities in zero-knowledge proof circuits can be reviewed more quickly and accurately, thereby reducing security risks. Attached Figure Description

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

[0043] Figure 1 is a flowchart illustrating a zero-knowledge proof circuit review method in one embodiment of this specification;

[0044] Figure 2 is a flowchart of a zero-knowledge proof circuit review method in one embodiment of this specification;

[0045] Figure 3 is a schematic block diagram of a zero-knowledge proof circuit review device according to one embodiment of this specification. Detailed Implementation

[0046] 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.

[0047] As mentioned earlier, a prover can use zero-knowledge proof techniques to prove the correctness of a proposition they claim without revealing additional information to a verifier. In this process, the prover needs to convert the proposition into a corresponding zero-knowledge proof circuit (hereinafter referred to as "circuit"), and then generate a zero-knowledge proof of the proposition's correctness based on the circuit.

[0048] A zero-knowledge proof circuit includes several variables and several circuit constraints on these variables. Circuit constraints include gate constraints and lookup table constraints. Gate constraints contain polynomials that constrain the values ​​of the corresponding variables within the polynomial. A gate constraint is said to be satisfied if the polynomial's value is zero. Lookup table constraints restrict the range of values ​​for a variable in the circuit; a lookup table constraint is satisfied if the variable's value falls within the range of the lookup table constraint.

[0049] When a prover transforms the proposition to be proved into a zero-knowledge proof circuit, the circuit may contain vulnerabilities, posing security risks. Therefore, before using this circuit to generate a zero-knowledge proof, its correctness must be reviewed to check for any circuit defects. Only after these defects have been discovered and repaired can the repaired circuit be used to generate a zero-knowledge proof.

[0050] Figure 1 is a flowchart illustrating a zero-knowledge proof circuit examination method in one embodiment of this specification. Here, "over-constrained" means that there is no set of variable values ​​that can satisfy all constraints in the circuit. "Under-constrained" means that one or more variables in the circuit can take more than two different values ​​and still satisfy all constraints in the circuit. "Correctly constrained" means that to satisfy all gate constraints and lookup table constraints in the circuit, the variables in the circuit have exactly one possible value.

[0051] In the example in Figure 1, to check for over-constraint / under-constraint vulnerabilities in the zero-knowledge proof circuit, the circuit constraint set needs to be solved. First, the circuit constraint set is converted into a corresponding constraint solving language, such as SMT-LIB, and then solved using this language. If the circuit constraint set has no solution, an over-constraint vulnerability is reported in the review results. If the circuit constraint set has a solution, this solution is used as a new circuit constraint, ensuring that the values ​​of each variable cannot be equal to the values ​​in the solution set. The new circuit constraint is then added to the circuit constraint set, and the circuit constraint set is solved again. If there is still no solution, it means that the circuit constraint set has exactly one solution, and the circuit constraint set is correctly constrained. If there are still solutions, it means that more than one solution can satisfy the circuit constraint set, and an under-constraint vulnerability is reported in the review results.

[0052] The following describes the specific implementation steps of the above-mentioned zero-knowledge proof circuit examination method with reference to specific embodiments.

[0053] Figure 2 is a flowchart of a zero-knowledge proof circuit review method according to an embodiment of this specification. The execution subject of the method can be any platform, server, or device cluster with computing and processing capabilities. As shown in Figure 2, the zero-knowledge proof circuit includes a circuit constraint group, which includes gate constraints and lookup table constraints. The variables in the circuit constraints correspond to the parameters in the target model. The target model is used to make predictions based on input data. The values ​​of specific variables in the circuit constraint group are determined by the input data. The method includes at least: step 202, converting each circuit constraint in the circuit constraint group into a corresponding constraint solving language; step 204, solving the circuit constraint group according to the constraint solving language; when no solution satisfying the circuit constraint group can be found, the review result is made to contain over-constraint vulnerabilities; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to contain under-constraint vulnerabilities.

[0054] The target model can be a predictive model, which makes predictions based on the input data to obtain the prediction result. The circuit constraint set in the zero-knowledge proof circuit is used to generate a zero-knowledge proof that demonstrates the correctness of the above prediction process.

[0055] The circuit constraint set can be derived from the prediction process of the target model, and the variables in it correspond to the parameters in the target model. Specific variables in the circuit constraint set may include relevant variables in the input circuit, which correspond to the input parameters of the target model, and their specific values ​​are determined by the input data.

[0056] In one embodiment, the target model is a tree model. The input data to the tree model can correspond to the input circuit of a zero-knowledge proof circuit, and the prediction result can correspond to the output circuit of the zero-knowledge proof circuit. Each circuit constraint in the circuit constraint group corresponds to the splitting node (decision node) and leaf node in the tree model.

[0057] Specifically, some constraints in the circuit constraint group are gate constraints, used to constrain the structure of the tree, including the hash value of the leaf nodes; the other part of the constraints are lookup table constraints, corresponding to the threshold on the split nodes.

[0058] Tree models can be used for prediction in various scenarios. For example, in one embodiment, a tree model can be used in an anti-fraud scenario to predict whether a user and / or transaction is a risky user and / or a risky transaction. In this case, the input data may include at least one of user characteristics and transaction information, and the prediction result may be the tree model's prediction of whether the input user / transaction is risky.

[0059] In another embodiment, the input data is text data. For example, it could be information related to users and / or transactions in an anti-fraud scenario.

[0060] The specific execution process of each of the above steps is described below.

[0061] First, in step 202, each circuit constraint in the circuit constraint group is converted into a corresponding constraint solving language.

[0062] Constraint solving languages ​​are used to describe and solve logical formulas, constraint problems, or symbolic computations. Examples include the SMT-LIB (Satisfied Modulo Theory-Library) language, the language used by the z3 solver, and the languages ​​used by the CVC4 / CVC5 solvers. For instance, a set of circuit constraints in SMT-LIB language format could be:

[0063] (set-logic QF_LIA); sets the logic to a quantized free integer linear expression.

[0064] (declare-const x Int); declares an integer variable x.

[0065] (declare-const y Int); declares an integer variable y.

[0066] (declare-const z Bool); declares a Boolean variable z.

[0067] (assert(=(+xy)10)); constraint 1: x+y=10

[0068] (assert(<=y 7)); constraint 2: y<=7

[0069] (assert(=z(>x 5))); Constraint 3: z=(x>5)

[0070] (check-sat); Checks if a solution exists that satisfies all constraints.

[0071] (get-model); if a solution exists, it returns the specific variable value.

[0072] In this step, the circuit constraints are converted into corresponding constraint solving languages. This can be achieved using automated tools provided by the zero-knowledge proof framework related to the zero-knowledge proof circuit. For example, when the relevant zero-knowledge proof framework is the Halo2 framework and the constraint solving language is SMT-LIB, the automated tool used could be snarkjs.

[0073] In the above conversion process, for some circuit constraints, direct conversion results in a more complex constraint solution language, increasing space usage and slowing down the subsequent solution process. Therefore, before converting each circuit constraint, appropriate preprocessing can be performed to reduce space usage.

[0074] In one embodiment, the transformation in step 202 includes:

[0075] If any first circuit constraint is a gate constraint that always holds true, then the first circuit constraint is not transformed.

[0076] When the first circuit constraint is a gate constraint, the polynomial it contains is simplified. If the simplification result is equal to 0, it means that the constraint is a constraint that always holds true. In step 202, the first circuit constraint can be removed without conversion.

[0077] For example, if a gate constraint a1×0=0, and the polynomial a1×0 it contains becomes 0 after simplification, then the gate constraint can be removed without transformation.

[0078] In another embodiment, the conversion in step 202 includes:

[0079] When any second circuit constraint is a lookup table constraint, and the lookup table constraint is within the second value range, then the second circuit constraint is converted into a constraint solving language in the form of the second value range.

[0080] When the second constraint circuit is directly converted, each value within the second value range is converted into a gate constraint, resulting in a significant waste of space. This embodiment saves space by converting the second circuit constraint into a constraint solution language in the form of the second value range.

[0081] For example, if a lookup constraint is used to constrain the variable 'a' to a value in the range 0, 1, ..., 100, a direct conversion would result in a constraint solver language in the form: a-0 = 0 or a-1 = 0 or ... or a-100 = 0, which wastes space. According to this embodiment, the conversion is changed to a ≤ 100 and a ≥ 0, which saves more space and facilitates subsequent solving.

[0082] In yet another embodiment, the conversion in step 202 includes:

[0083] When any third circuit constraint is a gate constraint, the third polynomial corresponding to the third circuit constraint is simplified, and the third circuit constraint is converted into the corresponding constraint solving language based on the simplified third polynomial.

[0084] For example, for the gate constraint (a2+0-a3)×1=0, the polynomial on the left side can be simplified to a2-a3, and then the simplified gate constraint a2-a3=0 can be converted into the corresponding constraint solving language.

[0085] Then, returning to Figure 2, in step 204, the circuit constraint set is solved according to the constraint solving language; when no solution can be found that satisfies the circuit constraint set, the review result is made to contain over-constraint vulnerabilities; when the number of solutions that satisfy the circuit constraint set is greater than one set, the review result is made to contain under-constraint vulnerabilities.

[0086] The set of circuit constraints can be solved using a constraint solver (hereinafter referred to as "solver"). For example, when the constraint solving language is SMT-LIB, the solver used can be the CVC5 solver, the Z3 solver, etc., and there are no limitations here. The constraint solver can automatically solve for the constraints based on the input set of constraints.

[0087] When no solution that satisfies the circuit constraint group can be found, the review result is made to include an over-constraint vulnerability.

[0088] When a unique set of solutions that satisfy the circuit constraint group is found, the circuit constraint group is correctly constrained.

[0089] When the number of solutions that satisfy the circuit constraint group is greater than one set, the review result is made to include an under-constraint vulnerability.

[0090] In some embodiments, existing constraint solvers typically return results after finding one set of feasible solutions and do not find all feasible solutions. At this time, constraints can be added to the circuit constraint group to exclude the current solution, and the constraint solver is run again to attempt to find more feasible solutions.

[0091] In one embodiment, step 204 specifically includes steps 2042 to 2046.

[0092] First, in step 2042, the circuit constraint group is solved using a solver.

[0093] Then, in step 2044, when the solver finds a set of first target solutions, the corresponding first target circuit constraints are determined according to the first target solutions and added to the circuit constraint group; the first target circuit constraints are used to make each variable in the circuit constraint group not equal to the value in the first target solutions.

[0094] The arithmetic expressions in the first target circuit constraints where each variable is not equal to the value in the first target solutions are in an "or" relationship.

[0095] For example, for the circuit constraint group x + y = 10, x < y, the first target solution can be x = 1, y = 9, and the corresponding first target circuit constraint can be x!= 1 or y!= 9, where!= represents "not equal to".

[0096] In step 2046, the updated circuit constraint group is solved using a solver. When the solver finds a set of second target solutions, the number of solutions that satisfy the circuit constraint group is greater than one set.

[0097] Continuing with the previous example, the updated circuit constraint group can be x + y = 10, x < y, x!= 1 or y!= 9. After solving again, the second target solution can be x = 2, y = 8. At this time, the number of solutions that satisfy the circuit constraint group is greater than one set, and the review result of this circuit constraint group includes an under-constraint vulnerability.

[0098] If step 2046 fails to find a solution other than the first objective solution, then the circuit constraint set has one and only one solution, and the circuit constraint set is correctly constrained.

[0099] The above describes the process of reviewing over-constrained / under-constrained circuit constraint groups.

[0100] In some possible implementations, the method further includes:

[0101] Step 206: When any fourth circuit constraint in the circuit constraint group is a gate constraint, determine whether the fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial; if so, let the review result include unused gate vulnerabilities.

[0102] The following will use the Halo2 circuit as an example to describe the review process for unused gate vulnerabilities.

[0103] A Halo2 circuit can be viewed as a table, where each column represents a variable and each row represents the different values ​​of that variable. The column types in a Halo2 circuit include Fixed, Selector, and Advice columns. The values ​​in the Fixed and Selector columns are fixed and do not change depending on the instance; they are visible to both the prover and the verifier. The difference is that the values ​​in the Fixed column can be any value, while the values ​​in the Selector column are Boolean values ​​of 0 or 1. The values ​​in the Advice column are variable and are only visible to the prover.

[0104] For example, a zero-knowledge proof circuit for a certain Halo2 framework can be shown in Table 1:

[0105] Table 1: Circuit Example 1

[0106] The circuit described above includes two Advice columns, one Fixed column, and one Selector column. The second row represents the values ​​of the variables in each column within their respective instances. For this circuit, the fourth polynomial corresponding to the fourth circuit constraint could be, for example, xs(a1-a2). If for each row, the fixed value is either x=0 or s=0, then this fourth polynomial is actually a constant-zero polynomial. The values ​​of the variables in the two Advice columns do not affect this fourth circuit constraint. In other words, the fourth circuit constraint cannot constrain the variables in the Advice1 and Advice2 columns. However, during code execution, this gate constraint is still checked for each row of the circuit table, leading to code redundancy and increased runtime.

[0107] Therefore, for constant-zero polynomials, unused gate vulnerabilities are reported in the review results. Optionally, the review results may also include the position of the fourth circuit constraint within the circuit constraint group.

[0108] A formal examination can be performed on the polynomials in each gate constraint to determine whether they are constant zero polynomials.

[0109] In one embodiment, step 206 specifically includes:

[0110] Determine the type of each term in the fourth polynomial; the type includes variable, non-zero constant, and zero.

[0111] The fourth polynomial is simplified by merging according to the type of each term; when the type of the simplification result is zero, the fourth polynomial is determined to be a constant zero polynomial.

[0112] The fourth polynomial can be simplified by combining terms based on the rules of operation and the order of operations. For example, the result of multiplying a zero type by a variable type is of type zero, the result of adding a variable type by a non-zero constant type is of type variable, and so on.

[0113] The algorithm can be shown in Table 2:

[0114] Table 2: Operation Rules

[0115] For example, for the polynomial xs(a1-a2) in the previous example, when x is a non-zero constant, s is zero, and a1 and a2 are variables, the simplification process for this polynomial is as follows:

[0116] xs(a1-a2) → non-zero constant × zero × (variable - variable) → zero × (variable - variable) → zero × variable → zero

[0117] Therefore, this polynomial is a zero polynomial.

[0118] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the method further includes:

[0119] Step 208: For any target column in the circuit table, if the target column does not appear in any circuit constraint, then make the review result include unused column vulnerabilities.

[0120] By traversing each circuit constraint and determining whether each constraint includes a target column, it can be determined whether the target column is an unused column, and the unused column vulnerability can be reported in the review results. Optionally, the review results can also include the position of the target column in the circuit table.

[0121] You can iterate through each column in the circuit table and check if they appear in at least one circuit constraint to identify all unused columns.

[0122] The following description uses the Halo2 circuit as an example to illustrate the review process for unused column vulnerabilities.

[0123] For example, a zero-knowledge proof circuit for a certain Halo2 framework can be shown in Table 3:

[0124] Table 3: Circuit Example 2

[0125] The circuit described above includes three Advice columns, one Fixed column, and one Selector column. The second row and subsequent rows contain the values ​​of the column variables in different instances. The circuit constraint group included in the above circuit can include two gate constraints, XSA1 and S(A1-A2), where A1 represents the variable in the Advice1 column, A2 represents the variable in the Advice2 column, X represents the variable in the Fixed column, and S represents the variable in the Selector column. It can be observed that the variable in the Advice3 column does not appear in any constraint, therefore, the Advice3 column can be determined to be an unused column.

[0126] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the method further includes:

[0127] Step 210: For any target cell in the circuit table, if the target cell does not appear in any non-zero gate constraint and does not appear in any lookup constraint, then let the review result include unconstrained cell vulnerabilities.

[0128] You can iterate through each cell in each column of the table and check if it appears in at least one non-zero gate constraint or a lookup constraint. If neither is true, the cell is an unconstrained cell, and the unconstrained cell vulnerability is reported in the review results. Optionally, the review results may also include the location of the target cell in the circuit table.

[0129] The method for determining non-zero gate constraints can be referred to in step 206, and will not be repeated here.

[0130] The following description uses the Halo2 circuit as an example to illustrate the review process for unconstrained lattice vulnerabilities, still employing zero-knowledge proof circuitry.

[0131] For example, a zero-knowledge proof circuit for a certain Halo2 framework can be shown in Table 4:

[0132] Table 4: Circuit Example 3

[0133] The circuit described above includes three Advice columns, one Fixed column, and one Selector column. The second row and subsequent rows contain the values ​​of the column variables in different instances. The circuit constraint group included in the circuit can include two gate constraints: XA1-A2 and S(A1-A2-A3), where A1 represents the variable in the Advice1 column, A2 represents the variable in the Advice2 column, A3 represents the variable in the Advice3 column, X represents the variable in the Fixed column, and S represents the variable in the Selector column. In this case, if the value of s2 in the circuit table is 0, then the value of S(A1-A2-A3) in this row is zero. Also, XA1-A2 does not include the Advice3 column, so a... 23 It does not appear in any non-zero gate constraints. At this point, a 23 It is an unconstrained cell. That is, a 23 No matter what value is chosen for this cell, it will not affect the results of the two gate constraints.

[0134] Based on the above steps, this embodiment of the specification automatically converts circuit constraints into a constraint solving language and solves the circuit constraints to check for under-constraint / over-constraint vulnerabilities. During the conversion process, formal checks are added to remove some constant-zero expressions and simplify constraints, reducing the number of constraints in the final output. Furthermore, lookup table constraints are evaluated; for range constraints within lookup table constraints, numerous equality checks are converted into size checks, significantly reducing the output.

[0135] In the review of vulnerabilities involving unused gates, unused columns, and unconstrained cells, the accuracy of the review is increased and the false positives and false negatives are reduced by simultaneously checking gate constraints and lookup table constraints.

[0136] Based on the same inventive concept, embodiments of this specification also provide a method for examining zero-knowledge proof circuits, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraints including gate constraints and lookup table constraints, and the method includes:

[0137] Convert each circuit constraint in the circuit constraint group into the corresponding constraint solving language;

[0138] The circuit constraint set is solved according to the constraint solving language; when no solution can be found that satisfies the circuit constraint set, the review result is made to contain over-constraint vulnerabilities; when the number of solutions that satisfy the circuit constraint set is greater than one set, the review result is made to contain under-constraint vulnerabilities.

[0139] In one embodiment, the conversion includes:

[0140] If any first circuit constraint is a gate constraint that always holds true, then the first circuit constraint is not transformed.

[0141] In one embodiment, the conversion includes:

[0142] When any second circuit constraint is a lookup table constraint, and the lookup table constraint is within the second value range, then the second circuit constraint is converted into a constraint solving language in the form of the second value range.

[0143] In one embodiment, the conversion includes:

[0144] When any third circuit constraint is a gate constraint, the third polynomial corresponding to the third circuit constraint is simplified, and the third circuit constraint is converted into the corresponding constraint solving language based on the simplified third polynomial.

[0145] In one embodiment, solving the circuit constraint set according to the constraint solving language includes:

[0146] The circuit constraint set is solved using a solver;

[0147] When the solver finds a first target solution, it determines the corresponding first target circuit constraint based on the first target solution and adds it to the circuit constraint group; the first target circuit constraint is used to ensure that each variable in the circuit constraint group is not equal to the value in the first target solution.

[0148] The solver is used to solve the updated set of circuit constraints. When the solver finds a second objective solution, the number of solutions that satisfy the set of circuit constraints is greater than one.

[0149] In some possible implementations, the method further includes:

[0150] When any fourth circuit constraint in the circuit constraint group is a gate constraint, determine whether the fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial; if so, let the review result include unused gate vulnerabilities.

[0151] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the method further includes:

[0152] For any target column in the circuit table, if the target column does not appear in any circuit constraint, then make the review result include unused column vulnerabilities.

[0153] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the method further includes:

[0154] For any target cell in the circuit table, if the target cell does not appear in any of the non-zero gate constraints and does not appear in any of the lookup table constraints, then let the inspection result contain unconstrained cell vulnerabilities.

[0155] According to another embodiment, a zero-knowledge proof circuit review apparatus is also provided. Figure 3 is a schematic block diagram of a zero-knowledge proof circuit review apparatus according to an embodiment of this specification. This apparatus can be deployed in any device, platform, or device cluster with computing and processing capabilities. As shown in Figure 3, the zero-knowledge proof circuit includes a circuit constraint group, which includes gate constraints and lookup table constraints. The variables in the circuit constraints correspond to the parameters in the target model. The target model is used to make predictions based on input data. The values ​​of specific variables in the circuit constraint group are determined by the input data. The apparatus 300 includes:

[0156] The conversion unit 302 is configured to convert each circuit constraint in the circuit constraint group into a corresponding constraint solving language.

[0157] The first vulnerability determination unit 304 is configured to solve the circuit constraint group according to the constraint solving language; when no solution can be found that satisfies the circuit constraint group, the review result is made to include over-constraint vulnerabilities; when the number of solutions that satisfy the circuit constraint group is greater than one group, the review result is made to include under-constraint vulnerabilities.

[0158] In some possible implementations, the device 300 further includes:

[0159] The second vulnerability determination unit 306 is configured to determine whether the fourth polynomial corresponding to any fourth circuit constraint in the circuit constraint group is a gate constraint when the fourth circuit constraint is a constant zero polynomial; if so, the review result is made to include unused gate vulnerabilities.

[0160] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the device 300 also includes:

[0161] The third vulnerability determination unit 308 is configured to, for any target column in the circuit table, if the target column does not appear in each circuit constraint, make the review result include unused column vulnerabilities.

[0162] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; the device 300 also includes:

[0163] The fourth vulnerability determination unit 310 is configured to, for any target cell in the circuit table, if the target cell does not appear in any non-zero gate constraint and does not appear in any lookup constraint, then make the review result include an unconstrained cell vulnerability.

[0164] According to another embodiment, a computer program product is also provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in any of the above embodiments.

[0165] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in any of the above embodiments.

[0166] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0167] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0168] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0169] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover 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 limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0170] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. 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 system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0171] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0172] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0173] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0174] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0175] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0176] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0177] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0178] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0179] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0180] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for examining zero-knowledge proof circuits, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraints including gate constraints and lookup table constraints, and the variables in the circuit constraints correspond to the parameters in the target model; The target model is used to make predictions based on the input data; The values ​​of specific variables in the circuit constraint group are determined by the input data; the method includes: Convert each circuit constraint in the circuit constraint group into the corresponding constraint solving language; The circuit constraint set is solved according to the constraint solving language; when no solution can be found that satisfies the circuit constraint set, the review result is made to contain over-constraint vulnerabilities; when the number of solutions that satisfy the circuit constraint set is greater than one set, the review result is made to contain under-constraint vulnerabilities.

2. The method according to claim 1, wherein, The conversion includes: If any first circuit constraint is a gate constraint that always holds true, then the first circuit constraint is not transformed.

3. The method according to claim 1, wherein, The conversion includes: When any second circuit constraint is a lookup table constraint, and the lookup table constraint is within the second value range, then the second circuit constraint is converted into a constraint solving language in the form of the second value range.

4. The method according to claim 1, wherein, The conversion includes: When any third circuit constraint is a gate constraint, the third polynomial corresponding to the third circuit constraint is simplified, and the third circuit constraint is converted into the corresponding constraint solving language based on the simplified third polynomial.

5. The method according to claim 1, further comprising: When any fourth circuit constraint in the circuit constraint group is a gate constraint, determine whether the fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial. If so, then include unused door vulnerabilities in the review results.

6. The method according to claim 5, wherein, Determining whether the fourth polynomial corresponding to the fourth circuit constraint is a constant-zero polynomial includes: Determine the type of each term in the fourth polynomial; the type includes variable, non-zero constant, and zero. The fourth polynomial is simplified by merging according to the type of each term; when the type of the simplification result is zero, the fourth polynomial is determined to be a constant zero polynomial.

7. The method according to claim 1, wherein the zero-knowledge proof circuit further includes a circuit table; the method further includes: For any target column in the circuit table, if the target column does not appear in any circuit constraint, then make the review result include unused column vulnerabilities.

8. The method according to claim 1, wherein the zero-knowledge proof circuit further includes a circuit table; the method further includes: For any target cell in the circuit table, if the target cell does not appear in any of the non-zero gate constraints and does not appear in any of the lookup table constraints, then let the inspection result contain unconstrained cell vulnerabilities.

9. A method for examining zero-knowledge proof circuits, wherein the zero-knowledge proof circuit includes a set of circuit constraints, the circuit constraints including gate constraints and lookup table constraints, the method comprising: Convert each circuit constraint in the circuit constraint group into the corresponding constraint solving language; The circuit constraint set is solved according to the constraint solving language. If no solution satisfying the set of circuit constraints can be found, the review result is deemed to contain over-constraint vulnerabilities; if the number of solutions satisfying the set of circuit constraints is greater than one set, the review result is deemed to contain under-constraint vulnerabilities.

10. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images