Zero-Knowledge Proof Method and Device Applicable to Blockchain

Abstract

The present application discloses a zero - knowledge proof method and device applicable to a blockchain. Among them, the method includes: in the stage where the prover submits evidence and the verifier checks the evidence, detecting whether any encoding matrix after encoding a vector with a preset length is an interleaved Reed - Solomon code; in the linear constraint checking stage, generating evidence for linear constraint checking, and performing verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies the first preset constraint checking condition; in the quadratic constraint checking stage, generating evidence for quadratic constraint checking, and performing verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies the second preset checking condition. Thereby, the technical problem in the related art that when the classical zero - knowledge proof protocol Ligero++ is applied to a blockchain, the computational overhead increases and computing resources cannot be saved is solved.

Description

Technical Field

[0001] This application relates to the technical fields of information security and e-commerce, and particularly relates to a zero-knowledge proof method and apparatus applicable to a blockchain. Background Art

[0002] In related technologies, the Ligero protocol is the first zero-knowledge proof protocol based on interactive oracle proof that achieves a square-root level of communication complexity. It is only based on the assumption of the existence of a collision-resistant hash function, has the advantages of sublinear proof scale, fast proof generation, quantum resistance, and no need for a trusted assumption, and is relatively suitable for a blockchain. However, it can only achieve a square-root level of communication complexity. For the arithmetic circuit satisfiability problem, the Ligero protocol includes two steps: correctness checking and consistency checking. The Ligero++ protocol proposes an inner product argument protocol, which improves the consistency checking step in the Ligero protocol and achieves a logarithmic level of communication complexity. Currently, zero-knowledge proof protocols based on interactive oracle proof, such as Ligero++ and Virgo, are widely used in blockchains, especially in blockchain scaling solutions such as plonky2 and estarck. In particular, this type of zero-knowledge proof can be organically combined with classical zk-SNARKs to construct a recursive zero-knowledge proof, thereby implementing a zero-knowledge proof protocol with fast proof time, small communication scale, and fast verification time, and applying it to the blockchain.

[0003] As described above, researching zero-knowledge proof based on interactive oracle proof, improving and enhancing the performance play a promoting role in improving the throughput of the blockchain and the performance of the scaling solution. As one of the representatives of this type of zero-knowledge proof protocol, improving Ligero++ itself, accelerating the proof and verification time, and reducing the computational overhead and communication overhead are of great significance. However, in related technologies, when the classical zero-knowledge proof protocol Ligero++ is applied to a blockchain, to implement multiple inner product relation checks in the consistency check, the computational overhead increases, and to achieve zero-knowledge, the actual proof scale is large, and computing resources cannot be saved, which urgently needs to be solved. Summary of the Invention

[0004] This application is made based on the inventor's following problems and understandings:

[0005] In blockchain applications, efficient and concise zero-knowledge proof protocols are used to ensure the security of blockchains in data circulation and sharing, which is the key for blockchain technology to be widely accepted and applied. To improve the prover time, proof size, and verifier time of zero-knowledge proof protocols, many zero-knowledge proof protocols have been proposed in the academic community. Among them, interactive oracle proofs stand out due to their sublinear proof size and efficient proof time. They only rely on the existence of collision-resistant hash functions and lightweight symmetric key operations, meeting the post-quantum security requirements. Currently, zero-knowledge proofs based on interactive oracle proofs have been used in blockchain Ethereum scaling solutions such as plonky2 and estark.

[0006] The Ligero protocol is the first zero-knowledge proof protocol based on interactive oracle proofs to achieve a square-root level of communication complexity. For the arithmetic circuit satisfiability problem, the Ligero protocol consists of two steps: correctness checking and consistency checking. In the correctness checking, the verifier intends to check whether the circuit constraints are satisfied. Specifically, in the correctness checking, the prover arranges all the wire values of the arithmetic circuit C into a matrix and then encodes each row using the Reed-Solomon code, thus encoding the entire matrix into an encoded matrix U. The verifier requests random linear combinations of each row of U and checks the correctness of the constraints.

[0007] In addition, in the consistency checking, the verifier checks multiple inner product relationships between the public random vector and some columns queried by the verifier in U. The communication overhead of the correctness checking is one row of U, and the communication overhead of the consistency checking is some columns of U. If the matrix size is set to:

[0008]

[0009] where |C| represents the number of gates in the arithmetic circuit.

[0010] Then, the Ligero protocol achieves a square-root level of communication complexity. The Ligero++ protocol uses the inner product argument protocol to complete the consistency checking in Ligero. If the matrix size is set to:

[0011] O(|C| / log|C|)×O(log|C|),

[0012] then the communication complexity of the Ligero++ protocol will be reduced to O(log|C|).

[0013] Although Ligero++ achieves a logarithmic level of communication complexity and has also been applied to practical applications such as quantum-resistant signatures, it still faces the following two problems when applied to blockchains:

[0014] First, there is the problem of high computational cost. To implement multiple inner product relation checks in consistency checking, the Ligero++ protocol calls the inner product argument protocol multiple times. Therefore, the low-degree check sub-protocol in the inner product argument is also executed multiple times, resulting in a high computational cost.

[0015] Second, there is the problem of a large actual proof size caused by achieving zero-knowledge. First, to achieve zero-knowledge, the Ligero++ protocol increases the degree of the encoding polynomial in the oracle matrix by t, where t is the number of columns of oracle access. That is, t additional random elements are filled in each row of the oracle matrix. However, compared with the row size of the oracle matrix, the size of t is relatively large, resulting in a large proof size. In addition, the Ligero++ protocol makes Merkle tree commitments for each column of the oracle matrix, resulting in a large communication overhead for Merkle tree verification paths, accounting for about 4 / 5 of the entire communication volume.

[0016] Therefore, when applying Ligero++ to the blockchain, there are two problems and they need to be improved urgently.

