Blockchain Scripting Engine

Abstract

1. A computer-implemented method for executing a script formed from a locking script of a first blockchain transaction and an unlocking script of a second blockchain transaction, the script including a first script portion, a version function, and a second script portion, the method comprising: a native script engine executing the first script portion; when a version function is encountered, the native script engine terminating execution of the script and determining whether the first script portion is valid according to a blockchain protocol; in response to determining that the first script portion is valid, the native script engine providing a sub-script including at least the version function and the second script portion to a versioned script engine; and the versioned script engine executing the sub-script, wherein execution of the sub-script by the versioned script engine does not affect the validity of the first blockchain transaction and / or the second blockchain transaction.

Description

[Technical field]

[0001] The present disclosure relates to a method for executing blockchain transactions and a blockchain script engine configured to execute blockchain transactions. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain includes a chain of data blocks, with each block including one or more transactions. Each transaction, other than the so-called "coinbase transaction," points to a preceding transaction in the sequence, which may span one or more blocks, back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining," which involves multiple nodes each competing to perform a "proof-of-work," i.e., solving a cryptographic puzzle based on an ordered and validated representation of pending transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be accomplished through mere publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: to transfer digital assets (i.e., some digital tokens), to order a set of entries in a virtual ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. A blockchain may also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow for the storage of additional user data or indexes to data in a transaction. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore more complex data can be incorporated. For example, this may be used to store electronic documents on the blockchain, or to store audio or video data.

[0004] Nodes of a blockchain network (often called "miners") perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a block template that attempts to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be propagated. Nodes that receive a transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into a block. Assuming the transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes an amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is performed by the actions of competing nodes, who act as agents of the network and are incentivized to report and thwart fraud. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can ensure the ongoing integrity of the blockchain.

[0006] 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 usable output includes an element that specifies an amount of a digital asset derivable from the preceding sequence of transactions. A usable output is sometimes called a UTXO (an “unspent transaction output”). An output may further include a locking script that specifies a condition for future redemption of the output. A locking script is a predicate that defines the condition required to validate and transfer a digital token or asset. Each input of a transaction (except for a coinbase transaction) includes a pointer (i.e., a reference) to such output in a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, considering a pair of transactions, we refer to them as a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that specifies an amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another prior valid transaction. A node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, although it may propagate to register the invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0008] Another type of transaction model is the account-based model. In this case, each transaction defines the amount to be transferred by referencing absolute account balances, not by referencing the UTXO of the preceding transaction in the sequence of past transactions. The current state of every account is stored and constantly updated by nodes separately from the blockchain. Summary of the Invention

[0009] Blockchains are designed so that a variety of applications can be built on top of their infrastructure. Some blockchain nodes not only provide security for the system, but also provide additional functionality and utility, such as the ability to execute smart contracts. Not all nodes provide these additional functions, and different nodes may support different types or levels of such functionality.

[0010] Blockchain nodes may signal their ability to provide additional functionality using node protocol version numbers or version numbers. Each version number may be associated with a specific functionality. In other words, blockchain nodes may be configured to implement functionality as part of a specific protocol. For example, the protocol may be a smart contact protocol, or a token protocol, or a specific protocol for validating transactions. As another example, blockchain nodes may be configured to execute code that is not specific to blockchain (e.g., Python or Java) and return (i.e., output) the results of executing said code.

[0011] Blockchain protocols may use a scripting language for transactions. A script is essentially a list of elements that can be data or instructions. Instructions are referred to in the literature as script words, opcodes, commands, or functions. Opcodes (short for operation code) perform a given action on the data in the script. A script may contain a version function (where function is commonly used to mean a type of instruction, such as an opcode), followed by a portion of the script that will only be executed, or will be executed in a certain way, depending on the node protocol version number associated with the blockchain node running the script.

[0012] The introduction of node versioning, i.e. allowing different nodes to execute parts of scripts differently depending on their capabilities, can significantly increase the capabilities of nodes in a blockchain network by allowing nodes to view and validate transactions differently according to their own protocol in addition to the native blockchain protocol. The additional capabilities can range from executing any smart contract to validating some specific transactions, from playing chess to exchanging assets or customized rules for validation.

[0013] However, problems arise if the execution of the script causes one (or more) blockchain nodes to consider the transaction valid and another blockchain node to consider the transaction invalid. This would create a split in the blockchain network, i.e., a blockchain fork. This can happen, for example, if one blockchain node has the ability to execute part of the script but the other does not. It can also happen if both nodes have the ability to execute the entire script, but the nodes execute the script differently depending on their version number.

[0014] Blockchain forks are problematic from a security perspective. Forks cause some blockchain nodes to "mine" one version of the blockchain while other nodes mine a different version, e.g., one version where transactions are considered valid, and one version where the same transactions are considered invalid. Here, mining on a blockchain means trying to add new blocks to the chain. This reduces the hashrate spent on either chain. As the hashrate decreases, the likelihood of malicious activity increases, e.g., so-called 51% attacks, where an entity that controls 51% of the hashrate can manipulate the blockchain. Blockchain forks are also problematic because they cause some nodes to waste resources (e.g., time, effort, and processing power) on a version of the chain that will eventually be lost to other nodes.

[0015] It is therefore desirable to allow blockchain nodes to perform transactions differently depending on their capabilities without causing the network to split.

[0016] According to one aspect disclosed herein, a computer-implemented method is provided for executing a script formed from a lock script of a first blockchain transaction and an unlock script of a second blockchain transaction, where the script includes a first script portion, a version function, and a second script portion, the method including: a native script engine executing the first script portion; upon encountering the version function, the native script engine terminating execution of the script and determining whether the first script portion is valid according to a blockchain protocol; in response to determining that the first script portion is valid, the native script engine providing a sub-script including at least the version function and the second script portion to a versioned script engine; and the versioned script engine executing the sub-script, where execution of the sub-script by the versioned script engine does not affect the validity of the first blockchain transaction and / or the second blockchain transaction.

