Zero-knowledge proof circuit review method and computing device

Abstract

The embodiment of the invention relates to a zero-knowledge proof circuit review method and computing equipment, a zero-knowledge proof circuit comprises a circuit constraint group, circuit constraints comprise gate constraints and table look-up constraints, and variables in the circuit constraints correspond to parameters in a target model; the target model is used for performing prediction according to input data; the value of a specific variable in the circuit constraint group is determined by the input data; the method comprises the following steps: firstly, converting each circuit constraint in the circuit constraint group into a corresponding constraint solving language; then, according to the constraint solving language, solving the circuit constraint group; when the solution satisfying the circuit constraint group cannot be found, making the review result contain an over-constraint vulnerability; and when the number of the found solutions meeting the circuit constraint group is greater than one group, the review result contains the under-constraint vulnerability.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of privacy computing technology, and in particular, to a zero-knowledge proof circuit review method and computing device. Background Art

[0002] As an important cryptographic technology, Zero-Knowledge Proof (ZKP) has been widely used in blockchain, digital identity authentication, privacy computing and other fields. Its core is to allow the prover to prove the correctness of a proposition to the verifier without revealing any additional information. This feature makes it an important cornerstone for building a trustworthy and privacy-preserving system.

[0003] For example, in a machine learning application scenario, there are two participants, the data holder and the model holder. The data holder sends the data to be predicted to the model holder, and the model holder uses the model to make predictions and sends the prediction results to the data holder. Since the model is often privately owned by the model holder, the data user cannot directly know the specific process of the prediction, and therefore cannot know whether the prediction result he obtained was predicted by the model.

[0004] At this point, the model holder can act as a prover and use zero-knowledge proof technology to prove to the data holder the correctness of the prediction process, including the use of the correct model to make the correct prediction, without disclosing the details of the model and the prediction process. The data holder, as a verifier, can verify the proof provided by the model holder to know the correctness of the prediction process.

[0005] However, the security of the zero-knowledge proof system is highly dependent on the correct implementation of its underlying zero-knowledge proof circuit. As the infrastructure of the entire system, the circuit will bring serious security risks once there are loopholes or defects. Malicious attackers may use these loopholes to construct false proofs, thereby bypassing system verification, and then interfering with or manipulating the system, causing serious consequences such as financial losses and data tampering.

[0006] Currently, the correctness verification of zero-knowledge proof circuits mainly relies on manual review by professionals. This not only requires a lot of manual input, but is also easily affected by human negligence, lack of experience or misjudgment, leading to misjudgment or omission of certain potential risks.

[0007] Therefore, a method is needed to automatically review zero-knowledge proof circuits to improve the efficiency and accuracy of the review. Summary of the invention

[0008] The purpose of this specification is to provide a zero-knowledge proof circuit review method and computing device, aiming to automatically review the zero-knowledge proof circuit.

[0009] In a first aspect, the present specification provides a zero-knowledge proof circuit review method, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraint includes a gate constraint and a table lookup constraint, and the variables in the circuit constraint correspond to the parameters in the target model; the target model is used to make predictions based on input data; the value of a specific variable in the circuit constraint group is determined by the input data; the method includes:

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

[0011] The circuit constraint group is solved according to the constraint solving language; when a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

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

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

[0014] In some possible implementations, solving the circuit constraint group according to the constraint solving language includes:

[0015] Solving the circuit constraint group using a solver;

[0016] When the solver finds a set of first target solutions, a corresponding first target circuit constraint is determined according to the first target solution and added to the circuit constraint group; the first target circuit constraint is used to make each variable in the circuit constraint group not equal to a value in the first target solution;

[0017] The updated circuit constraint group is solved using a solver. When the solver finds a set of second target solutions, the number of solutions satisfying the circuit constraint group is greater than one set.

[0018] A second aspect of the present specification provides a zero-knowledge proof circuit review method, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraint includes a gate constraint and a table lookup constraint, and the method includes:

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

[0020] The circuit constraint group is solved according to the constraint solving language; when a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

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

[0022] When any first circuit constraint is a gate constraint that is always satisfied, the first circuit constraint is not converted.

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

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

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

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

[0027] In some possible implementations, solving the circuit constraint group according to the constraint solving language includes:

[0028] Solving the circuit constraint group using a solver;

