Method and system for script-based byte interpretation for blockchain implementation

Abstract

The invention relates to a distributed account book technology, such as a block chain based on consensus. A computer-implemented method for a detrusted deterministic state machine implemented by a lock script of a depletion transaction is described. Consumption transaction transfers control of at least one digital asset or a portion thereof. The consumption transaction is associated with a previous transaction that includes a lock script having a sequence of bytecodes. The consumption transaction also includes a lock script having the same bytecode sequence. The consumption transaction may be confirmed by verifying whether bytecode sequences of locked scripts of the consumption transaction and a previous transaction match each other. As a result of executing the lock script, control of the at least one digital asset or a portion thereof may be transferred. For example, a lock script may apply a set of conditions to validate a consumption transaction.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201880053431.0 (PCT international application number PCT / IB2018 / 055892), application date August 6, 2018, and name “Script-based byte interpretation method and system for blockchain implementation”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority from UK Patent Application No. 1713046.9 filed on August 15, 2017, the entire contents of which are incorporated herein by reference. Technical Field

[0004] The present invention relates generally to blockchain technology, and more particularly to blockchain transactions using consuming transaction scripts. The present invention is particularly suitable for, but not limited to, use in self-executing smart contracts. Background Art

[0005] 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 unpermissioned ledgers, shared ledgers, and variations thereof. It should be understood that the present invention is not limited to use with a particular blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0006] Blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system consisting of blocks, which in turn consist of transactions and other information. For example, each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system, and includes at least one input and at least one output. In some embodiments, control of digital assets can be transferred by reassociating at least a portion of the digital assets from a first entity to a second entity. Each block contains a hash of the previous block, so that the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since the creation of the blockchain. Transactions contain small programs called scripts that are embedded in their inputs and outputs, which specify how and by whom to access the output of the transaction. These scripts use a stack-based script processing language.

[0007] In other words, a stack-based script processing language can utilize a data structure called a stack. In the case of a stack, values ​​can be pushed to or popped from the top of the stack.

[0008] In order for a transaction to be written to the blockchain, it must be "validated". Network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. Nodes can have different validity criteria than other nodes. Since validity in the blockchain is based on consensus, a transaction is considered valid if a majority of nodes agree that it is valid. The software client installed on the node partially performs this validation work on transactions that reference unspent transaction (UTXO) by executing the UTXO lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, and other validation conditions are met (if applicable), the transaction made by the node is valid. Confirmed transactions are propagated to other network nodes, which can then choose to include the transaction in the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must be: i) confirmed by the first node that receives the transaction - if the transaction is confirmed, the node relays it to other nodes in the network; ii) added to a new block; and iii) added to the public ledger of past transactions. When a sufficient number of blocks are added to the blockchain to make the transaction effectively irreversible, the transaction is considered to have been confirmed.

[0009] One area of ​​current research is the use of blockchain to implement "smart contracts." These smart contracts are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Unlike traditional contracts, which would be written in a natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce results, and actions can then be performed based on those results.

[0010] In an embodiment, a smart contract is "smart" in the sense that it is not enforced and / or executed on the creator or some other specific entity. In other words, although the interaction with a specific entity can be encoded at a specific step in the smart contract, the smart contract can be automatically executed by the machine in other ways and enforced by itself. Smart contracts are machine-readable and executable. In some examples, automatic execution means that any entity can consume UTXO and has the motivation (e.g., reward) to consume UTXO. It should be noted that in such examples, "any entity" that can consume UTXO refers to an entity that can create an unlocking script without proving that it knows certain secrets. In other words, a spending transaction can be confirmed without verifying that the data source has access to a cryptographic secret (e.g., a private asymmetric key, a symmetric key, etc.). Similarly, in such examples, self-enforcement refers to enforcing the consumption transaction by the confirmation node of the blockchain network according to the constraints. In some examples, "consuming" UTXO refers to a consumption transaction that quotes UTXO and is effectively executed.

[0011] Blockchain transaction outputs include a locking script and information about the ownership of a digital asset. A locking script "locks" a digital asset by specifying conditions that need to be met in order to spend the output. A locking script may also be referred to as a block. For example, a locking script may require certain data to be provided in an unlocking script to unlock the associated digital asset. Techniques for requiring a party to provide data to unlock a digital asset include embedding a hash of the data in a locking script. Summary of the invention

[0012] It is therefore desirable to provide improved methods and systems that improve blockchain technology in one or more of these aspects.Accordingly, some methods and corresponding systems are provided in accordance with the present invention.

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

[0014] As will be described in more detail below, in an embodiment, a trustless deterministic state machine may be implemented by a (first) locking script implemented or represented by a bytecode sequence. In one or more embodiments, the locking script may be part of or include a part of a parameterized smart contract, whereby a first ("spending") blockchain transaction is used to transfer control of a digital asset / resource. A spending transaction may reference a transaction, the previous transaction including a locking script including a bytecode sequence. A transaction may also include a locking script including a bytecode sequence such that the locking scripts of the previous transaction and the spending transaction share the same bytecode sequence. A spending transaction may be received at a node in a blockchain network. Confirmation may be performed by obtaining a previous transaction and verifying that the locking scripts of the previous transaction and the spending transaction share the same bytecode sequence.

[0015] In other embodiments, the locking script of the previous transaction may further include an interpreter code for interpreting the bytecode sequence of the locking script of the previous transaction, and the locking script of the consumed transaction may also include the interpreter code, so that the locking scripts of the previous transaction and the consumed transaction share the same interpreter code. The interpreter code may support the conversion of at least one high-level bytecode operation into a low-level bytecode operation executed by the node confirming the consumed transaction. In this case, the confirmation of the consumed transaction may further include verifying whether the locking scripts of the previous transaction and the consumed transaction share the same interpreter code.

[0016] As will be described in more detail below, in embodiments, the bytecode sequence and / or interpreter code of a locking script may be copied as part of a locking script for an ordered number of spending transactions (or a sequence of spending transactions) until a termination condition is achieved.

[0017] Therefore, according to an embodiment of the present invention, a computer-implemented method may be provided, the computer-implemented method comprising:

[0018] A first blockchain transaction (a "spending transaction") is received to transfer control of at least one digital asset or a portion thereof, wherein the first blockchain transaction includes a (first) locking script represented by a bytecode sequence, and wherein the first blockchain transaction references a previous (blockchain) transaction including a (second) locking script represented by a bytecode sequence, such that the first locking script and the second locking script share the same bytecode sequence; the first transaction may be referred to as a "spending" transaction. The transaction may be received at a node in a blockchain network. The transaction may be arranged to transfer control of a digital asset (also referred to as a "digital resource") to an entity, party or node via the network.

[0019] In addition, according to an embodiment of the present invention, a computer-implemented method may be provided, the method comprising: receiving a consumption blockchain transaction to transfer control of at least one digital asset or a portion thereof, wherein the consumption transaction includes a locking script represented by a bytecode sequence, and wherein the consumption transaction references a previous transaction including a locking script represented by a bytecode sequence, so that the first locking script and the second locking script share the same bytecode sequence; and confirming the consumption transaction by verifying whether the bytecode sequence of the locking script of the consumption transaction matches the bytecode sequence of the locking script of the previous transaction; wherein at least a portion of the consumption transaction is copied to generate a new consumption transaction until a termination condition is met; wherein the bytecode sequence of the locking script is copied as a part of the locking script of the consumption transaction an ordered number of times until the termination condition is met.

[0020] The aforementioned method may further include the following steps:

[0021] The first (spending) blockchain transaction is confirmed by confirming whether the bytecode sequence of the first locking script matches the bytecode sequence of the locking script of the previous transaction (i.e., the second locking script).

[0022] Preferably, the first blockchain transaction further includes an interpreter code, and the previous blockchain transaction further includes an interpreter code, so that the first blockchain transaction and the previous blockchain transaction share the same interpreter code to interpret the bytecode sequences of the first locking script and the second locking script, and confirming the first blockchain transaction further includes verifying whether the interpreter code of the first blockchain transaction matches the interpreter code of the previous blockchain transaction.

[0023] Preferably, the first blockchain transaction is received and / or confirmed by a node in the blockchain network. Additionally or alternatively, the previous blockchain transaction may be stored on a blockchain maintained by a node of the blockchain network. Additionally or alternatively, the first blockchain transaction may be generated by copying at least a portion of the previous blockchain transaction. Additionally or alternatively, the first locking script may include at least one operation to verify whether the bytecode sequence of the first locking script matches the bytecode sequence of the second locking script. The interpreter code may be included as part of the first locking script and the second locking script. Additionally or alternatively, the interpreter code may support converting at least one high-level bytecode operation to a low-level bytecode operation executed by the node. Additionally or alternatively, the first locking script may include at least one operation arranged to verify whether the interpreter code of the first locking script matches the interpreter code of the second locking script.

[0024] Preferably, the first locking script and the second locking script (i.e., the locking script of the consuming transaction and the locking script of the previous transaction) further include data related to different execution states of the bytecode sequence shared by the first locking script and the second locking script, wherein the data is used to control the interpretation of the bytecode sequence when confirming the first blockchain transaction.

[0025] 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, wherein the first locking script also 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 confirming the first blockchain transaction further includes: i) restoring the current execution state of the bytecode sequence using the data representing the current execution state of the bytecode sequence; ii) executing the bytecode sequence starting from the execution pointer corresponding to the current execution state of the bytecode sequence until the execution pointer corresponding to the next execution state of the bytecode sequence ends; and iii) comparing the state data resulting from executing 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 whether these state data match.

[0026] Preferably, confirming the first blockchain transaction further comprises extracting state data for a current execution state of the bytecode sequence from the virtual memory, extracting an execution pointer corresponding to the current execution state of the bytecode sequence from the virtual memory, and extracting an execution pointer corresponding to a next execution state of the bytecode sequence from the virtual memory.