[0017] This application provides a zero-knowledge proof method and device applicable to the blockchain to solve the technical problems in the related art that when the classical zero-knowledge proof protocol Ligero++ is applied to the blockchain, to implement multiple inner product relation checks in consistency checking, the computational cost increases, and to achieve zero-knowledge, the actual proof size is large and the computing resources cannot be saved.

[0018] The first aspect embodiment of this application provides a zero-knowledge proof method applicable to the blockchain, including the following steps: in the stage where the prover submits evidence and the verifier checks the evidence, detecting whether any encoding matrix encoded from a vector of a preset length is an interleaved Reed-Solomon code; in the linear constraint check stage, generating evidence for linear constraint check and performing verifier consistency check and verifier correctness check to detect whether any first encoded vector satisfies the first preset constraint check condition; in the quadratic constraint check stage, generating evidence for quadratic constraint check and performing verifier consistency check and verifier correctness check to detect whether any second encoded vector satisfies the second preset check condition.

[0019] Optionally, in an embodiment of the present application, in the stage where the prover submits evidence and the verifier checks the evidence, detecting whether any encoding matrix encoded from a vector of a preset length is an interleaved Reed-Solomon code includes: based on the prover, arranging the secret row vectors into an extended evidence matrix, encoding the extended evidence matrix into an oracle matrix using Reed-Solomon encoding, and using a Merkle tree to commit to each column of the oracle matrix, so as to send the calculation vector obtained from the first challenge vector selected by the verifier to the verifier; based on the verifier, detecting whether the calculation vector is a Reed-Solomon code, if not, terminating the protocol, otherwise running a batch zero-knowledge inner product argument to verify whether the inner product of each column of the oracle matrix and the first challenge vector is equal to the corresponding component of the calculation vector.

[0020] Optionally, in an embodiment of the present application, in the linear constraint checking stage, generating evidence for linear constraint checking to perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies a first preset constraint checking condition includes: based on the prover, obtaining a second challenge vector of the verifier, obtaining a second calculation vector, generating a first polynomial, so as to generate a second polynomial sent to the verifier; based on the verifier, detecting whether it satisfies a first preset correctness checking condition according to the second polynomial, if not, terminating the protocol, otherwise the verifier and the prover call a preset batch inner product argument for consistency checking, and if the batch zero-knowledge inner product argument check fails, terminating the protocol, otherwise the verifier accepts the proof.

[0021] Optionally, in an embodiment of the present application, in the quadratic constraint checking stage, generating evidence for quadratic constraint checking and performing verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies a second preset checking condition includes: based on the prover, obtaining a third challenge vector of the verifier and calculating a third polynomial; based on the verifier, detecting whether it satisfies a second preset correctness checking condition according to the third polynomial, if not, terminating the protocol, otherwise the prover and the verifier call the preset batch zero-knowledge inner product argument protocol for consistency checking, and if the batch zero-knowledge inner product argument check fails, terminating the protocol, otherwise the verifier accepts the proof.

[0022] The second aspect of the present application provides a zero - knowledge proof device applicable to a blockchain, including: a detection module, configured to detect whether any encoded matrix after encoding a vector with a preset length is an interleaved Reed - Solomon code during the phase where the prover submits evidence and the verifier checks the evidence; a first generation module, configured to generate evidence for linear constraint checking during the linear constraint checking phase, and perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies a first preset constraint checking condition; a second generation module, configured to generate evidence for quadratic constraint checking during the quadratic constraint checking phase, and perform verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies a second preset checking condition.

[0023] Optionally, in an embodiment of the present application, the detection module includes: a first calculation unit, configured to, based on the prover, arrange the secret row vectors into an extended evidence matrix, encode the extended evidence matrix into an oracle matrix using Reed - Solomon coding, and commit to each column of the oracle matrix using a Merkle tree, so as to send a calculation vector obtained from a first challenge vector selected by the verifier to the verifier; a first detection unit, configured to, based on the verifier, detect whether the calculation vector is a Reed - Solomon code. If not, terminate the protocol; otherwise, run a batch zero - knowledge inner product argument to verify whether the inner product of each column of the oracle matrix and the first challenge vector is equal to the corresponding component of the calculation vector.

[0024] Optionally, in an embodiment of the present application, the first generation module includes: a generation unit, configured to, based on the prover, obtain a second challenge vector of the verifier, obtain a second calculation vector, and generate a first polynomial, so as to generate a second polynomial sent to the verifier; a second detection unit, configured to, based on the verifier, detect whether the first preset correctness checking condition is satisfied according to the second polynomial. If not, terminate the protocol; otherwise, the verifier and the prover call a preset batch inner product argument for consistency checking, and if the batch zero - knowledge inner product argument check fails, terminate the protocol; otherwise, the verifier accepts the proof.

[0025] Optionally, in an embodiment of the present application, the second generation module includes: a second calculation unit, configured to, based on the prover, obtain a third challenge vector of the verifier and calculate a third polynomial; a third detection unit, configured to, based on the verifier, detect whether the second preset correctness checking condition is satisfied according to the third polynomial. If not, terminate the protocol; otherwise, the prover and the verifier call the preset batch zero - knowledge inner product argument protocol for consistency checking, and if the batch zero - knowledge inner product argument check fails, terminate the protocol; otherwise, the verifier accepts the proof.

[0026] In the third aspect of the embodiments of the present application, an electronic device is provided, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor executes the program to implement the zero-knowledge proof method applicable to the blockchain as described in the above embodiments.

[0027] In the fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, and the computer-readable storage medium stores a computer program, and when the program is executed by a processor, it implements the zero-knowledge proof method applicable to the blockchain as described above.

