Delegation of proof calculations

Abstract

The delegation of proof computation is disclosed and comprises: receiving private and public input data in a first processor to generate a computationally intensive proof associated with a transaction posted to the blockchain; performing a first proof computation in the first processor based at least in part on the private and public input data to generate an intermediate proof state; and transmitting the intermediate proof state from the first processor to a second processor, the second processor being configured to perform a second proof computation based at least in part on the intermediate proof state to generate a computationally intensive proof associated with a transaction, and deriving private input data from the intermediate proof state is computationally impossible for the second processor.

Description

Cross-references to other applications

[0001] This application claims priority under U.S. Patent Application No. 18 / 583,378, filed February 21, 2024, entitled "DELEGATION OF PROOF COMPUTATION," and U.S. Provisional Patent Application No. 63 / 472,482, filed June 12, 2023, entitled "DELEGATION OF PROOF COMPUTATION," which are incorporated herein by reference for all purposes. [Background technology]

[0002] The generation of proofs, which can be used to verify that a requested transaction is actually permitted by the initiating party, can be computationally intensive. Therefore, proof generation is not suitable for devices that cannot reasonably support such computations, especially when performed alongside other processes that are expected to run efficiently. In some conventional systems, computationally intensive proof generation can be delegated from the transaction initiator's device to another system with more computing resources. However, in this conventional type of delegation, any private (e.g., confidential) data entered into the transaction (e.g., by the transaction initiator) is also distributed among the one or more entities to which proof generation is delegated. Therefore, it is desirable to delegate proof generation efficiently while maintaining the security of any private input data to the transaction. [Brief explanation of the drawing]

[0003] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings.

[0004] [Figure 1] A diagram illustrating one embodiment of a system for the delegation of certification.

[0005] [Figure 2]A diagram showing an example of a client device for commissioning a proof according to some embodiments.

[0006] [Figure 3] A diagram showing an example of a prover system for receiving a commission of a proof according to some embodiments.

[0007] [Figure 4] A diagram describing a framework in which a client device commissions a part of the calculation of a proof associated with a transaction to a single third-party prover according to some embodiments.

[0008] [Figure 5] A flowchart showing an embodiment of a process for commissioning proof generation.

[0009] [Figure 6] A flowchart showing an example of a process for performing a first proof calculation (pre-calculation) according to some embodiments.

[0010] [Figure 7] A flowchart showing an example of a process for performing a first proof calculation (pre-calculation) according to some embodiments.

[0011] [Figure 8] A flowchart showing an example of a process for performing a second proof calculation according to some embodiments.

[0012] [Figure 9] A flowchart showing an example of a process for completing a complete proof according to some embodiments.

[0013] [Figure 10] A diagram showing a schematic explanation of a client device commissioning a part of a proof calculation to a single prover according to some embodiments.

[0014] [Figure 11] A sequence diagram illustrating an example of the process of delegating certificate generation from a client device to a certificater system, according to several embodiments.

[0015] [Figure 12] A sequence diagram illustrating an example of the process for verifying a proof according to several embodiments. [Modes for carrying out the invention]

[0016] The present invention can be implemented in various forms, including processes, apparatus, systems, compositions of materials, computer program products embodied on computer-readable storage media, and / or processors (processors configured to execute instructions stored and / or provided by memory connected to the processor). In this specification, these embodiments or any other forms the present invention may take may be referred to as "technologies." Generally, the order of the processes of the disclosed processes may be modified within the scope of the invention. Unless otherwise specified, components such as processors or memory described as configured to perform a task may be implemented as general components temporarily configured to perform a task at a given time, or as specific components manufactured to perform a task. In this specification, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data such as computer program instructions.

[0017] The following provides a detailed description of one or more embodiments of the present invention, with reference to drawings illustrating the principles of the present invention. While the present invention is described in relation to such embodiments, it is not limited to any of these embodiments. The scope of the present invention is limited only by the claims, and the present invention includes many substitutes, variations, and equivalents. The following description includes many specific details to provide a complete understanding of the present invention. These details are illustrative, and the present invention can be implemented in accordance with the claims without some or all of these specific details. For simplicity, technical matters well known in the art related to the present invention are not described in detail, so as not to complicate the present invention unnecessarily.

[0018] Embodiments of delegation of proof computation are described herein. Private and public input data are received by a first processor to generate a computationally intensive proof associated with a transaction to be posted to the blockchain. For example, the first processor belongs to a client device used by a user selected to initiate a transaction (e.g., via a software application running on the client device) for purposes such as transferring tokens to a recipient. In order for this transaction to be added to the blockchain, a computationally intensive proof is generated that proves the initiator actually authorized the transaction and is then sent to the blockchain network along with the transaction information. In various embodiments, the computationally intensive proof is a “zero-knowledge” type proof. In various embodiments, both public and private data input to a transaction are involved in the generation of the computationally intensive proof. In various embodiments, “private input data” or “private data” is sensitive information that is to be kept secure / confidential with respect to the proofer system, which is the system to which the generation of the computationally intensive proof is delegated. A first proof computation, at least in part on the private and public input data, is performed by the first processor to generate an intermediate proof state. As will be detailed later, the “first proof computation” is also called the “pre-computation” of the proof. The first proof computation (i.e., the “pre-computation”) is performed locally on the device on which the transaction is requested, using private and public input data. The intermediate proof state is sent to a second processor, which is configured to perform the second proof computation based at least partially on the intermediate proof state to generate the completed / full aggregate proof associated with the transaction. Deriving the private input data from the intermediate proof state is computationally impossible for the second processor.After the intermediate proof state is sent to the second processor (belonging to the proof system) to delegate the remainder of the proof calculation to the second processor, the second processor executes the remainder of the proof calculation and constructs the complete proof. The intermediate proof state (which is sent from the first processor to the second processor) has the characteristic that it cannot be used to reverse-analyze the private input data until the security of the private data input to the first proof calculation / pre-computation has been achieved. In other words, the recipient of the intermediate proof state (e.g., the second processor) cannot recover the private input data to the transaction from the intermediate proof state. After the second processor has computed the second proof calculation, it can combine at least part of the intermediate proof state and the results of the second proof calculation to generate a completed / complete proof. The second processor can then send the generated completed / complete proof, along with the information associated with the transaction, to the blockchain so that blockchain nodes can add the transaction to the blockchain after verifying the transaction based on the proof.

