System and method for a simultaneous bytecode interpreter implemented by a blockchain

Abstract

To provide a system and a method for simultaneous bytecode interpretation implemented by a block-chain.SOLUTION: A method generates and / or verifies a payment block-chain transaction. The payment block-chain transaction is a plurality of lock scripts, each lock script representing an instance of an execution thread. The execution thread is an execution thread branched from an execution thread represented by a lock script of a previous block-chain transaction and / or an execution thread of at least one previous block-chain transaction managed and / or controlled for inter-thread communication and control, and includes a plurality of lock scripts or a lock script representing an instance of an execution thread combined from a plurality of execution threads represented by the at least one previous block-chain transaction.SELECTED DRAWING: Figure 1A

Description

Technical Field

[0001] The present invention generally relates to a computer-implemented method for processing blockchain transactions, and more particularly to implementing a lock script within the structure of blockchain transaction processing to support concurrent and / or asynchronous thread execution. The present invention is particularly suitable for use in methods and apparatuses for processing and transacting within smart contract transactions, although not limited thereto.

Background Art

[0002] As used herein, the term "blockchain" represents any of several types of electronic, computer-based, distributed ledgers. These include consensus-based blockchains and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin blockchain. The example of Bitcoin may be referred to herein for convenience and illustrative purposes in the present disclosure, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are included within the scope of the present invention. For example, the present invention may be useful in other blockchain implementations having similar limitations as Bitcoin regarding what constraints can be encoded within a transaction. The term "Bitcoin" is used herein to include any variations of the Bitcoin protocol.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system. This ledger is composed of blocks, and the blocks may be composed of transactions and other information. A blockchain system or blockchain network has a plurality of blockchain nodes and a set of operations. The blockchain nodes may be configured to execute some or all of the operations in the set of operations. The various blockchain nodes may be implemented as computer hardware, computer software, or a combination of both, and may be operated by node operators. Here, the node operators may be independent and unrelated to other node operators. Each of the blockchain nodes may maintain a copy of the blockchain ledger or some portion thereof. The set of operations may include generating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating new blocks (mining) for proposed additions to the blockchain ledger, communicating with other blockchain nodes, and providing a wallet function to users for managing blockchain assets.

[0004] The blockchain ledger is decentralized in that there is no single blockchain node or entity that determines when the ledger is changed. Instead, blockchain nodes are programmed with knowledge of the rules of the blockchain protocol to verify the blockchain ledger and to verify that the actions taken by other blockchain nodes are consistent with their results. The term "blockchain" may refer to the fact that the blockchain ledger consists of a series of blocks chained together, where each block can be represented as a data structure in computer memory, is readable by a computer process, and is transmissible as data. A block contains one or more transactions, and the transactions can also be represented as data structures in computer memory, are readable by a computer process, and are transmissible as data. The blocks are chained, with each new block officially added to the blockchain containing an immutable reference to the previous block, which in turn contains an immutable reference to the block before it, and so on.

[0005] One of the rules of the blockchain protocol is that once a block is added to the blockchain, it cannot be changed, i.e., it is immutable, and the only possibility for changing the blockchain ledger is the addition of new blocks. As a rule, a blockchain node must not change the blocks that are in its copy of the blockchain ledger, but can only add blocks, and thus is programmed to only add a block after performing a verification process on the proposed block to ensure compliance with the blockchain protocol. Since a block is immutable once added to the ledger, the transactions within the block are also immutable.

[0006] Some of the nodes in the blockchain network operate to generate transactions. The generation of transactions may be considered to include operations related to an electronic wallet node, an agent node, or some other node of the blockchain network. When generating a transaction, a blockchain node generates a data object containing the details of the transaction and sends or broadcasts the data object to other blockchain nodes that can be connected in a standard peer-to-peer manner via the blockchain network. Some blockchain nodes operate as "miners", collecting one or more transactions to form a data structure corresponding to a block, performing calculations from something to verify the transactions to be included in the block, solving a puzzle, putting the solution of the puzzle into the data structure, and attempting to propagate the block to other blockchain nodes. The puzzle is a form of important calculation specific to the transaction data and the current state of the blockchain ledger, and may be something like the number of blocks in the ledger and the data from the last added block.

[0007] By making the puzzle transaction-dependent, malicious blockchain nodes cannot propagate the blocks they fabricated before the deadline. By making them solve a nontrivial puzzle, malicious blockchain nodes cannot simply inject blocks into the blockchain network, but are required to perform some significant computational task to prove that the blockchain nodes have made an effort (in short, showing a solution to a difficult problem is "proof-of-work"). Desirably, in the blockchain protocol, proof-of-work is nontrivial, but it is easy to verify that the puzzle has been solved and the work has been done. This means that other blockchain nodes do not necessarily have to trust the blockchain node that is proposing to add a new block to the ledger. When verified by another blockchain node, the blockchain node will add the new block to the end of its own copy of the blockchain ledger and propagate the new block to other blockchain nodes. Since other blockchain nodes perform the same verification, they will also conclude that the block is valid and should be added to the blockchain ledger. Therefore, they add the block to their copy of the blockchain ledger. If a blockchain node determines that the proposed new block is not valid, the node will not add the block to its own copy of the blockchain ledger and will not propagate the block. Since validity in the blockchain is based on consensus, a transaction is considered valid if the majority of the nodes agree that the transaction is valid.

[0008] A blockchain system typically operates in a way that node owners and operators do not necessarily trust other node owners and operators. Instead, the protocol makes it computationally impossible to perform certain actions not permitted by the protocol, such as modifying previous blocks, propagating new blocks without corresponding proof-of-work, or including invalid transactions. When it is computationally impossible to perform actions not permitted by the blockchain protocol in a way that goes undetected by other nodes, specific trust is not required.

[0009] For a transaction to be included in a block written to the blockchain, (1) a mining blockchain node (or verification node) verifies the transaction, (2) the mining blockchain node attempts to propagate the block containing the transaction, and (3) other nodes verify the validity of the block and the validity of the transactions within the block. Note that since mining blockchain nodes are programmed or configured according to these rules, mining blockchain nodes are less likely to include in a block transactions that fail verification, such as blocks that will not be accepted by other nodes and from which the mining node would not benefit. One such benefit of mining for some blockchain systems is that, when a block is accepted, the block is permitted to contain a "reward" transaction, and a certain amount of value is allocated to the operator of the node without requiring a corresponding deduction of value from some other entity. In this way, successful miners are compensated by the value generated by the block. Additionally, as described below, a transaction may include a transaction fee. The transaction fee also goes to the miner controlling the mining blockchain node and requires that the transaction be verifiable as valid for the miner to receive any compensation.

[0010] Transactions within a blockchain network contain various data elements, including transaction value and other data elements. In a decentralized distributed ledger system, the ledger is public, and thus anyone can view the ledger and see the transactions. The blockchain ledger contains a genesis transaction that starts the blockchain and assigns some unit of value to the genesis transaction. Here, for example, for illustrative purposes, the unit of value is cryptocurrency, but other variations using other digital assets are possible.

[0011] Transactions other than the genesis transaction and reward transactions involve the "spending" of the value of one or more existing transactions on the blockchain ledger, and when such a transaction is added to the blockchain ledger, it can also be spent. Each unspent transaction specifies, in a public way, the requirements necessary to spend the value of that transaction. A simple requirement could be "you first must prove that you are Alice, and then you can spend this". Alice then generates a new transaction that "spends" the value of that transaction. Here, Alice's new transaction proves that it originated from Alice and has a pointer to the previous transaction. In a reward transaction, there is a transaction value, but the reward transaction does not "spend" a previous transaction. Of course, for Alice's transaction to be accepted by the blockchain network, the transaction cannot reference a previously spent transaction, and Alice must actually prove that she generated the transaction.

[0012] If a transaction refers to a previous transaction output that has already been used (paid) according to the blockchain protocol and thus by the consensus of the blockchain nodes, the transaction is not valid. That is, for a previously used (paid) transaction output, the ledger contains a valid existing transaction input that refers to the previous transaction output. To prevent any intruder from generating a new transaction input that "uses" the value represented by a previous unused transaction output, each transaction output contains data representing the requirements imposed on any claimant who may generate such a transaction, and since the unused transaction output is immutable, this data cannot be changed. Of course, used transactions are also immutable.

[0013] In the above example, Alice may generate a payment transaction. As a result, the value within the previous transaction that only she has the ability to unlock can be transferred to Bob. That is, as a result, a new unused transaction is created that only Bob has the ability to unlock and thereby use. The payment transaction generated by Alice may contain data corresponding to the following requirements. "Anyone can point to this transaction and thereby use all of its value if they can provide sufficient information to prove that they know Bob's private key." If Bob is careful, Bob is the only person who can generate a valid transaction that uses the transaction. In fact, Bob is the only person who owns and can use the value. This does not require Bob to trust anyone who is an operator of a blockchain node or any other party who has the ability to generate a transaction. Bob only needs to trust that a malicious party cannot completely take over the majority of the blockchain nodes.

[0014] In certain cases, one transaction exactly uses one previous unused transaction in full, and that one transaction is either fully used by a later transaction or not used at all. In general cases, a transaction has one or more transaction inputs and one or more transaction outputs. Here, each transaction input references the transaction output of a previous transaction (and the transaction output has usable value), and each transaction output has usable value (remaining unused until used / referenced by the transaction input of a future transaction). The transaction outputs of a transaction specify the usable units of the transaction in terms of being either fully used or not used at all. In some of the examples described here, a transaction is said to be "used", and it should be understood that the description can include cases where fewer than all of the outputs of the transaction are used when the transaction has multiple transaction outputs.

[0015] If a transaction can have multiple transaction outputs, different transaction outputs of that transaction can be usable at different times. When a transaction is generated, its transaction outputs are considered unused. Each transaction output can be used by the transaction input of a later transaction or remain unused. If a transaction has a transaction input that attempts to use the transaction output of a previous transaction after the transaction output of the previous transaction has already been used, the blockchain node rejects it as an invalid transaction.

[0016] If Party Alice controls an unspent transaction output of value X and wishes to use only a portion Y of that transaction output, Alice can specify a new transaction having multiple transaction outputs, namely one transaction output having value Y that can be used only by Bob and one transaction output having value X - Y that can be used only by Alice. In fact, the original transaction output is fully spent, but there is a new "change-making" transaction output belonging to Alice.

[0017] The number of transaction inputs of a transaction and the number of transaction outputs of the transaction need not be the same. However, for a transaction to be valid, the sum of the values specified in the transaction outputs of the transaction must not exceed the sum of the values of the transaction outputs before being used by the transaction inputs of the transaction, and in some cases may be less, with some exceptions. In the genesis transaction and reward transactions, the sum of the values of the transaction outputs can be greater than the sum of the values of the transaction inputs. Or, there need not be any inputs at all. However, in normal transactions, a transaction may be invalid if the sum of the values of its transaction outputs exceeds the sum of the values of its transaction inputs. In some transactions, the sum of the values of the transaction outputs can be less than the sum of the values of the transaction inputs. In this case, the successful miner adds a transaction fee transaction for the difference, thus compensating and generating an incentive for the miner to process the transaction. In the Bitcoin protocol, this is a transaction based on the coins added to the block and is equal to the sum of all the transaction fees of the other transactions included in the Bitcoin block (i.e., the sum of the differences between all the inputs and outputs of all the included transactions) and the reward for generating the new block, having available outputs.

[0018] Each transaction output of a transaction includes constraints that must be satisfied in order to use the value of the output. In some blockchain protocols, the constraints are embedded in a "lock script" that specifies data and script commands that define what these constraints are. The lock script operates as an encumbrance on the value presented in the transaction output in that other actors cannot "use" the value presented in the transaction output unless they can "unlock" the lock script of the transaction output.

[0019] Each transaction input to a payment transaction uses the transaction output of a previous transaction. The "unlock script" of a payment transaction input specifies data and script commands that satisfy the constraints specified by the lock script of the previous transaction output. Only by satisfying these constraints can a payment transaction use the transaction output of the previous transaction. Thus, a valid transaction specifies at least one input, and each input of a valid payment transaction includes a pointer to the previous transaction output (to be used) and an unlock script that "unlocks" the lock script of the previous transaction output. A blockchain node operating according to the corresponding blockchain protocol executes the lock script and the unlock script together to verify the transaction input. In a particular system, the script is stack-based, and the verifying blockchain node starts with an empty stack, executes the unlock script, which leaves data objects on the stack, and then executes the lock script, which may use the data objects on the stack.

[0020] When the verification blockchain node combines the lock script and the unlock script and executes the combination, the result after execution is either "TRUE" or "FALSE". In some cases, the execution of the script ends with a false result before the script is fully executed. For example, for a given script execution, there may be two values that are always equal in a valid script execution, regardless of what happens within the script. During the execution of this script, a comparison is made between these two values, and if they are not equal, the execution of the script stops immediately after the comparison and can return a false result. The remaining part of the script does not need to be executed.

[0021] When the verification blockchain node combines the lock script and the unlock script, executes the combination, and the result is true (i.e., the unlock script contains everything necessary to unlock the transaction output), the verification blockchain node verifies that the transaction is valid (assuming other requirements are met, such as an appropriate timestamp, appropriate format, no pointer to a previously used transaction output, etc.). If the verification blockchain node verifies that the transaction is valid, it propagates the transaction for mining. Other blockchain nodes perform the same calculation and conclude that the transaction is valid. In this way, a valid transaction having an input that only refers to an unused transaction and an unlock script that unlocks the unused transaction output propagates and ultimately becomes part of the block that ultimately becomes part of the ledger.

[0022] On the other hand, if a malicious node attempts to propagate an invalid transaction, other nodes will discover that it is invalid and will not propagate it.

[0023] Once a transaction is valid and accepted into the blockchain, its content cannot be changed. This means that the lock script is finalized at the time of transaction generation. The unlock script, however, is not necessarily finalized at that time. This is because the unlock script is included in subsequent payment transactions and does not need to be generated until the subsequent payment transactions are generated.

[0024] In the standard case, the unlock script cannot be generated by just anyone, but only by a party authorized to use the previous transaction output. As in the example above, the lock script could be "anyone can point to this transaction and thereby use all of its value if they can provide sufficient information to prove they know Bob's secret key", and the unlock script could be in the form "Bob signs the transaction with his secret key and the result is <sig_Bob>". Next, the verifying blockchain node processes these two statements and reaches a true or false conclusion. This process works well when <sig_Bob> is easily verified to be a valid signature of Bob's, Bob (or someone with knowledge of Bob's secret key) can easily generate such a signature, and it is very difficult for anyone else to generate a valid signature without knowing Bob's secret key. As a result, value can be transferred within a trustless system. The generator of the transaction that Bob wants to use does not need to trust the system or Bob. This is because it is cryptographically difficult to form a valid and provable result that can be accepted by the consensus of the blockchain nodes without first knowing Bob's secret key.

[0025] The blockchain node can easily verify that Bob has signed the transaction and that the signature is the only requirement of the lock script. Of course, there may be malicious nodes that do not prove when other nodes have proven and prove when other nodes have not proven. However, unless malicious nodes can overwhelm honest nodes on the blockchain network, malicious nodes cannot push through invalid transactions or stop valid transactions from propagating or being mined.

[0026] When validating a payment transaction, the node executes the unlock script of one or more transaction inputs and the corresponding lock script of one or more previous transaction outputs. If the execution of such a script evaluates to true and other verification conditions are met where appropriate, the transaction is valid as far as that node is concerned. The node then propagates the verified transaction to other network nodes, and then the miner can choose to include the transaction in the block. Therefore, for a transaction to be written to the blockchain, (1) it must be verified by the node that received the transaction, (2) it must be relayed to other nodes in the network (but only if the transaction has been verified), (3) it must be added to a new block constructed by the miner, (4) it must be propagated as part of the proposed block, and (5) the proposed block must be accepted as an addition to the public ledger of past transactions by the general consensus of the nodes.

[0027] A transaction is considered approved when a sufficient number of blocks have been added to the blockchain to create a transaction that is effectively irreversible. Since the transaction cannot be changed, the blockchain protocol can prevent a unilateral reversal of the transaction. Of course, if Alice transfers value X to Bob and Alice wants to retrieve that value X, she can do so if Bob agrees. In this case, the Alice-to-Bob-for-X transaction is not reversed or cancelled, but there is a new transaction initiated by Bob, the Bob-to-Alice-for-X transaction.

[0028] Once a transaction is included in a block, the transaction is considered immutable, and once the block is committed to the blockchain, the block is considered immutable. There may be a short time period where there are forks within the blockchain and some ability to roll back the blockchain, but generally, the older it gets, the less likely it is to be rolled back. Here, unless otherwise specified, transactions and blocks are assumed to be immutable after being fully committed to the blockchain.

[0029] One way to ensure immutability is through the use of cryptography. For example, there are cryptographic operations such as hashing and digital signatures that take as input a sequence of data from anywhere and provide as output a sequence of data from anywhere corresponding to the input data sequence. Such operations are computationally infeasible, or impossible using the available computing resources, to find different cryptographic inputs that will result in the same cryptographic output for a given cryptographic output (e.g., a hash or digital signature) generated from a given cryptographic input (e.g., a transaction or block). Thus, a verifier can assume that if the cryptographic input is consistent with the cryptographic output, the input used to generate the cryptographic output was the cryptographic input and not some other modified cryptographic input.

[0030] In a blockchain network, each node is not required to trust each other node. Thus, transactions are verified, blocks are verified, and unverifiable transactions and blocks are ignored and not used. Transactions and blocks are considered to be effectively immutable, which may be the result of the assumption that a transaction or block has not been altered from its original if the hash or digital signature correctly corresponds to the transaction or block.

[0031] Some blockchain nodes may store a complete ledger, while other nodes may store only unspent transaction outputs (UTXOs in the Bitcoin ledger). Unspent transaction outputs correspond to spendable value, and preferably, each unspent transaction output has a lock script that cannot be easily generated by someone other than the "owner" of the value with a verifiable unlock script. Of course, this is not a requirement, but any transaction output for which a verifiable unlock script can be more easily generated by someone will be quickly spent in a transaction that transfers the value to another transaction output that can only be used by the person who noticed it first. As a result, the blockchain can be used to transfer cryptocurrency value, more generally digital asset control, from one participant within the blockchain system to another participant within the blockchain system, and the record of transactions with spent and unspent transaction outputs is recorded in a publicly immutable ledger, facilitating verification of the flow of these digital assets and preventing double spending of these digital assets.

[0032] As used herein, "digital asset" may represent one or more digital assets. The digital asset whose control is transferred may, in this example, be a collection of multiple digital assets, and this collection itself is a digital asset. In one embodiment, the cryptocurrency is a token-based cryptocurrency, each token represents a share of an asset (e.g., a share of a company), and a single transaction includes multiple types of tokens (e.g., includes shares in one or more different companies).

[0033] A transaction includes a lock script and an unlock script that can form a computational object. Once committed to the blockchain, the transaction becomes immutable. This feature has uses other than the immutable transfer of control for digital assets in the form of cryptocurrencies. In addition to the transfer of value, immutable transactions can be used to perform other operations. For example, recording an event by a notary, implementing a smart contract. Here, the rights and obligations of the parties are encoded within the transaction and transfer value according to the terms of the smart contract that follows the blockchain protocol.

