In-script functions within blockchain transactions

Abstract

A method of executing a transaction of a blockchain. The transaction includes at least one output, the at least one output includes a locking script, and the locking script includes an instance of a first opcode and one or more instances of a second opcode. Each instance of the second opcode delimits a portion of the locking script. Upon invocation of the instance of the first opcode, a first data element is read from at least one stack, the first data element generated during execution of the locking script using an unlocking script of a different transaction. A first portion of the locking script is output, the first portion following an instance of the second opcode corresponding to the first data element.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to implementing in-script composite functions using transactions of a blockchain. For example, a composite function can be used to create a loop in the script of a transaction. BACKGROUND

[0002] A blockchain refers to a form of distributed data structure wherein a duplicate copy of the blockchain is maintained at each node in a peer-to-peer (P2P) network. The blockchain comprises a chain of blocks, with each block comprising one or more transactions. Each transaction can reference a previous transaction in the sequence. Transactions can be included in a new block by submission to the network. The process of creation of a new block is referred to as “mining” and involves each of a plurality of mining nodes competing to perform “proof-of-work”, i.e. to solve a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Transactions in a blockchain are typically used to transfer a digital asset, i.e. data used as a means of value storage. However, it is also possible to make use of a blockchain to implement additional functionality layered on top of the blockchain. For example, a blockchain protocol can allow additional user data to be stored in a transaction output. Modern blockchains have an increasing maximum data capacity that can be stored in a single transaction, enabling more complex data to be incorporated. For example, this can be used to store electronic documents, or even audio or video data in a blockchain.

[0004] Each node in the network can have any one, two or all of the following three roles: forwarding, mining and storage. Forwarding nodes propagate transactions throughout the network of nodes. Mining nodes mine transactions into blocks. Storage nodes each store their own copy of the blockchain of mined blocks. In order for a transaction to be recorded in the blockchain, a party sends that transaction to one of the nodes in the network for propagation. Mining nodes that receive the transaction can compete to mine that transaction into a new block. Each node is configured to obey the same node protocol, which will include one or more conditions for validating a transaction as valid. Invalid transactions will not be propagated or mined into blocks. Assuming a transaction has been validated as valid, and is therefore accepted on the blockchain, then that transaction (including any user data) will thus continue to be stored at each of the nodes in the P2P network as an unalterable public record.

[0005] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying an amount of digital asset, sometimes referred to as a UTXO ("unspent transaction output"). The output can also include a locking script specifying conditions for redeeming the output. Each input includes a pointer to such an output in a previous transaction, and can also include an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, which will be referred to as a first transaction and a second (or "target") transaction. The first transaction includes at least one output specifying an amount of digital asset, and includes a locking script defining one or more conditions for unlocking the output. The second target transaction includes at least one input comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0006] In such a model, when the second target transaction is sent to the P2P network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to either of these conditions will not propagate the transaction, nor include the transaction for mining into a block to be recorded in the blockchain.

[0007] Another model of transaction is an account-based model. In this case, each transaction defines a transfer of an amount not by reference to a UTXO of a previous transaction in a sequence of past transactions, but by reference to an absolute account balance. The current state of all accounts is stored separately to the blockchain and is updated constantly.

[0008] Blockchain protocols can use a scripting language for transactions. A script is essentially a list of elements, which can be data or instructions. These instructions are referred to in the literature as script words, opcodes, commands or functions. An opcode (short for operation code) performs a predefined operation on data in the script.

[0009] One blockchain scripting language is a Forth-based two-stack implementation, but does not include any looping functionality. Forth uses two stacks, where the data stack is the primary stack and the return stack is the extra stack SUMMARY

[0010] One such opcode is OP_RETURN. In the original blockchain protocol, the purpose of OP_RETURN was to terminate execution of a script. It did not validate that the transaction containing the script was valid. However, when OP_RETURN was included in the input script of a transaction, this led to a fraudulent attack. Specifically, any input script of a transaction containing OP_RETURN could be used to unlock the output script of a previous transaction. Accordingly, a change was made to the protocol such that in the existing blockchain protocol, the opcode OP_RETURN indicates a provably unspendable transaction output, allowing data to be stored on the blockchain. In the existing protocol, the OP_RETURN opcode is used to terminate execution of a script while validating that the transaction is invalid. However, this results in a loss of functionality within the blockchain, because any transaction with OP_RETURN in its input script does not result in a "TRUE" (or valid) execution when run with any unlocking script.

[0011] Another opcode is OP_CODESEPARATOR (OCS). OCS is an "observable" opcode to the opcode OP_CHECKSIG, meaning that OP_CHECKSIG can locate where the next OCS is in the script. Typically, OP_CHECKSIG will check that a signature in the script is complete according to all the data after the last OCS executes.

[0012] According to one aspect disclosed herein, there is provided a method of executing a transaction of a blockchain, wherein the transaction comprises at least one output, the at least one output comprising a locking script, wherein the locking script comprises an instance of a first opcode and one or more instances of a second opcode, each instance of the second opcode separating parts of the locking script, and wherein the method comprises: upon invocation of the instance of the first opcode, reading a first data element from at least one stack, wherein the first data element is generated during execution of the locking script using an unlocking script of a different transaction; and outputting a first part of the locking script, the first part following an instance of the second opcode corresponding to the first data element.

[0013] Here, the first opcode has visibility of the second opcode, thereby allowing "selection" of parts of the locking script. In other words, parts of the script following a particular instance of the second opcode can be identified and output, for example, the parts to be executed. This can be used to enable in-script looping, by jumping from one part of the locking script to another, and so on.