[0027] Preferably, the virtual memory stores data related to different execution states of the bytecode sequence in different first and second formats, wherein the first format is used to store such data as part of a locking script, and wherein the second format is suitable for manipulating the data in the virtual memory when executing the bytecode sequence of the locking script.

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

[0029] The method may further include 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 comparing the state data resulting from executing the bytecode sequence with state data for a next execution state of the bytecode sequence included in the first (consuming) blockchain transaction by serializing the state data resulting from executing the bytecode sequence from a stack format to a byte format.

[0030] Preferably, control of the at least one digital asset, or a portion thereof, is transferred as a result of executing the first locking script, and the second locking script imposes a set of conditions to confirm the first blockchain transaction.

[0031] Preferably, the first blockchain transaction further includes an unlocking script, wherein executing the unlocking script provides data (which may be a determined data source or an undetermined data source) used to obtain a set of conditions for confirming the first blockchain transaction.

[0032] Preferably, at least a portion of the first blockchain transaction is copied to generate a new blockchain transaction until a termination condition is satisfied (e.g., when the size of the digital asset associated with the first blockchain transaction is insufficient to be transferred).

[0033] Preferably, the first blockchain transaction and the previous blockchain transaction embody a partial smart contract.

[0034] According to the present invention, a system is also provided, which is arranged to implement any embodiment of one or more methods described above. The system may include: a processor; and a memory, the memory containing executable instructions, the executable instructions are executed by the processor, so that the system performs the computer-implemented method of any one of the above embodiments.

[0035] A non-transitory computer-readable storage medium is also provided, on which executable instructions are stored. The executable instructions are executed by a processor of a computer system, causing the computer system to execute at least the computer-implemented method of any one of the above-mentioned embodiments.

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

[0037] In addition, the techniques described and taught in this disclosure must be rooted in computer technology to overcome problems that exist in distributed ledger technology and blockchain technology, especially in the use of scripting languages ​​that are specifically designed to limit functionality for security reasons. For example, the script processing language itself does not support the presence of complex flow control functions (e.g., loops). One advantage of this limitation is that the program has a predictable execution time. Another significant advantage of limiting the script to linear or tree-like decision tasks is that this avoids infinite loops, which may be used as a means of launching exploits such as denial of service (DoS or DDoS) attacks. Therefore, the security of blockchain transfers / exchanges is enhanced and retained, but mechanisms need to be found to implement functions that the language itself does not allow or provide. The present invention provides improvements in this regard, and the current limitations of blockchain transactions are at least partially solved by the implementation of self-replicating blockchain transaction locking scripts. Therefore, the present invention provides a technical solution to the technical problem and has advantages in security, improved control of digital asset exchanges / transfers via blockchains, and expansion of current blockchain-related functions. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0039] Figure 1 shows a blockchain environment in which various embodiments may be implemented;

[0040] Figure 2 An example of a smart contract employing a locking script containing a bytecode sequence replicated over a transaction sequence is shown according to an embodiment.

[0041] Figure 3 According to the embodiment Figure 2 An example of a locking script that employs a bytecode sequence that is interpreted to implement a trustless deterministic state machine;

[0042] FIG. 4A to FIG. 4C The embodiment of the present invention is shown in FIG. Figure 3 A flowchart of an example of the operation of consuming the unlocking script of a transaction and the locking script of a previous transaction;

[0043] Figure 5 is a schematic diagram of an exemplary virtual stack data structure of a bytecode sequence that may be used to execute a locking script according to an embodiment;

[0044] Figure 6 Depending on the implementation, it can be stored as Figure 3 Schematic diagram of serialized state data as part of a locking script;

[0045] Figure 7 is a method that can be used to convert serialized state data stored as part of a locking script into a state suitable for storage in Figure 5 A schematic diagram of the operation of the format on the stack data structure;

[0046] Figure 8 According to the implementation, it can be used to Figure 5 A schematic diagram of an operation of converting state data stored in the format of a stack data structure into serialized state data suitable for storage in a locking script;

[0047] Fig. 9 According to the embodiment Figure 2 Another example of a locking script that uses a bytecode sequence and interpreter code to implement a trustless deterministic state machine;

[0048] FIG. 10A to FIG. 10C The embodiment of the present invention is shown in FIG. Fig. 9 A flowchart of an example of the operation of consuming the unlocking script of a transaction and the locking script of a previous transaction;

[0049] Fig.11 is a diagram showing a method according to an embodiment Fig. 9 a schematic diagram of the execution of the interpreter code of the locking script, which cooperates with the execution of the built-in software interpreter of the runtime system of the confirming node (e.g., the blockchain client) to interpret the bytecode sequence of the locking script;

[0050] Fig. 12A and Fig. 12B As FIG. 10A to FIG. 10C a schematic diagram of exemplary operation of interpreter code of a locking script as part of the operation of , which exemplary operation interprets VOP_ADD bytecode as part of the locking script; and

[0051] Fig.13 A computing environment is shown in which various embodiments may be implemented. DETAILED DESCRIPTION

[0052] First, refer to Figure 1 , which shows an exemplary blockchain network 100 associated with a blockchain according to an embodiment of the present disclosure. In this embodiment, the exemplary blockchain network 100 includes peer-to-peer distributed electronic devices running an instance of the blockchain protocol. In some examples, the distributed electronic devices are referred to as nodes 102.

[0053] Node 102 may include any suitable computing device (e.g., including 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 computing resource service provider, or any suitable electronic client device such as Fig.11 computing device 2600).

[0054] In an embodiment, one or more of the nodes 102 are communicatively coupled to one or more other nodes in the nodes 102. Such communicatively coupling may employ one or more of well-known wired communication links or wireless communication links. In this embodiment, each node 102 maintains at least a portion of a "ledger" of all transactions in the blockchain. In this manner, the ledger is a distributed ledger. Transactions processed by a node affecting the ledger can be verified by one or more of the other nodes, so that the integrity of the ledger is maintained.

[0055] In an embodiment, at least some of the nodes 102 perform processes associated with complex computations, such as solving cryptographic problems. The node that solves the cryptographic problem creates a new block for the blockchain and broadcasts the new block to the other nodes in the nodes 102. The other nodes in the nodes 102 perform a verification process that verifies the work of the node and receives the block into the blockchain after verification (e.g., by adding the block to the distributed ledger of the blockchain). In some examples, a block is typically a set of transactions marked with a "fingerprint" (e.g., a hash) and a timestamp of the previous block. In this way, each block is linked to the previous block, thereby creating a "chain" of linked blocks in the blockchain. In an embodiment, valid blocks are added to the blockchain through the consensus of the nodes 102. Also in some examples, the blockchain includes a list of confirmed blocks.

[0056] In an embodiment, at least some of the nodes 102 operate as validation nodes that perform a validation process to validate transactions as described in this disclosure. Figure 1 An exemplary transaction marked as 104 is shown. In some examples, the transaction includes data that provides proof of ownership of the digital asset and conditions for accepting or transferring ownership / control of the digital asset. In some examples, a "spending transaction" refers to a transaction that reassociates (e.g., transfers ownership or control) at least a portion of a digital asset to an entity associated with a blockchain address, the digital asset represented by an unspent transaction output (UTXO) of a previous transaction. In some examples, a "previous transaction" refers to a transaction that contains a UTXO referenced by a spending transaction. In some embodiments, a transaction may include an "unlocking script" and a "locking script" that block the transaction by conditions that must be met before the transaction is confirmed and before the transaction transfers ownership / control. In some embodiments, a locking script may be associated with the output of a transaction and may be configured to define one or more conditions required to consume the output. In addition, the unlocking script of the spending transaction may be configured so that executing the unlocking script provides data for obtaining a set of conditions to confirm the spending transaction, which is evaluated by the locking script of the previous transaction executed. In some embodiments, a blockchain address is a string of alphanumeric characters 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. Confirmation of a transaction may include confirming one or more conditions specified in an unlocking script and / or locking script of the transaction. After successfully confirming the transaction, the confirming node may propagate the transaction to other network nodes, which may then choose to embed the transaction as part of a block added to a blockchain as described herein.

[0057] Some blockchain technologies use the Elliptic Curve Digital Signature Algorithm (ECDSA) as a mathematical scheme for digital signatures. In an embodiment, ECDSA is a cryptographic digital signature used to protect UTXO from being consumed by unauthorized entities. Elliptic Curve Digital Signatures (ECDS) typically have a signature hash tag (SIGHASH type) appended to the end; however, it is contemplated that the techniques of the present disclosure can be used with blockchain technologies that do not implement the SIGHASH type. In such blockchain technologies, it is contemplated that ECDS complies with the signature generation principles of the particular blockchain technology.

[0058] In some implementations, a SIGHASH type refers to a set of fields extracted from a transaction before being serialized (e.g., normalized) and hashed. For example, the SIGHASH type can affect which fields of a transaction are included in the signature. In some examples, the SIGHASH type can be one or more of SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, or SIGHASH_ANYONECANPAY.

[0059] Various operations may be performed using a script processing system called a "script". In the present disclosure, various script operation codes (or op_codes) and keywords are referenced to perform various operations. However, it is envisioned that other blockchain technologies may implement different instruction sets, and therefore, the operation codes described in the present disclosure are considered to be instructions for the operations performed by the operation code (rather than a specific operation code in the script). In some embodiments, the script processing system is a Turing incomplete instruction set (e.g., does not support loops, recursion, goto statements, etc.). In other embodiments, the script processing system may be a Turing complete instruction set.

[0060] Certain embodiments of the present disclosure may operate under the assumption that a script processing system or other system for implementing the described instruction set allows more than 200 instructions (e.g., operation codes or op_codes) in a single script. Likewise, certain embodiments of the present disclosure also assume that:

[0061] In a system executing an opcode script / instruction set, functionality provided by certain low-level opcodes (or low-level bytecode operations) is present and enabled; and / or

[0062] The functionality provided by certain high-level opcodes (or high-level bytecode operations) can be implemented by creating custom functions written to provide the desired behavior. These custom functions can 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 specific functionality not originally provided in the script processing language.

