Parallel State Machine Processing Using Blockchain

Abstract

To provide a method for implementing a state machine in the structure of block chain transaction processing including a trustless, deterministic and parallel state machine.SOLUTION: A method for trustless, deterministic state machines determines an unlocked transaction constraint for restricting unlocked transactions so as to include a transaction input that refers to the output of a preceding transaction, and generates a redeemable transaction so as to include a transaction output that includes a quantity and a transaction lock script. The transaction lock script includes an unlocked transaction constraint, and unlocking the quantity is premised on condition that at least one unlock script of an unlocked transaction that satisfies the unlocked transaction constraint is executed. The redeemable transaction is verified in a node 102 of a block chain network 100.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to a method for processing blockchain transactions implemented by a computer, and more particularly to implementing a state machine within the structure of blockchain transaction processing, including trustless, deterministic, and concurrent state machines. The present invention further utilizes cryptographic and mathematical techniques to implement security with respect to electronic transfers occurring on a blockchain network. The present invention is particularly suitable for use in a method and apparatus for processing and performing smart contract transactions and executing a state machine using such smart contract transactions, but is not limited thereto.

Background Art

[0002] As used herein, the term "blockchain" can represent any of several types of electronic, computer-based distributed ledgers, including consensus-based blockchains and transaction chain technologies, authorized and unauthorized ledgers, shared ledgers, and variations thereof. The most widely known use of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. For convenience and illustrative purposes, examples of "Bitcoin" may be referred to as useful applications described in this application, but Bitcoin is only one of many applications to which the technology described in this disclosure may be applied. However, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols, including non-commercial applications, are also within the scope of the present invention. For example, the technology described in this disclosure provides the advantage of utilizing blockchain implementations that have similar limitations to Bitcoin with respect to constraints that can be encoded within a transaction, regardless of whether a cryptocurrency exchange occurs.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, where a block is composed 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 satisfaction of the set of conditions is a prerequisite for the set of fields written to the blockchain data structure. A blockchain system or blockchain network may include multiple blockchain nodes and a set of operations. A blockchain node can be set to execute some or all of the set of operations. Various blockchain nodes may be implemented as computer hardware, computer software, or a combination of both operated by a node operator, and the node operator may be independent and unrelated to other node operators. Each blockchain node can hold a copy of the blockchain ledger, or a part thereof. The set of operations includes creation of transactions, propagation of transactions, reading of the blockchain ledger, evaluation of the blockchain ledger, generation (mining) of new blocks for proposed additions to the blockchain ledger, communication with other blockchain nodes, and provision of a wallet function for users to manage blockchain assets.

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

[0005] One of the rules of the blockchain protocol is that once a block is added to the blockchain, it cannot be changed, i.e., it is immutable, and the only thing that can be changed in the blockchain ledger is the addition of new blocks. Since blockchain nodes can be programmed as such as a rule, a blockchain node cannot modify the blocks in its copy of the blockchain ledger and can only add blocks. Further, in order to ensure compliance with the blockchain protocol, a block can only be added after performing a verification process on the proposed block. Since such a block is immutable once added to the ledger, the transactions within the block may also be immutable.

[0006] When creating a transaction, a blockchain node may create a data object containing the details of the transaction and typically propagate the data object in a peer-to-peer manner to other blockchain nodes to which the blockchain node is connected. Some blockchain nodes operate as "miners", collecting one or more transactions, forming a data structure corresponding to a block, performing some calculations to verify the transactions included in the block, solving a puzzle, putting the solution of the puzzle into the data structure, and attempting to convey the block to other blockchain nodes. This puzzle may be in the form of a non-trivial calculation specific to the transaction data and the current state of the blockchain ledger, such as, for example, the number of blocks in the ledger and data from the last added block.

[0007] By making the puzzle transaction-dependent, an unauthorized blockchain node may be unable to propagate pre-created blocks. By solving a non-trivial puzzle, an unauthorized blockchain node may not be able to simply inject blocks into the blockchain network, but may require performing important computational tasks to prove that the blockchain node has provided effort (in fact, showing a solution to a difficult problem is "proof-of-work"). Preferably, in the blockchain protocol, proof-of-work is not easy, but it is easy to verify that the puzzle has been solved and the work has been done. That is, other blockchain nodes do not necessarily have to trust the blockchain node that is proposing to add a new block to the ledger. When verified by other blockchain nodes, that blockchain node can add the new block to the end of its copy of the blockchain ledger and propagate the new block to other blockchain nodes. Since other blockchain nodes perform similar verifications and can also conclude that the block is valid and should be added to the blockchain ledger, the new block can be added to the copy of the blockchain ledger of the blockchain node. If a blockchain node determines that the proposed new block is not valid, it does not have to add the new block to its copy of the blockchain ledger and does not have to propagate it. Since the validity of the blockchain is consensus-based, a transaction may be considered valid if a majority of nodes agree that the transaction is valid.

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

[0009] To include a transaction in a block written to the blockchain, (1) the mining blockchain node verifies the transaction, (2) the mining blockchain node attempts to propagate the block containing the transaction, and (3) other nodes verify the validity of the block and the validity of the transactions within the block. Since mining blockchain nodes are programmed or configured with these rules in mind, it is unlikely that a mining blockchain node will include in a block a transaction that fails verification, and such a block will not be accepted by other nodes, and the mining node will not be able to gain an advantage. One such advantage of mining for some blockchain systems is that when a block is accepted, the block is permitted to include "distributed" transactions, and a certain amount of value is allocated to the operator of that node without requiring a corresponding decrease in value from some other entity. In this way, a successful miner can receive a reward from the value generated with the block. Additionally, as will be explained below, transactions include transaction fees. Transaction fees also reach the miner controlling the mining blockchain node, and it is necessary to confirm that the transaction is valid for the miner to receive compensation.

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

[0011] Transactions other than the genesis transaction and the distribution transaction involve the "unlocking" of one or more existing transactions on the blockchain ledger, and when such a transaction is added to the blockchain ledger, the transaction can be transferred. Each untransferred transaction publicly specifies the requirements necessary to unlock the value of that transaction. A simple requirement is, "You must first prove that you are Alice. Then, you can unlock it." Alice can then generate a new transaction to "unlock" the value of that transaction. Here, Alice's new transaction proves that it came from Alice and has a pointer to the previous transaction. For a distribution transaction, there is a transaction value, but the distribution 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 previously transferred transaction, and Alice must actually prove that she created it.

[0012] By the blockchain protocol, and thus by the consensus of the blockchain nodes, a transaction is not valid if it refers to the outputs of previous transactions that have already been transferred, i.e., if the ledger contains valid existing transaction inputs that refer to the outputs of previous transactions. To prevent an interloper from generating a new transaction input that "unlocks" the value represented by a previous UTXO, each transaction output contains data representing the requirements imposed on the claimant who generates such a transaction. Since the UTXO is immutable, the data cannot be changed. Of course, transferred transactions can also be immutable.

[0013] In the above example, Alice may have created an unlocking transaction. As a result, she can transfer the value in the previous transaction, which only she had the ability to unlock, to Bob. That is, there will now be a new untransferred transaction that only Bob has the ability to unlock, thereby unlocking it. The unlocking transaction created by Alice may contain data corresponding to the requirement that "anyone can freely point to this transaction and, if they can provide sufficient information to prove that they know Bob's private key, they can unlock all of the value." Assuming Bob is prudent, he will be the only person who can create a valid transaction to unlock that transaction. In fact, Bob owns that value and only he can unlock it. Note that this means Bob does not need to trust the operator of the blockchain node or other parties who have the ability to create transactions. All Bob needs to trust is that a malicious party cannot completely control the majority of the blockchain nodes.

[0014] In certain cases, one transaction exactly unlocks one previous unspent transaction, and one transaction is either fully spent by a later transaction or not spent at all. In the general case, a transaction has one or more inputs and one or more outputs, 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 unspent until transferred / referenced by an input of a future transaction). The outputs of a transaction are its redeemable units, and all of them are either spent or not spent at all. Note that in the examples described herein, a transaction may be said to be "spent" and includes cases where a transaction has multiple outputs of a plurality of transactions and spends a number of outputs less than all of its outputs, and in contrast to unlocking a transaction output, the case of "unlocking a transaction" may include cases where the output of a transaction having only one output is spent.

[0015] If a transaction can have multiple outputs, different transaction outputs of that transaction can be spent at different times. When a transaction is created, its outputs may be considered unspent. Each output is either spent by an input of a later transaction or remains unspent. If a transaction has an input attempting to unlock an output of a previous transaction after the output of the previous transaction has already been spent, the blockchain node rejects it as an invalid transaction.

[0016] If one party, Alice, controls a UTXO with a value of X and wants to unlock only a portion Y of that transaction output, Alice can specify a new transaction with multiple outputs: one transaction output with a value of Y that can only be transferred by Bob, and one transaction output with a value of X - Y that can only be transferred by Alice. In effect, the original transaction output is fully transferred, but there are new transaction outputs that "modify" Alice's transaction.

[0017] The number of inputs to 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 must not exceed the sum of the values of the outputs of the previous transaction that can be transferred by the inputs of the current transaction, and with some exceptions, it may be less in some cases. For genesis transactions and distribution transactions, the sum of the output values can be greater than the sum of the input values. Or, if there are no inputs at all, but in the case of a normal transaction, if the sum of the values of its outputs exceeds the sum of the values of its inputs, the transaction is invalid. In some transactions, the sum of the output values may be less than the sum of the input values. In this case, the successful miner adds the difference as a transaction fee transaction, and then the miner settles and creates a reason to process the transaction. In the Bitcoin protocol, this is a Coinbase transaction, which is added to the block and has a reimbursable output equal to the sum of the transaction fees of all other transactions included in the Bitcoin block (i.e., the sum of the differences between all inputs and outputs of all transactions included), plus the distribution for creating a new block.

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

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

[0020] When a verification blockchain node combines a lock script and an unlock script and executes the combination, the result after execution will be either "TRUE (true)" or "FALSE (false)". In some cases, before the script is fully executed, the execution of the script may end with a FALSE result. For example, assume that for the execution of a particular script, there are two values that are always equal for the execution of a valid script, regardless of what happens in the script. During the execution of that script, a comparison is made between these two values, and if they are not equal, the execution of the script can stop immediately after that comparison and return a FALSE result. There is no need to execute the remaining script.

[0021] When a verification blockchain node combines a lock script and an unlock script, executes the combination, and the result is TRUE (i.e., the unlock script contains everything necessary to unlock the transaction output), the verification blockchain node verifies that the transaction is valid (assuming other requirements are met, such as an appropriate timestamp, appropriate format, not referring to a transferred transaction output, etc.). When the verification blockchain node verifies that the transaction is valid, the node may propagate the transaction. Other blockchain nodes may perform the same calculation to conclude that the transaction is valid. In this way, a valid transaction with inputs referring only to UTXOs and an unlock script to unlock those UTXOs can be propagated and ultimately become part of a block that will eventually become part of the ledger.

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

[0023] Once a transaction is valid and accepted into the blockchain, its content cannot be changed. That is, the lock script is determined at the time of transaction creation. However, the unlock script is included within a later unlock transaction and does not necessarily need to be created until the later unlock transaction is created, so it is not always determined at that time.

