Random number generation in blockchain

Abstract

The present invention relates to distributed ledger technology, such as consensus-based blockchains. A computer-implemented method for secure random number generation within a blockchain script is described. The present invention is implemented using a blockchain network. A first transaction including a puzzle is verified at a node in the blockchain network, the first transaction being associated with a digital asset, and the solution to the puzzle being undeterminable at the time of verification of the first transaction. A pseudo-random number is generated based at least in part on a solution to the puzzle included in a second transaction, at least in part by verifying the second transaction, the second transaction being created to transfer control of a digital asset associated with the first transaction. Control of the digital asset is transferred based at least in part on the pseudo-random number.

Description

Technical Field

[0001] The present invention relates generally to distributed ledger technology, including blockchain transactions, and more specifically to secure random number generation within blockchain scripts. The present invention also utilizes cryptographic and mathematical techniques to enhance security associated with electronic transfers made over blockchain networks. The present invention is particularly suitable for, but not limited to, use in smart contracts. Background Art

[0002] As used herein, the term "blockchain" may refer to any of several types of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. It should be noted that alternative blockchain implementations and protocols, including non-commercial applications, also fall within the scope of the present invention. For example, the techniques described in this invention will provide advantages for using blockchain implementations.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system consisting of blocks, which in turn can consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured set of field values ​​that includes data and a set of conditions, where the satisfaction of the set of conditions is a prerequisite for writing the set of fields to a blockchain data structure. For example, each transaction is a data structure that encodes a transfer of control of a digital asset between participants in a blockchain system, and the data structure includes at least one input and at least one output.

[0004] In some embodiments, a "digital asset" refers to binary data associated with a right to use. In some embodiments, the digital asset is untokenized, so, for example, there is no identifier identifying the digital asset in the blockchain, but control of the digital asset is proved by the ability to generate a valid transaction recorded on the blockchain. Note, however, that some blockchain implementations may use tokenized digital assets so that, for example, the digital asset can be clearly identified using information recorded on the blockchain. Although in some embodiments, the digital asset can be used as a cryptocurrency, it is contemplated that in embodiments, the digital asset can be used in other environments in addition or alternatively. Note that the present invention, while applicable to control of digital assets, is technical in nature and can be applied in other environments using blockchain data structures without necessarily involving digital asset transfers. As used in the present invention, a "digital asset" may refer to one or more digital assets. For example, a transaction may have multiple inputs, each of which may represent a different digital asset. In this example, the digital asset whose control is transferred may be a collection of multiple digital assets, which is itself a digital asset. Similarly, a transaction may subdivide and / or combine these multiple inputs to produce one or more outputs so that, for example, the number of inputs and the number of outputs may be different.

[0005] In some embodiments, the transfer of control of the digital asset can be performed by reassociating at least a portion of the digital asset from the first entity to the second entity. Each block contains a hash of the previous block so that the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its inception. Transactions contain small programs called scripts that are embedded in the inputs and outputs of the transaction, which specify how and who can access the outputs of the transaction. These scripts are written using a stack-based scripting language.

[0006] In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models and operations. That is, a stack-based scripting language may use a data structure called a stack. Using a stack, values ​​may be pushed to or popped from the top of the stack. Various operations performed on the stack may result in one or more values ​​being pushed or popped from the top of the stack. For example, the OP_EQUAL operation pops the first two items from the stack, compares the two items, and pushes the result (e.g., 1 if equal, 0 if unequal) to the top of the stack. In some scripting languages ​​used in some embodiments, there may be at least two stacks: a main stack and an alternate stack. Some operations of the scripting language may move items from the top of one stack to the top of another stack. For example, OP_TOALTSTACK moves a value from the top of the main stack to the top of the alternate stack. Scripts written using a stack-based scripting language may be pushed into a logical stack, which may be implemented using any suitable data structure (e.g., a vector, a list, or a stack).

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

[0008] One area of ​​current research is the use of blockchain to implement “smart contracts.” Smart contracts are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Unlike traditional contracts written in a natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce results, and then actions can be performed based on those results.

[0009] In an embodiment, although the interaction with a specific entity can be encoded in a specific step of a smart contract, the smart contract can be automatically executed and self-executing. In some examples, automatic execution refers to the successful execution of a smart contract, and the execution of the smart contract is to achieve the transfer of UTXO. Note that in such examples, the "entity" that can cause the transfer of UTXO refers to an entity that can create an unlocking script without proving the knowledge of certain secrets. In other words, the unlocking transaction can be verified without verifying that the data source has access to the encrypted secret (e.g., a private asymmetric key, a symmetric key, etc.). In addition, in such examples, self-execution refers to the verification node of the blockchain network executing the unlocking transaction according to the constraints. In some examples, "unlocking" UTXO refers to creating an unlocking transaction that references UTXO and is effectively executed. Unlocking UTXO may also be referred to as spending UTXO in the art.

[0010] Blockchain transaction outputs include a locking script and information about the ownership of a digital asset. The locking script (also known as an encumbrance) "locks" a digital asset by specifying the conditions that need to be met to unlock the UTXO. For example, a locking script may require certain data to be provided in the unlocking script to unlock the associated digital asset. The locking script is also known as a "scriptPubKey". The technique of requiring a party to provide data to unlock a digital asset involves embedding a hash of the data in the locking script. However, problems arise if the data is undetermined (e.g., unknown and unfixed) when the locking script is created. Summary of the invention

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

[0012] Hence, according to the present invention, there is provided a method and a corresponding system as defined in the appended claims.

[0013] Therefore, it is desirable to provide a computer-implemented method for a node of a blockchain network, the computer-implemented method comprising:

[0014] Verifying a third transaction, the third transaction including the first puzzle and the second puzzle in a third locking script, wherein:

[0015] In a first transaction, the first puzzle is included in a first locking script, the first locking script locks a transfer of control of the first digital asset using a first condition, the first condition being satisfied by a solution to the first puzzle;

[0016] In a second transaction, the second puzzle is included in a second locking script, the second locking script locks the transfer of control of the second digital asset using a second condition, the second condition being satisfied by a solution to the second puzzle;

[0017] The first transaction and the second transaction are submitted to a blockchain; and

[0018] The third transaction is associated with a third digital asset;

[0019] generating a pseudo-random number based at least in part on a solution to the first puzzle and a solution to the second puzzle;

[0020] and

[0021] Control of the third digital asset is transferred based at least in part on the pseudo-random number.

[0022] The first transaction may be created by a first party, and the second transaction may be created by a second party different from the first party. Thus, under the condition that at least one of the first party or the second party remains honest (e.g., does not attempt to corrupt a pseudo-random number generator), a seed derived from a solution to the first puzzle and a solution to the second puzzle may be undeterminable.

[0023] The first party may access the solution to the first puzzle before the first transaction is created. Additionally or alternatively, the second party may access the solution to the second puzzle before the second transaction is created. In this way, both parties do not need to expend too much computing resources because they already know the solution to their respective puzzles.

[0024] The first locking script may include a time constraint. Additionally or alternatively, verification of a transaction including a solution to the first puzzle may cause control of the first digital asset to be transferred to a first entity, conditional upon the time constraint being met. Additionally or alternatively, verification of a penalty transaction may cause control of the first digital asset to be transferred to a second entity different from the first entity, conditional upon the time constraint not being met.

[0025] The time constraint may be to reveal the solution to the first puzzle before a time limit has expired. In this way, the first entity has a reason to provide the solution to the first puzzle within the time constraint, otherwise there is a risk of losing the digital asset to the second entity.

[0026] Verifying the pseudo-random number generation transaction can be performed before the first condition and the second condition are satisfied. Therefore, the pseudo-random number generation transaction can be submitted to the blockchain before the solution is published, thereby ensuring that the pseudo-random number generation transaction will not be manipulated by an entity that knows the solution to the first and second puzzles.

[0027] The first difficult problem may be a cryptographic hash difficult problem.

[0028] The first puzzle may be a set of opcodes in a locking script of the first transaction. Additionally or alternatively, execution of the set of opcodes may evaluate to true as a result of receiving a solution to the first puzzle as input.

[0029] Solving the first puzzle and the second puzzle may be computationally more difficult than verifying a solution to the first puzzle and a solution to the second puzzle.

