Concurrent state machine transactions using blockchain

Abstract

To implement a state machine in a blockchain transaction infrastructure including an untrusted deterministic concurrent state machine.SOLUTION: An unlock transaction constraint is determined that constrains the unlock transaction to include a transaction input that references an output of a previous transaction. A redeemable transaction is generated to include a transaction output including an amount and a transaction locking script. The transaction locking script includes the unlocking transaction constraint, and unlocking the amount is dependent on execution of at least one unlocking script of the unlocking transaction satisfying the unlocking transaction constraint. The redeemable transaction is validated at a node of a blockchain network.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to computer-implemented methods for processing blockchain transactions, and more particularly to implementing state machines within the framework of blockchain transaction processing, including trustless, deterministic, and concurrent state machines. The present invention further utilizes cryptographic and mathematical techniques to implement security for electronic transfers made on a blockchain network. The present invention is particularly suited, but not limited to, for use in methods and apparatus for processing and conducting smart contract transactions and executing state machines using such smart contract transactions. [Background technology]

[0002] As used herein, the term "blockchain" may refer to any of several types of electronic, computer-based distributed ledgers, including consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. While the most widely known application of blockchain technology is the Bitcoin ledger, other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, reference may be made to the "Bitcoin" example as a useful application described herein, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including those for non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure offers the advantage of utilizing a blockchain implementation that has similar restrictions as Bitcoin regarding the constraints that can be encoded within transactions, regardless of whether a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, computer-based distributed system composed of blocks, which in turn consist of transactions and other information. In some examples, a "blockchain transaction" refers to an input message that encodes a structured set of field values ​​that includes data and a set of conditions, where satisfaction of the set of conditions is a prerequisite for the set of fields to be written to the blockchain data structure. A blockchain system or network may include multiple blockchain nodes and a set of operations. A blockchain node can be configured to perform some or all of the set of operations. Various blockchain nodes may be implemented as computer hardware, computer software, or a combination of both operated by node operators, who may be independent and unrelated to other node operators. Each blockchain node can maintain a copy of the blockchain ledger, or a portion thereof. The set of operations includes creating transactions, propagating transactions, reading the blockchain ledger, evaluating the blockchain ledger, generating new blocks for proposed additions to the blockchain ledger (mining), communicating with other blockchain nodes, and providing wallet functionality for users to manage their blockchain assets.

[0004] A blockchain ledger may be decentralized because there is no single blockchain node or entity that determines when the ledger is modified. Instead, blockchain nodes are each programmed with knowledge of the rules of the blockchain protocol and can validate the blockchain ledger and verify that the behavior of other blockchain nodes is consistent with those rules. The term "blockchain" may refer to the fact that a blockchain ledger includes a series of chained blocks, each of which can be represented as a data structure in computer memory, readable by a computer process, and transmittable as a data transmission. A block includes one or more transactions and can be represented as a data structure in computer memory, readable by a computer process, and transmittable as a data transmission. Blocks may be chained such that each new block officially added to the blockchain includes an immutable reference to the block immediately preceding it, which may include an immutable reference to the block immediately preceding it, and so on.

[0005] One of the rules of a blockchain protocol is that once a block is added to the blockchain, it cannot be changed, i.e., it is immutable, and the only changeable thing in a blockchain ledger is the addition of new blocks. Blockchain nodes can be programmed with this rule so that they cannot modify blocks in their copy of the blockchain ledger, but only add blocks, and further, can only add blocks after running a validation process on proposed blocks to ensure compliance with the blockchain protocol. Because such blocks are immutable once added to the ledger, the transactions within the blocks can also be immutable.

[0006] When a blockchain node creates a transaction, it may create a data object containing the details of the transaction and propagate the data object to other blockchain nodes to which it can connect, typically in a peer-to-peer manner. Some blockchain nodes act as "miners" and collect one or more transactions, form a data structure corresponding to a block, perform some calculations to verify the transactions in the block, solve a puzzle, put the solution to the puzzle into the data structure, and attempt to communicate the block to other blockchain nodes. This puzzle may be in the form of a non-trivial calculation specific to the transaction's data and the current state of the blockchain ledger, such as the number of blocks in the ledger and data from the most recently added block.

[0007] By making the puzzle transaction-dependent, a dishonest blockchain node may be unable to propagate a pre-created block. By solving a nontrivial puzzle, a dishonest blockchain node may not be able to simply inject a block into the blockchain network, but may be required to perform a significant computational task to prove that the blockchain node contributed effort (effectively, demonstrating a solution to a hard problem is a "proof-of-work"). Preferably, a blockchain protocol ensures that proof-of-work is not easy, but that verifying that the puzzle has been solved and work has been done is easy. This means that other blockchain nodes do not necessarily need to trust the blockchain node proposing to add a new block to the ledger. If the proposed block is verified by other blockchain nodes, the blockchain node can 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 will also perform similar verification, they may also conclude that the block is valid and should be added to the blockchain ledger, and thus add the new block to their own copy of the blockchain ledger. If a blockchain node determines that a proposed new block is not valid, it may not add the new block to its copy of the blockchain ledger and may not propagate it. Because blockchain validity is based on consensus, a transaction may be considered valid if a majority of nodes agree that the transaction is valid.

[0008] A blockchain system may operate such that node owners and operators do not necessarily trust other node owners and operators. Instead, the protocol may make it computationally infeasible to perform certain operations not permitted by the protocol, such as modifying a previous block, proposing a new block without a corresponding proof-of-work, or including an invalid transaction. Certain trust may not be required if it is computationally infeasible to perform operations not permitted by the blockchain protocol in a way that would go unnoticed by other nodes.

[0009] To include a transaction in a block written to the blockchain, (1) a mining blockchain node validates 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 transactions within it. Because mining blockchain nodes are programmed or configured with these rules in mind, mining blockchain nodes are unlikely to include transactions that fail validation in a block; such blocks are not accepted by other nodes, and the mining node does not earn any profits. One such advantage of mining over some blockchain systems is that, if a block is accepted, it is allowed to include a "distribution" transaction, which allocates a specific amount of value to the node's operator without requiring a corresponding reduction in value from some other entity. In this way, successful miners can be rewarded with the value generated with the block. Furthermore, as explained below, transactions include a transaction fee. The transaction fee also reaches the miner controlling the mining blockchain node, and the miner must verify that the transaction is valid in order to receive compensation.

[0010] Transactions in a blockchain network include various data elements, such as a transaction value, a transaction time, and / or other data elements. In a decentralized distributed ledger system, the ledger is public, so anyone can view the ledger and see the transactions. In a blockchain ledger, there may be a genesis transaction that starts the blockchain and assigns some unit of value to that genesis transaction. In the examples herein, for purposes of illustration, the unit of value is a cryptocurrency, although other variations are possible.

[0011] Transactions other than genesis and distribution transactions involve the "unlocking" of one or more existing transactions on the blockchain ledger and can transfer such transactions when they are added to the blockchain ledger. Each untransferred transaction publicly specifies the requirements necessary to unlock its value. A simple requirement is, "You must first prove you are Alice, then you can unlock it." Alice can then generate a new transaction that "unlocks" the value of that transaction. Here, Alice's new transaction proves that it came from Alice and has a pointer to its previous transaction. As for distribution transactions, while they have transaction value, distribution transactions do not "unlock" previous transactions. Of course, for Alice's transaction to be accepted by the blockchain network, it cannot reference transactions that have already been transferred; she must actually prove that she created it.

[0012] By the blockchain protocol, and therefore by consensus of the blockchain nodes, a transaction is not valid if it points to the output of a previous transaction that has already been transferred, i.e., if the ledger contains a valid existing transaction input that points to the output of a previous transaction. To prevent an interloper from generating a new transaction input that "unlocks" the value represented by a previous UTXO, each transaction output contains data that represents the requirements placed on the claimant generating such a transaction. Because UTXOs are immutable, that data cannot be changed. Of course, transferred transactions can also be immutable.

[0013] In the example above, Alice might create an unlock transaction, allowing her to transfer to Bob the value in the previous transaction that only she had the ability to unlock. This means that there is now a new, untransferred transaction to unlock that only Bob has the ability to unlock. The unlock transaction created by Alice may contain data that meets the requirement that "anyone can freely point to this transaction and unlock all of its value if they can provide enough information to prove they know Bob's private key." Assuming Bob is careful, he is the only person who can create a valid transaction that unlocks the transaction. In fact, Bob owns the value, and only Bob can unlock it. Note that this does not require Bob to trust the operators of the blockchain nodes or any other parties with the ability to create transactions. What Bob does need to trust is that a dishonest party cannot fully control a majority of the blockchain nodes.

[0014] In certain cases, a transaction may completely unlock exactly one previous untransferred transaction, and a transaction may be completely or completely transferred by a later transaction. In the general case, a transaction has one or more inputs and one or more outputs, where each input references an output of a previous transaction (and that output has redeemable value), and each output has redeemable value (remaining untransferred until transferred / referenced by an input of a future transaction). A transaction's outputs are the redeemable units of that transaction, and all or none of them may be transferred. Note that in the examples described herein, a transaction may be referred to as "being transferred," which may include transferring fewer than all of the transaction's outputs if the transaction has multiple transaction outputs, and "unlocking a transaction," as opposed to unlocking transaction outputs, may include transferring the output of a transaction with only one output.

[0015] If a transaction can have multiple outputs, different transaction outputs of that transaction can be transferred at different times. When a transaction is created, its outputs may be considered untransferred. Each output may be transferred by an input of a later transaction or remain untransferred. If a transaction has an input that attempts to unlock an output of a previous transaction after that output has already been transferred, blockchain nodes will reject it as an invalid transaction.

[0016] If one party, Alice, controls a UTXO with value X, and wants to unlock only a portion of that transaction output, Y, she can specify a new transaction with multiple outputs: one transaction output with value Y that can only be transferred by Bob, and one transaction output with value XY that can only be transferred by Alice. Effectively, the original transaction output is transferred in its entirety, but there is a new transaction output that "modifies" Alice's transaction.

[0017] The number of inputs to a transaction and the number of outputs in that transaction do not need to be the same. However, to be a valid transaction, the total value specified in the outputs of the current transaction must not exceed the total value of the outputs of previous transactions that can be transferred by the inputs of the current transaction, and may be less, with some exceptions. For genesis and distribution transactions, the total value of the outputs can be greater than the total value of the inputs. Alternatively, for regular transactions that do not require any inputs, the transaction is invalid if the total value of its outputs exceeds the total value of its inputs. In some transactions, the total value of the outputs can be less than the total value of the inputs. In this case, a successful miner adds a transaction fee for the difference, which then liquidates the transaction and creates a reason to process it. In the Bitcoin protocol, this is a coinbase transaction, which is added to a block and has a redeemable output equal to the sum of the transaction fees of all other transactions included in the Bitcoin block (i.e., the sum of the differences between all inputs and outputs of all included transactions) plus a distribution for creating a new block.

[0018] Each output in a transaction contains constraints that must be met to unlock the value of that output. In some blockchain protocols, the constraints are embedded in a "lock script" that specifies the data and script commands that define what these constraints are. The lock script acts as collateral for the value represented in the transaction output. In this case, other actors cannot "unlock" the value represented in the transaction output unless they can also "unlock" the transaction output's lock script.

[0019] Each input to an unlock transaction unlocks the output of the previous transaction. The "unlock script" of an unlock transaction input determines whether the unlock transaction unlocks the output of the previous transaction. Thus, a valid transaction specifies at least one input, and each input of a valid unlock transaction includes a pointer to the output of the previous transaction (the output to be transferred) and an unlock script that "unlocks" the lock script. A blockchain node operating according to a corresponding blockchain protocol may execute the lock script and the unlock script together to validate a transaction input. In certain systems, the scripts are stack-based, and a validating blockchain node starts with an empty stack, executes the unlock script, which may leave data objects on the stack, and then executes the lock script, which may use the data objects on the stack.

[0020] When a validating blockchain node combines a lock script and an unlock script and executes that combination, the result after execution will be either "TRUE" or "FALSE." In some cases, a script execution may terminate with a FALSE result before the script is fully executed. For example, suppose a particular script execution has two values ​​that are always equal in a valid script execution, regardless of what happens in the script. Partway through that script execution, a comparison is made between these two values, and if they are not equal, the script execution can stop immediately after that comparison and return a FALSE result. The rest of the script does not need to be executed.

[0021] A validating blockchain node combines the lock script and unlock script, executes the combination, and if the result is TRUE (i.e., the unlock script contains everything necessary to unlock the transaction outputs), the validating blockchain node verifies that the transaction is valid (assuming other requirements are met, such as proper timestamp, proper format, not pointing to a transaction output that has already been transferred, etc.). If the validating blockchain node verifies that the transaction is valid, it may propagate the transaction. Other blockchain nodes may perform the same calculation to conclude that the transaction is valid. In this way, a valid transaction with inputs that point only to UTXOs and an unlock script that unlocks those UTXOs may propagate and eventually become part of a block that eventually becomes part of the ledger.

[0022] On the other hand, if a dishonest node attempts to propagate a dishonest transaction, other nodes will determine that it is dishonest and will not propagate it.

[0023] Once a transaction is valid and accepted into the blockchain, its contents cannot be changed. That is, the lock script is finalized when the transaction is created. However, the unlock script is not necessarily finalized at that time, since it is contained within a later unlock transaction and does not need to be created until the later unlock transaction is created.