[0063] Examples of low-level operation codes that the script processing system can support include:

[0064] OP_1SUB, where the value "1" is subtracted from the top stack item

[0065] OP_2DUP, which copies the first two stack items

[0066] OP_ADD, which adds the first two items on the stack

[0067] OP_CAT, which concatenates the first two items on the stack

[0068] OP_CHECKSIG, in which the public key and signature are popped from the stack and sent according to the SIGHASH class

[0069] OP_CHECKSIGVERIFY, which is the same as OP_CHECKSIG, but executes OP_VERIFY afterwards.

[0070] OP_DROP, which removes or pops the top item of the stack

[0071] OP_DUP, which duplicates the top stack item

[0072] OP_ELSE, if the previous OP_IF or OP_NOTIF or OP_ELSE is not executed, then these statements are executed; otherwise, if the previous OP_IF or OP_NOTIF or OP_ELSE is executed, then these statements are not executed

[0073] OP_ENDIF, which ends the if / else block

[0074] OP_EQUAL, returns 1 if the inputs are exactly equal, otherwise returns 0

[0075] OP_EQUALVERIFY, which is the same as OP_EQUAL, but runs OP_VERIFY afterwards OP_FROMALTSTACK, which places the input on top of the primary stack and removes the input from the alternate stack

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

[0077] OP_IF, if the top stack value is not False, execute this statement and remove the top stack value

[0078] OP_LEFT, which retains only the characters to the left of the specified point in the string

[0079] OP_MUL, which multiplies the first two items on the stack

[0080] OP_NOTIF, which executes the statement and removes the top stack value if the top stack value is False OP_RIGHT, which keeps only the characters to the right of the specified point in the string

[0081] OP_ROLL, where the item that is n items deep in the stack is moved to the top

[0082] OP_ROT, which rotates the first three items on the stack to the left

[0083] OP_SIZE, which pushes the string length of the top element of the stack (without popping it)

[0084] OP_SUBSTR, which returns a portion of a string

[0085] OP_SWAP, where the first two items on the stack are swapped

[0086] OP_TOALTSTACK, which places the input on top of the alternate stack and removes the input from the main stack

[0087] OP_TUCK, where the top item on the stack is incremented and inserted before the second positive item

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

[0089] The protocol's script handling system currently supports these low-level operation codes.

[0090] Examples of high-level operation codes that may be supported by the methods and systems of the present disclosure include:

[0091] OP_ECPX, which returns the x-coordinate of an elliptic curve point

[0092] OP_BIGMOD, which returns the remainder after dividing the first two items on the stack

[0093] OP_BIGMODADD, which performs the modulo addition of the first two items on the stack modulo the third item on the stack

[0094] OP_BIGMODINVERSE, which performs a modulus negative exponentiation operation

[0095] OP_BIGMODMUL, which performs a modulo multiplication of the first two items on the stack modulo the third item on the stack

[0096] OP_DERENCODE, which encodes the first two items on the stack in DER format

[0097] OP_ECPMULT, which performs elliptic curve point multiplication (also known as elliptic curve scalar multiplication) on the first two items on the stack

[0098] These high-level operation codes may provide specific functionality not originally provided by the protocol's script processing system.

