A system for recording verification keys on the blockchain.

Abstract

This invention provides a method, system, and non-temporary computer-readable storage medium that enable secure transfer and exchange on a blockchain. [Solution] In a blockchain system, the locking script for a Bitcoin-based Pay-to-Script-Hash (P2SH) transaction includes a redeem script. The unlocking script includes a signature, one or more subsets of the verification key VK (from the first VK element to the last VK element), and the redeem script. The signature is generated using the worker's private key, and the authenticity of the signature can be cryptographically verified using the public key associated with the worker. The public key associated with the worker is included in the redeem script. This allows the worker to prove ownership of the correct verification key VK, and the signature acts as proof that the worker owns the verification key VK.

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, more specifically, for implementing anonymous or nearly anonymous digital transactions. The present invention is particularly suited to use in protocols that utilize and / or benefit from cryptographically verifiable guarantees of integrity (if the protocol is followed correctly, a legitimate verifier will be confident in the validity of the output), sanity (a fraudulent prover cannot convince a legitimate verifier that the certainty of the output is true) and / or zero knowledge (if the output is valid, a fraudulent verifier learns nothing more than this fact). Various protocols described herein may be suitable for recording verification keys on a blockchain, where a worker has the correct verification key V (e.g., issued by the client). k It is possible to prove ownership. This invention can implement security related to electronic transfers that take place on a blockchain network by utilizing cryptographic and mathematical techniques. [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 their variations. 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. For example, the technology described herein applies when an entity has a correct or appropriate verification key V k This would offer the advantage of utilizing other blockchain implementations that have similar limitations to Bitcoin regarding the recording of entity verification keys, which can prove ownership. 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 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 includes 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 nodes perform this validation work for transactions that refer to partially unused transactions (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. However, this presents a problem when 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, the result of a verified blockchain transaction is a record of the transaction on the blockchain, which in some applications may result in the exchange or transfer of digital assets via the blockchain. Digital assets may be units of resources managed by the blockchain. While digital assets may be used as cryptocurrency in some embodiments, they are intended to be additionally or alternatively usable in other contexts in some embodiments. It should be noted that while the present invention is applicable to the control of digital assets, it is inherently technical and can be used in other contexts that utilize blockchain data structures without necessarily involving the transfer of digital assets. [Overview of the Initiative] [Problems that the invention aims to solve]

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

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

[0014] Accordingly, the present invention provides systems and methods as defined in the appended 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 can provide advantages related to (but not limited to) cryptographically verifiable guarantees of integrity, soundness, and / or zero knowledge. Alternatively, the present invention can provide an entity that is correct or appropriate with a verification key V k This invention can enable, or at least facilitate, the recording of verification keys in a blockchain that can prove ownership. Alternatively, the invention may be described as providing a control mechanism for controlling the performance of distributed computing, thereby improving efficiency and security.

[0016] The present invention may provide a computer implementation method which includes: an acquisition step of acquiring a redeem script associated with a blockchain transaction, wherein the first script comprises a first set of commands and one or more cryptographic hash values; an generation step of generating a second script which comprises 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 comprising each element of the verification key, the first script, and an identifier associated with a computer system generating the second script; and a step of generating a certificate that the computer system has access to the verification key, at least in part on executing the first set of commands and the second set of commands in relation to a determination that one or more cryptographic hash values ​​match one or more subsets of the verification key.

[0017] Some of the elements may be points on an elliptic curve.

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

[0019] The hash output may be generated by sequentially 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 key, and for each subset of the verification key, one or more cryptographic hash values, each corresponding cryptographic hash value.

[0021] Preferably, the method may further include the step of transferring control of the transaction-encumbered digital asset to a computer system, subject to the verification of the generated certificate.

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

[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 key is 512 bytes or larger and 520 bytes or smaller. In some cases, all of the verification key is 512 bytes or larger and 520 bytes or smaller.

[0025] Preferably, the first script is 58 bytes or larger and 104 bytes or smaller, and the second script is 1628 bytes or larger and 1650 bytes or smaller.

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

[0027] One or more subsets may be exactly one subset, and that one subset contains the verification key.

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

[0029] Furthermore, it is desirable to provide a system that includes 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.

[0030] Furthermore, it is desirable to provide a non-temporary computer-readable storage medium that stores executable instructions causing the computer system to execute at least one of the methods claimed, as a result of execution by the computer system's processor. Any of the features described above in relation to the method of the present invention may also be applied to the corresponding system. [Brief explanation of the drawing]

[0031] 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:

[0032] [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 is a diagram of a data structure that conforms to the blockchain protocol and is suitable for recording verification keys on the blockchain, allowing the operator to prove ownership of the correct verification key (Vk). [Figure 5] This is a diagram illustrating a locking transaction according to various embodiments described in this disclosure. [Figure 6] This figure shows the process for generating a redeem script according to at least one embodiment. [Figure 7]This diagram illustrates how the protocol is modified to include a proof of the calculation when unlocking digital assets based on the execution of a smart contract. [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]

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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”).

[0039] 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.

[0040] The systems and methods described herein in connection with exemplary applications of the present invention relate to the execution of locking transactions in a blockchain system. A locking transaction may refer to a transaction that initializes constraints that can verify an unlocking transaction. The present invention can be used in several exemplary applications to securely enumerate and exchange transactions. In the context of smart contracts, it may be advantageous to have a public record (e.g., recorded on the blockchain) and verification key of a proof of the correct execution of a circuit published by an operator, thereby enabling someone (e.g., a node on the blockchain) to verify the validity of the calculation and proof. However, there are challenges in recording large blocks of data (e.g., large keys that may contain 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 of a size of 1650 bytes or less in total, and redeem scripts (if used) may be limited to a size of 520 bytes or less.

[0041] Verifiable computation is a technique that enables the generation of proofs of computations. In exemplary embodiments, such a technique can be used by a client to outsource the evaluation of a function f for an input x to another computing entity, referred to herein as the 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).

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

[0043] 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.

[0044] 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.

[0045] 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 π, and enables the execution of zero-knowledge protocols on the blockchain during transaction verification. Therefore, this disclosure presents a suitable system and method for recording verification keys on the blockchain, in which case the worker can retrieve the digital asset for the execution of a set of operations (e.g., execution of a smart contract) using the correct verification key V (e.g., issued by the client). k It can prove ownership.

[0046] 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.

[0047] 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).

[0048] 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.

[0049] 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.

[0050] In one embodiment, the compiler 202 can 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. In one embodiment, the compiler 202 does not support the entire set of commands 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 representation of source code 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.

[0051] 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 generating an evaluation key and a verification key that form a secondary program for the system. Techniques for encoding computations as secondary 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 of 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):

Equation

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

Equation

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 subject to only one multiplication operation. 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 [].p Given, 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 transfers digital assets as a result of a successful computation. 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 resources (e.g., digital assets) that are being blocked 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 a computing entity such as a node in the blockchain. In some cases, the computing entity verifying the proof uses the evaluation key E K and verification key V KIt should be further noted that these are the same computing entities that generate the verification key V. In one embodiment, the nodes of the blockchain are the same computing entities that generate the 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 computation by any computational entity. 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 can follow the technique 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 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 resource (e.g., 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 one embodiment, the output y, the value (or a subset thereof) of the internal circuit wires, and the evaluation key EK are used to generate a proof 316 of legitimacy. The proof π can be stored on the blockchain and verified by multiple parties without requiring worker 304 to interact with those parties separately. In this way, the verifier 306 can verify the payment transaction using the public verification key VK and proof π, thereby verifying the contract. In some cases, if verification fails, client 302 may reclaim the digital assets that are being held back by the payment transaction.

[0066] Systems and methods for recording verification keys on a blockchain network are described herein. In many cases, blockchain systems or networks are used for ordinary (standard) transactions as described above. According to embodiments of this disclosure, it is possible to provide a system for creating and processing smart contracts by applying an implementation of a concise, non-interactive argument of zero knowledge (zk-SNARK).

[0067] In one embodiment, a transaction includes a small program known as a script embedded in its inputs and outputs, which specifies how and by whom the output of the transaction may be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language. The blockchain may further impose constraints related to a maximum data threshold for the amount of data that can be stored in a block, and the protocol may impose constraints related to the size of the key (e.g., a verification key V encoding multiple elliptic curve points) related to the maximum allowed size. k The selection may be based on the following: For example, in a Bitcoin-based protocol, the combined size of the locking and unlocking scripts may, in one embodiment, not exceed 1650 bytes, and the size of the redeem script may not exceed 520 bytes. In one embodiment, the unlocking script and / or redeem script may 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 worker possesses the verification key (e.g., by verifying a digital signature). Therefore, it is difficult to generate scripts that provide some or all of the above functions, particularly in relation to the use of larger key sizes, which may, in some embodiments, provide greater security and / or cryptographic assurance of security.

[0068] In one embodiment, as part of a locking transaction, the client exposes a Common Reference String (CRS) containing the evaluation and verification keys. In one embodiment, CRS={E KHowever, as mentioned above, please note that the common reference string can contain any additional appropriate information. Evaluation key E K The size is based at least partially on the size of the circuit under consideration (e.g., evaluation key E K The number of elements constituting it corresponds to and / or is proportional to the number of internal gates in the circuit). In one embodiment, the size of the verification key depends only on the input and output. Often, this is done using a public record of the proof (e.g., a proof of work or proof of correct execution published by the certifier / worker) and the corresponding verification key V K Having a proof and verification key V is useful - therefore, proof and verification key V K Any entity with access to the blockchain network can verify the validity of the calculations and proofs. In one embodiment, the verifier 306 is any suitable entity, such as a node on the blockchain. It should be further noted that in some embodiments, 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 to determine the validity of the calculations and proofs provided by the claimed prover / worker.

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

[0070] According to various embodiments, Figure 4 shows a data structure conforming to a blockchain protocol suitable for recording verification keys on the blockchain, where the worker redeems (for example, issued by the client) the correct verification key V KIt is possible to prove ownership of the contract. Furthermore, in some embodiments, the protocol allows for the inclusion of proof of legitimacy when redeeming rewards for executing a contract. In one embodiment, the protocol is implemented in accordance with an existing blockchain protocol—for example, the systems and methods described herein can be implemented on 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 the Bitcoin-based system. Generally speaking, a script hash-based transaction refers to any transaction in which verifying the validity of the unlocking script involves 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: the hash of the redeem script supplied by the unlocking script matches a specified value. For example, in the Bitcoin-based system, the locking script may be written based on: OP_HASH160 <20-byte hash of redemption script> OP_EQUAL

[0072] In one embodiment, Figure 400, shown in Figure 4, outlines a structure suitable for encoding a verification key, in which case the operator can obtain the correct verification key V KThis can prove ownership. The unlocking script 402 and redeem script 404 may be implemented according to those described in accordance with the Pay-To-Script-Hash (P2SH) transaction. In some cases, the blockchain protocol enforces a maximum total size for the unlocking script 402 and the corresponding locking script, and / or for the redeem script 404. For example, in a Bitcoin-based system, the redeem script for a standard P2SH transaction must be 520 bytes or less.

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

[0074] Specifically, the unlocking script 402 shown in Figure 4 contains a digital signature 406 and a verification key V K One or more subsets of (for example, the first subset 412 and the last subset 416), redeem script 404, and, if executed, the worker with verification key V KThe digital signature includes additional opcodes (also referred to throughout this disclosure as commands, operations, functions, and instructions) that provide a cryptographically verifiable guarantee that the worker possesses the public key V. In one embodiment, the digital signature 406 is generated using the worker's private key, and the authenticity of the digital signature 406 is cryptographically verifiable using the 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 cryptographically verifiable using the verification key V. K It acts as proof of ownership.

[0075] Verification Key V K In one sleeve, multiple elements

number

number

[0076] In some cases, verification key V KIt should be noted that the hash is not divided into multiple non-overlapping subsets, but instead encoded as a single block (i.e., the whole thing) within the unlocking script 402, and a single hash is encoded within the redeem script 404. The unlocking script functions in a similar manner to the embodiments described above and below in relation to the description of Figure 4, in which case only one hash value is used for verification key V. K The output is compared against the hash of the whole.

[0077] Continuing 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 generate a hash output that matches a value encoded in the corresponding locking script. In one embodiment, the locking script, unlocking script and redeem script are used in a two-step process, in which, 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. These conditions of the locking script may include the condition that the hash of the redeem script matches a predetermined value. In one embodiment, the OP_HASH160 opcode is used, which hashs 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 (0x14 bytes) in size.

[0078] As described above, the unlocking script 402 may further include an opcode, in which case, when the unlocking script 402 is executed, the operator will verify key V K Includes commands and data that provide cryptographically verifiable guarantees of ownership. For example, verification key V. KIn embodiments where it is divided into two subsets, one such unlocking script may be described in the following way, which is shown using instructions and data (in square brackets) according to a stack-based scripting language such as those used 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, commands (for example, "OP_PUSHDATA1") are written without square brackets, while data is written using square brackets (for example, "<length of signature> (This is a 1-byte integer corresponding to the byte size of a digital signature 406). The notation VK1 indicates the verification key V K VK2 refers to the first subset of the verification key V K This refers to the second subset of, and thereby, verification key V K =VK1||VK2 and

number

number

[0079] In one embodiment, the redeem script 404 is used 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, in which case the hash output on the routine will be an output value that matches the hash value included in the locking script. In one embodiment, the routine is the redeem script 404. In one embodiment, the redeem script 404 includes a verification key V K For each subset, the corresponding hash value, the public key 414 associated with the worker, and, if executed, the worker's verification key V K This includes additional opcodes (also referred to throughout this disclosure as commands, operations, functions, and instructions) that provide a cryptographically verifiable guarantee of ownership. In one embodiment, the redeem script 404 is executed in the context of the unlocking script 402. In one embodiment, the hash value encoded in the redeem script is the verification key V K The corresponding subsets are encoded in the reverse order of their appearance 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, hash 418, corresponding to the last subset of the verification key, is the first to appear in the redeem script relative to the hashes of the other subsets of the verification key. Note that in this context, the order refers to the relative order of the hash values, but does not imply or impose an order for other data and other commands encoded in the redeem script 404. Continuing with the previous example, a proper redeem script would be described as follows: OP_HASH160 <hvk1>OP_EQUALVERIFY OP_HASH160 <hvk2>OP_EQUALVERIFY<PubKey worker> OP_CHECKSIG Here, as mentioned above, commands (for example, "OP_HASH160") are written without square brackets, while data is written using square brackets (for example). <hvk1>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 worker by the client. The redeem script 404, in one embodiment, does not directly provide any information regarding the value of the verification key V K usable to determine K Note that it does not directly provide any information regarding the value of the verification key V.

[0080] In one embodiment, the blockchain protocol defines the 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 onto the stack. In one embodiment, the elements of the verification key are each 32 bits in size. Thus, the unlocking script 402 according to the above constraints may include: [Table 1] Thus, the above unlocking script and redeem script can be utilized to encode the verification key V K having 45 elements each 32 bytes in size.

[0081] Figure 5 shows a locking transaction according to various embodiments described herein. In an embodiment, the first party 502 and the second party 504 agree on the terms of the contract in any suitable manner. For example, the two parties may agree on a set of offline contract terms (e.g., face-to-face negotiations between representatives of both parties, telephone, email, or any other suitable medium of communication). In one embodiment, the contract terms are agreed on programmatically—for example, a computer system is configured to have parameters for evaluating an offer on the contract (e.g., a fulfillment price) and deciding whether to accept the offer. For example, the first and second parties agree that the first party will sell and issue tokens to the second party for a price that 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 including 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, this indication includes an indication of the operating mode and a qualifier indicating who can pay (e.g., anyone can pay). In one embodiment, the inputs and outputs are signed with SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. In one embodiment, the inputs include a transaction amount of nominal value (e.g., a small number of satoshis), and the outputs include a transaction amount including a digital asset for the worker (whose value may be selected based on various factors such as the value of the contract) and the value of the contract (e.g., the amount that the second party 504 agrees to pay to the first party 502 in accordance with the contract terms).

[0083] Generally speaking, the operating mode can provide instructions on which fields of the various fields of a locking transaction are signed and / or how they are signed. For example, in the 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 a supported operating mode is one where the output is not signed (e.g., SIGHASH_NONE) - so other entities can modify the transaction by changing their input sequence numbers. Yet another example of a supported operating mode is one where the input is signed but the sequence number is blank (e.g., SIGHASH_SINGLE). In one embodiment, some or all operating modes are supported. Furthermore, in addition to the operating modes, there may be separate instructions (e.g., SIGHASH_ANYONECANPAY) regarding only a single output (or more generally, any subset of outputs) being signed and other outputs being arbitrary.

[0084] Next, locking transaction 506 is provided to the second party 504. The locking transaction is received by the second party, who verifies that the locking transaction is correct. In this context, the legitimacy of a locking transaction means that it accurately reflects the prior agreement between the parties, and verification of legitimacy includes, for example, confirming 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 form agreed upon in advance. In one embodiment, determining the legitimacy of a 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 a new input 516 which may include digital assets (e.g., payments agreed upon as part of the terms of agreement between the two parties) and digital assets that the worker will pay for the execution of the contract. The second party 504 may also add an output 518 which constrains the common reference string and signs it 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 used. K and evaluation key E K ) is generated using field F. Here,

number

number

number

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

number

number

Number

Number

Number

Number

Number

[0087] As described above, the evaluation key E K and the verification key V K are composed of group elements. Any group with a sufficiently high cardinality is suitable, but for clarity purposes, note that the groups discussed in this specification are elliptic curves.

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

[0089] In some cases, the maximum size of a standard blockchain transaction corresponds to the maximum size of a block. Various blockchain systems may have different upper limits, such as Bitcoin-based systems, for example, a standard transaction has a defined maximum block size of 1 MB and a maximum standard transaction size of 100 KB. In blockchain systems like Bitcoin-based systems, the size of a redeem script is 520 bytes or less. The maximum size of a redeem script is, in one embodiment, 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 in an unlocking input script and a locking script (e.g., P2PK, P2PH, etc.) is 1650 bytes in one embodiment. In one embodiment, this is equivalent to the script storing or otherwise encoding 15 public keys. In one embodiment, the unlocking script, which may be called an input script or signing script (e.g., ScriptSig), contains a set of data parameters that satisfy the conditions set in the previous locking script, which may be called an output script or scriptPubKey.

[0090] Therefore, in one embodiment, the redeem script and the corresponding input script are arranged so that the maximum possible amount of data is attached, and the arrangement of the redeem script, the corresponding input script and / or other data is at least partially based on the maximum size. In one embodiment, the unlocking script includes or is otherwise encoded a digital signature. In one embodiment, Figure 4 shows the structure of the maximum possible unlocking and locking scripts, including a signature that conforms to a standard type of transaction in a Bitcoin-based system. In one embodiment, the structure shown in Figure 4 is used to attach the maximum possible amount of data within the constraints of the blockchain system (e.g., the maximum size of a standard transaction), but it should be noted that in other embodiments, the structure may be defined in any other appropriate way, such as a structure that is less than the maximum amount of data to be attached.

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

[0092] Figure 6 shows a flowchart illustrating a process 600 for generating a redeem script according to at least one embodiment. Process 600 may be executed by any suitable computer system, such as a client described elsewhere in this disclosure in relation to, for example, Figure 3. In one embodiment, the redeem script is generated in the context of other embodiments, as described in relation to Figure 4. Based on circuit C and the secret, the client executes process 600 to obtain verification key V K The Common Reference String CRS is determined, which includes the following. In one embodiment, the process follows a protocol that relies on various subroutines that execute various functions. For example, the no_TX(ARG) function is used in an embodiment to measure the size of the argument ARG, which has a conversion to bytes (e.g., bits), in bytes or any appropriate unit of measurement. In one embodiment, this function is used to determine 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, and if ARG exceeds the maximum size of a script in a standard transaction, the function returns the number of transactions required for the output (script) to accommodate the amount of data corresponding to the input ARG. 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 a script in a standard transaction, for example, a Boolean indication of TRUE or FALSE or any equivalent thereto (e.g., an integer value of 0 equal to the FALSE indication and a non-zero value equal to the TRUE indication). In one embodiment, the no_TX() subroutine (e.g., as described above) is used to verify the key V K Providing this as input provides information that can be used to determine how many locking transactions should be created.

number

number

number

[0093] The system serializes the verification key into multiple elements according to the embodiment.604 Generally speaking, serializing data means dividing the data into smaller chunks according to a length set by some standard or protocol, for example. For example, verification key V K This can be divided into 32-bit chunks, that is,

number

[0094] Generally speaking, the system selects at least a subset of the elements of the verification key.606 In one embodiment, the subset is a contiguous subset (e.g., as described in the example above) with 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 number of verification keys that fit within the specified size limit. K It is determined by sequentially selecting the elements.

[0095] In one embodiment, the system assigns a set of keys to be included in the corresponding unlocking script for each locking transaction, 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 size acceptable for a block. Thus, the verification key V K If the size is 520 bytes or less (i.e., if the system determines that it can encode the verification key without splitting it into multiple subsets). In one embodiment, the system computes a hash of the selected elements. The selected elements are the verification key V as described above. K It may be the whole. In one embodiment, an opcode such as OP_HASH160 is used to hash a subset. In one embodiment, the hashing of an object is performed by generating a hash output HVK using multiple cryptographic hash algorithms such as SHA-256 and RIPEMD-160, and then encoding it within a redeem script such as the following redeem script: OP_HASH160 <hvk>OP_EQUALVERIFY<PubKey worker> OP_CHECKSIG

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

[0097] In one embodiment, the system uses verification key V K However, it was determined that the maximum allowable size of the data block on the stack was exceeded, and verification key V K The data is divided into two or more subsets. In one embodiment, the system determines the number of chunks to be included in each subset by, for example, 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 having the maximum number of chunks or the number of remaining unencoded chunks. 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 the unlocking script is 1650 bytes, and the maximum size of the data block 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 identify an additional subset and determine whether it should be hashed.612 In one embodiment, the system uses a verification key V K Based on the determination that each element has a corresponding condition in the redeem script that is satisfied based on the worker who supplies each element as part of the unlocking script, it is determined that no additional subset is needed. In one embodiment, the system makes the redeem script available to workers, etc., who can use the redeem script to generate the corresponding locking script 614.

[0100] Worker (for example)<PubKey worker> In order to redeem payment to the entity associated with it, the worker, in one embodiment, uses the correct verification key V K To demonstrate ownership of the correct verification key V. In one embodiment, the correct verification key V K Any suitable certificate of ownership is available to the system, in which case the counterparty can cryptographically verify the certificate of the worker who claims to own it. In one embodiment, the worker creates an unlocking script for each locking script, and this unlocking script is created using a serialized verification key V, similar to the case of creating a redeem script. K It varies depending on the length.

[0101] Serialized verification key V K The cardinality is small enough in length (for example, small enough that the entire verification key can be pushed onto the stack without splitting it). K If (is small), the worker 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 the applicable threshold, the worker will V K Divide it 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 the unlocking script is 1650 bytes, and the maximum size of the data block is 520 bytes. The operator is V K to three subsets:

number

number

number

[0104] Various extensions to the embodiments described herein are contemplated in addition to those expressly discussed. In one embodiment, the systems and methods described herein are implemented using a protocol such as a Bitcoin-based protocol—in some cases, an existing protocol may be extended to support additional functionality.

[0105] For example, in one embodiment, the output is divided into multiple transfers—for example, the output is divided into two parts: one part containing elements belonging to the first group G1, and the other part containing elements for the second group G2. Thus, in this example, there are two inputs (hexadecimal representations of group elements from each group contained in the script) that make a payment for 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 together verification keys accordingly.

[0106] As a second example, the key (e.g., in the order of elements arising from groups G1 and G2, respectively) is maintained, and the protocol (e.g., an existing Bitcoin-based protocol) encodes and decodes the key and extends it to separate which group the 32-byte representation of the group elements belong to, for example, through the use of a hash map or any other suitable data structure. In one embodiment, software running on top of an existing protocol (e.g., an extension of the protocol used by at least a subset of the set of nodes in a blockchain network) is used to encode and decode the key and separate which group the 32-byte hexadecimal representation of the group elements belong to.

[0107] In one embodiment, Figure 7 shows Figure 700 of an embodiment in which the protocol is modified to include a proof of computation 704 when redeeming digital assets to execute a contract. For example, a Bitcoin-based protocol is extended to support including a proof of computation when redeeming digital assets to execute a contract. In one embodiment, the proof of computation includes a fixed number of elements and has a fixed length characteristic. Figure 7 shows one such example of how a proof of computation is recorded in a blockchain, where the first data block 702 (e.g., first data block Data1) is divided such that the first data block 702 includes elements corresponding to the proof of computation 704, and these elements are pushed into an alt stack (using a command such as OP_TOALTSTACK) to make space for a signature check against the 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 data block size annotation is purely illustrative.

[0108] Further enhancements are conceivable within the scope of this disclosure. As discussed elsewhere, protocols such as those described herein involve the hash value of the verified key (e.g., HASH160(V K )) and verification key V K It can be enhanced with additional support to read itself and expose both the locking transaction identifier and the worker redeeming transactions, respectively. Thus, an entity that later verifies the legitimacy proof exposed by a worker can do so with the assurance that the key was originally exposed by the client.

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

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] All documents cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as they are individually and specifically described herein, so as to be incorporated by reference.< / signature> < / signature> < / signature> < / hvk1> < / hvk> < / k> < / k> < / signature>

Claims

1. A computer implementation method: A step of obtaining a first script associated with a blockchain transaction, wherein the first script is The first set of commands, One or more cryptographic hash values, Steps including; A step of generating a second script, wherein the second script is The second set of commands, One or more subsets of a plurality of elements, wherein the plurality of elements collectively form 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 the computer system that generates the aforementioned second script, Steps including; The steps include generating a certificate that the computer system has access to the verification key, at least in part on the basis of executing a first set of commands and a second set of commands in connection with the determination that one or more cryptographic hash values ​​match one or more subsets of the verification key; A computer implementation method, including

2. One of the aforementioned elements is a point on an elliptic curve. The computer implementation method according to claim 1.

3. The first set of commands and the second set of commands collectively include instructions for determining whether a first cryptographic hash value among the one or more cryptographic hash values ​​matches the hash output, based at least partially on a subset of the one or more subsets of the verification key. The computer implementation method according to claim 1.

4. The hash output is generated using at least the SHA-256 and RIPEMD-160 cryptographic hash algorithms. The computer implementation method according to claim 3.

5. The step of obtaining the first script is: The steps include identifying one or more subsets of the verification key, The step of calculating a corresponding cryptographic hash value for each subset of one or more subsets of the verification key, wherein the one or more cryptographic hash values ​​include each corresponding cryptographic hash value, The computer implementation method according to claim 1.

6. A step of transferring control of the digital asset that was disrupted by the blockchain transaction to the computer system, subject to verifying the generated certificate, The computer implementation method according to claim 1, further comprising:

7. The process further includes the step of obtaining the first script from a second computer system, wherein the second computer system has contributed at least a portion of the digital assets. The computer implementation method according to claim 6.

8. The aforementioned blockchain transaction is a P2SH transaction. A computer implementation method as described in claim 1.

9. At least one of the one or more subsets of the verification key has a size of 512 bytes or more and a size of 520 bytes or less. The computer implementation method according to claim 1.

10. The first script mentioned above is 58 bytes or larger and 104 bytes or smaller in size. The second script mentioned above is larger than 1628 bytes and smaller than or equal to 1650 bytes. The computer implementation method according to claim 1.

11. The aforementioned blockchain transaction is a standard transaction that conforms to the blockchain protocol. The computer implementation method according to claim 1.

12. Each element of the verification key is within exactly one of the subsets, The computer implementation method according to claim 1.

13. The one or more subsets mentioned above is one subset, and that one subset includes the verification key. The computer implementation method according to claim 1.

14. The first script further includes a public key associated with the computer system, The identifier associated with the computer system is a digital signature generated using a private key corresponding to the public key associated with the computer system, The certificate that the computer system has access to the verification key is at least partially based on the digital signature and the public key, The computer implementation method according to claim 1.

15. In the system, Processor and; A memory containing executable instructions that cause the system to execute the computer implementation method described in any one of claims 1 to 14 as a result of being executed by the processor; A system that includes these features.

16. 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 14.

Images