Proving delegation of computations

Abstract

A delegation of attestation computations is disclosed, including: receiving, at a first processor, private input data and public input data to generate a compute-intensive attestation associated with a transaction to be published to a blockchain; and performing, at the first processor, a first attestation calculation based at least in part on the private input data and the public input data to generate an intermediate attestation state; sending an intermediate attestation state from the first processor to a second processor, where the second processor is configured to perform a second attestation computation based at least in part on the intermediate attestation state to generate a compute-intensive attestation associated with the transaction, wherein the second processor derives from the intermediate attestation state that the private input data is computationally infeasible.

Description

[0001] Cross-reference with other applications This application claims priority to U.S. Patent Application No. 18 / 583378, filed February 21, 2024, entitled “Entrustment to Prove Computation,” and U.S. Provisional Patent Application No. 63 / 472482, filed June 12, 2023, entitled “Entrustment to Prove Computation,” both of which are incorporated herein by reference for all purposes. Background Technology

[0002] The generation of proofs that can be used to verify that a requested transaction was indeed authorized by the initiator can be computationally intensive. Therefore, proof generation is not suitable for execution on devices that cannot reasonably support such computations, in conjunction with other processes expected to be performed efficiently. In some traditional systems, the generation of computationally intensive proofs can be delegated from the transaction initiator's device to another system with more computational resources. However, in this traditional type of delegation, any private (e.g., sensitive) data input into the transaction (e.g., by the transaction initiator) is also distributed to one or more entities that delegated the generation of the proof. Therefore, efficient delegation of proof generation, along with maintaining the security of any private input data within the transaction, is desirable. Attached Figure Description

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

[0004] Figure 1 This is a diagram illustrating an embodiment of a system for delegating proof delegation.

[0005] Figure 2 This is a diagram illustrating an example of a client device for delegated authentication according to some embodiments.

[0006] Figure 3 This is a diagram illustrating an example of a proofr system for receiving proof requests according to some embodiments.

[0007] Figure 4 This is a diagram illustrating the framework of a client device according to some embodiments, which delegates the computation of a portion of the proof associated with a transaction to a single third-party prover.

[0008] Figure 5 This is a flowchart illustrating an embodiment of the process for generating delegated proofs.

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

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

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

[0012] Figure 9 This is a flowchart illustrating an example of a process for completing a full proof, according to some embodiments.

[0013] Figure 10 A high-level description is shown of a client device, according to some embodiments, delegating a portion of the proof computation to a single prover.

[0014] Figure 11 This is a sequence diagram illustrating an example process of deleting proof generation from a client device to a proof generator system according to some embodiments.

[0015] Figure 12 This is a sequence diagram illustrating an example process for verifying proof according to some embodiments.

[0016] Detailed description This invention can be implemented in a variety of ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided thereto in memory coupled to the processor. In this specification, these implementations or any other form of the invention that may take the form of a technique may be referred to as such. Generally, within the scope of this invention, the order of steps of the disclosed process may be varied. Unless otherwise stated, components described as configured to perform a task (such as processors or memory) may be implemented as general-purpose components temporarily configured to perform the task at a given time, or manufactured as specific components to perform that task. As used herein, 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 detailed description of one or more embodiments of the invention, together with the accompanying drawings illustrating the principles of the invention, provides for illustrative purposes. The invention is described in conjunction with these embodiments, but is not limited to any particular embodiment. The scope of the invention is limited only by the claims, and the invention encompasses many alternatives, modifications, and equivalents. To provide a thorough understanding of the invention, numerous specific details are set forth in the following description. These details are provided for illustrative purposes, and the invention may be practiced without some or all of these specific details, as claimed. For clarity, technical materials known in the art related to the invention have not been described in detail, so that the invention will not be unnecessarily obscured.

[0018] This document describes an embodiment of delegated proof computation. Private and public input data are received at a first processor to generate a computationally intensive proof associated with a transaction to be published to the blockchain. For example, the first processor is a client device used by a user who has been selected (e.g., via a software application running on the client device) to initiate a transaction, such as transferring a token to a recipient. To add this transaction to the blockchain, a computationally intensive proof needs to be generated, in which the certifying initiator has effectively authorized the transaction, and then sends it along with transaction information to the blockchain network. In various embodiments, the computationally intensive proof is a "zero-knowledge" type of proof. In various embodiments, both the public and private data input into the transaction are included in the generation of the computationally intensive proof. In various embodiments, "private input data" or "private data" refers to sensitive information that is expected to remain secure / confidential relative to the prover system, and the generation of the computationally intensive proof is delegated to that system. A first proof computation, at least in part based on the private and public input data, is performed at the first processor to generate an intermediate proof state. As will be described in further detail below, the "first proof computation" is sometimes referred to as the "pre-computation" of the proof. The first proof computation (or "pre-computation") is performed locally for the device requesting the transaction using private and public input data. An intermediate proof state is sent to a second processor, which is configured to perform a second proof computation, at least partially based on the intermediate proof state, to generate a complete / full dense proof associated with the transaction. The second processor derives from the intermediate proof state that the private input data is computationally infeasible. After sending the intermediate proof state to the second processor (part of the prover system) to delegate the remaining computation of the proof to the second processor, the second processor performs the remaining part of the proof computation and constructs the complete proof. To ultimately ensure the security of the private data input into the first proof computation / pre-computation, the intermediate proof state sent from the first processor to the second processor has the property that it cannot be used to reverse engineer the private input data. In other words, the recipient of the intermediate proof state (e.g., the second processor) cannot recover the transaction from the private input data in the intermediate proof state. After the second processor computes the second proof computation, the second processor can combine at least a portion of the intermediate proof state and the result of the second proof computation to generate a complete / full proof. Then, the second processor can send the transaction-related information and the generated completion / fulfillment proof to the blockchain, allowing blockchain nodes to verify the transaction based on the proof and then add the transaction to the blockchain.

