Protocol used to verify the validity of blockchain transactions

Abstract

A method for verifying the validity of a transaction for recording it in a blockchain, the method comprising receiving one or more transactions at a node in a blockchain network. For each received transaction, a protocol for verifying the validity of the transaction is applied. The protocol is configured to allow a termination opcode to be included in the output script of the transaction. The termination opcode is configured to, when executed by the node, a) terminate execution of the output script; and b) not verify the transaction as invalid solely based on the inclusion of the termination opcode in the output script. The protocol is also configured to disallow any instance of the termination opcode from being included in the input script of the transaction, wherein if any instance of the termination opcode is included in the input script, the disallowing includes: the node at least verifying the transaction as invalid.

Description

Technical Field

[0001] This disclosure relates to the implementation of a protocol for verifying the validity of blockchain transactions. Background Technology

[0002] A blockchain is a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a series of data blocks, each containing one or more transactions. Each transaction points back to previous transactions in the sequence, tracing back to the genesis block at the beginning of the blockchain. Transactions can be included in new blocks by submitting them to the network. The process of creating a new block is called "mining," which involves each of multiple mining nodes competing to perform "proof-of-work," a cryptographic puzzle based on a pool of pending transactions waiting to be included in the block.

[0003] Transactions in blockchains are typically used to transfer digital assets, i.e., data used as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in transaction outputs. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, enabling the incorporation of more complex data. This can be used, for example, to store electronic documents, or even audio or video data, within the blockchain.

[0004] Each node in the network can have any one, two, or all of the following three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the network. Mining nodes mine transactions into blocks. Storing nodes each store their own copy of the mined blocks in the blockchain. To record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. Mining nodes receiving the transaction can compete to mine it into a new block. Each node is configured to adhere to the same node protocol, which will include one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated or mined into blocks. Assuming a transaction has been verified as valid and thus accepted on the blockchain, the transaction (including any user data) will therefore continue to be stored as an immutable public record at various nodes in the P2P network.

[0005] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying the amount of digital assets, sometimes referred to as a UTXO ("unspent transaction output"). This output may also include a locking script specifying the conditions used to redeem the output. Each input includes a pointer to such an output in a previous transaction and may also include an unlocking script used to unlock the locking script pointing to the output. Therefore, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets and includes a locking script defining one or more conditions for unlocking that output. The second target transaction includes at least one input and an unlocking script, the at least one input including a pointer to an output of the first transaction; this unlocking script is used to unlock the output of the first transaction.

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

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

[0008] Blockchain protocols can use scripting languages ​​for transactions. A script is essentially a list of elements, which can be data or instructions. These instructions are referred to in the literature as script words, opcodes, commands, or functions. Opcodes (short for operation codes) perform predefined operations on the data in the script. Summary of the Invention

[0009] 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 verify the invalidity of transactions containing that script. However, when OP_RETURN is included in the input script of a transaction, this can lead to fraudulent attacks. Specifically, any input script of a transaction containing OP_RETURN can be used to unlock the output script of a previous transaction. Therefore, the protocol was changed so that in the existing blockchain protocol, the opcode OP_RETURN represents a provably unspendable transaction output, allowing data to be stored on the blockchain. In the existing protocol, the OP_RETURN opcode is used to terminate the execution of a script while verifying the invalidity of the transaction. However, this results in a loss of functionality within the blockchain because any transaction with OP_RETURN in its input script, when run with any unlocking script, will not result in "TRUE" (or valid) execution.

[0010] According to one aspect disclosed herein, a method for verifying the validity of a transaction for recording it in a blockchain is provided, the method comprising: receiving one or more transactions at a node in a blockchain network; applying a protocol for verifying the validity of the received transaction to each received transaction, wherein the protocol is configured to: allow a termination opcode to be included in the output script of the transaction, wherein the termination opcode is configured to, when executed by the node, a) terminate execution of the output script; b) not verify the invalidity of the transaction solely based on the inclusion of the termination opcode in the output script; and disallow any instance of the termination opcode to be included in the input script of the transaction, wherein if any instance of the termination opcode is included in the input script, the disallowing includes: the node at least verifying the invalidity of the transaction.

[0011] For each of a plurality of transactions including the target transaction, at least some nodes in the network are configured to propagate each transaction if it is valid, and at least some nodes are configured to record each transaction in a copy of the blockchain at that node if it is valid. The validity of a transaction depends on the aforementioned protocol, according to which only the script terminates when a specific opcode is invoked, and crucially, the transaction is not verified as invalid. For example, the validity of a transaction might depend on the top element of the stack.

[0012] For the sake of brevity, the termination opcode will be referred to as "OP_RETURN" hereinafter. However, this disclosure is not limited to opcodes with this particular label. More generally, while embodiments will be described according to "OP_RETURN" in the blockchain scripting language, the same teachings can be implemented using any opcode that, when called by a script engine (e.g., a script interpreter), executes a specific function to terminate script execution without verifying transaction invalidity. References to first and second instances of opcodes should be interpreted as instances of the same type of opcode.

[0013] The protocol enables the recovery of transactions by allowing the input script to be executed effectively when run together with the output script, while preventing fraudulent attacks by ensuring that any input script with OP_RETURN cannot be used to unlock any output script.

[0014] This node is configured to verify the validity or invalidity of transactions it processes based on the protocol described above. In other words, when a node processes a transaction, including OP_RETURN in the transaction's output script (or multiple output scripts) will cause the output script to terminate upon invocation of OP_RETURN. Including OP_RETURN in the output script does not verify transaction invalidity. The transaction may be invalid for some other reason. On the other hand, if OP_RETURN is included in the transaction's input script, the node is configured to always verify transaction invalidity. In this document, including OP_RETURN in any input script will verify transaction invalidity. In some examples, before executing the script, the node scans for any instances of OP_RETURN in the input script, and if any such instances exist, the node is configured to verify transaction invalidity, i.e., before executing the input script.

[0015] Each type of node in a blockchain network can implement the same protocol. A node in a blockchain network can be, for example, a mining node, a forwarding node, or a storage node, and each node has one or more of the same functions, as described below. For example, if a node is a forwarding node, it can forward a transaction to one or more nodes in the blockchain network only if the transaction is valid according to the protocol, which includes at least the condition that the OP_RETURN opcode is not present in any of the transaction's input scripts. Attached Figure Description

[0016] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0017] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0018] Figure 2The illustration shows some examples of transactions that can be recorded in the blockchain;

[0019] Figure 3 This is a schematic block diagram of another system used to implement blockchain;

[0020] Figure 4 This is a schematic block diagram of node software used to execute transactions;

[0021] Figure 5a An example of initiating a transaction Tx is shown. In Each input has a commitment r from the player;

[0022] Figure 5b An example oracle transaction Tx is shown. Oracle The output 0 transfers digital assets to the participant, and the output 1 generates a random number.

[0023] Figure 6a This example illustrates when the off-block script interpreter jumps to output point address 1 within output 0 of a composite function transaction;

[0024] Figure 6b An example of a composite function transaction is shown, which contains many possible jumps between its output points;

[0025] Figure 7 This is an example of the unpacking loop of a composite script function with input a = 105 and b = 28 in the Euclidean algorithm;

[0026] Figure 8 This is an example of elliptic curve dot multiplication with inputs 5 and G, where the ALT stack (shown in shaded) and the Main stack are shown side by side. Detailed Implementation

[0027] Figure 1An exemplary system 100 for implementing blockchain 150 is shown. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0028] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0029] At least some of the nodes in node 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some of the nodes in node 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storage node storing a corresponding copy of the same blockchain 150 in its respective storage. A given node 104 can be forwarding node 104, storage node 104S, or any combination of these nodes.

