METHOD AND SYSTEM FOR BLOCKCHAIN ​​IMPLEMENTED SCRIPT-BASED BYTE INTERPRETATION

Abstract

To provide a method and system configured to set criteria for reassociating or transferring digital assets, thereby improving a blockchain technology including the execution of machine-executable smart contracts.SOLUTION: A spending transaction which transfers control of at least one digital asset or portion thereof references a previous transaction that includes a locking script with a bytecode sequence. The spending transaction also includes a locking script with the same bytecode sequence. The spending transaction can be validated by verifying that the bytecode sequences of the locking scripts of the spending and previous transactions match one another. Control of the at least one digital asset or portion thereof can be transferred as a result of execution of the locking script. For example, the locking script can impose a set of conditions for validation of the spending transaction.SELECTED DRAWING: Figure 4A

Description

[Technical field]

[0001] The present invention relates generally to blockchain technology, and more particularly to blockchain transactions employing spending transaction scripts, and is particularly suited for use in, but not limited to, the automated execution of smart contracts.

[0002] This application claims priority to UK Patent Application No. 1713046.9, filed August 15, 2017, which is incorporated herein by reference in its entirety. [Background technology]

[0003] In this document, the term “blockchain” is used to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Although “Bitcoin” may be referenced in this disclosure for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. For example, the present invention may be useful in other blockchain implementations that have similar limitations as Bitcoin regarding what constraints can be encoded within a transaction.

[0004] A blockchain is a peer-to-peer, electronic ledger implemented as a computer-based decentralised distributed system composed of blocks, which are further composed of transactions and other information. For example, for Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. In some implementations, the transfer of control of a digital asset can be performed by re-associating at least a portion of the digital asset from a first entity to a second entity. Each block contains a hash of the previous block, and blocks are then chained together to create a permanent, immutable record of all transactions that have been written since the inception of the blockchain. Transactions contain small programs, known as scripts, embedded in the inputs and outputs of the transaction, which specify how and by whom the output of the transaction can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0005] That is, stack-based scripting languages ​​may utilize a data structure called a stack, where values ​​can be pushed onto or popped off the top of the stack.

[0006] A transaction must be “validated” before it can be written to the blockchain. Network nodes (miners) work to ensure that each transaction is valid, and invalid transactions are rejected from the network. One node may have a different standard of validity than another. Since validity in the blockchain is based on consensus, a transaction is considered valid if a majority of nodes agree that it is valid. A software client installed at a node performs this validation work on a transaction, in part with reference to the unspent transaction (UTXO), by executing UTXO locking and unlocking scripts. A transaction is valid by a node if the execution of the locking and unlocking scripts evaluates to TRUE and other validation conditions, if applicable, are met. A confirmed transaction is propagated to other network nodes, where miner nodes may choose to include the transaction in the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be confirmed by the first node that receives it. If the transaction is confirmed, the node relays it to other nodes in the network. The transaction then must ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to a public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible. Summary of the Invention

[0007] One area of ​​current research is the use of blockchain for the implementation of “smart contracts”, which are computer programs designed to automate the execution of machine-readable contracts or terms of agreements. Unlike traditional contracts, which would be written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce outcomes, and then actions can be taken that depend on those outcomes.

[0008] In embodiments, a smart contract is “smart” in the sense that a creator, or some other specific entity, is not responsible for the enforcement and / or execution of the smart contract. That is, interactions with specific entities may be encoded in specific steps in the smart contract, but the smart contract may otherwise be automatically executed by a machine and be self-enforced. It is machine-readable and executable. In some embodiments, self-executing refers to any entity that can spend UTXOs and has an incentive (e.g., reward) to do so. Note that in such implementations, “any entity” that can spend UTXOs refers to an entity that can create an unlocking script without being required to prove knowledge of any secret. In other words, spending transactions may be verified without verifying that the source of the data has access to cryptographic secrets (e.g., private asymmetric keys, symmetric keys, etc.). Also, in such embodiments, self-execution refers to a validation node in the blockchain network that is adapted to execute a spend transaction according to the constraints. In some embodiments, "spending" a UTXO refers to creating a spend transaction that references the UTXO and executes as valid.

[0009] The output of a blockchain transaction includes a locking script and information about the ownership of a digital asset, such as Bitcoin. A locking script, also referred to as an encumbrance, “locks” a digital asset by specifying conditions that must be met to spend the output. For example, a locking script could require that certain data be provided in the unlocking script to unlock the associated digital asset. A locking script is also known as a “scriptPubKey” in Bitcoin. Techniques for requiring a party to provide data to unlock a digital asset include embedding a hash of the data into the locking script.

[0010] It would therefore be desirable to provide an improved method and system that improves upon blockchain technology in one or more of these aspects.Therefore, in accordance with the present invention there is provided a method and corresponding system as defined in the accompanying claims.

[0011] The present invention may be described as a verification method / system and / or a control method / system for controlling the exchange or transfer of digital resources or assets over a blockchain. The terms "asset" and "resource" may be used interchangeably herein. A digital resource may be a token, a portion of a cryptocurrency, etc. As described below, the present invention may also be described as a security method / system for new, improved and advantageous ways of performing operations over a blockchain network or platform.

[0012] As described in more detail below, in one embodiment, a trustless, deterministic state machine may be embodied by a (first) locking script implemented or represented by a bytecode sequence. In an embodiment, the locking script may be part of or included in a parameterized smart contract, whereby a first ("spending") blockchain transaction is used to transfer control of a digital asset / resource. The spending transaction may reference a previous transaction that includes a locking script having a bytecode sequence. The spending transaction may also include a locking script having a bytecode sequence, such that the locking scripts of the previous transaction and the spending transaction share the same bytecode sequence. The spending transaction may be received at a node in a blockchain network. It may be verified by retrieving the previous transaction and verifying that the locking scripts of the previous transaction and the spending transaction share the same bytecode sequence.

[0013] In other embodiments, the locking script of the previous transaction may also include an interpreter code used to interpret bytecode sequences of the locking script of the previous transaction, and the locking script of the spend transaction may also include an interpreter code such that the locking scripts of the previous transaction and the spend transaction share the same interpreter code. The interpreter code may support translation of at least one high-level bytecode operation into a low-level bytecode operation performed by the node validating the spend transaction. In this case, validating the spend transaction may further include verifying that the locking scripts of the previous transaction and the spend transaction share the same interpreter code.

[0014] As described in more detail below, in one embodiment, a bytecode sequence and / or interpreter code of a locking script may be replicated as part of the locking script for an ordered number (or sequence) of spend transactions until a termination condition is met.

[0015] Thus, according to one embodiment of the invention, there may be provided a computer-implemented method, the method comprising: The method includes receiving a first blockchain transaction (a “spending transaction”) to transfer control of at least one digital asset or a portion thereof, the first blockchain transaction including a (first) locking script represented by a bytecode sequence, and the first blockchain transaction references a previous (blockchain) transaction including a (second) locking script represented by a bytecode sequence, such that the first and second locking scripts share an identical bytecode sequence. The first transaction may be referred to as a “spending” transaction. It may be received at a node in a blockchain network. It may be configured to transfer control of a digital asset (which may also be referred to as a “digital resource”) to an entity, party, or node over the network.

[0016] The method also includes the following steps. Validating the first (spend) blockchain transaction by verifying that the bytecode sequence of the first locking script matches the bytecode sequence of the locking script of a previous transaction (i.e., the second locking script).

[0017] Preferably, the first blockchain transaction further includes an interpreter code, and the previous transaction further includes an interpreter code, such that the first blockchain transaction and the previous transaction share the same interpreter code for interpreting the bytecode sequences of the first and second locking scripts, and the step of validating the first blockchain transaction further includes the step of verifying that the interpreter code of the first blockchain transaction matches the interpreter code of the previous transaction.

[0018] Preferably, the first blockchain transaction is received and / or verified by a node in the blockchain network. Additionally or alternatively, previous blockchain transactions may be stored on a blockchain maintained by the node of the blockchain network. Additionally or alternatively, the first blockchain transaction may be generated by replicating at least a portion of a previous blockchain transaction. Additionally or alternatively, the first locking script may include at least one operation to verify that a bytecode sequence of the first locking script matches a bytecode sequence of the second locking script. An interpreter code may be included as part of the first and second locking scripts. Additionally or alternatively, the interpreter code may support translating at least one high-level bytecode operation into a low-level bytecode operation executed by the node. Additionally or alternatively, the first locking script may include at least one operation configured to verify that an interpreter code of the first locking script matches an interpreter code of the second locking script.

[0019] Preferably, the first and second locking scripts (i.e., the locking scripts of the spending transaction and the previous transaction) further include data regarding different execution states of the bytecode sequence shared by the first and second locking scripts, where such data is used to control the execution of the interpretation of the bytecode sequence when validating the first blockchain transaction.

[0020] Preferably, the second locking script includes state data for a current execution state of the bytecode sequence and an execution pointer corresponding to the current execution state of the bytecode sequence, where the first locking script further includes state data for a next execution state of the bytecode sequence and an execution pointer corresponding to the next execution state of the bytecode sequence (of the locking script). And, the step of validating the first blockchain transaction further includes: i) using the data representing the current execution state of the bytecode sequence to restore the current execution state of the bytecode sequence; ii) executing the bytecode sequence starting at the execution pointer corresponding to the current execution state of the bytecode sequence and ending at the execution pointer corresponding to the next execution state of the bytecode sequence; and iii) comparing the state data resulting from the execution of the bytecode sequence with the state data for the next execution state of the bytecode sequence of the second locking script included in the first blockchain transaction to verify that such state data match.

[0021] Preferably, the step of verifying the first blockchain transaction further includes the steps of reading state data relating to a current execution state of the bytecode sequence from the virtual memory; reading an execution pointer from the virtual memory corresponding to the current execution state of the bytecode sequence; and reading an execution pointer from the virtual memory corresponding to the next execution state of the bytecode sequence.

