Script-based blockchain interaction

Abstract

A computer-implemented method may be provided, which may be implemented using a blockchain network. The computer-implemented method comprises: i) receiving, at a node in a blockchain network, a first transaction related to a digital asset, the first transaction specifying at least: a) a first set of constraints to a second transaction for transferring control of the digital asset, the first set of constraints comprising one or more constraints, the one or more constraints cause the second transaction to contain a data set from a block chain; and b) a second set of constraints for the second transaction, the second set of constraints comprising one or more constraints, the one or more constraints being associated with data items of the data set; ii) verifying that the first set of constraints and the second set of constraints are satisfied; and iii) re-associating the digital asset based at least in part on the verification.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201880034526.8, application date May 23, 2018, and name “Script-based blockchain interaction”. Technical Field

[0002] The present invention generally relates to distributed ledger technology, including blockchain transactions, and more particularly to enabling fields from blockchains, block headers, blocks, and blockchain transactions to be injected into transaction scripts. The present invention is particularly suitable for, but not limited to, use in transactions based on blockchain states. Background Art

[0003] In this article, we use the term "blockchain" to cover all forms of computer-based electronic distributed ledgers, including consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variants. It should be noted that the present invention is not limited to use with a specific blockchain, and other blockchain applications and protocols, including non-commercial applications, also fall within the scope of the present invention.

[0004] As used herein, a "digital asset" is a unit of a resource managed by a blockchain. A digital asset is a unit of a resource managed by a blockchain. Although in some embodiments, a digital asset may be used as a specific digital asset, it is contemplated that in embodiments, a digital asset may be used additionally or alternatively in other situations. 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. The "digital asset" used in the present invention may refer to one or more digital assets. For example, a transaction may have multiple inputs, and each of these inputs may represent a different digital asset. In this example, the digital asset to which 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 those multiple inputs to produce one or more outputs, such that, for example, the number of inputs and the number of outputs are different. In one embodiment, a digital asset is a token-based digital asset, where each token represents a share of an asset (e.g., a share of a company), and a single transaction involves multiple types of tokens (e.g., involving shares of one or more different companies). Summary of the invention

[0005] This invention describes technical aspects of one or more blockchain-based computer programs. A blockchain-based computer program is a machine-readable and executable program recorded in a blockchain transaction. A blockchain-based computer program may include rules that can process inputs to produce results, and actions may then be performed based on those results. If a locking script has access to unlocking and previous transactions, then a blockchain can be utilized to enable highly flexible and complex blockchain-based computer programs. One area of ​​current research is the use of blockchain-based computer programs to implement "smart contracts." Unlike traditional contracts written in a natural language, smart contracts are computer programs designed to automatically execute the terms of a machine-readable contract or agreement.

[0006] In an embodiment, although interactions with specific entities may be encoded at specific steps in a smart contract, smart contracts may also be automatically executed and self-executing. In some examples, automatic execution refers to the execution of a smart contract that is successfully executed to enable the transfer of UTXO. Note that in such examples, an "entity" that enables the transfer of UTXO refers to an entity that is able to create an unlocking script without proving knowledge of certain secrets. That is, the unlocking transaction can be verified without verifying that the data source (e.g., the entity that creates the unlocking transaction) has access to the cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Similarly, in such examples, self-execution refers to enabling the verification node of the blockchain network to execute the unlocking transaction according to the constraints. In some examples, "unlocking" UTXO is used in a technical sense, referring to creating an unlocking transaction that references the UTXO and is executed as a valid execution. Unlocking UTXO may also be referred to as spending UTXO in the art.

[0007] Blockchain transaction outputs include a locking script and information about the ownership of digital assets. The locking script (which can also be called a "payload") "locks" digital assets by specifying the conditions that need to be met to transfer the UTXO. For example, the locking script may require certain data to be provided in the unlocking script to unlock the associated digital asset. The locking script is also called a "script public key" (scriptPubKey). The technique of requiring the locked party to provide data to unlock the digital asset involves embedding a hash of the data in the locking script. However, problems arise if the data is not determined (e.g., unknown and unfixed) when the locking script is created.

[0008] Additionally, if the locking script is predicted based on aspects of the blockchain itself (e.g., other transactions in the block or the contents of the block header), then that data did not exist when the locking script was created, and there is no opcode in the blockchain to query the state of the blockchain to obtain that data. Therefore, the locking script cannot require a specific block header, cannot require a specific state of the blockchain, and cannot require that the transaction be within a specific block of the blockchain.

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

[0010] Thus, according to the present invention, there is provided a method as defined in the appended claims.

[0011] The following describes in more detail a computer-implemented method and electronic device for implementing constraints on data in an unlocking script to require that the unlocking script include a block header, a blockchain, or a chain of block headers.

[0012] The data in the script enforces such constraints and is injected into the unlocking script at runtime. Transactions can be based on various aspects of the blockchain.

[0013] Therefore, according to the present invention, there may be provided a computer-implemented method (and corresponding system) as defined in the appended claims. The method may be described as a blockchain data constraint method. The computer-implemented method comprises: i) receiving a first transaction comprising a first script at a node in a blockchain network, the first script specifying a set of constraints on a second transaction, the set of constraints comprising a constraint that the data set obtained by the node comprises information obtained from a blockchain associated with the blockchain network; ii) obtaining a second transaction, the second transaction comprising a second script, the execution of which causes the node to obtain the above-mentioned data set; iii) verifying the second transaction by executing the first script and the second script.

[0014] The following describes in more detail a computer-implemented method and electronic device for implementing constraints on data in an unlocking script to require that the blockchain be in a specific state before the unlocking script can be used to unlock the locking script and access the digital assets of the transaction. By implementing constraints on the locking script to require that the unlocking script include a block header, a blockchain, or a chain of block headers, and injecting such data into the unlocking script at runtime, transactions can be based on the state of the blockchain.

[0015] The constraint set may include such a constraint: the above data set includes the block header of the block of the blockchain.

[0016] By at least verifying that the block header has a predetermined size, a node can determine whether such constraints are met:

[0017] The data set includes block headers of blocks of the blockchain. Additionally or alternatively, the node may determine whether the constraint that the data set includes block headers of blocks of the blockchain is satisfied by at least verifying that the block header includes a difficulty value greater than or equal to a certain difficulty value. Additionally or alternatively, the node may determine whether such a constraint is satisfied by at least verifying that a hash of the block header is less than or equal to a target value calculated from the difficulty value included in the block header: the data set includes block headers of blocks of the blockchain.

[0018] The set of constraints may include a constraint that the set of data includes a third transaction from a block of the blockchain.

[0019] The data set may include a block header of a block of the blockchain. Additionally or alternatively, the constraint set may include a constraint that a third transaction is included in the block. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied based at least in part on the block header of the block of the blockchain.

[0020] The node may determine whether the constraint that the third transaction is included in the block is satisfied by calculating at least a hash value of the third transaction based at least in part on the encoding of the transaction in the block identified by the block header. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied by at least verifying that the hash value of the third transaction is equal to the hash value stored in the block header.

[0021] The constraint set may include a constraint that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

[0022] The node may determine whether such a constraint is satisfied by selecting at least a pair of block headers based at least in part on an order associated with the plurality of block headers: the second script includes a block header chain. The pair of block headers includes:

[0023] A first block header in a pair of block headers and a second block header in the pair of block headers. Additionally or alternatively, the node may determine whether the constraint that the second script includes a block header chain is satisfied by verifying, at least for the pair of block headers, whether a hash of the first block header in the pair of block headers is equal to a hash value stored in the second block header in the pair of block headers.

[0024] The set of constraints may include a constraint that the set of data is obtained from a public blockchain of the blockchain network.

[0025] One or more properties of the blockchain network may be provided to the node prior to executing the first script and the second script.

[0026] Verifying the second transaction may be successfully performed without verifying that the entity that created the second transaction has access to the secret information.

[0027] The first script may be a locking script of the first transaction, and the second script may be an unlocking script of the first script.

[0028] The computer-implemented method may further include: transferring the digital asset based at least in part on the result of the verification. Therefore, according to the present invention, a computer-implemented method (and (one or more) corresponding systems) as defined in the attached claims may be provided. The method may be described as a blockchain state confirmation method. The computer-implemented method includes: i) receiving, at a node in a blockchain network, a first transaction that specifies at least the following: a) a first set of constraints on a second transaction, the first set of constraints including one or more constraints that cause the second transaction to include a data set from the blockchain; b) a second set of constraints on the second transaction, the second set of constraints including one or more constraints related to data items in the data set; ii) upon verifying that the first set of constraints and the second set of constraints are satisfied, storing the second transaction in the blockchain.

[0029] The following describes in more detail a computer-implemented method and electronic device for implementing constraints on data in an unlocking script to require that the blockchain be in a specific state before the unlocking script can be used to unlock the locking script, and to maintain access to the digital assets of the transaction in these states. By implementing constraints on the locking script to require that the unlocking script include a block header, a blockchain, or a chain of block headers, and by injecting such data into the unlocking script at runtime, the transaction outcome can be based on the state of the blockchain.

[0030] The set of data may be received at a node in a second transaction.

[0031] The computer-implemented method may further include: verifying the second transaction as a result of the verifying.

[0032] Verifying the second transaction may be successfully performed without verifying that the entity creating the second transaction has access to the secret information.

[0033] The first set of constraints may include a constraint that the data set includes a block header of the blockchain.

[0034] The first set of constraints may include a constraint that the set of data includes a third transaction from a block of the blockchain.

[0035] The first set of constraints may include constraints such that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

[0036] The second set of constraints may include constraints on the values ​​of the data items of the data set.

[0037] The second set of constraints may include constraints derived from one or more values ​​associated with data items of the data set.

[0038] The first set of constraints may be included in a locking script of the first transaction.

[0039] The second set of constraints may be included in the locking script of the first transaction.

[0040] The first set of constraints may include a constraint that the set of data is received from a public blockchain.

[0041] The node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by receiving at least a first set of blocks and a second set of blocks in a second transaction, wherein the first set of blocks includes blocks before the block received from the blockchain network, and the second set of blocks includes blocks after the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying that the first set of blocks is linked to the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying that the second set of blocks is linked to the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying whether the first set of blocks and the second set of blocks are valid. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying that each block in the first set of blocks and the second set of blocks has a difficulty value greater than a predetermined value.

[0042] Thus, according to the present invention, there may be provided a computer-implemented method (and (one or more) corresponding systems) as defined in the accompanying claims. The method may be described as a blockchain state-aware method. The computer-implemented method comprises: i) receiving, at a node in a blockchain network, a first transaction specifying at least: a) a first set of constraints on a second transaction, the first set of constraints comprising one or more constraints causing the second transaction to include a data set from the blockchain network; b) a second set of constraints on the second transaction, the second set of constraints comprising a constraint that the data set includes a block including the first transaction, the block being included in a blockchain associated with the blockchain network; ii) successfully verifying that the first set of constraints and the second set of constraints are satisfied, causing the second transaction to be recorded into the blockchain network.

[0043] The set of data may be received at a node in a second transaction.

[0044] The first set of constraints may include a constraint that the data set includes a block header of the blockchain.

[0045] The first set of constraints may include a constraint that the set of data includes a third transaction of a block of the blockchain.

[0046] The first set of constraints may include constraints such that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

[0047] Verifying that the first set of constraints and the second set of constraints are satisfied can provide a set of properties of the blockchain network to the node.

[0048] The set of properties of the blockchain network may include a corresponding timestamp associated with each block of the blockchain of the blockchain network.

[0049] The first set of constraints includes a constraint that the second transaction includes a timestamp associated with the block. Additionally or alternatively, verifying the constraint that the second transaction includes a timestamp associated with the block may be based at least in part on the set of properties of the blockchain network.

[0050] The first set of constraints includes a constraint that the data set includes a block header. Additionally or alternatively, the second set of constraints may include a constraint that the second transaction includes an identifier of the first transaction. Additionally or alternatively, the second set of constraints may include a constraint that the identifier of the first transaction is associated with a value of the block header.

[0051] The first set of constraints and the second set of constraints may be included in a locking script of the transaction.

[0052] The first transaction may specify a third set of constraints on the second transaction, the third set of constraints comprising constraints on values ​​of data items of the data collection.

[0053] The first transaction may specify a third set of constraints on the second transaction, the third set of constraints comprising constraints derived from one or more values ​​associated with the data items of the data set.

[0054] The computer-implemented method may further include: verifying the second transaction due to verifying that the first set of constraints and the second set of constraints are satisfied, thereby successfully verifying the second transaction, without verifying that the entity that created the second transaction has access to the secret information. Therefore, according to the present invention, a computer-implemented method (and (one or more) corresponding systems) as defined in the attached claims may be provided. The method can be described as a blockchain data constraint method. The computer-implemented method includes: i) receiving a first transaction associated with a digital asset at a node in a blockchain network, the first transaction including a first script, the first script specifying a set of constraints on a second transaction, the second transaction is used to transfer control of the digital asset, and the constraint set includes a constraint that the data set obtained by the node includes information obtained from a blockchain associated with the blockchain network; ii) obtaining a second transaction, the second transaction including a second script, the node obtaining the data set due to the execution of the second script; iii) verifying the second transaction by executing the first script and the second script.

[0055] The set of constraints may include a constraint that the set of data includes block headers of blocks of the blockchain.

[0056] By at least verifying that the block header has a predetermined size, the node may determine whether the constraint that the data set includes block headers of blocks of the blockchain is satisfied. Additionally or alternatively, the node may determine whether the constraint that the data set includes block headers of blocks of the blockchain is satisfied by at least verifying that the block header includes a difficulty value greater than or equal to a certain difficulty value. Additionally or alternatively, the node may determine whether the constraint that the data set includes block headers of blocks of the blockchain is satisfied by at least verifying that a hash of the block header is less than or equal to a target value calculated from the difficulty value included in the block header.

[0057] The set of constraints may include a constraint that the set of data includes a third transaction from a block of the blockchain.

[0058] The data set may include a block header of a block of the blockchain. Additionally or alternatively, the set of constraints may include a constraint that the third transaction is included in the block. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied based at least in part on the block header of the block of the blockchain.

[0059] The node may determine whether the constraint that the third transaction is included in the block is satisfied by calculating at least a hash value of the third transaction based at least in part on the encoding of the transaction in the block identified by the block header. Additionally or alternatively, the node may determine whether the constraint that the third transaction is included in the block is satisfied by verifying at least that the hash value of the third transaction is equal to the hash value stored in the block header.

[0060] The constraint set may include a constraint that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

[0061] The node may determine whether the constraint that the second script includes a block header chain is satisfied by selecting at least a pair of block headers based at least in part on an order associated with the plurality of block headers, i.e., a block header pair, the block header pair including: a first block header in the block header pair and a second block header in the block header pair. Additionally or alternatively, the node may determine whether the constraint that the second script includes a block header chain is satisfied by at least verifying for the block header pair whether a hash of the first block header in the block header pair is equal to a hash value stored in the second block header in the block header pair.

[0062] The set of constraints may include a constraint that the set of data is obtained from a public blockchain of the blockchain network.

[0063] One or more properties of the blockchain network may be provided to the node prior to executing the first script and the second script.

[0064] Verifying the second transaction may be successfully performed without verifying that the entity that created the second transaction has access to the secret information.

[0065] The first script may be a locking script of the first transaction, and the second script may be an unlocking script of the first script.

[0066] The computer-implemented method may further include transferring the digital asset based at least in part on a result of the verifying.

[0067] Thus, according to the present invention, there may be provided a computer-implemented method (and (one or more) corresponding systems) as defined in the accompanying claims. The method may be described as a blockchain state confirmation method. The computer-implemented method comprises: i) receiving a first transaction associated with a digital asset at a node in a blockchain network, the first transaction specifying at least: a) a first set of constraints on a second transaction, the first set of constraints being used to transfer control of the digital asset, the first set of constraints comprising one or more constraints causing the second transaction to include a data set from the blockchain; b) a second set of constraints on the second transaction, the second set of constraints comprising one or more constraints associated with data items in the data set; ii) verifying that the first set of constraints and the second set of constraints are satisfied; iii) reassociating the digital asset based at least in part on the verification.