[0030] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the current transaction can be any transaction in pool 154 or any block 151. While the existence and verification of the previous transaction 152i are required to ensure the validity of the current transaction, the previous transaction 152i does not necessarily exist when the current transaction 152j is created or even sent to network 106. Therefore, in this context, "previous" refers to the predecessor in the logical sequence linked by the pointer, not necessarily the creation or sending time in the time series, thus not necessarily excluding the possibility of out-of-order creation or sending of transactions 152i or 152j (see the discussion of orphaned transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

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

[0032] The above can be referred to as an "output-based" transaction protocol, or sometimes as a protocol for unspent transaction outputs (UTXOs) (where the output is called a UTXO). A user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special "wallet" application 105 to organize all of the user's UTXO values, which are scattered across many different transactions 152 on the blockchain 151.

[0033] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction's amount is not defined by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored separately in the blockchain and is continuously updated. In such systems, transactions are ordered using the account's running transaction history (also known as "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0034] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could be another user terminal). This node 104 checks the validity of the transaction according to the node protocol applied at each node in the node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of output-based transactions, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i pointed to by the input of the new transaction. In some transaction protocols, conditions may be defined, at least in part, by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or through a combination thereof. Regardless of the approach, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0035] In the output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it has 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 attempted to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the output of the same transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0036] Node 104M, having solved the puzzle, announces its solution on network 106, providing proof of the solution. Other nodes 104 in the network can then easily check the solution (once a solution with a hash value is provided, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). Based on the winner's announced solution being checked at each of these nodes, the winner's pool of transactions 154 that solved the puzzle is subsequently recorded in blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. Block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, block 151 is immutable because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointer 155 also imposes ordering on block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0037] It should be noted that different nodes 104M vying to solve the puzzle at any given time may perform this operation based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they begin searching for a solution. The person solving the corresponding puzzle first defines the transactions 152 contained in the new block 151n and updates the current unmined transaction pool 154. Then, nodes 104M continue to compete to create blocks from the newly defined unmined pool 154, and so on. Furthermore, there are protocols for resolving any potential "forks," where two nodes 104M solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain. In short, the fork with the longest possible direction becomes the final blockchain 150.

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

[0039] Each node 104's memory stores software configured to run on the node 104's processing device to perform its corresponding role and process transactions 152 according to the node protocol. It should be understood that any action attributed to node 104 herein can be performed via software running on the processing device of the corresponding computer device. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0040] Each of the multiple parties 103 acting as consumer users has its computer device 102 connected to network 101. They act as payers and payees in transactions, but do not necessarily participate in mining or disseminating transactions on behalf of other parties. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for convenience, they are not shown. Each party 103 may be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0041] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0042] The client application or software 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0043] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the network of nodes 104 and thus included in the blockchain 150. The other function is to report the amount of digital assets currently held by the corresponding party. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant party scattered across the blockchain 150.

[0044] An instance of client application 105 on each computer device 102 is operatively coupled to at least one forwarding node among forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query in blockchain 150 any transaction for which the corresponding party 103 is the recipient (or actually check transactions of other parties in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of transaction 152 according to a node protocol and, in the case of forwarding node 104F, forward transaction 152 to propagate such transactions throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes within it). All nodes 104 in network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to rules defined for that subtype, and different nodes may also play different roles, thus implementing different corresponding aspects of the protocol).

[0045] As described above, blockchain 150 includes a series of blocks 151, each block 151 comprising a set of one or more transactions 152 created through the proof-of-work process as previously described. Each block 151 also includes a block pointer 155 pointing to previously created blocks 151 in the blockchain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154 awaiting inclusion in new blocks through the proof-of-work process. Each transaction 152 includes pointers to previous transactions to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more early original transactions 152 in blockchain 150 point to the genesis block 153, not to previous transactions.

[0046] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152j from client application 105 to one of one or more forwarding nodes 104F that it is connected to. For example, this could be the forwarding node 104F that is closest to or has the best connection to Alice's computer. When any given node 104 receives the new transaction 152j, it will process it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets specific conditions to become "valid," specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0047] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any storage node 104S that receives transaction 152j will add the new valid transaction 152 to pool 154 in the replica of blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0048] Once pool 154, which includes the new transaction 152j, completes its proof-of-work, it will immutably become part of a block 151 in blockchain 150. Each transaction 152 includes pointers to earlier transactions, so the order of transactions is also immutably recorded.

[0049] Different nodes 104 can initially receive different instances of a given transaction, and thus have conflicting views about which instance is "valid" before an instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts an instance as valid and then finds that a second instance has been recorded in blockchain 150, then that node 104 must accept this and discard (i.e., consider) its initially accepted unmined instance invalid.

[0050] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments.

[0051] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies the amount of digital asset (a store of value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this 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 original transaction 152.

[0052] For example, Alice 103a wants to create transaction 152j to transfer related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is labeled "Tx1". This new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to the next transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0053] When Alice creates her new transaction Tx1, or at least when she sends it to network 106, the previous transaction Tx0 may already be valid and included in blockchain 150. This transaction may at this point be included in a block of block 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network together; or, if the node protocol allows buffering of “orphaned” transactions, Tx0 may even be sent after Tx1. The terms “previous” and “subsequent” as used in the context of transaction sequences in this paper refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can also be replaced with “predecessor” and “successor,” “preceding” and “descending,” or “parent” and “child,” etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (preceding transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. According to the node protocol, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0054] One of the outputs 203 of a previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script. This locking script defines the conditions that the unlocking script in the input 202 of a subsequent transaction must meet for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following condition: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the previous transaction was locked.

[0055] A locking script (also known as 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 a "script" (S capitalized). The locking script specifies the information required for the spend transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0056] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). AThis is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A Input 202 of Tx1 includes a pointer to Tx0 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index in Tx0 that identifies UTXO0, so as to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0057] When a new transaction Tx1 arrives at node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves concatenating two scripts:

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

[0059] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when run together, the scripts use Alice's public key P. A (Included in the locking script at the output of Tx0) to authenticate whether the locking script at the input of Tx1 contains the signature when Alice signs the expected portion of the data. The expected portion of the data itself (“message”) also needs to be included in Tx0 in order to perform this authentication. In this embodiment, the signed data includes the entire Tx0 (therefore, it is not necessary to include a separate element to plaintext specify the portion of the signed data, as it already exists on its own).

[0060] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), other entities such as Node 104 must have already signed the encrypted version of the message to authenticate it. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a specific data segment or transaction portion, etc., can mean signing the hash value of that data segment or transaction portion.

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

[0062] 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 failure criterion in most transaction models. Therefore, such a transaction will not be propagated or mined into block 151.

[0063] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount in a UTXO can be divided among multiple outputs of the next transaction. For example, the amount defined in UTXO0 of Tx0 can be divided among multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob all the amount defined in UTXO0, she can use the remaining amount to make change herself in the second output of Tx1, or pay the other party.

[0064] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the various UTXOs of transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The wallet function of the client application 105 serves to consolidate the various UTXO values ​​locked to the respective party and not yet spent in other subsequent transactions. This is achieved by querying a copy of blockchain 150 stored at any storage node 104S (e.g., the storage node 104S most recently or best connected to the respective party's computer device 102).

[0065] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, it might be written as [ChecksigP A ] indicates [Checksig P A ] = OP_DUP OP_HASH160 <H(P A OP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by the 'sig' input. Similarly, OP_RETURN is a scripting language opcode used to create a non-spendable output for a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0066] Signature P AThis is a digital signature. In this embodiment, it is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific data segment. In this embodiment, for a given transaction, the signature will sign part of the transaction input and all or part of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the output to be signed (and therefore fixed at the time of signing).

[0067] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature authentication. Furthermore, scripting languages ​​can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0068] Verification Agreement

[0069] Figure 4 An example of node software 400 that can run on each node 104 of a P2P network 106 is shown, in examples of UTXO-based or output-based models. Node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a collection of one or more blockchain-related functional modules (not shown). At any given node 104, these modules may include any one, two, or all of the following three modules: a mining module, a forwarding module, and a storage module (depending on one or more roles of that node). Script engine 402 may include a script interpreter configured to execute the script by interpreting portions of the script as data elements or functions for manipulating these data elements and / or pushing or reading data elements from stack 403. Alternatively, script engine 402 may employ another form of execution, such as Just-In-Time (JIT) compilation. Generally, the term “execution” as used herein is used in the broadest sense of running a script in any way (rather than the narrow sense of executing compiled machine code instructions). Therefore, “execution” can include interpretation in the current context. In addition, it should be noted that the “opcode” in the current context does not refer to the opcode of a single machine code instruction, but rather to the higher-level command mapped by the script engine 402 at each node 104 to the corresponding predefined function.

[0070] Protocol engine 401 is configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a field pointing to another previous transaction 152m-1(Tx) is received... m-1The output (e.g., UTXO) of the input transaction 152m (Tx) m When ), the protocol engine 401 identifier Tx m The unlock script is then passed to script engine 402. Protocol engine 401 is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 stored on the corresponding node or another node 104 in blockchain 150. Regardless of the method used, protocol engine 401 will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 402.

[0071] Therefore, script engine 402 has Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example, Figure 4 The examples shown are Tx1 and Tx2, but the same applies to any trading pair, such as Tx0 and Tx1. As previously mentioned, script engine 402 runs two scripts simultaneously, which will include placing data onto stack 403 and retrieving data from that stack according to the stack-based scripting language being used (e.g., script).

[0072] By running the scripts simultaneously, the script engine 402 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 402 returns this determination to the protocol engine 401. If the script engine 402 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0073] In output-based models, a "TRUE" result from the script engine's 402 check is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by the protocol engine must also be met; for example, Tx m The total amount of digital assets pointed to by the input does not exceed the total amount specified in the output, and Tx m-1 The output pointed to by the value has not yet been spent by another valid transaction. The protocol engine evaluates the result from the script engine 402 along with one or more protocol-level conditions, and only when all of them are TRUE does the protocol engine verify the transaction Tx. mValid. The protocol engine outputs an indication of whether the transaction is valid to the application-level decision engine (404). Only in Tx m Only under verified and valid conditions can the decision engine 404 select one or both of the control mining module and the forwarding module to execute their Tx-related operations. m The corresponding blockchain-related functions. This can include: a mining module, which will process Tx m Add to the corresponding pool 154 of the node to mine block 151; and / or the forwarding module, which forwards Tx m The transaction is forwarded to another node 104 in the P2P network 106. However, it should be noted that in this embodiment, while the decision engine 404 does not choose to forward or mine invalid transactions, this does not necessarily mean that the decision engine must trigger the mining or forwarding of a transaction simply because it is valid. Optionally, in this embodiment, the decision engine 404 may apply one or more additional conditions before triggering one or both of these functions.