[0030] Generating the pseudo-random number may include deriving a seed value based at least in part on a solution to the first puzzle and a solution to the second puzzle.

[0031] A seed transaction may be verified, the seed transaction including a solution to the first puzzle and a solution to the second puzzle. In this way, the seed may be undeterminable under the condition that at least one of the first party or the second party remains honest (e.g., does not attempt to corrupt a pseudo-random number generator).

[0032] Transferring control of the third digital asset may include: verification of the seed transaction may succeed under the condition that the pseudo-random number is a first value. Additionally or alternatively, verification of the seed transaction may fail under the condition that the pseudo-random number is a second value different from the first value. In this way, the constraints imposed in the locking script of the pseudo-random number generator may be affected by the pseudo-random number.

[0033] A refund transaction may be verified that returns control of the third digital asset to the entity that created the third transaction.

[0034] A validation refund transaction may occur under the condition that no successful validation of the seed transaction, which contains the solution to the first puzzle and the solution to the second puzzle, occurs within a certain period of time. In this way, the entity that created the third transaction does not suffer a loss of digital assets if the UTXO of the third transaction remains untransferred (e.g., after a certain period of time).

[0035] It is also desirable to provide a system comprising: a processor; and a memory comprising executable instructions, the executable instructions causing the system to perform any of the claimed methods as a result of execution by the processor.

[0036] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon, the executable instructions being executed as a result of one or more processors of a computer system causing the computer system to perform at least any one of the methods claimed.

[0037] Therefore, it is also desirable to provide a computer-implemented method comprising:

[0038] Verifying, at a node in a blockchain network, a first transaction including a puzzle, the first transaction being associated with a digital asset, a solution to the puzzle being undeterminable at the time of verification of the first transaction;

[0039] generating a pseudorandom number at least in part by verifying a second transaction, the second transaction created to transfer control of the digital asset associated with the first transaction, the pseudorandom number being based at least in part on a solution to a puzzle included in the second transaction; and

[0040] Transferring control of the digital asset based at least in part on the pseudo-random number.

[0041] The puzzle may be a cryptographic hash puzzle.

[0042] The puzzle may be a proof-of-work function.

[0043] The puzzle may be a set of opcodes in a locking script of the first transaction. Additionally or alternatively, execution of the set of opcodes evaluates to true as a result of receiving a solution to the puzzle as input.

[0044] Solving the puzzle may be computationally more difficult than verifying the solution.

[0045] Transferring control of the digital asset may include: verification of the second transaction may succeed under the condition that the pseudo-random number is a first value. Additionally or alternatively, verification of the second transaction is unsuccessful under the condition that the pseudo-random number is a second value different from the first value. In this way, the constraints imposed in the locking script of the pseudo-random number generator may be affected by the pseudo-random number.

[0046] The solution may be used, at least in part, to derive a seed for a pseudo-random number generation algorithm in the locking script of the first transaction.

[0047] The locking script can constrain the verification of the second transaction to a specific time frame. In this way, the parties can have a reason to solve the puzzle within the specific time frame.

[0048] Expiration of the particular time frame may enable a designated party to receive control of the digital asset.

[0049] The designated party may be the party that created the first transaction. In this way, the designated party may recover the digital asset if the puzzle is not solved (e.g., after a certain period of time).

[0050] The allocation for solving the puzzle can be larger than the digital asset. In this way, a larger allocation can provide reasons for the parties to solve the puzzle; the larger the allocation proportion of the digital asset, the greater the reasons. In some cases, the size of the allocation may be limited in order to minimize the risk of parties attempting to cheat (e.g., to subvert the pseudo-random number generation transaction and / or the solution).

[0051] The solution may be derived at least in part from a header of a block in the blockchain network.

[0052] When the first transaction is successfully verified, the header may be undeterminable. For example, the header may be the header of a future block at or after a specific time in the blockchain network. Thus, because the future header may be undeterminable when the first transaction is created, it can be guaranteed that the solution is unknown before a specific time.

[0053] It is also desirable to provide a system comprising: a processor; and a memory comprising executable instructions, wherein the executable instructions, as a result of execution of the processor, cause the system to perform any of the methods claimed.

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

[0055] The present invention may be described as a verification method / system, and / or a control method / system for controlling the verification of blockchain transactions. In some embodiments, a verified blockchain transaction results in the transaction being recorded on the blockchain; in some applications, this may result in the exchange or transfer of digital assets through the blockchain. A digital asset is a unit of resources managed by a blockchain. Although in some embodiments, digital assets may be used as cryptocurrencies, it is contemplated that in embodiments, digital assets may be used in other contexts in addition or alternatively. Note that the present invention, while applicable to the control of digital assets, is technical in nature and may be used in other situations that utilize blockchain data structures without necessarily involving the transfer of digital assets. As described below, the present invention may also be described as a security method / system for a new, improved, and advantageous way of performing operations through a blockchain network or platform. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0058] Figure 2 An example of blockchain randomization according to an embodiment is shown;

[0059] Figure 3 An example illustrating the problem of insecure randomization solved by an embodiment is shown;

[0060] Figure 4 An example of a partial commitment solution for generating a seed according to an embodiment is shown;

[0061] Figure 5 An example of a committed solution penalty according to an embodiment is shown;

[0062] Figure 6 An example of implementing a seed transaction to unlock a pseudo-random number generation transaction according to an embodiment is shown;

[0063] Figure 7 An example of returning a digital asset due to expiration of a time limit according to an embodiment is shown;

[0064] Figure 8 A flow chart showing an example of a commitment solution according to an embodiment;

[0065] Fig. 9 An example of a puzzle solving technique for generating a seed according to an embodiment is shown;

[0066] Fig.10 A flowchart illustrating an example of a puzzle solving technique according to an embodiment;

[0067] Fig.11 illustrates an example of randomized smart contract constraints according to an embodiment; and

[0068] Fig.12 A computing environment is shown in which various embodiments may be implemented. DETAILED DESCRIPTION

[0069] First, refer to Figure 1 , Figure 1 An exemplary blockchain network 100 associated with a blockchain according to an embodiment of the present invention is shown. In this embodiment, the exemplary blockchain network 100 includes blockchain nodes implemented as peer-to-peer distributed electronic devices, each node running an instance of software and / or hardware that performs operations that follow a blockchain protocol that is at least partially agreed upon between operators of the nodes 102. In some examples, a "node" refers to a peer-to-peer electronic device distributed in a blockchain network.

[0070] In some embodiments, node 102 may be implemented by any suitable computing device (e.g., by a server in a data center, by a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), by multiple computing devices in a distributed system of a computing resource service provider, or by a computing device such as Fig.12 In some embodiments, the node 102 may be a computing device 1200 of any suitable electronic client device. In some embodiments, the node 102 has an input to receive a data message or object representing a proposed transaction, such as transaction 104. In some embodiments, the node is queryable for information it maintains, such as state information of transaction 104.

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

[0072] As to which nodes 102 can communicate with which other nodes, assuming that the messages are messages that the blockchain protocol indicates should be forwarded, it is sufficient that each node in the exemplary blockchain network 100 is able to communicate with one or more other nodes 102, so that messages passed between nodes can propagate in the exemplary blockchain network 100 (or some significant portion thereof). One such message might be the publication of a proposed transaction by one of the nodes 102 (such as node 102A), which would then propagate along a path such as path 106. Another such message might be the publication of a new block that is proposed for inclusion in the blockchain.

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

[0074] In an embodiment, at least some nodes 102 serve as validation nodes for verifying transactions, as described in the present invention. In some examples, transactions include data that provides proof of digital asset ownership, as well as conditions for accepting or transferring digital asset ownership / control. In some examples, an "unlocking transaction" refers to a blockchain transaction that reassociates (e.g., transfers ownership or control) at least a portion of a digital asset indicated by a UTXO of a previous transaction to an entity associated with a blockchain address. In some examples, a "previous transaction" refers to a blockchain transaction that includes a UTXO referenced by an unlocking transaction. In some embodiments, a transaction includes a "locking script" that encumbers a transaction using conditions that must be met before ownership / control can be transferred ("unlocked").

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

[0076] Certain embodiments of the present invention operate under the assumption that the scripting system or other system for implementing the described instruction set allows more than 200 instructions (e.g., opcodes) in a single script. Likewise, certain embodiments of the present invention further assume that:

[0077] The functionality provided by the opcodes referenced in the present invention is present and enabled in the system executing the opcode script / instruction set; and / or

[0078] The desired functionality can be implemented by creating custom functions that are written to provide the desired behavior. These custom functions are written to implement the functionality of opcodes that existed in the language but have been disabled, or they may be the functionality of "new" opcodes that provide specific functionality not provided by the scripting language itself.

[0079] Examples of opcodes referenced in this disclosure include:

[0080] OP_ECPX, returns the x-coordinate of an elliptic curve point

[0081] OP_ADD, adds the first two items on the stack

[0082] OP_BIGMOD, divides the first two items on the stack and returns the remainder

[0083] OP_BIGMODADD performs a modular addition of the first two items on the stack and the third item on the stack.

[0084] OP_BIGMODINVERSE, performs a modulo negative exponentiation operation

[0085] OP_BIGMODMUL, performs a modular multiplication of the first two items on the stack and the third item on the stack

[0086] OP_CAT, concatenates the first two items in the stack

[0087] OP_CHECKSIG, where, depending on the SIGHASH type, the public key and signature are popped from the stack and verified against the signature of the transaction field. If the signature is valid, 1 is returned, otherwise 0 is returned.

[0088] OP_CHECKSIGVERIFY, which functions the same as OP_CHECKSIG, but then OP_VERIFY executes

[0089] OP_DERENCODE, encodes the first two items in the stack in DER format

[0090] OP_DUP, duplicate the top stack item

[0091] OP_ECPMULT, which performs elliptic curve point multiplication (also known as elliptic curve scalar multiplication) on the first two items on the stack

[0092] OP_ELSE, if the previous OP_IF or OP_NOTIF or OP_ELSE is not executed, these statements will be executed; otherwise, if the previous OP_IF or OP_NOTIF or OP_ELSE is executed, these statements will not be executed

[0093] OP_ENDIF, ends the if / else block

[0094] OP_EQUAL, returns 1 if the inputs are exactly equal, otherwise returns 0

[0095] OP_EQUALVERIFY, which is the same as OP_EQUAL, but then runs OP_VERIFY

[0096] OP_FROMALTSTACK, puts the input on top of the primary stack and removes it from the alternate stack

[0097] OP_HASH256, where the input is hashed twice: first with SHA-256, then with RIPEMD-160

[0098] OP_IF, if the top stack value is not false (False), execute the statement and remove the top stack value

[0099] OP_MUL, multiplies the first two items on the stack

[0100] OP_NOTIF, if the top stack value is false, executes the statement and removes the top stack value OP_ROLL, where the item with a depth of n items in the stack is moved to the top

[0101] OP_SUBSTR, returns part of a string

[0102] OP_SWAP, where the first two items in the stack are swapped

[0103] OP_TOALTSTACK, put the input on the top of the alternate stack and remove it from the main stack

[0104] OP_VERIFY, marks the transaction as invalid if the top stack value is not TRUE

[0105] Figure 2 2 is an example 200 illustrating an embodiment of the present invention. Figure 2 As shown, the example includes a pseudorandom number generator (PRNG) transaction 202 having a locking script 210 that includes a PRNG that generates a random number based on a seed value received as a result of executing an unlocking script 212 of a seed transaction 204 that attempts to unlock the UTXO of the PRNG transaction 202.

[0106] In some embodiments, the PRNG transaction 202 is a blockchain transaction that includes a PRNG in the locking script 210. In some embodiments, a PRNG, also known as a deterministic random bit generator (DRBG), refers to an algorithm that generates a sequence of numbers whose properties approximate the properties of a random number sequence. A PRNG is different from a true random number generator because the sequence depends on an initial seed value. In some embodiments, a PRNG with the same seed value will replicate the same sequence. In some embodiments, the PRNG is encoded in the locking script 210 as a sequence of opcodes that, as a result of execution, produces statistically random (e.g., does not contain a recognizable pattern or regularity) values. The PRNG takes a value as input as a seed to initialize the PRNG.