[0014] The first opcode can be an OP_RETURN opcode. Here, the OP_RETURN function is redefined so that the purpose of this function is no longer to terminate execution of a script and validate that a transaction is invalid. Instead, OP_RETURN receives an identifier or instance of the second opcode and outputs the script that follows that instance of the second opcode. In some cases, OP_RETURN can be used to jump forward or backward to another part of the script, rather than executing the script from one end to the other. For example, some parts of the script can be executed multiple times, while other parts can not be executed at all or can be executed in a different order.

[0015] The second opcode can be the OP_CODESEPARATOR (OCS) opcode. OCS is placed between parts of a script, effectively separating the parts. OP_RETURN is able to locate instances of OCS in a script in order to output the script that follows a particular instance.

[0016] For brevity, the first opcode will be referred to hereafter as "OP_RETURN" or "terminating opcode", and the second opcode will be referred to as "OP_CODESEPARATOR" or "separator opcode". However, the present disclosure is not limited to opcodes with these specific labels. More generally, while embodiments will be described in terms of OP_RETURN according to the blockchain script language, the same teachings can be implemented by any opcode that, when called by a script engine (e.g., a script interpreter), reads a first data element from the stack and outputs a part of the script that follows an instance of a second opcode corresponding to that data element. Similarly, while embodiments will be described in terms of OP_CODESEPARATOR, the same teachings can be implemented by any opcode that separates parts of a script and is visible to the first opcode.

[0017] References to first and second instances of the first opcode should be interpreted as instances of the same type of opcode. Similarly, references to first and second instances of the second opcode should be interpreted as instances of the same type of opcode, the first opcode and the second opcode being different types of opcodes. BRIEF DESCRIPTION OF DRAWINGS

[0018] To assist in the understanding of embodiments of the present disclosure and how such embodiments can be implemented, reference will now be made, by way of example only, to the accompanying drawings in which:

[0019] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0020] Figure 2Some examples of transactions that can be recorded in a blockchain are shown schematically;

[0021] Figure 3 is a schematic block diagram of node software for performing transactions;

[0022] Figure 4 is an example of loop unrolling of a script-in script function for the input a = 105 and b = 28 in the Euclidean algorithm;

[0023] Figure 5 is an example of script-in elliptic curve point multiplication for the input 7, G. DETAILED DESCRIPTION

[0024] Figure 1 An example system 100 for implementing a blockchain 150 is shown. The system 100 comprises a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 comprises a computer device of a peer, different nodes 104 belonging to different peers. Each node 104 comprises processing apparatus comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, special-purpose application processors and / or field-programmable gate arrays (FPGAs). Each node also comprises memory, that is computer-readable memory in the form of a non-transitory computer-readable medium. The memory can comprise one or more memory units in the form of one or more memory media, for example magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or electrically erasable programmable read-only memory (EEPROM) and / or optical media such as optical disk drives.

[0025] The blockchain 150 comprises a series of data blocks 151, with a respective copy of the blockchain 150 being maintained at each of a plurality of nodes in a P2P network 160. Each block 151 in the blockchain comprises one or more transactions 152, where a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol being used as part of a transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common transaction protocol, each transaction 152 has a data structure comprising at least one input and at least one output. Each output specifies an amount representing a value of a digital asset belonging to the user 103 to whom the output is cryptographically locked (requiring a signature of that user to unlock, and thus to redeem or spend). Each input points to an output of a previous transaction 152, thereby linking the transactions.

[0026] At least some of the nodes 104 play the role of forwarding nodes 104F, which forward and thus propagate transactions 152. At least some of the nodes 104 play the role of storage nodes 104S (sometimes also called “full copy” nodes), each of which stores a respective copy of the same blockchain 150 in a respective memory. A given node 104 can be a forwarding node 104, a storage node 104S, or any combination thereof.

[0027] In a given current transaction 152j, the input (or each input) includes a pointer that references an output of a previous transaction 152i in the sequence of transactions, specifying that the output is to be redeemed or “spent” in the current transaction 152j. In general, the current transaction can be any transaction in the pool 154 or any block 151. Although to ensure that the current transaction is valid, the previous transaction 152i will need to exist and be verified for validity, the previous transaction 152i need not exist at the time the current transaction 152j is created or even sent to the network 106. Thus, “previous” refers herein to a predecessor in the logical sequence linked by the pointers, not necessarily the time of creation or sending in the temporal sequence, and thus does not necessarily exclude the possibility of out-of-order creation or sending of transactions 152i, 152j (see discussion below regarding orphan transactions). The previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0028] The input of the current transaction 152j also includes a signature of the user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 can have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for change). In some cases, a transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more previous transactions and redistribute to one or more outputs of the current transaction.

[0029] The above can be called an “output-based” transaction protocol, sometimes also called a protocol of unspent transaction outputs (UTXO) (where the outputs are called UTXOs). A user’s total balance is not defined by any one number stored in the blockchain; rather, a user needs a special “wallet” application 105 to collate all the UTXO values for that user, which are scattered among many different transactions 152 of the blockchain 151.