[0074] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model ( Figure 4 In (not shown), the result can be indicated as "TRUE" by a combination of the implicit protocol-level verification of the signature by node 104 and the additional positive output of the smart contract (if both individual results are TRUE, the overall result is considered TRUE).

[0075] According to some embodiments, a condition for a valid transaction is that the transaction's unlocking script cannot contain any instance of the OP_RETURN opcode, or any other such termination opcode that marks the transaction as invalid. Protocol engine 401 and / or script engine 402 are configured to detect the presence of such opcodes within the transaction's unlocking script. Upon detecting a termination opcode in the unlocking script of a transaction (e.g., Tx2), protocol engine 401 is configured to mark the transaction as invalid. If a termination opcode is detected in the unlocking script, the transaction is immediately marked as invalid—the script will never be executed.

[0076] In additional or alternative embodiments, the node software includes an off-chain function 405. In this document, the protocol engine 401, script engine 402, and application-level decision engine 404 may be referred to as "on-chain" functions. "On-chain" does not mean that the function is actually included in block 151. Rather, it means that the function is integrated as part of a protocol used to verify the validity of transactions to be propagated on network 106 and mined into block 151. Conversely, "off-chain" means that the function's purpose differs from verifying block validity. In some examples, the function's purpose is to generate new transactions, generate template scripts including composite functions, or perform computations on data obtained from (or generated by) transaction Tx.

[0077] In these embodiments, script engine 402 is configured to provide data elements from stack 403 (e.g., from the top of the stack) to off-chain function 405. Script engine 402 is configured to, in the event of a transaction call ( Figure 4 When OP_RETURN is invoked in the locking script of Tx1, a data element is read from stack 403. 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 stack 403 and recorded on an "off-chain stack." In this document, the "off-chain stack" is a stack not used to verify the validity of a transaction. Each time OP_RETURN is invoked, the script engine 402 can read a data element from stack 403 and provide it to the off-chain function. The off-chain function 405 can be configured to generate a new transaction using the data element recorded on the off-chain stack. In other examples, the off-chain function 405 is configured to use the data element as a reference to the locking script within Tx1. Figure 4 As shown, Tx1 includes multiple locking scripts 1 to n. Off-chain function 405 interprets a data element as the address or index of a locking script (e.g., as the index of a third locking script) and then executes that locking script. Additionally or alternatively, the addressed locking script can be added to a script template stored in memory.

[0078] As mentioned above, a transaction must meet several requirements to become a valid transaction, and thus be propagated and mined throughout the blockchain. Embodiments of the present invention relate to the implementation of a modification to the protocol that specifies the conditions for transaction validity. This modification involves including a specific type of opcode in the transaction.

[0079] Blockchain protocols use scripting languages, which consist of two types of elements: data and opcodes. Data within a script can be, for example, numbers, public keys, signatures, hash values, etc. Opcodes are functions that perform operations on the data within the script. In scripting languages, scripts run from one end to the other (typically from left to right) using a data structure called a "stack." Data is always pushed onto the stack. Opcodes can pop data from the stack, perform operations on the data, and then optionally "push" new data onto the stack. Stack-based scripting languages ​​commonly used in many blockchains are called scripts. The opcodes of scripting languages ​​will be described below.

[0080] Those skilled in the art will be familiar with stack-based scripting languages. The following example illustrates an exemplary script implementation. Specifically, an exemplary verification and unlocking process is shown.

[0081] An exemplary script may include <Bob's signature> <Bob's public key> OP_DUP OP_HASH <Bob's public address> OP_EQUALVERIFY OP_CHECKSIG. The script operates from left to right.

[0082] Step 1: Push <Bob's Signature> onto the stack

[0083] <Bob's signature>

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

[0085] <Bob's public key> <Bob's signature>

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

[0087] <Bob's public key> <Bob's public key> <Bob's signature>

[0088] Step 4: Pop the OP_HASH opcode and run <Bob's public key> through a hash algorithm (followed by one or more optional operations) to obtain <Bob's public address> and place it on the stack.

[0089] <Bob's public address> <Bob's public key> <Bob's signature>

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

[0091] <Bob's public address> <Bob's public address> <Bob's public key> <Bob's signature>

[0092] 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 if these two addresses are the same. If they are not the same, the execution is considered to have failed. If the condition is TRUE, the next command is executed.

[0093] <Bob's public key> <Bob's signature>

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

[0095] TRUE

[0096] A specific opcode is the OP_RETURN opcode. In the original blockchain protocol, OP_RETURN has only one main function, used to terminate the execution of the script. This means that no operations are performed after executing the OP_RETURN opcode, and the final state of the stack will be exactly the same as the state when the OP_RETURN operation was executed. For example, when executing the script [ <x>OP_RETURN <y>When [the script element is executed], it will never be executed. <y>And the script will terminate, where <x>Keep it at the top of the (Main) stack.

[0097] However, this protocol is vulnerable to two types of attacks:

[0098] 1) Any locking script that starts with OP_RETURN can be redeemed using the unlocking script [OP_1] or an unlocking script with the same effect, where the top item on the stack is "true".

[0099] 2) Any locking script can be redeemed using the unlocking script [OP_1OP_RETURN] because the locking script will not be executed (i.e., it follows OP_RETURN).

[0100] To mitigate the aforementioned attacks, subsequent protocols (existing protocols) modified the OP_RETURN function to terminate script execution and cause it to fail. This is achieved by first marking the script as invalid and then terminating execution. The advantage of this is that OP_RETURN can be used to create provably unspendable output, because any locking script containing OP_RETURN will not result in "TRUE" execution when run with any unlocking script. For a transaction to be valid, "TRUE" execution needs to be implemented (i.e., the top element on the stack represents a TRUE result, such as the value 1).

[0101] This property of existing protocols has two main impacts on the use of blockchain:

[0102] 1) Data storage—Any data following OP_RETURN will not be processed by the verifier. This means it can have any type and format without compatibility with the constraints of stack-based scripting languages. For example, the 520-byte limit typically applied to data elements in scripts does not apply before OP_RETURN.

[0103] 2) Pruning—Since any OP_RETURN output is provably unspendable, there is no real incentive to retain data associated with these outputs. This leads to the selective pruning (i.e., not retaining) of OP_RETURN UTXO data or metadata.

[0104] According to an embodiment of the present invention, the new protocol implemented by the node imposes at least two conditions on the use of OP_RETURN:

[0105] 1) Allow OP_RETURN to be included in the output script of valid transactions.

[0106] 2) OP_RETURN is not allowed to be included in the input script of a valid transaction.

[0107] Now, according to the embodiment, the OP_RETURN function is used to terminate script execution without verifying transaction invalidity. In other words, when OP_RETURN is now called, the script pauses, and the stack remains unchanged.

[0108] When verifying a transaction's validity, the node will not verify its invalidity solely based on the presence of OP_RETURN in the output script of the transaction's output 203. Instead, the node will verify its invalidity solely based on the presence of OP_RETURN in the input script of the transaction's input 202. If a transaction has more than one input, it is sufficient for the node to verify its invalidity if only one of these inputs has an input script containing OP_RETURN. If the locking script includes OP_RETURN, the transaction will never be executed—it will be verified as invalid without execution.

[0109] Reference Figure 1 The first-party Alice 103a can generate transactions that include one or more inputs and / or one or more outputs. For example... Figure 2 As shown, each input can have an unlock script to unlock the locking script of a previous transaction. Each output can have a locking script to lock the digital asset amount to a corresponding second party, such as Bob 103b, which will be unlocked via the unlock script of a subsequent transaction. Alice 103a transmits the transaction to nodes in the P2P network. Forwarding node 104F checks the validity of the transaction before propagating it to one or more other forwarding nodes or mining nodes 104M. Alternatively, mining node 104M can receive the transaction directly from Alice 103a. Each node determines the validity of the transaction based at least on the above protocol. If the transaction meets the protocol's requirements regarding the use of OP_RETURN (and one or more other requirements of the protocol), the transaction will be propagated throughout the network and / or mined into the blockchain.

[0110] In some embodiments, only OP_RETURN may be allowed to be included in the lock script of a transaction. Similarly, in some embodiments, only OP_RETURN may not be allowed to be included in the unlock script of a transaction. As described above, each transaction includes: one or more inputs, each input may have an unlock script; and one or more outputs, each output may have a lock script. The unlock script of a given transaction unlocks the lock script of a previous transaction.

