A system to protect verification keys from modification and to verify the validity of proof of legitimacy.

Abstract

This invention provides a computer implementation method system and storage medium for blockchain network nodes that conserve computing power. [Solution] A blockchain transaction includes a digital resource that is blocked by a locking script that encodes a set of conditions. The set of conditions must be met before ownership / control of the blocked resource is transferred, i.e., before the blocked resource is used. An operator performs one or more calculations to generate a proof, which is encoded as part of the unlocking script. A verification algorithm uses the proof, verification key, and additional data such as a digital signature associated with the operator to confirm that the digital assets of the transaction should be transferred. As a result of transaction validation, any third party can check that the contract has been executed rather than having to re-execute the contract.

Description

[Technical Field]

[0001] This invention generally relates to blockchain technology, and more specifically to enabling the execution of zero-knowledge protocols on a blockchain by using locking scripts to protect verification keys from modification and to verify the validity of proof of correctness. The invention further employs cryptographic and mathematical techniques to implement security for electronic transfers performed on a blockchain network. While particularly suited to, and not limited to, use in the creation and execution of smart contracts, the invention is not limited to these applications. [Background technology]

[0002] In this specification, 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. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, Bitcoin may be referred to as a useful application of the technology described herein, but Bitcoin is only one of many applications to which the technology described herein may be applied. However, it should be noted that the present invention is not limited to use in the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system composed of blocks, which can consist of transactions and other information. In some examples, a “blockchain transaction” refers to an input message that encodes a structured collection of field values ​​containing a set of data and conditions, in which case satisfying the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. In Bitcoin, for example, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and contains at least one input and at least one output. In some embodiments, a “digital asset” refers to binary data associated with a right of use. Examples of digital assets include Bitcoin, Ethereum, and Litecoin. In some implementations, the transfer of control of a digital asset can be accomplished by reassociating at least a portion of the digital asset from a first entity to a second entity. Each block in the blockchain may contain a hash of the previous block so that the blocks, when chained together, create a persistent and immutable record of all transactions written to the blockchain from the beginning.

[0004] In some examples, “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 may utilize a stack. On a stack, values ​​can be pushed to the top of the stack or popped from the top of the stack. Various operations performed on a stack may 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 top two items from the stack, compares them, and pushes the result (e.g., 1 if equal, 0 otherwise) to the top of the stack. Other operations performed on a stack, such as OP_PICK, may allow selecting an item from a position other than the top of the stack. In some scripting languages ​​used in some embodiments, there may be at least two stacks, namely a main stack and an alternate stack. Some operations in a scripting language can move an item 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 stack-based scripting languages ​​are not necessarily limited to strict last-in, first-out (LIFO) operations. 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 in Bitcoin, respectively). Scripts written in a stack-based scripting language can be pushed onto a logical stack, which can be implemented using any suitable data structure such as vectors, lists, or stacks.

[0005] For a transaction to be written to the blockchain, it must be "validated". Network nodes (mining nodes) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. Nodes may have different validity standards than other nodes. Since blockchain validity is consensus-based, a transaction is considered valid if the majority of nodes agree that it is valid. Software clients installed on the nodes perform this validation work for transactions that partially reference UTXOs by executing UTXO locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions are met where applicable, the transaction is validated by the node. Validated transactions are propagated to other network nodes, where mining nodes can choose to include the transaction in the blockchain. Therefore, for a transaction to be written to the blockchain, i) the transaction must be verified by the first node that receives it, and if the transaction is verified, the node relays the transaction to other nodes in the network; ii) the transaction must be added to a new block built by a mining node; and iii) it must be mined, i.e., added to the public ledger of past transactions. To make the transaction effectively irreversible, a transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain.

[0006] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the realm of cryptocurrency. Such solutions, while having a wider range of applications, would be able to leverage the advantages of blockchain (e.g., persistence, tamper-proof event records, distributed processing, etc.).

[0007] This disclosure describes the technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable and executable program recorded within a blockchain transaction. A blockchain-based computer program may include rules that can process inputs to produce results, and then perform actions depending on those results. One area of ​​current research is the use of blockchain-based computer programs for the implementation of “smart contracts.” Unlike traditional contracts written in natural language, a smart contract may be a computer program designed to automate the execution of machine-readable contract or agreement terms.

[0008] Another area of ​​interest related to blockchain is the use of “tokens” (or “colored coins”) to represent and transfer real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that do not have an identifiable meaning or value. Thus, tokens act as identifiers that enable real-world items to be referenced from the blockchain.

[0009] In some embodiments, interaction with a specific entity can be encoded in a specific step of a smart contract, which can otherwise be automatically executed and self-enforced. It is machine-readable and executable. In some examples, automatic execution refers to the execution of a smart contract that is successfully executed to enable the transfer of a UTXO. Note that in such examples, the “entity” that enables the transfer of the UTXO refers to an entity that can create an unlocking script without being required to prove any secret knowledge. In other words, an unlocking transaction can be validated without verifying that the data source (e.g., the entity that created the unlocking transaction) has access to cryptographic secrets (e.g., secret asymmetric keys, symmetric keys, etc.). Also in such examples, self-enforcement refers to a validation node on the blockchain network that is enforcing the unlocking transaction according to the constraints. In some examples, “unlocking” a UTXO (also known as “spending” a UTXO) is used in a technical sense and refers to creating an unlocking transaction that references a UTXO and executes it as valid.

[0010] The output of a blockchain transaction includes a locking script and information about the ownership of digital assets such as Bitcoin. A locking script, sometimes called an encumbrance, "locks" a digital asset by specifying conditions that must be satisfied in order to transfer a UTXO. For example, a locking script may require certain data to be provided in an unlocking script in order to unlock the associated digital asset. In Bitcoin, a locking script is also known as a "scriptPubKey". The technique of requiring parties to provide data in order to unlock a digital asset involves embedding a hash of the data within the locking script. [Overview of the Initiative] [Problems that the invention aims to solve]

[0011] Therefore, it is desirable to provide methods and systems for improving blockchain technology in one or more of these embodiments. Such improved solutions have now been devised. Accordingly, the present invention provides methods as defined in the appended claims.

[0012] Such improved solutions have now been devised. [Means for solving the problem]

[0013] Accordingly, the present invention provides systems and methods as defined in the appended claims.

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

[0015] The verification key may contain multiple first elements of a finite field, and the proof may contain multiple second elements of a finite field.