[0030] As part of the account-based transaction model, another type of transaction protocol can be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the amount of the transfer by reference to the UTXO of a previous transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored separately into the blockchain and is constantly updated. In such a system, transactions are ordered using the running transaction record of the account (also referred to as the "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0031] Regardless of the type of transaction protocol employed, when a user 103 wishes to perform a new transaction 152j, it wishes to send the new transaction from its computer terminal 102 to one of the nodes 104 of the P2P network 106 (nowadays typically a server or data center, but in principle it could be another user terminal). This node 104 checks whether the transaction is valid according to the node protocol applied at each of the nodes 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the overall transaction model. The node protocol typically requires the node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of an output-based, this can include checking whether the user cryptographic signature contained in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i spent by the new transaction, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i pointed to by the input of the new transaction. In some transaction protocols, the condition can be defined at least in part by a custom script contained in the input and / or output. Alternatively, this can be determined solely by the node protocol or can be determined by a combination thereof. Regardless of the way in which it is determined, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0032] In an output-based model, the definition of whether a given output (e.g., UTXO) is spent is that, according to the node protocol, it is validly redeemed by an input of another subsequent transaction 152j. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it seeks to spend or redeem has not already been spent / redemption by another valid transaction. Again, if invalid, the transaction 152j will not propagate or be recorded in the blockchain. This prevents double spending, i.e., a spender spending the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by keeping account balances. Because there is also a defined order of transactions, the account balances have a single defined state at any time.

[0033] The node 104M that solves the puzzle announces the solution of the puzzle on the network 106, provides the solution as proof, and then other nodes 104 in the network can easily check the solution (once given the solution of the hash value, it can be directly checked whether the solution makes the output of the hash value meet the condition). Based on the announced solution of the winner that has been checked at each such node, the transaction pool 154 for which the winner has solved the puzzle is then recorded in the blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. The block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, the block 151 cannot be modified because it is identified and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes an order on the blocks 151. Because the transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0034] It should be noted that different nodes 104M competing to solve the puzzle at any given time can do so according to different snapshots of the unmined transaction pool 154 at any given time, depending on when they start searching for a solution. The person who solves the respective puzzle first defines the transactions 152 contained in the new block 151n and updates the current unmined transaction pool 154. Then, the node 104M continues to compete to create a block from the newly defined unfinished pool 154, and so on. In addition, there is also a protocol for resolving any "forks" that can arise, where two nodes 104M solve the puzzle within a short time of each other, thereby propagating conflicting views of the blockchain. In short, the longest fork direction becomes the final blockchain 150.

[0035] Each forwarding node 104M and / or storage node 104S can take the form of a server or data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0036] The memory of each node 104 stores software configured to run on the processing device of the node 104 to perform its respective role and process transactions 152 in accordance with the node protocol. It will be appreciated that any action attributed herein to a node 104 can be performed by software running on the processing device of the respective computer device. The node software can be implemented in one or more applications at the application layer or at a lower layer such as the operating system layer or the protocol layer or any combination of these layers. Furthermore, the term “blockchain” used herein is a generic term of art and is not limited to any particular proprietary blockchain, protocol or service.

[0037] A computer device 102 of each of a plurality of parties 103 playing the role of consuming users is also connected to the network 101. They act as payers and payees in transactions but do not necessarily participate in mining or propagating transactions on behalf of other parties. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and their respective computer device 102a, and a second party 103b and their respective computer device 102b. It will be appreciated that more such parties 103 and their respective computer devices 102 can exist and participate in the system but are not illustrated for convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limited to Alice or Bob and any reference herein to Alice or Bob can be replaced with “first party” and “second party” respectively.

[0038] The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, for example one or more CPUs, graphics processing units (GPUs), other accelerator processors, application specific processors and / or FPGAs. The computer equipment 102 of each party 103 also comprises memory, that is computer-readable storage in the form of a non-transitory computer-readable medium. This memory can comprise one or more memory units employing one or more memory media, for example a magnetic medium such as hard disk; an electronic medium such as SSD, flash memory or EEPROM; and / or an optical medium such as Blu-ray discs. The memory on the computer equipment 102 of each party 103 stores software comprising respective instances of at least one client application 105 arranged to run on the processing apparatus. It will be appreciated that any action attributed to a given party 103 in this document can be performed by software running on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, for example a desktop or laptop computer, a tablet computer, a smartphone or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 can also comprise one or more other network resources, such as cloud computing resources accessed through the user terminal.

[0039] The client application 105 can initially be provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, for example by download from a server, or on a removable storage device such as a removable SSD, flash drive key, removable EEPROM, removable magnetic disk drive, floppy disk or magnetic tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0040] The client application 105 comprises at least a “wallet” function. This has two main functions. One of these functions is to enable the respective user party 103 to create, sign and send transactions 152 intended to propagate throughout the network of nodes 104 and thus to be included in the blockchain 150. The other function is to report to the respective party the amount of digital asset that it currently holds. In an output-based system, this second function comprises collating the amounts defined in the outputs of the various transactions 152 belonging to the relevant party that are scattered throughout the blockchain 150.

[0041] Note: While various client functionalities can be described as integrated into a given client application 105, this is not necessarily limiting, and instead, any of the client functionalities described herein can be implemented in a suite of two or more different applications, e.g., interfacing via APIs or one application as a plug-in to another. More colloquially, the client functionalities can be implemented at the application layer or a lower layer such as an operating system, or any combination of these. The following will be described in terms of client applications 105, but it should be understood that this is not limiting.