[0099] Figure 2An example implementation 2100 of a smart contract is shown that employs a locking script as part of a transaction sequence, wherein 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 1 unit of the digital asset 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 added to the blockchain network, so that the first transaction 202 is embedded in a block, and then the block is verified, so that the block is stored on the blockchain 208. The locking script of the first transaction 202 (or a portion thereof) is copied and combined as part of the locking script of the second transaction 204. The second transaction 204 is a spending transaction confirmed by executing the locking script of the first transaction 202, which is configured to pay the initial amount X of 1 unit held by the first transaction 202 to a pay-to-public-key-hash (P2PKH) address belonging to Alice, and hold a new total amount (X'=X-1). In some examples, P2PK or P2PKH can be used to transfer a digital asset to an address of an entity associated with a corresponding public key. The second transaction 204 is then added to the blockchain network so that the second transaction 204 is embedded in a block, which is then verified so that the block is stored on the blockchain 208. The locking script of the second transaction 204 (or a portion thereof) is copied and combined as part of the locking script of the third transaction 206. The third transaction 206 is a spending transaction confirmed by executing the locking script of the second transaction 204, which is configured to pay 1 unit of the amount X' held by the second transaction 204 to a pay-to-public-key-hash (P2PKH) address belonging to Alice, and reserve a new total amount (X" = X'-1). The third transaction 206 is then added to the blockchain network so that the third transaction 206 is embedded in a block, which is then verified so that the block is stored on the blockchain 208. If desired, the locking script of the third transaction 206 (or a portion thereof) can be copied and combined as part of the locking script of one or more subsequent spending transactions as described above. Therefore, it can be seen that As processing continues, regardless of the initial amount X, a consumption transaction will eventually be generated to output an unconsumable amount of digital assets (e.g., zero). This can be intuitively understood by observing that each subsequent consumption transaction will have a smaller amount of digital assets than its previous transaction, even without deducting the minimum transaction fee deducted in various blockchain protocols. Therefore, the amount output will converge to zero, at which point it becomes meaningless to conduct a transaction. However, embodiments of the present disclosure include solutions to this problem by implementing a termination condition to avoid such unconsumable consumption transactions. Once confirmed and stored on the blockchain, the corresponding transaction sequence 202, 204, 206, etc. provides a transfer of control of the digital assets referenced by the transaction.

[0100] Furthermore, in an embodiment, the transaction sequences 202, 204, 206, etc. of the smart contract include a locking script having a bytecode sequence that is copied or replicated in all transactions. Therefore, the confirmation process for each consuming transaction of the smart contract may include: extracting the bytecode sequence of the locking script from the previous transaction, extracting the bytecode sequence of the locking script from the consuming transaction, and verifying whether the two extracted bytecode sequences match each other.

[0101] A basic overview of this process is provided in Table 1 below:

[0102] Table 1:

[0103]

[0104] As can be seen in the script above, the bytecode sequence of the locking script of the previous transaction (e.g., the first transaction 202) - which is the locking script that will unlock the UTXO of the previous transaction - is verified against the bytecode sequence of the locking script of the consuming transaction (e.g., the second transaction 204), which will be redeemed in the future when the consuming transaction is the previous transaction of another consuming transaction (e.g., the third transaction 206). Therefore, instead of creating a different consuming transaction for each transaction, the locking script enforces that the bytecode sequence for the two locking scripts must be the same. If the bytecode sequence of the locking script of the previous transaction is the same as the bytecode sequence of the locking script of the consuming transaction, it is ensured that both locking scripts are authentic.

[0105] In an embodiment, the termination condition avoids the situation where there is not enough funds for the previous transaction but the locking script is still confirmed, that is, a non-consumable transaction. For example, the termination condition can be implemented to verify whether there is enough digital assets to execute the next transaction, otherwise the confirmation is terminated. As a more specific example, if the initial pool contains 365 units of digital assets plus the amount required for each transaction fee (for example, enough to conduct one transaction every day for a year), the termination condition can confirm that the number of units remaining exceeds the number of units required to complete the transaction; for example, as long as there are sufficient funds, the transaction can continue to be confirmed. Otherwise, if there are insufficient funds, the termination condition is met and the confirmation is terminated. Therefore, if there are not enough funds on the 366th day, it is unnecessary to confirm the locking script of the 366th consuming transaction, and the termination condition ensures that it terminates the replication of the transaction and the associated locking script.

[0106] Notice, Figure 2The smart contract described above that pays a digital asset to a pay-to-public-key-hash (P2PKH) address belonging to Alice is exemplary. In embodiments, the principles and operations of the locking scripts described herein can be extended to support a wide variety of smart contracts using blockchains. In this document, the term "smart contract" is used to include contracts whose terms are executed by a sequence of transactions that employ a computerized transaction protocol to store transactions on a blockchain.

[0107] Figure 3 An exemplary transaction according to an embodiment of the present disclosure is shown, which employs a locking script with a public bytecode sequence to implement a trustless deterministic state machine. More specifically, the public bytecode sequence is a computer program that can be viewed as a state machine that embodies a set of state rules with a set of well-defined states, such that the bytecodes executing the bytecode sequence (computer program) provide transitions between states of the state machine.

[0108] like Figure 3 As schematically shown 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: serialized state data representing a current state within the state of the state machine 306 represented by the bytecode sequence; and a current state execution pointer (or "current execution pointer"). In the example shown, the serialized state data and the current execution pointer of the locking script 304 represent the current state "S1", and the set of state rules of the state machine 306 represented by the bytecode sequence provide two possible states ("S2" or "S3") for the next state after the current state S1. The current execution pointer included as part of the locking script 304 refers to the execution point of the bytecode sequence corresponding to the current state (in this case, state "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 execution point referenced by the current execution pointer included in the locking script 304.

[0109] from Figure 3As can be seen in the example of , the consumption transaction 308 includes a locking script 312 having a bytecode sequence that represents 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 serialized state data representing one of the possible next states after the current state S1 (in this case, state "S2") and a next state execution pointer (or "next execution pointer"). The next execution pointer included as part of the locking script 312 refers to the execution point of the bytecode sequence corresponding to the next state after 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.

[0110] Note that when creating a consumption transaction, the serialized state data included as part of the lock script 312 may be determined by restoring the current execution state of the bytecode sequence of the lock script using the serialized state data of the lock script 304 of the previous transaction to generate or access the next execution pointer included in the lock script 312, and then executing the bytecode sequence of the lock 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 lock script 312. Such execution may also be performed using the input data 310 determined by executing the unlocking script of the consumption transaction 308.

[0111] As part of validating the spending transaction 308, the common bytecode sequence of the unlocking script and the locking script 304 / 312 of the spending transaction 308 is executed. The execution of the common bytecode sequence takes as input the input data 310 determined by executing the unlocking script of the spending transaction 308, and the current state "S1" represented by the serialized state data and the current execution pointer contained in the locking script 304 of the previous transaction 302 and the next execution pointer contained in the locking script 312 of the spending 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 spending transaction 308. Such execution determines the appropriate next state (e.g., the second state "S2") from a set of state rules 314 represented by the common bytecode sequence. The next state (e.g., state "S2") determined from the execution of the common bytecode sequence to the point (or operation) corresponding to the next execution pointer contained in the locking script 312 of the consumption transaction 308 is organized as serialized state data that follows the serialization format of the state data contained as part of the locking script 312 of the consumption transaction 308. The serialized state data determined from the execution of the common bytecode sequence is then verified against the serialized state data contained as part of the locking script 312 of the consumption transaction 308. Again, rather than creating a different consumption transaction for each transaction, the execution of the locking script enforces that the execution state obtained by executing the bytecode sequence of the locking script during the validation of the consumption transaction matches the expected resulting execution state of the locking script contained in the consumption transaction when the consumption transaction was created. If the two resulting execution states are the same, the locking script is ensured to be valid.

[0112] Notice, Figure 3 The example of 308 shows that the state of the state machine represented by the bytecode sequence of the locking script 312 of the consumption transaction 308 provides a new state "S4" or "S5" that is possible for the next state transition starting from the state "S2". It should be noted that the set of state rules represented by the bytecode sequence of the locking script can be encoded as a switch statement or other conditional statement (e.g., "if-then-else") parameterized by the current state and one or more inputs.

[0113] In an embodiment, the bytecode sequence contained in the locking script of the transaction represents a set of state rules of the state machine, and the execution pointer and serialized state data of the locking script of the transaction represent the state of the state machine. In such an embodiment, the bytecode sequence of the locking script of the transaction is copied or copied to each consumption transaction that attempts to transfer control of the digital asset to the next transaction, and the next transaction must be linked to the current transaction. This process is repeated until the termination condition is met. Since the input data determined by the unlocking script of the execution consumption transaction is not fixed and can be uncertain data, the state of the state machine can be changed based on specific external inputs. Therefore, uncertain data provides input that may affect the next state.

[0114] Furthermore, the number of bytecode operations of the locking script to be executed upon confirming a drain transaction, which depends on the difference between the execution pointer of the current execution state of the bytecode sequence of the locking script as contained in the previous transaction and the execution pointer of the next execution state of the bytecode sequence of the locking script as contained in the drain transaction, can be designed to be changed by selecting or changing the execution pointer of the next execution state of the bytecode sequence of the locking script as contained in the drain transaction. In this way, the number of bytecode operations of the locking script to be executed upon confirming a drain transaction can be constrained or used to parameterize the constraints on the drain transaction (the drain transaction is a transaction that consumes the locking script). The parameterized constraints can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operations of the bytecode sequence of the smart contract), to logically divide the bytecode sequence of the smart contract into different segments executed on the drain transaction sequence, to calculate rewards for entities that create new transactions based on the parameterized constraints, or for other possible uses.

[0115] In the illustrative example, Alice borrowed some money from Bob, and Bob agreed to pay Alice back. The trustless deterministic state machine described above can be used to implement a smart contract that represents a payment from Bob to Alice. For example, the smart contract can be constructed so that Bob makes monthly payments to Alice for the next three months, and if a payment is missed, Bob's debt will enter the collection phase. Therefore, as long as Bob makes his monthly payments, the current state remains in the Repaid state. However, if an external entity provides an input indicating that Bob missed a payment, the state branches to the Missed Payment state. In the Missed Payment state, Alice can release the transaction and hand it over to the debt collector, whereupon the trustless deterministic state machine will switch to the Collection state. In the Collection state, the debt collector will collect the debt from Bob. Figure 2 and Figure 3 Such a smart contract can be created by using a variation of the script of the embodiment depicted in FIG.

[0116] In another example, Alice is a very charitable person who donates 1 unit of digital assets every month. Her rule is that anyone can claim digital assets, but only 1 unit per month. Alice creates a smart contract in the manner described in this disclosure and seeds the smart contract with an initial pool of 3 units of digital assets. Alice can construct a script that allows any entity to collect 1 unit of digital assets per month. The rest of the digital assets will be copied to subsequent smart contracts.

[0117] In other embodiments, the principles and operations of locking scripts described herein can be extended to support a wide variety of smart contracts using blockchain.

[0118] Table 2 below shows examples of unlocking scripts and locking scripts for implementing the trustless deterministic state machine of the present disclosure.

[0119] Table 2:

[0120]

[0121] FIG. 4A to FIG. 4C Together, a flowchart showing an exemplary operation is shown that executes an unlocking script of a consumption transaction as part of a smart contract and a locking script of a previous transaction. These operations can be part of the confirmation process of a consumption transaction. The consumption transaction includes a locking script having a bytecode sequence that implements a trustless deterministic state machine according to an embodiment of the present disclosure. The locking script also includes serialized state data representing the next execution state of the state machine and a next state execution pointer (or "next execution pointer"). The next execution pointer included as part of the locking script refers to the execution point of the bytecode sequence corresponding to the next execution state. The serialized state data included 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 consumption transaction.

[0122] Note that when creating a spending transaction, the serialized state data included as part of the locking script of the spending transaction can be determined by using the serialized state data of the locking script of the previous transaction to restore the current execution state of the state machine to generate or access the next execution pointer contained in the locking script of the spending transaction, 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 locking script of the previous transaction, and ends at a point (or operation) corresponding to the next execution pointer contained in the locking script of the spending transaction. Such execution may also use the input of the unlocking script of the spending transaction. It is contemplated that the creation of the spending transaction may include operations related to a wallet, a proxy node, or some other node of the blockchain network.

[0123] FIG. 4A to FIG. 4C Some or all of the operations of (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 may be implemented as executable instructions that are collectively executed on one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium).

[0124] For example, FIG. 4A to FIG. 4C Some or all of the operations of Figure 1 Such a validation node may include any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as Fig.13 computing device 2600).

[0125] FIG. 4A to FIG. 4C The operation of verifies whether the bytecode sequences of the locking scripts of the previous transaction and the consuming transaction are the same, obtains the current execution state from the previous transaction, obtains input by executing the unlocking script of the consuming transaction, determines a next execution state based at least in part on the interpretation of the bytecode sequence of the locking script, and verifies that the next execution state determined by executing the locking script matches the next execution state represented by the next state data included as part of the locking script of the consuming transaction. FIG. 4A to FIG. 4C Reflects variations of the example scripts found in Table 2. Assume that the locking script (e.g., scriptPubKey) of the previous transaction and the unlocking script (e.g., scriptSig) and locking script (e.g., scriptPubKey) of the consuming transaction are all stored in virtual memory, which can be implemented by one or more runtime data structures such as a stack, stack frame, or heap.

[0126] At 401, it is determined whether a termination condition is satisfied. In an embodiment, the termination condition may be a condition that, when satisfied, causes the state machine transition represented by the bytecode sequence of the locking script to end. If the termination condition is satisfied, the operation proceeds to 435, where further copying of the locking script is avoided, so that the copying of the locking script as part of the smart contract ends, and the operation proceeds to 427 and 429, as described below. If the termination condition is not satisfied, the operation proceeds to 403.

[0127] In 403, the bytecode sequence of the locking script of the previous transaction is retrieved from the virtual memory, and the bytecode sequence of the locking script of the consuming transaction is retrieved from the virtual memory, and the bytecode sequences of the two locking scripts are compared with each other to determine whether they match.

[0128] In 405 , it is determined whether the bytecode sequences of the two locking scripts compared in 403 match each other. If not, the operation proceeds to 433 , thereby determining that the consumption transaction is invalid. If they match, the operation proceeds to 407 .

[0129] At 407, an execution pointer for the current execution state of the bytecode sequence for the locking script is retrieved from virtual memory (as contained in the locking script of the previous transaction).

[0130] At 409, an execution pointer for the next execution state of the bytecode sequence for the lock script is retrieved from virtual memory (as contained in the lock script of the consuming transaction).

[0131] In 411, the current state data of the locking script is retrieved from the virtual memory (such as contained in the locking script of the previous transaction), and the execution state of the bytecode sequence of the locking script in the virtual memory is restored using the current state data of the locking script. For example, the current state data of the locking script can be extracted from the virtual memory in a serialized format, and then the current state data of the locking script can be deserialized into a stack format for restoring the stack data structure of the virtual memory that existed at the end of the previous execution of the bytecode sequence of the locking script (wherein the execution pointer is located at the current state execution pointer as contained in the locking script of the previous transaction).

[0132] At 413, a bytecode sequence of a locking script (such as contained in a locking script of a previous transaction) may be executed based on one or more inputs stored in the virtual memory. Execution of the bytecode sequence of the locking script begins at an execution pointer for a current execution state of the bytecode sequence of the locking script (such as retrieved at 407) and terminates at reaching an execution pointer for a next execution state of the bytecode sequence of the locking script (retrieved at 409). In an embodiment, the bytecodes of the bytecode sequence of the locking script are computer instructions, but not machine code (and therefore not tied to any specific CPU hardware), where these computer instructions are designed for efficient execution, including interpretation by a software interpreter that is part of a runtime system (e.g., a blockchain client) of a node that confirms a consuming transaction. 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 bytecode sequence for the locking script to the execution pointer of the next execution state of the bytecode sequence for the locking script) into machine code suitable for execution on the specific CPU hardware of the node, which confirms the consumption transaction as needed at runtime and executes the machine code on the specific CPU hardware. The execution of the software interpreter can convert the bytecode of the bytecode sequence segment into machine code one bytecode at a time (e.g., simple interpretation), or a just-in-time compilation method can be adopted, in which the bytecode sequence segment (or part thereof) is compiled into machine code as needed at runtime, and then the resulting machine code is executed. The resulting machine code can be cached and reused later without recompilation.

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