[0024] Typically, the validating unlock script is not created by anyone but only by a party authorized to unlock the output of a previous transaction. As in the example above, the lock script might be, "Anyone can freely point to this transaction output and thereby unlock all the specified values ​​if they can provide enough information to prove they know Bob's private key." The unlock script might be in the form, "Bob signs the transaction with his private key, where the result is ABCCC." A validating blockchain node can then process these two statements and reach a TRUE or FALSE conclusion. This process works well if it is easy to verify that ABCCC is a valid signature, easy for Bob (or someone else who knows Bob's private key) to generate such a signature, and very difficult for anyone else to generate a valid signature without knowing Bob's private key. The result is a trustless system for transferring value. The originator of the transaction Bob is trying to unlock does not need to trust the system or trust Bob, as it is cryptographically difficult to form a valid, verifiable result that would be accepted by consensus of the blockchain nodes without first knowing Bob's private key.

[0025] Blockchain nodes can easily verify that Bob signed the transaction and that the signature is the only requirement of the lock script. Of course, there can be rogue nodes that don't verify where other nodes do and may verify where other nodes don't, but unless they can overwhelm the good nodes on the blockchain network, they can't push invalid transactions or stop valid transactions from propagating or being mined.

[0026] If a node executes a transaction input's unlock script and the corresponding lock script of the previous transaction input, and each of them evaluates to TRUE, and other validation conditions (if applicable) are met, then the transaction is valid as far as that node is concerned. That node then propagates the validated transaction to other network nodes, which in turn allows miner nodes to choose to include the transaction in a block. Thus, in order for a transaction to be written to the blockchain, it must (1) be validated by the node receiving it, (2) be relayed to other nodes in the network (only if the transaction is validated), (3) be added to a new block constructed by a miner, (4) be propagated as part of a proposed block, and (5) be accepted by node consensus as an addition to the public ledger of past transactions.

[0027] A transaction may be considered confirmed when enough blocks have been added to the blockchain to make it effectively irreversible. Because transactions are immutable, blockchain protocols can block unilateral reversals of transactions. Of course, if Alice transfers value X to Bob and Alice requests that value X be returned, Alice can get value X if Bob agrees. In this case, the Alice-to-Bob-for-X transaction cannot be reversed or canceled, 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, it is considered immutable, and once a block is committed to the blockchain, it is considered immutable. There may be a short period during which a fork exists in the blockchain and there is some ability to roll back the blockchain, but generally, the longer the period, the less likely a rollback is. Here, unless otherwise specified, we assume that transactions and blocks are immutable once they are fully committed to the blockchain.

[0029] One way to ensure immutability is through the use of cryptographic techniques. For example, there are cryptographic operations, such as hashes and digital signatures, that take as their input some data sequence and provide an output data sequence that corresponds in some way to the input data sequence. The operations may be such that for a given cryptographic output (e.g., a hash or digital signature) generated from a given cryptographic input (e.g., a transaction or block), it is computationally infeasible or impossible, using the available computational resources, to find a different cryptographic input that yields the same cryptographic output. Thus, if the cryptographic input matches the cryptographic output, a verifier can assume that it was the cryptographic input, and not some other modified cryptographic input, that was used to generate the cryptographic output.

[0030] In a blockchain network, where nodes do not need to trust each other, transactions may be verified as such and blocks may be verified as such, and unverifiable transactions and blocks may be ignored and unused, and transactions and blocks may be considered to be effectively immutable, which may be a result of the assumption that if a hash or digital signature correctly corresponds to a transaction or block, then the transaction or block has not been altered from its origin.

[0031] Some blockchain nodes store the entire ledger, while others store only unspent transaction outputs (e.g., UTXOs in the Bitcoin ledger). UTXOs correspond to redeemable value, and each UTXO preferably has a locking script that prevents anyone other than the "owner" of that value from easily generating a verifiable unlocking script. While this is not a requirement, it is expected that UTXOs for which a verifiable unlocking script can be easily generated will be quickly transferred in transactions that transfer their value to another UTXO that can only be redeemed by the first person to notice it. As a result, blockchains can be used to transfer control of cryptocurrency value. More generally, digital assets and transaction records, including transferred transaction outputs and UTXOs, from one participant in a blockchain system to another can be recorded in a public, immutable ledger, making it easy to verify the flow of digital assets and prevent double unlocking of those digital assets.

[0032] In embodiments, a "digital asset" refers to binary data associated with usage rights. Examples of digital assets include Bitcoin, ether, and Litecoin. As used herein, a "digital asset" may refer to one or more digital assets. For example, a transaction may have multiple inputs, each of which may represent a different digital asset. The digital asset for which control is transferred, in this example, may be a collection of multiple digital assets, with the collection itself being a digital asset. Similarly, a transaction may subdivide and / or combine these multiple inputs to generate one or more outputs, e.g., with a different number of inputs and a different number of outputs.

[0033] In one embodiment, the cryptocurrency is a token-based cryptocurrency, where each token represents a share of an asset (e.g., a stock in a company), and a single transaction involves multiple types of tokens (e.g., stock in one or more different companies). In some embodiments, the digital assets are non-tokenized, such as with Bitcoin. As a result, for example, there is no identifier for the digital asset identified within the blockchain; rather, control of the digital asset is demonstrated through the ability to generate valid transactions that become recorded on the blockchain. However, it should be noted that some blockchain implementations may use tokenized digital assets, for example, such that the digital asset is specifically identifiable using information recorded on the blockchain. While digital assets may be used as cryptocurrency in some embodiments, it is contemplated that in embodiments, digital assets may additionally or alternatively be used in other contexts. It should be noted that the present invention, while applicable to control of digital assets, is technical in nature and may be used in other contexts that utilize blockchain data structures without necessarily involving the transfer of digital assets.

[0034] A transaction contains locking and unlocking scripts, which can form a computational object. Once committed to the blockchain, a transaction may become immutable, and its functionality may be used beyond simply the immutable transfer of control over digital assets in the form of cryptocurrency. In addition to transferring value, immutable transactions can be used to perform other operations, such as the notarization of events, the implementation of smart contracts in which the rights and obligations of parties are encoded in the transaction, and the transfer of value according to the terms of the smart contract in accordance with the blockchain protocol.

[0035] In the Bitcoin platform, scripts are written using stack-based scripting languages, although other approaches may be used instead. In some examples, a "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models and operations. When executing instructions in a stack-based scripting language, a processor (such as part of a blockchain node) stores data in a first-in, first-out data structure called a stack. The processor can push values ​​onto the top of the stack or pop values ​​from the top of the stack. Various operations performed on the stack can result in pushing or popping one or more values ​​from the top of the stack, performing operations on the values, or changing the order of elements on the stack (which may be equivalent to two pop operations and two pushes, with the first push popping the first item). For example, the OP_EQUAL operation may pop the top two items from the stack, compare them, and push the result (1 if equal, 0 if not equal) onto the top of the stack. Other operations performed on stacks, such as OP_PICK, may allow an item to be selected from a position other than the top of the stack. In some scripting languages ​​used by some embodiments of the present invention, there may be at least two stacks: a main stack and an alternate stack. Some operations in the scripting language can move an item from the top of one stack to the top of another. For example, executing an OP_TOALTSTACK operation causes the processor to move a value from the top of the main stack to the top of the alternate stack. Note that stack-based scripting languages, in some cases, are not limited to operating strictly in a last-in, first-out (LIFO) manner. For example, a stack-based scripting language may support an operation to copy or move the nth item in a stack to the top (e.g., OP_PICK and OP_ROLL in Bitcoin, respectively).Scripts written in stack-based scripting languages ​​can be pushed onto a logical stack, which can be implemented using any suitable data structure, such as a vector, a list, or a stack.

[0036] Scripts included in transactions can be used to implement smart contracts, where the terms of the agreement are encoded into the script. For example, a statement of the form "If Bob pays Carol X and Dave authorizes the transaction, then Alice pays Bob half of X" can be encoded as part of a locking script that evaluates to TRUE only if there is (among other things) a prior transaction in which Bob paid Carol and a prior transaction in which Dave encoded his authorization. As used here, "prior transaction" refers to a transaction that has already been added to the blockchain, not necessarily a prior transaction whose output the unlocking transaction unlocks. In effect, a smart contract can represent a machine-executable program containing rules that define inputs to produce results, which can result in the execution of actions that depend on those results.

[0037] In addition to transferring value, transactions may also transfer other objects of value or possession rights. For example, a transaction may transfer a nominal cryptocurrency value but contain data equivalent to the assertion, "Whoever can unlock this transaction is also the rightful owner of the house and land at 123 Marley Circle." Possession rights may be opaque in public records to the same effect. For example, a transaction may contain data equivalent to the assertion, "Whoever can unlock this transaction is also the rightful owner of a specific property held at Central Bank of Trust under consignment number 12345." This is referred to herein as a token, which represents and effects the transfer of a real-world entity via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Tokens can therefore function as identifiers that allow real-world items to be referenced from the blockchain.

[0038] In some embodiments, interactions with specific entities are encoded in specific steps within a smart contract, and the smart contract may otherwise be self-executing and self-enforcing. In some examples, self-execution refers to the execution of a smart contract that is performed to allow the transfer of a UTXO. In such examples, "any entity" that can unlock a UTXO refers to an entity that can generate an unlock script without being required to prove knowledge of any secret. In other words, an unlock script may be generated without verifying that the source of the data has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Also, in such examples, self-enforcement occurs as a result of validating nodes in the blockchain network validating the unlock transaction according to the constraints of the smart contract. In some examples, "unlocking" a UTXO refers to generating an unlock transaction output that references the UTXO and executes as valid. A side effect of unlocking such a transaction output is that the blockchain network can process the lock and unlock scripts to validate the new transaction, i.e., the unlock transaction. If valid, the output of the previous transaction is considered transferred. There is a reason for a party to create such an unlocking transaction by including a specific value in the transaction output, allowing anyone to unlock that output, and thus the steps of the smart contract are executed by others operating blockchain nodes, rather than by the participants of the smart contract.

[0039] The scripts that form the lock and unlock scripts recorded as part of a transaction may be immutable, so the lock script typically cannot be changed and the portions of future transactions that it references may not be known at the time the transaction is committed. The unlock script of a transaction input may reference portions of the output of the previous transaction that the transaction input points to, or a previous transaction in the blockchain other than the previous transaction. This may limit how the transaction can be used.

[0040] In one or more of these aspects, it would be desirable to provide additional and improved methods and systems for using blockchain technology. Accordingly, in accordance with the present invention, there is provided a system and / or method as defined in the accompanying claims. Summary of the Invention

[0041] In various embodiments of the computer-implemented method, the method comprises: determining a first set of constraints on a first use transaction output; determining a second set of constraints on a second spending transaction output; generating an initial transaction, the initial transaction comprising: at least one initial locking script including the first set of constraints and the second set of constraints; at least one usable value; and using the at least one usable value includes: the first set of constraints is satisfied, at least in part, by verifying that the spend transaction includes the first spend transaction output; and the second set of constraints is satisfied, at least in part, by verifying that the use transaction includes the second use transaction output; having the initial transaction validated at a node of a blockchain network; Includes.

[0042] The locking script in the first use transaction output may be a duplicate of the locking script in the second use transaction output.

[0043] The locking script in the first use transaction output may be different from the locking script in the second use transaction output.

[0044] The locking script in the first use transaction output may include at least a portion of at least one initial locking script.

[0045] Execution of the at least one initial locking script may select the at least one portion from a plurality of portions of the at least one initial locking script.

[0046] Execution of the unlock script of the use transaction may result in the at least one initial locking script receiving data corresponding to one of the first use transaction output or the second use transaction output.

[0047] The data may have an index value, and execution of at least one initial locking script may determine whether a first set of constraints is satisfied if the index value is a first index value, and execution of at least one initial locking script may determine whether a second set of constraints is satisfied if the index value is a second index value.

[0048] The data may include a new locking script. As a result of receiving the data, the first use transaction output may be constrained to include the new locking script.

[0049] At least one initial locking script may include a constraint on the source of the data.

[0050] The method may further include determining a usable value of the first use transaction output.

[0051] The initial transaction may encode a contract that has multiple states.

[0052] A usage transaction may include multiple input values ​​corresponding to multiple states.

[0053] A first set of constraints may constrain a first use transaction output to have a first state, and a second set of constraints constrain a second use transaction output to have a second state.

[0054] Further, there is provided a computer-implemented method comprising: determining a use transaction constraint that constrains use transactions to include use transaction inputs that reference outputs of previous transactions; generating an available transaction, the available transaction comprising: a spendable transaction output, including a spendable amount; an available transaction locking script including a usage transaction constraint, wherein usage of the available amount is conditioned on execution of at least one unlocking script of a usage transaction that satisfies the usage transaction constraint; and having the enabled transaction validated at a node of the blockchain network.

[0055] The use transaction constraint may further constrain the use transaction input to contain a particular hash value.

[0056] A particular hash value may encode an identifier that references the output of a previous transaction.

[0057] The use transaction constraint may further constrain the use transaction's lock script to include a set of script elements replicated from the available transaction lock script.

[0058] An enabling transaction may encode a contract that has multiple states.

[0059] The method may further include determining a usable value of the output of the usage transaction.

[0060] The use transaction constraint may include a particular lock script element from the output of a previous transaction. As a result of the use transaction input including the particular lock script element, execution of at least one unlock script may satisfy the use transaction constraint.

[0061] A particular lock script element may encode a cryptographic key for a particular entity.

[0062] The usage transaction constraint may be a first usage transaction constraint, and the method may further comprise: determining a second usage transaction constraint to further constrain the usage transaction; generating a second available transaction, the second available transaction comprising: A second usable amount; and a second available transaction locking script including a second usage transaction constraint, and using the second available amount may further include a step in which execution of at least one unlocking script may satisfy the second usage transaction constraint.

[0063] The available transaction lock script may be a first available transaction lock script, and the at least one unlock script may include a first unlock script and a second unlock script. The first usage transaction constraint may constrain the first unlock script to include at least a portion of the first available transaction lock script. The second usage transaction constraint may constrain the second unlock script to include at least a portion of the second available transaction lock script.

[0064] At least a portion of the first available transaction locking script may include a cryptographic key associated with a first entity, and at least a portion of the second available transaction locking script may include a cryptographic key associated with a second entity different from the first entity.

[0065] A use transaction constraint may further constrain a use transaction to constrain the output of the use transaction.

[0066] A use transaction constraint may encode another contract distinct from the contract: using the available amount may be conditional on other contracts being implemented in the output of the use transaction.

[0067] Further, there is provided a computer-implemented method comprising: generating a blockchain transaction, the blockchain transaction comprising: a state machine in a first state and having a set of allowed state transitions; encoding a set of script elements to be executed to cause the use transaction to decode a state machine according to a set of allowed state transitions, obey restrictions on inputs to the use transaction, or obey restrictions on outputs of the use transaction; and having the blockchain transaction validated by nodes of the blockchain network.

[0068] The set of allowed state transitions may include state transitions that can be implemented independently and in parallel in separate blockchain transactions.

[0069] The set of script elements may subject the use transaction to restrictions on the outputs of the use transaction, which may require that a first output of the use transaction exhibit a state corresponding to the first output according to the set of allowed state transitions, and that a second output of the use transaction exhibit a state corresponding to the second output according to the set of allowed state transitions.

[0070] The state corresponding to the first output and the state corresponding to the second output may be the same.

[0071] The state corresponding to the first output and the state corresponding to the second output may be different states.

[0072] The script element set may subject the use transaction to restrictions on the inputs of the use transaction, which may require that the inputs to the use transaction represent different state machines encoded in different blockchain transactions.

[0073] The restrictions on the inputs may require that the inputs refer to a state machine in a first state and to another state machine in another state different from the first state.

[0074] A first transition from a first state to a second state may be within the set of allowed state transitions. A second transition from another state to the second state may be within the set of allowed state transitions.

[0075] A set of script elements may subject a use transaction to restrictions on the use transaction's inputs. The restrictions on the inputs may describe a set of conditions for advancing a state machine. A set of conditions for advancing a state machine may depend on the state of another state machine.

[0076] Other state machines may be encoded within other blockchain transactions, which may encode sets of conditions for advancing other state machines, which sets of conditions for advancing other state machines may depend on the state of the state machine.

[0077] A script element set may subject a use transaction to restrictions on the use transaction's output, which may require the use transaction to incorporate a smart contract element set into its output.

[0078] The set of elements for a smart contract may be obtained from another blockchain transaction.

[0079] A set of script elements may subject a use transaction to both restrictions on the inputs of the use transaction and restrictions on the outputs of the use transaction.

[0080] Further, there is provided a computer-implemented method comprising: generating, at a node of the blockchain network, a blockchain transaction having a transaction output usable by a first use transaction input of a first use transaction; inserting a first set of script elements into the blockchain transaction, the first set of script elements constraining the first use transaction to include a first use transaction script element set corresponding to an operation of the state machine; and inserting into the blockchain transaction a second set of script elements that may constrain a second set of used transaction script elements corresponding to allowed state machine state transitions that include states implementable using different blockchain transactions that may be processed independently in parallel by the blockchain network, wherein the blockchain transaction may include a first output having a first locking script, the first transaction output value may include a second output having a second locking script and a second transaction output value, and the first set of script elements is part of the first locking script.

[0081] A spend transaction may include an unlock script that, when executed by a transaction validator with the lock script of the output of the previous transaction, and causing the node to at least store in memory accessible to the transaction validator values ​​representing fields of the use transaction when a predetermined validation test is satisfied, executing the locking script of the output of the previous transaction and inserting a first set of script elements into the use transaction, where the first set of script elements forms part of the use transaction locking script of the first output of the use transaction and matches requirements dictated by the previous transaction locking script, the first set of script elements corresponding to state machine operations; and inserting a second set of script elements into the use transaction, where the second set of script elements forms part of the use transaction locking script and matches requirements dictated by the previous transaction locking script and corresponds to allowed state machine state transitions, including states implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network.

[0082] A use transaction can include an input and an output, where the input references the output of a previous transaction. The use transaction includes an unlock script. The unlock script, when executed by a transaction verifier with a previous transaction lock script on the output of the previous transaction, satisfies a predetermined validation test, where the unlock script executes the lock script and inserts data corresponding to additional state machines into the use transaction as use transaction inputs and / or use transaction outputs based on allowed state machine state transitions, thereby causing the node to store at least values ​​representing fields of the use transaction in memory accessible to the transaction verifier when the number of use transaction inputs and / or use transaction outputs used in the use transaction is sufficient for the number of state machine transitions.

[0083] The permissible state machine state transition generates, for the use transaction, a first transaction output corresponding to a first subsequent state; inserts into the use transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output; inserts into the first transaction output of the use transaction a third script element set, where the third script element set is a portion of a first locking script that constrains the first subsequent transaction to assume the first subsequent state; generates, for the use transaction, a second transaction output corresponding to a second subsequent state; inserts into the use transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output; inserting a second transaction output value of the second transaction output sufficient to cause the transaction output to become an input of a second subsequent transaction that references the transaction output; inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second locking script that constrains the second subsequent transaction to assume a second subsequent state; and inserting a fifth set of script elements into the first transaction output or the second transaction output, where the fifth set of script elements is part of the first locking script or the second locking script that imposes a constraint that distinguishes the first subsequent transaction and the second subsequent transaction, thereby including a branching transaction from one initial state to two subsequent states.

[0084] The first locking script can constrain the first subsequent transaction to have a first state. The second locking script can constrain the second subsequent transaction to have a second state. The spending transaction can include three or more transaction output values ​​corresponding to a divergence of three or more states. The spending transaction can include three or more transaction input values ​​corresponding to a fusion of three or more states. The first locking script and the second locking script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0085] Typically, a usage transaction may include N transaction input values ​​and N transaction output values, where N may be 1, 2, 3, or more.

[0086] The allowed state machine state transitions can include merging transactions from two initial states to one subsequent state by inserting a first transaction input of a first predecessor state into the use transaction, inserting a second transaction input of a second predecessor state into the use transaction, and inserting a merging state into the use transaction that is an allowed transition from the first predecessor state and the second predecessor state according to a state transition matrix.

[0087] The allowed state machine state transitions can be hard-coded into the first transaction input and / or the second transaction input by inserting a first reference to a first previous transaction having a first previous state into the first transaction input, a second reference to a second previous transaction having a second previous state into the second transaction input, and a first transaction output in a fused state into the consumption transaction, where state transition matrices are available for the first previous transaction and the second previous transaction.

[0088] The allowed state machine state transitions can include parallel operation from N initial states to N successor states by inserting a first transaction input with a first predecessor state into the use transaction, inserting a second transaction input with a second predecessor state into the use transaction, inserting a first reference to a first predecessor transaction with the first predecessor state into the first transaction input, inserting a second reference to a second predecessor transaction with the second predecessor state into the second transaction input, inserting a first transaction output with a first successor state into the use transaction, inserting a third set of script elements into the first transaction output, where the third set of script elements is part of a first locking script that constrains the first successor transaction to assume the first successor state, inserting a second transaction output with a second successor state into the use transaction, and inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second locking script that constrains the second successor transaction to assume the second successor state, where N is greater than or equal to 2.

[0089] The behavior of the state machine may be encoded for a smart contract that is implemented using a blockchain.

[0090] The transactions may be divided by any constraints. The method may include, at a node of a blockchain network, generating a first transaction, the first transaction including a first output having a first usable value and a first locking script, the first transaction including a second output having a second usable value and a second locking script, including in the first locking script a first set of constraints on a first selected transaction output, the first set of constraints being satisfied by a first unlocking script if the first selected transaction output is to be validated to spend the first usable value, and including in the second locking script a second set of constraints on a second selected transaction output, the second set of constraints being satisfied by a second unlocking script if the second selected transaction output is to be validated to spend the second usable value, wherein the first set of constraints or the second set of constraints impose constraints on the locking scripts of spend transactions having the first selected transaction output or the second selected transaction output as a spend transaction output.

[0091] The first selected transaction output can be an output of a first use transaction, and the second selected transaction output can be an output of a second use transaction that is different from the first use transaction. The first constraint set can be different from the second constraint set and different from the constraints on the transaction inputs of the first transaction. The first constraint set and the second constraint set can each include a common constraint set. A constraint on the locking script of a use transaction can require that the locking script of the use transaction include a reference to at least one field of the use transaction for the use transaction to be valid. Another constraint on the locking script can require that the locking script of the use transaction include a copy of a portion of the first locking script and / or a copy of a portion of the second locking script for the use transaction to be valid.

[0092] The first selected transaction output may be an output of the first use transaction. The second selected transaction output may be an output of the second use transaction. The first unlock script may include fields of the first transaction, fields of the first selected transaction, and fields of the second use transaction. The first lock script may include a first comparison of extracted fields of the first transaction and a second comparison of extracted fields of the first use transaction.

[0093] The first and second constraint sets may each include a common constraint set, whereby the two constrained usage transaction output locking scripts are constrained by the common constraint set. The first and / or second constraint sets may include constraints on a hash of a portion of the first locking script and / or a hash of a portion of the second locking script and / or a size of a portion of the first locking script and / or a size of a portion of the second locking script.

[0094] The first set of constraints and / or the second set of constraints may include any reference to input data. Each of the multiple outputs of the first transaction may be constrained by a different constraint applied to the output of the multiple outputs.

[0095] Transactions may have any constraint and interdependencies embodied therein, such as by a computer-implemented method, comprising: generating, at a node of a blockchain network, a first spendable transaction, the first spendable transaction including a first spendable output having a first spendable value and a first locking script; including, in the first locking script, a first set of constraints on spend transactions, the first set of constraints being satisfied by the spend transaction's first unlocking script if the spend transaction is to be valid for spending the first spendable output; including, in the first constraint set, a first spend transaction constraint requiring that a first spend transaction output of the spend transaction include a first spend transaction output locking script to include the first set of smart contract script instructions; and including, in the first constraint set, a second spend transaction constraint requiring the spend transaction to include a second set of smart contract script instructions and requiring the spend transaction to include a use transaction input that references the second spendable transaction output.