[0017] According to another aspect disclosed herein, a blockchain script engine is provided that includes a native script engine and a versioned script engine, where the native script engine is configured to execute a script including a first script portion, a version function, and a second script portion, terminate execution of the script upon encountering the version function, determine whether the first script portion is valid according to a blockchain protocol, and in response to determining that the first script portion is valid, provide a sub-script including at least the version function and the second script portion to the versioned script engine, where the versioned script engine is configured to execute the sub-script.

[0018] Traditionally, blockchain nodes execute entirely using a native script engine. Here, an additional script engine (the versioned script engine) is introduced to handle versioned branches, i.e., the parts of the script that are executed following the version function. When the native script engine detects the version function, it terminates the execution of the script. The validity of the executed script is checked. If the executed script is invalid, the transaction is invalidated. If the executed script is valid, the remaining parts of the script are sent to the versioned script engine for execution. Only the native script engine influences the validity of the script and therefore the validity of the transaction. Thus, even if different nodes execute the remaining parts of the script differently, all nodes will reach the same consensus on the validity of the transaction, thus preventing forks.

[0019] Note that the version function is referred to below as "OP_VER." However, the present disclosure is not limited to functions (e.g., opcodes) with that particular label. More generally, although embodiments are described with respect to "OP_VER" in the blockchain scripting language, the same teachings can be implemented using any function (e.g., opcode) that, when invoked by a scripting engine (i.e., a script interpreter), causes an action to be attributed to the version function as described herein. [Brief description of the drawings]

[0020] To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2]1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 2 is a schematic block diagram of some node software for processing transactions. [Figure 4] FIG. 1 is a schematic block diagram of a system for implementing embodiments described herein. [Diagram 5] 1 illustrates a schematic layout of a versioned script executed by a dual script engine. [Figure 6] 1 illustrates a schematic diagram of an exemplary token transaction. [Figure 7] 1 illustrates a schematic diagram of an exemplary token transaction. [Figure 8] 1 illustrates a schematic diagram of an exemplary token transaction. [Figure 9] 1 illustrates a schematic diagram of an exemplary token transaction. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] 1. Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may be comprised of a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0022] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes one or more processors, e.g., processing devices including one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). Each node also includes memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. The memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, solid state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disk drives.

[0023] The blockchain 150 includes a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a decentralized or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of 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 an amount of digital assets as a property, an example of which is a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or used). Each input points to the output of a preceding transaction 152, thereby linking the transactions.

[0024] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain to define an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to a previous transaction to define an order for the sequence of transactions (Note: a sequence of transactions 152 can branch). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0025] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. This refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0026] For a given current transaction 152j, its input (or each input) contains a pointer that references an output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. Using or redeeming does not necessarily mean the transfer of a financial asset, although that is certainly one common use. More generally, using may be described as consuming an output or allocating it to one or more outputs in another onward transaction. In general, the preceding transaction may be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i must exist and be validated for the current transaction to be valid, but the preceding transaction 152i does not necessarily need to exist when the current transaction 152j is created or sent to the network 106. Thus, "preceding" herein refers to something that precedes it in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in a time sequence, and therefore does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i is also referred to as an antecedent transaction or a predecessor transaction.

[0027] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b, as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to split the input amount among multiple users or entities (one of which can be the original user or entity 103a to give the change). In some cases, the transaction can also have multiple inputs to pool amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0028] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (manually or by an automated process adopted by the party), the enacting party transmits the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient eventually transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which is currently typically a server or a data center, but could in principle be other user terminals). It is not excluded that the party 103 enacting the new transaction 152j transmits the transaction directly to one or more of the blockchain nodes 104 and in some examples does not transmit it to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of them. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction uses (or "assigns"), which condition typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i. Alternatively, it may be fixed solely by the blockchain node protocol or by a combination of these.In any event, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and then forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0029] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or “spent”) is whether it has been validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it is trying to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated for a warning) or recorded in the blockchain 150. This prevents double-spending, where a transactor tries to allocate the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because the transaction order is defined, the account balance is always in a single defined state.

[0030] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is supported by "proof of work." At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by trying to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated and hashed with a representation of the ordered pool 154 of pending transactions, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, other types are not excluded. A property of a hash function is that it has an unpredictable output for its input. This search can therefore only be performed in a brute force manner, consuming a significant amount of processing resources on each blockchain node 104 attempting to solve the puzzle.

[0031] The first blockchain node 104 to solve the puzzle publishes this to the network 106 and provides its solution as a proof that can be easily checked later by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the output of the hash satisfies the conditions). This first blockchain node 104 propagates the block to threshold consensus of other nodes that accept this block and enforces the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution indicates the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it uses or assigns the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0032] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of not-yet-published transactions 154 at any given time, depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, and in what order, the current pool of not-yet-published transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined, ordered pool of not-yet-published transactions 154, and so on. There are also protocols to resolve any "forks" that may occur if two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. In essence, whichever prong of the fork grows the longest will be the deterministic blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both forks.

[0033] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the additional amount of accepted digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be referred to as an "initiation transaction" or "generation transaction." This typically forms the first transaction of a new block 151n. The proof of work indicates the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturity period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generative) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is explained below.

[0034] Due to the resources involved in transaction validation and publishing, typically at least each of the blockchain nodes 104 takes the form of a server made up of one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0035] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0036] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0037] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not fulfill the role required of a blockchain node. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting (i.e., communicating) with the blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, namely, a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that there may be many more such parties 103 and their respective computer devices 102 and they may participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, although it will be understood that this is not limiting and that any reference to Alice or Bob herein may be replaced with "first party" and "second party," respectively.

[0038] The computer equipment 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises a memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. This memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to run on the processing device. It will be understood that any action attributed to a given party 103 herein may be performed using software running on the processing device of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0040] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104 for propagation across the network of blockchain nodes 104 and thereby inclusion in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of the various transactions 152 scattered across the blockchain 150 that belong to that party.