[0024] Typically, the unlock script to be verified is not created by just anyone, but only by a party given the authority to unlock the output of a previous transaction. As in the above example, the lock script is "Anyone can freely point to this transaction output if they can provide sufficient information to prove they know Bob's private key, thereby unlocking all the stipulated values.", and the unlock script might be in the form of "Bob signs the transaction with his private key and the result here is ABCCC." Subsequently, the verification blockchain node processes these two statements and may reach a conclusion of TRUE or FALSE. This process works well when it is easy to verify that ABCCC is a valid signature, easy for Bob (or anyone else who knows Bob's private key) to generate such a signature, and very difficult for anyone else who does not know Bob's private key to generate a valid signature. As a result, value can be transferred in a trustless system. Since it is cryptographically difficult for the sender of the transaction that Bob is trying to unlock to form a valid and verifiable result that will be accepted by the consensus of the blockchain nodes without first knowing Bob's private key, there is no need to trust the system or Bob.

[0025] The blockchain node can easily verify that Bob has signed the transaction and can verify that the signature is the only requirement of the lock script. Of course, there may be malicious nodes that do not verify where other nodes verify and verify where other nodes do not verify. However, as long as the malicious nodes cannot overwhelm the honest nodes on the blockchain network, the malicious nodes cannot push invalid transactions or stop the propagation or mining of valid transactions.

[0026] When a node executes the unlock script of the transaction input and the corresponding lock script of the previous transaction input, evaluates each of them to TRUE, and other verification conditions (if applicable) are met, the transaction is valid as far as that node is concerned. Next, that node propagates the verified transaction to other network nodes, and as a result, the miner nodes can choose to include the transaction in the block. Therefore, in order to write a transaction to the blockchain, (1) it must be verified by the node that receives the transaction, (2) relayed to other nodes in the network (only if the transaction is verified), (3) added to the new block constructed by the miner, (4) propagated as part of the proposed block, and (5) accepted by the consensus of the nodes as an addition to the public ledger of past transactions.

[0027] To make a transaction effectively irreversible, a transaction may be considered confirmed when a sufficient number of blocks have been added to the blockchain. Since a transaction is immutable, the blockchain protocol can block a unilateral reversal of the transaction. Of course, if Alice transfers value X to Bob and Alice requests the return of that value X, Alice can obtain value X if Bob agrees. In this case, the Alice-to-Bob-for-X transaction is not reversed or canceled, but there is a new transaction initiated by Bob, the Bob-to-Alice-for-X transaction.

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

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

[0030] In a blockchain network, if each node does not need to trust each other, transactions may be verified as such, blocks may be verified as such, unverifiable transactions and blocks may be ignored and become unused, and transactions and blocks may be considered substantially immutable, which can be a result of the assumption that a transaction or block has not been altered from its original state if the hash or digital signature correctly corresponds to the transaction or block.

[0031] Among blockchain nodes, some store the entire ledger, while others store only unused transaction outputs (e.g., UTXO in the Bitcoin ledger). UTXO corresponds to a redeemable value, and each UTXO preferably has a lock script such that others than the "owner" of that value cannot easily generate a verifiable unlock script. Of course, this is not a necessary condition, but a UTXO for which a verifiable unlock script can be easily generated by anyone is expected to be quickly transferred in a transaction that transfers its value to another UTXO that only the first person to notice it can redeem. As a result, the blockchain can be used to transfer control of cryptocurrency value. More generally, digital assets and transaction records from one participant to another in a blockchain system, including transferred transaction outputs and UTXO, can be recorded in a publicly immutable ledger, which makes it easier to verify the flow of digital assets and prevent double unlocking of those digital assets.

[0032] In an embodiment, a "digital asset" refers to binary data related to a right of use. Examples of digital assets include Bitcoin, ether, and Litecoin. As used herein, "digital asset" may refer to one or more digital assets. For example, a transaction may have multiple inputs, and each of these inputs can represent a different digital asset. The digital asset whose control is transferred may, in this example, be a collection of multiple digital assets, and the collection itself is a digital asset. Similarly, a transaction can subdivide and / or combine these multiple inputs to generate one or more outputs, for example, such that the number of inputs and the number of outputs are different.

[0033] In one embodiment, the cryptocurrency is a token-based cryptocurrency, and each token represents a share of an asset (e.g., a share of a company), and a single transaction includes multiple types of tokens (e.g., shares of one or more different companies). In some embodiments, for example, like Bitcoin, the digital asset is non-tokenized. As a result, for example, there is no identifier for the digital asset identified within the blockchain, but rather, the control of the digital asset is demonstrated through the ability to generate a valid transaction that will be recorded on the blockchain. However, note that some blockchain implementations can use tokenized digital assets, for example, such that the digital asset is particularly identifiable using the information recorded on the blockchain. A digital asset can be used as a cryptocurrency in some embodiments, but in embodiments, it is intended that the digital asset can be used additionally or alternatively in other contexts. The present invention is applicable to the control of digital assets, but is essentially technical and can be used in other contexts that utilize the blockchain data structure without necessarily involving the transfer of digital assets.

[0034] A transaction includes a lock script and an unlock script, which can form computational objects. Once committed to the blockchain, a transaction may become immutable, and its functionality can be used beyond simply an immutable transfer of control over digital assets in the form of cryptocurrency. Immutable transactions can be used to perform other operations such as, in addition to the transfer of value, a notarized record of events, the implementation of smart contracts where the rights and obligations of parties are encoded in the transaction, and the transfer of value in accordance with the conditions of smart contracts according to the blockchain protocol.

[0035] In the Bitcoin platform, scripts are written using a stack-based scripting language, although other approaches may be used instead. In some instances, the "stack-based scripting language" refers to a programming language that supports various stack-based or stack-oriented execution models and operations. When executing instructions of a stack-based scripting language, a processor (such as part of a blockchain node) stores data in a first-in, first-out data structure called a stack. The processor can push a value onto the top of the stack or pop a value from the top of the stack. The various operations performed on the stack can, as a result, push or pop one or more values from the top of the stack, perform operations on the values, or change the order of the elements on the stack (which can be equivalent to two pop operations and two push operations where the first push pops the first item). For example, the OP_EQUAL operation can pop the top two items from the stack, compare them, and push the result (1 if equal, 0 if not equal) onto the top of the stack. Other operations performed on the stack, such as OP_PICK, can allow items to be selected from positions other than the top of the stack. In some of the scripting languages used by some embodiments of the present invention, there may be at least two stacks, namely, a main stack and an alternative stack. Some operations of the scripting language can move an item from the top of one stack to the top of another stack. For example, when executing the OP_TOALTSTACK operation, the processor moves a value from the top of the main stack to the top of the alternative stack. It should be noted that stack-based scripting languages are not, in some cases, limited to operating strictly in a last-in, first-out (LIFO) manner. For example, a stack-based scripting language may support operations to copy or move the nth item in the stack to the top (such as OP_PICK and OP_ROLL in Bitcoin, respectively).Scripts written in a stack-based scripting language can be pushed onto a logical stack that can be implemented using any suitable data structure such as vectors, lists, or stacks.

[0036] Smart contracts can be implemented using scripts included in a transaction, where the terms of the contract are encoded in the script. For example, in the form "If Bob pays X to Carol and Dave gives permission to the transaction, then Alice pays half of X to Bob", which can be encoded as part of a lock script that evaluates to TRUE only if (among other things) there is a prior transaction where Bob paid Carol and a prior transaction where Dave encoded permission. As used herein, a "prior transaction" refers to a transaction that has already been added to the blockchain, and is not necessarily the transaction that immediately precedes the output that the unlock transaction unlocks. In fact, smart contracts can represent machine-executable programs that include rules defining inputs for generating results, thereby causing the execution of actions that depend on those results.

[0037] In addition to the transfer of value, a transaction may also transfer other objects or rights of possession of value. For example, a transaction may transfer the nominal cryptocurrency value but may also contain data corresponding to the claim that "the person who can cancel this transaction is also the legitimate owner of the house and land at Marley Circle 123". The right of possession may also be unclear in the public record in the same sense. For example, a transaction may contain data corresponding to the claim that "the person who can unlock this transaction is also the legitimate owner of a specific property entrusted with the trust number 12345 held by the Central Bank of Trust". Here, this is represented and caused by a token that transfers real-world entities via the blockchain. Potentially confidential or secret items can be represented by tokens that have no identifiable meaning or value. Thus, a token can function as an identifier that enables real-world items to be referenced from the blockchain.

[0038] In some embodiments, the interaction with a particular entity is encoded in a particular step within the smart contract, which would otherwise be automatically executable and self-enforcing. In some examples, the automatic execution represents the execution of the smart contract to enable the transfer of UTXOs. In such examples, an "any entity" that can unlock a UTXO represents an entity that can generate an unlock script without being required to prove any secret knowledge. In other words, the unlock script can be generated without verifying that the source of the data has access to cryptographic secrets (such as private asymmetric keys, symmetric keys, etc.). Also, in such examples, self-enforcement occurs as a result of the verification nodes of the blockchain network verifying unlock transactions according to the constraints of the smart contract. In some examples, the "unlock" of a UTXO represents generating an unlock transaction output that references and executes the UTXO as valid. A side effect of unlocking such a transaction output is that the blockchain network can process the lock script and the unlock script to verify a new transaction, namely the unlock transaction. If valid, the output of the previous transaction is considered transferred. By including a particular value in the transaction output to allow anyone to unlock that output, there is a reason for a party to create such an unlock transaction, and thus the steps of the smart contract are executed not by the participants of the smart contract but by others operating the blockchain nodes.

[0039] Scripts that form lock scripts and unlock scripts recorded as part of a transaction can be immutable, so lock scripts usually cannot be changed and reference parts of future transactions may be unknown when the transaction is finalized and thus cannot be referenced. The unlock script of a transaction input can reference a portion of the output of a previous transaction that the transaction input points to, or a previous transaction within the blockchain other than the previous transaction. This can limit how a transaction can be used.

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

Summary of the Invention

[0041] In various embodiments of a computer-implemented method, the method comprises determining a first set of constraints for a first used transaction output; determining a second set of constraints for a second used transaction output; generating an initial transaction, wherein the initial transaction comprises at least one initial lock script including the first set of constraints and the second set of constraints; and at least one usable value, wherein using the at least one usable value at least partially verifies that a used transaction includes the first used transaction output, thereby satisfying the first set of constraints, and A step, on the condition that at least partially verifying that the usage transaction includes the second usage transaction output verifies that the second set of constraints is satisfied; Causing the initial transaction to be verified at a node of the blockchain network; Including.

[0042] The lock script in the first usage transaction output may be a copy of the lock script in the second usage transaction output.

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

[0044] The lock script in the first usage transaction output may include at least a part of at least one initial lock script.

[0045] The execution of the at least one initial lock script may select the at least a part from a plurality of parts of the at least one initial lock script.

[0046] As a result of the execution of the unlock script of the usage transaction, the at least one initial lock script may receive data corresponding to one of the first usage transaction output or the second usage transaction output.

[0047] The data may have an index value. On the condition that the index value is the first index value, the execution of the at least one initial lock script may determine whether the first set of constraints is satisfied. On the condition that the index value is the second index value, the execution of the at least one initial lock script may determine whether the second set of constraints is satisfied.

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

[0049] At least one initial lock script may include constraints on the source of the data.

[0050] The method may further include determining the spendable value of the first spent transaction output.

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

[0052] The spend transaction may include multiple input values corresponding to multiple states.

[0053] The first set of constraints may constrain the first spent transaction output to have a first state. The second set of constraints constrains the second spent transaction output to have a second state.

[0054] Furthermore, a method implemented by a computer, determining a spend transaction constraint that constrains a spend transaction to include a spend transaction input that references the output of a previous transaction; generating a spendable transaction, the spendable transaction comprising: a spendable transaction output that includes a spendable amount; and a spendable transaction lock script that includes the spend transaction constraint, wherein the use of the spendable amount is conditioned on the execution of at least one unlock script of a spend transaction that satisfies the spend transaction constraint; causing a node of the blockchain network to verify the spendable transaction.

[0055] The usage transaction constraint may further constrain the usage transaction input to include a specific hash value.

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

[0057] The usage transaction constraint may further constrain the lock script of the usage transaction to include a set of script elements replicated from the usable transaction lock script.

[0058] The usable transaction may encode a contract having multiple states.

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

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

[0061] The specific lock script element may encode the cryptographic key of a specific entity.

[0062] The usage transaction constraint may be a first usage transaction constraint, and the method may further determining a second usage transaction constraint to further constrain the usage transaction; and generating a second usable transaction, the second usable transaction comprising a second usable amount; and A second usable transaction lock script including a second usage transaction constraint, and using the second usable amount may further include a step that is conditional on the execution of at least one unlock script satisfying the second usage transaction constraint.

[0063] The usable transaction lock script may be a first usable transaction lock script, and the at least one unlock script may include a first unlock script and a second unlock script. The first usage transaction constraint may restrict the first unlock script so as to include at least a part of the first usable transaction lock script. The second usage transaction constraint may restrict the second unlock script so as to include at least a part of the second usable transaction lock script.

[0064] At least a part of the first usable transaction lock script may include a cryptographic key associated with the first entity. At least a part of the second usable transaction lock script may include a cryptographic key associated with a second entity different from the first entity.

[0065] The usage transaction constraint may further restrict the usage transaction so as to restrict the output of the usage transaction.

[0066] The usage transaction constraint may encode another contract distinct from the contract. Using the usable amount may be conditional on the other contract being implemented in the output of the usage transaction.

[0067] Furthermore, a method implemented by a computer, generating a blockchain transaction, the blockchain transaction being a state machine in a first state and having a set of allowable state transitions, Encoding a set of script elements to be executed to cause a usage transaction to decode a state machine according to a set of permitted state transitions, to comply with restrictions on inputs to the usage transaction, or to comply with restrictions on outputs of the usage transaction; and causing a blockchain transaction to be verified by a node of a blockchain network. It is desirable to provide a method including these steps.

[0068] The set of permitted state transitions may include state transitions that can be implemented independently and in parallel in another blockchain transaction.

[0069] The set of script elements may cause the usage transaction to comply with restrictions on outputs of the usage transaction. The restrictions on outputs may require that the first output of the usage transaction indicates a state corresponding to the first output according to the set of permitted state transitions, and that the second output of the usage transaction indicates a state corresponding to the second output according to the set of permitted state transitions.

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

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

[0072] The set of script elements may cause the usage transaction to comply with restrictions on inputs to the usage transaction. The restrictions on inputs may require that an input to the usage transaction indicates another state machine encoded within another blockchain transaction.

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

[0074] The first transition from the first state to the second state may be within the range of the allowable state transition set. The second transition from another state to the second state may be within the range of the allowable state transition set.

[0075] The set of script elements may cause the usage transaction to comply with restrictions on the input of the usage transaction. The restrictions on the input may describe a set of conditions for advancing the state machine. The set of conditions for advancing the state machine may depend on the state of another state machine.

[0076] Another state machine may be encoded within another blockchain transaction. Another transaction may encode a set of conditions for advancing another state machine. Another set of conditions for advancing another state machine may depend on the state of the state machine.

[0077] The set of script elements may cause the usage transaction to comply with restrictions on the output of the usage transaction. The restrictions on the output may require that the usage transaction incorporate an element set of the smart contract into the output.

[0078] The element set of the smart contract may be obtained from another blockchain transaction.

[0079] The set of script elements may cause the usage transaction to comply with both the restrictions on the input of the usage transaction and the restrictions on the output of the usage transaction.

[0080] Furthermore, a method implemented by a computer, generating, at a node of a blockchain network, a blockchain transaction having a transaction output usable by a first usage transaction input of the first usage transaction; Inserting a first set of script elements into a blockchain transaction that can constrain a first usage transaction to include a first set of transaction script elements corresponding to the operation of the state machine. Inserting a second set of script elements into a blockchain transaction that can constrain a second set of transaction script elements corresponding to an allowable state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by a blockchain network. The blockchain transaction can include a first output having a first lock script, and the first transaction output value can include a second output having a second lock script and a second transaction output value. The first set of script elements is part of the first lock script.

[0081] The usage transaction can include an unlock script. The unlock script, when executed by a transaction validator using the lock script of the output of the previous transaction, Meet a specified verification test, execute the lock script of the output of the previous transaction, insert a first set of script elements into the using transaction, where the first set of script elements forms part of the using transaction lock script of the first output of the using transaction and conforms to the requirements indicated by the previous transaction lock script, the first set of script elements corresponds to the operation of the state machine, and, insert a second set of script elements into the using transaction, where the second set of script elements forms part of the using transaction lock script and conforms to the requirements indicated by the previous transaction lock script, when corresponding to an admissible state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by the blockchain network, cause the node to store at least in memory accessible by the transaction verifier a value representing a field of the using transaction.

[0082] The using transaction can include inputs and outputs, where the inputs refer to the outputs of the previous transaction. The using transaction includes an unlock script. When the unlock script is executed by the transaction verifier using the previous transaction lock script of the output of the previous transaction, it meets a specified verification test, where the unlock script executes the lock script and inserts data corresponding to an additional state machine into the using transaction as using transaction inputs and / or using transaction outputs based on an admissible state machine state transition, and as a result, when the number of using transaction inputs and / or using transaction outputs used in the using transaction is sufficient for the number of state machine transitions, cause the node to store at least in memory accessible by the transaction verifier a value representing a field of the using transaction.

[0083] The allowable state machine transition generates, for the usage transaction, a first transaction output corresponding to a first subsequent state, inserts into the usage transaction a first transaction output value of the first transaction output sufficient to cause the first transaction output to be an input to a first subsequent transaction that references the first transaction output, inserts into the first transaction output of the usage transaction a third set of script elements, where the third set of script elements is part of a first lock script that constrains the first subsequent transaction to take the first subsequent state, generates, for the usage transaction, a second transaction output corresponding to a second subsequent state, inserts into the usage transaction a second transaction output value of the second transaction output sufficient to cause the second transaction output to be an input to a second subsequent transaction that references the second transaction output, inserts into the second transaction output a fourth set of script elements, where the fourth set of script elements is part of a second lock script that constrains the second subsequent transaction to take the second subsequent state, and inserts into the first transaction output or the second transaction output a fifth set of script elements, where the fifth set of script elements is part of the first lock script or part of the second lock script that imposes a constraint by which the first subsequent transaction and the second subsequent transaction are distinguished, whereby a branching transaction from one initial state to two subsequent states may be included.

[0084] The first lock script can restrict the first subsequent transaction to have a first state. The second lock script can restrict the second subsequent transaction to have a second state. A usage transaction can include three or more transaction output values corresponding to branches of three or more states. A usage transaction can include three or more transaction input values corresponding to fusions of three or more states. The first lock script and the second lock script can restrict the first subsequent transaction and the second subsequent transaction to have the same state.

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

[0086] An admissible state machine state transition can include a merging transaction from two initial states to one subsequent state by inserting a first transaction input of a first previous state into the usage transaction, inserting a second transaction input of a second previous state into the usage transaction, and inserting a merged state that is an admissible transition from the first previous state and the second previous state according to a state transition matrix into the usage transaction.

[0087] An admissible state machine state transition can be hard - coded into the first transaction input and / or the second transaction input by inserting a first reference to a first previous transaction having a first previous state into the first transaction input, inserting a second reference to a second previous transaction having a second previous state into the second transaction input, and inserting a first transaction output of the merged state into the usage transaction. Here, the state transition matrix is available for the first previous transaction and the second previous transaction.

[0088] The allowable state machine transition inserts the first transaction input of the first previous state into the usage transaction, inserts the second transaction input of the second previous state into the usage transaction, inserts the first reference to the first previous transaction having the first previous state into the first transaction input, inserts the second reference to the second previous transaction having the second previous state into the second transaction input, inserts the first transaction output of the first subsequent state into the usage transaction, inserts the third set of script elements into the first transaction output, where the third set of script elements is part of the first lock script that constrains the first subsequent transaction to take the first subsequent state, inserts the second transaction output of the second subsequent state into the usage transaction, inserts the fourth set of script elements into the second transaction output, where the fourth set of script elements is part of the second lock script that constrains the second subsequent transaction to take the second subsequent state, whereby it can include parallel operations from the number N of initial states to N subsequent states. N is 2 or more.

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

[0090] A transaction can be divided by any constraints. The method includes, at a node of a blockchain network, generating a first transaction, where the first transaction includes a first output having a first usable value and a first lock script, and the first transaction further includes a second output having a second usable value and a second lock script; including in the first lock script a first set of constraints for a first selected transaction output, where the first set of constraints is satisfied by a first unlock script if the first selected transaction output is to be verified for using the first usable value; including in the second lock script a second set of constraints for a second selected transaction output, where the second set of constraints is satisfied by a second unlock script if the second selected transaction output is to be verified for using the second usable value, and where the first set of constraints or the second set of constraints imposes a constraint on a lock script of a using transaction having the first selected transaction output or the second selected transaction output as a using transaction output.

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

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

[0093] The first set of constraints and the second set of constraints can each include a common set of constraints. Thereby, the two constrained used transaction output lock scripts are constrained by the common set of constraints. The first set of constraints and / or the second set of constraints can include a hash of a part of the first lock script, and / or a hash of a part of the second lock script, and / or a constraint on the size of a part of the first lock script and / or the size of a part of the second lock script.

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

[0095] A transaction can incorporate an interdependence with any constraints, such as by a method implemented by a computer. The method includes generating, at a node of a blockchain network, a first usable transaction, where the first usable transaction includes a first usable output having a first usable value and a first lock script; including, in the first lock script, a first constraint set for the spending transaction, where the first constraint set is satisfied by a first unlocking script of the spending transaction if the spending transaction is to be valid for using the first usable output; including, in the first constraint set, a first spending transaction constraint that requires the first spending transaction output of the spending transaction to include a first spending transaction output lock script for including the first smart contract script instruction set; and including, in the first constraint set, a second spending transaction constraint that requires the spending transaction to include a second smart contract script instruction set and requires the spending transaction to include a spending transaction input that references a second usable transaction output.

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

[0097] The first constraint set may be that the first spent transaction output lock script includes a reference to the second spendable transaction output, and that the second smart contract script instruction set includes a reference to the output of the first spendable transaction.

[0098] The method may include the step of providing, within the first constraint set, a first parallel constraint requiring that the spent transaction include a first spent transaction input that references the first spendable transaction, a second parallel constraint requiring that the spent transaction include a second spent transaction input that references the second spendable transaction output, a third parallel constraint requiring that the first spent transaction output lock script include at least a first script instruction set determined at least in part by the first lock script within the first smart contract script instruction set, and a fourth parallel constraint requiring that the second spent transaction output lock script include a second smart contract script instruction set determined at least in part by the lock script of the second spendable transaction output.

[0099] The first constraint set may include a first parallel constraint requiring that the spent transaction include a first spent transaction input that references the first spendable transaction, a second parallel constraint requiring that the spent transaction include a second spent transaction input that references the second spendable transaction output, a third parallel constraint requiring that the first spent transaction output lock script include at least a first script instruction set replicated from the first lock script in the first smart contract script instruction set, and a fourth parallel constraint requiring that the second spent transaction output lock script include a second smart contract script instruction set replicated from the lock script of the second spendable transaction output.

[0100] Furthermore, a method implemented by a computer, comprising: determining a first set of constraints for a first unlock transaction output; determining a second set of constraints for a second unlock transaction output; generating an initial transaction, the initial transaction comprising: at least one initial lock script including the first set of constraints and the second set of constraints; at least one redeemable value, wherein unlocking the at least one redeemable value is conditional on verifying, at least in part, that an unlock transaction includes the first unlock transaction output, such that the first set of constraints is satisfied, and conditional on verifying, at least in part, that the unlock transaction includes the second unlock transaction output, such that the second set of constraints is satisfied; causing the initial transaction to be verified at a node of a blockchain network; It is desirable to provide a method implemented by a computer including the above.

[0101] The lock script in the first unlock transaction output may be a copy of the lock script in the second unlock transaction output.

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

[0103] The lock script in the first unlock transaction output may include at least a part of at least one initial lock script.

[0104] The execution of the at least one initial lock script may select the at least a portion from a plurality of parts of the at least one initial lock script.

[0105] As a result of the execution of the unlock script of the unlock transaction, the at least one initial lock script may receive data corresponding to one of the first unlock transaction output or the second unlock transaction output.

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

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

[0108] The at least one initial lock script may include constraints on the source of the data.

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

[0110] The initial transaction may encode a contract having a plurality of states.

[0111] The unlock transaction may include a plurality of input values corresponding to a plurality of states.

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

[0113] Furthermore, a method implemented by a computer, determining an unlock transaction constraint that constrains an unlock transaction to include an unlock transaction input that references the output of a previous transaction; generating a repayable transaction, the repayable transaction including a repayable transaction output that includes a repayable amount, and a repayable transaction lock script that includes the unlock transaction constraint, wherein unlocking of the repayable amount is conditional upon execution of at least one unlock script of an unlock transaction that satisfies the unlock transaction constraint; causing a node of a blockchain network to verify the repayable transaction.

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

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

[0116] The unlock transaction constraint may further constrain the lock script of the unlock transaction to include a set of script elements replicated from the repayable transaction lock script.

[0117] The repayable transaction may encode a contract having multiple states.

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

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

[0120] The specific lock script element may encode the cryptographic key of a specific entity.

[0121] The unlock transaction constraint may be a first unlock transaction constraint, and the method may further include determining a second unlock transaction constraint to further constrain the unlock transaction, and generating a second redeemable transaction, the second redeemable transaction including a second redeemable amount, and a second redeemable transaction lock script including the second unlock transaction constraint, wherein unlocking the second redeemable amount may further be conditional on the execution of at least one unlock script satisfying the second unlock transaction constraint.

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

[0123] At least a part of the first repayable transaction lock script may include a cryptographic key associated with the first entity. At least a part of the second repayable transaction lock script may include a cryptographic key associated with a second entity different from the first entity.

[0124] The unlock transaction constraint may further constrain the unlock transaction so as to constrain the output of the unlock transaction.

[0125] The unlock transaction constraint may encode another contract distinct from the contract. Unlocking the repayable amount may be conditional on other contracts being implemented within the output of the unlock transaction.

[0126] Furthermore, a method implemented by a computer, generating a blockchain transaction, the blockchain transaction comprising a state machine in a first state and having a set of allowable state transitions, and a set of script elements to be executed to cause the unlock transaction to decode the state machine according to the set of allowable state transitions, to conform to restrictions on the input to the unlock transaction, or to conform to restrictions on the output of the unlock transaction, and causing the blockchain transaction to be verified by a node of the blockchain network.

[0127] The set of allowable state transitions may include state transitions that are independently and concurrently implementable in another blockchain transaction.

[0128] The script element set may cause the unlock transaction to comply with restrictions on the output of the unlock transaction. The restrictions on the output may require that the first output of the unlock transaction indicates the state corresponding to the first output according to the set of allowed state transitions, and that the second output of the unlock transaction indicates the state corresponding to the second output according to the set of allowed state transitions.

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

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

[0131] The script element set may cause the unlock transaction to comply with restrictions on the input of the unlock transaction. The restrictions on the input may require that the input to the unlock transaction indicates another state machine encoded within another blockchain transaction.

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

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

[0134] The script element set may cause the unlock transaction to comply with restrictions on the input of the unlock transaction. The restrictions on the input may describe a set of conditions for evolving the state machine. The set of conditions for evolving the state machine may depend on the state of another state machine.

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

[0136] A set of script elements may cause an unlock transaction to comply with restrictions on the output of the unlock transaction. The restrictions on the output may require that the unlock transaction incorporate a set of elements of a smart contract into the output.

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

[0138] A set of script elements may cause an unlock transaction to comply with both restrictions on the input of the unlock transaction and restrictions on the output of the unlock transaction.

[0139] Furthermore, a method implemented by a computer, at a node of a blockchain network, generating a blockchain transaction having a transaction output transferable by a first unlock transaction input of the first unlock transaction; inserting a first set of script elements into the blockchain transaction, the first set of script elements being capable of constraining the first unlock transaction to include a first set of unlock transaction script elements corresponding to the operation of the state machine; Providing a method including the step of inserting into a blockchain transaction a second set of script elements that can constrain a second set of unlock transaction script elements corresponding to a permissible state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by a blockchain network. The blockchain transaction can include a first output having a first lock script, and the first transaction output value can include a second output having a second lock script and a second transaction output value, and the first set of script elements can be part of the first lock script.

[0140] An unlock transaction can include an unlock script. When the unlock script is executed by a transaction validator using the lock script of the output of the previous transaction, it satisfies a predetermined verification test, executes the lock script of the output of the previous transaction, inserts a first set of script elements into the unlock transaction, where the first set of script elements forms part of the unlock transaction lock script of the first output of the unlock transaction and may conform to the requirements indicated by the previous transaction lock script, the first set of script elements corresponds to the operation of the state machine, and inserts a second set of script elements into the unlock transaction, where the second set of script elements forms part of the unlock transaction lock script and conforms to the requirements indicated by the previous transaction lock script, and when corresponding to a permissible state machine state transition including a state implementable using different blockchain transactions that can be processed independently in parallel by a blockchain network, the node may cause a value representing a field of the unlock transaction to be stored at least in a memory accessible by the transaction validator.

[0141] An unlock transaction can include an input and an output, where the input references the output of a previous transaction. The unlock transaction includes an unlock script. When the unlock script is executed by a transaction validator using the previous transaction lock script of the output of the previous transaction, it satisfies a predetermined verification test. Here, the unlock script executes the lock script and inserts data corresponding to an additional state machine into the unlock transaction as an unlock transaction input and / or an unlock transaction output based on an allowable state machine state transition. As a result, when the number of unlock transaction inputs and / or unlock transaction outputs used in the unlock transaction is sufficient for the number of state machine transitions, the node is caused to store at least a value representing a field of the unlock transaction in memory accessible by the transaction validator.

[0142] The allowable state machine transition generates, for an unlock transaction, a first transaction output corresponding to a first subsequent state, inserts a first transaction output value of the first transaction output, which is sufficient to cause the first transaction output to be input to a first subsequent transaction that references the first transaction output, into the unlock transaction, inserts a third set of script elements into the first transaction output of the unlock transaction, where the third set of script elements may be a portion of a first lock script that constrains the first subsequent transaction to take the first subsequent state, generates, for the unlock transaction, a second transaction output corresponding to a second subsequent state, inserts a second transaction output value of the second transaction output, which is sufficient to cause the second transaction output to be input to a second subsequent transaction that references the second transaction output, into the unlock transaction, inserts a fourth set of script elements into the second transaction output, where the fourth set of script elements may be a portion of a second lock script that constrains the second subsequent transaction to take the second subsequent state, and inserts a fifth set of script elements into the first transaction output or the second transaction output, where the fifth set of script elements may be a portion of the first lock script or a portion of the second lock script that imposes a constraint by which the first subsequent transaction and the second subsequent transaction are distinguished, thereby allowing for a branch transaction from one initial state to two subsequent states.

[0143] The first lock script can constrain the first subsequent transaction to have a first state. The second lock script can constrain the second subsequent transaction to have a second state. The unlock transaction can include three or more transaction output values corresponding to branches of three or more states. The unlock transaction can include three or more transaction input values corresponding to the merging of three or more states. The first lock script and the second lock script can constrain the first subsequent transaction and the second subsequent transaction to have the same state.

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

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

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

[0147] The allowable state machine transition inserts the first transaction input of the first pre-stage state into the unlock transaction, inserts the second transaction input of the second pre-stage state into the unlock transaction, inserts the first reference to the first previous transaction having the first pre-stage state into the first transaction input, inserts the second reference to the second previous transaction having the second pre-stage state into the second transaction input, inserts the first transaction output of the first post-stage state into the unlock transaction, inserts the third set of script elements into the first transaction output, where the third set of script elements is part of the first lock script that constrains the first post-stage transaction to take the first post-stage state, inserts the second transaction output of the second post-stage state into the unlock transaction, inserts the fourth set of script elements into the second transaction output, where the fourth set of script elements is part of the second lock script that constrains the second post-stage transaction to take the second post-stage state, whereby parallel operation from the number N of initial states to N subsequent states can be included. N is 2 or more.

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

[0149] A transaction can be split by any constraints. The method includes, at a node of a blockchain network, generating a first transaction, where the first transaction includes a first output having a first redeemable value and a first lock script, and the first transaction further includes a second output having a second redeemable value and a second lock script; including, in the first lock script, a first set of constraints for a first selected transaction output, where the first set of constraints should be satisfied by a first unlock script if the first selected transaction output is to be valid for unlocking the first redeemable value; including, in the second lock script, a second set of constraints for a second selected transaction output, where the second set of constraints should be satisfied by a second unlock script if the second selected transaction output is to be valid for using the second redeemable value, and the first set of constraints or the second set of constraints impose constraints on a lock script of an unlock transaction having the first selected transaction output or the second selected transaction output as an output of the unlock transaction.

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

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

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

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

[0154] A transaction may incorporate an interdependence with any constraint, such as by a method implemented by a computer. The method includes, at a node of a blockchain network, generating a first redeemable transaction, the first redeemable transaction including a first redeemable output having a first redeemable value and a first lock script; including in the first lock script a first set of constraints for an unlock transaction, the first set of constraints being satisfied by a first unlock script of the unlock transaction if the unlock transaction is to be valid for unlocking the first redeemable output; including in the first set of constraints a first unlock transaction constraint requiring that an output lock script of the unlock transaction of the first unlock transaction output includes a first smart contract script instruction set; and including in the first set of constraints a second unlock transaction constraint requiring that the unlock transaction includes a second smart contract script instruction set and that the unlock transaction input references a second redeemable transaction output.

[0155] The first smart contract script instruction set can include script instructions replicated from the first lock script and / or script instructions corresponding to a new smart contract different from the smart contract implemented within the first lock script.

[0156] The first set of constraints may be that the output lock script of the first unlock transaction includes a reference to the second redeemable transaction output and that the second smart contract script instruction set includes a reference to the output of the first redeemable transaction.

[0157] The method may include the step of providing a first parallel constraint that requires, within a first set of constraints, a first unlock transaction input in which an unlock transaction references a first repayable transaction, a second parallel constraint that requires a second unlock transaction input in which an unlock transaction references a second repayable transaction output, a third parallel constraint that requires a lock script of an output of the first unlock transaction to include at least a first set of script instructions determined by a first lock script at least partially within a first smart contract script instruction set, and a fourth parallel constraint that requires a lock script of an output of the second unlock transaction to include a second set of smart contract script instructions determined at least partially by a lock script of the second repayable transaction output.

[0158] The first set of constraints may include a first parallel constraint that requires, within a first set of constraints, a first unlock transaction input in which an unlock transaction references a first repayable transaction, a second parallel constraint that requires a second unlock transaction input in which an unlock transaction references a second repayable transaction output, a third parallel constraint that requires a lock script of an output of the first unlock transaction to include at least a first set of script instructions replicated from a first lock script in a first smart contract script instruction set, and a fourth parallel constraint that requires a lock script of an output of the second unlock transaction to include a second set of smart contract script instructions replicated from a lock script of the second repayable transaction output.

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

[0160] Also, it is desirable to provide a non-transitory computer-readable storage medium storing executable instructions, wherein the executable instructions cause a processor of a computer system to execute at least any one of the above-described methods on the computer system as a result of being executed by the processor of the computer system. BRIEF DESCRIPTION OF THE DRAWINGS

[0161] These and other aspects of the present invention will become apparent from the embodiments described herein and will be described. Next, embodiments of the present invention will be described by way of example only, with reference to the accompanying drawings:

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

DETAILED DESCRIPTION OF THE INVENTION

[0162] First, referring to FIG. 1, an example of a blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure is shown. In this embodiment, the blockchain network 100 includes blockchain nodes that can be implemented as peer-to-peer distributed electronic devices that each execute an instance of software and / or hardware that performs operations according to a blockchain protocol that is wholly or partially agreed upon among operators of the blockchain nodes. In some examples, these distributed electronic devices are simply referred to as "nodes", such as node 102 in FIG. 1. An example of a blockchain protocol is the Bitcoin protocol.

[0163] Node 102 can comprise any suitable computing device (e.g., a server within a data center, a desktop computer, a laptop computer, a tablet computer, a client computing device such as a smartphone, etc.) by a plurality of computing devices within a distributed system of computer resource service providers or by any suitable electronic client device. Node 102 can have an input for receiving data messages or objects representing proposed transactions, such as transaction 104. Node 102 can query about the information they hold, e.g., for an understanding of the state of a transaction.

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

[0165] FIG. 2 shows an example of a blockchain node 202 that can be used in a blockchain environment as a node within the blockchain network of FIG. 1. As shown, the blockchain node 202 includes a processor 204, a program memory 206, a storage device 208 for blockchain rules and protocol details, a list of peers 210, a storage device 212 for application variables, a communication interface 214, and a storage device 216 for a blockchain ledger. The blockchain ledger 216 includes data corresponding to blocks 221, 222, 223, such as blocks 222 having transactions 230(1)-(4), which include data corresponding to the transactions. Except for block 223, the blocks can be cryptographically immutable in that subsequent blocks depend on values calculated based on the block when the block becomes immutable, and any modification to an immutable block can be easily recognized as an invalid block by other blockchain nodes. Block 223 is shown as an open box representing the storage of transactions that may be changeable and have not yet been committed to the blockchain.

[0166] The blockchain node 202 communicates via a communication interface 214 that can 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 maintain only untransferred transactions, while others maintain the entire ledger. In this way, since each node can have its own copy, the ledger is a distributed ledger. Nodes preferably modify only their own copies according to the rules of the protocol, and for all nodes that fully comply with those rules, their copies should, except for some propagation time for blocks and transactions, be the same as those of other nodes. The blockchain node should include a function to verify the received blocks and the transactions within those blocks. According to the rules of the blockchain protocol, if a blockchain node determines that a block of transactions is invalid, it does not propagate the block or transaction to other nodes. According to this rule, valid blocks and transactions that have been confirmed to be valid may propagate through the blockchain network, but invalid blocks and transactions do not propagate.

[0167] Some of the nodes within a blockchain network may be miner nodes that collect transactions and perform the operation of creating a block of transactions so that they can commit the new block to the blockchain. The miner nodes are expected to perform some operation that is complex (to avoid malicious nodes easily generating inappropriate blocks) and that depends on the data of the transactions included (so that malicious nodes cannot perform complex operations in advance). The performance of these tasks is easily verified by other nodes. These other nodes verify the work of the miner nodes, and upon verification, accept the block into their copy of the blockchain and propagate it. Thereby, new blocks are committed to the distributed ledger of the blockchain. In some examples, a block is a group of transactions and is often marked with the timestamp and "fingerprint" (such as a hash) of the previous block. In this way, each block is linked to the previous block, and a "chain" is created that links the blocks of the blockchain. In an embodiment, a valid block may be added to the blockchain by consensus of the nodes within the blockchain network. Also, in some examples, the blockchain includes a list of verified blocks.

[0168] In one embodiment, at least some of the nodes operate as verification nodes that verify transactions as described in this disclosure. In some examples, the blockchain attests to value in the form of digital assets, and the transactions of the blockchain provide a chain from the genesis transaction (which starts the blockchain) or a distribution transaction that newly "mines" digital assets for which a miner node operator participates, to subsequent transactions. The end of one part of the chain is an unspent transaction, or a portion thereof, and each transaction on the blockchain designates one or more outputs. Some of these outputs may be transferred, and some may not be transferred. Here, an output includes a specification of the value of that output and the requirements necessary to "unlock" that output by inserting a valid transaction (i.e., one that meets at least the specified requirements) that extends the relevant part of the chain. As used herein, an unspent transaction output may be referred to as a UTXO. Unlocking a UTXO is also known as using the UTXO.

[0169] The requirements necessary to unlock a UTXO can be specified within the lock script of the UTXO. A valid unlock transaction can (i) specify one or more previous UTXOs as inputs to the transaction, where the specification may be by pointer to the UTXO, (ii) meet the requirements of the lock script for each UTXO, and (iii) have inputs such that the sum of the values of all the UTXOs pointed to by these inputs is less than or equal to the sum of the values of all the outputs of the transaction. The data representing the satisfaction of the lock script requirements is called the unlock script. A verification node can process the lock script following the unlock script, and the output of that process is either an invalid result or the verification of the unlock transaction.

[0170] If a process where a node executes an unlock script and a lock script, and the result can be verified as the result on other nodes, then the process is a stateless process. Therefore, an unlock transaction that satisfies the lock script of the output of a previous transaction on a blockchain that has not yet been transferred can be propagated and ultimately committed to the blockchain. The node that creates the unlock transaction to be committed can specify, in its own lock script, the requirements necessary to unlock the value of the output of the new transaction. This process can be considered stateless because the script does not need to refer to references outside the script and, except for some minor exceptions, does not depend on variables or other states outside those scripts. As a result, the unlock script and the lock script can be evaluated separately.

[0171] In other variations, the blockchain system may include a feature that allows external data to be included in the script evaluation process. In such cases, the external data can be controlled and / or secured in a way that ensures consistency among the nodes that execute the evaluation when the unlock script and the lock script are evaluated using the external data.

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

[0173] In some blockchain implementations, there is no centralized mechanism for assigning unique TxID values. Instead, there is a decentralized mechanism for generating a unique TxID for a transaction by generating a hash of the contents of the transaction itself. Since a valid transaction cannot have exactly the same content as any other valid transaction, each valid transaction can have (except for the astronomically low probability of a hash collision) a hash that is unique to its TxID. However, here we assume that each transaction has a unique transaction ID. Due to the nature of hashes, once the TxID is generated from the content of the transaction, none of that content can be changed and the TxID remains valid for that transaction.

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

[0175] Figure 3 explicitly shows only one transaction input and one transaction output, but one or more are possible for each. Following the transaction input, there may be a #vout field 320 that can indicate the number of transaction outputs present within transaction 300 (described below). For each transaction output (here shown as exemplary Vout[x] 330), there may be a series of fields including an Output Value field 332 that indicates the transaction value provided by this transaction output Vout[x], a Locking_Script_Length field 334 that indicates the length of the following script, and a Locking_Script field 336 that includes the lock script for this transaction output Vout[x]. Thus, the transaction value of this transaction output can be "transferred" by anyone who can create an unlock transaction having a transaction input with an unlock script that the blockchain node can verify as TRUE when performing verification using the unlock script and the lock script. After the transaction output fields, there may follow other fields such as a Lock Time field 338 that restricts the transaction 300 from being active before a specified future time or before a specified future block. Each transaction input of an unlock transaction refers to the corresponding transaction output of the previous transaction's output, and if the previous transaction's output includes a transaction value, the transaction input need not include a field indicating that transaction value.

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

[0177] Following the transaction inputs, there is a #vout field 420 that indicates the number of transaction outputs present within transaction 400, and for each transaction output (here shown as exemplary Vout[x] 430), there may be a series of fields including an nValue field 432 that indicates the transaction value provided by this transaction output Vout[x] 430, a scriptPubKeyLen field 434 that indicates the length of the subsequent lock script, and a scriptPubKey field 436 that includes the lock script for this transaction output Vout[x] 430. Transaction 440 may also be shown with an nLockTime field 438 that can restrict transaction 400 from being active before a specified future time or before a specified future block.

[0178] OP code In examples of script languages such as those used in many Bitcoin blockchain nodes, there can be a set of operation codes that appear within the script as script instructions such as lock scripts or unlock scripts. In the present disclosure, various script OP codes and keywords are referenced to perform various operations. However, other blockchain technologies may implement different instruction sets, and thus, the opcodes described in the present disclosure should be considered as illustrative of the operations performed by the opcode.

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

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

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

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

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

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

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

[0186] OP_CHECKSIGVERIFY Has the same function as OP_CHECKSIG, but OP_VERIFY is executed later.

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

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

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

[0190] OP_ENDIF Ends the if / else block.

[0191] Read the first two items on the OP_EQUAL stack and push 1 onto the stack if the two items are exactly equal, and 0 otherwise.

[0192] OP_EQUALVERIFY is the same as OP_EQUAL, but then executes OP_VERIFY.

[0193] OP_FROMALTSTACK places the input on top of the main stack and deletes it from the alternative stack.

[0194] OP_HASH256 First, the input is hashed twice, first by SHA-256 and then by RIPEMD-160.

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

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

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

[0198] OP_OVER Copy the second item on the stack and push it onto the top of the stack.

[0199] OP_ROLL The top n items on the stack are moved to the top.

[0200] OP_SUBSTR Returns a section of a string.

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

[0202] OP_TOALTSTACK Places the input on top of the alternative stack and deletes it from the main stack.

[0203] OP_VERIFY If the top stack value is not true, mark the transaction as invalid.

[0204] Some of the above OP-codes may be basic OP-codes supported by the blockchain node, while others are referred to here as OP-codes for clarity, but are typically implemented as a small script composed of multiple basic OP-codes. For example, OP_BIGMOD is referred to as an OP-code, but may be implemented using a sequence of OP-codes to perform the function of dividing the top two items on the stack and returning the remainder. OP_BIGMODADD, OP_BIGMODINVERSE, OP_BIGMODMUL can be easily expressed as a similar sequence of OP-codes.

[0205] OP_GENSIG In the present disclosure, references to OP_GENSIG should be regarded as abbreviations for the operations corresponding to the OP_GENSIG script described herein. The OP_GENSIG script that generates the signature of a transaction can also be pushed onto or used by the stack. The OP_GENSIG script first takes the inputs pushed onto the main (last-in, first-out) stack in order: <SIGHASH Type> (indicating which fields of the transaction should be used in the hash), message value <m>(Double SHA256 of the serialized set of the transaction fields used in the transaction), private key (Message value <m>used for the hash of), and the numbers <k>(A random or pseudo-random number used to mask / protect the private key; assume it is a "mask number".

[0206] Figure 5 shows the input and output of the OP_GENSIG script. In the OP_GENSIG script, the first line is a number <k>Copy it to the alternative stack and then for the elliptic curve generator <PubK G> <k>Multiply to generate the elliptic curve point K at the top of the main stack. The second line of the script calculates r from the x - coordinate of K modulo n and pushes a copy of r onto the alternative stack. The third line of the script determines s = k -1 (m + r×a) mod n. Finally, the fourth line of the script encodes r and s in DER format and concatenates them to <SIGHASH Type>.

[0207] The type of the signature hash can be indicated by SIGHASH Type, which is a byte - encoded value. The SIGHASH Type value specifies the set of fields to be extracted from the transaction before serialization (e.g., normalization) and hashing. In some examples, the SIGHASH Type value can be SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, or a combination of two or more of these. In one embodiment, the type SIGHASH_ALL indicates that all fields in the transaction, except the input script, are included in the serialization (and thus hashed and signed). In one embodiment, the type SIGHASH_NONE indicates that the output does not need to be signed so that others can update the transaction. In one embodiment, the type SIGHASH_SINGLE indicates that the input is signed but the sequence number is blank. Thus, others can create a new version of the transaction using the same hash (assuming the hashed fields are not changed), but the signed output is only the output at the same position as the input.

[0208] In one embodiment, the SIGHASH_ANYONECANPAY type is combined with other types to indicate that inputs including SIGHASH_ANYONECANPAY are signed, but other inputs need not be signed. The SIGHASH Type value can be represented by a numerical value indicating the SIGHASH Type. For example, in some implementations, SIGHASH_ALL is represented by a byte with a value of 1 (e.g., binary "00000001"), SIGHASH_NONE is represented by a byte with a value of 2 (e.g., binary "00000010"), SIGHASH_SINGLE is represented by a byte with a value of 3 (e.g., binary "00000011"), and SIGHASH_ANYONECANPAY is represented by a byte with a value of 80 (e.g., binary "01010000"). In some implementations, the combination of SIGHASH Type values is performed by binary addition of the respective byte values. In some examples, the set of transaction fields determined by the SIGHASH Type represents a subset determined by the SIGHASH Type value of the corresponding serialized transaction. For example, the SIGHASH Type of SIGHASH_ANYONECANPAY includes only one transaction input in the signature.

[0209] By requiring the inclusion of SIGHASH in the unlock script, the lock script can verify that the set of serialized unlock transaction fields provided by the unlock script is actually the source of the SIGHASH, and then use the OP code OP_CHECKSIG to verify that the SIGHASH Type value provided by the unlock script matches the signature hash of the unlock transaction. The lock script can do this when executed by a transaction validator, as the transaction validator can then execute the OP_CHECKSIG operation and place the signature of the actual unlock transaction on the stack.

[0210] OP_DERENCODE In the present disclosure, references to OP_DERENCODE should be regarded as an abbreviation for an operation corresponding to popping the top two items from the stack, encoding them in DER format, and pushing the result onto the stack.

[0211] OP_ECPMULT In the present disclosure, references to OP_ECPMULT should be regarded as an abbreviation for an operation corresponding to popping two items from the stack, performing an elliptic curve point multiplication (also called an elliptic curve scalar multiplication) on these two items, and pushing the result onto the stack.

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

[0213] OP_PREVTXINJECTION In the present disclosure, references to OP_PREVTXINJECTION should be regarded as an abbreviation for an operation corresponding to the injection of the previous transaction corresponding to the input X of the unlock transaction. Figure 6 shows the input and output of the OP_PREVTXINJECTION script.

[0214] OP_SELFTXINJECTION In the present disclosure, references to OP_SELFTXINJECTION should be regarded as an abbreviation for an operation corresponding to the injection of the previous transaction corresponding to the signed input. Figure 7 shows the input and output of the OP_SELFTXINJECTION script.

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

[0216] OP_EXTRACTTXID In this disclosure, references to OP_EXTRACTTXID should be regarded as an abbreviation for an operation corresponding to obtaining a transaction ID and a transaction ID position as inputs and outputting the extracted transaction ID. The input to OP_EXTRACTTXID is a value X indicating a serialized transaction and an input index, and the output is a transaction identifier associated with the transaction input at that index in the serialized transaction. This script may need to parse the serialized transaction to extract the transaction ID. Because the serialized transaction contains variable-length fields with a length distribution indicated by other fields within the serialized transaction.

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

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

[0219] In a stateless stack-based transaction verifier, the lock script 910 and the unlock script 920 are processed independently, with some minor exceptions, and do not depend on variables or other states external to these scripts. As a result, the lock script 910 need not reference fields of previous transactions external to the lock script 910 itself. The lock script 910 also cannot reference fields of the unlock transaction 922 because there was no lock transaction 922 when the previous transaction 912, and thus the lock script 910, was created and made immutable.

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

[0221] In stack - based operations, the transaction validator executes the unlock script by processing each OP - code in the script in order. Some OP - codes are processed as a result, some result in data being pushed onto the stack, popped from the stack, or some combination. When the execution of the unlock script is complete, there may be data remaining on the stack. If there are no script errors or OP - codes that end the execution during the execution of the unlock script, the transaction validator can execute the lock script and use the data present on the stack. If the lock script and the unlock script can be written using the same set of OP - codes, this is substantially similar to executing a single script that includes the concatenation of the unlock script and the subsequent lock script. However, checking for script errors at the end of the execution of the OP - codes of the unlock script and before the execution of the OP - codes of the lock script can prevent problems caused by an improper unlock script.

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

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

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

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

[0226] One such constraint could be that the unlock script must contain some arbitrary data. Among the constraints could be "weak constraints" or more general constraints, such as a constraint that the unlock script must contain data of a 4-byte length, or a constraint that it contains a certain number of bytes without constraining the bytes to specific values. That the data must produce a specific hash value when hashed can be a stronger or more specific constraint. This latter constraint typically requires that the data be of a specific length and be a value unique to that data, because it is almost impossible for someone to determine different values that produce the same hash. The constraints can be implemented in the script by the unlock script pushing that data or the hash of that data onto the stack, the lock script pushing the required hash onto the stack, then executing the OP_EQUAL, and then executing the OP_VERIFY OP code. Those OP codes return True if the two pushed items match and False if they do not. In a more general case, constraints can be imposed that require the presence of specific data or data with specific characteristics.

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

[0228] The operations of constraints and the data of constraints may include elements of "smart contracts". A smart contract is something that defines the terms of a contract, such as who can do what, when they can do it, and who, when, and what gets paid. When the terms can be expressed as weak or strong constraints on the unlock script or other parts of the unlock transaction, the terms of the smart contract can be enforced by the blockchain protocol. Thus, as in the example above, for instance, if only Bob can unlock the value of a locked transaction output (because only the unlock script that Bob can create can unlock that transaction output), the transaction output can be used only after a certain amount of time has passed, only after another transaction output has been used, if permitted by one of the parties.

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

[0230] Figure 11 shows a procedure for generating a signature from a set of serialized transaction fields. This may be done by a blockchain node creating a transaction, or by other generators of the transaction. As shown in Figure 11, the serialized transaction 1110 (i.e., a transaction represented as 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 a SIGHASH Type 1112 and provides the signer's private key. The blockchain client / node can determine from the SIGHASH Type 1112 which fields or modified fields of the serialized transaction 1110 should be used. Some of the fields may be modified (other than setting to zero) before the hash is generated. In the example of Figure 11, the SIGHASH Type is set equal to SIGHASH_NONE|SIGHASH_ANYONECANPAY, and thus the fields selected are the fields indicated by the modified serialized transaction 1114.

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

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

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

[0234] The set of serialized transaction fields of an unlock transaction does not include the unlock script of the unlock transaction itself. Otherwise, problems of causality would arise. In some embodiments, for example, in a Bitcoin blockchain environment, the signature hash of a transaction can exclude some predetermined fields. The SIGHASH Type may represent which set of fields is extracted from the transaction before being serialized and hashed.

[0235] The lock script of the previous transaction can impose on the unlock transaction the requirement that, for the unlock transaction to be valid, the unlock script of the unlock transaction needs to include a copy of some or all of the fields of the unlock transaction and a reference to one or more of the transactions before the one that the unlock transaction unlocks. Of course, the fields of the unlock transaction can be changed when the unlock transaction is created. However, the lock script of the previous transaction can impose constraints on the fields of the unlock transaction in that the unlock transaction does not need to verify at the time of execution of the lock script if the fields of the unlock transaction that are part of the unlock script of the unlock transaction do not meet the constraints. Fields that are not part of the unlock script (such as fields not included by the SIGHASH Type value or not set to zero) do not need to be constrained by the lock script. Also, not all of the fields included in the serialized unlock transaction need to require constraints. For example, the lock script may only constrain one of many fields of the serialized unlock transaction included in the unlock script.

[0236] Different outputs of a previous transaction can potentially apply different sets of constraints to different inputs and outputs of different unlock transactions. Using such techniques, a blockchain node can generate a transaction using such a lock script, which can perform additional checks such that the generated transaction output can be transferred and the transaction unlocking that output must necessarily carry various data elements and states.

[0237] The transaction of FIG. 12 can be extended to implement a state machine with fairly complex functionality. As described above, the lock script can access data that is only available after the lock script has been created and finalized at verification time. That data can include details of the fields of the unlocking transaction being verified, and details of previous transactions including the lock script (and other previous transactions known to the blockchain node creating the unlocking transaction at that time may also be possible). This allows the state of the state machine to be represented within the script, the state 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 by processing transactions in the same way as other transactions processed by the blockchain network, using transactions that are verified by potentially untrusted blockchain nodes. In some examples, "trustless" represents the property that any entity can create a valid unlocking transaction as long as the constraints are met, and that entity does not need to be trusted. However, in some cases, an entity may need to interact with a determined source to obtain the necessary inputs. In some embodiments, one or more inputs can be obtained from an undetermined source such as a serialized previous transaction.

[0238] In a blockchain network, a transaction has some values of its inputs (determined by the transaction output values of the transaction before the transaction inputs are unlocked), and some values of its outputs. For it to be valid, the total of the outputs cannot exceed the total of the inputs (excluding distribution transactions and genesis transactions which may be excluded in this explanation), and also, for it to be incorporated into a miner node, the outputs may be made smaller than the inputs to provide a reason for the operator of the miner node to participate. When implementing a trustless deterministic state machine using a blockchain network, the initial state of the state machine may exist within transactions that contain sufficient value to provide a reason to the miner for including the transactions corresponding to the state transitions of the state machine.

[0239] In a general case, the unlock script of the previous transaction can be used when implementing the state machine. As a result, the unlock transaction represents the state transition of the state machine by a lock script that restricts the content of the unlock transaction, particularly the content and nature of the various transaction outputs of the unlock transaction. Thus, the lock script of the output of the previous transaction can substantially specify how each transaction output of the unlock transaction needs to be. The lock script can require different characteristics of different unlock transaction outputs, for example, by requiring that Vout[0] of the unlock transaction contains specific data and script elements, and that Vout[1] of the unlock transaction contains specific other data and other script elements.

[0240] An entity that provides a SIGHASH Type and the set of unlock transaction fields used by a particular SIGHASH Type can unlock a transaction output. In this way, some parties have a reason to propagate the content of a transaction by unlocking and transferring details from the lock script. As described above, in some examples, "unlocking" a transaction output means creating an unlock transaction that can reference and evaluate the transaction output, thereby causing a transfer of the transaction output.

[0241] Using the techniques and apparatus described above, a transaction can include a script that implements a smart contract, can implement a state machine, and can reference the fields of the current transaction, the previous transaction having the outputs transferred by the current transaction, and optionally other previous transactions, and can be created on a blockchain ledger. These capabilities enable a transaction flow to enforce a self-replicating script, such as one used in a smart contract.

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

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

[0244] In a more general case, the constraints may go beyond simply requiring the copying of the lock script. Further, the constraint sets may vary from output to output of the unlock transaction. These constraints may require the number of outputs that the unlock transaction can have, the value of each output, and the specific content of the lock script of the outputs of the unlock transaction.

[0245] Constraints on the Outputs of the Injected Unlock Transaction Figure 14 is a flowchart of an example of a portion 1400 of the unlock script of a transaction before imposing constraints on the unlock script of an unlock transaction. This example may be executed by a stack - based verifier that processes the unlock script of the output of an unlock transaction that can leave data on the stack, and then processes the lock script of the output of the previous transaction to perform this processing. Since the processing of the unlock script can leave data on the stack, and also since the unlock script can leave, for example, the serialized content of the unlock transaction, including details of the unlock script of the unlock transaction, on the stack, these details are available at verification time.

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

[0247] For each index of the output, the verifier executes 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, instead of incrementing the index one by one and verifying each output, the verifier loops through a set of indexes, which may not necessarily include all values of i and / or may not include them in sequential order, and does not check them. In such a variation, step 1418 is different accordingly and loops through index i for the outputs within the specific set of indexes being checked.

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

[0249] The unlock script of the output of the previous transaction constrains the output of the unlock transaction so that the previous transaction lock script can indicate rules regarding how to transfer the output of the unlock transaction. These constraints can be hard-coded in the unlock script of the output of the previous transaction or can be determined based on data present in the unlock script of the input of the unlock transaction that refers to that output of the previous transaction.

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

[0251] There is step 1506 regarding specific constraints that the lock script of the output of the previous transaction can impose on the lock script of the output of the unlock transaction, and the lock script of the output Vout[i] of the unlock transaction must be equal to the data from some determined source ("==" represents an equivalence test). Another example is step 1508, where the lock script of the output Vout[i] of the unlock transaction must be equal to the data hard - coded in the lock 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 unlock transaction based on the data from the determined source, and step 1512 covers the case where another constraint is imposed on Vout[i] based on the hard - coded data from the lock script of the output of the previous transaction.

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

[0253] The data to be used may be from a previous transaction, for example, hard - coded in the lock script of the output of the previous transaction, or from a transaction preceding the previous transaction (or a reference to a preceding transaction, two links out of an unlock transaction (i.e., the transaction to which one or more of its outputs were transferred by the previous transaction)). In this way, the data to be used can be obtained from any transaction in the chain from the previous transaction to its distribution transaction (e.g., the Coinbase transaction of the Bitcoin protocol).

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

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

[0256] In FIG. 16, steps 1614 and 1616 extract the lock script for a copy of the transaction referenced by TxID n ' and verify the constraint that the lock script of the output Vout[i] of the unlock transaction is equal to the extracted lock script of the transaction referenced by TxID n '.

[0257] The constraint can apply to a subset of the output lock script, not the entire lock script. The constraint can be determined from a subset of the data, not the entire data. For example, one subset may require that "Pay-to-Public-Key-Hash" appears, and another subset may require that "Pay-to-Bob" appears.

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

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

[0260] The constraints can correspond to indexes that reference various outputs. In some cases, the constraints are repeated for each index, while in other cases, some structures can be provided. For example, the index of the constraint can be used in a conditional statement to select a set of constraints such as "if index==0: constraint A els constraint B".

[0261] If a series of indexes are hardcoded, the result of the part of the script using those indexes can be fixed. Instead of, or in addition to, the constraints on the outputs of the unlock transaction, there can also be constraints on the inputs of the unlock transaction.

[0262] Constraints on the inputs of the injected unlock transaction One use of having a lock script that constrains the inputs of an unlock transaction is to enable the lock script to encode dependencies on transactions that have certain properties (e.g., the constrained inputs must reference that transaction). This is different from constraining the outputs of an unlock transaction in that the outputs are variable. On the other hand, the inputs may be references to existing immutable UTXOs on the blockchain. In other words, the outputs can be changed to meet the constraints, while the inputs that meet those constraints must be found.

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

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

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

[0266] Figure 18 is a flowchart of an example of a portion 1800 of the lock script of a previous transaction that imposes constraints on the inputs of the unlock transaction. This example may be executed by a verifier that processes the unlock script of the output of the unlock transaction. The verifier leaves data including details of the unlock transaction on the stack and then processes the lock script of the output of the previous transaction to perform this processing.

[0267] In step 1802 of the process, the verifier verifies that the unlock script contains certain data, and the verifier may perform other verifications that are not necessary for each output. In step 1804, the verifier checks whether these constraints are met, and if not, stops at step 1806 and invalidates the unlock transaction. Otherwise, the process proceeds to step 1808, where the verifier determines whether there are unlock transaction inputs to be checked. On the first pass, the verifier can set the index i = 0, and if there are no more inputs to be checked, moves to another processing flow at step 1810.

[0268] For each index of the input, the verifier executes steps 1812, 1814, and 1816, then increments i (step 1818), and returns to step 1808 until there are no more indexes to consider (alternatively, the verifier may loop through a set of indexes, not necessarily all indexes and / or not necessarily in increasing order; in these cases, step 1818 is correspondingly different and the input is checked via index i while looping). In step 1812, the verifier extracts a reference to the previous transaction and its own unlocking output from the unlock transaction input Vin[i]. This can be implemented using an OP_SUBSTR operation on the stack content. Next, in step 1814, the verifier determines, after the constraints become applicable to the fields of the previous transaction, what constraints should be on the reference or whether to use that reference to cause an injection of the previous transaction, based on the lock script of the output of the previous transaction. In step 1816, the verifier then verifies these constraints. In this way, the lock script of the output of the previous transaction transferred by the input of the unlock transaction can impose constraints on the input of that unlock transaction.

[0269] Other examples of input constraints are shown in FIG. 19 by elements 1902, 1904, 1906, 1910, 1912, and 1914. Since the TxID may be mapped one-to-one with the transaction, this may mean a constraint that a particular transaction must be referenced within the input. The transaction on which the lock script depends is created first, whereby the lock script can use its own TxID among the constraints on the input of the unlock transaction.

[0270] Constraints can be set on fields of the previous transaction corresponding to a reference during input. This may be possible by using the TxID in the input to cause an injection of the corresponding previous transaction before imposing constraints on fields of the previous transaction. The constraint can reference an input different from the input that unlocks the output of the previous transaction having the lock script imposing the constraint.

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

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

[0273] To reference previous transactions, these transactions must already exist and be immutable before the unlocking transaction is created. Nevertheless, the previous transactions can apply interdependent lock script constraints to the unlocking transaction. By imposing constraints on the set of inputs of the unlocking transaction, an interdependent lock script can be implemented, which can provide parallelism, among other things, in the context of a trustless deterministic state machine.

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

[0275] Since the TxID of a transaction is not known until the transaction is complete, the transaction lock script cannot directly specify the TxID that the unlocking transaction unlock script should reference. Basically, however, the lock script extracts the input pointer (including the TxID of the previous transaction that has the lock script), executes this, uses that TxID to inject into the fields of the previous transaction, and can verify that some fields of the previous transaction are equal to the expected values. In other words, the previous transaction has fields set to certain values, the lock script of the previous transaction obtains the TxID from the unlocking transaction input, injects the transaction that the TxID references, checks that the fields are set to the specific values, and if the fields are not set to that specific value, the unlocking transaction input must refer to a different previous transaction. Thus, by checking for specific values, the lock script of the output of the previous transaction can confirm whether the unlocking transaction input references the output of the previous transaction.

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

[0277] Interdependent lock scripts enable, among other things, multiple smart contracts that condition each other. For example, smart contract 1 is "Alice agrees to donate 1 BTC to Carol, but only if Bob donates 2 BTC to Carol", and smart contract 2 is "Bob agrees to donate 2 BTC to Carol, but only if Alice agrees to donate 1 BTC to Carol". For it to be valid, the unlocking transaction must unlock both smart contracts.

[0278] As described above, lock scripts can encode dependencies on transactions with specific properties, and those properties can include fields of that transaction. This means that it is possible to make a lock script dependent on a transaction that has a specific lock script.

[0279] For example, in the example of Figure 21, lock script #1 (of Vout[0] of Previous Tx1) restricts Vin[1] of Unlocking Tx1 to reference lock script 2124 (of Vout[0] of Previous Tx2), and lock script #3 2124 restricts Vout[0] of Unlocking Tx1 to reference lock script #1 of Vout[0] of Previous Tx1. Here, this can be called a lock script that encodes a dependency on another lock script.

[0280] Implementing mutually dependent 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. This is because one of Previous Tx1 and Previous Tx2 may exist earlier than the other. If lock script A hard - codes a dependency on lock script B, lock script B must already be known and determined, and it is impossible for lock script B to hard - code a dependency on an unknown lock script A. This can be addressed by having determinable dependencies in at least one of the lock scripts.

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

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

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

[0284] State machine Using the above techniques, a state machine can be implemented using blockchain transactions. Here, the transaction has a state, is encoded by a state machine structure such as a transaction matrix, and the next state is allowed. An unlock transaction can unlock the output of such a blockchain transaction and effectively cause a state transition of the state machine.

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

[0286] In embodiments, the set of state rules 2206 may include a state transition matrix that can be represented by constraints imposed on the unlock transaction 2204 by a lock script. In such embodiments, the constraints may be parameterized by the current state and the input that determines the next state. The constraints may include checks to ensure that the unlock transaction 2204 includes an output that contains the next state value in a particular field.

[0287] In embodiments, the current state is represented as a parameter embedded in the transaction, such as part of the lock script of the output of the transaction, and the unlock transaction 2204 may have a next state value embedded in the unlock transaction 2204. The next state value may be the current state with respect to a set of field values of the unlock transaction 2204 and may be accessible when the unlock transaction 2204 is generated, as described above.

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

[0289] FIG. 23 shows this. In this example, the trustless deterministic state machine system 2300 may include a previous transaction 2302 in a first state 2328A (“S1”) within a set of state rules 2306. The set of state rules 2306 provides two possible states 2330A (“S2” or “S3”) for the next state. The set of state rules 2306 may be encoded within the lock script of the output of the previous transaction 2302. The current state 2328A may be embedded in a Lock time field or in the lock script. The next state, S2 2328B in this example, is encoded within the lock script of the output of the unlock transaction that unlocks the output of the previous transaction to effect the state transition.

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

[0291] In an embodiment, each possible state is a set of rules for state changes, such as a state transition matrix, represented within a self-replicating unlock script, and a particular transaction output represents a state machine in a particular state. In such an embodiment, the unlock script of the transaction output is replicated to all unlock transactions that attempt to transfer control of the digital asset to the next transaction that must be linked to the current transaction output. This process may be repeated until an end condition is met. Since the inputs are not finalized and may be undetermined data, the state of the state machine can be changed based on particular external inputs. Thus, the undetermined data provides inputs that can affect the next state.

[0292] As an example for illustration, Alice lends funds to Bob, and Bob agrees to repay Alice. A trustless deterministic state machine as described in the present disclosure can be implemented as a smart contract representing the payments that Bob makes to Alice. For example, the smart contract can be constructed such that Bob makes payments to Alice every month for the next three months, and if Bob fails to make a payment, his debt enters the collection stage. Thus, as long as Bob makes monthly payments, the current state remains the repayment state. However, if an external entity provides an input indicating that Bob has failed to make a payment, the state branches to the delinquent state. In the delinquent state, Alice can release the transaction and transfer it to a debt collector, as a result of which the trustless deterministic state machine switches to the debt collection state. In the debt collection state, the debt collector recovers the debt from Bob. Such a smart contract can be created using variations of the scripts described herein.

[0293] In another example, Alice is a very charitable person and donates one unit of digital assets every month. Under her rules, anyone can claim digital assets, but only one unit per month can be claimed. Alice creates a smart contract in the manner described in the present disclosure and seeds it with an initial pool of three units of digital assets. Alice can construct a script such that any entity can obtain one unit of digital assets per month. The remaining portion of the digital assets is replicated to subsequent smart contracts.

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

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

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

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

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

[0299] In the context of describing the disclosed embodiments, unless otherwise specified, the use of the expression regarding executable instructions (also referred to as code, application, agent, etc.) that execute operations (such as data transmission, calculation, etc.) that usually do not execute alone by an instruction means that the instruction is executed by a machine and thereby causes the machine to execute the specified operation.

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

[0301] As will be described in more detail, a trustless deterministic state machine can be implemented using the lock script and unlock script of a blockchain transaction. The lock script contains the constraints that can be imposed on the unlock script and thus requires the injection of specific data into the unlock script of the unlock transaction input, such as the serialized fields of the unlock transaction itself, the serialized fields of the previous transaction containing the lock script being executed, the current state value, the input (optional) from the determined source, and the state transition matrix defining a series of flow conditions and operations of the state machine, and defines how to calculate the next state from the current state and other inputs. One of the constraints of the lock script in the unlock transaction is that the unlock transaction must replicate the lock script in one of its outputs and propagate the state machine.

[0302] Figure 26 shows a state machine that uses a state transition matrix 2600 with specific characteristics. State S1 is highlighted to indicate the current state. The state machine can transition to any state along the state transitions indicated by the arrows. In that state transition matrix, it is possible to transition along S1 - S2 - S3 - S4 - S8 - S12, but a transition from S1 may also be required at state S5. Similarly, state S5 transitions to S6 and S9. The transition from state S9 to state S10 may be conditional or have a barrier in the sense that the state transition shall not occur until the transition from state S6 to state S7, which occurs in parallel, has occurred. The transition to state S8 may occur as a merger from state S4 and state S7.

[0303] Each of these states is initiated by a state machine represented by a blockchain transaction output, each transition is processed by a single pass of the transaction output, and when the unlock transaction input unlocks the output of the previous transaction, a state transition as shown in FIG. 22 or FIG. 23 occurs. However, parallel processing of states can be achieved using the inputs and outputs of blockchain transactions. This is convenient when it is necessary to execute a smart contract in multiple parallel steps. During the process of a contract, it may be possible to execute operations in parallel during the process of the contract. For example, in a contract to build a house, there are various stages of completion of tile work and various stages of completion of landscaping work, but these can be carried out in parallel. By enabling parallel execution within a smart contract, different fragments of the contract can be executed asynchronously and independently of each other.

[0304] Figure 26 shows many requirements for such processing. One is to generate multiple paths from one state. This can be a fork in a smart contract. Assume that a smart contract starts in state S1. The fork of this smart contract can generate two state machines in states S2 and S5. Another requirement is the replication of a smart contract, with two identical state machines each in the same state and operating in parallel. For example, a smart contract may require multiple instances of the steps S2 - S3 - S4. This can be the cloning of a smart contract, a special case of a fork, where two or more new transaction outputs have the same state.

[0305] Another useful feature is the creation of a new contract. For example, the smart contract represented by the state transition matrix 2600 in Figure 26 may be such that in state S3, some party to the smart contract can create a separate contract that can be associated with the smart contract, but is not part of the smart contract and / or can be created after the smart contract is created. This can be called spawning in this specification. This new contract can be different from the original smart contract first provided in the state transition diagram of Figure 26.

[0306] Fusion means that two state machines or two smart contracts merge, as in the cases of states S4 and S7. As will be described below, different paths can be executed in parallel, such as S2 - S3 - S4, S5 - S6 - S7. Using these elements, a parallel trustless deterministic state machine can be easily implemented in a blockchain environment.

[0307] Figure 27 shows an example of a transaction having one input Vin[0] and two outputs Vout[0] and Vout[1]. By unlocking the outputs of this transaction, two independent transactions are placed on the blockchain ledger, and the creators of these transactions will be compensated by some value (not shown) presented to them by this transaction. As shown in the figure, the lock script of the output (referred to by Vin[0]) of the previous transaction requires that the unlock transaction unlocking that output includes states S2 and S5. To unlock the output (Vout[0] in Figure 27) of the unlock transaction including state S2, a future unlock transaction is constrained to include the next state based on the current state being S2. The same applies to state S5.

[0308] In this way, a transaction output can have a state and can impose constraints on what state an unlock transaction can be in. Thereby, blockchain transactions can implement processing according to a state diagram as shown in Figure 26, and the unlocking of a transaction output corresponds to a state transition in the state diagram. To avoid a situation where someone creates one transaction with multiple inputs and unlocks both outputs of the shown transaction, the lock script can check that transaction and disallow it. Rules for how a valid transaction is generated, the number of required outputs, etc. are encoded in the smart contract as hardcoded values or parameters provided after the smart contract is created.

[0309] Forking and Cloning of Smart Contracts Using Blockchain Transactions A fork is used when a state needs to transition in parallel to two or more (not necessarily unique) next states. A smart contract may be able to handle without all possible parallelism, but if parallelism should exist, a fork may initiate it. As described above, the lock script of the output of a smart contract transaction on the blockchain ledger can "impose" requirements on the input of the unlock transaction and / or the lock script of the output of the unlock transaction on the blockchain ledger. Cloning may be a specific type of fork where the set of next states may all be the same state. Regarding the unlock transaction, multiple outputs may be restricted to replicate the transition matrix and embed each respective next state.

[0310] Forking / cloning can be achieved by applying the constraints of a trustless deterministic state machine to the set of outputs. As described above, a series of indices enables applying different constraints to different outputs. This series of indices can be hardcoded within the transition matrix or provided as part of the input to the verification process.

[0311] A given unlock transaction may have multiple outputs, some of which may be unrelated to the state machine, or may be related to multiple unrelated state machines. So, it is more practical to embed the next state in the lock script of the transaction rather than in a field common to all outputs such as the Lock time field. Regarding restricting a subset of the lock script of the output, it is as described above.

[0312] Figure 28 shows how the script relates to the branching operation. As shown, the state machine 2810 is implemented using the previous transaction 2820 and the unlock transaction 2830. The lock script of the previous transaction 2820 constrains the unlock transaction 2830 to have at least two outputs, each of which requires that the subsequent unlock transaction have the output in the specified state (and be a separate transaction). This allows these states S2, S3 to be executed independently and, if possible, in parallel.

[0313] Using a state machine helps enable smart contracts for sub-tasks to execute faster and in parallel. Multiple states may be used to process sub-tasks, and since a single state machine can typically only be used in a single state at a time, simultaneity can be provided by having separate transaction threads. The state machine can be branched by creating multiple transaction lock scripts. Based on the current state from the output of the previous transaction, the unlock transaction can be constrained to have two or more outputs with lock scripts, as shown in Figure 28. To prevent the branch from becoming insolvent and stopping prematurely, each output value should be checked to ensure there is sufficient funds to continue the state machine.

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

[0315] The lock script of the output of the previous transaction is composed of the concatenation of <Current State><Transition Matrix><other script>, while the lock script of the output of the unlock transaction is <nextstate> <transitionmatrix>It may be composed of a concatenation of <other script>. Instead of replicating the entire lock script, only a subset of the lock script may be replicated, and other subsets may be restricted to include state.

[0316] Instead of storing the state in the lock script, the state of the state machine can be stored in a field of the transaction. This field cannot be used for other purposes such as the Lock time field. In practice, another unused transaction field can be used. This operates in a single state and can also operate when multiple states need to be stored, but it may be more complex.

[0317] Figure 29 shows an example of pseudocode that can be executed to perform a branching or cloning process. This pseudocode can be implemented using the OP codes described herein. This pseudocode can be executed by a processor of a blockchain node that generates and / or verifies transactions. In some embodiments, part of the script is from the unlock script and part of the script is from the lock script.

[0318] In the pseudocode of FIG. 29, the previous transaction, unlock transaction, and optional inputs are injected so that the lock script can access them. Thereafter, a check of the termination condition may be performed. If the smart contract has not terminated, the processor extracts the lock script of the previous transaction and the current state of the previous transaction, which can be done using the techniques described herein. Next, the processor loops through the outputs of the unlock transaction and for each of them extracts its lock script and checks the transaction matrix within the previous transaction lock script to determine whether it matches the transaction matrix within the lock script of the unlock transaction output being processed. If they do not match, the processor treats it as a script failure and does not verify the unlock transaction. If they match, the processor determines the next state of the state machine from the extracted current state, state transition matrix, optionally inputs, and output index value. Next, the processor checks the next state determined for the next state of the unlock transaction output being processed. If they do not match, the processor treats it as a failure of the script, halts, and does not verify the unlock transaction. If there are any other optional constraints to be checked, they can be checked at this time. If all constraints are met, the script passes.

[0319] Worker spawning smart contract In the previous section, the ability to fork and clone smart contracts was described. In this section, the ability to force a new smart contract to exist within an unlock transaction is detailed. The unlock transaction can be a smart contract that is not a completely different state machine or a completely different type of smart contract but is not a state machine.

[0320] An example of a constraint to enforce a new smart contract that is a state machine is shown in FIG. 30. As shown, the lock script of the output of the previous transaction places a constraint on the output of the unlock transaction such that the unlock transaction output lock script must be equal to the desired new smart contract script, or the hash of the output lock script must be equal to the hash of the desired new smart contract script. The new smart contract script or hash is hardcoded in the lock script of the output of the previous transaction or is securely provided as a parameter via the unlock script of the unlock transaction input. Multiple new smart contracts in the unlock transaction output can be enforced by having corresponding constraints within the lock script for each new smart contract as described above.

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

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

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

[0324] From the perspective of a state machine, the state machine can instantiate a new and different state machine to execute in parallel with the calling state machine. To apply this approach to a state machine, the lock script for this operation may be similar to that of a fork / clone operation, but instead of checking each new state machine instance for equivalence in that lock script, the existence of a new smart contract may be checked. The equivalence check can be performed over a variety of different value ranges, including a set of serialized transaction fields for the transaction, lock script bytecode, or hashes of these.

[0325] Figure 30 shows the creation of a new smart contract. As shown here, the state machine 3010 is implemented using the previous transaction 3020 and the unlock transaction 3030. The lock script of the output Vout[0] of the previous transaction 3020 constrains the unlock transaction 3030 to have at least two outputs, Vout[x] and Vout[y], each of which requires that the subsequent unlock transaction have the output in the specified state (and be a separate transaction). Specifically, as shown, the input Vin[0] of the unlock transaction 3030 unlocks Vout[0] of the previous transaction 3020, so the unlock transaction 3030 can be constrained such that Vout[x] has a transition matrix and is in state S4, while Vout[y] can be constrained to have a new smart contract.

[0326] In 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 described above, the new smart contract does not necessarily have to be a state machine itself, in which case the resulting smart contract may not have a field for state values.

[0327] As indicated by the dashed arrow in Figure 30, the input Vin[0] of the unlock transaction 3030 refers to the previous transaction 3020 and its output Vout[0]. This can be in the form of the TxID of the previous transaction 3020 and an integer value set to "0" to refer to the output Vout[0]. The lock script of Vout[0] includes the current state ("S3") and the transition matrix of the state machine, and constrains the Vout[x] of the unlock transaction 3030 to be in the next state of the state machine ("S4"), and the Vout[y] of the unlock transaction 3030 to be a new smart contract ("NSC"), and possibly other constraints.

[0328] As an example, the pseudo-code of an example of an operator creation process and a process of forcibly making a new smart contract exist in an unlock transaction can be shown in FIG. 31.

[0329] Merging of smart contracts When it is necessary to merge two or more states into the same next state, state fusion or combination can be used. In some cases, when not required by the smart contract, state machines operating in parallel may be in the same state but may not be merged. For example, in the state diagram of FIG. 26, S4 and S7 can transition to S8 separately and remain as two separate transactions.

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

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

[0332] As shown in FIG. 32, Vin[0] indicates the previous transaction 3220 and its output Vout[0], while Vin[1] indicates the previous transaction 3222 and its output Vout[0]. The lock scripts of both Vout[0]s constrain the Vout[x] of the unlock transaction 3230 to have the next state S8 and the state transition matrix. These constraints can be enforced by the lock script of the previous transaction 3222 that checks that the new smart contract is the output of the unlock transaction.

[0333] To achieve this with a parallel state machine, the transaction can use multiple inputs with inputs for each state machine to be combined. Constraints can be added within the state machine transition matrix to check the states of all the combined independent state machines. If one of the combined state machines is not in a converging state, the transaction may be rejected. To ensure the combining operation, constraints can be added to the state machine to confirm that there are two unlock scripts based on the state of the unlock transaction. For each script, a check can be performed to confirm that each script is in the correct state required for the transition. As described elsewhere in this specification, interdependent lock constraints can also be used.

[0334] FIG. 33 shows a pseudo-code sequence as an example of the process of fusing smart contracts in an unlock transaction with weak dependencies. In the fusion, a transition occurs from a series of current states (not necessarily unique states) to a shared next state. For the unlock transaction, the set of its inputs can unlock a set of lock scripts that share the constraint that the same output replicates the transition matrix and embeds the same next state. In the case of weak dependencies, there may be multiple state machines with the same next state for the same output.

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

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

[0337] Figure 34 shows a pseudo-code sequence as an example of a process for fusing smart contracts in an unlock transaction having explicit dependencies. In explicit dependencies, there may be multiple state machines, and it is not sufficient for them to have the same next state for the same output. Additionally, they may be distinct and separate state machines. The fusion according to FIGS. 32 and 34 can occur due to explicit dependencies. In the case of strong constraints, the unlock transaction may be required to refer to two or more distinct fused state machines.

[0338] In the pseudo-code sequence of FIG. 34, a processor that processes the script according to the pseudo-code sequence can inject the previous transaction, unlock transaction, and optionally some input data, and check for termination conditions before proceeding. Next, the processor extracts the unlock transaction lock script. Next, the processor loops through a series of input indices to extract the corresponding previous transaction lock script, checks whether the transition matrix in the corresponding previous transaction lock script is equal to the transition matrix in the unlock transaction lock script, and aborts if not. From there, the processor extracts the current state value of the previous transaction, adds it to the list of current states, and repeats for other inputs. From the current state, and the transition matrix and input (if used), the processor determines the next state and checks whether the next state matches the next state in the unlock transaction lock script. Optionally, other constraints can be checked here.

[0339] Parallel Smart Contract / Barrier As described above, two or more smart contracts can be fused into one smart contract with weak or strong constraints. It is also useful to have two or more smart contracts that can be executed in parallel. This may be more than parallel processing in that there is a constraint that two parallel paths must pass through one unlock transaction. This can also be used for a "barrier" within a parallel state machine, where certain transitions are not allowed to occur until another transition occurs elsewhere within the state machine.

[0340] Figure 35 shows a parallel processing operation. In this case, the unlock transaction 3530 has two inputs (Vin[0], Vin[1]), one for each of the previous transaction 3520 and the previous transaction 3530, and two outputs (Vout[x], Vout[y]) for continuing each of the separate smart contracts. The unlock transaction 3530 includes an unlock script that includes each of the previous transactions of the smart contract. Additionally, a lock script for each smart contract may be required to continue its execution. When using parallel smart contracts, each contract cannot transition independently, but instead all contracts (defined within the lock script) need to be done in parallel.

[0341] The previous examples branched smart contracts, fused two smart contracts, and provided parallel operation of two (or more smart contracts). These can be used in combination with parallel smart contracts. Barriers may be used when state transitions are in a logical relationship with other state transitions. As an example, it may require that another state machine be in a particular state or require input data from that state machine.

[0342] To facilitate this functionality, an unlock transaction can be created that includes multiple inputs and outputs. Each of the state machines (transitioning or related to constraints) required for the barrier may be included in their own unlock script. A lock script may be used for each state machine that executes a transition. In the example shown in FIG. 26, the transition from state S9 to S10 is allowed, but is only allowed if the transition from S6 to S7 occurs in parallel. For the unlock transaction, there are two unlock scripts, one for the state machine in state S6 and one for the state machine in state S9. Next, the unlock transaction has two lock scripts. One is for the state machine remaining in S7 and the other is for the state machine currently in S10.

[0343] FIG. 36 is a pseudo-code sequence as an example for using barriers in a parallel state machine that requires parallel transaction inputs / outputs. In this example, the script according to the pseudo-code sequence checks that each of the previous transactions has the same lock script as the lock script within the unlock transaction. In this example, one lock script is set to match the first previous transaction, etc. Next, the script according to the pseudo-code sequence extracts the current state from both previous transactions, reads the inputs of both state machines, and checks the barriers set for both state transitions.

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

[0345] The lock script of Vout[0] of the previous transaction 3520 imposes dependency #5, which requires that Vout[x] has state = S8 and has the transition matrix of state machine 1, and dependency #6, which requires that Vout[y] has state = S8 and has the transition matrix of state machine 2. The lock script of Vout[0] of the previous transaction 3522 imposes dependencies #7 and #8 in a similar manner. In some examples, instead of the constraints of the state machine, other forms of constraints of the smart contract may be used. The outputs of two (or more) previous transactions can provide a parallel smart contract because they constrain two (or more) unlock transaction outputs.

[0346] A barrier may be different from a merge. A barrier is the case where the transitions from a set of current states (not necessarily unique) are restricted to occur in parallel. For an unlock transaction, the set of its inputs may be to unlock a set of mutually dependent lock scripts, and all of them may apply their respective constraints to the set of outputs. The mutually dependent lock scripts may be a set of requirements and shared next states, but may not be required if possible. The mutually dependent lock scripts can be embedded in the transition matrix such that a particular transition requires this mutual dependency.

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

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

[0349] (2) Worker spawning. This can be used when a particular type of dance requires more lessons or when a different evaluation is provided compared to other types of dance.

[0350] (3) Merge. This process can be used at points S3 and S6 when a student reaches a new grade. In the new grade, it is necessary to evaluate each student in the final state S4 of the embedded dance state machine.

[0351] (4) Parallel Transaction / Barrier. It can be used to constrain state transitions within one state machine by another state machine. In the case of this usage example, it can be assumed that the transitions between S2 and S4 need to occur in parallel. This is because it is not possible to execute one dance type in one lesson.

[0352] Therefore, the present specification and drawings should be considered in an illustrative rather than a restrictive sense. However, it will be apparent that various modifications and changes can be made to it without departing from the scope of the invention as set forth in the claims. Similarly, other variations are within the scope of the present disclosure. Accordingly, the disclosed technology readily accepts various modifications and alternative configurations, some of which are illustrated in the drawings and described in detail above. However, it is not intended to limit the invention to the specific forms disclosed, but on the contrary, it is intended to cover all modifications, alternative configurations, and equivalents within the scope of the invention as defined in the appended claims.

[0353] The use of the terms “a” and “an” and “the” and similar reference terms in the context of describing the disclosed embodiments (in particular, in the context of the following claims) is to be construed to include both the singular and the plural forms unless otherwise indicated or clearly contradicted. The terms “comprising,” “having,” “including,” and “include” are to be construed as open-ended terms (i.e., meaning “including, but not limited to”) unless otherwise indicated. The term “connected” is to be construed to mean either physically connected without modification or, even if there is some intervening element, partially or wholly contained within, attached to, or coupled with. The recitation of a range of values in this disclosure is intended to function only as a convenient method of referring individually to each value that falls within the range, as if each value were individually recited, unless otherwise indicated. The term “set” (e.g., “a set of items”) or “subset” is to be construed as a non-empty set consisting of one or more elements unless otherwise noted or contradicted by the context, and further, the corresponding set term “subset” is not necessarily indicative of a proper subset of the corresponding set, although the subset and the corresponding set may be equal, unless otherwise noted or contradicted by the context.

[0354] Conjunctive phrases such as the phrase in the form of "at least one of A, B, and C" or "at least one of A, B, or C", unless otherwise specified or clearly inconsistent with the context, are understood in the generally used context, and items, terms, etc. indicate that they can be any non-empty subset of A, B, or C, or the set of A, B, and C. For example, in an example for the description of a set having three components, "at least one of A, B, and C" and "at least one of A, B, or C" refer to any of the following sets: {A}, {B}, {C}, {A}, {A, B}, {A}, {C}, {A, {B, C}}. Therefore, such conjunctive phrases are generally not intended to mean that a particular embodiment requires at least one of A, at least one of B, and at least one of C for each to exist.

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

[0356] Any examples provided, or the use of illustrative language (e.g., "such as"), are intended only to better clarify embodiments of the present invention and do not limit the scope of the present invention unless otherwise claimed. No usage of words in this specification should be construed as indicating that any element not claimed is essential for the practice of the present invention.

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

[0358] All references, including the publications, patent applications, and patents cited, are incorporated herein by reference in their entirety to the same extent as if each reference were individually and specifically incorporated by reference as a reference.

[0359] The above embodiments do not limit the present invention but illustrate it. It should be noted that those skilled in the art can design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, reference signs enclosed in parentheses shall not be construed as limiting the claims. The terms "comprising", "comprises", etc. do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "having", "comprising" (comprising, comprises) means "having", "comprising", "consisting of" (including, includes, consisting of). The singular form of an element does not exclude the plural form of such an element, and vice versa. The present invention can be implemented by means of several distinct elements of hardware and by a computer appropriately programmed. In apparatus claims listing several means, some of these means can be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be advantageously utilized.

Explanation of Signs

[0360] 100 Blockchain network 102 Node 104 Transaction< / transitionmatrix> < / nextstate> < / y> < / x> < / y> < / x> < / y> < / x> < / y> < / x> < / k> < / k> < / k> < / m> < / m>

Claims

1. A computer-implemented method, comprising: a step in which a computer generates an unlock transaction, obtaining a hash that is the transaction ID (TxID) of the previous transaction (TxZ) and the output (n) of the previous transaction, including them as transaction inputs in the unlock transaction, and the following: the normalized version of the previous transaction (TxZ), the normalized version of a further previous transaction (TxZ’) having an output transferred by the previous transaction (TxZ), a set of normalized unlock transaction fields of the unlock transaction, a byte indicating which unlock transaction fields of the unlock transaction are included in the unlock script, generating the same, and including them as an unlock script in the unlock transaction, including a lock script as an output in the unlock transaction, the computer-implemented method comprising the steps.

2. The lock script of the previous transaction constrains the unlock script of the unlock transaction to include the set of normalized unlock transaction fields of the unlock transaction, the computer-implemented method according to claim 1.

3. The lock script of the previous transaction constrains the unlock script to include the normalized version of the previous transaction (TxZ), the computer-implemented method according to claim 2.

4. The transaction ID of the previous transaction is extracted from a field of the unlock transaction, the computer-implemented method according to any one of claims 1 to 3.

5. The unlock script further includes one or more normalized versions of the previous transaction, the computer-implemented method according to any one of claims 1 to 4.

6. Different outputs of the previous transaction apply different sets of constraints to different inputs and outputs of different unlock blockchain transactions, the computer-implemented method according to any one of claims 1 to 5.

7. The lock script of the output of the previous transaction is used to implement a state machine, the unlock transaction represents a state transition of the state machine, and the lock script constrains the content of the unlock transaction. The computer-implemented method according to claim 1.

8. The method includes the computer verifying that the unlock script includes a normalized set of the unlock transaction fields, a normalized version of the previous transaction, and a reference to the previous transaction. The computer-implemented method according to any one of claims 1 to 7.

9. The method includes the computer extracting the lock script of the unlock transaction, and determining the constraints imposed on the lock script of the unlock transaction based on the lock script of the output of the previous transaction. The computer-implemented method according to claim 8.

10. The computer-implemented method according to claim 9, further including the computer verifying the constraints.

11. The method includes a blockchain node in a blockchain network verifying the unlock transaction. The computer-implemented method according to any one of claims 1 to 10.

12.

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

14. A computer program, which causes a computer to execute the computer-implemented method according to any one of claims 1 to 11 as a result of execution by a processor of the computer.

15. A non-transitory computer-readable storage medium storing the computer program according to claim 14.

Images