[0016] The elements of the field may be points on an elliptic curve.

[0017] Elements of a finite field may be encoded in a compressed format.

[0018] 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 a proof and a second digital certificate associated with the worker.

[0019] A locking script may include instructions to reclaim the digital asset for the provider of the digital asset, provided that a set of conditions has not been met by the unlocking script.

[0020] The locking script may further include a redeem script, the verification key and the redeem script encoding enough information to determine the satisfaction of at least a subset of the set of conditions; the locking script encoding that the hash of the redeem script matches a given value, as one of the set of conditions.

[0021] The redeem script may be less than or equal to a specified maximum size, for example, 520 bytes or less.

[0022] The unlocking script may contain one or more elements of the verification key, and the redeem script may contain at least some of the remaining elements of the verification key. The unlocking script and the redeem script may collectively contain the verification key.

[0023] The transaction locking script, unlocking script, and redeem script may follow the Pay-to-Script-Hash transaction of the Bitcoin-based protocol or a variation thereof.

[0024] Transactions may follow the standard transaction format of blockchain-based protocols such as the Bitcoin protocol.

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

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

[0027] Furthermore, it is desirable to provide a system comprising a processor and memory containing executable instructions that, as a result of execution by the processor, cause the system to execute any of the methods claimed in the patent.

[0028] Furthermore, it is desirable to provide a non-temporary computer-readable storage medium that stores executable instructions causing a computer system to execute at least one of the methods claimed in the patent as a result of execution by one or more processors of the computer system.

[0029] The present invention can 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 or portion of a cryptocurrency. As described below, the present invention can also be described as a secure method / system for a novel, improved, and advantageous way of performing operations via a blockchain network or platform. [Brief explanation of the drawing]

[0030] These and other aspects of the present invention will become apparent from the embodiments described herein and will be elucidated in connection with those embodiments. Embodiments of the present invention will now be described, merely illustrative, in connection with the accompanying drawings:

[0031] [Figure 1] This diagram shows a blockchain environment that can implement various embodiments. [Figure 2] This figure shows a computing environment that can be used to implement the protocol according to various embodiments. [Figure 3] This is a diagram of an environment suitable for performing verifiable calculations. [Figure 4] This figure illustrates an illustrative diagram 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 one embodiment. [Figure 5] This diagram shows the client supplying the verification key used to validate the proof. [Figure 6] This diagram shows a worker supplying a verification key used to validate the proof. [Figure 7] This is a diagram of process 700 for generating a redeem script according to one embodiment. [Figure 8] This figure shows a computing device that may be used to carry out at least one embodiment of the present disclosure. [Modes for carrying out the invention]

[0032] First, refer to Figure 1, which shows an exemplary blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure. In this embodiment, the exemplary blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each running an instance of software and / or hardware that performs operations in accordance with a blockchain protocol agreed upon at least partially among the operators of the nodes 102. In some examples, “node” refers to a peer-to-peer electronic device distributed across the blockchain network. An example of a blockchain protocol is the Bitcoin protocol.

[0033] In some embodiments, node 102 may consist of any suitable computing device (e.g., by a server in a data center, by a client computing device (e.g., a desktop computer, laptop computer, tablet computer, smartphone, etc.), by multiple computing devices in a distributed system of a computing resource service provider, or by any suitable electronic client device such as computing device 800 in Figure 8). In some embodiments, node 102 has an input for receiving data messages or objects representing proposed transactions, such as transaction 104. In some embodiments, the node is queryable for information maintained by the node, for example, for information about the state of transaction 104.

[0034] As shown in Figure 1, some of the nodes 102 are communicatively connected to one or more other nodes 102. Such communication connections may include one or more wired or wireless connections. In an embodiment, each node 102 maintains at least a portion of the “ledger” of all transactions in the blockchain. In this way, the ledger becomes a distributed ledger. Transactions processed by nodes that affect the ledger are verifiable by one or more of the other nodes so as to maintain the integrity of the ledger.

[0035] Regarding which node 102 can communicate with which other nodes, it is sufficient that each node in the exemplary blockchain network 100 can communicate with one or more other nodes among the nodes 102, so that messages passed between nodes can propagate throughout the exemplary blockchain network 100 (or any significant part thereof), assuming that the message is a message indicating that the blockchain protocol should forward. One such message may be the publication of a proposed transaction by one of the nodes 102, for example node 102A, which would then propagate along a path such as path 106. Another such message may be the publication of a new block proposed for inclusion in the blockchain.

