Output constraints for unlocking transactions in blockchain

Abstract

A trustless deterministic state machine can be implemented using a blockchain infrastructure, and the state machine can run concurrently on multiple blockchain transactions. A first set of constraints on a first transaction output is determined. A second set of constraints on a second transaction output is determined. An initial transaction is created to include at least one initial locking script and at least one redeemable value, the initial locking script including the first set of constraints and the second set of constraints, wherein unlocking the at least one redeemable value is dependent on: the first set of constraints being at least partially satisfied by verifying that the unlocking transaction includes the first transaction output; and the second set of constraints being at least partially satisfied by verifying that the unlocking transaction includes the second transaction output. The initial transaction is verified at a node of a blockchain network.

Description

Technical Field

[0001] The present invention generally relates to a computer-implemented method for processing blockchain transactions, and more particularly to implementing state machines within the fabric of blockchain transaction processing, including trustless, deterministic, and concurrent state machines. The present invention also utilizes cryptographic and mathematical techniques to enhance the security associated with electronic transfers made over a blockchain network. The present invention is particularly suitable for, but not limited to, use in methods and apparatus for processing and transacting in smart contract transactions and implementing state machines using such smart contract transactions. Background Art

[0002] As used herein, the term "blockchain" may refer to any of several types of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations. It should be noted that alternative blockchain implementations and protocols (including non-commercial applications) also fall within the scope of the present invention.

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

[0004] The blockchain ledger may be decentralized in that there is no single blockchain node or entity that decides when to modify the ledger. Instead, each blockchain node may be programmed with knowledge of the blockchain protocol rules and may verify that the blockchain ledger and the actions of other blockchain nodes are consistent with those rules. The term "blockchain" may refer to the fact that the blockchain ledger includes a series of chained blocks, each chained block represented as a data structure in a computer memory, readable by a computer process and transferable as a data transmission. A block may include one or more transactions, also represented as a data structure in a computer memory, readable by a computer process and transferable as a data transmission. These blocks may be chained because each new block formally added to the blockchain contains an immutable reference to the immediately previous block, which may contain an immutable reference to its immediately previous block, and so on.

[0005] One of the rules of a blockchain protocol may be that once a block is added to the blockchain, it cannot be changed; i.e., it is immutable, and the only possible modification of the blockchain ledger may be the addition of a new block. Since blockchain nodes are usually programmable with it, they do not modify blocks in their copy of the blockchain ledger, but only add blocks, and even then only after running a validation process on the proposed block to ensure that it complies with the blockchain protocol. Since these 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 may propagate that data object in a peer-to-peer fashion to other blockchain nodes to which it can connect. Some blockchain nodes collect one or more transactions, form a data structure corresponding to a block, perform some computation to verify the transactions placed in the block, solve a puzzle, place the solution to the puzzle in a data structure, and attempt to propagate the block to other blockchain nodes. The puzzle may be in the form of a nontrivial computation that is specific to the transaction's data and the current state of the blockchain ledger, such as the number of blocks in the ledger and the last block added.

[0007] By making puzzles transaction-dependent, Rogue Blockchain Node

[0008] It may not be possible to propagate pre-composed blocks. A rogue blockchain node may not be able to simply inject a block into the blockchain network by solving a non-trivial puzzle, but may require the blockchain node to perform some significant computational task to prove that it made the effort (in effect, showing the solution to the puzzle is "proof of work"). Preferably, in the blockchain protocol, the proof of work is non-trivial, but it is easy to verify that the puzzle has been solved and the work has been done. This means that other blockchain nodes do not necessarily have to trust the blockchain node that proposed adding a new block of data to the ledger. If verified by another blockchain node, the blockchain node can add the new block to the end of its copy of the blockchain ledger and propagate the new block to the other blockchain nodes. When the other blockchain nodes perform the same verification, they can also conclude that the block is valid and should be added to the blockchain ledger, so they can add the block to their copy of the blockchain ledger. If the blockchain node determines that the proposed new block is invalid, it may not add it to its copy of the blockchain ledger, and it may not propagate it. Because the validity of the blockchain is based on consensus, if the majority of nodes agree that the transaction is valid, then the transaction can be considered valid.

[0009] Blockchain systems can operate so that node owners and operators do not have to trust other node owners and operators. Conversely, the protocol can make it computationally infeasible to perform certain operations not permitted by the protocol, such as modifying an earlier block, proposing a new block without a corresponding proof of work, or including invalid transactions. When it is computationally infeasible to perform operations not permitted by the blockchain protocol in a way that other nodes do not notice, specific trust may not be required.

[0010] In order for a transaction to be included in a block written to the blockchain, (1) a mining blockchain node will validate the transaction, (2) a mining blockchain node will attempt to propagate a block containing the transaction, and (3) other nodes will verify the validity of the block and the validity of the transactions in the block. Because mining blockchain nodes will be programmed or configured with these rules in mind, mining blockchain nodes are unlikely to include unverifiable transactions in blocks because such blocks would not be accepted by other nodes and the mining node would not gain any benefit. For some blockchain systems, one of the benefits of such mining is that, if a block is accepted, it allows the block to include an "assignment" transaction in which a specified amount of value is assigned to the operator of the node without a corresponding reduction in value from other entities.

[0011] 4 / 76

[0012] Transactions in a blockchain network contain various data elements, such as transaction value, transaction time, and / or other data elements. In a decentralized distributed ledger system, the ledger is public, so anyone can view the ledger and transactions. In a blockchain ledger, there may be a genesis transaction that starts the blockchain and attributes certain units of value to that genesis transaction. In the examples in this article, other variations of the units of value are possible.

[0013] Transactions other than genesis and allocation transactions involve "unlocking" the value of one or more existing transactions in the blockchain ledger, and when such transactions are added to the blockchain ledger, it can in turn be transferred. Each untransferred transaction specifies in a public manner the requirements necessary to unlock the value of that transaction.

[0014] A simple requirement might be "You must first prove that you are Alice, then you can unlock this". Alice may then create a new transaction to "unlock" the value of that transaction, where Alice's new transaction proves that it came from Alice and has a pointer to the previous transaction. The transaction value exists in the assignment transaction, but the assignment transaction does not "unlock" the previous transaction. Of course, for Alice's transaction to be accepted by the blockchain network, it cannot refer to a transaction that has already been transferred, but must actually prove that Alice created the transaction.

[0015] According to the blockchain protocol, and therefore according to the agreement of the blockchain nodes, a transaction is invalid if it points to a previous transaction output that has already been transferred; that is, the ledger contains valid existing transaction inputs pointing to the previous transaction output. In order to prevent any interloper from creating new transaction inputs to "unlock"

[0016] The value represented by the previous unspent transaction output (UTXO), each transaction output includes data representing the claim to any claimant who made such a transaction, and since UTXO can be immutable, this data cannot be changed. Of course, transfer transactions can also be immutable.

[0017] In the example above, Alice may have created an unlocking transaction so that the value in the previous transaction that only she could unlock can be transferred to Bob, i.e., there will now be a new untransferred transaction that only Bob can unlock and therefore unlocks. The unlocking transaction created by Alice may include data corresponding to the following requirement: "If they can provide enough information to prove that they know Bob's

[0018] If Bao has the private key, then anyone can freely point to the transaction, thereby unlocking all its value." Assuming Bao 5 / 76

[0019] If Bob is careful, then Bob will be the only one who can create a valid transaction that unlocks that transaction. In effect, Bob owns the value and is the only one who can unlock it. Note that this does not require Bob to trust any of the operators of the blockchain nodes, nor does it require him to trust any other party who has the ability to create transactions. All Bob needs to trust is that a rogue party cannot completely take over a large portion of the blockchain nodes.

[0020] In certain cases, a transaction completely unlocks a previous untransferred transaction, and that one transaction can be completely transferred by a later transaction, or not transferred at all. In general, 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 a redeemable value), and each output has a redeemable value (which remains untransferred until transferred / referenced by an input of a future transaction). The output of a transaction is a redeemable unit of the transaction because it is completely transferred or not transferred at all. In some examples described herein, transactions are referred to as "transferred", and it should be understood that in the case of a transaction with multiple transaction outputs, the description may cover situations where less than all transaction outputs may be transferred. Relative to unlocking transaction outputs, a description of "Unlocking A Transaction" may cover situations where the output of a transaction with only one output is transferred.

[0021] When 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 can be considered untransferred. Each output is either transferred by the inputs of subsequent transactions or remains untransferred. If an input of a transaction attempts to unlock an output of a previous transaction after the output of the previous transaction has already been transferred, the blockchain node rejects it as an invalid transaction.

[0022] In the case where one party, Alice, controls a UTXO with value X and only wants to unlock a portion of that transaction output (Y), Alice can specify a new transaction with multiple outputs, one with value Y (which can only be transferred by Bob), and another with value XY (which can only be transferred by Alice). In effect, the original transaction output is transferred in full, but there are new transaction outputs that "make the change" for Alice's transaction.

[0023] The number of inputs of a transaction and the number of outputs of that transaction do not have to be the same. However, for a transaction to be valid, the sum of the values ​​specified in the outputs of the current transaction should not exceed the previous value that the inputs of the current transaction can transfer.

[0024] The sum of the values ​​of the transaction outputs, and in some cases (with some exceptions) will be smaller.

[0025] For genesis and allocation transactions, the sum of output values ​​can be greater than the sum of input values, or no input is required at all, but for regular transactions, if the sum of its output values ​​exceeds the sum of its input values, the transaction will be invalid. For some transactions, the sum of its output values ​​may be less than the sum of its input values.

[0026] This is the Coinbase Transaction that 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 block (i.e. the sum of the differences of all inputs and outputs of all included transactions), and an allocation for creating a new block.

[0027] Each output of a transaction includes constraints that must be satisfied in order to unlock the value of that output. In some blockchain protocols, the constraints are embedded in a "locking script" that specifies the data and script commands that define those constraints. The locking script acts as an encumbrance on the value represented in the transaction output, because another participant cannot "unlock" the value represented in the transaction output unless they can "unlock" the locking script of that transaction output.

[0028] Each input of an unlocking transaction unlocks the output of the previous transaction. The "unlocking script" of the unlocking transaction input determines whether the unlocking transaction unlocks the output of the previous transaction. Therefore, a valid transaction specifies at least one input, and each input of a valid unlocking transaction includes a pointer to the previous transaction output (the transaction being transferred) and an unlocking script that "unlocks" the locking script. Blockchain nodes operating according to the corresponding blockchain protocol can execute the locking script and the unlocking script together to verify the transaction input. In a specific system, the script is stack-based, and the verifying blockchain node can start with an empty stack, execute the unlocking script, which can leave the data object on the stack, and then execute the locking script, which can use the data object on the stack.

[0029] When a validating blockchain node combines a locking script and an unlocking script and executes the combination, the result after execution can be either TRUE or FALSE. In some cases, the execution of a script ends with a false result before the script is fully executed. For example, suppose that for a given script execution, there are two values ​​that are always equal in a valid script execution, regardless of what else happens in the script. If, partway through the execution of that script, a comparison is made between those two values, and they are not equal, then the execution of the script stops immediately after that comparison and returns a false result. The rest of the script does not need to be executed.

[0030] 7 / 76