[0019] Figure 1 shows one embodiment of a system for delegating certificate delegation. As shown in Figure 1, the system 100 comprises a client device 102, a certificate system 104, a network 106, and a blockchain network 108. The network 106 includes a data network and / or a telecommunications network.

[0020] The client device 102 is configured to execute computer program code associated with a standalone software application or a web browser-based application configured to manage accounts involved in transactions on blockchain 108. An example of the client device 102 could be a mobile device, laptop computer, desktop computer, tablet device, or any other computer device. A user (not shown) may interact with a user interface associated with the application running on the client device 102 to open a new account. In response to user input to initiate / request a transaction on blockchain 108, the application running on the client device 102 is configured to perform actions that result in information about the transaction being sent to blockchain 108. In the first example, the type of requested transaction is a deployment transaction, which involves deploying a new program containing a set of functions onto blockchain 108. For example, the newly deployed set of programs / functions will be used in future transactions. In the second example, the type of requested transaction is an execution transaction, which involves executing a previously deployed program / function. For example, an execution transaction might be used to execute a previously deployed program / function for the purpose of achieving a token transfer between two accounts on blockchain 108. In various embodiments, in response to a request from an execution transaction, the application running on the client device 102 is configured to retrieve user input data and functions associated with the transaction.

[0021] In various embodiments, an execution transaction requires the generation of a computationally intensive / computationally charged proof to prove the identity of the transaction initiating user. In various embodiments, the type of proof computed in a “zero-knowledge proof” (also known as a “zkp”) is a proof that proves to a receiving party that a given statement is true (e.g., that the transaction is actually authorized by the specified account holder) without revealing the underlying statement itself. The generation of a zero-knowledge proof is often impossible to complete on the client device 102 where the execution transaction is initiated due to the limited amount of computational resources available to the client device 102. For example, the computation of a zero-knowledge proof on the client device 102 may monopolize more than the desired proportion of the client device 102's computational resources to the extent that the client device 102 cannot complete other desired functions. Therefore, the various embodiments described herein allow for the partial delegation of the zero-knowledge proof computation from the device where the execution transaction is initiated (e.g., client device 102) to a third-party certifier system (e.g., certifier system 104) with relatively large computational resources. By delegating some of the computation / generation of zero-knowledge proofs as described herein, client device 102 can begin computation / generation of proofs without needing to possess sufficient computational resources to complete the proof itself.

[0022] In various embodiments, at least a portion of the user input data to the execution transaction may be confidential data or data that the user wishes to keep secret in some other form. Examples of private data may be personally identifiable information and / or financial history information. In other words, this “private” input data to the execution transaction is not intended to be shared with or distributed to any entity other than the client device 102, and therefore, the private input user data is not intended to be sent to the certifier system 104 when the zero-knowledge proof is delegated. Various embodiments described herein provide private input data that is used locally on the client device 102 for the pre-computation of the zero-knowledge proof but is not shared with the certifier system 104 when the generation of the rest of the proof is delegated to the certifier system 104. As will be detailed later, the pre-computation of the zero-knowledge proof using the private input data on the client device 102 results in an intermediate proof state, which is sent by the client device 102 to the certifier system 104 via the network 105 for the certifier system 104 to use to complete the full zero-knowledge proof. However, even though the intermediate proof state is partially derived from private input data, it cannot be used to reconstruct the private input data. Thus, the proofer system 104 can then use the intermediate proof state to complete the generation of a complete zero-knowledge proof without knowing the private input data for the execution transaction.

[0023] After the zero-knowledge proof generation is complete, the proofing system 104 is configured to send the proof to the blockchain 108 along with other (public) information about the executed transaction. In some embodiments, after the proofing system 104 has completed the proof, it may send the complete proof to the client device 102 so that the client device 102 can send the proof to the blockchain 108 along with public information about the executed transaction. The blockchain nodes verify the received zero-knowledge proof before adding the transaction (e.g., the output record of the transaction) to the ledger.

[0024] As described herein, in various embodiments, sensitive private input user data stored locally on a client device may be used to compute the first part (also called "pre-computation") of a proof (e.g., a zero-knowledge proof) on the client device (e.g., a device with relatively fewer computational resources than the prover system). In some embodiments, the proof is associated with a transaction that is ultimately recorded on a blockchain. In various embodiments, the proof protocol is selected such that the pre-computation of the first part of the proof performed on the client device is less computationally intensive than the remaining second part of the proof performed by the prover system. The remaining second part of the proof can then be delegated from the client device to the prover system by providing at least the function used to compute the first part of the proof on the client device, and potentially at least a portion of the first part of the proof. Advantageously, the client device does not need to pass on any sensitive private input user data used to compute the first part of the proof to the prover system. The first part of the proof and the remaining second part of the proof can be combined (e.g., by the prover) to construct a complete proof. Next, the entity generating the complete proof can send the complete proof to the blockchain network to associate it with a transaction. The blockchain network can then verify the transaction by verifying the complete proof.

[0025] Figure 2 shows an example of a client device for delegating proof according to several embodiments. In some embodiments, the client device 102 in Figure 1 may be implemented using the example client device in Figure 2. As shown in Figure 2, the client device comprises a transaction initiation engine 202, a proof pre-computation engine 204, and a proofer interface 206. Each of the transaction initiation engine 202, the proof pre-computation engine 204, and the proofer interface 206 may be implemented using software and / or hardware (e.g., a processor, a communication interface, memory).

