Using blockchain transactions to bring off-chain functionality

Abstract

A method for executing transactions on a blockchain network, wherein a first transaction has at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of an opcode is executed. A second transaction includes a first unlocking script that references the first output in the first transaction. Execution of the first instance of the opcode terminates execution of the first locking script without invalidating the first transaction. A first data element is read from the at least one stack, the first data element being generated during execution of the first unlocking script and the portion of the first locking script. The first data element read from the at least one stack is provided to an off-chain function, the function configured to generate a result based on at least the first data element.

Description

[Technical field]

[0001] The present disclosure relates to using blockchain transactions to provide additional off-chain functionality, for example to generate new transactions that are a function of the effective execution of prior transactions. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is held at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain has a chain of blocks of data, with each block having one or more transactions. Each transaction points back to the previous transaction in the sequence, back to a genesis block at the beginning of the chain of blocks. Transactions can be submitted to the network to be included in new blocks. New blocks are generated by a process known as "mining." Mining involves each of multiple mining nodes competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions in a blockchain are used to carry digital assets, i.e. data that acts as a store of value. However, blockchains may also be used to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing more complex data to be incorporated. For example, this could be used to store electronic documents or even audio or video data on the blockchain.

[0004] Each node in the network can have any one, two, or all of the three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions across the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own copy of the mined blocks of the blockchain. To record a transaction on the blockchain, a party sends and propagates the transaction to one of the nodes of the network. Mining nodes that receive the transaction can compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or mined into a block. Assuming the transaction is validated and thereby accepted onto the blockchain, then the transaction (including user data) remains stored at each of the nodes in the P2P network as an immutable public record.

[0005] Miners who successfully solve the proof-of-work puzzle to generate an updated block are rewarded with a new transaction, called a "generation transaction," which typically generates a new amount of digital assets. Because miners require a large amount of computational resources to mine a block, and because blocks containing double-spending attempts may not be accepted by other nodes, proof-of-work incentivizes miners not to cheat the system by including double-spending transactions in their blocks.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure for a given transaction has one or more inputs and one or more outputs. Every spendable output has an element, sometimes called a UTXO (for “Unspent Transaction Output”), that specifies an amount of digital assets. The output may further have a locking script that specifies the conditions under which the output should be redeemed. Each input has a pointer to such an output in a previous transaction, and may further have an unlocking script that unlocks the locking script of the pointed-to output. Thus, consider a pair of transactions, call them a first transaction and a second transaction (or “target” transaction). The first transaction has at least one output that specifies an amount of digital assets and has a locking script that defines one or more conditions for unlocking the output. The second, target transaction has at least one input that has a pointer to an output of the first transaction and an unlocking script that unlocks the output of the first transaction.

[0007] In such a model, when a second, target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the conditions for validity applied at each node is that the unlocking script satisfies all of one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not yet been cleared by another, preceding valid transaction. Any node that determines the target transaction is invalid according to any of these conditions will neither propagate it for recording in the blockchain nor include it for mining in a block.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of the previous transaction in the sequence of past transactions, but rather by referencing absolute account balances. The current state of every account is stored and constantly updated by miners separate from the blockchain.

[0009] Blockchain protocols can use scripting languages ​​for transactions. A script is essentially a list of elements, which can be data or instructions. Instructions are called script words, opcodes, commands, or functions in the literature. Opcodes (short for operation code) perform predefined operations on the data in the script.

[0010] One blockchain scripting language is a dual stack implementation based on Fourth that excludes any loop functions. Fourth uses a dual stack, where the data stack is the main stack and the return stack is an extra stack. Summary of the Invention

[0011] One such opcode is OP_RETURN. In the original blockchain protocol, the purpose of OP_RETURN was to terminate the execution of a script. It did not invalidate the transaction that contained the script. However, this allowed for fraudulent attacks when OP_RETURN was included in the input script of a transaction. Specifically, any input script of a transaction that contained OP_RETURN could be used to unlock the output script of a previous transaction. Therefore, the protocol was modified in the existing blockchain protocol so that the opcode OP_RETURN represents a Provably Unspentable transaction output while still allowing the preservation of data in the blockchain. In the existing protocol, the OP_RETURN opcode is used to terminate the execution of a script and invalidate the transaction at the same time. However, this results in a loss of functionality in the blockchain, since a transaction that has OP_RETURN in its input script may not result in a “TRUE” (or valid) execution if executed at the same time as any unlocking script.

[0012] According to one aspect disclosed herein, there is provided a method of executing a transaction in a blockchain network, wherein a first transaction has at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of an opcode is executed, and a second transaction includes a first unlocking script that references the first output in the first transaction, the method comprising: terminating execution of the first locking script without invalidating the first transaction; reading from at least one stack a first data element generated during execution of the first unlocking script and the portion of the first locking script; providing the first data element read from the at least one stack to an off-chain function; having the function is configured to generate a result based on at least the first data element; A method is provided.

[0013] For brevity, the specific opcode is hereinafter referred to as "OP_RETURN". However, the present disclosure is not limited to opcodes having that specific label. More generally, while the embodiments are described with respect to "OP_RETURN" of a blockchain scripting language, the same teachings can be implemented by any opcode that performs a specific function when called by a script engine (e.g., a script interpreter), where the function begins to terminate execution of the script without invalidating the transaction. References to a first and second instance of an opcode should be interpreted as instances of the same type of opcode.

[0014] Here, OP_RETURN does not invalidate the transaction. Therefore, script elements in the locking script before OP_RETURN is called (or executed) (i.e., those executed before OP_RETURN) can be used as input to the off-chain function. That is, when the locking script is executed, data will remain in at least one stack (e.g., the Main stack or the Alt stack). In accordance with this disclosure, the node protocol is adapted such that OP_RETURN causes this data to be read from the stack and provided to the function for off-chain purposes.

[0015] For example, a function may create a new transaction based on data read from the stack. Data may be read from the stack and stored on a "return" stack, i.e., a stack separate from the main stack and the alt stack.

[0016] As another example, data left on the stack may be used as a reference to other parts of the transaction. For example, the data may be interpreted by the function as an index (or address) of an output within the transaction. The function may then execute a locking script contained in the referenced output. In this sense, the function acts as an "off-chain script interpreter" that identifies and executes locking scripts. This can be used to create off-chain loops.

[0017] To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be embodied, reference will now be made, by way of example only, to the accompanying drawings in which: [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 is a simplified block diagram of a system implementing a blockchain. [Diagram 2] 1 illustrates diagrammatically some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 1 is a simplified block diagram of another system implementing a blockchain. [Figure 4] FIG. 2 is a simplified block diagram of node software for executing transactions. [Figure 5a] represents an example of an initial transaction TxIn where each input has a commitment r from a player. [Figure 5b] This represents an example of an oracle transaction, Txoracle, where output 0 transfers a digital asset to a participant and output 1 generates a random number. [Figure 6a] 13 illustrates an example of an off-block script interpreter that jumps to outpoint address 1 in output 0 of a composite function transaction. [Figure 6b] 1 represents an example of a composite function transaction incorporating many possible jumps between out points. [Figure 7] Here is an example of unpacking a loop from a composite script function of the Euclidean algorithm for inputs a=105 and b=28. [Figure 8] 1 is an example of elliptic curve point multiplication with input 5,G, where the ortho stack (shown shaded) is shown along with the main stack. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] FIG. 1 illustrates an example system 100 for implementing a blockchain 150. The system 100 includes a packet-switched network 101, typically a wide area internetwork such as the Internet. The packet-switched network 101 includes 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 includes a peer's computing equipment, with different ones of the nodes 104 belonging to different peers. Each node 104 includes a processing unit having one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (FPGAs). Each node 104 also includes memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units using one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as a solid state drive (SSD), flash memory, or EEPROM, and / or an optical medium such as an optical disk drive.

[0020] The blockchain 150 comprises a chain of blocks 151 of data, each copy of which is held at each of the multiple nodes in the P2P network 106. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 has at least one input and at least one output. Each output specifies an amount that represents the amount of digital assets belonging to the user 103 that the output is cryptographically locked (requiring that user's signature to be unlocked and redeemed or used). Each input points to the output of a previous transaction 152, linking the transactions.

[0021] At least some of the nodes 104 act as forwarding nodes 104F that forward and thereby propagate transactions 152. At least some of the nodes 104 act as miners 104M that mine blocks 151. At least some of the nodes 104 act as storage nodes 104S (sometimes also referred to as "full copy" nodes), each of which stores a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also holds a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104F, a miner 104M, a storage node 104S, or any combination of two or all of them.

[0022] For a given current transaction 152j, the (each) input has a pointer that references the output of a previous transaction 152i in the sequence of transactions and specifies that this output should be settled or "spent" in the current transaction 152j. In general, the previous transaction may be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist at the time the current transaction 152j is generated or sent to the network 106, but the previous transaction 152i must exist and be validated for the current transaction 152j to be valid. Thus, "preceding" in this application refers to the predecessor in the logical sequence linked by the pointer, not necessarily the time of generation or transmission in the time sequence, and therefore it does not necessarily exclude transactions 152i, 152j from being generated or sent out of order (see the following discussion on orphan transactions). The previous transaction 152i may also be referred to as the antecedent or predecessor transaction.

[0023] The input of the current transaction 152j also has the signature of the user 103a to which the output of the previous transaction 152i is locked. That is, the output of the current transaction 152j may be cryptographically locked to the new user 103b. The current transaction 152j may thus 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 may have multiple outputs to split the input amount among multiple users (one of which may be the original user 103a to provide the change). In some cases, a transaction may also have multiple inputs to pool together both from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0024] The above is sometimes called an "output-based" transaction protocol, also sometimes called an Unspent Transaction Output (UTXO) type protocol (where the outputs are called UTXOs). A user's total balance is not defined by any one number stored in the blockchain, instead, the user needs a special "wallet" 105 to collate the values ​​of all of the user's UTXOs that are spread across many different transactions 152 in the blockchain 150.