[0068] Optionally, the computer-implemented method may include: i) receiving a first transaction associated with a digital asset at a node in a blockchain network, the first transaction specifying at least: a) a first set of constraints on a second transaction, the second transaction being used to transfer control of the digital asset, the first set of constraints including one or more constraints, the one or more constraints causing the second transaction to include a data set from the blockchain; wherein the first set of constraints may include a constraint that the data set includes a third transaction from a block of the blockchain; b) a second set of constraints on the second transaction, the second set of constraints including one or more constraints related to data items in the data set; ii) verifying that the first set of constraints and the second set of constraints are satisfied; iii) reassociating the digital asset based at least in part on the verification.

[0069] The set of data may be received at a node in a second transaction.

[0070] The computer-implemented method may further include: verifying the second transaction as a result of the verifying.

[0071] Successfully performing verification of the second transaction without verifying that the entity that created the second transaction has access to the secret information.

[0072] The first set of constraints may include a constraint that the data set includes block headers of the blockchain.

[0073] The first set of constraints may include a constraint that the set of data includes a third transaction from a block of the blockchain.

[0074] The first set of constraints may include constraints such that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

[0075] The second set of constraints may include constraints on the values ​​of the data items of the data set.

[0076] The second set of constraints may include constraints derived from one or more values ​​associated with data items of the data set.

[0077] The first set of constraints may be included in a locking script of the first transaction.

[0078] The second set of constraints may be included in the locking script of the first transaction.

[0079] The first set of constraints may include a constraint that the set of data is received from a public blockchain.

[0080] The node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by receiving at least a first set of blocks and a second set of blocks in a second transaction, wherein the first set of blocks includes blocks before the block received from the blockchain network, and the second set of blocks includes blocks after the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying that the first set of blocks is linked to the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying that the second set of blocks is linked to the block received from the blockchain network. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying whether the first set of blocks and the second set of blocks are valid. Additionally or alternatively, the node may determine whether the constraint of receiving the data set from the public blockchain is satisfied by at least verifying that each block in the first set of blocks and the second set of blocks has a difficulty value greater than a predetermined value.

[0081] Thus, according to the present invention, there may be provided a computer-implemented method (and (one or more) corresponding systems) as defined in the accompanying claims. The method may be described as a blockchain state-aware method. The computer-implemented method comprises: i) receiving a first transaction associated with a digital asset at a node in a blockchain network, the first transaction specifying at least the following: a) a first set of constraints on a second transaction for transferring control of the digital asset, the first set of constraints comprising one or more constraints causing the second transaction to include a data set from the blockchain network; b) a second set of constraints on the second transaction, the second set of constraints comprising a constraint that the data set includes a block including the first transaction, the block being included in a blockchain associated with the blockchain network; ii) verifying that the first set of constraints and the second set of constraints are satisfied; and iii) transferring control of the digital asset based at least in part on the verification.

[0082] The set of data may be received at a node in a second transaction.

[0083] The first set of constraints may include a constraint that the data set includes a block header of the blockchain.

[0084] The first set of constraints may include a constraint that the set of data includes a third transaction from a block of the blockchain.

[0085] The first set of constraints may include constraints such that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

[0086] Verifying that the first set of constraints and the second set of constraints are satisfied can provide a set of properties of the blockchain network to the node.

[0087] The set of properties of the blockchain network may include a corresponding timestamp associated with each block of the blockchain of the blockchain network.

[0088] The first set of constraints includes a constraint that the second transaction includes a timestamp associated with the block. Additionally or alternatively, verifying the constraint that the second transaction includes a timestamp associated with the block may be based at least in part on a set of properties of the blockchain network.

[0089] The first set of constraints includes a constraint that the data set includes a block header. Additionally or alternatively, the second set of constraints may include a constraint that the second transaction includes an identifier of the first transaction. Additionally or alternatively, the second set of constraints may include a constraint that the identifier of the first transaction is associated with a value of the block header.

[0090] The first set of constraints and the second set of constraints may be included in a locking script of the transaction.

[0091] The first transaction may specify a third set of constraints on the second transaction, the third set of constraints comprising constraints on values ​​of data items of the data collection.

[0092] The first transaction may specify a third set of constraints on the second transaction, the third set of constraints comprising constraints derived from one or more values ​​associated with the data items of the data set.

[0093] The computer-implemented method may further include verifying the second transaction as a result of verifying that the first set of constraints and the second set of constraints are satisfied, wherein the second transaction is successfully verified without verifying that an entity that created the second transaction has access to the secret information.

[0094] It is also contemplated to provide a system comprising: a processor; and a memory containing executable instructions, wherein the processor executes the instructions so that the system performs any one of the methods of the claims.

[0095] It is also desirable to provide a non-transitory computer-readable storage medium storing executable instructions, wherein a processor of a computer system executes the executable instructions so that the computer system performs at least any one of the methods of the claims.

[0096] It is also contemplated to provide a system comprising: a processor; and a memory containing executable instructions, wherein the processor executes the instructions so that the system performs any one of the methods of the claims.

[0097] According to the present invention, an electronic device may be provided. The electronic device includes an interface device, a processor coupled to the interface device, and a memory coupled to the processor. The memory stores computer executable instructions, which, when executed, cause the processor to perform the method described herein.

[0098] According to the present invention, a computer-readable storage medium may be provided, wherein the computer-readable storage medium includes computer-executable instructions, which, when executed, cause a processor to perform the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0099] These and other aspects of the invention will be apparent from or 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.

[0100] Figure 1 A schematic diagram showing an example blockchain network in which various embodiments may be implemented;

[0101] Figure 2 A schematic diagram of an example electronic device according to an embodiment is shown, wherein the example electronic device can be used as a node in a blockchain network;

[0102] Figure 3 A schematic diagram illustrating an example embodiment of a transaction associated with a script-based blockchain interaction;

[0103] Figure 4 A schematic diagram showing an example problem solved by an embodiment, wherein the example problem relates to accessing a blockchain associated with a script-based blockchain interaction;

[0104] Figure 5 A schematic diagram showing an example problem solved by an embodiment, wherein the example problem relates to accessing a block in a blockchain associated with a script-based blockchain interaction;

[0105] Figure 6 A schematic diagram of an example environment is shown in accordance with an embodiment, wherein data is verified as a block header for script-based blockchain interaction;

[0106] Figure 7 A flow chart illustrating an example process for verifying that data is a block header in a script-based blockchain interaction according to an embodiment is shown;

[0107] Figure 8 A schematic diagram of an example environment is shown in accordance with an embodiment, wherein data verification is a block header of a previous block for script-based blockchain interaction;

[0108] Fig. 9A flow chart showing an example process for verifying that data is a block header of a previous block in a script-based blockchain interaction according to an embodiment is shown;

[0109] Fig.10 A schematic diagram of an example environment is shown in accordance with an embodiment, wherein data verification is a block header chain for script-based blockchain interaction;

[0110] Fig.11 A flow chart illustrating an example process for verifying that data is a block header chain in a script-based blockchain interaction according to an embodiment;

[0111] Fig.12 A schematic diagram of an example environment showing a Merkle tree of block headers that may be used in script-based blockchain interactions according to an embodiment is shown;

[0112] Fig.13 A schematic diagram of an example environment is shown in accordance with an embodiment, wherein transactions are verified as included in a block header for script-based blockchain interactions;

[0113] Fig.14 A flow chart illustrating an example process for verifying that a transaction is included in a block header of a script-based blockchain interaction according to an embodiment is shown;

[0114] Fig.15 A schematic diagram of an example environment illustrating how the methods described herein may be used to solve problems accessing a blockchain associated with script-based blockchain interactions is shown, according to an embodiment.

[0115] Fig.16 A schematic diagram of an example environment illustrating a state of a blockchain associated with script-based blockchain interactions according to an embodiment is shown;

[0116] Fig.17 A schematic diagram of an example environment in which the state of a blockchain is confirmed in a script-based blockchain interaction according to an embodiment is shown;

[0117] Fig.18 A flow chart showing an example process for confirming the state of a blockchain in a script-based blockchain interaction according to an embodiment is shown;

[0118] Fig.19 A schematic diagram showing an example problem of locking scripts in script-based blockchain interactions solved by an embodiment;

[0119] Fig. 20A schematic diagram showing an example of locking script access to data in a script-based blockchain interaction according to an embodiment;

[0120] Fig.21 A schematic diagram of an example environment in which a signature is generated from a set of serialized transaction fields in a script-based blockchain interaction according to an embodiment is shown;

[0121] Fig. 22 A flow chart illustrating an example process for causing injection of a serialized unlocking transaction field set in a script-based blockchain interaction according to an embodiment is shown;

[0122] Fig.23 A schematic diagram showing an example problem of locking scripts in script-based blockchain interactions solved by an embodiment;

[0123] Fig.24 A schematic diagram of an example environment in which injection of previously serialized transactions is induced in a script-based blockchain interaction is shown according to an embodiment;

[0124] Fig.25 A schematic diagram showing an example of a set of fields available based on a signature hash type in a script-based blockchain interaction according to an embodiment;

[0125] Fig.26 A schematic diagram showing an example of extracting a transaction identifier from a serialized transaction in a script-based blockchain interaction according to an embodiment;

[0126] Fig. 27 A flow chart illustrating an example process for causing the injection of previously serialized transactions in a script-based blockchain interaction according to an embodiment;

[0127] Fig.28 A schematic diagram of an example environment in which the state of a blockchain is used for script-based blockchain interactions according to an embodiment is shown;

[0128] Fig.29 A flowchart of an example process for using the state of a blockchain in a script-based blockchain interaction according to an embodiment is shown;

[0129] Fig.30 A diagram illustrating an example implementation of using states of a blockchain in script-based blockchain interactions according to an embodiment. DETAILED DESCRIPTION

[0130] First reference Figure 1 , Figure 1An example blockchain network 100 associated with a blockchain is shown in schematic form, and various embodiments may be implemented. Distributed electronic devices running an instance of a blockchain protocol (under which the blockchain network 100 may operate) may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102.

[0131] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including, for example, computers (e.g., desktop computers, laptop computers, tablet computers, servers), mobile devices (e.g., smartphones), wearable devices (e.g., smart watches), or other electronic devices.

[0132] The nodes 102 of the blockchain network 100 are coupled to each other using appropriate communication technologies, which may include wired and wireless communication technologies. Such communication follows protocols associated with the blockchain. The nodes 102 maintain a global ledger of all transactions on the blockchain. Therefore, the global ledger is a distributed ledger. Each node 102 can store a complete copy or a partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by other nodes 102, so that the validity of the global ledger is maintained. When the blockchain is a specific blockchain, the block can also be verified by checking the proof submitted with the block.

[0133] In some examples, at least some of the nodes 104 in the blockchain network 100 perform expensive computations in order to facilitate transactions on the blockchain. For example, the nodes may be required to solve a cryptographic problem. At least some of the nodes 104 find a random number such that the block header with double SHA256 hashes to a number less than the value of the currently defined difficulty. The node 104 that solves the cryptographic problem creates a new block for the blockchain and broadcasts the new block to the other nodes 102. The other nodes 102 verify that the node 104 that solves the cryptographic problem has actually solved the cryptographic problem and therefore presents sufficient proof before accepting that the block should be added to the blockchain. Before accepting that the block should be added to the blockchain, the other nodes 102 also verify that the block itself is valid (e.g., the transactions and block header of the block are valid). Through the consensus of the nodes 102, the block is added to the blockchain (i.e., added to the distributed global ledger).

[0134] The block created by the node 104 that solves the cryptographic problem includes transactions that have been broadcast to the blockchain by the nodes 102. For example, the block may include a transaction from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, the blocks in the blockchain serve as a record of transactions from one address to another address. The party that is to include the transaction in the block is required to prove that they are authorized to initiate the transfer by signing the request with the private key corresponding to their public key. The transfer is only added to the block if the request has been validly signed.

[0135] There is a one-to-one correspondence between public keys and addresses. That is, each public key is associated with a unique address. Therefore, any references herein to transferring digital assets to or from a public key (e.g., to an address associated with a public key) and to or from an address associated with a public key refer to generic operations.

[0136] Some nodes 102 may act as validating nodes. Validation of a transaction may involve checking signatures or other conditions specified in a locking script, confirming references to valid UTXOs, etc. Figure 1 The example includes six nodes 102, two of which participate as nodes 104 for solving cryptographic problems. In practice, the number of nodes 102 or nodes 104 for solving cryptographic problems may be different. In many blockchain networks, the number of nodes 102 and nodes 104 for solving cryptographic problems may be greater than Figure 1 The quantities shown are much larger.