[0026] The transaction initiation engine 202 is configured to receive requests for transactions to be posted to the blockchain. To initiate a transaction that will be verified by the blockchain, the user of the account enters the transaction-related parameters (input data) into the user interface of the application running on the client device. For example, if the transaction is an execution transaction associated with spending tokens associated with an account, the parameters associated with that transaction may include identification information associated with one or more verified records in the blockchain network that record what the new account holds. These verified records are included by the application as one or more input records within the transaction. Furthermore, in this example, the user input parameters also include at least the amount of tokens the user wishes to send to the receiving party, as well as at least one output record verified by the blockchain network that identifies the receiving party's account address, the program to be executed (a set of functions), and the amount of tokens to be sent to the receiving party, which are included in the transaction as output records by the application. In various embodiments, some parameters entered by the user for a transaction are considered "public," meaning they are permitted to be shared with other entities (such as a certificate system), while other parameters entered by the user for a transaction are considered "private," meaning they are restricted from being shared with other entities. In some embodiments, which parameters / input data are private or public may be determined based on the application / type of the transaction being executed. Specific examples of public input data may include the program / function to be executed, the serial number of the input record, blockchain identification information, and the user's credit score for the sender account.Specific examples of private input data may include the sender account's financial history, personally identifiable information of the sender account's user, the sender account's private account key, and the sender account's account address. For example, whether user input parameters are public or private may be determined based on predetermined rules (e.g., if the amount of tokens transferred in a transaction is greater than a predetermined amount, the token amount is designated as private user input within that transaction).

[0027] The proof pre-computation engine 204 is configured to pre-computate (Part 1) a zero-knowledge proof corresponding to an initiated / executed transaction, based on the transaction parameters (public and private input data). In this context, a "zero-knowledge proof" verifies that a transaction was initiated by the account holder / user who initiated the transaction without revealing the private input data to a verifier (e.g., a node on the blockchain network). A zero-knowledge proof protocol having the characteristic of being able to divide proof generation into a first private part that requires input data (including private input data) to the executed transaction and a second public part that does not directly require private input data is used to generate proofs in the various embodiments described herein. An example of a zero-knowledge proof protocol having this characteristic is the Marlin protocol. Thus, the proof pre-computation engine 204 is configured to perform Part 1 (pre-computation) of a zero-knowledge proof based on the public and private input data to the transaction. As will be detailed later, in some embodiments, performing the first part (pre-computation) of a zero-knowledge proof based on public and private input data to a transaction involves two sequential computation rounds (first and second rounds), where the private and public input data of the transaction are input to the first round, and the second round receives the output from the first round as input. A portion of the output from both the first and second rounds of the proof pre-computation by the proof pre-computation engine 204 is sent to the proof system via the network through the proof interface 206. This portion of the output from both the first and second rounds of the proof pre-computation is also called the “intermediate proof state”. In various embodiments, the intermediate proof state includes data that is specific to the transaction but is not available to reconstruct the private input data to the transaction.

[0028] The proof pre-computation engine 204 is configured to send a proof delegation request to the proofer system along with an intermediate proof state of the proof of the transaction that the proofer system is requested to complete. The receiving proofer system is then configured to complete the second / remaining portion of the zero-knowledge proof based on the intermediate proof state. For example, the proof delegation request may include public information about the transaction and identification information of the blockchain to which the transaction is posted.

[0029] Figure 3 shows an example of a certificate system for receiving delegation of proof according to several embodiments. In some embodiments, the certificate system 104 of Figure 1 may be implemented using the example of the certificate system of Figure 3. As shown in Figure 3, the certificate system comprises a client interface 302, a proof completion engine 304, and a blockchain interface 306. Each of the client device 302, the proof completion engine 304, and the blockchain interface 306 may be implemented using software and / or hardware (e.g., a processor, a communication interface, memory).

[0030] The client interface 302 is configured to receive certificate delegation and corresponding intermediate certificate status requests from the client device.

[0031] The proof completion engine 304 is configured to complete the zero-knowledge proof generation for each corresponding proof delegation request based on the intermediate proof state corresponding to the request. As will be detailed later, in some embodiments, the proof completion engine 304 uses at least a portion of the intermediate proof state associated with the transaction to perform two further sequential computations (third and fourth rounds), thereby inputting the intermediate proof state into the third round and receiving the output from the third round as input for the fourth round. In some embodiments, due to the characteristics of the zero-knowledge proof protocol used for proof delegation, the proof generation portion in the certifier system (e.g., the third and fourth rounds) is significantly more complex than the proof generation portion pre-computed on the client device. Thus, even though the proof is computed across the client device and the certifier system, the certifier system has to perform more complex computations and therefore uses more computing resources / processing power to complete the proof than is used on the client device during the pre-computation of the proof. After completing the third and fourth rounds of proof computation, the proof completion engine 304 is configured to generate a complete zero-knowledge proof based on at least a portion of the outputs from each of the first, second, third, and fourth calculation rounds. The outputs from the first and second calculation rounds included in the complete zero-knowledge proof are those received from the client device.

[0032] The blockchain interface 306 is configured to send a complete / completed zero-knowledge proof along with public information about the associated transaction to the blockchain network. Blockchain nodes verify the proof before confirming the transaction. For example, confirming a transaction involves adding an output record of the transaction to the blockchain ledger.