[0034] In the Bitcoin platform, scripts are written using a stack-based scripting language, although other approaches may be used instead. When executing instructions of a stack-based scripting language, a processor (e.g., part of a blockchain node) stores data in a last-in-first-out data structure called a stack. The processor can push a value onto the top of the stack, pop a value from the top of the stack, or perform possible access (read / write) to other values stored in the stack. The various operations performed on the stack can result in the push or pop or access of one or more of the values on the stack, the execution of an operation on them, and the change of the order of the elements on the stack (which can be equivalent to two pop operations and two pushes where the first push is the first popped element). For example, the OP_EQUAL operation can pop the top two items from the stack, compare them, and push the result (e.g., 1 if equal, 0 if not equal) onto the top of the stack. In some of the scripting languages utilized by some embodiments of the present invention, there may be at least two stacks, namely a main stack and an alternate stack. Some operations of the scripting language can move items from one stack to the other stack. For example, the execution of the OP_TOALTSTACK operation causes the processor to move a value from the top of the main stack to the top of the alternate stack.

[0035] A smart contract can be implemented by a script included in a transaction, where the terms of the contract are encoded within the script. An example could be in the form of "If Bob pays X to Carol and Dave gives permission for the transaction, then Alice pays half of X to Bob". This can be encoded as part of a lock script that is evaluated as true only if there are (among other conditions) transactions prior to the one where Bob pays Carol and prior to the one where Dave encodes his permission. As used herein, "prior transaction" may represent any transaction already added to the blockchain and not necessarily a prior transaction that has the output used by the payment transaction. In fact, a smart contract can represent a machine-executable program that includes rules for defining inputs to produce results, which can then be used to execute operations depending on those results.

[0036] In addition to the transfer of value, a transaction can also transfer other objects of value or mere possessory rights. For example, a transaction may transfer the nominal cryptocurrency value from something, but also include data corresponding to the claim that "anyone who can use this transaction is also the rightful owner of the house and land at Marley Circle 123". Mere possessory rights may, in the same vein, be hidden within public records. For example, a transaction may also include data corresponding to the claim that "anyone who can use this transaction is also the rightful owner of a specific property held in trust under trust number 12345 at the Central Bank of Trust". Here, this is referred to as a token. Tokens represent and effect the transfer of real-world entities across the blockchain. Potentially highly confidential or secret items can be represented by tokens that have no recognizable meaning or value. Thus, tokens function as identifiers that enable real-world items to be referenced from the blockchain.

[0037] As described in this specification, a smart contract is "smart" in the sense that the generator or some other specific entity does not perform the implementation and / or execution of the smart contract. Instead, the interaction with a specific entity can be encoded in specific steps within the smart contract, but in other cases, the smart contract can be automatically and self-executing. In some examples, self-execution means that any entity can use the unused transaction output for their benefit. In such examples, note that the "any entity" that can use the unused transaction output represents an entity that can generate an unlock script without requiring the provision of any secret knowledge. In other words, the payment transaction is verifiable without verifying that the data source has access to cryptographic secrets (e.g., secret asymmetric keys, symmetric keys, etc.). Also, in such examples, self-execution occurs as the consensus of the verification nodes of the blockchain network that verifies the payment transaction according to the constraints of the smart contract. In some examples, "using" an unused transaction output means generating a payment transaction output that references and executes the unused transaction output as valid. The side effect of using such a transaction output is that the blockchain network processes the lock script and the unlock script to verify the payment transaction, which is a new transaction. If valid, it is considered that the previous transaction output has been used. By including a specific value in the transaction output and enabling someone to use the output, the party is given an incentive to generate such a payment transaction. And thus, the steps of the smart contract may be executed by others operating the blockchain nodes rather than by the participants in the smart contract.

[0038] The scripts that form the lock script and the unlock script recorded as part of the transaction are immutable. Thus, the lock script usually cannot be changed or reference parts of future transactions that are unknown when the transaction is finalized. The unlock script of a transaction input can reference parts of the previous transaction output pointed to by the transaction input or previous transactions within the blockchain other than the previous transaction. This can limit how the transaction can be used.

[0039] In one or more of the above aspects, it is desirable to provide additional features and improved methods and systems that use blockchain technology. Accordingly, according to the present invention, a system and / or method as defined in the appended claims is provided.

Summary of the Invention

[0040] In various embodiments, a computer-implemented method comprising generating and / or validating a payment blockchain transaction, wherein the payment blockchain transaction comprises: i) a plurality of lock scripts where each lock script represents an instance of an execution thread, the execution thread being a thread that branches from an execution thread represented by a lock script of a previous blockchain transaction and / or an execution thread of at least one previous blockchain transaction that is managed and / or controlled for inter-thread communication and control; or ii) a lock script representing an execution thread combined from a plurality of execution thread instances represented by at least one previous blockchain transaction. A method is provided that includes the steps. When generated and / or validated, the payment blockchain transaction can be communicated over a blockchain network for storage in a blockchain ledger.

[0041] Additionally or alternatively, a computer-implemented method may generate and / or verify blockchain transactions that implement thread-specific lock scripts and related branch, join, and barrier constructs for concurrent or asynchronous execution threads. Such blockchain transactions may be verified and communicated over a blockchain network for storage in a blockchain ledger. The blockchain transactions may be used as part of a smart contract.

[0042] Additionally or alternatively, payment blockchain transactions may be generated by nodes of a blockchain network. A payment blockchain transaction may refer to the lock script of a previous blockchain transaction that represents an execution thread. A payment blockchain transaction may further include a plurality of lock scripts. Each lock script represents an instance of an execution thread that branches from the execution thread represented by the lock script of the previous blockchain transaction.

[0043] In one embodiment, the execution thread represented by the lock script of the previous blockchain transaction may include a bytecode sequence. At least one execution thread instance represented by the plurality of lock scripts of the payment blockchain transaction may be generated by replicating the bytecode sequence of the lock script of the previous blockchain transaction.

[0044] In another embodiment, the execution thread represented by the lock script of the previous blockchain transaction may include a bytecode sequence and an interpreter code. At least one execution thread instance represented by the plurality of lock scripts of the payment blockchain transaction may be generated by replicating the bytecode sequence and the interpreter code of the lock script of the previous blockchain transaction.

[0045] In yet another embodiment, the method can store or access a set of valid bytecode sequences. At least one execution thread instance represented by a plurality of lock scripts of a payment blockchain transaction can be generated by replicating the valid bytecode sequences of the set.

[0046] In yet another embodiment, the method can store or access a set of valid bytecode sequences and valid interpreter code. At least one execution thread instance represented by a plurality of lock scripts of a payment blockchain transaction may be generated by replicating the valid bytecode sequences and valid interpreter code of the set.

[0047] [[ID=I0]]In another embodiment, a payment blockchain transaction may be generated by generating execution state information (e.g., a next execution pointer) of an execution thread instance represented by a plurality of lock scripts of the payment blockchain transaction and including the execution state information (e.g., the next execution pointer) in the plurality of lock scripts of the payment blockchain transaction. Once generated and / or verified, the payment blockchain transaction may be communicated on a blockchain network for storage in a blockchain ledger.

[0048] Additionally or alternatively, payment blockchain transactions may be received by nodes of the blockchain network. Payment blockchain transactions may include a plurality of lock scripts. Each lock script represents an instance of an execution thread that branches from the execution thread represented by the lock script of the previous blockchain transaction. A node may verify a payment blockchain transaction by verifying the lock script of the payment blockchain transaction against one or more conditions. The verification may include comparing at least one of the plurality of lock scripts of the payment blockchain transaction against the lock script of the previous blockchain transaction. The verification may further include using the next execution pointer of the plurality of lock scripts of the payment blockchain transaction that represents an execution thread instance for executing the plurality of lock scripts of the payment blockchain transaction and generating resulting execution state information, and checking the resulting execution state information for verification.

[0049] In one embodiment, the execution thread represented by the lock script of the previous blockchain transaction may include a bytecode sequence and optionally interpreter code. The plurality of lock scripts of the payment blockchain transaction may be required to include the same bytecode sequence and optionally the same interpreter code for the verification of the payment blockchain transaction to succeed. In this case, verifying may include comparing the bytecode sequence and optionally the interpreter code of each of the plurality of lock scripts of the payment blockchain transaction against the bytecode sequence and optionally the interpreter code of the lock script of the previous blockchain transaction. The verification of the payment blockchain transaction may be determined based on the result of such comparison.

[0050] In another embodiment, the execution thread represented by the lock script of the previous blockchain transaction may include a bytecode sequence and optionally interpreter code. The plurality of lock scripts of the payment blockchain transaction may be i) the same bytecode sequence and optionally the same interpreter code of the lock script of the previous blockchain transaction, or ii) different bytecode sequences and optionally interpreter codes belonging to a set of valid lock scripts for the verification of the payment blockchain transaction to succeed. In this case, verifying may include generating a hash data value corresponding to the lock script of the previous blockchain transaction and adding the hash data value to a set of hash data values corresponding to the set of valid lock scripts. The hash data value may be generated for each lock script of the payment transaction and compared to the set of hash data values. The verification of the payment blockchain transaction can be determined based on the result of such a comparison of hash data values.

[0051] Additionally or alternatively, the payment blockchain transaction can be generated by a node of the blockchain network. The payment blockchain transaction can refer to a plurality of lock scripts of one or more previous blockchain transactions. Here, each of the plurality of lock scripts represents an instance of an execution thread. The payment blockchain transaction can also include a lock script representing an execution thread combined from the execution thread instances pointed to by the payment blockchain transaction. Once generated and / or verified, the payment blockchain transaction can be communicated over the blockchain network for storage in the blockchain ledger.

[0052] In one embodiment, a lock script representing an execution thread combined from an execution thread instance pointed to by a payment blockchain transaction can be generated by replicating the bytecode sequences of a plurality of lock scripts of one or more previous blockchain transactions.

[0053] In another embodiment, a lock script representing an execution thread combined from an execution thread instance pointed to by a payment blockchain transaction can be generated by replicating the bytecode sequences and interpreter code of a plurality of lock scripts of one or more previous blockchain transactions.

[0054] In yet another embodiment, the method can store or access a set of valid bytecode sequences. A lock script representing an execution thread combined from an execution thread instance pointed to by a payment blockchain transaction can be generated by replicating the valid bytecode sequences of the set.

[0055] In still another embodiment, the method can store or access a set of valid bytecode sequences and valid interpreter code. A lock script representing an execution thread combined from an execution thread instance pointed to by a payment blockchain transaction can be generated by replicating the valid bytecode sequences and valid interpreter code of the set.

[0056] In another embodiment, a payment blockchain transaction can be generated by generating execution state information (e.g., the next execution pointer) of an execution thread combined from an execution thread instance pointed to by the payment blockchain transaction, and including the execution state information (e.g., the next execution pointer) in the lock script of the payment blockchain transaction.

[0057] Additionally or alternatively, payment blockchain transactions can be received by nodes of the blockchain network. A payment blockchain transaction can refer to multiple lock scripts of one or more previous blockchain transactions. Here, the multiple lock scripts each represent an instance of an execution thread. A payment blockchain transaction can also include a lock script representing an execution thread combined from the execution thread instances pointed to by the payment blockchain transaction. A node can verify a payment blockchain transaction by verifying the lock script of the payment blockchain transaction against one or more conditions. Verification can include comparing the lock script of the payment blockchain transaction with multiple lock scripts of one or more previous blockchain transactions. Verification can further include executing multiple lock scripts of one or more previous blockchain transactions to generate resulting execution state information, and then fusing or combining the resulting execution state information.

[0058] In one embodiment, the multiple lock scripts of at least one previous blockchain transaction can include a common bytecode sequence and optionally an interpreter code. The lock script of the payment blockchain transaction may be required to include the common bytecode sequence and optionally the same interpreter code for the verification of the payment blockchain transaction to succeed. In this case, verification can include comparing the bytecode sequence and optionally the interpreter code of the lock script of the payment blockchain transaction with the bytecode sequence and optionally the interpreter code of each of the multiple lock scripts of the previous blockchain transaction. The verification of the payment blockchain can be determined based on the result of such comparison.

[0059] In another embodiment, the lock script of a payment blockchain transaction is the same bytecode sequence and possibly the same interpreter code of the lock scripts of one or more previous blockchain transactions, or can be different bytecode sequences and possibly interpreter codes corresponding to a set of valid lock scripts. In this case, verification can include generating a hash data value corresponding to the lock script of the previous blockchain transaction and adding the hash data value to a set of hash data values corresponding to the set of valid lock scripts. The hash data value is generated for each lock script of the payment transaction and can be compared to the set of hash data values. Verification of the payment blockchain transaction can be determined based on the result of such a comparison of hash data values.

[0060] Additionally or alternatively, a payment blockchain transaction can be generated by a node of the blockchain network. A payment blockchain transaction can refer to a plurality of lock scripts of one or more previous blockchain transactions. Here, each of the previous blockchain transactions represents an instance of an execution thread. A payment blockchain transaction can also include a corresponding plurality of lock scripts. Execution of the lock scripts includes inter-thread communication or control between the execution thread instances pointed to by the payment blockchain transaction. Once generated and / or verified, the payment blockchain transaction can be communicated over the blockchain network for storage in the blockchain ledger.

[0061] In one embodiment, a plurality of lock scripts of a payment blockchain transaction can be generated by replicating the bytecode sequence of the lock scripts of one or more previous blockchain transactions.

[0062] In another embodiment, multiple lock scripts of a payment blockchain transaction can be generated by replicating the bytecode sequences and interpreter code of multiple lock scripts of one or more previous blockchain transactions.

[0063] In yet another embodiment, a payment blockchain transaction can be generated by generating execution state information (e.g., the next execution pointer) of an execution thread instance represented by multiple lock scripts of the payment blockchain transaction, and including the execution state information (e.g., the next execution pointer) in the multiple lock scripts of the payment blockchain transaction.

[0064] Additionally or alternatively, a payment blockchain transaction can be received by a node of the blockchain network. The payment blockchain transaction can refer to multiple lock scripts of one or more previous blockchain transactions. Here, each of the previous blockchain transactions represents an instance of an execution thread. The payment blockchain transaction can also include corresponding multiple lock scripts. Execution of the lock scripts includes inter-thread communication or control between the execution thread instances pointed to by the payment blockchain transaction. The node can verify the payment blockchain transaction by verifying the multiple lock scripts of the payment blockchain transaction against one or more conditions. Verification can include comparing the multiple lock scripts of the payment blockchain transaction with the multiple lock scripts of one or more previous blockchain transactions. Verification can further include executing the execution thread instances represented by the multiple lock scripts of one or more previous blockchain transactions to provide inter-thread communication and / or control between the execution thread instances.

[0065] In one embodiment, the plurality of lock scripts of at least one previous blockchain transaction may include a bytecode sequence and possibly interpreter code. The plurality of lock scripts of a payment blockchain transaction may be required to include the bytecode sequence and interpreter code of the plurality of lock scripts of one or more previous blockchain transactions in order for the verification of the payment blockchain transaction to succeed. In this case, verifying may include collating the bytecode sequence and possibly interpreter code of each of the lock scripts of the payment blockchain transaction against the corresponding bytecode sequence and possibly interpreter code of the lock scripts of one or more previous blockchain transactions. The verification of the payment blockchain can be determined based on the result of such collation.

[0066] Additionally or alternatively, the operation of a payment blockchain transaction can encode the operation of a smart contract implemented using the blockchain.

[0067] Also, it is desirable to provide a system including a processor and a memory including executable instructions that, as a result of execution by the processor, cause the system to execute the method according to any of the claims.

[0068] Also, it is desirable to provide a non-transitory computer-readable storage medium storing executable instructions that, as a result of execution by one or more processors of a computer system, cause the computer system to execute the method according to any of the claims.

Brief Description of the Drawings

[0069] The above and other aspects of the present invention are apparent from and taught with reference to the embodiments described herein. Embodiments of the present invention are described below by way of example only and with reference to the accompanying drawings.

[0070]

Figure 1A

[0071]

Figure 1B

[0072]

Figure 2

Figure 3A

Figure 3B

Figure 3C

Figure 3D

[0073]

Figure 4

Figure 5

[0074]

Figure 6

[0075]

Figure 7

[0076]

Figure 8

[0077]

Figure 9

[0078]

Figure 10

[0079]

Figure 11

[0080]

Figure 12

[0081] Referring first to FIG. 1A, FIG. 1A shows an exemplary blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure. In this embodiment, the blockchain network 100 includes blockchain nodes. The blockchain nodes may be implemented as peer-to-peer distributed electronic devices, each executing an instance of software and / or hardware that follows a blockchain protocol, i.e., an operation agreed upon, either wholly or in part, among the operators of the blockchain nodes. In some examples, these distributed electronic devices are simply referred to as "nodes" such as node 102 in FIG. 1A. An example of a blockchain protocol is the Bitcoin protocol.

[0082] Node 102 may include any suitable computing device (e.g., a client computing device such as a server in a data center, a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), and may be by a plurality of computing devices in a distributed system of computing resource service providers, or by any suitable client device such as computing device 2600 in FIG. 12. Node 102 may have an input for receiving a proposed transaction, e.g., a data message or object representing transaction 104. Node 102 may be queryable for information they maintain, such as their understanding of the state of the transaction.

[0083] As shown in FIG. 1A, some nodes 102 are communicatively coupled to one or more other of the nodes 102. Details of which node 102 can communicate with which other node need not be centrally determined. It is sufficient that active nodes within the blockchain network 100 can communicate with one or more other nodes 102. As a result, when the blockchain protocol indicates that a message should be forwarded, the message passed from one node 102 to another can propagate through the exemplary blockchain network 100 (or some meaningful portion thereof). One such message may be the issuance of a transaction proposed by one of the nodes 102A. The transaction may then propagate along a path such as path 106. Another such message may be the issuance of a new block proposed for inclusion in the blockchain.

[0084] Node 102 can maintain a blockchain ledger that contains data corresponding to blocks within the blockchain. Blocks are cryptographically immutable in that later blocks depend on values calculated for certain blocks that have become immutable, and any changes to an immutable block can be easily recognized as an invalid block by other blockchain nodes. The blockchain ledger may also contain data corresponding to transactions that are changeable in some cases and have not yet been committed to the blockchain. The blockchain ledger may be a complete copy or a portion of the blockchain ledger of the blockchain network. Some nodes may maintain only unspent transactions, while other nodes may maintain the entire ledger. Thus, since each node can have its own copy, the ledger is a distributed ledger. Nodes should preferably only change their copy in accordance with the rules of the protocol, and for all nodes following these rules, their copies should sometimes be the same as other nodes and should save some propagation time for blocks and transactions. Node 102 should include the ability to verify the blocks it receives and the transactions within those blocks. The rules of the blockchain protocol may be that a node does not propagate a block or transaction to other nodes if the node determines that the block or transaction is invalid. By this rule, valid and confirmed-to-be-valid blocks and transactions propagate through the blockchain network, while invalid ones do not.

[0085] Some of the nodes 102 in the blockchain network are miner nodes that perform the operations of collecting transactions and generating blocks of transactions. As a result, new blocks can be committed to the blockchain. The miner nodes may be expected to perform some operation that is complex and depends on the data of the included transactions (to avoid malicious nodes from easily creating an invalid block), so that malicious nodes cannot perform the complex operation in advance. Here, the execution of these tasks is easily verified by other nodes. When these other nodes verify the work of the miner nodes and it is verified, they accept the block into their copy of the blockchain and propagate it. This commits the new block to the distributed ledger of the blockchain. In some examples, a block is a group of transactions and may be marked by a timestamp and the "fingerprint" (e.g., hash) of the previous block. In this way, each block becomes linked to the previous block, thereby creating a "chain" that links the blocks within the blockchain. In an embodiment, a valid block is added to the blockchain by the consensus of the nodes within the blockchain network. Also, in some examples, the blockchain includes a list of verified blocks.