[0022] Preferably, the virtual memory stores data relating to different execution states of the bytecode sequence in different first and second formats, where the first format is used for storing such data as part of the locking script, and where the second format is suitable for manipulating the data in the virtual memory when executing the bytecode sequence of the locking script.

[0023] Preferably, the virtual memory includes at least one stack data structure, and the first format includes a serialized byte format and / or the second format includes a stack format.

[0024] The method further includes a step of extracting state data for the current execution state of the bytecode sequence from the virtual memory by deserializing data representing the current execution state of the bytecode sequence from a byte format to a stack format, and / or a step of comparing the state data resulting from the execution of the bytecode sequence of the locking script with state data of a next execution state of the bytecode sequence of the locking script included in the spending transaction by serializing the state data resulting from the execution of the bytecode sequence of the locking script from a stack format to a byte format.

[0025] Preferably, control of at least one digital asset or portion thereof is transferred as a result of execution of the first locking script, and the second locking script imposes a set of conditions for confirmation of the first blockchain transaction.

[0026] Preferably, the first blockchain transaction further includes an unlocking script, where execution of the unlocking script provides data (which may be a determined data source or a non-determined data source) used to derive a set of conditions for validation of the first blockchain transaction.

[0027] Preferably, at least a portion of the first blockchain transaction is replicated to generate new blockchain transactions until a termination condition is met (e.g., the digital assets associated with the first blockchain transaction are of insufficient size to be transferred).

[0028] Preferably, the first blockchain transaction and the previous blockchain transaction form part of a smart contract.

[0029] There is also provided in accordance with the present invention a system configured to carry out any of the above-described method embodiments, the system comprising: A processor; and a memory containing executable instructions that, when executed by a processor, cause the system to perform a computer-implemented method of any one of the above embodiments.

[0030] Also provided is a tangible computer readable storage medium having executable instructions stored thereon which, when executed by a processor of a computer system, cause the computer system to at least perform the computer-implemented method of any one of the above-described embodiments.

[0031] The techniques described and suggested in this disclosure improve the field of computing, and in particular the field of blockchain technology (including the execution of machine-executable smart contracts), by utilizing blockchain networks and cryptographic techniques to set and enforce standards for reassociating or transferring digital assets. In addition, the techniques described and suggested in this disclosure improve the functionality of blockchain networks by enabling blockchain transactions to function as state machines.

[0032] Furthermore, the techniques described and suggested in this disclosure are necessarily rooted in computer technology to overcome problems that arise specifically for distributed ledger technology and blockchain technology that use scripting languages ​​(e.g., Bitcoin script) that have been specifically designed to limit functionality for security reasons. For example, Bitcoin scripting language does not natively support the occurrence of complex flow control functionality (e.g., loops). One advantage of this limitation is that programs have predictable execution times. Another significant advantage of limiting scripts to linear or tree-like decision tasks is that it avoids infinite loops, which can be used as a means to launch exploits such as denial of service (DoS) attacks. Thus, while the security of blockchain transfers / exchanges is enhanced and maintained, mechanisms must be found to implement functionality not permitted or provided by the language itself. The present invention provides an advance in this respect, addressing, at least in part, the current limitations of blockchain transactions with the implementation of a locking script of self-replicating and self-replicating blockchain transactions. The present invention thus provides a technical solution to a technical problem and offers advantages in terms of security, improved control over the exchange / transfer of digital assets via the blockchain, and an extension of current blockchain-related functionality. [Brief description of the drawings]

[0033] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter, which will now be described, by way of example only, and with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates a blockchain environment in which various embodiments may be implemented. [Diagram 2]FIG. 2 illustrates an example of a smart contract that uses a locking script that includes a bytecode sequence that is replicated across a sequence of transactions, according to one embodiment. [Diagram 3] FIG. 3 illustrates one implementation of the locking script of FIG. 2, using bytecode sequences that are interpreted to implement a trustless, deterministic state machine according to one embodiment. [Figure 4A] FIG. 4A is a flow chart illustrating one example of operations for executing the spend transaction unlocking script and the previous transaction locking script of FIG. 3, collectively, according to one embodiment. [Figure 4B] FIG. 4B is a flow chart illustrating one example of operations that collectively execute the spend transaction unlocking script and the previous transaction locking script of FIG. 3 according to one embodiment. [Figure 4C] FIG. 4C is a flow chart illustrating one example of operations that collectively execute the spend transaction unlocking script and the previous transaction locking script of FIG. 3 according to one embodiment. [Diagram 5] FIG. 5 is a schematic diagram of an exemplary virtual stack data structure that may be used to execute a bytecode sequence of a locking script according to one embodiment. [Figure 6] FIG. 6 is a schematic diagram of serialized state data that may be stored as part of the locking script of FIG. 3 according to one embodiment. [Figure 7] FIG. 7 is a schematic diagram of operations that may be used to convert serialized state data stored as part of a locking script into a format suitable for storage in the stack data structure of FIG. 5 according to one embodiment. [Figure 8]FIG. 8 is a schematic diagram of operations that may be used to convert state data stored in the format of the stack data structure of FIG. 5 into serialized state data suitable for storage within a locking script, according to one embodiment. [Figure 9] FIG. 9 illustrates another implementation of the locking script of FIG. 2, which uses bytecode sequences and interpreter code to implement a trustless, deterministic state machine according to one embodiment. [Figure 10A] FIG. 10A is a flow chart illustrating one example of operations for executing the spend transaction unlocking script and the previous transaction locking script of FIG. 9, according to one embodiment. [Figure 10B] FIG. 10B is a flow chart illustrating one example of operations for executing the spend transaction unlocking script and the previous transaction locking script of FIG. 9, according to one embodiment. [Figure 10C] FIG. 10C is a flow chart illustrating one example of operations for executing the spend transaction unlocking script and the previous transaction locking script of FIG. 9, according to one embodiment. [Figure 11] FIG. 11 is a schematic diagram illustrating execution of the interpreter code of the locking script of FIG. 9 in cooperation with execution of a built-in software interpreter associated with a run-time system (e.g., a blockchain client) of a validation node to interpret the bytecode sequence of the locking script, according to one embodiment. [Figure 12A] FIG. 12A is a schematic diagram of an exemplary operation of the locking script interpreter code as part of the operations of FIGS. 10A through 10C to interpret a VOP_ADD bytecode as part of the locking script. [Figure 12B]FIG. 12B is a schematic diagram of an exemplary operation of the locking script interpreter code as part of the operations of FIGS. 10A through 10C to interpret the VOP_ADD bytecode as part of the locking script. [Figure 13] FIG. 13 illustrates a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] 1, an example of a blockchain network 100 associated with a blockchain in accordance with one embodiment of the present disclosure is shown. In this embodiment, the example blockchain network 100 is comprised of peer-to-peer distributed electronic devices that run instances of a blockchain protocol. In some embodiments, the distributed electronic devices are referred to as nodes 102. One example of a blockchain protocol is the Bitcoin protocol or any version / variation thereof.

[0035] Node 102 may be comprised of any suitable computing device (e.g., a server in a data center, a client computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, etc.), multiple computing devices in a distributed system of a computer resource service provider, or any suitable electronic client device such as computing device 2600 of FIG. 11).

[0036] In one embodiment, one or more of the nodes 102 are communicatively coupled to one or more of the other nodes 102. Such communication coupling may use one or more of wired or wireless communication links, as is known. In an embodiment, each of the nodes 102 maintains at least a portion of a “ledger” of all transactions in the blockchain. As such, the ledger is a distributed ledger. Transactions processed by a node that affect the ledger are verifiable by one or more other nodes, such that the integrity of the ledger is maintained.