[0042] The instance of the client application or software 105 on each computer device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This can enable the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some or all of the storage nodes 104 to query the blockchain 150 for any transactions of the respective party 103 as recipient (or indeed inspect other parties’ transactions in the blockchain 150, as in embodiments the blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. Each node 104 runs software that is configured to validate transactions 152 as valid according to a node protocol, and in the case of forwarding nodes 104F, to forward transactions 152 for propagation of such transactions throughout the network 106. The transaction protocol and the node protocol correspond to each other, a given transaction protocol and a given node protocol together implementing a given transaction model. All transactions 152 in the blockchain 150 are in the same transaction protocol (although the transaction protocol can allow for different transaction subtypes within it). All nodes 104 in the network 106 are in the same node protocol (although it can distinguish between handling different transaction subtypes according to rules defined for that sub-type, and different nodes can also play different roles, implementing different corresponding aspects of the protocol).

[0043] As mentioned above, the blockchain 150 comprises a series of blocks 151, where each block 151 comprises a set of one or more transactions 152 created through a proof-of-work process as described earlier. Each block 151 also comprises a block pointer 155, which points to a previously created block 151 in the blockchain, to define the order of the blocks 151. The blockchain 150 also comprises a pool of valid transactions 154, which await inclusion in a new block through the proof-of-work process. Each transaction 152 comprises a pointer to a previous transaction, to define the order of the sequence of transactions (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to a genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 early in the blockchain 150 point to the genesis block 153, rather than a previous transaction.

[0044] When a given party 103 (say, Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which she is connected. This could be, for example, the forwarding node 104F to which Alice’s computer 102 has the best or most recent connection. When any given node 104 receives a new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to become “valid”, examples of which are discussed in more detail later. In some transaction protocols, the conditions for validity can be configured on a per-transaction basis by scripts included in the transaction 152. Alternatively, the conditions can simply be built-in functions of the node protocol, or defined by a combination of scripts and node protocol.

[0045] If the newly received transaction 152j passes the validity test (i.e. under the conditions for “valid”), any storing node 104S that receives the transaction 152j will add the new valid transaction 152 to the pool 154 in the copy of the blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives the transaction 152j will subsequently propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, and assuming the transaction 152j is valid, this means that the transaction will soon be propagated throughout the P2P network 106.

[0046] Once the pool 154 including the new transaction 152j has completed the proof-of-work, it becomes immutable as part of one of the blocks 151 in the blockchain 150. Each transaction 152 comprises a pointer to an earlier transaction, so the order of the transactions is also recorded immutably.

[0047] Different nodes 104 can first receive different instances of a given transaction, and thus have a conflicting view as to which instance is "valid" before one instance is mined into a block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts one instance as the valid instance, and then discovers that a second instance has been recorded in the blockchain 150, then the node 104 must accept this and will discard (i.e. treat as invalid) the unmined instance that it originally accepted.

[0048] Figure 2 An example transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the basic data structure of the blockchain 150 (each block 151 comprises one or more transactions 152). The following will be described by reference to an output-based or "UTXO"-based protocol. But this is not limited to all possible embodiments.

[0049] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 can comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO specifies a digital asset amount (a store of value). It can also contain the transaction ID of the source transaction and other information. The transaction data structure can also include a header 201 that can include size indicators for the input 202 and output 203 fields. The header 201 can also include an ID for the transaction. In embodiments, the transaction ID is a hash of the transaction data (without the transaction ID itself) and is stored in the header 201 of the original transaction 152.

[0050] Say Alice 103a wishes to create a transaction 152j that transfers a relevant digital asset amount to Bob 103b. In Figure 2 , Alice's new transaction 152j is labelled "Tx1". This new transaction takes a digital asset amount locked to Alice in the output 203 of a previous transaction 152i in the sequence, and transfers at least some of such amount to Bob. In Figure 2 , the previous transaction 152i is labelled "Tx0". Tx0 and Tx1 are arbitrary labels that do not necessarily imply that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to the next transaction in the pool 154. Tx1 can refer to any previous (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0051] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 can already be valid and included in the blockchain 150. It can at this point be included in one of the blocks 151, or it can still be in the pool 154 waiting to be included in a new block 151, in which case it will be shortly. Alternatively, Tx0 and Tx1 can be created and sent to the network 102 together; or Tx0 can even be sent after Tx1, if the node protocol allows for buffering of "orphan" transactions. The terms "previous" and "subsequent" used in the context of transaction sequences herein refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, and so on). They can equally be replaced by "predecessor" and "successor", "antecedent" and "descendant", or "parent" and "child", and so on. This does not necessarily refer to the order of their creation, sending to the network 106, or reaching any given node 104. However, a subsequent transaction (a descendant transaction or "child transaction") that points to a previous transaction (an antecedent transaction or "parent transaction") is not valid unless the parent transaction is valid. A child transaction that reaches a node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol, it can be discarded or buffered for a certain time, waiting for the parent transaction.

[0052] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labelled UTXO0. Each UTXO includes a value specifying the amount of digital asset that the UTXO represents, and a locking script defining a condition that must be met by an unlocking script in an input 202 of a subsequent transaction, in order for the subsequent transaction to be valid, and thus successfully redeem the UTXO. Typically, the locking script will lock the amount to a specific party (the beneficiary of the transaction of the amount). That is, the locking script defines an unlocking condition, which typically includes the condition that the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party that the previous transaction was locked to.

[0053] The locking script (also called scriptPubKey) is a piece of code written in a domain-specific language recognised by the node protocol. A specific example of such a language is called "Script" (S capital). The locking script specifies the information required to spend the transaction output 203, for example the requirement for Alice's signature. The unlocking script appears in the output of a transaction. The unlocking script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of a transaction.

[0054] So in the example shown, the UTXO0 in the output 203 of Tx0 includes a locking script [Checksig P A ], which requires Alice's signature Sig P Ato redeem UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem UTXO0 valid). [Checksig P A ] contains the public key P of Alice's public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (for example, by its transaction ID (TxID0), which in embodiments is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it amongst any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A >, which includes Alice's cryptographic signature, created by Alice applying the private key of her key pair to a predetermined piece of data (sometimes referred to in cryptography as a "message"). Alice needs to sign to provide the data (or "message") for which the signature is valid can be defined by the locking script, the node protocol, or a combination thereof.

[0055] When the new transaction Tx1 arrives at a node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together, to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions can include one or more criteria). In embodiments, this involves concatenating the two scripts:

[0056] <Sig P A ><P A >||[Checksig P A ]

[0057] where "||" denotes concatenation, "<...>" denotes putting data on the stack, and "[...]" denotes a function (in this example, a stack-based language) composed of the unlocking script. Again, the scripts can be run one after the other using a common stack, rather than concatenating the scripts. Whichever approach is taken, when run together, the scripts use Alice's public key P A (included in the locking script of the output of Tx0) to authenticate the signature when the locking script in the input of Tx1 includes the piece of data that Alice's signature was intended for. The intended piece of data itself ("message") also needs to be included in Tx0 in order to perform this authentication. In embodiments, the signed data includes the entire Tx0 (so there is no need to include a separate element to specify the piece of signed data in cleartext, as it is already present).

[0058] The skilled person will be familiar with the details of authentication by public-private cryptography. Essentially, if Alice has signed a message by encrypting it using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), another entity such as a node 104 can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value and labelling this to the plaintext version of the message as the signature, enabling any holder of the public key to authenticate the signature. It will therefore be noted that in embodiments, any reference herein to signing a particular piece of data or part of a transaction etc. can mean signing a hash value of that piece of data or part of a transaction.

[0059] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the illustrated example, if Alice's signature is provided in Tx1 and authenticated), then the node 104 considers Tx1 valid. If it is a storage node 104S, this means it will add to the pool of transactions 154 awaiting proof-of-work. If it is a forwarding node 104F, it will forward the transaction Tx1 to one or more other nodes 104 in the network 106, so that it will propagate throughout the network. Once Tx1 is valid and included in the blockchain 150, this defines UTXO0 in Tx0 as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. The node 104 therefore also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been spent (has formed a valid input to another valid transaction). This is one of the reasons why the defined order imposed by the blockchain 150 on transactions 152 is important. In practice, a given node 104 can maintain a separate database marking UTXOs 203 of transactions 152 that have been spent, but ultimately whether a UTXO has been spent depends on whether a valid input to another valid transaction has been formed in the blockchain 150.

[0060] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, then this is another ground for invalidity in most transaction models. Such a transaction will therefore not propagate or be mined into a block 151.

[0061] Note that in the UTXO-based transaction model, a given UTXO needs to be spent as a whole. It is not possible to "leave behind" the part of the amount defined in the UTXO as spent, while spending another part. But the amount of the UTXO can be split between multiple outputs of the next transaction. For example, the amount defined in UTXOo of Txo can be split between multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all the amount defined in UTXOo, she can use the remainder to find change in a second output of Tx1, or to pay another party.

[0062] Alice's and Bob's digital assets consist of the unspent UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No one location in the blockchain 150 stores a number defining the total balance of a given party 103. The role of the wallet functionality of the client application 105 is to collate together the values of various UTXOs locked to the respective party and not yet spent in other subsequent transactions. This can be achieved by querying the copy of the blockchain 150 stored at any storage node 104S, e.g. the one that is closest or best connected to the computer device 102 of the respective party.

[0063] Note that script code is often represented in a schematic way (i.e. in non-precise language). For example, the script code [Checksig P A ] can be written as [Checksig P A ] = OP DUP OP HASH160 < H(P A ) > OP EQUALVERIFY OP CHECKSIG. "OP_..." refers to a specific opcode of the script language. OP CHECKSIG (also known as "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, the signature ('sig') is removed from any occurrence in the script, but the additional requirement that it is verified in the transaction by the'sig' input remains. As another example, OP_RETURN is a script language opcode that creates an unspendable output of a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain 150. For example, the metadata can include a file that needs to be stored in the blockchain.

[0064] signature P Ais a digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In embodiments, for a given transaction, the signature will sign the partial transaction input as well as all or part of the transaction output. The particular part of the output that is signed depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature that selects which output is signed (and thus fixed at the time of signing).

[0065] The locking script, sometimes called "scriptPubKey", refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. The unlocking script, sometimes called "scriptSig", refers to the fact that it provides the corresponding signature. But more generally, in all applications of the blockchain 150, the condition for UTXO redemption does not necessarily include authenticating a signature. More generally, the scripting language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" can be preferred.

[0066] Some blockchain protocols use a scripting language that includes two types of elements: data and operation codes. Data within a script can be, for example, numbers, public keys, signatures, hash values, and so on. Operation codes are functions that perform operations on data within the script. In the scripting language, the script runs from one end to the other (typically left to right) and uses a data structure called a "stack". Data is always pushed onto the stack (i.e. placed on the stack). Operation codes can pop data off the stack (i.e. take data off the stack), perform an operation on the data, and then optionally push new data onto the stack. The scripting language commonly used in many blockchains is called Script. The following will be described in terms of the operation codes of Script.

[0067] Those skilled in the art will be familiar with stack-based scripting languages. The following example illustrates an example implementation of a script. In particular, the following illustrates an example verification and unlocking process.

[0068] An example script can include <Bob's signature> <Bob's public key> OP_DUP OP_HASH OP_EQUALVERIFY OP_CHECKSIG. This script operates from left to right.

[0069] Step 1 : Push <Bob's signature> onto the stack

[0070] <BOB'S SIGNATURE>

[0071] Step 2: Push <Bob's public key> onto the stack (this is now the top element on the stack)

[0072] bob's public key <BOB'S SIGNATURE>

[0073] Step 3: The OP_DUP opcode performs an operation on the top element on the stack to duplicate <bob's public key>.

[0074] bob's public key bob's public key <Bob's signature>

[0075] Step 4: The OP_HASH opcode pops and runs <bob's public key> through a hashing algorithm (followed by one or more optional operations) to obtain <bob's public address> and places it onto the stack.

[0076] <bob's public address> bob's public key <BOB'S SIGNATURE>

[0077] Step 5: Push <bob's public address> onto the stack (this is now the top element on the stack)

[0078] <bob's public address> <bob's public address> bob's public key <BOB'S SIGNATURE>

[0079] Step 6: The OP_EQUALVERIFY opcode pops the last two elements from the stack (<bob's public address> and <bob's public address>) and checks that the two addresses are the same. If they are not the same, the execution is considered to have failed. If the condition is TRUE, the next command is executed.

[0080] bob's public key <BOB'S SIGNATURE>

[0081] Step 7: The OP_CHECKSIG opcode pops <bob's public key> and <bob's signature> and checks their validity. Once this process is complete, Bob can unlock the transaction and access the specified amount of digital assets.

[0082] TRUE

[0083] In-Script Functions

[0084] Embodiments of the present invention provide for implementing in-script composite functions within blockchain transactions. This is achieved by redefining the OP_RETURN function (or, alternatively, configuring the opcode to perform the functions attributed to OP_RETURN below).

[0085] Figure 3An example of node software 300 that can run on each node 104 of a blockchain network 106 is shown, in examples of UTXO-based or output-based models. Node software 300 includes components such as a script engine 301, a stack 302, and an application-level decision engine 303. The script engine 301 may include a script interpreter configured to execute the script by interpreting portions of the script as data elements or functions for manipulating these data elements and / or pushing or reading data elements from the stack 302. Alternatively, the script engine 301 may employ another form of execution, such as Just-In-Time (JIT) compilation. Generally, the term “execution” as used herein is used in the broadest sense of running a script in any way (rather than the narrow sense of executing compiled machine code instructions). Therefore, “execution” can include interpretation within the current context. Furthermore, it should be noted that “opcode” in the current context does not refer to the opcode of a single machine code instruction, but rather to higher-level commands mapped by the script engine 301 at each node 104 to corresponding predefined functions.

[0086] Although not shown, the node software may also include a protocol engine and a collection of one or more blockchain-related functional modules. At any given node 104, these modules may include any one, two, or all of the following three modules: a mining module, a forwarding module, and a storage module (depending on one or more roles of the node). The protocol engine is configured to identify different fields of transaction 152 and process such fields according to the node protocol. When transaction 152m(Tx) is received... m ) has a pointer to another previous transaction 152m-1(Tx m-1 When the output (e.g., UTXO) is input to the protocol engine, the protocol engine identifies Tx. m The unlock script is then passed to the script engine 401. The protocol engine is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 in blockchain 150 stored on the corresponding node or another node 104. Regardless of the method used, the protocol engine will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 301.

[0087] Therefore, script engine 301 has Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example,Figure 4 Tx1 and Tx2 shown in the middle, but can equally apply to any transaction pair, such as Tx0 and Tx1, etc. As previously mentioned, the script engine 301 runs two scripts simultaneously, which will include placing data onto and retrieving data from the stack 302 in accordance with the stack-based scripting language (e.g. Script) being used.

[0088] As Figure 3 illustrated, the locking script of Tx1 includes one or more OCS opcodes (two in this example) and at least one OP_RETURN. The script engine 301 is configured to use the data element at the top of the stack 402 when calling OP_RETURN and interpret that data element as a reference to one of the OCS opcodes included in the locking script of Tx1. The script engine 301 is further configured to execute the portion of the locking script that follows the referenced OCS opcode, for example by replacing the unexecuted portion of the locking script with the portion of the locking script that follows the referenced OCS opcode.

[0089] As mentioned above, when a transaction is executed (e.g. validated), the locking script of that transaction is executed together with the unlocking script of a previous transaction. The transaction can include more than one locking script. At least one of these locking scripts includes one or more instances of OP_RETURN and OP_CODESEPARATOR (OCS). Each instance of OCS separates portions of the locking script. For example, there can be two OCS opcodes to separate three portions of the locking script. Unless context requires otherwise, first, second, third, etc. are merely labels to distinguish between different items in the same (e.g. OCS, OP_RETURN, portion, etc.).

[0090] As part of transaction validation, if the locking script is executed and the locking script includes OP_RETURN, a data element is read from one of the stacks (e.g., Main stack or ALT stack) when OP_RETURN is invoked. Data elements can be read from both stacks and combined (e.g., summed) to form a single data element. For example, the data element is generated during execution of the locking script up until the point of invoking OP_RETURN. The data element can be a number or other type of variable that is used to output a first portion of the locking script that follows the OCS corresponding to that data element. In other words, the data element is interpreted as an index (or address) for a particular OCS. In this document, the first portion of the locking script does not necessarily mean the very first portion of the locking script. In this document, first is used as a label to refer to a portion of the locking script - which can or can not be the very first portion, depending on the data element read from the stack. For example, if there are three OCS opcodes in the locking script, they can be indexed using the numbers 1, 2, and 3. If the data element corresponds to the second OCS in the script, the portion of the locking script that follows the second OCS is output. The portion of the locking script can be added to a script template, added to a set of instructions to be executed, and / or executed, for example.

[0091] Then, when the first portion of the locking script is executed, if the first portion of the locking script includes an instance of OP_RETURN, a data element can be read from the stack and used as an address for an OCS when the instance of OP_RETURN is invoked. Depending on the data element read from the stack, the same OCS or a different OCS can be referenced. A portion of the locking script (referred to as a second portion) that follows the referenced OCS is output. Following the example above, if the data element corresponds to the first OCS in the script, the portion of the locking script that follows the first OCS is output. Alternatively, the data element can correspond to the second or third OCS, in which case the portion of the locking script output by the output would follow the second or third OCS, respectively. If the contents of the locking script are selected accordingly, an infinite loop can be created, for example, by repeatedly referencing the same set of OCS opcodes.

[0092] In some embodiments, in the locking script, each OP_RETURN is preceded by an opcode that, when invoked, pushes a data element to the top of the stack. For example, each opcode preceding an OP_RETURN can push a data element corresponding to one of the OCS opcodes to the stack.

[0093] The script of a transaction can be read, executed, interpreted, etc. by a script engine (e.g., a script interpreter). Before executing the locking script, the script engine can scan the locking script for any instances of OP_RETURN. If the locking script does contain at least one instance of OP_RETURN, the script engine can create a sub-script that starts with the first OCS in the locking script and ends with the end of the locking script. This sub-script can be stored in memory. When OP_RETURN is invoked, the data element in the stack is used, e.g., the top element in the Main stack. If the data element is not a positive integer and / or is greater than the total number of OCS opcodes in the sub-script, execution can end. If the data element is a positive integer and is less than or equal to the total number of OCS opcodes in the sub-script, the portion of the locking script that follows the OCS corresponding to the data element is output. For example, the portion of the sub-script that follows the nth OCS is used to replace the portion of the script that has not been executed (i.e., the portion of the locking script that follows OP_RETURN), where n is the data element used by OP_RETURN.

[0094] When the script is executed, the main script and the sub-script can be saved in memory. The main script is the script to be executed on the stack. The sub-script is static and serves as a reference script— portions of the sub-script will be read and copied. The sub-script includes the entirety of the locking script that follows the initial OCS in the locking script. The main script is dynamic and not only used during execution, but can also be overwritten by a portion of the sub-script via OP_RETURN during execution. For example, each time OP_RETURN is invoked, the portion of the sub-script that follows the OCS corresponding to the data element used (i.e., the original locking script that forms a portion of the sub-script) is used to replace the main script.

[0095] Use Cases

[0096] Figure 4 An example script-in-function execution is shown. This example function performs the Euclidean algorithm. The Euclidean algorithm takes two inputs (a, b) and outputs the greatest common divisor (GCD) of a and b. For simplicity, assume a > b.

[0097] In this example, inputs a and b are 105 and 28, respectively. On the stack, the number 105 will be below the number 28. The output will be GCD(105, 28). The script to execute is: OCS OP_TUCK OP_MOD OP_DUP OP_IF OP_1 OP_RETURN OP_ENDIF OP_DROP. As can be seen, the script includes a single OCS and a single OP_RETURN. OP_RETURN follows OP_1, which pushes the value 1 to the stack. Upon invocation of OP_RETURN, the value 1 will be read and used to execute the portion of the script that follows the corresponding OCS. Now, since OCS is the first opcode in the script, this is equivalent to repeating the script.

[0098] As shown in Figure 4 the output is 7, i.e., GCD 105 and 28. Upon execution, the script can loop one or more times (in this example, one time). In other words, 18 opcodes are invoked to compute the greatest common divisor of 105 and 28. However, it takes only 9 opcodes to construct the script. One advantage of this is that a larger composite script can be implemented from a smaller script included in a transaction.

[0099] Figure 5 An example execution of another example script-in-function is shown. This example function performs elliptic curve point multiplication. The input to the function is (a, G), where a is a scalar and G is a generator point. In this example, a is 7. The output of the function is a G.

[0100] The script to execute is as follows:

[0101]

[0102]

[0103] In this script, there are three instances of the OCS opcode (OCS_1, OCS_2, OCS_3), each of which separates different portions of the script. There are four instances of OP_RETURN, each of which is preceded by an opcode that pushes to the stack a data element that corresponds to one of the OCS opcodes. In this example, each OP_RETURN follows an opcode that represents a number. Whenever OP_RETURN is encountered, the first element on the stack is used, and a new set of opcodes is copied to the script board for execution. Figure 5 The evolution of the stack (including data elements) and the script board (including opcodes) prior to the OP_RETURN instance is shown.

[0104] For example, if "OP_DUP[POINT_ADD] OP_2 OP_RETURN" is executed, OP_RETURN will use the data element "2" in the stack and continue the script following OP_2.

[0105] The script works as follows:

[0106] 1) Push 0 onto the ALT stack. This 0 helps identify when the bottom of the ALT stack is reached.

[0107] 2) There are two inputs (a, G). Check if a > 1.

[0108] a. If yes, continue with point doubling.

[0109] b. If no, start with point addition.

[0110] 3) In the case of point doubling, first push 1 onto the stack. This 1 acts as a counter for the number of times the point is doubled. Compare the counter to a. Make a copy of G, which is used later.