[0086] In one embodiment, at least some of the nodes operate as verification nodes that verify transactions as described in the present disclosure. In some examples, the blockchain proves the value in the form of a digital asset, and together, the transactions of the blockchain provide a chain from the genesis transaction (which started the blockchain) or a reward transaction that generates a newly mined digital asset as an incentive to the operator of the miner node to subsequent transactions. The end of a portion of the chain is an unspent transaction, or a portion thereof, and each transaction on the blockchain designates one or more outputs, some of which may be spent and some of which may be unspent. Here, an output includes the designation of the value of the output and the requirements necessary for someone to "spend" the output by inserting a valid transaction (i.e., a transaction that meets at least the specified requirements) that extends that portion of the chain. As used herein, an unspent transaction output may be referred to as a UTXO.

[0087] The requirements necessary for someone to spend a UTXO are specified in the lock script of the UTXO. A valid payment transaction may be a transaction that (i) designates one or more UTXOs as inputs to the transaction, which designation may be by a pointer to the UTXO, (ii) meets the requirements of the lock script of each of the UTXOs, and (iii) has inputs such that the sum of the values of all of the UTXOs pointed to by the inputs is less than or equal to the sum of the values of all of the outputs of the transaction. Data representing satisfaction of the requirements of the lock script can be provided by an unlock script. The verification node can process the unlock script and then follow the lock script, and the output of the process is either an invalid result or verification of the payment transaction.

[0088] Since the process can be a stateless process, when a node executes its unlock script and its lock script, the result can be a verification that is the outcome of other nodes. Thus, a payment transaction that satisfies the lock script of the output of a previous transaction that is already on the blockchain and has not yet been used propagates and is ultimately committed to the blockchain. The node that generated the committed payment transaction, on the other hand, can specify in its lock script the requirements that any party is required to meet in order to use the value of the output of that new transaction. The process is stateless in that, with a few minor exceptions, the script does not need to refer to external references outside of the script and does not depend on variables or other state outside of the script. As a result, the unlock script and the lock script can be evaluated independently.

[0089] In other variations, the blockchain system can include a feature that allows external data to be included in the script evaluation process. In such cases, the external data can be controlled and / or guaranteed in a way that the unlock script and the lock script are evaluated using the external data and the evaluation is consistent across the nodes that perform the evaluation.

[0090] Figure 1B shows an example of a transaction 150 that can be stored in the blockchain ledger used by the blockchain node 102 of Figure 1A. Other variations with similar functionality are possible. The data elements or fields of the transaction may be as shown in Figure 1B and may include additional fields other than those described in this disclosure. As shown, there is a blockchain version field 152 having a value indicating the blockchain protocol version of transaction 150. The #vin field 154 indicates how many transaction inputs (described below) are present in transaction 150. Although other fields may exist or not be shown, for each transaction input (exemplarily shown here as Vin[y] 160), there is a set of fields including the transaction ID (TxID) 161 of the previous transaction and an index 162 to one of the transaction outputs of the previous transaction (the transaction that provides the transaction output that matches the transaction input 160). Here, TxID 161 and index 162 together form a pointer 163 that references the transaction output of the previous transaction. As used herein, the term "previous transaction" when used in the context related to the current or existing transaction refers to a particular previous transaction (or transactions) having the transaction output(s) referenced (and "used") by the current or existing transaction. In the example, the current or existing transaction may be referred to as a "payment transaction".

[0091] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values. Instead, there is a decentralized mechanism for generating a unique TxID for a transaction, for example, by generating a hash of the content of the transaction itself. Since a valid transaction cannot have exactly the same content as another valid transaction in its entirety, each valid transaction has a unique hash of its TxID (apart from the astronomically low probability of a hash collision). However, for the purposes of this specification, it is assumed that each transaction has a unique ID when implemented. Due to the properties of hashing, once the TxID is generated from the content of the transaction, the content cannot be changed and the TxID remains valid for that transaction.

[0092] As shown in Figure 1B, the set of fields of the transaction input Vin[y]160 also includes an Unlocking_Script_Length field 164 indicating the length of the subsequent unlocking script, an Unlocking_Script field 165 (commonly referred to as "scriptSig" in the Bitcoin protocol) containing the unlocking script that "unlocks" the corresponding lock script of the transaction output pointed to by the pointer 163, and a Sequence# field 166 that can be used to constrain the transaction 150.

[0093] Figure 1B explicitly shows only one transaction input and one transaction output, but more than one of each is possible. Following the transaction input, there is a #vout field 170 that indicates how many transaction outputs (described later) are present within transaction 150. For each transaction output (exemplarily shown here as Vout[x]180), there is a set of fields including an output value field 181 that indicates the transaction value provided by this transaction output Vout[x]180, a Locking_Script_Length field 182 that indicates the length of the subsequent locking script, and a Locking_Script field 183 that contains the locking script of this transaction output Vout[x]180 (commonly referred to as "scriptPubKey" in the Bitcoin protocol). As explained, the transaction value of this transaction output can be "used" by anyone who can generate a payment transaction having a transaction input with an unlocking script that validates as true when the blockchain node executes verification using its unlocking script and its locking script. Other fields may follow the transaction output fields. For example, a lock time field 190 that can restrict transaction 150 from becoming active before a specified future time or before a specified future block. Each transaction input of the payment transaction point refers to the corresponding transaction output of the previous transaction output, and if the previous transaction output contains a transaction value, the transaction input need not include a field indicating that transaction value.

[0094] In the present disclosure, various script operation codes (or opcodes or op_code) and keywords are referred to for performing various operations. The Bitcoin protocol uses a script system called "Script" to perform various operations. However, other blockchain technologies can implement different instruction sets, and thus, the operation codes described in the present disclosure are considered to describe the operations performed by the operation codes rather than specific operation codes in the script. In some embodiments, the script system is a Turing-incomplete instruction set (e.g., does not support loop, recursion, goto statements, etc.). In other embodiments, the script system can be a Turing-complete instruction set.

[0095] Certain embodiments of the present disclosure can operate under the assumption that a script system or other system implementing the described instruction set allows more than 200 instructions (e.g., operation codes or op_code) in a single script. Similarly, certain embodiments of the present disclosure further assume the following: · The functions provided by certain low-level operation codes (or low-level bytecode operations) exist and are enabled within the system executing the operation code script / instruction set; and / or, · The functions provided by certain high-level operation codes (or high-level bytecode operations) can be implemented by generating customized functions described to provide the desired operations. These customized functions may be described to implement the functions of op_codes that exist but are hidden within the language, or may be "new" op_codes that provide specific functions not natively provided within the script language. Examples of low-level operation codes supported by the script system include the following: · OP_1SUB: The value "1" is subtracted from the top stack item. · OP_2DUP: Duplicates the top two stack items. ·OP_ADD: Adds the top two items on the stack. ·OP_CAT: Concatenates the top two items on the stack. ·OP_CHECKSIG: The public key and signature are popped from the stack and verified against the signature of the transaction fields according to the SIGHASH type. If the signature is valid, 1 is returned, and 0 is returned otherwise. ·OP_CHECKSIGVERIFY: Functions the same as OP_CHECKSIG, but OP_VERIFY is executed later. ·OP_DROP: Removes or pops the top item on the stack. ·OP_DUP: Duplicates the top stack item. ·OP_ELSE: These statements are executed if the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed, and are not executed otherwise, i.e., if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed. ·OP_ENDIF: Ends the if / else block. ·OP_EQUAL: Returns 1 if the inputs are exactly equal, and 0 otherwise. ·OP_EQUALVERIFY: Same as OP_EQUAL, but returns OP_VERIFY later. ·OP_FROMALTSTACK: Puts the input on top of the main stack and removes it from the alt stack. ·OP_HASH256: The input is hashed twice. First by SHA-256, then by RIPEMD-160. ·OP_IF: If the top stack value is not False, the statement is executed and the top stack value is removed. ·OP_LEFT: Keeps only the characters to the left of the specified point in the string. ·OP_MUL: Multiplies the top two items on the stack. ·OP_NOTIF: If the top stack value is False, the statement is executed and the top stack value is removed. ·OP_RIGHT: Retain only the characters to the right of the specified point in the string. ·OP_ROLL: The item at depth n items on the stack is moved to the top. ·OP_ROT: Rotate the top 3 items on the stack to the left. ·OP_SIZE: Push the string length of the top element on the stack (without popping). ·OP_SUBSTR: Return a section of the string. ·OP_SWAP: Swap the top 2 items on the stack. ·OP_TOALTSTACK: Place the input on top of the alt stack and remove it from the main stack. ·OP_TUCK: Copy the top item on the stack and insert it in front of the second item from the top. ·OP_VERIFY: If the top stack value is not TRUE, mark the transaction as invalid. These low-level operation codes are currently supported by the script system of the Bitcoin protocol.

[0096] Examples of high-level operation codes that can be supported by the methods and systems of the present disclosure include the following: ·OP_ECPX: Return the X coordinate of the elliptic curve point. ·OP_BIGMOD: Return the remainder after dividing the top 2 items on the stack. ·OP_BIGMODADD: Perform a modular addition of the top 2 items on the stack with the third item on the stack as the modulus. ·OP_BIGMODINVERSE: Perform a modular negative exponent operation. ·OP_BIGMODMUL: Perform a modular multiplication of the top 2 items on the stack with the third item on the stack as the modulus. ·OP_DERENCODE: Encodes the top two items on the stack in DER format. ·OP_ECPMULT: Performs an elliptic curve point multiplication (also called elliptic curve scalar multiplication) on the top two items on the stack. These high-level operation codes are not originally provided in the script system of the Bitcoin protocol.

[0097] Verification of a payment transaction can include verification of the unlock script (scriptSig) 165 of the same transaction input Vin[x]160 of the payment transaction against the lock script (scriptPubKey) of the unspent output of the previous transaction pointed to by the transaction input Vin[x]160 of the payment transaction. In a more general case, each transaction can have multiple inputs and / or multiple outputs. In this case, the lock script can be the lock script of one of the multiple transaction outputs of the previous transaction, and the unlock script can be the unlock script of one of the multiple transaction inputs of the payment transaction. Such verification can be performed by a stack-based transaction verifier that outputs a true or false result depending on whether the input is valid or not. In other variations, the transaction verifier can refer to external trusted data or state. The teachings of this specification may also be applied to blockchain systems that do not use a stack-based transaction verifier.

[0098] With a stack-based transaction validator, with some minor exceptions, the lock script and unlock script are processed independently and do not depend on variables or other state outside of these scripts. As a result, the lock script does not reference fields of previous transactions outside of the lock script itself. Since the payment transaction did not exist when the previous transaction and thus the lock script was created and made immutable, the lock script cannot reference fields of the payment transaction either. Furthermore, the unlock script cannot act directly on fields of the payment transaction. These limitations are useful in that they guarantee that any properly programmed blockchain node will produce the same result given the same lock script and the same unlock script. One exception to this is that a script may have the ability to check a signature within one of the scripts against a signature generated from the transaction as a whole. In one embodiment, the script can use the OP_CHECKSIG op_code for this purpose.

[0099] In stack-based operations, on the one hand, the transaction validator executes the unlock script by processing each op_code in the script. Some op_codes produce some result or some combination on the data accessed on the stack during processing. When the execution of the unlock script is complete, data may be left on the stack. If the execution of the unlock script does not have a script error or an op_code that ends the execution, the transaction validator executes the lock script using the data present on the stack. If the lock script and the unlock script are described using the same set of op_codes, this is effectively the same as executing a single script with the concatenation of the unlock script followed by the lock script. However, checking for script errors at the end of the execution of the op_codes of the unlock script and before the execution of the op_codes of the lock script can prevent problems caused by a malformed unlock script. When the execution of the script is complete, the result left on top of the stack is the result of the verification. If true is on top of the stack, this is considered proof that the unlock script has actually unlocked the lock script. In this regard, the unlock script meets all the requirements of the lock script.

[0100] Note that the lock script of a blockchain transaction can impose constraints on what must be present in the corresponding unlock script of the blockchain transaction through signatures and other cryptographic techniques. One such constraint is that the unlock script must contain some arbitrary data. Some constraints may be "weak" or more general. For example, a constraint that the unlock script must contain data of some specific number of bytes in length without constraining the bytes to 4 bytes or any specific value. A more powerful or more specific constraint is that the data must produce a specific hash value when hashed. This latter constraint typically requires that the data be of a specific length and of a specific value since it is nearly impossible for anyone to determine different values that produce the same hash. The constraints may be implemented within the script by the unlock script by pushing the data onto the stack or pushing the hash of the data onto the stack, causing the lock script to push the required hash onto the stack and then execute the OP_EQUAL op_code and then the OP_VERIFY op_code. These op_codes return true if the two pushed items match and false if they do not. More generally, constraints can be imposed that require the presence of specific data or data having specific characteristics.

[0101] An example of a weak constraint is that the lock script must contain certain data that the serialized set of payment transaction fields may include, but it is not necessary that these fields be any particular value. Thus, the lock script can be constrained to include the script of the unlock script that unlocks the output of the lock script, including the fields of the payment transaction from which the unlock script originated. This effectively enables the lock script to perform operations on the fields of the payment transaction left on the stack by the unlock script. Another example of a weak constraint is that the unlock script must contain certain data. The certain data is obtained from a specified location in some cases, but there are no constraints on the value of the data. This allows some weak constraints to be imposed even when the value of the data is not determined until after the lock script has become immutable.

[0102] The operation of the lock script and unlock script of a blockchain transaction involves specifying certain constraints and the data that the constraints may include, and can be used to implement a "smart contract". A smart contract can define the terms and conditions of a contract, including who can do what, when they can do it, and who is paid what when. The terms and conditions can be expressed as weak or strong constraints on the unlock script or other parts of the payment transaction, and these terms and conditions of the smart contract can be enforced by the blockchain protocol.

[0103] For purposes of illustration, in an example, Alice loans some money to Bob, and Bob agrees to repay Alice. The lock script and unlock script of the sequence of blockchain transactions can be implemented as a smart contract that represents the payment that Bob makes to Alice. For example, the smart contract can be configured such that Bob makes monthly payments to Alice for the next three months, and if no payment is made, Bob's debt enters the debt collection stage. In the debt collection stage, Alice can release the transaction and transfer the transaction to a debt collector who will recover the debt from Bob. Such a smart contract can be generated using variations to the lock script and unlock script described in this specification.

[0104] In another example, Alice is a very charitable person who distributes one unit of a digital asset every month. Her rule is that anyone can claim the digital asset, but only one unit can be claimed per month. Alice generates a smart contract in the manner described in this disclosure and seeds it with an initial pool of three units of the digital asset. Alice can configure a script that permits any entity to take one unit of the digital asset each month. This script is replicated to enable the remaining portion of the digital asset to be claimed over the sequence of monthly blockchain transactions.

[0105] The unlock script and the lock script of a blockchain transaction sequence can embody a bytecode sequence that implements a trustless deterministic finite state machine representing the state of a smart contract over time. More specifically, the bytecode sequence can be considered as a computer program that embodies a state machine having a set of state rules and a well-defined set of states. Thereby, the execution of the bytecode of the bytecode sequence (computer program) results in a transition between the states of the state machine. Some of the state rules are very complex and may have multiple paths. In such cases, some of the calculations or operations performed by the bytecode sequence can be done simultaneously or asynchronously with respect to other computer programs or operations.

[0106] The lock script can include constraints imposed on the unlock script and thus can require the insertion of specific data into the unlock script of a payment transaction input. The specific data can be, for example, a contiguous field of the payment transaction itself, a contiguous field of a previous transaction including the executing lock script, a current state value, an input (optional) from a determined source, and execution data specifying the conditions and operations of the state machine necessary to calculate the next state from the current state, and other inputs.

[0107] A lock script can include interpreter code and bytecode sequences. The interpreter code can be interpreted incrementally and sequentially to configure the execution of bytecode sequences. The execution of bytecode sequences can be understood as forming execution threads, similar to traditional programs. In traditional software programs, new execution threads can be generated and later joined together using the Fork-Join Model. This can enable new threads to continue executing until the containing program ends, the thread is requested to stop, or execution naturally ends. The executing program can wait for the thread to end and continue execution using the Join operation. This disclosure adopts this execution model for use within blockchain transactions in the context of smart contracts. To enable this behavior, the interpreted lock script utilizes specific markers or configurations that enable the interpreter code to determine when different functions (including fork, join, and barrier configurations) are required. These configurations support state machines that execute operations or calculations simultaneously or asynchronously with respect to other calculations or operations. The fork configuration generates multiple different execution paths (or "threads of execution" or "execution threads" or "execution thread instances") from one state or execution path. The execution threads generated from the fork configuration can be called child execution threads. One execution thread that generates a child execution thread can be called the parent execution thread. The fork configuration can be used to execute calculations or operations in parallel with each other (e.g., in a common map / reduce workflow) or to generate new contracts. The join configuration joins multiple different execution paths (or "threads of execution" or "execution threads" or "execution thread instances") together into one state or execution path. One execution thread generated by the join configuration can be called a child execution thread.Multiple execution threads that are combined to form a child execution thread can be referred to as a parent execution thread. The combination configuration can be used to fuse multiple execution threads of a smart contract together or to compose another smart contract from the results of multiple smart contracts. The barrier configuration is used to manage and control communication and cooperation between multiple different execution paths (or "threads of execution" or "execution threads" or "execution thread instances").

[0108] Figure 2 shows an exemplary embodiment of a sequence of blockchain transactions (TX1, TX2, TX3, TX4, TX5, TX6). Here, the sequence of blockchain transactions i) branches the execution of an execution thread to generate multiple execution threads under the control of a branching configuration, ii) utilizes inter-thread communication and cooperation between multiple execution threads under the control of a barrier configuration, and iii) fuses multiple execution threads under the control of a combination configuration. An execution thread is an execution path of one or more state machines that can be part of a smart contract or parts of different smart contracts.

[0109] Note that blockchain transactions TX3 and TX4, when committed to the blockchain, can represent the simultaneous or asynchronous execution of multiple execution threads (e.g., the thread A lock script of TX3, the thread B lock script of TX4) represented by the sequence of blockchain transactions. This can be useful when a smart contract needs to be executed in multiple simultaneous or asynchronous steps. Specifically, throughout the process of the contract, tasks can sometimes be executed simultaneously or asynchronously during the process of the contract. For example, a contract to build a house can have various stages of completion of tile laying work and various stages of completion of the exterior structure that can be executed in parallel. By enabling a smart contract to utilize blockchain transactions that are executed simultaneously or asynchronously with respect to each other, different fragments of the contract can be executed independently of each other in an asynchronous manner.

[0110] The branch configuration is encoded as part of the lock script of the blockchain transaction TX1. The branch configuration branches or clones the execution thread (or execution thread instance) of the blockchain transaction TX1 through the use of constraints on the lock script of the payment blockchain transaction TX2. At the transaction level, the branch configuration requires that for a given lock script, there must be at least two or more lock scripts in the payment blockchain transaction. In the illustrated example, the branch configuration of the lock script of the blockchain transaction TX1 supports the generation of multiple execution threads through the corresponding thread A lock script and thread B lock script of the two transaction outputs of the blockchain transaction TX2.

[0111] The barrier configuration is encoded as part of the thread A lock script of the blockchain transaction TX3 and / or the thread B lock script of the blockchain transaction TX4. The barrier configuration provides control over inter-thread communication and cooperation between the thread A lock script and the thread B lock script. Such control may include constraining the execution thread at a specific execution point, or stalling or sleeping until the execution of one execution thread (e.g., the thread B lock script) is released by the other execution thread (e.g., the thread A lock script), or other thread synchronization conditions. Such control can be used to avoid race conditions where multiple execution threads compete with each other to achieve their tasks. At the transaction level, the barrier configuration requires that each of the thread-specific lock scripts be managed or controlled, and that pointers to the thread-specific lock scripts and the corresponding thread-specific lock scripts must exist in the payment blockchain transaction.