[0037] In one embodiment, at least some of the nodes 102 are miner nodes that perform a mining process involving complex calculations, such as solving a cryptographic problem. Miner nodes that solve the cryptographic problem create new blocks for the blockchain and broadcast the new blocks to other nodes 102. The other nodes 102 perform a verification process to verify the work of the miner nodes and, upon verification, accept the block into the blockchain (e.g., by adding the block to the blockchain's distributed ledger). In some embodiments, a block is a group of transactions, often marked with a timestamp and a "fingerprint" (e.g., a hash) of the previous block. In this manner, each block becomes linked to the previous block, thereby creating a "chain" that links the blocks in the blockchain. In an embodiment, valid blocks are added to the blockchain by consensus of the nodes 102. In some embodiments, the blockchain also includes a list of confirmed blocks.

[0038] In one embodiment, at least some of the nodes 102 operate as validating nodes that perform a validation process to validate transactions as described in this disclosure. FIG. 1 illustrates one exemplary transaction labeled 104. In some embodiments, a transaction includes proof of ownership of a digital asset (e.g., a number of bitcoins) and data providing terms for the acceptance or transfer of ownership / control of the digital asset. In some embodiments, a "spending transaction" refers to a transaction that re-associates (e.g., transfers ownership or control) at least a portion of a digital asset, represented by an unspent transaction output (UTXO) of a previous transaction, to an entity associated with a blockchain address. In some embodiments, a "previous transaction" refers to a transaction that includes a UTXO referenced by a spending transaction. In some embodiments, a transaction includes an "unlocking script" and a "locking script" that encumbers the transaction with conditions that must be met before the transaction is confirmed and ownership / control is transferred by the transaction. In some embodiments, a locking script can be associated with an output of the transaction and configured to define one or more conditions required to spend the output. Additionally, an unlocking script for a spend transaction can be configured such that execution of the unlocking script provides data.The data is used to derive a set of conditions that are evaluated by execution of the locking script of the previous transaction for validation of the spending transaction. In some embodiments, the blockchain address is an alphanumeric string associated with an entity to which control of at least a portion of a digital asset is transferred / reassociated. In some blockchain protocols implemented in some embodiments, there is a one-to-one correspondence between a public key associated with an entity and a blockchain address. Validation of the transaction may include verification of one or more conditions specified in the locking script and / or unlocking script of the transaction. Upon successful validation of the transaction, the validating node may propagate the transaction to other network nodes, so that miner nodes may choose to embed the transaction as part of a block that is added to the blockchain as described herein.

[0039] Some blockchain technologies, such as Bitcoin, use the elliptic curve digital signature algorithm (ECDSA) as a mathematical scheme for digital signatures. In embodiments, ECDSA is a cryptographic digital signature used to protect UTXOs from being spent by unauthorized entities. Elliptic curve digital signatures (ECDSA) in Bitcoin typically appear with a signature hash flag (SIGHASH type) appended to the end. However, it is contemplated that the techniques of this disclosure may be used with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, ECDSA is contemplated to conform to the signature creation principles of the particular blockchain technology.

[0040] In some embodiments, the SIGHASH type refers to a set of fields that are extracted from a transaction before it is serialized (e.g., canonicalized) and hashed. For example, the SIGHASH type may affect which fields of a transaction are included in the signature. In some examples, the SIGHASH type may be one or more of SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, or SIGHASH_ANYONECANPAY, as used in the Bitcoin protocol.

[0041] The Bitcoin protocol uses a scripting system called “Script” to perform various operations. In this disclosure, various script operation codes (or op_codes) and keywords are referenced to perform various operations. However, it is contemplated that other blockchain technologies could implement different instruction sets, and thus the operation codes described in this disclosure are not intended to be specific operation codes in a script, but rather to illustrate the operations performed by the operation codes. In some embodiments, the scripting system is a Turing incomplete instruction set (e.g., lacking support for loops, recursion, goto statements, etc.). In other embodiments, the scripting system may be a Turing complete instruction set.

[0042] Certain embodiments of the present disclosure operate under the assumption that the scripting system or other system for implementing the described instruction set permits more than 200 instructions (e.g., operation codes or op_codes) in a single script. Similarly, certain embodiments of the present disclosure further assume the following: The functionality provided by a particular low-level opcode is present and available in the system that executes the opcode script / instruction set; and / or The functionality provided by particular high-level operation codes (or high-level bytecode operations) can be realized by the creation of customized functions that are written to provide the desired behavior. These customized functions may be written to implement the functionality of op_codes that exist in the language but have been disabled, or they may be "new" op_codes that provide particular functionality not natively provided in the scripting language.

[0043] Examples of low-level operation codes that may be supported by the scripting system include the following: OP_1SUB, the value "1" is subtracted from the top item of the stack OP_2DUP, duplicates the top two items in the stack OP_ADD, add the top two items to the stack OP_CAT, concatenates the top two items in the stack OP_CHECKSIG, the public key and signature are popped from the stack and verified against the signature in the transaction field according to the SIGHASH type. Returns 1 if the signature is valid, 0 otherwise. OP_CHECKSIGVERIFY, which works like OP_CHECKSIG but runs OP_VERIFY afterwards OP_DROP, remove or pop the top item from the stack OP_DUP, duplicates the top item of the stack These statements are executed if OP_ELSE, the preceding OP_IF, OP_NOTIF, or OP_ELSE was not executed, otherwise these statements are not executed if the preceding OP_IF, OP_NOTIF, or OP_ELSE was executed. OP_ENDIF, ends an if / else block OP_EQUAL, returns 1 if the inputs are exactly equal, 0 otherwise OP_EQUALVERIFY, like OP_EQUAL but then runs OP_VERIFY OP_FROMALTSTACK, puts the input on top of the main stack and removes it from the alternate stack OP_HASH256, the input is hashed twice, first using SHA-256 and then using RIPEMD-160 OP_IF, if the top stack value is not False, the statements are executed and the top stack value is removed. OP_LEFT, keeps only the characters to the left of the specified point in the string. OP_MUL, multiplies the top two items in the stack OP_NOTIF, if the value on the top of the stack is false, the statements are executed and the value on the top of the stack is removed. OP_RIGHT, keeps only the characters to the right of the specified point in the string OP_ROLL, an item n items deep in the stack is moved to the top OP_ROT, rotate the top three items in the stack to the left OP_SIZE, pushes the length of the string in the top element on the stack (without popping it up) OP_SUBSTR, returns a section of a string OP_SWAP, the top two items on the stack are swapped OP_TOALTSTACK, puts the input on top of the alternate stack and removes it from the main stack OP_TUCK, the item on the top of the stack is copied and inserted before the second top item OP_VERIFY, which marks the transaction as invalid if the value at the top of the stack is not true

[0044] These low-level opcodes are currently supported by the Bitcoin protocol's scripting system.

[0045] Examples of high level operation codes that may be supported by the methods and systems of the present disclosure include the following: OP_ECPX, returns the x-coordinate of an elliptic curve point OP_BIGMOD, returns the remainder after dividing the top two items in the stack OP_BIGMODADD, performs modulus addition of the top two items of the stack modulus to the third item in the stack. OP_BIGMODINVERSE, which performs a modulus negative exponent operation OP_BIGMODMUL, performs modulus multiplication of the top two items of the stack modulus on the third item of the stack. OP_DERENCODE, which DER-encodes the top two items in the stack OP_ECPMULT, which performs an elliptic curve point multiplication (also referred to as an elliptic curve scalar multiplication) of the top two items in the stack.

[0046] These high-level operation codes can provide specific functionality not natively provided in the Bitcoin protocol's scripting system.

[0047] FIG. 2 illustrates an example smart contract 2100 that uses a locking script as part of a sequence of transactions, where the locking script is configured to reduce the amount of digital assets sent to a spending transaction by one unit each time, and also pay one unit of digital assets to Alice. That is, a first transaction 202 includes a locking script and holds an initial amount X. The first transaction 202 is confirmed and then mined so that it is embedded in a block, which is then verified so that it is stored in the blockchain 208. The locking script (or a portion thereof) of the first transaction 202 is replicated and incorporated as part of the locking script of a second transaction 204. The second transaction 204 is a spending transaction confirmed by executing the locking script of the first transaction 202, and is configured to pay one unit of the initial amount X held by the first transaction 202 to a pay-to-public-key-hash address belonging to Alice and hold a new sum (X'=X-1). In some embodiments, the P2PK or P2PKH can be used as an address for direct transfer of digital assets to an entity associated with the respective public key. The second transaction 204 is then mined to be embedded in a block, and the block is then confirmed to be stored in the blockchain 208. The locking script (or a portion thereof) of the second transaction 204 is replicated and incorporated as part of the locking script of the third transaction 206.The third transaction 206 is a spend transaction confirmed by executing the locking script of the second transaction 204, and is configured to pay one unit of the amount X' held by the second transaction 204 to a pay-to-public-key-hash (P2PKH) address belonging to Alice, and to hold the new sum (X" = X'-1). The third transaction 206 is then mined so that it is embedded in a block, which is then verified so that it is stored in the blockchain 208. The locking script of the third transaction 206 (or a portion thereof) may be replicated, as necessary, and incorporated as part of one or more locking scripts that follow on the spend transaction, as described above. Thus, it can be seen that if the process continues regardless of the initial amount X, a spend transaction is eventually generated that outputs an unspendable amount of digital assets (e.g., zero). This is in accordance with the minimum transaction fees deducted in various blockchain protocols. This can be intuitively understood by observing that each subsequent spending transaction has a smaller amount of digital assets than the previous transaction, even without subtracting the fee. As a result, the amount outputs converge towards zero, at which point it becomes pointless to process the transaction. However, embodiments of the present disclosure include a solution to this problem by enforcing a termination condition to avoid such unspendable spending transactions. Once confirmed and stored in the blockchain, each sequence of transactions 202, 204, 206, etc., provides a transfer of control over the digital assets referenced by the transactions.

[0048] Further, in embodiments, the sequence of smart contract transactions 202, 204, 206, etc., includes a locking script with a bytecode sequence that is copied or replicated across all transactions. Thus, the validation process for each spend transaction of the smart contract may include extracting the locking script bytecode sequence from the previous transaction, extracting the locking script bytecode sequence from the spend transaction, and verifying that these two extracted bytecode sequences match each other.

[0049] A basic outline of this process is shown below in Table 1. [Table 1]

[0050] As can be seen in the above script, the bytecode sequence of the locking script of a previous transaction (e.g., the first transaction 202), i.e., the locking script that unlocks the previous transaction's UTXO, is verified against the bytecode sequence of the locking script of a spend transaction (e.g., the second transaction 204), which is then redeemed into another spend transaction (e.g., the third transaction 206) at a future time when this spend transaction is a previous transaction. Thus, rather than creating a different spend transaction for each transaction, the locking script instead enforces that the bytecode sequence must be identical for both locking scripts. If the bytecode sequence for the locking script of the previous transaction is identical to the bytecode sequence of the locking script of the spend transaction, then both locking scripts are assured to be genuine.

[0051] In an embodiment, the termination condition avoids the case where a previous transaction has insufficient funds but the locking script is still valid, i.e., an un-spendable transaction. For example, the termination condition can be implemented to verify that there are sufficient digital assets to execute the next transaction, and if not, the validation can be terminated. As a more specific example, if the initial pool includes 365 units of digital assets and the amount required for each transaction fee (e.g., enough for one transaction per day for a year), the termination condition can verify that the number of remaining units is greater than the number required to complete the transaction. For example, as long as sufficient funds exist, the validation of the transaction continues. Otherwise, if there are insufficient funds, the termination condition is met and validation stops. Thus, if there are insufficient funds on the 366th day, validation of the locking script of the 366th spending transaction is unnecessary, and the termination condition ensures that the replication of the transaction and the associated locking script are terminated.

[0052] Note that the smart contract of FIG. 2, which pays digital assets to a pay-to-public-key-hash (P2PKH) address belonging to Alice, as described above, is exemplary. In embodiments, the principles and operations of the locking script described herein may be extended to support a wide range of smart contracts that use the blockchain. In this document, we use the term “smart contract” to include an agreement whose terms are carried out by a series of transactions that use a computerized transaction protocol to store the transactions on the blockchain.

[0053] 3 illustrates an example transaction using a locking script with a common bytecode sequence to implement a trustless deterministic state machine according to one embodiment of the present disclosure. More specifically, the common bytecode sequence is a computer program that can be thought of as a state machine that embodies state rules with a set of well-defined states, whereby execution of the bytecodes of the bytecode sequence (the computer program) provides transitions between states of the state machine.

[0054] As shown diagrammatically in FIG. 3, the previous transaction 302 includes a locking script 304 having a bytecode sequence that represents a set of state rules for a state machine 306. The locking script 304 also includes a current state execution pointer (or “current execution pointer”) and serialized state data that represents a current state among the states of the state machine 306 represented by the bytecode sequence. In the illustrated example, the current execution pointer and serialized state data of the locking script 304 represent a current state “S1”, and the set of state rules of the state machine 306 represented by the bytecode sequence provides two possible states (“S2” or “S3”) for the next state following the current state S1. The current execution pointer included as part of the locking script 304 references the execution point of the bytecode sequence that corresponds to the current state (in this case, “S1”). The serialized state data included as part of the locking script 304 represents the state of the state machine represented by the bytecode sequence at the point of execution referenced by the current execution pointer included in the locking script 304 .

[0055] 3, the spend transaction 308 includes a locking script 312 with a bytecode sequence representing a set of state rules for a state machine 314, which is a copy of the state machine 306 represented by the bytecode sequence of the locking script 304 of the previous transaction 302. The locking script 312 also includes a next state execution pointer (or “next execution pointer”) and serialized state data representing one of the possible next states following the current state S1 (in this case, state “S2”). The next execution pointer included as part of the locking script 312 references an execution point of the bytecode sequence corresponding to the next state following the current state S1 (in this case, state “S2”). The serialized state data included as part of the locking script 312 represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the next execution pointer included in the locking script 312.

[0056] Note that the serialized state data included as part of the locking script 312 may be determined when creating a spend transaction by generating or accessing a next execution pointer included in the locking script 312. The serialized state data of the locking script 304 of the previous transaction is used to restore the current execution state of the bytecode sequence of the locking script 312, and then executes the bytecode sequence of the locking script. Such execution begins at a point (or operation) corresponding to the current execution pointer included in the previous transaction 302, and ends at a point (or operation) corresponding to the next execution pointer included in the locking script 312. Such execution may also use input data 310 determined by execution of the unlocking script of the spend transaction 308.

[0057] As part of the validation of the spend transaction 308, a common bytecode sequence of the unlocking script and the locking script 304 / 312 of the spend transaction 308 is executed. The execution of the common bytecode sequence takes as input the input data 310 determined from the execution of the unlocking script of the spend transaction 308, the current state "S1" embodied by the current execution pointer and serialized state data contained in the locking script 304 of the previous transaction 302, and the next execution pointer contained in the locking script 312 of the spend transaction 308, and executes the common bytecode sequence of the locking script 304 / 312 from the point (or operation) corresponding to the current state execution pointer contained in the locking script 304 of the previous transaction 302 to the point (or operation) corresponding to the next execution pointer contained in the locking script 312 of the spend transaction 308. Such execution determines the appropriate next state (such as a second state "S2") from the set of state rules 314 represented by the common bytecode sequence. This next state (such as state "S2"), determined from execution of the common bytecode sequence up to a point (or operation) corresponding to the next execution pointer included in the locking script 312 of the spend transaction 308, is configured as serialized state data that conforms to a serialized format of the state data included as part of the locking script 312 of the spend transaction 308. The serialized state data determined from execution of the common bytecode sequence is then verified against the serialized state data included as part of the locking script 312 of the spend transaction 308. Again, rather than creating a different spend transaction for each transaction, execution of the locking script enforces that the execution state resulting from execution of the bytecode sequence of the locking script during validation of the spend transaction matches the expected resulting execution state of the locking script included in the spend transaction when creating the spend transaction.If these two resulting execution states are identical, then the locking script is guaranteed to be valid.

[0058] Note that the example of Figure 3 shows that the state of the state machine represented by the bytecode sequence of the locking script 312 of the spend transaction 308 provides possible new states "S4" or "S5" for the next state transition from state "S2". Note that the set of state rules represented by the bytecode sequence of the locking script may be coded as switch statements or other conditional statements (e.g., "if-then-else") parameterized by the current state and one or more inputs.

[0059] In an embodiment, the bytecode sequence contained in the transaction locking script represents a set of state rules of the state machine, and the execution pointer and the serialized state data of the transaction locking script represent the state of the state machine. In such an embodiment, the bytecode sequence of the transaction locking script must be copied or replicated to every spending transaction that attempts to transfer control of a digital asset to a next transaction and linked to the current transaction. This process is repeated until an exit condition is met. Because the input data determined from the execution of the spending transaction unlocking script is not fixed and can be pending data, the state of the state machine can be changed based on certain external inputs. Thus, the pending data provides inputs that can affect the next state.

[0060] Furthermore, the number of locking script bytecode operations executed during validation of a spend transaction, which is determined by the difference between the execution pointer of the current execution state of the locking script bytecode sequence as included in the previous transaction and the execution pointer of the next execution state of the locking script bytecode sequence as included in the spend transaction, can be varied by design by selecting or modifying the execution pointer of the next execution state of the locking script bytecode sequence as included in the spend transaction. In this way, the number of locking script bytecode operations executed during validation of a spend transaction can be constrained or used in parameterizing constraints of spend transactions (transactions using the locking script). This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations of the smart contract bytecode sequence), to logically split the smart contract bytecode sequence into different segments executed over a sequence of spend transactions, to calculate rewards for entities that create new transactions based on the parameterized constraints, or for other possible uses.

[0061] As an example, Alice loans some money to Bob, and Bob agrees to pay Alice back. A trustless, deterministic state machine like the one described above can be used to implement a smart contract that represents payments that Bob makes to Alice. For example, a smart contract could be constructed such that Bob makes monthly payments to Alice for the next three months, and if he misses a payment, Bob's debt enters the debt collection phase. Thus, as long as Bob makes his monthly payments, the current state remains the payment state. However, if an external entity provides an input indicating that Bob has missed a payment, the state branches to the missed payment state. In the missed payment state, Alice can release the transaction and turn it over to the debt collector, so that the trustless, deterministic state machine switches to the debt collection state. In the debt collection state, the debt collector collects the debt from Bob. Such smart contracts can be created using variations on the script embodiments shown in Figures 2 and 3.

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

[0063] In other embodiments, the principles and operations of the locking scripts described herein can be extended to support a wide range of smart contracts that use blockchain.

[0064] Table 2 below shows one example of an unlocking script and a locking script that implements the trustless deterministic state machine of the present disclosure. [Table 2-1] [Table 2-2]

[0065] 4A-4C are flow charts illustrating an example operation of executing, collectively, an unlocking script of a spending transaction and a locking script of a previous transaction as part of a smart contract. This operation may be part of a validation process of the spending transaction. The spending transaction includes a locking script with a bytecode sequence that implements a trustless deterministic state machine according to an embodiment of the present disclosure. The locking script also includes a next state execution pointer (or “next execution pointer”) and serialized state data representing the next execution state of the state machine. The next execution pointer, as part of the locking script, references an execution point of the bytecode sequence corresponding to the next execution state. The serialized state data, as part of the locking script, represents the execution state of the state machine represented by the bytecode sequence at the execution point referenced by the next execution pointer included in the locking script of the spending transaction.

[0066] It is noted that the serialized state data included as part of the locking script of the spend transaction can be determined when creating the spend transaction by generating or accessing a next execution pointer included in the locking script of the spend transaction, restoring the current execution state of the state machine using the serialized state data of the locking script of the previous transaction, and then executing the bytecode sequence of the locking script. Such execution starts at a point (or operation) corresponding to the current execution pointer included in the locking script of the previous transaction and ends at a point (or operation) corresponding to the next execution pointer included in the locking script of the spend transaction. Such execution can also use input of the unlocking script of the spend transaction. It is contemplated that creation of the spend transaction can include operations involving a wallet, an agent node, or some other node of the blockchain network.

[0067] 4A-4C (or any other processes described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data and implemented as executable instructions collectively executing on one or more processors. The executable instructions and / or other data may be stored in a non-transitory, computer-readable storage medium (e.g., a computer program persistently stored in a magnetic, optical, or flash medium).

[0068] For example, some or all of the operations of Figures 4A-4C may be performed by a verification node in an example blockchain network, such as the example blockchain network 100 of Figure 1. Such a verification node may be comprised of any suitable computing device (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computational resource service provider, or by an electronic client device, such as computing device 2600 of Figure 13).

[0069] The operations of Figures 4A-4C that verify that the bytecode sequences of the locking script of the previous transaction and the spend transaction are the same obtain a current execution state from the previous transaction, obtain input from the execution of the unlocking script of the spend transaction, determine a next execution state based at least in part on an interpretation of the bytecode sequence of the locking script, and verify that the next execution state determined from the execution of the locking script matches the next execution state represented by the next state data included as part of the locking script of the spend transaction. The operations of Figures 4A-4C reflect variations of the example scripts found in Table 2. The locking script of the previous transaction (e.g., scriptPubKey) and the unlocking script (e.g., scriptSig) and locking script (e.g., scriptPubKey) of the spend transaction are all stored in virtual memory, which may be embodied by one or more runtime data structures, such as a stack, a stack frame, or a heap.

[0070] In 401, it is determined whether an exit condition is met. In an embodiment, the exit condition may be a condition that, when met, terminates the state machine transition represented by the bytecode sequence of the locking script. If the exit condition is met, the operations proceed to 435, where further replication of the locking script is prevented, thus terminating replication of the locking script as part of the smart contract, and the operations continue to 427 and 429, as described below. If the exit condition is not met, the operations continue to 403.

[0071] At 403, the bytecode sequence of the locking script of the previous transaction is retrieved from virtual memory, the bytecode sequence of the locking script of the spending transaction is read from virtual memory, and the bytecode sequences of the two locking scripts are compared to each other to determine whether they match.

[0072] At 405, it is determined whether the bytecode sequences of the two locking scripts compared at 403 match each other. If they do not match, operation proceeds to 433 where it is determined that the spend transaction is invalid. If they do match, operation continues to 407.

[0073] At 407, an execution pointer to the current execution state of the locking script's bytecode sequence (previously contained in the transaction's locking script) is retrieved from virtual memory.

[0074] At 409, an execution pointer to the next execution state of the locking script bytecode sequence (contained in the locking script of the spend transaction) is read from virtual memory.

[0075] At 411, the current state data of the locking script (previously included in the locking script of the transaction) is read from virtual memory and used to restore the execution state of the locking script's bytecode sequence in virtual memory. For example, the current state data of the locking script may be read from virtual memory in a serialized format and then deserialized into a stack format for use in restoring the stack data structure in virtual memory that existed at the end of the previous execution of the locking script's bytecode sequence (where the execution pointer was at the current state execution pointer because of its previous inclusion in the locking script of the transaction).

[0076] At 413, the locking script bytecode sequence (contained in the locking script of the previous transaction) may be executed based on the input or inputs stored in virtual memory. Execution of the locking script bytecode sequence starts at the execution pointer for the current execution state of the locking script bytecode sequence read at 407 and ends when the execution pointer for the next execution state of the locking script bytecode sequence read at 409 is reached. In an embodiment, the bytecode of the locking script bytecode sequence is computer instructions designed for efficient execution, including interpretation by a software interpreter that is part of the runtime system (e.g., blockchain client) of the node that validates the spending transaction, but is not machine code (and thus is not tied to a specific CPU hardware). The execution of the software interpreter can be configured to convert the bytecode of the bytecode sequence segment (e.g., from the execution pointer of the current execution state of the locking script bytecode sequence to the execution pointer of the next execution state of the locking script bytecode sequence) into machine code suitable for execution on the specific CPU hardware of the node that validates the spending transaction as necessary at runtime and executes the machine code on the specific CPU hardware. The execution of a software interpreter may convert the bytecodes of a bytecode sequence segment sequentially into one bytecode at a time (e.g., a simple interpretation), or may use a just-in-time compilation method in which a code sequence segment (or a portion thereof) is compiled into machine code as needed at run time, and the resulting machine code is then executed. The resulting machine code may be cached and reused at a later time without requiring recompilation.

[0077] In 415, it is determined whether execution of the locking script bytecode sequence has reached a point corresponding to the execution pointer for the next execution state of the locking script bytecode sequence. If not, operation returns to 413 where execution of the locking script bytecode sequence continues. If so, operation continues to 417.

[0078] At 417, it is determined whether the resulting execution state stored in virtual memory evaluates to true. In an embodiment, this check ensures that both the operation of the spend transaction's unlocking script and the operation of the previous transaction's locking script completed without error and that some or all of the conditions encoded by the spend transaction's unlocking script and the previous transaction's locking script were satisfied. If not, operation continues to 433, where it is determined that the spend transaction is invalid. If so, operation continues to 419.

[0079] At 419, the resulting execution state of the locking script bytecode sequence stored in the virtual memory (after the execution pointer for the next execution state of the locking script bytecode sequence is reached) is constructed and stored as serialized state data representing the next execution state of the locking script bytecode sequence. The serialized state data is stored in the virtual memory in a serialized format for inclusion in the spend transaction.

[0080] At 421, serialized state data representing the next execution state of the locking script's bytecode sequence is read from virtual memory.

[0081] At 423, the serialized state data representing the next execution state of the bytecode sequence of the locking script determined at 419 is compared against the serialized state data representing the next execution state of the bytecode sequence of the locking script read from virtual memory at 421 and included in the spend transaction to determine whether the serialized state data match.

[0082] At 425, it is determined whether the serialized state data matches. If not, operation proceeds to 433 where it is determined that the spend transaction is invalid. If so, operation continues to 427 and 429.

[0083] At 427 and 429, the operations determine whether one or more other conditions for validation of the spend transaction are met. Such conditions may include other constraints specified in the locking or unlocking script of the spend transaction. If so, the operations continue to 431, where the spend transaction may be deemed valid by the system performing the validation process. If not, the operations continue to 433, where the spend transaction is determined to be invalid. It is noted that one or more of the operations performed in 401-435 may be performed in various orders and combinations, including in parallel.

[0084] Also note that when (e.g., at 431) a spend transaction is determined to be valid and may be stored on the blockchain, and if so, the bytecode sequence of the locking script of the spend transaction may be replicated to generate a “new” spend transaction. In this manner, a portion of the “old” spend transaction is replicated into the transaction that spends it. In this case, the input of the “new” spend transaction may reference this “old” spend transaction, and the output of the “new” spend transaction may include a locking script that includes a copy of the bytecode sequence of the locking script of the “old” spend transaction. The validation process of the “new” spend transaction may equate the “old” spend transaction with the previous transaction as part of the validation process.

[0085] Also, the number of locking script bytecode operations executed when validating a "new" spending transaction is dictated by the difference between the execution pointer of the current execution state of the locking script included in the "old" spending transaction and the execution pointer of the next execution state of the locking script included in the "new" spending transaction, but can be varied by design by selecting or modifying the execution pointer of the next execution state of the locking script included in the "new" spending transaction. In this way, the number of locking script bytecode operations executed when validating a "new" spending transaction can be constrained or used in parameterizing the constraint on the "new" spending transaction (which is the transaction that is spending the locking script). This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations of the smart contract bytecode sequence), to logically split the smart contract bytecode sequence into different segments that are executed on the sequence of spending transactions, to calculate rewards for entities that create new transactions based on the parameterized constraint, or for other possible uses.

[0086] Also note that in one or more embodiments described above, for a given locking script, a spend transaction is a transaction that references the locking script in one of its inputs, and a previous transaction is a transaction that includes the locking script referenced in one of the inputs of the spend transaction. Furthermore, there can be as many previous transactions as there are inputs for the spend transaction. Furthermore, the blockchain protocol may not allow the locking script to query the spend transaction or one of the previous transactions. However, since a transaction is simply data with certain properties, and the locking script simply encodes constraints in the unlocking script to include certain data, these properties can be utilized to provide a locking script that allows injection of the spend transaction and previous transactions into the unlocking script. This allows the locking script to constrain the spend transaction (e.g., require that the spend transaction have one output) and also extract data from the previous transaction. Note that the locking script cannot constrain the previous transaction because it has already been written to the blockchain. The combination of both measures means that the locking script can extract data from previous transactions and restrict a spend transaction if the locking scripts of the previous transaction and the spend transaction contain the same bytecode sequence.

[0087] Furthermore, the bytecode sequences of the locking script, and the unlocking and locking scripts themselves, may be considered to be computer programs. As such, the unlocking and locking scripts require access to the memory system of the CPU executing the unlocking and locking scripts. In an embodiment, a portion of the memory system, referred to herein as virtual memory, may be allocated and managed to store the bytecode sequences and associated data of the locking and unlocking scripts.

[0088] Note that the locking script bytecode interpreter described herein may be configured to support a variety of bytecode operations as dictated by the design of the system. However, it is almost certain that the set of bytecode operations supported will allow interaction with virtual memory. In the Bitcoin scripting language, there are a range of bytecodes that deal with memory management. A few are listed below. OP_TOALTSTACK: Move the top item from the main stack to the top of the alternate stack. OP_FROMALTSTACK: Move the top item from the alternate stack to the top of the main stack. OP_SWAP: Swap the top two items on the stack OP_PICK: Take a specific item in the stack and copy it to the top OP_ROLL: Take a specific item in the stack and put it on top

[0089] Further, in embodiments described herein, the bytecode sequence of the locking script may include high-level bytecode operations (or "virtual bytecode operations") that are interpreted into a corresponding sequence or combination of low-level bytecode operations supported by a software interpreter of the runtime system (e.g., blockchain client) of the validation node. In this case, the bytecode sequence of the locking script is essentially a program within a program, similar to how software executes on an operating system. In such an embodiment, state data and execution pointers for the locking script may be maintained in two virtual stacks that reside in virtual memory as shown in FIG. 5. These are generally referred to as the Virtual Main Stack and the Virtual Alt Stack, and may be stored as part of Bitcoin's main stack. Note that the Virtual Main Stack is on top of the Virtual Alt Stack. To keep track of the beginning of these two stack data structures, the Main Stack contains a pointer to the top of the Virtual Main Stack. Each of these two stack data structures may store a set of items. First is the stack height (not counting itself), followed by the data. In this configuration, the state data and execution pointers for the locking script are effectively stored in two virtual memory data structures (a virtual main stack and a virtual alternate stack) that are embedded within another larger virtual memory data structure (the main stack).

[0090] For example, Tables 3A and 3B show two high-level bytecode operations, referenced VOP_SWAP and VOP_DROP, which operate on the virtual main and alternate stacks of FIG. 5 as follows: [Table 3A] [Table 3B]

[0091] Note that the script for these two byte code operations assumes that any necessary error checking (e.g., virtual main stack height >= 2) is performed before executing each operation.

[0092] In the embodiments described herein, the current execution state of the locking script bytecode sequence previously included in the transaction is extracted or read from the virtual memory for processing (see, e.g., 411 above). Similarly, after execution of the locking script bytecode sequence, the resulting execution state of the locking script bytecode sequence stored in the virtual memory is configured as serialized state data and compared to the serialized state data included in the locking script of the spending transaction (see, e.g., 419, 421, and 423 above). In the embodiments, the locking script state data has two formats: a first serialized format for embedding within the transaction, and a second format for “easy / direct” interpretation and manipulation in the virtual memory. Furthermore, the change from the first serialized format to the second format (which may be part of 411 above) may be referred to as deserialization, and the change from the second format to the first serialized format may be referred to as serialization (which may be part of 419 above). FIG. 5 illustrates the second format. FIG. 6 illustrates a first serialization format, in which the execution state data is represented by an ordered byte string that includes the following: - A stack height field, which encodes the number of stack items in a byte string - several stack items, each of which contains a size field and a data field, where the size field indicates the number of bytes in the data field of the stack item

[0093] 7 illustrates the deserialization of byte strings representing the current execution state of the locking script's bytecode sequence included in a previous transaction for storage in virtual memory (e.g., see 411 above) in a manner that restores the current state of the locking script's bytecode sequence. One example of a script for deserializing byte strings representing the current execution state of the locking script's bytecode sequence included in a previous transaction for storage in the virtual main stack and virtual alternate stack of FIG. 5 is shown in Table 4 below. [Table 4-1] [Table 4-2] [Table 4-3]

[0094] Figure 8 illustrates serializing the resulting execution state of the locking script bytecode sequence stored in virtual memory into a serialized byte string representing the next state data of the locking script bytecode sequence included in the spend transaction (see, e.g., 419 above). One example of a script that serializes the resulting execution state of the locking script bytecode sequence stored in the virtual main stack and virtual alternate stack of Figure 5 into a serialized byte string representing the next state data of the locking script bytecode sequence included in the spend transaction is provided in Table 5 below. [Table 5-1] [Table 5-2]

[0095] In an embodiment, the locking script replicated over a sequence of spending transactions may include an interpreter code used to interpret the bytecode sequence of the locking script. The interpreter code may support the translation of high-level bytecodes or commands that extend or complement the low-level bytecode operations supported by the software interpreter of the runtime system of the validation node (e.g., the blockchain client). For example, the interpreter code may support the translation of high-level bytecodes (or virtual bytecodes) into respective sequences or combinations of low-level bytecode operations supported by the software interpreter of the runtime system of the validation node. In this case, the interpreter code may support the translation of the virtual bytecode operations VOP_SWAP and VOP_DROP of Tables 3A and 3B into op_codes or commands that belong to the Bitcoin scripting language and are supported by the software interpreter of the runtime system of the validation node (e.g., the Bitcoin client). In another example, the interpreter code may support the translation of script bytecode operations written in a high-level programming language for interpretation by the software interpreter of the runtime system of the validation node. In this case, the interpreter code may support converting script bytecode operations written in a high-level programming language into op_codes or commands that belong to the Bitcoin scripting language and are supported by the software interpreter of the validator node's runtime system.

[0096] Further, in an embodiment, the verification process for each spend transaction of the smart contract may include extracting a bytecode sequence of the locking script from the previous transaction, extracting a bytecode sequence of the locking script from the spend transaction, verifying that the two extracted bytecode sequences match each other, extracting an interpreter code of the locking script from the previous transaction, extracting the interpreter code of the locking script from the spend transaction, and verifying that the two extracted interpreter codes match each other.

[0097] 9 illustrates an example transaction using a locking script having a common bytecode sequence and a shared interpreter code to implement a trustless, deterministic state machine in accordance with one embodiment of the present disclosure. More specifically, the common bytecode sequence is a computer program that can be thought of as a state machine that embodies state rules with a set of well-defined states, whereby execution of the bytecodes of the bytecode sequence (the computer program) provides transitions between states of the state machine. The shared interpreter code supports interpretation of the bytecode sequence of the locking script.

[0098] As shown generally in FIG. 9, the previous transaction 302′ includes a locking script 304′ having a bytecode sequence representing a set of state rules for a state machine 306′, as well as interpreter code that supports interpretation of the bytecode sequence of the locking script 304′. The locking script 304′ also includes a current state execution pointer (or “current execution pointer”) and serialized state data that represents a current state among the states of the state machine 306′ represented by the bytecode sequence of the locking script 304′. In the illustrated example, the current execution pointer and serialized state data of the locking script 304′ represent a current state “S1”, and the set of state rules of the state machine 306′ represented by the bytecode sequence provides two possible states (“S2” or “S3”) for the next state following the current state S1. The current execution pointer included as part of the locking script 304′ references the execution point of the bytecode sequence that corresponds to the current state (in this case, “S1”). The serialized state data included as part of the locking script 304' represents the state of the state machine represented by the bytecode sequence at the point of execution referenced by the current execution pointer included in the locking script 304'.

[0099] As can be seen from the example of FIG. 9, the spend transaction 308' includes a locking script 312' with a bytecode sequence representing a set of state rules for a state machine 314', as well as interpreter code to support interpretation of the bytecode sequence of the locking script 312'. The state machine 314' is a copy of the state machine 306' represented by the bytecode sequence of the locking script 304' of the previous transaction 302', and the interpreter code is a copy of the interpreter code of the locking script 304' of the previous transaction 302'. The locking script 312' also includes a next state execution pointer (or "next execution pointer") and serialized state data representing one of the possible next states following the current state S1 (in this case, state "S2"). The next execution pointer included as part of the locking script 312' references the execution point of the bytecode sequence corresponding to the next state following the current state S1 (in this case, state "S2"). The serialized state data included as part of the locking script 312' represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the next execution pointer included in the locking script 312'.

[0100] Note that the serialized state data contained in the locking script 312' may be determined when creating a spend transaction by generating or accessing the next execution pointer contained in the locking script 312', using the serialized state data of the locking script 304' of the previous transaction to restore the current execution state of the bytecode sequence of the locking script, and then executing the bytecode sequence of the locking script. Such execution begins at a point (or operation) corresponding to the current execution pointer contained in the previous transaction 302', and ends at a point (or operation) corresponding to the next execution pointer contained in the locking script 312'. Such execution may also use input data 310' determined by the execution of the unlocking script of the spend transaction 308'.

[0101] As part of the validation of the spend transaction 308', the common bytecode sequence of the unlocking script and the locking script 304' / 3122 of the spend transaction 308' is executed. The execution of the common bytecode sequence takes as input the input data 310' determined by the execution of the unlocking script of the spend transaction 308', the current state "S1" embodied by the current execution pointer and serialized state data contained in the locking script 304' of the previous transaction 302', and the next execution pointer contained in the locking script 312' of the spend transaction 308', and executes the shared interpreter code to interpret the common bytecode sequence of the locking script from the point (or operation) corresponding to the current state execution pointer contained in the locking script 304' of the previous transaction 302' to the point (or operation) corresponding to the next execution pointer contained in the locking script 312' of the spend transaction 308'. Such interpretation determines the appropriate next state (such as a second state "S2") from the set of state rules 314' represented by the bytecode sequence. This next state (such as state "S2"), determined from interpretation of the bytecode sequence up to a point (or operation) corresponding to the next execution pointer included in the locking script 312' of the spend transaction 308', is configured as serialized state data that conforms to a serialized format for state data included as part of the locking script 312' of the spend transaction 308'. The serialized state data determined from interpretation of the bytecode sequence is then validated against the serialized state data included as part of the locking script 312' of the spend transaction 308'.Again, rather than creating a different spend transaction for each transaction, execution of the locking script enforces that the result from executing the bytecode sequence of the locking script during validation of the spend transaction matches the expected resulting execution state of the locking script included in the spend transaction when creating the spend transaction. If these two resulting execution states are identical, then the locking script for the spend transaction 308' is guaranteed to be valid.

[0102] 9 example shows that the state of the state machine represented by the bytecode sequence of the locking script 312' for the spend transaction 308' provides possible new states "S4" or "S5" for the next state transition from state "S2". Note that the set of state rules represented by the bytecode sequence of the locking script may be coded as switch statements or other conditional statements (e.g., "if-then-else") parameterized by the current state and one or more inputs.

[0103] In an embodiment, the bytecode sequence contained in the transaction locking script represents a set of state rules of the state machine, and the execution pointer and serialized state data contained in the transaction locking script represent the state of the state machine. The locking script also includes an interpreter code used to interpret the bytecode sequence of the locking script. In such an embodiment, the bytecode sequence and the interpreter code of the transaction locking script must be copied or replicated into every spending transaction that attempts to transfer control of a digital asset to a next transaction and linked to the current transaction. This process is repeated until a termination condition is met. Because the input data determined from the execution of the spending transaction unlocking script is not fixed and can be pending data, the state of the state machine can be changed based on certain external inputs. Thus, the pending data provides inputs that can affect the next state.

[0104] Furthermore, the number of bytecode operations of the locking script interpreted during validation of a spending transaction is determined by the difference between the execution pointer of the current execution state of the bytecode sequence of the locking script as included in the previous transaction and the execution pointer of the next execution state of the bytecode sequence of the locking script as included in the spending transaction, but can be varied by design by selecting or modifying the execution pointer of the next execution state of the bytecode sequence of the locking script as included in the spending transaction. In this way, the number of bytecode operations of the locking script interpreted during validation of a spending transaction can be constrained or used in parameterizing constraints of spending transactions (transactions using the locking script). This parameterized constraint can be used to limit the number of bytecode operations interpreted between transactions (e.g., to avoid inefficient operation of the bytecode sequence of the smart contract), to logically split the bytecode sequence of the smart contract into different segments executed over the sequence of spending transactions, to calculate rewards for entities that create new transactions based on the parameterized constraints, or for other possible uses.

[0105] Table 6 below shows one example of an unlocking script and a locking script that implements the trustless deterministic state machine of the present disclosure. [Table 6-1] [Table 6-2]

[0106] 10A-10C are flow charts illustrating an example operation of executing an unlocking script of a spending transaction and a locking script of a previous transaction, which are collectively part of a smart contract. This operation may be part of a verification process of a spending transaction. The spending transaction includes a locking script with a bytecode sequence and an interpreter code that implements a trustless deterministic state machine according to an embodiment of the present disclosure. The locking script also includes a next state execution pointer (or "next execution pointer") and serialized state data representing the next execution state of the state machine. The next execution pointer, as part of the locking script, references an execution point of the bytecode sequence corresponding to the next execution state. The serialized state data, as part of the locking script, represents the execution state of the state machine represented by the bytecode sequence at the execution point referenced by the next execution pointer included in the locking script. The interpreter code is used to interpret the bytecode sequence of the locking script.

[0107] It is noted that the serialized state data included as part of the locking script of the spend transaction can be determined when creating the spend transaction by generating or accessing the next execution pointer included in the locking script of the spend transaction, restoring the current execution state of the state machine using the serialized state data of the locking script of the previous transaction, and then executing the bytecode sequence of the locking script. Such execution starts at a point (or operation) corresponding to the current execution pointer included in the locking script of the previous transaction and ends at a point (or operation) corresponding to the next execution pointer included in the locking script of the spend transaction. Such execution can also use input of the unlocking script of the spend transaction. It is contemplated that creation of the spend transaction can include operations involving a wallet, an agent node, or some other node of the blockchain network.

[0108] 10A-10C (or any other processes described, or variations and / or combinations of these processes) may be performed under the control of one or more computer systems configured with executable instructions and / or other data and implemented as executable instructions collectively executing on one or more processors. The executable instructions and / or other data may be stored in a non-transitory, computer-readable storage medium (e.g., a computer program persistently stored in a magnetic, optical, or flash medium).

[0109] For example, some or all of the operations of Figures 10A-10C may be performed by a verification node in an example blockchain network, such as the example blockchain network 100 of Figure 1. Such a verification node may be comprised of any suitable computing device (e.g., by a server in a data center, by a client computing device, by multiple computing devices in a distributed system of a computational resource service provider, or by an electronic client device, such as computing device 2600 of Figure 13).

[0110] The operations of Figures 10A-10C verify that both the bytecode sequence and interpreter code of the locking script for the previous transaction and the spend transaction of the smart contract are the same, obtain a current execution state from the previous transaction, obtain input from the execution of the unlocking script of the spend transaction, determine a next execution state based at least in part on the interpretation of the bytecode sequence of the locking script, and verify that the next execution state determined from the execution of the locking script of the spend transaction matches the next execution state represented by the next state data included as part of the locking script of the spend transaction. The operations of Figures 10A-10C reflect the example script variations found in Table 6. The locking script of the previous transaction (e.g., scriptPubKey), as well as the unlocking script (e.g., scriptSig) and the unlocking script of the spend transaction (e.g., scriptSig) are all stored in virtual memory, which may be realized by one or more runtime data structures such as a stack, stack frame, or heap.

[0111] At 1001, it is determined whether an exit condition is met. In an embodiment, the exit condition may be a condition that, upon achievement, terminates a transition of a state machine represented by a bytecode sequence of the locking script. If the exit condition is met, the operations proceed to 1039, where replication of the locking script as part of the smart contract is terminated and further replication of the locking script is prevented such that operations continue to 1031 and 1033, as described below. If the exit condition is not met, the operations continue to 1003.

[0112] In 1003, the bytecode sequence of the locking script of the previous transaction is read from virtual memory, and the bytecode sequence of the locking script of the spending transaction is read from virtual memory, and the bytecode sequences of the two locking scripts are compared to each other to determine whether they match.

[0113] In 1005, it is determined whether the bytecode sequences of the two locking scripts compared in 1003 match each other. If not, operation continues to 1037 where it is determined that the spend transaction is invalid. If so, operation continues to 1007.

[0114] At 1007, the interpreter code of the locking script of the previous transaction is read from virtual memory and the interpreter code of the locking script of the spend transaction is read from virtual memory, and the interpreter code of the two locking scripts is compared to each other to determine whether they match.

[0115] In 1009, it is determined whether the interpreter codes of the two locking scripts compared in 1007 match each other. If not, operation continues to 1037 where it is determined that the spend transaction is invalid. If so, operation continues to 1011.

[0116] At 1011, an execution pointer to the current execution state of the locking script bytecode sequence (contained in the locking script of the previous transaction) is read from virtual memory.

[0117] At 1013, an execution pointer to the next execution state of the locking script bytecode sequence (contained in the locking script of the spend transaction) is read from virtual memory.

[0118] At 1015, the locking script's current state data (previously included in the transaction's locking script) is read from virtual memory and used to restore the execution state of the locking script's bytecode sequences in virtual memory. For example, the locking script's current state data is retrieved from virtual memory in a serialized format and then deserialized into a stack format and used in restoring the stack data structure in virtual memory that existed at the end of the previous execution of the locking script (where the execution pointer was at the current state execution pointer previously included in the transaction's locking script).

[0119] At 1017, the interpreter code (contained in the locking script of the previous transaction) is invoked, possibly interpreting the bytecode sequence of the locking script based on the input or inputs stored in virtual memory. Interpretation of the bytecode sequence of the locking script begins at the execution pointer for the current execution state of the locking script retrieved at 1011, and ends when the execution pointer for the next execution state of the locking script retrieved at 1013 is reached. In an embodiment, the bytecodes of the bytecode sequence of the locking script are computer instructions designed for interpretation by the execution of the interpreter code contained in the previous transaction.

[0120] In an embodiment, the execution of the interpreter code converts the bytecodes of the locking script bytecode sequence into opcodes or commands supported by the software interpreter of the validation node's runtime system (e.g., the blockchain client). The opcodes or commands are converted into machine code that runs on the validation node's CPU hardware, as shown in FIG. 11. The execution of the interpreter code can support the conversion of high-level bytecodes or commands that extend or complement the low-level bytecode operations supported by the software interpreter of the validation node's runtime system. For example, the interpreter code can support the conversion of virtual bytecodes that represent combinations of bytecode operations supported by the software interpreter of the validation node's runtime system. In this case, the interpreter code can support the conversion of the virtual bytecode operations OP_VSWAP and OP_VDROP of Tables 4A and 4B into op_codes or commands that belong to the Bitcoin scripting language and are supported by the software interpreter of the validation node's runtime system (e.g., the Bitcoin client). In another example, the interpreter code may support the conversion of script bytecode operations written in a high-level programming language for interpretation by a software interpreter of the validation node's runtime system. In this case, the interpreter code may support the conversion of script bytecode operations written in a high-level programming language into op_codes or commands that belong to the Bitcoin scripting language and are supported by the software interpreter of the validation node's runtime system. The execution of the software interpreter may sequentially convert the opcodes or commands into one bytecode at a time (e.g., simple interpretation) or may use a just-in-time compilation method.Bytecode sequence segments (or parts thereof) are compiled into machine code at run-time as necessary, and the resulting machine code is then executed. The resulting machine code may be cached and reused later without needing to be recompiled.

[0121] At 1019, it is determined whether the interpreter code has interpreted the bytecode sequence of the locking script to a point that corresponds to the execution pointer for the next execution state of the bytecode sequence of the locking script. If not, operation returns to 1017 where execution of the interpreter code continues. If so, operation continues to 1021.

[0122] In 1021, it is determined whether the resulting execution state stored in virtual memory is true. In an embodiment, this check ensures that both the operation of the spend transaction's unlocking script and the operation of the previous transaction's locking script's bytecode sequence completed without error and that all conditions encoded by the spend transaction's unlocking script and the previous transaction's locking script were satisfied. If not, operation continues to 1037, where it is determined that the spend transaction is invalid. If so, operation continues to 1023.

[0123] In 1023, the resulting execution state of the locking script bytecode sequence stored in the virtual memory (after reaching the execution pointer for the next execution state of the locking script bytecode sequence) is constructed and stored as serialized state data representing the next execution state of the locking script bytecode sequence, the serialized state data being in a serialized format for inclusion in the spend transaction.

[0124] At 1025, serialized state data representing the next execution state of the locking script's bytecode sequence is read from the virtual memory.

[0125] In 1027, the serialized state data representing the next execution state of the bytecode sequence of the locking script determined in 1023 is compared with the serialized state data representing the next execution state of the bytecode sequence of the locking script included in the spend transaction read from the virtual memory in 1025 to determine whether the serialized state data match.

[0126] At 1029, it is determined whether the serialized state data matches. If so, operation continues to 1031. If not, operation continues to 1037 where it is determined that the spend transaction is invalid.

[0127] At 1031 and 1033, operations determine whether one or more other conditions for the validity of the spend transaction are met. Such conditions may include other constraints specified in the previous transaction unlocking script and the spend transaction locking script. If so, operations continue to 1035, where the spend transaction may be deemed valid by the system performing the validation process. If not, operations continue to 1037, where the spend transaction is determined to be invalid. It is noted that one or more of the operations performed at 1001-1039 may be performed in various orders and combinations, including in parallel.

[0128] Also note that if the spend transaction is determined to be valid (e.g., at 1035) and potentially stored in the blockchain, the bytecode sequence of the locking script of the spend transaction may be duplicated to generate a “new” spend transaction. In this way, a portion of the “old” spend transaction is duplicated into the transaction that pays it. In this case, the input of the “new” spend transaction may reference this “old” spend transaction, and the output of the “new” spend transaction may include a locking script that embeds a copy of the bytecode sequence and shares the interpreter code of the locking script of the “old” spend transaction. The validation process of the “new” spend transaction may equate the “old” spend transaction to the previous transaction as part of the validation process.

[0129] Furthermore, the number of locking script bytecode operations interpreted when validating a "new" spend transaction is dictated by the difference between the execution pointer of the current execution state of the locking script bytecode sequence included in the "old" spend transaction and the execution pointer of the next execution state of the locking script bytecode sequence included in the "new" spend transaction, but can be varied by design by selecting or modifying the execution pointer of the next execution state of the locking script bytecode sequence included in the "new" spend transaction. In this way, the number of locking script bytecode operations executed when validating a "new" spend transaction can be constrained or used in parameterizing a constraint on the "new" spend transaction (which is a transaction that pays for the locking script). This parameterized constraint can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations of the smart contract bytecode sequence), to logically split the smart contract bytecode sequence into different segments that are executed on the spend transaction sequence, to calculate rewards for entities that create new transactions based on the parameterized constraint, or for other possible uses.