[0029] When the solver finds a set of first target solutions, a corresponding first target circuit constraint is determined according to the first target solution and added to the circuit constraint group; the first target circuit constraint is used to make each variable in the circuit constraint group not equal to a value in the first target solution;

[0030] The updated circuit constraint group is solved using a solver. When the solver finds a set of second target solutions, the number of solutions satisfying the circuit constraint group is greater than one set.

[0031] In some possible implementations, the following further includes:

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

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

[0034] For any target column in the circuit table, if the target column does not appear in each circuit constraint, the inspection result is set to include an unused column vulnerability.

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

[0036] For any target cell in the circuit table, if the target cell does not appear in each non-zero gate constraint and does not appear in each table lookup constraint, the review result is set to include an unconstrained cell vulnerability.

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

[0038] A fourth aspect of the present specification provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect or the second aspect is implemented.

[0039] A fifth aspect of the present specification provides a computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the first aspect or the second aspect.

[0040] The zero-knowledge proof circuit review method and computing device proposed in the embodiments of this specification convert the circuit constraint group into a circuit constraint language and solve the circuit constraint group according to the circuit constraint language. When there is no solution, an over-constrained vulnerability is reported, and when there is more than one solution, an under-constrained vulnerability is reported. By automatically solving the circuit constraint group, potential vulnerabilities in the zero-knowledge proof circuit can be reviewed more quickly and accurately to reduce security risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0042] Figure 1 It is a flowchart of a zero-knowledge proof circuit review method in an embodiment of this specification;

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

[0044] Figure 3 It is a schematic block diagram of a zero-knowledge proof circuit review device in one embodiment of this specification. DETAILED DESCRIPTION

[0045] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0046] As mentioned above, in order to prove the correctness of a proposition claimed by the prover to the verifier without revealing additional information, the prover can use zero-knowledge proof technology. 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 correctness of the proposition based on the circuit.

[0047] The zero-knowledge proof circuit includes several variables and several circuit constraints for these variables. Circuit constraints include gate constraints and table lookup constraints, where the gate constraint contains a polynomial that is used to constrain the values ​​of the corresponding variables in the polynomial. If the value of the polynomial is zero, the gate constraint is said to be satisfied. The table lookup constraint is a constraint on the value range of a variable in the circuit. When the value of the variable falls within the range of the table lookup constraint, the table lookup constraint is satisfied.

[0048] When the prover converts the proposition to be proved into a zero-knowledge proof circuit, the circuit may have loopholes, which may lead to security risks. Therefore, before using the circuit to generate a zero-knowledge proof, it is necessary to review the correctness of the circuit to see if there are any circuit defects. After the circuit defects are found and repaired, the repaired circuit can be used to generate a zero-knowledge proof.

[0049] Figure 1 It is a flowchart of the zero-knowledge proof circuit review method in an embodiment of this specification. Among them, over-constraint means that there is no set of variable values ​​that can satisfy all constraints in the circuit. Under-constraint means that one / some variables in the circuit can take more than two different values ​​and still satisfy all constraints in the circuit. Correct constraint means that if all gate constraints and table lookup constraints in the circuit are to be satisfied, the value of the variable in the circuit has and only has one possible value.

[0050] exist Figure 1 In the example, in order to check whether there are over-constraint / under-constraint vulnerabilities in the zero-knowledge proof circuit, the circuit constraint group needs to be solved. First, the circuit constraint group is converted into the corresponding constraint solving language form, such as SMT-LIB, and then the circuit constraint group is solved based on the constraint solving language. When the circuit constraint group has no solution, an over-constraint vulnerability is reported in the review result; when the circuit constraint group has a solution, this set of solutions is used as the new circuit constraint so that the values ​​of each variable cannot be equal to the values ​​in the set of solutions, and the new circuit constraints are added to the circuit constraint group, and the circuit constraint group is solved again. At this time, if there is no solution, it means that the circuit constraint group has one and only one set of solutions, and the circuit constraint group is correctly constrained; if there is still a solution, it means that there are more than one set of solutions that can satisfy the circuit constraint group, and an under-constraint vulnerability is reported in the review result.

[0051] The following describes the specific implementation steps of the above zero-knowledge proof circuit review method in conjunction with a specific embodiment.

[0052] Figure 2 This is a flowchart of a zero-knowledge proof circuit review method in an embodiment of this specification. The execution subject of the method can be any platform or server or device cluster with computing and processing capabilities. Figure 2 As shown, the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraints include gate constraints and table lookup 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 input data; the values ​​of specific variables in the circuit constraint group are determined by the input data; the method at least includes: 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 a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