[0137] Figure 2 An example electronic device 200 is shown in schematic form, which can be used as a blockchain network according to an embodiment (e.g., in combination with Figure 1 Nodes in the blockchain network 100 shown (e.g., in conjunction with Figure 1 102). The example electronic device 200 may be used as a node, for example, in conjunction with Figure 1 The blockchain network 100 shown combines Figure 1 One of the nodes 102 is shown. In one embodiment, the blockchain network is a peer-to-peer blockchain network.

[0138] The electronic device may be in a variety of forms including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device (such as a smartphone), a wearable device (such as a smart watch), or other forms.

[0139] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 may communicate with each other via a bus 240. The memory 220 stores a computer software program including machine-readable instructions and data for performing the functions described herein. For example, the memory may include processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may include instructions that, when executed by the processor 210, cause the electronic device to implement communication with a blockchain network (e.g., in conjunction with Figure 1 Instructions of the protocol associated with the described blockchain network 100).

[0140] The memory 220 may store the blockchain network (e.g., Figure 1 The memory 220 may store a global ledger or a portion thereof of the blockchain network 100 described herein. That is, the memory 220 may store all blocks or a portion of blocks of the blockchain, such as the latest block, or a portion of the information in some blocks.

[0141] Although the memory 220 is Figure 2 Although shown as a single box in the figure, in fact, the electronic device 200 may include multiple memory components. The memory components can be of various types, including, for example, random access memory (RAM), hard disk drive (HDD), solid state drive (SSD), flash drive (Flash Drives), etc. Different types of memory can be suitable for different purposes. In addition, although the memory 220 is shown separately from the processor 210, the processor 210 may include an embedded memory.

[0142] like Figure 2 As shown, the processor 210 may include a secure area, such as a trusted execution environment (TEE). The TEE 250 is an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, integrity of trusted applications, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded inside the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 can be used to protect the integrity and confidentiality of important resources (such as encryption keys). The TEE 250 is implemented at least in part at the hardware level, thereby protecting the instructions and data executed within the TEE 250 from access and manipulation from the rest of the electronic device 200 and external parties such as the owner of the electronic device. The data and computations within the TEE 250 are protected from being manipulated by nodes that include the TEE 250 (for example, in conjunction with Figure 1 Described node 102) is accessed and manipulated by one party.

[0143] The TEE 250 is operable to instantiate a secure execution environment (also referred to herein as an "enclave") and then add pages of memory one at a time while cumulatively hashing the added pages of memory. In one embodiment, hashing of the memory pages is performed on a remote machine (e.g., a developer machine or another machine) so that the remote machine determines and stores the expected hash. Thus, the contents of the enclave can be verified by any remote machine to ensure that the enclave is running the approved algorithm. This verification can be performed by comparing hashes. The enclave will be locked after it is fully built. Code can be run in the TEE 250 and secrets can be sent to the code, but once the enclave is locked, the code cannot be changed. The final hash can be signed by an authentication key and can be used by the data owner for verification before the data owner sends any secrets to the enclave.

[0144] TEE 250 can be used to protect the confidentiality and integrity of cryptographic keys stored within TEE 250. For example, TEE 250 can be used to generate and store private key shares. The purpose of TEE 250 is to ensure that no member can directly obtain private key shares within the TEE 250 isolation zone, nor can it obtain information about other private key shares from inter-member communication or inter-isolated zone communication. The protocol is also strong in compromising isolation zone thresholds. In addition, TEE 250 can enable nodes (for example, as combined with Figure 1 Remote attestation (one of the nodes 102 shown) is used to prove to other nodes that the TEE 250 is authentic and is running approved computer executable instructions of the protocol implemented by the blockchain network 100. Remote attestation can be provided by the TEE 250 by running a specific code segment and sending a hash of the node inside the enclave signed by the enclave's internal attestation key.

[0145] The TEE 250 may be equipped with a secure random number generator located inside the TEE's isolation zone that may be used to generate private keys, random challenges, or other random data. The TEE 250 may also be used to read data from external memory and may be used to write data to external memory. Such data may be encrypted using a secret key that is maintained only within the isolation zone.

[0146] The TEE 250 may be implemented using various platforms, such as a Trusted Platform Module (TPM) or Intel Software Guard Extensions (SGX). For example, SGX supports remote attestation, enabling an enclave to obtain signed statements from a processor executing a specific enclave with a given member known as a quote. A third-party attestation service, such as Intel Attestation Service (IAS), can attest that these signed statements originate from a real CPU that complies with the SGX specification.

[0147] The present invention may provide a method (and corresponding system) for modifying a cryptographic public key embedded in a locking script of a blockchain transaction (Tx) using undetermined data provided in an unlocking script of another transaction. When used in conjunction with, for example, a signature check opcode using a serialized transaction as a message, both the transaction and the data may need to be approved or authorized by the owner of the public key. This protects the transaction and the data from being altered.

[0148] The methods described herein use one or more digital signature schemes to verify various transactions. The digital signature scheme may be an elliptic curve digital signature algorithm (ECDSA) scheme. The digital signature scheme may also be a two-party ECDSA scheme. The digital signature scheme may also be a threshold ECDSA scheme. The scheme may be used to construct a valid signature without having to reconstruct the private key and without either party having to reveal their key share to the other party. In the example of a two-party ECDSA scheme, there are two parties, and both parties need to reconstruct the private key.

[0149] The ECDSA scheme includes a node (e.g., a combination of Figure 1 Various mechanisms used by nodes 102 described above to identify malicious or uncooperative parties. For example, verifiable secret sharing (VSS) can be used to share the polynomials required for Shamir's secret sharing (SSS). SSS is a form of secret sharing in which the secret is divided into multiple parts and provided to each participant, and each participant receives its own unique part. These parts can be used to reconstruct the secret. If inconsistent shares are provided to different nodes, or if a share secret is sent to a node that is different from the blind share broadcast to all nodes, the node can use VSS to identify malicious nodes or members. Any node can identify inconsistent shares. The sharing of secrets can be made verifiable by including auxiliary information that allows nodes to verify that their shares are consistent.

[0150] The sending of incorrect shares (i.e., shares that differ from the broadcast blind shares) to a single node can be identified by the intended recipient node of the shares. The identification of incorrect shares sent secretly to a node can be publicly verified using publicly verifiable secret sharing (PVSS) techniques. Such techniques can avoid delays that can occur in identifying a fraudulent sender when PVSS is not used and the recipient of the incorrect shares is offline, or is disconnected from a large portion of the network when the incorrect shares are sent.

[0151] Misbehavior, such as providing inconsistent shares to different nodes, can be addressed by the network to deter malicious behavior. For example, when a node is identified as a malicious party by other nodes, many nodes can cooperate to punish the malicious party. For example, nodes can take action involving digital assets (e.g., tokens, shares, or value) deposited to the blockchain network by a malicious party. For example, the blockchain network can destroy the tokens, shares, or value by transferring them to an address that is not redeemable, or the blockchain network can confiscate such digital assets by reaching a consensus with other rejecting nodes. Nodes that are not abnormal behavior nodes can also prevent abnormal behavior by cooperating to exclude abnormal behavior nodes (e.g., by effectively invalidating key shares; for example, by excluding the node from participating in the conference agreement, or by re-sharing the private key without allocating shares to the abnormal behavior node).

[0152] The ECDSA technique described above can be enhanced by using a TEE. For example, a strong form of adversary is conceived based on the threshold ECDSA signature technique of Ibrahim et al., referred to herein as a Byzantine adversary. This type of adversary may behave arbitrarily, for example, they not only refuse to participate in the signing process or stop the party midway, but they may also pretend to participate honestly and send incorrect information. However, by using a TEE, and generating the data for signing within the isolation of the TEE storing the key shares, additional security can be provided because the isolation is extremely unlikely to be compromised in large numbers. For example, if no more than one key share is assigned to each TEE, assuming n is large enough, it is reasonable to expect that the number of potentially compromised TEEs will not approach the strong threshold against Byzantine adversaries. The protocol can be made secure if it only tolerates a small number of malicious adversaries relative to the total number of key shares.

[0153] For example, if all nodes have a TEE, access to secrets stored in an isolated area can only be achieved without compromising the maker of the TEE, only with physical access to the node, and only with great effort and expense. Such maker-level compromise is expected to be manageable. For example, if a maker falsely claims that many public keys correspond to real TEEs, they can gain direct access to private key shares and could launch an attack. However, such an attack would require a sufficient number of key shares to enable the maker to produce valid signatures without the help of other nodes. This would mean accumulating a large portion of the total shares, which would be very expensive. Moreover, by conducting an attack, the value of a large portion of the shares held would be destroyed.

[0154] When using TEEs, it is useful to consider how robust the protocol is to "corrupted nodes". A corrupted node is a node where the hardware external to the TEE is compromised, but the integrity of the TEE is not compromised. A corrupted node can control what information the enclave receives and does not receive. In particular, a corrupted node can suspend, i.e. avoid participating in the protocol. If the information provided to the protocol requires to be signed by a private key that is kept secret in the enclave (the corresponding public key is attested during the authentication process), then the private key is as trustworthy as the enclave itself. Therefore, a corrupted node cannot send arbitrary (attested) information to the protocol and can only try to interfere by suspending or trying to misbehave the enclave (e.g. by feeding it outdated information). Therefore, a successful attack against a corrupted node would require collecting a sufficient number of partial signatures to produce a complete signature.

[0155] In some embodiments, other threshold schemes may be used, including non-ECDSA signature schemes.

[0156] Figure 3 An example embodiment 300 of a transaction associated with a script-based blockchain interaction is shown in schematic form. Figure 3 The illustrated example embodiment 300 depicts a previous blockchain transaction 302 encoding a first state 306 of a blockchain and an unlocking blockchain transaction 304 encoding a second state 308 of the blockchain. In the example embodiment 300, the current state 306 at a first time is represented as a parameter embedded in the previous transaction 302. In one embodiment, the unlocking transaction 304 includes a parameter representing a next state 308.

[0157] In example embodiment 300, transactions 302 and 304 are field value sets that contain one or more inputs and one or more outputs. In some embodiments, the inputs and outputs reflect an intention to transfer control of a digital asset from at least one entity to at least another entity. In example embodiment 300, previous transaction 302 is the latest, confirmed transaction included in the blockchain. In example embodiment 300, unlocking transaction 304 is a transaction that will occur in the near future, which has not yet been confirmed and has not yet been included in the blockchain. Each input of unlocking transaction 304 receives an output of previous transaction 302.

[0158] Some blockchain technologies use the Elliptic Curve Digital Signature Algorithm (ECDSA) as a mathematical scheme for digital signatures. In an embodiment, ECDSA is an encrypted digital signature used to ensure that UTXO is only transferred to its legitimate owner. Elliptic Curve Digital Signature (ECDS) typically appends a signature hash tag (SIGHASH type) to the end. However, it is conceivable that the technology of the present invention can be used with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, ECDS is conceived as a signature generation principle that conforms to the specific blockchain technology.

[0159] In an embodiment, a SIGHASH type refers to a set of fields extracted from a transaction before being serialized (e.g., normalized) and hashed. For example, a SIGHASH type can affect which fields of a transaction are included in a signature. In some examples, the SIGHASH type can be one or more of SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, or SIGHASH_ANYONECANPAY. In one embodiment, the type SIGHASH_ALL characterizes that all fields in a transaction will be hashed and signed except for the input script. In one embodiment, the type SIGHASH_NONE characterizes that the output does not need to be signed, which can allow others to update the transaction. In one embodiment, the type SIGHASH_SINGLE characterizes that the input is signed but the sequence number is blank, so others can create a new version of the transaction, but the only output signed is the output in the same position as the input. In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types and characterizes that the input including SIGHASH_ANYONECANPAY is already signed, while other inputs do not need to be signed. The SIGHASH type can be represented by a value characterizing the SIGHASH type. For example, in some implementations, SIGHASH_ALL is represented by a byte with a value of 1, SIGHASH_NONE is represented by a byte with a value of 2 (e.g., "00000010"), SIGHASH_SINGLE is represented by a byte with a value of 3 (e.g., "00000011"), and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80 (e.g., "01010000"). In some implementations, the SIGHASH types are combined by adding the byte values ​​together.

[0160] In some examples, the set of transaction fields determined by the SIGHASH type refers to a subset of the corresponding transaction encoded in bytes determined by the SIGHASH type. For example, in the case where the SIGHASH type is SIGHASH_ANYONECANPAY, only one transaction input is included in the signature.

[0161] In an embodiment, ECDS is represented by a pair of 256-bit numbers (r, s) encoded in the Distinguished Encoding Rules (DER) format. However, please note that the techniques of the present invention can be used with other encoding formats, such as Basic Encoding Rules (BER) or Canonical Encoding Rules (CER). The parameters used in ECDSA include K (elliptic curve point with coordinates (x, y)), k (256-bit number; usually random to protect the private key), G (base point on the elliptic curve of order n: n×G=0, where 0 represents the same elliptic curve point), n is a large prime number used as a parameter in the finite field of the elliptic curve, r (one of the 256-bit numbers in ECDS), s (another of the 256-bit numbers in the signature, k -1 (The modular multiplication inverse of k, that is, k -1 k≡1mod n), m (the message / data being signed; in an embodiment, it is adjusted to 256 bits by a hash function), a (private key; for example, a 256-bit number). In this embodiment, ECDS is generated as follows:

[0162] First, determine the elliptic curve point K by multiplying k with the generator K = k × G. Then, determine the point x from K, and then determine the first of the 256-bit numbers in the ECDS: r according to the formula r = x mod n. Then, determine the elliptic curve point K by multiplying k with the generator K = k × G. Then, determine the point x from K, and then determine the first of the 256-bit numbers in the ECDS: r according to the formula s = k -1 (m+r×a) mod n determines the second of the 256-bit numbers in ECDS: s. Finally, (r, s) is encoded in DER format. Given a signature (r, s), a message / data m, and a public key A corresponding to a private key a, the signature is verifiable. To verify the signature, calculate v=s -1 ×(m×G+r×y). If v=r, the signature is valid.

[0163] A scripting system called "Script" may be used. In the present invention, various script opcodes and keywords are referenced to perform various operations. However, it is conceivable that other blockchain technologies may implement different instruction sets, and therefore, the opcodes described in the present invention are considered to be instructions for operations performed by the opcode rather than a specific opcode in the script. In some embodiments, the scripting system is a Turing incomplete instruction set (e.g., does not support loops, recursion, "goto" statements, etc.). In other embodiments, the scripting system is a Turing complete instruction set.

[0164] Certain embodiments of the present invention operate under the assumption that the scripting system or other system used to implement the described instruction set allows more than 200 instructions (e.g., opcodes) in a single script, while this limit is prohibited in certain implementations of some blockchains. Likewise, certain embodiments of the present invention also assume that the functionality provided by the opcodes referenced by the present invention is present and enabled in the system executing the opcode script / instruction set. In certain implementations of some blockchains, one or more of these opcodes may be disabled or restricted by default.

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

[0166] OP_ECPX: Returns the x-coordinate of an elliptic curve point

[0167] OP_ADD: Add the first two items on the stack

[0168] OP_BIGMOD: Returns the remainder after dividing the first two items on the stack

[0169] OP_BIGMODADD: Add the first two items on the stack modulo and then apply the result modulo the third item.

[0170] OP_BIGMODINVERSE: Performs a modulus negative exponentiation operation

[0171] OP_BIGMODMUL: multiply the first two items on the stack modulo and then apply the result modulo the third item.

[0172] OP_CAT: concatenates the first two items in the stack together

[0173] OP_CHECKSIG: Pop the public key and signature from the stack based on the SIGHASH type and verify the signature of the transaction field. Returns 1 if the signature is valid, otherwise returns 0.

[0174] OP_CHECKSIGVERIFY: This does the same thing as OP_CHECKSIG, but executes OP_VERIFY afterwards

[0175] OP_DERENCODE: Encode the first two items in the stack in DER format

[0176] OP_DUP: Duplicate the top stack item

[0177] OP_ECPMULT: performs an elliptic curve multiplication on the first two items on the stack

[0178] OP_ELSE: These statements will be executed if the preceding OP_IF or OP_NOTIF or OP_ELSE is not executed; otherwise, these statements will not be executed if the preceding OP_IF or OP_NOTIF or OP_ELSE is executed

[0179] OP_ENDIF: Ends the if / else block

[0180] OP_EQUAL: Returns 1 if the inputs are exactly equal, otherwise returns 0

[0181] OP_EQUALVERIFY: Same as OP_EQUAL, but runs OP_VERIFY afterwards

[0182] OP_FROMALTSTACK: Places the input on top of the primary stack and removes it from the alternate stack OP_HASH256: The input is hashed twice: first with SHA-256, then with RIPEMD-160

[0183] OP_IF: If the top stack value is not False, execute this statement and delete the top stack value OP_NOTIF: If the top stack value is false (False), execute this statement and delete the top stack value OP_ROLL: Move an item n items deep in the stack to the top

[0184] OP_SUBSTR: Returns a portion of a string

[0185] OP_SWAP: Swap the first two items in the stack

[0186] OP_TOALTSTACK: Place the inputs on the top of the alternate stack and remove them from the main stack OP_VERIFY: Mark the transaction as invalid if the top stack value is not true

[0187] In an embodiment, an ECDS generation script may be created using an opcode that may be extended to create a signature generation script OP_GENSIG by appending a SIGHASH byte to the end.

[0188] Table 1

[0189]

[0190] In the above script shown in Table 1,<SIGHASH Byte> ,information <m>, private key and numbers <k>

[0191] sequentially (e.g., after inserting the four items, the numbers <k> At the top of the stack, then the private key< / k> < / k> , followed by the message <m>, and finally<SIGHASH Byte> ) into a main (e.g., last-in, first-out) stack.

[0192] Script operation "OP_DUP OP_TOALTSTACK<PubK G> OP_ECPMULT" will cause the number <k>to the alternate stack, where <k>With elliptic curve generator<PubK G> Multiply them together to produce the elliptic curve point K on top of the main stack.

[0193] Script operation "OP_ECPX <n>The execution of "OP_BIGMOD OP_DUP OP_TOALTSTACK" causes r to be calculated based on the x-coordinate of K mod n. A copy of r is pushed onto the alternate stack.

[0194] Script Operation" <n>OP_BIGMODMUL <n>OP_BIGMODADD”, "OP_FROMALTSTACK OP_SWAP OP_FROMALTSTACK <n>” and “OP_BIGMODINVERSE <n>OP_BIGMODMUL" is executed through k -1 (m+r×a) mod n calculates s. Finally, the execution of the script operation "OP_DERENCODE OP_SWAP OP_CAT" causes r and s to be encoded in DER format and combined with<SIGHASH Byte> connect.

[0195] In the present invention, the script is referred to as OP_GENSIG. Therefore, references to OP_GENSIG in embodiments of the present invention should be considered as shorthand for the operations performed in the above script.

[0196] < / n> < / n> < / n> < / n> < / n> < / k> < / k> < / m> Figure 4 An example problem 400 solved by an embodiment is shown in schematic form, wherein the example problem 400 is related to accessing a blockchain associated with a script-based blockchain interaction. Figure 4 In the example problem 400 shown in FIG. 4 , the locking script 406 in the transaction 402 (e.g., in conjunction with Figure 3 The blockchain 404 cannot be accessed by a previous transaction described (e.g., previous transaction 302) or unlocking transaction 304).

[0197] As noted, in some embodiments, transaction 402 is the most recent, confirmed transaction included in the blockchain. Similarly, in some embodiments, transaction 402 is a future transaction that has not yet been confirmed and is not yet included in the blockchain, and represents an attempt to transfer control of at least a portion of a digital asset controlled by a previous transaction.

[0198] In some embodiments, locking script 406 is a script that blocks a transaction by specifying conditions that need to be met in order to transfer an output. More specifically, execution of locking script 406 is used to: as a result of execution by a validating node of a blockchain system, accept data from an executed unlocking script, perform certain operations based on the data, and return a result that characterizes whether execution of the unlocking script successfully "unlocked" (i.e., satisfied the set of conditions set therein) the locking script. In some embodiments, locking script 406 defines one or more data constraints that must be satisfied (e.g., by data provided via the unlocking script) in order for verification of the transaction to be successful. For example, locking script 406 may require that certain data be provided in the unlocking script to unlock the associated digital asset of transaction 402.

[0199] As shown in the example problem 400, the locking script 406 of the transaction 402 cannot query the blockchain 404 to, for example, determine the number of blocks. The locking script 406 of the transaction 402 also cannot query the blocks of the blockchain 404 including the first block 408 (also referred to as the "initial block") of the blockchain 404, any of the internal blocks of the blockchain 404 (e.g., block 410), or the latest block 412 of the blockchain 404. The methods described herein enable the locking script 406 of the transaction 402 to query the blocks of the blockchain 404 including the first block 408, any of the internal blocks (e.g., block 410), or the latest block 412 of the blockchain 404.

[0200] Figure 5 An example problem 500 solved by an embodiment is shown in schematic form, wherein the example problem 500 relates to accessing a block in a blockchain associated with a script-based blockchain interaction. Figure 5 In the exemplary problem 500 shown in FIG. 5 , a transaction 502 (e.g., a previous transaction, such as a combination of Figure 3 The previous transaction 302 described; or unlocking transaction, such as combining Figure 3 The locking script 506 in the unlock transaction 304 described above cannot access blocks in the blockchain, such as block 504 (i.e., the first block, an internal block, or the latest block).

[0201] As noted, in some embodiments, transaction 502 is the latest, confirmed transaction included in the blockchain. Similarly, in some embodiments, transaction 502 is a future transaction that has not yet been confirmed and has not yet been included in the blockchain, and represents an attempt to transfer control of at least a portion of a digital asset controlled by a previous transaction.

[0202] In some embodiments, locking script 506 is a script that blocks a transaction by specifying conditions that need to be met in order to transfer an output as described herein. As shown in example problem 500, locking script 506 of transaction 502 cannot query block 504 of the blockchain to, for example, determine the number of transactions or access a specific transaction. As shown in example problem 500, locking script 506 of transaction 502 cannot query block 504 of the blockchain, cannot query block header 508 of block 504, and cannot query transaction 510 of block 504. In block 504 including transaction 502 (represented as transaction Tx in transaction 510 of block 504), the locking script 506 of transaction 502 cannot query block 504 of the blockchain, for example, to determine the number of transactions or access a specific transaction. As shown in example problem 500, locking script 506 of transaction 502 cannot query block 504 of the blockchain, cannot query block header 508 of block 504, and cannot query transaction 510 of block 504. i 512), the locking script 506 of transaction 502 cannot query transaction Tx i 512 (e.g., unable to query the transaction containing the locking script 506). The method described herein enables the locking script 506 of the transaction 502 to query the block 504 of the blockchain, query the block header 508 of the block 504, query the transaction 510 of the block 504, and query the transaction Tx in the transaction 510 of the block 504. i 512 (eg, enabling the locking script to query the transaction containing the locking script 506).

[0203] Figure 6 An example environment 600 is shown in schematic form in accordance with an embodiment, wherein data is verified as a block header, which is used for script-based blockchain interactions. A block header is a portion of a block of a blockchain that contains data about the block. For example, a block header 602 is 80 bytes of data, the first 4 bytes store the version of the blockchain implementation ("nVersion"), the next 32 bytes (or 256 bits) store the hash of the previous block of the blockchain ("HashPrevBlock"), the next 32 bytes store the hash of the Merkle tree of transactions for the block ("HashMerkleRoot", which is described in detail herein), the next 4 bytes store the creation time of the block ("nTime"), the next 4 bytes store the 32-bit difficulty value of the block ("nBits"), and the last 4 bytes store the random seed of the block ("nNonce").

[0204] It can be observed that if the block header 602 is data used as input to the locking script (e.g., provided as an unlocking script), then by encoding the constraints on the block header 602 as the locking script, the unlocking script data must contain a valid block header, otherwise it will not be a valid unlocking script. The three constraints on the block header, such as the block header 602, are: i) 80 bytes long; ii) the nBits field of the block header must be greater than or equal to a certain difficulty value; iii) the double SHA256 of the block header must be less than or equal to the difficulty value. Each of these constraints is shown as a separate script in this article, and the details of the linked scripts (e.g., branch constraints and maintenance stacks) are omitted for ease of illustration.

[0205] When these three scripts are combined with the omitted linker script details, a single script is formed. This is an example of an OP_CHECKBLOCKVERIFY script that verifies the <data>is a valid block header. In the example shown, the three scripts return true or false, but when chained together as a single script to generate an OP_CHECKBLOCKVERIFY script, OP_VERIFY would typically be added to the end of each script. It is contemplated that other implementations of the OP_CHECKBLOCKVERIFY script may be implemented and are considered to be within the scope of the present invention.

[0206] In step 604, the so-called block header is provided as the unlocking script, represented as <data>.

[0207] In step 606, a first script is executed, which verifies <data>The size of is 80 bytes (e.g., the first constraint). Table 2 shows the verification <data>The size of the first script is 80 bytes.

[0208] Table 2

[0209]

[0210] In step 608, a second script is executed that verifies that the "nBits" field of the block header is greater than or equal to the blockchain difficulty value. Table 3 shows a second script that verifies that the "nBits" field of the block header is greater than or equal to the blockchain difficulty value. It should be noted that the difficulty value "<0x1D00FFFF>" of the script shown in Table 3 is the minimum difficulty based on some blockchain specifications. In an embodiment, the difficulty value is used as a data item of the unlocking script. In an embodiment, a higher difficulty value (e.g., a value greater than 0x1D00FFF) is used as a target difficulty. In an embodiment, a lower difficulty value (e.g., a value less than 0x1D00FFF) is used as a target difficulty.

[0211] Table 3

[0212]

[0213] In step 610, a third script is executed, which verifies that the double SHA256 of the block header (implemented by the opcode OP_HASH256 as described above) is less than or equal to the difficulty value represented. Table 4 shows the third script, which verifies that the double SHA256 of the block header is less than or equal to the difficulty value represented. The third script shown in Table 4 introduces two additional opcodes:

[0214] OP_LBYTESHIFT: Perform a left byte shift on data of any size

[0215] OP_BIGLESSTHANOREQUAL: Interprets data of arbitrary size as numbers and compares two numbers to determine whether the first number is less than or equal to the second number

[0216] Table 4

[0217]

[0218] Figure 7 An example process 700 is shown in flowchart form according to an embodiment, and the example process is used to verify that data is a block header in a script-based blockchain interaction. Part or all of process 700 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 jointly executed 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 is permanently stored on a magnetic, optical, or flash memory medium). The example process 700 can be performed by a node of a blockchain network (e.g., in conjunction with Figure 1 102 described above) executes, the blockchain network is combined with Figure 1 The blockchain network 100 described. That is, the node (such as the combination of Figure 1 One of the nodes 102 described above may perform the example process 700 for verifying that data is combined with Figure 7 Such a node may be composed of any suitable computing device (e.g., composed of a server in a data center, composed of a client computing device, composed of multiple computing devices in a distributed system of a computing resource service provider, or composed of any suitable electronic client device such as a combination of Figure 2 The computing device 200 described above is composed of ).

[0219] In step 702 of the example process 700, the system receives <data>In step 704 of the example process 700, the system combines Figure 6 Start the OP_CHECKBLOCKVERIFY script. In step 706 of the example process 700, the system verifies the <data>The size of is 80 bytes. In step 708 of the example process 700, it is determined whether a previous script (eg, the script shown in Table 2 above) passes.

[0220] If it is determined in step 708 of the example process 700 that the previous script did not pass, then in step 718 of the example process 700, <data>Not a valid block header, and the locking script failed to unlock.

[0221] If it is determined in step 708 of the example process 700 that the previous script did pass, then in step 710 of the example process 700, the system verifies that the previous script did pass by executing a script such as that shown in Table 3 above. <data>The "nBits" field of is greater than or equal to the blockchain difficulty. In step 712 of the example process 700, it is determined whether the previous script (e.g., the script shown in Table 3 above) passes.

[0222] If it is determined in step 712 of the example process 700 that the previous script did not pass, then in step 718 of the example process 700, <data>Not a valid block header, and the locking script failed to unlock.

[0223] If it is determined in step 712 of the example process 700 that the previous script did pass, then in step 714 of the example process 700, the system verifies that the previous script did pass by executing a script such as that shown in Table 4 above. <data>The SHA256 of is less than or equal to the desired target. In step 716 of the example process 700, it is determined whether the previous script (eg, the script shown in Table 4 above) passes.

[0224] If it is determined in step 716 of the example process 700 that the previous script did not pass, then in step 718 of the example process 700, <data>Not a valid block header, and the locking script failed to unlock.

[0225] If it is determined in step 716 of the example process 700 that the previous script did pass, then in step 720 of the example process 700, <data>It is a valid block header, and the locking script is unlocked successfully.

[0226] Note that Figure 7 One or more of the operations performed in the example process 700 shown in FIG. 7 may be performed in various orders (including in parallel) and combinations.

[0227] Figure 8 An example environment 800 is schematically illustrated in accordance with an embodiment, wherein data verification is a block header of a previous block for script-based blockchain interaction. As described herein, a block header is a portion of a block of a blockchain that contains data about the block. A portion of the block header is a hash of a previous block header ("HashPrevBlock"). If a first block header is provided as input to a locking script (e.g., provided as part of an unlocking script), and a second block header alleged to be for the next block in the blockchain is also provided as input to the locking script (e.g., provided as part of an unlocking script), then by encoding a constraint that the hash of the first block header is the HashPrevBlock of the second block in the unlocking script, if the hash of the first block header is not the HashPrevBlock of the second block, then the two block headers will not be valid unlocking scripts.

[0228] In step 804, the first block header 802 is provided as the data of the unlocking script (expressed as <data1>), and in step 810, the second block header 808 is provided as data for the unlocking script as shown below (expressed as<Data 2> ). In step 806, the script (such as the above combined Figure 6 and Figure 7 OP_CHECKBLOCKVERIFY script described in<Data 1> is the block header. In step 812, the script (e.g., the above combined Figure 6 and Figure 7 OP_CHECKBLOCKVERIFY script described in<Data 2> It is the block header.

[0229] In step 814, the script is executed to verify the first block header<Data 1> The double SHA256 is equal to the second block header<Data 2> Table 5 shows an example of a script that verifies the first block header.<Data 1> The double SHA256 is equal to the second block header<Data 2> The script shown in Table 5 is an example of an OP_CHECKCHAINVERIFY script to verify<Data 1> is immediately after<Data 2> Valid blocks before. It is contemplated that other implementations of the OP_CHECKCHAINVERIFY script may be implemented and considered to be within the scope of the present invention. It should be noted that the final opcode of the OP_CHECKCHAINVERIFY script shown in Table 5 is OP_EQUAL because the "true" value should be preserved on the stack after execution. In embodiments where the OP_CHECKCHAINVERIFY script is used in conjunction with other scripts, the final OP_EQUAL opcode of the script is changed to an OP_EQUALVERIFY opcode.

[0230] Table 5

[0231]

[0232] Fig. 9 An example process 900 is shown in flowchart form according to an embodiment, and the example process is used to verify that data is a block header of a previous block in a script-based blockchain interaction. Part or all of the process 900 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 jointly executed 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). The example process 900 can be performed by a node (e.g., in conjunction with Figure 1 One of the nodes 102 of the blockchain network described herein) executes, the blockchain network is for example combined Figure 1 The blockchain network 100 described. That is, a node (e.g., a combination of Figure 1 One of the nodes 102 described above may perform an example process 900 for verifying that data is combined with Fig. 9 The block header of the previous block in the script-based blockchain interaction described above. Such a node can be composed of any suitable computing device (e.g., composed of a server in a data center, composed of a client computing device, composed of multiple computing devices in a distributed system of a computing resource service provider, or composed of any suitable electronic client device (e.g., combined with Figure 2 The computing device 200 described is composed of ).

[0233] In step 902 of the example process 900, the system receives<Data 1> and<Data 2> , which are two so-called block headers. In step 904 of the example process 900, the system combines Figure 8 Start to <data1>and<Data 2> OP_CHECKCHAINVERIFY process is performed. In step 906 of the exemplary process 900, the system combines Figure 6 and Figure 7 Through<Data 1> Execute the OP_CHECKCHAINVERIFY script to verify<Data 1> It is the block header.

[0234] In step 908 of the example process 900, a previous script (e.g.,<Data 1> If the OP_CHECKBLOCKVERIFY script on the example process 900) passes (i.e., the OP_CHECKBLOCKVERIFY script returns true). If it is determined in step 908 of the example process 900 that the previous script did not pass, then in step 910 of the example process 900,<Data 1> is not a valid block header, and in step 922 of the example process 900,<Data 1> no<Data 2> , so the unlocking of the locking script fails.

[0235] If it is determined in step 908 of the example process 900 that the previous script did pass, then in step 912 of the example process 900, the system combines the Figure 6 and Figure 7 Verify by executing the OP_CHECKBLOCKVERIFY script <data2>It is the block header.

[0236] In step 914 of the example process 900, a previous script (e.g.,<Data 2> 900) passed (i.e., the OP_CHECKBLOCKVERIFY script returned true). If it is determined in step 914 of the example process 900 that the previous script did not pass, then in step 916 of the example process 900, <data2>is not a valid block header, and in step 922 of the example process 900,<Data 1> no<Data 2> , so the unlocking of the locking script fails.

[0237] If it is determined in step 914 of the example process 900 that the previous script did pass, then in step 918 of the example process 900, the system verifies<Data 1> The double SHA256 is equal to<Data 2> The "HashPrevBlock" field of

[0238] In step 920 of the example process 900, it is determined<Data 1> Is the double SHA256 of <data2>If it is determined in step 920 of the example process 900 that<Data 1> The double SHA256 is not equal to<Data 2> , then in step 922 of the example process 900,<Data 1> no<Data 2> Therefore, the locking script fails to unlock.

[0239] If it is determined in step 920 of the example process 900 that<Data 1> The double SHA256 is equal to<Data 2> , then in step 924 of the example process 900,<Data 1> yes <data2>'s previous block, so the unlocking of the locking script succeeds.

[0240] Note that Fig. 9 One or more of the operations performed in the example process 900 shown in FIG. 9 may be performed in various orders (including in parallel) and combinations.

[0241] Fig.10 An example environment 1000 is shown in schematic form in which data is verified as a block header chain for script-based blockchain interaction according to an embodiment. Fig.10 The example environment 1000 shown is a combination of Figure 8 and Fig. 9 An extension of the described operation. Fig.10 In the example environment 1000 shown in FIG. 1 , the double SHA256 of the first block header 1002 of the block header chain 1010 (i.e., the chain of block headers) is compared with the HashPrevBlock of the second block header 1004 of the block header chain 1010, and the double SHA256 of the second block header 1004 of the block header chain 1010 is compared with the HashPrevBlock of the third block header 1006 of the block header chain 1010, and so on, until the double SHA256 of the second to last block (not shown) of the block header chain 1010 is compared with the HashPrevBlock of the last block header 1008 of the block header chain 1010.

[0242] Example environment 1000 illustrates that the OP_CHECKCHAINVERIFY script shown in Table 5 can be generalized into additional blocks by repeating the script shown in Table 5 for each pair of blocks. Such a script is referred to herein as OP_CHECKBLOCKCHAINVERIFY.

[0243] For example, the OP_CHECKBLOCKCHAINVERIFY script can take multiple block headers in the block header chain and the block header of the block header chain as input parameters and repeatedly execute OP_CHECKCHAINVERIFY. Table 6 shows an example of how to use this script to verify a chain of six block headers.

[0244] Table 6

[0245]

[0246] Table 7 shows an example implementation of OP_CHECKBLOCKCHAINVERIFY that repeats the operation of OP_CHECKCHAINVERIFY for a large number of blocks. In the example implementation of OP_CHECKBLOCKCHAINVERIFY shown in Table 7, this part is repeated to cover <d-1>Range of values ​​that loops through the block header (e.g. <d>Block header cycle <d-1>times) and performs an OP_CHECKCHAINVERIFY operation on each pair of block headers, using the alt stack to preserve and maintain the order.

[0247] Table 7

[0248]

[0249] Fig.11 An example process 1100 according to an embodiment is shown in flowchart form, and the example process is used to verify that data is a block header chain in a script-based blockchain interaction. Part or all of process 1100 can be executed 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 jointly executed on one or more processors. The executable instructions and / or other data can be stored on a non-transitory computer-readable storage medium (for example, a computer program is permanently stored on a magnetic, optical, or flash memory medium). Example process 1100 can be executed by a node (e.g., a combination of a blockchain network) Figure 1 One of the nodes 102 described above) executes, the blockchain network is for example combined Figure 1 The blockchain network 100 described. That is, the node (such as the combination of Figure 1 One of the nodes 102 described above may perform an example process 1100 for verifying that data is combined with Fig.11 Such a node may be composed of any suitable computing device (e.g., composed of a server in a data center, composed of a client computing device, composed of multiple computing devices in a distributed system of a computing resource service provider, or composed of any suitable electronic client device such as a combination of Figure 2 The computing device 200 described above is composed of ).

[0250] In step 1102 of the example process 1100, the system receives an ordered set of data, namely<Data 1> to<Data n> In step 1104 of the exemplary process 1100, the system combines Fig.10 As described, start the OP_CHECKBLOCKCHAINVERIFY script for the ordered data set.

[0251] In step 1106 of the example process 1100, the system selects a first data item (e.g.,<Data 1> In step 1108 of the example process 1100, the system selects a second data item from the ordered data set based at least in part on the order of the ordered data set (e.g.,<Data 2> ). In an embodiment, the system uses, for example, the above combined Figure 6 and Figure 7 The OP_CHECKBLOCKVERIFY script described here verifies that the first data item and the second data item are valid block headers.

[0252] In step 1110 of the example process 1100, the system verifies that the first data item is a previous block of the second data item by performing OP_CHECKCHAINVERIFY on the first data item and the second data item, as shown in Table 5 in conjunction with Figures 8 to 9 shown.

[0253] In step 1112 of the example process 1100, it is determined whether the OP_CHECKCHAINVERIFY scripts on the first data item and the second data item pass (ie, whether the first data item is a previous block header of the block header in the second data item).

[0254] If it is determined in step 1112 of example process 1100 that the OP_CHECKCHAINVERIFY scripts on the first data item and the second data item do not pass, then in step 1114 of example process 1100, the first data item is not a previous block header of the block header in the second data item, and in step 1116 of example process 1100, the ordered set of data is not a valid block header chain.

[0255] If it is determined in step 1112 of the example process 1100 that the OP_CHECKCHAINVERIFY scripts on the first data item and the second data item do pass, then in step 1118 of the example process 1100 , it is determined whether there is more data in the ordered data set.

[0256] If it is determined in step 1118 of the example process 1100 that there is more data in the ordered data set, then in step 1120 of the example process 1100, the second data item becomes the first data item in the example process 1100, in step 1122 of the example process 1100, a new second data item is selected from the ordered data set based at least in part on the order of the data, and in step 1110 of the example process 1100, as shown in Table 5 and in combination Figure 8 and Fig. 9 As described, the system verifies that the new first data item is a previous block of the new second data item by performing OP_CHECKCHAINVERIFY on the new first data item and the new second data item.

[0257] If it is determined in step 1118 of the example process 1100 that there is no more data in the ordered data set, then in step 1124 of the example process 1100, the ordered data set is a valid block header chain.

[0258] Note that Fig.11 One or more of the operations performed in the example process 1100 shown in FIG. 1 may be performed in various orders (including in parallel) and combinations.

[0259] Fig.12 An example environment 1200 is shown in schematic form, according to an embodiment, showing a Merkle tree of block headers that can be used in script-based blockchain interactions. A Merkle tree (also known as a "binary hash tree") is a data structure used to verify the set of transactions in a block. A Merkle tree is a binary tree of cryptographic hashes containing transactions. However, by repeatedly hashing and concatenating the data, a Merkle tree can be stored as a single hash value (e.g., a single 32-byte or 256-bit value).

[0260] In the example environment 1200, a Merkle tree 1204 is generated by: i) computing a hash of each transaction of a block; ii) selecting a pair of hashes and concatenating them together; iii) computing a hash of the concatenated value; iv) repeating the process at successively higher levels of the tree until a final hash value ("Merkle root") is produced. This Merkle root is then inserted into the block header as the "HashMerkleRoot" value.

[0261] For example, starting with transaction 1206, a hash 1208 of the transaction is calculated. As used herein, transaction 1206 will be referred to as T A , the hash 1208 of transaction 1206 will be referred to as H(T A ). Similarly, transaction 1210 (T B ) has hash 1212H(T B ). To generate hash 1216, the left value is concatenated with the right value before hashing 1214, so hash 1216 is H(H(T A )+H(T B )), where the "+" operator is overloaded in this case to represent concatenation (for example, if H(T A ) is "1234", H(T B ) is "5678", then H(T A )+H(T B ) is "12345678", H(H(T A )+H(T B )) is the hash of "12345678".

[0262] The example environment 1200 also illustrates a Merkle branch, which is a set of nodes in a Merkle tree that, in combination with a Merkle root, can be used to verify that data for a particular leaf node (i.e., a particular transaction) is in the Merkle tree. Given a Merkle root and a Merkle branch, the existence of a given transaction (e.g., transaction 1218) in the Merkle tree can be verified in the following manner. First, a hash 1220 of the transaction is calculated. Then, a hash 1224 of the next level in the Merkle tree is calculated. However, as described above, the hash 1224 at the next level in the Merkle tree requires a hash 1222 of another transaction (e.g., a partner transaction of transaction 1218 in the Merkle tree). This hash 1222 is the first node in the Merkle branch.

[0263] Given hash 1224, hash 1226 is calculated at the next level of the Merkle tree. This calculation requires hash 1216 of other transactions (e.g., another branch) of the Merkle tree. This hash 1216 is the second node in the Merkle branch. It can be imagined that at each level of the Merkle tree, the Merkle branch requires the hash of the combination of transactions in the "other" branch of the tree. Therefore, assuming that the left branch of hash 1230 is the branch containing transaction 1218 (which can be calculated as described above), to calculate hash 1230, hash 1228 of the right branch (another node in the Merkle branch) is required. Finally, in order to calculate the Merkle root, hash 1232 of the entire right side of the Merkle tree is required. The Merkle branches that can be used to verify that transaction 1218 is in the Merkle tree 1204 are hash 1230, hash 1228, hash 1216, and hash 1222. Since the depth of the tree is 4, four nodes are in the Merkle tree. It should be noted that the depth of the Merkle tree depends on the number of transactions in the block and is the log2 of the number of transactions (i.e., for 512 transactions, the depth of the tree is 9 and the node for verifying the Merkle branch has 9 nodes, for 1024 transactions, the depth of the tree is 10 and the Merkle branch for verifying the node has 10 nodes, for 2048 transactions, the depth of the tree is 11 and the Merkle branch for verifying the node has 11 nodes, etc.). For example, if the average number of transactions per block in a block is about 2000, the depth of the Merkle tree for a typical block is 11.

[0264] Fig.13 An example environment 1300 is schematically illustrated in accordance with an embodiment, wherein transactions are verified as included in a block header for script-based blockchain interactions. As described herein, a block header is a portion of a block of a blockchain that contains data about the block. A portion of a block header is a Merkle root ("HashMerkleRoot") of a Merkle tree that can be used to verify transactions in the block. If a block header is provided as an input to a locking script (e.g., provided as an unlocking script), along with a transaction and a Merkle branch for the transaction, a constraint can be encoded (the constraint being that the HashMerkleRoot of the block header is the same as the Merkle root calculated from the Merkle branch and the transaction), and if the HashMerkleRoot of the block header is different from the calculated Merkle root, then the block header, Merkle branch, and transaction will not be a valid unlocking script.

[0265] In step 1304, the first block header 1302 is provided as data for the unlocking script (expressed as<Data 1> ). In step 1306, the script, for example, Figure 6 and Figure 7 The OP_CHECKBLOCKVERIFY script is used to verify<Data 1> is the block header. In step 1308, HashMerkleRoot is extracted from the valid block header.

[0266] In step 1312, the Merkle branch 1310 is provided as data for the unlocking script (denoted as<Data 2> ). Merkle branch 1310 may be approximately 10, 11, or 12 nodes, provided in an encoding format that characterizes whether a particular node is a left input to a join operation as described herein or a right input to a join operation, although not shown herein.

[0267] Table 8 shows an example implementation of OP_CALCMERKLEROOT, where the Merkle branch 1310 is provided in an encoded format that includes references to <hash1> ， <x1> ， <hash2> ， <x2>, ..., <hash d >, <x d > and value <d>,in <d>Indicates how many pairs there are in the pair set, each <hash i > is the hash of a value in the Merkle tree, each <x i > is a value (e.g., 0 or 1) that indicates whether it is a left join or a right join. In the example implementation of OP_CALCMERKLEROOT shown in Table 8, <x i The value 1 in > represents a left-hand join, while <x i A value of 0 in > indicates a right-hand connection.

[0268] Table 8

[0269]

[0270] In step 1316, transaction 1314 is provided as data for the unlocking script (denoted as <data3>). In step 1318, the OP_CALCMERKLEROOT script (not shown here) is used to retrieve the Merkle root<Data 2> and transactions<Data 3> Compute the Merkle root.

[0271] In step 1320, the script is executed to verify the<Data 1> The extracted HashMerkleRoot is compared with<Data 2> and<Data 3> Table 9 shows an example of a script that verifies that<Data 1> The extracted HashMerkleRoot is compared with<Data 2> and<Data 3> The script shown in Table 9 is an example of an OP_CHECKBLOCKTXVERIFY script that uses<Data 2> The Merkle branch verifies the block header<Data 1> The block contains<Data 3> It is contemplated that other implementations of the OP_CHECKBLOCKTXVERIFY script may be implemented and may be considered within the scope of the present invention. In the OP_CHECKBLOCKTXVERIFY script shown in Table 9, the OP_CHECKBLOCKVERIFY operation is omitted for ease of illustration.

[0272] Table 9

[0273]

[0274] Fig.14 An example process for verifying that a transaction is included in a block header of a script-based blockchain interaction according to an embodiment is shown in flowchart form. Part or all of process 1400 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 are executed collectively 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). Example process 1400 may be executed by a node (e.g., a combination of a blockchain network) or a plurality of nodes. Figure 1 One of the nodes 102 described above) executes, the blockchain network is for example combined Figure 1 The blockchain network 100 described. That is, the node (such as the combination of Figure 1 One of the nodes 102 described above may perform an example process 1400 for verifying the binding Fig.14 The block headers in the script-based blockchain interaction described herein include transactions. Such a node may be composed of any suitable computing device (e.g., composed of a server in a data center, composed of a client computing device, composed of multiple computing devices in a distributed system of a computing resource service provider, or composed of any suitable electronic client device such as a combination of Figure 2 The computing device 200 described above is composed of ).

[0275] In step 1402 of the example process 1400, as described above in conjunction with Fig.13 As described, the system receives <data1> ， <data2>and<Data 3> In step 1402 of the exemplary process 1400, also as described above in conjunction with Fig.13 As mentioned above, the system<Data 1> ,<Data 2> and<Data 3> Execute the OP_CHECKBLOCKTXVERIFY script.

[0276] In step 1406 of the example process 1400, as described above in conjunction with Figure 6 and Figure 7 As described above, the system uses, for example, the OP_CHECKBLOCKVERIFY script to verify<Data 1> Is a valid block header.

[0277] In step 1408 of the example process 1400, it is determined<Data 1> The OP_CHECKBLOCKVERIFY script on the 1400th step passes. If it is determined in step 1408 of the example process 1400 that<Data 1> 1400, if the OP_CHECKBLOCKVERIFY script on the OP_CHECKBLOCKVERIFY script fails, then in step 1410 of the example process 1400, <data1>is not a valid block header, and in step 1412 of example process 1400,<Data 3> The transaction is verified to no longer have a block header<Data 1> in the block.

[0278] If it is determined in step 1408 of the example process 1400 that<Data 1> If the OP_CHECKBLOCKVERIFY script on the OP_CHECKBLOCKVERIFY script does pass, then in step 1414 of the example process 1400, as described above in conjunction with Fig.13 As mentioned above, the system<Data 1> In step 1416 of example process 1400, as also described above in conjunction with step 13, the system extracts the HashMerkleRoot field from<Data 2> and <data3>Compute the Merkle root.

[0279] In step 1418 of the example process 1400, also as described above in conjunction with Fig.13 As mentioned above, the system verifies<Data 1> The extracted HashMerkleRoot is equal to<Data 2> and<Data 3> The calculated Merkle root.

[0280] In step 1420 of the example process 1400, it is determined that<Data 1> Is the extracted HashMerkleRoot equal to the<Data 2> and<Data 3> In step 1420 of the example process 1400, if it is determined that<Data 1> The HashMerkleRoot extracted is not equal to the<Data 2> and <data3>The Merkle root of the computation, then in step 1412 of the example process 1400,<Data 3> Transactions are verified to no longer have a block header<Data 1> in the block.

[0281] In step 1420 of the example process 1400, if it is determined that<Data 1> The HashMerkleRoot extracted is indeed equal to that obtained from<Data 2> and<Data 3> The calculated Merkle root, then in step 1422 of the example process 1400,<Data 3> Transactions are verified in a block with header<Data 1> in the block.

[0282] Note that Fig.14 One or more of the operations performed in the example process 1400 shown in FIG. 14 may be performed in various orders (including in parallel) and combinations.

[0283] Fig.15 An example environment 1500 is shown in schematic form according to an embodiment, illustrating how the methods described herein may be used to solve the problem of accessing a blockchain associated with script-based blockchain interactions. In the example environment 1500, a transaction 1502 (e.g., in conjunction with Figure 3 The locking script 1506 in the previous transaction, such as the previous transaction 302 or the unlocking transaction 304, can use one or more combinations of Figure 6-14 The method described above is used to query the blockchain 1504. This is combined with Figure 4 The example problem 400 is the opposite. Similarly, in the example environment 1500, the locking script 1506 in the transaction 1502 can use the combination of Figures 6 to 14 One or more of the methods described above can be used to query block 1508 of blockchain 1504. Figure 5 The example problem 500 is the opposite. In an embodiment, the transaction 1510 of block 1508 is the same as transaction 1502 (e.g., transaction Tx i ).

[0284] Fig.16 An example environment 1600 according to an embodiment is shown in schematic form, showing the state of a blockchain associated with a script-based blockchain interaction. The blockchain contains all blocks since the blockchain was created. In the example environment 1600, the block header of the first block 1604 of the blockchain 1602 is a record of the state 1606 of the blockchain 1602 at the minimum nTime (e.g., the earliest or most ancient time). Using the methods described herein, the locking script of the transaction can query the blockchain 1602, can query the first block 1604, and thus can query the state 1606 of the blockchain 1602 at the minimum nTime. Using the methods described herein, the locking script of the transaction can query the blockchain 1602, can query the block 1608 of the blockchain 1602 (which can be a block containing a transaction), and thus can query the state 1610 of the blockchain 1602 at the block's nTime. Using the methods described herein, the locking script of a transaction can query blockchain 1602, can query the latest block 1612 of blockchain 1602, and can therefore query the state 1614 of blockchain 1602 at nTime of the latest block (e.g., can query the current state of the blockchain). The use of this state query is Fig.17 and Fig.18 Described in detail in .

[0285] Fig.17 An example environment 1700 is schematically illustrated in accordance with an embodiment in which the state of a blockchain is confirmed in a script-based blockchain interaction. As described herein, a block header is a portion of a block of a blockchain that contains data about the block. A portion of a block header is a Merkle root ("HashMerkleRoot") of a Merkle tree that can be used to verify transactions in the block. If a block header is provided as input to a locking script (e.g., provided as an unlocking script), along with a transaction and a Merkle branch for the transaction, a constraint can be encoded (the constraint being that the HashMerkleRoot of the block header is the same as the Merkle root calculated from the Merkle branch and the transaction), and if the HashMerkleRoot of the block header is different from the calculated Merkle root, then the block header, Merkle branch, and transaction will not be a valid unlocking script.

[0286] In an embodiment, checking the state of a blockchain and / or confirming the state of a blockchain includes checking other aspects of the blockchain, including, but not limited to, checking block headers of one or more blocks of the blockchain, checking the relationship between one or more blocks of the blockchain, checking the number of blocks of the blockchain, checking one or more transactions in a single block of the blockchain, or checking multiple transactions in multiple blocks of the blockchain.

[0287] In step 1708, the block header 1706 is provided as data for the unlocking script (denoted as <data1>). In one embodiment, the script is such as the above combined Figure 6 and Figure 7 The OP_CHECKBLOCKVERIFY script described here is used to verify <data1>is a block header. In step 1712, as above combined Figure 13 to Figure 14 As described above, the Merkle branch 1710 is provided as data for unlocking the script (expressed as<Data 2> ). In step 1716, transaction 1714 is provided as data for unlocking the script (denoted as <data3>). In one embodiment, as described above in conjunction with Fig.13 and 14 As described, use the OP_CALCMERKLEROOT script to get the Merkle root<Data 2> and transactions<Data 3> Compute the Merkle root.

[0288] In step 1718, the OP_CHECKBLOCKTXVERIFY script is executed to verify the<Data 1> The extracted HashMerkleRoot is compared with the one shown in Table 9 above.<Data 2> and<Data 3> The Merkle root calculated by the executed OP_CALCMERKLEROOT script is the same.

[0289] It should be noted that, according to an embodiment, step 1718 illustrates an example of a script type that can be executed in an environment such as example environment 1700, where the state of the blockchain is confirmed in a script-based blockchain interaction. Step 1718 illustrates a first set of constraints that enables the use of an opcode to inject a data set from the blockchain into a transaction. In an embodiment, as described herein, OP_CHECKBLOCKVERIFY is used to verify that the data set includes a block header. In an embodiment, OP_CHECKBLOCKTXVERIFY (i.e., as shown in step 1718) is used to verify that the data set includes a transaction and that the transaction is included in the block header. It is conceivable that the examples of constraints in the first set of constraints described herein are illustrative examples, and other types of constraints in the first set of constraints may be considered within the scope of the present invention. The second set of constraints is described below with respect to step 1722.

[0290] In example environment 1700, in step 1704, the script is used to verify the block header<Data 1> The block header is a block that is part of a public blockchain, rather than a block that is specifically created to simulate a block of that public blockchain by using a verification script (e.g., OP_CHECKBLOCKCHAINVERIFY) as described above. In an embodiment, the script is used to verify the block header<Data 1> It is the block header of a block that is part of a public blockchain, to which the blockchain 1702 or a complete or partial chain of block headers as described above can be provided.

[0291] In the example environment 1700, in step 1722, the script is used to verify other aspects of the transaction. In step 1720, the transaction 1714 is provided as data for the unlocking script in step 1722 (represented as<Data 3> ). It should be noted that in some embodiments, the transaction <data3> in step 1720 is the transaction <data3> in step 1716.<Data 3> At this point, for example, the OP_CHECKBLOCKTXVERIFY script in step 1718 executes the transaction in step 1716<Data 3> .

[0292] As shown in step 1718 above, it should be noted that step 1722 illustrates an example of a script type that can be executed in an environment such as example environment 1700, in which the state of the blockchain is confirmed in a script-based blockchain interaction according to an embodiment. As described above in conjunction with step 1718, step 1722 illustrates a second set of constraints associated with a data set from a blockchain that is injected into a transaction using an opcode. In an embodiment, the second set of constraints includes constraints on the values ​​of data items of the data set (i.e., constraints that include data items of the data set, for example, are less than, equal to, or greater than the value). In one embodiment, the second set of constraints includes constraints determined based on the data (e.g., if the number of transactions in the block associated with the block header is greater than 100, then execute "A", otherwise, execute "B"). It is contemplated that the examples of constraints in the second set of constraints described herein are illustrative examples, and other types of constraints in the second set of constraints can be considered to be within the scope of the present invention.

[0293] If used to verify the block header in step 1704<Data 1> If the script of the block header of the block (the block is part of the public blockchain, not a block specifically used to simulate the block of the public blockchain) passes, then in step 1718, the OP_CHECKBLOCKTXVERIFY script verifies the<Data 1> The extracted HashMerkleRoot is compared with the <data2>and<Data 3> The Merkle root computed by the executed OP_CALCMERKLEROOT script is the same, and in step 1722, the script for validating other aspects of the transaction passes, and then the lock script succeeds in step 1724. In an embodiment, step 1704 illustrates a third set of constraints associated with a set of data from the blockchain injected into the transaction using the opcode (e.g., a constraint that the block is a block of a public blockchain).

[0294] It should be noted that, as described above, in step 1722, the script for verifying other aspects of the transaction includes constraints of the second set of constraints, which are associated with a set of data from the blockchain injected into the transaction using the opcode. As such, in an embodiment, the second set of constraints includes verification of multiple aspects of the transaction, including but not limited to the transferee, the transferor, the amount of the transaction, or other aspects of the transaction. Additionally, it should be noted that in step 1722, the script for verifying other aspects of the transaction may include aspects of the blockchain, aspects of the chain of block headers, aspects of the block, or other aspects of the blockchain environment. For example, in step 1722, the script for verifying other aspects of the transaction and including constraints of the second set of constraints may include constraints for verifying the nTime of a block, verifying a number of transactions in a block, determining an amount of time that has passed between two blocks, determining a minimum block height, or determining other such aspects of the blockchain environment. It should also be noted that by not including a "verify" opcode at the end of the script (which is used to verify other aspects of the transaction in step 1722), a branching condition can be introduced (e.g., if there are more than 1000 transactions in the block, Alice can unlock; if there are no more than 1000 transactions in the block, Bob can unlock). Examples of branching conditions are described below in conjunction with Fig.30 Describe in more detail.

[0295] Same as step 1704 (the script is used to verify the block header<Data 1> One problem with using a block header that is part of a public blockchain rather than a block specifically created to emulate a block of the public blockchain is that, in some embodiments, it may be computationally quite easy to create a block specifically emulating a block of the public blockchain. Consider, for example, the locking script of Table 10, which requires that the data in the unlocking script include a block header (e.g., the unlocking script may include more than just a block header).<Data 1> ).

[0296] Table 10

[0297]

[0298] In some implementations, if the difficulty (nBits) is set to a minimum value, the data can be a header of a block in a public blockchain, but can also be a completely unrelated block because the data does not require a lot of computing power to generate a block with the minimum difficulty. To prevent this practice, the locking script creator should make the constraints on the locking script difficult enough so that the cost of computing power required to create an alternative blockchain that mimics the public blockchain is much greater than the value that can be unlocked. This can be done by increasing the difficulty (e.g., as shown in Table 3 and combined with Figure 6 and 7 ) or by requiring a longer chain of block headers (e.g., as shown in Table 6 and combined with Fig.10 and 11 This is done by using the block header chain in the script described above.

[0299] Table 11 shows an example of a script for verifying other aspects of the transaction in step 1724 (i.e., determining whether aspects of the second set of constraints and / or the first set of constraints are satisfied). In the example script for verifying other aspects of the transaction shown in Table 11, the data<Data 1> Constrained to contain transactions <data3>The block header of , and the transaction is paid to Bob's public key. It should be noted that for illustration purposes, the " <script to check output of data3is p2kh bob>”脚本。

[0300] 表11

[0301]

[0302] 图18以流程图形式示出了根据实施例的示例过程1800，所述示例过程用于在基于脚本的区块链交互中确认区块链的状态。过程1800的部分或全部可以在配置有可执行指令和 / 或其他数据的一个或多个计算机系统的控制下执行，并且可以实现为在一个或多个处理器上共同执行的可执行指令。可执行指令和 / 或其他数据可以存储在非暂时性计算机可读存储介质上(例如，计算机程序永久存储在磁、光、或闪存介质上)。示例过程1800可以由节点(例如区块链网络的结合图1描述的节点102之一)执行，区块链网络例如为结合图1描述的区块链网络100。也就是说，节点(如结合图1所描述的节点102之一)可执行示例过程1800，用于确认在结合图18描述的基于脚本的区块链交互中的区块链的状态。这样的节点可以由任何合适的计算设备组成(例如，由数据中心中的服务器组成，由客户端计算设备组成，由计算资源服务提供者的分布式系统中的多个计算设备组成，或由任何合适的电子客户端设备例如结合图2描述的计算设备200组成)。

[0303] 在示例过程1800的步骤1802中，系统接收上文结合图17所描述的<Data1>、<Data2>和<Data 3>。

[0304] 在示例过程1800的步骤1804中，如以上文结合图17所述，使用OP_CHECKBLOCKCHAINVERIFY来验证<Data 1>是公共区块链的区块。如上所述，OP_CHECKBLOCKCHAINVERIFY是可用于确定是否满足对数据集合(例如，上述第三约束集合)的约束的脚本的示例。

[0305] 在示例过程1800的步骤1806中，确定<Data 1>是否是公共区块链的区块。如果在示例过程1800的步骤1806中确定<Data 1>不是公共区块链的区块，则在示例过程1800的步骤1808中，<Data 3>的交易被验证不在区块头为<Data1>的区块中，并且在示例过程1800的步骤1810中，锁定脚本解锁失败。

[0306] 如果在示例过程1800的步骤1806中确定<Data 1>是公共区块链的区块，则在示例过程1800的步骤1812中，如表9中所示的示例，系统使用OP_CHECKBLOCKTXVERIFY脚本验证<Data 3>的交易在区块头为<Data 1>的区块中。如上所述，OP_CHECKBLOCKTXVERIFY是脚本的示例，该脚本可用于确定是否满足对数据集合(例如，上述第一约束集合)的约束。在实施例中，OP_CHECKBLOCKTXVERIFY用于验证数据集合包括交易，并验证该交易包括在由区块头标识的区块中。在一个实施例中，使用OP_CHECKBLOCKVERIFY来验证该数据集合包括区块头。

[0307] 在示例过程1800的步骤1814中，确定OP_CHECKBLOCKTXVERIFY是否通过。如果在示例过程1800的步骤1814中确定OP_CHECKBLOCKTXVERIFY没有通过，则在示例过程1800的步骤1816中，<Data 3>的交易不在区块头为<Data 1>的区块中，并且在示例过程1800的步骤1810中，锁定脚本解锁失败。

[0308] 如果在示例过程1800的步骤1814中确定OP_CHECKBLOCKTXVERIFY通过，则在示例过程1800的步骤1818中，系统如本文所述验证交易的一个或多个其他方面(即，验证与数据集合相关联的第二约束集合的约束得以满足。

[0309] 在示例过程1800的步骤1820中，确定交易的一个或多个其他方面是否被验证。如果在示例过程1800的步骤1820中确定交易的一个或多个其他方面未被验证，则在示例过程1800的步骤1810中，锁定脚本解锁失败。

[0310] 如果在示例过程1800的步骤1820中确定交易的一个或多个其他方面被验证，则在示例过程1800的步骤1822中，锁定脚本解锁成功。

[0311] 注意，在图18中示出的示例过程1800中执行的一个或多个操作可以以各种顺序(包括并行地)和组合来执行。

[0312] 图19以示意图形式示出了由实施例解决的在基于脚本的区块链交互中锁定脚本的示例问题1900。在图19中所示的示例问题1900中，先前交易1902中的锁定脚本1906不能直接读取解锁交易1904的字段。

[0313] 如所指出的，在一些实施例中，先前交易1902是包括在区块链中的最新的、确认的交易。同样地，在一些实施例中，解锁交易1904是未来交易，其尚未被确认并且尚未包括在区块链中，该区块链表示尝试转移对由先前交易1902控制的数字资产的至少一部分的控制。

[0314] 如本文所述，在一些实施例中，锁定脚本1906是为了转移输出而通过指定需要满足的条件来阻碍交易的脚本。更具体地，由于区块链系统的验证节点的执行，执行锁定脚本1906用于从执行的解锁脚本接受数据，并基于该数据执行某些操作，并返回结果，该结果表征是否解锁脚本成功执行"解锁”(即，满足其中设置的条件集合)了锁定脚本。在一些实施例中，锁定脚本1906定义了一个或多个数据约束，这些约束必须被满足(例如，被由解锁脚本提供的数据满足)，以便成功进行交易的验证。例如，锁定脚本1906可以要求在解锁脚本中提供某些数据以解锁先前交易1902的相关联的数字资产。

[0315] 图20以示意图形式示出了根据实施例的示例环境2000，该示例环境示出了在基于脚本的区块链交互中锁定脚本对数据的访问。图20描述了示例环境2000，该示例环境2000示出了在实施例中，与先前交易2002的锁定脚本2006不同，本发明的解锁脚本2008有权访问解锁交易2004的字段(例如，根据SIGHASH类型确定的解锁交易字段的集合)。在实施例中，先前交易2002与图19的先前交易1902类似。在实施例中，解锁交易2004与图19的解锁交易1904类似。在一些实施例中，锁定脚本2006具有与图19的锁定脚本1906相似的特性。

[0316] 在一些实施例中，解锁脚本2008是写在交易的输入上的可执行脚本，所述交易上的输入试图满足通过锁定脚本写在交易的输出上的一组条件。解锁脚本也称为"scriptSig”。如上所述，解锁脚本2008被设计为提供根据SIGHASH类型确定的解锁交易字段集合作为锁定脚本的输入，从而使锁定脚本有权访问解锁交易的字段。关于串行化交易的内容和结构的更多细节在图21的描述中示出。

[0317] 图21以示意图的形式示出了根据实施例的示例环境2100，在所述示例环境中，在基于脚本的区块链交互中，从串行化交易字段集合中生成签名。如图21所示，串行交易2110(即，以串行化的特定格式的字节表示的交易)包括交易的字段值集合。在2112中，签名者选择SIGHASH类型和数字k。数字k通常是随机数或伪随机数，以掩蔽 / 保护私钥，因此在本发明中有时被称为"掩蔽数(mask number)”。交易2114的修改后的副本是串行化交易2110的字段集合的示例，所述串行化交易2110的字段集合是根据指定的SIGHASH类型(例如，在示例环境2100中为SIGHASH_NONE+ANYONECANPAY)选择的。签名人对交易2114的修改后的副本进行散列(例如执行OP_HASH256)，从而产生消息m2116。签名人然后例如如上文结合图3所描述的使用SIGHASH类型、消息m、签名人的私钥(例如a)和数字k创建签名。

[0318] 表12示出了典型的锁定和解锁脚本的示例，其中使用OP_CHECKSIG操作码根据实体A的公钥来检查解锁脚本中指定的实体A的假定签名。

[0319] 表12

[0320] 类型脚本解锁脚本<Sig A>锁定脚本<PubK A>OP_CHECKSIG

[0321] 因此，在理解了图21的签名生成的情况下，表13示出了如果示例环境2100中示出的过程的一部分被移动到解锁脚本内，则解锁和锁定脚本的示例。

[0322] 表13

[0323] 类型脚本解锁脚本<SIGHASH Type><m><k>OP_GENSIG锁定脚本<PubK A>OP_CHECKSIG

[0324] 可以进一步修改解锁脚本，以包括计算解锁脚本中的消息m的步骤，如表14所示。

[0325] 表14

[0326]

[0327] 但是请注意，除了SIGHASH类型和根据SIGHASH类型确定的解锁交易字段集合外，该过程的其他操作可以移至锁定脚本，如表15所示。

[0328] 表15

[0329] 类型脚本解锁脚本<SIGHASH Type><Serialized Set of Unlocking Tx Fields>锁定脚本OP_HASH256<k>OP_GENSIG<PubK A>OP_CHECKSIG

[0330] 因此，通过在锁定脚本内移动"OP_HASH256<k>OP_GENSIG”的操作，使得解锁脚本包含SIGHASH类型和根据SIGHASH类型确定的解锁交易字段集合，从而使解锁脚本有效。

[0331] 这样就使得串行化的先前交易被注入到锁定脚本中。表16说明了锁定和解锁脚本如何执行示例环境2100的每个步骤过程并验证交易。

[0332] 表16

[0333]

[0334] 但是请注意，任何提供SIGHASH类型和根据SIGHASH类型确定的解锁交易字段集合的实体都可以接收交易输出。这可能成为本文所述方法的有用特征。例如，智能合约的实施可以允许将合约实施为区块链交易，从而释放合约的创建者和 / 或合约的任何其他方，以确保履行合约而无需要求各方信任彼此，且无需要求各方管理或监视合约。在实施例中，需要与合约进行一些交互。在实施例中，在不与合约交互的情况下自动执行合约。

[0335] 如上所述，任何提供SIGHASH类型和根据SIGHASH类型确定的解锁交易字段集合的实体都可以接收交易输出，所以智能合约可以自动执行(或部分自动执行)。在实施例中，该属性可以通过对解锁交易施加附加约束来限制，使得只有提供SIGHASH类型和根据SIGHASH类型确定的解锁交易字段集合的实体可以接收交易输出。另外，可以对智能合约进行编码，以使得提供SIGHASH类型和根据SIGHASH类型确定的解锁交易字段集合的实体只能以特定方式获得交易输出。

[0336] 在实施例中，智能合约包括用作计算机系统可检测到的信号的值，以使其他计算机系统验证交易。也就是说，通过提供数字资产的至少一部分(该数字资产依据执行与智能合约相关联的交易的验证的情况获得)，可以促使验证实体对交易进行验证。例如，可以创建与1.0的数字资产相关联的智能合约，以使0.9的数字资产到达指定的接收者，而其余0.1的数字资产可以由验证实体声明。以这种方式执行智能合约。可以想到，影响实体以获得交易输出和 / 或执行智能合约的其他方法可以视为是在本发明的范围内。

[0337] 如本文中所使用的，智能合约具有自动执行属性和自我执行属性。智能合约的自动执行属性是两个要素的组合。智能合约的自动执行属性的第一要素是任何实体都可以有效地解锁锁定脚本。当任何实体可以有效地解锁锁定脚本时，任何实体都可以创建引用UTXO和 / 或锁定脚本的有效解锁交易。这是因为没有约束条件要求实体证明自己知道某些秘密(例如，私钥或将产生特定散列的值)。但是，应注意，智能合约的自动执行属性的第一要素限于本文所述。智能合约的自动执行属性的第二要素是智能合约是自动的，因为可能有诱因促使其他方解锁锁定脚本。智能合约的自我执行属性也是两个要素的组合。智能合约的自我执行属性的第一要素是可以将约束写在串行化的解锁交易字段上，然后将这些约束反映在解锁交易中。智能合约的自我执行属性的第二要素是锁定脚本中的约束由区块链网络执行。

[0338] 图22以流程图的形式示出了根据实施例的示例过程2200，所述示例过程用于在基于脚本的区块链交互中引起串行化解锁交易字段集合的注入。示例过程2200中的部分或全部可以在配置有可执行指令和 / 或其他数据的一个或多个计算机系统的控制下执行，并且可以被实现为在一个或多个处理器上共同执行的可执行指令。可执行指令和 / 或其他数据可以存储在非暂时性计算机可读存储介质上(例如，永久存储在磁、光或闪存介质上的计算机程序)。示例过程2200可以由节点(例如区块链网络的结合图1描述的节点102之一)执行，区块链网络例如为结合图1描述的区块链网络100。也就是说，节点(如结合图1所描述的节点102之一)可执行示例过程2200，用于在结合图22描述的基于脚本的区块链交互中引起串行化的解锁交易字段的注入。这样的节点可以由任何合适的计算设备组成(例如，由数据中心中的服务器组成，由客户端计算设备组成，由计算资源服务提供者的分布式系统中的多个计算设备组成，或由任何合适的电子客户端设备例如结合图2描述的计算设备200组成)。

[0339] 示例过程2200包括串行化的操作，其中，执行示例过程2200的系统结合图21中描述的方式执行未验证交易的解锁脚本和锁定脚本，因此而获得SIGHASH类型和交易字段值集合，生成签名，并验证签名。

[0340] 在示例过程2200的步骤2202中，系统从寻求数字资产控制权转移的实体获得未验证的交易。未验证的交易包括锁定脚本和解锁脚本。解锁脚本由系统在执行锁定脚本之前执行。解锁脚本可能类似于上文表15和表16中所示的解锁脚本，并且表征SIGHASH类型和未验证交易的串行化字段。在示例过程2200的步骤2204中，执行示例过程2200的系统获得所表征的SIGHASH类型，并且在示例过程2200的步骤2206中获得未验证交易的串行化交易字段值。在实施例中，在成功完成解锁脚本的执行时，系统开始使用主堆栈的状态(以及在一些实施方式中为替代堆栈的状态)执行锁定脚本。锁定脚本可与上文表15和表16中所示的锁定脚本类似。

[0341] 在示例过程2200的步骤2208中，根据锁定脚本，系统至少使用SIGHASH类型和由于执行解锁脚本而写在主堆栈上的交易字段值集合和与公私钥对关联的私钥来生成签名。在示例过程2200的步骤2210中，根据锁定脚本，系统根据密钥对的公钥成功地验证了签名。这样，通过解锁脚本使交易字段集被注入到锁定脚本中。

[0342] 注意，在图22中示出的示例过程2200中执行的一个或多个操作可以以各种顺序(包括并行地)和组合执行。

[0343] 图23以示意图形式示出了由实施例解决的在基于脚本的区块链交互中锁定脚本的示例问题。在图23中示出的示例问题2300中，锁定脚本2306不能读取其所嵌入的交易的输入，因此，不能直接读取先前交易的字段。

[0344] 在一些实施例中，交易2304与本文所述的解锁交易类似，其表示尝试转移对由先前交易控制的数字资产的至少一部分的控制。如上文所述，在一些实施例中，与本文所述的锁定脚本类似，锁定脚本2306是为了转移输出而通过指定需要满足的条件来阻碍交易的脚本。

[0345] 图24以示意图的形式示出了根据实施例的示例环境2400，在所述环境中，在基于脚本的区块链交互中引起先前的串行化交易的注入。图24中所示的示例环境2400示出了具有解锁脚本2408的解锁交易2404，解锁脚本2408利用了来自先前交易2402A-02B的输出。可以看出，解锁脚本使已串行化的先前交易被检索。在一些示例中，串行化的先前交易是指先前交易的字段值集合的未修改版本。

[0346] 图24所示的实施例可以通过观察到交易ID是串行化交易的双SHA256并且交易ID与交易一对一映射来理解。因此，通过应用表17中所示的约束，可以使交易注入到解锁脚本中。

[0347] 表17

[0348] 类型脚本解锁脚本<Serialized Tx>锁定脚本OP_HASH256<Tx ID>OP_EQUAL

[0349] 本发明的实施例通过不仅引起任何串行化交易的注入，而且还通过引起在解锁交易2404的输入中引用的一个或多个串行化的先前交易(例如，先前交易2402A-02B)的注入，进一步改善了这种注入。如上文参考图21所述，可以使根据SIGHASH类型确定的解锁交易字段集合经由解锁脚本2406注入到锁定脚本中。图25示出了根据指定的SIGHASH类型在串行化交易中包括哪些字段。

[0350] 图25以示意图的形式示出了根据实施例的示例环境2500，其中，在基于脚本的区块链交互中，所述字段集合基于签名散列类型而可用。但是，请注意，图25的目的在于说明，在各种实施例中有更多比图25中描述的SIGHASH类型。如图25所示，在具有不同的SIGHASH类型的情况下，在根据SIGHASH类型确定的解锁交易字段集合中包括不同的先前交易ID集合(注意，"散列”字段以高位编址格式表示交易ID)。在一些实施例中，不管指定了哪种SIGHASH类型，嵌入锁定脚本的先前交易的交易ID总是可用的。

[0351] 因此，可以使某些字段在解锁交易字段集合中显示，所述解锁交易字段集合通过以下方式约束SIGHASH类型来确定：首先，复制SIGHASH类型。然后，将SIGHASH类型压入堆栈(例如SIGHASH_ALL)。最后，调用OP_EQUALVERIFY。从图25中可以看出，SIGHASH_ALL(如所示解锁交易2504A)包括先前交易"y”和"z”的散列，而且如所表示的，代表交易ID。相反，SIGHASH_ALL|ANYONECANPAY(如所示解锁交易2504B)仅包括紧邻的先前交易"y”的散列。在一些实施例中，解锁交易2504A-04B与图19的解锁交易1904类似。图19表示尝试转移对由先前交易(例如，交易y和 / 或x)控制的数字资产的至少一部分的控制。可以通过使用子串操作码解析串行化的交易直到得到期望的字段来完成提取交易ID的操作，如图26所示。

[0352] 图26以示意图形式示出了根据实施例的示例环境2600，其中，在基于脚本的区块链交互中从串行化交易中提取交易标识符。在图26中所示的示例环境2600中，由高位编址格式的交易ID组成的散列2620是串行化交易2610的子串，串行化交易2610的子串可以通过使用子串操作码在脚本中提取。在一些实施例中，首先解析串行化交易1020来在可以提取交易ID前识别散列2620的位置，因为一些字段(例如，#vin，scriptSigLen，scriptSig，scriptPubKeyLen和scriptPubKey)的字节长度是可变的。然而，可以想到，在字段具有固定长度的实施中，解析可能不是必需的。

[0353] 因此，在一些实施例中，通过构建锁定脚本，该锁定脚本以参照图22描述的方式在解锁交易中强制注入引用的特定串行化的先前交易，可以使先前的交易ID可访问。例如，首先确定SIGHASH类型的约束，提取交易ID，复制串行化的先前交易，并按照从解锁交易串行化字段集合(根据SIGHASH类型)提取的交易ID对串行化的先前交易进行检查。注意，可以执行此过程以强制注入多个不同的串行化先前交易。作为示例，表18提供了一个脚本，该脚本引起与交易X的输入相对应的先前交易的注入。表18中所示的脚本是OP_PREVTXINJECTION脚本的一个示例，该脚本引起与解锁脚本的输入X相对应的先前交易的注入。

[0354] 表18

[0355]

[0356] 但是，注意，任何提供SIGHASH类型、根据SIGHASH类型确定的解锁交易字段集合、以及串行化的先前交易的实体都可以获取如本文所述的交易输出。

[0357] 作为另一个示例，表19提供了一个脚本，该脚本引起与正被签名的输入相对应的先前交易的注入。表19中显示的脚本是OP_SELFTXINJECTION脚本的示例，该脚本引起与正被签名的输入相对应的先前交易的注入。

[0358] 表19

[0359]

[0360] 注意，提供SIGHASH类型、根据SIGHASH类型确定的解锁交易字段集合、以及串行化的先前交易的任何实体都可以接收如本文所述的交易输出。

[0361] 图27以流程图形式示出了根据实施例的示例过程2700，在基于脚本的区块链交互中，所述示例过程用于引起先前串行化交易的注入。示例过程2700中的部分或全部可以在配置有可执行指令和 / 或其他数据的一个或多个计算机系统的控制下执行，并且可以被实现为在一个或多个处理器上共同执行的可执行指令。可执行指令和 / 或其他数据可以存储在非暂时性计算机可读存储介质上(例如，永久存储在磁、光或闪存介质上的计算机程序)。示例过程2700可以由节点(例如区块链网络的结合图1描述的节点102之一)执行，区块链网络例如为结合图1描述的区块链网络100。也就是说，节点(如结合图1所描述的节点102之一)可执行示例过程2700，用于使得在结合图27描述的基于脚本的区块链交互中注入串行化的先前交易。这样的节点可以由任何合适的计算设备组成(例如，由数据中心中的服务器组成，由客户端计算设备组成，由计算资源服务提供者的分布式系统中的多个计算设备组成，或由任何合适的电子客户端设备例如结合图2描述的计算设备200组成)。

[0362] 示例过程2700包括串行化的操作，其中，执行示例过程2700的系统对未验证交易的解锁脚本和锁定脚本结合执行，从而获得与从未验证交易中提取的交易ID相对应的串行化的先前交易。

[0363] 在示例过程2700的步骤2702中，系统从寻求转移对数字资产的控制的实体获得未验证的交易。未验证的交易包括锁定脚本和解锁脚本。锁定脚本和解锁脚本可与表18和19中所示的锁定脚本和解锁脚本类似。也就是说，锁定脚本包括一组指令，这些指令(例如通过解锁脚本)以输入值的形式存储在主堆栈和备用堆栈中。如果指令集的执行评估为真，则指令集的执行将成功验证未验证的交易。因此，解锁脚本在锁定脚本之前执行，从而在主堆栈和备用堆栈中设置要由锁定脚本使用的值。图27的实施例中的未验证交易的解锁脚本示出串行化的先前交易、SIGHASH类型、和串行化的解锁交易字段集合。

[0364] 由于执行锁定脚本后再执行解锁脚本，在示例过程2700的步骤2704中，系统获得串行化的先前交易、SIGHASH类型、和在解锁脚本中指定的串行化的解锁交易字段集合。在示例过程2700的步骤2706中，系统基于基于SIGHASH的未验证交易的字段值的串行化集合来签名。注意，SIGHASH类型影响在签名生成中使用哪些字段，并且所需的SIGHASH可能取决于所寻求的特定先前交易。例如，表18说明了用于提取先前交易的锁定脚本和解锁脚本，但不一定提取包含相同锁定脚本的先前交易，表18利用了SIGHASH类型的SIGHASH_ALL。如图25所示，SIGHASH_ALL类型使得能够检索解锁交易的其他先前交易的输入。相反，表19说明了用于提取具有相同锁定脚本的先前交易(即，与正被签名的输入相对应的先前交易)的锁定脚本和解锁脚本，表19利用了SIGHASH类型的SIGHASH_ALL|ANYONECANPAY。如图25所示，SIGHASH类型的SIGHASH_ALL|ANYONECANPAY除去了具有正被签名的输入的先前交易之外的其他先前交易的输入。

[0365] 在示例过程2700的步骤2708中，系统验证先前生成的签名。在示例过程2700的步骤2710中，系统通过执行所获得的串行化的先前交易的双SHA256来产生应当与解锁交易的交易ID匹配的值(即，字段值的串行化集合)。使用子串操作码，在示例过程2700的步骤2712中，系统提取字段值的串行化集合的交易ID，并且在示例过程2700的步骤2714中，系统确定由串行化的先前交易的双SHA256产生的交易ID与串行化的字段值集合的交易ID是否匹配。注意，在各种实施例中，匹配不一定需要相等。例如，如果两个值不相等，但在数学上等同，则可以匹配。又例如，如果两个值对应于公共对象(例如，值)或以某种预定方式互补和 / 或两个值满足一个或多个匹配标准，则两个值可以匹配。通常，可以使用确定是否存在匹配的任何方式。

[0366] 注意，在图27中示出的示例过程2700中执行的一个或多个操作可以被以各种顺序(包括并行地)和组合来执行。

[0367] 图28以示意图形式示出了根据实施例的示例环境2800，在所述环境中，区块链的状态用于基于脚本的区块链交互。如本文所述，区块头是区块链的区块的一部分，所述区块链包含有关该区块的数据。

[0368] 在步骤2804中，提供区块头2802作为用于本文所述的解锁脚本的数据(表示为<Data 1>)。在实施例中，例如上文结合图6至图7描述的OP_CHECKBLOCKVERIFY脚本用于验证<Data 1>是区块头。在步骤2808中，提供默克尔分支2806作为用于如上文结合图13至图14描述的解锁脚本的数据(表示为<Data 2>)。在步骤2812中，提供交易2810作为用于解锁脚本的数据(表示为<Data 3>)。在实施例中，使用如上文结合图13和14所述的OP_CALCMERKLEROOT脚本从默克尔根<Data 2>和交易<Data 3>计算出默克尔根。

[0369] 在步骤2814中，执行OP_CHECKBLOCKTXVERIFY脚本以验证从<Data 1>提取的HashMerkleRoot与从OP_CALCMERKLEROOT脚本计算的默克尔根相同，所述OP_CALCMERKLEROOT脚本是对上文表9所示的和结合图13、14和17描述的<Data 2>和<Data 3>执行的。

[0370] 在步骤2816中，执行OP_SELFTXINJECTION脚本以验证<Data 3>的交易的解锁脚本包括串行化交易，该串行化交易包含上表18和19中所示的和结合26、27和28所描述的锁定脚本。

[0371] 在步骤2818中，如上文所述，如果2814的OP_CHECKBLOCKTXVERIFY脚本和步骤2816的OP_SELFTXINJECTION成功，则已知具有区块头<Data 1>的区块包括交易<Data 3>，<Data3>的解锁脚本包括锁定脚本的串行化交易，且锁定脚本可以访问区块链状态。这样的锁定脚本有权访问的信息包括但不限于时间(即，来自一个或多个区块头的nTime字段)，伪随机数(即，来自nNonce或HashMerkleRoot，两者都是伪随机数的良好来源)或其他信息，这些信息中的一些或全部可以在锁定脚本中使用。这样的附加信息的示例在图30所示的示例中示出。

[0372] 在实施例中，脚本用于验证区块头<Data 1>是作为公共区块链的一部分的区块的区块头，而不是如上所述通过使用验证脚本(例如OP_CHECKBLOCKCHAINVERIFY)专门为模拟该公共区块链的区块而建立的区块。在实施例中，脚本用于验证区块头<Data 1>是作为公共区块链的一部分的区块的区块头，可以将区块链1702或如上文所述完整或部分区块头链提供给所述公共区块链。

[0373] 在实施例中，脚本也可以用来验证如上文结合图17所描述的交易和 / 或区块链状态的其他方面。如上文所述，用来验证交易的其他方面的脚本可以包括交易的多个方面的验证，包括但不限于受让人，转让人，交易数量或交易的其他方面。此外，应注意，用于验证交易其他方面的脚本可包括区块链的各个方面，区块链状态的各个方面，区块头链的各个方面，区块的各个方面或区块链环境的其他各个方面。例如，用于验证交易其他方面的脚本可以验证区块的nTime，区块中的交易数量，两个区块之间的经过的时间量，最小区块高度或区块链环境的其他方面。还应注意，通过在脚本(用于验证交易的其他方面)的末尾不包括"验证”操作码，可以引入分支条件(例如，如果在区块中有超过1000个交易，则爱丽丝可以解锁；如果区块中的交易不超过1000个，则鲍勃可以解锁)。下文结合图30对分支条件的示例进行更详细地描述。

[0374] 尽管在示例环境2800中未示出，但是在实施例中，用于验证交易的其他方面的附加脚本，例如表11中示出的并且结合图17所描述的脚本，可以作为图28中描述的示例环境2800的一部分来执行。

[0375] 图29以流程图形式示出了根据实施例的示例过程2900，所述示例过程为在基于脚本的区块链交互中使用区块链的状态的示例过程。过程2900的部分或全部可以在配置有可执行指令和 / 或其他数据的一个或多个计算机系统的控制下执行，并且可以被实现为在一个或多个处理器上共同执行的可执行指令。可执行指令和 / 或其他数据可以存储在非暂时性计算机可读存储介质上(例如，永久存储在磁、光、或闪存介质上的计算机程序)。示例过程2900可以由节点(例如区块链网络的结合图1描述的节点102之一)执行，区块链网络例如为结合图1描述的区块链网络100。也就是说，节点(如结合图1所描述的节点102之一)可执行示例过程2900，所述示例过程用于在结合图29描述的基于脚本的区块链交互中使用区块链的状态。这样的节点可以由任何合适的计算设备组成(例如，由数据中心中的服务器组成，由客户端计算设备组成，由计算资源服务提供者的分布式系统中的多个计算设备组成，或由任何合适的电子客户端设备例如结合图2描述的计算设备200组成)。

[0376] 在示例过程2900的步骤2902中，系统接收如上文结合图17所描述的<Data1>，<Data 2>和<Data 3>。

[0377] 在示例过程2900的步骤2904中，如以上文结合图17所述，使用OP_CHECKBLOCKCHAINVERIFY来验证<Data 1>是公共区块链的区块。

[0378] 在示例过程2900的步骤2906中，确定<Data 1>是否是公共区块链的区块。如果在示例过程2900的步骤2906中确定<Data 1>不是公共区块链的区块，则在示例过程2900的步骤2908中，<Data 3>的交易被验证不在具有区块头<Data1>的区块中，并且在示例过程2900的步骤2910中，锁定脚本不可以访问区块链状态。

[0379] 如果在示例过程2900的步骤2906中确定<Data 1>是公共区块链的区块，则在示例过程2900的步骤2912中，如表9中所示的示例，系统使用OP_CHECKBLOCKTXVERIFY脚本验证<Data 3>的交易在具有区块头<Data 1>的区块中。

[0380] 在示例过程2900的步骤2914中，确定OP_CHECKBLOCKTXVERIFY是否通过。如果在示例过程2900的步骤2914中确定OP_CHECKBLOCKTXVERIFY没有通过，则在示例过程2900的步骤2916中，<Data 3>的交易不在具有区块头<Data 1>的区块中，并且在示例过程2900的步骤2910中，锁定脚本不可以访问区块链状态。

[0381] 如果在示例过程2900的步骤2914中确定OP_CHECKBLOCKTXVERIFY通过，则在示例过程2900的步骤2918中，系统使用OP_SELFTXINJECTION脚本(例如表19中所示的脚本)来验证<Data 3>中的交易的解锁脚本包括锁定脚本的串行化交易。

[0382] 在示例过程2900的步骤2920中，确定<Data 3>中的交易的解锁脚本是否包括锁定脚本的串行化交易。如果在示例过程2900的步骤2920中确定<Data3>中的交易的解锁脚本不包括锁定脚本的串行化交易，则在示例过程2900的步骤2910中，锁定脚本不可以访问区块链状态。

[0383] 如果在示例过程2900的步骤2920中确定<Data 3>中的交易的解锁脚本确实包括锁定脚本的串行化交易，则在示例过程2900的步骤2922中，锁定脚本有权访问区块链状态。

[0384] 注意，在图29中示出的示例过程2900中执行的一个或多个操作可以以各种顺序(包括并行地)和组合来执行。

[0385] 图30以示意图形式示出了根据实施例的在基于脚本的区块链交互中使用区块链的状态的示例实施方式3000。示例实施方式3000示出了本文描述的方法的几个方面。在示例实施方式3000中，基于包含风险投资的交易的区块和紧邻的先前区块之间的时间差，决定对包含风险投资的交易的区块添加到公共区块链的时间做风险投资。每人放置一份数字资产，如果时间差少于10分钟，则两份数字资产归爱丽丝所有。相反，如果时间差不少于10分钟，则两份数字资产归鲍勃所有。

[0386] 爱丽丝用数字资产3004为她的那半风险投资交易3002提供资金，鲍勃用数字资产3006为他的那半风险投资交易3002提供资金。风险投资交易3002指出，如果时间差(t2-t1)小于10分钟，则爱丽丝得到两份数字资产3008。相反，如果时间差(t2-t1)不小于10分钟，则鲍勃得到两份数字资产3008。

[0387] 使用本文描述的方法，可以确定风险投资交易3002是否在具有区块头3014的区块B2中。类似地，使用本文描述的方法，可以确定具有区块头3012的区块B1是否是紧邻的先前区块。最终，可以确定区块头3014的nTime是否在区块头3012的nTime之后十分钟内，并且因此，可以将两份数字资产3008转移到爱丽丝或鲍勃。

[0388] 表20示出了该风险投资交易3002的示例锁定脚本。本文未示出表20所示的脚本中使用的OP_EXTRACTTIME脚本，但是，可以想到，OP_EXTRACTTIME脚本是用于从区块头中提取时间条目的脚本，该区块头与表3中所示的用来提取nBit的脚本类似。

[0389] 表20

[0390]

[0391] 因此，说明书和附图应被认为是说明性的而不是限制性的。然而，显而易见的是，在不脱离权利要求中所阐述的本发明的更广泛精神和范围的情况下，可以对其进行各种修改和改变。

[0392] 其他变型在本发明的精神内。因此，尽管所公开的技术易于进行各种修改和替代，但是其示出的某些实施例在附图中示出并且已经在上文进行了详细描述。然而，应当理解，无意将本发明限制为所公开的一种或多种特定形式，相反，其意图是涵盖所附权利要求书中所定义的落入本发明的精神和范围内的所有修改，替代构造和等同物。

[0393] 在描述所公开的实施例的上下文中(特别是在所附权利要求的上下文中)术语"一个”和"一种”("a”，"an”，"the”)以及类似指代的使用应解释为涵盖单数和复数，除非本文另有说明或与上下文明显矛盾。除非另有说明，否则术语"包括(comprising”)，"具有(having)”，"包括(including)”和"包含("containing)”应解释为开放式术语(即，意思是"包括但不限于”)。术语"连接”在未修改的情况下指的是物理连接时，应理解为部分或全部包含在内，连接在一起，即使有某些中介物。本文中数值范围的引用仅旨在用作分别指代落入该范围内的每个单独值的简写方法，除非在本文另外指出并且每个单独值都被并入说明书中使得其类似于在本文中被单独叙述。术语"集合”(例如，"一组项目”)或"子集”的使用应被解释为包括一个或多个成员的非空集合，除非上下文另外指出或有矛盾。此外，对应集合的术语"子集”不一定表示对应集合的适当子集，而是该子集和对应集合可以相等，除非上下文另外指出或有矛盾。

[0394] 除非另有明确说明或与上下文明显矛盾，否则应将"A、B、和C中的至少一个”或"A、B和C中的至少一个”形式的连接语言结合上下文一起理解，通常用于表示项目、术语等可以是A或B或C，也可以是A和B和C的集合的任何非空子集。例如，在具有三个项目的集合的说明性示例中，连接语"A、B、和C中的至少一个”和"A、B和C的至少一个”指的是以下集合中的至少一个：{A}，{B}，{C}，{A，B}，{A，C}，{B，C}，{A，B，C}。因此，这种连接语通常不意在表示某些实施例要求存在至少一个A，至少一个B和至少一个C。

[0395] 本文描述的过程的操作可以以任何合适的顺序执行，除非本文另外指出或与上下文明显矛盾。本文描述的过程(或其变型和 / 或组合)，可以通过硬件或其组合，在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可以实现为在一个或多个处理器上共同执行的代码(例如，可执行指令，一个或多个计算机程序或一个或多个应用程序)。该代码可以例如以计算机程序的形式存储在计算机可读存储介质上，该计算机程序包括可由一个或多个处理器执行的多个指令。所述计算机可读存储介质可以是非暂时性的。

[0396] 除非另外要求，否则本文提供的任何和所有示例或示例性语言(例如，"例如”)的使用仅旨在更好地阐明本发明的实施例，并且不对本发明的范围构成限制。说明书中的任何语言都不应解释为表示任何未要求保护的元素对于实施本发明必不可少。

[0397] 本文描述了本发明的实施例，包括发明人已知的用于实施本发明的最佳方式。通过阅读前述说明，那些实施例的变型对于本领域普通技术人员而言将变得显而易见。发明人期望有经验的技术人员适当地采用这样的变型，并且发明人希望以不同于本文具体描述的方式来实践本发明的实施例。因此，本发明的范围包括适用法律所允许的所附权利要求中记载的主题的所有修改和等同物。而且，除非本文另外指出或与上下文明显矛盾，否则上述元件在其所有可能的变型中的任何组合均被本发明的范围涵盖。

[0398] 应注意，在描述本发明的实施例的上下文中，除非另有说明，否则与可执行指令(也称为代码，应用程序，代理等)相关的表达的使用表示指令正在由机器执行，从而使机器执行指定的操作。所述可执行指令执行的操作为："指令”通常不在没有辅助的情况下执行(例如，数据的传输、计算等)。

[0399] 应当注意，上述实施例说明而不是限制本发明，并且本领域技术人员将能够在不脱离由所附权利要求限定的本发明的范围的情况下设计许多替代实施例。在权利要求中，括号中的任何附图标记不应被解释为对权利要求的限制。词语"包括(comprising)”和"包括(comprises)”等不排除任何权利要求或说明书整体中列出的元件或步骤之外的元件或步骤的存在。在本说明书中，"包括(comprises)”是指"包括(includes)或者由……组成(consists of)”，而"包括(comprising)”是指"包括(including)或者由……组成(consisting of)”。元件的单数引用不排除这些元件的复数引用，反之亦然。本发明可以通过包括几个不同元件的硬件以及通过适当编程的计算机来实现。在列举了几个装置的设备权利要求中，这些装置中的几个可以由同一个硬件来实现。在相互不同的从属权利要求中引用某些措施这一事实并不表示这些措施的组合不能有利地使用。< / script> < / data1> < / d> < / d> < / hash2> < / x1> < / hash1> < / d> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / data> < / m>

Claims

1. A computer-implemented method comprising: A first transaction related to a digital asset is received at a node in a blockchain network, the first transaction specifying at least: a first set of constraints on a second transaction, the second transaction being used to transfer control of a digital asset, the first set of constraints comprising one or more constraints causing the second transaction to include a set of data from a blockchain; wherein the first set of constraints comprises a constraint that the set of data includes a third transaction from a block of the blockchain; and a second constraint set for the second transaction, the second constraint set comprising one or more constraints, the one or more constraints being associated with data items of the data set; verifying that the first set of constraints and the second set of constraints are satisfied; and The digital asset is reassociated based at least in part on the verification.

2. The computer-implemented method of claim 1, wherein the set of data is received at a node of the second transaction.

3. The computer-implemented method of claim 1 or 2, further comprising verifying the second transaction as a result of the verifying.

4. The computer-implemented method of claim 3, wherein verifying the second transaction is successfully performed without verifying that the entity that created the second transaction has access to secret information.

5. A computer-implemented method according to any one of claims 1 to 4, wherein the first set of constraints includes the constraint that the data set includes a block header chain, the block header chain includes an ordered set of block headers, the ordered set of block headers includes multiple block headers, and the ordered set of block headers specifies an order associated with the multiple block headers.

6. A computer-implemented method according to any one of claims 1 to 5, wherein the second set of constraints comprises constraints on values ​​of data items of the data set.

7. A computer-implemented method according to any one of claims 1 to 6, wherein the second set of constraints comprises constraints derived from one or more values ​​associated with data items of the data set.

8. The computer-implemented method of any one of claims 1 to 7, wherein the first set of constraints is included in a locking script of the first transaction.

9. The computer-implemented method of any one of claims 1 to 8, wherein the second set of constraints is included in a locking script of the first transaction.

10. The computer-implemented method of any one of claims 1 to 9, wherein the first set of constraints comprises a constraint that the set of data is received from a public blockchain.

11. The computer-implemented method of claim 10, wherein the node determines whether a constraint of receiving the set of data from the public blockchain is satisfied by at least: Receiving a first set of blocks and a second set of blocks in the second transaction, the first set of blocks including blocks before the block received from the blockchain network, and the second set of blocks including blocks after the block received from the blockchain network; Verifying that the first set of blocks is linked to blocks received from the blockchain network; verifying that the second set of blocks is linked to blocks received from the blockchain network; verifying that the first set of blocks and the second set of blocks are valid; and Verify that each block in the first set of blocks and the second set of blocks has a difficulty value greater than a predetermined value.

12. A system comprising: processor; and A memory comprising executable instructions, wherein the processor executes the instructions so that the system performs the computer-implemented method according to any one of claims 1 to 11.

13. A non-transitory computer-readable storage medium storing executable instructions, wherein a processor of a computer system executes the executable instructions so that the computer system at least performs the computer-implemented method of any one of claims 1 to 11.

Images