[0041] It should be noted that various client functions may be described as being integrated into a given client application 105, but are not necessarily limited thereto; instead, any client functionality described herein may be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer or a lower layer, such as an operating system, or any combination thereof. The following description is given with respect to client application 105, but will be understood to be non-limiting.

[0042] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward the transactions 152 to propagate them across the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol goes with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0043] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using a wallet function in Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This includes first checking if the newly received transaction 152j meets certain conditions to be "valid", examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0044] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, it will be propagated immediately throughout the network 106.

[0045] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle for the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whichever node solves it first defines the set of transactions contained in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it universally becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 contains a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

[0046] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views on which instance is "valid" until one instance is published in a new block 151 (at which point all blockchain nodes 104 agree that the published instance is the only valid instance). If a blockchain node 104 accepts one instance as valid and then discovers that another instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the one not published in block 151).

[0047] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing the UTXO of the preceding transaction in the sequence of past transactions. The current state of every account is stored and constantly updated by the nodes of the network separately from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of the account. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field in the transaction may also be signed. This data field may point to a previous transaction, for example if a previous transaction ID is included in the data field.

[0048] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. It is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). In the following, it is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0049] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include a transaction ID of the underlying transaction, among other information. The transaction data structure may also include a header 201 that may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 that is submitted to the node 104.

[0050] Suppose Alice 103a wants to create a transaction 152j that transfers an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point to any previous (i.e., earlier) transaction that still has an unspent output 203 locked to Alice.

[0051] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 106 together, or even Tx0 may be submitted after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of the transactions in a sequence defined by transaction pointers (e.g., which transactions point to which other transactions) specified in the transactions. They may similarly be replaced with "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order of their creation, transmission to the network 106, or arrival at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for the parent or discarded, depending on the node protocol and / or node behavior.

[0052] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that an unlocking script in the input 202 of the following transaction must satisfy in order for the following transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines an unlocking condition that includes a condition that an unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0053] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is needed to use the transaction output 203, e.g. the need for Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0054] That is, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A ] is the public key P of Alice's public-private key pair.A Tx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key of her key pair to a given portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0055] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" are functions that are composed in the lock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the unlock script in Tx1's input contains Alice's signature signing the expected portion of the data. In order to perform this authentication, the expected portion of the data itself (the "message") must also be included. In embodiments, the data to be signed includes the entirety of Tx1 (i.e., a separate element specifying the signed portion of the plaintext data does not need to be included, as that is already inherently present).

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

[0057] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the ordered pool 154 of pending transactions. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it uses unspent transaction outputs 203. If it attempts to use an output that has already been used by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO has been spent is whether it already formed a valid input to another valid transaction in the blockchain 150.

[0058] 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 ground of invalidity in most transaction models, so such a transaction will not be propagated or included in block 151.

[0059] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined as spent in the UTXO cannot be "left" while another part is spent. However, it is possible to split the amount from the UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself in the second output of Tx1 or to pay another party.

[0060] In practice, Alice would also typically need to include a fee for any Bitcoin node 104 that successfully includes Alice's transaction 104 in a block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus may not be propagated and included in the blockchain 150, even if it is technically valid (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or used) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0061] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. No number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together all the values ​​of the various UTXOs that are locked to the respective parties and that have not yet been used in another subsequent transaction. This can be done by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0062] Note that scripting code is often represented generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in the scripting language. As an example, OP_RETURN is an opcode in the scripting language that creates an unusable output of a transaction that can store data in the transaction when preceded by OP_FALSE at the beginning of the lock script, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0063] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific portion of the data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and some or all of the transaction outputs. The specific portion of the outputs that are signed depends on the SIGHASH flag, which is a four-byte code that is typically included at the end of the signature (and is therefore fixed at the time of signing) to select which outputs are signed.

[0064] A lock script may typically be referred to as a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script may typically be referred to as a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, any condition or conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0065] 3. Node Software FIG. 4 illustrates an example of node software 450 executed on each blockchain node 104 of the network 106 in an example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required for a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize different fields of a transaction 152 and process them according to a node protocol. Another preceding transaction 152i (Tx m-1 ) j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlock script in the Tx j Based on the pointer at the input of Tx i Identify and extract Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx i Alternatively, Tx i may not yet have been published on the blockchain 150. In this case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Txi and passes it to the script engine 452.

[0066] Therefore, the script engine 452 executes the Tx i Lock script and Tx j and an unlock script from the corresponding inputs of . For example, while Figure 2 shows transactions labeled Tx0 and Tx1, the same could apply for any pair of transactions. The script engine 452 executes the two scripts together as described above, which includes placing data on and taking data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0067] By executing the scripts together, the script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., "unlock" the output in which the lock script is included. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0068] In an output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. Typically, Tx j the aggregate value of the Digital Assets indicated in the output(s) of Tx will not exceed the aggregate value indicated by its inputs; iThere are also one or more further protocol level conditions evaluated by the protocol engine 451 that must be satisfied as well, such as that the pointed-to output of has not already been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 along with one or more protocol level conditions, and only if they are all true does it accept the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j is actually validated, the decision engine 454 j , . . . , . . . In one embodiment, the consensus module 455C may choose to control both the consensus module 455C and the propagation module 455P to perform respective blockchain-related functions with respect to the nodes' respective ordered sets of transactions 154, Tx j and the propagation module 455P transmits the Tx j Optionally, in embodiments, the application level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish a transaction only on the condition that the transaction is valid and has sufficient transaction fees remaining.

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

[0070] 4.OP_VER The expansion of block sizes and increased transaction throughput has led to a significant increase in the number of blockchain-based applications in the blockchain ecosystem. Many of these new applications provide services beyond the basic transfer of digital assets and therefore rely on an external validation or interpretation process. While the validation of blockchain nodes (miners) concerns the validity of using these digital assets, external validation allows companies to create applications and services that leverage blockchain capabilities for more complex purposes. Examples of such processes include the creation of overlay networks such as metanets, goods and service representations such as token systems, and many others. The numerous overlay services have prompted block producers and blockchain companies to offer specialized services, resulting in the creation of de facto blockchain communities and hierarchical network topologies.