[0028] In the embodiments of the present application, during the stage where the prover submits evidence and the verifier checks the evidence, it can be detected whether any encoding matrix after encoding a vector of a certain length is an interleaved Reed-Solomon code. During the linear constraint checking stage, evidence for linear constraint checking is generated, and verifier consistency checking and verifier correctness checking are performed to detect whether any first encoded vector satisfies the first constraint checking condition. During the quadratic constraint checking stage, evidence for quadratic constraint checking is generated, and verifier consistency checking and verifier correctness checking are performed to detect whether any second encoded vector satisfies the second checking condition, thereby effectively reducing the communication complexity of the existing zero-knowledge proof system, reducing redundant overhead, and saving computing resources. Thus, it solves the technical problems in the related art that when the classical zero-knowledge proof protocol Ligero++ is applied to the blockchain, in order to implement multiple inner product relation checks in consistency checking, the computing overhead increases, and in order to achieve zero-knowledge, the actual proof scale is large and computing resources cannot be saved.

[0029] Additional aspects and advantages of the present application will be given in part in the following description, will become apparent in part from the following description, or will be understood through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description of the embodiments in conjunction with the drawings, where:

[0031] Figure 1 is a flowchart of a zero-knowledge proof method applicable to the blockchain according to an embodiment of the present application;

[0032] Figure 2 is a flowchart of a zero-knowledge proof method applicable to the blockchain in a specific embodiment of the present application;

[0033] Figure 3 is a schematic structural diagram of a zero-knowledge proof device applicable to the blockchain according to an embodiment of the present application;

[0034] Figure 4Schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. Detailed implementation manners

[0035] The embodiments of the present application will be described in detail below. Examples of the embodiments are shown in the drawings, where the same or similar reference numerals represent the same or similar elements or elements with the same or similar functions throughout. The embodiments described below with reference to the drawings are exemplary and are intended to explain the present application and should not be construed as limiting the present application.

[0036] The zero-knowledge proof method and apparatus applicable to a blockchain according to an embodiment of the present application will be described below with reference to the drawings. In the related art mentioned in the above background art, when the classical zero-knowledge proof protocol Ligero++ is applied to a blockchain, in order to implement multiple inner product relationship checks in consistency checking, the computational overhead increases, and in order to achieve zero-knowledge, the actual proof scale is large, and computational resources cannot be saved. The present application provides a zero-knowledge proof method applicable to a blockchain. In this method, during the stage where the prover submits evidence and the verifier checks the evidence, it can be detected whether any encoding matrix obtained by encoding a vector with a preset length is an interleaved Reed-Solomon code. During the linear constraint checking stage, evidence for linear constraint checking is generated, and verifier consistency checking and verifier correctness checking are performed to detect whether any first encoded vector satisfies the first constraint checking condition. During the quadratic constraint checking stage, evidence for quadratic constraint checking is generated, and verifier consistency checking and verifier correctness checking are performed to detect whether any second encoded vector satisfies the second checking condition, thereby effectively reducing the communication complexity of the existing zero-knowledge proof system, reducing redundant overhead, and saving computational resources. Thus, the technical problem in the related art that when the classical zero-knowledge proof protocol Ligero++ is applied to a blockchain, in order to implement multiple inner product relationship checks in consistency checking, the computational overhead increases, and in order to achieve zero-knowledge, the actual proof scale is large, and computational resources cannot be saved is solved.

[0037] Specifically, Figure 1 Flow chart of a zero-knowledge proof method applicable to a blockchain provided according to an embodiment of the present application.

[0038] As Figure 1 shown, the zero-knowledge proof method applicable to a blockchain includes the following steps:

[0039] In step S101, during the stage where the prover submits evidence and the verifier checks the evidence, it is detected whether any encoding matrix obtained by encoding a vector with a preset length is an interleaved Reed-Solomon code.

[0040] It can be understood that in the stage where the prover submits evidence and the verifier checks the evidence in the embodiments of the present application, it is possible to detect whether any encoding matrix obtained by encoding a vector of a certain length, for example, a vector of length h1h2, is an interleaved Reed-Solomon code. Here, an encoding matrix refers to first arranging the vector in sequence into a matrix of h1×h2, effectively improving the executability of the zero-knowledge proof method.

[0041] It should be noted that the preset length vector is set by those skilled in the art according to the actual situation and is not specifically limited herein.

[0042] Optionally, in an embodiment of the present application, in the stage where the prover submits evidence and the verifier checks the evidence, detecting whether any encoding matrix obtained by encoding a vector of a preset length is an interleaved Reed-Solomon code includes: based on the prover, arranging the secret row vector into an extended evidence matrix, encoding the extended evidence matrix into an oracle matrix using Reed-Solomon coding, and using a Merkle tree to commit to each column of the oracle matrix, so as to send the calculated vector obtained from the first challenge vector selected by the verifier to the verifier; based on the verifier, detecting whether the calculated vector is a Reed-Solomon code. If not, terminate the protocol. Otherwise, run a batch zero-knowledge inner product argument to verify whether the inner product of each column of the oracle matrix and the first challenge vector is equal to the corresponding component of the calculated vector.

[0043] In the actual execution process, in the embodiments of the present application, the prover can submit evidence. The prover can arrange the secret row vector into an extended evidence matrix W, that is:

[0044]

[0045] where represents a finite field, h represents the size of the coset H, and H represents the multiplicative coset on the field

[0046] where H represents the multiplicative coset on the field and the elements are arranged in a certain order. For example, the elements in H are ξ1,…,ξ |H|

[0047] Then, the extended evidence matrix W is encoded into an oracle matrix using Reed-Solomon coding, that is:

[0048]

[0049] where represents the size of the coset L, and L represents the multiplicative coset on the field

[0050] where L represents the field​​​ The upper multiplication coset, with elements arranged in a certain order, where the elements are different from H and |L| > |H|, and the elements are η1, …, η |L| .

[0051] And use a Merkle tree to commit to each column of, and send the Merkle root to the verifier. The verifier randomly selects a challenge vector After the prover obtains the challenge vector r of the verifier, calculate the vector v, that is:

[0052] v = rU w ,

[0053] Furthermore, the embodiment of the present application sends the vector v to the verifier.