[0025] An alternative type of transaction protocol is sometimes called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referencing the UTXO of the previous transaction in the sequence of past transactions, but rather by referencing the absolute account balance. The current state of every account is stored and constantly updated by a miner separate from the blockchain. In such a system, transactions are ordered using the account's intermediate transaction tally (also called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an arbitrary data field can also sign a transaction. This data field can point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0026] With any type of transaction protocol, when a user 103 wants to make a new transaction, he / she sends it from his / her computer terminal 102 to one of the nodes 104 (today usually a server or a data center, but in principle it could be another user terminal) of the P2P network 106. This node 104 checks if the transaction is valid according to a node protocol applied at each of them. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 in question, and together they form the overall transaction model. The node protocol usually asks the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may consist in checking that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i used by the new transaction. This condition typically involves at least checking that a cryptographic signature on the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, the condition may be defined at least in part by custom scripts included in the inputs and / or outputs. Alternatively, it may be determined solely by the node protocol, or by a combination of both. In any case, if the new transaction 152j is valid, the current node forwards it to one or more other of the nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, following the same node protocol and applying the same tests, and therefore forward the new transaction 152j to one or more further nodes 104, and so on.In this manner, the new transaction is propagated across the network of nodes 104.

[0027] In the output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has yet been validly redeemed by the input of another subsequent transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it is attempting to spend or redeem has not yet been spent / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double spending, where a spender tries to spend the same transaction output more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Again, since the order of transactions is defined, account balances have one defined state at a time.

[0028] In addition to validation, at least some of the nodes 104M also compete to be the first to generate a block of transactions in a process known as mining. This is backed by a "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a certain predefined number of leading zeros. A property of a hash function is that it has an unpredictable output with respect to its input. This search therefore consumes a significant amount of processing resources at each node 104M trying to solve the puzzle, since it can only be done by brute force.

[0029] The first miner node 104M to solve the puzzle will announce this to the network 106 and provide the solution as a proof. The solution can then be easily checked by other nodes 104 in the network (given the solution to the hash, it is easy to check that it satisfies the conditions on the output of the hash). The pool 154 of transactions in which the winner solved the puzzle will then be recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's announced solution at each such node. A block pointer 155 is also assigned to the new block 151n, pointing to the previously generated block 151n-1 in the chain. Proof-of-work helps to reduce the risk of double spending, since it takes a lot of effort to generate a new block 151, and mining nodes 104M are motivated not to allow double spending to be included in their blocks, since any block containing a double payment is likely to be rejected by other nodes 104. Once created, blocks 151 cannot be modified because they are known and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

[0030] Note that different miners 104M competing to solve the puzzle at any given time may be doing so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started looking for a solution. Whoever solves the puzzle first defines which transactions will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. The miners 104M then continue competing to generate blocks from the newly defined outstanding pool 154, and so on. The protocol also exists to resolve any "forks" that may occur. A fork is when two miners 104M solve a puzzle very quickly from each other, which leads to the propagation of competing views of the blockchain. In essence, whichever end of the fork is the longest, results in a deterministic blockchain 150.

[0031] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that generates a new digital asset out of thin air (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generation" transaction. It automatically forms part of a new block 151n. This reward motivates the miner 104M to participate in the proof-of-work competition. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M that generated the block 151n in which the transaction was included.

[0032] Depending on the computational resources involved in mining, at least each of the miner nodes 104M typically takes the form of a server including one or more physical server units, or an entire data center. Each transfer node 104F and / or storage node 104S also takes the form of a server or data center. However, in principle, any given node 104 may take the form of a user terminal or a group of user terminals networked together.

[0033] The memory of each node 104 stores software configured to execute on the processing unit of the node 104 to perform its respective one or more roles and to process transactions 152 according to the node protocol. It is understood that any operation attributed to a node 104 herein may be performed by software executing on the processing unit of the respective computing facility. The node software may 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 thereof. Additionally, the term "blockchain" as used herein is a general term that refers to the type of technology in general and is not limited to any particular proprietary blockchain, protocol, or service.

[0034] Also connected to the network 101 are computer devices 102 of a number of parties 103 each acting as a consuming user. They act as players and payees in a transaction, but do not necessarily participate in mining or propagating the transaction on behalf of the other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and his / her respective computer device 102a, and a second party 103 and his / her respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system, but for convenience they are not depicted. Each party 103 may be an individual or an organization. Purely by way of illustration, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be understood that this is not limiting and that any reference herein to Alice or Bob may be replaced with "the first party" and "the second party," respectively.

[0035] The computing equipment 102 of each party 103 has a respective processing unit having one or more processors, for example one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further has a memory, i.e. computer readable storage in the form of one or more non-transitory computer readable media. This memory may have one or more memory units using one or more memory media, for example magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory in the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to be executed on the processing unit. It will be understood that any operation attributed to a given party 103 herein may be performed using software executed on the processing unit of each computing equipment 102. Each party's 103 computing equipment 102 has at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. A given party's 103 computing equipment 102 may have one or more other networked resources, such as cloud computing resources, accessed via the user terminal.

[0036] The client application 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example downloaded from a server or provided on a removable storage device, such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0037] The client application 105 has at least a "wallet" function. It has two main functionalities. One of them is to allow each user party 103 to generate, sign and send transactions 152 to be propagated across the network of nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets he or she currently owns. In an output-based system, this second functionality consists in reconciling the amounts defined in the outputs of the various transactions 152 scattered across the blockchain 150 that belong to the party in question.

[0038] Note: Although various client functionality may be described as being included in a given client application 105, this is not necessarily a limitation, and instead any client functionality described herein may be implemented in a suite of two or more distinct applications, for example, interfacing via an API or plugged into one another. More generally, client functionality may be implemented at the application layer, or at a lower layer, such as an operating system, or any combination thereof. The following is described with respect to client application 105, but it will be understood that this is not a limitation.

[0039] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet function of the client 105 to send transactions to the network 106. The client 105 may also contact one, some, or all of the storage nodes 104S to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, to actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and transmit a transaction protocol 152 according to the transaction protocol. Each node 104 executes software configured to validate the transactions 152 in the case of a forwarding node 104F forwarding them for propagation across the network 106 according to the node protocol. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol works in conjunction with a given node protocol to together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow transactions of different subtypes within it). The same node protocol is used by all nodes 104 in the network 106 (although it may handle transactions of different subtypes differently according to rules defined for that subtype, and different nodes may play different roles and therefore implement different corresponding aspects of the protocol).

[0040] As stated, the blockchain 150 has a chain of blocks 151, each of which has a set of one or more transactions 152 generated by the proof-of-work process as described above. Each block 151 also has a block pointer 155 that points to a previously generated block 151 in the chain to define a sequential order for the blocks 151. The blockchain 150 also has a pool 154 of valid transactions waiting to be included in a new block by the proof-of-work process. Each transaction 152 has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 stretches all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0041] When a given party 103, for example Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (for example, using a wallet function in her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from the client application 105 to one or more transfer nodes 104F to which she is connected. For example, this may be the transfer node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives a new transaction 152j, it processes the new transaction 152j according to the node protocol and its respective role. This involves first checking whether the newly received transaction 152j satisfies certain conditions to be "valid". An example of this is explained in more detail later. In some transaction protocols, the validity conditions may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in mechanism of the node protocol or may be defined by a combination of the script and the node protocol.

[0042] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j adds the new validated transaction 152 to a pool 154 in the copy of the blockchain 150 held by that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it assumes that the transaction 152j is valid, which means that the transaction 152j will be propagated immediately throughout the P2P network 106.

[0043] With the copy of the blockchain 150 held in one or more storage nodes 104S, the miner nodes 104M then start racing to solve a proof-of-work puzzle for the latest version of the pool 154 that contains the new transaction 152. (Other miners 104M may still be trying to solve the puzzle based on their old view of the pool 154, but whoever gets there first will define where the next new block 151 ends and the new pool begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j.) Once the proof-of-work is done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0044] Different nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views of which instances are 'valid' before one instance is mined into block 151, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept this and discard (i.e. treat as invalid) the un-mined instance that it originally accepted.

[0045] Figure 2 depicts an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 contains one or more transactions 152). The following is described by reference to an output-based or "UTXO-based" protocol. However, this is not a limitation to all possible embodiments.

[0046] In the UTXO-based model, each transaction ("Tx") 152 has a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may have an unspent transaction output (UTXO), which can be used as a source for inputs 202 of other new transactions (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). It may also include, among other information, a transaction ID of the transaction from which it originated. The transaction data structure may also have a header 201, which may have indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include an ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0047] For example, Alice 103a wishes to create a transaction 152j that transfers an amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j begins with “Tx 1 " in Figure 2. It takes the amount of digital assets locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 15i is labeled "TX 0 " Tx 0 and Tx 1 are simply arbitrary labels. They do not necessarily refer to Tx 0 The fact that this is the first transaction in blockchain 150 also means that Tx 1 It does not mean that Tx is the next transaction in the pool 154. 1 may point to any previous (i.e., preceding) transaction that still has unspent outputs 203 locked to Alice.

[0048] Previous transaction Tx 0 has already been validated and Alice has created a new transaction Tx 1 Tx can be included in the blockchain 150 by the time she generates it, or at least by the time she sends it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 154, in which case it will soon be included in a new block 151. Alternatively, Tx 0 and Tx 1 may be generated and sent together to the network 106, or, if the node protocol includes buffering "orphan" transactions, Tx 0 Tx 1 may be sent after a transaction. The terms "preceding" and "subsequent" as used herein in relation to a sequence of transactions refer to the order of the transactions in the sequence defined by the transaction pointer specified in the transaction (which transaction points to which other transaction, and so on). They may similarly be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", etc. It does not necessarily imply the order in which they are generated, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (a succeeding transaction or "child") that points to a previous transaction (a preceding transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time waiting for the parent, depending on the node protocol and / or minor behavior.

[0049] Previous transaction Tx 0 One of the one or more outputs 203 of 0 Each UTXO has a value that specifies the amount of the digital asset represented by that UTXO, and a locking script that defines the conditions that must be satisfied by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully liquidated. Typically, the locking script locks the amount to a specific party (the recipient of the transaction in which it is included). That is, the locking script defines the unlocking conditions, typically having a condition that the unlocking script in the input of the subsequent transaction contains a cryptographic signature of the party to which the previous transaction is locked.

[0050] A locking script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A locking script specifies what information is needed to use the transaction output 203, e.g., the requirements of Alice's signature. An unlocking script appears in the output of a transaction. An unlocking script (aka scriptSig) is a piece of code written in a domain-specific language that supplies the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