[0071] One technique for enterprises and developers to leverage a layered network involves the use of the opcode OP_VER and its related opcodes OP_VERIF and OP_VERNOTIF. These version-specific opcodes allow nodes in the network to view and validate transactions differently according to their own protocol in addition to the native Bitcoin protocol.

[0072] Using the opcode OP_VER, nodes can offer new functionality in parallel with transaction validation. By broadcasting their node version number, nodes effectively broadcast to the public what services they offer. This can range from running any smart contract to validating specific transactions such as games, exchanging assets, or a customized set of rules for validation. [Table 1]

[0073] When OP_VER is enabled, block producers (i.e., miners) can choose which overlay protocol(s) to support in addition to the native blockchain protocol. More specifically, all transactions must be blockchain valid before they can be passed to the overlay protocol for validation.

[0074] A locking script that uses OP_VERIF can be defined as follows: [Table 2]

[0075] Consider a miner supporting the overlay protocol, say Michelle, that runs a custom smart contract with node version number "0x2abc". Michelle reflects this in her configuration file setting as "NODE_VERSION=0x2abc". If a user, say Bob, wants to have his custom contract validated as part of a transaction, Bob creates a transaction that uses an outpoint with a lock script using the format suggested above. When Michelle receives Bob's transaction, the opcode OP_VERIF detects Michelle's node version number and compares it to the version number in the lock script. Since the versions match, the custom smart contract transaction is read and validated; i.e., both branch 1 and branch 2 are executed. When a non-participating miner receives Bob's transaction, their node version numbers do not match, so it skips the contents of the second branch and treats Bob's transaction as a standard transaction where only branch 1 is executed. An example logic flow that may be followed when a transaction containing a call to OP_VER is used may be as follows:

number

[0076] Moving the version-specific content results to the alt stack (step 4) ensures that transaction validation results are deterministic and independent of the miner's node version when all actors are honest. However, a malicious user or computation bug can leave a version-specific branched result in the main stack (steps 1-3). This introduces the possibility of network partitioning, since an OP_VER transaction may be valid for some nodes but not others.

[0077] At the time of writing, OP_VER and its associated opcodes OP_VERIF, OP_VERNOTIF have not yet been implemented. These version-specific codes allow additional functionality in blockchain transactions by triggering additional checks, the results of which may be written to the alternate stack. However, if a malicious user were to create a transaction that would result in a version-specific branch being pushed back into the main stack, an inconsistency would occur during the native validation process. If such a transaction were inserted into a block published by a standard (non-versioned) node, the inconsistency would turn into a partition of the network.

[0078] Consider the following script: TRUE 0x12ab OP_VERIF FALSE OP_ENDIF

[0079] Standard nodes will evaluate this script as TRUE, while version-specific nodes (with version number 0x12ab) will evaluate this script as FALSE. Disagreement about the script will lead to disagreement about transaction validity, which will further lead to network partitioning. Attackers can exploit this vulnerability to craft transactions with the intent of partitioning the network, resulting in the security flaws and inefficiencies discussed above.

[0080] Therefore, it is recognized that there is a need for improved handling of the OP_VER family of opcodes.

[0081] 5. Versioned Script Engine 4 illustrates an example system 400 for executing a blockchain script according to an embodiment of the present disclosure. The system 400 includes a blockchain node 104 and one or more users, e.g., Alice 103a and Bob 103b. The blockchain node is configured to obtain a first transaction and a second transaction, e.g., from Alice 103a and Bob 103b, respectively. Alternatively, the first and / or second transaction may be obtained from a different node 104 or directly from the blockchain 150.

[0082] The second transaction includes an input that references an output of the first transaction, and therefore the unlock script of the second transaction attempts to unlock the lock script of the first transaction. To validate the second transaction, node 104 executes the unlock script of the second transaction in parallel with the lock script of the first transaction. According to some blockchain protocols, the unlock script is executed first, followed by the lock script. Other protocols may execute the lock script first.

[0083] The blockchain node 104 has a native script engine, for example, the script engine 452 described with reference to FIG. 3. The native script engine is used to execute transactions. More specifically, the native script engine is used to execute the unlock script and the lock script of the transaction. When a transaction is received, a script is formed using the unlock scripts of the inputs of the received transaction and the lock scripts of the transaction outputs referenced by the inputs. Traditionally, the native script engine executes the entire script, or at least attempts to execute the entire script. This execution may terminate early, for example, if an invalid element (e.g., a function) is encountered. As another example, the execution of the script may terminate if a return function (e.g., OP_RETURN) is encountered. If the script terminates early, the remaining script is not executed.

[0084] According to the present disclosure, in addition to the native script engine, the blockchain node 104 also has a versioned script engine. The versioned script engine is configured to execute blockchain scripts. The difference between the native script engine and the versioned script engine is that the execution of a script by the versioned script engine does not affect the validity of a transaction (i.e., a transaction that includes an unlock script or a transaction that includes a lock script).

[0085] The native script engine and / or the versioned script engine may be implemented entirely in software, entirely in hardware, or using a combination of both software and hardware components.

[0086] When the native script engine encounters (i.e., detects) a versioned function, the native script engine is configured to finish executing the script and determine whether a transaction is valid based on the executed script, i.e., the script executed up to (but not including) the versioned function. If the transaction is valid, the native script engine sends the unexecuted script (including the versioned function) to the versioned script engine. The versioned script engine then executes the remaining script. The remaining script is sometimes referred to as the "versioned script." The versioned script engine executes the script in the same manner as the native script engine, except for its handling of versioned functions. If the versioned script engine encounters a versioned function, the versioned script engine executes the versioned function.

[0087] If the transaction is determined to be invalid by the native script engine, the transaction is rejected and the remaining script is not sent to the versioned script engine.

[0088] By terminating execution of the script by the native script engine when a version opcode is encountered, each blockchain node 104 will have the same view of whether the transaction is valid or invalid. This is because the native script engine of each blockchain node 104 executes the script in the same way, and transaction validity is only affected by the native script engine, not the versioned script engine. Thus, the results of execution of the remaining script by the versioned script engine may differ between nodes 104 without affecting the validity of the transaction. This allows different nodes to execute parts of the script differently (e.g., depending on their capabilities) without causing network partitioning.