[0112] The combining construct is encoded as part of the thread A lock script and / or the thread B lock script and is used to generate the blockchain transaction TX6. The combining construct can ensure that the thread A lock script and the thread B lock script have finished, and combine or fuse the execution states resulting from the thread A lock script and the thread B lock script into a single execution thread (e.g., the thread C lock script). This can be useful when a smart contract needs to process result data generated by multiple execution threads. At the transaction level, the combining construct requires that each of the thread-specific lock scripts be combined, and the corresponding lock script needs to be present in the payment blockchain transaction.

[0113] Figure 3A shows the generation, verification, and mining of the blockchain transaction TX2 of FIG. 2. Here, the lock script of the previous blockchain transaction TX1 encodes a branch configuration. This exemplary branch configuration branches the execution of the thread A lock script of the previous blockchain transaction TX1 to generate two execution threads (or execution thread instances) as the lock scripts of the two transaction outputs A and B of the blockchain transaction TX2 (for example, transaction output A includes the continuation of the thread A lock script of the previous blockchain transaction TX1, and transaction output B includes a new thread B lock script). In this case, the blockchain transaction TX2 is generated as shown. This includes a single transaction input, and two transaction outputs for the continuation of the thread A lock script and the new thread B lock script. The single transaction input includes the unlock script of the thread A lock script of the previous blockchain transaction TX1. The transaction output A for the continuation (or a portion thereof) of the thread A lock script is replicated from the transaction output of the previous blockchain transaction TX1. The transaction output B for the new thread B lock script is determined from the execution of the branch configuration. As described in more detail below, different scenarios are considered to exist for the new thread B lock script. Once generated, the blockchain transaction TX2 is sent or broadcast to the blockchain network for verification. Upon successful verification, the blockchain transaction TX2 can be mined by the mining nodes of the blockchain network for storage in the blockchain 208 as shown.

[0114] In one scenario (referred to as "forking by replicated threads"), the operation of the new thread B lock script for transaction output B of the transaction is replicated from the operation of the thread A lock script. In this case, two different execution threads sharing the same operation may execute with different input data. This is a useful variation in a typical MapReduce-type situation. In this "forking by replicated threads" scenario, the generation and / or verification of blockchain transaction TX2 involves processing each transaction output of blockchain transaction TX2 to check that the lock script of the transaction output of blockchain transaction TX2 matches the lock script of a single transaction output of the previous blockchain transaction TX1. If this check fails for any one of the transaction outputs of blockchain transaction TX2, a failure state is raised and blockchain transaction TX2 is considered invalid. If this check passes, the fork configuration can continue. Here, the execution state of the lock script of the transaction output of blockchain transaction TX2 can be checked to ensure it corresponds to a specified execution state. This specified execution state may be the same or different for the lock script of the transaction output of blockchain transaction TX2. If this further check fails for any one of the transaction outputs of blockchain transaction TX2, a failure state is raised and blockchain transaction TX2 is considered invalid. If this further check passes for all the transaction outputs of blockchain transaction TX2 and any additional checks are satisfied, blockchain transaction TX2 is considered valid.

[0115] In another scenario (referred to as "branching to support different threads"), the operation of the new thread B lock script for output B can be the same as, different from, or distinguishable from the operation of the thread A lock script. In this case, the set of valid hash values corresponding to valid lock scripts can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence interpreted as part of the lock script). The generation and / or verification of blockchain transaction TX2 may include determining the hash value of the lock script of the previous blockchain transaction pointed to by the transaction input of blockchain transaction TX2 and, if necessary, adding this hash value to the set of hash values. Each transaction output of blockchain transaction TX2 is processed to check that hashing the lock script of the transaction output of blockchain transaction TX2 generates a hash value that matches one of the valid hash values in the set. If this check fails for any one of the transaction outputs of blockchain transaction TX2, a failure state is raised and blockchain transaction TX2 is considered invalid. If this check passes, the branching configuration can continue. Here, the execution state of the lock script of the transaction output of blockchain transaction TX2 can be checked to ensure that it corresponds to the specified execution state. This specified execution state can be the same as or different from that of the lock script of the transaction output of blockchain transaction TX2. If this further check fails for any one of the transaction outputs of blockchain transaction TX2, a failure state is raised and blockchain transaction TX2 is considered invalid.If this further check passes for all the transaction outputs of the blockchain transaction TX2 and any additional checks are satisfied, the blockchain transaction TX2 is considered valid.

[0116] Figure 3B shows the generation, verification, and mining of the blockchain transaction TX3 of Figure 2. Here, the execution of the thread A lock script of the previous blockchain transaction TX2 continues. In this case, the blockchain transaction TX3 is generated as shown. This includes a single transaction input and a single transaction output that includes the continuation of the thread A lock script. The transaction input includes the unlock script of the thread A lock script of the previous blockchain transaction TX2. The transaction output for the continuation (or a portion thereof) of the thread A lock script is replicated from the transaction output of the previous blockchain transaction TX2 for the thread A lock script. Once generated, the blockchain transaction TX3 is sent or broadcast to the blockchain network for verification. If the verification is successful, the blockchain transaction TX3 can be mined by the mining nodes of the blockchain network for storage in the blockchain 208.

[0117] In an embodiment, the generation and / or verification of blockchain transaction TX3 may include processing the transaction output of blockchain transaction TX3 to check that the lock script of the transaction output of blockchain transaction TX3 matches the lock script of the transaction output of the previous blockchain transaction TX2 for the thread A lock script. If this check fails for the transaction output of blockchain transaction TX3, a failure state is raised and blockchain transaction TX3 is considered invalid. If the check for the transaction output of blockchain transaction TX3 passes, the execution state of the lock script of the transaction output of blockchain transaction TX3 may be checked to ensure that it corresponds to the specified execution state. If this further check fails, blockchain transaction TX3 is considered invalid. If this further check passes and any additional checks are satisfied, blockchain transaction TX3 is considered valid.

[0118] Figure 3B shows the generation, verification, and mining of blockchain transaction TX4 of FIG. 2. Here, the execution of the thread B lock script of the previous blockchain transaction TX2 continues. In this case, the blockchain transaction TX4 is generated as shown. This includes a single transaction input and a single transaction output including the continuation of the thread B lock script. The transaction input includes the unlock script of the thread B lock script of the previous blockchain transaction TX2. The transaction output for the continuation (or a portion thereof) of the thread B lock script is replicated from the transaction output of the previous blockchain transaction TX2 for the thread B lock script. Once generated, the blockchain transaction TX4 is sent or broadcast to the blockchain network for verification. Upon successful verification, the blockchain transaction TX4 can be mined by the mining nodes of the blockchain network for storage in the blockchain 208.

[0119] In an embodiment, the generation and / or verification of blockchain transaction TX4 may include processing the transaction output of blockchain transaction TX4 to check that the lock script of the transaction output of blockchain transaction TX4 matches the lock script of the transaction output of the previous blockchain transaction TX2 for the thread B lock script. If this check fails for the transaction output of blockchain transaction TX4, a failure state is raised and blockchain transaction TX4 is considered invalid. If the check for the transaction output of blockchain transaction TX4 passes, the execution state of the lock script of the transaction output of blockchain transaction TX4 may be checked to ensure that it corresponds to the specified execution state. If this further check fails, a failure state is raised and blockchain transaction TX4 is considered invalid. If this further check passes and any additional checks are satisfied, blockchain transaction TX4 is considered valid.

[0120] Figure 3C shows the generation, verification, and mining of the blockchain transaction TX5 in FIG. 2. Here, it includes the execution of the thread A lock script of the previous blockchain transaction TX3 and the execution of the thread B lock script of the previous blockchain transaction TX4 under the control of the barrier configuration. In this case, the blockchain transaction TX5 is generated as shown. This includes two transaction inputs (one includes the unlock script of the thread A lock script of the previous blockchain transaction TX3, and the other includes the unlock script of the thread B lock script of the previous blockchain transaction TX4), and two transaction outputs of the thread A lock script and the thread B lock script. The transaction output A for the thread A lock script (or a part thereof) is replicated from the transaction output of the previous blockchain transaction TX3. The transaction output B for the thread B lock script (or a part thereof) is replicated from the transaction output of the previous blockchain transaction TX4. Once generated, the blockchain transaction TX5 is sent or broadcast to the blockchain network for verification. If the verification is successful, the blockchain transaction TX5 can be mined by the mining nodes of the blockchain network for storage in the blockchain 208.

[0121] In an embodiment, generating or verifying the blockchain transaction TX5 may include processing each transaction output of the blockchain transaction TX5 to check that the lock script of the transaction output of the blockchain transaction TX5 matches the lock script of the corresponding transaction output of the previous blockchain transaction (e.g., TX3 or TX4 in this example). If this check fails for any one of the transaction outputs of the blockchain transaction TX5, a failure state is raised and the blockchain transaction TX5 is considered invalid. If this check passes, the barrier configuration can continue, where the execution state of the lock script of the transaction output of the blockchain transaction TX5 can be checked to ensure that it corresponds to the specified execution state. The resulting execution state can be described by one or more parameters of the barrier configuration. Such parameters can include restricting the thread for execution at a particular execution point, or stalling or sleeping the execution of one thread of execution (e.g., the thread B lock script) until it is released by another thread of execution (e.g., the thread A lock script), or other thread synchronization conditions. Such control can be used to avoid race conditions where multiple threads of execution compete with each other to achieve their tasks. If this further check fails for any one of the transaction outputs of the blockchain transaction TX5, a failure state is raised and the blockchain transaction TX5 is considered invalid. If this further check passes for all the transaction outputs of the blockchain transaction TX5 and any additional checks are satisfied, the blockchain transaction TX5 is considered valid.

[0122] Figure 3D shows the generation, verification, and mining of blockchain transaction TX6 of Figure 2. Here, multiple execution threads (thread A lock script and thread B lock script) of the previous blockchain transaction TX5 under the control of the combined configuration are combined into a single execution thread (thread C lock script) of blockchain transaction TX6. In this case, blockchain transaction TX6 is generated as shown. This includes two transaction inputs (one includes the unlock script of the thread A lock script of the previous blockchain transaction TX5, and the other includes the unlock script of the thread B lock script of the previous blockchain transaction TX5), and one transaction output of the new thread C lock script. The transaction output for the thread C lock script can be determined from the execution of the combined configuration. As will be described in more detail below, different scenarios are considered to exist for the thread C lock script. Once generated, blockchain transaction TX6 is sent or broadcast to the blockchain network for verification. Upon successful verification, blockchain transaction TX6 can be mined by the mining nodes of the blockchain network for storage in blockchain 208.

[0123] In one scenario (referred to as "Combination by Duplicated Thread"), the operations of the new thread C lock script are replicated from the common operations of the thread A lock script and the thread B lock script. In this scenario, the generation and / or verification of the blockchain transaction TX2 may involve processing a single transaction output of the blockchain transaction TX6 to check that the lock script of the transaction output matches the lock script of each of one of the two transaction outputs of the previous blockchain transaction TX5 (the thread A lock script and the thread B lock script). If this check fails for any one of the parent lock scripts, a failure state is raised and the blockchain transaction TX6 is considered invalid. If this check passes, the combination process continues. Here, the thread A lock script and the thread B lock script are executed to some statically defined or dynamically inferred specific locations, and then the resulting execution states are combined or merged to derive an initial execution state for the execution of the thread C lock script at some defined location. If this further check fails, a failure state is raised and the blockchain transaction TX6 is considered invalid. If this further check passes and any additional checks are satisfied, the blockchain transaction TX6 is considered valid.

[0124] In another scenario (referred to as "combining to support different threads"), the operation of the new thread C lock script can be the same as, different from, or distinguishable from the operations of the thread A lock script and the thread B lock script. In this case, the set of valid hash values corresponding to valid lock scripts can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence interpreted as part of the lock script). The generation and / or verification of the blockchain transaction TX6 may include determining the hash values of the thread A lock script and the thread B lock script of the previous blockchain transaction TX5 pointed to by the transaction input of the blockchain transaction TX6, and, if necessary, adding these hash values to the set of hash values. The transaction output of the blockchain transaction TX6 is processed to check that hashing the lock script of the transaction output of the blockchain transaction TX6 generates a hash value that matches one of the valid hash values in the set. If this check fails, a failure state is raised and the blockchain transaction TX6 is considered invalid. If this check passes, the combining configuration continues. Here, the thread A lock script and the thread B lock script are executed to some statically defined or dynamically inferred specific locations, and then the resulting execution states are combined or fused to derive an initial execution state for the execution of the thread C lock script at some defined location. If this further check fails, a failure state is raised and the blockchain transaction TX6 is considered invalid. If this further check passes and any additional checks are satisfied, the blockchain transaction TX6 is considered valid.

[0125] In all of these scenarios of the combination configuration, the specified execution state of transaction TX6 can ensure that the thread A lock script and / or the thread B lock script have finished execution, and may include combining or fusing the execution states resulting from the thread A lock script and the thread B lock script. This may be useful when a smart contract needs to process result data generated by multiple execution threads.

[0126] Figure 4 shows another sequence of blockchain transactions of different smart contracts. Here, the sequence of blockchain transactions branches the execution of the execution thread to generate multiple execution threads under the control of a branching configuration or operation, and ii) fuses multiple execution threads under the control of a combination configuration or operation. This sequence of blockchain transactions avoids inter-thread communication and cooperation between multiple execution threads under the control of a barrier configuration or operation.

[0127] The blockchain transactions TX2, TX3, and TX4 in Figure 4 can be generated, verified, and mined as described above with respect to Figures 3A - 3B. Note that the blockchain transactions TX3 and TX4, when committed to the blockchain, can represent the concurrent or asynchronous execution of multiple execution threads represented by the sequence of blockchain transactions (e.g., the thread A lock script of blockchain transaction TX3 and the thread B lock script of blockchain transaction TX4).

[0128] Figure 5 shows the generation, verification, and mining of blockchain transaction TX6 of FIG. 4. Here, the execution thread of the thread A lock script of the previous blockchain transaction TX3 and the execution thread of the thread B lock script of the previous blockchain transaction TX4 under the control of the combined configuration are combined into a single execution thread (thread C lock script) of blockchain transaction TX6'. In this case, blockchain transaction TX6' is generated as shown. This includes two transaction inputs (one including the unlock script of the thread A lock script of the previous blockchain transaction TX3 and the other including the unlock script of the thread B lock script of the previous blockchain transaction TX4), and one transaction output of the new thread C lock script. The transaction output for the thread C lock script can be determined from the execution of the combined configuration. As described in more detail below, different scenarios are considered to exist for the thread C lock script. Once generated, blockchain transaction TX6' is sent or broadcast to the blockchain network for verification. Upon successful verification, blockchain transaction TX6' can be mined by the mining nodes of the blockchain network for storage in blockchain 208.

[0129] In the "Combination by Replicated Thread" scenario, the operations of the thread C lock script are replicated from the common operations of the thread A lock script and the thread B lock script. In this scenario, the verification of the blockchain transaction TX6 may include processing a single transaction output of the blockchain transaction TX6 and checking that the lock script of the transaction output matches the thread A lock script of the transaction output of the previous blockchain transaction TX3 and the thread B lock script of the transaction output of the previous blockchain transaction TX4. If this check fails for any one of the parent thread lock scripts, a failure state is raised and the blockchain transaction TX6' is considered invalid. If this check passes, the combination configuration can continue. Here, the execution state of the lock script of the transaction output of the blockchain transaction TX6' can be checked to ensure that it corresponds to the specified execution state and the execution state of the parent thread of the thread A lock script of the previous blockchain transaction TX3 and the thread B lock script of the previous blockchain transaction TX4. If this further check fails, a failure state is raised and the blockchain transaction TX6' is considered invalid. If this further check passes and any additional checks are satisfied, the blockchain transaction TX6' is considered valid.

[0130] In the "join supporting different threads" scenario, the operations of the new thread C lock script can be the same as or different from (or distinguished from) the operations of the thread A lock script and the thread B lock script. In this case, the set of valid hash values corresponding to valid lock scripts can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence interpreted as part of the lock script). The generation and / or verification of the blockchain transaction TX6' may include determining the hash values of the thread A lock script of the previous blockchain transaction TX3 and the thread B lock script of the previous blockchain transaction TX4 pointed to by the transaction input of the blockchain transaction TX6', and, if necessary, adding these hash values to the set of hash values. The transaction output of the blockchain transaction TX6' is processed to check that hashing the lock script of the transaction output of the blockchain transaction TX6' generates a hash value that matches one of the valid hash values of the set. If this check fails, a failure state is raised and the blockchain transaction TX6' is considered invalid. If this check passes, the join configuration can continue. Here, the execution state of the lock script of the transaction output of the blockchain transaction TX6' can be checked to ensure that it corresponds to the specified execution state and the execution state of the parent threads of the thread A lock script of the previous blockchain transaction TX3 and the thread B lock script of the previous blockchain transaction TX4. If this further check fails, a failure state is raised and the blockchain transaction TX6' is considered invalid. If this further check passes and any additional checks are satisfied, the blockchain transaction TX6' is considered valid.

[0131] In all of these scenarios of the binding configuration, the specified execution state of transaction TX6’ can ensure that the thread A lock script and / or the thread B lock script have finished execution, and may include combining or fusing the execution states resulting from the thread A lock script and the thread B lock script. This may be useful when a smart contract needs to process result data generated by multiple execution threads.

[0132] Figure 6 shows exemplary details of blockchain transaction TX2 of Figure 2. Here, the execution of the lock script of the previous blockchain transaction TX1 includes the execution of a branching configuration. The branching configuration branches the execution of the execution thread (i.e., the thread A lock script) executed as the lock script of the previous blockchain transaction TX1 to generate a plurality of execution threads (i.e., the continuation of the thread A lock script and the new thread B lock script).

[0133] As schematically illustrated, the previous blockchain transaction TX1 has a single transaction input Vin[x] that includes an unlock script (labeled "scriptSig"). The previous blockchain transaction TX1 also has a transaction output Vout[x] that represents a thread A lock script (labeled "scriptPubKey") that includes a bytecode sequence and an interpreter code. The bytecode sequence is a computer program that can be considered as a state machine that embodies a state rule set having a state rule set and a clearly defined state set. Thereby, the execution of the bytecode of the bytecode sequence (computer program) results in a transition between the states of the state machine. The interpreter code supports the interpretation of the bytecode sequence of the thread A lock script. The thread A lock script also includes a current state execution pointer (or "current execution pointer") and contiguous state data (labeled "virtual memory") that together represent the current state within the state of the state machine represented by the bytecode sequence of the thread A lock script. The current execution pointer, included as part of the thread A lock script, refers to the execution point of the bytecode sequence corresponding to the current state. The contiguous state data, included as part of the thread A lock script, represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the current execution pointer included in the thread A lock script.

[0134] As can be seen in the example of FIG. 6, the payment blockchain transaction TX2 has a single transaction input Vin[x] and two separate transaction outputs, namely, one Vout[x] representing the thread A lock script and the other Vout[y] representing the thread B lock script. The single transaction input Vin[x] of the payment blockchain transaction TX2 includes a pointer to the transaction output Vout[x] of the previous blockchain transaction TX1 and an unlock script (the "scriptSig") for the thread A lock script of the transaction output Vout[x] of the previous blockchain transaction TX1. Both transaction outputs Vout[x] and Vout[y] include a bytecode sequence and an interpreter code. The bytecode sequence and interpreter code of the thread A lock script of the payment blockchain transaction TX2 can be replicated from the bytecode sequence and interpreter code of the thread A lock script of Vout[x] of the previous blockchain transaction TX1.