[0054] Among them, the specific process of this encoding is to first perform Reed - Solomon encoding on each row of W to obtain an encoding matrix This encoding is mapped from the coset H1 to L1, and then each column of the matrix is also encoded by Reed - Solomon encoding to obtain an oracle matrix This encoding is mapped from the coset H2 to L2.

[0055] Next, the embodiment of the present application can perform a correctness check by the verifier. The verifier checks whether the vector v is a Reed - Solomon code. When it is not a Reed - Solomon code, the protocol is terminated. Otherwise, the verifier performs a consistency check in the following steps.

[0056] Finally, the embodiment of the present application performs a consistency check by the verifier. The verifier runs a batch zero - knowledge inner - product argument to verify whether the inner product of each column of U w and the challenge vector r is equal to the corresponding component of the vector v. When the verifier performs the inner - product check, it can use the inner - product argument protocol in the embodiment of the present application to check multiple groups of inner products at one time, effectively improving the utilization rate of the communication bandwidth and reducing communication and computational overhead.

[0057] In step S102, in the linear constraint check phase, generate evidence for linear constraint check and perform verifier consistency check and verifier correctness check to detect whether any first encoded vector satisfies the first preset constraint check condition.

[0058] It can be understood that the embodiment of the present application can generate evidence for linear constraint check in the linear constraint check phase and perform verifier consistency check and verifier correctness check to detect whether any first encoded vector satisfies the first constraint check condition. For example, it can check whether a vector encoded as satisfies Ax T= 0, where A represents a matrix over a field, T represents vector transpose, is a publicly sparse matrix, thus effectively reducing the communication complexity of the protocol.

[0059] It should be noted that the first preset constraint check condition is set by those skilled in the art according to the actual situation and is not specifically limited herein.

[0060] Optionally, in an embodiment of the present application, in the linear constraint check stage, evidence for linear constraint check is generated to perform verifier consistency check and verifier correctness check to detect whether any first encoded vector satisfies the first preset constraint check condition, including: based on the prover, obtaining the second challenge vector of the verifier and obtaining the second calculation vector, generating the first polynomial to generate the second polynomial sent to the verifier; based on the verifier, detecting whether the first preset correctness check condition is satisfied according to the second polynomial, if not, terminating the protocol, otherwise the verifier and the prover call the preset batch inner product argument for consistency check, and if the batch zero-knowledge inner product argument check fails, terminating the protocol, otherwise the verifier accepts the proof.

[0061] As a possible implementation, the embodiment of the present application can generate evidence for linear constraint check. The prover obtains the challenge vector r of the verifier, calculates the vector a = rA, and then generates the polynomial a i (·), where a i represents the i-th component of the vector a, For i ∈ [h1], j ∈ [h2], denote the set before row encoding as whose size is h2, and the encoded set is whose size is For Let Finally, the prover calculates the polynomial q(·), that is:

[0062]

[0063] Furthermore, the embodiment of the present application sends the polynomial q(·) to the verifier.

[0064] Then, the embodiment of the present application can perform correctness check. When the verifier receives the polynomial q(·), check whether there is If not, terminate the protocol, otherwise the verifier performs the consistency check in the following steps.

[0065] Finally, the embodiment of the present application performs consistency check. The verifier and the prover call the batch inner product argument of the embodiment of the present application for consistency check. The prover inputs multiple groups of inner product relationships to be proved, that is:

[0066]

[0067] Among them, is a set of inner product relations.

[0068] When the batch zero-knowledge inner product argument check fails, the protocol is terminated; otherwise, the verifier accepts the proof.

[0069] In summary, in the embodiment of the present application, by designing a batch inner product argument protocol, the communication complexity of the protocol is effectively reduced, the utilization rate of the communication bandwidth is improved, and the latency of the system is reduced.

[0070] It should be noted that the first preset correctness check condition and the preset batch inner product argument are set by those skilled in the art according to the actual situation, and no specific limitation is made here.

[0071] In step S103, in the quadratic constraint check stage, evidence for the quadratic constraint check is generated, and verifier consistency check and verifier correctness check are performed to detect whether any second encoded vector satisfies the second preset check condition.

[0072] It can be understood that in the embodiment of the present application, in the quadratic constraint check stage, evidence for the quadratic constraint check can be generated, and verifier consistency check and verifier correctness check are performed to detect whether any second encoded vector satisfies the second check condition. For example, it can be checked whether a vector encoded as satisfies x⊙y - z = 0, thereby effectively improving the accuracy and reliability of the quadratic constraint check stage.

[0073] It should be noted that the second preset check condition is set by those skilled in the art according to the actual situation, and no specific limitation is made here.

[0074] Optionally, in an embodiment of the present application, in the quadratic constraint check stage, evidence for the quadratic constraint check is generated, and verifier consistency check and verifier correctness check are performed to detect whether any second encoded vector satisfies the second preset check condition, including: based on the prover, obtaining the third challenge vector of the verifier and calculating the third polynomial; based on the verifier, detecting whether the second preset correctness check condition is satisfied according to the third polynomial. If not, the protocol is terminated; otherwise, the prover and the verifier call the preset batch zero-knowledge inner product argument protocol for consistency check, and if the batch zero-knowledge inner product argument check fails, the protocol is terminated; otherwise, the verifier accepts the proof.

[0075] In some embodiments, the embodiments of the present application can generate secondary constraint evidence. The prover obtains the challenge vector r of the verifier and calculates the polynomial q(·), that is:

[0076]

[0077] where

[0078]

[0079] Furthermore, the embodiments of the present application send the polynomial q(·) to the verifier.

[0080] Next, the embodiments of the present application can perform a correctness check. After receiving the polynomial q(·), the verifier checks whether q(ξ j ) = 0 holds for all j ∈ [h2]. If it does not hold, the protocol is terminated. Otherwise, a consistency check in the following steps is performed.