[0130] Also note that in one or more embodiments described above, for a given locking script, a spending transaction is a transaction that references the locking script in one of its inputs, and a previous transaction is a transaction that includes a locking script referenced in one of the inputs of the spending transaction. Furthermore, there can be as many previous transactions as there are inputs for the spending transaction. Furthermore, the blockchain protocol may not allow the locking script to query the spending transaction or one of the previous transactions. However, since a transaction is simply data with certain properties, and the locking script simply encodes constraints in the unlocking script to include certain data, these properties can be utilized to provide a locking script that allows the spending transaction and previous transactions to be injected into the unlocking script. This allows the locking script to constrain the spending transaction (e.g., require that the spending transaction have one output) and also to extract data from the previous transaction. Note that the locking script cannot constrain the previous transaction because it has already been written to the blockchain. The combination of both measures means that the locking script can extract data from previous transactions and constrain a spend transaction if the locking scripts of the previous transaction and the spend transaction contain the same bytecode sequences.

[0131] Furthermore, the bytecode sequences of the locking script, and the unlocking and locking scripts themselves, may be considered to be computer programs. As such, the unlocking and locking scripts require access to the memory system of the CPU executing the unlocking and locking scripts. In an embodiment, a portion of the memory system, referred to herein as virtual memory, may be allocated and managed to store the bytecode sequences and associated data of the locking and unlocking scripts.