[0107] In some embodiments, locking script 210 is a script that locks PRNG transaction 202 with conditions to be satisfied (e.g., data provided by unlocking script 212) in order for PRNG transaction 202 to be successfully verified and control / ownership of digital assets associated with PRNG transaction 202 to be transferred. For example, locking script 210 may require certain data to be provided in unlocking script 212 in order to unlock the associated digital assets of PRNG transaction 202. More specifically, a blockchain system (such as a blockchain system in conjunction with Figure 1 The verification node in the blockchain network described in the embodiment of the present invention executes the locking script 210, so that the locking script 210 receives data from the executed unlocking script (e.g., unlocking script 212), performs certain operations based on the data, and returns a result indicating whether the locking script 210 has been successfully "unlocked" (i.e., the set of conditions set in the locking script 210 is satisfied). In the present invention, the locking script 210 also includes a PRNG as described above, which includes as a condition receiving a seed as an input to the PRNG (e.g., as a result of the execution of the unlocking script 212 of the seed transaction 204). In some embodiments, the locking script is encoded to use a random number generated by the PRNG for use in the constraints of the locking script 210.

[0108] In some embodiments, the seed transaction 204 is a blockchain transaction that contains in the unlocking script 212 at least a seed value that can be used by the PRNG in the locking script 210 of the PRNG transaction 202. In some embodiments, the unlocking script 212 is an executable script of the seed transaction 204 that attempts to satisfy a set of conditions placed on the locking script 210 of the PRNG transaction 202. The operating principle of the present invention is that the seed value is undeterminable at the time of creating the locking script 210, and therefore, the value generated by the PRNG based on the seed value is also undeterminable at the time of creating the locking script 210. The present invention describes embodiments that satisfy these conditions.

[0109] Figure 3 An example 300 of the insecure randomness problem solved by an embodiment of the present invention is shown. That is, Figure 2 In the illustrated example 200 , the PRNG 306 is included in a locking script 310 of a first transaction 302 , and a seed 308 of the PRNG 306 is provided via an unlocking script 312 of a second transaction 304 , which is created to unlock / redeem the digital asset associated with the first transaction 302 .

[0110] In some embodiments, the first transaction 302 and the second transaction 304 are field value sets representing the transfer of digital assets in the blockchain network. In some embodiments, the field value set may include inputs and outputs. In some embodiments, the input represents an attempt to unlock the output of the previous blockchain transaction. In some embodiments, after successfully verifying the transaction, the verification node adds the transaction to the blockchain and causes it to be distributed to other nodes of the blockchain.

[0111] In some embodiments, the second transaction 304 is a blockchain transaction created to reassociate (e.g., transfer ownership or control) at least a portion of the digital asset of the first transaction 302 (e.g., as shown in UTXO) to a specific entity. In some embodiments, the first transaction 302 includes a locking script 310 that locks the first transaction 302 with conditions that must be satisfied before ownership / control can be transferred ("unlocked"). In some embodiments, a blockchain address is an alphanumeric string that is associated with an entity to which control of at least a portion of the digital asset is transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between a public key associated with an entity and a blockchain address. In some embodiments, verification of the transaction involves verifying one or more conditions specified in the locking script 310 by executing the unlocking script 312 and the locking script 310 in succession.

[0112] As described above, in some embodiments, PRNG 306 is a pseudo-random number generator that generates a sequence of numbers whose properties approximate the properties of a random number sequence. In some examples, PRNG 306 is a cryptographically secure pseudo-random number generator (CSPRNG), also known as a cryptographic pseudo-random number generator (CPRNG). In some embodiments, PRNG 306 can be any pseudo-random number generator encoded in a locking script according to the above assumptions (including but not limited to Yarrow, Fortuna, and arc4random algorithms).

[0113] In some embodiments, the locking script 310 is a script that locks a blockchain transaction by specifying conditions that need to be met (i.e., "unlocking") in order to transfer control of at least a portion of the digital assets associated with the transaction. More specifically, the execution of the locking script 310 is used (as a result of execution by a validating node of the blockchain system) to accept data from an executed unlocking script (e.g., unlocking script 312), perform certain operations based on the data, and return a result indicating whether the execution of the unlocking script successfully "unlocked" the locking script 310, where "unlocking" means satisfying the set of conditions set in the locking script 310. In some embodiments, the locking script 310 defines one or more data constraints that must be met (e.g., data provided by the unlocking script) in order to successfully verify the transaction. For example, the locking script 310 may require certain data to be provided in the unlocking script 312 in order to unlock the relevant digital assets associated with the first transaction 302.

[0114] In some embodiments, seed 308 is a number or vector used to initialize a pseudo-random number generator, such as PRNG 306. However, since seed 308 determines the pseudo-random numbers generated by PRNG 306, Figure 3 As can be seen, the entity 314 that provides the seed 308 to the PRNG 306 can manipulate the output of the PRNG 306. However, the present invention proposes two solutions as a defense against seed manipulation. The first solution is a commitment solution, in which the seed is a combination of two or more puzzle solutions, each of which is known to a separate party. However, before creating a PRNG transaction, each party submits a certain amount of digital assets to the puzzle transaction, which can be recovered by revealing the solution to the puzzle in the solution transaction. In some embodiments of the commitment solution, failure to reveal the puzzle solution will result in the digital assets submitted by the defaulting party being confiscated by the party or parties that reveal their puzzle solution. In some of these embodiments, each puzzle solution must be revealed within a certain period of time, otherwise the party will be deemed to have violated its commitment. In this way, each party can have a reason to contribute to the seed of the PRNG. With the commitment solution, each party that generates the puzzle transaction is allowed to know the corresponding solution to the puzzle in advance. In the puzzle solution technology, the seed is the solution to the puzzle transaction. When the puzzle is created, the solution is unknown, but the party that solves the puzzle can collect the allocation of digital assets associated with the puzzle transaction.

[0115] In some examples, a "puzzle" refers to a set of logical expressions using one or more opcodes in a scripting language that evaluate to true as a result of execution if a specific numeric "solution" is used as input. Puzzles can have various difficulties, which can affect the time required to solve the puzzle. Puzzles can also have the characteristic that obtaining a solution (i.e., solving the puzzle) is computationally more difficult than verifying that the solution is correct. An example of a puzzle is a cryptographic hash puzzle, where the puzzle is to find a number that, when combined (e.g., added, multiplied, appended, etc.) with a specified number and then processed by a given cryptographic hash algorithm (e.g., SHA256, MD5, BLAKE, BLAKE2, etc.), produces a value containing a specific number (e.g., five leading zeros, "1234", etc.). In some examples, a cryptographic hash puzzle is a problem created or solved using a cryptographic hash algorithm, e.g., a problem defined by a function that includes at least one cryptographic hash algorithm and a set of conditions, and the solution to the puzzle is a set of inputs to the function that produces an output that satisfies the set of conditions.

[0116] Note that in an embodiment, a cryptographic hash function or one-way function h(x)=y is used to generate the hash, where for a given x, y is easy to compute, but for a given y, it is computationally difficult to compute x. In some cases, the solution may be a digital signature or other data of one party, which, if provided as input to a locking script holding the puzzle via an unlocking script, results in the locking script evaluating to true as a result of the execution of the unlocking script and the locking script.

[0117] In some examples, computational difficulty refers to a complexity class in the field of computational complexity theory. For example, digitally signing a message using a Merkle signature scheme may involve performing 2r cryptographic hash operations as part of generating a correct solution, where r is the depth of the generated Merkle tree. Conversely, verifying that the signing key used to generate the digital signature is a leaf node of the Merkle tree may involve performing r cryptographic hash operations to verify the authentication from the leaf node (corresponding to the signing key) to the root node. It can be seen that performing 2r cryptographic hash operations is computationally more difficult than performing r cryptographic hash operations (e.g., spending more CPU cycles, using more memory / storage space, etc.). As a second example, the system can generate two prime numbers and provide the product of the prime numbers as a difficult problem, the solution of which is to decompose the provided product.

[0118] It should be noted that the phrase "one-way function" includes functions that are not necessarily one-way in the strict mathematical sense, but which exhibit properties that make the function useful in the context of applying the various techniques of the present invention (e.g., collision resistance, resistance to preimage attacks, and resistance to second preimage attacks). Thus, an entity that has the output of the function but does not have access to the corresponding input may not be able to determine the input without, for example, a significant expenditure of computing resources required by a cryptographic (e.g., brute force) attack. One-way functions (also referred to as "effectively one-way functions") include, but are not limited to, cryptographic hash functions such as message authentication codes (e.g., hash-based message authentication codes (HMACs)), key derivation functions such as PBKDF2 and bcrypt (e.g., whose cryptograms are based at least in part on plaintext and an encryption key), and other secure randomization functions, which may, but need not, have a domain (the set of possible inputs) greater than their range (possible outputs). A value may be cryptographically derived using a one-way function. A cryptographic function may be a one-way function (or may be a component of a one-way function) from the perspective of an entity that lacks information used as an input to the cryptographic function (e.g., a cryptographic key and / or salt). In some examples, "cryptographically derived" refers to using a one-way function at least once, using a value or deriving an input from a value (possibly cryptographically derived from a value). For example, an encryption operation is a "one-way" operation on an entity that does not have a decryption key.

[0119] Figure 4 An example embodiment 400 of the present invention is shown. Specifically, Figure 4 The first stage of a committed solution for seed generation is described. The committed solution described in the example embodiment 400 involves at least two parties 406A-06B providing solutions 408A-08B that can be combined to derive a seed for a PRNG. The committed solution provides an advantage in that because the solutions 408A-08B are combined together, the consent of all parties is required to manipulate the seed; that is, as long as one party provides a solution that is not known in advance by the other party, the final seed will be unknown before generation.

[0120] In the commitment solution, each party 406A-06B (p∈{0,1,…,v}) creates a separate commitment transaction 402A-02B, where the puzzle 410A-10B is included as a constraint in the transaction's respective locking script. In some embodiments, each commitment transaction is associated with a constraint (δ p ←Verify(puzzle p ,π p ))'s locking script locks a certain amount of digital assets (e.g. x p ) is associated with pis a proposed solution to a puzzle for party p. In some embodiments, the constraint is also time-bound, meaning that the party must reveal the solution within a specific time period or risk having the submitted digital assets confiscated. In some embodiments, digital assets are submitted from the party's own reserves. In other embodiments, digital assets are provided as potential allocations by a third party (e.g., a party attempting to generate random numbers from a seed determined by the parties 406A-06B). In some embodiments, the digital assets are provided by a third party (e.g., a party attempting to generate random numbers from a seed determined by the parties 406A-06B) from a PRNG transaction (such as Figure 6 The creator of the PRNG transaction 610), or a commitment of allocation from some other entity interested in creating seeds for pseudo-random number generation, provides the parties 406A-06B with a reason to participate in the creation of the seeds.

[0121] Each party (p) in the parties 406A-06B can reveal the Commitment Transaction puzzle (π) by creating a solution transaction using the unlocking script p ←Puzzle solution p ), thereby unlocking the UTXO of their respective commitment transactions, which unlocks the locking script of the corresponding commitment transaction. As can be seen from the example embodiment 400, the solution transactions 404A-04B include the solutions 408A-08B to their corresponding puzzles 410A-10B. Therefore, verification of the solution transactions 404A-04B allows the parties 406A-06B to recover the UTXO of their respective commitment transactions 402A-02B.

[0122] In some embodiments, commitment transactions 402A-02B are blockchain transactions, similar to Figure 3 The first transaction 302 has digital assets submitted by corresponding parties 406A-06B. In some embodiments, the solution transactions 404A-04B are blockchain transactions, similar to Figure 3 The second transaction 304 is created by the parties 406A-06B to "unlock" the UTXO of their respective commitment transactions in order to redeem the submitted digital assets.