[0135] The thread A lock script of the transaction output Vout[x] of the payment blockchain transaction TX2 also includes the following state execution pointer (or "next execution pointer") and the contiguous state data (labeled as "virtual memory") that together represent the next state within the state of the state machine represented by the bytecode sequence of the thread A lock script. The next execution pointer included as part of the thread A lock script refers to the execution point of the bytecode sequence of the thread A lock script corresponding to the next state. The contiguous state data included as part of the thread A lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread A lock script.

[0136] Note that the sequential state data included in the thread A lock script of the payment blockchain transaction TX2 can be determined by generating or accessing the next execution pointer included in the thread A lock script of the payment blockchain transaction TX2 when generating the payment blockchain transaction TX2, restoring the current state of the execution of the bytecode sequence of the thread A lock script using the sequential state data of the thread A lock script of the previous blockchain transaction TX1, and then executing the bytecode sequence of the thread A lock script. Such execution starts at the point (or operation) corresponding to the current execution pointer of the thread A lock script included in the previous blockchain transaction TX1 and ends at the point (or operation) corresponding to the next execution pointer of the thread A lock script. Such execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] of the payment blockchain transaction TX2.

[0137] Note that the number of bytecode operations of the thread A lock script of the payment blockchain transaction TX2, which is executed when generating and verifying the payment blockchain transaction TX2, is described by the difference between the current execution pointer of the thread A lock script included in the previous blockchain transaction TX1 and the next execution pointer of the thread A lock script of the payment blockchain transaction TX2. This difference in execution pointers can be changed by design by selecting or changing the next execution pointer of the thread A lock script of the payment blockchain transaction TX2. Thus, the number of bytecode operations of the thread A lock script of the payment blockchain transaction TX2, which is executed when generating and verifying the payment blockchain transaction TX2, can be restricted or used when parameterizing the constraints for the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically divide the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates a new transaction based on the parameterized constraint, or for other possible uses.

[0138] The transaction output Vout[y] of the payment blockchain transaction TX2 for the new thread B lock script is determined from the execution of the branch configuration. As described in more detail below, different scenarios are considered to exist for the new thread B lock script.

[0139] In the "fork by replicated thread" scenario, the bytecode sequence and interpreter code of the new thread B lock script can be replicated from the bytecode sequence and interpreter code of the thread A lock script of Vout[x] of the previous blockchain transaction TX1. In this case, two different execution threads (the thread A lock script of Vout[x] of the payment blockchain transaction TX2, and the thread B lock script of Vout[y] of the payment blockchain transaction TX2) that share the same operation can execute with different input data. This is a useful variation in a general MapReduce-type situation. The thread B lock script of the transaction output Vout[y] of the payment blockchain transaction TX2 also includes the following state execution pointer (or "next execution pointer"), and the consecutive state data (labeled as "virtual memory") that represents the next state within the state of the state machine represented by the bytecode sequence of the thread B lock script. The next execution pointer included as part of the thread B lock script refers to the execution point of the bytecode sequence of the thread B lock script corresponding to this next state. The consecutive state data included as part of the thread B lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread B lock script.

[0140] Note that the sequential state data included in the thread B lock script of the payment blockchain transaction TX2 can be determined by generating or accessing the next execution pointer included in the thread B lock script of the payment blockchain transaction TX2 when generating the payment blockchain transaction TX2, restoring the current state of the execution of the bytecode sequence of the thread B lock script using the sequential state data of the thread A lock script of the previous blockchain transaction TX1, and then executing the bytecode sequence of the thread B lock script. Such execution starts at the point (or operation) corresponding to the current execution pointer of the thread A lock script included in the previous blockchain transaction TX1 and ends at the point (or operation) corresponding to the next execution pointer of the thread B lock script. Such execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] of the payment blockchain transaction TX2.

[0141] In the "fork by replicated thread" scenario, the number of bytecode operations of the thread B lock script of the payment blockchain transaction TX2 executed when generating and verifying the payment blockchain transaction TX2 can be described by the difference between the current execution pointer of the thread A lock script included in the previous blockchain transaction TX1 and the next execution pointer of the thread B lock script of the payment blockchain transaction TX2. This difference in execution pointers can be changed by design by selecting or changing the execution pointer of the next execution pointer of the thread B lock script of the payment blockchain transaction TX2. Thus, the number of bytecode operations of the thread B lock script of the payment blockchain transaction TX2 executed when generating and verifying the payment blockchain transaction TX2 can be restricted or used when parameterizing the constraints on the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically divide the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates a new transaction based on the parameterized constraint, or for other possible uses.

[0142] In the "branching by replicated thread" scenario, the generation and / or verification of blockchain transaction TX2 involves processing each transaction output of payment blockchain transaction TX2 to check that the bytecode sequence and interpreter code of the lock script of a given transaction output (or the hash value of a combination of such data) match the bytecode sequence and interpreter code of the thread A lock script of a single transaction output Vout[x] of the previous blockchain transaction TX1 (or the hash value of a combination of such data). If this check fails for any one of the transaction outputs, a failure state is raised and blockchain transaction TX2 is considered invalid. If this check passes, the branching configuration can continue. Here, the execution state of the bytecode sequence of the lock script of the transaction outputs of blockchain transaction TX2 can be checked to ensure that it corresponds to the specified execution state. This specified execution state can be the same or different for the two lock scripts of the transaction outputs of payment blockchain transaction TX2. If this further check fails for any one of the transaction outputs, a failure state is raised and blockchain transaction TX2 is considered invalid. If this further check passes for all the transaction outputs of payment blockchain transaction TX2 and any additional checks are satisfied, payment blockchain transaction TX2 is considered valid.

[0143] In other embodiments, a payment blockchain transaction can include two or more transaction outputs that represent two or more child execution threads that branch from the parent execution thread of the lock script of the previous blockchain transaction. In the "fork by replicated threads" scenario, the lock script of the transaction output of the payment blockchain transaction represents a plurality of execution threads that are each replicated from the lock script of the previous blockchain transaction. In an embodiment, the lock script of each transaction output can include a number of elements including: · A child thread bytecode sequence to be executed; · An interpreter code that interprets and executes the child thread bytecode sequence; · A next execution pointer that represents the execution position within the child thread bytecode sequence; · A copy or snapshot of the virtual memory that represents the execution state of the child thread bytecode sequence at the next execution pointer. In other embodiments, the lock script of each transaction output can include additional or other data elements. Further, the unlock script ("scriptSig") of the transaction input of a payment blockchain transaction (which refers to the parent execution thread of the lock script of a previous blockchain transaction branched by a fork configuration) can include: i) a copy of a portion of the payment blockchain transaction itself, and ii) a copy of the previous blockchain transaction that refers to the transaction input. When verifying a payment blockchain transaction, note that the unlock script is first placed in virtual memory (the stack) and is thus accessible for later use by the specific interpreter virtual bytecode of the corresponding lock script. By including these two items as part of the unlock script ("scriptSig") of the transaction input of a payment blockchain transaction, it is possible to perform verification of the payment blockchain transaction and the fork configuration.

[0144] The following Table A provides pseudo-code that describes the virtual bytecode (VOP_FORK_DUP) of the branching configuration according to the "fork by replicated thread" scenario described in the present specification. The virtual bytecode VOP_FORK_DUP is included in the bytecode sequence of the lock script, can be interpreted using the interpreter code included in the lock script, and executes the operations of Table A. The virtual bytecode VOP_FORK_DUP can be interpreted when generating and / or verifying payment blockchain transactions as described in the present specification. In this case, the operation extracts the lock script of the previous blockchain transaction stored in the unlock script of the transaction input of the payment blockchain transaction and pointed to by the transaction input. The operation loops through a set of transaction outputs of the payment blockchain transaction that can be represented by parameters that can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence interpreted as part of the lock script). For each transaction output, it checks that the bytecode sequence and interpreter code of the lock script included in the transaction output (or the hash value of the combination of such data) match the bytecode sequence and interpreter code of the lock script of the previous blockchain transaction stored in the unlock script of the transaction input of the payment blockchain transaction (or the hash value of the combination of such data). If this check fails for any one of the transaction outputs, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the interpretation of the combined configuration can continue. Here, it is checked that the next execution pointer of the bytecode sequence of the lock script of the transaction output is at a specific position. The next execution pointer of the bytecode sequence of the lock script of the transaction output can be the same or different.If this further check fails for any one of the transaction outputs, the failure state is raised and the blockchain transaction is considered invalid. If this further check passes for all the transaction outputs and any additional checks are satisfied, the blockchain transaction is considered valid. If the verification of the VOP_FORK_DUP virtual bytecode is successful, the execution of one or more bytecodes of the child thread lock script of the payment blockchain transaction continues and is checked to ensure that it matches a snapshot of the virtual memory representing the execution state of the child thread bytecode sequence at the next execution pointer for the verification of the payment blockchain transaction. Table A

Table 1

[0145] In another scenario (the "branch that supports different threads"), the bytecode sequence and / or interpreter code of the new thread B lock script can be the same as or different from (or distinguishable from) the bytecode sequence and interpreter code of the thread A lock script of the previous blockchain transaction T1. In this scenario, the set of valid hash values corresponding to the valid bytecode sequence and interpreter code can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence interpreted as part of the lock script). The thread B lock script of the transaction output Vout[y] of the payment blockchain transaction TX2 also includes the following state execution pointer (or "next execution pointer") and the consecutive state data (labeled as "virtual memory") that represents the next state within the state of the state machine represented by the bytecode sequence of the thread B lock script. The next execution pointer included as part of the thread B lock script refers to the execution point of the bytecode sequence of the thread B lock script corresponding to this next state. The consecutive state data included as part of the thread B lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread B lock script.

[0146] In this "branch supporting different threads" scenario, the sequential state data included in the thread B lock script of the payment blockchain transaction TX2 can be determined by generating or accessing the next execution pointer included in the thread B lock script of the payment blockchain transaction TX2 when generating the payment blockchain transaction TX2, initializing the current state of the execution of the bytecode sequence of the thread B lock script, and then executing the bytecode sequence of the thread B lock script. Such execution ends at the point (or operation) corresponding to the next execution pointer of the thread B lock script. Such execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] of the payment blockchain transaction TX2.

[0147] In the "branch supporting different threads" scenario, the number of bytecode operations of the thread B block script of the payment blockchain transaction TX2 executed when generating and verifying the payment blockchain transaction TX2 can be described by the difference between the initial execution pointer of the bytecode sequence of the thread B block script and the next execution pointer of the thread B block script of the payment blockchain transaction TX2. This difference in the execution pointer can be changed by design by selecting or changing the next execution pointer of the thread B block script of the payment blockchain transaction TX2. Thus, the number of bytecode operations of the thread B block script of the payment blockchain transaction TX2 executed when generating and verifying the payment blockchain transaction TX2 can be restricted or used when parameterizing the constraints for the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically divide the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates new transactions based on the parameterized constraint, or for other possible uses.

[0148] In the "branch supporting different threads" scenario, the generation and verification of the payment blockchain transaction TX2 may include determining the hash value of the concatenation of the bytecode sequence and interpreter code of the thread A lock script of the previous blockchain transaction TX1, and, if necessary, adding this hash value to a set of configured values. The process then loops through the transaction outputs (Vout[x] and Vout[y]) of the payment blockchain transaction TX2. Here, each iteration of the loop checks that the hashing of the concatenation of the bytecode sequence and interpreter code of the lock script of a particular transaction output matches one of the valid hash values in the set. If this check fails for any one of the transaction outputs, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the branch configuration can continue, where the execution state of the bytecode sequence of the lock script of the transaction output can be checked to ensure that it corresponds to the specified execution state. The specified execution state of the bytecode sequence of the lock script of the transaction output can be the same or different. If this further check fails for any one of the transaction outputs, a failure state is raised and the payment blockchain transaction TX2 is considered invalid. If these further checks pass and any additional checks are satisfied, the payment blockchain transaction TX2 is considered valid.

[0149] In other embodiments, a payment blockchain transaction that includes a branching configuration can include two or more transaction outputs that represent two or more child execution threads that branch from the parent execution thread of the lock script of the previous blockchain transaction. In a "branching that supports different threads" scenario, the lock script of the transaction output of a payment blockchain transaction represents different execution threads of the payment blockchain transaction. In an embodiment, the lock script of each transaction output can include a number of elements including: · A child thread bytecode sequence to be executed; · An interpreter code that interprets and executes the child thread bytecode sequence; · A next execution pointer that represents an execution position within the child thread bytecode sequence; · A copy or snapshot of virtual memory that represents the execution state of the child thread bytecode sequence at the next execution pointer. In other embodiments, the lock script of each transaction output can include additional or other data elements. Further, the unlock script ("scriptSig") of a transaction input of a payment blockchain transaction (which refers to the parent execution thread of the lock script of a previous blockchain transaction branched by a fork configuration) can include: i) a copy of a portion of the payment blockchain transaction itself, and ii) a copy of the previous blockchain transaction that refers to the transaction input. When verifying a payment blockchain transaction, note that the unlock script is first placed in virtual memory (the stack) and is thus accessible for later use by the specific interpreter virtual bytecode of the corresponding lock script. By including these two items as part of the unlock script ("scriptSig") of a transaction input of a payment blockchain transaction, it is possible to perform verification of the payment blockchain transaction and the fork configuration.

[0150] The following Table B provides pseudocode that describes the virtual bytecode (VOP_FORK_DISTINCT) of a branch configuration according to the "branch supporting different threads" scenario described in the present specification. The virtual bytecode VOP_FORK_DISTINCT is included in the bytecode sequence of the lock script and can be interpreted using the interpreter code included in the lock script to execute the operations in Table B. The virtual bytecode VOP_FORK_DISTINCT can be interpreted when generating and / or verifying payment blockchain transactions as described in the present specification. The operation extracts the lock script of the previous blockchain transaction stored in the unlock script of the transaction input of the payment transaction. The operation loops through a set of child thread lock scripts (corresponding to the set of transaction outputs) of the payment blockchain transaction, which can be represented by parameters that can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence being interpreted as part of the lock script). The operation reads hash values corresponding to the concatenation of the bytecode sequence and interpreter code of each child thread lock script (or transaction output). In an embodiment, these hash values can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence being interpreted as part of the lock script). For example, in relation to the VOP_FORK_DISTINCT virtual bytecode, several bytes of data following the virtual bytecode can be specified together with a character delimiter used to determine the concatenation of the bytecode sequence / interpreter code hash values of the set of child thread lock scripts (and thus the set of bytecode sequence / interpreter code hash values and the corresponding set of transaction outputs).The calculation initializes a set of hash values corresponding to the combination of a valid bytecode sequence and interpreter code. This set of hash values can be stored statically (e.g., as part of the interpreter code of a lock script) or can be represented by data that can be stored dynamically (e.g., in the bytecode sequence interpreted as part of a lock script). Next, the hash value of the combination of the bytecode sequence and interpreter code of the lock script of the previous blockchain transaction is calculated and added to the set. The calculation then loops through the set of transaction outputs of the payment blockchain transaction. For each transaction output, the calculation extracts the lock script from the corresponding output of the payment blockchain transaction, calculates the hash value of the combination of the extracted bytecode sequence of the lock script and the interpreter code, and checks that the calculated hash value exists in the set of hash values. If this check fails for any one of the transaction outputs, a failure state is raised and the payment blockchain transaction is considered invalid. If this check passes, the branching configuration can continue. Here, the execution state of the lock script of the transaction output of the payment blockchain transaction can be checked to ensure that it corresponds to the specified execution state. This specified execution state can be the same or different for the lock script of the transaction output of the payment blockchain transaction. If this further check fails for any one of the transaction outputs, a failure state is raised and the blockchain transaction is considered invalid. If this further check passes for all transaction outputs and any additional checks are satisfied, the payment blockchain transaction is considered valid.If the verification of the VOP_FORK_DISTINCT virtual bytecode is successful, the execution of one or more bytecodes of the child thread lock script of the payment blockchain transaction continues and is checked to ensure that it matches a snapshot of the virtual memory representing the execution state of the child thread bytecode sequence at the next execution pointer for the verification of the payment blockchain transaction.

[0151] Furthermore, it is also possible to have a child thread bytecode sequence of the output of the payment blockchain transaction included in the parent thread bytecode sequence of the previous blockchain transaction. In this case, next, it is simply checked that the child thread bytecode sequence exists within the parent thread bytecode sequence, and then it is possible to continue executing the bytecode sequence from the specific position that includes the child thread operation. Table B [Table 2]

[0152] Figure 7 shows exemplary details of the blockchain transaction TX3 of Figure 2. Here, the execution of the thread A lock script of the previous blockchain transaction TX2 continues. As schematically illustrated, the previous blockchain transaction TX2 has a single transaction input Vin[x] and two separate transaction outputs, namely, one transaction output Vout[x] representing the thread A lock script and the other Vout[y] representing the thread B lock script. Both transaction outputs include a bytecode sequence and an interpreter code. The transaction input Vin[x] of the previous blockchain transaction TX2 includes a pointer to the transaction output Vout[x] of the previous blockchain transaction TX1 and an unlock script ("scriptSig").

[0153] The thread A lock script of the transaction output Vout[x] of the previous blockchain transaction TX2 includes a current state execution pointer (or "current execution pointer") and contiguous state data (labeled "virtual memory") that together represent the current state within the state of the state machine represented by the bytecode sequence of the thread A lock script. The current execution pointer included as part of the thread A lock script refers to the execution point of the bytecode sequence of the thread A lock script corresponding to this current state. The contiguous state data included as part of the thread A lock script represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the current execution pointer included in the thread A lock script.

[0154] As can be seen in the example of FIG. 7, the payment blockchain transaction TX3 has a single transaction input Vin[x] and a single transaction output Vout[x]. The transaction input Vin[x] includes a pointer to the transaction output Vout[x] of the previous blockchain transaction TX2 and an unlock script (labeled "scriptSig") for the thread A lock script of the transaction output Vout[x] of the previous blockchain transaction TX2. The transaction output Vout[x] represents a thread A lock script (labeled "scriptPubKey") that includes a bytecode sequence and an interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread A lock script. The bytecode sequence and interpreter code of the thread A lock script of the payment blockchain transaction TX3 can be replicated from the bytecode sequence and interpreter code of the Vout[x] thread A lock script of the previous blockchain transaction TX2.

[0155] The thread A lock script of the payment blockchain transaction TX3 includes the following state execution pointer (or "next execution pointer") and the continuous state data (labeled as "virtual memory") that represents the next state among the states of the state machine represented by the bytecode sequence of the thread A lock script. The next execution pointer included as part of the thread A lock script refers to the execution point of the bytecode sequence of the thread A lock script corresponding to the next state. The continuous state data included as part of the thread A lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread A lock script.

[0156] The continuous state data included in the thread A lock script of the payment blockchain transaction TX3 can be determined by generating or accessing the next execution pointer included in the thread A lock script of the payment blockchain transaction TX3 when generating the payment blockchain transaction TX3, restoring the current state of the execution of the bytecode sequence of the thread A lock script using the continuous state data of the thread A lock script of the previous blockchain transaction TX2, and then executing the bytecode sequence of the thread A lock script. Such execution starts at the point (or operation) corresponding to the current execution pointer of the thread A lock script included in the previous blockchain transaction TX2 and ends at the point (or operation) corresponding to the next execution pointer of the thread A lock script. Such execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] of the payment blockchain transaction TX3.