[0111] When implementing the protocol, if a node verifies a transaction's validity, it means that, in addition to meeting other conditions, the transaction will not contain any OP_RETURN in any of its input scripts. Verifying the transaction's validity results in a non-empty and non-zero result on the stack after executing the combination of the transaction's unlock script and the locking scripts of different transactions. Alternatively, verifying the transaction's validity may cause a node to forward the transaction to one or more nodes in the network. Another result of verifying the transaction's validity could be that the transaction is mined (i.e., recorded) into a block on the blockchain.

[0112] The protocol defined in this document advantageously prevents fraudulent attacks while maintaining compatibility with existing blockchain functionality (i.e., data storage applications). Fraudulent attacks are prevented by ensuring that OP_RETURN does not exist in the unlocking script of a transaction. Existing functionality can be prevented by including OP_RETURN before OP_RETURN in the transaction's output (e.g., the locking script). <0> To achieve this. Here. <0> This is any element that causes a zero value to be pushed onto the stack. For example, the zero opcode OP_0 can be placed before OP_RETURN. This will create a provably unspendable transaction output by inserting [OP_0OP_RETURN<arbitrary data>] into the transaction's locking script. For example, arbitrary data can be one or more of image data, text data, video data, and audio data. For example, a video file or a legal document can be included in the transaction's output.

[0113] A further advantage of allowing OP_RETURN to be executed efficiently in the output script is the provision of off-block (or off-chain) functionality, as described below.

[0114] Before OP_RETURN is called (or executed), script elements in the lock script (i.e., script elements executed before OP_RETURN) can be used as input to off-chain functions. In other words, when the lock script is executed, data is retained on at least one stack (e.g., the Main stack or the ALT stack). This data can be read from the stack and provided to functions for off-chain use.

[0115] For example, the function can generate a new transaction based on data read from the stack. Data can be read from the stack and recorded on the "Return" stack (i.e., a stack independent of the Main stack and the ALT stack).

[0116] As another example, data retained on the stack can be used as a reference to another part of a transaction. For instance, data can be interpreted by the function as an index (or address) of an output in the transaction. The function can then execute a locking script contained in the referenced output. In this sense, the function acts as an "off-chain script interpreter" for identifying and executing locking scripts. The function can also be used to create off-chain loops.

[0117] Generate new transactions

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

[0119] For example, the function can generate at least a portion of one of the inputs to a new transaction (e.g., a public key, signature, random variable). Additionally or alternatively, the function can generate at least a portion of one of the outputs to a new transaction (e.g., the amount of digital assets to be transferred).

[0120] The new transaction may include the output of a locking script. This locking script may include a portion of a script to be executed before calling OP_RETURN. At least a portion of the locking script may be based on data elements provided to the off-chain function. Similarly, when OP_RETURN is called, the locking script terminates, and the new data elements remain on the stack. These data elements can be read from the stack and provided to the off-chain function, for example, to generate further transactions. This makes it possible to construct a transaction cycle where each of the further transactions is based on data elements produced by the locking script that executed the previous transaction.

[0121] In an exemplary blockchain script, there are two stacks: the Main stack and the ALT stack. When verifying transactions, the script is executed on these stacks. During execution, it is impossible to write anything to the stack except for pre-defined script content. However, this paper recognizes that data can be read from the stack immediately after execution ends using external functions (or proxies). The use of a third stack—an off-chain stack called the "Return stack"—is described below. The function of the Return stack is to read and record data from the Main and ALT stacks after script execution, for example, to connect the blockchain to the outside world. The data stored on the Return stack can then be fed to off-chain functions to provide additional functionality, such as feeding it into the next script execution, generating new transactions, or performing certain other off-chain computations. While using the term "stack," any data storage configured to store data read from the Main or ALT stack can be used.

[0122] Use Case — Rolling Dice

[0123] Below is an example simulating a game called "Rolling Dice" to illustrate the interaction between the Return stack and blockchain transactions. This example involves two entities: the dealer, Charlie; and the player, Alice. Each of these entities can be a corresponding party 103. In this simplified example, the game of rolling dice is played as follows: a player (i.e., the "shooter") takes out two dice and rolls them onto the dice table—or, if rolling dice online, presses the "Roll" button.

[0124] After rolling the first number, there are three possible outcomes:

[0125] 1. Natural – “Natural” means rolling a 7 or 11. When this happens, the player wins and rolls the dice again.

[0126] 2. Rolling the dice – This means rolling a 2 (also called a two), 3, or 12. When this happens, the player loses the game.

[0127] However, the game is not over yet, and the players will roll the dice again.

[0128] 3. Game Point—A player rolls a 4, 5, 6, 8, 9, or 10. In live games, the dealer marks the "game point" (the number rolled) on the table. In online dice games, once the game point is established, a small button appears. This button is usually white and displays "Open." The player now needs to roll the dice again and hopes to hit the same number again. It doesn't have to be the same combination as the previous roll. As long as the sum is the same, the player wins. If a player rolls a 7, the player faces "Seven Out"—the player loses the game and ends their stakes for that round.

[0129] To further simplify the game, in this example, the result of "Nature" and "Rolling Dice" will end the game. Consider the initial transaction TX0 created by Alice and Charlie below.

[0130]

[0131] TX0 Notes:

[0132] 1) There are two inputs in TX0: Alice's venture capital and Charlie's venture capital.

[0133] 2) TX0 has two outputs: each output represents a die. These two outputs can be combined into one output. However, having two outputs emphasizes that there are two dice, and also emphasizes that more than one person will "roll" the dice.

[0134] 3) Assume Alice is the only player rolling the dice. In other words, Alice knows the private keys of PK1 and PK2. To allow other players to roll the dice, PK2 can be replaced with a public key chosen by another player.

[0135] 4) To prevent Alice from cheating, Alice's public key can be replaced with a 2-out-of-2 multi-signature. In this case, Alice and Charlie's signatures are required.

[0136] 5) Each output contains two OP_IF statements. If the top stack value is not FALSE, the statement is executed. The top stack value is then removed.

[0137] a. The first step is to check the validity of the signature. If TRUE, continue "rolling the dice". If TRUE, Charlie can declare an output. It should be noted that this assumes Charlie is trusted by the player. If this is not the case, a time-locking mechanism can be implemented to ensure Alice has priority in declaring an output.

[0138] b. The second method is used to check the validity of the random string provided in the unlocking script. This can be done by checking the string's prefix using a hash puzzle. For example:

[0139] i.[CHECK_RANDOM_STRING]:="get_first_4_bytes OP_HASH<pre-determinedhash value> OP_EQUAL”.

[0140] c. If the random string is invalid, Charlie can declare the output.

[0141] 6) Assuming the random string is valid and indeed random, then the script "OP_HASH" <6> "OP_MOD" will generate a number in the range {0, 1, 2, 3, 4, 5} with almost equal probabilities. These results represent the six possible outcomes of rolling the dice {1, 2, 3, 4, 5, 6}.

[0142] To simulate rolling dice, Alice needs to build two unlock scripts. Then, Alice passes this incomplete transaction TX1 to Charlie. Charlie completes transaction TX1 by adding two random strings.

[0143]

[0144] Assuming PK betpool Controlled by the dealer, and Charlie is trusted to provide two new random strings.

[0145] After verifying that TX1 is valid, one of the scripts will execute as follows:

[0146] <random_string_1> <sig1> <pk1>

[0147] OP_DUP OP_HASH<Hash of PK1> OP_EQUAL OP_CHECKSIG

[0148] OP_IF

[0149] [CHECK_RANDOM_STRING]

[0150] OP_IF

[0151] OP_HASH <6> OP_MOD OP_RETURN

[0152] OP_ELSE

[0153] OP_DUP OP_HASH <Hash of PK Charlie >OP_EQUALVERIFY

[0154] OP_CHECKSIGVERIFY

[0155] OP_END_IF

[0156] OP_ELSE

[0157] OP_DUP OP_HASH <Hash of PK Charlie >OP_EQUALVERIFY

[0158] OP_CHECKSIGVERIFY

[0159] OP_ENDIF

[0160] When OP_RETURN is invoked, the existing version of OP_RETURN terminates the script and verifies that the transaction is invalid. However, in the OP_RETURN implementation by the node in the embodiment described herein, OP_RETURN marks the transaction as valid and leaves a number on the stack after execution and before clearing the stack. The number left on the stack is read and stored on the Return stack.

[0161] Suppose Alice has rolled a and b, where a, b ∈ {1, 2, 3, 4, 5, 6}. All dice rolling rules can be implemented in a script used for off-chain evaluation (e.g., an off-chain function). The pseudocode is shown below:

[0162] 1) If (a+b) = 7 or 11, then it is "natural".

[0163] 2) If (a+b) = 2, 3 or 12, then it is "rolling dice".