[0081] Finally, the embodiments of the present application can perform a consistency check. It can be defined that U[j] = U x [j] ⊙ U y [j] - U z [j], j ∈ [l2]. The prover and the verifier call the batch zero-knowledge inner product argument protocol for consistency check. The prover inputs multiple groups of inner product relations to be proved, that is:

[0082]

[0083] where q(η i ) = <r, U[i]> is a group of inner product relations.

[0084] When the batch zero-knowledge inner product argument protocol fails, the protocol is terminated. Otherwise, the verifier accepts the proof.

[0085] In summary, the embodiments of the present application use zero-knowledge batch processing technology to achieve zero-knowledge while ensuring low communication volume, effectively reducing the communication complexity of the existing zero-knowledge proof system, reducing redundant overhead, and saving computing resources.

[0086] It should be noted that the second preset correctness check condition is set by those skilled in the art according to the actual situation and is not specifically limited herein.

[0087] For example, as Figure 2 shown, the working principle of the embodiments of the present application is elaborated in detail below with a specific embodiment.

[0088] Step S1: Convert the arithmetic circuit into a statement to be proved.

[0089] The prover arranges the input and output line values corresponding to all the multiplication gates in the arithmetic circuit C into an extended proof For example, let n be the number of input line values of the multiplication gate, s be the number of output line values of the multiplication gate, and the input line values of the entire circuit be α1, …, α n , and the output line values of each multiplication gate be β1, …, β s , then:

[0090]

[0091] Among them, n represents the number of input line values of the multiplication gate, and s represents the number of output line values of the multiplication gate.

[0092] Denote x as the vector formed by arranging the left inputs of each multiplication gate, y as the vector formed by arranging the right inputs of each multiplication gate, and z as the vector formed by arranging the outputs of each multiplication gate. There are:

[0093]

[0094] The prover constructs matrices according to the circuit structure:

[0095] P x w T = x, P y w T = y, P z w T = z,

[0096] Construct matrices:

[0097]

[0098] Step S2: Generate the encoding matrix and the oracle matrix algorithm.

[0099] Algorithm input: w is the secret row vector to be encoded, and H1, H2, L1, L2 are multiplication cosets. Let |H1| = h1, |H2| = h2, and assume h1h2 ≥ |w|.

[0100] Step S21: Arrange w into a matrix w of size h1 × h2. Specifically, fill 0 on the right side of w until the length reaches h1h2, and then serve as the j-th row of matrix W.

[0101] Step S22: Encode each row of W as RS[L2, h2 / l2]. Among them, RS represents Reed - Solomon encoding, and denote the encoded matrix as the encoding matrix U w .

[0102] Step S23: For U wEach column of is encoded as RS[L1, h1 / l1], and this matrix is denoted as the oracle matrix

[0103] Similarly, the prover also generates the corresponding encoding matrices U for x, y, z x , U y , U z and the oracle matrix

[0104] Step S3: IRS Interleaved Reed - Solomon Coding Check Algorithm

[0105] Algorithm purpose: Prove that U w , U x , U y , U z is an IRS code. This protocol runs four times. Here, U w is taken as an example

[0106] Algorithm input:

[0107] Step S31: The prover generates the oracle matrix Perform Merkle commitment on each row of the matrix and give the root node of the Merkle tree to the verifier. Denote this step as

[0108] Step S32: The verifier selects a random vector and sends it to the prover

[0109] Step S33: The prover calculates the vector v ← rU w and sends it to the verifier

[0110] Step S34: The verifier checks whether there is If not, terminate the protocol; otherwise, continue to the next step

[0111] Step S35: The prover and the verifier jointly call the batch zero - knowledge inner product argument protocol. Input:

[0112]

[0113] When the batch zero - knowledge inner product argument protocol fails, terminate the protocol; otherwise, the verifier accepts U w as an IRS code

[0114] Step S4: Linear Check Algorithm