[0111] a. If the value of the counter is greater than a, halve the value of the counter and subtract this value from a. This creates a new value of a that is smaller than the original value.

[0112] b. At the same time, push the result of the doubling onto the ALT stack. After that, push 1 onto the ALT stack to indicate that there is a value to be taken from the ALT stack.

[0113] c. Then, use OP_RETURN to execute step 2 with the new value of a.

[0114] 4) In the case where doubling cannot continue, check if a = 1 or a = 0.

[0115] a. If a = 1, take each element on the ALT stack one by one and perform point addition until the bottom of the stack is reached.

[0116] b. If a = 0, first discard G, then take one result from the ALT stack, and then return to the above step "a."

[0117] It should be noted that point addition is defined by [POINT_ADD] and point doubling is defined by OP_DUP[POINT_ADD]([POINT_DOUBLE]) as an abbreviation for a large number of opcodes. [POINT_ADD] uses the first two elements on the stack, P1 and P2, and pushes P1 and P2 points onto the stack. [POINT_DOUBLE] uses the first element on the stack, P, and pushes 2P points onto the stack.

[0118] It will be appreciated that the above embodiments are described by way of example only. For clarity, embodiments are not limited to operation codes having a particular "name". Rather, embodiments are limited only to operation codes having a particular function. For brevity, the terms "OP_RETURN" and "OP_CODESEPARATOR" are used.