[0134] At 417, it is determined whether the resulting execution state stored in the virtual memory evaluates to true. In an embodiment, this check ensures that the operation of the unlocking script of the consumption transaction and the operation of the locking script of the previous transaction have been completed without error, and that any and all conditions encoded by the unlocking script of the consumption transaction and the locking script of the previous transaction have been satisfied. If not, the operation proceeds to 433, thereby determining that the consumption transaction is invalid. If so, the operation proceeds to 419.

[0135] The resulting execution state of the bytecode sequence of the locking script stored in the virtual memory (after reaching an execution pointer for the next execution state of the bytecode sequence of the locking script) is organized and stored as serialized state data representing the next execution state of the bytecode sequence of the locking script at 419. The serialized state data is stored in the virtual memory in a serialized format contained in a consumption transaction.

[0136] At 421, serialized state data representing a next execution state of the bytecode sequence of the locking script is retrieved from virtual memory.

[0137] At 423, the serialized state data representing the next execution state of the bytecode sequence of the locking script as determined at 419 is compared with the serialized state data representing the next execution state of the bytecode sequence of the locking script as included in the consumption transaction as retrieved from the virtual memory at 421 to determine whether the serialized state data matches.

[0138] In 425, it is determined whether the serialized state data matches. If not, the operation proceeds to 433, whereby it is determined that the consumption transaction is invalid. If it matches, the operation proceeds to 427 and 429.

[0139] In 427 and 429, the operation determines whether to meet one or more other conditions for the validity of the consumption transaction. Such conditions can include other constraints specified in the lock script or unlock script of the consumption transaction. If satisfied, the operation proceeds to 431, and the system of the subsequent execution confirmation process can be considered as valid for the consumption transaction. If not satisfied, the operation proceeds to 433, thus determining that the consumption transaction is invalid. It should be noted that one or more operations performed in 401 to 435 can be performed in various orders and combinations, including parallel execution.

[0140] It should also be noted that if the drain transaction is determined to be valid (e.g., in 431) and can be stored on the blockchain and in the case where the drain transaction is determined to be valid (e.g., in 431) and can be stored on the blockchain, the bytecode sequence of the locking script of the drain transaction can be copied to generate a "new" drain transaction. In this way, a portion of the "old" drain transaction is copied as a transaction that consumes the transaction. In this case, the input of the "new" drain transaction can reference this "old" drain transaction, and the output of the "new" drain transaction may include such a locking script, which includes a copy of the bytecode sequence of the locking script of this "old" drain transaction. As part of the confirmation process, the confirmation process of the "new" drain transaction may equate the "old" drain transaction with the previous transaction.

[0141] Furthermore, the number of bytecode operations of the locking script to be executed upon confirming a "new" drain transaction - which depends on the difference between the execution pointer of the current execution state of the locking script as contained in the "old" drain transaction and the execution pointer of the next execution state of the locking script as contained in the "new" drain transaction - can be designed to be changed by selecting or changing the execution pointer of the next execution state of the locking script contained in the "new" drain transaction. In this way, the number of bytecode operations of the locking script to be executed upon confirming a "new" drain transaction can be constrained or used to parameterize the constraints on the "new" drain transaction (the "new" drain transaction is the transaction that consumes the locking script). The parameterized constraints can be used to limit the number of bytecode operations executed between transactions (e.g., to avoid inefficient operation of the bytecode sequence of the smart contract), to logically divide the bytecode sequence of the smart contract into different segments executed on the drain transaction sequence, to calculate rewards for entities that create new transactions based on the parameterized constraints, or for other possible uses.

[0142] It should also be noted that in one or more embodiments as described above, for a given locking script, a consuming transaction is a transaction that references a locking script in one of its inputs, and a previous transaction is a transaction that contains a locking script referenced in one of the inputs of the consuming transaction. In addition, there can be as many previous transactions as inputs in the consuming transaction. In addition, the blockchain protocol may not allow the locking script to query its consuming transaction or one of its previous transactions. However, since a transaction is just data with certain properties, and a locking script simply encodes constraints on an unlocking script to contain certain data, these properties can be used to provide a locking script, resulting in the injection of consuming transactions and previous transactions into the unlocking script. This allows the locking script to constrain the consuming transaction (e.g., the consuming transaction must have one output) and also extract data from the previous transaction. It should be noted that the locking script cannot constrain the previous transaction because the previous transaction has been written to the blockchain. The combination of the two means that the locking script can extract data from the previous transaction and constrain the consuming transaction, but only if the locking scripts of the previous transaction and the consuming transaction contain the same bytecode sequence.

[0143] In addition, the bytecode sequence of the locking script and the unlocking script and the locking script themselves can be regarded as computer programs. In this way, the unlocking script and the locking script need to access the memory system of the CPU that executes the unlocking script and the locking script. In an embodiment, a part of the storage system (referred to as virtual memory in this article) can be allocated and managed to store the bytecode sequence and related data of the locking script and the unlocking script.

[0144] It should be noted that the bytecode interpreter of the locking script as described herein can be configured to support various bytecode operations as dictated by the design of the system. However, it is almost certain that a set of supported bytecode operations will allow interaction with virtual memory. There are a range of bytecodes for memory management. Some bytecodes are shown below:

[0145] OP_TOALTSTACK: Move the top item from the main stack to the top of the alternate stack

[0146] OP_FROMALTSTACK: Move the top item from the alternate stack to the top of the main stack

[0147] OP_SWAP: Swap the first two items on the stack

[0148] OP_PICK: Get a specific item in the stack and copy it to the top

[0149] OP_ROLL: Gets a specific item in the stack and places it on the top

[0150] Furthermore, in embodiments described herein, the bytecode sequence of a locking script may include high-level bytecode operations (or "virtual bytecode operations") that are interpreted as a corresponding sequence or combination of low-level bytecode operations supported by a software interpreter of a validation node's runtime system (e.g., a blockchain client). In this case, the bytecode sequence of a locking script is essentially a program within a program, much like how software runs on top of an operating system. In such embodiments, state data and execution pointers for a locking script may be maintained in two virtual stacks residing in virtual memory, such as Figure 5 As shown, these two virtual stacks are generally referred to as virtual main stack and virtual Alt stack, and can be stored as part of the main stack. It should be noted that the virtual main stack is located on top of the virtual Alt stack. In order to track 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 can store a set of items, the first is the stack height (not counting itself), and then the data. In this configuration, the state data and execution pointer of the locked script are effectively stored in two virtual memory data structures (virtual main stack and virtual Alt stack), which are embedded in another larger virtual memory data structure (main stack).

[0151] For example, Tables 3A and 3B show two high-level bytecode operations called VOP_SWAP and VOP_DROP. Figure 5 The virtual main stack and virtual alt stack work as follows.

[0152] Table 3A

[0153]

[0154] Table 3B

[0155]

[0156] It should be noted that the scripts for these two bytecode operations assume that any necessary error checking has been performed before executing the corresponding operation (eg, the height of the virtual main stack >= 2).

[0157] In embodiments described herein, the current execution state of the bytecode sequence of the locking script, such as contained in the previous transaction, is extracted or retrieved from the virtual memory for processing (e.g., see 411 as described above). Similarly, after executing the bytecode sequence of the locking script, the resulting execution state of the bytecode sequence of the locking script, such as stored in the virtual memory, is organized as serialized state data and compared with the serialized state data contained in the locking script of the consuming transaction (e.g., see 419, 421, and 423 as described above). In embodiments, the state data of the locking script has two formats: a first serialization format for embedding in a transaction; and a second format for "easy / direct" interpretation and manipulation in the virtual memory. In addition, changing from the first serialization format to the second format (which may be part of 411 as described above) may be referred to as deserialization, while changing from the second format to the first serialization format may be referred to as serialization (which may be part of 419 as described above). Figure 5 A second format is shown. Figure 6 A first serialization format is shown, in which the execution state data is represented by an ordered byte string, which includes the following:

[0158] - Stack Height field, which encodes the number of stack items in the byte string

[0159] - A number of stack items, each of which comprises a size field and a data field, wherein the size field indicates the number of bytes of the data field of the stack item.

[0160] Figure 7 The deserialization of a byte string representing the current execution state of a byte code sequence of a locking script as included in a previous transaction for storage in virtual memory in a manner to restore the current state of the byte code sequence of the locking script is shown (e.g., see 411 as described above). An example script is provided in Table 4 below, which deserializes a byte string representing the current execution state of a byte code sequence of a locking script as included in a previous transaction for storage in virtual memory in a manner to restore the current state of the byte code sequence of the locking script. Figure 5The byte string of the current state of the bytecode sequence of the locked script in the virtual main stack and the virtual alt stack is deserialized.

[0161] Table 4

[0162]

[0163]

[0164] Figure 8 The resulting execution state of the bytecode sequence of the locking script stored in virtual memory is shown as being serialized into a serialized byte string representing the next state data of the bytecode sequence of the locking script as contained in the consumption transaction (e.g., see 419 as described above). An example script is provided in Table 5 below, which converts the execution state of the bytecode sequence of the locking script stored in virtual memory into a serialized byte string representing the next state data of the bytecode sequence of the locking script as contained in the consumption transaction. Figure 5 The resulting execution state of the bytecode sequence of the locking script in the virtual main stack and the virtual Alt stack is serialized into a serialized byte string, which represents the next state data of the bytecode sequence of the locking script as included in the consumption transaction.

[0165] Table 5

[0166]

[0167] In an embodiment, the locking script copied on the sequence of the consumption transaction may include an interpreter code for interpreting the bytecode sequence of the locking script. The interpreter code may support the conversion of high-level bytecodes or commands that extend or supplement the low-level bytecode operations supported by the software interpreter of the runtime system (e.g., blockchain client) of the confirmation node. For example, the interpreter code may support the conversion of high-level bytecodes (or virtual bytecodes) into a corresponding sequence or combination of low-level bytecode operations supported by the software interpreter of the runtime system of the confirmation node. In this case, the interpreter code may support the conversion of the virtual bytecode operations VOP_SWAP and VOP_DROP of Tables 3A and 3B into op_code or commands that belong to the scripting language and are supported by the software interpreter of the runtime system of the confirmation node. In another example, the interpreter code may support the conversion of script bytecode operations written in a high-level programming language to be interpreted by the software interpreter of the runtime system of the confirmation 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 belonging to the scripting language and supported by the software interpreter of the runtime system of the confirming node.