[0033] Figure 4 illustrates a framework in which, according to several embodiments, a client device delegates part of the calculation of the proof associated with a transaction to a single third-party certifier. The framework described in Figure 4 shows that private (e.g., confidential) input data associated with the requested transaction received by the client device (e.g., the private account key of the transaction initiator, the public address of the transaction recipient, the contents of the transaction's input and / or output records) is also used locally to generate an intermediate proof state for the proof corresponding to the transaction. However, such private input data is not passed from the client device to the third-party certifier system. Rather, the third-party certifier system receives only the intermediate proof state from the client device, and then uses it, along with the function associated with the transaction, to compute the complete proof associated with the transaction. The third-party certifier system can then send the complete proof to the blockchain over the network. The framework described in Figure 4 illustrates that the certifier system knows only the function associated with the transaction and not the private input data, which enables secure proof delegation with minimal information transfer.

[0034] Figure 5 is a flowchart illustrating one embodiment of the process for delegating proof generation. In some embodiments, the process 500 is performed, at least in part, on the client device 102 in Figure 1.

[0035] In step 502, private and public input data are received by the first processor to generate a computationally intensive proof associated with a transaction to be posted to the blockchain. The private and public input data are parameters for the execution transaction requested by the client device. In various embodiments, the computationally intensive proof is a zero-knowledge proof.

[0036] In step 504, a first proof computation is performed on a first processor, at least in part on private and public input data, to generate an intermediate proof state. In various embodiments, the zero-knowledge proof protocol used allows proof generation to be split into two computations such that the first proof computation requires private and public input data, and the second proof computation takes part of the output from the first proof computation but does not require private and public input data. As a result, the first proof computation (also called the “pre-computation”) based on the private and public input data of a transaction may be computed by a first processor that is local to a client device where the private and public input data may be stored or retrieved. The portion of the output of the first proof computation generated on the client device and sent over the network to a remote second processor (associated with the certifier system) is the “intermediate proof state”.

[0037] In step 506, the intermediate proof state is sent from the interface to the second processor, which is configured to perform a second proof computation at least partially based on the intermediate proof state to generate a computationally intensive proof associated with the transaction, and it is computationally impossible for the second processor to derive private input data from the intermediate proof state. The intermediate proof state includes data (e.g., a challenge) that is ultimately generated from the private input data and public input data but is not available to reconstruct the private input data. In other words, the intermediate proof state is transaction-specific data used by the second processor to perform the second proof computation to generate a complete proof. The proofer system can then send the completed proof, along with the public information of the transaction, to the blockchain for record-keeping, without knowing the private input data of the transaction.

[0038] Figure 6 is a flowchart showing an example of a process for performing a first proof calculation (pre-calculation) according to several embodiments. In some embodiments, process 600 is performed at least partially on the client device 102 in Figure 1. In some embodiments, steps 502 and 504 of process 500 in Figure 5 are performed using process 600 in Figure 6.

[0039] In step 602, a request to initiate a transaction is received. In various embodiments, the requested transaction includes an execution transaction. An example of an execution transaction is the transfer of a token from one account (for example, the account of the user who initiated the transaction) to another account.

[0040] In step 604, public and private input data associated with the transaction are received. In some embodiments, at least a portion of the public and private input data associated with the transaction may be entered by the user who initiated the transaction. In some embodiments, at least a portion of the public and private input data associated with the transaction may be stored locally on the client device from which the transaction was initiated. In some embodiments, at least a portion of the public and private input data associated with the transaction may be queried by the client device from which the transaction was initiated. The designation of data as public or private may be configurable by the user on the client device. Examples of private input data include the private account key of the transaction initiator, the public addresses of the transaction recipients, and the contents of the transaction's input and / or output records. Examples of public input data include identification information associated with the blockchain and identification information associated with the function executed for the transaction.

[0041] In step 606, the first proof computation of a zero-knowledge proof corresponding to a transaction is performed, at least in part, on the set of public input data, private input data, and functions associated with the transaction, where the execution of the first proof computation generates an intermediate proof state, from which the private input data cannot be recovered. In various embodiments, a series of multiple rounds of computation need to be performed in the zero-knowledge proof protocol. The first computation round takes the public and private input data of the transaction as input, and each subsequent round then takes at least a portion of the output from the previous round as input. In some embodiments, the first two rounds of the series of computation rounds are computed locally on the client device in the first proof computation (pre-computation) to generate an intermediate proof state. The intermediate proof state contains a portion of the output of the first and second rounds of computation performed on the client device and is transmitted from the client device to a remote certifier system over the network. The advantage of transmitting the intermediate proof state to the remote certifier system is that the certifier system can complete the zero-knowledge proof in the intermediate proof state without needing the private input data from which the intermediate proof state is derived. In other words, private input data never leaves the client device during the certificate delegation process.

[0042] Figure 7 is a flowchart showing an example of a process for performing a first proof calculation (pre-calculation) according to several embodiments. In some embodiments, process 700 is performed at least partially on the client device 102 in Figure 1. In some embodiments, step 606 of process 600 in Figure 6 is performed using process 700 in Figure 7.

[0043] In step 702, the set of functions associated with the transaction is synthesized into a function-associated arithmetic circuit. In a specific example of a token transfer transaction, three types of functions may be executed. The first function is for performing a token transfer from the sender account to the receiver account. The second function is for checking that the input value of the token in the transfer is equal to the output value of the token. The third function is for checking that the input token sent by the sender account has been previously transferred to / belongs to the sender account. In various embodiments, the functions include mathematical functions that describe the logic of the constraints to be enforced and are implemented by segments of high-level computer code. For example, the second function, which checks that the input value of the token in the transfer is equal to the output value of the token, may be implemented by computer code that sums the tokens contained in all input records, sums the tokens contained in all output records, and then checks whether the sum of input tokens is equal to the sum of output tokens.

[0044] As described above, in some embodiments, the set of functions executed for a transaction is implemented as high-level computer code. However, since compilers that compute zero-knowledge proofs do not understand high-level computer code, the functions need to be synthesized into arithmetic circuits, which are low-level representations of the functions that are understandable to the compiler.

[0045] In step 704, the public input data associated with the transaction is formatted into private input data for witness assignments. Each function contains its own private and / or public inputs. For example, a third function that checks whether an input token sent by a sender account actually belongs to the sender account may receive a public input of a Merkle tree root (where the Merkle tree is generated from transactions posted to the blockchain) and a private input of a Merkle tree path to input records in the blockchain that are transferred / consumed within the transaction. The function verifies that the private input Merkle tree path is indeed associated with input records that belong to the sender account.

[0046] The private and public input data for each function are high-level values, but they are formatted as witness assignments, which are low-level representations of values ​​that can be understood by function-related arithmetic circuits.

[0047] In step 706, a first computational round is performed, involving matrix multiplication between function-related arithmetic circuits and witness assignments, to generate a product of a set of matrix multiplications. In some embodiments, the witness assignments include vectors, and each function-related arithmetic circuit includes a matrix. In the first computational round of the selected zero-knowledge proof protocol, the function-related arithmetic circuits / matrices are multiplied by the witness assignment vectors to obtain a matrix-vector product.

[0048] In step 708, the first set of polynomials is derived from a set of multiplication products using polynomial interpolation. The polynomial representations of the first set are determined from matrix-vector products using polynomial interpolation. Each polynomial representation is the lowest possible polynomial that passes through pairs of vector values, including the interpolation of the corresponding matrix-vector product. In some embodiments, further random polynomials, sampled for randomness, are also generated in the first computation round.

[0049] In step 710, the first set of commitments derived from the first set of polynomials is sent to the proof system. Because the polynomials generated from the first computation round contain information about witness assignment (including private input data), the polynomials cannot be sent directly to the proof system to prevent leakage of private input data. Instead of sending the polynomials themselves, commitments (polynomial commitments) are derived from the polynomials using a protocol such as Kate-Zaverucha-Goldberg (KZG). A polynomial commitment is a short representation of the polynomial, similar to a hash of its values. For example, a polynomial may have millions of coefficients, but its KZG commitment may be only 32 or 48 bytes. In various embodiments, polynomial commitments are derived from the polynomials, but the polynomial commitments cannot be used to reconstruct the polynomials themselves.

[0050] In step 712, a second computational round is performed, at least partially based on the first set of polynomials, to verify that the first set of polynomials was derived from the witness substitution and to generate a second set of polynomials and a set of challenges. The second computational round is performed to further verify (to the final verifier of the proof) that the first set of polynomials was derived from the witness substitution. The execution of the second computational round results in a second set of polynomials and a set of challenges. In some embodiments, the challenges in that set are random values ​​derived during the execution of the zero-knowledge proof protocol.

[0051] In step 714, the set of challenges, the second set of commitments, and the first evaluation proof derived from the second set of polynomials are sent to the prover system. Polynomial commitments and their corresponding evaluation proofs are derived from the second set of polynomials (similar to how the commitments were derived from the first set of polynomials from the first round) and then sent to the prover system along with the set of challenges. The evaluation proofs corresponding to the polynomial commitments from the second computation round include a method by which the proof constructor convinces the final verifier that each committed polynomial, when evaluated at a given point, results in the asserted evaluation. In some embodiments, both the polynomial commitments and the corresponding evaluation proofs are elliptic curve elements.

[0052] In summary, in some embodiments, a first set of polynomial commitments, a second set of polynomial commitments, a first evaluation proof, and a set of challenges form an "intermediate proof state" sent from the client device to the proofer system so that the proofer system can complete a zero-knowledge proof. Since there are no components of the intermediate proof state that can be used to reconstruct the private input data, the data privacy of the private input data is guaranteed.

[0053] Figure 8 is a flowchart showing an example of a process for performing a second proof calculation according to several embodiments. In some embodiments, process 800 is performed at least in part by the proofer system 104 of Figure 1.

[0054] In step 802, the client device receives a first set of commitments, a second set of commitments, a first evaluation proof, and a set of challenges associated with the requested transaction, where the private input data to the transaction cannot be reconstructed from one or more of the sets of commitments, second set of commitments, first evaluation proof, and challenges. As described above, the first set of commitments, second set of commitments, first evaluation proof, and set of challenges are generated by the client device performing a first proof computation (pre-computation) of the zero-knowledge proof corresponding to the transaction (for example, using a process such as process 700 in Figure 7). For example, the first set of commitments, second set of commitments, first evaluation proof, and set of challenges are sent from the client device along with the proof delegation request to complete the generation of the proof for the transaction.

[0055] In step 804, the set of functions associated with the requested transaction is determined. The set of functions associated with the transaction may be identified, for example, within the delegation of proof request.

[0056] In step 806, a third calculation round is performed, at least partially based on a set of functions and a set of challenges, to generate a third set of polynomials and a claimed sum. In some embodiments, the polynomials are derived from matrices representing the functions. These polynomials are derived from matrices that are specific to the functions but general to all transactions that use those functions. The set of challenges received from the client device is specific to the transaction but is not available to reconstruct the private input data to the transaction. In some embodiments, polynomial interpolation is used to generate polynomials corresponding to each matrix derived from different functions performed on the transaction. These polynomials derived from the function-associated matrices are the "third set of polynomials". The third set of polynomials and the set of challenges are then used to determine the "claimed sum". In some embodiments, the claimed sum output by round 3 is the evaluation of each polynomial in the third set at each of the challenge value data points (received from the client device). The claimed sum is the sum of the evaluations of each polynomial in the third set at each of the challenge values.

[0057] In step 808, the third set commitment is derived from the third set polynomial. As described above, the polynomial commitment ("third set commitment") can be derived from the third set polynomial using the KZG protocol.

[0058] In step 810, the fourth computational round is performed, at least partially based on the third set of polynomials, to generate the fourth set of polynomials.

[0059] In step 812, the fourth set of commitments and the second evaluation proof are derived from the third set of polynomials.

[0060] Figure 9 is a flowchart showing an example of the process for completing a full proof according to several embodiments. In some embodiments, process 900 is performed, at least in part, by the proofer system 104 of Figure 1.

[0061] In step 902, a complete zero-knowledge proof corresponding to a transaction is generated, at least in part, based on the respective sets of commitments and evaluation proofs corresponding to multiple computation rounds performed across the client device and the certifier system. In some embodiments, each polynomial commitment and evaluation proof generated by the fourth computation round is used to construct the zero-knowledge proof corresponding to the transaction. As described above, in some embodiments, the first two rounds (which constitute the "private" part of the zero-knowledge proof protocol) are computed first by the client device, and the last two rounds (which constitute the "public" part of the zero-knowledge proof) are delegated to the certifier system and computed by the certifier system.

[0062] In step 904, the complete zero-knowledge proof is sent to the blockchain along with other public transaction information, where the blockchain is configured to verify the transaction based at least partially on the complete zero-knowledge proof. The completed zero-knowledge proof is then sent to the blockchain along with the public information associated with the transaction. For example, a node on the blockchain verifies / verifies the proof before verifying the transaction (e.g., by adding the transaction's output record to the ledger). Examples of public information include the root of the Merkle tree generated from the blockchain and the serial number of the input record.

[0063] In some other embodiments, instead of the proofing system constructing a complete zero-knowledge proof based on the polynomial commitment and evaluation proof corresponding to the fourth computation round, the proofing system sends the polynomial commitment and evaluation proof generated from the computed rounds (third and fourth rounds) to the client device. Thus, the client device has the polynomial commitment and evaluation proof corresponding to all four rounds and can then construct a complete zero-knowledge proof locally. The client device then sends the constructed zero-knowledge proof and the public information associated with the transaction to the blockchain.

[0064] Figure 10 provides a schematic explanation of how a client device delegates part of a proof computation to a single certifier according to several embodiments. The requested transaction for which zero knowledge is computed may be multiple functions, including one or more functions of the same function type (e.g., three functions of function type 1, two functions of function type 2, and one function of function type 3), and / or further, functions of different function types (e.g., one function of function type 1, one function of function type 2, and one function of function type 3). As shown in Figure 10, the client device receives public input data, private input data, and functions associated with the transaction as input. The private input data (e.g., sensitive user data) can be stored locally on the client device and, according to the various embodiments described herein, is not transmitted to the certifier system during the delegation process to avoid leakage of private information. Thus, in the delegation system described herein, the private input data is used only during the pre-computation of the proof on the client device and is not subsequently passed on to another entity (e.g., a certifier). Rather, pre-computation on the client device results in an intermediate proof state, which contains values ​​that are not available to recover the private input data. In various embodiments, the proofing system that receives the intermediate proof state associated with a transaction is aware of the function used to complete the proof for the transaction. For example, the function associated with a transaction may be queried from the blockchain where the transaction's function was previously deployed. The proofing system then completes the remainder of the proof computation based on the transaction's function and the intermediate proof state.

[0065] The intermediate proof state of the proof generated by the client device and the second part of the proof generated by the proofer system can be combined to form a complete proof that is sent to the blockchain over the network.

[0066] The computational complexity of the first proof computation / pre-computation by the client device can be described as O(n log n) and O(n), where n is the number of constraints, which is the number of constraints in the arithmetic representation of the function-related circuit as a matrix. The computational complexity of the second proof computation by the prover can be described as O(m log m) and O(m), where m is the number of non-zero entries, which is the number of terms that appear in the arithmetic representation of the function-related circuit as a matrix. Empirical observations of computing zero-knowledge proofs using protocols such as the Marlin protocol show that m > n, and consequently, the portion of the second proof computation in the prover system is more complex (e.g., computationally expensive) than the first proof computation / pre-computation in the client device. Therefore, such protocols do not burden the client device (which is relatively less robust than the prover system) with the computationally intensive task of completing a complete proof.

[0067] Figure 11 is a sequence diagram illustrating an example of the process of delegating certificate generation from a client device to a certificater system according to several embodiments. In some embodiments, the processes 700 in Figure 7 and 800 in Figure 8 can be performed, at least in part, using the process 1100 in Figure 11.

[0068] The steps of process 1100 are described in the sample mathematical description from the Marlin zero-knowledge proof protocol.

[0069] In step 1102, rounds 1 and 2 of the zero-knowledge proof (ZKP) protocol are computed on the client device based on the public input data, private input data, and functions associated with the transaction.

[0070] In step 1104, the Round 1 commitment, Round 2 commitment, Round 2 evaluation certificate, and one set of challenges are generated on the client device and sent to the certifier system.

[0071] Calculation for Round 1

[0072]

number

[0073]

[0074]

[0075] As shown in the mathematical description above, in round 1, private input data (w i,j ) and public input data (x i,j ) is the witness substitution vector (z i,j ) is formatted as follows. The witness assignment vector is multiplied by matrices (A and B), which are the arithmetic circuit representations of the functions associated with the transaction. Polynomial (e.g.,

number

[0076] Round 1 commitment to send to the certification system

[0077]

number

[0078] As shown above, the polynomial commitment is derived from the polynomial generated in Round 1 (for example, using the KZG protocol).

[0079] Calculation for Round 2

[0080]

number

[0081]

[0082]

[0083]

[0084]

[0085]

[0086]

[0087]

[0088]

[0089]

[0090]

[0091]

[0092] As shown in the mathematical description above, in Round 2, the polynomial generated by Round 1 is further multiplied by a set of challenges (η) (e.g., g1 and h1) A η B η C , α, {v i}, and {τ i,j Used to generate}).

[0093] In particular, each set of challenges is based on commitments generated from Round 1.

number

[0094] g1 and h1 are polynomials that can be used to convert the above-mentioned sum check claim into a polynomial equality claim, which is a type of claim that is easy to check.

[0095] g1 and h1 are (as described above)

Number

[0096] Round 2 commitments and challenges to submit to the certification system

[0097] Commitment cm g1 , cm h1、 α and β

[0098] As shown above, the polynomial commitment (cm g1 , cm h1 ) is derived from the polynomial generated in round 2 (for example, using the KZG protocol). The challenges α and β are derived from data that is unique to the transaction, but appear random and cannot be used by the prover system to recover the private input data.

[0099] In step 1106, rounds 3 and 4 of the zkp protocol are calculated in the prover system.

[0100] In step 1108, the round 3 commitment, the round 4 commitment, and the round 4 evaluation proof are generated in the prover system.

[0101] Calculation for Round 3

[0102]

Number

[0103]

[0104]

[0105]

[0106]

[0107]

[0108] As shown in the mathematical description above, in round 3, (for example, val M *, row M *, col M The matrix polynomial (represented by *) is determined from different types of functions associated with the transaction, and the set of challenges (α and β) is the polynomial (g A,i , g B,i , and, g C,i It is used to determine ).

[0109] Rounds 3 and 4 collectively reduce the matrix-vector product A to a specific sum-checking claim. z B z , and, C z This enables efficient checking of polynomial g. A,i , g B,i , and, g C,i This serves the same purpose as polynomial g1 in Round 2.

[0110] Round 3 commitments and claimed total

[0111] Commitment {cm gA,i},{cm gB,i},{cm gC,i} and the claimed total {σ M}

[0112] As shown above, polynomial commitment (cm gA,i ,cm gB,i ,cm gC,i ) is derived from the polynomial generated in round 4 (for example, using the KZG protocol). The claimed sum (σ) M) is the sum of the evaluations of the matrix polynomial at the data points including challenges α and β.

[0113] Calculations for Round 4

[0114]

number

[0115]

[0116] As shown in the mathematical description above, in round 4, the polynomial (h2) is derived from the polynomial generated in round 3.

[0117] Round 4 Commitment

[0118] Commitment CM h2

[0119] As shown above, polynomial commitment (cm h2 ) is derived from the polynomial generated in the round (for example, using the KZG protocol).

[0120] In step 1110, the complete ZKP is generated by the certifier system combining the Round 1 Commitment, Round 2 Commitment, Round 3 Commitment, Round 4 Commitment, Round 2 Evaluation Certification, and Round 4 Evaluation Certification.

[0121]

number

[0122] {v gA,i :=g A,i (γ)},{v gB,i :=g B,i (γ)},{v gC,i :=g C,i (γ)}

[0123] cmh2 Using this, for each M∈M, row M , col M rowcol M , val M , evaluation g M (γ), and total σ M Index the commitments against the provisional commitments vcm mat To construct.

[0124]

number

[0125] Randomness ρ1,···,ρ |Q| Using PC.Open, which has the following, we construct the following batch opening proof π2.

number

[0126] Rounds 1, 2, 3, and 4 of commitments, evaluation proofs, and the calculation and combination of evaluations generate the complete proof π.

[0127] A complete proof includes commitments from rounds 1, 2, 3, and 4, evaluation proofs from rounds 2 and 4, and evaluations from rounds 2 and 4 (e.g., arrays containing them). For example, evaluations from round 2

number

[0128] In step 1112, the complete zkp and transaction public information are sent to the blockchain by the certificate system.

[0129] In some embodiments, either a client device or a proof system can construct a complete proof using commitments and evaluation proofs from four rounds to complete the calculation of the complete proof. Either the client device or the proof system may be specified by the delegation processing settings to construct a complete proof using commitments and evaluation proofs from four rounds. In some embodiments, either the client device or the proof system may be selected to construct a complete proof based on one or more factors, such as the amount of unused computing power and / or whether the entity is connected to the network. In some embodiments, the entity constructing the complete proof sends the complete proof to the blockchain network, which can verify the associated transactions based on the proof before recording the output record in the ledger.

[0130] Figure 12 is a sequence diagram showing an example of a process for verifying a proof according to several embodiments. In some embodiments, process 1200 is performed by a blockchain node or any party.

[0131] In step 1202, a complete zero-knowledge proof of the transaction is obtained. For example, the proof is generated by a process such as process 1100 in Figure 11.

[0132] In step 1204, it is determined whether or not the zero-knowledge proof can be verified. If the zero-knowledge proof can be verified, control proceeds to step 1206. Conversely, if the zero-knowledge proof cannot be verified, control proceeds to step 1208.

[0133] verification

[0134] The verifier needs to check the following:

[0135]

number

[0136]

[0137]

[0138] In other words, the verifier uses all parts of the complete proof π (all commitments, all evaluation proofs, and all evaluations) to check that the two polynomials derived from the sum check in rounds 2 and 4 are equal.

[0139] In step 1206, the transaction is confirmed. In some embodiments, if the proof can be verified by a blockchain node, the transaction is confirmed and added to the blockchain. For example, if the transaction was a token transfer, confirming such a transaction may involve adding an output record (e.g., recording the use / transfer of the token) to the ledger, which is the blockchain.

[0140] In step 1208, the transaction confirmation is rejected. However, if the proof cannot be verified by the blockchain node, the transaction is not confirmed and therefore not added to the blockchain. For example, if the transaction was a token transfer, rejecting confirmation of such a transaction would result in the output record of the transaction (e.g., recording the use / transfer of tokens) not being added to the ledger, which is the blockchain.

[0141] The example above shows a proof computation scheme involving four rounds, but in other examples, the proof computation scheme may include more or fewer computation rounds.

[0142] Although the embodiments described above are explained in some detail for ease of understanding, the present invention is not limited to the details provided. Many alternative methods exist for carrying out the present invention. The disclosed embodiments are illustrative and not intended to be limiting.

Claims

1. It is a system, A first processor, To generate computationally intensive proofs associated with transactions posted to the blockchain, private and public input data are received. A first processor is configured to perform a first proof computation based at least partially on the private input data and the public input data in order to generate an intermediate proof state. An interface configured to transmit the intermediate proof state to a second processor, Equipped with, The system is configured such that the second processor performs a second proof computation based at least partially on the intermediate proof state in order to generate the computationally intensive proof associated with the transaction, and it is computationally impossible for the second processor to derive the private input data from the intermediate proof state.

2. The system according to claim 1, wherein the computationally intensive proof includes a zero-knowledge proof.

3. The system according to claim 2, wherein the zero-knowledge proof is generated based on the Marlin protocol.

4. The system according to claim 1, wherein the first proof calculation is performed by The set of functions associated with the transaction is synthesized into a function-related arithmetic circuit. Formatting the public input data and the private input data associated with the transaction into witness assignments, A system that includes these features.

5. The system according to claim 4, wherein performing the first proof calculation further, To generate the product of a set of matrix multiplications, the matrix multiplication between the function-related arithmetic circuit and the witness substitution is performed. Using polynomial interpolation, derive the first set of polynomials from the product of the multiplications of the aforementioned sets. Equipped with, The aforementioned intermediate proof state is a system comprising a first set of commitments derived from the first set of polynomials.

6. The system according to claim 5, wherein the commitment of the first set is determined from the polynomial of the first set using the Kate-Zaverucha-Goldberg (KZG) protocol.

7. The system according to claim 5, wherein performing the first proof calculation further, The method comprises verifying that the first set of polynomials was derived from the witness substitution, and performing a second computational round, at least partially based on the first set of polynomials, to generate a second set of polynomials and a set of challenges. The aforementioned intermediate proof state is a system further comprising the challenge of the aforementioned set, the commitment of a second set, and a first evaluation proof derived from the polynomial of the second set.

8. The system according to claim 1, wherein the second processor is configured to perform the second proof calculation, Based on a set of functions associated with the transaction, obtain a matrix polynomial, Based on the matrix polynomial and the set of challenges included in the intermediate proof state received from the first processor, a third set of polynomials is determined. To derive the commitment of the third set from the aforementioned third set of polynomials, A system that includes these features.

9. The system according to claim 8, wherein the second processor is configured to perform the second proof calculation, To generate the fourth set of polynomials, a fourth computational round is performed, based at least partially on the third set of polynomials. To derive the fourth set commitment and the second evaluation proof from the aforementioned fourth set of polynomials, A system that includes these features.

10. The system according to claim 9, wherein the intermediate proof state comprises a first set of commitments associated with a first computation round, a second set of commitments associated with a second computation round, and a first evaluation proof associated with the second computation round, and generating the computationally intensive proof associated with the transaction comprises combining the first set of commitments, the second set of commitments, the first evaluation proof, the third set of commitments, the fourth set of commitments, and the second evaluation proof.

11. A system according to claim 1, wherein the first processor is configured to transmit the computationally intensive proof to the blockchain, and the blockchain is configured to verify the computationally intensive proof in order to confirm the transaction.

12. The system according to claim 1, wherein the first proof calculation is associated with a lower computational complexity than the second proof calculation.

13. The system according to claim 1, wherein the public input data includes the root of a Merkle tree, and the Merkle tree is determined based on the records of the blockchain.

14. It is a method, To generate computationally intensive proofs associated with transactions posted to the blockchain, private and public input data are received by the first processor. To generate an intermediate proof state, the first proof computation is performed on the first processor based at least partially on the private input data and the public input data. Transmitting the aforementioned intermediate proof state from the first processor to the second processor, Equipped with, A method wherein the second processor is configured to perform a second proof computation based at least partially on the intermediate proof state in order to generate the computationally intensive proof associated with the transaction, and deriving the private input data from the intermediate proof state is computationally impossible for the second processor.

15. The method according to claim 14, wherein performing the first proof calculation is: The set of functions associated with the transaction is synthesized into a function-related arithmetic circuit. Formatting the public input data and the private input data associated with the transaction into witness assignments, A method that includes [a certain feature].

16. The method according to claim 15, wherein performing the first proof calculation further, To generate the product of a set of matrix multiplications, the matrix multiplication between the function-related arithmetic circuit and the witness substitution is performed. Using polynomial interpolation, derive the first set of polynomials from the product of the multiplications of the aforementioned sets. Equipped with, The method wherein the intermediate proof state comprises a first set of commitments derived from the first set of polynomials.

17. The method according to claim 16, wherein performing the first proof calculation further, The method comprises verifying that the first set of polynomials was derived from the witness substitution, and performing a second computational round, at least partially based on the first set of polynomials, to generate a second set of polynomials and a set of challenges. The method further comprises the challenge of the aforementioned set, the commitment of a second set, and a first evaluation proof derived from the polynomial of the second set.

18. The method according to claim 14, wherein the second processor is configured to perform the second proof calculation, Based on a set of functions associated with the transaction, obtain a matrix polynomial, Based on the matrix polynomial and the set of challenges included in the intermediate proof state received from the first processor, a third set of polynomials is determined. To derive the commitment of the third set from the aforementioned third set of polynomials, A method that includes [a certain feature].

19. The method according to claim 18, wherein the second processor is configured to perform the second proof calculation, To generate the fourth set of polynomials, a fourth computational round is performed, based at least partially on the third set of polynomials. To derive the fourth set commitment and the second evaluation proof from the aforementioned fourth set of polynomials, A method that includes [a certain feature].

20. A method according to claim 19, wherein the intermediate proof state comprises a first set of commitments associated with a first computation round, a second set of commitments associated with a second computation round, and a first evaluation proof associated with the second computation round, and generating the computationally intensive proof associated with the transaction comprises combining the first set of commitments, the second set of commitments, the first evaluation proof, the third set of commitments, the fourth set of commitments, and the second evaluation proof.

Images