[0157] Note that the number of bytecode operations of the thread A lock script of the payment blockchain transaction TX3, which is executed when generating and verifying the payment blockchain transaction TX3, is described by the difference between the current execution pointer of the thread A lock script included in the previous blockchain transaction TX2 and the next execution pointer of the thread A lock script of the payment blockchain transaction TX3. This difference in the execution pointer can be changed by design by selecting or changing the next execution pointer of the thread A lock script of the payment blockchain transaction TX3. Thus, the number of bytecode operations of the thread A lock script of the payment blockchain transaction TX3, which is executed when generating and verifying the payment blockchain transaction TX3, can be restricted or used when parameterizing the constraints for the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically divide the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates a new transaction based on the parameterized constraint, or for other possible uses.

[0158] The generation and / or verification of the payment blockchain transaction TX3 may include processing the transaction output Vout[x] of the payment blockchain transaction TX3 to check that the bytecode sequence and interpreter code of the thread A lock script of the transaction output Vout[x] (or the hash value of the combination of such data) match the bytecode sequence and interpreter code of the thread A lock script of the transaction output Vout[x] of the previous blockchain transaction TX2 (or the hash value of the combination of such data). If this check fails, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the operation can continue, where the execution state of the thread A lock script of the payment blockchain transaction TX3 can be checked to ensure that it corresponds to the specified execution state. If this further check fails, a failure state is raised and the blockchain transaction is considered invalid. If this further check passes and any additional checks are satisfied, the blockchain transaction is considered valid.

[0159] Figure 8 shows exemplary details of the blockchain transaction TX4 of FIG. 2. Here, the execution of the thread B lock script of the previous blockchain transaction TX2 continues. As schematically illustrated, the previous blockchain transaction TX2 has a single transaction input Vin[x] and two separate transaction outputs, namely, one transaction output Vout[x] representing the thread A lock script and the other Vout[y] representing the thread B lock script. Both transaction outputs include a bytecode sequence and an interpreter code. The single transaction input Vin[x] of the previous blockchain transaction TX2 includes a pointer to the transaction output Vout[x] of the previous blockchain transaction TX1 and an unlock script ("scriptSig").

[0160] The thread B lock script of the transaction output Vout[y] of the previous blockchain transaction TX2 represents the current state together with the current state execution pointer (or "current execution pointer") and the continuous state data (labeled "virtual memory") representing the state of the state machine in the state represented by the bytecode sequence of the thread B lock script. The current execution pointer included as part of the thread B lock script refers to the execution point of the bytecode sequence of the thread B lock script corresponding to this current state. The continuous state data included as part of the thread B lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the current execution pointer included in the thread B lock script.

[0161] As can be seen in the example of FIG. 8, the payment blockchain transaction TX4 has a single transaction input Vin[x] and a single transaction output Vout[x]. The transaction input Vin[x] includes a pointer to the transaction output Vout[y] of the thread B lock script of the previous blockchain transaction TX2 and an unlock script (labeled "scriptSig") for the thread B lock script of the previous blockchain transaction TX2. The transaction output Vout[x] represents a thread B lock script (labeled "scriptPubKey") that includes a bytecode sequence and an interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread B lock script. The bytecode sequence and interpreter code of the thread B lock script of the payment blockchain transaction TX4 can be replicated from the bytecode sequence and interpreter code of the thread B lock script of Vout[y] of the previous blockchain transaction TX2.

[0162] The thread B lock script of Vout[x] of the payment blockchain transaction TX4 also includes the following state execution pointer (or "next execution pointer") and contiguous state data (labeled "virtual memory") that together represent the next state within the state of the state machine represented by the bytecode sequence of the thread B lock script. The next execution pointer, included as part of the thread B lock script, refers to the execution point of the bytecode sequence of the thread B lock script corresponding to the next state. The contiguous state data, included as part of the thread B lock script, represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread B lock script.

[0163] The sequential state data included in the thread B lock script of the payment blockchain transaction TX4 can be determined by generating or accessing the next execution pointer included in the thread B lock script of the payment blockchain transaction TX4 when generating the payment blockchain transaction TX4, restoring the current state of the execution of the bytecode sequence of the thread B lock script using the sequential state data of the thread B lock script of the previous blockchain transaction TX2, and then executing the bytecode sequence of the thread B lock script. Such execution starts at the point (or operation) corresponding to the current execution pointer of the thread B lock script included in the previous blockchain transaction TX2 and ends at the point (or operation) corresponding to the next execution pointer of the thread B lock script. Such execution can also use the input determined by the execution of the unlock script ("scriptSig") of Vin[x] of the payment blockchain transaction TX4.

[0164] Note that the number of bytecode operations of the thread B block script of the payment blockchain transaction TX4, when generating and verifying the payment blockchain transaction TX4, is described by the difference between the current execution pointer of the thread B block script included in the previous blockchain transaction TX2 and the next execution pointer of the thread B block script of the payment blockchain transaction TX4. This difference in execution pointers can be changed by design by selecting or changing the next execution pointer of the thread B block script of the payment blockchain transaction TX4. Thus, the number of bytecode operations of the thread B block script of the payment blockchain transaction TX4, when generating and verifying the payment blockchain transaction TX4, can be restricted or used when parameterizing the constraints for the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically partition the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates new transactions based on the parameterized constraint, or for other possible uses.

[0165] The generation and / or verification of payment blockchain transaction TX4 involves processing the transaction output Vout[x] of payment blockchain transaction TX4 to check that the bytecode sequence and interpreter code of the thread B lock script of transaction output Vout[x] (or the hash value of the combination of such data) match the bytecode sequence and interpreter code of the thread B lock script of transaction output Vout[y] of the previous blockchain transaction TX2 (or the hash value of the combination of such data). If this check fails, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the operation can continue, where the execution state of the thread B lock script of payment blockchain transaction TX4 can be checked to ensure that it corresponds to the specified execution state. If this further check fails, a failure state is raised and the blockchain transaction' is considered invalid. If this further check passes and any additional checks are met, the blockchain transaction is considered valid.

[0166] Figure 9 shows exemplary details of blockchain transaction TX5 of Figure 2. Here, the execution of the thread A lock script of the previous blockchain transaction TX3 and the execution of the thread B lock script of the previous blockchain transaction TX4 continue under the control of the barrier configuration.

[0167] As schematically illustrated, the previous blockchain transaction TX3 has a single transaction input Vin[x] that includes an unlock script (labeled "scriptSig"). The previous blockchain transaction TX3 also has a transaction output Vout[x] that represents a thread A lock script (labeled "scriptPubKey") that includes a bytecode sequence and interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread A lock script. The thread A lock script also includes a current state execution pointer (or "current execution pointer") and contiguous state data (labeled "virtual memory") that together represent the current state within the state of the state machine represented by the bytecode sequence of the thread A lock script. The current execution pointer, included as part of the thread A lock script, references the execution point of the bytecode sequence corresponding to the current state. The contiguous state data, included as part of the thread A lock script, represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the current execution pointer included in the thread A lock script.

[0168] As schematically illustrated, the previous blockchain transaction TX4 has a single transaction input Vin[x] that includes an unlock script (labeled "scriptSig"). The previous blockchain transaction TX4 also has a transaction output Vout[x] that represents a thread B lock script (labeled "scriptPubKey") that includes a bytecode sequence and interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread B lock script. The thread B lock script also includes a current state execution pointer (or "current execution pointer") and contiguous state data (labeled "virtual memory") that together represent the current state within the state of the state machine represented by the bytecode sequence of the thread B lock script. The current execution pointer included as part of the thread B lock script refers to the execution point of the bytecode sequence corresponding to the current state. The contiguous state data included as part of the thread B lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the current execution pointer included in the thread B lock script.

[0169] As can be seen in the example of FIG. 9, the payment blockchain transaction TX5 has two separate transaction inputs Vin[x], Vin[y] and two separate transaction outputs Vout[x], Vout[y]. The transaction input Vin[x] of the payment blockchain transaction TX5 includes a pointer to the transaction output Vout[x] of the thread A lock script of the previous blockchain transaction TX3 and an unlock script ( "scriptSig") for the thread A lock script of Vout[x] of the previous blockchain transaction TX3. The transaction input Vin[y] of the payment blockchain transaction TX5 includes a pointer to the transaction output Vout[x] of the thread B lock script of the previous blockchain transaction TX4 and an unlock script ( "scriptSig") for the thread B lock script of Vout[x] of the previous blockchain transaction TX3. The transaction output Vout[x] represents the thread A lock script. The transaction output Vout[y] represents the thread B lock script. Both transaction outputs include a bytecode sequence and an interpreter code. The interpreter code supports the interpretation of the bytecode sequence of a given transaction output.

[0170] The bytecode sequence and interpreter code of the thread A lock script of Vout[x] of the payment blockchain transaction TX5 can be replicated from the bytecode sequence and interpreter code of the thread A lock script of Vout[x] of the previous blockchain transaction TX3. The thread A lock script of Vout[x] of the payment blockchain transaction TX5 also includes the next state execution pointer (or "next execution pointer") and the contiguous state data (labeled as "virtual memory") that together represent the next state within the state of the state machine represented by the bytecode sequence of the thread A lock script. The next execution pointer, included as part of the thread A lock script, refers to the execution point of the bytecode sequence of the thread A lock script corresponding to the next state. The contiguous state data, included as part of the thread A lock script, represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread A lock script.

[0171] Note that the continuous state data included in the thread A lock script of the payment blockchain transaction TX5 can be determined by generating or accessing the next execution pointer included in the thread A lock script of the payment blockchain transaction TX5 when generating the payment blockchain transaction TX5, restoring the current state of the execution of the bytecode sequence of the thread A lock script using the continuous state data of the thread A lock script of the previous blockchain transaction TX3, and then executing the bytecode sequence of the thread A lock script. Such execution starts at the point (or operation) corresponding to the current execution pointer of the thread A lock script included in the previous blockchain transaction TX3 and ends at the point (or operation) corresponding to the next execution pointer of the thread A lock script. Such execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] of the payment blockchain transaction TX5.

[0172] Note that the number of bytecode operations of the Thread A lock script of the payment blockchain transaction TX5, when generating and verifying the payment blockchain transaction TX5, is described by the difference between the current execution pointer of the Thread A lock script included in the previous blockchain transaction TX3 and the next execution pointer of the Thread A lock script of the payment blockchain transaction TX5. This difference in execution pointers can be changed by design by selecting or changing the next execution pointer of the Thread A lock script of the payment blockchain transaction TX5. Thus, the number of bytecode operations of the Thread A lock script of the payment blockchain transaction TX5, when generating and verifying the payment blockchain transaction TX5, can be restricted or used when parameterizing the constraints on the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically partition the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates a new transaction based on the parameterized constraint, or for other possible uses.

[0173] The bytecode sequence and interpreter code of the Thread B lock script of Vout[y] of the payment blockchain transaction TX5 can be replicated from the bytecode sequence and interpreter code of the Thread B lock script of Vout[x] of the previous blockchain transaction TX4.

[0174] The thread B block script of Vout[y] of the payment blockchain transaction TX5 includes the following state execution pointer (or "next execution pointer") and the consecutive state data (labeled as "virtual memory") that represents the next state within the state of the state machine represented by the bytecode sequence of the thread B block script. The next execution pointer included as part of the thread B block script refers to the execution point of the bytecode sequence of the thread B block script corresponding to the next state. The consecutive state data included as part of the thread B block script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread B block script.

[0175] Note that the consecutive state data included in the thread B block script of the payment blockchain transaction TX5 can be determined by generating or accessing the next execution pointer included in the thread B block script of the payment blockchain transaction TX5 when generating the payment blockchain transaction TX5, restoring the current state of the execution of the bytecode sequence of the thread B block script using the consecutive state data of the thread B block script of the previous blockchain transaction TX4, and then executing the bytecode sequence of the thread B block script. Such execution starts at the point (or operation) corresponding to the current execution pointer of the thread B block script included in the previous blockchain transaction TX4 and ends at the point (or operation) corresponding to the next execution pointer of the thread B block script. Such execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[y] of the payment blockchain transaction TX5.

[0176] Note that the number of bytecode operations of the thread B block script of the payment blockchain transaction TX5, which is executed when generating and verifying the payment blockchain transaction TX5, is described by the difference between the current execution pointer of the thread B block script included in the previous blockchain transaction TX4 and the next execution pointer of the thread B block script of the payment blockchain transaction TX5. This difference in execution pointers can be changed by design by selecting or changing the next execution pointer of the thread B block script of the payment blockchain transaction TX5. Thus, the number of bytecode operations of the thread B block script of the payment blockchain transaction TX5, which is executed when generating and verifying the payment blockchain transaction TX5, can be restricted or used when parameterizing the constraints for the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically divide the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates a new transaction based on the parameterized constraint, or for other possible uses.

[0177] During the generation and execution of payment blockchain transaction TX5, the execution state of the thread A lock script and / or the execution state of the thread B lock script resulting from the execution of the thread A lock script and the thread B lock script can be described by one or more parameters of the barrier configuration or operation. Such parameters may include restricting the thread for execution at a specific execution point, or stalling or sleeping the execution of one execution thread (e.g., the thread B lock script) until it is released by the other execution thread (e.g., the thread A lock script), or other thread synchronization conditions. Such control can be used to avoid race conditions where multiple execution threads compete with each other to achieve their tasks.

[0178] The generation and / or verification of the blockchain transaction TX5 involves processing the transaction output Vout[x] of the blockchain transaction TX5 to check that the lock script of the transaction output Vout[x] matches the lock script of the corresponding transaction output Vout[x] of the previous blockchain transaction TX3 for the thread A lock script, and processing the transaction output Vout[y] of the blockchain transaction TX5 to check that the lock script of the transaction output Vout[y] matches the lock script of the corresponding transaction output Vout[x] of the previous blockchain transaction TX4 for the thread B lock script. If this check fails for any one of the transaction outputs of the blockchain transaction TX5, a failure state is raised and the blockchain transaction TX5 is considered invalid. If this check passes, the barrier configuration can continue, where the execution states of the thread A lock script and the thread B lock script of the transaction outputs of the blockchain transaction TX5 can be checked to ensure that they correspond to their specified execution states. The resulting execution states of the thread A lock script and the thread B lock script can be described by one or more parameters of the barrier configuration or operation. Such parameters can include restricting the threads for execution at a specific execution point, or stalling or sleeping the execution of one thread of execution (e.g., the thread B lock script) until it is released by the execution of the other thread of execution (e.g., the thread A lock script), or other thread synchronization conditions. Such control can be used to avoid race conditions where multiple threads of execution compete with each other to achieve their tasks. If this further check fails, a failure state is raised and the payment blockchain transaction TX5 is considered invalid.If this further check passes and any additional checks are satisfied, the blockchain transaction TX5 is considered valid.

[0179] In other embodiments, a payment blockchain transaction including a barrier configuration can include more than two transaction inputs and corresponding transaction outputs representing more than two execution threads to be managed or controlled. In a payment blockchain transaction including a barrier configuration, the lock script of the transaction output of the payment blockchain transaction represents the resulting execution threads. In an embodiment, the lock script of each transaction output can include a number of elements including: · A thread bytecode sequence to be executed; · An interpreter code to interpret and execute the thread bytecode sequence; · A next execution pointer representing the execution position within the thread bytecode sequence; · A copy or snapshot of the virtual memory representing the execution state of the thread bytecode sequence at the next execution pointer. In other embodiments, the lock script of each transaction output can include additional or other data elements. Further, the unlock script of the transaction input of a payment blockchain transaction (the "scriptSig"), which refers to multiple execution threads of the lock script of a previous blockchain transaction that is the subject of the barrier configuration, each includes: i) a copy of a portion of the payment blockchain transaction itself, and ii) a copy of the previous blockchain transaction that refers to each transaction input. When verifying a payment blockchain transaction, note that the unlock script is first placed in virtual memory (the stack) and is thus accessible for later use by the specific interpreter virtual bytecode of the corresponding lock script. By including these two items as part of the unlock script (the "scriptSig") of the transaction input of a payment blockchain transaction, it is possible to verify the payment blockchain transaction and the barrier configuration.

[0180] Table C provides pseudocode that describes the virtual bytecode (VOP_BARRIER) of the barrier configuration described in this specification. The virtual bytecode VOP_BARRIER is included in the bytecode sequence of the lock script, is interpreted using the interpreter code included in the lock script, and can execute the operations of Table C. The virtual bytecode VOP_BARRIER can be interpreted when generating and / or verifying payment blockchain transactions as described in this specification. The barrier configuration can restrict another thread to a specific point or can restrict it further ahead in its execution for the execution of that thread. If the verification of the VOP_BARRIER virtual bytecode is successful, the execution of one or more bytecodes of the child thread lock script of each transaction output of the payment blockchain transaction continues and is checked to ensure that it matches a snapshot of the virtual memory representing the execution state of the child thread bytecode sequence at the next execution pointer for the verification of the payment blockchain transaction. Table C [Table 3]

[0181] Figure 10 shows exemplary details of the blockchain transaction TX6' of Figure 5. Here, under the control of the combined configuration, the execution of the thread A lock script of the previous blockchain transaction TX3 and the execution of the thread B lock script of the previous blockchain transaction TX4 are combined.

[0182] As schematically illustrated, the previous blockchain transaction TX3 has a single transaction input Vin[x] that includes an unlock script (labeled "scriptSig"). The previous blockchain transaction TX3 also has a transaction output Vout[x] that represents a thread A lock script (labeled "scriptPubKey") that includes a bytecode sequence and interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread A lock script. The thread A lock script also includes a current state execution pointer (or "current execution pointer") and sequential state data (labeled "virtual memory") that together represent the current state within the state of the state machine represented by the bytecode sequence of the thread A lock script. The current execution pointer, which is included as part of the thread A lock script, references the execution point of the bytecode sequence corresponding to the current state. The sequential state data, which is included as part of the thread A lock script, represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the current execution pointer included in the thread A lock script.

[0183] As schematically illustrated, the previous blockchain transaction TX4 has a single transaction input Vin[x] that includes an unlock script (labeled "scriptSig"). The previous blockchain transaction TX4 also has a transaction output Vout[x] that represents a thread B lock script (labeled "scriptPubKey") that includes a bytecode sequence and interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread B lock script. The thread B lock script also includes a current state execution pointer (or "current execution pointer") and contiguous state data (labeled "virtual memory") that together represent the current state within the state of the state machine represented by the bytecode sequence of the thread B lock script. The current execution pointer, included as part of the thread B lock script, references the execution point of the bytecode sequence corresponding to the current state. The contiguous state data, included as part of the thread B lock script, represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the current execution pointer included in the thread B lock script.

[0184] As can be seen in the example of FIG. 10, the payment blockchain transaction TX6’ has two separate transaction inputs Vin[x] and Vin[y] for two threads to be combined, and one transaction output Vout[x] representing the thread C lock script. The transaction input Vin[x] of the payment blockchain transaction TX6’ includes a pointer to the transaction output Vout[x] of the thread A lock script of the previous blockchain transaction TX3, and an unlock script ("scriptSig") for the thread A lock script of Vout[x] of the previous blockchain transaction TX3. The transaction input Vin[y] of the payment blockchain transaction TX6’ includes a pointer to the transaction output Vout[x] of the thread B lock script of Vout[x] of the previous blockchain transaction TX4, and an unlock script ("scriptSig") for the thread B lock script of Vout[x] of the previous blockchain transaction TX4.