[0115] Algorithm purpose: Check whether an encoded vector satisfies P x w T = x T , Py w T = y T , P z w T = z T , where P is checked x w T = x T , that is, check [P x , -I][w T , x T = 0 as an example to illustrate the detailed process. Other checks are similar to this check.

[0116] Algorithm input:

[0117] Step S41: The verifier selects a random vector and sends it to the prover.

[0118] Step S42: Both the prover and the verifier calculate the vector a ← r[P x , -I] and generate a polynomial a i (·), where Then let

[0119] Step S43: The prover calculates and sends it to the verifier.

[0120] Step S44: The verifier checks whether there is When it does not hold, the protocol is terminated. Otherwise, proceed to the next step.

[0121] Step S45: The prover and the verifier jointly call the batch zero - knowledge inner product argument protocol, input:

[0122]

[0123] If the batch zero - knowledge inner product argument protocol fails, the protocol is terminated. Otherwise, the verifier accepts the proof.

[0124] Step S5: Quadratic check algorithm.

[0125] Algorithm purpose: For vectors x , U y , U z encoded as whether it satisfies x ⊙ y - z = 0.

[0126] Algorithm input:

[0127]

[0128] And the algorithm can prove U x ⊙ Uy -U z = 0.

[0129] Step S51: The verifier selects a random vector and sends it to the prover.

[0130] Step S52: The prover constructs a polynomial and sends it to the verifier, where

[0131] Step S53: The verifier checks whether for any j ∈ [h2], q(ξ j ) = 0. If not satisfied, the protocol is terminated; otherwise, proceed to the next step.

[0132] Step S54: Let The prover and the verifier jointly call the batch zero - knowledge inner - product argument protocol, with inputs:

[0133]

[0134] If the batch zero - knowledge inner - product argument protocol fails, the protocol is terminated; otherwise, the verifier accepts the proof.

[0135] In summary, the embodiments of the present application can transform an arithmetic circuit into three - item constraint conditions and check them one by one. Among them, each check includes a correctness check and a consistency check. In the consistency check, the batch zero - knowledge proof protocol can be used to complete the proof of multiple groups of inner - product relationships at one time, effectively reducing the communication complexity of the protocol, reducing the system latency, and improving the utilization rate of the communication bandwidth.

[0136] For example, in the embodiments of the present application, the batch zero - knowledge inner - product argument protocol design can be carried out first.

[0137] That is to say, in the single - variable summation verification protocol of the embodiments of the present application, if f(x) = v(x)·u(x) is set, the following can be obtained:

[0138] ∑ a∈H v(a)u(a) = <v| H , u| H >,

[0139] where v| H represents the evaluation vector of the polynomial v(·) on H, and u| H represents the evaluation vector of the polynomial u(·) on H.

[0140] Actually, it is the proof of the inner - product relationship. That is, assuming is a secret vector, is a public vector, and the prover needs to prove to the verifier that Among them, y is a public value.

[0141] Next, in order to implement the batch inner product argument protocol, the embodiments of the present application can utilize the linear combination of Reed-Solomon (RS) codes, and still based on the properties of Reed-Solomon codes, run the univariate summation verification on the random linear combination of multiple polynomials.

[0142] Specifically, the prover first encodes the vector group (v1, …, v t ), and generates commitments for the encoded vector group (v1| L , …, v t | L ). Then the verifier selects a random challenge Finally, both parties call the univariate summation verification protocol to prove that:

[0143]

[0144] If for some k ∈ [t], <u k , v k > ≠ y k , the probability that the univariate summation verification protocol passes is only

[0145] Secondly, the embodiments of the present application can batch the inner product relationship definition.

[0146] That is to say, is a set that contains all , where is a finite field, L and H are 's multiplicative cosets and |L| > 2|H|, actually represents a set of inner product relationships, that is, for each j ∈ [t], it satisfies the inner product relationship <v j , u j > = j .

[0147] Finally, the process of the batch zero-knowledge inner product argument protocol in the embodiments of the present application. Table 1 is the step table of the batch zero-knowledge inner product argument protocol process, and the specific Table 1 is as follows:

[0148] Table 1

[0149]

[0150] For another example, as can be seen from the above steps, the statement to be proved is The embodiments of the present application can elaborate on the process of the batch zero-knowledge inner product argument protocol in combination with Table 1.

[0151] 1) The prover encodes the secret vector and the public vector.

[0152] For all j ∈ [t]:

[0153] Let u j (x) ← IFFT(u j , H), u j | L ← FFT(u j (x), L),

[0154] Let v j (x) ← IFFT(v j , H),

[0155] Select a random polynomial δ (x) of degree j ,

[0156] where represents the size of the number of oracle accesses by the verifier in the FRI protocol.

[0157] Let

[0158] where [t] represents the set {1, 2, 3…, t}, FFT(u j (x), ) represents the fast Fourier transform of the polynomial u j (x) on L, and IFFT(u j , H) represents the inverse fast Fourier transform of u j on H.

[0159] 2) The verifier encodes the public vector.

[0160] For all j ∈ [t]:

[0161] Let u j (x) ← IFFT(u j , H), u j | L ← FFT(u j (x), L).

[0162] 3) The prover commits to the secret vector.

[0163] Randomly select a polynomial γ(x) of degree ,

[0164] Let Γ ← ∑ a∈H γ(a), γ | L ← FFT(γ(x), L),

[0165] Denote

[0166] Record

[0167] The prover sends Γ, to the verifier.

[0168] Among them, Γ represents the point value sum of the function γ(x) on the interval H, represents the root of the Merkle tree commitment after calling (v′1| L ,…,v′ t | L,γ | L ).

[0169] 4) The verifier selects a random vector as a challenge and sends it to the prover.

[0170] 5) The prover calculates

[0171] Then, decompose q(x) into

[0172] Record

[0173] Let h| l ←FFT(h(x),L),

[0174] Send the commitment to the verifier.

[0175] Among them, represents the root of the Merkle commitment after calling the evaluation vector of the polynomial h(·) on L.

[0176] 6) The prover and the verifier jointly call the FRI sub-protocol, where FRI is a fast Reed-Solomon coding interactive proof.

[0177] The prover inputs (q(x),h(x),p(X)),

[0178] The verifier inputs

[0179] The verifier sets the position and sends it to the prover.

[0180] 7) The prover opens the commitment, that is, the Merkle commitment opening algorithm for the vector.

[0181] Let

[0182] Let

[0183] Then send to the verifier.

[0184] 8) The verifier checks the commitment, i.e., the Merkle commitment verification algorithm for the vector.

[0185] Check

[0186] Check

[0187] If the verification is successful, accept the proof; otherwise, terminate the protocol.

[0188] In summary, the embodiments of the present application can effectively reduce the number of executions of the inner product argument protocol in the existing zero-knowledge proof system protocol, save computing resources, reduce the latency of the system, and ensure zero-knowledge under low communication volume.

[0189] According to the zero-knowledge proof method applicable to blockchain proposed by the embodiments of the present application, during the stage where the prover submits evidence and the verifier checks the evidence, it can detect whether any encoding matrix after encoding a vector of a certain length is an interleaved Reed-Solomon code. During the linear constraint checking stage, generate evidence for linear constraint checking, and perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies the first constraint checking condition. During the quadratic constraint checking stage, generate evidence for quadratic constraint checking, and perform verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies the second checking condition, thereby effectively reducing the communication complexity of the existing zero-knowledge proof system, reducing redundant overhead, and saving computing resources. Thus, it solves the technical problem in the related art that when the classical zero-knowledge proof protocol Ligero++ is applied to blockchain, to achieve multiple inner product relation checks in consistency checking, the computing overhead increases, and to achieve zero-knowledge, the actual proof scale is large and computing resources cannot be saved.

[0190] Secondly, a zero-knowledge proof device applicable to blockchain proposed according to the embodiments of the present application is described with reference to the accompanying drawings.