[0053] The target model may be a prediction model, which performs prediction based on input data to obtain a prediction result. The circuit constraint group in the zero-knowledge proof circuit is used to generate a zero-knowledge proof that proves the correctness of the above prediction process.

[0054] The circuit constraint group can be obtained by converting the prediction process of the target model, wherein the variables correspond to the parameters in the target model. The specific variables in the circuit constraint group can include relevant variables in the input circuit, which correspond to the input parameters of the target model, and the specific values ​​are determined by the input data.

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

[0056] Specifically, some constraints in the circuit constraint group are gate constraints, which are used to constrain the structure of the tree, including the hash value of the leaf node; and another part of the constraints are table lookup constraints, which correspond to the threshold value on the split node.

[0057] The tree model can be a model for making predictions in a variety of scenarios. For example, in one embodiment, the 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 can include at least one of user features and transaction information, and the prediction result can be the prediction result of the tree model on whether the input user / transaction is risky.

[0058] In another embodiment, the input data is text data, for example, information related to a user and / or a transaction in an anti-fraud scenario.

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

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

[0061] Constraint solving languages ​​are used to describe and solve logical formulas, constraint problems or symbolic calculations, such as the Satisfied Modulo Theory-Library (SMT-LIB) language, the language used by the z3 solver, and the language used by the CVC4 / CVC5 solver. For example, a circuit constraint group in the SMT-LIB language format can be:

[0062] (set-logic QF_LIA); Set the logic to quantized free integer linear expression

[0063] (declare-const x Int); declare an integer variable x

[0064] (declare-const y Int); declare an integer variable y

[0065] (declare-const z Bool); declare a Boolean variable z

[0066] (assert(=(+xy)10)); Constraint 1: x+y=10

[0067] (assert(<=y 7)); Constraint 2: y<=7

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

[0069] (check-sat); Checks whether there is a solution that satisfies all constraints.

[0070] (get-model); If a solution exists, return the specific variable value.

[0071] In this step, each circuit constraint is converted into a corresponding constraint solving language, which can be implemented using an automated tool provided by a zero-knowledge proof framework related to the zero-knowledge proof circuit. For example, when the related zero-knowledge proof framework is the Halo2 framework and the constraint solving language is SMT-LIB, the automated tool used can be snarkjs.

[0072] In the above conversion process, for some circuit constraints, if the conversion is performed directly, the form of the constraint solution language obtained by the conversion will be more complicated, which increases the space occupied and causes the subsequent solution process to become slow. Therefore, before converting each circuit constraint, the circuit constraint can be preprocessed accordingly and then converted to reduce the space occupied.

[0073] In one embodiment, the conversion in step 202 includes:

[0074] When any first circuit constraint is a gate constraint that is always satisfied, the first circuit constraint is not converted.

[0075] When the first circuit constraint is a gate constraint, the polynomial contained therein is simplified. If the simplified result is equal to 0, it means that the constraint is a constant constraint. In this case, the first circuit constraint can be removed in step 202 without conversion.

[0076] For example, for a gate constraint a 1 ×0=0, which contains the polynomial a 1 ×0, after simplification, the result is 0, so the gate constraint can be removed and no conversion is performed.

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

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

[0079] When the second constraint circuit is directly converted, each value in the second value range will be converted into a gate constraint, which will cause a lot of space waste. This embodiment saves space by converting the second circuit constraint into a constraint solving language in the form of the second value range.

[0080] For example, if a table lookup constraint is used to constrain the value of variable a to be between 0, 1, ..., 100, if it is directly converted, the constraint solution language will be in the following form: a-0=0ora-1=0or...ora-100=0, resulting in a waste of space. According to the conversion of this embodiment, it will be converted into a≤100anda≥0, which saves more space and is more conducive to subsequent solutions.

[0081] In yet another embodiment, the converting in step 202 includes:

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

[0083] For example, for a door constraint (a 2 +0-a 3 )×1=0, the polynomial on the left can be simplified to a 2 -a 3 , and then the simplified gate constraint a 2 -a 3 =0 is converted into the corresponding constraint solving language.

[0084] Then, return to Figure 2 In step 204, the circuit constraint group is solved according to the constraint solving language; when a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

