System for protecting verification key from alteration and verifying validity of proof of correctness

Abstract

The invention relates to a distributed ledger technology, such as a consensus-based block chain. A blockchain transaction may include a digital resource locked by a locking script that encodes a set of conditions that must be satisfied prior to using the locked resource (e.g., transferring ownership / control of the locked resource). A worker (e.g., a computer system) performs one or more calculations to generate a proof that is encoded as part of an unlock script. A verification algorithm may utilize an attestation, a verification key, and additional data, such as encrypted material associated with a worker (e.g., a digital signature), to verify that the digital asset of the transaction should be transferred. As a verification result of the transaction, any third party can check whether the contract is corrected instead of re-executing the contract, thereby saving computing power.

Description

[0001] This application is a divisional application of a patent application with Chinese application number 201880072801.5, application date October 29, 2018, and name “System for protecting verification keys from being altered and verifying the validity of correctness proof”. Technical Field

[0002] The present invention generally relates to blockchain technology, and more specifically, to executing a zero-knowledge protocol on a blockchain by utilizing a locking script to protect verification keys from being altered and verify the validity of correctness proofs. The present invention further utilizes cryptographic and mathematical techniques to strengthen the security associated with electronic transmissions over a blockchain network. The present invention is particularly suitable for, but not limited to, use in smart contract generation and execution. Background Art

[0003] As used herein, the term "blockchain" may refer to any of several types of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. It should be noted that the present invention is not limited to use with a particular blockchain; alternative blockchain implementations and protocols, including non-commercial applications, also fall within the scope of the present invention.

[0004] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system consisting of blocks, which in turn may consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured set of field values ​​including data and a set of conditions, where satisfying the set of conditions is a prerequisite for writing the field set to the blockchain data structure. For example, each transaction is a data structure that encodes a transfer of control of a digital asset between participants in a blockchain system, and each transaction includes at least one input and at least one output. In some embodiments, a "digital asset" refers to binary data associated with a right to use. In some implementations, the transfer of control of a digital asset may be performed by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block of the blockchain may contain a hash of the previous block so that the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation.

[0005] In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models and operations. That is, a stack-based scripting language can utilize a stack. By using a stack, values ​​can be pushed to the top of the stack or popped from the top of the stack. Various operations performed on the stack result in one or more values ​​being pushed to the top of the stack or popped from the top of the stack. For example, the OP_EQUAL operation pops the first two items from the stack, compares them, and pushes the result (e.g., 1 in the case of equality and 0 in the case of inequality) to the top of the stack. Other operations performed on the stack, such as OP_PICK, may allow items to be selected from locations other than the top of the stack. In some scripting languages ​​used in some embodiments, there may be at least two stacks: a main stack (mainstack) and an alternate stack (alternatestack). Some operations of the scripting language may move items from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternate stack. It should be noted that in some cases, a stack-based scripting language may not be limited to operations that are performed in a strict last-in, first-out (LIFO) manner. For example, a stack-based scripting language may support operations that copy or move the nth item in a stack to the top (e.g., OP_PICK and OP_ROLL, respectively). Scripts written in a stack-based scripting language may be pushed to a logical stack, which may be implemented using any suitable data structure, such as a vector, a list, or a stack.

[0006] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes perform work to ensure that each transaction is valid and invalid transactions are rejected by the network. A node can have different validity criteria than other nodes. Because the validity of the blockchain is based on consensus, a transaction is considered valid if a majority of nodes agree that it is valid. The software client installed on the node performs this validation work in part by executing the unspent transaction output (UTXO) lock and unlock scripts on transactions that reference UTXO. If the execution of the lock and unlock scripts evaluates to true (TRUE), and other validation conditions are met (if applicable), the transaction is validated by the node. Validated transactions are propagated to other network nodes, which can then choose to include the transaction in the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction (if the transaction is validated, the node relays the transaction to other nodes in the network); ii) be added to a new block; and iii) have the transaction added to the public ledger of past transactions. When a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible, the transaction is considered confirmed.

[0007] Digital entrepreneurs have begun exploring the use of cryptographically secure systems and data that can be stored on blockchains to implement new systems. It would be very beneficial if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of blockchains (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more versatile in their applications.

[0008] This disclosure describes technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable and executable program recorded in a blockchain transaction. A blockchain-based computer program may include rules that may process inputs to produce results, and actions may then be performed based on those results. One area of ​​current research is the use of blockchain-based computer programs to implement "smart contracts." Unlike traditional contracts written in a natural language, a smart contract may be a computer program designed to automatically execute the terms of a machine-readable contract or agreement.

[0009] Another area of ​​interest related to blockchain is the use of 'tokens' to represent real-world entities and transfer them via blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, the token acts as an identifier that allows the real-world item to be referenced from the blockchain.

[0010] In an embodiment, although the interaction with a specific entity can be encoded at specific steps in a smart contract, the smart contract can also be automatically executed and self-enforced. Smart contracts are machine-readable and executable. In some examples, automatic execution refers to the successful execution of a smart contract to achieve the transfer of UTXO. Note that in these examples, the "entity" that can cause the transfer of UTXO refers to an entity that can create an unlocking script without proving knowledge of a secret. In other words, the unlocking transaction can be verified without verifying that the data source (e.g., the entity that creates the unlocking transaction) has access to the cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). In addition, in such an example, self-enforcement refers to enabling the verification node of the blockchain network to implement the unlocking transaction according to the constraints. In some examples, "unlocking" UTXO (also called "spending UTXO"), used in a technical sense, refers to creating an unlocking transaction that references UTXO and is effectively executed.

[0011] Blockchain transaction outputs include a locking script and information about the ownership of a digital asset. A locking script, which can also be called an encumbrance, "locks" a digital asset by specifying the conditions that must be met to transfer the UTXO. For example, a locking script may require certain data to be provided in an unlocking script to unlock the associated digital asset. A locking script is also called a "script public key." One technique for requiring a party to provide data to unlock a digital asset involves embedding a hash of the data inside a locking script. Summary of the invention

[0012] It would therefore be desirable to provide methods and systems that improve blockchain technology in one or more of these aspects.

[0013] Such an improved solution is now designed.

[0014] Thus, in accordance with the present invention, certain systems and methods are provided.

[0015] According to the present invention, a computer-implemented method for a node of a blockchain network may be provided, the computer-implemented method comprising: generating a transaction output of a transaction, the transaction output comprising a digital asset indication and a locking script, the locking script encoding a set of conditions for transferring control of the digital asset, and determining the satisfaction of the set of conditions based at least in part on a verification key and a proof; generating a transaction input of the transaction, the transaction input comprising: an identifier associated with the transaction output and an unlocking script containing the proof; and verifying the satisfaction of the set of conditions based at least in part on the locking script and the unlocking script; and transferring control of the digital asset in response to verifying the satisfaction of the set of conditions.

[0016] According to the present invention, a computer-implemented verification method can be provided, comprising: generating a transaction output of a transaction, the transaction output comprising an indication of a digital asset and a locking script, the locking script encoding a set of conditions for transferring control of the digital asset, and determining the satisfaction of the set of conditions based at least in part on a verification key and a proof; generating a transaction input of the transaction, the transaction input may comprise an unlocking script, the unlocking script comprising the proof; and, verifying the satisfaction of the set of conditions based at least in part on the locking script and the unlocking script; and, in response to verifying the satisfaction of the set of conditions, transferring control of the digital asset.

