System for recording verification keys on blockchain

Abstract

To provide systems and methods to enable secure transfers and exchanges over a blockchain.SOLUTION: A method comprises: obtaining a redeem script associated with a blockchain transaction, where a first script comprises a first set of commands and one or more cryptographic hash values; generating a second script comprising a second set of commands, one or more subsets of a plurality of elements, where the plurality of elements collectively forms a verification key and the one or more subsets collectively include each element of the verification key, the first script, and an identifier associated with a computer system generating the second script; and generating an attestation that the computer system has access to the verification key on the basis of at least in part, executing the first set of commands and the second set of commands in connection to determine that the one or more cryptographic hash values match the one or more subsets of the verification key.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention generally relates to computer-implemented security and / or verification techniques. It also relates to solutions for extending or enhancing blockchain functionality, and more specifically to implementing anonymous or nearly anonymous digital transactions. The present invention is particularly suited, but not limited to, for use in protocols that utilize and / or can benefit from cryptographically verifiable guarantees of integrity (if the protocol is followed correctly, a legitimate verifier will be convinced of the validity of the output), soundness (a dishonest prover cannot convince a legitimate verifier that the certainty of the output is true), and / or zero-knowledge (if the output is valid, a dishonest verifier will not learn anything other than this fact). Various protocols described herein may be suitable for recording a verification key on the blockchain, where a worker can provide a correct (e.g., client-issued) verification key V. k The present invention can utilize cryptographic and mathematical techniques to implement security in connection with electronic transfers made over a blockchain network. [Background technology]

[0002] 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 unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, Bitcoin may be referenced as a beneficial application of the technology described herein, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure may be used to verify that an entity has a valid or appropriate verification key V k It would be advantageous to utilize other blockchain implementations that have similar limitations to Bitcoin with respect to recording an entity's verification key that can prove possession of the key. Note that as described herein, Bitcoin refers to any blockchain-based blockchain network, such as Bitcoin Cash and Bitcoin Classic.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks, which may be composed of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured collection of field values ​​that contain data and a set of conditions, where satisfying the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. For example, in Bitcoin, each transaction is a data structure that encodes the transfer of control of a digital asset between participants of the blockchain system and includes at least one input and at least one output. In some embodiments, a "digital asset" refers to binary data that is associated with usage rights. Examples of digital assets include Bitcoin, Ether, and Litecoin. In some implementations, transferring 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 a blockchain may include a hash of the previous block, such that the blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception.

[0004] 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 may utilize a stack. In a stack, values ​​can be pushed onto the top of the stack or popped off the top of the stack. Various operations performed on a stack may result in one or more values ​​being pushed onto or popped off the top of the stack. For example, an OP_EQUAL operation pops the top two items off the stack, compares them, and pushes the result (e.g., 1 if equal, 0 if not) onto the top of the stack. Other operations performed on a stack, such as OP_PICK, may allow an item to be selected from a position other than the top of the stack. In some scripting languages ​​used in some of the embodiments, there may be at least two stacks, a main stack and an alternate stack. Some operations in the 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. Note that stack-based scripting languages, in some cases, are not limited to strictly last-in, first-out (LIFO) operations. For example, a stack-based scripting language may support an operation that copies or moves the nth item in the stack to the top (e.g., OP_PICK and OP_ROLL in Bitcoin, respectively). Scripts written in stack-based scripting languages ​​may be pushed onto a logical stack, which may be implemented using any suitable data structure, such as a vector, list, or stack.

[0005] In order 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 can have different standards for validity than other nodes. Since blockchain validity is consensus-based, a transaction is considered valid if a majority of nodes agree that it is valid. A software client installed on a node performs this validation work for transactions that reference partially unspent transactions (UTXOs) by executing the UTXO locking and unlocking scripts. A transaction is validated by a node if the execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions are met, if applicable. Validated transactions are propagated to other network nodes, where mining nodes can choose to include the transaction in the blockchain. Thus, for a transaction to be written to the blockchain, i) it must be verified by the first node that receives it, which, if verified, relays the transaction to other nodes in the network; ii) it must be added to a new block constructed by mining nodes; and iii) it must be mined, i.e., added to the public ledger of past transactions. A transaction is considered confirmed once a sufficient number of blocks have been added to the blockchain to make it effectively irreversible.

[0006] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, 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 to automate tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be able to take advantage of the benefits of blockchain (e.g. persistence, tamper-proof record of events, distributed processing, etc.), although their uses are more diverse.

[0007] This disclosure describes technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program may be a machine-readable, executable program that is recorded in a blockchain transaction. A blockchain-based computer program may include rules that can process inputs to generate results and then cause actions to be performed 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 that are written in natural language, smart contracts may be computer programs that are designed to automate the execution of the terms of a machine-readable contract or agreement.

[0008] Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities through the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Thus, the tokens act as identifiers that allow real-world items to be referenced from the blockchain.

[0009] In embodiments, interactions with specific entities may be encoded in specific steps of a smart contract, but the smart contract may otherwise be automatically executed and self-enforcing. 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 a UTXO refers to an entity that can create the unlocking script without being required to prove knowledge of any secret. In other words, the unlocking transaction can be verified without verifying that the source of the data (e.g., the entity that created the unlocking transaction) has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcing refers to validating nodes of a blockchain network forcing the unlocking transaction according to constraints. In some examples, "unlocking" a UTXO (also known as "spending" a UTXO) is used in a technical sense to refer to creating an unlocking transaction that executes as valid, with reference to the UTXO.

[0010] The output of a blockchain transaction includes a locking script and information about the ownership of a digital asset, such as Bitcoin. A locking script, sometimes called an encumbrance, "locks" a digital asset by specifying conditions that must be satisfied in order for a UTXO to be transferred. For example, a locking script may require that certain data be provided in the unlocking script in order to unlock the associated digital asset. A locking script is also known as a "scriptPubKey" in Bitcoin. A technique for requiring a party to provide data to unlock a digital asset involves embedding a hash of the data inside the locking script. However, this presents a problem if the data is undetermined (e.g., unknown and not fixed) at the time the locking script is created.

[0011] The present invention may be described as a verification method / system and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the recording of a transaction on the blockchain, which in some applications may result in the exchange or transfer of digital assets via the blockchain. A digital asset may be a unit of a resource managed by the blockchain. In some embodiments, a digital asset may be used as cryptocurrency, although it is contemplated that in some embodiments, a digital asset may additionally or alternatively be used in other contexts. It is noted that the present invention, while applicable to the control of digital assets, is technical in nature and may be used in other contexts utilizing blockchain data structures without necessarily involving the transfer of digital assets. Summary of the Invention [Problem to be solved by the invention]

[0012] It is therefore desirable to provide a system and method configured to enable secure transfers and exchanges on a blockchain. Preferably, but not necessarily, this is a public blockchain. It is further desirable to implement anonymous digital transfers and / or communications, where information about the transfer / communication is obscured, such as (for example) information related to the recipient of the digital asset in the blockchain transaction. It is further desirable to provide credential authority to read / write metadata on the blockchain, such that the metadata cannot be read and / or modified unless appropriate credentials are presented, according to a protocol. The present invention therefore provides enhanced verification and / or security.

[0013] Such an improved solution has now been devised. [Means for solving the problem]

[0014] Therefore, in accordance with the present invention there is provided a system and method as defined in the accompanying claims.