[0089] The entire script to be executed is formed from the lock script of the first transaction and the unlock script of the second transaction (first and second are arbitrary labels). The entire script includes the first script part, the version function, and the second part, in that order. In general, the version function may come from (i.e., be included as part of) the lock script of the first transaction or the unlock script of the second transaction, but the former is more likely. The native script engine executes only the first script part, i.e., the part of the script up to the native script engine. When the native script engine encounters the version function, it supplies the versioned script engine with a sub-script that includes the version function and the second script part. This process is shown diagrammatically in FIG. 5.

[0090] In some examples, the first script portion may include a data element that represents the target version number. In these examples, the sub-script that is provided to the versioned script engine also includes the target version number. The native script engine may know that the data element is the target version number, for example, based on one or more of the data element's format, size, type, etc. Alternatively, the native script engine may interpret a data element adjacent to (e.g., preceding) the version number as the target version number and include this data element as part of the sub-script. Note that the target version number is provided at run time by the native engine when creating the sub-script. That is, when the native engine creates the sub-script, it adds the target version number before providing the sub-script to the versioned engine.

[0091] In some examples, when the versioned script engine executes the version function, the versioned script engine is configured to obtain the version number of the blockchain node 104 (e.g., from the memory of the node 104) and output the version number, for example, to the stack. In general, the version number may be stored in any type of memory, i.e., computer-readable storage. The version number indicates the particular protocol, i.e., functionality or capability, that the blockchain node 104 is configured to provide.

[0092] Note that version numbers are not limited to being represented using integers, but instead may be composed of both letters and integers, for example, version numbers may be represented in hexadecimal.

[0093] In some examples, the blockchain node 104 may output a fixed-length representation of the version number instead of the version retrieved from memory. For example, the stored version number may be longer in length (e.g., 6 bytes), but only the first 4 bytes are output.

[0094] The versioned script engine may compare the obtained version number with a target version number provided by the native script engine as part of the sub-script. Execution of the sub-script (specifically, the second script portion) may depend on whether the obtained version number and the target version number match. For example, the second script portion may be executed only if the version numbers match. Alternatively, the second script portion may be executed only if the version numbers do not match.

[0095] In some examples, the second script portion itself may include one or more version functions, each associated with a respective script portion (i.e., a respective section of the second script portion) and a respective target version number. The versioned script engine may be configured to execute each respective script portion based on the associated respective target version number. For example, the respective script portion may be executed only if the respective target version number matches the version number associated with the blockchain node 104. Alternatively, the respective script portion may be executed only if the respective target version number does not match the version number associated with the blockchain node 104. There may be cases where some respective parts are executed (e.g., due to matching version numbers) and some respective script parts are not executed (e.g., due to mismatching version numbers), or vice versa.

[0096] The blockchain node 104 may be configured to output a result of executing the second script portion and / or each result of executing each of the second script portions, e.g., to a memory, to a stack, to one or more users 103a, 103b, or to the blockchain. For example, the result(s) may be included in an output (e.g., an OP_RETURN output) of the blockchain transaction.

[0097] In some examples, the blockchain node 104 may obtain multiple results, each result being a result of executing a respective versioned script. The blockchain node 104 may build a Merkle tree using the results as respective leaves of the Merkle tree and store the root of the Merkle tree on the blockchain, for example, as part of the OP_RETURN output. The versioned scripts may be related in some way, for example, may be related to the same layer 2 protocol or application, such as a token protocol.

[0098] In general, a versioned script may include any type of script or code. For example, a versioned script may include a portion of a script, e.g., Script, written in a native blockchain scripting language. In other words, the portion of code may include data and / or opcodes in the native scripting language that any blockchain node is configured to execute. For example, as in the case of a pay-to-public-key-hash (P2PKH) output, the portion of code may include a blockchain address and script that requests that the unlocking script include a corresponding public key and signature.

[0099] In other examples, the versioned script may include portions of the script written in a non-native scripting language, i.e., a scripting language native to a different blockchain, e.g., the native scripting language may be native to the Bitcoin blockchain and the non-native scripting language may be native to the Ethereum blockchain.

[0100] In some examples, the versioned script may include code written in a non-blockchain language, i.e., a language that is not native to any blockchain. For example, some of the code may be written using programming languages ​​such as C, C++, Go, Ruby, Python, Java, JavaScript, etc.

[0101] 6. Versioned Script Engine & OP_VER This section provides further examples of the described embodiments in the context of a version function that is one of a family of OP_VER opcodes. It should be recognized that OP_VER is just one example of a version function that may be used to trigger the termination of script execution by a native script engine and the triggering of script execution by a versioned script engine.

[0102] The use of a versioned script engine as part of a dual-validation script engine prevents network partitioning without imposing significant restrictions on the implementation and use of the family of OP_VER codes. The dual-validation script engine requires that these version-specific opcodes use an independent validation engine, referred to herein as a versioned engine, which is the default validation engine for versioned branches in the script and facilitates version-specific overlay validation. The term native engine refers to the native validation engine. During validation of a blockchain transaction, opcodes are executed sequentially by the native engine. Upon encountering the first OP_VER or related opcode, the native engine terminates and the validity of this execution is checked by the native engine. If the native execution is deemed valid, the versioned engine is instantiated (otherwise the entire process terminates and the transaction is rejected).

[0103] The versioned engine does not determine or influence whether a transaction is valid according to the blockchain protocol. Execution results from the versioned engine are interpreted independently of the native blockchain protocol and may be application specific.

[0104] A versioned engine may follow the same scripting rules as a native engine, except for OP_VER and its associated opcodes. This ensures that any versioned branch can be replayed in the future. Alternatively, a versioned engine may execute any code specified by a node version number. This approach offers great flexibility.