[0051] Thus, in the example shown, Tx 0 UTXO in the output 0 is UTXO 0 In order for the transaction to be settled (strictly speaking, UTXO 0 (so that any subsequent transaction attempting to settle the transaction is valid), Alice’s signature Sig P ALocking script that requires [Checksig P A ]. [Checksig P A ] is the public key P from Alice’s public-private key pair. A Includes: Tx 1 The input 202 is (for example, in an embodiment, transaction Tx 0 The transaction ID TxID, which is the hash of the entire 0 (Using) Tx 1 Contains a pointer to Tx 1 The input 202 of the TX 0 UTXOs in 0 The index that identifies Tx 0 to distinguish it from any other possible output of Tx 1 The input 202 is an unlocking script that contains Alice's cryptographic signature, which was generated by Alice applying her private key from the key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P A What data (or "message") needs to be signed by Alice to result in a valid signature may be defined by the locking script, or by the node protocol, or by a combination of both.

[0052] New transaction Tx 1 When a locking script arrives at node 104, the node applies the node protocol. This involves running the locking script and the unlocking script together to check if the unlocking script satisfies the conditions defined in the locking script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function constructed by the unlocking script (in this example, a stack-based language). Equivalently, the scripts may be executed one after the other, with a common stack, rather than concatenating the scripts. In either case, when executed together, the scripts are executed in the Tx 1 To verify that the locking script in Tx's input contains Alice's signature, which signs the expected portion of the data, 0 The locking script in the output of A The expected part of the data itself (the "message") also uses Tx 0 In an embodiment, the signed data is also included in Tx 0 (Thus, a separate element specifying the signed portion of the data in plaintext needs to be included, since it is inherently already present).

[0053] The details of authentication using public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the plaintext message, other entities such as node 104 can authenticate that the encrypted version of the message should have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the plaintext version of the message, allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or portion of a transaction, etc., may in embodiments mean signing a hash of that piece of data or portion of a transaction.

[0054] Tx 1The unlocking script in Tx 0 If the locking script satisfies one or more of the conditions specified in the locking script (so, in the example shown, Alice's signature is Tx 1 If the node 104 is authenticated, the node 104 1 If it is the storage node 104S, this means that the storage node 104S considers Tx 1 This means that the transfer node 104F adds the transaction Tx 1 to one or more nodes 104 in the network 106 so that it propagates throughout the network. 1 Once validated and included in the blockchain 150, this results in Tx 0 UTXO from 0 is defined as used. Tx 1 Note that Tx can only be valid if it is used as an unused transaction output 203. If an attempt is made to use an output that is already in use by another transaction 152, then Tx 1 is invalid even if all other conditions are met. Therefore, node 104 also 0 It is also necessary to check whether a referenced UTXO in has already been spent (already forms a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a predefined order on transactions 152. In particular, a given node 104 could keep a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0055] 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, this is another criterion for invalidity in most transaction models. Thus, such a transaction is not propagated or mined into a block 151.

[0056] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" a portion of the amount defined in the UTXO as spent while another portion is spent. However, an amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, Tx 0 UTXOs in 0 The quantity defined in is Tx 1 Therefore, if Alice receives a UTXO 0 If you do not want to give Bob the entire amount defined in Tx 1 With the second output of the , she can either give herself change or pay it to another party.

[0057] In practice, Alice would usually also need to include a fee for the winning miners, since today the payoff for generation transactions is usually not enough to incentivize mining. If Alice did not include a fee for the miners, Tx 0may be rejected by the minor nodes 104M, and thus even if technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force the miners 104M to accept the transaction 152 if they do not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically awarded to the winning miner 104M. For example, the UTXO 0 A pointer to Tx 1 is the only input to the Tx 1 produces only one output UTXO 1 UTXO 0 The amount of digital assets specified in 1 If the difference is greater than the amount specified in the UTXO 203 of transaction 152, then the difference automatically goes to the winning miner 104M. Alternatively, or in addition, however, it is not necessarily excluded that the minor fee may be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0058] Alice and Bob's digital assets consist of unspent UTXOs that are locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across UTXOs in various transactions 152 across the blockchain 150. There is no single number that defines a given party's 103 total balance stored anywhere in the blockchain 150. The role of the wallet function in the client application 105 is to collate together the values ​​of all the various UTXOs that are locked to each party and that have not yet been used in other subsequent transactions. It can do this by querying a copy of the blockchain 150 stored at one of the storage nodes 104S, e.g., the storage node 104S that is closest or best connected to each party's computing device 102.

[0059] Note that script code is often expressed generally (i.e., not in a strict language). A ]=OP_DUP OP_HASH160 <H(P A )>OP_EQUALVERIFY OP_CHECKSIG [Checksig P A] may be written. "OP_···" refers to a specific opcode in the scripting language. OP_CHECKSIG (also called "Checksig") is a scripting 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, any occurrence of the signature ('sig') is removed from the script, but additional requirements such as hash puzzles remain in the transaction that was verified by the 'sig' input. As another example, OP_RETURN is a scripting language opcode to store metadata within the transaction, thereby generating an unusable output of the transaction that can immutably record the metadata in the blockchain 150. For example, the metadata may comprise a document that is desired to be stored in the blockchain.

[0060] signature P A is a digital signature. In an embodiment, it is based on ECDSA with the elliptic curve secp256k1. A digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature will sign a portion of the transaction inputs and all or a portion of the transaction outputs. The specific portion of the outputs it signs depends on the SIGHASH flag, which is a 4-byte code that is included at the end of the signature (and modified at the time of signing) to select which outputs are signed.

[0061] The locking script is sometimes called "scriptPubKey", referring to the fact that it contains the public key of the party to which each transaction is locked. The unlocking script is sometimes called "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that a condition for a UTXO to be redeemed be to authenticate the signature. More generally, a scripting language may be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0062] FIG. 3 shows a further system 100 implementing a blockchain 150. The system 100 is substantially the same as described with respect to FIG. 1, except that an additional communication functionality is included. The client applications on each of Alice's and Bob's computing devices 102a, 102b each have an additional communication functionality, namely, that allows Alice 103a to establish (at the instigation of either party or a third party) a separate side channel 301 with Bob 103b. The side channel 301 allows for the exchange of data apart from the P2P network. Such communication is sometimes referred to as "off-chain". For example, this can be used to exchange transactions 152 between Alice and Bob, without the transactions (yet) being published to the P2P network 106 or reaching the chain 150 until one of the parties chooses to broadcast the transactions 152 to the network 106. Alternatively, or additionally, side channel 301 may be used to exchange any other transaction related data, such as keys, negotiated amounts or terms, data content, etc.

[0063] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively, or in addition, the side channel 301 may be established over a different network, such as a local area network, such as a mobile cellular network, or a local wireless network, or a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, the side channel 301 referred to anywhere herein may have any one or more links over one or more networking technologies or communication media that exchange data "off-chain," i.e., separate from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links may be referred to as a side channel 301 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange certain information or pieces of data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be sent over exactly the same links or the same type of network.

[0064] [Off-chain functions] Embodiments of the present invention provide for extracting additional functionality from blockchain transactions, which is accomplished by configuring OP_RETURN to terminate script execution without invalidating the transaction.

[0065] FIG. 4 illustrates an example of node software 400 that may be executed on each node 104 of the P2P network 106 in an example UTXO or output-based model. The node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set of one or more blockchain-related functional modules (not shown). At any given node 104, they may include any one, two, or all of a mining module, a forwarding module, and a storage module (depending on the node's role or roles). The script engine 402 may include a script interpreter configured to execute the script by interpreting parts of the script as data elements or functions that act on those data elements and / or push or retrieve data elements from the stack 403. Alternatively, the script engine 402 may use other forms of execution, such as just-in-time (JIT) compilation. In general, the term "execute" is used herein in its broad sense of running a script in any manner (rather than in the narrow sense of running compiled machine code instructions). Thus, "executing" in this context can include interpreting. Also, note that "opcode" in this context does not mean the opcode of an individual machine code instruction, but rather the higher level command that is mapped to each predefined function by the script engine 402 at each node 104.

[0066] The protocol engine 401 is configured to recognize the different fields of the transaction 152 and process them according to the node protocol. m ) but the other previous transaction 152m-1 (Tx m-1 ) with an input pointing to an output (e.g., a UTXO), the protocol engine 401 mThe protocol engine 401 also identifies the unlocking script in the Tx m Based on the pointer in the input of Tx m-1 It also identifies and reads out Tx m-1 from each node's own pool 154 of pending transactions if Tx is not already in the blockchain 150, or m-1 If Tx is already in the blockchain 150, the node or other nodes 104 store a copy of the block 151 in the blockchain 150, and the node 104 stores the block 151 in the blockchain 150. m-1 In any case, the protocol engine 401 may read Tx m-1 The script engine 402 then identifies the locking script in the pointed to output and passes it to the script engine 402.

[0067] In this way, the script engine 402 executes the Tx m-1 Locking script and Tx m and an unlocking script from the corresponding input of 1 and Tx 2 is shown in Figure 4, but the same thing can be said about Tx 0 and Tx 1 This applies to any pair of transactions such as , etc. The script engine 402 executes the two scripts together as described above. This involves putting data onto and reading data from the stack 403 according to the stack-based scripting language being used (e.g., Script).

[0068] By executing the scripts together, the script engine 402 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether it "unlocks" the output in which the locking script is contained. The script engine 402 returns the result of this determination to the protocol engine 401. If the script engine 402 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, it returns the result "true." Otherwise, it returns the result "false."

[0069] In the output-based model, a "true" result from the script engine 402 is one of the conditions for the validity of a transaction. Typically, there are also one or more further protocol-level conditions evaluated by the protocol engine 401 that should also be satisfied. For example, Tx m The total amount of digital assets pointed to by the inputs of Tx does not exceed the total amount specified in the outputs. m-1 The protocol engine 401 evaluates the result from the script engine 402 together with one or more protocol level conditions, and only if they are all true does it accept the transaction Tx m The protocol engine 401 outputs an indication of whether the transaction is valid to the application level decision engine 404. m Only if Tx is in fact validated, the decision engine 404 controls one or both of the mining and forwarding modules to perform their respective blockchain-related functions as Tx m This means that the mining module may choose to execute on Tx m , and / or the forwarding module sends the Tx mNote that while, in embodiments, the decision engine 404 will not choose to forward or mine an invalid transaction, this does not necessarily mean that, conversely, it is obligated to trigger the mining or forwarding of a valid transaction simply because it is valid. Optionally, in embodiments, the decision engine 404 may apply one or more additional conditions before triggering either or both of these functions. For example, if the node is a mining node 104M, the decision engine 404 may choose to mine a transaction only if the transaction is valid and has sufficient mining fees remaining.

[0070] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result represented in the form of only a single binary digit (bit), even though that is certainly one possible implementation. More generally, "true" can refer to any state indicating a successful or positive outcome, and "false" can refer to any state indicating an unsuccessful or non-positive outcome. For example, in an account-based model (not shown in FIG. 4), a "true" outcome may be indicated by a combination of an implicit (protocol-level) validation of the signature by the node 104 and an additional positive outcome of the smart contract (the overall outcome is considered to signal true if both individual outcomes are true).

[0071] According to some embodiments, one condition for a valid transaction is that the unlocking script of that transaction cannot contain any instance of an OP_RETURN opcode, or any other such terminating opcode that does not mark the transaction as invalid. Protocol engine 401 and / or script engine 402 are configured to detect the presence of such opcodes in the unlocking script of a transaction. 2When a terminating opcode is detected in the unlocking script, protocol engine 401 is configured to mark the transaction as invalid. If a terminating opcode is detected in the unlocking script, the transaction is immediately marked as invalid and the script is never executed.

[0072] In further or alternative embodiments, the node software 400 has off-chain functions 405, where the protocol engine 401, the script engine 402, and the application level decision engine 404 may be referred to as "on-chain" functions. On-chain does not mean that the functions are actually included in the blocks 151. Rather, it means that the functions are incorporated as part of a protocol that validates transactions to be propagated across the network 106 and mined into the blocks 151. Conversely, off-chain means that the functions serve a purpose other than validating blocks. In some examples, the purpose is to generate new transactions, generate template scripts that include synthetic functions, or perform calculations on data taken from transaction Tx (or results therefrom).

[0073] In these embodiments, the script engine 402 is configured to feed a data element from a stack 403 (e.g., from the top of the stack) to an off-chain function 405. The script engine 402 also processes a transaction (Tx 1The off-chain function 405 is configured to read a data element from the stack 403 upon invocation of OP_RETURN present in the locking script of the script engine 402 (where Tx is a locking script). The off-chain function 405 is configured to generate a result based on the data element (or, in other words, perform an operation on the data element). In some examples, the data element is read from the stack 403 and recorded in an "off-chain stack", which is a stack that is not used for transaction validation purposes. Each time OP_RETURN is called by the script engine 402, a data element may be read from the stack 403 and provided to the off-chain function 405. The off-chain function 405 may be configured to generate a new transaction using the data element recorded in the off-chain stack. In other examples, the off-chain function 405 may generate a result based on the data element (or, in other words, perform an operation on the data element). In some examples, the data element is read from the stack 403 and recorded in an "off-chain stack", which is a stack that is not used for transaction validation purposes. Each time OP_RETURN is called by the script engine 402, a data element may be read from the stack 403 and provided to the off-chain function 405. The off-chain function 405 may be configured to generate a new transaction using the data element recorded in the off-chain stack. 1 As shown in FIG. 4, the Tx 1 has a number of locking scripts 1 through n. The off-chain function 405 interprets the data element as an address or index of a locking script (e.g., as an index of a third locking script) and then executes that locking script. Additionally or alternatively, the addressed locking script may be added to a script template saved in memory.

[0074] Some blockchain protocols use scripting languages ​​that have two types of elements: data and opcodes. Data in a script can be, for example, numbers, public keys, signatures, hash values, etc. Opcodes are functions that operate on the data in the script. In scripting languages, scripts are executed from one end to the other (usually from left to right) and utilize a data structure called a "stack." Data is always pushed (i.e., placed) onto the stack. Opcodes can pop data off the stack (i.e., take data off the stack), perform operations on the data, and then, optionally, "push" new data onto the stack. A scripting language that is widely used in many blockchains is simply called Script. The following is described with respect to opcodes of scripting languages.

[0075] Stack-based scripting languages ​​are familiar to those skilled in the art. The following example illustrates an example script implementation. Specifically, an example verification and unlocking process is presented below.

[0076] An example script might have: <Bob's signature><Bob's public key> OP_DUP OP_HASH<Bob's public address> OP_EQUALVERIFY OP_CHECKSIG The script is operated from left to right.

[0077] Step 1: Push <Bob's signature> onto the stack. [Table 1]

[0078] Step 2: Push <Bob's public key> onto the stack (this is now the top element of the stack). [Table 2]

[0079] Step 3: The OP_DUP opcode operates on the top element of the stack to duplicate <Bob's public key>. [Table 3]

[0080] Step 4: The OP_HASH opcode pops out <Bob's public key> and runs it through a hash algorithm (followed by one or more optional operations) to get <Bob's public address> and puts it on the stack. [Table 4]

[0081] Step 5: Put <Bob's public address> onto the stack (this is now the top element of the stack). [Table 5]

[0082] Step 6: The OP_EQUALVERIFY opcode pops the last two elements (<Bob's public address> and <Bob's public address>) from the stack and checks to see if the two addresses are the same. If they are not the same, the execution is considered unsuccessful. If the condition is true, the following command is executed. [Table 6]

[0083] Step 7: The OP_CHECKSIG opcode pops out <Bob's public key> and <Bob's signature> and checks them to ensure their validity. When this process is complete, Bob can unlock the transaction and access the specified amount of digital assets. [Table 7]

[0084] When executing a transaction, the unlocking script of a transaction is executed together with the locking script of the previous transaction. A transaction may have more than one locking script. For convenience, one of those locking scripts is hereafter referred to as the first locking script. The first locking script may be the locking script that appears first in the transaction (i.e., at output 1), or the first locking script may be at a different output of the transaction (e.g., at output 6). Similarly, a reference to a "first output" does not necessarily imply that it is the first in the list of outputs of the transaction. Unless the context requires otherwise, first, second, third, etc. are merely labels to distinguish between different ones of the same item (e.g., locking script, output, transaction, etc.).

[0085] When a first locking script is executed and it has OP_RETURN, when OP_RETURN is called, execution of the first locking script is terminated, leaving a data element on one or both stacks. Embodiments of the invention provide several ways in which this data element can be utilized to provide additional functionality. The data element is popped from the stack and provided to an off-chain function, which is configured to generate a result based on the data element (or equivalently, to perform an operation on the data element). The same device (or node) that executes the locking script may also implement the off-chain function. Alternatively, the data element may be provided to an external party that implements the off-chain function.

[0086] [Generate a new transaction] In some embodiments, the function is configured to generate a new transaction based on the data element. The new transaction may be generated and transmitted at any time after the first transaction is executed. The function may generate a transaction based directly on the data element or by first performing an operation on the data element. The new transaction may be transmitted to one or more nodes 104 of the blockchain network 106 for propagation across the network and / or recording on the blockchain.

[0087] As an example, the function may generate at least a portion of one of the inputs of the new transaction (e.g., a public key, a signature, a random variable). Additionally or alternatively, the function may generate at least a portion of one of the outputs of the new transaction (e.g., an amount of a digital asset to transfer).

[0088] The new transaction may include an output having a locking script. The locking script may have a portion of the script that should be executed before OP_RETURN is called. At least a portion of the locking script may be based on a data element provided to an off-chain function. Again, when OP_RETURN is called, the locking script is terminated and a new data element is left on the stack. This data element may be read from the stack and provided to an off-chain function, for example, to generate a further transaction. This allows a loop of transactions to be constructed, where each further transaction is based on a data element obtained from the execution of the locking script of the previous transaction.

[0089] In the example blockchain script, there are two stacks: the main stack and the alt stack. When validating a transaction, the script is executed on the stack. During execution, nothing can be written to the stack except the given script. However, it is recognized herein that it is possible to read data from the stack using an external function (or agent) immediately after execution has finished. The following describes the use of a third stack, an off-chain stack called the "return stack." The function of the return stack is to read and record data from the main stack and the alt stack, for example, to link the blockchain with the outside world. For example, the return stack may read from the main stack and the alt stack after the execution of the script. The data stored in the return stack may then be fed to off-chain functions to provide additional functionality, for example, to feed into the next script execution, to generate new transactions, or for other off-chain computations. Although the term "stack" is used, any data storage configured to store data read from the main stack or the alt stack may be used.

[0090] [Use case - Craps] The following example, which simulates a casino game called Craps, is given to illustrate the interaction between the return stack and blockchain transactions. The example involves two entities: Charlie, the casino, and Alice, the player. Each of them may be a respective party 103. In this simple example, the game of Craps plays as follows: one player, the "shooter," picks up two dice and shakes them on the craps table, or presses the "roll" button if playing online craps.

[0091] When the first digit is rolled, there are three possible outcomes: 1. Natural – A “natural” means the result of the roll is either 7 or 11. If this happens, the player wins and can roll the dice again. 2. Craps - A 2 (also known as Snake Eyes), 3, or 12 is rolled. If this happens, the player loses. However, the round is not over and players can roll the dice again. 3. Point - The player rolls a 4, 5, 6, 8, 9 or 10. In a live casino, the dealer marks the "point" (the number rolled) on the table. In online craps games, there is a small button that appears when a point is made. It is usually white and says "On". The player must now roll the dice more than once and hope that they land on the same number again. It does not have to be the same combination of dice that was rolled previously. As long as it is the same total, the player wins. If the player rolls a 7, the player is "seven out", i.e., they lose, and the betting round ends.

[0092] To make the game even simpler, in this example, the outcomes "natural" and "craps" end the game. 0 Think about it. [Table 8]

[0093] TX 0 Observations regarding: 1) TX 0 has two inputs: Alice's bet and Charlie's bet. 2) TX 0 has two outputs: each output represents one die. It is possible to combine the two outputs into one. However, having two outputs emphasizes that there are two dice and that more than one person "rolls" the dice. 3) Alice is assumed to be the only player who rolls the dice. That is, Alice is the only player who rolls the dice. 1 and P.K. 2 In order to allow other players to roll, the PK 2 may be replaced with a public key chosen by another player. 4) To prevent Alice from cheating, her public key may be replaced with two of the two MultiSigs, requiring signatures from both Alice and Charlie. 5) For each output, there are two OP_IFs. If the top stack value is False, the statement is executed. The top stack value is removed. a. The first is to check the validity of the signature. If it is true, proceed to "shake". If it is not true, Charlie can claim the output. Note that we assume that Charlie is trusted by the players. If this is not the case, a lock time can be implemented to ensure that Alice has priority to claim the output. b. The second is to check the validity of the random string given in the unlocking script. This can be a check of a prefix of the string with a hash puzzle. For example: i.[CHECK_RANDOM_STRING]:="get_first_4_bytes OP_HASH<predetermined hash value> OP_EQUAL". c. If the random string is not valid, Charlie can request the output. 6) Assuming the random string is valid and indeed random, run the script “OP_HASH <6> "OP_MOD" generates numbers in the range {0,1,2,3,4,5} with approximately equal probability. These outcomes represent the six possible outcomes from a roll of the dice {1,2,3,4,5,6}.