[0015] The present invention may be described as a security method / system. Alternatively, the present invention may be described as a verification method / system. The present invention may provide advantages related to (but not limited to) cryptographically verifiable guarantees of integrity, soundness and / or zero-knowledge. Alternatively, the present invention may provide a method / system for verifying that an entity has a correct or appropriate verification key V. k Alternatively, the present invention may be described as providing a control mechanism for controlling the performance of distributed computation, improving efficiency and security.

[0016] According to the present invention, a computer-implemented method may be provided, the computer-implemented method including: obtaining a redeem script associated with a blockchain transaction, the first script including a first set of commands and one or more cryptographic hash values; generating a second script including a second set of commands, one or more subsets of a plurality of elements, the plurality of elements collectively forming a verification key, the one or more subsets collectively including each element of the verification key, the first script, and an identifier associated with the computer system generating the second script; and generating a certificate that the computer system has access to the verification key based at least in part on executing the first set of commands and the second set of commands in association with a determination that the one or more cryptographic hash values ​​match the one or more subsets of the verification key.

[0017] An element of the plurality of elements may be a point on an elliptic curve.

[0018] The first set of commands and the second set of commands may collectively include instructions to determine whether a first cryptographic hash value of the one or more cryptographic hash values ​​matches the hash output based at least in part on a subset of the one or more subsets of the verification key.

[0019] The hash output may be generated by successively hashing the input using cryptographic hash algorithms such as SHA-256 and RIPEMD-160, for example using SHA-256 and then RIPEMD-160.

[0020] Preferably, the method includes identifying one or more subsets of the verification keys, and for each subset of the one or more subsets of the verification keys, the one or more cryptographic hash values ​​include a respective corresponding cryptographic hash value.

[0021] Preferably, the method may further comprise the step of transferring control of the digital assets encumbered by the transaction to a computer system, conditional on verifying the generated certificate.

[0022] Preferably, the method may further comprise the step of obtaining the first script from a second computer system, the second computer system having contributed at least a portion of the digital asset.

[0023] The transaction may be a Pay-to-Script-Hash (P2SH) transaction, such as a P2SH transaction that follows a Bitcoin-based protocol.

[0024] Preferably, at least a portion of the verification keys are greater than or equal to 512 bytes in size and less than or equal to 520 bytes in size. Optionally, all of the verification keys are greater than or equal to 512 bytes in size and less than or equal to 520 bytes in size.

[0025] Preferably, the first script is greater than or equal to 58 bytes in size and less than or equal to 104 bytes in size, and the second script is greater than or equal to 1628 bytes in size and less than or equal to 1650 bytes in size.

[0026] The transaction may be a standard transaction that conforms to the blockchain protocol.

[0027] The one or more subsets may be exactly one subset, where the one subset includes the verification key.

[0028] The first script may further include a public key associated with the computer system, the identifier associated with the computer system may be a digital signature generated using a private key corresponding to the public key, and proof that the computer system has access to the verification key may be further based at least in part on the digital signature and the public key.

[0029] It is also desirable to provide a system including a processor and a memory containing executable instructions which, upon execution by the processor, cause the system to perform any of the claimed methods.

[0030] It is also desirable to provide a non-transitory computer readable storage medium storing executable instructions which, upon execution by a processor of a computer system, cause the computer system to perform at least any of the claimed methods. Any of the features described above in relation to the methods of the present invention may also be applied to the corresponding systems. [Brief description of the drawings]

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

[0032] [Figure 1] FIG. 1 illustrates a blockchain environment in which various embodiments may be implemented. [Diagram 2] FIG. 1 illustrates a computing environment that may be utilized to implement protocols in accordance with various embodiments. [Diagram 3] FIG. 1 is a diagram of an environment suitable for performing verifiable computations. [Figure 4] FIG. 1 is a diagram of a data structure according to the blockchain protocol that is suitable for recording a verification key on the blockchain, allowing an operator to prove possession of the correct verification key Vk. [Diagram 5] FIG. 2 is a diagram of a locking transaction in accordance with various embodiments described in this disclosure. [Figure 6] FIG. 1 illustrates a process for generating a redeem script according to at least one embodiment. [Figure 7]FIG. 13 illustrates a diagram in which the protocol is modified to include a proof of computation upon unlocking of digital assets based on execution of a smart contract. [Figure 8] FIG. 1 illustrates a computing device that may be used to implement at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] Reference is first made to Figure 1, which illustrates an example blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure. In this embodiment, the example blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each of which executes instances of software and / or hardware that perform operations according to a blockchain protocol agreed upon at least in part among operators of the nodes 102. In some examples, a "node" refers to a peer-to-peer electronic device that is distributed among the blockchain network. One example of a blockchain protocol is the Bitcoin protocol.

[0034] In some embodiments, node 102 may be comprised of any suitable computing device (e.g., by a server in a data center, by a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smart phone, 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 of FIG. 8). In some embodiments, node 102 has an input for receiving data messages or objects representing proposed transactions, such as transaction 104. The node, in some embodiments, is queried for information it maintains, such as information on the state of transaction 104.

[0035] As shown in Figure 1, some of the nodes 102 are communicatively coupled to one or more of the other nodes 102. Such communicative coupling may include one or more of wired or wireless communication. In an embodiment, the nodes 102 each maintain at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger is a distributed ledger. Transactions processed by a node that affect the ledger are verifiable by one or more of the other nodes such that the integrity of the ledger is maintained.

[0036] With respect to which nodes 102 may communicate with which other nodes, it is sufficient that each of the nodes in the example blockchain network 100 may communicate with one or more other of the nodes 102 such that messages passed between nodes may propagate throughout the example blockchain network 100 (or any significant portion thereof), assuming that the messages are messages that the blockchain protocol indicates should be forwarded. One such message may be the publication of a proposed transaction by one of the nodes 102, e.g., node 102A, which would then propagate along a path such as path 106. Another such message may be the publication of a proposed new block for inclusion in the blockchain.

[0037] In one embodiment, at least some of the nodes 102 are mining nodes that perform complex calculations, such as solving cryptographic problems. The mining nodes that solve the cryptographic problems create new blocks for the blockchain and broadcast the new blocks to other nodes 102. The other nodes 102 verify the mining node's work and, upon verification, accept the block into the blockchain (e.g., 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., a hash) of the previous block. In this manner, each block may become linked to the previous block, thereby generating a "chain" that links the blocks in the blockchain. In an embodiment, valid blocks are added to the blockchain by consensus of the nodes 102. Also, in some examples, the blockchain includes a list of validated blocks.

[0038] In one embodiment, at least some of the nodes 102 operate as validating nodes that validate 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 providing conditions for accepting or transferring ownership / control of the digital asset. 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 represented by a UTXO of a previous transaction to an entity associated with a blockchain address. In some examples, a "previous transaction" refers to a blockchain transaction that includes a UTXO referenced by the unlocking transaction. In some embodiments, a transaction includes a "locking script" that blocks the transaction with conditions that must be met before ownership or control can be transferred ("unlocked").

[0039] 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 being 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, validation of a transaction includes verifying one or more conditions specified in a locking script and / or an unlocking script. Upon successful validation of a transaction 104, the validating node adds the transaction 104 to the blockchain and distributes it to nodes 102.