[0123] In some embodiments, the parties 406A-06B have agreed to be PRNGs (e.g. Figure 6The PRNG in the time limit constraint 610 of the present invention provides entities of the puzzle 410A-10B and solution 408A-08B used in seed generation. The puzzle 410A-10B does not have to be complex. For example, one party 406 may know the result of a cryptographic hash of a known "letters", and may create a puzzle 410A to cryptographically hash an input and compare the cryptographically hashed input with the known cryptographic hash of "letters". If the hashed input matches the known hash result, then the input is a correct solution to the puzzle 410A. In this case, the solution is the letters "letters", which is known to the first party 406A and which may be used as the first solution 408A input to solve the unlocking script of the transaction 404A. However, other parties that examine the cryptographic hash in the locking script are unlikely to directly recognize that the solution is the letters "letters. Although only two parties are depicted in the example 400, it is contemplated that any number of parties may participate in providing puzzles and solutions as long as there are at least two parties.

[0124] In some embodiments, solutions 408A-08B (similar to Figure 6 The solutions 608 of the present invention are values ​​that can be combined to derive a seed for a PRNG (e.g., the PRNG in the time limit constraint 610). Individually, each of the solutions 408A-08B is a value that, if provided as an input to the locking script of the commitment transaction 402A-02B containing the puzzle 410A-10B through the unlocking script of the solution transaction 404A-04B, will cause the execution of the corresponding unlocking and locking scripts to evaluate to true. Providing a seed to the PRNG causes the execution of the PRNG to generate a random number that can be used in a variety of ways in the smart contract, some examples of which are shown in Tables 2 and 3 below. In some embodiments, at least one of the parties 406A-06B knows or otherwise has access to the solution to its respective puzzle when the associated commitment transaction is created. In other embodiments, all parties 407A-06B know or otherwise have access to the solution to their respective puzzle 410A-10B when their associated commitment transaction 402A-02B is created.

[0125] You can submit a value (such as x p ) and PRNG transaction values ​​(e.g. Figure 6 and 7 y) to prompt the parties 406A-06B to reveal their respective puzzle solutions 408A-08B. For example, if x p >>y, then the parties 406A-06B will have good reason to reveal their solutions 408A-08B, because they face losses far greater than enforcing a refund transaction (e.g. Figure 7 The risk of potential revenue resulting from the refund transaction 704).

[0126] In some embodiments, puzzles 410A-10B are algorithms that include a sequence of operations, such as a sequence of opcodes in a scripting language, executed on one or more inputs that return an indication of true or false. For example, if solution 404A is a valid solution to puzzle 410A, then the execution of puzzle 410 in the locking script of commitment transaction 402A may evaluate to true (assuming any other constraints present in commitment transaction 402A are also satisfied). However, if the proposed solution to puzzle 410A is an invalid solution, then the execution of puzzle 410A in the locking script of commitment transaction 402A evaluates to false.

[0127] Figure 5 An example 500 of the consequences of failing to provide a valid solution for a commitment transaction within a specific time frame is shown. Specifically, Figure 5 Depicts the first party 506A at time limit 516 (t c ) before the expiration of the first commitment transaction 502A. a ) provides a solution. On the other hand, the second party 506B does provide a solution to the corresponding puzzle 510B (σ ) in the commitment transaction 502B created by the second party 502B within the time limit 516. b ) provides understanding 508(π b ). Thus, as a result of the verification of the penalty transaction 504A, the second party 506B is able to claim the digital asset (x a ) ownership.

[0128] In some embodiments, commitment transactions 502A-02B are similar to Figure 4 Similarly, in some embodiments, puzzles 510A-10B are similar to puzzles 410A-10B. In some embodiments, solution transaction 504 is similar to Figure 4 Similarly, in some embodiments, solution 508 is similar to Figure 4 In some embodiments, the parties 506A-06B are similar to Figure 4 The parties 406A-06B are entities.

[0129] In some embodiments, penalty transaction 514 is a blockchain transaction that can be verified to unlock the UTXO of commitment transaction 502A under the condition that the UTXO of commitment transaction 502A remains untransferred after time limit 516. Because first party 506A has submitted a portion of digital assets to commitment transaction 506A, penalty transaction 514 exists to prevent first party 506A from failing to reveal the solution to puzzle 510A, because if first party 506A fails to reveal its solution, then one or more other parties (e.g., second party 506B) that have made commitment transactions can claim any digital assets that first party 506A has submitted to first commitment transaction 502A. In this way, both parties 506A-06B can commit to revealing the solution to their respective puzzles 510A-10B, otherwise both parties 506A-06B face the risk of losing their submitted digital assets. In addition, due to the possibility that the other party failed to reveal its solution, each party 506A-06B has further reason to reveal the solution of its respective puzzle 510A-10B, thereby allowing the non-breaching party to not only recover their own submitted digital assets, but also to be rewarded with at least a portion of the digital assets submitted by their breaching party. This is the situation shown in example 500, where the second party 506B profits from revealing the solution 508 and receives a distribution from the penalty transaction 514.

[0130] In some embodiments, the time limit 516 is a deadline enforced in the locking script of the commitment transaction 502A. That is, in some embodiments, the locking script of the commitment transaction 502A-02B is used to limit the entity that is allowed to unlock the UTXO of the commitment transaction 502A-02B to only the creator of the respective commitment transaction until the time limit 516 encoded into the locking script expires. However, in some embodiments, the locking script can be used to allow one or more other parties (such as the second party 506B) to claim the UTXO of the commitment transaction after the time limit 516 expires, and does not allow the creator of the commitment transaction 502A to claim the UTXO of the commitment transaction 502A. In some embodiments, the commitment transaction 502A-02B must include the time limit 516 in its locking script in order to be verified. In this way, the penalty transaction 514 can be used as a penalty to give the parties 506A-06B a reason to provide their puzzles 510A-10B with a timely solution.

[0131] Figure 6 Another example embodiment 600 of the present invention is shown. Specifically, Figure 6 Depicts the second stage in the commitment solution for seed generation, which can be compared with Figure 4 That is, PRNG transaction 602 is created by an entity that attempts to impose a random constraint on the transfer of control of digital asset y. Therefore, the locking script of PRNG transaction 602 is composed of PRNG and time limit constraints 610σAll ←∧σ p The locking script and code of the seed transaction 604 are locked to solve the puzzle in the unlocking script {π a ,…,π b} into a solution π, where the locking script (e.g., π←Combine({π a ,…,π n The seed for the PRNG in})) can be derived from the solution π. That is, in some cases, the solution π itself can be used as a seed, while in other cases, the solution π can be hashed or otherwise manipulated into a value that can be used as a seed by the PRNG. The time limit constraint 610 can be constrained in a variety of ways. For example, there can be one or more opcodes in the locking script of the PRNG transaction 602 that, when executed, check the current time against a specified expiration time.

[0132] In example embodiment 600, seed transaction 604 is a blockchain transaction created to unlock the UTXO of PRNG transaction 602. In some embodiments, to prevent manipulation of the PRNG, a seed transaction (e.g., Figure 4 PRNG transaction 602 is created after commitment transactions 402A-02B) are submitted to the blockchain but before solution transactions (e.g., solution transactions 404A-04B) are created. In some embodiments, seed transaction 604 is created after all solutions to the puzzles (e.g., solutions 408A-08B) have been submitted to the blockchain or otherwise made available to the creator of seed transaction 604. In some embodiments, seed transaction 604 includes solutions 608(π) to various puzzles in its unlocking script, such as Figure 4 Solution 408A-08B to puzzle 410A-10B.

[0133] In some embodiments, each solution 608 is listed separately and combined by the execution of the locking script of the PRNG transaction 602. In other embodiments, each solution 608 is combined together in the unlocking script of the seed transaction 604 in a manner supported by the locking script of the PRNG transaction 602. If all solutions 408A-08B are provided in the unlocking script of the seed transaction 604, then the locking script of the PRNG transaction 602 can evaluate to true. Alternatively, in some embodiments, if no solution 408A-08B is provided before the time limit expires, then Figure 7 As shown, the digital asset y is refunded.

[0134] In one example, an entity has a group of parties create a Figure 4 The entity then creates a PRNG transaction 602 using puzzles 410A-10B incorporated into time constraints 610. That is, Figure 4 In the simplified two-party example of exemplary embodiment 400 of , if first party 406A reveals first solution 608A before creating PRNG transaction 602, second party 406B, which already knows second solution 408B and just knows first solution 408A, can potentially determine the result of the PRNG in the locking script of PRNG transaction 602. Therefore, in order to protect the unpredictability of the PRNG result, solutions 408A-08B should not be revealed before PRNG transaction 602 is created.