[0132] 12A illustrates exemplary operations performed by executing interpreter code in interpreting a bytecode sequence included in a locking script. In an embodiment, both the interpreter code and the bytecode sequence are included as part of the locking script, as described herein. For the virtual memory of FIG. 5, interpreting the bytecode sequence may include first restoring a virtual main stack and a virtual alternate stack from the current state of the locking script, and then interpreting single bytecodes starting from the execution pointer of the current state until the execution pointer of the next state is reached.

[0133] As part of interpreting a bytecode, the executing interpreter code can perform an operation to obtain the next bytecode that requires interpretation. Table 7 below provides an opcode that performs this function, referred to as OP_GETOP. This opcode essentially takes the interpreted bytecode, extracts the current position from the previous transaction, and returns the required byte, in this case the next bytecode, to the top of the stack. [Table 7]

[0134] Table 8 below is a script describing the execution of interpreter code operating to interpret one exemplary bytecode, specifically the VOP_ADD bytecode shown diagrammatically in FIG. 12B. [Table 8]

[0135] In the context of describing the disclosed embodiments, unless otherwise specified, use of language referring to executable instructions (also referred to as code, applications, agents, etc.) that perform operations that the “instructions” do not normally perform unaided (e.g., transmitting data, performing calculations, etc.) means that the instructions are being executed by a machine, thereby causing the machine to perform the specified operations.

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