[0096] The first smart contract script instruction set may include script instructions replicated from the first locking script and / or script instructions corresponding to a new smart contract that is different from the smart contract implemented in the first locking script.

[0097] The first set of constraints may be that the first spend transaction output locking script includes a reference to a second spendable transaction output, and that the second set of smart contract script instructions includes a reference to an output of the first spendable transaction.

[0098] The method may include providing, in a first set of constraints, a first parallel constraint requiring the use transaction to include a first use transaction input that references the first usable transaction; a second parallel constraint requiring the use transaction to include a second use transaction input that references the second usable transaction output; a third parallel constraint requiring the first use transaction output locking script to include at least a first set of script instructions in the first smart contract script instruction set determined at least in part by the first locking script; and a fourth parallel constraint requiring the second use transaction output locking script to include a second set of smart contract script instructions determined at least in part by the locking script of the second usable transaction output.

[0099] The first set of constraints may include a first parallel constraint requiring the use transaction to include a first use transaction input that references the first usable transaction; a second parallel constraint requiring the use transaction to include a second use transaction input that references the second usable transaction output; a third parallel constraint requiring the first use transaction output locking script to include in the first smart contract script instruction set at least a first set of script instructions copied from the first locking script; and a fourth parallel constraint requiring the second use transaction output locking script to include a second set of smart contract script instructions copied from the locking script of the second usable transaction output.

[0100] Further, there is provided a computer-implemented method comprising: determining a first set of constraints on the first unlocking transaction output; determining a second set of constraints on the second unlocking transaction output; generating an initial transaction, the initial transaction comprising: at least one initial locking script including the first set of constraints and the second set of constraints; at least one redeemable value, wherein unlocking the at least one redeemable value comprises: the first set of constraints is satisfied, at least in part, by verifying that the unlocking transaction includes the first unlocking transaction output; and the second set of constraints is satisfied, at least in part, by verifying that the unlocking transaction includes the second unlocking transaction output; having the initial transaction validated at a node of a blockchain network; It is desirable to provide a computer-implemented method comprising:

[0101] The locking script in the first unlocking transaction output may be a duplicate of the locking script in the second unlocking transaction output.

[0102] The locking script in the first unlocking transaction output may be different from the locking script in the second unlocking transaction output.

[0103] The locking script in the first unlocking transaction output may include at least a portion of at least one initial locking script.

[0104] Execution of the at least one initial locking script may select the at least one portion from a plurality of portions of the at least one initial locking script.

[0105] Execution of an unlock script of the unlock transaction may result in the at least one initial lock script receiving data corresponding to one of the first unlock transaction output or the second unlock transaction output.

[0106] The data may have an index value, and execution of at least one initial locking script may determine whether a first set of constraints is satisfied if the index value is a first index value, and execution of at least one initial locking script may determine whether a second set of constraints is satisfied if the index value is a second index value.

[0107] The data may include the new lock script. As a result of receiving the data, the first unlock transaction output may be constrained to include the new lock script.

[0108] At least one initial locking script may include a constraint on the source of the data.

[0109] The method may further include determining a redeemable value of the first unlocked transaction output.

[0110] The initial transaction may encode a contract that has multiple states.

[0111] An unlock transaction may include multiple input values ​​corresponding to multiple states.

[0112] A first set of constraints may constrain the first unlock transaction output to have a first state, and a second set of constraints constrain the second unlock transaction output to have a second state.

[0113] Further, there is provided a computer-implemented method comprising: determining an unlocking transaction constraint that constrains unlocking transactions to include unlocking transaction inputs that reference outputs of previous transactions; generating a redeemable transaction, the redeemable transaction comprising: a redeemable transaction output comprising a redeemable amount; and a redeemable transaction locking script including an unlocking transaction constraint, wherein unlocking of the redeemable amount is conditioned on execution of at least one unlocking script of an unlocking transaction that satisfies the unlocking transaction constraint; and having the redeemable transaction validated at a node of the blockchain network.

[0114] The unlock transaction constraint may further constrain the unlock transaction input to contain a particular hash value.

[0115] A particular hash value may encode an identifier that references the output of a previous transaction.

[0116] The unlocking transaction constraint may further constrain the locking script of the unlocking transaction to include a set of script elements replicated from the redeemable transaction locking script.

[0117] A redeemable transaction may encode a contract that has multiple states.

[0118] The method may further include determining a redeemable value of the output of the unlocking transaction.

[0119] The unlock transaction constraint may include a particular lock script element from the output of a previous transaction. As a result of the unlock transaction input including the particular lock script element, execution of at least one unlock script may satisfy the unlock transaction constraint.

[0120] A particular lock script element may encode a cryptographic key for a particular entity.

[0121] The unlocking transaction constraint may be a first unlocking transaction constraint, and the method may further comprise: determining a second unlocking transaction constraint to further constrain the unlocking transaction; generating a second redeemable transaction, the second redeemable transaction comprising: A second redeemable amount; and and a second redeemable transaction locking script including a second unlocking transaction constraint, wherein unlocking the second redeemable amount may further include a step in which execution of the at least one unlocking script may be conditioned on satisfying the second unlocking transaction constraint.

[0122] The redeemable transaction locking script may be a first redeemable transaction locking script, and the at least one unlocking script may include a first unlocking script and a second unlocking script. The first unlocking transaction constraint may constrain the first unlocking script to include at least a portion of the first redeemable transaction locking script. The second unlocking transaction constraint may constrain the second unlocking script to include at least a portion of the second redeemable transaction locking script.

[0123] At least a portion of the first redeemable transaction locking script may include a cryptographic key associated with a first entity, and at least a portion of the second redeemable transaction locking script may include a cryptographic key associated with a second entity different from the first entity.

[0124] The unlocking transaction constraint may further constrain the unlocking transaction to constrain the output of the unlocking transaction.

[0125] The unlocking transaction constraint may encode another contract distinct from the contract: unlocking the redeemable amount may be conditional on another contract being implemented in the output of the unlocking transaction.

[0126] Further, there is provided a computer-implemented method comprising: generating a blockchain transaction, the blockchain transaction comprising: a state machine in a first state and having a set of allowed state transitions; encoding a set of script elements to be executed to cause the unlock transaction to decode a state machine according to a set of allowed state transitions, obey restrictions on inputs to the unlock transaction, or obey restrictions on outputs of the unlock transaction; and having the blockchain transaction validated by nodes of the blockchain network.

[0127] The set of allowed state transitions may include state transitions that can be implemented independently and in parallel in separate blockchain transactions.

[0128] The set of script elements may subject the unlock transaction to restrictions on the outputs of the unlock transaction, which may require that a first output of the unlock transaction exhibit a state corresponding to the first output according to the set of allowed state transitions, and that a second output of the unlock transaction exhibit a state corresponding to the second output according to the set of allowed state transitions.

[0129] The state corresponding to the first output and the state corresponding to the second output may be the same.

[0130] The state corresponding to the first output and the state corresponding to the second output may be different states.

[0131] The script element set may subject the unlock transaction to restrictions on the inputs of the unlock transaction, which may require that the inputs to the unlock transaction represent different state machines encoded in different blockchain transactions.

[0132] The restrictions on the inputs may require that the inputs refer to a state machine in a first state and to another state machine in another state different from the first state.

[0133] A first transition from a first state to a second state may be within the set of allowed state transitions. A second transition from another state to the second state may be within the set of allowed state transitions.

[0134] A set of script elements may subject the unlock transaction to restrictions on the inputs of the unlock transaction. The restrictions on the inputs may describe a set of conditions for advancing a state machine. The set of conditions for advancing a state machine may depend on the state of another state machine.

[0135] Other state machines may be encoded within other blockchain transactions, which may encode sets of conditions for advancing other state machines, which sets of conditions for advancing other state machines may depend on the state of the state machine.

[0136] The script element set may subject the unlock transaction to restrictions on the output of the unlock transaction. The output restrictions may require the unlock transaction to incorporate a smart contract element set into the output.

[0137] The set of elements for a smart contract may be obtained from another blockchain transaction.

[0138] A set of script elements may cause the unlock transaction to obey both restrictions on the inputs of the unlock transaction and restrictions on the outputs of the unlock transaction.

[0139] Further, there is provided a computer-implemented method comprising: generating, at a node of the blockchain network, a blockchain transaction having a transaction output transferable by a first unlocking transaction input of the first unlocking transaction; inserting a first set of script elements into the blockchain transaction, the first set of script elements constraining the first unlock transaction to include a first set of unlock transaction script elements corresponding to an operation of the state machine; and inserting into the blockchain transaction a second set of script elements that may constrain a second set of unlocking transaction script elements corresponding to allowed state machine state transitions that include states implementable using different blockchain transactions that may be processed independently in parallel by the blockchain network. The blockchain transaction may include a first output having a first locking script, the first transaction output value may include a second output having a second locking script and a second transaction output value, and the first set of script elements may be part of the first locking script.

[0140] An unlocking transaction may include an unlocking script that, when executed by a transaction validator with the locking script of the output of the previous transaction, Meet the specified verification tests, may execute the locking script of the output of the previous transaction and insert a first set of script elements into the unlocking transaction, where the first set of script elements may form part of the unlocking transaction locking script of the first output of the unlocking transaction and conform to requirements dictated by the previous transaction locking script, the first set of script elements corresponding to state machine operations; and may cause the node to at least store values ​​representing fields of the unlocking transaction in memory accessible to the transaction validator when inserting a second set of script elements into the unlocking transaction, where the second set of script elements form part of the unlocking transaction locking script and conform to requirements dictated by the previous transaction locking script and correspond to allowed state machine state transitions including states implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network.

[0141] The unlock transaction can include an input and an output, where the input references the output of a previous transaction. The unlock transaction includes an unlock script. The unlock script, when executed by a transaction verifier with a previous transaction lock script of the output of the previous transaction, satisfies a predetermined validation test, where the unlock script executes the lock script and inserts data corresponding to additional state machines into the unlock transaction as unlock transaction inputs and / or unlock transaction outputs based on allowed state machine state transitions, thereby causing the node to store at least values ​​representing fields of the unlock transaction in memory accessible to the transaction verifier when the number of unlock transaction inputs and / or unlock transaction outputs used in the unlock transaction is sufficient for the number of state machine transitions.

[0142] The allowed state machine state transitions include, for the unlock transaction, generating a first transaction output corresponding to a first subsequent state, inserting into the unlock transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output, inserting into the first transaction output of the unlock transaction a third set of script elements, where the third set of script elements may be part of a first locking script that constrains the first subsequent transaction to assume the first subsequent state, generating for the unlock transaction a second transaction output corresponding to a second subsequent state, inserting into the unlock transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input of a first subsequent transaction that references the first transaction output, inserting a second transaction output value of the second transaction output sufficient to cause the first transaction output to become an input of a second subsequent transaction that references the second transaction output; inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements may be part of a second locking script that constrains the second subsequent transaction to assume a second subsequent state; and inserting a fifth set of script elements into the first transaction output or the second transaction output, where the fifth set of script elements may be part of the first locking script or a second locking script that imposes a constraint that distinguishes the first and second subsequent transactions, thereby comprising a branching transaction from one initial state to two subsequent states.

[0143] The first locking script can constrain the first subsequent transaction to have a first state. The second locking script can constrain the second subsequent transaction to have a second state. The unlocking transaction can include three or more transaction output values ​​corresponding to a branch of three or more states. The unlocking transaction can include three or more transaction input values ​​corresponding to a union of three or more states. The first locking script and the second locking script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0144] Typically, an unlock transaction may include N transaction input values ​​and N transaction output values, where N may be 1, 2, 3, or more.

[0145] The allowed state machine state transitions can include a merging transaction from two initial states to one subsequent state by inserting a first transaction input of a first predecessor state into the unlock transaction, inserting a second transaction input of a second predecessor state into the unlock transaction, and inserting a merging state into the unlock transaction that is an allowed transition from the first predecessor state and the second predecessor state according to a state transition matrix.

[0146] The allowed state machine state transitions can be hard-coded into the first transaction input and / or the second transaction input by inserting a first reference to a first previous transaction having a first previous state into the first transaction input, inserting a second reference to a second previous transaction having a second previous state into the second transaction input, and inserting the first transaction output in the fused state into the unlock transaction, where state transition matrices are available for the first previous transaction and the second previous transaction.

[0147] The allowed state machine state transitions can include parallel operation from N initial states to N successor states by inserting a first transaction input with a first predecessor state into the unlock transaction, inserting a second transaction input with a second predecessor state into the unlock transaction, inserting a first reference to a first previous transaction having the first predecessor state into the first transaction input, inserting a second reference to a second previous transaction having the second predecessor state into the second transaction input, inserting a first transaction output with a first successor state into the unlock transaction, inserting a third set of script elements into the first transaction output, where the third set of script elements is part of a first locking script that constrains the first successor transaction to assume the first successor state, inserting a second transaction output with a second successor state into the unlock transaction, where N is greater than or equal to 2, and inserting a fourth set of script elements into the second transaction output, where the fourth set of script elements is part of a second locking script that constrains the second successor transaction to assume the second successor state.

[0148] The behavior of the state machine may be encoded for a smart contract that is implemented using a blockchain.

[0149] The transactions may be divided by any constraints. The method may include, at a node of a blockchain network, generating a first transaction, the first transaction including a first output having a first redeemable value and a first locking script, the first transaction including a second output having a second redeemable value and a second locking script, including in the first locking script a first set of constraints on a first selected transaction output, the first set of constraints being satisfied by the first unlocking script if the first selected transaction output should be valid for unlocking the first redeemable value, and including in the second locking script a second set of constraints on a second selected transaction output, the second set of constraints being satisfied by the second unlocking script if the second selected transaction output should be valid for spending the second redeemable value, wherein the first set of constraints or the second set of constraints impose constraints on the locking script of an unlocking transaction having the first selected transaction output or the second selected transaction output as an output of the unlocking transaction.

[0150] The first selected transaction output can be an output of a first unlocking transaction, and the second selected transaction output can be an output of a second unlocking transaction that is different from the first unlocking transaction. The first constraint set can be different from the second constraint set and different from the constraints on the transaction inputs of the first transaction. The first constraint set and the second constraint set can each include a common constraint set. A constraint on the locking script of the unlocking transaction can require that the locking script of the unlocking transaction include a reference to at least one field of the unlocking transaction for the unlocking transaction to be valid. Another constraint on the locking script requires that the locking script of the unlocking transaction include a copy of a portion of the first locking script and / or a copy of a portion of the second locking script for the unlocking transaction to be valid.

[0151] The first selected transaction output can be an output of the first unlocking transaction. The second selected transaction output can be an output of the second unlocking transaction. The first unlocking script can include fields of the first transaction, fields of the first selected transaction, and fields of the second unlocking transaction. The first unlocking script can include a first comparison of extracted fields of the first transaction and a second comparison of extracted fields of the first unlocking transaction.

[0152] The first and second constraint sets may each include a common constraint set, whereby the lock scripts of the outputs of the two constrained unlock transactions may be constrained by the common constraint set. The first and / or second constraint sets may include constraints on a hash of a portion of the first lock script and / or a hash of a portion of the second lock script and / or a size of a portion of the first lock script and / or a size of a portion of the second lock script.

[0153] The first set of constraints and / or the second set of constraints may include any reference to input data. Each of the multiple outputs of the first transaction may be constrained by a different constraint applied to the output of the multiple outputs.

[0154] Transactions may have any constraint and interdependencies embodied therein, such as by a computer-implemented method, comprising: generating, at a node of a blockchain network, a first redeemable transaction, the first redeemable transaction including a first redeemable output having a first redeemable value and a first locking script; including, in the first locking script, a first set of constraints for unlocking transactions, the first set of constraints being satisfied by the first unlocking script of the unlocking transaction if the unlocking transaction is to be valid for unlocking the first redeemable output; including, in the first constraint set, a first unlocking transaction constraint requiring that a first unlocking transaction output of the unlocking transaction include a locking script of an output of the first unlocking transaction to include the first set of smart contract script instructions; and including, in the first constraint set, a second unlocking transaction constraint requiring the unlocking transaction to include a second set of smart contract script instructions and requiring the unlocking transaction to include an unlocking transaction input that references the second redeemable transaction output.

[0155] The first smart contract script instruction set may include script instructions replicated from the first locking script and / or script instructions corresponding to a new smart contract that is different from the smart contract implemented in the first locking script.

[0156] The first set of constraints may be that the locking script of the output of the first unlocking transaction includes a reference to a second redeemable transaction output, and that the second set of smart contract script instructions includes a reference to an output of the first redeemable transaction.

[0157] The method may include providing, in a first set of constraints, a first parallel constraint requiring the unlocking transaction to include a first unlocking transaction input that references the first redeemable transaction; a second parallel constraint requiring the unlocking transaction to include a second unlocking transaction input that references a second redeemable transaction output; a third parallel constraint requiring the locking script of the output of the first unlocking transaction to include at least a first set of script instructions in the first smart contract script instruction set that are determined at least in part by the first locking script; and a fourth parallel constraint requiring the locking script of the output of the second unlocking transaction to include a second set of smart contract script instructions that are determined at least in part by the locking script of the second redeemable transaction output.

[0158] The first set of constraints may include a first parallel constraint requiring the unlocking transaction to include a first unlocking transaction input that references the first redeemable transaction; a second parallel constraint requiring the unlocking transaction to include a second unlocking transaction input that references the second redeemable transaction output; a third parallel constraint requiring the locking script of the output of the first unlocking transaction to include at least a first set of script instructions replicated from the first locking script in the first smart contract script instruction set; and a fourth parallel constraint requiring the locking script of the output of the second unlocking transaction to include a second set of smart contract script instructions replicated from the locking script of the second redeemable transaction output.

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

[0160] It is also desirable to provide a non-transitory computer-readable storage medium having executable instructions stored thereon that, when executed by a processor of a computer system, cause the computer system to perform at least one of the methods described above. [Brief explanation of the drawings]