[0019] Figure 1 This is a diagram illustrating an embodiment of a system for delegating proof delegation. (As shown) Figure 1As shown, system 100 includes client device 102, proof system 104, network 106, and blockchain network 108. Network 106 includes data and / or telecommunications networks.

[0020] Client device 102 is configured to execute computer program code associated with a standalone software application or a web browser-based application, which is configured to manage accounts participating in transactions on blockchain 108. Examples of client device 102 may be mobile devices, laptops, desktop computers, tablets, or any other computing device. A user (not shown) may interact with a user interface associated with the application executing at client device 102 to open a new account. In response to a user's input initiating / requesting a transaction on blockchain 108, the application executing at client device 102 is configured to execute a process that results in transaction-related information being sent to blockchain 108. In a first example, the type of requested transaction is a deployment transaction, which involves deploying a new program comprising a set of functions to blockchain 108. For example, the newly deployed program / set of functions will be used in future transactions. In a second example, the type of requested transaction is an execution transaction, which involves executing a previously deployed program / function. For example, an execution transaction can be used to execute a previously deployed program / function to enable a token transfer between two accounts on blockchain 108. In various embodiments, in response to a request to execute a transaction, the application executed at client device 102 is configured to obtain user input data and transaction-related functions.

[0021] In various embodiments, executing a transaction requires generating computationally intensive / heavy proofs to authenticate the identity of the user initiating the transaction. In various embodiments, the type of proof computed in "zero-knowledge proofs" (sometimes called "zkp") is a type of proof that proves to the recipient that a given statement is true (e.g., the transaction was indeed authorized by a designated account holder) without revealing the underlying statement itself. Because client device 102 is equipped with a limited amount of computational resources, it is generally impractical to complete the generation of zero-knowledge proofs at the client device 102 that initiates the transaction. For example, computed zero-knowledge proofs at client device 102 might monopolize a greater-than-expected proportion of the client device 102's computational resources, preventing client device 102 from performing other desired functions. Therefore, the various embodiments described herein enable the computation of zero-knowledge proofs to be partially delegated from the device initiating the transaction (e.g., client device 102) to a third-party prover system (e.g., prover system 104) with relatively large computational resources. The delegation of part of the computation / generation of zero-knowledge proofs as described herein allows client device 102 to begin computation / generation of proofs without requiring client device 102 to have sufficient computational processing resources to complete the proof.

[0022] In various embodiments, at least a portion of the user input data used in executing a transaction may be sensitive data or data that the user expects to keep private. Examples of private data may be personally identifiable information and / or financial history information. In other words, it is not expected that this “private” input data used in executing the transaction will be shared or distributed with another entity other than client device 102; therefore, in the delegation of zero-knowledge proofs, it is not intended to send private input user data to prover system 104. The various embodiments described herein provide private input data for local pre-computation of zero-knowledge proofs at client device 102, but it is not shared with prover system 104 in delegating the generation of the remainder of the proof to prover system 104. As will be described in further detail below, the pre-computation of the zero-knowledge proof using the private input data at client device 102 will produce an intermediate proof state, which client device 102 will send to prover system 104 via network 105 for prover system 104 to use in completing the full zero-knowledge proof. However, although it has been partially derived from the private input data, the intermediate proof state cannot be used to recover the private input data. In this way, the prover system 104 can then use intermediate proof states to generate a complete zero-knowledge proof without learning the private input data of the transaction.