[0094] To simulate a throw, Alice needs to construct two unlocking scripts. Then, Alice can execute this incomplete transaction, TX 1 to Charlie. Charlie creates the transaction TX by appending two random strings. 1 Complete. [Table 9] [Table 10]

[0095] Penalty kick betpool It is assumed that the real random string is controlled by the casino and that Charlie is trusted to provide two new random strings.

[0096] TX 1 When is validated, one of the script executions looks like this:

number

[0097] Previous versions of OP_RETURN would terminate the script and invalidate the transaction when OP_RETURN was called, but with OP_RETURN implemented by the nodes of the embodiments described herein, OP_RETURN marks the transaction as valid and leaves a number on the stack after execution and before the stack is cleared. The number left on the stack is read and saved to the return stack.

[0098] Suppose Alice rolls a and b, where a,b∈{1,2,3,4,5,6}. All of the rules of craps can be implemented in scripts (e.g., off-chain functions) for off-chain evaluation. The pseudocode looks like this: 1) If (a+b)=7 or 11, it's a "natural." 2) If (a+b)=2, 3, or 12, then "Craps." 3) Else, save (a+b) on the return stack and call "point".

[0099] Each result corresponds to a new transaction. By interpreting the results from the return stack, a result transaction can be constructed: Natural transactions simply send a TX 1 Pays bounties from outputs in. ● Craps-Transactions, TX 1 Settle the output in: i.e., pay Charlie. ● Point-transaction is TX 1 which allows Alice to shake again.