[0161] These and other aspects of the invention will be apparent from and elucidated by the embodiments described hereinafter. Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 illustrates a blockchain environment in which various embodiments may be implemented. [Figure 2] 2 illustrates an example of a blockchain node that may be used in the blockchain environment of FIG. 1. [Figure 3] 3 illustrates an example of a transaction that may be stored in a blockchain ledger used by the blockchain nodes of FIG. [Figure 4] Here is an example of a blockchain transaction specific to the Bitcoin blockchain environment: [Figure 5] 10 shows an example script for implementing an OP_GENSIG script for generating a signature. [Figure 6] 10 shows an example script for implementing the OP_PREVTXINJECTION script for injecting a previous transaction corresponding to the input of an unlock transaction. [Figure 7] 10 shows an example script for implementing the OP_SELFTXINJECTION script for injecting a previous transaction corresponding to the input being signed. [Figure 8] 10 shows an example script for implementing an OP_SPENDINGTXINJECTION script for injecting a serial unlock transaction into a lock script. [Figure 9]An example of a pair of transactions is shown, one with value to be transferred and the other representing the unlocking of that value. [Figure 10] An example of a multiple transaction is shown, where the transaction has multiple inputs from other transactions and multiple outputs that can be transferred by future transactions. [Figure 11] 10 illustrates an example of generating a signature from a set of serialized transaction fields according to one embodiment. [Figure 12] 1 shows an example of an unlock transaction, including an unlock script that contains a copy of part of the unlock transaction. [Figure 13] Shows unlock transaction and previous transaction. [Figure 14] 10 is a flowchart of an example lock script that imposes constraints on the lock script of an unlock transaction. [Figure 15] Some examples of more specific steps corresponding to the steps in FIG. 14 are shown below. [Figure 16] Here is an example to verify the unlock script: [Figure 17] Here is an example of a lock script that imposes a set of constraints on its inputs: [Figure 18] 10 is a flowchart of an example of a lock script that imposes constraints on the input of an unlock transaction. [Figure 19] Here are some examples of input constraints: [Figure 20] An example of a constraint is shown in the context of the process shown in FIG. [Figure 21] Shows script constraint interlocks. [Figure 22] 1 shows an example of a state machine implemented using blockchain transactions. [Figure 23] We show examples of how state machine logic can be encoded in blockchain transactions. [Figure 24]1 illustrates an example of an unreliable deterministic state machine, according to one embodiment. [Figure 25] 1 is a flowchart illustrating an example of a process for a trustless deterministic state machine in accordance with various embodiments. [Figure 26] 1 shows a state machine that uses a state transition matrix with specific characteristics. [Figure 27] Here are some examples of transactions that can be used to implement a state machine: [Figure 28] An example of a branching portion of a smart contract using blockchain transactions. [Figure 29] 1 is an example of a pseudo-code sequence for branching processing. [Figure 30] An example of creating a new smart contract from a smart contract using a blockchain transaction is shown. [Figure 31] 1 is an example pseudo-code sequence for enforcing a smart contract in an unlock transaction. [Figure 32] 1 shows an example of a fusion operation for a smart contract that uses blockchain transactions. [Figure 33] 1 is a pseudo-code sequence as an example of a fusion process with weak dependencies. [Figure 34] 1 is a pseudo-code sequence as an example of a fusion process with strong dependencies. [Figure 35] 1 shows an example of parallel processing behavior for smart contracts that use blockchain transactions. [Figure 36] 1 is an example pseudo-code sequence of a parallel transaction barrier process. [Figure 37] We show an example of how parts of a smart contract can be executed using blockchain transactions in parallel paths, complying with contract barriers. DETAILED DESCRIPTION OF THE INVENTION

[0162] Referring first to Figure 1, an example of a blockchain network 100 associated with a blockchain according to one embodiment of the present disclosure is shown. In this embodiment, blockchain network 100 includes blockchain nodes, which may be implemented as peer-to-peer distributed electronic devices that each execute instances of software and / or hardware that perform operations according to a blockchain protocol agreed upon in whole or in part among operators of the blockchain nodes. In some examples, these distributed electronic devices are referred to simply as "nodes," such as node 102 in Figure 1. One example of a blockchain protocol is the Bitcoin protocol.

[0163] Nodes 102 may comprise any suitable computing device (e.g., a server in a data center, a client computing device such as a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), among multiple computing devices in a distributed system of a computer resource service provider, or among any suitable electronic client device. Nodes 102 may have inputs for receiving data messages or objects representing proposed transactions, e.g., transactions 104. Nodes 102 may query information they hold, e.g., understanding the state of a transaction.

[0164] As shown in FIG. 1 , some nodes 102 may be communicatively coupled to one or more other nodes 102. Details regarding which nodes 102 can communicate with which other nodes need not be centrally determined. Active nodes in the blockchain network 100 can communicate with one or more other nodes 102. As a result, messages passed from one node 102 to another node 102 can propagate throughout the entire blockchain network 100 (or a significant portion thereof), assuming the message is a message that the blockchain protocol indicates should be forwarded. One such message is the announcement of a proposed transaction by one of nodes 102A, which propagates along a path such as path 106. Such a message may be the announcement of a new block proposed for inclusion in the blockchain.

[0165] FIG. 2 illustrates an example of a blockchain node 202 that may be used in a blockchain environment as a node in the blockchain network of FIG. 1. As illustrated, blockchain node 202 includes a processor 204, program memory 206, storage 208 for blockchain rules and protocol details, a list of peers 210, storage 212 for application variables, a communications interface 214, and storage 216 for a blockchain ledger. Blockchain ledger 216 includes data corresponding to blocks in the blockchain, such as blocks 221, 222, and 223, which contain data corresponding to transactions, such as block 222 with transactions 230(1)-(4). With the exception of block 223, blocks may be cryptographically immutable, in that subsequent blocks rely on values ​​calculated based on the block when it becomes immutable, and any modifications to an immutable block may be easily recognized by other blockchain nodes as an invalid block. Block 223 is shown as an open box, representing storage for transactions that may be mutable and have not yet been committed to the blockchain.

[0166] Blockchain nodes 202 communicate via communication interface 214, which can be implemented as one or more of wired or wireless communication. Blockchain ledger 216 may be a complete copy or a portion of the blockchain network's blockchain ledger. Some blockchain nodes maintain only untransferred transactions, while others maintain the entire ledger. In this way, the ledger is a distributed ledger, since each node can have its own copy. Nodes preferably modify only their own copies according to the rules of the protocol, and for all nodes that fully follow those rules, their copies should be identical to other nodes', except for a certain propagation time for blocks and transactions, sometimes. Blockchain nodes must include the ability to validate received blocks and the transactions within those blocks. The rules of the blockchain protocol dictate that a blockchain node will not propagate a block or transaction to other nodes if it determines that the block of transactions is invalid. According to these rules, blocks and transactions that are valid and verified as valid may propagate through the blockchain network, but invalid blocks and transactions are not.

[0167] Some nodes in a blockchain network may be miner nodes, performing operations to collect transactions and create blocks of transactions so that new blocks can be committed to the blockchain. Miner nodes may be expected to perform some operations that are complex (to prevent dishonest nodes from easily generating improper blocks) and dependent on the data of the included transactions (to prevent dishonest nodes from performing complex operations in advance). The performance of these tasks is easily verified by other nodes. These other nodes verify the work of the miner nodes and, upon verification, accept and propagate the block to their copy of the blockchain, thereby committing the new block to the blockchain's distributed ledger. In some examples, a block is a group of transactions, often marked with the timestamp and "fingerprint" (e.g., hash) of the previous block. In this way, each block is linked to the previous block, creating a "chain" that links the blocks of the blockchain. In embodiments, valid blocks may be added to the blockchain by consensus of nodes in the blockchain network. In some examples, the blockchain also includes a list of validated blocks.

[0168] In one embodiment, at least some of the nodes act as validating nodes that validate transactions as described in this disclosure. In some examples, a blockchain provides proof of value in the form of digital assets, and transactions on the blockchain provide a chain from a genesis transaction (which starts the blockchain) or a distribution transaction that generates newly "mined" digital assets as a result of participation by miner node operators, to subsequent transactions. At the end of one portion of the chain are untransferred transactions, or portions thereof, and each transaction on the blockchain specifies one or more outputs. Some of these outputs may be transferred, while others may not. Here, an output includes a specification of its value and the requirements needed to "unlock" the output by inserting a valid transaction (i.e., one that at least meets the specified requirements) that extends that portion of the chain. As used herein, an unspent transaction output may be referred to as a UTXO. Unlocking a UTXO is also known as spending a UTXO.

[0169] The requirements necessary to unlock a UTXO can be specified in the UTXO's locking script. A valid unlocking transaction (i) specifies one or more previous UTXOs as inputs to the transaction, which may be by pointers to the UTXOs, (ii) satisfies the locking script requirements for each UTXO, and (iii) has inputs such that the sum of the values ​​of all UTXOs pointed to by these inputs is less than or equal to the sum of the values ​​of all outputs of the transaction. The data representing the satisfaction of the locking script requirements is called the unlocking script. A validating node can process the locking script following the unlocking script, and the output of that processing is either an invalid result or validation of the unlocking transaction.

[0170] When one node executes an unlock script and a lock script, the result of which is a validation that can be implemented on other nodes, the process is stateless. Thus, an unlock transaction that satisfies the lock script of a previous transaction's output on the blockchain that has not yet been transferred may propagate and eventually be committed to the blockchain. The node that created the committed unlock transaction may specify in its own lock script the requirements necessary to unlock the value of the new transaction's output. This process can be considered stateless because the scripts do not need to reference anything outside of the scripts and, with a few minor exceptions, do not depend on variables or other state outside of those scripts. As a result, the unlock script and the lock script can be evaluated separately.

[0171] In other variations, the blockchain system may include functionality that allows for the inclusion of external data in the script evaluation process. In such cases, the external data may be controlled and / or secured in such a way that when the unlock script and lock script are evaluated using the external data, the evaluation is consistent across the nodes performing the evaluation.

[0172] FIG. 3 illustrates an example transaction 300 stored in a blockchain ledger used by the blockchain nodes of FIG. 2. Other variations with similar functionality are possible. The data elements or fields of the transaction may be as shown in FIG. 3 or may include additional fields other than those described in this disclosure. As shown, there is a Blockchain Version field 302 having a value indicating the blockchain protocol version of the transaction 300. A #vin field 304 indicates the number of transaction inputs (described below) present in the transaction 300. While other fields are present and not shown, for each transaction input (illustratively shown here as Vin[y] 310), there may be a set of fields including a transaction ID (TxID) 311 of the previous transaction, a pointer 312 to one of the outputs of the previous transaction (the transaction that provides a transaction output matching the transaction input 310), where the TxID 311 and the pointer 312 together form a pointer 313 that references the output of the previous transaction. As used herein, when used in the context of a current or present transaction, the term "prior transaction" may refer to a particular previous transaction whose transaction output is referenced (and "transferred") by the current transaction. In an example, the current transaction may be referred to as the "unlocking transaction."

[0173] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values; instead, there is a decentralized mechanism for generating unique TxIDs for transactions by generating a hash of the contents of the transaction itself. Because a valid transaction cannot have the exact same content as another valid transaction, each valid transaction can have a unique hash for its TxID (barring the astronomically low probability of a hash collision). However, here we assume that each transaction has a unique transaction ID. Due to the nature of hashing, once a TxID is generated from the contents of a transaction, none of its contents can be changed, and the TxID remains valid for that transaction.

[0174] As shown in FIG. 3, the field set for transaction input Vin[y] 310 includes an Unlocking_Script_Length field 314 that indicates the length of the following script, an Unlocking_Script field 315 that contains an unlocking script for vin[y] 310 that “unlocks” the corresponding locking script of the transaction output pointed to by pointer 313, and a Sequence# field 316 that can be used to constrain transaction 300.

[0175] While Figure 3 explicitly shows only one transaction input and one transaction output, there can be one or more of each. Following the transaction input, there may be a #vout field 320, which can indicate the number of transaction outputs (also described below) present in the transaction 300. For each transaction output (shown here as an example Vout[x] 330), there may be a series of fields, including an Output Value field 332 indicating the transaction value provided by this transaction output Vout[x] 330, a Locking_Script_Length field 334 indicating the length of the following script, and a Locking_Script field 336 containing the locking script for this transaction output Vout[x] 330. In this way, the transaction value of this transaction output can be "transferred" by anyone who can create an unlock transaction with a transaction input whose unlock script can be verified as TRUE by a blockchain node when verified using the unlock script and lock script. The transaction output field may be followed by other fields, such as a Lock Time field 338 that constrains the transaction 300 to be inactive before a specified future time or before a specified future block. If each transaction input of an unlock transaction points to a corresponding transaction output of an output of a previous transaction, and the output of the previous transaction contains a transaction value, the transaction input need not include a field indicating that transaction value.

[0176] FIG. 4 illustrates an example blockchain transaction 400 specific to the Bitcoin blockchain environment. In this example, blockchain transaction 400 includes the data elements or fields shown and may include additional fields other than those shown or described in this disclosure. Transaction 400 includes an nVersion field 402 having a value indicating the version of transaction 400. A #vin field 404 may indicate the number of transaction inputs present in transaction 400. For each transaction input, such as transaction input Vin[y] 410, there may be a series of fields, including a hash 411 that references the previous transaction, a pointer n 412 to a specific output of the previous transaction, a scriptSigLen field 414 indicating the length of the following unlock script, a scriptSig field 415 that contains the unlock script for that transaction input Vin[y] 410, and an nSequence field 416 that may be used to constrain transaction 400.

[0177] Following the transaction inputs is a #vout field 420 indicating how many transaction outputs are present in the transaction 400, and for each transaction output (shown here as exemplary Vout[x] 430), there may be a series of fields including an nValue field 432 indicating the transaction value provided by this transaction output Vout[x] 430, a scriptPubKeyLen field 434 indicating the length of the following lock script, and a scriptPubKey field 436 containing the lock script for this transaction output Vout[x] 430. The transaction 440 may also be shown with an nLockTime field 438, which may constrain the transaction 400 to not be active before a specified future time or before a specified future block.

[0178] OP Code In an example scripting language, such as that used in many Bitcoin blockchain nodes, there may be a set of operation codes that appear within the script as script instructions, such as lock script and unlock script. In this disclosure, various script opcodes and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies may implement different instruction sets, and therefore the opcodes set forth in this disclosure should be considered exemplary of the operations performed by the opcodes.

[0179] Certain embodiments of the present disclosure operate under the assumption that a scripting system or other system for implementing the described instruction set allows for more than 200 instructions (e.g., more than 200 opcodes) in a single script. Likewise, certain embodiments of the present disclosure further assume that the functionality provided by the opcodes referred to in this disclosure is present and possible in the system executing the opcodes, scripts / instruction sets. Examples of operation codes referred to in this disclosure include: OP_ADD Pops the top two items from the stack, adds them, and pushes the result onto the stack.

[0180] OP_BIGMOD Pops the top two items from the stack, divides the second item by the first, and pushes the remainder onto the stack.

[0181] OP_BIGMODADD Pops the top three items from the stack, modulo adds the first and second items, modulo adds the third item, and pushes the result onto the stack.

[0182] OP_BIGMODINVERSE Pops the top two items from the stack, performs a modulo negative exponentiation of the second item modulo the first item, and pushes the result onto the stack.

[0183] OP_BIGMODMUL Pops the top three items from the stack, modulo multiplies the first and second items, modulo multiplies the third item, and pushes the result onto the stack.

[0184] OP_CAT Pops the top two items from the stack, concatenates the two items, and pushes the result onto the stack.

[0185] OP_CHECKSIG Pops two items from the stack, uses the first item as the public key and the second item as the signature, checks whether the popped signature is a valid signature, and if so, pushes 1 (TRUE) onto the stack; otherwise, pushes 0 (FALSE) onto the stack.

[0186] OP_CHECKSIGVERIFY Has the same functionality as OP_CHECKSIG, but OP_VERIFY is executed afterwards.

[0187] OP_DIV Pops two items from the stack, divides the second item by the first, and pushes the result onto the stack.

[0188] OP_DUP Duplicates the top item on the stack by pushing a copy of the top item onto the stack.

[0189] OP_ELSE If the preceding OP_IF, OP_NOTIF, or OP_ELSE was not executed, these statements are executed. If the preceding OP_IF, OP_NOTIF, or OP_ELSE was executed, these statements are not executed if the previous OP_IF, OP_NOTIF, or OP_ELSE was executed.

[0190] OP_ENDIF Ends an if / else block.

[0191] OP_EQUAL Reads the top two items on the stack and pushes a 1 onto the stack if the two items are exactly equal, and a 0 otherwise.

[0192] OP_EQUALVERIFY Same as OP_EQUAL, but performs OP_VERIFY afterwards.

[0193] OP_FROMALTSTACK Puts the input on top of the main stack and removes it from the alternate stack.

[0194] OP_HASH256 The input is hashed twice, first with SHA-256 and then with RIPEMD-160.

[0195] OP_IF If the top stack value is not False, the statement is executed and the top stack value is removed.

[0196] OP_MUL Multiplies the top two items on the stack.

[0197] OP_NOTIF If the top stack value is False, the statement is executed and the top stack value is removed.

[0198] OP_OVER Copies the second item on the stack and pushes it onto the top of the stack.

[0199] OP_ROLL The nth deep item in the stack is moved to the top.

[0200] OP_SUBSTR Returns a section of a string.

[0201] OP_SWAP Swap the top two items on the stack.

[0202] OP_TOALTSTACK Puts the input onto the top of the alternate stack and removes it from the main stack.

[0203] OP_VERIFY Marks the transaction as invalid if the top stack value is not true.

[0204] Some of the opcodes above may be base opcodes supported by a blockchain node, while others, which for clarity will be referred to here as opcodes, are typically implemented as small scripts composed of multiple base opcodes. For example, OP_BIGMOD, which will be referred to as an opcode, might be implemented using a sequence of opcodes to perform the function of dividing the top two items on the stack and returning the remainder. OP_BIGMODADD, OP_BIGMODINVERSE, and OP_BIGMODMUL could easily be expressed as a sequence of similar opcodes.

[0205] OP_GENSIG In this disclosure, references to OP_GENSIG should be considered as shorthand for the operation corresponding to the OP_GENSIG script described herein. OP_GENSIG scripts that generate transaction signatures can also be pushed onto a stack or used. OP_GENSIG scripts are implemented by first pushing inputs onto the main (last-in, first-out) stack, then<SIGHASH Type> (indicating which fields of the transaction should be used in the hash), the message value <m>(double SHA256 of the serialized set of used transaction fields of the transaction), private key (Message value <m>used for hashing), and numbers <k>(Let us assume it is a random or pseudo-random number used to mask / protect the private key; "mask number").