[0105] In summary, this dual-engine approach to OP_VER provides a consistent view of transaction validity by separating the versioned branch from the standard branch in the script. Additionally, the versioned engine does not require additional memory since it is instantiated only after the native engine has finished.

[0106] A common native validation process allows transactions to be published on-chain without the risk of partitioning the network, while the use of version-specific validation processes allows the creation of application-specific communities of nodes: all nodes validate transactions according to the native protocol, but only a subset of nodes validate specific applications and services, e.g., tokens, smart contracts, or snippets, specified by their node version number.

[0107] Because OP_VER, OP_VERIF, and OP_VERNOTIF are always executed in a versioned engine, a native engine must perform some specific steps when it encounters one of these opcodes, which we call Dual Engine Validation (DEV) rules.

[0108] The native validation process for versioning-related opcodes is as follows:

number

[0109] All remaining versioning related opcodes contained in the subscript are then executed in the versioned engine.

[0110] The behavior of versioning-related opcodes in a versioned engine is as follows:

number

[0111] From a logical point of view, <0x2abc> OP_VERIF is equivalent to OP_VER <0x2abc> OP_EQUAL OP_IF. However, from an execution point of view, when they are executed in a native engine, there is a difference worth mentioning: OP_VERIF consumes one element from the main stack, while OP_VER does not.

[0112] Following the logic above, the standard and versioned branches of code in a lock script can be contained within the same script, for example as shown below. [Table 3]

[0113] Depending on the particular blockchain protocol, in order to have a valid transaction, a standard branch may be required to appear before any versioning opcodes.

[0114] Note that the behavior of any opcode that immediately exits the script (e.g. OP_RETURN) remains unchanged, thereby terminating the entire script in both native and versioned engines.

[0115] Each node is assigned at most one version number, but a single version number may provide access to more than one branch of versioned code. Consider the following lock script: OP_VER 0x1 OP_EQUAL OP_IF <…> OP_VER 0x2 OP_EQUAL OP_NOTIF <…>

[0116] Here, the use of different conditionals means that both branches will be executed by the node with version number 0x1.

[0117] We now describe two examples of the DEV process from the perspective of a node with version number 0x1: the first uses OP_VER to add 1 to a predefined number in the versioned engine, and the second uses OP_VERIF to achieve the same result.

[0118] Example using OP_VER: The lock script is as follows:

number

[0119] The unlock script is: <sig> <pubkey>

[0120] Concatenating the unlock script and the lock script gives a script that is validated as follows:

number

[0121] At the end of the standard branch, the top of the native engine's main stack contains the result of the signature check (e.g. true): [Table 4] When OP_VER is encountered the native engine will exit. The subscript is created as follows:

number

[0122] A versioned engine is instantiated to execute the subscript. [Table 5]

[0123] Execution of the subscript begins with OP_VER, which pushes the version number of the node in a versioned engine (e.g., 0x1). [Table 6]

[0124] The remaining subscripts to be validated are: 0x1 OP_EQUAL OP_IF OP_5 OP_1ADD OP_ENDIF

[0125] Now 0x1 is pushed onto the main versioned stack: [Table 7]

[0126] Remaining subscripts: OP_EQUAL OP_IF OP_5 OP_1ADD OP_ENDIF

[0127] The OP_EQUAL opcode is executed and the result is written to the stack: [Table 8]

[0128] The rest of the script: OP_IF OP_5 OP_1ADD OP_ENDIF

[0129] The remaining opcodes are executed. OP_IF consumes the top element in the versioned stack, the remaining opcodes are consumed, and the result is written to the versioned stack: [Table 9]

[0130] The script validation results for all nodes in the network are:

number

[0131] Example using OP_VERIF : Lock script:

number

[0132] The unlock script is: <sig> <pubkey>

[0133] So the script to be validated is:

number

[0134] At the end of the standard branch, the top of the main stack contains the result of the signature check (e.g., true), and then 0x1 is pushed onto the stack. The state of the main stack for both engines is: [Table 10]

[0135] When OP_VERIF is encountered, the top element on the main stack is consumed and stored. The native engine then exits. Since execution is valid, a subscript is created as follows:

number

[0136] A versioned engine is instantiated to execute the subscript. [Table 11]

[0137] 0x1 is pushed onto the versioned engine's main stack. [Table 12]

[0138] OP_VERIF is executed as OP_VER OP_EQUAL OP_IF, and execution continues to OP_5 OP_1 OP_ADD. [Table 13]

[0139] The script validation results are as follows:

number

[0140] The dual validation described in the example above can be generalized as follows: When validating a transaction that contains a versioning-related opcode, the following logic flow is followed:

number

[0141] The use and functionality of the OP_VER family can be extended to facilitate scripts that contain multiple version numbers, for example: [Table 14]

[0142] The validation result from the native engine determines whether the transaction can be published in a block, but the validation result from the versioned engine does not affect the publication of the transaction. However, if the validation result from the versioned engine is recorded, the transaction must be valid since the versioned engine can only be instantiated if the native validation gives TRUE. Thus, for any off-chain record of versioned validation results, one can identify the published transaction and replay the execution of the script to obtain the same result. This ability to replay scripts at any given time in the future makes OP_VER-based applications and services more transparent and auditable, and therefore more trustworthy.

[0143] For more convenience, a record of the versioned validation results (i.e., the results of running the script following OP_VER) may be published in the transaction as an OP_RETURN payload or integrated into a Merkle tree whose Merkle root can be published in the Bitcoin transaction. This can be done by node 104, an application or service provider, or a dedicated third party. Since all results can be publicly obtained by replaying the execution of the relevant script, there would be no tampering with the results. For example, in an OP_VER-based token system, a token issuer could collect all token transactions that are at least six blocks deep, derive the system state, such as the allocation of tokens in circulation, from the versioned validation results, and publish the system state in a transaction signed by the issuer itself.

[0144] Below we describe a use case where token transactions are implemented with token-specific version numbers. A commensal token chain pegs token values ​​to Bitcoin and validates token rules using versioned branches. Each token chain has its own node version number and each token transaction represents only one type of token.