[0191] Figure 3 It is a block diagram of a zero-knowledge proof device applicable to blockchain according to the embodiments of the present application.

[0192] As Figure 3 shown, the zero-knowledge proof device 10 applicable to blockchain includes: a detection module 100, a first generation module 200, and a second generation module 300.

[0193] Specifically, the detection module 100 is used to detect whether any encoding matrix after encoding a vector of a preset length is an interleaved Reed-Solomon code during the stage where the prover submits evidence and the verifier checks the evidence.

[0194] The first generation module 200 is used to generate evidence for linear constraint checking during the linear constraint checking phase, and perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies the first preset constraint checking condition.

[0195] The second generation module 300 is used to generate evidence for quadratic constraint checking during the quadratic constraint checking phase, and perform verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies the second preset checking condition.

[0196] Optionally, in an embodiment of the present application, the detection module 100 includes: a calculation unit and a first detection unit.

[0197] Among them, the first calculation unit is used to arrange the secret row vectors into an extended evidence matrix based on the prover, encode the extended evidence matrix into an oracle matrix using Reed-Solomon coding, and commit each column of the oracle matrix using a Merkle tree, so as to send the calculation vector obtained from the first challenge vector selected by the verifier to the verifier.

[0198] The first detection unit is used to detect whether the calculation vector is a Reed-Solomon code based on the verifier. If not, the protocol is terminated. Otherwise, a batch zero-knowledge inner product argument is run to verify whether the inner product of each column of the oracle matrix and the first challenge vector is equal to the corresponding component of the calculation vector.

[0199] Optionally, in an embodiment of the present application, the first generation module includes: a generation unit and a second detection unit.

[0200] Among them, the generation unit is used to obtain the second challenge vector of the verifier based on the prover, obtain the second calculation vector, and generate the first polynomial, so as to generate the second polynomial sent to the verifier.

[0201] The second detection unit is used to detect whether the first preset correctness checking condition is satisfied based on the second polynomial by the verifier. If not, the protocol is terminated. Otherwise, the verifier and the prover call a preset batch inner product argument for consistency checking, and if the batch zero-knowledge inner product argument check fails, the protocol is terminated. Otherwise, the verifier accepts the proof.

[0202] Optionally, in an embodiment of the present application, the second generation module includes: a calculation unit and a third detection unit.

[0203] Among them, the second calculation unit is used to obtain the third challenge vector of the verifier based on the prover and calculate the third polynomial.

[0204] A third detection unit, configured to, based on a verifier, detect whether a second preset correctness check condition is satisfied according to a third polynomial. If not, the protocol is terminated. Otherwise, the prover and the verifier call a preset batch zero-knowledge inner product argument protocol to perform a consistency check. And if the batch zero-knowledge inner product argument check fails, the protocol is terminated. Otherwise, the verifier accepts the proof.

[0205] It should be noted that the foregoing explanations of the embodiments of the zero-knowledge proof method applicable to blockchain also apply to the zero-knowledge proof device applicable to blockchain in this embodiment, and will not be elaborated here.

[0206] The zero-knowledge proof device applicable to blockchain proposed according to the embodiments of the present application can, in the stage where the prover submits evidence and the verifier checks the evidence, detect whether any encoding matrix after encoding a vector of a certain length is an interleaved Reed-Solomon code. In the linear constraint check stage, generate evidence for linear constraint check, and perform verifier consistency check and verifier correctness check to detect whether any first encoded vector satisfies the first constraint check condition. In the quadratic constraint check stage, generate evidence for quadratic constraint check, and perform verifier consistency check and verifier correctness check to detect whether any second encoded vector satisfies the second check condition, thereby effectively reducing the communication complexity of the existing zero-knowledge proof system, reducing redundant overhead, and saving computing resources. Thus, the technical problem in the related art is solved that when the classical zero-knowledge proof protocol Ligero++ is applied to blockchain, in order to implement multiple inner product relation checks in consistency check, the computing overhead increases, and in order to achieve zero-knowledge property, the actual proof scale is large and computing resources cannot be saved.

[0207] Figure 4 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. The electronic device may include:

[0208] A memory 401, a processor 402, and a computer program stored on the memory 401 and executable on the processor 402.

[0209] When the processor 402 executes the program, it implements the zero-knowledge proof method applicable to blockchain provided in the above embodiment.

[0210] Further, the electronic device further includes:

[0211] A communication interface 403, configured for communication between the memory 401 and the processor 402.

[0212] The memory 401 is used to store a computer program executable on the processor 402.

[0213] The memory 401 may include high-speed RAM memory and may also include non-volatile memory, such as at least one disk memory.

[0214] If the memory 401, the processor 402, and the communication interface 403 are implemented independently, the communication interface 403, the memory 401, and the processor 402 can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0215] Optionally, in a specific implementation, if the memory 401, the processor 402, and the communication interface 403 are integrated on a single chip, the memory 401, the processor 402, and the communication interface 403 can communicate with each other through an internal interface.

[0216] The processor 402 may be a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0217] The embodiments of the present application also provide a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the zero-knowledge proof method applicable to the blockchain as described above is implemented.

[0218] In the description of this specification, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc., mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0219] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of these features. In the description of this application, the meaning of "N" is at least two, such as two, three, etc., unless otherwise specifically defined.

[0220] Any process or method description depicted in a flowchart or otherwise described herein can be understood to represent a module, segment, or portion of code including one or N executable instructions for implementing a customized logical function or process, and the scope of the preferred embodiments of this application includes additional implementations where the functions may be executed in a substantially simultaneous manner or in the reverse order according to the functions involved, rather than in the order shown or discussed, which should be understood by those skilled in the art to which the embodiments of this application pertain.

[0221] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a definite sequence list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in conjunction with these instruction execution systems, apparatus, or devices. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection part (electronic device) having one or N wirings, a portable computer disk cartridge (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically by optically scanning the paper or other media, followed by editing, interpretation, or otherwise processing it as appropriate, and then storing it in a computer memory.

[0222] It should be understood that various parts of the present application can be implemented by hardware, software, firmware, or a combination thereof. In the above-described embodiments, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application-specific integrated circuits having suitable combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), and the like.