[0135] In some embodiments, the entity may also create a penalty transaction for each of the commitment transactions 401A-02B, similar to Figure 5 Penalty transaction 514. In addition, in some embodiments, the entity may additionally or alternatively create a refund transaction (similar to Figure 7 A refund transaction 704) is provided to ensure that the entity does not forfeit the digital asset y without providing one or more solutions 408A-08B.

[0136] Figure 7 Another example 700 of the consequences of a party failing to provide a valid solution to a commitment transaction within a specific time frame is shown. Specifically, Figure 7 Describes a party's failure to provide All In the case of a solution to one of the problems in Figure 5 Therefore, at time 716t c After +Δt, the digital asset y associated with the PRNG transaction 702 can be redeemed via a refund transaction 704.

[0137] In some embodiments, PRNG transaction 702 is similar to Figure 6 PRNG transaction 602. As shown in example 700, in some embodiments, the PRNG transaction 702 is encoded to be c ) to prevent a party from waiting until just before PRNG transaction 702 expires to reveal its solution, as doing so would compromise the ability to create a seed transaction (e.g., seed transaction 604) in time to unlock the UTXO of PRNG transaction 702.

[0138] In some embodiments, refund transaction 704 is a blockchain transaction that is created to repay / reclaim the digital asset associated with PRNG transaction 702 if digital asset y remains unclaimed after time 716t+Δt (e.g., by verifying a seed transaction containing a solution to the puzzle 710). In an example, refund transaction 704 is created by the creator of PRNG transaction 702 to ensure that the creator can get back digital asset y if a solution to the puzzle 710 is not found. However, in some examples, the creator of PRNG transaction 702 and the creator of refund transaction 704 need not be the same party. In some embodiments, time 716 is a time limit set for the amount of time allowed for PRNG transaction 702 to provide a solution.

[0139] Figure 8 800 for generating random numbers according to various embodiments of the commitment solution of the present invention. Some or all of process 800 (or any other process described, or variations and / or combinations of these processes) can be performed under the control of one or more computer systems configured with executable instructions and / or other data, and can be implemented as executable instructions that are executed together on one or more processors. The executable instructions and / or other data can be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium).