[0145] In this section, we explain how to merge tokens from different token chains into one transaction and how to split them afterwards. We assume that there is a token platform where all token issuers issue and manage tokens using a symbiotic token chain. Tokens can be traded as financial instruments on this platform. To simplify the exchange of transactions, the base currency for trading tokens is assumed to be fiat and settled independently against the blockchain (if the base currency is Bitcoin, an additional input-output pair is needed to indicate token transactions in the Bitcoin platform). We assume that there exists a trusted oracle that signs off on token transactions to make them Bitcoin valid after checking that they are token valid. The oracle is trusted in the sense that it guarantees to provide a signature for valid token transactions and will not burn tokens by creating valid transactions that are token invalid. More details are explained in the transaction example below.

[0146] Let Alice be a token issuer. Alice can partner with a Bitcoin node, say Natalie, that represents Alice's token by setting its node version number to 0xaaaa. Let Bob be another token issuer. Bob partners with a different Bitcoin node, say Mucha, that represents Bob's token by setting its node version number to 0xbbbb.

[0147] Starting with Alice's token, Alice creates a token issuance transaction to issue 1000 units of her token to investor Ivan. This can be considered an initial token offering (ITO). Alice's transaction is shown in Figure 6. Note that the token value is fixed to the number of satoshis in the Bitcoin transaction, so one token unit equals one satoshi. The token transfer is captured in a versioned branch, but a standard branch would create a valid Bitcoin transaction to carry the token transfer. Similarly, Bob issues 1000 units of Bob's token to another investor, Ivanka. Bob's transaction is shown in Figure 7.

[0148] Now, let us assume that Fred is a fund manager who is interested in both Alice's tokens and Bob's tokens. Fred buys 1000 units of tokens from Ivan and Ivanka respectively. These transfers of tokens can be captured in a single transaction as shown in Figure 8. Here, Fred's token portfolio is captured by one output of a transaction that combines the transfers of different types of tokens. After some valuation of Alice's tokens, Fred decides to sell them to Felix using the transaction shown in Figure 9.

[0149] Note that node 104 does not need two copies of Fred's digital signature because it does not validate both versioned branches in the output of TxID1. At this point, the state of Alice's token chain is TxID A , TxID1, and TxID2, and Bob’s token chain state is maintained by Natalie based on TxID B , TxID1, and TxID2 are maintained by Mucha.

[0150] An adversary able to intercept the transaction before it is published could modify the unlock script in the input of the token transaction such that the transaction is Bitcoin valid but the token is invalid. For example, an adversary could modify the signature in the unlock script that is verified by a versioned branch, i.e., <Sig Fred > <PK Fred > can be modified or removed. This type of attack effectively denies or disrupts the token service. One way to mitigate such attacks is for oracles to send transactions to versioned nodes via mAPI, a secure communication channel between Bitcoin nodes and users. After receiving token transactions, node 104 propagates them only after it finds a valid block header for the block containing those token transactions.

[0151] This use case demonstrates the advantage of having multiple version numbers in one output: the benefit is that each user of the token platform only needs to manage one transaction output at any time, regardless of how many types of tokens they hold.

[0152] 6. Further notes Other variations or use cases of the disclosed techniques may become apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0153] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0154] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0155] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, on those other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0156] Even more generally, any reference above to the term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element”, where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0157] It will be understood that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided according to any one or more of the following statements:

[0158] <Statement 1> A computer-implemented method for executing a script formed from a lock script of a first blockchain transaction and an unlock script of a second blockchain transaction, the script including a first script portion, a version function, and a second script portion, the method being executed by a blockchain node; executing a first script portion by a native script engine; Upon encountering the version function, the native script engine terminates execution of the script and determines whether the first script portion is valid according to a blockchain protocol; in response to determining that the first script portion is valid, the native script engine provides a sub-script including at least a version function and a second script portion to the versioned script engine; a step of executing the sub-script by the versioned script engine, wherein execution of the sub-script by the versioned script engine does not affect validity of the first blockchain transaction and / or the second blockchain transaction; The method includes:

[0159] <Statement 2> The method described in statement 1, wherein the first script portion includes a target node protocol version number, and the sub-script portion includes a target node protocol version number.

[0160] <Statement 3> The step of executing the subscript includes a step of executing a version function, and the step of executing the version function includes obtaining a node protocol version number of a blockchain node; outputting a node protocol version number, the node protocol version number being associated with a particular function that the blockchain node is configured to perform; The method according to statement 1 or 2, comprising:

[0161] <Statement 4> The method described in Statement 2 and Statement 3, wherein the step of executing a version function includes a step of determining whether the output node protocol version number matches the target node protocol version number.

[0162] <Statement 5> The above step of executing the version function is executing a second script portion if the output node protocol version number matches the target node protocol version number; if the output node protocol version number does not match the target node protocol version number, not execute the second script portion; The method according to claim 4, comprising:

[0163] <Statement 6> The above step of executing the version function is not executing the second script portion if the output node protocol version number matches the target node protocol version number; if the output node protocol version number does not match the target node protocol version number, executing a second script portion; The method according to claim 4, comprising:

[0164] <Statement 7> The method of any preceding statement, wherein the second script portion includes a plurality of respective version functions, each respective version function being associated with a respective script portion.

[0165] <Statement 8> Each respective script portion is associated with a respective target node protocol version number, the method comprising: A versioned script engine executes each script part based on the node protocol version number. The method according to statement 7, comprising:

[0166] <Statement 9> A method according to any preceding statement, comprising the step of outputting a result of said execution of the sub-script to a user.

[0167] <Statement 10> A step of storing the result of the above execution of the subscript in the blockchain. The method according to any preceding statement, including

[0168] <Statement 11> A step of obtaining a plurality of respective results, each of the respective results being obtained from execution of a respective script formed from a respective lock script of a respective first blockchain transaction and a respective unlock script of a respective second blockchain transaction, each of the respective scripts including a respective first script portion, a respective version function, and a respective second script portion; generating a Merkle tree based on the plurality of respective results; storing the Merkle root of the Merkle tree in the blockchain; The method according to any preceding statement, including