[0023] After generating the zero-knowledge proof, the prover system 104 is configured to send the proof, along with other (public) information related to the execution of the transaction, to the blockchain 108. In some embodiments, after the prover system 104 completes the full proof, it can send the full proof to the client device 102, which then sends the proof, along with public information related to the execution of the transaction, to the blockchain 108. The nodes of the blockchain will verify the received zero-knowledge proof before adding the transaction (e.g., the transaction's output record) to the ledger.

[0024] As described herein, in various embodiments, sensitive private input user data locally stored at the client device can be used to compute a first part (sometimes referred to as “pre-computation”) of a proof (e.g., a zero-knowledge proof) at the client device (e.g., a device with relatively fewer computing resources than the prover system). In some embodiments, the proof will be associated with a transaction that will eventually be recorded at the blockchain. In various embodiments, a proof protocol is chosen such that the pre-computation of the first part of the proof executed at the client device is less computationally intensive than the remaining second part of the proof to be executed 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 a function for computing the first part of the proof at the client device, and possibly at least a portion of the first part of the proof. Advantageously, the client device does not need to pass any sensitive, private input user data for computing 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 (e.g., by the prover) combined to construct a complete proof. The entity that generates the complete proof can then send the complete proof to the blockchain network to associate the complete proof with a transaction. The blockchain network can confirm the transaction by verifying the complete proof.

[0025] Figure 2 This is a diagram illustrating an example of a client device for delegated authentication according to some embodiments. In some embodiments, Figure 1 Client device 102 can use Figure 2 This is implemented using an example client device. For example... Figure 2 As shown, the client device includes a transaction initiation engine 202, a proof pre-computation engine 204, and a prover interface 206. Each of the transaction initiation engine 202, the proof pre-computation engine 204, and the prover interface 206 can be implemented using software and / or hardware (e.g., a processor, a communication interface, a memory).

[0026] Transaction initiation engine 202 is configured to receive requests for transactions to be published on the blockchain. To initiate a transaction to be confirmed by the blockchain, the account's user enters parameters (input data) associated with the transaction into the user interface of an application executed on the client device. For example, if the transaction is an execution transaction related to spending tokens associated with the account, the parameters associated with the transaction may include identification information associated with one or more confirmation records on the blockchain network that record the documents owned by the new account. These confirmation records will be included in the transaction by the application as one or more input records. Furthermore, in this example, the user input parameters will also include at least the number of tokens the user expects to send to the recipient, and at least one output record to be confirmed by the blockchain network, specifying the recipient's account address, the program (a set of functions) to be executed, and the number of tokens to be sent to the recipient (which will be included in the transaction by the application as an output record). In various embodiments, while some parameters entered by the user for a transaction are considered "public" or allowed to be shared with another entity (such as a proofer system), some parameters entered by the user for a transaction are considered "private" or restricted from being shared with another entity. In some embodiments, which parameters / input data are private or public can be specified based on the application / type performing the transaction. Specific examples of public input data may include the program / function to be executed, the sequence number of the input record, blockchain identification information, and the credit score of the sender account's user. Specific examples of private input data may include the sender account's financial history, the sender account's personally identifiable information, the sender account's private account key, and the sender account's account address. For example, whether user input parameters are public or private can also be determined based on predetermined rules (e.g., if the number of tokens to be transferred in a transaction is greater than a predetermined number, then the number of tokens is designated as private user input in that transaction).

[0027] The proof precomputation engine 204 is configured to perform a precomputation (first part) of a zero-knowledge proof corresponding to the initiated / executed transaction based on the transaction's parameters (public and private input data). In this case, the "zero-knowledge proof" verifies that the transaction was initiated by the holder / user of the account that initiated the transaction, without revealing the private input data to a validator (e.g., a node in the blockchain network). In the various embodiments described herein, a zero-knowledge proof protocol is used to generate the proof, which has the property of being able to divide the proof generation into a first private part that requires input data (including private input data) to enter the executed transaction and a second public part that does not directly require the private input data. An example of a zero-knowledge proof protocol with this property is the Marlin protocol. Therefore, the proof precomputation engine 204 is configured to perform the first part (precomputation) of the zero-knowledge proof based on the transaction's public and private input data. As will be described in further detail below, in some embodiments, performing the first part (precomputation) of the zero-knowledge proof based on the transaction's public and private input data includes computing two consecutive rounds of computation (a first round and a second round), whereby the transaction's private and public input data are input into 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 proof precomputation performed by the proof precomputation engine 204 is sent to the prover system via the network by the prover interface 206. This portion of the output from both the first and second rounds of proof precomputation is sometimes referred to as the "intermediate proof state." In various embodiments, the intermediate proof state includes transaction-specific data but cannot be used to reconstruct a transaction from private input data.

[0028] The proof precomputation engine 204 is configured to send a proof delegation request along with the intermediate proof state of the transaction proof to the proof provider system. The receiving proof provider system is then configured to complete the second / remaining part of the zero-knowledge proof based on the intermediate proof state. For example, the proof delegation request may include public information related to the transaction and identification information of the blockchain to which the transaction is to be published.

[0029] Figure 3 This is a diagram illustrating an example of a proofr system for receiving proof requests according to some embodiments. In some embodiments, Figure 1 The proof system 104 can be used Figure 3 An example prover system is implemented as follows. Figure 3 As shown, the proof system includes a client interface 302, a proof completion engine 304, and a blockchain interface 306. Each of the client interface 302, the proof completion engine 304, and the blockchain interface 306 can be implemented using software and / or hardware (e.g., a processor, a communication interface, a memory).

[0030] Client interface 302 is configured to receive requests for proof delegation and corresponding intermediate proof status from client devices.

[0031] The proof completion engine 304 is configured to generate a zero-knowledge proof for each corresponding proof delegation request based on the intermediate proof state corresponding to that request. As will be described in further detail below, in some embodiments, the proof completion engine 304 uses at least a portion of the transaction-related intermediate proof state to compute two additional consecutive rounds of computation (a third and fourth round), whereby the intermediate proof state is input into the third round, and the fourth round receives the output from the third round as input. In some embodiments, due to the characteristics of the zero-knowledge proof protocol used in the proof delegation, the portion of proof generation at the prover system (e.g., the third and fourth rounds) is more complex than the portion of proof generation pre-computed at the client device. Thus, even though the proof is computed across the client device and the prover system, the prover system is required to perform more complex computations and is therefore required to use more computing resources / processing power on the client device than 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 output from each of the first, second, third, and fourth rounds of computation. Receive the output of the first and second rounds of computation included in the complete zero-knowledge proof from the client device.

[0032] Blockchain interface 306 is configured to send a complete / final zero-knowledge proof, along with public information related to the transaction, to the blockchain network. Blockchain nodes will verify the proof before confirming the transaction. For example, confirming a transaction involves adding the transaction's output record to the blockchain's ledger.

[0033] Figure 4 This is a diagram illustrating the framework of a client device according to some embodiments, which delegates the computation of a portion of the proof associated with a transaction to a single third-party prover. Figure 4 The framework described depicts a scenario where private (e.g., sensitive) input data associated with the requested transaction received at the client device (e.g., the transaction initiator's private account key, the transaction receiver's public address, and the contents of the transaction's input and / or output records) is also used locally to generate an intermediate proof state corresponding to the transaction. However, this private input data is not passed from the client device to the third-party prover system. Instead, the third-party prover system only receives the intermediate proof state from the client device, and then uses it along with a function associated with the transaction to compute the complete proof associated with the transaction. The third-party prover system can then send the complete proof to the blockchain via the network. Figure 4The framework described in the document reiterates that the prover system learns only transaction-related functions, not private input data, which allows for secure proof delegation with minimal information transfer.

[0034] Figure 5 This is a flowchart illustrating an embodiment of a process for generating delegated proof. In some embodiments, process 500 is at least partially in... Figure 1 The client device is implemented at 102 locations.

[0035] At point 502, private and public input data are received at the first processor to generate a computationally intensive proof associated with the transaction to be published to the blockchain. The private and public input data are parameters requested at the client device to execute the transaction. In various embodiments, the computationally intensive proof is a zero-knowledge proof.

[0036] At 504, a first proof computation is performed at the first processor, at least in part, based 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 both private and public input data, and the second proof computation takes a portion of the output from the first proof computation but does not require the private and public input data. Therefore, the first proof computation based on the transaction's private and public input data (or sometimes referred to as "pre-computation") can be computed by the first processor, which is located locally on the client device that stores or obtains the private and public output data. The portion of the output of the first proof computation generated at the client device and sent over the network to a remote second processor (as associated with the prover system) is the "intermediate proof state."

[0037] At point 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. The second processor derives from the intermediate proof state that the private input data is computationally infeasible. The intermediate proof state includes data (e.g., challenges) ultimately generated from both private and public input data but not usable to recover 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 the complete proof. The prover system can then send the completed proof, along with the transaction's public information, to the blockchain for recording without knowing the transaction's private input data.

[0038] Figure 6 This is a flowchart illustrating an example of a process for performing a first proof calculation (pre-computation) according to some embodiments. In some embodiments, process 600 is at least partially in... Figure 1Implemented at client device 102. In some embodiments, Figure 5 Steps 502 and 504 of process 500 can be used Figure 6 The process is achieved through 600.

[0039] At 602, a request to initiate a transaction is received. In various embodiments, the requested transaction includes executing a transaction. An example of executing a transaction is transferring a token from one account (e.g., the user initiating the transaction) to another account.

[0040] At position 604, public and private input data associated with the transaction are received. In some embodiments, at least some of the public and private input data associated with the transaction may be input by the user initiating the transaction. In some embodiments, at least some of the public and private input data associated with the transaction may be stored locally on the client device initiating the transaction. In some embodiments, at least some of the public and private input data associated with the transaction may be queried by the client device initiating the transaction. Specifying a piece of data as public or private may be configurable by the user at the client device. Examples of private input data include the private account key of the transaction initiator, the public address of the transaction recipient, 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 to be executed by the transaction.

[0041] At point 606, a first proof computation corresponding to a transaction's zero-knowledge proof is performed, at least in part, based on public input data, private input data, and a set of functions associated with the transaction. The execution of the first proof computation produces an intermediate proof state, where the private input data cannot be recovered from the intermediate proof state. In various embodiments, a sequence of multiple rounds of computation needs to be performed within the zero-knowledge proof protocol. The initial round computation takes the transaction's public and private input data as input, and each subsequent round computation takes at least a portion of the output from the previous round as input. In some embodiments, during the first proof computation (pre-computation), the first two rounds of the computation round sequence are locally computed at the client device to generate an intermediate proof state. The intermediate proof state includes a portion of the output of the first and second round computations performed at the client device and is transmitted from the client device to a remote prover system via a network. The advantage of transmitting the intermediate proof state to the remote prover system is that the prover system can perform the zero-knowledge proof on the intermediate proof state without needing to derive the private input data of the intermediate proof state from it. In other words, the private input data does not leave the client device during the proof delegation process.

[0042] Figure 7This is a flowchart illustrating an example of a process for performing a first proof calculation (pre-computation) according to some embodiments. In some embodiments, process 700 is at least partially in... Figure 1 Implemented at client device 102. In some embodiments, Figure 6 Step 606 of process 600 can be used Figure 7 The process is achieved through 700.

[0043] At 702, a set of functions associated with the transaction are synthesized into the function-related arithmetic circuit. In a specific example of a token transfer transaction, three types of functions can be executed. The first function performs a token transfer from the sender's account to the receiver's account. The second function checks that the input value of the transferred token equals the token's output value. The third function checks whether the input token to be sent by the sender's account has previously been transferred to / belongs to the sender's account. In various embodiments, the functions include mathematical functions describing the constraint logic to be implemented and implemented by a piece of high-level computer code. For example, the second function, which checks that the input value of the transfer token equals the token's output value, can be implemented by computer code that sums up the tokens included in all input records, sums up the tokens included in all output records, and then checks that the total input tokens equal the total output tokens.

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

[0045] At 704, the public and private input data associated with a transaction are formatted as witness assignments. Each function contains its own private and / or public inputs. For example, a third function that checks whether an input token to be sent by a sender account actually belongs to the sender account could take the public input of the Merkle tree root (where the Merkle tree is generated from the transaction published to the blockchain) and the private input of the Merkle tree path of the input record to be transferred / spent in the transaction within the blockchain. This function will confirm that the private input Merkle tree path is indeed associated with the input record belonging to the sender account.

[0046] Although the private and public input data of each function are high-level values, they are formatted as witness assignments, which are low-level representations of the values ​​that allow the arithmetic circuits associated with the function to understand them.

[0047] At 706, a first round of computation is performed, including matrix multiplication between the function-dependent arithmetic circuit and the witness assignment, to generate a set of matrix multiplication products. In some embodiments, the witness assignment comprises a vector, and each function-dependent arithmetic circuit comprises a matrix. In the first round of computation of the selected zero-knowledge proof protocol, the function-dependent arithmetic circuit / matrix is ​​multiplied with the witness assignment vector to obtain a matrix-vector product.

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

[0049] At point 710, the first set of commitments derived from the first set of polynomials is sent to the prover system. The polynomials generated from the first round of computation contain information about the witness assignments, including private input data; therefore, to prevent leakage of this private input data, the polynomials cannot be sent directly to the prover system. For example, commitments (polynomial commitments) are derived from the polynomials using protocols such as Kate Zaverucha Goldberg (KZG), instead of sending the polynomials themselves. A polynomial commitment is a short representation of a polynomial, similar to a hash of a value. For example, a polynomial may have millions of coefficients, but its KZG commitment may only be 32 or 48 bytes. In various embodiments, although polynomial commitments are derived from polynomials, they cannot be used to recover the polynomials themselves.

[0050] At point 712, a second round of computation is performed, at least in part, based on the first set of polynomials, to confirm that the first set of polynomials is derived from the witness assignment, and to generate a second set of polynomials and a set of challenges. The second round of computation is performed to further confirm (to the final verifier of the proof) that the first set of polynomials is derived from the witness assignment. Performing the second round of computation produces a second set of polynomials and a set of challenges. In some embodiments, the set of challenges are random values ​​derived during the execution of the zero-knowledge proof protocol.

[0051] At point 714, the set of challenges, the second set of commitments derived from the second set of polynomials, and the first evaluation proof are sent to the prover system. The polynomial commitments (similar to how commitments are derived from the first set of polynomials from the first round) and the corresponding evaluation proofs are derived from the second set of polynomials (e.g., using the KZG protocol) and then sent to the prover system along with the set of challenges. The evaluation proofs corresponding to the polynomial commitments computed in the second round constitute a way for the proof builder to convince the final verifier that, when evaluated at a given point, the polynomial of each commitment evaluates to the stated evaluation. In some embodiments, the polynomial commitments and the corresponding evaluation proofs are both 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 the set of challenges form an "intermediate proof state" sent from the client device to the prover system so that the prover system can perform zero-knowledge proofs. Because no component of the intermediate proof state can be used to recover private input data, the data privacy of the private input data is secure.

[0053] Figure 8 This is a flowchart illustrating an example of a process for performing a second proof calculation according to some embodiments. In some embodiments, process 800 is at least partially in Figure 1 The proof system is implemented at 104 points.

[0054] At point 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, wherein the private input data of the transaction cannot be recovered from one or more of the first set of commitments, the second set of commitments, the first evaluation proof, and the set of challenges. As described above, the first set of commitments, the second set of commitments, the first evaluation proof, and the set of challenges are computed (pre-computed) by the client device by performing a first proof computation (pre-computation) of the zero-knowledge proof corresponding to the transaction (e.g., using...). Figure 7 The process (such as process 700) generates the transaction proof. For example, the first set of commitments, the second set of commitments, the first evaluation proof, and the set of challenges and proof delegation requests are sent together from the client device to complete the generation of the transaction proof.

[0055] At position 804, identify the set of functions associated with the requested transaction. For example, this set of functions associated with the transaction can be identified in the proof delegation request.

[0056] At 806, a third round of computation is performed, at least in part, based on the set of functions and the set of challenges, to generate a third set of polynomials and a sum of declarations. In some embodiments, the polynomials are derived from matrices representing the functions. These polynomials are derived from function-specific matrices but are general to all transactions using these functions. The set of challenges received from the client device is transaction-specific but cannot be used to recover the transaction's private input data. In some embodiments, polynomial interpolation is used to generate a polynomial corresponding to each matrix, which is derived from the different functions to be performed for the transaction. These polynomials derived from the function-related matrices are the "third set of polynomials." This third set of polynomials and the set of challenges are then used to determine the "sum of declarations." In some embodiments, the sum of declarations of the third round output is an evaluation of each polynomial in the third set at each challenge value data point (received from the client device). The sum of declarations is the sum of the evaluations of each polynomial in the third set at each challenge value.

[0057] At point 808, the third set of commitments is derived from the third set of polynomials. As mentioned above, the polynomial commitments (“third set of commitments”) can be derived from the third set of polynomials using the KZG protocol.

[0058] At position 810, a fourth round of computation is performed, at least in part, based on the third set of polynomials, to generate the fourth set of polynomials.

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

[0060] Figure 9 This is a flowchart illustrating an example of a process for completing a full proof according to some embodiments. In some embodiments, process 900 is at least partially in... Figure 1 The proof system is implemented at 104 points.

[0061] At point 902, a complete zero-knowledge proof corresponding to the transaction is generated, at least in part, based on the corresponding set of commitment and evaluation proofs corresponding to the multi-round computations already performed across the client device and the prover system. In some embodiments, the zero-knowledge proof corresponding to the transaction is constructed using the corresponding polynomial commitment and evaluation proofs generated by four rounds of computation. As described above, in some embodiments, the first two rounds (constituting the "private" part of the zero-knowledge proof protocol) are first computed by the client device, and the last two rounds (constituting the "public" part of the zero-knowledge proof protocol) are then delegated to and computed by the prover system.

[0062] At point 904, the complete zero-knowledge proof is sent to the blockchain along with other public transaction information, where the blockchain is configured to confirm transactions at least partially based 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, blockchain nodes will confirm / verify the proof before confirming 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 sequence number of the input record.

[0063] In some other embodiments, instead of the prover system constructing the complete zero-knowledge proof based on the polynomial commitment and evaluation proofs corresponding to the four rounds of computation, the prover system sends the polynomial commitment and evaluation proofs generated from its computed rounds (rounds three and four) to the client device. The client device then has the polynomial commitment and evaluation proofs corresponding to all four rounds and can then construct the 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 A high-level description is shown of a client device, according to some embodiments, delegating a portion of proof computation to a single prover. The requested transaction for which zero-knowledge is to be computed can be multiple functions, including one or more instances of functions of the same type (e.g., three instances of function type 1, two instances of function type 2, and one instance of function type 3) and / or instances of different function types (e.g., one instance of function type 1, one instance of function type 2, and one instance of function type 3). Figure 10 As shown, the client device takes public input data, private input data, and a function associated with the transaction as input. The private input data (e.g., sensitive user data) may be stored locally on the client device and, according to the various embodiments described herein, is not passed to the prover system during the delegation process to avoid leakage of private information. Therefore, in the delegation system described herein, the private input data is only used during the pre-computation proof at the client device and is not subsequently passed to another entity (e.g., the prover). Instead, the pre-computation at the client device results in an intermediate proof state, which includes values ​​that cannot be used to recover the private input data. In various embodiments, the prover system receiving the intermediate proof state associated with the transaction knows the function to be used to complete the transaction proof. For example, the function associated with the transaction can be queried from a blockchain where the function of the transaction was previously deployed. The prover system then completes the remainder of the proof computation based on the transaction function and the intermediate proof state.

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

[0066] The computational complexity of the first proof computation / pre-computation performed by the client device can be described as O(n log n) and O(n), where n = the number of constraints, i.e., the number of constraints when the functionally dependent circuit is arithmetically represented as a matrix. The computational complexity of the second proof computation performed by the prover can be described as O(m log m) and O(m), where m = the number of non-zero entries, which is the number of terms in the matrix when the functionally dependent circuit is arithmetically represented. Empirical observations using protocols like the Marlin protocol to compute zero-knowledge proofs show that m > n; therefore, at the prover system, the portion of the second proof computation is more complex (e.g., more computationally expensive) than the first proof computation / pre-computation at the client device. Thus, this protocol alleviates the computationally intensive task of the client device performing the complete proof, even though the client device's hardware is relatively weaker than the prover system.

[0067] Figure 11 This is a sequence diagram illustrating an example process of deleting proof generation from a client device to a proof generator system according to some embodiments. In some embodiments, Figure 7 Process 700 and Figure 8 The process 800 can at least partially utilize Figure 11 The process is achieved through 1100.

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

[0069] At 1102, rounds 1 and 2 of the zero-knowledge proof (zkp) protocol are computed at the client device based on public input data, private input data, and transaction-related functions.

[0070] At point 1104, the commitment for round 1, the commitment for round 2, the evaluation proof for round 2, and a set of challenges are generated at the client device and sent to the prover system.

[0071] Calculation round 1 sample and Sample mask polynomial , making As described in the mathematical description above, in round 1, private input data and public input data Formatted as witness assignment The vector of witness assignment is multiplied by matrices (A and B), which are arithmetic circuit representations of functions associated with the transaction. Polynomials (e.g.) and The polynomials are generated from matrix-vector products using polynomial interpolation. For example, the number of polynomials generated is as many as the number of instances of the function execution. Furthermore, random polynomials are generated for randomness. m ).

[0072] Round 1 commitment sent to the proof system promise As shown above, the polynomial commitment is derived from the polynomial generated in round 1 (e.g., using the KZG protocol).

[0073] Calculation round 2 calculate and On H Perform a total check make turn up , making use ,Evaluate Sum of all To build a virtual .

[0074] Use of randomness PC.Open is used to build the following batch opening certificate. :exist place right The assessment.

[0075] As described in the mathematical description above, in round 2, the polynomial generated in round 1 is used to generate additional polynomials (e.g., g1 and h1) and a set of challenges ( and ).

[0076] In particular, this set of challenges is based on commitments generated from round 1 (e.g., The hash is derived from the witness task in round 1. While the commitment is derived from the witness task itself, the commitment does not reveal any private / sensitive data from the witness task; therefore, the hash derived from the commitment does not reveal any personal / sensitive data in the witness assignment. Thus, this set of challenges can be shared / sent with the prover system without revealing any sensitive data that might be included in the witness task.

[0077] g1 and h1 are polynomials that can be used to convert the above summation check declarations into polynomial equality declarations, which is a type of declaration that is easier to check.

[0078] g1 and h1 can be obtained by (as shown above) Divided by the vanishing polynomial .

[0079] Commitments and challenges sent to the proof system in round 2 promise and As shown above, polynomial commitment Derive the polynomial from round 2 (e.g., using the KZG protocol). Challenge and It is derived from transaction-specific but seemingly random data and cannot be used by the prover system to recover private input data.

[0080] At 1106, rounds 3 and 4 of the zkp protocol are computed at the prover system.

[0081] At point 1108, the commitment for round 3, the commitment for round 4, and the evaluation proof for round 4 are generated in the prover system.

[0082] Calculation round 3 For each ,exist Top Perform a total check make make turn up and , making As described in the mathematical description above, in round 3, the matrix polynomial is determined from different types of functions associated with the transaction (e.g., by...). (indicate), and use the set of challenges ( and ) to determine the polynomial ( and ).

[0083] Rounds 3 and 4 jointly achieve the matrix-vector product A by reducing it to a specific summation check statement. Z B Z and C Z Valid check. Polynomial and Used for the same purpose as polynomial g1 in round 2.

[0084] Commitments and statements in Round 3 sum promise The sum of the statements As shown above, polynomial commitment Derived from the polynomial generated in round 4 (e.g., using the KZG protocol). Sum of declarations. It is a matrix polynomial in including challenges and The sum of the evaluations at the data points.

[0085] Calculation round 4 make As the mathematical description above shows, in round 4, the polynomial (h2) is derived from the polynomial generated in round 3.

[0086] Commitment in Round 4 promise As shown above, polynomial commitment ( The polynomial generated in round 4 is derived (e.g., using the KZG protocol).

[0087] At 1110, the complete zkp is generated by the prover system, which combines the commitments of round 1, round 2, round 3, round 4, the evaluation proof of round 2, and the evaluation proof of round 4.

[0088] use And for each , index the commitment into Evaluate Sum of all To construct a virtual commitment (VCM)mat .

[0089] Use of randomness PC.Open is used to build the following batch opening certificate. :exist place right The assessment.

[0090] Calculate and combine the commitments, evaluations, and assessments from rounds 1, 2, 3, and 4 to generate a complete justification. 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., included by an array). For example, the evaluations include those from round 2. and round 4 The assessment.

[0091] At point 1112, the complete zkp and public information of the transaction are sent to the blockchain by the proof system.

[0092] In some embodiments, to complete the computation of the full proof, the client device or prover system may construct the full proof using commitment and evaluation proofs from four rounds. The delegation process can be configured to specify any one of the client device or prover systems to construct the full proof using commitment and evaluation proofs from four rounds. In some embodiments, one of the client devices or provers may be selected to construct the full proof based on one or more factors, such as the amount of idle computing power and / or whether the entity is connected to a network. In some embodiments, the entity constructing the full proof sends the full proof to a blockchain network, which can verify the associated transaction based on the proof before recording the output on the ledger.

[0093] Figure 12 This is a sequence diagram illustrating an example process for verifying proofs according to some embodiments. In some embodiments, process 1200 is implemented by a blockchain node or any party.

[0094] At position 1202, a complete zero-knowledge proof of the transaction is obtained. For example, the proof is provided by, for instance, a zero-knowledge proof of the transaction. Figure 11 It is generated by processes such as 1100.

[0095] At point 1204, determine whether the zero-knowledge proof can be verified. If the zero-knowledge proof can be verified, control transfers to point 1206. Otherwise, if the zero-knowledge proof can be verified, control transfers to point 1208.

[0096] verify The validator will need to perform the following checks: The verifier will calculate t i The following checks will be required: In other words, the validator will use all parts of the complete proof of π (all commitments, all evaluation proofs, all evaluations) to check whether the two polynomials derived from the sum check of rounds 2 and 4 are equal.

[0097] At point 1206, the transaction is confirmed. In some embodiments, if the proof can be verified by blockchain nodes, the transaction is confirmed and added to the blockchain. For example, if the transaction is a token transfer, confirming such a transaction might involve adding an output record (e.g., a record of token spending / transfer) to the ledger that serves as the blockchain.

[0098] At point 1208, the transaction confirmation is rejected. However, if a blockchain node cannot verify the proof, the transaction will not be confirmed and therefore will not be added to the blockchain. For example, if the transaction is a token transfer, rejecting the confirmation of such a transaction may result in the transaction's output records (e.g., files recording token spending / transfer) not being added to the ledger that serves as the blockchain.

[0099] While the example above shows a proof computation scheme involving four rounds, in other examples, the proof computation scheme may involve more or fewer rounds of computation.

[0100] Although the embodiments described above have been given in detail for clarity of understanding, the invention is not limited to the details provided. Many alternative methods of carrying out the invention are available. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system comprising: The first processor is configured as follows: It receives private and public input data to generate computationally intensive proofs associated with transactions to be published to the blockchain; and The first proof computation is performed, at least in part, based on private and public input data, to generate an intermediate proof state; An interface is configured to send an intermediate proof state to a second processor, wherein the second processor is 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, wherein the second processor derives from the intermediate proof state that private input data is computationally infeasible.

2. The system of claim 1, wherein computationally intensive proofs include zero-knowledge proofs.

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

4. The system of claim 1, wherein performing the first proof calculation comprises: Combine a set of functions associated with a transaction into a function-dependent arithmetic circuit; and Format the public and private input data associated with the transaction into a witness assignment.

5. The system of claim 4, wherein performing the first proof calculation further comprises: Perform matrix multiplication between function-dependent arithmetic circuits and witness assignments to generate a set of matrix multiplication products; and The first set of polynomials is derived from the set of multiplicative products using polynomial interpolation, wherein the intermediate proof states include the first set of commitments derived from the first set of polynomials.

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

7. The system of claim 5, wherein performing the first proof calculation further comprises: The second round of computation is performed at least in part based on the first set of polynomials to confirm that the first set of polynomials is derived from the witness assignment, and to generate the second set of polynomials and a set of challenges, wherein the intermediate proof state also includes the set of challenges, the second set of commitments derived from the second set of polynomials, and the first evaluation proof.

8. The system of claim 1, wherein the second processor configured to perform the second proof calculation comprises: The matrix polynomial is obtained based on a set of functions associated with the transaction; The third set of polynomials is determined based on the matrix polynomial and a set of challenges included in the intermediate proof states received from the first processor; and The third set of commitments is derived from the third set of polynomials.

9. The system of claim 8, wherein the second processor configured to perform the second proof calculation comprises: The fourth round of computation is performed, at least in part, based on the third set of polynomials, to generate the fourth set of polynomials; and The fourth set of commitments and the second evaluation proof are derived from the fourth set of polynomials.

10. The system of claim 9, wherein the intermediate proof state includes a first set of commitments associated with a first round of computation, a second set of commitments associated with a second round of computation, and a first evaluation proof associated with a second round of computation, and wherein generating a computationally intensive proof associated with a transaction includes 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. The system of claim 1, wherein the first processor is configured to send computationally intensive proofs to a blockchain, wherein the blockchain is configured to verify the computationally intensive proofs to confirm transactions.

12. The system of claim 1, wherein the first proof computation has lower computational complexity compared to the second proof computation.

13. The system of claim 1, wherein the common input data includes the root of the Merkle tree, wherein the Merkle tree is determined based on records from the blockchain.

14. A method comprising: Private and public input data are received at the first processor to generate computationally intensive proofs associated with the transactions to be published to the blockchain; and At the first processor, a first proof computation is performed based at least in part on private input data and public input data to generate an intermediate proof state; An intermediate proof state is sent from a first processor to a second processor, wherein the second processor is 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 the transaction, wherein the second processor derives from the intermediate proof state that the private input data is computationally infeasible.

15. The method of claim 14, wherein performing the first proof calculation comprises: Combine a set of functions associated with a transaction into a function-dependent arithmetic circuit; and Format the public and private input data associated with the transaction into a witness assignment.

16. The method of claim 15, wherein performing the first proof calculation further comprises: Perform matrix multiplication between function-dependent arithmetic circuits and witness assignments to generate a set of matrix multiplication products; and A first set of polynomials is derived from the set of multiplicative products using polynomial interpolation, wherein intermediate proof states include a first set of commitments derived from the first set of polynomials.

17. The method of claim 16, wherein performing the first proof calculation further comprises: The second round of computation is performed at least in part based on the first set of polynomials to confirm that the first set of polynomials is derived from the witness assignment, and to generate the second set of polynomials and a set of challenges, wherein the intermediate proof state also includes the set of challenges, the second set of commitments derived from the second set of polynomials, and the first evaluation proof.

18. The method of claim 14, wherein the second processor configured to perform the second proof calculation comprises: The matrix polynomial is obtained based on a set of functions associated with the transaction; The third set of polynomials is determined based on the matrix polynomial and a set of challenges included in the intermediate proof states received from the first processor; and The third set of commitments is derived from the third set of polynomials.

19. The method of claim 18, wherein the second processor configured to perform the second proof calculation comprises: The fourth round of computation is performed, at least in part, based on the third set of polynomials, to generate the fourth set of polynomials; and The fourth set of commitments and the second evaluation proof are derived from the fourth set of polynomials.

20. The method of claim 19, wherein the intermediate proof state includes a first set of commitments associated with a first round of computation, a second set of commitments associated with a second round of computation, and a first evaluation proof associated with a second round of computation, and wherein generating a computationally intensive proof associated with a transaction includes 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