[0168] Furthermore, in an embodiment, the confirmation process for each consumption transaction of a smart contract may include: extracting a bytecode sequence of a locking script from a previous transaction, extracting a bytecode sequence of a locking script from a consumption transaction, verifying whether the two extracted bytecode sequences match each other, extracting an interpreter code of a locking script from a previous transaction, extracting an interpreter code of a locking script from a consumption transaction, and verifying whether the two extracted interpreter codes match each other.

[0169] Fig. 9 An exemplary transaction according to an embodiment of the present disclosure is shown, which employs a locking script having a common bytecode sequence and a shared interpreter code to implement a trustless deterministic state machine. More specifically, the common bytecode sequence is a computer program that can be viewed as a state machine that embodies a set of state rules having a set of well-defined states, such that the bytecodes that execute the bytecode sequence (computer program) provide transitions between states of the state machine. The shared interpreter code supports interpretation of the bytecode sequence of the locking script.

[0170] like Fig. 9 As schematically shown in , the previous transaction 302' includes a locking script 304' having a bytecode sequence and an interpreter code, the bytecode sequence representing a set of state rules for a state machine 306', and the interpreter code supporting the interpretation of the bytecode sequence of the locking script 304'. The locking script 304' also includes serialized state data representing the current state within the state of the state machine 306' represented by the bytecode sequence of the locking script 304' and a current state execution pointer (or "current execution pointer"). In the example shown, the serialized state data and the current execution pointer of the locking script 304' represent the current state "S1", and the set of state rules of the state machine 306' represented by the bytecode sequence provide two possible states ("S2" or "S3") for the next state after the current state S1. The current execution pointer included as part of the locking script 304' refers to the execution point of the bytecode sequence corresponding to the current state (in this case, state "S1"). The serialized state data included as part of the lock script 304' represents the state of the state machine represented by the bytecode sequence at the execution point referenced by the current execution pointer included in the lock script 304'.

[0171] As from Fig. 9As can be seen in the example of , the consumption transaction 308' includes a locking script 312' having a bytecode sequence and an interpreter code, the bytecode sequence representing a set of state rules of a state machine 314', and the interpreter code supports the 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 serialized state data representing one of the possible next states after the current state S1 (in this case, state "S2") and a next state execution pointer (or "next execution pointer"). The next execution pointer included as part of the locking script 312' refers to the execution point of the bytecode sequence corresponding to the next state after the current state S1 (in this case, state "S2"). The serialized state data included as part of the lock 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 lock script 312'.

[0172] Note that when creating a consumption transaction, the serialized state data contained in the locking script 312' may be determined by restoring the current execution state of the bytecode sequence of the locking script using the serialized state data of the locking script 304' of the previous transaction to generate or access the next execution pointer contained in the locking script 312', 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 the input data 310' determined by executing the unlocking script of the consumption transaction 308'.

[0173] As part of confirming the spending transaction 308', the common bytecode sequence of the unlocking script and the locking script 304' / 312' of the spending transaction 308' is executed. The execution of the common bytecode sequence takes as input the input data 310' determined by executing the unlocking script of the spending transaction 308', as well as the current state "S1" represented by the serialized state data and the current execution pointer contained in the locking script 304' of the previous transaction 302' and the next execution pointer contained in the locking script 312' of the spending transaction 308', and calls 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 spending transaction 308'. Such interpretation determines the appropriate next state (e.g., the second state "S2") according to a set of state rules 314' represented by the bytecode sequence. The next state (e.g., state "S2") determined from the interpretation of the bytecode sequence to the point (or operation) corresponding to the next execution pointer contained in the locking script 312' of the consumption transaction 308' is organized as such serialized state data that follows the serialization format of the state data contained as part of the locking script 312' of the consumption transaction 308'. The serialized state data determined according to the execution of the common bytecode sequence is then verified for the serialized state data contained as part of the locking script 312' of the consumption transaction 308'. Again, rather than creating a different consumption transaction for each transaction, the execution of the locking script enforces that the execution state obtained by executing the bytecode sequence of the locking script during the confirmation of the consumption transaction matches the expected execution state of the locking script contained in the consumption transaction when the consumption transaction was created. If the two obtained execution states are the same, the locking script of the consumption transaction 308' is ensured to be valid.

[0174] Notice, Fig. 9 The example of 308' shows that the state of the state machine represented by the bytecode sequence of the locking script 312' of the consumption transaction 308' provides a new state "S4" or "S5", which is possible for the next state transition starting from the state "S2". It should be noted that the set of state rules represented by the bytecode sequence of the locking script can be encoded as a switch statement or other conditional statement (e.g., "if-then-else") parameterized by the current state and one or more inputs.

[0175] In an embodiment, the bytecode sequence included in the locking script of the transaction represents a set of state rules of the state machine, and the execution pointer and serialized state data included in the locking script of the transaction represent the state of the state machine. The locking script also includes an interpreter code for interpreting the bytecode sequence of the locking script. In such an embodiment, the bytecode sequence and the interpreter code of the locking script of the transaction are copied or copied to each consumption transaction that attempts to transfer the control of the digital asset to the next transaction, and the next transaction must be linked to the current transaction. This process is repeated until the termination condition is met. Because the input data determined by executing the unlocking script of the consumption transaction is not fixed and can be uncertain data, the state of the state machine can be changed based on specific external input. Therefore, uncertain data provides input that may affect the next state.

[0176] Furthermore, the number of bytecode operations of the locking script to be interpreted when confirming a drain transaction, which depends on the difference between the execution pointer of the current execution state of the bytecode sequence of the locking script as contained in the previous transaction and the execution pointer of the next execution state of the bytecode sequence of the locking script as contained in the drain transaction, can be designed to be changed by selecting or changing the execution pointer of the next execution state of the bytecode sequence of the locking script as contained in the drain transaction. In this way, the number of bytecode operations of the locking script to be interpreted when confirming a drain transaction can be constrained or used to parameterize the constraints on the drain transaction (the drain transaction is a transaction that consumes the locking script). The parameterized constraints 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 divide the bytecode sequence of the smart contract into different segments executed on the drain transaction sequence, to calculate rewards for entities that create new transactions based on the parameterized constraints, or for other possible uses.

[0177] Table 6 below shows an example of an unlocking script and a locking script for implementing the trustless deterministic state machine of the present disclosure.

[0178] Table 6:

[0179]

[0180] FIG. 10A to FIG. 10CTogether, a flowchart of an exemplary operation is shown, which executes an unlocking script of a consumption transaction as part of a smart contract and a locking script of a previous transaction. These operations can be part of the confirmation process of the consumption transaction. The consumption transaction includes a locking script having a bytecode sequence and an interpreter code, which implements a trustless deterministic state machine according to an embodiment of the present disclosure. The locking script also includes serialized state data representing the next execution state of the state machine and a next state execution pointer (or "next execution pointer"). The next execution pointer included as part of the locking script refers to the execution point of the bytecode sequence corresponding to the next execution state. The serialized state data included 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.

[0181] Note that when creating a spending transaction, the serialized state data included as part of the locking script of the spending transaction can be determined by using the serialized state data of the locking script of the previous transaction to restore the current execution state of the state machine to generate or access the next execution pointer contained in the locking script of the spending transaction, 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 and ends at a point (or operation) corresponding to the next execution pointer contained in the locking script of the spending transaction. Such execution may also use the input of the unlocking script of the spending transaction. It is contemplated that the creation of the spending transaction may include operations related to a wallet, a proxy node, or some other node of the blockchain network.

[0182] FIG. 10A to FIG. 10C Some or all of the operations of (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 may be implemented as executable instructions that are collectively executed on one or more processors. The executable instructions and / or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program permanently stored on a magnetic, optical, or flash memory medium).

[0183] For example, FIG. 10A to FIG. 10C Some or all of the operations of Figure 1 Such a validation node may include any suitable computing device (e.g., a server in a data center, a client computing device, multiple computing devices in a distributed system of a computing resource service provider, or any suitable electronic client device, such as Fig.13computing device 2600).

[0184] FIG. 10A to FIG. 10C The operation verifies whether the bytecode sequences and interpreter codes of the locking scripts of the previous transaction and the consuming transaction of the smart contract are the same, obtains the current execution state from the previous transaction, obtains input by executing the unlocking script of the consuming transaction, determines the next execution state based at least in part on the interpretation of the bytecode sequence of the locking script, and verifies whether the next execution state determined by executing the locking script of the consuming transaction matches the next execution state represented by the next state data included as part of the locking script of the consuming transaction. FIG. 10A to FIG. 10C The operations reflect variations of the example scripts found in Table 6. It is assumed that the locking script (e.g., scriptPubKey) of the previous transaction and the unlocking script (e.g., scriptSig) and unlocking script (e.g., scriptSig) of the consuming transaction are all stored in virtual memory, which can be implemented by one or more runtime data structures such as a stack, stack frame, or heap.

[0185] At 1001, it is determined whether a termination condition is satisfied. In an embodiment, the termination condition may be a condition that, when satisfied, causes the state machine transition represented by the bytecode sequence of the locking script to end. If the termination condition is satisfied, the operation proceeds to 1039, where further copying of the locking script is avoided, so that the copying of the locking script as part of the smart contract ends, and the operation proceeds to 1031 and 1033, as described below. If the termination condition is not satisfied, the operation proceeds to 1003.

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

[0187] In 1005, it is determined whether the bytecode sequences of the two locking scripts compared in 1003 match each other. If not, the operation proceeds to 1037, thereby determining that the consumption transaction is invalid. If they match, the operation proceeds to 1007.