[0031] If the validating blockchain node combines the locking script and the unlocking script, executes the combination, and the result is true (i.e., the unlocking script contains everything needed to unlock the transaction output), the validating blockchain node will verify the transaction as valid (assuming other requirements are met, such as correct timestamp, correct 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 can propagate the transaction. Other blockchain nodes can perform the same calculations to conclude that the transaction is valid.

[0032] In this way, a valid transaction with inputs that only point to a UTXO and with an unlocking script that unlocks the UTXO can propagate and eventually become part of a block that eventually becomes part of the ledger.

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

[0034] Once a transaction is valid and accepted by the blockchain, its contents cannot be changed. This means that the locking script is fixed when the transaction is created. However, the unlocking script does not have to be fixed at that time, because the unlocking script is included in the later unlocking transaction and does not need to be created before the later unlocking transaction is created.

[0035] In a typical case, a verified unlocking script cannot be created by just anyone, but only by a party that is authorized to unlock the previous transaction output. As in the example above, the locking script might be "If anyone can provide enough information to prove that they know Bob's private key, then anyone can freely point to this transaction output, thereby unlocking all the value it states", and the unlocking script might be of the form

[0036] "Bob has signed a transaction with his private key, and the result is: ABCCC". Then a validating blockchain node can process these two statements and conclude that they are either true or false. This process works well when it is easy to verify that ABCCC is a valid signature, it is easy for Bob (or someone else who knows Bob's private key) to generate such a signature, and it is difficult for others to generate a valid signature without knowing Bob's private key. Therefore, value can be transferred in a trustless system. The initiator of the transaction that Bob is about to unlock does not need to trust the system or trust Bob, because it is cryptographically difficult to form a valid and verifiable result that is unanimously accepted by the blockchain nodes without first knowing Bob's private key.

[0037] The blockchain nodes can easily verify that Bob signed the transaction, and verify that the signature is the only requirement of the locking script. Of course, there may be rogue nodes that do not verify where other nodes verify, and may verify where other nodes do not verify, but as long as the rogue nodes cannot overwhelm the performance of the blockchain network 8 / 76

[0038] Good nodes, rogue nodes cannot push invalid transactions or prevent the propagation or mining of valid transactions.

[0039] If a node is executing the unlocking script of a transaction input and the corresponding locking script of the previous transaction input, and each script evaluates to true, and other validation conditions are met (if applicable), then the transaction is valid as far as that node is concerned. The node then propagates the validated transaction to other network nodes, which may choose to include the transaction in a block. Therefore, in order for a transaction to be written to the blockchain, the transaction must (1) be validated by the node that received the transaction, (2) be relayed (but only if the transaction is validated) to other nodes in the network, (3) be added to a new block that is constructed, (4) be propagated as part of a proposed block, and (5) be accepted by consensus of the nodes as an addition to the public ledger of past transactions.

[0040] A transaction is considered confirmed when a sufficient number of blocks are added to the blockchain to make the transaction effectively irreversible. Since transactions are immutable, the blockchain protocol can prevent unilateral reversal of transactions. Of course, if Alice transfers value X to Bob, and Alice wants that value X back, she can get it if Bob agrees, in which case the Alice-to-Bob-for-X transaction is not reversed or canceled, but Bob initiates a new transaction, namely Bob-to-Alice-for-X.

[0041] Once a transaction is included in a block, the transaction is considered immutable, and once a block is committed to the blockchain, the block is considered immutable. There may be a short period of time when a fork in the blockchain occurs and there is some ability to roll back the blockchain, but generally speaking, the longer the time that has passed, the less likely any rollback will be. In this article, transactions and blocks are assumed to be immutable after they have been fully committed to the blockchain unless otherwise stated.

[0042] One way to ensure immutability is to use cryptographic techniques. For example, there are cryptographic operations (such as hashing and digital signatures) that take as their input some sequence of data and provide an output sequence of data that corresponds in some way to that sequence of input data. The operation 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 a block), it is computationally infeasible or impossible to find a different cryptographic input that results in the same cryptographic output using available computational resources.

[0043] Yes. Therefore, the verifier can assume that if the encrypted input and the encrypted output are the same, then the encrypted input is

[0044] The input is used to produce the encrypted output, rather than some other modified encrypted input.

[0045] In a blockchain network that does not require every node to trust each other, transactions can be verified, blocks can be validated, and unverifiable transactions and blocks can be ignored and not used, transactions and blocks can be considered to be effectively immutable, which may be a result of the following assumption: if a hash or digital signature correctly corresponds to a transaction or block, then the transaction or block has not been modified from its original contents.

[0046] Some blockchain nodes may store the entire ledger, while others may store only unspent transaction outputs (UTXOs). A UTXO corresponds to a redeemable value, and preferably each UTXO has a locking script for which no one other than the "owner" of the value can easily generate a verifiable unlocking script. Of course, this is not a requirement, but it is contemplated that any UTXO for which anyone can easily generate a verifiable unlocking script can be quickly transferred in a transaction that transfers its value to another UTXO that can only be redeemed by the first person to notice it. Thus, a blockchain can be used to transfer control of a digital asset from one participant of a blockchain system to another, and a record of the transaction, including the transferred transaction outputs and UTXOs, can be recorded in a public, immutable ledger, thereby facilitating verification of the flow of digital assets and preventing double unlocking of those digital assets.

[0047] In an embodiment, a "digital asset" refers to binary data associated with a right to use. As used herein, a "digital asset" may refer to one or more digital assets. For example, a transaction may have multiple inputs, and each of these inputs may represent a different digital asset. In this example, the digital asset whose control is transferred may be a collection of multiple digital assets, which is itself a digital asset. Similarly, a transaction may subdivide and / or combine multiple inputs to produce one or more outputs, such that, for example, the number of inputs and the number of outputs may be different.

[0048] In embodiments, tokens represent shares of an asset (e.g., shares of a company), and a single transaction involves multiple types of tokens (e.g., involving shares of one or more different companies). In some embodiments, the digital asset is untokenized, such that, for example, there is no identified identifier for the digital asset on the blockchain, but control of the digital asset is demonstrated by the ability to generate valid transactions recorded on the blockchain. However, it is noted that some blockchain implementations may use tokenized digital assets, so that, for example, information recorded on the blockchain can be used to unambiguously identify the digital asset. It is contemplated that in embodiments, the digital asset may be used additionally or alternatively in other contexts. Note 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 and do not necessarily involve the transfer of digital assets.

[0049] Transactions contain locking and unlocking scripts, which can form computational objects. Once submitted to the blockchain, transactions may become immutable, a feature that may have uses beyond just immutable transfers of control over digital assets. In addition to transferring value, immutable transactions can be used to implement other operations, such as notarized records of events, implementation of smart contracts (where the rights and obligations of the parties can be encoded in the transaction), and transfer of value according to the terms of the smart contract, in accordance with the blockchain protocol.

[0050] The script is written using a stack-based scripting language, but other methods 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 (e.g., part of a blockchain node) stores data on a first-in, last-out data structure called a stack. The processor can push values ​​to the top of the stack or pop values ​​from the top of the stack. Various operations performed on the stack may result in one or more values ​​being pushed or popped from the top of the stack, performing operations on them, and changing the order of elements on the stack (which may be equivalent to two pop operations and two pushes, the first push being the first item popped). For example, an OP_EQUAL operation may pop the first two items from the stack, compare them, and push the result (e.g., 1 if equal, 0 if not equal) to the top of the stack. Other operations performed on the stack (e.g., OP_PICK) may allow items to be selected from locations other than the top of the stack. In some scripting languages ​​used in some embodiments, there may be at least two stacks: a main stack and a backup stack. Some operations of a scripting language can move items from the top of one stack to the top of another stack. For example, executing an OP_TOALTSTACK operation causes the processor to move a value from the top of the primary stack to the top of an alternate stack. It should be noted that in some cases, a stack-based scripting language may not be limited to operating in a strict Last-in-First-out (LIFO) manner. For example, a stack-based scripting language may support operations that copy or move the nth item in a stack to the top (e.g., OP_PICK and OP_ROLL, respectively). Scripts written in a stack-based scripting language can be pushed onto a logical stack, which can be implemented using any suitable data structure (e.g., a vector, a list, or a stack).

[0051] With scripts included in transactions, smart contracts can be implemented where the terms of the contract are encoded into the script. An example could be "If Bob has paid Carol X, and Dave has granted permission for the transaction, then Alice will pay Bob half of X", and this can be encoded as part of a locking script that evaluates to true only if (among other conditions) there is a prior transaction in which Bob pays Carol and a prior transaction in which Dave encodes his permission. As used herein, a "prior transaction" can refer to any transaction that has been added to the blockchain, not necessarily the previous transaction with an output unlocked by an unlocking transaction. In practice, a smart contract can represent a machine-executable program that includes rules that define inputs to produce results, and actions can then be performed based on those results.

[0052] In addition to value transfers, transactions may transfer other objects of value or owned interests. For example, a transaction may include data corresponding to the following assertion: "The person who can unlock this transaction is also the legal owner of the house and land at 123 Marley Circle". Owned interests may be obfuscated in the public record, with the same effect. For example, a transaction may include data corresponding to the following assertion: "The person who can unlock this transaction is also the legal owner of certain property held in trust under Trust No. 12345 held at Central Trust Bank". This is referred to as a token in this article, which represents and enables the transfer of a real-world entity through a blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Therefore, tokens can be used as identifiers that allow real-world items to be referenced from the blockchain.

[0053] In some embodiments, the interaction with a specific entity is encoded at a specific step in the smart contract, and the smart contract can also automatically self-executing and self-enforced. In some examples, self-executing refers to the effectiveness of the smart contract, which executes the smart contract to achieve the transfer of UTXO. Note that in such examples, "any entity" that can unlock UTXO refers to an entity that can create an unlocking script without proving knowledge of certain secrets. In other words, the unlocking transaction can be verified without verifying whether the data source has access to the encrypted secret (e.g., private asymmetric key, symmetric key, etc.). In addition, in such examples, self-enforcement occurs because the verification node of the blockchain network verifies the unlocking transaction according to the constraints of the smart contract. In some examples, "unlocking" UTXO refers to creating an unlocking transaction output that references UTXO and acts as a valid execution. The side effect of unlocking such a transaction output is that the blockchain network can process the locking script and the unlocking script to verify the new transaction, i.e., the unlocking transaction. If valid, the previous transaction output is considered to have been transferred. By including a certain value in a transaction output and making it so that anyone can unlock that output, parties have a reason to create such unlocking transactions, and therefore it is very likely that the steps of the smart contract will be executed, if not by the participants of the smart contract, then by someone else operating a blockchain node.

[0054] The scripts that form the locking and unlocking scripts recorded as part of a transaction may be immutable, so the locking script cannot generally be modified or reference parts of future transactions, as these may not be known at the time the transaction was pinned. The unlocking script of a transaction input may refer to parts of a previous transaction output pointed to by a transaction input on the blockchain or a previous transaction other than the previous one. This may limit how the transaction can be used.

[0055] It is desirable to provide additional functionality and improved methods and systems using blockchain technology in one or more of these aspects. Thus, according to the present invention, there is provided a system and / or method as defined in the appended claims. Summary of the invention

[0056] In various embodiments of a computer-implemented method, the method includes: determining a first set of constraints on a first spending transaction output; determining a second set of constraints on a second spending transaction output; creating an initial transaction to include: at least one initial locking script, the script including the first set of constraints and the second set of constraints; and at least one spendable value, wherein spending the at least one spendable value is contingent upon: the first set of constraints being satisfied at least in part by verifying that the spending transaction includes the first spending transaction output; and the second set of constraints being satisfied at least in part by verifying that the spending transaction includes the second spending transaction output; and causing the initial transaction to be verified at a node of a blockchain network.

[0057] The locking script in the first spending transaction output can be a copy of the locking script in the second spending transaction output.

[0058] The locking script in the first spending transaction output can be different from the locking script in the second spending transaction output.

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

[0060] The execution of the at least one locking initialization script may select at least one portion from a plurality of portions of the at least one initial locking script.

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

[0062] The data may have an index value. Under the condition that the index value is a first index value, execution of the at least one initial locking script may determine whether a first set of constraints are satisfied. Under the condition that the index value is a second index value, execution of the at least one initial locking script may determine whether a second set of constraints are satisfied.

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

[0064] At least one initial locking script may include constraints on the data source.

[0065] The above method may also include determining a spendable value of the first spending transaction output.

[0066] The initial transaction can encode a contract with multiple states.

[0067] A spend transaction may include multiple input values ​​corresponding to multiple states.

[0068] The first constraint set may constrain the first spending transaction output to have a first state. The second constraint set constrains the second spending transaction output to have a second state.

[0069] It is also desirable to provide a computer-implemented method comprising: determining a spending transaction constraint that constrains a spending transaction to include a spending transaction input that references a previous transaction output; creating a spendable transaction comprising: a spendable transaction output that includes a spendable amount; and a spendable transaction locking script that includes the spending transaction constraint, wherein spending the spendable amount is contingent upon execution of at least one unlocking script of the spending transaction satisfying the spending transaction constraint; and causing the spendable transaction to be verified at a node of a blockchain network.

[0070] Spending transaction constraints can also constrain spending transaction inputs to include specific hash values.

[0071] A specific hash value can encode an identifier that references a previous transaction output.

[0072] Spending transaction constraints may also constrain the spending transaction's locking script to include a set of script elements copied from the spendable transaction's locking script.

[0073] Spendable transactions can encode contracts with multiple states.

[0074] The above method may also include determining a spendable value of an output of the spending transaction.

[0075] The spending transaction constraint may include a specific locking script element from a previous transaction output. As a result of the spending transaction input including the specific locking script element, the execution of at least one unlocking script may satisfy the spending transaction constraint.

[0076] Certain locking script elements may encode a cryptographic key for a particular entity.

[0077] The spending transaction constraint may be a first spending transaction constraint; and the method may further include: determining a second spending transaction constraint to further constrain the spending transaction; and creating a second spendable transaction, the transaction comprising: a second spendable amount; and a second spendable transaction locking script comprising the second spending transaction constraint, wherein spending the second spendable amount may also depend on the execution of at least one unlocking script that satisfies the second spending transaction constraint.

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

[0079] At least a portion of the first spendable transaction locking script may include a cryptographic key associated with the first entity.At least a portion of the second spendable transaction locking script may include a cryptographic key associated with a second entity different from the first entity.

[0080] Spending transaction constraints can also constrain spending transactions to constrain the output of spending transactions.

[0081] The spending transaction constraints may encode another contract different from the above. The spendable amount may depend on another contract being executed on the output of the spending transaction.

[0082] It is also desirable to provide a computer-implemented method comprising creating a blockchain transaction encoding: a state machine in a first state and having a permitted set of state transitions; and a set of script elements to be executed such that a spending transaction: encodes the state machine according to the permitted set of state transitions; and complies with restrictions on inputs to the spending transaction or complies with restrictions on outputs of the spending transaction; and causes the blockchain transaction to be verified by a node in a blockchain network.

[0083] The set of permitted state transitions may include state transitions that can be implemented independently and simultaneously in different blockchain transactions.

[0084] The set of script elements may cause a spending transaction to conform to restrictions on outputs of the spending transaction. The restrictions on outputs may require: a first output of the spending transaction to indicate a state corresponding to the first output that conforms to a permitted set of state transitions; and a second output of the spending transaction to indicate a state corresponding to a second output that conforms to the permitted set of state transitions.

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

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

[0087] The set of script elements can make the spending transaction conform to restrictions on the inputs of the spending transaction. Restrictions on the inputs may require the inputs of the spending transaction to indicate another state machine encoded in another blockchain transaction.

[0088] Restrictions on an input may require that the input reference a state machine in a first state and reference another state machine in another state different from the first state.

[0089] 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 a second state may be within the set of allowed state transitions.

[0090] The set of script elements can make the spend transaction conform to constraints on the inputs of the spend transaction. The constraints on the inputs can state a set of conditions for advancing a state machine. The set of conditions for advancing a state machine can depend on the state of another state machine.

[0091] Another state machine may be encoded in another blockchain transaction. Another transaction may encode a set of conditions for advancing another state machine. Other sets of conditions for advancing another state machine may depend on the state of the state machine.

[0092] The script element set can make the spending transaction conform to the restrictions on the outputs of the spending transaction. The restrictions on the outputs may require the spending transaction to incorporate the smart contract element set into the output.

[0093] A collection of elements of a smart contract can be obtained from another blockchain transaction.

[0094] A collection of script elements can make a spending transaction conform to restrictions on spending transaction inputs and restrictions on spending transaction outputs.

[0095] It is also desirable to provide a computer-implemented method, the method comprising: creating a blockchain transaction at a node in a blockchain network having a transaction output that can be spent by a first spending transaction input of a first spending transaction; inserting a first set of script elements constraining the first spending transaction into the blockchain transaction to include a first set of spending transaction script elements corresponding to operations of a state machine; and inserting a second set of script elements into the blockchain transaction, the second set of script elements constraining a second set of spending transaction script elements, the second set of spending transaction script elements corresponding to permitted state machine state transitions, the state machine state transitions including states that can be implemented using different blockchain transactions, the transactions being processed by the blockchain network simultaneously but independently. The blockchain transaction may include a first output having a first locking script, and the first transaction output value may include a second output having a second locking script and a second transaction output value, wherein the first set of script elements is part of the first locking script.

[0096] A spending transaction may include an unlocking script that, when executed by a transaction validator using a previous transaction output locking script, will satisfy a predetermined validation test and will cause a node, when executing the previous transaction output locking script, to store at least values ​​of fields representing the spending transaction in a memory accessible to the transaction validator, insert a first set of script elements into the spending transaction, wherein the first set of script elements forms part of a spending transaction locking script for a first output of the spending transaction and is consistent with the requirements specified by the previous transaction locking script, and wherein the first set of script elements corresponds to operations of a state machine, and insert a second set of script elements into the spending transaction, wherein the second set of script elements forms part of a spending transaction locking script, is consistent with the requirements specified by the previous transaction locking script, and corresponds to a permitted state machine state transition, the state machine state transition comprising states that may be achieved using different blockchain transactions that may be processed concurrently but independently by the blockchain network.

[0097] The spending transaction may include an input and an output, wherein the input references a previous transaction output, and wherein the spending transaction includes an unlocking script that, when executed by a transaction validator using a previous transaction locking script for the previous transaction output, will satisfy a predetermined verification test, wherein the unlocking script causes a node to store at least values ​​representing fields of the spending transaction in a memory accessible to the transaction validator when executing the locking script, and to insert data corresponding to an additional state machine into the spending transaction as a spending transaction input and / or a spending transaction output based on a permitted state machine state transition, such that the number of spending transaction inputs and / or spending transaction outputs used in the spending transaction is sufficient for multiple state machine transitions.

[0098] The permitted state machine state transition may include a forking transition from an initial state to two subsequent states by creating a first transaction output for a spending transaction corresponding to a first subsequent state, inserting in the spending transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to become an input to a first subsequent transaction that references the first transaction output, inserting in the first transaction output of the spending transaction a third set of script elements, wherein the third set of script elements is part of a first locking script, the first locking script constraining the first subsequent transaction to assume the first subsequent state, creating a second transaction output for the spending transaction corresponding to a second subsequent state, inserting in the spending transaction a second transaction output value of the second transaction output sufficient to cause the second transaction output to become an input to a second subsequent transaction that references the second transaction output, inserting in the second transaction output a fourth set of script elements, wherein the fourth set of script elements is part of a second locking script constraint, the second locking script constraining the second subsequent transaction to assume the second subsequent state, and inserting in the first transaction output or the second transaction output a fifth set of script elements, wherein the fifth set of script elements is part of the first locking script or the second locking script that imposes different constraints on the first subsequent transaction and the second subsequent transaction.

[0099] The first locking script may constrain the first subsequent transaction to have a first state, and the second locking script may constrain the second subsequent transaction to have a second state. A spending transaction may include three or more transaction output values ​​corresponding to the forks of three or more states. A spending transaction may include three or more transaction input values ​​corresponding to the merge of three or more states. The first locking script and the second locking script may constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0100] Typically, a spending transaction may include N transaction input values ​​and N transaction output values, where N is 1, 2, 3, or more.

[0101] The permitted state machine state transitions may include a merged transition from two initial states to a subsequent state by inserting a first transaction input for a first previous state in a spend transaction, inserting a second transaction input for a second previous state in the spend transaction, and inserting a merged state in the spend transaction that is a permitted transition from the first previous state and the second previous state according to the state transition matrix.

[0102] Permitted state machine state transitions may 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 in the first transaction input, inserting a second reference to a second previous transaction having a second previous state in the second transaction input, and inserting a first transaction output for merging states in the spending transaction, wherein a state transition matrix is ​​available for the first previous transaction and the second previous transaction.

[0103] The permitted state machine state transitions may include parallel operations from a number N (N is two or more) of initial states to a number N of subsequent states by inserting a first transaction input for a first previous state in a spending transaction, inserting a second transaction input for a second previous state in the spending transaction, inserting a first reference to a first previous transaction having the first previous state in the first transaction input, inserting a second reference to a second previous transaction having the second previous state in the second transaction input, inserting a first transaction output for the first subsequent state in the spending transaction, inserting a third set of script elements in the first transaction output, wherein the third set of script elements is part of a first locking script that constrains the first subsequent transaction to present the first subsequent state, inserting a second transaction output for the second subsequent state in the spending transaction, and inserting a fourth set of script elements in the second transaction output, wherein the fourth set of script elements is part of a second locking script that constrains the second subsequent transaction to present the second subsequent state.

[0104] The operations of the state machine can be encoded for smart contracts implemented using the blockchain.

[0105] Transactions may be split using arbitrary constraints. The method may include creating a first transaction at a node in a blockchain network, wherein the first transaction includes a first output having a first spendable value and a first locking script, and the first transaction includes a second output having a second spendable value and a second locking script, in the first locking script, including a first set of constraints on a first selected transaction output, wherein if the first selected transaction output is valid for spending the first spendable value, then the first unlocking script will satisfy the first set of constraints, in the second locking script, including a second set of constraints on a second selected transaction output, wherein if the second selected transaction output is valid for spending the second spendable value, then the second unlocking script will satisfy the second set of constraints, and wherein the first set of constraints or the second set of constraints imposes constraints on a locking script of a spending transaction having the first selected transaction output or the second selected transaction output as a spending transaction output.

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

[0107] The first selected transaction output may be an output of a first spending transaction, the second selected transaction output may be an output of a second spending transaction, the first unlocking script may include fields of the first transaction, fields of the first selected transaction, and fields of the second spending transaction, and wherein the first locking script may include a first comparison of an extracted field of the first transaction and a second comparison of an extracted field of the first spending transaction.