[0206] Figure 5 shows the input and output of the OP_GENSIG script. In the OP_GENSIG script, the first line is a number. <k>to the alternate stack, then the elliptic curve generator<PubK G> against <k>to generate an elliptic curve point K on the top of the main stack. The second line of the script computes r from the x-coordinate of K modulo n and pushes a copy of r onto the alternate stack. The third line of the script computes s=k -1 Determine (m+r×a) mod n. Finally, line 4 of the script encodes r and s in DER format,<SIGHASH Type> Concatenate to.

[0207] The type of signature hash can be indicated by a byte-encoded value, SIGHASH Type. The SIGHASH Type value specifies the set of fields to extract from the transaction before serialization (e.g., canonicalization) and hashing. In some examples, the SIGHASH Type value can be SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, or a combination of two or more of these. In one embodiment, the type SIGHASH_ALL indicates that all fields in the transaction, except for the input script, are included in the serialization (and therefore will be hashed and signed). In one embodiment, the type SIGHASH_NONE indicates that outputs do not need to be signed so that others can update the transaction. In one embodiment, the type SIGHASH_SINGLE indicates that the input is signed, but the sequence number is blank. Thus, others can create new versions of the transaction that use the same hash (assuming the hashed fields do not change), but only outputs in the same position as the input are signed.

[0208] In one embodiment, the type SIGHASH_ANYONECANPAY is combined with other types to indicate that an input containing SIGHASH_ANYONECANPAY is signed, but that other inputs need not be signed. SIGHASH Type values ​​may be represented by a numeric value that indicates the SIGHASH Type. For example, in some implementations, SIGHASH_ALL is represented by a byte with a value of 1 (e.g., binary "00000001"), SIGHASH_NONE is represented by a byte with a value of 2 (e.g., binary "000000010"), SIGHASH_SINGLE is represented by a byte with a value of 3 (e.g., binary "000000011"), and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80 (e.g., binary "01010000"). In some implementations, the combination of SIGHASH Type values ​​is performed by binary addition of the respective byte values. In some instances, the set of transaction fields determined by a SIGHASH Type represents a subset determined by the SIGHASH Type value of the corresponding transaction being serialized. For example, a SIGHASH Type of SIGHASH_ANYONECANPAY means that only one transaction input is included in the signature.

[0209] By requiring the inclusion of a SIGHASH in the unlock script, the lock script can verify that the serialized set of unlock transaction fields provided by the unlock script is indeed the source of the SIGHASH, and then use the opcode OP_CHECKSIG to verify that the SIGHASH Type value provided by the unlock script matches the signature hash of the unlock transaction. The lock script is able to do this because, when executed by the transaction verifier, the transaction verifier can then perform the OP_CHECKSIG operation and put the signature of the actual unlock transaction onto the stack.

[0210] OP_DERENCODE In this disclosure, references to OP_DERENCODE should be considered as shorthand for an operation that corresponds to popping the top two items from the stack, encoding them in DER format, and pushing the result onto the stack.

[0211] OP_ECPMULT In this disclosure, references to OP_ECPMULT should be considered as shorthand for an operation that corresponds to popping two items from the stack, performing elliptic curve point multiplication (also called elliptic curve scalar multiplication) of those two items, and pushing the result onto the stack.

[0212] OP_ECPX In this disclosure, references to OP_ECPX should be considered as shorthand for the operation corresponding to popping two items from the stack, using the first item as the modulus n and the second item as the elliptic curve point K, computing the x-coordinate of K modulo n, and pushing the result onto the stack.

[0213] OP_PREVTXINJECTION In this disclosure, references to OP_PREVTXINJECTION should be seen as a shorthand for the operation corresponding to the injection of a previous transaction corresponding to input X of an unlock transaction. Figure 6 shows the inputs and outputs of the OP_PREVTXINJECTION script.

[0214] OP_SELFTXINJECTION In this disclosure, references to OP_SELFTXINJECTION should be considered as shorthand for the operation corresponding to the injection of a previous transaction corresponding to the input being signed. Figure 7 shows the inputs and outputs of the OP_SELFTXINJECTION script.

[0215] OP_SPENDINGTXINJECTION In this disclosure, references to OP_SPENDINGTXINJECTION should be considered as shorthand for an operation corresponding to injecting a serialized unlock transaction into a lock script. An entity that provides a SIGHASH Type value and an unlock transaction field set determined according to the SIGHASH Type can unlock the transaction output. This is a convenience feature. Figure 8 shows the inputs and outputs of the OP_SPENDINGTXINJECTION script.

[0216] OP_EXTRACTTXID In this disclosure, references to OP_EXTRACTTXID should be considered as shorthand for an operation that takes a transaction ID and a transaction ID position as input and outputs an extracted transaction ID. The inputs to OP_EXTRACTTXID are a serialized transaction and a value X indicating an input index, and the output is the transaction identifier associated with the transaction input at that index in the serialized transaction. This script may need to parse the serialized transaction to extract the transaction ID because serialized transactions contain variable-length fields with length variances indicated by other fields in the serialized transaction.

[0217] 9 shows an example pair of transactions. A blockchain node 902 validating a transaction may have a transaction verifier 904. The transaction verifier 904 may be a stateless stack-based transaction verifier that outputs a TRUE or FALSE result 906 depending on whether its input is valid. In other variations, the transaction verifier is not necessarily stateless and / or may reference external authoritative data or state. The teachings herein may also be applied to blockchain systems that do not use stack-based transaction verifiers.

[0218] The inputs to the transaction validator 904 may be a lock script 910 from the output (transaction output to be transferred) of a previous transaction (Previous Tx) 912 and an unlock script 920 from the input (unlocking transaction input) of an unlocking transaction (Unlocking Tx) 922. Although not shown, each transaction may include other fields. In the more general case, each transaction may have multiple inputs and / or multiple outputs, in which case the lock script 910 may be a lock script for one of the transaction outputs of the previous transaction 912, and the unlock script 920 may be an unlock script for one of the transaction inputs of the unlocking transaction 922.

[0219] In a stateless stack-based transaction verifier, lock script 910 and unlock script 920 are processed independently and, with a few exceptions, do not depend on variables or other state outside of these scripts. As a result, lock script 910 does not need to reference fields of previous transactions outside of lock script 910 itself. Lock script 910 also cannot reference fields of previous transaction 912, and therefore unlock transaction 922, because lock transaction 922 did not exist when lock script 910 was created and made immutable.

[0220] The unlock script 920 is also stateless and cannot directly operate on the fields of the unlock transaction 922. The stateless quality can be useful in that it guarantees that a properly programmed blockchain node will reach the same result 906 given the same lock script 910 and the same unlock script 920. One exception to this is that a script can check the signature of one script against the signature generated from the entire transaction. In one embodiment, the script can use OP_CHECKSIG for this purpose.

[0221] In stack-based operations, the transaction verifier executes the unlock script by processing each opcode in the script in order. Some opcodes are processed as results, and some result in data being pushed onto the stack, popped from the stack, or some combination. When the unlock script completes execution, data may remain on the stack. If the unlock script execution is free of script errors or execution-terminating opcodes, the transaction verifier executes the lock script and can use the data present on the stack. If the lock script and unlock script can be written using the same set of opcodes, this is essentially similar to executing a single script that contains the concatenation of the unlock script and a subsequent lock script. However, checking for script errors at the end of execution of the unlock script's opcodes and before executing the lock script's opcodes can prevent problems caused by a malformed unlock script.

[0222] When the script execution is complete, the result remaining on the top of the stack is the result of the verification. If TRUE is on the top of the stack, this can be considered verification that the unlock script actually unlocks the lock script. In this regard, the unlock script meets all of the requirements of a lock script.

[0223] 10 shows an example of multiple transactions and multiple inputs and outputs. As shown, a previous transaction (Previous Tx1) 1002 has two transaction outputs, Vout[0] 1004 with a lock script 1006 and Vout[1] 1014 with a lock script 1016, and their corresponding transaction output values, such as the transaction inputs to the previous transaction 1002, among other fields not shown. An unlocking transaction (Unlocking Tx1) 1020 is shown with two transaction inputs, Vin[0] 1024 (with an unlock script 1026 and a pointer 1028 to the corresponding output of the previous transaction) and Vin[1] 1034 (with an unlock script 1036 and a pointer 1038 to the corresponding output of the previous transaction). In this example, the corresponding previous transaction output for Vin[0] is Vout[0] of the previous transaction (Previous Tx1) 1002, while the corresponding previous transaction output for Vin[1] is some output of another transaction (Previous Tx2) (not shown).

[0224] To validate the unlock transaction 1020, a blockchain node 1042 with a transaction validator 1044 outputs a TRUE or FALSE result 1046 depending on whether all of its inputs are valid. In this case, since multiple inputs may exist for unlocking the transaction 1020, each input is validated by processing the transaction input's unlock script and the corresponding transaction output's lock script to which the input's pointer points.

[0225] Because it can have multiple outputs and multiple inputs, the value of one transaction can be transferred by multiple other transactions, and the value redeemable in a new transaction can come from more than one previous transaction. As explained above, the locking script can impose constraints on what should be in the unlocking script via signatures and other cryptographic techniques.

[0226] One such constraint might be that the unlock script must contain some arbitrary data. Some constraints might be "weak" or more general, such as that the unlock script must contain data that is four bytes long, or that it must contain a certain number of bytes without constraining the bytes to a specific value. A stronger or more specific constraint might be that the data must produce a specific hash value when hashed. This latter constraint typically requires the data to be a specific length and a unique value for that data, since it is nearly impossible for someone to determine different values ​​that produce the same hash. Constraints can be implemented in a script by having the unlock script push its data or a hash of its data onto the stack, and the lock script push the required hash onto the stack, then execute OP_EQUAL and then OP_VERIFY opcodes. These opcodes return True if the two pushed items match and False if they do not. In more general cases, constraints can be imposed that require specific data to be present or that require data with specific characteristics to be present.

[0227] An example of a weak constraint is when an unlock script must contain certain data that may constitute the set of serialized unlock transaction fields, without necessarily requiring those fields to be specific values. In this way, a lock script can constrain the script of the unlock script that unlocks the output of a lock script to include the fields of the unlock transaction from which the unlock script came. This allows the lock script to effectively perform operations on the fields of the unlock transaction that the unlock script leaves on the stack. Another example of a weak constraint is when an unlock script must contain certain data that may come from specified locations, but there are no constraints on the values ​​of the data. This allows some weak constraints to be imposed, even if the values ​​of the data will not be determined until after the lock script is immutable.

[0228] Constraint operations and constraint data may contain elements of a "smart contract." A smart contract defines the terms of an agreement: who can do what, when they can do it, and who gets paid, when, and what. Smart contract conditions can be enforced by the blockchain protocol, where they can be expressed as weak or strong constraints on the unlock script or other parts of the unlock transaction. Thus, as in the example above, if only Bob can unlock the value of a locked transaction output (because only an unlock script that only Bob can create unlocks that transaction output), the transaction output can be spent only if authorized by one party, after a certain amount of time has passed, and only after the other transaction output has been spent.

[0229] Figure 8 shows OP_SPENDINGTXINJECTION, an abbreviation for the opcode for a script that encodes a constraint for injecting a serialized set of unlock transaction fields. A lock script may include the opcode OP_GENSIG (resulting in a Bitcoin signature) followed by the opcode OP_CHECKSIG (resulting in the signature being checked as a valid signature for an unlock transaction). For OP_GENSIG to generate a valid signature, it must have the following specific input elements: a SIGHASH type element, a serialized set of unlock transaction fields (the specific set corresponding to the SIGHASH type element), a private key, and a mask number (e.g., a random or pseudo-random number used to mask / protect the private key). By including the hash opcode, private key, and random number in the lock script, this effectively constrains the unlock script to provide the SIGHASH type and the serialized set of unlock transaction fields.

[0230] Figure 11 shows the procedure for generating a signature from a set of serialized transaction fields. This may be done by a blockchain node creating a transaction or by some other generator of transactions. As shown in Figure 11, a serialized transaction 1110 (i.e., a transaction represented as a series of data objects in a particular format) includes a set of transaction field values. The signer of the serialized transaction 1110 selects a SIGHASH Type 1112 and provides the signer's private key. From the SIGHASH Type 1112, the blockchain client / node can determine which fields of the serialized transaction 1110 or modified fields should be used. Some of the fields may be modified (except set to zero) before the hash is generated. In the example of Figure 11, the SIGHASH Type is set equal to SIGHASH_NONE|SIGHASH_ANYONECANPAY, and therefore the fields selected are those indicated by the modified serialized transaction 1114.

[0231] The blockchain client / node generates a hash of the modified serialized transaction 1114 (e.g., performs a double SHA-256 hash), resulting in message m 1116. The blockchain client / node processing the serialized transaction 1110 selects a number k 1118, typically a random or pseudo-random number, to mask / protect the private key. The number k is referred to as the "mask number" during this disclosure. The blockchain client / node then generates a signature 1124 (in this example, a DER-encoded EC signature) from a set of signing inputs 1120: the SIGHASH Type 1112, the message m 1116, the signer's private key 1122, and the number k 1118. The signature 1124 and the SIGHASH Type 1112 can then be used in the unlock script.

[0232] FIG. 12 shows an example of an unlock transaction 1200 that includes an unlock script 1203, which contains a copy of the unlock transaction (e.g., a serialized set of unlock transaction fields). As shown in FIG. 12, one of the transaction inputs is Vin[z]. Input Vin[z] has a hash, which is the previous transaction TxID, and the number of outputs, n, of the previous transaction. Together, these form a pointer 1202 to the specific output of the specific previous transaction that Vin[z] should unlock. Transaction input Vin[z] has an unlock script 1203, which also has several components or subscripts 1206, 1208, 1210, and 1212. Unlock script 1203 includes a serialized version 1206 of Previous TxZ. Also shown is a serialized version 1208 of Previous TxZ', which is a transaction with the outputs transferred by Previous TxZ serialized in the same way. Although not shown, additional previous transactions can be included. The unlock script 1203 also includes a SIGHASH_TYPE byte 1210 to indicate which fields of the unlock transaction 1200 were included.

[0233] The previous transaction's lock script uses OP_GENSIG and OP_CHECKSIG to include the unlock transaction in the unlock script, and the previous transaction's TxID and OP_EQUALVERIFY to include a serialized version 1206 of the Previous TxZ in the unlock script. The TxID of the Previous TxZ can be extracted from a field in the unlock transaction and the Previous TxZ can be inserted. The Previous TxZ itself contains the TxID of the Previous TxZ', so that TxID can be extracted, and so on.

[0234] The set of serialized transaction fields for an unlock transaction does not include the unlock script of the unlock transaction itself; otherwise, causality issues arise. In some embodiments, such as in the Bitcoin blockchain environment, the signature hash of a transaction can exclude some predefined fields. The SIGHASH Type may indicate which set of fields is extracted from the transaction before it is serialized and hashed.

[0235] A previous transaction's locking script can impose a requirement on an unlocking transaction that, for the unlocking transaction to be valid, the unlocking transaction's unlocking script must include a copy of some or all of the unlocking transaction's fields and a reference to one or more of the previous transactions that the unlocking transaction unlocks. Of course, the fields of an unlocking transaction are mutable when the unlocking transaction is created. However, a previous transaction's locking script can impose constraints on the fields of the unlocking transaction, in that if a field of the unlocking transaction that is part of the unlocking transaction's unlocking script does not satisfy the constraint, the unlocking transaction need not validate it when the locking script is executed. Fields that are not part of the unlocking script (such as fields not included by a SIGHASH Type value or not set to zero) need not be constrained by the locking script. Also, not all fields included in a serialized unlocking transaction require constraints. For example, a locking script might only constrain one of many fields of a serialized unlocking transaction that is included in the unlocking script.

[0236] Different outputs of a previous transaction can apply different sets of constraints, possibly to different inputs and outputs of different unlocking transactions. Using such techniques, a blockchain node can generate transactions using such a locking script, which can perform further checks so that the generated transaction output is transferred and the transaction unlocking that transaction output can necessarily carry different data elements and state.

[0237] The transactions in Figure 12 can be expanded to implement state machines with significantly more complex functionality. As mentioned above, the lock script, when validated, has access to data that is only available after the lock script is created and finalized. That data can include details about the fields of the unlock transaction being validated and details about the previous transaction that included the lock script (and potentially other previous transactions known to the blockchain node creating the unlock transaction at the time). This allows the state of the state machine to be expressed in the script, and states and state transitions to be implemented and occur within the trustless confines of the blockchain environment. In other words, the state machine can be implemented by treating transactions like any other transaction processed by the blockchain network, with transactions validated by blockchain nodes that are not necessarily trusted. In some examples, "trustless" refers to the property that any entity can create a valid unlock transaction as long as constraints are met, and that entity does not need to be trusted. However, in some cases, an entity may need to interact with a determined source to obtain required inputs. In some embodiments, one or more inputs can be obtained from an undetermined source, such as a serialized previous transaction.

[0238] In a blockchain network, a transaction has some value for its inputs (determined by the transaction output values ​​of the transaction before the transaction inputs unlock) and some value for its outputs. To be valid, the sum of the outputs cannot exceed the sum of the inputs (except for distribution and genesis transactions, which may be excluded in this description), and to be accepted by a miner node, the outputs may be smaller than the inputs to provide the miner node's operator with a reason to participate. When implementing a trustless deterministic state machine using a blockchain network, the initial state of the state machine may be present in a transaction that contains enough value to provide the miner with a reason to include the transaction corresponding to the state machine's state transition.

[0239] In the general case, the unlock script of a previous transaction can be used in implementing a state machine. As a result, the unlock transaction represents a state transition of the state machine, with the lock script constraining the content of the unlock transaction, and in particular the content and nature of the various transaction outputs of the unlock transaction. Thus, the lock script of the output of the previous transaction can, in effect, specify what each transaction output of the unlock transaction should look like. The lock script can require different characteristics of different unlock transaction outputs, for example, by requiring that Vout[0] of the unlock transaction contain certain data and script elements, and that Vout[1] of the unlock transaction contain certain other data and other script elements.

[0240] An entity that provides a SIGHASH Type and the unlock transaction field set that a particular SIGHASH Type uses can unlock a transaction output. In this way, some parties have reason to propagate the contents of a transaction by unlocking and transferring details from a lock script. As noted above, in some instances, "unlocking" a transaction output represents creating an unlock transaction that references the transaction output and can evaluate as valid, thereby resulting in the transfer of the transaction output.

[0241] Using the techniques and apparatus described above, transactions can be created on a blockchain ledger that includes scripts that implement smart contracts, that can implement state machines, and that can reference fields of the current transaction, previous transactions whose outputs are transferred by the current transaction, and possibly other previous transactions. These features allow transaction flows to be forced to execute self-replicating scripts for use in smart contracts and the like.