[0137] The bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface to receive data from other systems and to transmit data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a wireless network so that the data technician can transmit and receive data while at a remote location, such as a user data center. The bus subsystem 2604 may be utilized to communicate data, such as details, search terms, etc., to the surveillance models of the present disclosure, and may be utilized to communicate outputs of the surveillance models to one or more processors 2602 and to merchants and / or creditors via the network interface subsystem 2616.

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

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

[0140] The memory subsystem 2608 may have multiple memories, including a main random access memory (RAM) 2618 for storing instructions and data during program execution and a read-only memory (ROM) 2620 in which fixed instructions may be stored. The file / disk storage subsystem 2610 may provide non-transient persistent (non-volatile) storage for program files and data files, and may include hard disk drives, floppy disk drives with associated removable media, compact disk read-only memory drives (CD-ROMs), optical drives, removable media cartridges, and other similar storage media.

[0141] Computing device 2600 may include at least one local clock 2624. Local clock 2624 is a counter that represents the number of ticks that have occurred since a particular starting date and may be integrally located within computing device 2600. Local clock 2624 is used to synchronize data transfers among the processors and all subsystems contained therein for computing device 2600 at a particular clock pulse, and may be used to coordinate synchronization operations between computing device 2600 and other systems in a data center. In one embodiment, local clock 2624 is an atomic clock. In another embodiment, local clock is a programmable interval timer.