[0100] Note that in this example use case, the natural and craps transactions end the game, while in the case of the points transaction, the game continues. Most importantly, the output of the first throw (the sum of a and b) is saved in the return stack. In other words, the result is the data element that is read from the stack and saved in the return stack. The output of the second throw will then be compared to a+b. If they are equal, a transaction is generated for Alice to claim her prize. Otherwise, the TX 0 Another transaction like this is generated for Alice to throw again.

[0101] In short, by having a return stack, a complex while loop can be simulated. This loop exists off-chain, and playing craps is an example of how this loop can be implemented. The use of a return stack can be generalized to many other applications, as will be demonstrated in the following examples.

[0102] [Use case - jury selection process] An example concerns a method that uses a group of N participants to achieve Random Number Generation (RNG) in a blockchain script. The method involves a minimum of two transactions: a) Initiate (first) transaction Tx In -Each participant signs an initiation transaction with their input, which includes a public commitment r to a secret value s. This transaction pays the digital asset to the oracle. b) Oracle (second) transaction Tx oracle -The oracle (off-chain function) obtains a secret value for each player and generates a random number R N The locking script creates a transaction that combines all N player secret values ​​to generate (first data element), and then locks the digital asset to the public key according to that number.

[0103] Random numbers R generated in oracle transaction locking script N may be used to determine the terms under which subsequent redemption transactions may use those digital assets. N Since x is likely pseudorandom, it may be used to seed other off-chain processes, such as laboratory experiments that require a seed for a deterministic process. In particular, provably-fair selection of jurors in criminal court proceedings could take advantage of this solution.

[0104] The use of provably fair random numbers in off-chain jury selection, generated by an on-chain locking script, requires running such a locking script to determine the final random number R. N This is further aided by introducing a return stack to return code to the off-chain interpreter.

[0105] A court may be considered responsible for selecting jurors to participate in criminal proceedings. Thereby, the selection should be done randomly to ensure that jurors are not "packed" or unfairly biased. The court may operate hardware and software that has the ability to run an off-chain return stack. Furthermore, the court may read data from the blockchain, execute transaction scripts, and store the results of their execution in its local return stack. The process defined by the court for selecting jurors from a pool of N possible jurors is derived from random numbers generated using the on-chain method described above. However, the court need not be involved in the generation process itself, instead acting as a third-party observer of the blockchain. In that case, the RNG process is performed by another third party, e.g., a lottery company.

[0106] Each time a jury is to be selected for a trial, the following process takes place: 1) The court requires service provider T to have an on-chain RNG process: A starting transaction Tx with aN participants In is organized and broadcast by T. b. Oracle transaction Tx oracle is generated and broadcast by T. 2) The court decided that Tx In and Tx oracle Read it from the blockchain. 3) The court may use the unlocking script to oracle Run the locking script: a. The unlocking script is Tx In It is generated by taking all r values ​​from b. The unlocking script is Tx oracle is taken out. 4) Top (main) stack item R N(first data element) is copied and stored on the court's return stack. 5) The court’s return stack (an off-chain stack) is used to select jurors, e.g., items from the stack are passed to a random number R N This is fed into an off-chain function that takes a sequential hash of the citations and maps the result to an eligible citizen's ID.

[0107] To achieve step 4, OP_RETURN is sent to Tx oracle OP_RETURN should be included in the locking script so that it can be used to terminate script execution in step 3. Additionally, OP_RETURN ensures that the top stack item is reset when script execution ends. N To ensure that the transaction is executed correctly, it is also required that the functionality be implemented to not terminate execution and invalidate the transaction. If OP_RETURN instead invalidated the transaction, the court interpreter would encounter an error upon termination, rather than the desired random number.

[0108] The transactions involved in this scenario are shown in Figures 5a and 5b.

[0109] The court initiated the transaction Tx In From the input of commitment r 1 ,···,r N and use them as the unlocking script during step 3 of the jury selection procedure:

number

[0110] Similarly, the court ruled that oracle transaction Tx oracle Extract the locking script output 1. This is:

number

[0111] The first line of this locking script is used to check that the committed r value matches the beginning transaction. The second line then injects a random value R during the script execution process. N Use the secret s value committed by the r value to generate . Finally, the third line is simply an OP_RETURN call, which terminates the script execution, so R N on the top of the main stack.

[0112] In step 3 of the jury selection procedure, the court executes the locking and unlocking scripts described above together. This execution is performed using a random number R N If execution completes successfully, the court can then read a random value from the top of the main stack and save it on the local machine's return stack.

[0113] This value R N The Tx is then used to select jurors in a manner that is provably fair. The entire process is repeated each time jury selection is required and In and Tx oracle can be repeated each time the generation of can be either overseen by the court's return stack or outsourced to a third party.

[0114] The main advantage of this approach is transparency: the public can read the transactions on-chain to see that the process is indeed random and unbiased.

[0115] [Composite Function] In some embodiments, the first transaction (hereinafter referred to as the "previous transaction") may have multiple outputs, each of which includes a locking script (some of which may be the same or different). Each output is referenced by an Output Address (OA), hereinafter also referred to as an outpoint address. This address may be a number that indexes the position of the output in the transaction. At least one of the outputs has a locking script with an output address that references a different one of the outputs. For example, the locking script may include a number (e.g., 2) or an opcode (e.g., OP_2), which when combined with OP_RETURN, may be interpreted as the address of the second output (the second in the list of outputs).

[0116] A second transaction (hereafter referred to as the "new transaction" or "further transaction"), generated at some point after the first transaction, has one or more inputs, each of which has an unlocking script. At least one of those unlocking scripts references an output of the previous transaction (hereafter referred to as the "first output" or "main output"). The first output does not have to be the first in the list of previous outputs, the label "first" is used only to indicate that the output is the first one to be called.

[0117] When executing the unlocking script, the locking script of the first output is referenced and executed. The locking script of the first output has at least an output address (i.e., a data element that can be interpreted as an output address) of an output of the same transaction. The output may be the same output (i.e., the first output) or a different output (e.g., the second output). Here, the second output does not necessarily mean that the second output is the second output in the list of outputs of the previous transaction, even if it is. The label "second" is used only to indicate that the output is the second one to be read. The locking script of the first output also has at least OP_RETURN. The locking script may also have additional data elements or opcodes.

[0118] OP_RETURN is configured to end the execution of the script without invalidating the transaction, such that the output address of the second output remains on the stack when OP_RETURN is called. In some examples, the output address in the locking script is immediately followed by OP_RETURN, i.e. there are no data elements or opcodes between the output address and OP_RETURN. The off-chain function is configured to read the data element remaining on the stack and interpret it as the output address of one of the outputs (in this case, the second output).

[0119] The function may then execute the locking script of the second output. Note that in contrast to normal execution of the locking script, the locking script of the second output is not executed along with the unlocking script. This is because the function is "off-chain", so the purpose of executing the locking script is not to validate the transaction for the purpose of sending it to a blockchain node for mining into the blockchain. Instead, one advantage is to configure the script, e.g., to implement the locking script or a smart contract.

[0120] The locking script of the second output may also have an output address, for example, of the third output, followed by OP_RETURN. Again, "third" here is used as a label to distinguish between the first and second, and does not indicate the order of the outputs in the previous transaction. However, it does not exclude that the first, second, and third outputs are part of an ordered sequence of outputs of the previous transaction. In this case, when the locking script of the second output is executed, the output address of the third output is pushed onto the stack. The output address may be a number or other data element that the function is configured to interpret as the output address of one of the outputs (in this case, the third output). The off-chain function may then use the third output address to reference the locking script of the third output.

[0121] The process of executing locking scripts may be repeated one or more times. Whenever OP_RETURN is called, the data element on the top of the stack is interpreted as the output address of one of the outputs. One or more of the outputs of the previous transaction may be executed more than once. The process may end once each of the locking scripts of each of the outputs has been executed. In some instances, not every output of the previous transaction is referenced by the unlocking script of the second transaction or by the outputs of the first transaction.