[0169] <Statement 12> The method of statement 3 or any statement subordinate thereto, wherein the step of outputting the node protocol version number includes the step of outputting a fixed-length representation of the node protocol version number.

[0170] <Statement 13> The method of any preceding statement, wherein the second script portion includes a portion of code written in a language other than the native blockchain language, and the blockchain node is configured to execute the code written in that language.

[0171] <Statement 14> The method according to statement 13, wherein a portion of the code is written in a blockchain language other than the native blockchain language.

[0172] <Statement 15> The method of any of statements 1 to 12, wherein the second script portion includes a locking condition based on a public key and / or a public key hash.

[0173] <Statement 16> The method of any preceding statement, wherein the first transaction and the second transaction are each token transactions, and the target node protocol version number is associated with a token protocol.

[0174] <statement 17> A method according to any preceding statement, where the version function is one of the opcodes OP_VER, OP_VERIF, or OP_VERIFNOT.

[0175] <Statement 18> A computer device, a memory comprising one or more memory units; a processing device comprising one or more processing units; wherein the memory stores code configured to be executed on a processor, the code being configured, when on the processor, to perform a method as recited in any preceding statement. Computer equipment.

[0176] <Statement 19> A computer program embodied on a computer-readable storage device and configured to execute the method according to any one of statements 1 to 17 when executed on one or more processors.

[0177] <Statement 20> A blockchain script engine including a native script engine and a version-controlled script engine, wherein the native script engine: executing a script including a first script portion, a version function, and a second script portion; When a version function is encountered, terminating execution of the script and determining whether the first script portion is valid according to a blockchain protocol; in response to determining that the first script portion is valid, providing a sub-script including at least a version function and a second script portion to the versioned script engine; configured to: The versioned script engine is configured to execute the sub-script. Blockchain scripting engine.< / pubkey> < / sig> < / pubkey> < / sig>

Claims

1. 1. A computer-implemented method for executing a script formed from a lock script of a first blockchain transaction and an unlock script of a second blockchain transaction, the script including a first script portion, a version function, and a second script portion, the method being executed by a blockchain node; a native script engine executing the first script portion; Upon encountering the version function, the native script engine terminates execution of the script and determines whether the first script portion is valid according to a blockchain protocol; in response to determining that the first script portion is valid, the native script engine provides a sub-script including at least the version function and the second script portion to a versioned script engine; the version-controlled script engine executing the sub-script, wherein execution of the sub-script by the version-controlled script engine does not affect validity of the first blockchain transaction and / or the second blockchain transaction; The method includes:

2. The method of claim 1 , wherein the first script portion includes a target node protocol version number and the sub-script portion includes the target node protocol version number.

3. The step of executing the sub-script includes the step of executing the version function, the step of executing the version function comprising: Obtaining a node protocol version number of the blockchain node; outputting the node protocol version number, the node protocol version number being associated with a particular function that the blockchain node is configured to perform; The method of claim 1 , comprising:

4. The step of executing the sub-script includes the step of executing the version function, the step of executing the version function comprising: Obtaining a node protocol version number of the blockchain node; outputting the node protocol version number, the node protocol version number being associated with a particular function that the blockchain node is configured to perform; Including, and executing the version function includes determining whether the output node protocol version number matches the target node protocol version number. The method of claim 2.

5. The step of executing the version function comprises: executing the second script portion if the output node protocol version number matches the target node protocol version number; not executing the second script portion if the output node protocol version number does not match the target node protocol version number; The method of claim 4 , comprising:

6. The step of executing the version function comprises: not executing the second script portion if the output node protocol version number matches the target node protocol version number; executing the second script portion if the output node protocol version number does not match the target node protocol version number; The method of claim 4 , comprising:

7. The method of claim 1 , wherein the second script portion includes a plurality of respective version functions, each respective version function being associated with a respective script portion.

8. Each respective script portion is associated with a respective target node protocol version number, the method comprising: said versioned script engine executing said respective script portions based on said node protocol version number. The method of claim 7, comprising:

9. The method of claim 1 , further comprising the step of outputting a result of said execution of said sub-script to a user.

10. storing a result of the execution of the subscript in the blockchain. The method of claim 1 , comprising:

11. obtaining a plurality of respective results, each respective result being obtained from the execution of a respective script formed from a respective lock script of a respective first blockchain transaction and a respective unlock script of a respective second blockchain transaction, the respective script including a respective first script portion, a respective version function, and a respective second script portion; generating a Merkle tree based on each of the plurality of results; storing the Merkle root of the Merkle tree in the blockchain; The method of claim 1 , comprising:

12. The method of claim 3 , wherein the step of outputting the node protocol version number comprises outputting a fixed length representation of the node protocol version number.

13. 2. The method of claim 1, wherein the second script portion includes a portion of code written in a language other than a native blockchain language, and the blockchain node is configured to execute code written in that language.

14. 14. The method of claim 13, wherein the portion of the code is written in a blockchain language other than the native blockchain language.

15. The method of claim 1 , wherein the second script portion includes a lock condition based on a public key and / or a public key hash.

16. 2. The method of claim 1, wherein the first transaction and the second transaction are each a token transaction, and the target node protocol version number is associated with a token protocol.

17. The method of claim 1 , wherein the version function is one of the opcodes OP_VER, OP_VERIF, or OP_VERIFNOT.

18. 1. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 2. The method of claim 1, wherein the memory stores code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of claim 1. Computer equipment.

19. A computer program embodied on a computer readable storage device and configured to perform the method of claim 1 when executed on one or more processors.

20. A blockchain script engine including a native script engine and a versioned script engine, the native script engine comprising: executing a script including a first script portion, a version function, and a second script portion; Terminating execution of the script when the version function is encountered and determining whether the first script portion is valid according to a blockchain protocol; in response to determining that the first script portion is valid, providing a sub-script including at least the version function and the second script portion to the versioned script engine; configured to: the versioned script engine is configured to execute the sub-script; Blockchain scripting engine.

Images