[0085] A constraint solver (hereinafter referred to as "solver") may be used to solve the circuit constraint group. For example, when the constraint solving language is SMT-LIB, the solver used may be a cvc5 solver, a z3 solver, etc., which are not limited here. The constraint solver may automatically solve a solution that satisfies the constraint conditions according to the input constraint group.

[0086] When a solution that satisfies the circuit constraint group cannot be found, the review result is allowed to include an over-constraint vulnerability.

[0087] When a unique set of solutions is found that satisfies the circuit constraint set, then the circuit constraint set is correctly constrained.

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

[0089] In some embodiments, existing constraint solvers typically return a result after finding one group 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.

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

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

[0092] Then, in step 2044, when the solver finds one group 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.

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

[0094] 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".

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

[0096] 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 group, and the review result of this circuit constraint group includes an under-constrained vulnerability.

[0097] If step 2046 cannot find solutions other than the first target solutions, the circuit constraint group has and only has a unique group of solutions, and this circuit constraint group is correctly constrained.

[0098] The above describes the review process for over-constrained / under-constrained of the circuit constraint group.

[0099] In some possible implementation manners, the method further includes:

[0100] Step 206, when any fourth circuit constraint in the circuit constraint group is a gate constraint, determine whether a fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial; if yes, let the review result include an unused gate vulnerability.

[0101] The following will take the zero-knowledge proof circuit as a Halo2 circuit as an example to describe the review process for unused gate vulnerabilities.

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

[0103] For example, a zero-knowledge proof circuit of a Halo2 framework may be shown in Table 1:

[0104] Table 1: Circuit Example 1

[0105] Advice1 Advice2 Fixed Selector <![CDATA[a 1 ]]> <![CDATA[a 2 ]]> x s

[0106] The above circuit includes two Advice columns, a Fixed column and a Selector column. The second line contains the values ​​of the variables in each column in the corresponding instance. For the above circuit, the fourth polynomial corresponding to the fourth circuit constraint can be, for example, xa(a 1 -a 2 ). If for each row, the fixed values ​​have x=0 or s=0, then this fourth polynomial is actually a constant zero polynomial. No matter how the variables in the two Advice columns take values, it will not affect the fourth circuit constraint. In other words, the fourth circuit constraint cannot constrain the variables in the Advice1 and Advice2 columns. However, during the code execution, this gate constraint will still be checked for each row of the circuit table, which will lead to code redundancy and longer running time.

[0107] Therefore, for the constant zero polynomial, an unused gate vulnerability is reported in the review result. Optionally, the review result may also include the position of the fourth circuit constraint in the circuit constraint group.

[0108] The polynomials in each gate constraint can be formally checked to determine whether they are constant zero polynomials.

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

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

[0111] The fourth polynomial is merged and simplified according to the types of each term; when the type to which the simplified result belongs is zero, the fourth polynomial is determined to be a constant zero polynomial.

[0112] The fourth polynomial can be combined and simplified based on the types of each term according to the operation rules and operation order. For example, the result type of multiplying the zero type by the variable type is the zero type, the result type of adding the variable type and the non-zero constant type is the variable type, and so on.

[0113] The operation rules can be shown in Table 2:

[0114] Table 2: Calculation rules

[0115] Item Type Item Type Add / Subtract take variable variable variable variable variable Non-zero constant variable variable variable zero variable zero Non-zero constant Non-zero constant Non-zero constant / zero Non-zero constant Non-zero constant zero Non-zero constant zero zero zero zero zero

[0116] For example, for the polynomial xs(a 1 -a 2 ), when x is a non-zero constant, s is zero, and a 1 and a 2 When is a variable, the simplification process of the polynomial is as follows:

[0117] xs(a 1 -a 2 )→non-zero constant×zero×(variable-variable)→zero×(variable-variable)→zero×variable→zero

[0118] Therefore, the polynomial is a constant zero polynomial.

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

[0120] Step 208 : For any target column in the circuit table, if the target column does not appear in each circuit constraint, the review result is set to include an unused column vulnerability.

[0121] By traversing each circuit constraint and determining whether each circuit 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 result. Optionally, the review result can also include the position of the target column in the circuit table.

[0122] All unused columns may be determined by traversing each column in the circuit table and checking whether they appear in at least one circuit constraint.

[0123] The following still takes the zero-knowledge proof circuit as the Halo2 circuit as an example to describe the review process of the unused column vulnerability.