[0036] In one embodiment, at least some of the nodes 102 are mining nodes that perform complex computations, such as solving a cryptographic problem. The mining nodes that solve the cryptographic problem create a new block for the blockchain and broadcast the new block to the other nodes of Node 102. The other nodes of Node 102 acknowledge the work of the mining nodes and, upon acknowledgment, accept the block into the blockchain (for example, by adding the block to the blockchain's distributed ledger). In some examples, a block is a group of transactions, often marked with a timestamp and a "fingerprint" (e.g., hash) of the previous block. In this way, each block may be linked to the previous block, thereby creating a "chain" that links the blocks in the blockchain. In some embodiments, valid blocks are added to the blockchain by consensus of the nodes 102. Also in some examples, the blockchain contains a list of verified blocks.

[0037] In one embodiment, at least some of the nodes 102 operate as verification nodes that verify transactions, as described in this disclosure. In some examples, a transaction includes a proof of ownership of a digital asset (e.g., multiple Bitcoins) and data that provides conditions for accepting or transferring ownership / control of the digital asset. In some examples, “unlocking transaction” refers to a blockchain transaction that reassociates at least some of the digital assets indicated by the UTXO of the previous transaction with an entity associated with a blockchain address (e.g., transferring ownership or control). In some examples, “previous transaction” refers to a blockchain transaction that includes the UTXO referenced by the unlocking transaction. In some embodiments, a transaction includes a “locking script” that prevents the transaction by conditions that must be met before ownership or control can be transferred (“unlocked”).

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

[0039] The systems and methods described herein involve a locking script that uses verification key V K This relates to enabling protection from modification, verifying the validity of proof π, and thereby allowing the execution of zero-knowledge protocols on the blockchain during transaction verification.

[0040] Verifiable computation is a technique that enables the generation of proofs of computations. In embodiments, such a technique is used by a client to outsource the evaluation of a function f for an input x to another computing entity, referred to herein as a worker. In some cases, the client may be computationally constrained and unable to perform the evaluation of the function (e.g., the expected runtime of the computation using the computing resources available to the client exceeds a maximum allowable threshold), but this is not required, and the client may delegate the evaluation of the function f for an input x based on any appropriate criteria, such as computational runtime or computational cost (e.g., the economic cost of allocating computing resources to perform the evaluation of the function).

[0041] In one embodiment, the worker is any suitable computing entity, such as a blockchain node, which is described in more detail elsewhere in this disclosure. In one embodiment, the worker (e.g., a blockchain node) evaluates a function f for an input x and generates an output y and a proof π of the correctness of the output y, which can be verified by the aforementioned client and / or other computing entities, such as other nodes in the blockchain network. The proof, sometimes also called an argument, can be verified faster than the actual computation and thus computational overhead can be reduced by verifying the correctness of the proof instead of recalculating the function f for the input x to determine the correctness of the output generated by the aforementioned worker (e.g., reducing power overhead and the costs associated with powering up and performing the computational resources). In zero-knowledge verifiable computation, the worker provides the client with a certificate that the worker knows an input having certain characteristics.

[0042] A valid variation of the zero-knowledge proof of knowledge is the zk-SNARK (Succcinct Non-interactive ARgument of Knowledge). In one embodiment, all pairing-based zk-SNARKs involve a process in which an operator computes multiple group elements using a common group operation, and a verifier checks the proof using multiple pairing product equations. In one embodiment, the linear interactive proof operates over a finite field, and operator and verifier messages contain, encode, or otherwise contain information that can be used to determine the vector of field elements.

[0043] In one embodiment, the systems and methods described herein enable a blockchain mining node to perform a computation (e.g., evaluating a function f for an input x) once and generate a proof that can be used to verify the validity of an output, where evaluating the validity of a proof is less computationally expensive than evaluating the function. In this context, the cost of an operation and task (i.e., how expensive) may refer to the computational complexity of performing the operation or task. In one embodiment, computational complexity refers to the average or worst-case computational cost of performing a sorting algorithm—for example, both the heapsort and quicksort algorithms have an average computational cost of o(n log n), while quicksort has an average computational cost of o(n log n). 2The worst-case computational cost of o(n logn) is o(n logn), while heapsort has a worst-case computational cost of o(n logn). In one embodiment, the average computational cost and / or worst-case computational cost of evaluating a function f on input x is worse than the cost of evaluating the validity of a proof. Therefore, the use of the systems and methods described herein is very advantageous and can, for example, enable the execution of more computationally expensive contracts, because such contracts do not increase the time required for such contacts to proportionally verify the blockchain. Further advantages may include a reduction in the power consumption of the verifier system, thereby improving the efficiency of the verifier computer system and reducing the energy cost associated with running such a verifier computer system when evaluating the validity of a proof. Currently, smart contracts must be executed and verified on all nodes—this constraint limits the complexity of smart contracts. Using the methods and systems described herein, the efficiency of the blockchain can be improved by executing a contract once to generate a proof of legitimacy, and a system can be implemented in which all nodes of the blockchain can verify the validity of a contract based on the proof of legitimacy provided by the worker and the verification key provided by the client. In this way, the efficiency of the blockchain is improved by increasing the throughput of smart contracts, which can be executed collectively by the nodes of the blockchain and / or enable the computation of smart contracts with higher computational costs.

[0044] In one embodiment, verification key V k Alternatively, parts of it can be extracted from public parameters and input / output data generated during the setup phase of the zero-knowledge protocol and used with proof π, to verify the alleged proof of the validity calculation provided by the operator. For example, as described in more detail above and below, systems and methods that allow locking scripts use verification key V kThis protects against modification, checks the validity of proof pi, and enables the execution of zero-knowledge protocols on the blockchain during transaction verification. Accordingly, this disclosure discloses a system and method for performing the verification stage using blockchain scripts (e.g., in a Bitcoin-based network) to store the elements used in verifying the computation.

[0045] Figure 2 shows a computing environment 200 that may be used to implement the protocol according to various embodiments. The protocol may be implemented using blockchain technology to store proof of legitimacy and combine "correct-by-construction" cryptographic methods with smart contracts. In one embodiment, the publicly verifiable computing scheme includes three stages: a setup stage, a computing stage, and a verification stage.

[0046] The setup phase may be performed as part of the process to outsource the execution of computational tasks. The term "client" may refer to an entity such as a customer or client computer system that delegates the execution of computational tasks to a worker, as mentioned below; this may be a different computer system. Generally speaking, but not limited to, clients may delegate the execution of computational tasks for a variety of reasons, including but not limited to computational resources, lack of computational resources, the economic costs associated with using the client computer system to perform tasks, and the energy costs associated with using the client computer system to perform tasks (for example, a mobile device or laptop that relies on batteries for power may utilize a worker to perform computationally intensive tasks, thereby saving power and extending the use of the battery-powered device).

[0047] In one embodiment, the setup phase includes a client, customer, employee of the organization, or any other appropriate entity writing the contract in a formal language with precise meaning. The contract may be written in a high-level programming language such as C or Java®. Generally speaking, the contract may be expressed in any language or syntax that can be converted or translated into a format that can be manipulated by a computer system. In one embodiment, for limited purposes, a domain-specific language may provide type safety and a limited degree of expression may be utilized. The generated source code may be an exact description of the contract.

[0048] The compiler 202 may be any hardware, software, or any combination thereof that, when executed by one or more processors of a computer system, contains executable code that causes the system to take source code 206 as input and generate a circuit. The compiler 202 may refer to a computer program that executes or enforces instructions based on instructions compiled into a machine-readable format such as binary code. Although the compiler 202 is illustrated, it should be noted that an interpreter, assembler, and other appropriate software and / or hardware components may be used to translate the source code into a circuit. In one embodiment, the circuit is an arithmetic circuit comprising wires that carry values ​​from field F and connect to logic and / or arithmetic gates. In one embodiment, the circuit C is used by the system to generate a secondary program Q 208 containing a set of polynomials that provide a complete description of the original circuit C.

[0049] In one embodiment, the compiler 202 may recognize a substantial subset of programming languages ​​such as C or Java®, including, but not limited to, preprocessor instructions, static initializers, global and local functions, block-scope variables, arrays, data structures, pointers, function calls, function operators (e.g., functors), conditions and loops, and arithmetic and bitwise Boolean operators. However, in one embodiment, the compiler 202 may not support the entire set of commands specified by the programming language standard (this may be intended to prevent certain types of algorithms from being executed in smart contracts, such as prohibiting recursive algorithms). In one embodiment, the compiler extends the source code representation into an arithmetic gate language and generates arithmetic circuits. Implementations of circuits have been considered in the past 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 arithmetic circuit may be used by the compiler 202 or any other suitable hardware, software, or combination thereof (e.g., software modules not shown in Figure 2) to construct a quadratic arithmetic problem (QAP). The quadratic program is compiled, according to one embodiment, into a set of cryptographic routines for the client (e.g., key generation and verification) and the worker (e.g., calculation and proof generation). In some embodiments, arithmetic circuit optimization techniques, such as those described in UK Patent Application No. 1718505.9, may be used to reduce the resources required for the worker to determine the outcome of the smart contract.

[0050] In one embodiment, when the key generator 204 is executed by one or more processors of a computer system, it includes hardware, software, or a combination thereof that contains executable code for causing the system to generate an evaluation key and a verification key that form a quadratic program. Techniques for encoding computations as quadratic programs are considered in "Quadratic Span Programs and Succinct NIZKs without PCPs" by Gennaro, R., et al. (2013). In one embodiment, the quadratic arithmetic problem (QAP) Q encodes a circuit C over a field F and includes a set of m + 1 polynomials: V = {vk(x)}, W = {wk(x)}, Y = {yk(x)} where 0 ≤ k ≤ m. A target polynomial t(x) is also defined. Given a function f that takes n elements of F as input and outputs n' elements, and given N = n + n', Q is such that {c1,..., c N} ∈ F N is a valid assignment for the input and output groups of f, and there exists a list of coefficients {c N+1 ,..., c m} such that f is computed so that t(x) divides p(x):

Number

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

[0052] In one embodiment, constructing the QAP of an arithmetic circuit involves, for each multiplication gate g in the circuit, picking an arbitrary root r g ∈ F, and

Number

number

[0053] In one embodiment, QAP is in field F p Defined above, where p is a large prime. In one embodiment, F p It is desirable that the above QAP efficiently computes any function that can be expressed with respect to addition and multiplication modulo p. The arithmetic partition gate is [0,2 k-1 An arithmetic wire a ∈ Fp known to be within [0,2] may be designed to be converted into k binary output wires. Thus, Boolean functions can be represented using arithmetic gates. For example, NAND(a,b) = 1 - ab. Each embedded Boolean gate is subjected to only one multiplication. Furthermore, new gates such as split can be defined as standalone and can be constructed with other gates. k-1 An input a∈F is known to be located within []. pGiven, the partition gate is Σ k Σ 2i-1 a i It outputs k wires that hold the binary numbers a1, ..., ak of a, such as =a, and each a i It is either 0 or 1.

[0054] Ultimately, the public parameters used by all provers and verifiers are generated by the system as part of the setup phase. Evaluation key E K and verification key V K It should be noted that this is derived using a secret value selected by the client. The key generator 204 utilizes a quadratic arithmetic program (QAP) in relation to the key generation algorithm to generate the evaluation key E K 210 and verification key V K It is possible to generate 212.

[0055] In one embodiment, performing a computation task involves the worker computing a function on input 216 (i.e., the process of evaluating f(x)). In this embodiment, the worker is any suitable computer system to which a client can delegate the computation task. Input 216 includes, in one embodiment, information that verifies the worker's identity, such as a digital signature generated using a private key associated with the worker. In this embodiment, the worker is a computer system to which the client pays a reward for a successful computation (e.g., by the transfer of digital assets). In one embodiment, the client is input x and evaluation key E K The operator is provided with the evaluation module 214 to calculate the output y (i.e., y = f(x), where the input is x and the function is f), and the evaluation key E K Using 210, a proof of validity 218 is generated. In one embodiment, the evaluation module is hardware and / or software that, when executed by one or more processors of a computer system, includes instructions that cause the computer system to evaluate the values ​​of the internal circuit wires of QAP208 and generate the output y of QAP.

[0056] In one embodiment, each polynomial v of the quadratic program k (x)∈F is an element g within a bilinear group vk(s) This is mapped to a formula where s is a secret value selected by the client, g is the group generator, and F is the discrete logarithmic field of g. In one embodiment, for a given input, the operator evaluates the circuit to obtain the coefficients c of a quadratic program. i The output and value of the corresponding internal circuit wire are obtained. Therefore, the operator obtains v(s) = Σ k∈{m} Evaluate ck·vk(s) and g v(s) Obtain the values; calculate w(s) and y(s); h(x) = p(x) / t(x) = Σ d h i ·x i Calculate; h in the evaluation key i and g s(i) Use the term g h(s) The following is calculated. In one embodiment, the proof of legitimacy 218 is (g v(s) , g w(s) , g y(s) , g h(s) The verifier uses a bilinear map to check p(s) = h(s)·t(s). In one embodiment, proof π may be stored on blockchain 222 for later use or may be verified by multiple parties without requiring the prover to interact with each of them separately. In one embodiment, the evaluation of the circuit storage of proof of legitimacy may be performed to unlock digital assets that are being prevented by the transaction locking script.

[0057] In one embodiment, 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 computational entity, such as a node on the blockchain. Optionally, evaluation key E K and verification key V KIt should be further noted that the same computing entity that generates the proof also verifies the proof. In one embodiment, a node in the blockchain uses verification key V. K Payment transactions can be verified using proof π, and the contract can be verified if the verification is successful. One requirement of the protocol is the verification key V K Even if they know this, the worker cannot provide an inaccurate proof. Therefore, in this protocol, the common reference string (CRS) is at least the evaluation key E K and verification key V K It is generated by the client or trusted third party who publishes it. In one embodiment, the published verification key V K This can be used to verify a calculation by any computation entity.

[0058] Using the techniques described herein, a client can partially obfuscate transaction data, such as the identity of the recipient of a blockchain transaction. In one embodiment, the unlocking script does not expose the recipient's address and public key. However, in some cases, the value of the transaction (e.g., the amount of digital assets being transferred) may be visible to nodes on the blockchain network. In one embodiment, the cryptographic techniques described above and below are used by the client to convert the locking script into a quadratic arithmetic program, which an operator then solves to generate a proof.

[0059] Generally speaking, a client can use standard transactions such as P2PK and P2PKH (standard transactions as defined on, for example, Bitcoin-based blockchain networks) to pay a counterparty or worker. For example, in one embodiment, the client converts a P2PK locking script into an arithmetic circuit and broadcasts a payment transaction containing a puzzle derived from the circuit. The counterparty or worker receives the circuit, provides appropriate inputs (information proving the worker's identity, such as a shared secret between the client and the worker or a digital signature generated using the worker's private key), and runs the circuit to generate proof π of legitimacy. In one embodiment, the proof is used to unlock a digital asset, and furthermore, information identifying the counterparty or worker (e.g., a public key and / or digital signature associated with the counterparty or worker) may not be recorded on the blockchain in an obfuscated format.

[0060] In embodiments, the verification key and the corresponding proof are generated according to the techniques described above and / or below. Thus, the verifier computes multiple elliptic curve multiplications (e.g., one for each public input variable) and five pair checks, one of which includes an additional pairing multiplication, so that the verification key V K And given proof π:

number

[0061] Verification Key V K , proof π and (a1, a2, ..., a N Given ), t(x) partitions p(x), therefore, (x N+1 ,...,x m )=f(x0,...,x N To verify this, the verifier proceeds as follows: First, the three alpha terms:

number

number

number

number

number

number

number

number

number

number

number

[0062] Therefore, considering the notation from the above sections and the examples described herein, verification, according to one embodiment, includes a set of pair checks of the following elements:

number

[0063] Figure 3 shows Figure 300 for tuning the performance of verifiable calculations. Client 302, worker 304, and verifier 306 may be nodes of the blockchain network. Client 302 may be any suitable computer system and may include executable code that, when executed by one or more processors of the computer system, causes the computer system to receive the smart contract 308. In one embodiment, the smart contract 308 is encoded in a high-level programming language such as source code, such as C, C++, or Java®. In one embodiment, software such as a compiler, interpreter, and / or assembler is used to process the smart contract 308 into fields.

number

[0064] In one embodiment, client 302 provides worker 304 with an arithmetic circuit 310 and an input 312 to the circuit. The circuit 310 may be used to generate a quadratic program Q containing a set of polynomials that provide a complete description of the original circuit. In either case, worker 304 may run the circuit C or the quadratic program Q on input 312 to produce one or more outputs 314. In some embodiments, worker (i.e., prover) is expected to obtain as an output a valid transcript of {C,x,y} which is an assignment of values ​​to circuit wires, such that the values ​​assigned to the input wires are those of x, the intermediate values ​​correspond to the correct operation of each gate in C, and the value assigned to the output wire is y; if the requested output is incorrect (i.e., y≠P(x)), then no valid transcript of {C,x,y} exists. In embodiments, worker is expected to provide a subset of values ​​for the circuit wires, the selected subset of values ​​for the circuit wires is not known to the worker in advance.

[0065] In this embodiment, the output y, the value of the internal circuit wire (or a subset thereof), and the evaluation key E are used. K This is used to generate proof 316 of legitimacy. Proof π can be stored on the blockchain and can be verified by multiple parties without requiring worker 304 to interact with each party separately. In this way, verifier 306 uses the public verification key V K The payment transaction can be verified using Proof π, thereby verifying the contract. In some cases, if verification fails, client 302 may reclaim the digital assets that were blocked by the payment transaction. In some cases, the verifier 306 and client 302 are the same computer system.

[0066] Figure 4 shows Figure 400 of an embodiment of the present disclosure. Specifically, Figure 4 shows points on an elliptic curve 402 encoded in various formats suitable for use in blockchain-based scripts such as Bitcoin-based locking and unlocking scripts.

[0067] In various embodiments, elliptic curve points can be encoded in locking and unlocking scripts executed in connection with a transaction. In Bitcoin-based systems, these scripts may be written in a stack-based scripting language. For example, verification key V K teeth,

number

number

number

[0068] Figure 4 shows that points on the elliptic curve 402 are suitable for use in blockchain scripts such as locking scripts or unlocking scripts, and are compressed (P C ) or uncompressed (P U Figure 400 shows an example represented using one of the encodings.

[0069] In one embodiment,

number

number

[0070] In one embodiment, the uncompressed encoding 404 encodes a point P in a finite field such as the x-coordinate 408 and y-coordinate 410 of a point on an elliptic curve (i.e.,

number

[0071] Generally speaking, the incompressible point P U P U Note that the points are uncompressible elliptic curve points and may be represented in any suitable format that encodes the information available to determine the x and y coordinates of the points. Similarly, compressed points P C P C The information used to determine that a point is a compressed elliptic curve point, and the compressed information used to determine the x and y coordinates of the point, may be represented in any suitable format.

[0072] As an example, consider the representation of a point on a secp256k1 elliptic curve in a Bitcoin-based system. In embodiments where an uncompressed point is represented, the first octet in the encoded bit sequence of the uncompressed elliptic curve P is 0x04, followed by two 256-bit digits corresponding to the X and Y coordinates of the point (i.e., P = C||X||Y). As an example, the DER (Distinguished Encoding Rules) encoding format is used, but other suitable encoding formats, such as Basic Encoding Rules (BER) and Canonical Encoding Rules (CER), are also possible within the scope of this disclosure.

[0073] In one embodiment, a one-byte script opcode containing the length of an elliptic curve point is concatenated to the actual point (for example, the length is concatenated to the beginning of the actual point). x=0xe3b01684a8a8b66f8e44203db5869b4dcb74a0afc905ae9197ed74a8d6cecdcc y=0x6424d186a23687532c8b20911defc2f42c93749b3736857912c6abe2dc3f01d1 In this case, the compressed script P C and uncompressed ScriptP U In one embodiment, these are as follows: Script P C :0x21||0x03e3b01684a8a8b66f8e44203db5869b4dcb74a0afc905ae9197ed74a8d6cecdcc Script P U :0x41||0x04e3b01684a8a8b66f8e44203db5869b4dcb74a0afc905ae9197ed74a8d6cecdcc6424d1 86a23687532c8b20911defc2f42c93749b3736857912c6abe2dc3f01d1

[0074] In one embodiment, a client is a party to a smart contract and decides to use a blockchain to execute the contract. As part of this decision, the client posts a payment transfer to the blockchain to transfer digital assets managed by the client to a party publishing proof pi (e.g., a worker). A verifier computer system, such as the one described above, can perform a verification routine to determine that proof pi is correct.

[0075] According to the protocol, the client may generate a common reference string for proofing and generating. In some embodiments, the common reference string is generated by a trusted party (e.g., a third party). While a trusted third party may generate the common reference string, it should be noted that the introduction of a trusted third party into the protocol is optional, and the protocol requires a client and a worker and may be executed without any additional third parties.

[0076] Continuing with the protocol, the verification of the calculation is performed as part of the transaction verification phase. In one embodiment, such as a Bitcoin-based network, the client or worker performs the verification as part of the locking script and / or unlocking script.

number

number

number

number

[0077] Blockchain-based systems, such as Bitcoin-based systems, in one embodiment support the execution of operations (also called opcodes and commands) according to a scripting language such as scripts (for example, Bitcoin-based systems support scripts). In one embodiment, a transaction includes a locking (output) script and an unlocking (input) script, which can be identified as one of a list of standard types. For example, in Bitcoin-based systems, there are five standard types: namely, Pay-to-Public-Key (P2PK), Pay-to-Public-Key-Hash (P2PKH), Multi-Signature, Pay-to-Script-Hash (P2SH), and OP_RETURN.

[0078] As described herein, when implementing the proposed zk protocol, information such as common reference strings, proof π, and / or parts thereof is stored on the blockchain. Furthermore, as part of the verification process, the system may extract specific elements pushed onto the stack during the transaction verification process and check the pairing from the verification stage as described above.

[0079] Transactions may include small programs known as scripts embedded in their inputs and outputs, such scripts specifying how and by whom the transaction's output can be accessed. On the Bitcoin platform, 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 or non-standard transaction. In one embodiment, there are restrictions on the size of elements pushed onto the execution stack and the total size of input scripts. For example, in a Bitcoin-based system, all elements pushed onto the execution stack are limited to 520 bytes, and each input script is limited to 1650 bytes. In one embodiment, after script execution, the stack contains exactly one non-false element. Input scripts cannot contain any OP code other than OP_PUSHDATA (except for the redeem script portion). In one embodiment, a Bitcoin-based system requires a minimum output value of 546 satoshis, but it should be noted that different blockchain systems may define different amounts and / or units of digital assets to be included as output values ​​(e.g., the minimum payment to a mining node for a transaction). In one embodiment, the minimum output value is zero (i.e., no transfer of digital assets is required). Transactions that deviate from these rules are considered non-standard.

[0080] As part of the verification process, the verifier (e.g., the client) will use the verification key V K The elements of the proof are extracted and used for pairing checks. In one embodiment, the verification check includes a bilinear mapping that satisfies a set of constraints. For example, as follows: e(3,4+5)=2 3*9 =2 27 e(3,4)*e(3,5)=2 3*4 2 3*5 =212 2 15 = 2 27 such as the formal constraints:

Number

[0081] Note that the above pairing is for illustrative purposes - such mappings may not be useful verbatim for applications in cryptographic systems, but note that the process of verifying the bilinear constraints remains the same as when the bilinear map is extended onto an elliptic curve. Again, for illustration purposes, an example of how to extract and use information from the Bitcoin script at the verification stage from a common reference string (e.g., verification key V K ) and proof π is shown below:

Table 1

[0082] Note that the examples provided above are only used to illustrate examples of pair checks and may include additional constraints such as those described above in relation to Figure 2.

[0083] Verification key V for use in relation to verifying proof π K There are various techniques for providing this. Figure 5 is an exemplary diagram 500 in which client 510 supplies the verification key V K used for validating proof π. In one embodiment, the client generates a transaction output 502, and this transaction includes an output value 504 (e.g., payment of digital assets to a worker for contract execution) and a locking script 508 that performs a verification check including a bilinear mapping that satisfies a set of constraints, or is otherwise associated. In one embodiment, the locking script is based at least in part on the client's digital signature for the verification key VK The integrity of the locking script is verified. In some cases, the locking script may specify that if validation fails, the client can reclaim the digital assets in relation to the transaction, as described above. Such a transaction may be sent to the blockchain network, which is mined by nodes (e.g., workers) on the blockchain network. In some blockchain systems, the transaction encodes a parameter in relation to the locking script that indicates the size of the locking script (e.g., in bytes). The size of the locking script is sometimes referred to as the locking script size 506, as shown in relation to Figure 5.

[0084] For example, a locking script may be written based on the following: [Table 2]

[0085] Please note that the examples provided above illustrate the locking script, and do not necessarily describe locking script 508 itself verbatim. For example, some fields written in square brackets—for example, the client's public key—may refer to the following:<PubKey Client> The '-' is not included in locking script 508 verbatim. Similarly, some fields in parentheses may be based on mathematical calculations—for example, the 'OP_(i+1)' above does not have to be included in locking script verbatim, but rather refers to an opcode or command determined at least partially on mathematical calculations—in this case, 'i' refers to the number of elements in proof π, and therefore, in the example of proof π = {π1,...,π8}, 'OP_(i+1)' may be expressed in locking script as 'OP_7' in a stack-based scripting language. It should be further noted that the text after the double slash ' / / ' above refers to a comment and does not correspond to executable code. For example, ' / / Check pairing' is not mapped to executable code and merely indicates to the human that the text following the comment is used to verify the pairing.

[0086] Again, it should be noted that the transaction output 502 described above is merely an example, and such variations may exist—the transaction may include any appropriate payment amount in any appropriate unit of measurement, and various locking scripts may exist, for example, utilizing some or all of the functionality of the locking script described above. Generally speaking, the locking script 508 may be any appropriate set of commands that perform a set of pairing checks. In one embodiment, the locking script 508 uses at least an asymmetric public key associated with the client, and a verification key V KThis includes an integrity check. In one embodiment, the locking script allows the client to reclaim the digital assets if validation fails. In one embodiment, the locking script 508 has a threshold period (e.g., as described above)<n days> Includes an instruction to mark the transaction as invalid (followed by the value corresponding to ").

[0087] Client 510 may be a client as described elsewhere in this disclosure, but may generate a transaction input 512 that references the transaction 502 described above and transmit it to a counterparty (e.g., a worker who is supposed to compute a valid proof π). In one embodiment, the transaction input 512 may encode an identifier 514 associated with the transaction output 502, a transaction output index 516 associated with the transaction output 502 (e.g., the index may be zero-based in some cases), an unlocking script 520, a parameter indicating the size of the unlocking script (e.g., in bytes), which may be called the unlocking script size 518, a sequence number 522, and any suitable combination thereof. For example, in some embodiments, the size of the unlocking script is not explicitly encoded in the transaction input 512 and can be derived in other ways (e.g., through the detection of a specific termination sequence indicating the end of the unlocking script). In one embodiment, the unlocking script 518 is a verification key V K This includes 524 and the digital signature 526 associated with the client. In some cases, the unlocking script 518 may include additional information such as instructions for branching information that control the execution of the verification process.

[0088] For example, an unlocking script may be described based on the following:

number

[0089] Please note that the example provided above is a description of the unlocking script and not necessarily the unlocking script itself verbatim. For example, some of the fields enclosed in square brackets above are not verbatim included in the unlocking script 518. Returning to the example above, which is a description of the unlocking script, the unlocking script 518 is a description of the verification key V K The 524 elements may include an ordered or unordered sequence, 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 according to the Bitcoin-based system. The unlocking script 518 may include execution control information that can be used 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 statements in the unlocking script (e.g., the OP_IF branch instead of the OP_ELSE branch).

[0090] In one embodiment, worker 528 calculates proof π 530, appends it to an unlocking script 518 along with a digital signature 532 associated with the worker, and broadcasts the transaction (for example, to clients and / or one or more nodes of the blockchain network).

[0091] As an example, an unlocking script with a proof and the worker's digital signature may be described as follows:

number

[0092] Thus, in one embodiment, the unlocking script according to the above description can satisfy the conditions imposed on the output by the locking script and can enable the use of digital assets (such as those indicated by the output value).

[0093] Verification key V for use in relation to the validity check of proof π K There are various techniques for providing. FIG. 6 shows the verification key V used for the validity check of proof π K which is an exemplary FIG. 600 supplied by an operator. Transaction output 602 may follow a Bitcoin-based system and may include an output value 604, a locking script 606 (optionally, in some systems) and a locking script 608. In one embodiment, the transaction is a Pay-to-Script-Hash (P2SH) transaction following a Bitcoin-based system. In one embodiment, transaction output 612 follows a Bitcoin-based system and includes a transaction ID 614, an output index 616, an unlocking script size 620, an unlocking script 618 and a sequence number 622 as described above in relation to FIG. 5. The structure of the transaction described in FIG. 6 may follow that described in FIG. 5, but it should be noted that FIG. 6 may, in particular, include a locking script 608 and an unlocking script 618 following a P2SH transaction. Client 610 may generate a verification key V K and a redeem script 628 and provide them to operator 624.

[0094] In one embodiment, the blockchain system supports various types of transactions. In one embodiment, supported transactions (e.g., standard transactions) are script hash-based transactions, such as Pay-to-Script-Hash (P2SH) transactions that follow a Bitcoin-based system. Generally speaking, a script hash-based transaction refers to any transaction in which verifying the validity of the locking script involves providing a script that matches a specified hash value. For example, in a Bitcoin-based P2SH transaction, the unlocking script 620 includes a redeem script 628, and the locking script 608 includes at least one condition that the hash of the redeem script supplied by the unlocking script matches a specified value. For example, in a Bitcoin-based system, the locking script may be written based on: OP_HASH160 <20-byte hash of redemption script> OP_EQUAL

[0095] Depending on the circumstances, worker 624 may use verification key V in the verification phase. K 626 is provided. In one embodiment, the unlock conditions that check the verification stage can be stored in the redeem script. In one embodiment, the locking script for a P2SH transaction includes a hash of the redeem script, which may be kept secret (e.g., encrypted by the worker) and revealed only when there is an instruction to trigger the transfer of output values.

[0096] In one embodiment, client 610 creates a P2SH unused transaction output by identifying the redeem script and applies a hash (e.g., HASH160) to it. To transfer the UTXO, the client creates an input script (which references the UTXO) that includes and / or otherwise references the redeem script. Blockchain-based systems may have limitations on the type or amount of data that can be included in the redeem script, but it should be noted that in one embodiment, the redeem script is suitable for storing arbitrary data. For example, in relation to Bitcoin-based systems, there may be limitations on the size of data that can be exposed to the stack (e.g., the PUSHDATA operation is limited to 520 bytes of data). In one embodiment, the redeem script is compressed at point P, as described in relation to Figure 4. C and the incompressible point P U This includes. Therefore, in one embodiment, the maximum number of elliptic curve points that can be stored in the redeem script according to a Bitcoin-based protocol is 15 compressed points (e.g., 15 points × 34 bytes / point = 510 bytes) or 7 uncompressed points (7 points × 66 bytes / point = 462 bytes). In one embodiment, the unlocking script 618 includes a proof 630, a redeem script 628, and commands (e.g., opcodes) that can be used together to satisfy a set of conditions encoded in the locking script 608.

[0097] Figure 7 is an illustrative diagram of a process 700 for generating a redeem script according to one embodiment. In one embodiment, the process 700 is implemented using hardware, software, or a combination thereof. A suitable system for executing the process includes an operator supplying the P2SH unlocking script in connection with the description in Figure 6.

[0098] In one embodiment, the system uses verification key V KThe system determines that it has sufficient cardinality. In one embodiment, the system determines the size of a redeem script, which includes each element of the verification key and a script for checking a set of constraints, 702 where the redeem script and proof π are sufficient to unlock the corresponding locking script. The system may determine whether the size of such a redeem script exceeds a predetermined threshold, 704. The predetermined threshold may be based on a size limit imposed by the blockchain protocol—for example, the blockchain protocol may require that the redeem script be no larger than 520 bytes. If the redeem script is of sufficient size, the system generates a redeem script and an unlocking script, 706 in which the redeem script includes the verification key and a script for checking a set of constraints, the unlocking script includes proof π, and the redeem script and the unlocking script together include a set of commands sufficient to verify the payment transaction.

[0099] For example, verification key V K If the cardinality of is less than 16, then the following may apply: [Table 3] Here, the redeem script and the unlocking script are sufficient to unlock the locking script.

[0100] If the redeem script exceeds a predetermined threshold, the system generates an unlocking script that stores one or more elements of the verification key VK in part of the unlocking script preceding the redeem script 708, thereby bringing the total size of the redeem script within the threshold and generating the redeem script with the elements of the verification key and the aforementioned constraints 710. In one embodiment, the verification key V K One or more elements of may be encoded elsewhere in the unlocking script. For example, VK If the cardinality of is greater than 15, the following may apply: [Table 4] Here, the redeem script and the unlocking script are sufficient to unlock the locking script.

[0101] Therefore, by encoding the steps required in the validation phase within the locking script, transaction validation should become a process equivalent to the validation phase of the zk-protocol. In one embodiment, the OP_VERIFYPROOF opcode may be used as follows: [Table 5]

[0102] The unlocking script and locking script may be implemented in any suitable manner. The unlocking script is implemented using <π1>..<π8> and verification key V. K It is implemented in any suitable way to encode it. Similarly, the locking script is π i and

number

[0103] Figure 8 is an exemplary simplified block diagram of a computing device 800 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 800 can be used to implement any of the systems illustrated and described above. For example, the computing device 800 may be configured to be used as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 8, the computing device 800 may, in embodiments, include one or more processors 802 that communicate with 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, which includes a memory subsystem 808 and a file / disk storage subsystem 810, one or more user interface input devices 812, one or more user interface output devices 814, and a network interface subsystem 816. Such a storage subsystem 806 may be used for temporary or long-term storage of information.

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

[0105] In some embodiments, the user interface input device 812 includes one or more user input devices such as keyboards; pointing devices such as integrated mice, trackballs, touchpads, or graphics tablets; scanners; barcode scanners; touchscreens integrated into displays; audio input devices such as voice recognition systems and microphones; and other types of input devices. Generally, the use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information into the computing device 800. In some embodiments, the user interface output device 814 includes non-visual displays such as display subsystems, printers, or audio output devices. In some embodiments, the display subsystem includes flat panel devices such as cathode ray tubes (CRTs), liquid crystal displays (LCDs), light-emitting diode (LED) displays, projection devices, or other display devices. Generally, 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 and facilitate user interaction with applications that perform the described processes and their variations when such interaction may be appropriate.

[0106] In some embodiments, the storage subsystem 806 provides a computer-readable storage medium for storing basic programming and data constructs that provide functionality for at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) provide functionality for one or more embodiments of the present disclosure when executed by one or more processors in some embodiments, and are stored in the storage subsystem 806 in some embodiments. These application modules or instructions can be executed by one or more processors 802. In various embodiments, the storage subsystem 806 further provides a repository for storing data used in accordance with the present disclosure. In some embodiments, the storage subsystem 806 includes a memory subsystem 808 and a file / disk storage subsystem 810.

[0107] In some embodiments, the memory subsystem 808 includes multiple 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 capable of storing fixed instructions. In some embodiments, the file / disk storage subsystem 810 provides non-temporary persistent (non-volatile) storage for program files and data files and may include a hard disk drive, a floppy disk drive, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media, along with associated removable media.

[0108] In some embodiments, the computing device 800 includes at least one local clock 824. In some embodiments, the local clock 824 is a counter representing the number of ticks that have occurred since a particular start date, and in some embodiments, it is integrally located within the computing device 800. In various embodiments, the local clock 824 may be used to synchronize data transfers within the processor and its constituent subsystems for the computing device 800 at a particular clock pulse, and may 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.

[0109] The computing device 800 can be any of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. In addition, in some embodiments, the computing device 800 may include another device that can be connected to the computing device 800 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). In embodiments, such a device includes a port that accepts an optical fiber connector. Thus, in some embodiments, this device converts optical signals into electrical signals that are transmitted through the port connecting the device to the computing device 800 for processing. Due to the constantly changing nature of computers and networks, the description of the computing device 800 shown in Figure 8 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations with more or fewer components than the system shown in Figure 8 are also possible.

[0110] The embodiments described above are illustrative, not limiting, of the invention, and it should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, all reference numerals enclosed in parentheses should not be construed as limiting the claims. Terms such as “comprising” and “comprises” do not exclude the existence of elements or steps other than those enumerated in any claim or the entire specification. In this specification, “comprising” means “including or consisting of.” A singular reference to an element does not exclude a plural reference to such an element, and vice versa. The invention may be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In device claims enumerating several means, some of these means may be embodied by a single hardware item. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be advantageously utilized.

[0111] All documents cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as when each document is individually and specifically designated to be incorporated by reference, and is described herein in whole.

Claims

1. A computer implementation method: A step of generating a transaction output of a transaction which includes instructions for a digital asset and a locking script that encodes a set of conditions for transferring control of the digital asset, wherein the satisfaction of the set of conditions is determined at least in part on a verification key and a proof; A step of generating a transaction input for the transaction, wherein the transaction input is: The identifier associated with the transaction output, An unlocking script including the aforementioned proof, Steps including; A step of confirming that the set of conditions is met, at least in part, based on the locking script and the unlocking script; In response to confirming that the set of conditions described above has been satisfied, the steps include: transferring control of the digital asset; Includes, A computer implementation method comprising: a client encoding the transaction input using the verification key and a first digital certificate associated with the client; and an operator encoding the transaction input using the proof and a second digital certificate associated with the operator.

2. The verification key comprises a plurality of first elements of a finite field, and the proof comprises a plurality of second elements of the finite field. The computer implementation method according to claim 1.

3. The elements of the aforementioned finite field are points on an elliptic curve. The computer implementation method according to claim 2.

4. The elements of the aforementioned finite field are encoded in a compressed format. The computer implementation method according to claim 2.

5. The locking script includes an instruction to retrieve the digital asset for the supplier of the digital asset, provided that one of the set of conditions is not met by the unlocking script. The computer implementation method according to claim 1.

6. The unlocking script further includes a redeem script, and the verification key and the redeem script satisfy the set of conditions, The locking script encodes the condition from the set of conditions in which the hash of the redeem script matches a predetermined value. The computer implementation method according to claim 1.

7. The aforementioned redeem script is 520 bytes or less in size. The computer implementation method according to claim 6.

8. The unlocking script includes one or more elements of the verification key, The computer implementation method according to claim 6.

9. The aforementioned transaction is a P2SH transaction that follows a Bitcoin-based protocol. The computer implementation method according to claim 6.

10. The aforementioned transaction is a standard transaction that follows a blockchain-based protocol. The computer implementation method according to claim 1.

11. The locking script and unlocking script are encoded in a stack-based scripting language. The computer implementation method according to claim 1.

12. The set of conditions mentioned above includes a bilinear constraint. The computer implementation method according to claim 1.

13. It is a system: Processor and; A memory containing executable instructions that, as a result of being executed by the processor, cause the system to execute the computer implementation method described in any one of claims 1 to 12; A system equipped with these features.

14. A non-temporary computer-readable storage medium that stores executable instructions, which, as a result of being executed by the processor of a computer system, cause the computer system to perform at least one of the computer implementation methods described in any one of claims 1 to 12.

Images