[0040] The systems and methods described herein in connection with exemplary applications of the invention relate to the execution of locking transactions in a blockchain system. A locking transaction may refer to a transaction that initializes a constraint that allows an unlocking transaction to be verified. The invention may be used to securely enumerate and exchange transactions in some exemplary applications. In the context of smart contracts, it may be advantageous to have a public record (e.g., recorded on the blockchain) of a proof of correct execution of a circuit published by an operator and a verification key, thereby allowing someone (e.g., a node on the blockchain) to verify the validity of the computation and the proof. However, there are challenges in recording large blocks of data (e.g., large keys that may include multiple elliptic curve points) on the blockchain. For example, in a Bitcoin-based blockchain network, protocols utilizing standard transactions may be constrained to locking and unlocking scripts overall being 1650 bytes in size or less, and redeem scripts (if utilized) may be limited to a size of 520 bytes or less.

[0041] Verifiable computation is a technique that allows for the generation of a proof of computation. In an exemplary embodiment, such techniques may be utilized by a client to outsource the evaluation of a function f on an input x to another computing entity, referred to herein as a worker. In some cases, the client may be computationally constrained, making it infeasible for the client to perform the evaluation of the function (e.g., the expected runtime of the computation using the computational resources available to the client exceeds a maximum allowed threshold), but this need not be the case and the client may, generally speaking, delegate the evaluation of the function f on an input x based on any suitable criteria, such as computational runtime or computational cost (e.g., the economic cost of allocating the computational resources to perform the evaluation of the function).

[0042] The worker, in one embodiment, is any suitable computing entity, such as a blockchain node, described in more detail elsewhere in this disclosure, such as those described in connection with FIG. 1 and FIG. 8. 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 that can be verified by other computing entities, such as the client and / or other nodes of the blockchain network. The proof, sometimes referred to as an argument, can be verified faster than an actual computation, and thus can reduce computational overhead (e.g., reducing power overhead and costs associated with powering up and running computational resources) by verifying the correctness of the proof instead of recomputing the function f for the input x to determine the correctness of the output generated by the worker. In zero-knowledge verifiable computation, the worker provides a client with a certificate that the worker knows an input with certain properties.

[0043] A useful variant of zero-knowledge proof of knowledge is the succinct non-interactive ARgument of knowledge (zk-SNARK). In one embodiment, all pairing-based zk-SNARKs involve a process in which an operator computes multiple group elements using a general group operation, and a verifier checks the proof using multiple pairing product equations. In one embodiment, linear interactive proofs work over finite fields, and the operator and verifier messages contain, encode, or otherwise include information usable to determine a vector of field elements.

[0044] In one embodiment, the systems and methods described herein enable mining nodes of a blockchain to perform a computation once (e.g., evaluating a function f on an input x) and generate a proof that can be used to verify the correctness of the output, where evaluating the correctness of the proof is computationally less expensive than evaluating the function. In this context, the cost (i.e., how expensive) of operations and tasks 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, heapsort and quicksort algorithms both have an average computational cost of o(n logn), while quicksort has an average computational cost of o(n logn). 2), whereas heapsort has a worst-case computational cost of o(n logn). In one embodiment, the average and / or worst-case computational cost of evaluating the function f on the input x is worse than the cost of evaluating the correctness of the proof. Thus, the use of the systems and methods described herein may be highly advantageous, for example, allowing for more computationally expensive contracts to be executed, since such contracts do not proportionally increase the time required to verify the blockchain. Further advantages may include reduced 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 when evaluating the correctness of the proof. Currently, smart contracts must be executed and verified at all nodes - this constraint limits the complexity of smart contracts. The methods and systems described herein can be used to improve the efficiency of a blockchain by executing a contract once to generate a proof of correctness, and to implement a system in which all nodes of the blockchain can verify the validity of the contract based on the proof of correctness 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 that can be collectively executed by the nodes of the blockchain and / or allowing the computation of more computationally expensive smart contracts.

[0045] In one embodiment, the verification key V k A proof π, or a portion thereof, can be extracted from the public parameters and input / output data generated in the setup phase of the zero-knowledge protocol and used with the proof π to verify the alleged proof of correctness computation provided by the worker. For example, as described above and in more detail below, systems and methods that allow locking scripts include a verification key V kfrom modification, checks the validity of the proof π, and enables the execution of zero-knowledge protocols on the blockchain during transaction verification. Thus, the present disclosure presents a system and method suitable for recording a verification key on a blockchain, where an operator needs to obtain the correct verification key V (e.g., issued by a client) to redeem a digital asset for the execution of a set of operations (e.g., execution of a smart contract). k can prove ownership.

[0046] 2 illustrates a computing environment 200 that may be utilized to implement the protocol, according to various embodiments. The protocol may be implemented using blockchain technology to store proofs of correctness and combine "correct-by-construction" cryptography with smart contracts. In one embodiment, the publicly verifiable computation scheme includes three phases: a setup phase, a computation phase, and a verification phase.

[0047] The setup phase may be performed as part of a process to outsource the execution of a computational task. A client, as referred to below, may refer to an entity such as a customer or a client computer system that delegates the execution of a computational task to a worker, which may be a different computer system. A client may delegate the execution of a computational task for a variety of reasons, generally speaking, including but not limited to, computational resources, lack of computational resources, economic 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 a battery for power may utilize a worker to perform a computationally intensive task, thereby conserving power and extending the use of the battery-powered device).

[0048] In one embodiment, the setup phase involves a client, customer, employee of an organization, or any other suitable entity writing a contract in a formal language with precise semantics. 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 is or can be converted 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 limited expressivity may be utilized. The generated source code may be a precise description of the contract.

[0049] The compiler 202 may be any hardware, software, or combination thereof that includes executable code that, when executed by one or more processors of a computer system, 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 performs 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 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 with wires that carry values ​​from a field F and connect to logic and / or arithmetic gates. In one embodiment, the circuit C is used by the system to generate a quadratic program Q 208 that includes a set of polynomials that provide a complete description of the original circuit C.

[0050] In one embodiment, the compiler 202 can recognize a substantial subset of a programming language such as 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, functional operators (e.g., functors), conditionals and loops, and arithmetic and bitwise Boolean operators. In one embodiment, the compiler 202 does not support the entire set of commands from a programming language standard (which may in some cases be intended to prevent certain types of algorithms from being executed in smart contracts, such as disallowing recursive algorithms). In one embodiment, the compiler extends the representation of the source code to an arithmetic gate language and generates arithmetic circuits. Circuit implementations have been previously considered 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 circuits may be utilized by a compiler 202 or any other suitable hardware, software, or combination thereof (e.g., software modules not shown in FIG. 2) to construct a Quadratic Arithmetic Problem (QAP). The quadratic program is compiled into a set of cryptographic routines for clients (e.g., key generation and verification) and workers (e.g., calculations and proof generation) according to one embodiment. In some embodiments, arithmetic circuit optimization techniques such as those described in UK Patent Application No. 1718505.9 may be utilized to reduce the resources required for workers to determine the outcome of a smart contract.

[0051] In one embodiment, the key generator 204 is hardware, software, or a combination thereof that includes executable code that, when executed by one or more processors of a computer system, causes the system to generate evaluation and verification keys forming 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, a 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. The target polynomial t(x) is also defined. Let f be a function that takes n elements of F as input and n' elements as output, and given N = n + n', Q is a polynomial of {c1,...,c N}∈F N is a valid assignment of the input and output groups of f, and the list of coefficients {c N+1 ,...,c m}, compute f such that t(x) divides p(x):