[0242] FIG. 13 shows an unlock transaction 1320 and a previous transaction 1310. In this example, the unlock transaction has an input Vin[0] 1322 that references the previous transaction and the previous transaction's transaction output Vout[x] 1314. For the unlock transaction to be considered valid, constraints on the lock script of Vout[x] must be satisfied. As noted above, some constraints may be simple. For example, a simple requirement is that the unlock script of an unlock transaction input that points to a lock script must be able to provide a valid signature signed by the public key that appears in the lock script. However, as described herein, the lock script can provide more complex constraints.

[0243] For example, the lock script for Vout[x] 1314 of the previous transaction 1310 can impose constraints specifically on the outputs of the unlock transaction. The lock script for Vout[x] 1314 in this example imposes a set of constraints (Constraint Set1) on output Vout[0] 1324 of the unlock transaction 1320 and a set of constraints (Constraint Set2) on output Vout[0] 1326 of the unlock transaction 1320. In the particular case, Constraint Set1 and Constraint Set2 are identical and simply require that both lock scripts for outputs Vout[0] 1324 and Vout[1] 1326 be the same as the lock script for Vout[x] 1314 of the previous transaction 1310.

[0244] In the more general case, constraints may go beyond simply copying the lock script. Furthermore, the set of constraints may vary from unlock transaction output to output. These constraints may be the number of outputs an unlock transaction can have, the value of each output, and require specific content of the lock script for the unlock transaction's outputs.

[0245] Constraints on the output of injected unlocking transactions 14 is a flowchart of an example portion 1400 of a lock script of a previous transaction that imposes constraints on the lock script of the unlock transaction. This example may be performed by a stack-based verifier that processes the unlock script of the output of the unlock transaction, which may leave data on the stack, and then processes the lock script of the output of the previous transaction to perform this processing. Because the processing of the unlock script may leave data on the stack, and the unlock script may leave the serialized contents of the unlock transaction on the stack, including, for example, details of the lock script of the unlock transaction, these details are available during verification.

[0246] In step 1402 of the process, the verifier verifies that the unlock script contains certain data; the verifier may perform other validations that do not need to be done for each output. Examples of such data may include a serialized set of unlock transaction fields, a serialized previous transaction, a reference to the previous transaction, etc. In step 1404, the verifier checks whether these constraints are met, and if not, stops at step 1406 and invalidates the unlock transaction. Otherwise, processing continues at step 1408, where the verifier determines whether there are any unlock transaction outputs to check. The first time, the verifier may set index i=0, and if there are no more outputs to check, it moves on to another processing flow at step 1410.

[0247] For each index of an output, the verifier performs steps 1412, 1414, and 1416, then increments i (step 1418) and returns to step 1408 until there are no more indices to consider. In another variation, instead of incrementing the index by one and validating each output, the verifier loops through a set of indices that does not necessarily include all values ​​of i and / or does not necessarily include and check them in an additive order. In such a variation, step 1418 would differ accordingly, looping through index i for outputs in the particular set of indices being checked.

[0248] In step 1412, the verifier extracts the lock script of Vout[i] of the unlocking transaction. This can be implemented using an OP_SUBSTR operation on the stack contents. Next, in step 1414, the verifier determines what constraints exist on the lock script of Vout[i] of the unlocking transaction based on the lock script of the output of the previous transaction. In step 1416, the verifier then verifies these constraints. In this way, the lock script of the output of the previous transaction, which is transferred by the input of the unlocking transaction, can impose constraints on the output of the unlocking transaction.

[0249] The locking script of the output of the previous transaction constrains the output of the unlocking transaction such that the locking script of the previous transaction dictates the rules for how to transfer the output of the unlocking transaction. These constraints can be hard-coded in the locking script of the output of the previous transaction, or the constraints can be determined based on data present in the unlocking script of the input of the unlocking transaction that points to that output of the previous transaction.

[0250] Figure 15 shows some example, more specific steps corresponding to steps 1402 and 1414 of Figure 14. One example of a verifier performing step 1402 is to perform step 1502, in which the verifier determines that some of the data in the unlock script (or elsewhere) in the input of the unlock transaction came from a determined source. The determined source may be a serialization of the unlock transaction or a previous serialized transaction. Alternatively, or in addition, the verifier may perform step 1504 and perform some other validation of the details of the unlock transaction data.

[0251] Regarding specific constraints that the locking script of the output of the previous transaction may impose on the locking script of the output of the unlocking transaction, there is step 1506, where the locking script of the output of the unlocking transaction must equal data from some determined source ("==" represents a test of equality). Another example is step 1508, where the locking script of the output of the unlocking transaction must equal data hard-coded in the locking script of the output of the previous transaction. Step 1510 covers the case where another constraint is imposed on the output of the unlocking transaction based on data from a determined source, and step 1512 covers the case where another constraint is imposed on Vout[i] based on hard-coded data from the locking script of the output of the previous transaction.

[0252] In some cases, instead of using the full range of data from the source or hard-coded, a hash of the data can be used, in which case the comparison is done hash to hash.

[0253] The data to be used may come from the previous transaction, for example hardcoded in the locking script of the previous transaction's outputs, or it may come from a transaction preceding the previous transaction (or a reference to a preceding transaction, two links emanating from the unlocking transaction (i.e., a transaction whose outputs were transferred by the previous transaction)). In this way, the data used can come from any transaction in the chain from the previous transaction to its distribution transaction (e.g., a Coinbase transaction in the Bitcoin protocol).

[0254] An example of this is shown in Figure 16. For step 1402 in process 1400 of Figure 14 (where the verification is that the unlock script has specific data), steps 1602, 1604, 1608, 1610, and 1612 can be performed to verify that the unlock script of the unlock transaction has a reference to a transaction in the transaction chain.

[0255] In step 1602, the verifier extracts the transaction ID (TxID) from the input of the unlock transaction. This can be done if the TxID is available in the unlock script. The verifier can then verify in step 1604 that the unlock script also contains a serialized copy of the previous transaction for that TxID. If not, the verifier can invalidate the transaction, but if it does, in step 1608, the verifier extracts the TxID from the previous transaction TxID' and then verifies in step 1610 that the previous transaction contains a copy of or a reference to the serialized transaction referenced by TxID'. This chain can continue n times, where in step 1612, the verifier extracts the TxID from the previous transaction TxID'. (n-1) Verify that the transaction referenced by '(n-1 dash) contains a copy of the serialized transaction referenced by 'TxIDn' (n dash).

[0256] In FIG. 16, steps 1614 and 1616 are n ' and extract the lock script for the copy of the transaction referenced by TxID '. n ' is equal to the extracted lock script of the transaction referenced by

[0257] Constraints can be applied to a subset of an output's lock script, rather than the entire lock script. Constraints can be determined from a subset of the data, rather than the entire data. For example, one subset might require that "Pay-to-Public-Key-Hash" appear, while another subset might require that "Pay-to-Bob" appear.

[0258] The lock script for the output of the unlock transaction is <x> <y>It can be expressed in two parts, where <x>and <y>teeth, <x>and <y>can be extracted using a string concatenation operation so that the constraints are applied to each individually. For example, <x>teeth<PubK A> Constrained by <y>is constrained by OP_CHECKSIG. In this way, the overall locking script is<PubK A> Constrained by OP_CHECKSIG. It is also possible to use constraints derived from data in the unlock script.

[0259] Using these techniques, the locking script of an output of a previous transaction can impose constraints on an unlocking transaction that attempts to unlock that output. In particular, the constraints can be on the set of outputs that the unlocking transaction has, and the constraints can be different for different outputs and can be different from the locking script of the previous transaction.

[0260] Constraints can correspond to indices that refer to various outputs. In some cases, constraints are repeated for each index, but in other cases, they can provide some structure. For example, the index of a constraint can be used in a conditional statement to select a set of constraints, such as "if index==0: constraint A els constraint B".

[0261] If a set of indexes is hard-coded, the results of the part of the script that uses the indexes may be fixed. Instead of, or in addition to, constraints on the outputs of the unlocking transaction, there may also be constraints on the inputs of the unlocking transaction.

[0262] Constraints on the input of injected unlock transactions One use of having a locking script that constrains the inputs of an unlocking transaction is to allow the locking script to encode a dependency on a transaction with certain properties (e.g., the constrained input must reference that transaction). This differs from constraining the outputs of an unlocking transaction in that the outputs are mutable, whereas the inputs may be references to existing immutable UTXOs on the blockchain. In other words, the outputs can be changed to match the constraints, while inputs that match those constraints must be found.

[0263] Constraints on the inputs of an unlocking transaction fall into two general types: (1) constraints placed directly on the input's references (i.e., the transaction TxID field and, optionally, the output pointer field), and (2) constraints on fields of the previous transaction that the references in the input point to.

[0264] 17 shows a previous transaction 1710 and an unlock transaction 1720. The previous transaction 1710 has an input Vin[y] 1712 and an output Vout[x] 1714. The unlock transaction 1720 has inputs Vin[0] 1722 and Vin[1] 1723 and an output Vout[0] 1724. The lock script for Vout[x] 1714 imposes a constraint set (Constraint Set1) on input Vin[0] 1722 and a constraint set (Constraint Set2) on input Vin[0] 1723. The constraint sets can include constraints on the unlock script, references, or other parts of the inputs. The constraint sets can be the same, different, or have more than one input, some for the same input and some for different inputs.

[0265] In part, these constraints can reference portions of the unlock transaction by having a serialized set of unlock transaction fields injected as data into the unlock script, such as by using the OP_SPENDINGTXINJECTION script.

[0266] 18 is a flowchart of an example portion 1800 of a locking script of a previous transaction that imposes constraints on the inputs of an unlocking transaction. This example may be performed by a validator that processes the unlocking script of the output of an unlocking transaction. The validator performs this processing by leaving data containing the details of the unlocking transaction on a stack and then processing the locking script of the output of the previous transaction.

[0267] In step 1802 of the process, the verifier verifies that the unlock script contains certain data; the verifier may perform other validations that do not need to be done for each output. In step 1804, the verifier checks whether these constraints are met, and if not, stops at step 1806 and invalidates the unlock transaction. Otherwise, processing continues at step 1808, where the verifier determines whether there are any unlock transaction inputs to check. The first time, the verifier may set index i=0, and if there are no more inputs to check, it moves on to another processing flow at step 1810.

[0268] For each index of the input, the verifier performs steps 1812, 1814, and 1816, then increments i (step 1818) and returns to step 1808 until there are no more indices to consider. (Alternatively, the verifier loops through a set of indices, not necessarily all indices and / or not necessarily in increasing order; in these cases, step 1818 is accordingly different, looping while checking inputs via index i.) In step 1812, the verifier extracts a reference to the previous transaction and its own unlocking output from the unlocking transaction input Vin[i]. This can be implemented using an OP_SUBSTR operation on the stack contents. Next, in step 1814, the verifier determines, based on the locking script of the previous transaction's output, what constraints should be on the reference, or use that reference to trigger the injection of the previous transaction, after the constraints become applicable to the fields of the previous transaction. In step 1816, the verifier then verifies these constraints. In this way, a locking script on the output of a previous transaction that is transferred by the input of an unlocking transaction can impose constraints on the input of that unlocking transaction.

[0269] Other examples of input constraints are shown in Figure 19 by elements 1902, 1904, 1906, 1910, 1912, and 1914. Since TxIDs may be mapped one-to-one with transactions, this may mean that the constraint is that a specific transaction must be referenced in the input. The transaction that the locking script depends on is created first, so that the locking script can use its own TxID in the constraint for the input of the unlocking transaction.

[0270] Constraints can be set on fields of a previous transaction that correspond to references in an input. This may be possible by using the TxID in the input to trigger injection of the corresponding previous transaction before imposing the constraint on the field of the previous transaction. The constraint can reference an input that is different from the input that unlocks the output of the previous transaction whose lock script imposes the constraint.

[0271] Figure 20 shows example constraints associated with steps 1802 and 1814 in process 1800 of Figure 18. In Figure 20, steps 2002, 2004, 2014, and 2016 may be implemented. In step 2002, the verifier extracts the transaction ID (TxID) from the input of the unlock transaction. This can be done if the TxID is available in the unlock script. The verifier can then verify in step 2004 that the unlock script also includes a copy of the serialized previous transaction for that TxID. In step 1614, the verifier extracts one or more field sets from the previous transaction and verifies any constraints on the extracted field sets in step 1616.

[0272] 21 illustrates interlocking script constraints. As shown, a previous transaction (Previous Tx1) 2102 and a previous transaction (Previous Tx2) 2104 may be referenced by inputs of an unlocking transaction (Unlocking Tx1) 2106. In particular, as indicated by arrow 2110, input Vin[0] of Unlocking Tx1 points to Vout[0] of Previous Tx1. Therefore, if Unlocking Tx1 is valid, it can unlock Vout[0] of Previous Tx1. Also, as indicated by arrow 2112, input Vin[1] of Unlocking Tx1 points to Vout[0] of Previous Tx2. Such references may be conventional references for unlocking transactions with multiple inputs that reference multiple previous transactions.

[0273] In order to reference previous transactions, these transactions must already exist and be immutable before the creation of the unlocking transaction. Nevertheless, previous transactions can apply interdependent lock script constraints to the unlocking transaction. By imposing constraints on the set of inputs of the unlocking transaction, interdependent lock scripts can be implemented, which can provide concurrency, especially in the context of trustless deterministic state machines.

[0274] The lock script 2120 for output Vout[0] of Previous Tx1 has a constraint on input Vin[1] of Unlocking Tx1 that requires input pointer 2122 (e.g., a reference to the previous transaction and the output of the previous transaction) to be a reference to Previous Tx2 and Vout[0] of Previous Tx2. The lock script 2124 for output Vout[0] of Previous Tx2 has a constraint on input Vin[0] of Unlocking Tx1 that requires input pointer 2126 (e.g., a reference to the previous transaction and the output of the previous transaction) to be a reference to Previous Tx1 and Vout[0] of Previous Tx1.

[0275] Because a transaction's TxID is not known until the transaction ends, the transaction locking script cannot directly specify the TxID that the unlocking transaction's unlocking script should reference. However, the locking script can essentially do this by extracting an input pointer (which contains the TxID of the previous transaction with the locking script), using that TxID to inject into a field in the previous transaction, and verifying that some field in the previous transaction is equal to an expected value. In other words, if the previous transaction has a field set to a certain value, the previous transaction's locking script can get the TxID from the unlocking transaction input, inject the transaction that TxID references, and check that the field is set to a specific value. If the field is not set to that specific value, then the unlocking transaction input must point to a different previous transaction. Therefore, by checking for a specific value, the locking script for the previous transaction's output can verify whether the unlocking transaction input references the previous transaction's output.

[0276] Thus, Previous Tx1 states that its first output can only be transferred by a transaction (Previous Tx2) that also unlocks the first output of that particular transaction, and Previous Tx2 states that its first output can only be transferred by a transaction that also unlocks the first output of Previous Tx1.

[0277] Interdependent locking scripts allow, among other things, multiple smart contracts that set conditions on each other. For example, smart contract 1 could be "Alice agrees to contribute 1 BTC to Carol, but only if Bob contributes 2 BTC to Carol," and smart contract 2 could be "Bob agrees to contribute 2 BTC to Carol, but only if Alice agrees to contribute 1 BTC to Carol." To be valid, an unlock transaction must unlock both smart contracts.

[0278] As mentioned above, a lock script can encode a dependency on a transaction that has certain properties, and those properties can include fields of that transaction. This means that a lock script can be made dependent on a transaction that has a particular lock script.

[0279] 21, lock script #1 (of Vout[0] of Previous Tx1) constrains Vin[1] of Unlocking Tx1 to reference lock script #2124 (of Vout[0] of Previous Tx2), and lock script #3 2124 constrains Vout[0] of Unlocking Tx1 to reference lock script #1 of Vout[0] of Previous Tx1. Here, this can be referred to as a lock script encoding a dependency on another lock script.

[0280] Implementing interdependent lock scripts can create a causality race condition, where the first lock script encodes a dependency on the second lock script, and the second lock script encodes a dependency on the first lock script, because it is possible for one of Previous Tx1 and Previous Tx2 to exist before the other. If lock script A hard-codes a dependency on lock script B, lock script B must already be known and determined; it is impossible for lock script B to hard-code a dependency on unknown lock script A. This can be addressed by having a determinable dependency in at least one of the lock scripts.

[0281] For example, lock script A depends on lock script X, which is provided in unlock script A, and lock script B depends on lock script Y, which is provided in unlock script B. When an unlock transaction is created, both lock script A and lock script B are known, so the unlock script A in the unlock transaction can include lock script B as its data, and the unlock script B in the unlock transaction can include lock script A as its data.

[0282] In some variations, to validate an unlock transaction input, its unlock script must reference Previous Tx1 and Previous Tx2. In other variations, it is sufficient for the unlock script to reference two (or more) previous transactions that have the same lock script as Previous Tx1.

[0283] In some variations, instead of imposing a requirement that the unlock script reference a particular previous transaction or set of previous transactions, the requirement may be exclusive, in that the requirement may be that the unlock script not reference a particular previous transaction or set of previous transactions. Combinations of these variations are also possible, effectively implementing Boolean logic regarding what previous transactions are referenced. For example, to validate an unlock transaction input, the unlock script must have references to Previous Tx1 and Previous Tx2, no reference to Previous TxA, and must have a reference to either Previous TxB or Previous TxC. Other logical expressions may also be possible.

[0284] State Machine Using the above techniques, a state machine can be implemented using blockchain transactions, where transactions have states, are encoded by a state machine structure such as by a transaction matrix, and are allowed to have next states. An unlock transaction can unlock the output of such a blockchain transaction, effectively causing a state transition in the state machine.

[0285] FIG. 22 illustrates an example state machine 2200 implemented using blockchain transactions. Specifically, FIG. 22 illustrates a state machine that transitions from a first state to a second state using blockchain transactions. In some examples, the state machine's state transitions are described as determining a next state given (1) a current state, (2) one or more inputs 2226, and (3) a state rule set 2206. The example 2200 in FIG. 22 illustrates a previous transaction 2202 having a state rule set 2206 and a first state 2228A embedded in the parameters. In some embodiments, an unlock transaction 2204 is created to accept the input 2226 from a determined source. The input 2226, in combination with the first state 2228A, may be usable to reference the state rule set 2206 to determine a second state 2228B embedded in the parameters of the unlock transaction 2204.