[0017] Optionally, the transaction input may also include an identifier associated with the transaction output.

[0018] The verification key may include a first plurality of finite field elements and the proof includes a second plurality of finite field elements.

[0019] The finite field elements may be points on an elliptic curve.

[0020] The finite field elements may be encoded in a compressed format.

[0021] Preferably, the method may include the client encoding the transaction input using a verification key and a first digital certificate associated with the client, and the worker encoding the transaction input using the certification and a second digital certificate associated with the worker.

[0022] The locking script may include instructions to reclaim the digital asset for the provider of the digital asset if the unlocking script does not satisfy the set of conditions.

[0023] The unlocking script may also include a redemption script, wherein the verification key and the redemption script encode sufficient information to determine that at least a subset of the set of conditions is satisfied; and the locking script encodes a condition of the set of conditions, which is that a hash of the redemption script matches a predetermined value.

[0024] The redemption script may be less than or equal to a predetermined maximum value, for example, 520 bytes.

[0025] The unlocking script may include one or more elements of the verification key, and the redemption script may include at least some remaining elements of the verification key. The unlocking script and the redemption script may collectively include the verification key.

[0026] The transaction may be a script hash based transaction, for example the transaction may be a P2SH transaction.

[0027] The lock script, unlock script, and redeem script of a transaction can be based on the transaction based on the script hash.

[0028] The transaction's locking script, unlocking script, and redeem script can be based on a Pay-to-Script-Hash (P2SH) transaction or a variation thereof.

[0029] The transaction may be in accordance with a standard transaction based on a blockchain-based protocol.

[0030] Scripts such as locking scripts and unlocking scripts may be encoded using commands and data in a stack-based scripting language, where the commands and data are placed on a stack in a last-in-first-out order.

[0031] The set of conditions may include one or more bilinear constraints.

[0032] It is also desirable to provide a system comprising: a processor; and a memory comprising executable instructions, wherein the executable instructions are executed by the processor so that the system performs any of the methods described above.

[0033] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon, the executable instructions being executed by one or more processors of a computer system so that the computer system performs at least any of the methods described above.

[0034] The present invention may be described as a verification method / system and / or a control method / system for controlling the exchange or transfer of digital assets via a blockchain. In some embodiments, the digital asset is a token. As described below, the present invention may also be described as a security method / system for a new, improved and advantageous way of performing operations via a blockchain network or platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] These and other aspects of the invention will become apparent and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0036] Figure 1 A blockchain environment in which various embodiments may be implemented is shown;

[0037] Figure 2 shows a computing environment that may be used to implement a protocol according to various embodiments;

[0038] Figure 3 A diagram showing an environment suitable for performing verifiable computations;

[0039] Figure 4 An example diagram is shown in which points on an elliptic curve are represented using compressed and uncompressed encodings suitable for use with blockchain scripts such as locking or unlocking scripts, according to an embodiment;

[0040] Figure 5 A diagram is shown in which a client provides a verification key for use in verifying a certificate;

[0041] Figure 6 A diagram is shown in which a worker provides a verification key for use in verifying a certification;

[0042] Figure 7 A diagram showing a process 700 for generating a redemption script according to an embodiment; and

[0043] Figure 8 A computing device is shown that can be used to practice at least one embodiment of the invention. DETAILED DESCRIPTION

[0044] First reference Figure 1, which shows an example blockchain network 100 associated with a blockchain according to an embodiment of the present application. In this embodiment, the example blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each node running an instance of software and / or hardware that performs operations that follow a blockchain protocol that is at least partially agreed to by an operator of the node 102. In some examples, a "node" refers to a peer-to-peer electronic device distributed in a blockchain network.

[0045] In some embodiments, node 102 may be implemented by any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), multiple computing devices in a distributed system of a computing resource service provider, or a plurality of computing devices such as a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), or a plurality of computing devices in a distributed system of a computing resource service provider. Figure 8 800, etc.) of any suitable electronic client device. In some embodiments, node 102 has an input for receiving a data message or object representing a proposed transaction (e.g., transaction 104). In some embodiments, a node may be queried to obtain information maintained by it, for example, to obtain status information of transaction 104.

[0046] like Figure 1 As shown, some nodes 102 are communicatively coupled to one or more other nodes 102. Such communicatively coupling may include one or more of wired or wireless communications. In this embodiment, each node 102 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger will be a distributed ledger. Transactions processed by a node affecting the ledger may be verified by one or more other nodes, thereby maintaining the integrity of the ledger.

[0047] As to which nodes 102 can communicate with which other nodes, assuming that the message is a message that the blockchain protocol indicates should be forwarded, each node in the example blockchain network 100 is able to communicate with one or more other nodes 102, so that the message passed between the nodes can be transmitted in the example blockchain network 100.

[0048] It is sufficient that a message is propagated along a path (or some significant portion thereof) of a blockchain. One such message may be a message from a node 102, e.g., node 102A, publishing a proposed transaction, which is then propagated along a path, e.g., path 106. Another such message may be a message proposing a new block for inclusion in the blockchain.

[0049] In one embodiment, at least some of the nodes 102 are network nodes that perform complex computations such as solving cryptographic problems. The network nodes that solve the cryptographic problems create new blocks for the blockchain and broadcast the new blocks to the other nodes 102. The other nodes 102 verify the work of the network nodes and, upon verification, accept the block into the blockchain (e.g., by adding it to the distributed ledger of the blockchain).

[0050] In some examples, a block is a group of transactions, typically marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this way, each block can be linked to the previous block, creating a "chain" that links blocks in the blockchain. In an embodiment, valid blocks are added to the blockchain through the consensus of nodes 102. Also in some examples, the blockchain includes a list of verified blocks.

[0051] In one embodiment, at least some nodes 102 operate as verification nodes that verify transactions as described herein. In some examples, transactions include data that provide proof of ownership of digital assets and conditions for accepting or transferring ownership / control of digital assets. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates (e.g., transfers ownership or control) at least a portion of a digital asset indicated by a UTXO of a previous transaction with an entity associated with a blockchain address. In some examples, a "previous transaction" refers to a blockchain transaction that contains a UTXO referenced by an unlocking transaction. In some embodiments, a transaction includes a "locking script" that locks (encumbers, also translated as obstructions) a transaction with a condition that must be met before ownership / control can be transferred ("unlocked").

[0052] In some embodiments, a blockchain address is an alphanumeric string associated with an entity to which control of at least a portion of a digital asset is transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between a public key associated with an entity and a blockchain address. In some embodiments, verification of a transaction includes verifying one or more conditions specified in a locking script and / or unlocking script. Upon successful verification of transaction 104, the verification node adds transaction 104 to the blockchain and distributes it to nodes 102.

[0053] The systems and methods described herein relate to enabling a locking script to protect a verification key V K It cannot be altered and verifies the validity of the proof π, allowing zero-knowledge protocols to be executed on the blockchain during transaction verification.