[0108] The first constraint set and the second constraint set may each include a common set of constraints, whereby two constrained spend transaction output locking scripts are constrained by the common set of constraints. The first constraint set and / or the second constraint set may include 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 constraint on a size of a portion of the first locking script and / or a size of a portion of the second locking script.

[0109] The first set of constraints and / or the second set of constraints may include optional references to input data.Each of the plurality of outputs of the first transaction may be constrained by a different constraint imposed on the outputs of the plurality of outputs.

[0110] Transactions may be combined with arbitrary constraints or have interdependencies, such as using a computer-implemented method, including a node in a blockchain network creating a first spendable transaction, wherein the first spendable transaction includes a first spendable output having a first spendable value and a first locking script, including a first set of constraints for the spend transaction in the first locking script, wherein if the spend transaction is valid for spending the first spendable output, a first unlocking script of the spend transaction will satisfy the first set of constraints, including in the first set of constraints a first spend transaction constraint requiring a first spend transaction output of the spend transaction including a first spend transaction output locking script to include a first set of smart contract script instructions, and including in the first set of constraints 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 spend transaction input that references a second spendable transaction output.

[0111] The first set of smart contract script instructions may include script instructions copied 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.

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

[0113] The above method may include providing a first parallel constraint in a first constraint set, the first parallel constraint requiring a spending transaction to include a first spending transaction input referencing a first spendable transaction, a second parallel constraint requiring a spending transaction to include a second spending transaction input referencing a second spendable transaction output, a third parallel constraint requiring a first spending transaction output locking script to include at least a first set of script instructions in a first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint requiring a second spending transaction output locking script to include a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by a locking script of a second spendable transaction output.

[0114] The above method may include providing a first parallel constraint in a first constraint set, the first parallel constraint requiring a spending transaction to include a first spending transaction input referencing a first spendable transaction, a second parallel constraint requiring a spending transaction to include a second spending transaction input referencing a second spendable transaction output, a third parallel constraint requiring a first spending transaction output locking script to include at least a first set of script instructions in a first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint requiring a second spending transaction output locking script to include a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by a locking script of a second spendable transaction output.

[0115] The first set of constraints may include a first parallel constraint requiring a spending transaction to include a first spending transaction input referencing a first spendable transaction, a second parallel constraint requiring a spending transaction to include a second spending transaction input referencing a second spendable transaction output, a third parallel constraint requiring a first spending transaction output locking script to include in a first set of smart contract script instructions at least a first set of script instructions copied from the first locking script, and a fourth parallel constraint requiring a second spending transaction output locking script to include a second set of smart contract script instructions copied from a locking script of a second spendable transaction output.

[0116] It is also desirable to provide a computer-implemented method comprising: determining a first set of constraints on a first unlocking transaction output; determining a second set of constraints on a second unlocking transaction output; creating an initial transaction to include: at least one initial locking script, the script including the first set of constraints and the second set of constraints; and at least one redeemable value, wherein unlocking the at least one redeemable value is contingent upon: the first set of constraints being satisfied at least in part by verifying that the unlocking transaction includes the first unlocking transaction output; and the second set of constraints being satisfied at least in part by verifying that the unlocking transaction includes the second unlocking transaction output; and causing the initial transaction to be verified at a node of a blockchain network.

[0117] The locking script in the first unlocking transaction output can be a copy of the locking script in the second unlocking transaction output.

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

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

[0120] The execution of the at least one locking initialization script may select at least one portion from a plurality of portions of the at least one initial locking script.

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

[0122] The data may have an index value. Under the condition that the index value is a first index value, execution of the at least one initial locking script may determine whether a first set of constraints are satisfied. Under the condition that the index value is a second index value, execution of the at least one initial locking script may determine whether a second set of constraints are satisfied.

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

[0124] At least one initial locking script may include constraints on the data source.

[0125] The above method may also include determining a redeemable value of the first unlocked transaction output.

[0126] The initial transaction can encode a contract with multiple states.

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

[0128] The first set of constraints may constrain the first unlock transaction output to have a first state. The second set of constraints may constrain the second unlock transaction output to have a second state.

[0129] It is also desirable to provide a computer-implemented method comprising: determining an unlocking transaction constraint constraining an unlocking transaction to include an unlocking transaction input referencing a previous transaction output; creating a redeemable transaction comprising: a redeemable transaction output comprising a redeemable amount; and a redeemable transaction locking script comprising the unlocking transaction constraint, wherein unlocking the redeemable amount is contingent upon execution of at least one unlocking script of the unlocking transaction satisfying the unlocking transaction constraint; and causing the redeemable transaction to be verified at a node of a blockchain network.

[0130] Unlock transaction constraints can also constrain unlock transaction inputs to include specific hash values.

[0131] A specific hash value can encode an identifier that references a previous transaction output.

[0132] The unlocking transaction constraint may also constrain the unlocking transaction's locking script to include a set of script elements copied from the redeemable transaction's locking script.

[0133] Redeemable transactions can encode contracts with multiple states.

[0134] The above method may also include determining a redeemable value for an output of the unlock transaction.

[0135] The unlocking transaction constraint may include a specific locking script element from a previous transaction output. As a result of the unlocking transaction input including the specific locking script element, the execution of at least one unlocking script may satisfy the unlocking transaction constraint.

[0136] Certain locking script elements may encode a cryptographic key for a particular entity.

[0137] The unlocking transaction constraint may be a first unlocking transaction constraint; and the above method may also include: determining a second unlocking transaction constraint to further constrain the unlocking transaction; and creating a second redeemable transaction, the transaction comprising: a second redeemable amount; and a second redeemable transaction locking script including the second unlocking transaction constraint, wherein unlocking the second redeemable amount may also depend on the execution of at least one unlocking script that satisfies the second unlocking transaction constraint.

[0138] The redeemable transaction lock script may be a first redeemable transaction lock 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 lock script. The second unlocking transaction constraint may constrain the second unlocking script to include at least a portion of the second redeemable transaction lock script.

[0139] At least a portion of the first redeemable transaction locking script may include a cryptographic key associated with the first entity.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.

[0140] Unlocking transaction constraints can also constrain the unlocking transaction to constrain the output of the unlocking transaction.

[0141] The unlock transaction constraints may encode another contract different from the above. The unlock redeemable amount may depend on another contract being executed on the output of the unlock transaction.

[0142] It is also desirable to provide a computer-implemented method comprising creating a blockchain transaction encoding: a state machine in a first state and having a permitted set of state transitions; and a set of script elements to be executed so that an unlocking transaction: encodes the state machine according to the permitted set of state transitions; and complies with restrictions on inputs to the unlocking transaction or complies with restrictions on outputs of the unlocking transaction; and causes the blockchain transaction to be verified by nodes in a blockchain network.

[0143] The set of permitted state transitions may include state transitions that can be implemented independently and simultaneously in different blockchain transactions.

[0144] The set of script elements may cause the unlocking transaction to comply with restrictions on the outputs of the unlocking transaction. The restrictions on the outputs may require: the first output of the unlocking transaction to indicate a state corresponding to the first output that complies with the permitted set of state transitions; and the second output of the unlocking transaction to indicate a state corresponding to the second output that complies with the permitted set of state transitions.

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

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

[0147] The set of script elements may enable the unlocking transaction to conform to restrictions on the inputs to the unlocking transaction. Restrictions on the inputs may require the inputs to the unlocking transaction to indicate another state machine encoded in another blockchain transaction.

[0148] Restrictions on an input may require that the input reference a state machine in a first state and reference another state machine in another state different from the first state.

[0149] 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 a second state may be within the set of allowed state transitions.

[0150] The set of script elements can make the unlock transaction conform to the constraints on the inputs to the unlock transaction. The constraints on the inputs can state a set of conditions for advancing the state machine. The set of conditions for advancing the state machine can depend on the state of another state machine.

[0151] Another state machine may be encoded in another blockchain transaction. Another transaction may encode a set of conditions for advancing another state machine. Other sets of conditions for advancing another state machine may depend on the state of the state machine.

[0152] The set of script elements can make the unlocking transaction conform to the constraints on the outputs of the unlocking transaction. The constraints on the outputs may require the unlocking transaction to incorporate the set of elements of the smart contract into the outputs.

[0153] A collection of elements of a smart contract can be obtained from another blockchain transaction.

[0154] The set of script elements can make the unlocking transaction comply with the restrictions on the inputs of the unlocking transaction and the restrictions on the outputs of the unlocking transaction.

[0155] It is also desirable to provide a computer-implemented method, the method comprising: creating a blockchain transaction at a node in a blockchain network having a transaction output that can be unlocked by a first unlocking transaction input of a first unlocking transaction; inserting a first set of script elements constraining the first unlocking transaction into the blockchain transaction to include a first set of unlocking transaction script elements corresponding to operations of a state machine; and 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, the second set of unlocking transaction script elements corresponding to permitted state machine state transitions, the state machine state transitions including states that can be implemented using different blockchain transactions that can be processed simultaneously but independently by the blockchain network. The blockchain transaction may include a first output having a first locking script, and the first transaction output value may include a second output having a second locking script and a second transaction output value, wherein the first set of script elements is part of the first locking script.

[0156] The unlocking transaction may include an unlocking script that, when executed by a transaction validator using a previous transaction output locking script, will satisfy a predetermined validation test and will cause a node, when executing the previous transaction output locking script, to store at least values ​​of fields representing the unlocking transaction in a memory accessible to the transaction validator, insert a first set of script elements into the unlocking transaction, wherein the first set of script elements forms part of an unlocking transaction locking script for a first output of the unlocking transaction and is consistent with requirements specified by the previous transaction locking script, and wherein the first set of script elements corresponds to operations of a state machine, and insert a second set of script elements into the unlocking transaction, wherein the second set of script elements forms part of an unlocking transaction locking script, is consistent with requirements specified by the previous transaction locking script, and corresponds to a permitted state machine state transition, the state machine state transition comprising states that may be implemented using different blockchain transactions that may be processed concurrently but independently by the blockchain network.

[0157] The unlocking transaction may include an input and an output, wherein the input references a previous transaction output, and wherein the unlocking transaction includes an unlocking script that, when executed by a transaction validator using a previous transaction locking script of the previous transaction output, will satisfy a predetermined verification test, wherein the unlocking script causes a node to store at least a value representing a field of the unlocking transaction in a memory accessible to the transaction validator when executing the locking script, and insert data corresponding to an additional state machine into the unlocking transaction as an unlocking transaction input and / or an unlocking transaction output based on a permitted state machine state transition, such that the number of unlocking transaction inputs and / or unlocking transaction outputs used in the unlocking transaction is sufficient for multiple state machine transitions.

[0158] The permitted state machine state transition may include a forking transition from an initial state to two subsequent states by creating a first transaction output corresponding to a first subsequent state for the unlocking transaction, inserting in the unlocking transaction a first transaction output value of the first transaction output sufficient to make the first transaction output an input to a first subsequent transaction that references the first transaction output, inserting in the first transaction output of the unlocking transaction a third set of script elements, wherein the third set of script elements is part of a first locking script, the first locking script constraining the first subsequent transaction to assume the first subsequent state, creating a second transaction output corresponding to a second subsequent state for the unlocking transaction, inserting in the unlocking transaction a second transaction output value of the second transaction output sufficient to make the second transaction output an input to a second subsequent transaction that references the second transaction output, inserting in the second transaction output a fourth set of script elements, wherein the fourth set of script elements is part of a second locking script constraint, the second locking script constraining the second subsequent transaction to assume the second subsequent state, and inserting in the first transaction output or the second transaction output a fifth set of script elements, wherein the fifth set of script elements is part of the first locking script or the second locking script and imposes different constraints on the first subsequent transaction and the second subsequent transaction.

[0159] The first locking script may constrain the first subsequent transaction to have a first state, and the second locking script may constrain the second subsequent transaction to have a second state. The unlocking transaction may include three or more transaction output values ​​corresponding to the forks of three or more states. The unlocking transaction may include three or more transaction input values ​​corresponding to the merger of three or more states. The first locking script and the second locking script may constrain the first subsequent transaction and the second subsequent transaction to have the same state.

[0160] Typically, an unlocking transaction may include N transaction input values ​​and N transaction output values, where N is 1, 2, 3, or more.

[0161] The permitted state machine state transitions may include merged transitions from two initial states to a subsequent state by inserting a first transaction input for a first previous state in an unlock transaction, inserting a second transaction input for a second previous state in the unlock transaction, and inserting a merged state in the unlock transaction, the merged state being a permitted transition from the first previous state and the second previous state according to the state transition matrix.

[0162] The permitted state machine state transitions may 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 in the first transaction input, inserting a second reference to a second previous transaction having a second previous state in the second transaction input, and inserting a first transaction output for merging states in the unlocking transaction, wherein a state transition matrix is ​​available for the first previous transaction and the second previous transaction.

[0163] The permitted state machine state transitions may include parallel operations from a number N (N is two or more) of initial states to a number N of subsequent states by inserting a first transaction input for a first previous state in an unlocking transaction, inserting a second transaction input for a second previous state in the unlocking transaction, inserting a first reference to a first previous transaction having the first previous state in the first transaction input, inserting a second reference to a second previous transaction having the second previous state in the second transaction input, inserting a first transaction output for the first subsequent state in the unlocking transaction, inserting a third set of script elements in the first transaction output, wherein the third set of script elements is part of a first locking script that constrains the first subsequent transaction to present the first subsequent state, inserting a second transaction output for the second subsequent state in the unlocking transaction, and inserting a fourth set of script elements in the second transaction output, wherein the fourth set of script elements is part of a second locking script that constrains the second subsequent transaction to present the second subsequent state.

[0164] The operations of the state machine can be encoded for smart contracts implemented using the blockchain.

[0165] Transactions may be split using arbitrary constraints. The method may include creating a first transaction at a node in a blockchain network, wherein the first transaction includes a first output having a first redeemable value and a first locking script, and the first transaction includes a second output having a second redeemable value and a second locking script, in the first locking script, including a first set of constraints on a first selected transaction output, wherein if the first selected transaction output is valid for unlocking the first redeemable value, the first unlocking script will satisfy the first set of constraints, in the second locking script, including a second set of constraints on a second selected transaction output, wherein if the second selected transaction output is valid for unlocking the second redeemable value, the second unlocking script will satisfy the second set of constraints, and wherein the first set of constraints or the second set of constraints imposes constraints on the locking script of an unlocking transaction having the first selected transaction output or the second selected transaction output as an unlocking transaction output.

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

[0167] The first selection transaction output may be an output of a first unlocking transaction, the second selection transaction output may be an output of a second unlocking transaction, the first unlocking script may include fields of the first transaction, fields of the first selection transaction, and fields of the second unlocking transaction, and wherein the first locking script may include a first comparison of an extracted field of the first transaction and a second comparison of an extracted field of the first unlocking transaction.

[0168] The first constraint set and the second constraint set may each include a common set of constraints, whereby two constrained unlocking transaction output locking scripts are constrained by the common set of constraints. The first constraint set and / or the second constraint set may include 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 constraint on the size of a portion of the first locking script and / or a size of a portion of the second locking script.

[0169] The first set of constraints and / or the second set of constraints may include optional references to input data.Each of the plurality of outputs of the first transaction may be constrained by a different constraint imposed on the outputs of the plurality of outputs.

[0170] Transactions may be combined with arbitrary constraints or have interdependencies, such as using a computer-implemented method, including creating a first redeemable transaction at a node in a blockchain network, wherein the first redeemable transaction includes a first redeemable output having a first redeemable value and a first locking script, including a first set of constraints for an unlocking transaction in the first locking script, wherein if the unlocking transaction is valid for unlocking the first redeemable output, the first unlocking script of the unlocking transaction will satisfy the first set of constraints, including in the first set of constraints a first unlocking transaction constraint requiring the first unlocking transaction output of the unlocking transaction to include the first unlocking transaction output locking script to include a first set of smart contract script instructions, and including in the first set of constraints 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.

[0171] The first set of smart contract script instructions may include script instructions copied 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.

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

[0173] The above method may include providing a first parallel constraint in a first constraint set, the first parallel constraint requiring the unlocking transaction to include a first unlocking transaction input referencing a first redeemable transaction, a second parallel constraint requiring the unlocking transaction to include a second unlocking transaction input referencing a second redeemable transaction output, a third parallel constraint requiring the first unlocking transaction output locking script to include at least a first set of script instructions in a first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint requiring the second unlocking transaction output locking script to include a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by the locking script of the second redeemable transaction output.

[0174] The above method may include providing a first parallel constraint in a first constraint set, the first parallel constraint requiring the unlocking transaction to include a first unlocking transaction input referencing a first redeemable transaction, a second parallel constraint requiring the unlocking transaction to include a second unlocking transaction input referencing a second redeemable transaction output, a third parallel constraint requiring the first unlocking transaction output locking script to include at least a first set of script instructions in a first set of smart contract script instructions, the first set of script instructions being at least partially determined by the first locking script, and a fourth parallel constraint requiring the second unlocking transaction output locking script to include a second set of smart contract script instructions, the second set of smart contract script instructions being at least partially determined by the locking script of the second redeemable transaction output.