[0164] 3) Otherwise, save (a+b) on the Return stack and save the "local point".

[0165] Each result corresponds to a new transaction. The result transactions can be constructed by interpreting the results of the Return stack:

[0166] ●Natural—The transaction simply involves paying Alice the winning reward from the output in TX1.

[0167] ● Roll the dice—the transaction will redeem the output in TX1: that is, pay Charlie.

[0168] ● Game Point - The trade will create another trade similar to TX1, which will allow Alice to roll the dice again.

[0169] It should be noted that in this exemplary use case, the game ends in the case of a natural transaction or a dice roll transaction; the game continues in the case of a point transaction. Most importantly, the output of the first dice roll (the sum of a and b) is stored in the Return stack. In other words, the result is a data element read from the stack and stored on the Return stack. Then, the output of the second dice roll is compared with a+b. If they are equal, a transaction is created for Alice to claim the reward. If they are not equal, another transaction, TX0, is created for Alice to roll the dice again.

[0170] In summary, complex while loops can be simulated by using a Return stack. It should be noted that this loop exists off-chain; playing dice is an example of how to implement such a loop. The use of the Return stack can be generalized to many other applications, as shown in the following examples.

[0171] Use Case—Jury Selection

[0172] This example illustrates a method for implementing random number generation (RNG) using a set of N participants in a blockchain script. This method involves at least two transactions:

[0173] a) Initiate (first) transaction Tx In —Each participant adds inputs to and signs the transaction, including a public commitment to the secret value s. The transaction then pays its digital assets to the oracle.

[0174] b) Oracle (Second) Trading Tx Oracle —The oracle (off-chain function) obtains the secret value s from each player and generates a transaction. The locking script of this transaction combines the secret values ​​of all N players to generate a random number R. N (First data element), and lock the digital asset to the public key based on that number.

[0175] The random number R generated in the locking script of the oracle transaction. N This can be used to determine the conditions under which these digital assets are spent in subsequent redemption transactions. However, due to R... N It is provably pseudorandom, and therefore can be used to seed other off-chain processes, such as laboratory experiments that require seeds to complete deterministic processes. In particular, the solution can be utilized for provably fair jury selection procedures in criminal trials.

[0176] This type of locked script is executed by introducing a Return stack and the final random number R is obtained. N Returning to the off-chain interpreter further facilitates the use of provably fair random numbers in off-chain jury selection generated by on-chain locking scripts.

[0177] In legal proceedings for criminal cases, the court can be responsible for selecting the jury, thereby randomly selecting the jury to ensure that the jury is not "bribed" or subject to unfair bias in any way. The court can operate hardware and software capable of running an off-chain return stack. Furthermore, the court can read data from the blockchain, execute transaction scripts, and store the results of these executions in its local return stack. The court-defined process for selecting a jury from a pool of N possible jurors is derived from random numbers generated using the aforementioned on-chain methods. However, the court does not need to participate in the generation process itself, but rather acts as a third-party observer of the blockchain; in this case, the RNG process is run by another third party T (e.g., a lottery company).

[0178] The following process occurs each time a jury is selected for a criminal trial:

[0179] 1) The court requires service provider T to provide the on-chain RNG process:

[0180] a. Initiating a transaction Tx involving N participants In Organized and broadcast by T;

[0181] b. Oracle Trading Tx Oracle Generated and broadcast by T.

[0182] 2) The court retrieves Tx from the blockchain. In and Tx Oracle .

[0183] 3) The court uses the unlock script to execute Tx Oracle Locking script:

[0184] a. Unlock script via Tx In Extract all r values ​​to generate;

[0185] b. Unlock script from Tx Oracle Extract from.

[0186] 4) Move the top (Main) stack item R N (The first data element) is copied to the court's Return stack and stored.

[0187] 5) The court's Return stack (off-chain stack) is used for jury selection. For example, items in the stack are fed to an off-chain function, which generates a random number R. N The consecutive hash values ​​are then mapped to the IDs of qualified citizens.

[0188] To achieve step 4, OP_RETURN must be included in Tx Oracle The locked script allows it to be used to terminate script execution in step 3. Additionally, OP_RETURN is required to have the functionality to terminate execution and verify transaction invalidity, ensuring that the top stack item is R when script execution terminates. N If OP_RETURN is changed to verify that the transaction is invalid, the court interpreter will encounter an error upon termination instead of the required random number.

[0189] The transactions involved in this scenario are as follows: Figure 5a and Figure 5b As shown.

[0190] The court can determine the origin of the transaction from Tx. in Extract the commitment list r1,…,r from the input. N And use them as unlocking scripts during step 3 of the jury selection process:

[0191] [Unlock Script] = <r1> <r2>… <r N >

[0192] Similarly, the court seized oracle transaction Tx. Oracle The locking script outputs 1, which is written as:

[0193] [Locked Script] =<H(r1)><H(r2)> … <H(r N )>OP_EQUALVERIFY…OP_EQUALVERIFY

[0194] <s1> <s2>… N >OP_ADD…OP_ADD OP_HASH256 <n>OP_MOD

[0195] OP_RETURN

[0196] The first line of the locking script checks if the promised value 'r' matches the value of the initiating transaction. Then, the second line uses the secret value 's' promised by the value 'r' to generate a random number 'R' during script execution. N Finally, the third line is simply an OP_RETURN call, which causes the script execution to terminate and therefore R... N Keep it at the top of the Main stack.

[0197] In step 3 of the jury selection process, the court will simultaneously execute the aforementioned locking and unlocking scripts, which will return a random number R. N Or execution may fail. In the event of successful execution, the court can read a random value from the top of the Main stack and store it in the Return stack on the local computer.

[0198] Then, the value R N Used to select juries in a provably fair manner. Each time jury selection is required, and Tx In and Tx Oracle The generation process can be repeated each time it is overseen by the court or outsourced to a third party.

[0199] The main advantage of this approach is transparency. The public will be able to read the transactions on the blockchain to prove that the process is indeed random and unbiased.

[0200] Composite function

[0201] In some embodiments, a first transaction (hereinafter referred to as the previous transaction) may have multiple outputs, each containing 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 output point address. This address may be a number used to index the position of the output within the transaction. At least one of the outputs has a locking script that includes the output address referencing another output within the outputs. For example, the locking script may contain a number (e.g., 2) or an opcode (e.g., OP_2) that, when coupled with OP_RETURN, can be interpreted as the address of a second output (e.g., a second output in the output list).

[0202] A second transaction (hereinafter referred to as a new transaction or further transaction) generated at some point after the first transaction includes one or more inputs, each with an unlock script. At least one of these unlock scripts references an output of the previous transaction (hereinafter referred to as the first output or main output). The first output does not necessarily have to be the first output in the list of outputs of the previous outputs; the label "first" is only used to indicate that the output is the first output to be invoked.

[0203] When the unlock script is executed, the lock script for the first output is referenced and executed. The lock script for the first output includes at least the output address (OA) of the outputs in the same transaction (i.e., a data element that can be interpreted as an output address). The output can be the same output (i.e., the first output) or a different output (e.g., the second output). In this document, the second output does not necessarily mean that the second output is the second output in the previous output list, although this may be the case. The label "second" is only used to indicate that the output is the second output to be invoked. The lock script for the first output also includes at least the OP_RETURN opcode. The lock script may also include additional data elements or opcodes.

[0204] Because OP_RETURN is configured to terminate script execution without verifying transaction invalidity, the output address of the second output will remain on the stack when OP_RETURN is called. In some examples, the output address in the locking script immediately follows OP_RETURN, meaning 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).

[0205] The function can then execute the locking script as a second output. It's important to note that, unlike typical locking script execution, the second output locking script is not executed alongside the unlocking script. This is because this function is "off-chain," and therefore the purpose of executing the locking script is not to verify the transaction's validity by transmitting it to nodes in the blockchain network that have mined it. Instead, an advantage is the ability to construct the script, for example, within the locking script or a smart contract.

[0206] The locking script for the second output can also include an output address, such as the output address of the third output, followed by OP_RETURN. Again, the term "third" used herein serves as a label to distinguish the first from the second and does not imply the order of outputs in previous transactions. However, it is not excluded that the first, second, and third outputs are part of an ordered sequence of outputs from previous transactions. In this case, when the locking script for the second output is executed, the output address of the third output is pushed onto the stack. The output address can 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 can then use the third output address to reference the locking script for the third output.

[0207] The execution of the locking scripts can be repeated once or multiple times. Whenever OP_RETURN is called, the data element at the top of the stack is interpreted as the output address of one of the outputs. One or more outputs from previous transactions can be executed multiple times. The process may end after each locking script in the corresponding locking script of the output is executed. In some examples, not every output from a previous transaction is referenced by the unlocking script of a second transaction or the output of the first transaction.