[0124] For example, a zero-knowledge proof circuit of a Halo2 framework may be shown in Table 3:

[0125] Table 3: Circuit Example 2

[0126] Advice1 Advice2 Advice3 Fixed Selector <![CDATA[a 11 ]]> <![CDATA[a 12 ]]> <![CDATA[a 13 ]]> <![CDATA[x 1 ]]> <![CDATA[s 1 ]]> <![CDATA[a 21 ]]> <![CDATA[a 22 ]]> <![CDATA[a 23 ]]> <![CDATA[x 2 ]]> <![CDATA[s 2 ]]>

[0127] The above circuit includes three Advice columns, one Fixed column and one Selector column. The second and subsequent rows are the values ​​of each column variable in different instances. The circuit constraint group included in the above circuit can include two gate constraints, namely XSA 1 and S(A 1 -A 2 ), where A 1 Represents the variable of Advice1 column, A 2 represents the variable in the Advice2 column, X represents the variable in the Fixed column, and S represents the variable in the Selector column. At this point, we can find that the variable in the Advice3 column does not appear in any constraint, so we can determine that the Advice3 column is an unused column.

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

[0129] Step 210, for any target cell in the circuit table, if the target cell does not appear in each non-zero gate constraint and does not appear in each table lookup constraint, then the review result is set to include an unconstrained cell vulnerability.

[0130] You can traverse each cell corresponding to each column in the store table and check whether it appears in at least one non-zero gate constraint or in a table lookup constraint. If not, the cell is an unconstrained cell (UnconstrainedCells) and the unconstrained cell vulnerability is reported in the review result. Optionally, the review result can also include the location of the target cell in the circuit table.

[0131] The method for determining the non-zero gate constraint may refer to the process of step 206, which will not be described in detail here.

[0132] The following still uses the zero-knowledge proof circuit as the Halo2 circuit as an example to describe the review process of unconstrained lattice vulnerabilities.

[0133] For example, a zero-knowledge proof circuit of a Halo2 framework may be shown in Table 4:

[0134] Table 4: Circuit Example 3

[0135] Advice1 Advice2 Advice3 Fixed Selector <![CDATA[a 11 ]]> <![CDATA[a 12 ]]> <![CDATA[a 13 ]]> <![CDATA[x 1 ]]> <![CDATA[s 1 ]]> <![CDATA[a 21 ]]> <![CDATA[a 22 ]]> <![CDATA[a 23 ]]> <![CDATA[x 2 ]]> <![CDATA[s 2 ]]>

[0136] The above circuit includes three Advice columns, one Fixed column and one Selector column. The second and subsequent rows are the values ​​of each column variable in different instances. The circuit constraint group included in the above circuit can include two gate constraints, namely XA 1 -A 2 and S(A 1 -A 2 -A 3 ), where A 1 Represents the variable of Advice1 column, A 2 Represents the variable of Advice2 column, A 3 represents the variable in the Advice3 column, X represents the variable in the Fixed column, and S represents the variable in the Selector column. 2 The value of is 0, then S(A 1 -A 2 -A 3 ) in this row has a value of zero, and XA 1 -A 2 If the Advice3 column is not included, then a 23 does not appear in any non-zero gate constraint. At this time, a 23 is an unconstrained lattice. 23 No matter what value this grid takes, it will not affect the results of the two gate constraints.

[0137] According to the above steps, the embodiment of this specification automatically converts the 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 zeros and simplify the constraints to reduce the number of constraints output in the final output. In addition, the table lookup constraints are also judged. For the range constraints in the table lookup constraints, a large number of equation judgments are converted into size judgments, which greatly reduces the output.

[0138] In the review of unused gates, unused columns, and unconstrained grid vulnerabilities, the gate constraints and table lookup constraints are checked simultaneously to increase the review accuracy and reduce false positives and negatives of vulnerabilities.

[0139] Based on the same inventive concept, an embodiment of this specification also provides a zero-knowledge proof circuit review method, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraint includes a gate constraint and a table lookup constraint, and the method includes:

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

[0141] The circuit constraint group is solved according to the constraint solving language; when a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

[0142] In one embodiment, the converting includes:

[0143] When any first circuit constraint is a gate constraint that is always satisfied, the first circuit constraint is not converted.

[0144] In one embodiment, the converting includes:

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

[0146] In one embodiment, the converting includes:

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