[0286] In an embodiment, state rule set 2206 includes a state transaction matrix that can be represented by constraints on unlock transaction 2204 imposed by a lock script. In such an embodiment, the constraints can be parameterized by the inputs for which the current state and next state are determined. The constraints can include checks to ensure that unlock transaction 2204 includes an output that contains the next state value in a particular field.

[0287] In an embodiment, the current state is expressed as a parameter embedded in the transaction, such as part of the locking script of the transaction's output, and the unlock transaction 2204 may have a next state value embedded in the unlock transaction 2204. The next state value may be the current state for a set of field values ​​in the unlock transaction 2204 and may be accessible when the unlock transaction 2204 is created, as described above.

[0288] In some embodiments, at least one input is provided as external data within parameters that are determined when the unlock transaction 2204 is generated. To be secure, such parameters come from a determined source. This can provide deterministic state transitions. Finally, by using self-replicating lock scripts, trustless deterministic state machine embodiments can be created. Furthermore, by allowing different lock scripts to be imposed on different transaction inputs and outputs of a transaction, concurrent trustless deterministic state machines can be implemented.

[0289] Figure 23 illustrates this point. In this example, a trustless deterministic state machine system 2300 may include a previous transaction 2302 in a first state 2328A ("S1") in a state rule set 2306. The state rule set 2306 provides two possible states 2330A ("S2" or "S3") for the next state. The state rule set 2306 may be encoded in a lock script of the output of the previous transaction 2302. The current state 2328A may be embedded in a Lock time field or in the lock script. The next state, in this example S2 2328B, is encoded in a lock script of the output of an unlock transaction that unlocks the output of the previous transaction and executes the state transition.

[0290] As shown in example 2300, an unlock transaction 2304 takes as input the inputs 2326 in its unlock script and a first state 2328A ("S1") embedded in the set of field values ​​of the previous transaction 2302, and determines an appropriate second state 2328B ("S2") from the state rule set 2306. Additionally, as shown in example 2300, a state transition matrix provides a possible new state 2330B ("S4" or "S5") for the next state transition from the second state 2328B. Note that the state rule set 2306 may be encoded as a switch statement or other conditional statement (e.g., "if-then-else") parameterized by the current state and one or more inputs. The current state, S2 2328B, may be embedded in the Lock time field or in the lock script. The next state, in this example S2 2328B, is encoded in the lock script of the output of the unlock transaction, which unlocks the output of the previous transaction and executes the state transition.

[0291] In embodiments, each possible state is represented in a self-replicating locking script with a set of rules for state changes, such as a state transition matrix, and a particular transaction output represents a state machine in a particular state. In such embodiments, the locking script of a transaction output is replicated to all unlocking transactions that attempt to transfer control of a digital asset to a next transaction that must be linked to the current transaction output. This process may be repeated until a termination condition is met. Because the inputs are undetermined and may be pending data, the state of the state machine can change based on certain external inputs. Thus, pending data provides inputs that can affect the next state.

[0292] As an illustrative example, Alice lends funds to Bob, and Bob agrees to repay Alice. A trustless deterministic state machine, such as that described in this disclosure, can be implemented as a smart contract representing payments Bob makes to Alice. For example, the smart contract can be constructed so that Bob makes monthly payments to Alice for the next three months, and if Bob misses a payment, Bob's debt enters the collection phase. Thus, as long as Bob makes monthly payments, the current state remains in the repayment state. However, if an external entity provides input indicating that Bob has missed a payment, the state branches to the delinquent state. In the delinquent state, Alice can release the transaction and hand it over to the debt collector, which causes the trustless deterministic state machine to switch to the debt collection state. In the debt collection state, the debt collector collects the debt from Bob. Such smart contracts can be created using variations of the scripts described herein.

[0293] In another example, Alice is a very charitable person who donates one unit of digital assets each month. Her rules state that anyone can claim the digital assets, but only one unit per month. Alice creates a smart contract in the manner described in this disclosure and seeds it with an initial pool of three units of digital assets. Alice can construct a script that allows any entity to acquire one unit of digital assets per month. The remainder of the digital assets are replicated to subsequent smart contracts.

[0294] FIG. 24 illustrates unlock and lock scripts for an exemplary trustless deterministic state machine of the present disclosure.

[0295] Figure 25 is a flowchart illustrating an example of a process 2500 for a trustless deterministic state machine, according to various embodiments. An example of a script for doing this is the script of Figure 24. Some or all of process 2500 (or any other processes described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems comprised of executable instructions and / or other data, and may be implemented as executable instructions collectively executing on one or more processors. The executable instructions and / or other data may be stored in a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on a magnetic, optical, or flash medium). These instructions may be executed as part of a blockchain transaction validation process.

[0296] For example, some or all of process 2500 may be performed by a validator node in an example blockchain network, such as example blockchain network 100 of FIG. 1. Such a validator node may include any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computational resource service provider, or any suitable electronic client device). Process 2500 includes a series of operations in which a lock script of a self-replicating smart contract is validated, the current state is obtained from a serialized previous transaction, input is obtained from an unlock script, and the next state is determined at least in part based on a set of state rules.

[0297] In step 2502, the system receives an unlock transaction. The system begins by executing the unlock script of the unlock transaction input, which places the serialized previous transaction and the inputs embedded in the lock script on a stack. These inputs can be retrieved in 2512. In 2504, the system executing process 2500 determines whether an exit condition is met. In an embodiment, the exit condition is a condition that, upon completion, terminates the state machine transition. If the exit condition is met, the system executing process 2500 proceeds to 2506, whereby the trustless deterministic state machine stops self-replication and / or state propagation.

[0298] In step 2508, the system verifies that the lock script of the output of the previous transaction matches the lock script of the output of the unlock transaction. If the lock scripts do not match, the verification fails and the unlock transaction may not be verified. Alternatively, if the lock scripts match, in 2510, the system extracts a current state from the set of possible states from the serialized previous transaction. In 2512, the system obtains one or more inputs placed on the stack as a result of executing the lock script. Next, in 2514, the system applies a state rule set to determine a next state from the set of possible states of the trustless deterministic state machine based on the current state and the one or more inputs. In 2516, the system may verify that the next state (e.g., state variables and, if applicable, other state-related data) is embedded in the unlock transaction. The system may also apply any remaining constraints as specified in the lock script. After successful completion of operations 2502 through 2516, the process ends in 2518, and the unlock transaction may be considered valid by the system executing the process. It should be noted that one or more of the operations performed in steps 2502-2518 may be performed in various orders and combinations, including in parallel.

[0299] In the context of describing the disclosed embodiments, unless otherwise specified, use of language relating to executable instructions (also called code, applications, agents, etc.) that perform actions that the "instructions" do not normally perform alone (e.g., transmit data, perform calculations, etc.) means that the instructions are being executed by a machine, thereby causing the machine to perform the specified actions.

[0300] State Machines as Blockchain Transactions Using the techniques and apparatus described above, a state machine can be implemented using blockchain transactions. The state machine can be operated by having states change from state to state along a state transition matrix. Some state diagrams can be very complex and have multiple paths. In such cases, some of the calculations performed by the state machine can be performed in parallel with other calculations. As described herein, the state machine can operate using blockchain transactions and can operate partially in parallel.

[0301] As described in more detail, a trustless deterministic state machine can be implemented using a lock script and an unlock script of a blockchain transaction. The lock script includes constraints that can be imposed on the unlock script and can therefore require the injection of specific data into the unlock script of an unlock transaction input, such as serialized fields of the unlock transaction itself, serialized fields of the previous transaction that includes the lock script being executed, the current state value, inputs from determined sources (optional), and a state transition matrix that defines a set of flow conditions and operations for the state machine, dictating how to compute the next state from the current state and other inputs. One of the constraints of the lock script in an unlock transaction is that the unlock transaction must replicate the lock script in one of its outputs and propagate the state machine.

[0302] FIG. 26 illustrates a state machine using a state transition matrix 2600 with certain characteristics. State S1 is highlighted to indicate the current state. The state machine can transition to any state along the state transitions indicated by the arrows. In the state transition matrix, transitions can occur along S1-S2-S3-S4-S8-S12, although state S5 may also require a transition from S1. Similarly, state S5 transitions to S6 and S9. The transition from state S9 to state S10 may be conditional or have a barrier, meaning that the state transition must not occur until the parallel transition from state S6 to state S7 has occurred. The transition to state S8 may occur as a merger from states S4 and S7.

[0303] Each of these states is initiated by a state machine represented by a blockchain transaction output, and each transition is processed by a single pass of the transaction output, with an unlock transaction input unlocking the output of a previous transaction resulting in a state transition as shown in Figure 22 or Figure 23. However, blockchain transaction inputs and outputs can be used to achieve parallel processing of states. This is useful when a smart contract needs to execute in multiple parallel steps. During the course of a contract, tasks may be executed in parallel. For example, a contract to build a house may have various stages of completing tile work and various stages of completing landscaping work, which can occur in parallel. By enabling parallel execution within a smart contract, different fragments of the contract can be executed asynchronously and independently of each other.

[0304] Figure 26 illustrates many needs for such processing. One is to generate multiple paths from a single state. This can be smart contract branching. Suppose a smart contract begins at state S1. Branching this smart contract can generate two state machines: state S2 and state S5. Another need is smart contract replication, having two identical state machines, each at the same state and operating in parallel. For example, a smart contract may require multiple instances of steps S2-S3-S4. This can be smart contract cloning, which is a special case of branching, where two or more new transaction outputs have the same state.

[0305] Another useful feature is the spawning of new contracts. For example, the smart contract represented by the state transition matrix 2600 of Figure 26 may be such that, in state S3, some party to the smart contract creates a separate contract that may be bound to the smart contract but is not part of the smart contract and / or may be created after the smart contract is created. This may be referred to herein as spawning. This new contract may differ from the initial smart contract originally provided in the state transition diagram of Figure 26.

[0306] A fusion is when two state machines or two smart contracts merge, as in the case of state S4 and state S7. As explained below, different paths can be executed in parallel, such as S2-S3-S4 or S5-S6-S7. Using these elements, parallel trustless deterministic state machines can be easily implemented in a blockchain environment.

[0307] Figure 27 shows an example transaction with one input, Vin[0], and two outputs, Vout[0] and Vout[1]. By unlocking the outputs of this transaction, two independent transactions are placed on the blockchain ledger, and the creators of these transactions are compensated by some value (not shown) offered to them by this transaction. As shown, the lock script of the output of the previous transaction (referred to as Vin[0]) requires that the unlock transaction that unlocks that output include states S2 and S5. To unlock the output of the unlock transaction that includes state S2 (Vout[0] in Figure 27), future unlock transactions are constrained to include the next state based on the current state being S2. Similarly for state S5.

[0308] In this way, transaction outputs can have states, imposing constraints on which states an unlocking transaction can be in. This allows blockchain transactions to be implemented according to a state diagram such as the one shown in Figure 26, with the unlocking of a transaction output corresponding to a state transition in the state diagram. To avoid the case where someone creates a single transaction with multiple inputs and unlocks both outputs of the indicated transaction, a locking script can check the transaction and disallow it. The rules for how valid transactions are generated, the number of required outputs, etc., are encoded into the smart contract as hard-coded values ​​or parameters provided after the smart contract is created.

[0309] Forking and cloning smart contracts using blockchain transactions Branching is used when a state needs to transition to two or more (not necessarily unique) next states in parallel. A smart contract may be able to operate without all possible concurrency, but if concurrency should exist, branching may initiate it. As mentioned above, the locking script of the output of a smart contract transaction on the blockchain ledger can "impose" requirements on the input of an unlocking transaction and / or on the locking script of the output of an unlocking transaction on the blockchain ledger. Cloning may be a specific type of branching where a set of next states may all be the same state. For an unlocking transaction, multiple outputs may be constrained to replicate the transition matrix and populate each next state.

[0310] Branching / cloning can be achieved by applying trustless deterministic state machine constraints to a set of outputs. As mentioned above, a set of indices allows different constraints to be applied to different outputs. This set of indices can be hard-coded in the transition matrix or provided as part of the input to the verification process.

[0311] Because a given unlock transaction may have multiple outputs, some of which may be unrelated to the state machine or may be associated with multiple unrelated state machines, it is more practical to embed the next state in the transaction's lock script rather than embedding it in a field common to all outputs, such as the Lock time field. Constraining the subset of the lock script for outputs is discussed above.

[0312] Figure 28 shows how scripts relate to a fork operation. As shown, a state machine 2810 is implemented using a previous transaction 2820 and an unlock transaction 2830. The lock script of the previous transaction 2820 constrains the unlock transaction 2830 to have at least two outputs, each requiring the subsequent unlock transaction to have an output in a specified state (and be a separate transaction). This allows these states S2, S3 to execute independently and, where possible, in parallel.

[0313] Using state machines, subtasks help enable faster, parallel execution of smart contracts. Multiple states may be used to process subtasks, and concurrency can be provided by having separate transaction threads, since a single state machine can typically only be used in a single state at a time. State machines can branch by creating multiple transaction locking scripts. Based on the current state from the output of a previous transaction, an unlocking transaction can be constrained to have two or more outputs with locking scripts, as shown in Figure 28. To prevent branches from becoming irredeemable and terminating prematurely, each output value should be checked to ensure there are enough funds to continue the state machine.

[0314] As indicated by the dashed arrows, input Vin[0] of unlock transaction 2830 points to the previous transaction 2820 and that transaction's output Vout[0]. The lock script for Vout[0] includes a current state ("S1"), a transition matrix for the state machine, and constrains Vout[x] of unlock transaction 2830 to be a next state ("S3") and Vout[y] of unlock transaction 2830 to be another next state ("S2"), each constrained to convey a state transition matrix, and possibly other constraints.

[0315] The lock script for the output of the previous transaction is<Current State><Transition Matrix><other script> while the locking script of the output of the unlocking transaction is <nextstate> <transitionmatrix><other script>Instead of replicating the entire lock script, only a subset of the lock script may be replicated, and the other subset may be constrained to include state.

[0316] Instead of storing the state in a lock script, you can store the state of the state machine in a field of the transaction. This field cannot be used for other purposes, such as the lock time field. In fact, you can use another unused transaction field. This works for a single state, and also works if you need to store multiple states, but it can be more complicated.

[0317] 29 shows an example of pseudocode that may be executed to perform the forking or cloning process. This pseudocode may be implemented using the OP Code described herein. This pseudocode may be executed by a processor of a blockchain node that generates transactions and / or validates transactions. In some embodiments, a portion of the script is from an unlock script and a portion of the script is from a lock script.

[0318] In the pseudocode of FIG. 29, the previous transaction, the unlock transaction, and optional inputs are injected so that the lock script can access them. A check for an exit condition may then be performed. If the smart contract has not exited, the processor extracts the previous transaction's lock script and the previous transaction's current state, which can be done using the techniques described herein. The processor then loops through the unlock transaction's outputs, extracting its lock script for each one and checking the transaction matrix in the previous transaction's lock script to determine whether it matches the transaction matrix in the lock script of the unlock transaction output being processed. If they do not match, the processor treats it as a script failure and does not validate the unlock transaction. If they match, the processor determines the next state of the state machine from the extracted current state, state transition matrix, optional input, and output index values. The processor then checks the determined next state against the next state of the unlock transaction output being processed. If they do not match, the processor treats it as a script failure, stops, and does not validate the unlock transaction. If there are any other constraints to check, they can be checked at this time. If all constraints are met, the script passes.

[0319] Worker Spawning Smart Contract The previous section described the ability to branch and clone smart contracts. This section details the ability to force a new smart contract to exist within an unlocking transaction, which can be an entirely different state machine, or an entirely different type of smart contract that is not a state machine.

[0320] An example of a constraint for enforcing a new smart contract that is a state machine is shown in Figure 30. As shown, the locking script of the output of the previous transaction constrains the output of the unlocking transaction, such that the output locking script of the unlocking transaction must equal the desired new smart contract script, or the hash of the output locking script must equal the hash of the desired new smart contract script. The new smart contract script or hash is either hard-coded in the locking script of the output of the previous transaction, or securely provided as a parameter via the unlocking script of the input of the unlocking transaction. Multiple new smart contracts in the unlocking transaction outputs can be enforced by having corresponding constraints in the locking script, as described above for each new smart contract.

[0321] As mentioned above, a new smart contract is created, which can be a state machine. This can be the same state machine as the previous transaction, or another entirely different state machine. The new state and transition matrix can be checked. This can be done separately (e.g., check the new state, then check the values ​​of the transition matrix) or in parallel.

[0322] Although not shown in Figure 30, the new smart contract may be something other than a state machine. In such cases, the next state value may or may not be required, but the new smart contract may be verified using an equality check of the script or its hash.

[0323] A new smart contract can be generated with a transition from the current state of the previous transaction and a new smart contract for the output of the unlock transaction. In the illustrated example, the first set of outputs of the unlock transaction is constrained to replicate the state transition matrix and embed the next state, and the second set of outputs is constrained to include the new smart contract. The output of the unlock transaction can be constrained to include the new lock script, and different constraints can be applied to different outputs by using multiple indexes. The set of new smart contracts can be hard-coded in the transition matrix or provided as part of the inputs.

[0324] From a state machine perspective, a state machine can instantiate a new, different state machine to run in parallel with the calling state machine. To apply this approach to state machines, the lock script for this operation may be similar to that of a fork / clone operation, but instead of each new state machine instance being checked for equality in its lock script, it may be checked for the existence of a new smart contract. The equality check can be performed over a range of different values, including the serialized set of transaction fields for the transaction, the lock script bytecode, or a hash of these.

[0325] Figure 30 illustrates the creation of a new smart contract. As shown, a state machine 3010 is implemented using a previous transaction 3020 and an unlock transaction 3030. The lock script for output Vout[0] of the previous transaction 3020 constrains the unlock transaction 3030 to have at least two outputs, Vout[x] and Vout[y], each requiring that a subsequent unlock transaction have an output in a specified state (and be a separate transaction). Specifically, as shown, in order for input Vin[0] of the unlock transaction 3030 to unlock Vout[0] of the previous transaction 3020, the unlock transaction 3030 may constrain Vout[x] to be in state S4 with a transition matrix, while Vout[y] may be constrained to have a new smart contract.

[0326] In this approach, the new smart contract can be processed in parallel with the state machine. Although not explicitly shown, the new smart contract can be a second state machine. As noted above, the new smart contract does not need to be a state machine itself, in which case the resulting smart contract may not have a state value field.