[0208] Each time a lock script is referenced, that lock can be copied to the script template, i.e., the "script to be executed". After the off-chain function has completed executing all referenced lock scripts, the script template will include the contents of the referenced lock scripts, not the OP_RETURN opcodes in those lock scripts. In other words, the script template has a script with all loops unpacked, which can be used to build a lock script for a new transaction without OP_RETURN.

[0209] In other words, suppose there exists a first transaction containing multiple outputs, and a second transaction that references one of the outputs of the first transaction. The following steps can be performed.

[0210] Step 1: Check if OP_RETURN exists in the referenced output locking scripts. If it exists, extract all locking scripts from the first transaction and index them accordingly.

[0211] Step 2: Assuming OP_RETURN does exist, copy the unlock script and the lock script referenced by the unlock script into the script to be executed.

[0212] Step 3: Execute the script to be executed.

[0213] Step 4: When OP_RETURN is called, use the first element on the stack.

[0214] Step 5: Assuming the first element used is a valid index, the locking script referenced by the element used by OP_RETURN in Step 4 is now copied to the beginning of the script to be executed.

[0215] Step 6: Continue execution.

[0216] For example, the first transaction could have the following locking script:

[0217] Locking script 1: [function 1] OP_2 OP_RETURN

[0218] Lock script 2: [function 2]

[0219] Locking script 3: OP_1OP_RETURN

[0220] The second transaction can have an unlock script for locking script 3: x

[0221] Therefore, there are 3 locking scripts in the first transaction and 1 unlocking script in the second transaction, which references the third output in the first transaction. Functions 1 and 2 are functions in the corresponding locking scripts; for example, these functions can push and / or manipulate data on the stack. Functions 1 and 2 are executed because locking script 3 is executed first, making it possible to execute locking script 1 (which contains function 1), and then making it possible to execute locking script 2 (which contains function 2).

[0222] In order to execute the transaction:

[0223] 1. Push x onto the stack.

[0224] 2. Execute the locking script 3

[0225] 3. Call lock script 1

[0226] 4. Execute function 1

[0227] 5. Call lock script 2

[0228] 6. Execute function 2

[0229] 7. Execution complete

[0230] When OP_RETURN is called, the unlock script is not re-executed, nor are any other unlock scripts executed. The execution of the locking script is off-chain.

[0231] Off-chain functions act as out-of-block (or off-chain) script interpreters. These interpreters help users build complex scripts for implementation in locked scripts and smart contracts. On-chain, OP_RETURN is configured to terminate script execution when called during the validity of any transaction, without verifying transaction validity. Off-chain, out-of-block script interpreters add new functionality to OP_RETURN. This new functionality uses OP_RETURN to construct compound script functions containing loops. Some blockchain scripting languages ​​do not allow loops. Therefore, any loops in the constructed function are unpacked before being placed into the locked script.

[0232] Off-chain functions utilize a single transaction with multiple output points (output points and outputs are interchangeable). The out-of-block definition of OP_RETURN will allow a jump from one output point in a transaction to another, where the output point index given by the top item of the stack is used to indicate the output point to jump to.

[0233] This is like Figure 6a and Figure 6b As shown, and can be described as follows:

[0234] Each output point in a transaction contains a locking script. This locking script can be viewed as a single function for each output point. Each output point is referenced by a unique Open Access Script (OA), which is an index of the output points within the transaction.

[0235] There is an output point that can be considered the "main" function and is executed first. For example, this might be the last output point of a transaction.

[0236] It should be noted that transaction output points are indexed starting from 0. 0 is a special value that is typically reserved for failed scripts when followed by OP_RETURN. For simplicity, the following will assume that output points are indexed starting from 1.

[0237] When OP_RETURN is executed, the out-of-block script interpreter jumps to the OA given by the top item on the stack, adds the opcode from the locked script to the instruction set, and then continues execution. The Main stack and ALT stack remain unchanged except for popping the top item.

[0238] like Figure 6a and Figure 6b As shown, the script interpreter performs the following tasks:

[0239] ● Input: <oa>

[0240] ● Operator: OP_RETURN

[0241] ●Output: [From <oa>[Locking script], using <oa>.

[0242] It is important to emphasize that, except for executing OP_RETURN, the script interpreter is the same as the script interpreter used to verify the validity of the transaction. This construction allows transactions to be interpreted as templates for compound functions within the script. Where functions can be compiled, they could be written in a single output point, where all loops must be unpacked, resulting in a complex and lengthy piece of code. However, in embodiments of this invention, all logic is contained within separate output points of the transaction, which can be much smaller. This logic is easier to understand and more closely related to Forth. More specifically, this improves code readability, reduces the codebase, and allows for unit testing.

[0243] If unspent, this form of transaction is stored in a UTXO collection, which can be considered a general-purpose "memory" in terms of recording data for future reference. The transaction contains everything needed to build a composite function—no other high-level language is required. This will implement a universally accepted set of composite functions. This is particularly useful for functions that may be repeated in many applications, such as the elliptic curve dot multiplication described below.

[0244] This also allows the UTXO collection to be used as a decentralized repository of Turing-complete code snippets. Besides storing a set of useful composite functions, the repository can be used to outsource computationally difficult but easily verifiable processing. The solution to such computations can then be migrated to the blockchain, where digital assets can be redeemed by providing an exact solution that can be verified in a script. Another possible use case is using the UTXO collection as a decentralized repository for smart contracts.

[0245] To avoid spending such transactions in the UTXO set, the transaction creator, Alice, could add `OP_CHECKSIGVERIFY` (requiring her signature) at the beginning of the locked script. This part can be safely ignored when interpreting the script. Alternatively, a partial transaction could be constructed containing output points as described above but without inputs, which would be sufficient to define the function. After Alice is satisfied with using the composite function, the transaction can be completed and either committed or discarded.

[0246] Use Case—Euclidean Algorithm

[0247] For example, a transaction TX_[Euclidean_algorithm] can be generated with two output points that make up the Euclidean algorithm. The inputs to the transaction are left blank to emphasize the output points.

[0248]

[0249] The Euclidean algorithm takes two inputs (ab) and outputs the greatest common divisor (GCD) of a and b. For simplicity, assume a > b.

[0250] It should be noted that, according to the design, whenever "" is called When "OP_RETURN" is executed, the out-of-block interpreter replaces these two items with those stored in i. th Output the entire script at the point. The loop function is implemented via i. th Set " in output point" This is achieved using "OP_RETURN". In this use case, the final output point of the transaction is the main function, which will be called first. <1> Any call to "OP_RETURN" will be replaced with "OP_TUCK OP_MOD OP_DUP OP_IF". <1> OP_RETURN OP_ENDIF. Figure 7 The example is shown below. Follow the steps below:

[0251] 1) First, push the input onto the stack.

[0252] 2) Call the main function <1> OP_RETURN OP_DROP.

[0253] 3) Put " <1> OP_RETURN" replaced with "OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF.

[0254] 4) Execute "OP_TUCK OP_MOD OP_DUP OP_IF".

[0255] 5) When the input is non-zero, continue executing the "if" statement. <1> OP_RETURN.

[0256] 6) Put " <1> OP_RETURN" replaced with "OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF.

[0257] 7) Execute "OP_TUCK OP_MOD OP_DUP OP_IF".

[0258] 8) When the input is non-zero, continue executing the "if" statement. <1> OP_RETURN.

[0259] 9) <1> OP_RETURN" replaced with "OP_TUCK OP_MOD OP_DUP OP_IF <1> OP_RETURN OP_ENDIF.

[0260] 10) Execute "OP_TUCK OP_MOD OP_DUP OP_IF".

[0261] 11) When the input is zero, jump directly to "OP_ENDIF" to close the "if" statement in step 9.

[0262] 12) Go to "OP_ENDIF" to close the "if" statement in step 6.

[0263] 13) Go to "OP_ENDIF" to close the "if" statement in step 3.

[0264] 14) Return to the main function and go to "OP_DROP".

[0265] 15) The result will remain on top of the stack.

[0266] Use Case—Elliptic Curve Dot Multiplication

[0267] For simplicity, this use case involves three functions, abbreviated as [DECIMAL_TO_BINARY], [POINT_ADD], and [POINT_DOUBLE].

[0268] [DECIMAL_TO_BINARY] Uses the first element d on the stack and pushes the following output onto the stack. <2> <d n >… <d0>Above, among which <2> It is an indicator of the first element to be pushed in the sequence (used to indicate the end of the binary sequence), and It should be noted that the first element on the stack will be d0.

[0269] [POINT_ADD] takes the first two elements P1 and P2 on the stack and pushes to add points P1 and P2 to the stack.

[0270] [POINT_DOUBLE] can be interchanged with OP_DUP[POINT_ADD], which uses the first element P on the stack and pushes point 2P onto the stack.

[0271] TX_[POINT_MUL] is a transaction containing a composite script function for elliptic curve point multiplication.

[0272]

[0273] The main function, represented by the last output point in the above transaction, takes two inputs (a, G) and an output a·G. Figure 8 The example is shown in the image. It should be noted that whenever OP_RETURN is encountered, " "OP_RETURN" will all be replaced with i th The entire script at the output point. The step-by-step explanation of the script is as follows, assuming the input (a, G) is pushed onto a stack, where G is the first element on the stack:

[0274] Call the main function (output point 6).

[0275] 1) Push G onto the ALT stack.

[0276] 2) Call [DECIMAL_TO_BINARY] to get the binary representation of a.

[0277] 3) Move G back from the ALT stack.

[0278] 4) Push 0 onto the ALT stack. This 0 helps to indicate when the bottom of the ALT stack has been reached.

[0279] 5) Initially, process the first (least significant) bit 'a'. If it is 1, push G onto the ALT stack.

[0280] 6) Then, push 1 onto the ALT stack. This 1 indicates that there is a non-zero element adjacent to it on the ALT stack.

[0281] 7) Before encountering 2 (indicating the end of the binary sequence) on the Main stack, continuously call output point 4.

[0282] 8) Repeat this operation for output point 4, and if the binary bit is 1, push the result onto the ALT stack followed by 1 (as described in step 6).

[0283] 9) When output point 4 is completed, there will be a list of points to be added together on the ALT stack.

[0284] 10) Move the first point from the ALT stack to the Main stack, and then call output point 5 to start adding points.

[0285] 11) When the end of the ALT stack is reached, the expected result will be on the Main stack.

[0286] It should be understood that the above embodiments are described by way of example only. For clarity, the embodiments are not limited to opcodes with specific names. Rather, the embodiments are limited to opcodes with specific functions. For brevity, the term "OP_RETURN" is used.

[0287] According to a first embodiment of the teachings disclosed herein, a computer implementation method for verifying the validity of a transaction for recording it in a blockchain is provided, the method comprising: receiving one or more transactions at a node in a blockchain network; and applying a protocol for verifying the validity of the received transaction to each transaction, wherein the protocol is configured to: allow a termination opcode to be included in the output script of the transaction, wherein the termination opcode is configured to, when executed by the node, a) terminate execution of the output script; b) not verify the transaction as invalid solely based on the inclusion of the termination opcode in the output script; and disallow any instance of the termination opcode to be included in the input script of the transaction, wherein if any instance of the termination opcode is included in the input script, the disallowing includes: the node at least verifying the transaction as invalid.

[0288] Because the output script contains a termination opcode, the transaction is not completely invalidated. In other words, the transaction is not invalidated based on the termination opcode in the output script itself, but may be invalidated for other reasons, as discussed.

[0289] According to a second optional embodiment, a method according to the first embodiment can be provided, wherein the output script may be a locking script included in the transaction, and the input script may be an unlocking script included in the transaction for unlocking a previous transaction's locking script.

[0290] According to a third alternative embodiment, a method according to the first or second embodiment can be provided, wherein the protocol can be configured such that: when the output script includes a combination of instances of the termination opcode preceding at least one data element, the transaction is verified to be invalid based on the combination of the instances of the termination opcode and the at least one data element.

[0291] In some examples, for a transaction to be verified as invalid based on the combination, the instance of the termination opcode must immediately precede the at least one data element. That is, the at least one data element and the termination opcode are adjacent elements of the output script. Proving unspendable output enables data (e.g., contracts, media files, documents, etc.) to be stored on the blockchain.

[0292] The data element can be any element of the script (e.g., function, string, opcode, etc.).

[0293] According to a fourth alternative embodiment, a method according to the third embodiment can be provided, wherein the at least one data element may include one or both of the following: a zero opcode; or a zero value representation, to create a provably unspendable output of the transaction.

[0294] According to a fifth alternative embodiment, a method according to any one of the first to fourth embodiments can be provided, wherein the protocol can be configured to disallow any opcode from being included in the input script of the transaction, and if any opcode is included in the input script, the disallowing includes: the node at least verifying that the transaction is invalid.

[0295] According to a sixth alternative embodiment, a method according to any one of the first to fifth embodiments can be provided, wherein the effectiveness may include at least one of the following: after the node executes the combination of the output script and the input script, a non-empty and non-zero result is generated; the node forwards the transaction to one or more nodes of the network for recording in the blockchain; the node records the transaction in the blockchain.

[0296] According to a seventh alternative embodiment, a method according to any one of the first to sixth embodiments can be provided, wherein the method may include: executing a transaction of the blockchain network according to the protocol, wherein a first transaction includes at least a first output, the first output including a first locking script of a stack-based scripting language, wherein the first locking script includes a portion of the first locking script to be executed before executing a first instance of the termination opcode; wherein a second transaction includes a first unlocking script, the first unlocking script referencing the first output in the first transaction, the method may include, upon executing the first instance of the termination opcode: terminating the execution of the first locking script without verifying the invalidity of the first transaction; reading a first data element from at least one stack, wherein the first data element is generated during the 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, wherein the function is configured to generate a result based at least on the first data element.

[0297] According to an eighth alternative embodiment, a method according to the seventh embodiment can be provided, wherein reading the first data element may include recording the first data element on the off-chain stack, and wherein providing may include providing the first data element read from the at least one off-chain stack to the off-chain function.

[0298] According to the ninth alternative embodiment, a method according to the seventh or eighth embodiment can be provided, wherein the generation may include generating further transactions of the blockchain network as a result.

[0299] According to a tenth alternative embodiment, a method according to the ninth embodiment can be provided, wherein generating the further transaction may include inputs for generating the further transaction, wherein the inputs are based at least on the first data element.

[0300] According to the eleventh alternative embodiment, a method according to the ninth or tenth embodiment can be provided, wherein the method may include: transmitting the further transaction to one or more nodes of the blockchain network.

[0301] According to a twelfth alternative embodiment, a method according to any one of the ninth to eleventh embodiments can be provided, wherein the method may include: executing a third transaction of the blockchain network, wherein the third transaction includes at least a second output, the second output including a second locking script of the stack-based scripting language, wherein the second locking script includes a portion of the second locking script to be executed before executing a second instance of the termination opcode; wherein the further transaction includes a second unlocking script, the second unlocking script referencing the second output in the third transaction, and wherein the method may include, upon executing the second instance of the termination opcode of the further transaction: terminating the execution of the second locking script without verifying the invalidity of the further transaction; reading a second data element from the at least one stack, wherein the second data element is generated during the execution of the second unlocking script and the portion of the second locking script; providing the second data element read from the at least one stack to the off-chain function, wherein the function is configured to generate further results based at least on the second data element.

[0302] According to the thirteenth alternative embodiment, a method according to the seventh embodiment can be provided, wherein the first transaction may include a plurality of outputs, each of the plurality of outputs including a corresponding locking script, wherein each of the plurality of outputs is referenced by a corresponding output address, wherein the first data element is an output address referencing a second output among the outputs, and wherein the first output is referenced in the unlocking script of the second transaction; and wherein the off-chain function is configured to use the output address read from the stack to reference the locking script of the second output when the first instance of the termination opcode is invoked.

[0303] According to the fourteenth alternative embodiment, a method according to the thirteenth embodiment can be provided, wherein the method may include: executing the unlock script and the first lock script, the execution including pushing the output address of the second output onto the stack.

[0304] According to the fifteenth alternative embodiment, a method according to the fourteenth embodiment can be provided, wherein the method may include: copying the unlock script and the first lock script to a script template before executing the unlock script and the first lock script, wherein the script template includes a script to be executed.

[0305] According to a sixteenth alternative embodiment, a method according to the fifteenth embodiment can be provided, wherein the method may include: when invoking the first instance of the termination opcode, copying the locking script of the second output to the beginning of the script template.

[0306] According to the seventeenth alternative embodiment, a method according to any one of the thirteenth to sixteenth embodiments can be provided, wherein the method may include executing the locking script of the second output.

[0307] According to an eighteenth alternative embodiment, a method according to the seventeenth embodiment can be provided, wherein the locking script of the second output may include a portion of a script to be executed before the second instance of the termination opcode, the portion including an output address referencing a third output in the output; and wherein the locking script executing the second output may include: pushing the output address of the third output onto the stack; and wherein the function is configured to, when the second instance of the termination opcode is invoked, use the output address read from the stack to reference the locking script of the third output.

[0308] According to the nineteenth alternative embodiment, a method according to the eighteenth embodiment can be provided, wherein the method may include: when invoking the second instance of the termination opcode, copying the locking script of the third output to the beginning of the script template.

[0309] According to the twentieth alternative embodiment, a method according to the eighteenth or nineteenth embodiment can be provided, wherein the first output, the second output, and the third output can be listed sequentially among the plurality of outputs.

[0310] According to the twenty-first alternative embodiment, a method according to the eighteenth or nineteenth embodiment can be provided, wherein the first output, the second output, and the third output may be listed among the plurality of outputs in no particular order.