[0122] Each time a locking script is referenced, it may be copied to a script template, i.e., the "script to be executed." When the off-chain function has finished executing all of the referenced locking scripts, the script template will have the contents of those locking scripts except for the OP_RETURN opcode in the referenced locking scripts. In other words, the script template has the script with all loops unpacked, which can be used to construct a locking script without OP_RETURN for a new transaction.

[0123] In other words, consider a first transaction that contains multiple outputs, and a second transaction that references one of the outputs in the first transaction. The following steps may be performed: Step 1: Check if OP_RETURN exists in the locking script of the referenced output. If so, take all the locking scripts from the first transaction and index them accordingly. Step 2: If OP_RETURN is not present, copy the unlocking script and any locking scripts referenced by the unlocking script to the script to be executed. Step 3: run the script that should be executed. Step 4: When OP_RETURN is called, the first element on the stack is consumed. Step 5: If the first element consumed is a valid index, then the locking script referenced by the element consumed by OP_RETURN in step 4 is now copied to the beginning of the script to be executed. Step 6: Execution continues.

[0124] As an example, a first transaction may have the following locking script: Locking script 1: [Function 1] OP_2 OP_RETURN Locking script 2: [Function 2] Locking script 3:OP_1 OP_RETURN.

[0125] A second transaction may have an unlocking script :x for a locking script 3.

[0126] Thus, there are three locking scripts from the first transaction and one unlocking script from the second transaction that references the third output in the first transaction. Functions 1 and 2 are functions within each locking script, which may, for example, push and / or manipulate data on the stack. Functions 1 and 2 are executed because locking script 3 executes first, allowing locking script 1 (containing function 1) to execute, which then allows locking script 2 (containing function 2) to execute.

[0127] To perform a transaction: 1.x is pushed onto the stack. 2. Locking script 3 is executed. 3. Locking script 1 is called. 4. Function 1 is executed. 5. Locking script 2 is called. 6. Function 2 is executed. 7. Execution ends.

[0128] When OP_RETURN is called, the unlocking script is not re-executed, nor are any other unlocking scripts executed. Locking script execution is off-chain.

[0129] The off-chain function acts as an off-block (or off-chain) script interpreter. Such an interpreter can help users compose complex scripts to be implemented in locking scripts and smart contracts. On-chain, OP_RETURN is configured to terminate script execution without invalidating the transaction when it is called during any validation of the transaction. Off-chain, the off-block script interpreter adds a new feature to OP_RETURN. The new feature uses OP_RETURN to compose composite script functions that contain loops. Some blockchain scripting languages ​​do not allow loops. Therefore, any loops in the composed functions will be unpacked before they are placed in the locking script.

[0130] Off-chain functions utilize a single transaction that has multiple outpoints (outpoint and output are used synonymously). The off-block definition of OP_RETURN allows jumping from one outpoint to another within a transaction, and the outpoint index given by the top item on the stack is used to indicate the outpoint to jump to. This is depicted in Figures 6a and 6b and can be explained as follows:

[0131] Each outpoint of a transaction contains a locking script. For each outpoint, this locking script can be viewed as a single function. Each outpoint is referenced by a unique OA, which is the index of the outpoint within the transaction.

[0132] There is one outpoint that can be considered the "main" function and is executed first. This can be, for example, the last outpoint of a transaction.

[0133] Note that transaction outpoints are indexed from 0, which is a special value normally reserved for scripts that fail if followed by an OP_RETURN. In what follows, for simplicity, it is assumed that outpoints are indexed from 1.

[0134] When OP_RETURN is executed, the off-block script interpreter jumps to the OA given by the top item on the stack, adds the opcode in the locking script to the instruction set, and then continues execution as before. Except for popping the top item, the main stack and alt stack remain unchanged.

[0135] As shown in Figures 6a and 6b, the script interpreter performs the following tasks: Input: <oa> Operator: OP_RETURN ● Output: [ <oa>Locking script from <oa>is consumed.

[0136] It is important to emphasize that, except for the execution of OP_RETURN, the script interpreter is the same as the script interpreter that validates the transaction. The above configuration allows the transaction to be interpreted as a template for composite functions in the script. If the function could be compiled, it would be written out with a single out point where all loops should be unpacked, and the result would be a long and complex piece of code. However, in an embodiment of the present invention, all logic is contained in a separate output of the transaction, which is significantly smaller in size. This logic is more easily understood and more closely related to the forces. More specifically, this improves the reliability of the code, reduces the code base, and enables unit testing.

[0137] When unspent, transactions of this form will be stored in a UTXO set, which can be thought of as a universal "memory" for Bitcoin in terms of logging data for future reference. The transactions contain everything needed to compose composition functions, no other high-level language is required. This allows for a universally agreed upon set of composition functions. This is particularly useful for functions that may be repeated in many applications, e.g., elliptic curve point multiplication, which is described below.

[0138] This also allows the UTXO set to be used as a distributed repository for tuning complete code snippets. Apart from storing a set of useful composition functions, this repository can be used to outsource the processing of computations that are computationally hard to perform but easy to verify. Solutions to such computations can then be transferred on the blockchain. Digital assets are then redeemable by providing the exact solution, which is verifiable by the script. Another possible use case is to use the UTXO set as a distributed repository for smart contracts.

[0139] To prevent such a transaction in the UTXO set from being used, Alice, the transaction creator, adds OP_CHECKSIGVERIFY to the beginning of the locking script (requiring her signature). This part can be safely ignored when interpreting the script. Alternatively, a partial transaction can be constructed as above that includes an outpoint but has no inputs. This is sufficient to define a function. Once the composed function has been used to Alice's satisfaction, the transaction can either be completed and submitted, or discarded.

[0140] [Use Case - Euclidean Algorithm] As an example, a transaction TX_[Euclidean_algorithm] may be created with two outpoints, including the Euclidean algorithm, and the inputs of the transaction are left blank to highlight the outpoints. [Table 11]

[0141] The Euclidean algorithm takes two inputs (a, b) and outputs the Greatest Common Divisor (GCD) of a and b. For simplicity, assume that a>b.

[0142] By design, " Note that whenever "OP_RETURN" is called, the off-block interpreter replaces these two items with the entire script stored in the ith outpoint. The loop function executes " This is achieved by having "OP_RETURN". In this use case, the final outpoint of the transaction is the main function, which is the first to be called. <1> Any call to OP_RETURN is ignored by OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF". An example is shown in Figure 7. Step by step, the execution is as follows: 1) The input is first pushed onto the stack. 2) Main function " <1> "OP_RETURN OP_DROP" is called. 3) " <1> OP_RETURN” is “OP_TUCK OP_MOD OP_DUP OP_IF <1> It is replaced with "OP_RETURN OP_ENDIF". 4) "OP_TUCK OP_MOD OP_DUP OP_IF" is executed. 5) The input is non-zero, so the " <1> Go to "P_RETURN". 6) " <1> OP_RETURN" is changed to "OP_TUCK OP_MOD OP_DUP OP_IF <1> It is replaced with "OP_RETURN OP_ENDIF". 7) "OP_TUCK OP_MOD OP_DUP OP_IF" is executed. 8) The input is non-zero, so the " <1> Go to "P_RETURN". 9) " <1> OP_RETURN" is changed to "OP_TUCK OP_MOD OP_DUP OP_IF <1> It is replaced with "OP_RETURN OP_ENDIF". 10) "OP_TUCK OP_MOD OP_DUP OP_IF" is executed. 11) Since the input is zero, proceed directly to "OP_ENDIF" to close the if statement in step 9. 12) Proceed to "OP_ENDIF" to close the if statement in Step 6. 13) Proceed to "OP_ENDIF" to close the if statement in Step 3. 14) Return to the main function and proceed to "OP_DROP". 15) The result is left on the top of the stack.

[0143] [Use Case - Elliptic Curve Point Multiplication] For simplicity, the use case involves three functions, abbreviated as [DECIMAL_TO_BINARY], [POINT_ADD], and [POINT_DOUBLE].

[0144] [DECIMAL_TO_BINARY] consumes the first element d on the stack and outputs <2> <d n >··· <d 0 > onto the stack, where <2> is the first element of the indicator to be pushed in sequence (used to signal the end of a binary sequence),

number

[0145] [POINT_ADD] is the first two elements P on the stack. 1 and P 2 Consume and P 1 and P 2 Push the point addition onto the stack.

[0146] [POINT_DOUBLE] is interchangeable with OP_DUP[POINT_ADD], which consumes the first element on the stack, P, and pushes point 2P onto the stack.

[0147] TX_[POINT_MUL] is a transaction that contains a composite script function for elliptic curve point multiplication. [Table 12]

[0148] The main function, represented by the last outpoint in the above transaction, takes two inputs (a, G) and produces an output a·G. An example is shown in Figure 8. Note that "OP_RETURN" is replaced with the entire script from the i-th outpoint every time an OP_RETURN is encountered. A step-by-step explanation of what the script is doing is as follows, where the input (a,G) is assumed to be pushed onto a stack, and G is the first element on the stack.

[0149] The main function (outpoint 6) is called.

[0150] 1) Push G onto the alt stack. 2) Call [DECIMAL_TO_BINARY] to get the binary representation of a. 3) Return G to the alt stack. 4) Push a 0 onto the alt stack. This 0 helps identify when the bottom of the alt stack has been reached. 5) First, process the first (least significant) bit of a. If it is 1, push G onto the alt stack. 6) Then we push a 1 onto the alt stack, which indicates that there is a nonzero element next to it on the alt stack. 7) Outpoint 4 continues to be called until it finds a 2 on the main stack (indicating the end of the binary sequence). 8) Outpoint 4 doubles the point, and if the binary bit is 1, it pushes the result onto the alt stack after the 1 (described in step 6). 9) Once outpoint 4 is complete, there will be a list of points on the altstack to be summed. 10) Move the first point from the alt stack to the main stack, call out point 5 and start adding points. 11) When the end of the alt stack is reached, the expected result is on the main stack.

[0151] [protocol] The above discussion shows how allowing OP_RETURN in a transaction's output script (e.g., locking script) to terminate script execution without invalidating the transaction can provide additional functionality. However, allowing OP_RETURN to act in this way in a transaction's unlocking script can open up the possibility for malicious attacks to occur. To prevent this, a node processing a transaction MAY invalidate the transaction if any input script (e.g., unlocking script) has OP_RETURN.