[0148] In one embodiment, solving the circuit constraint group according to the constraint solving language includes:

[0149] Solving the circuit constraint group using a solver;

[0150] When the solver finds a set of first target solutions, a corresponding first target circuit constraint is determined according to the first target solution and added to the circuit constraint group; the first target circuit constraint is used to make each variable in the circuit constraint group not equal to a value in the first target solution;

[0151] The updated circuit constraint group is solved using a solver. When the solver finds a set of second target solutions, the number of solutions satisfying the circuit constraint group is greater than one set.

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

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

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

[0155] For any target column in the circuit table, if the target column does not appear in each circuit constraint, the inspection result is set to include an unused column vulnerability.

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

[0157] For any target cell in the circuit table, if the target cell does not appear in each non-zero gate constraint and does not appear in each table lookup constraint, the review result is set to include an unconstrained cell vulnerability.

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

[0159] A conversion unit 302 is configured to convert each circuit constraint in the circuit constraint group into a corresponding constraint solving language;

[0160] The first vulnerability determination unit 304 is configured to solve the circuit constraint group according to the constraint solving language; when a solution satisfying the circuit constraint group cannot be found, the review result is configured to include an over-constrained vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is configured to include an under-constrained vulnerability.

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

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

[0163] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; and the apparatus 300 further includes:

[0164] 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 an unused column vulnerability.

[0165] In some possible implementations, the zero-knowledge proof circuit further includes a circuit table; and the apparatus 300 further includes:

[0166] 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 each non-zero gate constraint and does not appear in each table lookup constraint, make the review result include an unconstrained cell vulnerability.

[0167] According to another aspect of the embodiment, a computer program product is also provided, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

[0168] According to yet another embodiment, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in any one of the above embodiments is implemented.

[0169] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0170] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

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

[0172] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0173] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0174] This specification is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0175] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0176] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0178] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0179] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0180] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present 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.

[0181] One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0182] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0183] The above description is only an example of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. For those skilled in the art, one or more embodiments of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification shall be included in the scope of the claims.

Claims

1. A zero-knowledge proof circuit review method, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraint includes a gate constraint and a table lookup constraint, and the variables in the circuit constraint correspond to the parameters in the target model; The target model is used to make predictions based on input data; The value of a specific variable in the circuit constraint group is determined by the input data; the method comprises: Convert each circuit constraint in the circuit constraint group into a corresponding constraint solving language; The circuit constraint group is solved according to the constraint solving language; when a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

2. The method according to claim 1, wherein: The conversion includes: When any first circuit constraint is a gate constraint that is always satisfied, the first circuit constraint is not converted.

3. The method according to claim 1, wherein: The conversion includes: When any second circuit constraint is a table lookup constraint, and the table lookup constraint is within the second value range, 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, a third polynomial corresponding to the third circuit constraint is simplified, and the third circuit constraint is converted into a corresponding constraint solving language according to 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, determining whether a fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial; If yes, let the audit result include the unused gate vulnerability.

6. The method according to claim 5, wherein: Determining whether a fourth polynomial corresponding to the fourth circuit constraint is a constant zero polynomial includes: Determining the type of each term in the fourth polynomial; the type includes a variable, a non-zero constant, and zero; The fourth polynomial is merged and simplified according to the types of each term; when the type to which the simplified result belongs 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 comprises a circuit table; the method further comprises: For any target column in the circuit table, if the target column does not appear in each circuit constraint, the inspection result is set to include an unused column vulnerability.

8. The method according to claim 1, wherein the zero-knowledge proof circuit further comprises a circuit table; the method further comprises: For any target cell in the circuit table, if the target cell does not appear in each non-zero gate constraint and does not appear in each table lookup constraint, the review result is set to include an unconstrained cell vulnerability.

9. A zero-knowledge proof circuit review method, wherein the zero-knowledge proof circuit includes a circuit constraint group, the circuit constraint includes a gate constraint and a table lookup constraint, and the method comprises: Convert each circuit constraint in the circuit constraint group into a corresponding constraint solving language; Solving the circuit constraint group according to the constraint solving language; When a solution satisfying the circuit constraint group cannot be found, the review result is made to include an over-constraint vulnerability; when the number of solutions satisfying the circuit constraint group is greater than one group, the review result is made to include an under-constraint vulnerability.

10. A computing device comprising a memory and a processor, wherein the memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 9 is implemented.

Images