number

[0052] In one embodiment, constructing a QAP for an arithmetic circuit includes, for each multiplication gate g in the circuit, g ∈F and

number

number

[0053] In one embodiment, the QAP is a field F p is defined above, where p is a large prime. In one embodiment, F p It is desirable for the QAP above to efficiently compute any function that can be expressed in terms of addition and multiplication modulo p. The arithmetic split gate is k-1 ] into k binary output wires. Thus, Boolean functions can be expressed using arithmetic gates, e.g., NAND(a,b)=1-ab. Each embedded Boolean gate takes only one multiplication operation. Furthermore, new gates, such as split, can be defined as standalone and can be composed with other gates. k-1 ] is known to be in Fp Given, the split gate is Σ k Σ 2i-1 a i Output k wires each holding the binary digits a1,...,ak of a such that a = a, and for each a i is either 0 or 1.

[0054] Finally, the public parameters used by all provers and verifiers are generated by the system as part of the setup phase. K and the verification key V K Note that E is derived using a secret value selected by the client. The key generator 204 utilizes a quadratic arithmetic program (QAP) in conjunction with the key generation algorithm to derive the evaluation key E K 210 and verification key V K 212 can be generated.

[0055] In one embodiment, performing a computational task involves the computation of a function on input 216 by an actor (i.e., the process of evaluating f(x)). In an embodiment, an actor is any suitable computer system to which a client can delegate a computational task. Input 216, in one embodiment, includes information verifying the identity of the actor, such as a digital signature generated using a private key associated with the actor. In one embodiment, an actor is a computer system to which a client transfers a digital asset as a result of a successful computation. A client, in one embodiment, receives input x and an evaluation key E K to the operator, who uses the evaluation module 214 for a computation routine to calculate an output y (i.e., y=f(x), where the input is x and the function is f) and obtains an evaluation key E K 210 to generate a proof of correctness 218. The evaluation module, in one embodiment, is hardware and / or software that includes instructions that, when executed by one or more processors of a computer system, cause the computer system to evaluate values ​​of the internal circuit wires of the QAP 208 and generate an output y of the QAP.

[0056] In one embodiment, each polynomial v of the quadratic program k (x)∈F is an element g in the bilinear group vk(s) where s is a secret value selected by the client, g is the generator of the group, and F is the field of discrete logarithms of g. In one embodiment, for a given input, the operator evaluates the circuit to find the coefficient c i Therefore, the operator obtains the output and value of the internal circuit wire corresponding to v(s)=Σ k∈{m} Rate ck·vk(s) v(s) Obtain w(s) and y(s) and calculate h(x)=p(x) / t(x)=Σ d h i x i Calculate h in the evaluation key. i and g s(i) Using the term g h(s) In one embodiment, the proof of correctness 218 calculates (g v(s) , g w(s) , g y(s) , g h(s) ), and the verifier uses the bilinear map to check p(s)=h(s)·t(s). In one embodiment, the proof π may be stored on the blockchain 222 for later use or verified by multiple parties without the prover needing to interact with each of them separately. In one embodiment, evaluation of the circuit storage of the proof of correctness may be performed to unlock resources (e.g., digital assets) that are blocked by the transaction's locking script.

[0057] 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 a computational entity such as a node of the blockchain. In some cases, the computing entity verifying the proof uses an evaluation key E K and the verification key V KIt is further noted that the nodes of the blockchain are the same computing entities that generate the verification keys V. K The payment transaction can be verified using the proof π and the contract can be verified if the verification is successful. One requirement of the protocol is the verification key V K Therefore, in this protocol, the common reference string (CRS) must be at least as long as the evaluation key E K and the verification key V K In one embodiment, the verification key V is generated by a client or a trusted third party that publishes the verification key V. K can be used by any computational entity to verify a computation. In some embodiments, the verification step is performed using a blockchain script (e.g., a Bitcoin-based network) that stores the elements used to verify the computation, which may follow the techniques described in UK Patent Application No. 1719998.5.