[0175] The first set of constraints may include a first parallel constraint requiring the unlocking transaction to include a first unlocking transaction input referencing a first redeemable transaction, a second parallel constraint requiring the unlocking transaction to include a second unlocking transaction input referencing a second redeemable transaction output, a third parallel constraint requiring the first unlocking transaction output locking script to include in a first set of smart contract script instructions at least a first set of script instructions copied from the first locking script, and a fourth parallel constraint requiring the second unlocking transaction output locking script to include a second set of smart contract script instructions copied from a locking script of a second redeemable transaction output.

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

[0177] It is also desirable to provide a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to perform at least any of the claimed methods. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0180] Figure 2 It shows that it can be Figure 1 An example of a blockchain node used in a blockchain environment.

[0181] Figure 3 shows that it can be stored in Figure 2 An example of a transaction in a blockchain ledger used by a blockchain node.

[0182] Figure 4 An example of a blockchain transaction is shown.

[0183] Figure 5 An example script for implementing the OP_GENSIG script for generating signatures is shown.

[0184] Figure 6 An example script for implementing a previous transaction OP_PREVTXINJECTION script that injects the input corresponding to the unlocking transaction is shown.

[0185] Figure 7An example script for implementing an OP_SELFTXINJECTION script that injects a previous transaction corresponding to an input being signed is shown.

[0186] Figure 8 An example script for implementing an OP_SPENDINGTXINJECTION script that injects a serialized unlocking transaction into a locking script is shown.

[0187] Fig. 9 An example of a pair of transactions is shown, where one is a transaction with a value to be transferred and the other is a transaction representing the unlocking of that value.

[0188] Fig.10 An example of multiple transactions is shown, where a transaction has multiple inputs from other transactions and multiple outputs that can be transferred by future transactions.

[0189] Fig.11 An example of generating a signature from a serialized set of transaction fields according to an embodiment is shown.

[0190] Fig.12 An example of an unlock transaction is shown, the unlock transaction including an unlock script that includes a copy of a portion of the unlock transaction.

[0191] Fig.13 The unlock transaction and the previous transaction are shown.

[0192] Fig.14 is a flow diagram of an example of a locking script that imposes constraints on the locking script of an unlocking transaction.

[0193] Fig.15 Shows the corresponding Fig.14 Some examples of more specific steps of the steps.

[0194] Fig.16 An example of verifying the unlocking script is shown.

[0195] Fig.17 An example of a locking script that imposes a set of constraints on the input is shown.

[0196] Fig.18 is a flow chart of an example of a locking script that imposes constraints on the inputs of an unlocking transaction.

[0197] Fig.19 An example of input constraints is shown.

[0198] Fig. 20 Shown in Fig.18 Examples of constraints in the environment of the process shown.

[0199] Fig.21 Interlocking script constraints are shown.

[0200] Fig. 22 An example of a state machine implemented using blockchain transactions is shown.

[0201] Fig.23 An example showing how state machine logic can be encoded in a blockchain transaction.

[0202] Fig.24 An example of a trustless deterministic state machine according to an embodiment is shown.

[0203] Fig.25 is a flow chart illustrating an example of processing for a trustless deterministic state machine according to various embodiments.

[0204] Fig.26 A state machine using a state transition matrix having certain characteristics is shown.

[0205] Fig. 27 An example of a transaction that can be used to implement a state machine is shown.

[0206] Fig.28 An example of forking a portion of a smart contract using a blockchain transaction is shown.

[0207] Fig.29 is an example pseudocode sequence for a fork process.

[0208] Fig.30 An example of creating a new smart contract from a smart contract using blockchain transactions is shown.

[0209] Fig.31 is an example pseudocode sequence for forcing a smart contract in an unlock transaction.

[0210] Fig.32 An example of a merge operation of a smart contract using a blockchain transaction is shown.

[0211] Fig.33 Pseudo-code sequence as an example of a merge process with weak dependencies.

[0212] Fig.34 is a pseudo code sequence as an example of a merge process with strong dependencies.

[0213] Fig.35 An example of parallel processing operations of smart contracts using blockchain transactions is shown.

[0214] Fig.36 is a pseudocode sequence as an example of parallel transaction barrier processing.

[0215] Fig.37An example showing how to use blockchain transactions in concurrent paths to execute parts of a smart contract in accordance with contract barriers. DETAILED DESCRIPTION

[0216] First, refer to Figure 1 , Figure 1 An exemplary blockchain network 100 associated with a blockchain according to an embodiment of the present invention is shown. In this embodiment, the blockchain network 100 includes blockchain nodes that may be implemented as peer-to-peer distributed electronic devices, each of which runs an instance of software and / or hardware that performs operations that follow a blockchain protocol that is agreed upon in whole or in part between the operators of the nodes. In some examples, these distributed electronic devices are simply referred to as "nodes" (e.g. Figure 1 Node 102 in ).