[0188] In 1007, the interpreter code of the locking script of the previous transaction is retrieved from the virtual memory, and the interpreter code of the locking script of the consuming transaction is retrieved from the virtual memory, and the interpreter codes of the two locking scripts are compared with each other to determine whether they match.

[0189] In 1009, it is determined whether the interpreter codes of the two locking scripts compared in 1007 match each other. If not, the operation proceeds to 1037, thereby determining that the consumption transaction is invalid. If it matches, the operation proceeds to 1011.

[0190] At 1011, an execution pointer for the current execution state of the bytecode sequence for the locking script is retrieved from virtual memory (as contained in the locking script of the previous transaction).

[0191] At 1013, an execution pointer for the next execution state of the bytecode sequence for the lock script is retrieved from virtual memory (as contained in the lock script of the consuming transaction).

[0192] At 1015, the current state data of the locking script is retrieved from the virtual memory (such as contained in the locking script of the previous transaction), and the execution state of the bytecode sequence of the locking script in the virtual memory is restored using the current state data of the locking script. For example, the current state data of the locking script may be extracted from the virtual memory in a serialized format and then deserialized into a stack format for restoring the stack data structure of the virtual memory that existed at the end of the previous execution of the locking script (where the execution pointer was located at the current state execution pointer as contained in the locking script of the previous transaction).

[0193] In 1017, the interpreter code (which is included in the locking script of the previous transaction) may be called based on one or more inputs stored in the virtual memory to interpret the bytecode sequence of the locking script. The interpretation of the bytecode sequence of the locking script begins at the execution pointer for the current execution state of the locking script as retrieved in 1011, and terminates when the execution pointer for the next execution state of the locking script (retrieved in 1013) is reached. In an embodiment, the bytecodes of the bytecode sequence of the locking script are computer instructions designed to be interpreted by executing the interpreter code included in the previous transaction.

[0194] In an embodiment, the execution of the interpreter code converts the bytecode of the bytecode sequence of the locking script into operation codes or commands supported by the software interpreter of the runtime system (e.g., blockchain client) of the confirmation node, and the confirmation node converts these operation codes or commands into machine code executed on the CPU hardware of the confirmation node, such as Fig.11As shown. The execution of the interpreter code can support the conversion of high-level bytecodes or commands, which extend or supplement the commands of the low-level bytecode operations supported by the software interpreter of the runtime system of the confirmation node. For example, the interpreter code can support the conversion of virtual bytecodes, and the virtual bytecode represents the combination of bytecode operations supported by the software interpreter of the runtime system of the confirmation node. In this case, the interpreter code can support the conversion of the virtual bytecode operations OP_VSWAP and OP_VDROP of Table 4A and Table 4B to op_code or commands belonging to the script language and supported by the software interpreter of the runtime system of the confirmation node. In another example, the interpreter code can support the conversion of the script bytecode operations written in a high-level programming language to be interpreted by the software interpreter of the runtime system of the confirmation node. In this case, the interpreter code can support the conversion of the script bytecode operations written in a high-level programming language to op_code or commands belonging to the script language and supported by the software interpreter of the runtime system of the confirmation node. The execution of a software interpreter may convert the opcodes or commands into machine code one bytecode at a time (e.g., simple interpretation), or may employ a just-in-time compilation approach, in which bytecode sequence segments (or portions thereof) are compiled into machine code as needed at runtime, and the resulting machine code is then executed. The resulting machine code may be cached and reused later without recompilation.

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

[0196] At 1021, it is determined whether the resulting execution state stored in the virtual memory evaluates to true. In an embodiment, this check ensures that the operation of the unlocking script of the consuming transaction and the operation of the bytecode sequence of the locking script of the previous transaction have been completed without error, and that any and all conditions encoded by the unlocking script of the consuming transaction and the locking script of the previous transaction have been satisfied. If not, the operation proceeds to 1037, thereby determining that the consuming transaction is invalid. If so, the operation proceeds to 1023.

[0197] At 1023, the resulting execution state of the bytecode sequence of the locking script stored in the virtual memory (after reaching an execution pointer for the next execution state of the bytecode sequence of the locking script) is organized and stored as serialized state data representing the next execution state of the bytecode sequence of the locking script. The serialized state data is in a serialized format as contained in a consumption transaction.

[0198] At 1025, serialized state data representing a next execution state of the bytecode sequence of the locking script is retrieved from virtual memory.

[0199] At 1027, the serialized state data representing the next execution state of the bytecode sequence of the locking script as determined at 1023 is compared with the serialized state data representing the next execution state of the bytecode sequence of the locking script as included in the consumption transaction as retrieved from the virtual memory at 1025 to determine whether the serialized state data matches.

[0200] At 1029, it is determined whether the serialization state data matches. If so, the operation proceeds to 1031. If not, the operation proceeds to 1037, whereupon it is determined that the consumption transaction is invalid.

[0201] In 1031 and 1033, the operation determines whether one or more other conditions for the validity of the consumption transaction are met. Such conditions may include other constraints specified in the unlocking script of the previous transaction and the locking script of the consumption transaction. If met, the operation proceeds to 1035, and the system that subsequently performs the confirmation process can regard the consumption transaction as valid. If not met, the operation proceeds to 1037, thereby determining that the consumption transaction is invalid. It should be noted that one or more operations performed in 1001 to 1039 can be performed in various orders and combinations, including performing in parallel.

[0202] It should also be noted that if it is determined that the consumption transaction is valid (e.g., in 1035) and can be stored on the blockchain, the bytecode sequence of the locking script of the consumption transaction can be copied to generate a "new" consumption transaction. In this way, a portion of the "old" consumption transaction is copied as a transaction that consumes the transaction. In this case, the input of the "new" consumption transaction can reference this "old" consumption transaction, and the output of the "new" consumption transaction may include a locking script that embeds a copy of the bytecode sequence of the locking script of the "old" consumption transaction and shared interpreter code. As part of the confirmation process, the confirmation process of the "new" consumption transaction can equate the "old" consumption transaction to the previous transaction.

[0203] Furthermore, the number of bytecode operations of the locking script to be interpreted when confirming a "new" drain transaction - which depends on the difference between the execution pointer of the current execution state of the bytecode sequence of the locking script as contained in the "old" drain transaction and the execution pointer of the next execution state of the locking script as contained in the "new" drain transaction - can be designed to be changed by selecting or changing the execution pointer of the next execution state of the bytecode sequence of the locking script as contained in the "new" drain transaction. In this way, the number of bytecode operations of the locking script to be interpreted when confirming a "new" drain transaction can be constrained or used to parameterize the constraints on the "new" drain transaction (the "new" drain transaction is the transaction that consumes the locking script). The parameterized constraints can be used to limit the number of bytecode operations executed between transactions (for example, to avoid inefficient operation of the bytecode sequence of the smart contract), to logically divide the bytecode sequence of the smart contract into different segments executed on the drain transaction sequence, to calculate rewards for entities that create new transactions based on the parameterized constraints, or for other possible uses. It should also be noted that in one or more embodiments as described above, for a given locking script, a consuming transaction is a transaction that references a locking script in one of its inputs, and a previous transaction is a transaction that contains a locking script referenced in one of the inputs of the consuming transaction. In addition, there can be as many previous transactions as inputs in the consuming transaction. In addition, the blockchain protocol may not allow the locking script to query its consuming transaction or one of its previous transactions. However, since a transaction is just data with certain properties, and a locking script simply encodes constraints on an unlocking script to contain certain data, these properties can be used to provide a locking script, resulting in the injection of consuming transactions and previous transactions into the unlocking script. This allows the locking script to constrain the consuming transaction (e.g., the consuming transaction must have one output) and also extract data from the previous transaction. It should be noted that the locking script cannot constrain the previous transaction because the previous transaction has been written to the blockchain. The combination of the two means that the locking script can extract data from the previous transaction and constrain the consuming transaction, but only if the locking scripts of the previous transaction and the consuming transaction contain the same bytecode sequence.

[0204] In addition, the bytecode sequence of the locking script and the unlocking script and locking script themselves can be regarded as computer programs. Since the bytecode sequence is embedded in the locking script, the bytecode sequence is essentially a program in a program, just like the way software runs on an operating system. In this way, the unlocking script and the locking script need to access the memory system of the CPU that executes the unlocking script and the locking script. In an embodiment, a portion of the storage system (referred to as virtual memory in this article) can be allocated and managed to store the bytecode sequence and related data of the locking script and the unlocking script.

[0205] Fig. 12A Exemplary operations performed by executing interpreter code when interpreting a bytecode sequence contained in a locking script are shown. In one or more embodiments, both the interpreter code and the bytecode sequence are included as part of a locking script as described herein. Figure 5 The interpretation of the bytecode sequence may include: first restoring the virtual main stack and the virtual Alt stack from the current state of the locked script, and then interpreting a single bytecode starting from the execution pointer of the current state until the execution pointer of the next state is reached.

[0206] As part of interpreting the bytecode, the execution of the interpreter code can be used to get the next bytecode that needs to be interpreted. Table 7 below provides an operation code called OP_GETOP that performs this function. This operation code essentially takes the interpreted bytecode, extracts the current position from the previous transaction, and then returns the desired byte - in this example, the next bytecode - to the top of the stack.

[0207] Table 7

[0208]

[0209] Table 8 below is a script describing the execution of the interpreter code for interpreting the exemplary bytecode, specifically Fig. 12B The VOP_ADD bytecode is schematically shown in FIG.

[0210] Table 8

[0211]

[0212] It should be noted that in the context of describing the disclosed embodiments, unless otherwise specified, the use of expressions relating to the following executable instructions (also referred to as code, application, agent, etc.) means that the instructions are executed by a machine so that the machine performs specified operations: the executable instructions perform operations that the "instructions" do not normally perform independently (for example, transmission of data, calculation, etc.).