[0054] Verifiable computation is a technique that allows for the generation of proofs of computation. In one embodiment, a client utilizes this technique to outsource the evaluation of a function f on an input x to another computational entity referred to herein as a worker. In some cases, the client is computationally limited such that it is infeasible for the client to perform the evaluation of the function (e.g., the expected runtime of the computation using the client's available computational resources exceeds a maximum acceptable threshold), although this may not necessarily be the case, in general, the client may delegate the evaluation of the function f on the input x based on any suitable criteria, such as computational runtime, computational cost (e.g., the financial cost of allocating computational resources to perform the function evaluation), etc.

[0055] In one embodiment, a worker is any suitable computing entity, such as a blockchain node as described in more detail elsewhere in this application. In one embodiment, a worker (e.g., a blockchain node) evaluates a function f on an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by other computing entities (e.g., clients as described above) and / or other nodes of the blockchain network. Proofs, which may also be referred to as arguments, can be verified faster than actual computations, and thus computational overhead (e.g., reducing power overhead and costs associated with powering and running computing resources) can be reduced by verifying the correctness of the proof rather than recomputing the function f on the input x to determine the correctness of the output generated by the above worker. In zero-knowledge verifiable computation, a worker provides a proof to a client proving that the worker knew of an input with specific properties.

[0056] An efficient variant of zero-knowledge proofs is zk_SNARK (Succinct Non-Interactive Argument of Knowledge). In one embodiment, all pairing-based zk_SNARKs include a process in which workers use universal group operations to compute multiple group elements, and verifiers use multiple pairing product equations to verify the proof. In one embodiment, linear interactive proofs work over finite fields, and worker and verifier messages include information that encodes, references, or otherwise includes vectors that can be used to determine field elements.

[0057] In one embodiment, the systems and methods described herein allow a blockchain's network nodes to perform a computation (e.g., evaluation of a function f on an input x) and generate a proof that can be used to verify the correctness of an output, where evaluating the correctness of the proof is computationally cheaper than evaluating the function. In this context, the cost (i.e., how expensive) of an operation or task can refer to the computational complexity of performing the operation or task. In one embodiment, the computational complexity refers to the average computational cost or the worst-case computational cost of performing a sorting algorithm, e.g., both the heap sort algorithm and the quick sort algorithm have an average computational cost of O(nlogn), but quick sort has a worst-case computational cost of O(nlogn).2 ), while heap sort has a worst-case computational cost of O(nlogn). In one embodiment, the average computational cost and / or the worst-case computational cost of evaluating the function f on the input x is more expensive than the average computational cost and / or the worst-case computational cost of evaluating the correctness of the proof. Therefore, the use of the systems and methods described herein is very advantageous and, for example, may allow computationally more expensive contracts to be run because such contracts do not proportionally increase the time required to verify the blockchain. Further advantages may include reducing the power consumption of the verifier system, thereby improving the efficiency of the verifier computer system and reducing the energy costs associated with running such a verifier computer system to evaluate the correctness of the proof. Currently, smart contracts must be executed and verified on all nodes, a constraint that limits the complexity of smart contracts. The methods and systems described herein may be used to implement a system that increases the efficiency of a blockchain by executing a contract once to generate a proof of correctness, and based on the proof of correctness provided by the worker and the verification key provided by the client, all nodes of the blockchain may verify the validity of the contract. In this way, the efficiency of the blockchain is improved by increasing the throughput of smart contracts that can be executed together by the nodes of the blockchain and / or allowing computationally more expensive smart contracts.

[0058] In one embodiment, the verification key V can be extracted from the input / output data and the public parameters generated during the setup phase of the zero-knowledge protocol and used with the proof π K or part thereof, to verify the so-called computational proof of correctness provided by the worker. For example, as described above and in more detail below, systems and methods that allow locking scripts to protect the verification key V K The validity of the proof π is not altered and verified, thereby allowing the zero-knowledge protocol to be executed on the blockchain during transaction verification. Therefore, the present application provides a system and method for performing the verification phase using a blockchain script for storing elements used in the verification of the calculation.

[0059] Figure 2 A computing environment 200 that can be used to implement the protocol according to various embodiments is shown. The protocol can be implemented using blockchain technology to store proofs of correctness and combine "correct-by-construction" cryptographic methods with smart contracts. In one embodiment, the public verifiable computing scheme includes three phases: a setup phase, a computation phase, and a verification phase.

[0060] The setup phase can be performed as part of a process to outsource the performance of a computing task. As described below, a client can refer to an entity that delegates the performance of a computing task to a worker, such as a customer or client computer system, which can be a different computer system. In general, a client can delegate the performance of a computing task for a variety of reasons, including but not limited to limited computing resources, lack of computing resources, financial costs associated with utilizing a client computer system to perform a task, energy costs associated with utilizing a client computer system to perform a task (e.g., a mobile device or laptop that relies on battery power can utilize a worker to perform a computing intensive task, thereby saving power and extending the use of the battery-powered device), etc.

[0061] In one embodiment, the setup phase includes a client, customer, employee of an organization, or any other suitable entity writing a contract using a formal language with precise semantics. The contract can be written in a high-level programming language, such as C or Java. In general, the contract can be expressed in any language or syntax that can be converted to a format that can be manipulated by a computer system. In one embodiment, a domain-specific language with a limited purpose can provide type-safety and can utilize limited expressive power. The generated source code may be an accurate description of the contract.

[0062] Compiler 202 may be any hardware, software, or combination thereof including executable code that, if executed by one or more processors of a computer system, causes the system to take source code 206 as input and generate a circuit. Compiler 202 may refer to a computer program that executes or completes instructions based on instructions that have been compiled into a machine-readable format (e.g., binary code). It should be noted that although compiler 202 is shown, interpreters, assemblers, and other suitable software and / or hardware components may be utilized to convert source code into a circuit. In one embodiment, the circuit is an arithmetic circuit that includes wires that carry values ​​from field F and are connected to logic and / or arithmetic gates. In one embodiment, the system uses circuits To generate a quadratic program Q 208, the quadratic program includes providing the original circuit A set of polynomials that fully describes .

[0063] In one embodiment, compiler 202 is capable of recognizing a substantial subset of a programming language (e.g., C or Java), including, but not limited to: preprocessor directives, static initializers, global and local functions, block-scoped variables, arrays, data structures, pointers, function calls, function operators (e.g., functors), conditional and loop statements, and arithmetic and bitwise Boolean operators. In one embodiment, compiler 202 does not support a full set of commands in accordance with the programming language standard (in some cases, this may be intended to prevent certain types of algorithms from being executed in smart contracts, e.g., prohibiting recursive algorithms). In one embodiment, the compiler expands the expression of the source code into an operation gate language to generate an operation circuit. Circuit implementations have been envisioned by Campanelli, M. et al. (2017) in “Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for Services” and by Tillich, S. and Smart, B. in “Circuits of Basic Functions Suitable For MPC and FHE”. The operational circuits may be implemented by the compiler 202 or any other suitable hardware, software, or combination thereof (e.g., Figure 2 A software module (not shown in FIG. 1 ) is used to construct a quadratic arithmetic problem (QAP). According to an embodiment, the quadratic program is compiled into a set of cryptographic programs for the client (e.g., key generation and verification) and the worker (e.g., computation and proof generation). In some embodiments, computational circuit optimization techniques such as those described in UK Patent Application No. 1718505.9 can be used to reduce the resources required by the worker to determine the outcome of the smart contract.

[0064] In one embodiment, key generator 204 is hardware, software, or a combination thereof including executable code that, if executed by one or more processors of a computer system, causes the system to generate evaluation keys and verification keys to form a quadratic program. Techniques for encoding computations as quadratic programs are contemplated in Gennaro, R. et al. (2013), "Quadratic Span Programs and Succinct NIZKs without PCPs". In one embodiment, a quadratic arithmetic problem (QAP) Q is a circuit on a field F. is encoded and consists of a set of m+1 polynomials:

[0065] V={v k (x)},W={w k (x)},Y={y k (x)}

[0066] where 0≤k≤m. In addition, the target polynomial t(x) is also defined. Given a function f, it takes n elements of F as input and outputs n' elements, where N = n+n'. Then, if {c1,…,c N}∈F N is a valid assignment of the input and output sets of f and there exists a coefficient list {c N+1 ,…,c m}, then Q calculates f such that t(x) divides p(x):

[0067]

[0068] Therefore, in one embodiment, there must exist some polynomial h(x) such that h(x)·t(x)=p(x). The size of Q is m, and its degree is the degree of t(x).

[0069] In one embodiment, constructing a QAP for an arithmetic circuit includes selecting an arbitrary root r for each multiplication gate g in the circuit. g ∈F, and define the target polynomial as t(x) = ∏ g (xr g ). In one embodiment, an index k∈{1...m} is associated with each input of the circuit and each output of a multiplication gate. The polynomial in V encodes the left input of each gate, W encodes the right input of each gate, and Y encodes the output. For example, if the kth wire is the left input of gate g, then v k (r g )=1, otherwise v k (r g ) = 0. Therefore, for a particular gate g and its root r g , the previous equation can be simplified as follows:

[0070]

[0071] The output value of a gate is equal to the product of its inputs. The divisibility test is decomposed into deg(t(x)) separate tests, where each gate g and root r of t(x) g There is a test such that p(r g ) = 0. The addition gate and the multiplication constant gate have no effect on the size and number of QAPs.

[0072] In one embodiment, a QAP is defined over a field Fp, where p is a large prime number. In one embodiment, it is desirable that a QAP over Fp efficiently computes any function that can be expressed using addition and multiplication modulo p. The operation separation gate can be designed to separate the operation wire a∈Fp (known to be in [0,2 k-1 ]) into k binary output wires. Therefore, it can be seen that Boolean functions can be represented using operation gates. For example, NAND(a,b) = 1–ab. Each embedded Boolean gate requires only one multiplication operation. In addition, new gates such as split can be defined independently and combined with other gates. Given an input a∈F p (It is known that in [0,2 k-1 ]), the separation gate outputs k wires, which hold the binary digits a1,...,a k , so that∑ k 2 i-1 a i =a, each a i Is 0 or 1.

[0073] Finally, the system generates public parameters used by all provers and verifiers as part of the setup phase. It should be noted that the evaluation key E K and verification key V K is derived using a secret value selected by the client. The key generator 204 may utilize a quadratic arithmetic program (QAP) in conjunction with a key generation algorithm to generate the evaluation key E K 210 and verification key V K 212.

[0074] In one embodiment, performing a computational task includes computing, by a worker, a function on input 216 (i.e., a process for evaluating f(x)). In one embodiment, the worker is any suitable computer system to which a client can delegate a computational task. In one embodiment, input 216 includes information proving the identity of the worker, such as a digital signature generated using a private key associated with the worker. In one embodiment, the worker is a computer system to which the client pays a fee (e.g., through the transfer of a digital asset) for successful computations. In one embodiment, the client provides the worker with input x and an evaluation key E. K , the worker uses the evaluation module 214 for the computational procedure to compute the output y (ie, y=f(x), where the input is x and the function is f), and uses the evaluation key E K 210 to generate a proof of correctness 218. In one embodiment, the evaluation module is hardware and / or software including instructions that, if executed by one or more processors of a computer system, cause the computer system to evaluate the values ​​of the internal circuit wires of the QAP 208 and generate an output y of the QAP.

[0075] In one embodiment, each polynomial v of the quadratic program k (x)∈F is mapped to an element g in the bilinear group vk (s) , where s is a secret value chosen by the client, g is the generator of the group, and F is the field of the discrete logarithm of g. In one embodiment, for a given input, the worker evaluates the circuit to obtain the coefficients c corresponding to the quadratic program i The output and internal circuit wire values ​​of . Therefore, the worker can evaluate v(s) = ∑ k∈{m} c k ·v k (s), to obtain g v(s) ; Calculate w(s) and y(s); Calculate h(x) = p(x) / t(x) = ∑ d h i ·x i ; and use h in the evaluation key i and g s(i) Calculate g h(s) In one embodiment, the correctness proof 218 includes (g v(s) ,g w(s) ,g y(s) ,g h(s) ), and the verifier uses a bilinear map to verify that p(s) = h(s) t(s). In one embodiment, the proof π is stored on the blockchain 222 for later use, or can be verified by multiple parties without the prover having to interact with each of these parties individually. In one embodiment, the evaluation of the circuit storage of the proof of correctness can be performed to unlock the digital asset locked (encumbered) by the transaction's locking script.

[0076] In one embodiment, the proof π is broadcast to the blockchain network, and a verifier 220 is used to verify the proof. In one embodiment, the verifier 220 is any suitable computing entity, such as a node on the blockchain. It should also be noted that in some cases, the evaluation key E is generated. K and verification key V K The same computing entity that verifies the proof also verifies the proof. In one embodiment, the nodes of the blockchain can use the verification key V K and proof π to verify the payment transaction, thereby verifying the contract if the verification succeeds. A requirement of the protocol is that even if the worker knows the verification key V K Therefore, in this protocol, the public reference string (CRS) is published by the client or at least the evaluation key E K and verification key V KIn one embodiment, any computing entity can use the published verification key V K To verify the calculation.

[0077] By using the techniques described herein, a client is able to partially obfuscate transaction data, such as the identity of a recipient of a blockchain transaction. In one embodiment, the unlocking script does not disclose the recipient's address and the recipient's public key. However, in some cases, the value of the transaction (e.g., the amount of digital assets transferred) may be visible to nodes of the blockchain network. In one embodiment, the client converts the locking script into a quadratic arithmetic program using the cryptographic techniques described above and below, and the worker solves the arithmetic program using these cryptographic techniques to generate a proof.

[0078] In general, a client is able to pay a counterparty or worker using standard transactions, such as P2PK and P2PKH. For example, in one embodiment, a client converts a P2PK locking script into an operational circuit and broadcasts a payment transaction that includes a puzzle derived from the circuit. The counterparty or worker receives the circuit, provides appropriate input (e.g., information proving the identity of the worker (e.g., a secret shared between the client and the worker or a digital signature generated using the worker's private key)), and runs the circuit to generate a correctness proof π. In one embodiment, the proof is used to unlock the digital asset. In addition, it may be the case that information identifying the counterparty or worker (e.g., a public key and / or digital signature associated with the counterparty or worker) is not recorded to the blockchain in a clear format.

[0079] In one embodiment, the verification key and corresponding certificate are generated according to the techniques described above and / or below. Thus, the verification key V is provided to the verifier. K And prove π:

[0080]

[0081]

[0082] The verifier is made to compute multiple elliptic curve multiplications (eg, one elliptic curve multiplication for each public input variable) and five pairwise checks, where one pairwise check includes an additional pairwise multiplication.

[0083] Given a verification key V K , prove that π and (a1, a2, …, a N ), to verify that t(x) is divided by p(x), so (x N+1 ,…,x m )=f(x0,…,x N ), the verifier performs the following operations. First, check all three α items:

[0084]

[0085] in, and Then, the validator verifies project β:

[0086]

[0087] and Finally, the verifier checks the divisibility requirement:

[0088]

[0089] in,

[0090] and

[0091] Therefore, according to an embodiment, after considering the notations from the above sections and the examples described in this application, a set of pair checks including the following elements is verified:

[0092]

[0093] Figure 3 A diagram 300 for coordinating the execution of a verifiable computation is shown. Clients 302, workers 304, and verifiers 306 may be nodes of a blockchain network. Client 302 may be any suitable computer system that may include executable code that, if executed by one or more processors of the computer system, causes the computer system to receive a smart contract 308. In one embodiment, smart contract 308 is source code encoded in a high-level programming language, such as C, C++, or Java. In one embodiment, software such as a compiler, interpreter, and / or assembler may be used to convert smart contract 308 into an operational circuit 310 that is composed of a processor carrying a domain name. It should be noted that an arithmetic circuit refers to a logic circuit that can be implemented by a physical circuit comprising a series of physical gates (e.g., using transistor-transistor logic (TTL) integrated circuits (e.g., 7400 series gates, flip-flops, buffers, decoders, multiplexers, etc.)) connected by physical wires.

[0094] In one embodiment, client 302 provides worker 304 with computational circuit 310 and input 312 of the circuit. Circuit 310 can be used to generate a quadratic program Q that includes a set of polynomials that provide a complete description of the original circuit. In either case, worker 304 can execute circuit 310 on input 312. or a quadratic program Q to generate one or more outputs 314. In some embodiments, the worker (ie, the prover) is expected to obtain a valid transcript As output, the transcript is an assignment of values ​​to the circuit wires such that the value assigned to the input wire is x and the intermediate value corresponds to For the correct operation of each gate in , the value assigned to the output wire is If the requested output is incorrect (i.e., Does not exist In one embodiment, the worker is expected to provide a subset of values ​​for the circuit conductors, wherein the selected subset of values ​​for the circuit conductors is not known in advance to the worker.

[0095] In the example, the output The value of the internal circuit wire (or a subset thereof) and the evaluation key E K Used to generate a correctness proof 316. This proof π can be stored on the blockchain and verified by multiple parties without the worker 304 having to interact with the multiple parties individually. In this way, the verifier 306 can use the public verification key V K The client 302 can verify the payment transaction by verifying the contract with the proof π. In some cases, if the verification fails, the client 302 can recover the digital assets locked (encumber) by the payment transaction. In some cases, the verifier 306 and the client 302 are the same computer system.

[0096] Figure 4 A diagram 400 of an embodiment of the present application is shown. Specifically, Figure 4 Points on an elliptic curve 402 are depicted encoded in various formats suitable for blockchain-based scripting.

[0097] In various embodiments, elliptic curve points can be encoded in lock and unlock scripts that are executed in association with a transaction. These scripts can be written in a stack-based scripting language. For example, the verification key V K Can include Prove that π can consist of a set of elements {π1,..,π8}, where and π j is a finite field Points on the elliptic curve on . Figure 4 An example graph 400 is shown in which points on an elliptic curve 402 are compressed using (P C ) or uncompressed (P U ) encoding suitable for use with blockchain scripts such as locking or unlocking scripts.

[0098] In one embodiment, assuming is a point on the elliptic curve. If The point is then represented by its affine coordinates. In the uncompressed encoding 404, point P is represented by information indicating the uncompressed encoding (e.g., prefix 406 (e.g., parameter 'C' described below)) and two field elements (x and y coordinates 408 and 410), while in the compressed encoding, the point is represented only by its x coordinate and an additional bit that uniquely identifies the y coordinate. Thus, in one embodiment, P U =C||X||Y, where:

[0099] C=0x04

[0100] X = FieldElements2OctetString (x)

[0101] Y = FieldElements2OctetString (y)

[0102] The double pipe operator "||" refers to the concatenation operation, and the FieldElements2OctetString() function can be used to convert an element of a field (e.g., a finite field) into an octet string containing exactly eight bits. C =C||X, where:

[0103]

[0104] X = FieldElements2OctetString (x)

[0105] In one embodiment, the uncompressed code 404 includes a finite field (i.e. 408 and y coordinate 410 of a point P on an elliptic curve. Uncompressed encoding 404 also includes information that can be used to determine that the encoding is an uncompressed encoding (e.g., a prefix 406 value prepended / postpended to x-coordinate 408 and y-coordinate 410). In contrast, compressed encoding 412 includes an encoding of a point P of a finite field (e.g., as described above), and information that can be used to determine that the encoding is a compressed encoding. For example, compressed encoding 412A encodes prefix 414 and x-coordinate 408 of point P, wherein a corresponding y-coordinate is determined based at least in part on prefix 414. For example, prefix 414 indicates that the y-coordinate is an even number. In contrast, a second compressed encoding 412B encodes a different prefix 416 and x-coordinate 408 of point P, and is used to determine an odd y-coordinate.

[0106] It should be noted that, in general, the uncompressed point P U can be represented in any suitable format that can be encoded for determining P Uis the information of the uncompressed elliptic curve point, the x-coordinate of the point, and the y-coordinate of the point. Similarly, the compressed point P C can be represented in any suitable format that can be encoded for determining P C It is the information of the compressed elliptic curve point and the compressed information used to determine the x-coordinate and y-coordinate of the point.

[0107] As an example, consider the representation of a point of the secp256k1 elliptic curve. In an embodiment representing an uncompressed point, the first octet in the encoded bit string of the uncompressed elliptic curve P is 0x04, followed by two 256-bit numbers corresponding to the X coordinate of the point and the Y coordinate of the point (i.e., P=C||X||Y). As an example, the Distinguished Encoding Rules (DER) encoding format is used, although other suitable encoding formats are also considered within the scope of the present application, such as Basic Encoding Rules (BER) and Canonical Encoding Rules (CER).

[0108] In one embodiment, a single-byte script opcode including the length of the elliptic curve point is concatenated to the actual point (e.g., the length is concatenated to the front of the actual point). For example, if:

[0109] x=0xe3b01684a8a8b66f8e44203db5869b4dcb74a0afc905ae9197ed74a8d6cecdcc

[0110] y=0x6424d186a23687532c8b20911defc2f42c93749b3736857912c6abe2dc3f01d1 In one embodiment, the compressed and uncompressed script P C and P U They are:

[0111] Script: P C :0x21||

[0112] 0x03e3b01684a8a8b66f8e44203db5869b4dcb74a0afc905ae9197ed74a8d6cecdcc Script: P U :0x41||

[0113] 0x04e3b01684a8a8b66f8e44203db5869b4dcb74a0afc905ae9197ed74a8d6cecdcc6424d1 86a23687532c8b20911defc2f42c93749b3736857912c6abe2dc3f01d1

[0114] In one embodiment, the client is a party to a smart contract and determines to utilize a blockchain to execute the contract. As part of the determination, the client issues a payment transfer to the blockchain to transfer a digital asset controlled by the client to a party (e.g., a worker) that published proof π. A verifier computer system as described above can execute a verification program to determine that proof π is correct.

[0115] According to the protocol, the client can generate a public reference string for generating and producing proof π. In some embodiments, the public reference string is generated by a trusted party (e.g., a third party). It should be noted that although a trusted third party can generate a public reference string, introducing a trusted third party into the protocol is optional - the protocol requires a client and a worker, and can be executed without an additional third party.

[0116] Continuing with the protocol, verification of the computation is performed as part of the transaction verification phase. In one embodiment, the client or worker is restricted to providing As part of the locking script and / or unlocking script. This constraint can be implemented in a variety of ways. For example, in one embodiment, the worker provides the verification key V by injecting a serialized unlock transaction. K , the serialized unlocking transaction contains in one of its unlocking scripts As a second example, a client broadcasts a transaction where the locking script includes and the equation used in the verification phase, and creates a K The client passes this input to the worker who needs to add {π1, .., π8}, sign and broadcast. As another example, the worker provides the verification key V by using a fixed-length script hash (e.g., a 20-byte script hash). K , which is a fixed-length script hashed into the locking script of the transaction that pays for its execution. Of course, these are just some of the ways to provide As an illustrative example of a portion of a locking script, unlocking script, or any other suitable script or operation, these scripts or operations are performed as part of transaction verification according to any suitable blockchain protocol. In one embodiment, the worker provides {π1, .., π8} as part of the unlocking script, and if the proof π satisfies the conditions set in the output script, then the proof π is authorized.

[0117] In one embodiment, the blockchain-based system supports the execution of operations (also known as opcodes and commands) according to a scripting language such as Script. In one embodiment, a transaction includes locking (output) and unlocking (input) scripts and can be identified as one of a list of standard types. For example, there are five standard types: pay to public key (P2PK), pay to public key hash (P2PKH), multi-signature, pay to script hash (P2SH), and OP_RETURN.

[0118] When running the proposed zk protocol described herein, information such as the public reference string, the proof π and / or parts thereof are stored on the blockchain. Additionally, as part of the verification process, it may also be the case that the system extracts a specific element pushed on the stack during the transaction verification process and checks the pairing from the verification phase as described above.

[0119] Transactions may include small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. These scripts are written using a stack-based scripting language. In one embodiment, the protocol includes various technical rules and syntax-based restrictions on transactions that determine whether a transaction is a standard transaction or a non-standard transaction. In one embodiment, there are restrictions on the size of elements pushed on the execution stack and the total size of input scripts. For example, each element pushed on the execution stack is limited to 520 bytes and each input script is limited to 1650 bytes. In one embodiment, after the script is executed, the stack includes exactly one non-false element. The input script cannot contain any OP code other than OP_PUSHDATA (except for the redemption script part). In one embodiment, it should be noted that different blockchain systems may define different quantities and / or units of digital assets to be included as output values. In one embodiment, the minimum output value is zero (i.e., no digital asset needs to be transferred). Transactions that deviate from these rules are considered non-standard.

[0120] As part of the verification phase, the verifier (e.g., the client) extracts the verification key V K and prove the elements of π and use them in the pairing test. In one embodiment, the verification test includes a bilinear map that satisfies a set of constraints. As an example, consider a map that satisfies the form The constrained bilinear map e(x,y)=2 xy , as shown below:

[0121] e(3,4+5)=2 3*9 =2 27

[0122] e(3,4)*e(3,5)=2 3*4 2 3*5=2 12 2 15 =2 27

[0123] It should be noted that this pairing is for illustration purposes, and while this verbatim mapping may not be very useful for applications in cryptographic systems, it should be noted that the process of verifying bilinear constraints is the same, where the bilinear mapping is extended over elliptic curves. Again, for illustration purposes, an example is shown below of how to use a script to verify a key from a public reference string (e.g., the verification key V) during the verification phase. K ) and prove π to extract and use information:

[0124]

[0125] It should be noted that the examples provided above are merely examples of pairwise testing and may include additional constraints, for example, Figure 2 The constraints discussed.

[0126] There are a variety of techniques for providing the verification key V K Used to verify the proof π. Figure 5 is an illustrative diagram 500 in which a client 510 provides a verification key V K , used to verify the proof π. In one embodiment, the client creates a transaction output 502, wherein the transaction includes or is associated with an output value 504 (e.g., a digital asset paid to a worker executing a contract) and a locking script 508, which performs a verification check including a bilinear mapping that satisfies a set of constraints. In one embodiment, the locking script verifies the verification key V based at least in part on the client's digital signature. K In some cases, the locking script may specify that if verification fails, the client can reclaim the digital assets associated with the transaction. In some blockchain systems, a transaction encodes a parameter indicating the size of the locking script (e.g., in bytes) when associated with the locking script. This parameter may be referred to as the locking script size 506. Figure 5 shown.

[0127] As an example, a locking script could be described based on the following:

[0128]

[0129]

[0130] It should be noted that the examples provided above are descriptions of the lock scripts and not necessarily verbatim descriptions of the lock script 508 itself. For example, some of the fields described above in brackets (e.g., "<PubKey Client> ”, which may refer to the client's public key) is not included verbatim in the locking script 508. Similarly, some of the fields in brackets are based on mathematical calculations. For example, as described above, “OP_(i+1)” may not be included verbatim in the locking script, but refers to an opcode or command determined at least in part based on a mathematical calculation, in which case “i” refers to the number of elements that prove π, so in the example of π={π1,..,π8}, “OP_(i+1)” may be represented in the locking script in a stack-based scripting language as “OP_7”. It should also be noted that the text following the double slashes “ / / ” above refers to comments that do not correspond to executable code. For example, “ / / verify pairing” does not map to executable code, but simply indicates to people that the text following the comment is used to perform verification of the pairing.

[0131] It should be noted again that the transaction output 502 described above is merely illustrative, and that variations may exist, i.e., the transaction may include any suitable payment amount in any suitable unit of measure, and that a variety of locking scripts may exist, such as a locking script that utilizes some or all of the functionality of a locking script as described above. In general, the locking script 508 may be any suitable set of commands that perform a set of pairing checks. In one embodiment, the locking script 508 includes verifying the key V using at least one asymmetric public key pair associated with the client. K In one embodiment, the locking script 508 includes instructions to mark the transaction as invalid after a threshold duration (e.g., corresponding to a “<n days> ” value, as described above).

[0132] Client 510 may be those clients described elsewhere in this application, which may create a transaction input 512 that references the transaction 502 described above and transmit it to a counterparty (e.g., a worker who intends to compute a valid proof π). In one embodiment, transaction input 512 may encode an identifier 514 associated with transaction output 502, a transaction output index 516 associated with transaction output 502 (e.g., in some cases, the index is zero-based), an unlocking script 520, a parameter indicating the size of the unlocking script (e.g., in bytes) (which may be referred to as unlocking script size 518), a sequence number 522, and any suitable combination thereof. For example, in some embodiments, the unlocking script size is not explicitly encoded in transaction input 512, but may be derived (e.g., by detecting a particular termination sequence that indicates the end of the unlocking script). In one embodiment, unlocking script 518 includes a verification key V K 524 and a digital signature associated with the client 526. In some cases, unlocking script 518 includes additional information, such as an indication of branch information that controls the execution of the verification process.

[0133] As an example, the unlocking script can be described based on the following:

[0134]

[0135] It should be noted that the examples provided above are descriptions of unlocking scripts, and not necessarily verbatim descriptions of the unlocking scripts themselves. For example, some of the fields described in brackets above are not verbatim included in unlocking script 518. Returning to the example of the unlocking script described above, unlocking script 518 may include verification key V K The unlocking script 518 may include an ordered or unordered sequence of elements 524, a digital signature 526 associated with the client, and branch information. In one embodiment, the digital signature 526 includes a hash type flag. In one embodiment, the hash flag is SIGHASH_NONE|SIGHASH_ANYONECANPAY. The unlocking script 518 may include execution control information that may be used in conjunction with the locking script to verify the transaction. For example, in the above example, "1" indicates that the script should enter the first branch of the control statement in the unlocking script (e.g., an OP_IF branch, not an OP_ELSE branch).

[0136] In one embodiment, worker 528 computes proof π 530 and appends the proof to unlocking script 518 along with a digital signature 532 associated with the worker, and broadcasts the transaction (e.g., to clients and / or one or more nodes of a blockchain network).

[0137] As an example, an unlocking script with proof and worker digital signature can be described as follows:

[0138]

[0139] Thus, in one embodiment, an unlocking script according to the above description is able to satisfy the conditions set on the output by the locking script and may allow the digital asset to be spent (e.g., as indicated by the output value).

[0140] There are a variety of techniques for providing the verification key V K , used to verify the proof π. Figure 6 is an illustrative diagram 600 in which a worker provides a verification key V K , used to verify proof π. Transaction output 602 may include output value 604, locking script 606 (optionally, in some systems), and locking script 608. In one embodiment, the transaction may be a pay to script hash (P2SH) transaction. In one embodiment, transaction output 612 includes a transaction ID, an output index 616, an unlocking script size 618, an unlocking script 618, and a sequence number 622, as described above in conjunction with Figure 5 It should be noted that although Figure 6 The structure of the transaction described in can be based on Figure 5 The structure described in Figure 6 It may specifically include a locking script 608 and an unlocking script 618 according to a P2SH transaction. The client 610 may generate a verification key V K and redemption script 628, and provides it to worker 624.

[0141] In one embodiment, the blockchain system supports various types of transactions. In one embodiment, the supported transactions (e.g., standard transactions) are script hash-based transactions, such as pay-to-script-hash (P2SH) transactions. In general, a script hash-based transaction refers to any transaction in which verifying the validity of an unlocking script includes providing a script that matches a specified hash value. For example, unlocking script 620 includes redemption script 628, and locking script 608 includes at least one condition that the hash of the redemption script provided by the unlocking script matches a specified value. For example, the locking script can be described based on the following:

[0142] OP_HASH160<20-byte hash of redeem script>OP_EQUAL

[0143] In some cases, the worker 624 provides the verification key V K626, for the verification phase. In one embodiment, the unlocking condition for the verification phase can be stored in a redemption script. In one embodiment, the locking script of a P2SH transaction includes a hash of the redemption script, and in some cases, the redemption script is kept secret (e.g., encrypted by a worker) and is only disclosed when an output value is transferred.

[0144] In one embodiment, client 610 creates a P2SH unspent transaction output by identifying a redemption script and applying a hash to it (e.g., HASH160). To transfer a UTXO, the client creates an input script (which references the UTXO) that includes and / or references the redemption script. It should be noted that, in one embodiment, although a blockchain-based system may have restrictions on the type or amount of data that may be included in a redemption script, the redemption script is suitable for storing arbitrary data. For example, there are restrictions on the size of data that can be posted to the stack (e.g., a PUSHDATA operation is limited to 520 bytes of data). In one embodiment, the redemption script includes compressed and uncompressed point P C and P U , such as combined Figure 4 Thus, in one embodiment, the maximum number of elliptic curve points that can be stored in a redemption script is 15 compressed points (e.g., 15 points * 34 bytes / point = 510 bytes) or 7 uncompressed points (e.g., 7 points * 66 bytes / point = 462 bytes). In one embodiment, unlocking script 618 includes proof 630, redemption script 628, and commands (e.g., opcodes) that can be used together to satisfy a set of conditions encoded in locking script 608.

[0145] Figure 7 is a schematic diagram of a process 700 for generating a redemption script according to an embodiment. In one embodiment, the process 700 is implemented using hardware, software, or a combination thereof. A suitable system for performing the process includes a worker who provides a Figure 6 Discussion related to P2SH unlocking script.

[0146] In one embodiment, the system determines the verification key V Khas sufficient cardinality. In one embodiment, the system determines the size of a redemption script (702), the redemption script including a script that verifies each element of the key and verifies a set of constraints, wherein the redemption script and proof π are sufficient to unlock the corresponding locking script. The system may determine whether the size of the redemption script exceeds a predetermined threshold (704), which may be based on a size limit imposed by the blockchain protocol, for example, the blockchain protocol may require that the size of the redemption script be less than or equal to 520 bytes. If the redemption script has sufficient size, the system generates a redemption script and an unlocking script (706), wherein the redemption script includes a script that verifies the key and verifies a set of constraints, and the unlocking script includes proof π, wherein the redemption script and the unlocking script together include a set of commands sufficient to verify the payment transaction.

[0147] For example, in the verification key V K When the cardinality is less than 16, it may be:

[0148]

[0149] Among them, the redeem script and the unlocking script are sufficient to unlock the locking script.

[0150] If the redemption script exceeds a predetermined threshold, the system generates an unlocking script that verifies the key V K One or more elements of V are stored in the portion of the unlocking script preceding the redemption script (708) so that the total size of the redemption script is within the threshold, and the redemption script is generated using the elements and constraints of the verification key described above (710). In one embodiment, the verification key V may be used elsewhere in the unlocking script. K For example, in V K When the cardinality is greater than 15, it may be:

[0151]

[0152] Among them, the redeem script and the unlocking script are sufficient to unlock the locking script.

[0153] Therefore, by encoding the required stages of the verification phase in the locking script, the verification of transactions should become an equivalent process with the verification phase of the zk protocol. In one embodiment, the OP_VERIFYPROOF opcode can be used as follows:

[0154]

[0155] The unlocking and locking scripts can be implemented in any suitable way. The unlocking script is implemented in any suitable way, where the unlocking script encodes <π1>..<π8> and the verification key V KSimilarly, the locking script may be implemented in any suitable manner, where π i and is extracted and the pairing call is executed. In one embodiment, OP_PAIRING as described above is an opcode that supports elliptic curves with efficient bilinear mappings, for example, the curve can be a curve represented by the equation y 2 =x 3 +3 defined bn128 curve.

[0156] Figure 8 800 is an illustrative simplified block diagram of a computing device 800 that can be used to practice at least one embodiment of the present application. In various embodiments, the computing device 800 can be used to implement any of the systems shown and described above. For example, the computing device 800 can be used as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. Figure 8 As shown, the computing device 800 may include one or more processors 802, which in some embodiments communicate and are operably coupled to a plurality of peripheral subsystems via a bus subsystem 804. In some embodiments, these peripheral subsystems include a storage subsystem 806, one or more user interface input devices 812, one or more user interface output devices 814, and a network interface subsystem 816, wherein the storage subsystem 806 includes a memory subsystem 808 and a file / disk storage subsystem 810. Such a storage subsystem 806 may be used for temporary or long-term storage of information.

[0157] In some embodiments, bus subsystem 804 provides a mechanism for enabling various components and subsystems of computing device 800 to communicate with each other as expected. Although bus subsystem 804 is schematically shown as a single bus, alternative embodiments of bus subsystem can utilize multiple buses. In some embodiments, network interface subsystem 816 provides an interface to other computing devices and networks. In some embodiments, network interface subsystem 816 is used as an interface for receiving data from other systems and sending data from computing device 800 to other systems. In some embodiments, bus subsystem 804 is used to transmit data such as details, search terms, etc.

[0158] In some embodiments, the user interface input device 812 includes one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touch panel, or graphics tablet; a scanner; a barcode scanner; a touch screen incorporated into a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to the computing device 800. In some embodiments, one or more user interface output devices 814 include a display subsystem, a printer, or a non-visual display, such as an audio output device, etc. In some embodiments, the display subsystem includes a cathode ray tube (CRT), a flat panel device (e.g., a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection display or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 800. One or more user interface output devices 814 can be used, for example, to present a user interface to facilitate user interaction with an application that executes the described processes and their variations when the interaction is appropriate.

[0159] In some embodiments, the storage subsystem 806 provides a computer-readable storage medium for storing basic programming and data structures that provide the functions of at least one embodiment of the present application. In some embodiments, when an application is executed by one or more processors, the application (program, code module, instruction) provides the functions of one or more embodiments of the present application, and in an embodiment, the application is stored in the storage subsystem 806. These application modules or instructions can be executed by one or more processors 802. In various embodiments, the storage subsystem 806 additionally provides a repository for storing data used according to the present application. In some embodiments, the storage subsystem 806 includes a memory subsystem 808 and a file / disk storage subsystem 810.

[0160] In some embodiments, the memory subsystem 808 includes a plurality of memories, such as a main random access memory (RAM) 818 for storing instructions and data during program execution and / or a read-only memory (ROM) 820 in which fixed instructions may be stored. In some embodiments, the file / disk storage subsystem 810 provides non-transitory persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive and associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0161] In some embodiments, the computing device 800 includes at least one local clock 824. In some embodiments, the local clock 824 is a counter that represents the number of ticks that have passed since a specific start date, and in some embodiments, the local clock 824 is entirely located within the computing device 800. In various embodiments, the local clock 824 is used to synchronize data transfers in processors of the computing device 800 and its included subsystems with specific clock pulses, and can be used to coordinate synchronization operations between the computing device 800 and other systems in the data center. In another embodiment, the local clock is a programmable interval timer.

[0162] The computing device 800 can be any of a variety of types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 800 can include another device, which in some embodiments can be connected to the computing device 800 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). In some embodiments, such a device includes a port that accepts a fiber optic connector. Thus, in some embodiments, the device converts optical signals into electrical signals and transmits these electrical signals through the port that connects the device to the computing device 800 for processing. Due to the ever-changing nature of computers and networks, Figure 8 The description of computing device 800 depicted in FIG. 8 is intended only as a specific example to illustrate a preferred embodiment of the device. Figure 8 Many other configurations of the systems depicted with more or fewer components are possible.

[0163] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention. In the claims, any reference numerals in brackets shall not be construed as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of other elements or steps than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consists of". The singular reference of an element does not exclude the plural reference of these elements, and vice versa. The present invention may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be implemented by the same hardware. The fact that certain measures are cited in mutually different dependent claims does not mean that a combination of these measures cannot be used advantageously.

[0164] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. A computer-implemented verification method comprising: generating a transaction output of the transaction, the transaction output comprising an indication of the digital asset and a locking script, the locking script encoding a set of conditions for transferring control of the digital asset, satisfaction of the set of conditions being determined based at least in part on the verification key and the attestation; Generate a transaction input for the transaction, the transaction input comprising: an unlocking script containing the proof; and verifying satisfaction of the set of conditions based at least in part on the locking script and the unlocking script; and In response to verifying satisfaction of the set of conditions, control of the digital asset is transferred.

2. The method according to claim 1, wherein: The transaction input also includes an identifier associated with the transaction output.

3. The computer-implemented method of claim 1 , wherein: The verification key comprises a first plurality of finite field elements and the proof comprises a second plurality of finite field elements.

4. The computer-implemented method of claim 3, wherein: The finite field elements are points on the elliptic curve.

5. A computer-implemented method according to any one of claims 2 to 4, wherein: The finite field elements are encoded in a compressed format.

6. A computer-implemented method according to any preceding claim, wherein: The client encodes the transaction input using the verification key and a first digital certificate associated with the client, and the worker encodes the transaction input using the certification and a second digital certificate associated with the worker.

7. A computer-implemented method according to any preceding claim, wherein: The locking script includes instructions for reclaiming the digital asset for the provider of the digital asset if the unlocking script does not satisfy the set of conditions.

8. A computer-implemented method according to any preceding claim, wherein: The unlocking script also includes a redemption script, wherein the verification key and the redemption script need to satisfy this set of conditions; and The locking script encodes one condition of the set of conditions, which is that the hash of the redemption script matches a predetermined value.

9. The computer-implemented method of claim 8, wherein: The size of the redemption script is less than or equal to 520 bytes.

10. The computer-implemented method according to any one of claims 8 to 9, wherein: The unlocking script includes one or more elements of the verification key.

11. The method according to claim 10, wherein: The redemption script includes at least some remaining elements of the verification key.

12. The method according to claim 11, wherein: The unlocking script and the redemption script together include the verification key.

13. A computer-implemented method according to any one of claims 7 to 12, wherein: The transaction is based on a P2SH transaction.

14. A computer-implemented method according to any preceding claim, wherein: The transaction is a standard transaction according to the blockchain-based protocol.

15. A computer-implemented method according to any preceding claim, wherein: The locking script and the unlocking script are encoded in a stack-based scripting language.

16. A computer-implemented method according to any preceding claim, wherein: This set of conditions includes bilinear constraints.

17. A system comprising: processor; as well as A memory comprising executable instructions, the executable instructions being executed by a processor so that the system performs a computer-implemented method according to any one of claims 1 to 16.

18. A non-transitory computer-readable storage medium having executable instructions stored thereon, wherein the executable instructions are executed by a processor of a computer system so that the computer system at least performs the computer-implemented method according to any one of claims 1 to 16.

Images