[0311] According to the twenty-second alternative embodiment, a method according to any one of the thirteenth to twenty-first embodiments can be provided, wherein the method may include performing the following operations: executing a locking script for a referenced output, pushing the output address of the corresponding output onto the off-chain stack, wherein the function is configured to, when the corresponding instance of the termination opcode of the corresponding output is invoked, use the output address read from the stack to reference a locking script for the next output in the output; wherein the operation is repeated until each locking script for the plurality of outputs referenced by another locking script has been executed.

[0312] According to the twenty-third optional embodiment, a method according to the twenty-second embodiment can be provided, wherein the method may include: copying the locking script to the beginning of the script template each time one of the locking scripts is executed.

[0313] According to the twenty-fourth optional embodiment, a method according to the twenty-third embodiment can be provided, wherein the method may include: using the script template as a locking script for further transactions, wherein the locking script for the further transactions does not contain an instance of the termination opcode.

[0314] According to the twenty-fifth optional embodiment, a method according to any one of the thirteenth to twenty-fourth embodiments can be provided, wherein one or more of the locking scripts may include corresponding functions, and wherein executing the corresponding locking script may include executing the corresponding function.

[0315] According to the twenty-sixth alternative embodiment, a method according to the twenty-fifth embodiment can be provided, wherein the corresponding function can be configured to operate on data on the off-chain stack when the corresponding function is executed.

[0316] According to the twenty-seventh alternative embodiment, a method according to any one of the thirteenth to twenty-sixth embodiments can be provided, wherein the method may include: if the first locking script includes an instance of the termination opcode, extracting all locking scripts from the first transaction and indexing the locking scripts using the corresponding output addresses.

[0317] According to the twenty-eighth optional embodiment, a method according to any one of the thirteenth to twenty-seventh embodiments can be provided, wherein each output address in each locking script can be a corresponding data element, and wherein the function can be configured to interpret the corresponding data element as an output address.

[0318] According to a twenty-ninth embodiment of the teachings disclosed herein, a computer program is provided, the computer program being stored on a computer-readable storage medium and configured to perform the method described in any one of the first to twenty-eighth embodiments when run on a node of a blockchain network.

[0319] According to a thirtieth embodiment of the teachings disclosed herein, a computing device is provided, the computing device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to, when run on the processing means, perform the method according to any one of the first to twenty-eighth embodiments.

[0320] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims. < / oa> < / oa> < / oa> < / n> ​ < / s1> < / r1> < / sig1> < / x> < / y> < / y> < / x>

Claims

1. A computer-implemented method for verifying the validity of a transaction to record it in a blockchain, the method comprising: Receive one or more transactions at a node in the blockchain network; And a protocol for verifying the validity of each received transaction, wherein the protocol is configured as follows: The termination opcode can be included in the output script of the transaction, wherein the termination opcode is configured to, when executed by the node, a) terminate the execution of the output script; b) not verify the transaction as invalid solely based on the inclusion of the termination opcode in the output script; Any instance of the termination opcode is not allowed to be included in the input script of the transaction. If any instance of the termination opcode is included in the input script, the disallowing includes: the node at least verifying that the transaction is invalid.

2. The method according to claim 1, wherein, The output script is a locking script included in the transaction, and the input script is an unlocking script included in the transaction, the unlocking script being used to unlock the locking script of a previous transaction.

3. The method according to claim 1, wherein, The protocol is configured such that: When the output script includes a combination of instances of the termination opcode preceding at least one data element, the transaction is verified to be invalid based on the combination of the instances of the termination opcode and the at least one data element.

4. The method according to claim 3, wherein, The at least one data element includes one or both of the following: Zero opcode; or A zero value represents a provably unspendable output used to create the transaction.

5. The method according to claim 1, wherein, The protocol is configured as follows: No opcodes are allowed to be included in the input script of the transaction. If any opcode is included in the input script, the disallowing includes: the node at least verifying that the transaction is invalid.

6. The method according to claim 1, wherein, The validity includes at least one of the following: After the node executes the combination of the output script and the input script, a non-empty and non-zero result is produced; The node forwards the transaction to one or more nodes in the network so that the transaction is recorded in the blockchain; as well as The node records the transaction in the blockchain.

7. The method according to claim 1, wherein the method comprises: Executing transactions on the blockchain network according to the protocol, wherein a first transaction includes at least a first output, the first output including a first locking script in a stack-based scripting language, wherein the first locking script includes a portion of a first locking script to be executed before executing a first instance of the termination opcode; wherein a second transaction includes a first unlocking script referencing the first output in the first transaction, and the method includes, when executing the first instance of the termination opcode: Terminate the execution of the first locking script, and do not verify that the first transaction is invalid; A first data element is read from at least one stack, wherein the first data element is generated during the execution of said portion of the first unlock script and the first lock script; The first data element, read from the at least one stack, is provided to an off-chain function, wherein the function is configured to generate a result based at least on the first data element.

8. The method according to claim 7, wherein, Reading the first data element includes recording the first data element on an off-chain stack, and wherein providing includes providing the off-chain function with the first data element read from the at least one off-chain stack.

9. The method according to claim 7, wherein, The generation includes generating further transactions for the blockchain network as a result.

10. The method according to claim 9, wherein, The generation of the further transaction includes the input for generating the further transaction, wherein the input is based at least on the first data element.

11. The method according to claim 9, wherein the method comprises: The further transactions are transmitted to one or more nodes in the blockchain network.

12. The method according to claim 9, wherein the method comprises: Executing a third transaction of the blockchain network, wherein the third transaction includes at least a second output, the second output including a second locking script of the stack-based scripting language, wherein the second locking script includes a portion of a second locking script to be executed before executing a second instance of the termination opcode; wherein the further transaction includes a second unlocking script, the second unlocking script referencing the second output of the third transaction, and wherein the method includes, when executing the second instance of the termination opcode of the further transaction: Terminate the execution of the second locking script, and do not verify the invalidity of the further transactions; A second data element is read from the at least one stack, wherein the second data element is generated during the execution of the portion of the second unlock script and the second lock script; The second data element, read from the at least one stack, is provided to the off-chain function, wherein the function is configured to generate further results based at least on the second data element.

13. The method according to claim 8, wherein, The first transaction includes multiple outputs, each of which includes a corresponding locking script, wherein each of the multiple outputs is referenced by a corresponding output address, wherein the first data element is an output address referencing a second output among the outputs, and wherein the first output is referenced in the unlocking script of the second transaction; and The off-chain function is configured to use the output address read from the stack to reference the locking script of the second output when the first instance of the termination opcode is called.

14. The method according to claim 13, wherein the method comprises: Execute the unlock script and the first lock script, the execution including pushing the output address of the second output onto the stack.

15. The method of claim 14, wherein the method comprises: Before executing the unlock script and the first lock script, the unlock script and the first lock script are copied to a script template, wherein the script template includes the script to be executed.

16. The method of claim 15, wherein the method comprises: When the first instance of the termination opcode is invoked, the locking script of the second output is copied to the beginning of the script template.

17. The method of claim 15, wherein the method comprises: Execute the locking script from the second output.

18. The method according to claim 17, wherein, The locking script of the second output includes a portion of a script to be executed before the second instance of the termination opcode, the portion including an output address referencing the third output in the output; Furthermore, the locking script that executes the second output includes: Push the output address of the third output onto the stack; and The function is configured to, when calling the second instance of the termination opcode, use the output address read from the stack to reference the locking script of the third output.

19. The method of claim 18, wherein the method comprises: When the second instance of the termination opcode is invoked, the locking script of the third output is copied to the beginning of the script template.

20. The method according to claim 18, wherein, The first output, the second output, and the third output are listed in sequence among the plurality of outputs.

21. The method of claim 18, wherein the first output, the second output, and the third output are not listed in order among the plurality of outputs.

22. The method of claim 15, wherein the method comprises performing the following operations: Execute the locking script for the referenced output, and push the output address of the corresponding output onto the off-chain stack, wherein, The function is configured to, when calling the corresponding instance of the termination opcode of the corresponding output, use the output address read from the stack to reference the locking script of the next output in the output; The operation is repeated until each of the plurality of outputs referenced by another locking script has been executed.

23. The method according to claim 22, wherein the method comprises: Each time one of the locking scripts is executed, the locking script is copied to the beginning of the script template.

24. The method of claim 23, wherein the method comprises: The script template is used as a locking script for further transactions, wherein the locking script for further transactions does not contain an instance of the termination opcode.

25. The method according to claim 13, wherein, One or more of the locking scripts include corresponding functions, and the execution of the corresponding locking script includes the execution of the corresponding function.

26. The method of claim 25, wherein, The corresponding function is configured to operate on the data on the off-chain stack when the corresponding function is executed.

27. The method of claim 13, wherein the method comprises: If the first locking script includes an instance of the termination opcode, extract all locking scripts from the first transaction and index the locking scripts using the corresponding output addresses.

28. The method according to claim 13, wherein, Each output address in each locking script is a corresponding data element, and the function is configured to interpret the corresponding data element as an output address.

29. A computer program product contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 28 when run on a node of a blockchain network.

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

Images