[0119] According to a first embodiment of the teachings disclosed herein, there is provided a computer-implemented method of executing a transaction of a blockchain, wherein the transaction comprises at least one output, the at least one output comprising a locking script, wherein the locking script comprises an instance of a first operation code and one or more instances of a second operation code, each instance of the second operation code separating parts of the locking script, and wherein the method comprises: upon invocation of the instance of the first operation code, reading a first data element from at least one stack, wherein the first data element is generated during execution of the locking script using a unlocking script of a different transaction; outputting a first part of the locking script, the first part following an instance of the second operation code corresponding to the first data element.

[0120] The first operation code can be a terminating operation code. The second operation code can be a separator operation code.

[0121] According to a second optional embodiment, there can be provided a method according to the first embodiment, wherein the outputting can comprise at least executing some content of the first part of the locking script.

[0122] According to a third optional embodiment, there can be provided a method according to the first or second embodiment, wherein the method can comprise creating a sub-script, the sub-script starting from a first instance of the second operation code and following by the remainder of the locking script to be executed after the first instance of the second operation code, wherein the first part of the locking script is a first part of the sub-script.

[0123] According to a fourth optional embodiment, there can be provided a method according to any of the first to third embodiments, wherein the locking script and the sub-script can be stored in a memory of a node, and wherein the outputting can comprise replacing an unexecuted part of the locking script with the first part of the sub-script in the memory.