[0327] As indicated by the dashed arrow in Figure 30, the input Vin[0] of the unlock transaction 3030 points to the previous transaction 3020 and that transaction's output Vout[0]. This may be in the form of the TxID of the previous transaction 3020 and an integer value set to "0" to point to the output Vout[0]. The lock script for Vout[0] contains the current state ("S3") and the state machine transition matrix, constraining Vout[x] of the unlock transaction 3030 to be the next state state machine ("S4") and Vout[y] of the unlock transaction 3030 to be a new smart contract ("NSC"), and possibly other constraints.

[0328] As an example, pseudocode for an example of a worker creation process and a process for forcing a new smart contract into existence for an unlocking transaction can be seen in Figure 31.

[0329] Smart contract merging State merging or merging can be used when two or more states need to be fused to the same next state. In some cases, state machines running in parallel may be in the same state but not fused if not required by the smart contract. For example, in the state diagram of Figure 26, it is possible for S4 and S7 to transition to S8 separately and remain two separate transactions.

[0330] 32 illustrates the merging operation of state machine 3210. In this case, unlock transaction 3230 (with inputs Vin[0] and Vin[1], and output Vout[x]) unlocks Vout[0] of both previous transaction 3220 and previous transaction 3222. Using these techniques, a smart contract can branch by instantiating a new instance of itself or by instantiating a different smart contract, and multiple smart contracts, whether identical or not, can be merged to form a single smart contract via the corresponding state machines.

[0331] Each merging unlocking transaction can have one locking script. This locking script continues the execution of a single smart contract. This can be either one of the smart contracts being merged or an entirely new smart contract. In either case, multiple checks may be performed. Each smart contract can be checked as being a valid input to the unlocking transaction. This can be done by validation using previous transactions.

[0332] 32, Vin[0] denotes the previous transaction 3220 and its output Vout[0], while Vin[1] denotes the previous transaction 3222 and its output Vout[0]. The locking scripts of both Vout[0] constrain Vout[x] of the unlocking transaction 3230 to have the next state S8 and state transition matrix. These constraints can be enforced by the locking script of the previous transaction 3222, which checks that the new smart contract is an output of the unlocking transaction.

[0333] To achieve this with concurrent state machines, a transaction can use multiple inputs, with an input for each state machine that needs to be combined. Constraints can be added to check the states of all combined independent state machines within the state machine transition matrix. If one of the combined state machines is not in a convergence-enabled state, the transaction may be rejected. To ensure the combine operation, constraints can be added to the state machine to ensure there are two unlock scripts based on the state of the unlock transaction. A check can be performed for each script to ensure it is in the correct state required for the transition. Interdependent lock constraints can also be used, as described elsewhere herein.

[0334] Figure 33 shows an example pseudocode sequence for the process of merging smart contracts in an unlocking transaction with weak dependencies. Merging involves transitioning from a set of current states (not necessarily unique states) to a shared next state. For an unlocking transaction, its set of inputs can unlock a set of locking scripts that share the constraint that the same outputs duplicate the transition matrix and populate the same next state. In the case of weak dependencies, there may be multiple state machines with the same next state for the same output.

[0335] The fusion according to Figures 32 and 33 can occur with weak dependencies. Lock scripts can include other constraints, such as interdependencies, branching, creation of new smart contracts, etc. As an example of a weak dependency, if fusion occurs by chance, lock script 1 may be a branch from state A to state X and state Y, and lock script 2 may be a normal transition from state B to state X. These two lock scripts constrain that state X happens to be included in the output of the unlock transaction.

[0336] In the pseudocode sequence of Figure 33, a processor processing a script according to that pseudocode sequence may inject the previous transaction, the unlock transaction, and optionally some input data, and check for an exit condition before proceeding. Next, the processor extracts the previous transaction lock script and the unlock transaction lock script. Next, the processor may check that the transaction matrix in the previous transaction lock script is equal to the transaction matrix in the unlock transaction lock script, and if not, abort. From there, the processor extracts the current state value of the previous transaction, determines the next state from that and from the transaction matrix and input (if used), and checks the next state to determine if it matches the next state in the unlock transaction lock script. Optionally, other constraints can be checked here.

[0337] Figure 34 shows a pseudocode sequence as an example of a process for merging smart contracts in an unlocking transaction with explicit dependencies. With explicit dependencies, there may be multiple state machines, and it is not enough that they have the same next state for the same output; they may also be unique, separate state machines. Merging according to Figures 32 and 34 can occur due to explicit dependencies. In strong constraints, the unlocking transaction may be required to point to two or more unique merging state machines.

[0338] In the pseudocode sequence of Figure 34, a processor processing a script according to the pseudocode sequence can inject the previous transaction, the unlock transaction, and optionally some input data and check for an exit condition before proceeding. Next, the processor extracts the unlock transaction lock script. Next, the processor loops through a set of input indexes to extract the corresponding previous transaction lock script, checks whether the transition matrix in the corresponding previous transaction lock script is equal to the transition matrix in the unlock transaction lock script, and aborts if not. From there, the processor extracts the current state value of the previous transaction, adds it to a list of current states, and repeats for other inputs. From the current state, and the transition matrix and input (if used), the processor determines the next state and checks the next state to determine whether it matches the next state in the unlock transaction lock script. Optionally, other constraints can be checked here.

[0339] Parallel Smart Contracts / Barriers As mentioned above, two or more smart contracts can be merged into one smart contract with weak or strong constraints. It is also useful to have two or more smart contracts that can run in parallel. This can go beyond parallelism in that there is a constraint that two parallel paths must go through a single unlock transaction. This can also be used for "barriers" within concurrent state machines, where a particular transition is not allowed to occur until another transition occurs elsewhere in the state machine.

[0340] Figure 35 illustrates parallel processing operation. In this case, unlock transaction 3530 has two inputs (Vin[0], Vin[1]), one for each of previous transaction 3520 and previous transaction 3530, and two outputs (Vout[x], Vout[y]), each for continuing separate smart contracts. Unlock transaction 3530 includes an unlock script that includes each of the smart contract's previous transactions. Additionally, a lock script for each smart contract may be required to continue its execution. With parallel smart contracts, each contract cannot be transitioned independently, but instead all contracts (defined in the lock script) must be executed in parallel.

[0341] The previous examples provided branching smart contracts, merging two smart contracts, and parallel operation of two (or more) smart contracts. These can be used in combination with parallel smart contracts. A barrier may be used when a state transition has a logical relationship with another state transition. As an example, it may require another state machine to be in a particular state, or require input data from that state machine.

[0342] To facilitate this functionality, unlock transactions can be created that contain multiple inputs and outputs. Each of the state machines required for the barrier (those that make a transition or those involved in a constraint) may be included in their own unlock script. A lock script may be used for each state machine that performs a transition. In the example shown in Figure 26, the transition from state S9 to S10 is allowed, but only if the transition from S6 to S7 occurs in parallel. For the unlock transaction, there are two unlock scripts, one for the state machine in state S6 and one for the state machine in state S9. The unlock transaction then has two lock scripts: one for the state machine that remains in S7 and one for the state machine that is currently in S10.

[0343] Figure 36 is an example pseudocode sequence for using barriers in a concurrent state machine that requires parallel transaction input / output. In this example, the script following the pseudocode sequence checks that each of the previous transactions has a lock script that is identical to the lock script in the unlocking transaction. In this example, one lock script is set to match the first previous transaction, and so on. The script following the pseudocode sequence then extracts the current state from both previous transactions, reads the inputs of both state machines, and checks the barriers set on both state transitions.

[0344] 35, various dependencies are indicated by dashed arrows and numbered circles. Dependency #1 may be that Vin[0] must reference the previous transaction 3520, dependency #2 may be that Vin[0] must reference the first output (Vout[0]) of the specified transaction (previous transaction 3520), dependency #3 may be that Vin[1] must reference the previous transaction 3522, and dependency #4 may be that Vin[1] must reference the first output (Vout[0]) of the specified transaction (previous transaction 3522). This may simply be two dependencies: that Vin[0] must reference Vout[0] of transaction 3520, and that Vin[1] must reference Vout[0] of transaction 3522.

[0345] The locking script for Vout[0] of the previous transaction 3520 imposes dependency #5, which requires Vout[x] to have state=S8 and a transition matrix of state machine 1, and dependency #6, which requires Vout[y] to have state=S8 and a transition matrix of state machine 2. The locking script for Vout[0] of the previous transaction 3522 imposes dependencies #7 and #8 in a similar manner. In some examples, instead of state machine constraints, other types of constraints on smart contracts may be used. Two (or more) previous transaction outputs may constrain two (or more) unlocking transaction outputs, providing for parallel smart contracts.

[0346] A barrier may differ from a merge. A barrier is when transitions from a set of current states (not necessarily unique states) are constrained to occur in parallel. For an unlock transaction, its set of inputs may be to unlock a set of interdependent lock scripts, all of which may apply their respective constraints to a set of outputs. Interdependent lock scripts may be requirements and sets of shared next states, but may not be required if possible. Interdependent lock scripts can be embedded in a transition matrix such that certain transitions require this interdependency.

[0347] Figure 37 shows a state diagram for a barrier / parallel smart contract use case. Suppose Alice and Bob are learning to dance and go to dance lessons. As a way to maintain the progress of the dance students, their progress is recorded using a state machine. First, there may be a state machine between grades, which contains states regarding overall dance ability for all dance types. This is represented by states S1, S3, S5, and finally S6. These grades progress sequentially until the student reaches the highest grade supported by the dance club. To progress to the next grade (e.g., S1-S3), the student may need to achieve several types of dance. Each dance type may be monitored using smaller embedded state machines (e.g., S2 and S4). In this use case, the following operations are possible:

[0348] (1) Fork and clone: ​​This is used at points S1 and S5 and can indicate the start of a new class, whereby there may be branches into multiple state machines, one for each dance type.

[0349] (2) Worker spawning. This can be used when certain dance types require more lessons or are offered different assessments than other dance types.

[0350] (3) Merge. This process can be used at points S3 and S6 when students reach a new grade. The new grade requires each student to be evaluated at the final state S4 of the embedded dance state machine.

[0351] (4) Parallel Transaction / Barrier. It can be used to constrain the state transitions in one state machine by another. In this use case, we can assume that the transitions S2 and S4 must occur in parallel, because we cannot perform one dance type in one lesson.

[0352] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. However, it will be apparent that various modifications and changes can be made thereto without departing from the scope of the invention as set forth in the appended claims. Likewise, other variations are within the scope of this disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown in the drawings and described above in detail. It is to be understood, however, that there is no intention to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the scope of the invention as defined by the appended claims.

[0353] The use of "a" and "an," as well as "the" and similar referential terms in the context of describing disclosed embodiments (particularly in the context of the claims that follow), is intended to include both the singular and the plural unless otherwise indicated or clearly contradicted. The terms "construction," "having," "include," and "includes" are intended to be open-ended terms (i.e., meaning "including, but not limited to") unless otherwise indicated. The term "connected," when referring to an unmodified physical connection, is intended to be partially or wholly contained within, attached to, or coupled to, even if there is something intervening. Recitation of ranges of values ​​in this disclosure is merely intended to serve as a shorthand method of individually referring to each individual value included within the range, as if each individual value were individually recited, unless otherwise indicated. The term "set" (e.g., "set of items") or "subset" should be construed as a non-empty collection of one or more members, unless the context otherwise indicates or contradicts; further, unless the context otherwise indicates or contradicts, the term "subset" of a corresponding set does not necessarily indicate a proper subset of the corresponding set, although a subset and a corresponding set may be equivalent.

[0354] Connective language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, or C," is understood in its general context of use to indicate that an item, term, etc. may be any non-empty subset of A, B, or C, or the set A, B, and C, unless specifically stated otherwise or clearly contradicted by context. For example, in the illustrative example of a set having three members, "at least one of A, B, and C" and "at least one of A, B, or C" refer to any of the following sets: {A}, {B}, {C}, {A}, {A, B}, {A}, {C}, {A, {B, C}}. Thus, such connective language is not generally intended to imply that a particular embodiment requires at least one of A, at least one of B, and at least one of C to each be present.

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

[0356] Any examples provided, or the use of exemplary language (e.g., "such as"), are intended merely to better illuminate embodiments of the invention and do not limit the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0357] Embodiments of the present disclosure are described, including the best mode known to the inventors for carrying out the invention. Variations of these embodiments may become apparent to those skilled in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the embodiments of the present disclosure to be practiced otherwise than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Furthermore, any combination of the above-described elements in all possible variations thereof is encompassed within the scope of the present disclosure unless otherwise indicated or clearly contradicted by context.

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

[0359] It should be noted that the above-described embodiments illustrate the present invention rather than limit it, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, reference signs placed in parentheses shall not be construed as limiting the claims. The use of "comprising", "comprises", and similar words does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "having", "comprising", "comprises" means "having", "including", "including", "consisting of". The singular form of an element does not exclude the plural form of such elements, and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. [Explanation of symbols]

[0360] 100 Blockchain Networks 102 nodes 104 transactions< / transitionmatrix> < / nextstate> < / y> < / x> < / y> < / x> < / y> < / x> < / y> < / x> < / k> < / k> < / k> < / m> < / m>

Claims

1. 1. A computer-implemented method comprising: generating a blockchain transaction at a node of a blockchain network, the blockchain transaction having a transaction output transferable by a first unlock transaction input of a first unlock transaction; inserting a first set of script elements into the blockchain transaction, the first set of script elements constraining the first unlock transaction to include a first set of unlock transaction script elements corresponding to a state machine operation; inserting a second set of script elements into the blockchain transaction, the second set of script elements constraining a second set of unlocking transaction script elements corresponding to allowed state machine state transitions including states implementable using different blockchain transactions that can be processed independently at the same time by the blockchain network; 20. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the blockchain transaction includes a first output having a first locking script and a first transaction output value, the first transaction output value includes a second output having a second locking script and a second transaction output value, and the first set of script elements is part of the first locking script.

3. 3. The computer-implemented method of claim 1, wherein the first unlocking transaction includes an unlocking script that, when executed by a transaction verifier together with a previous transaction output locking script, satisfies a predetermined validation test, causing the node to store at least values ​​representing fields of the unlocking transaction in memory accessible by the transaction verifier when executing the previous transaction output locking script.

4. the first unlock transaction includes an input and an output, the input referencing a previous transaction output, the first unlock transaction including an unlock script, the unlock script satisfying a predetermined validation test when executed by a transaction verifier together with a previous transaction lock script of the previous transaction output; The unlock script causes the node to store in a memory at least values ​​representing fields of the first unlock transaction, the memory storing: Run the lock script, inserting data corresponding to additional state machines as the unlock transaction inputs and / or the unlock transaction outputs into the first unlock transaction based on the allowed state machine state transitions, such that the number of unlock transaction inputs and / or unlock transaction outputs used in the first unlock transaction is sufficient for the number of state machine transitions; The computer-implemented method of any of claims 1 to 3, wherein the transaction verifier is accessible at the time.

5. The allowed state machine state transitions are: generating a first transaction output corresponding to a first subsequent state for the first unlock transaction; inserting a first transaction output value of the first transaction output into the first unlock transaction sufficient to make the first transaction output an input of a first subsequent transaction that references the first transaction output; inserting a third set of script elements into the first transaction output of the first unlock transaction, the third set of script elements being a portion of a first lock script that constrains the first subsequent transaction to have the first subsequent state; generating a second transaction output for the first unlock transaction, the second transaction output corresponding to a second subsequent state; inserting a second transaction output value of the second transaction output into the first unlock transaction sufficient to make the second transaction output an input of a second subsequent transaction that references the second transaction output; inserting a fourth set of script elements into the second transaction output, the fourth set of script elements being a portion of a second locking script that constrains the second subsequent transaction to have the second subsequent state; inserting a fifth set of script elements into the first transaction output or the second transaction output, the fifth set of script elements being a portion of the first locking script or the second locking script that imposes a constraint that the first subsequent transaction and the second subsequent transaction are different; 5. The computer-implemented method of claim 1, wherein the method comprises branching transitions from one initial state to two subsequent states.

6. 6. The computer-implemented method of claim 5, wherein the first locking script constrains the first subsequent transaction to have a first state, and the second locking script constrains the second subsequent transaction to have a second state.

7. The computer-implemented method of claim 5 or 6, wherein the first unlocking transaction includes three or more transaction output values ​​corresponding to three or more branching states.

8. The computer-implemented method of any of claims 5 to 7, wherein the first unlocking transaction includes three or more transaction input values ​​corresponding to a fusion of three or more states.

9. The computer-implemented method of any one of claims 5 to 8, wherein the first locking script and the second locking script constrain the first subsequent transaction and the second subsequent transaction to have the same state.

10. 10. The computer-implemented method of claim 1, wherein the first unlocking transaction includes N transaction input values ​​and N transaction output values, where N is 1, 2, 3, or more.

11. The allowed state machine state transitions are: inserting a first transaction input in a first pre-stage state into the first unlock transaction; inserting a second transaction input in a second pre-stage state into the first unlock transaction; inserting a fusion state, which is an allowed transition from the first predecessor state and the second predecessor state according to a state transition matrix, into the first unlock transaction; The computer-implemented method of any of claims 1 to 10, comprising a fusion transition from two initial states to one subsequent state by:

12. The allowed state machine state transitions are: inserting into the first transaction input a first reference to a first previous transaction having the first predecessor state; inserting into the second transaction input a second reference to a second previous transaction having the second predecessor state; inserting a first transaction output of the fused state into the first unlock transaction, the state transition matrix being available for the first previous transaction and the second previous transaction; The computer-implemented method of claim 11 , wherein the first transaction input and / or the second transaction input are hard-coded by:

13. The allowed state machine state transitions are: inserting a first transaction input in a first pre-stage state into the first unlock transaction; inserting a second transaction input in a second pre-stage state into the first unlock transaction; inserting into the first transaction input a first reference to a first previous transaction having the first predecessor state; inserting into the second transaction input a second reference to a second previous transaction having the second predecessor state; inserting a first transaction output in a first subsequent state into the first unlocked transaction; inserting a third set of script elements into the first transaction output, the third set of script elements being a portion of a first locking script that constrains the first subsequent transaction to have the first subsequent state; inserting a second transaction output in a second later state into the first unlock transaction; inserting a fourth set of script elements into the second transaction output, the fourth set of script elements being a portion of a second lock script that constrains the second subsequent transaction to have the second subsequent state; 10. The computer-implemented method of claim 5, wherein the method comprises parallel operations from N initial states to N subsequent states, where N is 2 or greater.

14. 1. A system comprising: a processor; a memory containing executable instructions that, upon execution by the processor, cause the system to perform the computer-implemented method of any one of claims 1 to 13; A system including:

15. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by a processor of a computer system, cause the computer system to perform at least the computer-implemented method of any one of claims 1 to 13.

Images