[0223] Those of ordinary skill in the art of this technology can understand that all or part of the steps carried by the method of implementing the above embodiments can be completed by instructing relevant hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0224] In addition, each functional unit in various embodiments of the present application may be integrated into one processing module, may exist separately physically for each unit, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0225] The above-mentioned storage medium may be a read-only memory, a magnetic disk, an optical disc, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present application. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. A zero-knowledge proof method applicable to blockchain, characterized in that Including the following steps: In the stage where the prover submits evidence and the verifier checks the evidence, detect whether any encoding matrix after encoding a vector of a preset length is an interleaved Reed - Solomon code; In the linear constraint checking stage, generate evidence for linear constraint checking, and perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies a first preset constraint checking condition. Among them, in the linear constraint checking stage, generating evidence for linear constraint checking to perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies a first preset constraint checking condition includes: based on the prover, obtain a second challenge vector of the verifier, and obtain a second calculation vector, generate a first polynomial, so as to generate a second polynomial sent to the verifier; based on the verifier, detect whether it satisfies a first preset correctness checking condition according to the second polynomial. If it does not satisfy, terminate the protocol. Otherwise, the verifier and the prover call a preset batch inner - product argument for consistency checking. And if the batch zero - knowledge inner - product argument check fails, terminate the protocol. Otherwise, the verifier accepts the proof; and In the quadratic constraint checking stage, generate evidence for quadratic constraint checking, and perform verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies a second preset checking condition.

2. The method according to claim 1, wherein The step in the stage where the prover submits evidence and the verifier checks the evidence to detect whether any encoding matrix after encoding a vector of a preset length is an interleaved Reed - Solomon code includes: Based on the prover, arrange the secret row vectors into an extended evidence matrix, encode the extended evidence matrix into an oracle matrix using Reed - Solomon coding, and use a Merkle tree to commit to each column of the oracle matrix, so as to send the calculation vector obtained from the first challenge vector selected by the verifier to the verifier; Based on the verifier, detect whether the calculation vector is a Reed - Solomon code. If not, terminate the protocol. Otherwise, run a batch zero - knowledge inner - product argument to verify whether the inner - product of each column of the oracle matrix and the first challenge vector is equal to the corresponding component of the calculation vector.

3. The method according to claim 1, characterized in that, The step in the quadratic constraint checking stage to generate evidence for quadratic constraint checking and perform verifier consistency checking and verifier correctness checking to detect whether any second encoded vector satisfies a second preset checking condition includes: Based on the prover, obtain a third challenge vector of the verifier and calculate a third polynomial; Based on the verifier, detect whether it satisfies a second preset correctness checking condition according to the third polynomial. If it does not satisfy, terminate the protocol. Otherwise, the prover and the verifier call the preset batch zero - knowledge inner - product argument protocol for consistency checking. And if the batch zero - knowledge inner - product argument check fails, terminate the protocol. Otherwise, the verifier accepts the proof.

4. A zero-knowledge proof device applicable to a blockchain, characterized in that: Including: A detection module, configured to detect whether any encoding matrix encoded from a vector of a preset length is an interleaved Reed-Solomon code during the stage where the prover submits evidence and the verifier checks the evidence; A first generation module, configured to generate evidence for linear constraint checking and perform verifier consistency checking and verifier correctness checking during the linear constraint checking stage to detect whether any first encoded vector satisfies a first preset constraint checking condition. Wherein, during the linear constraint checking stage, generating evidence for linear constraint checking to perform verifier consistency checking and verifier correctness checking to detect whether any first encoded vector satisfies a first preset constraint checking condition includes: based on the prover, obtaining a second challenge vector of the verifier, obtaining a second calculation vector, generating a first polynomial, and generating a second polynomial to be sent to the verifier; based on the verifier, detecting whether the first preset correctness checking condition is satisfied according to the second polynomial, if not, terminating the protocol, otherwise the verifier and the prover call a preset batch inner product argument for consistency checking, and if the batch zero-knowledge inner product argument check fails, terminating the protocol, otherwise the verifier accepts the proof; and A second generation module, configured to generate evidence for quadratic constraint checking and perform verifier consistency checking and verifier correctness checking during the quadratic constraint checking stage to detect whether any second encoded vector satisfies a second preset checking condition.

5. The device according to claim 4, characterized in that, The detection module includes: A first calculation unit, configured to, based on the prover, arrange the secret row vectors into an extended evidence matrix, encode the extended evidence matrix into an oracle matrix using Reed-Solomon coding, and commit to each column of the oracle matrix using a Merkle tree, so as to send the calculation vector obtained from the first challenge vector selected by the verifier to the verifier; A first detection unit, configured to, based on the verifier, detect whether the calculation vector is a Reed-Solomon code, if not, terminating the protocol, otherwise running a batch zero-knowledge inner product argument to verify whether the inner product of each column of the oracle matrix and the first challenge vector is equal to the corresponding component of the calculation vector.

6. The device according to claim 4, characterized in that, The second generation module includes: A second calculation unit, configured to, based on the prover, obtain a third challenge vector of the verifier and calculate a third polynomial; A third detection unit, configured to, based on the verifier, detect whether the second preset correctness checking condition is satisfied according to the third polynomial, if not, terminating the protocol, otherwise the prover and the verifier call the preset batch zero-knowledge inner product argument protocol for consistency checking, and if the batch zero-knowledge inner product argument check fails, terminating the protocol, otherwise the verifier accepts the proof.

7. An electronic device, characterized in that, Includes: A memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor executes the program to implement the zero-knowledge proof method applicable to a blockchain according to any one of claims 1-3.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the zero-knowledge proof method applicable to a blockchain as described in any one of claims 1-3.

Images