[0124] According to a fifth optional embodiment, there can be provided a method according to the third or fourth embodiment, the method can comprise, prior to executing the locking script, scanning the locking script for any instances of the first operation code; and if the locking script comprises any instances of the operation code, creating the sub-script.

[0125] According to a sixth optional embodiment, there can be provided a method according to any one of the first to fifth embodiments, wherein the method can comprise interpreting the first data element as an address of the instance of the second opcode.

[0126] According to a seventh optional embodiment, there can be provided a method according to any one of the first to sixth embodiments, wherein the method can comprise terminating execution of the locking script in at least one of the following cases: the first data element is not a positive integer; and the first data element is greater than a total number of instances of the second opcode.

[0127] According to an eighth optional embodiment, there can be provided a method according to any one of the first to seventh embodiments, wherein the first part of the locking script can comprise a second instance of the first opcode, and wherein the method can comprise, upon invocation of the second instance of the first opcode, reading a second data element from at least one stack, wherein the second data element is generated during execution of the first part of the locking script; and outputting a second part of the locking script, which second part follows an instance of the second opcode corresponding to the second data element.

[0128] According to a ninth optional embodiment, there can be provided a method according to the eighth embodiment, wherein the outputting the second part of the locking script can comprise at least executing some of the second part of the locking script.