[0140] For example, some or all of process 800 may be performed by one or more computing devices (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by a server such as ... Fig.12 The process 800 includes a series of operations in which two puzzles are integrated into a locking script of a PRNG transaction, the solutions to the puzzles are integrated into an unlocking script of a seed transaction after the PRNG transaction is submitted to the blockchain, the PRNG in the locking script of the PRNG transaction is executed based on using a seed derived from the solution to generate a pseudo-random number, and constraints are imposed based on the generated pseudo-random number.

[0141] At 802, one or more problems (such as Figure 4 In one embodiment, the puzzle may be obtained from the script of a commitment transaction (such as commitment transactions 402A-02B). As described above, the puzzle may be a collection of logical expressions using one or more opcodes in a scripting language. The puzzle is such that if a solution to the puzzle is received as input, the puzzle algorithm / logical expression evaluates to true as a result of execution. The puzzle may be a cryptographic hash puzzle, a proof-of-work puzzle, or some other puzzle that has a numerical solution.

[0142] At 804, after the commitment transaction has been submitted to the blockchain, the puzzle obtained at 802 is combined with a PRNG transaction (such as Figure 6 PRNG transaction 602) in such a way that solutions to the puzzle (such as solution 408A-08BB) can be received as input and combined to derive a value that can be used as a seed for the PRNG to generate pseudo-random numbers.

[0143] At 806, after determining that the PRNG transaction has been submitted to the blockchain, execution of process 800 proceeds to 808. At 808, once the PRNG transaction has been submitted to the blockchain, from such Figure 4 The solution to the puzzle incorporated in the PRNG transaction is obtained from the solution 408A-08B. In some embodiments, the solution is obtained over a period of time t c Afterwards (for example, Figure 7 to allow the parties sufficient time to provide their solutions.

[0144] At 810, it is determined whether the time limit (e.g., Figure 7 The solution of all puzzles incorporated into the locking script of the PRNG transaction is obtained within t+Δt in t+Δt). If all solutions cannot be obtained, execution of process 800 proceeds to 812, whereupon the penalty transaction can be verified to refund the digital assets associated with the PRNG transaction (such as in Figure 7 Otherwise, if all solutions are obtained within the time limit, execution of process 800 proceeds to 814.

[0145] At 814, the solution is incorporated into the unlocking script of the seed transaction, such that at 816, execution of the combination of the unlocking script and the locking script causes the solution to be converted into a seed value (e.g., combining the solution value and performing a SHA256 hash operation on the combined solution value), which seed value is used as an input to the PRNG in the locking script, causing the PRNG to generate a pseudo-random number. At 818, the pseudo-random number can be used to affect constraints on the locking script of the PRNG transaction. That is, based on the pseudo-random number generated by the PRNG in the PRNG locking script, the transfer of control of the digital asset associated with the PRNG transaction is constrained in some manner (e.g., the pseudo-random number of the signature accepted, the validity of the signature based in part on whether the pseudo-random number is within a certain range of values, whether the pseudo-random number of the digital asset is transferred, etc.), such as in conjunction with Fig.11 Note that one or more of the operations performed in 802-18 may be performed in various orders and combinations, including in parallel.

[0146] Fig. 9 An example embodiment 900 of the present invention is shown. Specifically, Fig. 9An example of a puzzle solving technique for seed generation is described. Figure 4-8 The described commitment solutions involve two or more committers, but the puzzle solution technique described in the example embodiment 900 requires only one puzzle solution 908, which can be used to derive the seed for the PRNG transaction 902.

[0147] In some embodiments, the PRNG transaction 902 is associated with a digital asset y that is locked by a locking script with a constraint (σ←Verify(puzzle,π)), which can be unlocked (e.g., evaluated to true) if there is a valid solution (π←puzzle solution) to the puzzle 910 in the unlocking script of the seed transaction 904. In some embodiments, the locking script of the PRNG transaction 902 also includes a time limit within which the PRNG transaction 902 can be transferred. That is, in such embodiments, if the valid seed transaction 904 is not verified within a specific time frame (e.g., before the time limit expires), the digital asset y can be transferred by the creator of the PRNG transaction 902 or, in some embodiments, by another party through a process similar to Figure 7 The refund transaction shown is 704 to restore the refund transaction.

[0148] In the puzzle solution technique of example embodiment 900, the puzzle solution 908 of puzzle 910 is unknown to the parties to the transaction when the PRNG transaction 902 is created. In some embodiments, the PRNG transaction 902 is associated with an allocation (e.g., a portion of a digital asset) that is transferred to the first party to provide the puzzle solution 908, thereby providing the parties with a reason to attempt to discover the puzzle solution 908 of puzzle 910. In some cases, the allocation is an allocation outside the blockchain (e.g., real currency). In other cases, the allocation is a portion of digital asset y. In other cases, the allocation is a portion of a digital asset of another transaction. In some embodiments, the allocation is greater than digital asset y, so as to provide a reason to reveal the puzzle solution 908.

[0149] In some embodiments, puzzle 910 is an algorithm that includes a sequence of operations (e.g., a sequence of opcodes in a scripting language) that, if executed on one or more inputs, returns an indication of true or false. For example, in an embodiment, if puzzle solution 908 is a valid solution to puzzle 910, then execution of a locking script of a PRNG transaction 902 containing puzzle 910 will evaluate to true. However, in some embodiments, if puzzle solution 908 is invalid, then execution of the locking script will evaluate to false. A limitation of puzzle solving techniques is that, in this embodiment, the puzzle solution 908 of puzzle 910 is unknown or undeterminable at the time puzzle 910 is created. In some examples, puzzle 910 is computationally complex (e.g., involving a certain amount of time and / or processing power exceeding a threshold) such that a solution to the puzzle cannot be determined before a certain time after PRNG transaction 902 is created.

[0150] An example of a puzzle 910 is a proof-of-work function, such as a cryptographic hash of a future block header of a blockchain at a specific time. Because it becomes increasingly difficult to predict future block headers of a blockchain the further into the future a specific time is, it is unlikely that the parties to the transaction will know the puzzle solution 908 of the puzzle 910 when the PRNG transaction 902 is created and the allocation is associated with providing proof-of-work. Note that future block headers can be specified in a variety of ways. For example, the solution can be the hash of the first block header created after a specified date / time in the future. As another example, a future block header can be specified as the first future block header that contains a specific number of transactions in the block. Therefore, a proof-of-work puzzle for a future block header is an example of a constraint that satisfies a puzzle solution technique.

[0151] Access to future block headers can be enforced by implementing constraints on data in the unlocking script to require that the unlocking script include a block header, a blockchain, or a chain of block headers. By implementing such constraints on the data in the unlocking script, and by injecting such data into the unlocking script at runtime, transactions can be based on various aspects of the blockchain. For example, a block header can be included as data in the unlocking script of a potential seed transaction, and an opcode sequence can be executed in the locking script to verify that the data is a valid block header (e.g., the size of the script is 80 bytes, the nBits field of the data is equal to or greater than the blockchain difficulty, and verify that SHA256 is less than or equal to a target value), such as the script shown in Table 1 below.

[0152] Table 1:

[0153]

[0154] In some embodiments, seed transaction 904 is a transaction created to provide a value that can be used in a PRNG transaction 902 locking script to derive a seed for the PRNG, in the form of a puzzle solution 908. In some embodiments, puzzle solution 908 is a value that, if provided as an input to puzzle 910 via the unlocking script of seed transaction 904, causes the locking script of PRNG transaction 902 to evaluate to true as a result of execution. Providing a seed to the PRNG also causes the PRNG to execute to generate random numbers. In one embodiment, solving puzzle 910 is associated with a distribution (e.g., at least a portion of a digital asset associated with PRNG transaction 902) as a reason to reveal a solution. In this way, a party that solves puzzle 910 can be provided with a reason to avoid withholding solution 908, because doing so will increase the likelihood that the other party will solve puzzle 910 and claim the distribution first.

[0155] Fig.10 A flow chart illustrating an example of a process 1000 for generating random numbers according to various embodiments of the puzzle solving techniques of the present invention is shown. Some or all of the process 1000 (or any other process described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions that execute together on one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium).

[0156] For example, some or all of process 1000 may be performed by one or more computing devices (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computing resource service provider, or by a server such as ... Fig.12 The process 1000 may be executed by any suitable electronic client device of the computing device 1200 of the embodiment of the present invention. The process 1000 includes a series of operations in which a PRNG transaction including a puzzle is verified, and a seed transaction causes a seed to be provided to the PRNG in a locking script of the PRNG transaction. The execution of the PRNG generates a pseudo-random number. Constraints are imposed on the transaction based on the generated pseudo-random number.

[0157] At 1002, a PRNG transaction (e.g. Fig. 9In one embodiment, the PRNG transaction includes a puzzle similar to puzzle 910 that has a solution that is unknown when the PRNG transaction is created. For example, in some embodiments, the solution to the puzzle involves data that is available or determinable only after a certain time has passed since the PRNG transaction was created. At 1004, after the PRNG transaction has been submitted to the blockchain network, a seed transaction containing a solution to the puzzle in the unlocking script (e.g., puzzle solution 908) is obtained by the same or different validating node in the blockchain network.

[0158] At 1006, the same or a different verification node executes the unlocking script of the seed transaction, which makes the solution available as an input to the locking script of the PRNG transaction. The verification node then executes the locking script of the PRNG transaction, which takes the solution as input and derives a value based on the solution that the PRNG can use to generate pseudo-random numbers. At 1008, the pseudo-random number is used to affect the constraints of the locking script of the PRNG transaction. That is, based on the pseudo-random number generated by the PRNG in the PRNG locking script, the transfer of control of the digital asset associated with the PRNG transaction is constrained in some manner (e.g., the pseudo-random number of an accepted signature, the validity of the signature being based in part on whether the pseudo-random number is within a certain range of values, whether a pseudo-random number of digital assets is transferred, etc.), such as in conjunction with Fig.11 Note that one or more of the operations performed in 1002-18 may be performed in various orders and combinations, including in parallel.

[0159] Fig.11 An example 1100 of how to implement the PRNG of the embodiments described in the present invention is shown. Specifically, Fig.11 An example of a locking script in a PRNG transaction 1102 is depicted, which randomly produces one of two results due to being seeded in the manner described in the above embodiments. Note that although Fig.11 Only two possible outcomes are depicted, but the actual number of possible outcomes and the probability of each outcome can be determined by the creator of the PRNG transaction 1102 and encoded in the locking script of the PRNG transaction 1102. Therefore, there are many possible outcomes and probabilities. In the first possible outcome described in example 1100, the random outcome 1106A is that the first transaction 1104A attempting to unlock the UTXO of the PRNG transaction 1102 is successfully verified, but the second transaction 1104B attempting to unlock the UTXO of the PRNG transaction 1102 is unsuccessful in verification. In the second possible outcome, the random outcome 1106B is that the first transaction 1104A attempting to unlock the UTXO of the PRNG transaction 1102 is unsuccessful in verification, but the second transaction 1104B attempting to unlock the UTXO of the PRNG transaction 1102 is successfully verified.

[0160] In some embodiments, PRNG transactions 1102 are similar to combining Figure 6 and 9 PRNG transaction 602 or PRNG transaction 902 described above. In some embodiments, the first and second transactions 1104A-04B are similar to Figure 6 and 9 1102. That is, each of the first and second transactions 1104A-1104B may include one or more solutions to one or more puzzles included in the locking script of the PRNG transaction 1102. However, because the seed for the pseudo-random number generator is derived from the solution provided to the locking script, even though the first transaction 1104A and the second transaction 1104B may both include the same solution, the result (in the example 1100, determining which transaction is successfully verified) is pseudo-random. For example, the locking script may be encoded to accept Alice's signature on values ​​from the pseudo-random number generator greater than 5, while accepting Bob's signature on values ​​from the pseudo-random number generator less than or equal to 5.

[0161] In some embodiments, random results 1106A-06B reflect the results of a PRNG of a locking script of PRNG transaction 1102 that has been seeded with one or more puzzle solutions. The following table illustrates several examples of using a PRNG-generated random number in a locking script to determine a set of constraints. Table 2 shows an example of using a random number generator of the type described in this invention to determine a set of constraints:

[0162] Table 2:

[0163]

[0164] In the above table, a random number is generated based on a seed (e.g., a value derived from a value in stack memory after executing an unlocking script), which is constrained to a value between 1 and 3 by performing a modulo 3 operation and adding 1. Using the random number on the stack, the OP_CHECKMULTISIG operation checks the number of signatures equal to the random number on the stack. Table 3 shows another example of determining a constraint set using a random number generator of the type described in this invention:

[0165] Table 3:

[0166]

[0167] In the table above, like the previous script, a random number is generated based on a seed. In this case, the value is constrained to be in the range of 0 to 1. If the random number is 1, then it is determined to check Alice's valid signature (e.g., associated with PubK A), while if the random number is 0, then it is determined to check Bob's valid signature (e.g., associated with PubK B).

[0168] Note that in the context of describing the disclosed embodiments, unless otherwise specified, the use of expressions referring to executable instructions (also referred to as code, application, agent, etc.) that perform operations that are not typically performed independently (e.g., transfer of data, computation, etc.) indicates that the instructions are being executed by a machine, causing the machine to perform the specified operations.

[0169] Fig.12 1 is a schematic simplified block diagram of a computing device 1200 that can be used to practice at least one embodiment of the present invention. In various embodiments, the computing device 1200 can be used to implement any of the systems shown and described above. For example, the computing device 1200 can be used as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Fig.12 As shown, the computing device 1200 may include one or more processors 1202, which in an embodiment are used to communicate with and operably connect to a plurality of peripheral subsystems via a bus subsystem 1204. In some embodiments, these peripheral subsystems include a storage subsystem 1206, which includes a memory subsystem 1208 and a file / disk storage subsystem 1210, one or more user interface input devices 1212, one or more user interface output devices 1214, and a network interface subsystem 1216. Such a storage subsystem 1206 may be used for temporary or long-term storage of information.

[0170] In some embodiments, bus subsystem 1204 provides a mechanism for enabling various components and subsystems of computing device 1200 to communicate with each other as expected. Although bus subsystem 1204 is schematically shown as a single bus, alternative embodiments of the bus subsystem use multiple buses. In some embodiments, network interface subsystem 1216 provides an interface for other computing devices and networks. In some embodiments, network interface subsystem 1216 is used as an interface for receiving data from computing device 1200 and sending data from computing device 200 to other systems. In some embodiments, bus subsystem 1204 is used to transmit data such as detailed information, search terms, etc.

[0171] In some embodiments, user interface input devices 1212 include one or more user input devices (e.g., keyboards); pointing devices (e.g., integrated mice, trackballs, touchpads, or graphics tablets); scanners; barcode scanners; touch screens incorporated into displays; audio input devices (e.g., voice recognition systems, microphones); and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computing device 1200. In some embodiments, one or more user interface output devices 1214 include a display subsystem, a printer, or a non-visual display such as an audio output device. In some embodiments, the display subsystem includes a cathode ray tube (CRT), a flat panel device (e.g., a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computing device 1200. For example, one or more user interface output devices 1214 may be used to present a user interface to facilitate user interaction with an application that performs the processes and variations described therein (when such interaction may be appropriate).

[0172] In some embodiments, the storage subsystem 1206 provides a computer-readable storage medium for storing basic programming and data structures that provide the functionality of at least one embodiment of the present invention. In some embodiments, when executed by one or more processors, applications (programs, code modules, instructions) provide the functionality of one or more embodiments of the present invention and, in embodiments, are stored in the storage subsystem 1206. These application modules or instructions can be executed by one or more processors 1202. In various embodiments, the storage subsystem 1206 additionally provides a repository for storing data used in accordance with the present invention. In some embodiments, the storage subsystem 1206 includes a memory subsystem 1208 and a file / disk storage subsystem 1210.

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

[0174] In some embodiments, computing device 1200 includes at least one local clock 1224. In some embodiments, local clock 1224 is a counter that represents the number of ticks that have elapsed since a particular start date, and in some embodiments, local clock 1224 is integrally located within computing device 1200. In various embodiments, local clock 1224 is used to synchronize data transfers among computing device 1200 processors and subsystems included therein at specific clock pulses, and can be used to coordinate synchronization operations between computing device 1200 and other systems in a data center. In another embodiment, the local clock is a programmable interval timer.

[0175] The computing device 1200 may be any of a variety of types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 1200 may include another device, which in some embodiments may be connected to the computing device 1200 via one or more ports (e.g., USB, headphone jack, lightning connector, etc.). In an embodiment, such a device includes a port for accepting a fiber optic connector. Thus, in some embodiments, the device is used to convert an optical signal into an electrical signal that is transmitted through a port connecting the device to the computing device 1200 for processing. Due to the ever-changing nature of computers and networks, Fig.12 The description of computing device 1200 depicted in the drawings is intended only as a specific example to illustrate a preferred embodiment of the device. Fig.12 Other configurations are possible with more or fewer components of the systems shown.

[0176] Therefore, the description and drawings should be considered illustrative rather than restrictive. However, it is obvious that various modifications and changes can be made thereto without departing from the scope of the invention as set forth in the claims. Likewise, other variations are also within the scope of the invention. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, the specific illustrated embodiments are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the invention to one or more specific forms disclosed, but rather, the intention is to cover all modifications, alternative constructions and equivalents that fall within the scope of the invention as defined by the appended claims.

[0177] In the context of describing the disclosed embodiments (especially in the context of the following claims), the use of the terms "a" and "an" and "the" and similar referents are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Unless otherwise noted, the terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to." The term "connected" refers to a physical connection without modification, even if something intervenes, and is to be understood as partially or completely contained, connected, or connected together. Unless otherwise noted, the recitation of numerical ranges herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, and each separate value is incorporated into the specification as if individually recited. Unless otherwise noted or contradicted by context, the use of the term "set" (e.g., "aset of items") or "subset" is to be understood as a non-empty set that includes one or more members. In addition, unless otherwise noted or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a true subset of the corresponding set, but a subset and a corresponding set may be equivalent.

[0178] Unless expressly stated otherwise or clearly contradicted by context, conjunction language such as phrases of the form "atleast one of A, B, and C" or "at least one of A, B or C" is understood in context to be generally used to indicate that an item, term, etc. may be A or B or C, or any non-empty subset of the set A and B and C. For example, in the illustrative example of a set having three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B or C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunction language does not generally imply that a particular embodiment requires the presence of at least one of A, at least one of B, and at least one of C.

[0179] Unless otherwise specified or clearly contradicted by the context, the operations of the described processes may be performed in any suitable order. The described processes (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors. In some embodiments, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program that includes a plurality of instructions that may be executed by one or more processors. In some embodiments, the computer-readable storage medium may be non-transitory.

[0180] Unless otherwise specified, the use of any and all examples or exemplary language (e.g., "such as") provided is intended only to better illustrate embodiments of the invention and does not limit the scope of the invention. No language in the specification should be construed as indicating any non-claimed element is essential to the practice of the invention.

[0181] Embodiments of the present invention are described, including the best mode known to the inventor for carrying out the present invention. Variations of these embodiments will become apparent to those of ordinary skill in the art by reading the foregoing description. The inventor expects that such variations will be appropriately adopted by a skilled person, and the inventor intends to practice the embodiments of the present invention in a manner different from that specifically described. Therefore, the scope of the present invention includes all modifications and equivalents of the main contents listed in the appended claims as permitted by applicable law. In addition, unless otherwise stated or clearly contradictory to the context, any combination of the above elements in all possible variations thereof is included within the scope of the present invention.

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

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

[0184] Summarize

[0185] The techniques described and suggested in this invention extend the functionality of blockchains without destroying the properties of blockchains that ensure the integrity of data stored in blockchain data structures. For example, the techniques described in this invention improve the field of computing, particularly the field of smart contracts, by providing greater flexibility for implementing constraints on transactions. In addition, the techniques described and suggested in this invention can improve the functionality of blockchain networks by generating pseudo-random numbers in scripts. Furthermore, the techniques described and suggested in this invention must be rooted in computer technology in order to overcome problems that arise specifically from the lack of random number generation functionality in blockchain script opcodes.

Claims

1. A computer-implemented method comprising: Verifying, at a node in a blockchain network, a first transaction including a puzzle, the first transaction being associated with a digital asset, a solution to the puzzle being undeterminable at the time of verification of the first transaction; generating a pseudorandom number at least in part by verifying a second transaction created to transfer control of the digital asset associated with the first transaction, the pseudorandom number being based at least in part on a solution to the puzzle included in the second transaction; and transferring control of the digital asset based at least in part on the pseudorandom number; wherein: the puzzle is a set of opcodes in the locking script of the first transaction; and As a result of receiving as input a solution to the puzzle, execution of the set of opcodes evaluates to true; wherein the solution is used at least in part to derive a seed for a pseudo-random number generation algorithm in the locking script of the first transaction; and Among other things, transferring control of the digital assets includes: Under the condition that the pseudo-random number is the first value, verification of the second transaction succeeds; Under the condition that the pseudo-random number is a second value different from the first value, verification of the second transaction is unsuccessful.

2. The computer-implemented method of claim 1 , wherein: The puzzle is a cryptographic hash puzzle.

3. The computer-implemented method of claim 1 or 2, wherein: The puzzle is a proof-of-work function.

4. The computer-implemented method of claim 1 , wherein: Solving the puzzle is computationally more difficult than verifying the solution.

5. The computer-implemented method of claim 1 , wherein: The locking script constrains validation of the second transaction to a time frame.

6. The computer-implemented method of claim 5, wherein: Expiration of the time frame enables the designated party to receive control of the digital asset.

7. The computer-implemented method of claim 6, wherein: The designated party is the party that created the first transaction.

8. The computer-implemented method of claim 1 , wherein: The allocation for solving the puzzle is greater than the digital asset.

9. The computer-implemented method of claim 1 , wherein: The solution is derived at least in part from a header of a block in the blockchain network.

10. The computer-implemented method of claim 9, wherein: When the first transaction is successfully authenticated, the header is undeterminable.

11. A system comprising: processor; and A memory comprising executable instructions, the executable instructions as a result of execution by the processor causing the system to perform the method according to any one of claims 1 to 10.

12. A non-transitory computer-readable storage medium having executable instructions stored thereon, wherein the executable instructions, as a result of being executed by a processor of a computer system, cause the computer system to at least perform the method according to any one of claims 1 to 10.

Images