[0152] For each of the multiple transactions, including the target transaction, at least some nodes of the network are configured to propagate each transaction, provided that the transaction is valid, and at least some nodes are configured to record each transaction in its copy of the blockchain, provided that the transaction is valid. The validity of the transaction is subject to the above protocol, according to which if OP_RETURN is called, the script only terminates and, importantly, the transaction is not invalidated. For example, transaction validity may depend on the top element of the stack.

[0153] The protocol restores transaction functionality by allowing input scripts to execute properly when executed together with an output script, while preventing fraudulent attacks by ensuring that any input script with OP_RETURN cannot be used to unlock any output scripts.

[0154] A node is configured to validate or invalidate transactions it processes based on the above protocol. That is, when a node processes a transaction, the inclusion of OP_RETURN in the transaction's output script (or more than one output script) will cause the output script to terminate when OP_RETURN is called. The inclusion of OP_RETURN in an output script does not invalidate a transaction; a transaction may be invalidated for other reasons. On the other hand, a node is configured to invalidate a transaction whenever OP_RETURN is included in the transaction's input script; now, the inclusion of OP_RETURN in any input script will cause the transaction to be invalidated.

[0155] Each type of node in a blockchain network may implement the same protocol. A node in a blockchain network may be, for example, a mining node, a forwarding node, or a storage node, each having one or more of the same functions, as described below. For example, if a node is a forwarding node, the forwarding node may forward a transaction to one or more nodes in the blockchain network only on the condition that the protocol is implemented, e.g., on the condition that the OP_RETURN opcode is not present in any of the transaction's input scripts.

[0156] The protocol defined to be implemented by nodes according to embodiments of the present invention imposes at least two conditions on the use of OP_RETURN: 1) OP_RETURN is permitted in the output script of a valid transaction. 2) OP_RETURN is not allowed in the input script of a valid transaction.

[0157] The function of OP_RETURN is to terminate the execution of the script without invalidating the transaction, i.e. when OP_RETURN is called, the script is stopped and the stack is not modified.

[0158] When validating a transaction, a node will not invalidate a transaction based solely on the presence of OP_RETURN in the transaction's output script. Conversely, a node will invalidate a transaction based solely on the presence of OP_RETURN in the transaction's input script. If a transaction has more than one input, it is sufficient that only one of them has an input script containing OP_RETURN for the node to invalidate the transaction. If the locking script has OP_RETURN, the transaction will never be executed; that is, it will be invalidated without execution.

[0159] Referring to FIG. 1, a first party, Alice 103a, may generate a transaction having one or more inputs and / or one or more outputs. As shown in FIG. 2, each input may have an unlocking script to unlock the locking script from the previous transaction. Each output may have a locking script to lock an amount of digital assets to a respective second party, e.g., Bob 103b, which will be unlocked by the unlocking script of a later transaction. Alice 103a sends the transaction to the P2P network nodes. The forwarding node 104F checks the transaction for validity before propagating it to one or more other forwarding nodes or to the mining node 104M. Alternatively, the mining node 104M may receive the transaction directly from Alice 103a. Each node determines whether the transaction is valid or not based at least on the above protocol. If a transaction satisfies the protocol's requirements regarding the use of OP_RETURN (as well as one or more other requirements of the protocol), the transaction is propagated across the network and / or mined into the blockchain.

[0160] In some embodiments, OP_RETURN may only be permitted in a transaction's locking script. Similarly, in some embodiments, OP_RETURN may only be disallowed from a transaction's unlocking script. In some examples, before executing an input script, a node may be configured to scan for any instances of OP_RETURN in the input script, and if such an instance is present, the node may disable the transaction, i.e., before executing the input script. As described above, each transaction has one or more inputs, each of which may have an unlocking script, and one or more outputs, each of which may have a locking script. The unlocking script of a given transaction unlocks the locking script of any previous transaction.

[0161] When implementing the protocol, when a node validates a transaction, it means that, among other conditions, the transaction does not contain any OP_RETURN in any input script. Validity of a transaction results in a non-empty and non-zero result on the stack after executing the combination of an unlocking script from the transaction and a locking script from a different transaction. Validity of a transaction additionally or alternatively causes the node to forward the transaction to one or more nodes in the network, e.g., to miners for mining into the blockchain. Another consequence of validating a transaction is that, if the node is a miner, the miner mines (i.e., records) the transaction into a block on the blockchain.

[0162] The protocol defined herein advantageously prevents fraudulent attacks and remains compatible with existing functionality of blockchains (i.e., data storage applications). Fraudulent attacks are prevented by ensuring that OP_RETURN cannot be present in the unlocking script of a transaction. Existing functionality may require OP_RETURN to be present in the output (e.g., locking script) of a transaction before <0> This can be achieved by including: <0> is any element that results in a zero being pushed onto the stack. For example, a zero opcode OP_0 may be placed before OP_RETURN. This produces a transaction output that is unrevealable, i.e., by inserting [OP_0 OP_RETURN<arbitrary data>] in the transaction's locking script. The arbitrary data may be, for example, one or more of image data, text data, video data, and audio data. As an example, a video file or a legal document may be included in the transaction's output.

[0163] It will be understood that the above embodiments are described by way of example only. For clarity, the embodiments are not limited to opcodes having particular names. Rather, the embodiments are limited to opcodes having particular functions. The term "OP_RETURN" is used for brevity.

[0164] According to a first embodiment of the teachings disclosed herein, there is provided a method of executing a transaction in a blockchain network, the first transaction having at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of an opcode is executed, and a second transaction including a first unlocking script that references the first output in the first transaction, the method including, upon executing the first instance of the opcode: terminating execution of the first locking script without invalidating the first transaction; reading from at least one stack a first data element generated during execution of the first unlocking script and the portion of the first locking script; providing the first data element read from the at least one stack to an off-chain function; having the function is configured to generate a result based on at least the first data element; A method is provided.

[0165] The opcode may be referred to as a terminating opcode, i.e., the terminating opcode terminates the execution of the script.

[0166] According to a second optional embodiment, there is provided a method according to the first embodiment, wherein reading the first data element may comprise recording the first data element in at least one off-chain stack, and wherein providing may comprise providing the first data element read from the at least one off-chain stack to the off-chain function.

[0167] According to a third optional embodiment, there is provided a method according to the first or second embodiment, wherein the result may include a further transaction in the blockchain network.

[0168] According to a fourth optional embodiment, there is provided a method according to any of the first to third embodiments, wherein generating the further transaction may comprise generating an input for the further transaction, the input being based on at least the first data element.

[0169] According to a fifth optional embodiment, there is provided a method according to any of the first to fourth embodiments, which may comprise sending the further transaction to one or more nodes of the blockchain network.

[0170] According to a sixth optional embodiment, there is provided a method according to any of the third to fifth embodiments, the method comprising: executing a third transaction in the blockchain network, the third transaction having at least a second output including a second locking script in the stack-based scripting language, the second locking script including a portion of the second locking script to be executed before the second instance of the opcode is executed, the further transaction including a second unlocking script referencing the second output in the third transaction, the method comprising: upon executing the second instance of the opcode of the further transaction, terminating execution of the second locking script without invalidating the further transaction; reading from the at least one stack a second data element generated during execution of the second unlocking script and the portion of the second locking script; and providing the second data element read from the at least one stack to the off-chain function, the function configured to generate a further result based on at least the second data element.

[0171] According to a seventh optional embodiment, there is provided the method according to the first embodiment, wherein the first transaction may have a plurality of outputs, each having a respective locking script, each of the plurality of outputs referenced by a respective output address, the first data element being an output address that references a second output of the plurality of outputs, the first output being referenced in the unlocking script of the second transaction, and the off-chain function may be configured to use the output address popped from the stack to reference a locking script for the second output when invoking the first instance of the opcode.

[0172] According to an eighth optional embodiment, there is provided a method according to the seventh embodiment, which may include executing the unlocking script and the first locking script, the executing including pushing an output address of the second output onto the stack.

[0173] According to a ninth optional embodiment, there is provided a method according to the eighth embodiment, which may include, prior to said execution of said unlocking script and said first locking script, copying said unlocking script and said first locking script to a script template, said script template including the script to be executed.

[0174] According to a tenth optional embodiment, there is provided a method according to the ninth embodiment, which may include, upon invoking the first instance of the opcode, copying a locking script of the second output to the beginning of the script template.

[0175] According to an eleventh optional embodiment, there is provided a method according to any of the seventh to tenth embodiments, which may comprise executing a locking script of the second output.

[0176] According to a twelfth optional embodiment, there is provided a method according to the eleventh embodiment, wherein the locking script for the second output may include a portion of a script to be executed before a second instance of the opcode, the portion having an output address referencing a third output of the plurality of outputs, and executing the locking script for the second output may include pushing an output address of the third output onto the stack, and the function is configured to use the output address read from the stack to refer to the locking script for the third output when invoking the second instance of the opcode.

[0177] According to a thirteenth optional embodiment, there is provided a method according to the twelfth embodiment, which may include, upon invoking the second instance of the opcode, copying the locking script of the third output to the beginning of the script template.

[0178] According to a fourteenth optional embodiment, there is provided a method according to the twelfth or thirteenth embodiment, wherein the first output, the second output, and the third output may be listed sequentially in the plurality of outputs.

[0179] According to a fifteenth optional embodiment, there is provided a method according to the twelfth or thirteenth embodiment, wherein the first output, the second output, and the third output do not have to be listed sequentially in the plurality of outputs.

[0180] According to a sixteenth optional embodiment, there is provided a method according to any of the seventh to fifteenth embodiments, the method comprising executing a locking script of a referenced output to push an output address of each output onto the off-chain stack, the function being configured to use the output address read from the stack to reference a locking script of a next output of the plurality of outputs upon invocation of each instance of the opcode of each output, the operation being repeated until each locking script of the plurality of outputs referenced by another locking script has been executed.

[0181] According to a seventeenth optional embodiment, there is provided a method according to the sixteenth embodiment, which may include copying one of the locking scripts to the beginning of the script template each time that locking script is executed.

[0182] According to an eighteenth optional embodiment, there is provided a method according to the sixteenth or seventeenth embodiment, which may comprise using the script template as a locking script for a further transaction, wherein the locking script for the further transaction does not include an instance of the opcode.