[0142] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. The device may thus be configured to convert optical signals into electrical signals that may be sent to the computing device 2600 for processing via the ports connecting the devices. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 13 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 13.

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

[0144] The use of the terms "a" and "an" and "the" and similar references in the context of describing the disclosed embodiments (particularly in the context of the claims which follow) are intended to cover both the singular and the plural unless otherwise indicated or clearly contradicted by context. The terms "comprising," "having," and "containing" are intended to be open-ended terms (i.e., meaning "including, but not limited to") unless otherwise indicated. The term "connected" is intended to be unmodified and, when referring to a physical connection, to be partially or wholly contained within, attached to, or joined together, even if there is some intervening material. Recitations of ranges of values ​​in this disclosure are merely intended to serve as a shorthand method of individually referring to each separate value falling within the range, unless otherwise indicated, and each separate value is incorporated into the specification as if it were individually recited. Use of the term "set" (e.g., "a set of items" or "subset") should be construed as a nonempty collection that contains one or more members, unless otherwise noted or contradicted by context. Further, unless otherwise noted or contradicted by context, use of the term "subset" in reference to a corresponding set does not necessarily indicate a proper subset of the corresponding set, although a subset and a corresponding set may be equivalent.

[0145] Conjunctive language, such as phrases of the form "at least one of A, B, and C" or "at least one of A, B and C," is understood in its general context to indicate that an item, term, etc. may be either A or B or C, or any non-empty subset of the set A and B and C, unless specifically stated otherwise or clearly contradicted by context. For example, in the illustrative example of a set having three members, the conjunctive language "at least one of A, B, and C" refers to any of the following sets: {A}, {B}, {C}, {A,B}, {A,C}, {A,B,C}. Thus, such conjunctive language is not generally intended to mean that a given embodiment requires that there be at least one A, at least one B, and at least one C, respectively.

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

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