[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 reveal the recipient's address and the recipient's public key. In some cases, however, 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 cryptographic techniques described above and below are utilized by the client to convert the locking script into a quadratic arithmetic program, and the worker solves the arithmetic program to generate a proof.

[0059] Generally speaking, a client can use standard transactions such as P2PK and P2PKH (e.g., standard transactions defined in a Bitcoin-based blockchain network) 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 that includes a puzzle derived from the circuit. The counterparty or worker receives the circuit, provides appropriate inputs (e.g., information that proves the identity of the worker, such as a shared secret between the client and the worker or a digital signature generated using the worker's private key), and executes the circuit to generate a proof of correctness π. In one embodiment, the proof is used to unlock a resource (e.g., a digital asset), and furthermore, information that identifies the counterparty or worker (e.g., a public key and / or digital signature associated with the counterparty or worker) may not be recorded in the blockchain in an obfuscated format.

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

number

[0061] Verification key V K , proof π and (a1, a2, ..., a N ), then t(x) divides p(x), and so (x N+1 ,...,x m )=f(x0,...,x N To verify α, the verifier proceeds as follows. First, the three α terms:

number

number

number

number

number

number

number

number

number

number

number

[0062] Thus, considering the notations from the sections above and the examples described in this disclosure, validation, according to one embodiment, involves a set of paired checks of the following elements:

number

[0063] 3 illustrates a diagram 300 for coordinating the performance of a verifiable computation. The client 302, the worker 304, and the verifier 306 may be nodes of a blockchain network. The 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 a 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 write the smart contract 308 in a field

number

[0064] In one embodiment, the client 302 provides the worker 304 with an arithmetic circuit 310 and inputs 312 to the circuit. The circuit 310 may be used to generate a quadratic program Q, which includes a set of polynomials that provide a complete description of the original circuit. In either case, the worker 304 may run the circuit C or the quadratic program Q on the inputs 312 to generate one or more outputs 314. In some embodiments, the worker (i.e., the prover) is expected to obtain as output a valid transcript for {C, x, y}, which is the assignment of values ​​to the 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 values ​​assigned to the output wires are y; there is no valid transcript for {C, x, y} if the claimed output is incorrect (i.e., y ≠ P(x)). In an embodiment, the worker is expected to provide a subset of the values ​​of the circuit wires, and the selected subset of the values ​​of the circuit wires is not known a priori to the worker.

[0065] In an embodiment, the output y, the values ​​of the internal circuit wires (or a subset thereof), and the evaluation key EK are used to generate a proof of correctness 316. The proof π can be stored on the blockchain and verified by multiple parties without requiring the worker 304 to interact with those parties separately. In this manner, the verifier 306 can verify the payment transaction using the public verification key VK and the proof π, thereby validating the contract. In some cases, the client 302 may reclaim the digital assets encumbered by the payment transaction if the verification fails.

[0066] A system and method for recording a verification key on a blockchain network is described herein. Often, the blockchain system or network is used for normal (standard) transactions as described above. According to an embodiment of the present disclosure, it is possible to provide a provisioning system for the creation and processing of smart contracts by applying an implementation of zero-knowledge simple non-interactive arguments of knowledge (zk-SNARK).

[0067] In one embodiment, transactions contain small programs known as scripts embedded in their inputs and outputs that specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language. Blockchains may further impose constraints related to maximum data thresholds for the amount of data that can be stored in a block, and protocols may enforce constraints related to the size of the keys (e.g., a verification key V that encodes multiple elliptic curve points) related to the maximum allowed size. k ) may be selected based on the size of the locking script and the unlocking script. For example, in a Bitcoin-based protocol, the combined size of the locking script and the unlocking script, in one embodiment, does not exceed 1650 bytes, and the size of the redeem script does not exceed 520 bytes. In one embodiment, the unlocking script and / or the redeem script include instructions (e.g., opcodes) in addition to encoding the verification key, and may further include additional instructions and / or data for verifying that the operator possesses the verification key (e.g., by verifying a digital signature). Thus, it may be difficult to generate scripts that provide some or all of the above-mentioned functionality, especially in conjunction with the use of larger key sizes, which, in embodiments, may provide greater security and / or cryptographic guarantees of security.

[0068] In one embodiment, as part of the locking transaction, the client publishes a Common Reference String (CRS) that contains the reputation and verification keys. K, VK}, but note that, as mentioned above, the common reference string may contain any additional suitable information. K The size of is based at least in part on the size of the circuit under consideration (e.g., the evaluation key E K (The number of elements constituting V corresponds to and / or is proportional to the number of internal gates in the circuit.) The size of the verification key, in one embodiment, depends only on the inputs and outputs. Often, a public record of a proof (e.g., a proof of work or proof of correct execution published by a prover / worker) and a corresponding verification key V K - hence the proof and verification keys V K Any entity with access to the blockchain network can verify the validity of the computations and proofs. In one embodiment, the verifier 306 is any suitable entity, such as a node of the blockchain. It is further noted that in some implementations, the verifier 306 and the client 302 are the same computer system. In other words, in some embodiments, any computer system with access to the blockchain network can perform a verification process that determines the validity of the computations and proofs provided by the purported prover / worker.

[0069] In some systems, the identity of the worker is known and the client can pay the worker for the execution of a contract directory. In one embodiment, the client pays the worker directly by obtaining an address associated with the worker and transferring digital assets to the address associated with the worker.

[0070] According to various embodiments, FIG. 4 illustrates a diagram 400 of a data structure according to a blockchain protocol suitable for recording a verification key on a blockchain, where an operator must provide the correct verification key V (e.g., issued by a client) to redeem a digital asset for the execution of a set of operations (e.g., execution of a smart contract). KIn addition, in some embodiments, the protocol allows for a proof of validity to be included when redeeming rewards for executing a contract. In one embodiment, the protocol is implemented according to existing blockchain protocols - e.g., the systems and methods described herein can be implemented in the existing Bitcoin network without requiring modifications to the Bitcoin protocol.

[0071] 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 according to a Bitcoin-based system. Generally speaking, a script hash-based transaction refers to any transaction, where validating the unlocking script includes providing a script that matches a specified cryptographic hash value. For example, in a Bitcoin-based P2SH transaction, the unlocking script includes a redeem script, and the locking script includes at least one condition that a hash of the redeem script provided by the unlocking script matches a specified value. For example, in a Bitcoin-based system, the locking script may be written based on the following: OP_HASH160 <20-byte hash of redemption script> OP_EQUAL

[0072] In one embodiment, diagram 400 shown in FIG. 4 outlines a suitable structure for encoding a verification key, where an operator must provide the correct verification key V KThe unlocking script 402 and the redeem script 404 may be implemented according to that described according to a Pay-To-Script-Hash (P2SH) transaction. In some cases, a blockchain protocol enforces a maximum total size for the unlocking script 402 and the corresponding locking script and / or enforces a maximum total size for the redeem script 404. For example, in a Bitcoin-based system, the redeem script for a P2SH standard transaction must be 520 bytes or less.

[0073] The unlocking script 402 includes a collection of data parameters that satisfy a set of conditions placed in the corresponding locking script. In a P2SH transaction, the locking script typically includes a hash value and requires the unlocking script to include a redeem script, where the hash of the redeem script matches the hash value encoded in the locking script. Thus, in one embodiment, the locking script encodes a hash value based at least in part on a set of constraints, and indirectly encodes the set of constraints by requiring that the redeem script presented in the unlocking script encode the set of constraints.

[0074] Specifically, the unlocking script 402 shown in FIG. 4 includes a digital signature 406 and a verification key V K , one or more subsets of (e.g., first subset 412 and last subset 416), a redeem script 404, and a verification key V KThe digital signature 406 includes an additional opcode (also referred to throughout this disclosure as a command, operation, function, and instruction) that provides a cryptographically verifiable guarantee that the worker possesses a verification key V. In one embodiment, the digital signature 406 is generated using the private key of the worker, and the authenticity of the digital signature 406 is cryptographically verifiable using a public key 408 associated with the worker. The public key 408 associated with the worker may be encoded within the redeem script 404. Thus, the digital signature 406 is generated using a public key 408 associated with the worker that the worker possesses using a verification key V. K It serves as proof of possession of the

[0075] Verification key V K In one embodiment,

number

number

[0076] In some cases, a verification key V KNote that v is not split into multiple non-overlapping subsets, but instead is encoded as a single block (i.e., in its entirety) in the unlocking script 402, and a single hash is encoded in the redeem script 404. The unlocking script functions in a manner similar to the embodiment described above and below in conjunction with the description of FIG. 4, where a single hash value is encoded as the verification key V. K The whole is compared against the output of the hash.

[0077] Continuing with the above description of the unlocking script 402, the unlocking script may further include a redeem script 410. In one embodiment, the redeem script is a set of parameters that produces a hash output that matches a value encoded in the corresponding locking script. In one embodiment, the locking script, the unlocking script, and the redeem script are utilized in a two-step process, where during the first step, the redeem script is checked against the locking script to determine whether the redeem script satisfies the conditions of the locking script. The conditions of the locking script may include a condition that the hash of the redeem script matches a predefined value. In one embodiment, the OP_HASH160 opcode is utilized, which hashes the input first with SHA-256 and then with RIPEMD-160 to generate a hash output. In one embodiment, the hash output of the OP_HASH160 operation is 20 bytes in size (0x14 bytes).

[0078] As mentioned above, the unlocking script 402 may further include an opcode, in which case the unlocking script 402, when executed, allows the operator to obtain the verification key V K The verification key V KIn embodiments where is split into two subsets, one such unlocking script may be described in the following manner, which is denoted using instructions and data (in square brackets) in accordance with a stack-based scripting language such as that utilized by Bitcoin-based systems: OP_PUSHDATA1<length of signature> <signature>OP_PUSHDATA1<byte-length of VK1> VK1 OP_PUSHDATA1<byte-length of VK2> VK2 OP_PUSHDATA1<length of redeem script><redeem script> Here, as mentioned above, the command (e.g., "OP_PUSHDATA1") is written without brackets, and the data is written with brackets (e.g., "<length of signature> " is a one-byte integer corresponding to the size in bytes of the digital signature 406.) The notation VK1 denotes the verification key V K , and VK2 refers to the first subset of the verification key V K , which gives the verification key V K =VK1||VK2 and

number

number

[0079] In one embodiment, the redeem script 404 is utilized to satisfy one or more conditions encoded within the locking script. For example, the locking script may include a hash value and a condition that the unlocking script includes a routine where a hash output on the routine results in an output value that matches the hash value included in the locking script. The routine, in one embodiment, is the redeem script 404. In one embodiment, the redeem script 404 includes a verification key V K For each subset of , the corresponding hash value, a public key 414 associated with the worker, and, if executed, a verification key V K The redeem script 404 includes an additional opcode (also referred to as a command, operation, function, or instruction throughout this disclosure) that provides a cryptographically verifiable guarantee that the redeem script 404 possesses a verification key V. In one embodiment, the redeem script 404 executes in the context of the unlocking script 402. In one embodiment, the hash value encoded in the redeem script is a verification key V. K are encoded in the reverse order that the corresponding subsets of the verification key appear in the unlocking script 402. For example, if the first subset 412 appears first in the unlocking script 402, then the corresponding first hash 414 is the last hash value to appear in the redeem script 404. Similarly, the hash 418 corresponding to the last subset of the verification key appears first in the redeem script relative to the hashes of the other subsets of the verification key. Note that in this context, order refers to the relative order of the hash values, but does not imply or impose an order with respect to other data and other commands encoded in the redeem script 404. Continuing with the previous example, a suitable redeem script may be described as follows: OP_HASH160 <hvk1>OP_EQUALVERIFY OP_HASH160 <hvk2>OP_EQUALVERIFY<PubKey worker> OP_CHECKSIG Here, as mentioned above, the command (e.g., "OP_HASH160") is written without brackets, and the data is written with brackets (e.g., <hvk1>(VK1 is a 20-byte value corresponding to the result of applying the OP_HASH160 operation to VK1). In one embodiment, the redeem script is provided to the operator by the client. The redeem script 404, in one embodiment, facilitates cryptographic attacks to verify the verification key VK1. K A verification key V can be used to determine K Note that the metric does not directly provide any information about the value of

[0080] In one embodiment, the blockchain protocol defines a maximum size of the unlocking script 402 to be up to 1650 bytes. The blockchain protocol may further define a maximum size of 520 bytes as the largest overall chunk of data that can be pushed on the stack. In one embodiment, the elements of the verification key are each 32 bits in size. Thus, an unlocking script 402 subject to the above constraints may include the following: [Table 1] Therefore, the unlocking script and redeem script described above generate a verification key V with 45 elements, each element being 32 bytes in size. K can be used to encode the

[0081] FIG. 5 illustrates a diagram 500 of a locking transaction according to various embodiments described in this disclosure. In an embodiment, a first party 502 and a second party 504 agree to the terms of a contract in any suitable manner. For example, the parties may agree to a set of terms offline (e.g., face-to-face negotiation between representatives of both parties, telephone, email, or any other suitable communication medium). In one embodiment, the terms are agreed to programmatically - e.g., a computer system configured with parameters to evaluate offers for the contract (e.g., fulfillment price) and determine whether to accept the offer. For example, the first party and the second party agree that the first party will sell and issue tokens to the second party for a price the second party agrees to pay. In one embodiment, the tokens may be redeemable for physical assets (e.g., consumer goods and services), digital assets, and any combination thereof.

[0082] In one embodiment, the first party creates a locking transaction 506 that includes two inputs (e.g., inputs 508 and 510) and two outputs (e.g., outputs 512 and 514) and signs them with an indication of how the signature should be verified (e.g., using OP_CHECKSIG). In one embodiment, the indication includes an indication of the mode of operation and a modifier indicating who can pay (e.g., anyone can pay). In one embodiment, the input and output are signed with SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. In one embodiment, the input includes a transaction amount of a nominal value (e.g., a small number of satoshis), and the output includes a transaction amount that includes a digital asset for the worker (the value of which may be selected based on various factors such as the value of the contract) and the value of the contract (e.g., an amount that the second party 504 agrees to pay the first party 502 according to the terms of the contract).

[0083] Generally speaking, the operating mode may provide an indication of which and / or how various fields of the locking transaction are signed. For example, in a first operating mode (e.g., SIGHASH_ALL), all signable parameters are signed. In one embodiment, this includes all fields of the transaction except the input script. A second example of an operating mode that may be supported is an operating mode in which outputs are not signed (e.g., SIGHASH_NONE) - thus other entities can modify the transaction by changing their input sequence numbers. Yet another example of an operating mode that may be supported is a mode in which inputs are signed but the sequence numbers are blank (e.g., SIGHASH_SINGLE). In one embodiment, some or all operating modes are supported. Furthermore, in addition to the operating mode, a separate indication (e.g., SIGHASH_ANYONECANPAY) may be made regarding only a single output (or more generally, any subset of outputs) being signed, while other outputs are optional.

[0084] The locking transaction 506 is then provided to a second party 504. The locking transaction is received by the second party, who verifies the locking transaction is correct. In this context, the validity of the locking transaction refers to the locking transaction accurately reflecting a prior agreement between the parties, and validating the validity includes, for example, verifying that the price encoded in the token is the agreed-upon cost between the parties and that the terms of the contract are in the pre-agreed-upon format. In one embodiment, determining the validity of the locking transaction includes verifying the authenticity of the digital signature.

[0085] If the locking transaction is determined to be correct, the second party 504 adds new inputs 516, which may include digital assets (e.g., a payment agreed upon as part of the terms of the agreement between the parties) and the digital assets the worker will pay for the execution of the contract. The second party 504 may also add an output 518 that constrains the common reference string and signs with SIGHASH_SINGLE or SIGHASH_ALL, and broadcasts it (e.g., to the blockchain network). Once the locking transaction is broadcast, the first party may be considered the owner of the contract. In one embodiment, a key (e.g., a verification key V included as part of the CRS) may be added to the output 518. K and evaluation key E K ) is generated using the field F, where:

number

number

number

[0086] In one embodiment, the evaluation key E K and the verification key V K is a random or pseudorandom value

number

number

number

number

number

number

number

[0087] As mentioned above, the evaluation key E K and the verification key V K is composed of group elements. Note that for purposes of clarity, the groups discussed herein are elliptic curves, although any group of sufficiently high cardinality is suitable.

[0088] In one embodiment, there is an elliptic curve based implementation of the pairing function. In one embodiment, encryption in the blockchain network is based on elliptic curves, such as the secp256k1 elliptic curve. In some embodiments, it is possible to determine and / or estimate the amount of space required to allocate keys in the blockchain. As mentioned above, the verification key V K The subset of elements of is independent of the size of the circuit, and the space required for such a field is independent of the size of the circuit.

[0089] In some cases, the maximum size of a standard blockchain transaction corresponds to the maximum size of a block. Different blockchain systems may have different upper limits, such as a Bitcoin-based system, where a standard transaction has a defined maximum block size of 1MB and a maximum standard transaction size of 100KB. In a blockchain system such as a Bitcoin-based system, the size of a redeem script is 520 bytes or less. The maximum size of a redeem script, in one embodiment, is the largest overall chunk of data that can be pushed on the stack while still conforming to the conditions of a standard transaction. The upper limit on unlocking input scripts and locking scripts (e.g., P2PK, P2PH, and others), in one embodiment, is 1650 bytes. In one embodiment, this is equivalent to the script storing or otherwise encoding 15 public keys. In one embodiment, the unlocking script is called an input script or signature script (e.g., ScriptSig) and contains a set of data parameters that meet the conditions placed on the previous locking script, which may be called an output script or scriptPubKey.

[0090] Thus, in one embodiment, the redeem script and corresponding input script are arranged to have the maximum amount of data attached thereto, and the arrangement of the redeem script, corresponding input script, and / or other data is based at least in part on the maximum size. In one embodiment, the unlocking script includes or otherwise encodes a digital signature. In one embodiment, FIG. 4 illustrates the structure of the largest possible unlocking and locking script, including a signature conforming to a standard type transaction of a Bitcoin-based system. It should be noted that, in one embodiment, the structure illustrated in FIG. 4 is utilized to attach the maximum amount of data possible within the constraints of the blockchain system (e.g., the maximum size of a standard transaction), while in other embodiments, the structure is defined in any other suitable manner, such as a structure with less than the maximum amount of data attached.

[0091] In one embodiment, data is recorded in the non-standard transaction in addition to and / or instead of a standard transaction. In one embodiment, the hard-coded script length is 10 kilobytes (KB), and a set of mining nodes in the blockchain accept transactions for smart transactions that would otherwise be considered non-standard. In other words, some embodiments utilize non-standard transactions that are identifiable as smart transactions, and one or more nodes in the blockchain network accept such transactions.

[0092] 6 shows a flowchart illustrating a process 600 for generating a redeem script according to at least one embodiment. Process 600 may be performed by any suitable computer system, such as the client described elsewhere in this disclosure in connection with FIG. 3. In one embodiment, the redeem script is generated in the context of other embodiments, such as the one described in connection with FIG. 4. Based on the circuit C and the secret, the client derives a verification key V by performing process 600. K In one embodiment, the process follows a protocol that depends on different subroutines that perform different functions. For example, the no_TX(ARG) function is used in an embodiment to measure the size of the argument ARG in bytes or any suitable unit of measurement with conversion to bytes (e.g., bits). In one embodiment, this function is used to determine 602 the number of locking scripts to be created. In one embodiment, the no_TX(ARG) function measures the byte size of the ARG input parameter and returns 1 if the amount of data can be stored in a standard script, or returns the number of transactions required for the output (script) that are needed to accommodate the amount of data corresponding to the input of the function ARG if the ARG exceeds the maximum size of the script in a standard transaction. In one embodiment, the function simply returns an indication of whether the amount of data corresponding to the input ARG exceeds the maximum size of the script in a standard transaction, such as a Boolean indication of TRUE or FALSE or any equivalent thereof (e.g., an integer value of 0 equal to a FALSE indication and a non-zero value equal to a TRUE indication). In one embodiment, the no_TX() subroutine (e.g., as described above) is passed a verification key V K Supplying as input provides information that can be used to determine how many locking transactions to create.

number

number

number

[0093] The system serializes the verification key into multiple elements according to an embodiment 604. Generally speaking, serializing data means splitting the data into smaller chunks, for example according to a length set by some standard or protocol. For example, the verification key V K may be split into 32-bit chunks, i.e.

number

[0094] Generally speaking, the system selects 606 at least a subset of the elements of the verification key. In one embodiment, the subset is a contiguous subset (such as those described in the example above) that has a total size that does not exceed a threshold size (e.g., the 520 byte limit for stack objects in a Bitcoin-based system). In one embodiment, the subset is a set of many verification keys V that fit within a specified size limit. K It is determined by selecting the elements in turn.

[0095] In one embodiment, the system assigns for each locking transaction a set of keys to be included in the corresponding unlocking script according to a set of rules. In one embodiment, the protocol has an upper limit on the size of data objects that can be pushed onto the stack - for example, in Bitcoin, 520 bytes is the maximum allowable size for a block. Thus, the verification key V K is 520 bytes or less in size (i.e., the system determines that the verification key can be encoded without splitting it into multiple subsets). In one embodiment, the system calculates 608 a hash over the selected elements. The selected elements are used to generate the verification key V, as described above. K In one embodiment, an opcode such as OP_HASH160 is used to hash the subset. In one embodiment, the hashing of the object utilizes multiple cryptographic hash algorithms such as SHA-256 and RIPEMD-160 to generate a hash output HVK, which is encoded in the redeem script such as the following redeem script: OP_HASH160 <hvk>OP_EQUALVERIFY<PubKey worker> OP_CHECKSIG

[0096] Of course, other hashing algorithms and corresponding hashing opcodes may be used in various embodiments. K When executed in conjunction with an unlocking script that provides proof of ownership of the calculated hash, the redeem script can be used to unlock a digital asset that is blocked by the corresponding locking script. Thus, a redeem script is generated 610 having one or more conditions that the corresponding unlocking script includes one or more parameters that match based at least in part on the calculated hash. In an embodiment, the redeem script further includes a condition that the output script includes a digital signature generated using the worker's private key that corresponds to the public key encoded in the redeem script.

[0097] In one embodiment, the system uses a verification key V K exceeds the maximum allowable size of a data block on the stack, and the verification key V K into two or more subsets. In one embodiment, the system determines the number of chunks to be included in each subset, for example, by calculating the maximum number of chunks that can be encoded within the size limits of the protocol. In one embodiment, the system encodes each subset that has the maximum number of chunks or the number of chunks remaining that are not encoded. For example, each chunk

number

number

number

number

number

number

number

number

[0098] As a third example, consider the embodiment described in relation to Figure 4. In this case, the maximum size of an unlocking script is 1650 bytes, and the maximum size of a block of data is 520 bytes. The system maximizes the size of the verification key,

number

number

number

number

[0099] Each time a hash is generated, the system may determine whether an additional subset should be identified and hashed 612. In one embodiment, the system uses a verification key V K The system determines that no additional subsets are needed based on a determination that each element of has a corresponding condition in the redeem script that is satisfied based on the worker supplying the respective element as part of the unlocking script. In one embodiment, the system makes the redeem script available 614 to workers and others who can use the redeem script to generate a corresponding locking script.

[0100] Workers (e.g.<PubKey worker> To redeem a payment to an entity associated with K In one embodiment, the possession of the correct verification key V K Any suitable proof of ownership of V can be used by the system, where a counterparty can cryptographically verify the worker's proof of purported ownership. In one embodiment, for each locking script, the worker creates an unlocking script, which is generated using a serialized verification key V, as in the creation of the redeem script. K The length of the

[0101] The serialized verification key V K The length of V is small enough (e.g., V is large enough that the entire verification key can be pushed onto the stack without splitting it) K If , the operator creates an unlocking script: OP_PUSHDATA1<length of signature> <signature>OP_PUSHDATA1<byte-length of VK> VK OP_PUSHDATA1<length of redeem script><redeem script>

[0102] Otherwise, if the length of the serialized verification key exceeds an applicable threshold, the operator K Divide into two or more subsets. For example,

number

number

number

number

[0103] As a third example, consider the embodiment described in relation to Figure 4. In this case, the maximum size of an unlocking script is 1650 bytes, and the maximum size of a block of data is 520 bytes. K The three subsets:

number

number

number

[0104] Various extensions to the embodiments described in this disclosure are contemplated in addition to those explicitly discussed. In one embodiment, a protocol such as a Bitcoin-based protocol is used to implement the systems and methods described herein - in some cases, existing protocols may be extended to support additional functionality.

[0105] For example, in an embodiment, the output is split into multiple transfers - e.g., the output is split into two parts, one part of elements belonging to the first group G1 and the other part of elements for the second group G2. Thus, in this example, there are two inputs (hexadecimal representations of group elements from each group included in the script) that pay into the worker's public key. The steps of this protocol for symmetric pairing are repeated for each of the two inputs. In one embodiment, the protocol is extended to splice the verification key accordingly.

[0106] As a second example, the keys (e.g., in the order of elements originating from groups G1 and G2, respectively) are kept as is, and a protocol (e.g., an existing Bitcoin-based protocol) is extended to encode and decode the keys and isolate which 32-byte representations of group elements belong to, e.g., through the use of a hash map or any other suitable data structure. In one embodiment, software running on top of the existing protocol (e.g., an extension of the protocol used by at least a subset of the set of nodes in the blockchain network) is used to encode and decode the keys and isolate which 32-byte hexadecimal representations of group elements belong to.

[0107] In one embodiment, FIG. 7 illustrates a diagram 700 of an embodiment in which a protocol is modified to include a proof of computation 704 when redeeming a digital asset to execute a contract. For example, a Bitcoin-based protocol is extended to support including a proof of computation when redeeming a digital asset to execute a contract. In one embodiment, the proof of computation includes a fixed number of elements and has a fixed length property. FIG. 7 illustrates one such example of how to record a proof of computation in a blockchain, where a first data block 702 (e.g., first data block Data1) is split so that the first data block 702 includes elements corresponding to the proof of computation 704, and those elements are pushed to an alt stack (e.g., using a command such as OP_TOALTSTACK) to make space for a signature check against a corresponding public key. In one embodiment, the first batch of elements corresponding to the verification key is in a block labeled "Data1" 708. Note that the annotation of the data block size is purely exemplary.

[0108] Further enhancements are contemplated within the scope of this disclosure. As discussed elsewhere, the protocol as described herein may be modified to include a hash value (e.g., HASH160(V K )) and verification key V K This can be augmented with additional support for reading the key itself and publishing the two in conjunction with the transaction identifiers of the locking and the workers redeeming transactions respectively. In this way, entities that subsequently verify the proofs of correctness published by the workers can do so with the assurance that the key was originally published by the client.

[0109] In one embodiment, the protocols described herein (e.g., Bitcoin-based protocols) are extended with additional opcodes, commands, or statements that perform checks on the proof of validity (e.g., in the manner described above). In one embodiment, the OP_CHECKPOC opcode is supported and operates on the proof of validity, a verification key, input (u), and output (y) in a manner similar to how OP_CHECKSIG checks that the signature on the transaction input is valid. In one embodiment, OP_CHECKPOC returns a value of TRUE or FALSE, a value of 1 or 0, etc., to indicate whether the proof of validity was verified.

[0110] FIG. 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 can be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As illustrated in FIG. 8, the computing device 800 can, in embodiments, include one or more processors 802 that communicate with and are operably coupled to a number of peripheral subsystems via a bus subsystem 804. In some embodiments, these peripheral subsystems include a storage subsystem 806 that 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 can be used for temporary or long-term storage of information.

[0111] In some embodiments, the bus subsystem 804 provides a mechanism that allows the various components and subsystems of the computing device 800 to communicate with each other as intended. Although the bus subsystem 804 is shown generally 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. The network interface subsystem 816, in some embodiments, serves as an interface for receiving data from the computing device 800 and transmitting data to other systems. In some implementations, the bus subsystem 804 is utilized to communicate data such as details, search terms, etc.

[0112] In some embodiments, the user interface input devices 812 include one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen integrated into a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, 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 one or more user interface output devices 814 include a display subsystem, a non-visual display, such as a printer or an audio output device, and the like. In some embodiments, the display subsystem includes a flat panel device, such as a cathode ray tube (CRT), a liquid crystal display (LCD) or a light emitting diode (LED) display, a projection device, or other display device. In general, 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. The one or more user interface output devices 814 can be used, for example, to present a user interface and to facilitate user interaction with applications that perform the described processes and variations thereof, when such interaction may be appropriate.

[0113] In some embodiments, the storage subsystem 806 provides a computer readable storage medium for storing basic programming and data constructs that provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which in some embodiments when executed by one or more processors, provide functionality of one or more embodiments of the present disclosure, are stored in the storage subsystem 806 in embodiments. These application modules or instructions may 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.

[0114] In an embodiment, memory subsystem 808 includes multiple memories, such as a main random access memory (RAM) 818 for storage of instructions and data during program execution and / or a read-only memory (ROM) 820 that may store fixed instructions. In some embodiments, file / disk storage subsystem 810 provides non-transient persistent (non-volatile) storage for program files and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, or other similar storage media.

[0115] In some embodiments, computing device 800 includes at least one local clock 824. The local clock 824, in some embodiments, is a counter that represents the number of ticks that have occurred since a particular start date and, in some embodiments, is integrally located within computing device 800. In various embodiments, the local clock 824 is used to synchronize data transfers within the processor and subsystems contained therein for computing device 800 at a particular clock pulse, and may be used to coordinate synchronization operations between computing device 800 and other systems in a data center. In another embodiment, the local clock is a timer with a programmable interval.

[0116] The computing device 800 can be any of a variety of types, including a portable computing device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 800, in some embodiments, can 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 a fiber optic connector. Thus, in some embodiments, the device converts optical signals into electrical signals that are transmitted through a port that connects the device to the computing device 800 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 800 shown in FIG. 8 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations having more or fewer components than the system shown in FIG. 8 are possible.

[0117] It should be noted that the above-described embodiments are illustrative rather than limiting of the invention, and 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, any reference signs placed in parentheses shall not be construed as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "including or consisting of" and "comprises" or "comprises" or "comprises". A singular reference of an element does not exclude a plural reference of such element and vice versa. The invention may be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.

[0118] All references cited in this specification, including publications, patent applications, and patents, are hereby incorporated by reference into this specification to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.< / signature> < / signature> < / signature> < / hvk1> < / hvk> < / k> < / k> < / signature>

Claims

1. 1. A computer-implemented method for generating a redeem script, the method being performed by a processing resource, the method comprising: determining the number of locking scripts to be created; obtaining a verification key; serializing the verification key into a number of elements; selecting a subset of the elements of the verification key; assigning a set of keys to be included in a corresponding unlocking script; determining a hash of the selected subset of the elements; generating a redeem script including one or more matching parameters based on the determined hash; A computer-implemented method comprising:

2. The verification key is determined based on a common reference string. The method of claim 1.

3. The number of locking scripts is determined based on a no_TX(ARG) function. The method of claim 1.

4. the verification key is serialized by splitting the verification key into multiple chunks; The method of claim 1.

5. the plurality of chunks are determined based at least in part on a size of the verification key; The method according to claim 4.

6. the subset of elements is a contiguous subset having a total size not exceeding a threshold size; The method of claim 1.

7. The redeem script further includes a provision that an output script includes a digital signature generated using a private key corresponding to a public key encoded in the redeem script. The method of claim 1.

8. The private key is the private key of the worker. The method according to claim 7.

9. an element of the plurality of elements is a point on an elliptic curve; The method of claim 1.

10. The hash is generated using at least the SHA-256 and RIPEMD-160 cryptographic hash algorithms; The method of claim 1.

11. In the system, A processor; A memory containing executable instructions that, when executed by the processor, cause the system to perform the computer-implemented method of claim 1; A system comprising:

12. A non-transitory computer readable storage medium storing executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least the computer-implemented method of claim 1.

Images