[0185] The transaction output Vout[x] of the payment blockchain transaction TX6’ includes a bytecode sequence and an interpreter code. The interpreter code supports the interpretation of the bytecode sequence of the thread C lock script of the transaction output Vout[x]. The thread C lock script of Vout[y] of the payment blockchain transaction TX6’ also includes the following state execution pointer (or “current execution pointer”), and consecutive state data (labeled as “virtual memory”) that together represent the next state within the state of the state machine represented by the bytecode sequence of the thread C lock script. The next execution pointer included as part of the thread C lock script refers to the execution point of the bytecode sequence of the thread C lock script corresponding to the next state. The consecutive state data included as part of the thread C lock script represents the state of the state machine represented by the bytecode sequence at the execution point referred to by the next execution pointer included in the thread C lock script. The transaction output Vout[x] of the payment blockchain transaction TX6’ for the new thread C lock script is determined from the execution of the combined configuration. As described in more detail below, different scenarios are considered to exist for the new thread C lock script.

[0186] In the “combination by replicated threads” scenario, the bytecode sequence and interpreter code of the new thread C lock script can be replicated from the bytecode sequence and interpreter code of the thread A lock script of Vout[x] of the previous blockchain transaction TX3, or from the bytecode sequence and interpreter code of the thread B lock script of Vout[y] of the previous blockchain transaction TX4.

[0187] In this "joining by replicated threads" scenario, the sequential state data included in the thread C lock script of the payment blockchain transaction TX6' can be determined by executing the thread A lock script and the thread B lock script to a specific position, statically defined or dynamically estimated from, when generating the payment blockchain transaction TX6', then joining or fusing the resulting execution states to derive the initial execution state of the bytecode sequence of the thread C lock script, and then executing the bytecode sequence of the thread C lock script. Such an execution ends at the point (or operation) corresponding to the next execution pointer of the thread C lock script. Such an execution can also use the inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] and / or the unlock script ("scriptSig") of Vin[y] of the payment blockchain transaction TX6'.

[0188] In the "Combined by Replicated Threads" scenario, the number of bytecode operations of the Thread C lock script of the payment blockchain transaction TX6' executed when generating and verifying the payment blockchain transaction TX6' can be described by the difference between the current execution pointer of the Thread A lock script included in the previous blockchain transaction TX3 (or the current execution pointer of the Thread B lock script included in the previous blockchain transaction TX4) and the next execution pointer of the Thread C lock script of the payment blockchain transaction TX6'. This difference in execution pointers can be changed by design by selecting or changing the next execution pointer of the Thread C lock script of the payment blockchain transaction TX6'. Thus, the number of bytecode operations of the Thread C lock script of the payment blockchain transaction TX6' executed when generating and verifying the payment blockchain transaction TX6' can be restricted or used when parameterizing the constraints for the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of a smart contract), to logically divide the bytecode sequence of a smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for an entity that generates a new transaction based on the parameterized constraint, or for other possible uses.

[0189] In the "Combination by Replicated Threads" scenario, the generation and / or verification of the payment blockchain transaction TX6' involves processing the transaction output Vout[x] of the blockchain transaction TX6' to check that the bytecode sequence and interpreter code of the Thread C lock script of the transaction output Vout[x] (or the hash of such data combination) match the bytecode sequence and interpreter code of the Thread A lock script of the transaction output Vout[x] of the previous blockchain transaction TX3 (or the hash of such data combination), and / or match the bytecode sequence and interpreter code of the Thread B lock script of the single transaction output Vout[x] of the previous blockchain transaction TX4 (or the hash of such data combination). If this check fails, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the combination configuration can proceed, where the execution states of the lock scripts of the transaction inputs of the blockchain transaction are checked to ensure they correspond to the specified execution states, and then such execution states can be combined or merged together. If this further check fails, a failure state is raised and the payment blockchain transaction TX6' is considered invalid. If this further check passes and any additional checks are satisfied, the blockchain transaction TX6' is considered valid.

[0190] In other embodiments, a payment blockchain transaction including a merge construct can include more than two transaction inputs representing more than two parent execution threads that are fused together to form a child execution thread of the lock script of the payment blockchain transaction. In the "merge by replicated threads" scenario, the lock script of the payment blockchain transaction that merges multiple execution threads of the lock script of the previous blockchain transaction can include the following number of elements: · A child thread bytecode sequence to be executed; · An interpreter code that interprets and executes the child thread bytecode sequence; · A next execution pointer representing an execution position within the child thread bytecode sequence; · A copy or snapshot of virtual memory representing the execution state of the child thread bytecode sequence at the next execution pointer. In other embodiments, the lock script of a payment blockchain transaction that combines multiple execution threads of the lock script of a previous blockchain transaction can include additional or other data elements. Further, the unlock script of a transaction input of a payment blockchain transaction ("scriptSig") (which refers to the multiple execution threads of the lock script of the previous blockchain transaction to be combined by the combining configuration) each includes: i) a copy of a portion of the payment blockchain transaction itself, and ii) a copy of the previous blockchain transaction that refers to each transaction input. When verifying a payment blockchain transaction, note that the unlock script is first placed in virtual memory (the stack) and is thus accessible for later use by a specific interpreter virtual bytecode of the corresponding lock script. By including these two items as part of the unlock script ("scriptSig") of a transaction input of a payment blockchain transaction, the payment blockchain transaction and the combining configuration can be verified.

[0191] The following Table D provides pseudo-code that describes virtual bytecode (VOP_JOIN_DUP) for joining the execution threads of the lock scripts of multiple previous blockchain transactions under the control of a join configuration, according to the "join by replicated thread" scenario. The virtual bytecode VOP_JOIN_DUP is included in the bytecode sequence of the lock script and is interpreted using the interpreter code included in the lock script to perform the operations of Table D. The virtual bytecode VOP_JOIN_DUP can be interpreted when generating and / or verifying payment blockchain transactions as described in this specification. The operation extracts the lock script of the payment blockchain transaction stored in the unlock script of the transaction input. The operation loops through the set of transaction inputs of the payment blockchain transaction. For each transaction input, the operation extracts the lock script of the previous blockchain transaction stored in the unlock script of the corresponding transaction input and designated as the transaction input, and checks that the bytecode sequence and interpreter code (or hash value of such a combination of data) of the lock script of the payment blockchain transaction match what is included in the lock script of the previous blockchain transaction stored in the unlock script of the corresponding transaction input. If this check fails for any one of the transaction inputs, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the operations of the join configuration can continue. Here, the next execution pointer of the lock script of the payment blockchain transaction is checked against some statically defined or dynamically estimated specific position. If the next execution pointer is correct, the execution state of the lock script of the previous blockchain transaction is extracted and the virtual memory instances are fused together to form a single virtual memory state of the resulting execution thread.If the next execution pointer is incorrect, a failure state is raised and the payment blockchain transaction is considered invalid. If the verification of the VOP_JOIN_DUP virtual bytecode is successful, the execution of one or more bytecodes of the child thread lock script of the payment blockchain transaction continues and is checked to ensure consistency with a snapshot of the virtual memory representing the execution state of the child thread bytecode sequence at the next execution pointer for the verification of the payment blockchain transaction. Table D [Table 4]

[0192] In the "join to support different threads" scenario, the bytecode sequence and / or interpreter code of the new thread C lock script can be the same as or different from (or distinguishable from) the bytecode sequence and / or interpreter code of the thread A lock script of the previous blockchain transaction T3, or the bytecode sequence of the thread B lock script of the previous blockchain transaction T4. In this scenario, the bytecode sequence and interpreter code of the new thread C lock script can be copied from the set of valid bytecode sequences and interpreter codes used in the lock script.

[0193] In this "joining that supports different threads" scenario, the sequential state data included in the thread C lock script of the payment blockchain transaction TX6' is determined by executing the thread A lock script and the thread B lock script from a specific position that is statically defined or dynamically estimated from something when generating the payment blockchain transaction TX6', then combining or fusing the resulting execution states to derive the initial execution state of the bytecode sequence of the thread C lock script, and then executing the bytecode sequence of the thread C lock script. Such execution ends at a point (or operation) corresponding to the next execution pointer of the thread C lock script. Such execution can also use inputs determined by the execution of the unlock script ("scriptSig") of Vin[x] and / or the unlock script ("scriptSig") of Vin[y] of the payment blockchain transaction TX6'.

[0194] In the "Combination Supporting Different Threads" scenario, the number of bytecode operations of the Thread C lock script of the payment blockchain transaction TX6' executed when generating and verifying the payment blockchain transaction TX6' can be described by the next execution pointer of the Thread C lock script of the payment blockchain transaction TX6'. Thus, the number of bytecode operations of the Thread C lock script of the payment blockchain transaction TX6' executed when generating and verifying the payment blockchain transaction TX6' can be restricted or used when parameterizing the constraints on the payment transaction. This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations in the bytecode sequence of the smart contract), to logically divide the bytecode sequence of the smart contract into different segments executed across the sequence of payment transactions, to calculate the reward for the entity generating new transactions based on the parameterized constraint, or for other possible uses.

[0195] In the "Combination Supporting Different Threads" scenario, a set of valid hash values resistant to valid lock scripts can be accessed and maintained. The generation and / or verification of the payment blockchain transaction TX6' may include processing the transaction output Vout[x] of the payment blockchain transaction TX6' to check that the thread C lock script of the transaction output Vout[x] generates a hash value that matches one of the valid hash values in the set. If this check fails, a failure state is raised and the blockchain transaction TX6' is considered invalid. If this check passes, the operation of the combination configuration can continue. Here, the next execution pointer of the new execution thread to be combined is checked against some statically defined or dynamically estimated specific position. If the next execution pointer is correct, the execution state of the thread of the lock script execution of the previous blockchain transaction is extracted and merged together. If the next execution pointer is incorrect, a failure state is raised and the blockchain transaction is considered invalid.

[0196] In all of these scenarios, the combination configuration may include ensuring that the thread A lock script and / or the thread B lock script have finished execution and combining or merging the resulting execution states of the thread A lock script and the thread B lock script. This may be useful when a smart contract needs to process result data generated by multiple execution threads.

[0197] In other embodiments, note that a payment blockchain transaction that includes a combined construction can include more than two transaction inputs that represent more than two parent execution threads that are fused together to form a child execution thread of the lock script of the payment blockchain transaction. In the "combination by different threads" scenario, the lock script of the payment blockchain transaction that combines multiple execution threads of the lock script of the previous blockchain transaction can include the following number of elements: · A child thread bytecode sequence to be executed; · Interpreter code that interprets and executes the child thread bytecode sequence; · A next execution pointer that represents an execution position within the child thread bytecode sequence; · A copy or snapshot of virtual memory that represents the execution state of the child thread bytecode sequence at the next execution pointer. In other embodiments, the lock script of the payment blockchain transaction that combines multiple execution threads of the lock script of the previous blockchain transaction can include additional or other data elements. Further, the unlock script ("scriptSig") of the transaction input of the payment blockchain transaction, which refers to the multiple execution threads of the lock script of the previous blockchain transaction to be combined by the combining configuration, each includes: i) a copy of a portion of the payment blockchain transaction itself, and ii) a copy of the previous blockchain transaction referring to each transaction input. When verifying the payment blockchain transaction, note that the unlock script is first placed in virtual memory (the stack) and is accessible for later use by a specific interpreter virtual bytecode of the corresponding lock script. By including these two items as part of the unlock script ("scriptSig") of the transaction input of the payment blockchain transaction, the payment blockchain transaction and the combining configuration can be verified.

[0198] The following Table E provides pseudocode that describes virtual bytecode (VOP_JOIN_DISTINCT) for joining the execution threads of the lock scripts of multiple previous blockchain transactions under the control of a join configuration according to the "join supporting different threads" scenario. The virtual bytecode VOP_JOIN_DISTINCT is included in the bytecode sequence of the lock script, is interpreted using the interpreter code included in the lock script, and can execute the operations of Table E. The virtual bytecode VOP_JOIN_DISTINCT can be interpreted when generating and / or validating payment blockchain transactions as described in this specification. The operations loop through the number of parent thread lock scripts (corresponding to the number of transaction inputs) of the payment blockchain transaction, which can be represented by parameters that can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence being interpreted as part of the lock script). The operations read hash values corresponding to the concatenation of the bytecode sequence and interpreter code of each parent thread lock script. In embodiments, these hash values can be stored statically (e.g., as part of the interpreter code of the lock script) or dynamically (e.g., in the bytecode sequence being interpreted as part of the lock script). For example, in connection with the VOP_JOIN_DISTINCT virtual bytecode, several bytes of data following the virtual bytecode can be specified together with a character delimiter used to determine the concatenation of the bytecode sequences / interpreter code hash values of the number of parent thread lock scripts (and thus the number of bytecode sequences / interpreter code hash values and the corresponding number of transaction inputs). The operations initialize a set of hash values corresponding to the concatenation of valid bytecode sequences and interpreter code.This set of hash values can be stored statically (e.g., as part of the interpreter code of the lock script) or represented by data that can be stored dynamically (e.g., in a bytecode sequence that is interpreted as part of the lock script). Next, the hash value of the concatenation of the bytecode sequence of the parent thread lock script of the previous blockchain transaction and the interpreter code is calculated and added to the set. The operation then loops through the set of transaction inputs of the payment blockchain transaction. For each transaction input, the operation extracts the lock script of the payment blockchain transaction stored in the unlock script of the corresponding transaction input, extracts the lock script of the previous blockchain transaction stored in the unlock script of the corresponding transaction input of the payment blockchain transaction, and checks that the hash value of the concatenation of the bytecode sequence of the lock script of the payment blockchain transaction and the interpreter code exists in the set of hash values, and that the hash value of the concatenation of the bytecode sequence of the lock script of the previous blockchain transaction and the interpreter code (which corresponds to the transaction input) exists in the set of hash values. If this check fails for any one of the transaction inputs, a failure state is raised and the blockchain transaction is considered invalid. If this check passes, the operation on the concatenated structure can continue. Here, the next execution pointer of the lock script of the payment blockchain transaction is checked against some statically defined or dynamically inferred specific location. If the next execution pointer is correct, the execution state of the parent thread lock script of the previous blockchain transaction is extracted and the virtual memory instances are fused together to form a single virtual memory state of the child thread of execution. If the next execution pointer is incorrect, a failure state is raised and the payment blockchain transaction is considered invalid.If the verification of the VOP_JOIN_DISTINCT virtual bytecode is successful, the execution of one or more bytecodes of the child thread lock script of the payment blockchain transaction continues and is checked to ensure consistency with a snapshot of the virtual memory representing the execution state of the child thread bytecode sequence at the next execution pointer for the verification of the payment blockchain transaction. Table E [Table 5]

[0199] In an exemplary case of the "join by replicated threads" scenario, we can assume that one or more previous blockchain transactions have a lock script representing the execution of a set of threads from the same bytecode. Both threads are in a state where they need to be merged to continue to the next state. A new payment transaction is generated. This example is shown in Figure 7. The new payment transaction includes a single transaction output containing a lock script. The lock script includes the following: · The same bytecode sequence as the other two parent threads of the execution, which is the encapsulation of the entire program being executed on the blockchain; · The interpreter code used to interpret and execute the bytecode sequence; · The next execution pointer representing the execution position within the bytecode sequence; · A copy or snapshot of the virtual memory representing the execution state of the thread bytecode sequence at the next execution pointer. This payment blockchain transaction merges two execution threads represented by the lock scripts of the previous blockchain transactions and thus includes multiple transaction inputs each pointing to an execution thread to be merged.

[0200] In an embodiment, the bytecode sequence of the thread-specific lock script of the blockchain transaction described in the present specification is a computer instruction designed for interpretation by execution of the interpreter code included in each blockchain transaction. Execution of the interpreter code converts the bytecode of the bytecode sequence of the thread-specific lock script into an opcode or command supported by a software interpreter of the verification node's runtime system (e.g., a blockchain client). This verification node converts such an opcode or command into machine code executed by the CPU hardware of the verification node as shown in FIG. 11. Execution of the interpreter code can support the conversion of high-level bytecode or commands that extend or enhance low-level bytecode operations supported by a software interpreter of the verification node's runtime system. For example, the interpreter code can support the conversion of virtual bytecodes representing branch constructs (e.g., variants of the VOP_FORK_DUP or VOP_FORK_DISTINCT virtual bytecodes as described above), barrier constructs (e.g., the VOP_BARRIER virtual bytecode as described above), and / or join constructs (e.g., the VOP_JOIN_DUP or VOP_JOIN_DISTINCT virtual bytecodes as described above) into combinations of bytecode operations supported by a software interpreter of the verification node's runtime system. In this case, the interpreter code can support the conversion of such virtual bytecode operations into opcodes or commands belonging to the Bitcoin script language and supported by a software interpreter of the verification node's runtime system. In another example, the interpreter code can support the conversion of script bytecode operations described in a high-level programming language for interpretation by a software interpreter of the verification node's runtime system.In this case, the interpreter code can support the conversion of script virtual bytecode operations written in a high-level programming language to opcodes or commands that belong to the Bitcoin script language and are supported by the software interpreter of the verification node's runtime system. The execution of the software interpreter can convert the opcode or command, one bytecode at a time sequentially, to machine code (e.g., simple interpretation), or in some cases, use the just-in-time compilation method where a bytecode sequence segment (or a portion thereof) is compiled to machine code as needed at runtime, and then the resulting machine code is executed. The resulting machine code can, in some cases, be cached and reused later without the need for recompilation.

[0201] Note that the lock script of the blockchain transaction described in this specification can sometimes include a state that is updated during execution. In the context of smart contracts, this state can be broken down into two types. Namely, the "global shared state" used across the thread-specific lock scripts of the smart contract, or the "private state" used internally by one of the thread-specific lock scripts of the smart contract. Appropriate policies can be used to support both the "global shared state" and the "private state" in order to support the branching and joining of execution threads. These policies can be any of the following: · Static: The appropriate actions to be taken with respect to the state are handled by the interpreter in a single static manner. This is applied in the same way for each branch or join during the execution of the thread-specific lock scripts of the smart contract's blockchain transaction. · Dynamic: The appropriate actions are taken on a case-by-case basis. How the state is shared with new threads at a branch and used during the joining of threads is explicitly defined within the bytecode sequence being executed by the interpreter.

[0202] Accordingly, an embodiment of the present invention is a method implemented by a computer, the method comprising the steps of generating and / or verifying a payment blockchain transaction, the payment blockchain transaction comprising: i) a plurality of lock scripts, each lock script representing an instance of an execution thread, the execution thread being a thread that branches from an execution thread represented by a lock script of a previous blockchain transaction and / or an execution thread of at least one previous blockchain transaction that is managed and / or controlled for inter-thread communication and control; or ii) a lock script representing an instance of an execution thread combined from a plurality of execution thread instances represented by at least one previous blockchain transaction. A method may be provided that further comprises the step of communicating the payment blockchain transaction over a blockchain network for storage on the blockchain.

[0203] The payment blockchain transaction can be generated by a node of the blockchain network and / or the payment blockchain transaction can reference a lock script of a previous blockchain transaction that represents an execution thread. Additionally or alternatively, the payment blockchain transaction comprises a plurality of lock scripts. Each lock script represents an instance of an execution thread that branches from an execution thread represented by a lock script of a previous blockchain transaction. Additionally or alternatively, a node transmits the payment blockchain transaction to other nodes of the blockchain network for verification and storage in the blockchain.

[0204] The execution thread represented by the lock script of the previous blockchain transaction includes a bytecode sequence. At least one instance of an execution thread represented by a plurality of lock scripts of a payment blockchain transaction is generated by replicating the bytecode sequence of the lock script of the previous blockchain transaction.