[0129] According to a tenth optional embodiment, there can be provided a method according to any one of the first to ninth embodiments depending on the fourth embodiment, wherein the second part of the locking script can be a second part of the sub-script, and wherein the method can comprise replacing an unexecuted part of the first part of the locking script with the second part of the sub-script in the memory.

[0130] According to an eleventh embodiment of the teachings disclosed herein, there is provided a computer program, embodied on a computer-readable storage medium and configured so as when run on a node of a blockchain network to perform a method according to any one of the first to tenth embodiments.

[0131] According to a twelfth embodiment of the teachings disclosed herein, there is provided a computing device comprising: a memory comprising one or more memory units; a processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus, to perform the method according to any one of the first to tenth embodiments.

[0132] Other variations or uses of the disclosed technology can become apparent from the disclosure herein. The scope of the disclosure is not limited to the described embodiments, but only to the claims appended hereto.

Claims

1. A computer-implemented method for executing blockchain transactions, wherein, The transaction includes at least one output, the at least one output including a locking script, wherein the locking script includes instances of a first opcode and one or more instances of a second opcode, each instance of the second opcode separating portions of the locking script, and wherein the method is executed by blockchain nodes of a blockchain network, and the method includes: During the execution of the locking script by the blockchain node, when the instance of the first opcode is invoked, a first data element is read from at least one stack, wherein the first data element is generated during the execution of the locking script using an unlocking script with different transactions; and The first part of the locking script is output, following the instance of the second opcode corresponding to the first data element.

2. The method according to claim 1, wherein, The output includes at least some of the first part of the locking script.

3. The method according to claim 1 or 2, wherein the method comprises: A subscript is created, which begins with a first instance of the second opcode and is followed by the remainder of the locking script that will be executed after the first instance of the second opcode, wherein the first part of the locking script is the first part of the subscript.

4. The method according to claim 3, wherein, The locking script and the sub-script are stored in the node's memory, and the output includes replacing the unexecuted portion of the locking script with the first portion of the sub-script in the memory.

5. The method according to claim 3, wherein the method comprises: Before executing the locking script, the locking script is scanned to find any instances of the first opcode; and If the locking script includes any instance of the opcode, then the sub-script is created.

6. The method of claim 1, wherein the method includes interpreting the first data element as the address of the instance of the second opcode.

7. The method of claim 1, wherein the method includes terminating the execution of the locking script in at least one of the following circumstances: The first data element is not a positive integer; The total number of instances where the first data element is greater than the second opcode.

8. The method according to claim 2, wherein, The first part of the locking script includes a second instance of the first opcode, and wherein the method includes: When the second instance of the first opcode is invoked, a second data element is read from at least one stack, wherein the second data element is generated during the execution of the first portion of the locking script; and The second part of the locking script is output, following the instance of the second opcode corresponding to the second data element.

9. The method according to claim 8, wherein, The output of the second part of the locking script includes at least some of the content of executing the second part of the locking script.

10. The method according to claim 4, wherein, The second part of the locking script is the second part of the subscript, and the method includes replacing the unexecuted portion of the first part of the locking script with the second part of the subscript in the memory.

11. A computer-readable storage medium containing a computer program configured to perform the method according to any one of claims 1 to 10 when run on a node of a blockchain network.

12. A computing device, the computing device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 10 when run on the processing apparatus.

Images