[0217] Node 102 may include any suitable computing device (e.g., a server in a data center, a client computing device (such as a desktop computer, laptop computer, tablet computer, smart phone, etc.), be composed of multiple computing devices in a distributed system of a computing resource service provider, or be composed of any suitable electronic client device. Node 102 may have an input to receive a data message or object representing a proposed transaction (such as transaction 104). Node 102 may query the information it maintains, such as an understanding of the state of the transaction.

[0218] like Figure 1 As shown, some nodes 102 may be communicatively connected to one or more other nodes 102. As to which nodes 102 may communicate with which other nodes, these details need not be centrally determined. Assuming that the message is one that the blockchain protocol indicates should be forwarded, it is sufficient that the active nodes in the blockchain network 100 are able to communicate with one or more other nodes 102 so that the message passed from one node 102 to another node 102 can propagate in the blockchain network 100 (or some significant portion thereof). One such message may be the publication of a transaction proposed by one of the nodes 102A, which message would then propagate along a path such as path 106. Another such message might be the publication of a new block proposed for inclusion in the blockchain.

[0219] Figure 2 It shows that it can be used in a blockchain environment Figure 12 is an example of a blockchain node 202 of a node in a blockchain network. As shown, the blockchain node 202 is shown to include a processor 204, a program memory 206, a storage blockchain rules and protocol details 208, a peer list 210, a storage application variables 212, a communication interface 214, and a storage blockchain ledger 216. The blockchain ledger 216 contains data corresponding to blocks in the blockchain, such as blocks 221, 222, 223 containing data corresponding to transactions, such as block 222 with transactions 230(1)-(4). With the exception of block 223, the above blocks can be cryptographically immutable because subsequent blocks depend on the values ​​calculated on the block when it becomes immutable, and any modifications to the immutable block can be easily identified as invalid blocks by other blockchain nodes. Block 223 is shown as an open block, representing the storage of transactions that may be mutable and may not have been committed to the blockchain.

[0220] The blockchain nodes 202 communicate via a communication interface 214, which may be implemented as one or more of wired or wireless communications. The blockchain ledger 216 may be a complete copy or a portion of the blockchain ledger of the blockchain network. Some blockchain nodes may only maintain untransferred transactions, while other nodes may maintain the entire ledger. In this way, the ledger is a distributed ledger because each node can have its own copy. Preferably, the nodes modify their copies only according to the rules of the protocol, and for all nodes that fully follow these rules, their copies should sometimes be the same as other nodes, saving some propagation time for blocks and transactions. Blockchain nodes should include the ability to verify the blocks they receive and the transactions in these blocks. The rules of the blockchain protocol may be that if a blockchain node determines that the block of a transaction is invalid, the blockchain node does not propagate the block or transaction to other nodes. According to this rule, valid and verified blocks and transactions can propagate the blockchain network, while invalid blocks and transactions may not be propagated.

[0221] Some nodes in a blockchain network may be blockchain nodes that perform operations of collecting transactions and creating transaction blocks so that new blocks can be submitted to the blockchain. The blockchain node may be expected to perform some operations that are both complex (to prevent rogue nodes from easily creating inappropriate blocks) and dependent on the data of the included transactions (so that rogue nodes cannot perform complex operations in advance), and the performance of these tasks is easily verified by other nodes. Since the above-mentioned other nodes verify the work of the blockchain node, after verification, the other nodes receive the block into their copy of the blockchain and propagate it. This submits the new block to the distributed ledger of the blockchain. In some examples, a block is a group of transactions, usually marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this way, each block is linked to the previous block, thereby creating a "chain" that links the blocks in the blockchain. In an embodiment, a valid block can be added to the blockchain through the consensus of the nodes in the blockchain network. Also in some examples, the blockchain includes a list of verified blocks.

[0222] In an embodiment, as described in the present invention, at least some nodes are used as verification nodes for verifying transactions. In some examples, blockchains prove value in the form of digital assets, and transactions of blockchains collectively provide a chain from a founding transaction (starting blockchain) or an allocation transaction to a subsequent transaction. The end of a portion of the chain will be an untransferred transaction or a portion thereof, and each transaction on the blockchain specifies one or more outputs, some of which may be transferred and some not, wherein the output includes a specification of the value of the output and a requirement for someone to "unlock" the output by inserting a valid transaction (i.e., a transaction that at least meets the specified requirements), which will extend the portion of the chain. As used herein, unspent transaction outputs may be referred to as (Unspent Transaction Output, referred to as UTXO). Unlocking UTXO may also be referred to as spending UTXO in the art.

[0223] The requirements required for someone to unlock a UTXO can be specified in the UTXO's locking script. A valid unlocking transaction can be one that (i) specifies one or more previous UTXOs as inputs to the transaction, where the specification can be accompanied by a pointer to the UTXO, (ii) satisfies the requirements of the locking script for each UTXO, and (iii) has inputs such that the sum of the values ​​of all the UTXOs pointed to by those inputs is less than or equal to the sum of the values ​​of all the outputs of the transaction. The data representing that the requirements of the locking script are satisfied can be called an unlocking script. A validating node can process an unlocking script, followed by a locking script, and the output of this process is either an invalid result or a verification of the unlocking transaction.

[0224] The process can be a stateless process, so if one node runs the unlocking script and the locking script, the result is a verification that will be the result for other nodes. Thus, an unlocking transaction that satisfies the locking script of a previous transaction output that already exists on the blockchain but has not yet been transferred can be propagated and eventually submitted to the blockchain. The node that creates the unlocking transaction to be submitted in turn specifies in its own locking script the requirements required for anyone to unlock the output value of this new transaction. The process can be considered stateless because the scripts do not need to refer to references outside of the scripts, nor do they rely on variables or other state outside of these scripts, with some minor exceptions. Therefore, the unlocking script and the locking script can be evaluated separately.

[0225] In other variations, the blockchain system may include functionality that allows external data to be included in the script evaluation process. In this case, the external data may be controlled and / or protected in the following manner: When the unlocking script and the locking script are evaluated using the external data, the evaluation may be consistent between the nodes performing the evaluation.

[0226] Figure 3 shows that can be stored in Figure 2 300 in a blockchain ledger used by a blockchain node. Other variations with similar functionality are possible. The data elements or fields of a transaction may be as follows: Figure 3 As shown, and may include other fields in addition to those described in the present invention. As shown, there is a blockchain version field 302, which has a value indicating the blockchain protocol version of the transaction 300. The #vin field 304 indicates how many transaction inputs are present in the transaction 300 (described below). Other fields may be present and are not shown, but for each transaction input (shown herein as an example Vin[y] 310), there may be a set of fields that include a transaction identifier (TxID) 311 of the previous transaction, a pointer 312 to one of the outputs of the previous transaction (a transaction that provides a transaction output to match the transaction input 310), wherein the TxID 311 and the pointer 312 together form a pointer 313 that references the output of the previous transaction. As used herein, the term "previous transaction" when used in the context of a current or present transaction may refer to a specific previous transaction (or multiple transactions) having a transaction output referenced (and "transferred") by the current or present transaction. In the example, the current or present transaction may be referred to as an "unlocking transaction".

[0227] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values, but rather a decentralized mechanism for generating unique TxIDs for transactions, such as by generating a hash of the contents of the transaction itself. Since a valid transaction cannot have exactly the same contents as another valid transaction, each valid transaction can have a unique hash for its TxID (except for a very low probability of hash collisions). Regardless of the implementation, this article assumes that each transaction has a unique transaction identifier. Due to the nature of the hash, once a TxID is generated from the contents of a transaction, that content cannot be changed and the TxID remains valid for that transaction.

[0228] like Figure 3 As shown, the field set of the transaction input Vin[y]310 also includes an unlocking script length field 314 (Unlocking_Script_Length field) indicating the length of the subsequent script, an unlocking script field (Unlocking_Script field) 315 containing the unlocking script of vin[y]310, the unlocking script of which "unlocks" the corresponding locking script of the transaction output pointed to by pointer 313, and a sequence # field (sequence#field) 316 that can be used to constrain transaction 300.

[0229] although Figure 3 Only one transaction input and one transaction output are explicitly shown, but multiple transaction inputs and multiple transaction outputs are possible. Following the transaction inputs, there may be a #vout field 320, which may indicate how many transaction outputs there are in the transaction 300 (also explained below). For each transaction output (shown herein as an example Vout[x] 330), there may be a set of fields including an output value field 332 indicating the transaction value provided by the transaction output Vout[x] 330, a locking script length field (Locking_Script_Lengthfield) 334 indicating the length of the latter script, and a locking script field (Locking_Scriptfield) 336 containing the locking script of the transaction output Vout[x] 330. As explained, the transaction value of the transaction output can be "transferred" by anyone who can create an unlocking transaction with a transaction input having an unlocking script that a blockchain node can verify as true when performing verification using the unlocking script and the locking script. Other fields may follow the transaction output field, such as a lock time field 338, which may restrict the transaction 300 from being active until a specified future time or until a specified future block. In the case where each transaction input of an unlocking transaction points to a corresponding transaction output of a previous transaction output and the previous transaction output includes a transaction value, the transaction input need not include a field indicating the transaction value.

[0230] Figure 4 An example of a blockchain transaction 400 is shown. In this example, the blockchain transaction 400 includes the data elements or fields shown, and may include additional fields in addition to those shown or described in the present invention. The transaction 400 includes an nVersion field 402 having a value indicating the version of the transaction 400. The #vin field 404 may indicate how many transaction inputs are present in the transaction 400. For each transaction input, such as a transaction input Vin[y] 410, there may be a set of fields including a hash 411 referencing a previous transaction, a pointer n412 to a specific output of the previous transaction, a scriptSigLen field 414 indicating the length of the next unlocking script, a scriptSig field 415 containing the unlocking script of the transaction input Vin[y] 410, and an nSequence field 416 that may be used to constrain the transaction 400.

[0231] Following the transaction inputs, there may be a #vout field 420 indicating how many transaction outputs there are in the transaction 400, and for each transaction output (one is shown herein as an example, Vout[x] 430), there may be a set of fields including an nValue field 432 indicating the transaction value provided by the transaction output Vout[x] 430, a scriptPubKeyLen field 434 indicating the length of the following locking script, and a scriptPubKey field 436 containing the locking script for the transaction output Vout[x] 430. The transaction 440 may also be shown with an nLockTime field 438, which may constrain the transaction 400 to be inactive until a specified future time or until a specified future block.

[0232] Operation Code

[0233] In the example scripting language, there may be a set of operation codes (OP codes for short), which may appear as script instructions in a script (e.g., a lock script or an unlock script). In the present invention, various script operation codes and keywords are referenced to perform various operations. However, it is conceivable that other blockchain technologies may implement different sets of instructions, and therefore the operation codes described in the present invention should be viewed as descriptions of the operations performed by the operation codes.

[0234] Certain embodiments of the present invention operate under the assumption that the scripting system or other system for implementing the described instruction set allows more than 200 instructions (e.g., more than 200 operation codes) in a single script. Likewise, certain embodiments of the present invention also assume that the functionality provided by the operation codes referenced by the present invention exists and is enabled in the system executing the operation code script / instruction set. Examples of operation codes referenced in the present invention include:

[0235] OP_ADD pops the first two items from the stack, adds them and pushes the result back to the stack

[0236] OP_BIGMOD pops the first two items from the stack, divides the second item by the first item, and pushes the remainder back onto the stack

[0237] OP_BIGMODADD pops the first three items from the stack and performs a modular addition on the first and second items.

[0238] Perform a modulo operation on the third term and push the result onto the stack

[0239] OP_BIGMODINVERSE pops the first two items from the stack, performs a negative modulo exponentiation operation on the first item modulo the second item, and pushes the result onto the stack

[0240] OP_BIGMODMUL pops the first three items from the stack and performs a modular multiplication on the first and second items.

[0241] Perform a modulo operation on the third term and push the result onto the stack

[0242] OP_CAT, pop the first two items from the stack, concatenate the two items and push the result back to the stack

[0243] OP_CHECKSIG pops two items from the stack, uses the first as the public key and the second as the signature, checks if the popped signature is a valid signature, and pushes 1 (true) onto the stack if it is valid, otherwise pushes 0 (false) onto the stack

[0244] OP_CHECKSIGVERIFY, which has the same functionality as OP_CHECKSIG, but OP_

[0245] VERIFY is then executed

[0246] OP_DIV pops two items from the stack, separates the second item from the first, and pushes the result onto the stack

[0247] OP_DUP, which pushes a copy of the top item on the stack onto the stack, thereby duplicating the top item OP_ELSE, which executes if a preceding OP_IF or OP_NOTIF or OP_ELSE is not executed; otherwise, it does not execute if a preceding OP_IF or OP_NOTIF or OP_ELSE is executed

[0248] OP_ENDIF, ends the if / else block

[0249] OP_EQUAL, reads the first two items on the stack and pushes 1 onto the stack if the two items are exactly equal, otherwise pushes 0

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

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

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

[0253] OP_IF, if the top stack value is not false, execute the statement and remove the top stack value

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

[0255] OP_NOTIF, if the top stack value is false, execute the statement and remove the top stack value

[0256] OP_OVER, copies the second item on the stack and pushes it to the top of the stack

[0257] OP_ROLL, where the item at depth n in the stack is moved to the top

[0258] OP_SUBSTR, returns part of a string

[0259] OP_SWAP, which swaps the first two items in the stack

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

[0261] OP_VERIFY, marks the transaction as invalid if the top stack value is not true

[0262] Some of the above opcodes may be basic opcodes supported by blockchain nodes, while others are referred to herein as opcodes for ease of description, but are typically implemented as small scripts consisting of multiple basic opcodes. For example, OP_BIGMOD is referenced as an opcode, but may be implemented using a sequence of opcodes to perform the function of returning the remainder after dividing the first two items in the stack. OP_BIGMODADD, OP_BIGMODINVERSE, and OP_BIGMODMUL may be represented in a straightforward manner using similar opcode sequences.

[0263] OP_GENSIG: In this disclosure, references to OP_GENSIG should be considered shorthand for operations corresponding to the OP_GENSIG script described herein. An OP_GENSIG script that generates a transaction signature that may be pushed onto the stack or used. The OP_GENSIG script starts with the following assumption: the inputs pushed onto the main (last-in, first-out) stack in order are<SIGHASH Type> (indicates which fields of the transaction will be used in the hash), the message value <m>(double SHA256 of the serialized set of the transaction's used transaction fields), private key (For message value <m>hash) and numbers <k>(a random or pseudo-random number used to mask / protect the private key; "mask number").

[0264] < / k> < / m> Figure 5 The input and output of the OP_GENSIG script are shown. In the OP_GENSIG script, the first line results in the number <k>is copied to the alternate stack, and then <k>Multiplying by the elliptic curve generator<PubK G> , to produce the elliptic curve point K on 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 standby stack. The third line of the script determines s = k -1 (m+r×a) modulo n. Finally, the fourth line of the script encodes r and s in DER format and <sighashtype>connect.

[0265] The type of the signature hash may be represented by a byte-encoded value, SIGHASH Type. The SIGHASH Type value specifies a set of fields to be extracted from the transaction before serialization (e.g., normalization) and hashing. In some examples, the SIGHASH type value may be SIGHASH_ALL, SIGHASH_NONE, SIGHSH_SIGNAL, SIGHASH_ANYONECANPAY, or some combination of two or more thereof. In an embodiment, the SIGHASH_ALL type means that all fields in the transaction, except the input script, will be included in the serialization (and therefore hashed and signed). In an embodiment, the SIGHASH_NONE type indicates that the output does not need to be signed, which may allow others to update the transaction. In an embodiment, the SIGHASH_SIGNAL type indicates that the input is signed, but the sequence number is blanked, so that others can create a new version of the transaction that will use the same hash (assuming that the hashed fields have not changed), but the only output that is signed is the output that is in the same position as the input.

[0266] In an embodiment, the SIGHASH_ANYONECANPAY type is combined with other types and indicates that inputs including SIGHASH_ANYONECANPAY are signed, but other inputs do not need to be signed. The SIGHASH Type value can be represented by a number representing the SIGHASH Type. For example, in some embodiments, SIGHASH_ALL is represented by a byte with a value of 1 (e.g., binary "0000001"), SIGHASH_NONE is represented by a byte with a value of 2 (e.g., binary "0000010"), SIGHASH_NONE is represented by a byte with a value of 3 (e.g., binary "0000011"), and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80 (e.g., binary "01010000"). In some implementations, combining SIGHASH Type values ​​is performed by binary addition of the individual byte values. In some examples, the set of transaction fields determined by the SIGHASH Type refers to a subset of the corresponding transactions serialized as determined by the SIGHASH Type value. For example, for a SIGHASH Type of SIGHASH_ANYONECANPAY, only one transaction input is included in the signature.

[0267] By requiring the unlocking script to include SIGHASH, the locking script can verify that the serialized set of unlocking transaction fields provided by the unlocking script is actually the source of SIGHASH, and in turn, utilizing the OP code OP_CHECKSIG, the locking script can verify that the SIGHASH Type value provided by the unlocking script matches the signature hash of the unlocking transaction. The locking script can do this because when it is executed by a transaction validator, that transaction validator is able to perform an OP_CHECKSIG operation and place the signature of the actual unlocking transaction on the stack.

[0268] OP_DERENCODE: For the purposes of this disclosure, references to OP_DERENCODE should be considered shorthand for the operation corresponding to popping the first two items from the stack, encoding them in DER format, and pushing the result onto the stack.

[0269] OP_ECPMULT: In this invention, references to OP_ECPMULT should be considered as shorthand for an operation corresponding to popping two items from the stack, performing elliptic curve point multiplication (also called elliptic curve scalar multiplication) on the two items, and pushing the result onto the stack.

[0270] OP_ECPX: References to OP_ECPX should be taken as shorthand for an operation that pops two items from the stack, uses the first item as modulo n and the second item as the elliptic curve point K, computes the x-coordinate of K modulo n, and pushes the result onto the stack.

[0271] OP_PREVTXINJECTION: In this disclosure, references to OP_PREVTXINJECTION should be considered shorthand for the operation corresponding to the injection of the previous transaction corresponding to input X of the unlocking transaction. Figure 6 The input and output of the OP_PREVTXINJECTION script are shown.

[0272] OP_SELFTXINJECTION: In this invention, references to OP_SELFTXINJECTION should be considered shorthand for the operation corresponding to the injection of the previous transaction corresponding to the input being signed. Figure 7 The input and output of the OP_SELFTXINJECTION script are shown.

[0273] OP_SPENDINGTXINJECTION: For the purposes of this invention, references to OP_SPENDINGTXINJECTION should be considered shorthand for an operation that corresponds to injecting a serialized unlocking transaction into a locking script. Any entity that provides a SIGHASH Type value and a set of unlocking transaction fields determined from the SIGHASH Type can unlock the transaction output. This can be a useful feature. Figure 8 The input and output of the OP_SPENDINGTXINJECTION script are shown.

[0274] OP_EXTRACTTXID: For the purposes of this disclosure, references to OP_EXTRACTTXID should be considered shorthand for an operation that takes a transaction ID and a transaction ID position as input and outputs the extracted transaction ID. The input to OP_EXTRACTTXID is a serialized transaction and a value X indicating an input index, and the output is a transaction identifier associated with the transaction input at that index in the serialized transaction. The script may need to parse the serialized transaction to extract the transaction ID, as serialized transactions may include fields of variable length, with variations in length indicated by other fields in the serialized transaction.

[0275] Fig. 9 An example of a pair of transactions is shown. A blockchain node 902 that verifies a transaction may have a transaction verifier 904, which 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 trusted data or state. The guidance herein may also be applicable to blockchain systems that do not use a stack-based transaction verifier.

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

[0277] With a stateless stack-based transaction validator, locking script 910 and unlocking script 920 can be processed independently without relying on variables or other state outside of these scripts, with some minor exceptions. As a result, locking script 910 may not reference fields of the previous transaction outside of locking script 910 itself. Locking script 910 also cannot reference fields of unlocking transaction 922 because unlocking transaction 922 did not exist when previous transaction 912 and locking script 910 were created and became immutable.

[0278] Unlocking script 920, in order to be stateless, cannot operate directly on fields of unlocking transaction 922. The stateless quality can be useful because it ensures that given the same locking script 910 and the same unlocking script 920, any appropriately programmed blockchain node will get the same result 906. One exception to this is that the script may have the ability to check the signature in one of the scripts against the signature generated by the entire transaction. In an embodiment, the script may use OP_CHECKSIG for this purpose.

[0279] In stack-based operations, the transaction validator executes the unlocking script by processing each operation code in the script in turn. Some operation codes result in processing, some result in data being pushed onto or popped off the stack, or some combination. Once the execution of the unlocking script is complete, there may be residual data on the stack. If the execution of the unlocking script is complete without a script error or an operation code that terminates execution, the transaction validator executes the locking script, which can use the data present on the stack. In the case where the locking script and the unlocking script can be written using the same set of operation codes, this is actually similar to executing a single script that includes the concatenation of the unlocking script and the locking script. However, checking for script errors at the end of the execution of the unlocking script's operation codes and before executing the locking script's operation codes can prevent problems caused by malformed unlocking scripts.

[0280] Once the execution of the script 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 a verification that the unlocking script actually unlocks the locking script. In this respect, the unlocking script satisfies all the requirements of the locking script.

[0281] Fig.10 An example of multiple transactions and multiple inputs / outputs is shown. As shown, the previous transaction 1002 has two transaction outputs, Vout[0] 1004 with its locking script 1006 and Vout[1] 1014 with its locking script 1016, and their corresponding transaction output values, as well as other fields not shown, (e.g., the transaction inputs of the previous transaction 1002). The unlocking transaction 1020 is shown as having two transaction inputs, Vin[0] 1024 (with its unlocking script 1026 and a pointer 1028 pointing to its corresponding previous transaction output) and Vin[1] 1034 (with its unlocking script 1036 and a pointer 1038 pointing to its corresponding previous transaction output). In this example, the previous transaction output corresponding to Vin[0] is Vout[0] of the previous transaction 1002 (previous transaction 1), and the previous transaction output corresponding to Vin[1] is some output (not shown) of another transaction (previous transaction 2).

[0282] To verify the unlocking transaction 1020, the blockchain node 1042 with the transaction validator 1044 outputs a true or false result 1046 depending on whether all its inputs are valid. In this case, there may be multiple inputs for the unlocking transaction 1020, so each input is verified by processing the unlocking script of the transaction input and the locking script of the corresponding transaction output pointed to by the input's pointer.

[0283] Using the ability to have multiple outputs and multiple inputs, the value of one transaction can be transferred through multiple other transactions, and the value redeemable in a new transaction can come from multiple previous transactions. As mentioned above, the locking script can impose constraints on what must be included in the unlocking script through signatures and other cryptographic techniques.

[0284] One such constraint might be that the unlocking script must contain some arbitrary data. Some constraints might be "weak constraints" or more general constraints, such as that the unlocking script must contain some data that is 4 bytes long, or some specific number of bytes without constraining those bytes to be any particular value. A stronger or more specific constraint might be that the data must produce a specific hash value when hashed. The latter constraint typically requires that the data be of a specific length and that the data have a specific value, since it is virtually impossible for someone to determine that different values ​​would result in the same hash. This constraint can be implemented in the script by having the unlocking script push that data onto the stack, or by pushing the hash of that data onto the stack and having the locking script push the required hash onto the stack and then execute an OP_EQUAL and then an OP_VERIFY opcode. These opcodes will return true if the two pushed items match, and false if they do not. In more general cases, constraints can be imposed that require certain data to be present, or data with certain characteristics.

[0285] An example of a weak constraint is that the unlocking script must include certain data, which may contain a serialized set of the fields of the unlocking transaction, without necessarily requiring those fields to be any particular values. In this way, the locking script can constrain the script of the unlocking script that unlocks the output of that locking script to include the fields of the unlocking transaction that the unlocking script came from. This effectively allows the locking script to perform operations on the fields of the unlocking transaction that the unlocking script left on the stack. Another example of a weak constraint is that the unlocking script must contain certain data, which may be obtained from a specified location, but there is no constraint on the value of the data. This allows some weak constraints to be imposed, even if the value of the data is determined after the locking script is made immutable.

[0286] Constrained operations and constrained data may include elements of a "smart contract". A smart contract defines the terms and conditions of a contract regarding who can do what, when they can do it, and who gets paid when. The terms and conditions may be expressed as constraints (weak or strong) in an unlocking script or other part of an unlocking transaction, and these terms and conditions of the smart contract may be enforced by the blockchain protocol. Thus, just as in the example above, only Bob can unlock the value of a locked transaction output (because only the unlocking script that Bob can create can unlock that transaction output), there may be constraints that a transaction output can only be spent after one party has granted permission and after a certain time and only after another transaction output has been spent, and so on.

[0287] Figure 8 OP_SPENDINGTXINJECTION is shown, short for the operation code of a script that encodes the constraints for causing the injection of a serialized set of unlocking transaction fields. The locking script may include the operation code OP_GENSIG (which will cause the generation of a signature) followed by the operation code OP_CHECKSIG (which will cause the signature to be checked to see if it is a valid signature for the unlocking transaction). In order for OP_GENSIG to produce a valid signature, it must have certain elements as input: a SIGHASHType element, a hash of the serialized set of unlocking transaction fields (corresponding to a specific set of SIGHASH Type elements), a private key, and a masking number (e.g., a random number or pseudo-random number used to mask / protect the private key). By including the hash operation code, private key, and random number in the locking script, this effectively constrains the unlocking script to provide the SIGHASH Type and serialized set of unlocking transaction fields.

[0288] Fig.11 The process for generating a signature from a serialized set of transaction fields is shown. This can be done by the blockchain node or other transaction generator that created the transaction. Fig.11 As shown, a serialized transaction 1110 (i.e., a transaction represented by a series of data objects in a specific format) includes a set of field values ​​of the transaction. The signer of the serialized transaction 1110 selects SIGHASH Type 1112 and provides the signer's private key. The blockchain client / node can determine the fields to be used or modified of the serialized transaction 1110 from SIGHASH Type 1112. Some fields may be modified (rather than set to zero) before the hash is generated. Fig.11 In the example of , SIGHASH Type is set equal to SIGHASH_NONE|SIGHASH_ANYONECANPAY, so the selected fields are the fields shown by the modified serialized transaction 1114.

[0289] The blockchain client / node generates a hash of the modified serialized transaction 1114 (e.g., performing a double SHA-256 hash), resulting in a message m 1116. The blockchain client / node processing the serialized transaction 1110 selects a number k 1118, which is typically a random number or pseudo-random number, to mask / protect the private key. In the present invention, the number k is sometimes referred to as a "masking number". The blockchain client / node creates a signature 1124 (a DER-encoded electronic signature in this example) based on the set of signature inputs 1120 from SIGHASH Type 1112, message m 1116, the signer's private key 1122, and the number k 1118. The signature 1124 and SIGHASH Type 1112 can then be used in the unlocking script.

[0290] Fig.12 An example of an unlock transaction 1200 is shown, which includes an unlock script 1203, which includes a copy of the unlock transaction (e.g., a serialized set of fields of the unlock transaction). Fig.12 As shown, one of the transaction inputs is Vin[z]. The input Vin[z] has a hash that is the TxID of the previous transaction and the output number n of the previous transaction. Together these form a pointer 1202 to a specific output of a specific previous transaction that will be unlocked by Vin[z]. The transaction input Vin[z] has an unlocking script 1203, which in turn has a number of components or sub-scripts 1206, 1208, 1210, 1212. The unlocking script 1203 includes a serialized version 1206 of the previous transaction Z. Also shown is a serialized version 1208 of the previous transaction Z′, which is a transaction with an output transferred by the previous transaction Z serialized in the same manner. Although not shown, additional previous transactions may be included. The unlocking script 1203 also includes a SIGHASH_TYPE byte 1210 to indicate which fields of the unlocking transaction 1200 have been included.

[0291] The locking script of the previous transaction uses OP_GENSIG and OP_CHECKSIG to constrain the unlocking script to include the unlocking transaction, and uses the TxID of the previous transaction and OP_EQUALVERIFY to constrain the unlocking script to include the serialized version 1206 of the previous transaction Z. The TxID of the previous transaction Z can be extracted from the fields of the unlocking transaction and can be injected into the previous transaction Z. Because the previous Tx Z itself includes the TxID of the previous transaction Z′, the TxID can be extracted, and so on.

[0292] The serialized set of transaction fields of the unlocking transaction does not include the unlocking script of the unlocking transaction itself; otherwise there would be causality issues. In some embodiments, the signature hash of the transaction may exclude some predetermined fields. SIGHASH Type may refer to the set of fields extracted from the transaction before serialization and hashing.

[0293] The locking script of the previous transaction may impose such a requirement on the unlocking transaction that, in order for the unlocking transaction to be valid, the unlocking script of the unlocking transaction needs to include a copy of some or all fields of the unlocking transaction and a reference to one or more previous transactions unlocked by the unlocking transaction. Of course, the fields of the unlocking transaction may be mutable when the unlocking transaction is created. However, the locking script of the previous transaction may impose constraints on the fields of the unlocking transaction, because if those fields of the unlocking transaction that are part of the unlocking script of the unlocking transaction do not meet these constraints, the unlocking transaction may not verify when the unlocking script is executed. Fields that are not part of the unlocking script (e.g., fields that do not contain a SIGHASH Type value or are set to zero) may not be constrained by the locking script. In addition, not all fields included in the serialized unlocking transaction need to be constrained. For example, the locking script may only constrain one of the multiple fields of the serialized unlocking transaction included in the unlocking script.

[0294] Different outputs of the previous transaction may have different sets of constraints applied, perhaps constraints on different inputs and outputs of different unlocking transactions. Using this technique, a blockchain node may create a transaction using this locking script, and the locking script may also perform other checks, so that as the created transaction output is transferred, the transaction that unlocks the transaction output, etc. may necessarily carry various data elements and states.

[0295] Fig.12 The transaction can be extended to implement a state machine with quite complex functions. As described above, the locking script can access data that is only available after the locking script is created and fixed at the time of verification. This data can include details of the fields of the unlocking transaction being verified and details of the previous transaction containing the locking script (and possible other previous transactions known to the blockchain node that is creating the unlocking transaction at the time). This allows the state of the state machine to be represented in the script, and allows states and state transitions to be implemented and occur within the trustless scope of the blockchain environment. In other words, the state machine can be implemented using transactions verified by blockchain nodes that are not necessarily trusted, by processing the transaction like other transactions processed by the blockchain network. In some examples, "trustless" refers to the property that any entity can create a valid unlocking transaction as long as the constraints are met, and the entity does not need to be trusted. However, in some cases, the entity may need to interact with a determined source to obtain the required input. In some embodiments, one or more inputs can be obtained from an undetermined source (e.g., from a serialized previous transaction).

[0296] In a blockchain network, a transaction has some input value (determined by the transaction output value of the previous transaction unlocked by the transaction input) and some output value. To be valid, the sum of the outputs cannot exceed the sum of the inputs (except for allocation transactions and genesis transactions, which can be reserved in this specification), and the output may be less than the input. When implementing a trustless deterministic state machine using a blockchain network, the initial state of the state machine will be in a transaction that contains enough value.

[0297] In general, the locking script of the previous transaction can be used to implement a state machine, so that the unlocking transaction represents a state transition of the state machine, where the locking script constrains the content of the unlocking transaction, and in particular constrains the content and properties of the various transaction outputs of the unlocking transaction. Therefore, the locking script of the previous transaction output can actually specify what each transaction output of the unlocking transaction needs to look like. The locking script can require different characteristics of different unlocking transaction outputs (for example, by requiring that Vout[0] of the unlocking transaction include certain data and script elements), and that Vout[1] of the unlocking transaction include certain other data and other script elements.

[0298] Any entity that provides a SIGHASH Type and a set of unlocking transaction fields used by a specific SIGHASH Type can unlock a transaction output. In this way, some parties will have reason to propagate the contents of a transaction by unlocking the transaction and forwarding the details from the locking script. As described above, in some examples, "unlocking" a transaction output means creating an unlocking transaction that references the transaction output and can be evaluated as valid, thereby causing the transaction output to be transferred.

[0299] Using the above techniques and apparatus, a transaction can be created on a blockchain ledger that includes a script that implements a smart contract, a script that can implement a state machine, and a script that can reference the current transaction, the previous transaction with the output transferred by the current transaction, and possibly other previous transactions. With these tools, a transaction flow can execute a self-replicating script for use in a smart contract or other purposes.

[0300] Fig.13 An unlocking transaction 1320 and a previous transaction 1310 are shown. In this example, the unlocking transaction has an input Vin[0] 1322 that references a previous transaction and a transaction output Vout[x] 1314 of the previous transaction. In order for the unlocking transaction to be considered valid, the constraints of the locking script for Vout[x] must be satisfied. As described above, some constraints may be simple, such as a simple requirement that an unlocking script that points to an unlocking transaction input of a locking script must be able to provide a valid signature signed by a public key that appears on the locking script. However, as described herein, a locking script may provide more complex constraints.

[0301] For example, the locking script of Vout[x] 1314 of the previous transaction 1310 may impose specific constraints on the output of the unlocking transaction. In this example, the locking script of Vout[x] 1314 imposes a set of constraints (constraint set 1) on the output Vout[0] 1324 of the unlocking transaction 1320, and a set of constraints (constraint set 2) on the output Vout[0] 1326 of the unlocking transaction 1320. In certain cases, constraint set 1 and constraint set 2 are the same, and both only require that the locking scripts of outputs Vout[0] 1324 and Vout[1] 1326 be the same as the locking script of Vout[x] 1314 of the previous transaction 1310.

[0302] In more general cases, constraints may be more than just the requirement to copy the locking script. Furthermore, the set of constraints can vary from unlocking transaction output to output. Constraints could be the number of outputs an unlocking transaction can have, the value of each output, and something required in the locking script of an unlocking transaction output.

[0303] Injecting output constraints into unlocking transactions

[0304] Fig.14 Flowchart of an example of a portion 1400 of a locking script of a previous transaction that imposes constraints on the locking script of an unlocking transaction. The example can be performed by a stack-based verifier that processes the unlocking script of the output of the unlocking transaction, which can retain data on the stack, and then processes the locking script of the output of the previous transaction to perform the process. Because the processing of the unlocking script can retain data on the stack, and because the unlocking script can retain, for example, the serialized contents of the unlocking transaction (including the details of the locking script of the unlocking transaction) on the stack, these details can be available at the time of verification.

[0305] In step 1402 of the above process, the verifier verifies that the unlocking script contains certain data, and the verifier may perform other verifications that do not need to be completed on an output-by-output basis. Examples of such data may include a serialized set of unlocking transaction fields, a serialized previous transaction, a reference to a previous transaction, etc. In step 1404, the verifier checks whether these constraints are met, and if not, stops at step 1406, invalidating the unlocking transaction. Otherwise, processing continues at step 1408, where the verifier determines whether there are any unlocking transaction outputs to be checked. For the first pass, the verifier can set index i=0, and when there are no more outputs to check, go to another processing flow of step 1410.

[0306] For each index of the output, the verifier performs steps 1412, 1414, and 1416, then increments i (step 1418) and returns to step 1408 until there are no more indexes to consider. In another variation, the verifier may loop through a set of indexes to be checked, where the set of indexes does not necessarily include all values ​​of i and / or does not necessarily include them and verify them in increasing order, rather than incrementing the index by 1 and verifying each output. In such a variation, step 1418 is correspondingly different, looping through the indexes i of the outputs in the particular set of indexes being checked.

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

[0308] The locking script of the output of the previous transaction constrains the output of the unlocking transaction to allow the previous transaction locking script to specify rules about how the output of the unlocking transaction can be transferred. These constraints can be hard-coded in the locking script of the previous transaction output, or the constraints can be determined based on data present in the unlocking script of the input of the unlocking transaction pointing to the previous transaction output.

[0309] Fig.15 Shows the corresponding Fig.14 Some examples of more specific steps of steps 1402 and 1414 of the present invention. An example of a verifier performing step 1402 is performing step 1502, in which the verifier determines that some portion of the data in the unlocking script (or elsewhere) in the unlocking transaction input comes from a determined source. The determined source can be a serialization of the unlocking transaction or a serialized previous transaction. Alternatively or additionally, the verifier can perform step 1504 and perform some other verification of the unlocking transaction data details.

[0310] As for specific constraints that the locking script of the output of the previous transaction can impose on the locking script of the output of the unlocking transaction, there is step 1506, where the locking script of the output Vout[i] of the unlocking transaction must be equal to data from a certain source ("==" refers to an equality test). Another example is step 1508, where the locking script of the output Vout[i] of the unlocking transaction must be equal to data hard-coded into the locking script of the output of the previous transaction. Step 1510 covers the case where another constraint is imposed on the output Vout[i] of the unlocking transaction based on data from a certain 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.

[0311] In some cases, rather than using the entire data from the above sources or being hard-coded, a hash of the data may be used, in which case a comparison is made between the hashes.

[0312] The data to be used can come from the previous transaction, such as from a locking script that is hard-coded into the output of the previous transaction, or can be data from a previous transaction (or a reference to a previous transaction, two links away from the unlocking transaction) of the previous transaction (i.e., a transaction whose one or more 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).

[0313] Fig.16 An example of this is shown. Fig.14 Step 1402 in process 1400 (where verification is that the unlocking script has certain data) may perform steps 1602, 1604, 1608, 1610, and 1612 to verify that the unlocking script of the unlocking transaction has a reference to a transaction in the transaction chain.

[0314] In step 1602, the verifier extracts the transaction identification (TxID) from the input of the unlocking transaction, which it may do if available in the unlocking script. The verifier may then verify in step 1604 that the unlocking script also contains a serialized copy of the previous transaction for that TxID. If not, the verifier may invalidate the transaction, but if so, then 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 serialized copy of the transaction referenced by TxID′ or a reference to it. The chain may continue n times, where in step 1612, the verifier verifies that the TxID (n -1) '(n-1 prime numbers) The transaction referenced contains TxID n '(n prime numbers) refers to a serialized copy of the transaction.

[0315] exist Fig.16 In steps 1614 and 1616, steps 1614 and 1616 involve extracting the TxID n ′ and verifies the constraint that the locking script of the output Vout[i] of the unlocking transaction is equal to the extracted locking script of the transaction referenced by TxIDn′.

[0316] Constraints can be applied to subsets of an output's locking script, rather than the entire locking script. Constraints can be determined from subsets of the data, rather than the entire data. For example, one subset might require showing "Pay-to-Public-Key-Hash", and another subset might require showing "Pay to Bob".

[0317] Assume that the locking script of the output of the unlocking transaction can be composed of two parts ( <x> <y>) to indicate that <x>and <y>You can use string concatenation to extract the constraints so that they can be applied separately <x>and <y>An example is <x>Constrained to<PubK A> ,and <y>is constrained to OP_CHECKSIG. In this way, the entire locking script is constrained to<PubK A> OP_CHECKSIG. It is also possible to use constraints derived from data in the unlock script.

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

[0319] Constraints may correspond to indices that reference various outputs. In one case, the constraints are repeated for each index, but in other cases some structure may be provided. For example, the index of a constraint may be used in a conditional statement to select a set of constraints, such as "if index == 0: then constraint A, else constraint B".

[0320] If the set of indices is hardcoded, the results of the parts of the script that use the indices can 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.

[0321] Injecting input constraints for unlocking transactions

[0322] One use of having a locking script constrain the inputs of an unlocking transaction is to allow the locking script to encode dependencies on transactions with specific properties (e.g., the constrained input must reference that transaction). This is different from constraining the outputs of an unlocking transaction, in that outputs are mutable, while inputs can be references to pre-existing immutable UTXOs on the blockchain. In other words, outputs can be modified to match constraints, while inputs must be found to match those constraints.

[0323] Constraints on unlocking transaction inputs may be of two general types: (1) constraints placed directly on references to the inputs (i.e., the transaction TxID field, and optionally the output pointer field), and (2) constraints on fields of the previous transaction pointed to by the reference in the input.

[0324] Fig.17 A previous transaction 1710 and an unlocking transaction 1720 are shown, where the previous transaction 1710 has input Vin[y] 1712 and output Vout[x] 1714, and the unlocking transaction 1720 has inputs Vin[0] 1722 and Vin[1] 1723 and output Vout[0] 1724. The locking script of Vout[x] 1714 imposes a set of constraints (constraint set 1) on the input Vin[0] 1722 and a set of constraints (constraint set 2) on the input Vin[0] 1723. The constraint sets may include constraints on the unlocking script, references, or other parts of the inputs. The constraint sets can be the same or different, or there may be more than two inputs, some of which are the same and some of which are different.

[0325] In part, these constraints can reference parts of the unlocking transaction, for example by injecting a serialized set of the unlocking transaction fields as data into the unlocking script using the OP_SPENDINGTXINJECTION script.

[0326] Fig.18 Flowchart of an example of a portion 1800 of a locking script of a previous transaction that imposes constraints on the inputs of an unlocking transaction. The example can be executed by a validator that processes the unlocking script of the output of the unlocking transaction, which can leave data (including details of the unlocking transaction) on the stack, and then processes the locking script of the output of the previous transaction to perform the process.

[0327] In step 1802 of the process, the verifier verifies that the unlocking script contains certain data, and the verifier may perform other verifications that do not need to be done on an output-by-output basis. In step 1804, the verifier checks whether these constraints are met, and if not, stops at step 1806, invalidating the unlocking transaction. Otherwise, processing continues at step 1808, where the verifier determines whether there are any unlocking transaction inputs to check. For the first pass, the verifier can set index i=0, and when there are no more inputs to check, jump to another processing flow at step 1810.

[0328] 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 indexes to consider (or the verifier loops through the set of indexes to check, not necessarily all of them and / or not necessarily in increasing order; in these cases, step 1818 is correspondingly different, looping through the indexes i of the inputs being checked). In step 1812, the verifier extracts its reference to the previous transaction from the unlocking transaction input Vin[i] and outputs its unlock. This can be achieved using an OP_SUBSTR operation on the stack contents. Next, in step 1814, the verifier determines the constraints on the reference based on the locking script of the previous transaction output, or uses the reference to cause an injection of the previous transaction, after which the constraints can be applied to the fields of the previous transaction. In step 1816, the verifier then verifies these constraints. In this way, the locking script of the output of the previous transaction transferred by the input of the unlocking transaction can impose constraints on the input of the unlocking transaction.

[0329] Other examples of input constraints are in Fig.19 1902, 1904, 1906, 1910, 1912, and 1914. Since TxIDs may be a one-to-one mapping with transactions, this means that constraints may be that a specific transaction must be referenced in the input. The transaction that the locking script depends on may be created first, allowing the locking script to use its own TxID in the constraints on the inputs of the unlocking transaction.

[0330] A constraint can be placed on a field of a previous transaction that corresponds to a reference in an input. Before placing a constraint on a field of a previous transaction, the corresponding previous transaction can be injected by using the TxID in the input. A constraint can reference a different input than the one that is unlocking the output of a previous transaction that has a locking script that imposes the constraint.

[0331] Fig. 20 Shown in Fig.18 An example of constraints in the context of steps 1802 and 1814 of process 1800. Fig. 20 In the example above, steps 2002, 2004, 2014, and 2016 may be performed. In step 2002, the verifier extracts the transaction identifier (TxID) from the input of the unlocking transaction, which it may do if available in the unlocking script. The verifier may then verify in step 2004 that the unlocking script also contains a serialized copy of the previous transaction for that TxID. In step 1614, the verifier extracts a set of one or more fields from the previous transaction, and in step 1616 verifies certain constraints on the extracted set of fields.

[0332] Fig.21 Interlocking script constraints are shown. As shown, the input of the unlocking transaction (unlocking transaction 1) 2106 can reference the previous transaction (previous transaction 1) 2102 and the previous transaction 2104 (previous transaction 2). In particular, the input Vin[0] of unlocking transaction 1 points to Vout[0] of previous transaction 1, as shown by arrow 2110. Therefore, if unlocking transaction 1 is valid, Vout[0] of previous transaction 1 can be unlocked. Similarly, the input Vin[1] of unlocking transaction 1 points to the output[0] of previous transaction 2, as shown by arrow 2112. Such a reference may be a regular reference to an unlocking transaction with multiple inputs that reference multiple previous transactions.

[0333] In order to reference a previous transaction, these transactions should already exist and be immutable before the unlocking transaction is created. Nevertheless, the previous transaction can apply interdependent locking script constraints on the unlocking transaction. By constraining the input set of the unlocking transaction, interdependent locking scripts can be implemented, which can provide concurrency in the context of a trustless deterministic state machine.

[0334] The locking script 2120 of the output Vout[0] of the previous transaction 1 has a constraint on the input Vin[1] of the unlocking transaction 1, which requires that the pointer 2122 of the input (e.g., its reference to the previous transaction and the output of the previous transaction) is a reference to the previous transaction 2 and Vout[0] of the previous transaction 2. The locking script 2124 of the output Vout[0] of the previous transaction 2 has a constraint on the input Vin[0] of the unlocking transaction 1, which requires that the pointer 2126 of the input (e.g., its reference to the previous transaction and the output of the previous transaction) is a reference to the previous transaction 1 and Vout[0] of the previous transaction 1.

[0335] Since the TxID of a transaction is unknown until the transaction is completed, the transaction locking script cannot directly specify the TxID that the unlocking transaction unlocking script must reference, but this can basically be achieved by the locking script extracting a pointer to the input (including the TxID of the previous transaction with the locking script), injecting the fields of the previous transaction using that TxID, and verifying whether a certain field of the previous transaction is equal to the value it should be. In other words, if the previous transaction has a field set to a certain value, and the locking script of the previous transaction obtains the TxID from the unlocking transaction input, injects any transaction referenced by that TxID, checks the fields set to a specific value and the fields not set to that specific value, then the unlocking transaction input must point to a different previous transaction. Therefore, by checking that specific value, the locking script of the previous transaction output can determine whether the unlocking transaction input references that previous transaction output.

[0336] In this way, the previous transaction 1 indicates that its first output can only be transferred by a transaction that unlocks the first output of a specific transaction (previous transaction 2), and the previous transaction 2 indicates that its first output can only be transferred by a transaction that also unlocks the first output of the previous transaction 1.

[0337] Interdependent locking scripts allow multiple smart contracts to place conditions on each other. For example, smart contract 1 might be "Alice agrees to contribute 1BTC to Carol, but only if Bob contributes 2BTC to Carol", while smart contract 2 might be "Bob agrees to contribute 2BTC to Carol, but only if Alice agrees to contribute 1BTC to Carol". To be valid, the unlocking transaction must unlock both smart contracts.

[0338] As mentioned above, a locking script can encode dependencies into a transaction with certain properties, and these properties can include fields of that transaction. This means that a locking script may depend on a transaction with a specific locking script.

[0339] For example, in Fig.21 In the illustration of , locking script #1 (of Vout[0] of previous transaction 1) constrains Vin[1] of unlocking transaction 1 to reference locking script 2124 (of Vout[0] of previous transaction 2), and locking script #3 2124 constrains Vout[0] of unlocking transaction 1 to reference locking script #1 of Vout[0] of previous transaction 1. In this article, this may be referred to as a locking script that encodes a dependency of another locking script.

[0340] Implementing interdependent lock scripts can create causal race conditions 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 one of previous transaction 1 and previous transaction 2 may have existed before the other. If lock script A hard codes the dependency onto lock script B, then lock script B must be known and fixed, making it impossible for lock script B to hard code a dependency on an unknown lock script A. This can be solved by having determinable dependencies in at least one lock script.

[0341] As an example, locking script A depends on locking script X, and locking script X will be provided in unlocking script A, and locking script B depends on locking script Y, which will be provided in unlocking script B. When the unlocking transaction is created, both locking script A and locking script B are known, enabling unlocking script A of the unlocking transaction to include locking script B as its data, and enabling unlocking script B of the unlocking transaction to include locking script A as its data.

[0342] In some variations, for an unlocking transaction input to be verified, its unlocking script must reference both previous transaction 1 and previous transaction 2. In other variations, it is sufficient for the unlocking script to reference any two (or more) previous transactions that have the same locking script as previous transaction 1.

[0343] In some variations, the requirement may be exclusive, rather than mandating that the unlocking script reference a specific previous transaction or set of previous transactions, as the requirement may be that the unlocking script not reference a specific previous transaction or set of previous transactions. Combinations of these variations are also possible, effectively implementing Boolean logic on previously referenced transactions. For example, a requirement may be that for the unlocking transaction input to be verified, its unlocking script must reference previous transaction 1 and previous transaction 2, not reference previous transaction 1, and must reference previous transaction B or previous transaction C. Other logical expressions are also possible.

[0344] State Machine

[0345] Using the above techniques, a state machine can be implemented using blockchain transactions, where transactions have states and are encoded using a state machine structure (e.g., through a transition matrix and permitted next states). An unlocking transaction can unlock the output of such a blockchain transaction, effectively causing a state transition of the state machine.

[0346] Fig. 22 An example 2200 of a state machine implemented using blockchain transactions is shown. Specifically, Fig. 22 A state machine is depicted that uses blockchain transactions to transition from a first state to a second state. In some examples, the state transitions of the state machine are interpreted as determining a next state given (1) a current state, (2) one or more inputs 2226, and (3) a set of state rules 2206. Fig. 22 Example 2200 shows a previous transaction 2202 with a state rule set 2206 and a first state 2228A embedded in the parameters. In some embodiments, the unlock transaction 2204 is created to accept an input 2226 from a determined source. In conjunction with the first state 2228A, the input 2226 can be used to reference the state rule set 2206 to determine a second state 2228B embedded in the parameters of the unlock transaction 2204.

[0347] In an embodiment, the state rule set 2206 includes a state transaction matrix, which can be represented by the constraints imposed by the locking script on the unlocking transaction 2204. In such an embodiment, the constraints can be parameterized by the current state and the inputs from which the next state is determined. The constraints can include checks to ensure that the unlocking transaction 2204 includes an output that includes a next-state value in a particular field.

[0348] In an embodiment, the current state is represented as a parameter embedded in a transaction, such as part of a locking script of an output of that transaction, and the unlocking transaction 2204 may have a next-state value also embedded in the unlocking transaction 2204. The next-state value may be the current state relative to a set of field values ​​of the unlocking transaction 2204, which may be accessible when the unlocking transaction 2204 is created, as described above.

[0349] In some embodiments, at least one input is provided as external data in the parameters determined when creating the unlock transaction 2204. For security, these parameters come from a deterministic source. This can provide a deterministic state transition. Finally, by using a script that self-replicates the locking script, an embodiment of a trustless, deterministic state machine can be created. By further allowing different locking scripts to be applied on different transaction inputs and outputs of a transaction, a concurrent trustless, deterministic state machine can be implemented.

[0350] Fig.23 This is illustrated. In this example, the 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 the locking script of the output of the previous transaction 2302. The current state 2328A may be embedded in a lock time field, or may be embedded in a locking script. The next state (S2 2328B in this example) is encoded in the locking script of the output of the unlocking transaction, which unlocks the output of the previous transaction to achieve the state transition.

[0351] As can be seen in example 2300, the unlocking transaction 2304 takes as input the input 2326 in its unlocking script and the first state 2328A ("S1") embedded in the field value set of the previous transaction 2302, and determines the appropriate second state 2328B ("S2") from the state rule set 2306. It can also be seen from example 2300 that the state transition matrix now provides a new state 2330B ("S4" or "S5") that is possible for the next state transition from the second state 2328B. Note that the state rule set 2306 can 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 can be embedded in the lock time field and can also be embedded in the locking script. The next state (S2 2328B in this example) is encoded in the locking script of the output of the unlocking transaction, which unlocks the output of the previous transaction to achieve the state transition.

[0352] In an embodiment, in a self-replicating locking script, each possible state is represented in a set of rules for state changes (e.g., a state transition matrix), and a specific transaction output represents a state machine in a specific state. In such an embodiment, the locking script of the transaction output is copied to each unlocking transaction that attempts to transfer control of the digital asset to the next transaction, which must be linked to the current transaction output. This process can be repeated until the termination condition is met. Because the input is not fixed and may be undetermined data, the state of the state machine can be changed according to specific external inputs. Therefore, the undetermined data provides input that may affect the next state.

[0353] In an illustrative example, Alice lends Bob some money, and Bob agrees to pay Alice back. As described in the present invention, a trustless, deterministic state machine can be implemented as a smart contract to represent the payment made by Bob to Alice. For example, a smart contract can be constructed so that Bob pays Alice monthly for the next three months, and if a payment is missed, Bob's debt enters the debt collection phase. Therefore, as long as Bob pays monthly, the current state remains in the repayment state. However, if an external entity provides an input indicating that Bob has missed a payment, the state transitions to the missed payment state. In the unpaid state, Alice can release the transaction and hand it over to the debt collector, so the untrusted deterministic state machine switches to the debt collection state. In the debt collection state, the debt collector will collect debts from Bob. Such a smart contract can be created using a variation of the script described herein.

[0354] In another example, Alice is a very charitable person who gives away one unit of a digital asset each month. Her rule may be that anyone can claim the digital asset, but only one unit per month. Alice creates a smart contract in the manner described in this invention and seeds it with an initial pool of 3 units of the digital asset. Alice can construct a script that allows any entity to take 1 unit of the digital asset each month. The remainder of the digital asset is copied to subsequent smart contracts.

[0355] Fig.24 The unlocking script and the locking script of the exemplary trustless deterministic state machine of the present invention are shown.

[0356] Fig.25 is a flow chart illustrating an example of a process 2500 for a trustless deterministic state machine according to various embodiments. An example script to achieve this is Fig.24 Script. Some or all of process 2500 (or any other process described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data, and may be implemented as executable instructions that are collectively executed on one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium). These instructions may be executed as part of a blockchain transaction verification process.

[0357] For example, some or all of process 2500 may be implemented by an exemplary blockchain network (e.g. Figure 1 The process 2500 is performed by a verification node in the exemplary blockchain network 100 of FIG. 2501 . Such a verification node may include any suitable computing device (e.g., through a server in a data center, through a client computing device, through multiple computing devices in a distributed system of a computing resource service provider, or through any suitable electronic client device). The process 2500 includes a series of operations in which a locking script of a self-replicating smart contract is verified, a current state can be obtained from a serialized previous transaction, an input can be obtained from an unlocking script, and a next state can be determined based at least in part on a set of state rules.

[0358] At step 2502, the system receives an unlock transaction. The system first runs the unlock script of the unlock transaction input, which will cause the serialized previous transaction and the inputs embedded in the locking script to be placed on the stack. These inputs can be retrieved at 2512. At 2504, the system executing process 2500 determines whether a termination condition is met. In an embodiment, a termination condition is a condition that, once met, causes the state machine transition to end. If the termination condition is met, the system executing process 2500 proceeds to 2506, whereupon the trustless deterministic state machine stops self-replication and / or propagation of states.

[0359] At step 2508, the system verifies that the previous transaction output locking script matches the unlocking transaction output locking script. If the locking scripts do not match, the verification fails and the unlocking transaction may not be verified. Otherwise, if the locking scripts match, then in 2510, the system extracts the current state of the possible state set from the serialized previous transaction. At 2512, the system obtains one or more inputs placed on the stack as a result of the execution of the locking script. Then, at 2514, the system applies a set of state rules to determine the next state of the possible state set of the trustless deterministic state machine based on the current state and one or more inputs. At 2516, the system can verify that the next state (e.g., state variables and other state-related data, if applicable) is embedded in the unlocking transaction. The system can also apply any remaining constraints specified in the locking script. After successfully completing the operations of 2502 to 2516, the process ends with 2518, and the system executing the process can then consider the unlocking transaction valid. Note that one or more operations performed in steps 2502 to 2518 can be performed in various orders and combinations, including parallel execution.

[0360] Note that in the context of describing the disclosed embodiments, unless otherwise stated, expressions relating to executable instructions (also referred to as code, applications, agents, etc.) are used to perform operations that the "instructions" do not typically perform alone (e.g., data transfer, computation, etc.), indicating that the instructions are being executed by a machine, causing the machine to perform the specified operations.

[0361] As a state machine for blockchain transactions

[0362] Using the above techniques and devices, a state machine can be implemented using blockchain transactions. A state machine can be operated by causing states to change from one state to another along a state transition matrix. Some state diagrams can be very complex and have multiple paths. In this case, some of the computations performed by the state machine can be performed simultaneously with other computations. As described below, a state machine can be operated using blockchain transactions and partially simultaneously.

[0363] As described below, a trustless deterministic state machine can be implemented using the locking script and unlocking script of a blockchain transaction. The locking script contains constraints that can be imposed on the unlocking script, so it can be required that certain data be injected into the unlocking script of the unlocking transaction input, such as a serialized field of the unlocking transaction itself, a serialized field of the previous transaction containing the locking script being executed, the current state value, inputs from a deterministic source (optional), and a state transition matrix that defines the set of flow conditions and operations of the state machine and specifies how to calculate the next state from the current state and other inputs. One locking script constraint of the unlocking transaction may be that the unlocking transaction must replicate the locking script in one of its outputs, thereby propagating the state machine.

[0364] Fig.26 A state machine using a state transition matrix 2600 with certain features is shown. State S1 is highlighted to indicate the current state. The state machine can transfer to any state along the state transition (as shown by the arrows). In the state transition matrix, there may be possible transitions along S1-S2-S3-S4-S8-S12, but the transition from state S1 may also require being in state S5. Similarly, state S5 transitions to S6 and S9. The transition from state S9 to state S10 can be conditional or barriered because the state transition cannot occur until the transition from state S6 to state S7 occurs at the same time. The transition to state S8 can occur as a merge of state S4 and state S7.

[0365] Each of these states can be entered through a state machine represented by a blockchain transaction output, and each transition is handled by a single path of transaction outputs. A state transition occurs when an unlocking transaction input unlocks the previous transaction output (e.g. Fig. 22 or Fig.23 ). However, by leveraging the inputs and outputs of blockchain transactions, parallel processing of state can be achieved. This can be useful when a smart contract needs to be executed in multiple concurrent steps. During a contract process, tasks can sometimes be executed simultaneously during the contract process. For example, a contract to build a house may have different completion stages for tiling work and different completion stages for landscaping, which may be executable in parallel. By allowing concurrency in smart contracts, different pieces of a contact can be executed independently of each other in an asynchronous manner.

[0366] Fig.26 A number of requirements for this processing are shown. One requirement is the creation of multiple paths from a state. This could be a fork of a smart contract. Assume that the smart contract starts at S1. A fork of the smart contract could create two state machines, one at state S2 and one at state S5. Another requirement could be a clone of the smart contract to have two identical state machines running in parallel, each in the same state. For example, a smart contract could require multiple instances of the S2-S3-S4 steps. This could also be a clone of a smart contract, which is a special case of a fork where two or more new transaction outputs have the same state.

[0367] Another useful feature is the generation of new contracts. For example, Fig.26 The state transition matrix 2600 of the smart contract may be such that, in state S3, a party to the smart contract will create a separate contract that may be associated with the smart contract but may not be part of the smart contract and / or may be created after the smart contract is created. This may be referred to herein as spawning. The new contract may be different from the one originally provided. Fig.26 The original smart contract of the state transition diagram.

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

[0369] Fig. 27 An example of a transaction with one input Vin[0] and two outputs Vout[0] and Vout[1] is shown. By unlocking the outputs of this transaction, two separate transactions will be recorded in the blockchain ledger, and the creators of these transactions will be compensated by some value provided to them by the transaction (not shown). As shown, the locking script of the previous transaction output (pointed to by Vin[0]) requires that the unlocking transaction that unlocks this output contains states S2 and S5. In order to unlock the output of the unlocking transaction containing state S2 ( Fig. 27 Vout[0] in , future unlocking transactions based on the current state S2 will be constrained to include the next state. The same is true for the S5 state.

[0370] In this way, transaction outputs can have states and impose constraints on the states that the unlocking transaction can be in. Thus, blockchain transactions can be Fig.26 The state diagram shown implements the processing, and the unlocking of the transaction output corresponds to the state transition of the state diagram. To prevent someone from creating a transaction with multiple inputs and unlocking both outputs of the transaction shown, the locking script can check for this and prohibit it. The rules for how to generate valid transactions (such as how many outputs are required) can be encoded in the smart contract as hard-coded values ​​or parameters that can be provided after the smart contract is created.

[0371] Forking and cloning smart contracts using blockchain transactions

[0372] A fork can be used when a state needs to transition to two or more (not necessarily unique) next states simultaneously. Sometimes a smart contract can be processed without all possible concurrency, but in the case of concurrency, a fork can initiate it. As described above, the locking script of the output of a smart contract transaction on the blockchain ledger can "impose" requirements on the input of the unlocking transaction and / or the locking script of the output of the unlocking transaction on the blockchain ledger. A clone may be a specific type of fork where the next set of states may all be the same state. In the case of an unlocking transaction, multiple outputs may be constrained to copy the transition matrix and embed their respective next states.

[0373] Forking / cloning can be achieved by applying constraints of a trustless deterministic state machine to a set of outputs. As mentioned above, the 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.

[0374] Since a given unlocking transaction may have multiple outputs, some of which may be unrelated to the state machine, or related to multiple unrelated state machines, it may be more practical to embed the next state in the transaction's locking script rather than embedding it in a common field for all outputs (such as the lock time field). A subset of constraint output locking scripts is described above.

[0375] Fig.28 It shows how the script is related to the fork operation. As shown, the state machine 2810 is implemented using the previous transaction 2820 and the unlocking transaction 2830. The locking script of the previous transaction 2820 constrains the unlocking transaction 2830 to have at least two outputs, each of which requires the subsequent unlocking transaction to have an output in a specified state (and is a separate transaction). This can allow those states S2, S3 to be executed independently and possibly simultaneously.

[0376] With state machines, subtasks become useful for enabling faster concurrent smart contracts. To handle subtasks, multiple states can be used, and since a state machine can usually only be in a single state at a time, concurrency can be provided by having independent transaction threads. State machines can be forked by creating multiple transaction locking scripts. Based on the current state from the previous transaction output, the unlocking transaction can be constrained to have two or more outputs with locking scripts (such as Fig.28 To prevent the fork from becoming irredeemable and halting prematurely, each output value should be checked to ensure that there are sufficient funds to continue the state machine.

[0377] As shown by the dotted arrow, the input Vin[0] of the unlocking transaction 2830 points to the previous transaction 2820 and the output Vout[0] of that transaction. The locking script of Vout[0] includes the current state ("S1"), the transition matrix of the state machine, and constrains Vout[x] of the unlocking transaction 2830 to be in the next state ("S3") and Vout[y] of the unlocking transaction 2830 to be in another next state ("S2"), each state is also constrained to carry the state transition matrix and possible other constraints.

[0378] The locking script of the previous transaction output may include the concatenation of <current state><transition matrix><other scripts>, while the locking script of the output of the unlocking transaction may include the concatenation of <next state><transition matrix><other scripts>. Instead of copying the entire locking script, only a subset of the locking script may be copied, and another subset may be constrained to contain the state.

[0379] Instead of being stored in the lock script, the state of the state machine can be stored in transaction fields that may not be used for other purposes (such as the lock time field). In fact, different unused transaction fields can be used. This works for a single state, and also for the case where multiple states need to be stored, although the latter may be more complicated.

[0380] Fig.29 Example pseudocode that can be executed to implement a fork or clone process is shown. The pseudocode can be implemented using the operation code described herein. The pseudocode can be executed by a processor of a blockchain node that creates a transaction and / or verifies a transaction. In some embodiments, a portion of the script comes from an unlocking script and a portion of the script comes from a locking script.

[0381] exist Fig.29 In the pseudo code of , the previous transaction, unlocking transaction, and optional inputs are injected so that the locking script can access them. Then, the termination condition may be checked. If the smart contract does not terminate, the processor extracts the previous transaction lock script and the previous transaction current state, which can be done using the techniques described in this article. The processor then loops through the outputs of the unlocking transaction, and for each unlocking transaction output, extracts its lock script and checks the transition matrix in the previous transaction lock script to determine whether it matches the transition matrix in the lock script of the unlocking transaction output being processed. If they do not match, the processor treats it as a script failure, stops, and does not verify the unlocking transaction. If they match, the processor determines the next state of the state machine based on the extracted current state, the state transition matrix (optionally the input), and the output index value. The processor then checks the determined next state against the next state in the unlocking transaction output being processed. If they do not match, the processor treats it as a script failure, stops, and does not verify the unlocking transaction. If there are other optional constraints to check, these constraints can be checked at this time. If all constraints are met, the script passes.

[0382] Workers produce smart contracts

[0383] In the previous section, the ability to fork and clone smart contracts was described. This section details the ability to force a new smart contract to appear in the unlock transaction, which could be a completely different state machine or a completely different type of smart contract that may not be a state machine.

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

[0385] As described above, a new smart contract, which may be a state machine, is created. This new smart contract may be the same state machine as the previous transaction, or a completely different state machine. The new state and transition matrix may be checked. This may be done independently (e.g., checking the new state and then checking the transition matrix value), or together.

[0386] Although not in Fig.30 As shown in , the new smart contract may not be a state machine. In this case, the next state value may or may not be needed, but the new smart contract can be verified using an equality check of the script or its hash.

[0387] A new smart contract can be generated using a new smart contract that converts from the current state in the previous transaction and the output of the unlocking transaction. In the example shown, the first set of outputs of the unlocking transaction is constrained to copy the state transition matrix and embed the next (multiple) states, and the second set of outputs is constrained to contain the new smart contract. The output of the unlocking transaction can be constrained to contain a new locking script, and by using multiple indexes, different constraints can be applied to different outputs. The new set of smart contracts can be hard-coded in the transition matrix, or provided as part of the input.

[0388] From a state machine perspective, a state machine can instantiate a new, different state machine to execute concurrently with the calling state machine. To apply this approach to state machines, the locking script for this operation could be similar to the locking script for a fork / clone operation, but instead of checking for equality in the locking script of each new state machine instance, the existence of the new smart contract can be checked. The equality check can be performed on a range of different values, including a serialized set of transaction fields of the transaction, the locking script bytecode, or a hash of these values.

[0389] Fig.30 The generation of a new smart contract is shown. As shown, the state machine 3010 is implemented using the previous transaction 3020 and the unlocking transaction 3030. The locking script of the output Vout[0] of the previous transaction 3020 constrains the unlocking transaction 3030 to have at least two outputs (Vout[x] and Vout[y]), each of which requires a subsequent unlocking transaction to have an output of a specified state (and is a separate transaction). Specifically, as shown, in order to make the input Vin[0] of the unlocking transaction 3030 unlock Vout[0] of the previous transaction 3020, the unlocking transaction 3030 can be constrained to make Vout[x] have a transition matrix and be in state S4, while also constraining Vout[y] to have a new smart contract.

[0390] Using this approach, a 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 mentioned 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.

[0391] like Fig.30 As shown by the dashed arrow, the input Vin[0] of the unlocking transaction 3030 points to the previous transaction 3020 and the output Vout[0] of that transaction. This can 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 locking script for Vout[0] includes the current state ("S3"), the transition matrix of the state machine, and constrains Vout[x] of the unlocking transaction 3030 to be the state machine in the next state ("S4"), constrains Vout[y] of the unlocking transaction 3030 to be a new smart contract ("NSC"), and possible other constraints.

[0392] As an example, pseudo code for the worker generation process and the process of forcing a new smart contract to appear in the unlocking transaction can be as follows Fig.31 shown.

[0393] Merging Smart Contracts

[0394] In situations where two or more states need to merge to the same next state, a merge or join of states can be used. In some cases, concurrently running state machines may find themselves in the same state, but if the smart contract does not require a merge, they will not be merged. For example, using Fig.26 In the state diagram, S4 and S7 may each transition to S8 and remain as two separate transactions.

[0395] Fig.32 The merge operation of state machine 3210 is shown. In this case, unlock transaction 3230 (inputs Vin[0] and Vin[1] and output Vout[x]) unlocks output Vout[0] of previous transaction 3220 and previous transaction 3222. Using these techniques, a smart contract can branch out by instantiating a new instance of itself or instantiating a different smart contract, and multiple smart contracts (the same or different) can be merged through their corresponding state machines to form a single smart contract.

[0396] Each merge-unlock transaction can have a locking script. This locking script continues the execution of a single smart contract. This can be one of the smart contracts being merged, or a completely new smart contract. In any case, a number of checks can be performed. Each smart contract can be checked as a valid input to the unlock transaction. This can be performed by using the validation of the previous transaction.

[0397] like Fig.32 As shown, Vin[0] points to the previous transaction 3220 and its output Vout[0], while Vin[1] points to the previous transaction 3222 and its output Vout[0]. The locking scripts of the two Vout[0] constrain the Vout[x] of the unlocking transaction 3230 to have the next state S8 and the state transition matrix. These constraints can be implemented by checking that the new smart contract is the output of the unlocking transaction by the locking script 3222 of the previous transaction.

[0398] To implement this using concurrent state machines, a transaction can use multiple inputs, one for each state machine that needs to be joined. In the state machine transition matrix, constraints can be added to check the states of all the independent state machines that are joined. If one of the state machines that are joined is not in a state that allows convergence, the transaction may be rejected. To ensure the join operation, a constraint can be added to the state machine to check if two unlocking scripts exist based on the state in the unlocking transaction. A check can be done on each script to ensure that each is in the correct state required for the transition. Interdependent locking constraints can also be used as explained elsewhere in this article.

[0399] Fig.33 A pseudocode sequence is shown as an example of the process of merging smart contracts in an unlock transaction with weak dependencies. For merging, a transition occurs from a set of current states (not necessarily unique states) to a shared set of next states. In the case of an unlock transaction, its set of inputs can unlock a set of locking scripts that share the constraint that the same output must replicate the transition matrix and embed the same next state. For weak dependencies, there may be multiple state machines that happen to have the same next state for the same output.

[0400] according to Fig.32 and Fig.33 The merge can occur with weak dependencies. Locking scripts can contain other constraints, such as mutual dependencies, forks, generating new smart contracts, etc. As an example of weak dependencies, in the case where a merge happens to occur, locking script 1 can be a fork from state A to states X and Y, while locking script 2 can be a normal transition from state B to state X. These two locking scripts happen to constrain the output of the unlocking transaction to contain state X.

[0401] exist Fig.33 In a pseudocode sequence of , a processor that processes a script according to the pseudocode sequence can inject the previous transaction, the unlocking transaction, and optionally some input data, and check the termination condition before continuing. The processor then extracts the previous transaction lock script and the unlocking transaction lock script. Next, the processor can check whether the transition matrix in the previous transaction lock script is equal to the transition matrix in the unlocking transaction lock script, and if not, abort. The processor extracts the current state value of the previous transaction from it, and determines the next state from the current state value and from the transition matrix and input (if used), and checks the next state to determine whether it matches the next state in the unlocking transaction lock script. Optionally, other constraints can be checked here.

[0402] Fig.34 A pseudocode sequence is shown as an example of the process of merging smart contracts in an unlock transaction with explicit dependencies. For explicit dependencies, there may be multiple state machines, and it may not be sufficient that they happen to have the same next state for the same output, but furthermore, they may be specifically different state machines. Fig.32 and Fig.34 The merging of can occur through explicit dependencies. Under strong constraints, an unlocking transaction may need to point to two or more specific merged state machines.

[0403] exist Fig.34 In a pseudocode sequence of , a processor that processes a script according to the pseudocode sequence can inject a previous transaction, an unlocking transaction, and optionally some input data, and check the termination condition before continuing. The processor then extracts the unlocking transaction lock script. Next, the processor can loop through the input index set and extract its corresponding previous transaction lock script, and check whether the transition matrix in the corresponding previous transaction lock script is equal to the transition matrix in the unlocking transaction lock script, and if not, abort. The processor extracts the current state value of the previous transaction from it and appends it to the current state list, and then repeats for other inputs. Based on 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 unlocking transaction lock script. Optionally, other constraints can be checked here.

[0404] Parallel Smart Contracts / Barriers

[0405] As mentioned above, two or more smart contracts can be combined into one smart contract with either weak or strong constraints. It may also be useful to have two or more smart contracts that can be executed in parallel. This may be more than just concurrent processing, as the constraint may be that two concurrent paths must pass through an unlocking transaction. This can also be used for "barriers" in concurrent state machines, where a specific transition is not allowed to occur until another transition occurs elsewhere in the state machine.

[0406] Fig.35 Parallel processing operations are shown. 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 a separate smart contract. Unlock transaction 3530 contains an unlocking script, which interprets the script containing each previous transaction of the smart contract. In addition, the locking script of each smart contract may be required to continue execution. With parallel smart contracts, each contract cannot be transformed independently, but all contracts (as defined in the locking script) need to occur at the same time.

[0407] Previous examples provided for forking a smart contract, merging two smart contracts, and parallel operations of two (or more smart contracts). These can be used in conjunction with parallel smart contracts. Barriers can be used when a state transition has a logical relationship to another state transition. For example, it may require another state machine to be in a specific state, or require input data from that state machine.

[0408] An unlocking transaction can be created to facilitate this function, which includes multiple inputs and outputs. Each state machine required in the barrier (either in a transition or involved in a constraint) can be included in its own unlocking script. For each state machine that is undergoing a transition, a locking script can be used. Fig.26 In the example shown, the transition from state S9 to S10 is allowed, but only if the transition from S6 to S7 occurs at the same time. To do this, there are two unlocking scripts in the unlocking transaction, one for the state machine in state S6 and one for the state machine in state S9. The unlocking transaction has two locking scripts, one for the state machine still in S7 and one for the state machine now in S10.

[0409] Fig.36 is a pseudocode sequence that serves as an example of using barriers in a parallel state machine that requires parallel transaction input / output. In this example, the script according to the pseudocode sequence checks whether each previous transaction has the same locking script as in the unlocking transaction. In this example, a locking script is set to match the first previous transaction, and so on. Next, the script according to the pseudocode sequence extracts the current state from the two previous transactions, reads the inputs of the two state machines, and checks any barriers set for the two state transitions.

[0410] Back to Fig.35 , various dependencies are shown using dashed arrows and numbered circles. Dependency #1 might be that Vin[0] must reference the previous transaction 3520, dependency #2 might be that Vin[0] must reference the first output (Vout[0]) of a given transaction (previous transaction 3520), dependency #3 might be that Vin[1] must reference the previous transaction 3522, and dependency #4 might be that Vin[1] must reference the first output (Vout[0]) of a given transaction (previous transaction 3522). This might be just two dependencies, one that Vin[0] must reference Vout[0] of transaction 3520, and another that Vin[1] must reference Vout[0] of transaction 3522.

[0411] The locking script of Vout[0] of the previous transaction 3520 imposes dependency #5, which requires Vout[x] to have state = S8 and have a transition matrix for state machine 1, and imposes dependency #6, which requires Vout[y] to have state = S8 and have a transition matrix for state machine 2. The locking script of Vout[0] of the previous transaction 3522 imposes dependencies #7 and #8 in a similar manner. In some examples, it may be a constraint of some other form of smart contract rather than a constraint of a state machine. Since two (or more) previous transaction outputs constrain two (or more) unlocking transaction outputs, parallel smart contracts can be provided.

[0412] Barriers may be different from merges. A barrier may be a case where a set of transitions from the current state (not necessarily the only state) are constrained to occur simultaneously. In the case of an unlocking transaction, its set of inputs may unlock a set of interdependent locking scripts, all of which may apply their respective constraints to the set of outputs. Interdependent locking scripts may be a requirement as well as a shared set of next states, which, while possible, may not be necessary. Interdependent locking scripts may be embedded in the transition matrix such that certain transitions require this interdependency.

[0413] Fig.37 A state diagram for a use case of a barrier / parallel smart contract is shown. Assume Alice and Bob are learning to dance and go to dance lessons. As a way to keep track of the dance students' progress, their progress can be recorded using a state machine. First, there may be a state machine between levels, containing states about their overall dance ability in various dance types. This is reflected in states S1, S3, S5, and finally S6. The states for these grades progress in sequence until the student reaches the highest grade supported by the dance club. In order to advance to the next grade (for example, from S1 to S3), the student may need to learn several dance types. Smaller embedded state machines (for example, S2 and S4) can be used to monitor each dance type. In this use case, the following operations can exist:

[0414] 1) Fork or clone - This can be used at points S1 and S5 to indicate the start of a new level, whereby there can be a fork to multiple state machines, one for each dance type.

[0415] 2) Worker Generation - This might be used at some point when a particular dance type requires more lessons or is evaluated differently than the other dance types offered.

[0416] 3) Merge - This process can be used at points S3 and S6 when students reach a new level. For the new level, each student needs to be evaluated at the final state S4 of the embedded dance state machine.

[0417] 4) Parallel Transactions / Barriers - This can be used to constrain the state transitions between one state machine and another. In the case of this use case, we can assume that the transitions between S2 and S4 need to happen at the same time, as you cannot dance a single type of dance in a single class.

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

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

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

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

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

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

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

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

Claims

1. A computer-implemented method comprising: Determining a first set of constraints to be applied to a first locking script in a first transaction output; determining a second set of constraints to be applied to a second locking script in the second transaction output; An initial blockchain transaction is created, the initial blockchain transaction comprising: at least one initial locking script, the initial locking script comprising the first set of constraints and the second set of constraints, and at least one redeemable value; Creating an unlocking blockchain transaction, the unlocking blockchain transaction including the first transaction output and the second transaction output; verifying that the first locking script satisfies the first set of constraints and the second locking script satisfies the second set of constraints; and The initial blockchain transaction is verified at a node of the blockchain network.

2. The computer-implemented method of claim 1 , wherein: The first locking script is a copy of the second locking script.

3. The computer-implemented method of claim 1 , wherein: The first locking script is different from the second locking script.

4. The computer-implemented method of claim 1 , wherein: The first locking script includes at least a portion of the at least one initial locking script.

5. The computer-implemented method of claim 4, wherein: Execution of the at least one initial locking script selects the at least one portion from among a plurality of portions of the at least one initial locking script.

6. The computer-implemented method of claim 1 , wherein: Execution of the unlocking script of the unlocking transaction causes the at least one initial locking script to receive data corresponding to one of the first transaction output or the second transaction output.

7. The computer-implemented method of claim 6, wherein: The data is an index value; In a case where the index value is a first index value, execution of the at least one initial locking script determines whether the first set of constraints is satisfied; and In a case where the index value is a second index value, execution of the at least one initial locking script determines whether the second set of constraints is satisfied.

8. The computer-implemented method of claim 6, wherein: The data includes a new locking script; and As a result of receiving the data, the first transaction output is constrained to include the new locking script.

9. The computer-implemented method of claim 6, wherein: The at least one initial locking script includes constraints on the source of the data.

10. The computer-implemented method of claim 1 , further comprising: Determine a redeemable value for the first transaction output.

11. The computer-implemented method of claim 1 , wherein: The initial blockchain transaction encodes a contract having multiple states.

12. The computer-implemented method of claim 11, wherein: The unlock transaction includes a plurality of input values ​​corresponding to the plurality of states.

13. The computer-implemented method of claim 12, wherein: The first set of constraints constrains the first transaction output to have a first state; and The second set of constraints constrains the second transaction output to have a second state.

14. A system comprising: processor; and A memory comprising executable instructions which, when executed by the processor, cause the system to perform a computer-implemented method according to any one of claims 1 to 13.

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

Images