[0205] Alternatively, the execution thread represented by the lock script of the previous blockchain transaction includes a bytecode sequence and an interpreter code. At least one instance of an execution thread represented by a plurality of lock scripts of a payment blockchain transaction is generated by replicating the bytecode sequence and the interpreter code of the lock script of the previous blockchain transaction. Alternatively, the node stores or accesses a set of valid bytecode sequences. At least one instance of an execution thread represented by a plurality of lock scripts of a payment blockchain transaction is generated by replicating the valid bytecode sequences of the set. As yet another alternative, the node stores or accesses a set of valid bytecode sequences and valid interpreter code. At least one instance of an execution thread represented by a plurality of lock scripts of a payment blockchain transaction is generated by replicating the valid bytecode sequences and the valid interpreter code of the set.

[0206] Additionally or alternatively, the generation of a payment blockchain transaction includes generating execution state information (e.g., the next execution pointer) of a plurality of lock scripts of the payment blockchain transaction representing an instance of an execution thread, and including the execution state information (e.g., the next execution pointer) in the plurality of lock scripts of the payment blockchain transaction.

[0207] Payment blockchain transactions can be received by nodes of a blockchain network. Additionally or alternatively, a payment blockchain transaction refers to a lock script of a previous blockchain transaction representing an execution thread. Additionally or alternatively, a payment blockchain transaction includes multiple lock scripts. Each lock script represents an instance of an execution thread that branches from the execution thread represented by the lock script of the previous blockchain transaction. Additionally or alternatively, a node verifies a payment blockchain transaction by verifying the lock script of the payment blockchain transaction against one or more conditions.

[0208] In some embodiments, verification includes comparing at least one of a plurality of lock scripts of a payment blockchain transaction to a lock script of a previous blockchain transaction. Additionally or alternatively, verification includes checking execution state information (e.g., a next execution pointer) of an execution thread instance represented by a plurality of lock scripts of a payment blockchain transaction. Additionally or alternatively, the execution thread represented by the lock script of the previous blockchain transaction includes a bytecode sequence and optionally interpreter code. Each of the plurality of lock scripts of a payment blockchain transaction may be required to include the same bytecode sequence and optionally the same interpreter code for the verification of the payment blockchain transaction to succeed. Additionally or alternatively, verifying includes comparing the bytecode sequence and optionally the interpreter code of each of the plurality of lock scripts of a payment blockchain transaction to the bytecode sequence and optionally the interpreter code of the lock script of the previous blockchain transaction. Thereby, the verification of the payment blockchain transaction is determined based on the result of such comparison. The execution thread represented by the lock script of the previous blockchain transaction includes a bytecode sequence and optionally interpreter code. The plurality of lock scripts of a payment blockchain transaction can be either i) the same bytecode sequence and optionally the same interpreter code of the lock script of the previous blockchain transaction, or ii) different bytecode sequences and optionally interpreter codes belonging to a set of lock scripts valid for the verification of the payment blockchain transaction to succeed.

[0209] Additionally or alternatively, verifying includes generating a hash data value corresponding to the lock script of a previous blockchain transaction, adding the hash data value to a set of hash data values corresponding to a set of valid lock scripts, and comparing the hash data value generated for each lock script of the payment transaction to the set of hash data values. Thereby, verification of the payment blockchain transaction is determined based on the result of such comparison of hash data values.

[0210] Payment blockchain transactions can be generated by nodes of the blockchain network and / or a payment blockchain transaction refers to a plurality of lock scripts of one or more previous blockchain transactions, where each of the plurality of lock scripts represents an instance of an execution thread and / or a payment blockchain transaction includes a lock script representing an execution thread combined from the execution thread instances referred to by the payment blockchain transaction and / or a payment blockchain transaction is sent by a node to other nodes of the blockchain network for verification and storage within the blockchain.

[0211] A lock script representing a combined execution thread from an execution thread instance pointed to by a payment blockchain transaction can be generated by replicating the bytecode sequences of multiple lock scripts of one or more previous blockchain transactions. Alternatively, a lock script representing a combined execution thread from an execution thread instance pointed to by a payment blockchain transaction is generated by replicating the bytecode sequences and interpreter code of multiple lock scripts of one or more previous blockchain transactions. Alternatively, a node stores or accesses a set of valid bytecode sequences, and a lock script representing a combined execution thread from an execution thread instance pointed to by a payment blockchain transaction is generated by replicating the valid bytecode sequences of the set. Alternatively, a node stores or accesses a set of valid bytecode sequences and valid interpreter code, and a lock script representing a combined execution thread from an execution thread instance pointed to by a payment blockchain transaction is generated by replicating the valid bytecode sequences and valid interpreter code of the set.

[0212] Additionally or alternatively, the generation of a payment blockchain transaction includes generating execution state information (e.g., the next execution pointer) of a combined execution thread from an execution thread instance pointed to by the payment blockchain transaction, and including the execution state information (e.g., the next execution pointer) in the lock script of the payment blockchain transaction.

[0213] Payment blockchain transactions can be received by nodes of the blockchain network, and / or a payment blockchain transaction refers to multiple lock scripts of one or more previous blockchain transactions, where each of the multiple lock scripts represents an instance of an execution thread, and / or a payment blockchain transaction includes a lock script representing an execution thread combined from the execution thread instances pointed to by the payment blockchain transaction, and / or a node verifies a payment blockchain transaction by verifying the lock script of the payment blockchain transaction against one or more conditions.

[0214] In one or more embodiments, verifying includes comparing the lock script of a payment blockchain transaction with a plurality of lock scripts of one or more previous blockchain transactions, and / or verifying includes checking the execution state information (e.g., the next execution pointer) of the plurality of lock scripts of one or more previous blockchain transactions and then fusing or combining such execution state information, and / or the plurality of lock scripts of at least one previous blockchain transaction includes a common bytecode sequence and optionally an interpreter code, and the lock script of the payment blockchain transaction is required to include the common bytecode sequence and optionally the same interpreter code for the verification of the payment blockchain transaction to succeed, and / or verifying includes comparing the bytecode sequence and optionally the interpreter code of the lock script of the payment blockchain transaction with the bytecode sequence and optionally the interpreter code of each of the plurality of lock scripts of the previous blockchain transactions, whereby the verification of the payment blockchain is determined based on the result of such comparison, and / or the lock script of the payment blockchain transaction can be the same bytecode sequence and optionally the same interpreter code as one or more previous blockchain transactions or can be different bytecode sequences and optionally interpreter codes corresponding to a set of valid lock scripts, and / or verifying includes generating a hash data value corresponding to the lock script of the previous blockchain transaction and adding the hash data value to a set of hash data values corresponding to a set of valid lock scripts, wherein generating the hash data value is generated for each lock script of the payment blockchain transaction, and comparing with the set of hash data values, and whereby the verification of the payment blockchain transaction isIt is determined based on the result of the comparison of such hash data values.,

[0215] A payment blockchain transaction can be generated by a node of the blockchain network, and / or the payment blockchain transaction refers to a plurality of lock scripts of one or more previous blockchain transactions, where each of the plurality of lock scripts represents an instance of an execution thread, and / or the payment blockchain transaction includes a plurality of lock scripts, and the execution of the lock scripts includes inter-thread communication or control between the execution thread instances pointed to by the payment blockchain transaction, and / or the payment blockchain transaction is sent by a node to other nodes of the blockchain network for verification and storage in the blockchain.

[0216] The plurality of lock scripts of the payment blockchain transaction can be generated by replicating the bytecode sequence of the plurality of lock scripts of one or more previous blockchain transactions. Alternatively, the plurality of lock scripts of the payment blockchain transaction can be generated by replicating the bytecode sequence and interpreter code of the plurality of lock scripts of one or more previous blockchain transactions. And / or the generation of the payment blockchain transaction includes generating execution state information (e.g., the next execution pointer) of the execution thread instance of the lock script of the payment blockchain transaction, and including the execution state information (e.g., the next execution pointer) in the plurality of lock scripts of the payment blockchain transaction.

[0217] Additionally or alternatively, the present invention includes a computer-implemented method, the method comprising that a payment blockchain transaction is received by a node of a blockchain network, and / or that a payment blockchain transaction refers to a plurality of lock scripts of one or more previous blockchain transactions, wherein each of the plurality of lock scripts represents an instance of an execution thread, and / or that a payment blockchain transaction includes a corresponding plurality of lock scripts, the execution of which includes inter-thread communication or control between the execution thread instances referred to by the payment blockchain transaction, and that a node verifies a payment blockchain transaction by verifying a plurality of lock scripts of the payment blockchain transaction against one or more conditions.

[0218] Verifying includes comparing multiple lock scripts of a payment blockchain transaction with multiple lock scripts of one or more previous blockchain transactions. And / or, checking execution state information (e.g., next execution pointer) of multiple lock scripts of one or more previous blockchain transactions to provide inter-thread communication or control between execution thread instances pointed to by the payment blockchain transaction. And / or, multiple lock scripts of at least one previous blockchain transaction include bytecode sequences and possibly interpreter code, and multiple lock scripts of the payment blockchain transaction are required to include bytecode sequences and interpreter code of multiple lock scripts of one or more previous blockchain transactions for the verification of the payment blockchain transaction to succeed. And / or, verifying includes comparing the bytecode sequence and possibly interpreter code of each lock script of the payment blockchain transaction with the corresponding bytecode sequence and possibly interpreter code of the lock script of one or more previous blockchain transactions, whereby the verification of the payment blockchain is determined based on the result of such comparison.

[0219] Referring now to FIG. 12, FIG. 12 shows a simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 12, the computing device 2600 may include one or more processors 2602 configured and operatively coupled to communicate with a number of peripheral subsystems via a bus subsystem 2604. The processor 2602 may be utilized for processing unlock scripts and lock scripts as part of verifying payment transactions described herein. These peripheral subsystems may include a storage subsystem 2606 that includes a memory subsystem 2608 and a file / disk storage subsystem 2610, one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616. Such a storage subsystem 2606 may be used for temporary or long-term storage of information such as details related to transactions described in the present disclosure.

[0220] The bus subsystem 2604 may provide a mechanism that enables the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 2616 may provide an interface to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and transmitting data to other systems of the computing device 2600. For example, the network interface subsystem 2616 enables a data technician to connect the device to a wireless network. As a result, the data technician can send and receive data from a remote location such as a user's data center. The bus subsystem 2604 may be utilized to communicate data such as details, search terms, etc. to the managed models of the present disclosure, and to communicate the output of the managed models to one or more processors 2602 and to merchants and / or lenders via the network interface subsystem 2616.

[0221] The user interface input device 2612 may include one or more user input devices such as a keyboard, an integrated mouse, a trackball, a touchpad, or a pointing device such as a graphics tablet, a scanner, a barcode scanner, a touch screen incorporated in a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. Generally, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600. One or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device, etc. The display subsystem may include a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection, or other display devices. Generally, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface and to enable user interaction with an application that executes the processes and variations described herein when such interaction is appropriate.

[0222] The memory subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions) may be stored in the memory subsystem 2606 and, when executed by one or more processors, provide the functionality of one or more embodiments of the present disclosure. These application modules or instructions may be executed by one or more processors 2602. The memory subsystem 2606 further provides a repository for storing data used in accordance with the present disclosure. The memory subsystem 2606 may include a memory subsystem 2608 and a file / disk storage subsystem 2610.

[0223] Memory subsystem 2608 may include a number of memories including a main random access memory (RAM) 2618 for storing instructions and data during program execution and a read-only memory (ROM) 2620 in which fixed instructions may be stored. File / disk storage subsystem 2610 may provide non-volatile persistent storage for program and data files and may include a hard disk drive, a floppy disk drive in conjunction with associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, a removable media cartridge, and other similar storage media.

[0224] Computing device 2600 may include at least one local clock 2624. Local clock 2624 may be a counter representing the number of hours elapsed since a particular start date and may be disposed inside computing device 2600. Local clock 2624 is used to synchronize data transfers within the processor for computing device 2600 and all subsystems included therein at a particular clock rate and may be used to coordinate the timing operations between computing device 2600 and other systems within a data center. In one embodiment, local clock 2624 is an atomic clock. In another embodiment, the local clock is a programmable internal timer.

[0225] Computing device 2600 may be of various types including a portable computing device, a tablet computer, a workstation, or any other device described hereinafter. Further, computing device 2600 may include another device connectable to computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). The device connectable to computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Accordingly, this device may be configured to convert an optical signal into an electrical signal transmitted to computing device 2600 through the port connecting the devices for processing. Due to the constantly changing characteristics of computers and networks, the description of computing device 2600 shown in FIG. 12 is intended only as a specific example for the purpose of explaining a preferred embodiment of the device. Many other configurations with more or fewer components than the system shown in FIG. 12 are possible.

[0226] The specification and drawings should therefore be considered in an illustrative rather than a limiting sense. However, it is clear that various changes and modifications to these may be made without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of the present disclosure. Accordingly, the disclosed technology is subject to various changes and alternative configurations, although the particular illustrated embodiments have been shown and described in detail above. However, there is no intention to limit the invention to one or more specific forms of the disclosure, and on the contrary, it is intended to cover all changes, alternative configurations, and equivalents included within the scope of the invention as defined in the appended claims.

[0227] In the context of describing the disclosed embodiments, the terms "a", "an", "the", and similar references (especially in the context of the following claims) are intended to cover both the singular and the plural, unless the context specifically indicates otherwise or is clearly negated. The terms "having", "comprising", "including", "containing", etc. should be considered as open-ended terms (i.e., meaning "including but not limited to") unless otherwise specified. When the term "connected" is unmodified and refers to a physical connection, it should be considered to mean that, even in the absence of an intermediary, components are either partially or wholly included, added, or joined together. The recitation of a range of values in this disclosure is, unless otherwise specified, merely a shorthand notation for referring individually to each of the separate values within that range, and each separate value is considered to be incorporated herein as if it were individually recited. The use of the terms "set or collection" (e.g., "a set of items") or "subset or subcollection" should be considered to refer to a non-empty collection containing one or more components, unless otherwise specified or the context negates this. Further, unless otherwise specified or the context negates this, the term "subset" of a corresponding set does not necessarily denote a proper subset of the corresponding set, and the subset and the corresponding set may be equal.

[0228] Conjunctive language, such as "at least one of A, B, and C" or "at least one of A, B or C", is generally understood in context to be used to indicate that items, terms, etc. can be any one of A or B or C, or any non-empty subset of the set of A and B and C, unless otherwise stated or clearly negated in the context. For example, in an example for the description of a set having three members, the conjunctive phrase "at least one of A, B, and C" or "at least one of A, B or C" represents any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {B,C}, {A,B,C}. Thus, such conjunctive language is not generally intended to mean that a particular embodiment requires the presence of at least one A, at least one B, and at least one C, respectively.

[0229] The operations of the described process can be performed in any suitable order, unless otherwise stated or clearly negated in the context. The described process (or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) that executes in cooperation on one or more processors by hardware or a combination thereof. The code may be stored in a computer-readable storage medium, for example, in the form of a computer program having a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

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

[0231] Embodiments of the disclosure are described that include the best mode known to the inventor for practicing the invention. These various embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventor expects those skilled in the art to appropriately utilize such variations, and the inventor intends for the embodiments of the disclosure to be practiced in a manner different from that specifically described. Accordingly, the scope of the disclosure includes all modifications and equivalents of the subject matter recited in the appended claims, as permitted by the applicable law. Further, any combination of the above-described elements in all possible variations thereof is included within the scope of the disclosure, unless otherwise specifically stated or clearly precluded by context.

[0232] All cited documents, including publications, patent applications, and patents, are hereby incorporated by reference as if each document were individually and specifically indicated and as if the entire document were set forth herein.

[0233] The above embodiments do not limit the present invention, but rather are for illustrative purposes, and it should be noted that those skilled in the art can devise many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference signs in parentheses are not intended to limit the claim. Terms such as "having" and "comprising" (comprising, comprises) do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "having" means "having or consisting of", and "comprising" means "comprising or consisting of". A reference to a single element does not exclude a reference to plural elements of that element. Vice versa. Unless otherwise specified or clear from the context, the term "and / or" in a list of items indicates the presence of at least one item in the list, without excluding or requiring the presence of any item in the list. Embodiments of the present disclosure can be implemented by hardware including several distinct elements and by a computer appropriately programmed. In apparatus claims listing several means, some of these means may be embodied by one and the same item of hardware. The mere fact that certain means are described in mutually different dependent claims does not indicate that a combination of these means cannot be used advantageously.

Explanation of Signs

[0234] 100 Blockchain Network 102 Node 104 Transaction

Claims

1. A method implemented by a computer, comprising: generating a payment blockchain transaction, wherein the payment blockchain transaction includes a lock script representing an instance of an execution thread combined from a plurality of execution thread instances represented by at least one previous blockchain transaction; communicating the payment blockchain transaction onto a blockchain network for storage in a blockchain; A method implemented by a computer, comprising the above steps.

2. The method implemented by a computer according to claim 1, further comprising storing the previous blockchain transaction in a blockchain maintained by a blockchain network.

3. The method implemented by a computer according to claim 1 or 2, wherein the payment blockchain transaction is generated by a node of the blockchain network.

4. The method implemented by a computer according to any one of claims 1 to 3, wherein the payment blockchain transaction refers to a plurality of lock scripts of one or more previous blockchain transactions, and each of the plurality of lock scripts represents an instance of an execution thread.

5. The method implemented by a computer according to claim 4, wherein the payment blockchain transaction includes a lock script representing an execution thread combined from the execution thread instances pointed to by the payment blockchain transaction.

6. The method implemented by a computer according to claim 4 or 5, wherein the lock script representing the execution thread combined from the execution thread instances pointed to by the payment blockchain transaction can be generated by replicating a bytecode sequence of the plurality of lock scripts of the one or more previous blockchain transactions.

7. The lock script representing the execution thread combined from the execution thread instance pointed to by the payment blockchain transaction can be generated by replicating the bytecode sequence and interpreter code of the plurality of lock scripts of the one or more previous blockchain transactions. The computer-implemented method according to claim 4 or 5.

8. Accessing a set of valid bytecode sequences; Generating the lock script representing the execution thread combined from the execution thread instance pointed to by the payment blockchain transaction by replicating the valid bytecode sequences of the set; The computer-implemented method according to any one of claims 1 to 7, further comprising:

9. Accessing a set of valid bytecode sequences and valid interpreter code; Generating the lock script representing the execution thread combined from the execution thread instance pointed to by the payment blockchain transaction by replicating the valid bytecode sequences and valid interpreter code of the set; The computer-implemented method according to any one of claims 1 to 6, further comprising:

10. The payment blockchain transaction generates execution state information of the execution thread combined from the execution thread instance pointed to by the payment blockchain transaction, and includes the execution state information in the lock script of the payment blockchain transaction. The computer-implemented method according to any one of claims 4 to 9, generated thereby.

11. The payment blockchain transaction is received by a node of the blockchain network. The computer-implemented method according to any one of claims 1 to 10.

12. The node verifies the payment blockchain transaction by verifying the lock script of the payment blockchain transaction against one or more conditions. The computer-implemented method according to claim 11.

13. Verifying the lock script of the payment blockchain transaction comprises comparing the lock script of the payment blockchain transaction with the plurality of lock scripts of the one or more previous blockchain transactions, and executing the plurality of lock scripts of the one or more previous blockchain transactions to generate resulting execution state information and then merging or combining the resulting execution state information, The computer-implemented method according to claim 12, dependent on claim 4, comprising.

14. A system comprising a processor and a memory including executable instructions that, as a result of execution by the processor, cause the system to execute the computer-implemented method according to any one of claims 1 to 13, A system comprising.

15. A non-transitory computer-readable storage medium storing executable instructions, the executable instructions causing a computer system to execute the computer-implemented method according to any one of claims 1 to 13 as a result of execution by a processor of the computer system.

Images