[0148] The embodiments of the present disclosure have been 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 such variations to be adopted by those skilled in the art as appropriate, and the inventors intend for the embodiments of the present disclosure to be practiced other than as specifically described. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the appended claims as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed within the scope of the present disclosure unless otherwise indicated or clearly contradicted by context.

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

[0150] It should be noted that the above-described embodiments are illustrative rather than limiting the present invention, and 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, any reference signs placed 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 specification as a whole. In this specification, "comprising" means "comprising or consisting of" and "comprising" means "comprising or consisting of". A singular reference of an element does not exclude a plural reference of such element, and vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. [Explanation of symbols]

[0151] 100 Blockchain Networks 102 nodes 202 1st Transaction 204 Second Transaction 206 3rd Transaction 208 Blockchain 304 Locking Script 306 State Machine 308 Expenditure Transactions 312 Locking Script 314 Set of State Rules 2600 Computing Devices

Claims

1. 1. A computer-implemented method comprising: in response to determining that the termination condition is not satisfied, reading a bytecode sequence of a locking script of the previous transaction and a bytecode sequence of a locking script of the spend transaction from the spend and comparing the bytecode sequences of the two locking scripts to each other to determine whether they match; responsive to determining that the locking scripts match, reading from a virtual memory an execution pointer for a current execution state of the bytecode sequence of the locking script of the previous transaction; reading from said virtual memory an execution pointer for a next execution state of said bytecode sequence of said spend transaction locking script; reading from the virtual memory data of a current state of the locking script of the previous transaction to restore an execution state of the bytecode sequence of the locking script in the virtual memory; executing the bytecode sequence of the previous transaction's locking script based on input stored in the virtual memory; in response to determining that the execution pointer of the locking script has reached a point corresponding to the execution pointer for a next execution state of the bytecode sequence of the locking script, evaluating a resulting next execution state as true; storing the resulting next execution state in the virtual memory as serialized next state data representing the next execution state of a bytecode sequence of the locking script; reading serialized next state data of a locking script for said spend transaction; in response to determining that the serialized next state data stored in the virtual memory matches the serialized next state data included in the spending transaction, determining whether one or more other conditions regarding the validity of the spending transaction are met; determining that the spend transaction is valid; A method comprising:

2. The method is executed by a validator node of a blockchain network. The method of claim 1.

3. The current state data of the locking script is extracted from said virtual memory in a serialized format, and then deserialized into a stack format for use in restoring the virtual memory stack data structure that existed at the end of a previous execution of the bytecode sequence associated with the locking script of the previous transaction; the execution pointer was the current state execution pointer contained in the locking script of the previous transaction; The method according to claim 1 or claim 2.

4. Executing the bytecode sequence of the locking script comprises: starting with an execution pointer for the current execution state of the bytecode sequence associated with the locking script retrieved from the previous transaction; and terminating when an execution pointer for the next execution state of the bytecode sequence associated with the locking script retrieved from the spend transaction is reached.

4. The method according to claim 1 .

5. the bytecodes of the bytecode sequence for the locking script are computer instructions for interpretation by a software interpreter that is part of a runtime system of a node that validates the spend transaction; 5. The method according to any one of claims 1 to 4.

6. execution of the software interpreter is configured to convert the bytecode of a bytecode sequence segment into machine code suitable for execution on a particular CPU hardware of a node validating the spend transaction; The method according to claim 5.

7. Execution of the software interpreter comprises: Sequentially converting the bytecodes of the bytecode sequence segment into machine code, one bytecode at a time; or using a just-in-time compilation method, where the bytecode sequence segments are compiled into machine code at run-time as needed, and the resulting machine code is then executed; The method according to claim 6.

8. The resulting machine code is: Cached and It can be reused later without having to be recompiled, The method according to claim 7.

9. the serialized state data is stored in the virtual memory in a serialized format for inclusion in the spend transaction; 9. The method according to any one of claims 1 to 8.

10. the one or more other conditions for determining that the spend transaction is valid include other constraints specified in the locking script or an unlocking script of the spend transaction.

10. The method according to any one of claims 1 to 9.

11. 1. A system comprising: A processor; a memory containing executable instructions; The executable instructions, upon execution by the processor, cause the system to perform a method according to any one of claims 1 to 10. system.

12. A non-transitory computer-readable storage medium having executable instructions stored thereon, comprising: The executable instructions, upon execution by a processor of a computer system, cause the computer system to perform the method of any one of claims 1 to 10. A non-transitory computer-readable storage medium.

Images