[0183] According to an optional nineteenth embodiment, there is provided a method according to any of the seventh to eighteenth embodiments, wherein one or more of the locking scripts may have respective functions, and execution of each of the locking scripts comprises executing the respective functions.

[0184] According to a twentieth optional embodiment, there is provided a method according to the nineteenth embodiment, wherein each function may be configured to operate on data on the off-chain stack at the time the each function is executed.

[0185] According to a twenty-first optional embodiment, there is provided a method according to any of the seventh to twentieth embodiments, which may include retrieving all locking scripts from the first transaction if the first locking script has an instance of the opcode and indexing them by their respective output addresses.

[0186] According to an optional twenty-second embodiment, there is provided a method according to any of the seventh to twenty-first embodiments, wherein each output address in each locking script may be a respective data element, and the method may include interpreting the respective data element as an output address.

[0187] According to a twenty-third optional embodiment, in the method according to any of the first to twenty-second embodiments, executing the transaction may comprise validating a transaction for recording on the blockchain, the method comprising applying a protocol for validating the transaction, the protocol comprising: enabling an end opcode to be included in an output script of the transaction, the end opcode being configured, when executed by a node, to a) terminate execution of the output script; and b) not invalidate the transaction based solely on the inclusion of the end opcode in the output script; disallowing any instance of the end opcode from being included in an input script of the transaction, the disallowing comprising the node at least invalidating the transaction if any instance of the end opcode is included in the input script. A method is provided, which may be configured to:

[0188] A transaction is not invalidated simply because of the presence of OP_RETURN in the output script, or in other words, a transaction is not invalidated based on an OP_RETURN in the output script itself, but may be invalidated for other reasons, as explained.

[0189] According to a twenty-fourth optional embodiment, there is provided a method according to the twenty-third embodiment, wherein the output script may be a locking script included in the transaction, and the input script is an unlocking script included in the transaction for unlocking a locking script of a previous transaction.

[0190] According to an optional embodiment of a twenty-fifth aspect, there is provided a method according to the twenty-third or twenty-fourth embodiment, wherein the protocol may be configured to invalidate the transaction based on the combination of the instance of the end opcode and the at least one data element when the output script includes a combination of an instance of the end opcode preceded by at least one data element.

[0191] In some instances, for a transaction to be invalidated based on the combination, an instance of the end opcode should be immediately preceded by at least one data element, i.e., the at least one data element and the end opcode are adjacent elements of the output script. Apparently unusable outputs allow for data storage (e.g., contracts, media files, documents, etc.) on the blockchain.

[0192] According to a twenty-sixth optional embodiment, there is provided a method according to the twenty-fifth embodiment, wherein the at least one data element may have one or both of a zero opcode or a zero value representation to generate an obviously unusable output of the transaction.

[0193] A data element can be any element of a script (eg, a function, a string, an opcode, etc.).

[0194] According to an optional 27th embodiment, there is provided a method according to any of the 23rd to 26th embodiments, wherein the protocol may be configured to not allow any opcodes to be included in the input script of the transaction, the not being allowed comprising the node at least invalidating the transaction if any opcode is included in the input script.

[0195] According to an optional twenty-eighth embodiment, there is provided a method according to any of the twenty-third to twenty-seventh embodiments, wherein the validating may include at least one of: resulting in a non-empty and non-zero result after execution by the node of a combination of the output script and the input script; the node forwarding the transaction to one or more nodes of the network for recording in the blockchain; and the node recording the transaction to the blockchain.

[0196] According to a twenty-ninth optional embodiment, there is provided a method according to any of the above embodiments, wherein the first instance of the opcode, when executed, is configured to mark the first transaction as valid and to leave a number on the at least one stack after execution of the first instance of the opcode and before the at least one stack is cleared, and the first data element is the number.

[0197] According to a thirtieth optional embodiment, there is provided a method according to any of the above embodiments, wherein the first instance of the opcode is an OP_RETURN opcode.

[0198] According to a thirty-first optional embodiment, there is provided a method according to the second embodiment or any embodiment dependent thereon, wherein the off-chain stack is a stack that is not used for purposes of validating transactions.

[0199] According to a thirty-second embodiment of the teachings disclosed herein, there may be provided a computer program embodied in a computer readable storage and configured to perform a method according to any of the first to twenty-eighth embodiments when executed on a node of a blockchain.

[0200] According to a thirty-third embodiment of the teachings disclosed herein, there is provided a computing device having a memory having one or more memory units and a processing device having one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when executed on the processing device, to perform a method according to any of the first to twenty-eighth embodiments.

[0201] Other variations or uses of the disclosed teachings will be apparent to those skilled in the art in view of the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims. < / oa> < / oa> < / oa>

Claims

1. A computer-implemented method for executing transactions on a blockchain network, wherein a first transaction has at least a first output including a first locking script in a stack-based scripting language, the first locking script including a portion of the first locking script to be executed before a first instance of an opcode is executed, and a second transaction includes a first unlocking script that references the first output of the first transaction, wherein executing the first instance of the opcode: terminating execution of the first locking script without invalidating the first transaction; reading from at least one stack a first data element generated during execution of the first unlocking script and the portion of the first locking script; providing the first data element read from the at least one stack to an off-chain function; having the off-chain function is configured to generate a result based on at least the first data element; the first transaction has a plurality of outputs, each having a respective locking script, each of the plurality of outputs being referenced by a respective output address, the first data element being an output address that references a second output of the plurality of outputs, the first output being referenced in the first unlocking script of the second transaction; the off-chain function is configured to, upon invoking the first instance of the opcode, use an output address read from the stack to reference a locking script for the second output. method.

2. executing the first unlocking script and the first locking script, the executing including pushing an output address of the second output onto the stack. The method of claim 1.

3. copying the first unlocking script and the first locking script to a script template prior to said executing the first unlocking script and the first locking script; The script template includes a script to be executed. The method of claim 2.

4. copying the second output locking script to the beginning of the script template when the first instance of the opcode is invoked. The method according to claim 3.

5. executing a locking script of the second output.

5. The method according to any one of claims 1 to 4.

6. the locking script for the second output includes a portion of a script to be executed before a second instance of the opcode, the portion having an output address that references a third output of the plurality of outputs, and executing the locking script for the second output includes pushing an output address of the third output onto the stack; the off-chain function is configured, upon invoking the second instance of the opcode, to use an output address read from the stack to reference a locking script for the third output. The method according to claim 5.

7. copying the locking script of the third output to the beginning of a script template when the second instance of the opcode is invoked. The method according to claim 6.

8. the first output, the second output, and the third output are listed sequentially in the plurality of outputs. The method according to claim 6 or 7.

9. the first output, the second output, and the third output are not listed sequentially in the plurality of outputs. The method according to claim 6 or 7.

10. executing a locking script for the referenced outputs to perform an operation of pushing an output address of each output onto an off-chain stack; the off-chain function is configured to use an output address read from the stack to reference a locking script for a next output of the plurality of outputs upon invoking each instance of the opcode for each of the outputs; the operations are repeated until each locking script of the plurality of outputs referenced by another locking script has been executed.

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

11. each time one of the locking scripts is executed, copying the locking script to the beginning of a script template. The method of claim 10.

12. using the script template as a locking script for further transactions; the locking script for the further transaction does not contain an instance of the opcode; 12. The method according to claim 10 or 11.

13. one or more of the locking scripts having a respective function, and execution of the respective locking script comprises executing the respective function.

13. The method according to any one of claims 1 to 12.

14. Each of the functions is configured to operate on data on an off-chain stack at the time the respective function is executed. The method of claim 13.

15. extracting all locking scripts from the first transaction if the first locking script has an instance of the opcode and indexing them with their respective output addresses.

15. The method according to any one of claims 1 to 14.

16. Each output address in each locking script is a respective data element, The method includes interpreting each data element as an output address.

16. The method according to any one of claims 1 to 15.

17. executing the transaction includes validating the transaction for recording on the blockchain network; The method includes applying a protocol for validating the transaction, the protocol comprising: enabling an end opcode to be included in an output script of the transaction, the end opcode being configured, when executed by a node on the blockchain network, to a) terminate execution of the output script; and b) not invalidate the transaction based solely on the inclusion of the end opcode in the output script; disallowing any instance of the end opcode from being included in an input script of the transaction, the disallowing comprising the node at least invalidating the transaction if any instance of the end opcode is included in the input script. It is configured as follows:

17. A method according to any one of claims 1 to 16.

18. the output script is a locking script included in the transaction; the input script is an unlocking script included in the transaction for unlocking a locking script of a previous transaction; 20. The method of claim 17.

19. the protocol is configured to invalidate the transaction based on the combination of the instance of the end opcode and the at least one data element if the output script includes a combination of the instance of the end opcode preceded by at least one data element.

19. The method according to claim 17 or 18.

20. the at least one data element has one or both of a zero opcode or a zero value representation to produce an obviously unusable output of the transaction; 20. The method of claim 19.

21. the protocol is configured to not allow any opcodes to be included in the input script of the transaction, the not allowing comprising the node at least invalidating the transaction if any opcode is included in the input script; 21. The method according to any one of claims 17 to 20.

22. The validating step comprises: yielding a non-empty and non-zero result after execution by the node of a combination of the output script and the input script; the node forwarding the transaction to one or more nodes of the blockchain network for recording on the blockchain network; the node records the transaction on the blockchain network; having at least one of:

22. The method according to any one of claims 17 to 21.

23. the first instance of the opcode is configured, when executed, to mark the first transaction as valid and to leave a number on the at least one stack after execution of the first instance of the opcode and before the at least one stack is cleared; the first data element being the number; 23. A method according to any one of claims 1 to 22.

24. the first instance of the opcode is an OP_RETURN opcode; 24. A method according to any one of claims 1 to 23.

25. The off-chain stack is a stack that is not used for the purpose of validating transactions.

15. The method according to claim 10 or 14.

26. 26. A computer program embodied in a computer readable storage and configured to perform the method of any one of claims 1 to 25 when executed on a node of a blockchain network.

27. a memory having one or more memory units; a processing device having one or more processing units; having The memory stores code arranged to be executed on the processing device, the code being configured to perform a method according to any one of claims 1 to 25 when executed on the processing device. Computer equipment.

Images