[0213] Fig.13 is an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, computing device 2600 can be used to implement any of the systems shown and described above. For example, computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Fig.13As shown, computing device 2600 may include one or more processors 2602, which may be configured to communicate with and operatively couple to a plurality of peripheral subsystems via bus subsystem 2604. Processor 2602 may be used to process unlocking scripts and locking scripts as part of confirming the consumption transactions described herein. These peripheral subsystems may include storage subsystem 2606 (including memory subsystem 2608 and file / disk storage subsystem 2610), one or more user interface input devices 2612, one or more user interface output devices 2614, and network interface subsystem 2616. Storage subsystem 2606 may be used for temporary or long-term storage of information, such as details associated with transactions described in the present disclosure.

[0214] The bus subsystem 2604 can provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as expected. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses. The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can be used as an interface for receiving data from other systems of the computing device 2600 and transmitting data to other systems of the computing device 2600. For example, the network interface subsystem 2616 can enable a data technician to connect the device to a wireless network, so that the data technician can send and receive data when in a remote location, such as a user data center. The bus subsystem 2604 can be used to transmit data such as details, search terms, etc. to the supervisory model of the present disclosure, and can be used to transmit the output of the supervisory model to one or more processors 2602 and to merchants and / or creditors via the network interface subsystem 2616.

[0215] The user interface input device 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 incorporated into a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, the 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. 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 cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projector or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate such interaction when a user interacts with an application program that performs the described processes and variations therein as appropriate.

[0216] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that may provide the functionality of at least one embodiment of the present disclosure. Application programs (programs, code modules, instructions) may provide the functionality of one or more embodiments of the present disclosure when executed by one or more processors and 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.

[0217] The memory subsystem 2608 may include a plurality of memories, including a main random access memory (RAM) 2618 for storing instructions and data during program execution, and a read-only memory (ROM) 2620 that may store fixed instructions. The file / disk storage subsystem 2610 may provide non-transitory permanent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive and associated removable media, a compact disk read-only memory (CD-ROM) drive, an optical drive, removable media cartridges, and other similar storage media.

[0218] The computing device 2600 may include at least one local clock 2624. The local clock 2624 may be a counter that indicates the number of ticks that have occurred since a specific start date, and may be integrally located within the computing device 2600. The local clock 2624 may be used to synchronize data transmissions in the processor of the computing device 2600 and all subsystems included in the computing device 2600 with specific clock pulses, and may be used to coordinate synchronization operations between the computing device 2600 and other systems in the data center. In one embodiment, the local clock 2624 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.

[0219] The computing device 2600 may be of various types, including a portable computer device, a tablet computer 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 a plurality of ports configured to receive fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, there is a need for Fig.13 The description of the computing device 2600 depicted in FIG. 2 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Fig.13 Many other configurations are possible with more or fewer components than the system depicted.

[0220] Therefore, the description and the drawings should be considered as illustrative rather than restrictive. However, it is obvious that various modifications and changes can be made thereto without departing from the scope of the invention. Similarly, other variations are also within the scope of the present disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, some of its illustrated embodiments are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the present invention to one or more specific forms disclosed, on the contrary, the present invention is intended to cover all modifications, alternative constructions and equivalent forms within the scope of the present invention defined in the appended claims.

[0221] Unless otherwise indicated or clearly contradictory to the context, the use of the terms "a", "an", "the" and similar references in the context of describing the disclosed embodiments should be interpreted as covering both the singular and the plural. Unless otherwise indicated, the terms "comprising", "having", "including" and "containing" should be interpreted as open terms (i.e., meaning "including but not limited to"), unless otherwise indicated. The term "connected" should be understood as partially or completely contained, attached or joined together when it is not modified and refers to a physical connection, even if there is some intervention. Unless otherwise indicated, the enumeration of numerical ranges in the present disclosure is intended only to be used as a shorthand method of referring to each individual value falling within the range, and each individual value is combined in the specification as if it were listed separately. Unless otherwise indicated or contradictory to the context, the use of the term "group" (e.g., "a group of items") or "subgroup" should be interpreted as a non-empty set including one or more members. Furthermore, unless otherwise specified or contradicted by context, the term "subgroup" of a corresponding group does not necessarily mean a proper subgroup of the corresponding group, but rather the subgroup and the corresponding group may be equivalent.

[0222] Unless expressly stated otherwise or clearly contradicted by context, conjunctions such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" are generally understood in context to indicate that an item, term, or the like may be A or B or C, or any non-empty subgroup of the group of A and B and C. For example, in the illustrative example of a group having three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following groups: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunction language is generally not intended to imply that certain embodiments require that at least one of A, at least one of B, and at least one of C each be present.

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

[0224] Unless otherwise required, the use of any and all examples or exemplary language (e.g., "such as") provided is intended only to better illustrate the embodiments of the present invention and is not intended to limit the scope of the present invention. No language in the specification should be construed as indicating any unclaimed element essential to the implementation of the present invention.

[0225] Embodiments of the present disclosure are described, including specific embodiments known to the inventor for carrying out the present invention. By reading the foregoing description, variations of the embodiments will become apparent to those of ordinary skill in the art. The inventor expects that skilled technicians will appropriately adopt such variations, and the inventor anticipates that the embodiments of the present disclosure may be practiced in a manner different from that specifically described. Therefore, the scope of the present disclosure includes all modifications and equivalents of the subject matter recorded in the appended claims as permitted by applicable law. Moreover, unless otherwise noted or clearly contradictory to the context, any combination of the above elements in all possible variations thereof is covered by the scope of the present disclosure.

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

[0227] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprising", "comprises", etc. do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprises" means "includes or consists of", and "comprising" means "including or consists of". The singular reference of an element does not exclude the plural reference of these elements, and vice versa. The present invention may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be implemented by the same item of hardware. The fact that certain measures are cited in mutually different dependent claims does not mean that a combination of these measures cannot be used advantageously.

Claims

1. A computer-implemented method comprising: receiving a drain blockchain transaction to transfer control of at least one digital asset or a portion thereof, wherein the drain transaction includes a locking script represented by a bytecode sequence, and wherein the drain transaction references a previous transaction including a locking script represented by the bytecode sequence, such that the first locking script and the second locking script share the same bytecode sequence; Confirming the spending transaction by verifying whether the bytecode sequence of the locking script of the spending transaction matches the bytecode sequence of the locking script of the previous transaction; wherein at least a portion of the consumption transaction is copied to generate a new consumption transaction until a termination condition is met; The bytecode sequence of the locking script is copied as part of the locking script of the consumption transaction in an ordered number of times until the termination condition is met.

2. The computer-implemented method of claim 1 , wherein: The previous transaction is stored on the blockchain, and / or the interpreter code supports converting at least one high-level bytecode operation into a low-level bytecode operation executed by the node.

3. A computer-implemented method according to any preceding claim, wherein: The locking script of the previous transaction and the locking script of the consuming transaction also include data related to different execution states of the bytecode sequence shared by the locking script of the previous transaction and the locking script of the consuming transaction, wherein these data are used to control the interpretation of the bytecode sequence when confirming the consuming transaction.

4. The computer-implemented method of claim 3, wherein: The locking script of the previous transaction further includes state data for a current execution state of the bytecode sequence of the locking script, and an execution pointer corresponding to the current execution state of the bytecode sequence of the locking script, wherein the locking script of the consumption transaction further includes state data for a next execution state of the bytecode sequence of the locking script, and an execution pointer corresponding to the next execution state of the bytecode sequence of the locking script, and confirming that the consumption transaction further includes: i) restoring the current state of execution of the bytecode sequence of the locking script using data representing the current state of execution of the bytecode sequence of the locking script, ii) executing the bytecode sequence of the locked script starting from the execution pointer corresponding to the current execution state of the bytecode sequence until the execution pointer corresponding to the next execution state of the bytecode sequence ends; and iii) comparing the state data resulting from the execution of the bytecode sequence of the locking script with the state data for the next execution state of the bytecode sequence of the locking script contained in the spending transaction to verify whether these state data match.

5. The computer-implemented method of claim 4, wherein: Confirming the consumption transaction also includes: extracting state data of the current execution state of the bytecode sequence for the locking script from the virtual memory, extracting an execution pointer corresponding to the current execution state of the bytecode sequence for the locking script from the virtual memory, and extracting an execution pointer corresponding to the next execution state of the bytecode sequence for the locking script from the virtual memory.

6. The computer-implemented method of claim 5, wherein: The virtual memory stores data related to different execution states of the bytecode sequence in different first and second formats, wherein the first format is used to store the data as part of a locking script, and wherein the second format is suitable for manipulating the data in the virtual memory when executing the bytecode sequence of the locking script.

7. The computer-implemented method of claim 6, wherein: The virtual memory includes at least one stack data structure, the first format includes a serialized byte format, and the second format includes a stack format.

8. The computer-implemented method of claim 7, further comprising: The state data for the current execution state of the bytecode sequence of the locking script is extracted from the virtual memory by deserializing data representing the current execution state of the bytecode sequence from the byte format into the stack format, and / or the state data generated by executing the bytecode sequence of the locking script is compared with the state data for the next execution state of the bytecode sequence of the locking script included in the consumption transaction by serializing the state data generated by executing the bytecode sequence of the locking script from the stack format into the byte format.

9. A computer-implemented method according to any preceding claim, wherein: As a result of executing the locking script, control of the at least one digital asset, or a portion thereof, is transferred, and the locking script imposes a set of conditions to confirm the spending transaction.

10. The computer-implemented method of claim 9, wherein: The consumption transaction also includes an unlocking script, wherein executing the unlocking script provides data for deriving a set of conditions for confirming the consumption transaction.

11. A computer-implemented method according to any preceding claim, wherein: The consumption transaction and the previous transaction embody part of the smart contract.

12. A system comprising: processor; as well as A memory comprising executable instructions, the execution of which by the processor causes the system to perform a computer-implemented method according to any one of claims 1 to 11.

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

Images