Versioned transactions

Abstract

A computer-implemented method of processing blockchain transactions, wherein the method is performed by a transaction processor and comprises: obtaining a first script from a first blockchain transaction, wherein the first script comprises a version opcode; obtaining a second script from a second blockchain transaction, wherein the second blockchain transaction comprises a version value; and executing the first script together with the second script, wherein said executing comprises executing the version opcode, and wherein said executing of the version opcode comprises outputting the version value of the second blockchain transaction.

Description

[0001] VERSIONED TRANSACTIONS

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to methods of generating and validating blockchain transactions that are processed based on a version of the spending transaction. Amongst other things, this allows for outputs that can be spent (i.e. assigned or transferred) in multiple ways.

[0004] BACKGROUND

[0005] A Bitcoin transaction contains four fields: a version number, a locktime value, a list of inputs and a list of outputs. The serialised byte format of these fields, called raw format, is used for publishing transactions, and broadcasting them between network peers. The hashed raw format (sha256(sha256(raw data)) creates the transaction ID. Once the transaction is signed, the version number and locktime value cannot be changed. Depending on the chosen sighash flag, the list of inputs and list of outputs may or may not be changed.

[0006] The version number is a 4-byte field typically used to indicate the consensus rules that apply to a Bitcoin transaction. Currently the version number is set to 1 for all BSV transactions. In BTC, transactions are typically version 1, but transaction version 2 is associated with support for OP_CHECKSEQUENCEVERIFY as specified by Bitcoin Improvement Proposal (Bl P)-68 and BIP-112.

[0007] Historically, OP_VER and its related opcodes OP_VERIF, OP_VERNOTIF were defined as instructions that allow transactions to be validated in different ways, depending on the Bitcoin node evaluating them. According to this definition, nodes in the Bitcoin network view and validate transactions selecting branches in the locking script that depends on the node software version being executed, for example using OP_VERIF. In this implementation, OP_VER reads the node protocol version number from a local file (this file used to be serialize. h), converts the value to a 4-byte number and pushes it to the stack. OP_VERIF and OP_VERNOTIF, in addition to pushing the value to the stack, compare it with another value previously pushed to the stack and push the result of the evaluation (True or False). Figure 3 shows an example of how a transaction that uses OP_VERIF would be interpreted by the nodes in the Bitcoin network according to this definition. When the transaction is published to the Bitcoin network each node evaluates the transaction according to its node software version, with only nodes with version 2 accepting the transaction.

[0008] These version-specific opcodes are not currently enabled in the Bitcoin validation engine.

[0009] SUMMARY

[0010] Blockchain transactions were initially mainly used for exchanging value between two or more parties. With the spreading of blockchain-based applications, transactions are now used for a wide range of use-cases such as, for example, tokenisation, certification, or tracking. For more advanced use cases, when a transaction is created, it is not always obvious when and who will spend it. This poses additional complexity in the creation of transactions and potentially limits some of these use cases.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method of processing blockchain transactions, wherein the method is performed by a transaction processor and comprises: obtaining a first script from a first blockchain transaction, wherein the first script comprises a version opcode; obtaining a second script from a second blockchain transaction which references the first blockchain transaction, wherein the second blockchain transaction comprises a version value; and executing the first script together with the second script, wherein said executing comprises executing the version opcode, and wherein said executing of the version opcode comprises outputting the version value of the second blockchain transaction.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method of generating a blockchain transaction, wherein the method is performed by a first party and comprises: generating a first blockchain transaction comprising a first script, wherein the first script comprises one or more respective version opcodes, wherein each respective version opcode is configured so as to, when executed during execution of the first script together with a second script of a second blockchain transaction which references the first blockchain transaction, cause a version value of a second blockchain transaction to be output; and sending or causing the first blockchain transaction to be sent to one or more nodes of a blockchain network.

[0013] According to one aspect disclosed herein, there is provided a computer-implemented method of generating a blockchain transaction, wherein a blockchain comprises a first blockchain transaction comprising a first script, wherein the first script comprises one or more respective version opcodes, wherein each respective version opcode is configured so as to, when executed during execution of the first script together with a second script of a second blockchain transaction which references the first blockchain transaction, cause a version value of a second blockchain transaction to be output, wherein the method is performed by a second party and comprises: generating second blockchain transaction comprising a version value, wherein the second blockchain references the first blockchain transaction and comprises a second script to be executed together with the first script of the first blockchain transaction; and sending or causing the second blockchain transaction to be sent to one or more nodes of a blockchain network.

[0014] According to one aspect disclosed herein, there is provided a computer-implemented method of facilitating the processing of blockchain transactions, wherein the method is performed by a third party and comprises: maintaining a register, wherein the register comprises a plurality of respective version values, each respective version value being mapped to a respective application and / or a respective multicast address.

[0015] As used herein, the second blockchain transaction referencing first blockchain transaction means that an input (comprising the second script) of the second blockchain transaction references an output (comprising the first script) of the first blockchain transaction.

[0016] Disclosed herein is a technique for creating "versioned transactions" based on an existing opcode, OP_VER, which is currently disabled. This technique adds flexibility to the transaction locking script, allowing for multiple ways to unlock it, dependent on the transaction version. The technique is based on a new interpretation of OP_VER and its related opcodes. OP_VER pushes a (e.g. 4-byte) version number to the blockchain node script engine. In this implementation, the version number refers to the version of the transaction spending an output that contains OP_VER. The version value is comprised in the spending transaction, but is not part of the unlocking script of the spending transaction.

[0017] Versioned transactions are more flexible because they can be spent in several ways, each of them separated by OP_VER statements. In other words, users can spend a versioned transaction according to different sets of rules that can be chosen by specifying the transaction version at spend time (i.e. not at creation time). Moreover, versioned transactions may be used for efficient filtering of transactions and to prevent UTXO merging (i.e. to keep two steams of transactions separate). This technique may also be used in conjunction with IP multicast addresses to create efficient overlay networks.

[0018] For simplicity, the version opcode will be referred to herein as "OP_VER". However the disclosure is not limited to an opcode having that specific label, or to a blockchain protocol that makes use of an opcode having that specific label. More generally, while embodiments will be described in terms of "OP_VER" of a blockchain scripting language, the same embodiments can be implemented using any opcode, which when called by a script engine (or script interpreter) performs the particular function described herein as being performed by OP_VER, the function being to cause a transaction processor to obtain and output a transaction version value of the spending transaction. The version opcode may cause the transaction processor to perform one or more additional actions. The version value may take any suitable form, e.g. a number, a string, an alphanumeric, a sequence of bytes, etc.

[0019] In general blockchain protocols use a scripting language for transactions. A script is essentially a list of elements, which may be data or instructions. The instructions are referred to in the literature as: script words, opcodes, commands, or functions. These terms may be used interchangeably herein. Opcodes (short for operation codes) perform predefined operations on the data within a script.

[0020] BRIEF DESCRIPTION OF THE DRAWINGS

[0021] To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

[0022] Figure 1 is a schematic block diagram of a system for implementing a blockchain; Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain;

[0023] Figure 3 schematically illustrates a transaction that spends a locking script containing OP_VER, wherein when the transaction is published to the Bitcoin network each node evaluates the transaction according to its software version, with only nodes with version 2 accepting it;

[0024] Figure 4 schematically illustrates a transaction that spends a locking script containing OP_VER (i.e. a versioned transaction), wherein when the transaction is published to the blockchain network each node evaluates the transaction according to the transaction version, with all the nodes accepting it because the transaction version is 2;

[0025] Figure 5 schematically illustrates an example of an application-specific transaction using OP_VER, with the transaction being spent, broadcast to the blockchain network and then multicast to the application users; and

[0026] Figure 6 is a schematic block diagram of some node software for processing transactions

[0027] DETAILED DESCRIPTION OF EMBODIMENTS

[0028] 1. VERSIONED TRANSACTIONS

[0029] Embodiments of the present disclosure make use of a "version opcode" to affect the processing of blockchain transactions, meaning that a transaction is processed according to the transaction version (or simply the version) of the transaction.

[0030] Figure 1 illustrates an example system for implementing the described embodiments. Alice 103a is configured to generate a first transaction having a first script comprising a version opcode. The first script may be a locking script which is part of an output of the first transaction. Alice 103a submits the first transaction to the blockchain network 106, or to a third party for submitting to the blockchain network 106. Bob 103b is configured to generate a second transaction having a second script. The second script may be an unlocking script which is part of an input of the second transaction. The second transaction references the first transaction, e.g. using a transaction identifier of the first transaction. As an example, the input of the second transaction may reference the output of the first transaction, e.g. using a transaction identifier of the first transaction and an output index of the output of the first transaction. The second transaction has a "version field" containing a transaction version number. The transaction version number may be a 4 byte number. The version number may be a different size, depending on the blockchain protocol. Bob 103b submits the first transaction to the blockchain network 106, or to a third party for submitting to the blockchain network 106.

[0031] A transaction processor (e.g. a blockchain node 104) is configured to obtain the first and second transactions, either directly from Alice 103a and / or Bob 103b, from a (different) blockchain node 104, or from the blockchain 150.

[0032] The transaction processor extracts the first script from the first transaction and the second script from the second transaction and executes the first script together with the second script. Upon executing the version opcode from the first script, the transaction processor is configured to obtain (e.g. extract) the transaction version number from the second transaction and output the transaction version number, e.g. to memory. The memory may be a stack-based memory. In other words, the version opcode is configured to cause the transaction processor to output the transaction version number. That is, the blockchain protocol may stipulate that when the version opcode is called, the transaction processor is to extract and output the transaction version number. Other options for outputting the transaction version number include sending the transaction version to number to Alice 103a and / or Bob 103b or a third party, or publishing the transaction version number on the blockchain 150 or to another publicly accessible resource.

[0033] In some examples, Alice 103a may include a first number as part of the first script. Upon executing the version opcode from the first script, the transaction processor may be configured to verify if the first number is the same as the transaction version number. Further execution of the first and / or second script may be dependent on the first number being the same as the transaction version number. For instance, the first number and / or the version opcode may be associated with a sub-script, and the sub-script may be executed only if the first number matches the transaction version number. Any suitable association may be implemented. For example, the sub-script may simply follow (or precede) the version opcode.

[0034] Alternatively, upon executing the version opcode from the first script, the transaction processor may be configured to verify if the first number is note the same as the transaction version number. Further execution of the first and / or second script may be dependent on the first number not being the same as the transaction version number. For instance, the first number and / or the version opcode may be associated with a sub-script, and the subscript may be executed only if the first number does not match the transaction version number.

[0035] Use of the version opcode in this way allows for (an output of) a transaction to be spent (i.e. assigned, transferred, etc.) dependent on the version number of the spending transaction.

[0036] In some examples, one type of version opcode (e.g. OP_VER) may only cause the transaction processor to output the transaction version number and a different type of version opcode (e.g. OP_VERIF or OP_VERNOTIF) may cause the transaction processor to perform the verifications described above.

[0037] In some examples, Alice 103a may include multiple version opcodes. One or more version opcodes may simply cause the transaction processor to output the transaction version number. Additionally or alternatively, one or more version opcodes may be associated with a respective number (e.g. a second number associated with a second version opcode, a third number associated with a third version opcode, and so on) and cause the transaction processor to verify if the transaction version number matches or does not match the respective number. As described above, each version opcode may be associated with a subscript which may only be executed dependent on the outcome of the verifications. In some examples, each of the respective numbers are different numbers. The transaction processor may process the second transaction as part of validating the second transaction. Therefore validation of the second transaction is dependent on the version number of the second transaction. If the transaction processor determines that, after executing the first and second scripts, the second transaction is valid, the transaction processor may publish (or at least attempt to publish) a block 151 to the blockchain 150 that contains the second transaction. Additionally or alternatively, the transaction processor may send the second transaction to one or more third parties. For example, the transaction processor may propagate the second transaction to one or more blockchain nodes 104.

[0038] In some examples, a register (i.e. table, list, etc.) may be maintained, whereby transaction version numbers are mapped to applications. I.e. a first number mapped to a first application, a second number mapped to a second application, etc. The version numbers may be mapped to one or more of: a name of the application, an identifier of the application, an owner of the application, a public key associated with the application. In these examples, the transaction processor may determine whether the second transaction has been generated by a party associated with the application, and only accept (e.g. validate) the transaction if the second transaction has been generated by said party. Said determining may be based on whether the second transaction includes a signature corresponding to a public key associated with the party, e.g. the public key mapped to the version number in the register. The register may be maintained by one or more blockchain nodes 104, e.g. the transaction processor. Alternatively, the register may be maintained by a third party, e.g. a trusted service provider. The third party may make the register available to the transaction processor, e.g. by publishing the register and / or sending the register to the transaction processor.

[0039] In some examples, the transaction version number may be mapped to (i.e. linked to) a multicast address. The transaction processor may broadcast the second transaction to the multicast address. The mapping of version numbers to multicast addresses may be maintained in a register, e.g. the same register as the mapping of version numbers to applications. Whilst embodiments have been described in terms of Alice 103a generating the first transaction and Bob 103b generating the second transaction, in general both Alice 103a and Bob 103b may be configured to generate the first and / or second transaction.

[0040] Note that unless the context requires otherwise, "first", "second" and so on are used merely as labels and do not necessarily imply a specific order.

[0041] 1.1 OP VER redefined

[0042] To date, the OP_VER opcode has never been officially implemented, but in one of the first Bitcoin node software versions it was described as an opcode that requires the Bitcoin script engine to read the node protocol version number from a local file and push it to the stack. Herein, OP_VER is redefined such that 'version' refers to the version of the transaction spending a UTXO that contains OP_VER in its locking script. Following this logic, OP_VER can be used to create transactions that can be spent in multiple predefined ways. The version chosen is specified when the transaction is spent, by selecting a specific transaction version. These transactions are referred to as versioned transactions.

[0043] In this context, OP_VER does not push the version of the node software to the stack, instead it pushes the transaction version of the spending transaction (e.g. transaction. nVersion).

[0044] While the previous interpretation of OP_VER was vulnerable to attacks potentially leading to blockchain forks, this new definition is not susceptible to the same attacks. The transaction version is chosen and signed along with the other transaction fields by the user spending the transaction. Therefore, all nodes 104 that execute the script to validate the transaction get the same result. This is because the version is read from the spending transaction instead of the node software (nodes 104 may run different software versions), and the version field of the spending transaction, once signed, cannot be changed.

[0045] This definition of OP_VER, along with its related opcodes OP_VERIF and OP_VERNOTIF will enable transactions that are spendable for multiple use-cases, optimising transaction management through transaction versioning. Figure 4 shows an example of how a versioned transaction would be interpreted by the nodes in the network 106 according to this definition. When the transaction is published to the network 106 each node 104 evaluates the transaction according to the transaction version, all the nodes 104 accept it because the transaction version is 2.

[0046] From a technical point of view, OP_VER can be generally used to create branches in a locking script. A pseudocode for such a locking script is as follows:

[0047] OP_FALSE (top of the stack is false if no branch is executed)

[0048] <version 1> OP_VERIF

[0049] <Locking script 1>

[0050] OP_ENDIF

[0051] <version 2> OP_VERIF

[0052] <Locking script 2>

[0053] OP_ENDIF

[0054] <version n> OP_VERIF

[0055] <Locking script n>

[0056] OP_ENDIF

[0057] A user 103 can spend this locking script by satisfying the conditions in one of the branches (<Locking script x>) and specifying the selected branch (x) in the transaction version. As mentioned, the branch chosen must be specified in the transaction version of the spending transaction. For example, an unlocking script for branch 2 must specify transaction version 2 in order to spend the locking script. A possible valid unlocking script for the locking script above is:

[0058] Transaction version (specified in the header): 2

[0059] Unlocking script: <Unlocking script 2>

[0060] If the branch requires a digital signature to be unlocked, the user 103 signing the transaction is explicitly committing to a specific branch, publicly visible to everyone. This could be used to enable new use-cases that require users 103 to commit to a specific version, or where a specific version indicates something meaningful. OP_VERIF and OP_VERNOTIF behave in a similar way: OP_VERIF is equivalent to OP_VER OP_EQUAL OPJF while OP_VERNOTIF is equivalent to OP_VER OP_EQUAL OP_NOTIF.

[0061] 1.2 Transaction interpretation and filtering

[0062] OP_VER allows a locking script to enforce its spending transaction to have a particular version number or a version number from a given set. When a transaction is serialised, the version number is at the beginning of the serialisation. It allows one to interpret the transaction without fully parsing the transaction. For example, version 1 implies Alice 103a, version 2 implies Bob 103b. When given a transaction that is valid (after checking its Merkle proof), one can just read the version number at the beginning to determine who spent it. This provides a more efficient way to interpret a transaction than using any other types of flags in a transaction. OP_VER can also be used to filter transactions.

[0063] 1.3 Prevent UTXO merging

[0064] Another observation is that if Alice 103a sends Charlie 1 bitcoin with a locking script that enforces its spending transaction to have version 1, while Bob 103b sends Charlie 1 bitcoin with a locking script that enforces its spending transaction to have version 2, then Charlie will not be able to spend the two outputs in a single transaction. This example illustrates that OP_VER provides a mechanism to force outputs to be spent in different transactions. This is powerful as it can be used to prevent two or more transaction chains from merging. Independent transaction chains can be verified independently.

[0065] In the context of horizontal scaling and parallelising transaction validation, independent verification provides a natural way to shard transactions with zero communication overhead between each shard. For application providers who require fast transaction validation, they are incentivised to force their transaction to be isolated from other transaction chains by using OP_VER.

[0066] 1.4 Transaction versioning

[0067] As mentioned, using OP_VER in the locking script means that now transactions can be versioned. This enables the creation of transactions that can be spent in multiple ways (i.e. according to different rules). Applications may require that a transaction can be spent for different use-cases and / or different users. They can create versioned transactions and associate a version to each use-case or user. Each use-case has different rules, specified in different branches of the locking script using OP_VER or one of the related codes. The spender commits to a specific use-case by selecting the relative transaction version. Depending on the use-case, different rules (defined in the locking script) apply.

[0068] Versioned transactions can also be used for simple use-cases, where only one possible version is accepted. This is useful when an entity, for example a software company, wants their users to spend transactions using a specific transaction version. In this case the software company can create versioned transactions with only one OP_VERIF branch and hands them to the users for software related usages. This is useful for classifying transactions and filtering them (e.g. all transactions with transaction version 123 are part of the software xyz). Since the version number appears at the beginning of the serialised transaction it can be quickly and easily identified, enabling efficient identification of relevant transactions.

[0069] 1.5 Mapping

[0070] The transaction version field is typically 4 bytes, meaning that it is possible to map a maximum of 232use-cases (4,294,967,296) per application. Different applications can, in fact, re-use the same transaction version. In other words, a version number must be unique only within the same application or ecosystem of applications.

[0071] A way to resolve version collisions (i.e. two applications using the same transaction version) is to have a global organisation (or group of organisations) that assigns a version number using a shared register similar to what IANA (the global coordination of the DNS Root, IP addressing, and other Internet protocol resources) does for IP addresses. We refer to this register as a Transaction Version Register, or TVR. TVR allows for reserving transaction versions for specific applications or use-cases: versioned transactions using versions reserved in the TVR would be validated and inserted in a block only if they are created by an entity approved in the shared register and associated to that version. TVR would need to be maintained, or at least accessed, by blockchain nodes 104. This is a requirement as they are the only ones that can enforce the rules. If a specific transaction version is reserved for an application and this is agreed in the TVR, then only transactions generated within that application are considered valid. This means versioned transactions created by other parties would be automatically considered invalid, even if the script engine says that the script is formally valid.

[0072] Linking transaction versions to applications authorised in the TVR can be achieved in several ways, for example by recording in the TVR the public keys that can be used to sign a transaction. If a versioned transaction does not contain a signature created by one of the public keys specified in the shared register it would be automatically deemed invalid.

[0073] Alternatively, the authorised parties need a unequivocable way to be able to be identified in the TVR (e.g. using PKI).

[0074] Hybrid approaches are also possible, with some transaction versions reserved for relevant applications (e.g. government or bank applications), and other transaction versions freely available to use for other applications (e.g. private applications).

[0075] 1.7 Usage with multicast

[0076] OP_VER can be linked to an IP multicast address to create overlay networks for specific applications. Overlay networks are used to optimise the network traffic (e.g. transaction broadcasting) in the blockchain network 106: applications only receive the section of traffic related to their usage. This approach drastically reduces the bandwidth and hardware required, leading to a higher scalability of the entire ecosystem.

[0077] Network traffic may be partitioned using IP multicast addresses: a multicast address is linked to an application, and all the users of that service send and receive transactions through that multicast address. Only blockchain nodes must listen to all the multicast addresses to validate transactions. Nodes can send SPV proofs to the application multicast address to inform the interested parties that a transaction has been published. The multicast address may be linked to a transaction version. When a transaction is spent with a specified version, it can be broadcast to the interested group. A versioned transaction can potentially belong to different overlay networks when it is created. When it is spent, the specific overlay network is identified using the specified transaction version, and the spending transaction is broadcast only to the associated multicast address. Specialised overlay networks only receive transactions with a related transaction version, reducing the network traffic drastically (transactions transmitted). As for other multicast overlay networks, nodes 104 listen to all the multicast addresses to validate and publish transactions.

[0078] As noted in the previous section, the transaction version field is typically 4 bytes, meaning that it is possible to map a maximum of 232(4,294,967,296) IP multicast addresses. Since the transaction version is now linked to a multicast address, the re-use of the transaction version for different applications is not acceptable anymore. This is because transactions with a specific version are now sent to a multicast address that belongs to an application. Therefore, a shared register, such as TVR, or an equivalent may be necessary in this case. Applications can be assigned a version number using this shared register, the same register can be extended to map a version number to an IP multicast address. The association can be, for example:

[0079] • a multicast address cryptographically linked to an application, or

[0080] • a multicast address assigned by a third-party.

[0081] 1.8 Example Use Cases

[0082] 1.8.1 Banks

[0083] A bank can reserve a multicast address and a transaction version using the relevant shared registries. They can enforce all the payments to be versioned transactions starting with the reserved transaction version, for example using a script like this:

[0084] <bank code> OP_VERIF <locking script> OP_ELSE OP_0 OP_ENDIF.

[0085] The <bank code> can also include a country code, to reflect similar codifications used for bank transfers. Bank users willing to move their funds must create transactions specifying the bank code. The same locking script structure must be enforced in all the bank related transactions (e.g. for example the bank app might do that automatically). The network nodes 104, when publishing a bank-related transaction, would send an SPV proof to the linked IP multicast address. This creates a bank overlay network, where all the bank branches are notified for every operation.

[0086] 1.8.2 Train tokens

[0087] A travel company releases train tokens valid for multiple train companies. Each company has an associated 4-byte code and a linked IP multicast address. The travel company releases the train tokens using blockchain transactions. The train token transaction contains a locking script with a <train company code> OP_VERIF for each allowed company. A user can buy a train token without having to choose the train company they are willing to use immediately.

[0088] When a user wants to use a train token, they go to the station and spend the transaction, specifying the train company code in the transaction version. The blockchain nodes 104 publish the train token transaction and send an SPV proof to the IP multicast address linked to the train company code. All the stations where the train company operates are subscribed to the same multicast address and, therefore, receive a notification. The ones where the token is valid keep a copy of the transaction enabling the passage of the arrival station turnstile. Note that this technique is used to enable the travel on a selected route, not to send the payment (as the ticket was paid in advance).

[0089] In another configuration, the user can claim the ticket beforehand by creating the transaction, specifying the train company code, and sending the signed transaction to the train company server. The train company shows acceptance of the train token by publishing the train token transaction to the blockchain and sending a confirmation, for example in form of ticket token transaction, to the user. Using the linked multicast address all the relevant parties are aware of the current state of the ticket. In both configurations, only the interested train company is involved. The process is transparent for the other companies that do not receive any unnecessary transaction.

[0090] 1.8.3 Tokens

[0091] Tokens (e.g. central bank digital currency (CBDC) tokens) may be issued based on versioned transactions. Versioned transactions linked to multicast address can create more efficient communities of token holders. Tokens can be more easily manageable and interchangeable by coding specific spending conditions or actions that depend on the token version.

[0092] 1.8.4 Metanet

[0093] Metanet branches may be created using versioned transactions. Metanet nodes can be created with different conditions, representing different users or use-cases. Users can filter Metanet trees using the transaction version of the branches.

[0094] 2. EXAMPLE SYSTEM OVERVIEW

[0095] A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below.

[0096] Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.

[0097] The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data.

[0098] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.

[0099] 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 criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0100] An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

[0101] Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.

[0102] Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive.

[0103] The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.

[0104] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.

[0105] In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

[0106] Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0107] The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.

[0108] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g. proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations.

[0109] Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 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 recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, 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).

[0110] Some or all of the parties 103 may be connected as part of a different network, e.g. 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; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively.

[0111] The computer equipment 102 of each party 103 comprises respective processing apparatus comprising 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 memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus 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 smartwatch. The computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

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

[0113] The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0114] Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

[0115] The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing 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 the nodes 104 in the network 106.

[0116] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

[0117] Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contact" refers to a transaction that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0118] 3. UTXO-BASED MODEL

[0119] Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

[0120] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of 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 embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.

[0121] Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled " TxT. It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “ Txo" in Figure 2. TAT? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0122] The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and 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 discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour. One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

[0123] The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.

[0124] So in the example illustrated, UTXOo in the output 203 of TAT? comprises a locking script [Checksig PA which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA contains a representation (i.e. a hash) of the public key PA from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0125] When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check T1 whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria).

[0126] Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain.

[0127] Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

[0128] The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

[0129] 4. NODE SOFTWARE

[0130] Figure 6 illustrates an example of the node software 450 that is run on each blockchain node 104 of the network 106, in the example of a UTXO- or output-based model. Note that another entity may run node software 450 without being classed as a node 104 on the network 106, i.e. without performing the actions required of a node 104. The node software 450 may contain, 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 functional modules 455. Each node 104 may run node software that contains one or more of: a consensus module 455C (for example, proof-of-work), a propagation module 455P and a storage module 455S (for example, a database). The consensus module 455C may contain a validation module (not shown) configured to validate transactions according to the blockchain protocol. The validation module may instead be separate from the consensus module 455C. One or more of the modules may operate in parallel. A node 104 may contain additional modules. The protocol engine 401 is typically configured to recognize the different fields of a transaction 152 and process them in accordance with the node protocol. When a transaction 152j (Txj) is received having an input pointing to an output (e.g. UTXO) of another, preceding transaction 152i (Txm-), then the protocol engine 451 identifies the unlocking script in Txj and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Txtbased on the pointer in the input of Txj. Txtmay be published on the blockchain 150, in which case the protocol engine may retrieve Txtfrom a copy of a block 151 of the blockchain 150 stored at the node 104. Alternatively, Txtmay yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Txtfrom the ordered set 154 of unpublished transactions maintained by the nodel04.

[0131] Either way, the script engine 451 identifies the locking script in the referenced output of Txtand passes this to the script engine 452.

[0132] The script engine 452 thus has the locking script of Txtand the unlocking script from the corresponding input of Txj. For example, transactions labelled Tx0and Tx are illustrated in Figure 2, but the same could apply for any pair of transactions. The script engine 452 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 453 in accordance with the stack-based scripting language being used (e.g. Script).

[0133] By running the scripts together, the script engine 452 determines whether or not the unlocking script meets the one or more criteria defined in the locking script - i.e. does it "unlock" the output in which the locking script is included? The script engine 452 returns a result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result "true". Otherwise it returns the result "false".

[0134] In an output-based model, the result "true" from the script engine 452 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 451 that must be met as well; such as that the total amount of digital asset specified in the output(s) of TXj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Txthas not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction Txj. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on condition that Txj is indeed validated, the decision engine 454 may select to control both of the consensus module 455C and the propagation module 455P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 455C adding Txj to the node's respective ordered set of transactions 154 for incorporating in a block 151, and the propagation module 455P forwarding Txj to another blockchain node 104 in the network 106. Optionally, in embodiments the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. E.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee.

[0135] Note also that the terms "true" and "false" herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, "true" can refer to any state indicative of a successful or affirmative outcome, and "false" can refer to any state indicative of an unsuccessful or non-affirmative outcome. For instance in an account-based model, a result of "true" could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true).

[0136] 5. FURTHER REMARKS

[0137] Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims.

[0138] For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.

[0139] In preferred embodiments of the invention, the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform 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 blocks (recall that these entities are not considered nodes of the preferred bitcoin network 106).

[0140] In other embodiments of the 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 instance, 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.

[0141] Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104.

[0142] Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof- of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof- of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator.

[0143] It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements.

[0144] Statement 1. A computer-implemented method of processing blockchain transactions, wherein the method is performed by a transaction processor and comprises: obtaining a first script from a first blockchain transaction, wherein the first script comprises a version opcode; obtaining a second script from a second blockchain transaction, wherein the second blockchain transaction comprises a version value; and executing the first script together with the second script, wherein said executing comprises executing the version opcode, and wherein said executing of the version opcode comprises outputting the version value of the second blockchain transaction.

[0145] Statement 2. The method of statement 1, wherein said outputting comprises outputting the version value to a stack-based memory.

[0146] Statement 3. The method of statement 1 or statement 2, wherein the first script comprises a first value, and wherein said executing of the version opcode comprises verifying if the first value matches the version value.

[0147] Statement 4. The method of statement 3, wherein the version opcode is associated with a first sub-script of the first script, and wherein said executing of the version opcode comprises executing the first sub-script only if the first value matches the version value.

[0148] Statement 5. The method of statement 1 or statement 2, wherein the first script comprises a first value, and wherein said executing of the version opcode comprises verifying if the first value does not match the version value.

[0149] Statement 6. The method of statement 5, wherein the version opcode is associated with a first sub-script of the first script, wherein said executing of the version opcode comprises executing the first sub-script only if the first value does not match the version value.

[0150] Statement 7. The method of any preceding statement, wherein the first script comprises a plurality of respective version values, each associated with a respective version opcode, and wherein each respective version opcode is associated with a respective sub-script.

[0151] Statement 8. The method of any preceding statement, comprising determining whether the second blockchain transaction is a valid transaction based on said execution of the first script together with the second script. Statement 9. The method of statement 8, comprising, upon determining that the second blockchain transaction is a valid transaction, processing a block comprising the second blockchain transaction and / or forwarding the second blockchain transaction to one or more parties.

[0152] Statement 10. The method of any preceding statement, wherein the transaction processor comprises a blockchain node.

[0153] Statement 11. The method of any of statements 8 to 10, wherein a first register is maintained in which respective version values are mapped to respective applications, and wherein said determining if the second blockchain transaction is a valid transaction comprises determining, based on the register, whether the second blockchain transaction has been generated by a party associated with the application mapped to the version value of the second blockchain transaction.

[0154] Statement 12. The method of statement 11, comprising maintaining the first register.

[0155] Statement 13. The method of any preceding statement, wherein the version value of the second blockchain transaction is linked to a multicast address, and wherein the method comprises sending the second blockchain transaction to the multicast address.

[0156] Statement 14. The method of statement 13, wherein a second register is maintained in which respective version values are mapped to respective multicast addresses, and wherein said sending of the second blockchain transaction to the multicast address comprises looking-up the multicast address in the second register using the version number of the second blockchain transaction.

[0157] Statement 15. A computer-implemented method of generating a blockchain transaction, wherein the method is performed by a first party and comprises: generating a first blockchain transaction comprising a first script, wherein the first script comprises one or more respective version opcodes, wherein each respective version opcode is configured so as to, when executed during execution of the first script together with a second script of a second blockchain transaction, cause a version value of a second blockchain transaction to be output; and sending or causing the first blockchain transaction to be sent to one or more nodes of a blockchain network.

[0158] Statement 16. The method of statement 15, wherein one or more of the plurality of respective version opcodes are associated with a respective value, and wherein the one or more of the respective version opcodes are configured so as to, when executed, verify that the respective value matches the version value.

[0159] Statement 17. The method of statement 16, wherein one or more of the plurality of version opcodes are associated with a respective sub-script of the first script, and wherein the one or more of the respective version opcodes are configured so as to, when executed, cause the respective sub-script to be executed only if the respective value matches the version value.

[0160] Statement 18. The method of statement 15, wherein one or more of the plurality of respective version opcodes are associated with a respective value, and wherein the one or more of the respective version opcodes are configured so as to, when executed, verify that the respective value does not match the version value.

[0161] Statement 19. The method of statement 18, wherein one or more of the plurality of version opcodes are associated with a respective sub-script of the first script, and wherein the one or more of the respective version opcodes are configured so as to, when executed, cause the respective sub-script to be executed only if the respective value does not match the version value.

[0162] Statement 20. A computer-implemented method of generating a blockchain transaction, wherein a blockchain comprises a first blockchain transaction comprising a first script, wherein the first script comprises one or more respective version opcodes, wherein each respective version opcode is configured so as to, when executed during execution of the first script together with a second script of a second blockchain transaction, cause a version value of a second blockchain transaction to be output, wherein the method is performed by a second party and comprises: generating second blockchain transaction comprising a version value, wherein the second blockchain references the first blockchain transaction and comprises a second script to be executed together with the first script of the first blockchain transaction; and sending or causing the second blockchain transaction to be sent to one or more nodes of a blockchain network.

[0163] Statement 21. A computer-implemented method of facilitating the processing of blockchain transactions, wherein the method is performed by a third party and comprises: maintaining a register, wherein the register comprises a plurality of respective version values, each respective version value being mapped to a respective application and / or a respective multicast address.

[0164] Statement 22. The method of statement 21, comprising making the register available to one or more transaction processors.

[0165] Statement 23. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 22.

[0166] Statement 24. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 22.

[0167] According to another aspect disclosed herein, there may be provided a method comprising the actions of some or all of: the transaction processor, the first party, the second party, the third party. According to another aspect disclosed herein, there may be provided a system comprising the computer equipment of some or all of: the transaction processor, the first party, the second party, the third party.

Claims

CLAIMS1. A computer-implemented method of processing blockchain transactions, wherein the method is performed by a transaction processor and comprises: obtaining a first script from a first blockchain transaction, wherein the first script comprises a version opcode; obtaining a second script from a second blockchain transaction which references the first blockchain transaction, wherein the second blockchain transaction comprises a version value; and executing the first script together with the second script, wherein said executing comprises executing the version opcode, and wherein said executing of the version opcode comprises outputting the version value of the second blockchain transaction.

2. The method of claim 1, wherein said outputting comprises outputting the version value to a stack-based memory.

3. The method of claim 1 or claim 2, wherein the first script comprises a first value, and wherein said executing of the version opcode comprises verifying if the first value matches the version value.

4. The method of claim 3, wherein the version opcode is associated with a first subscript of the first script, and wherein said executing of the version opcode comprises executing the first sub-script only if the first value matches the version value.

5. The method of claim 1 or claim 2, wherein the first script comprises a first value, and wherein said executing of the version opcode comprises verifying if the first value does not match the version value.

6. The method of claim 5, wherein the version opcode is associated with a first subscript of the first script, wherein said executing of the version opcode comprises executing the first sub-script only if the first value does not match the version value.

7. The method of any preceding claim, wherein the first script comprises a plurality of respective version values, each associated with a respective version opcode, and wherein each respective version opcode is associated with a respective sub-script.

8. The method of any preceding claim, comprising determining whether the second blockchain transaction is a valid transaction based on said execution of the first script together with the second script.

9. The method of claim 8, comprising, upon determining that the second blockchain transaction is a valid transaction, processing a block comprising the second blockchain transaction and / or forwarding the second blockchain transaction to one or more parties.

10. The method of any preceding claim, wherein the transaction processor comprises a blockchain node.

11. The method of any of claims 8 to 10, wherein a first register is maintained in which respective version values are mapped to respective applications, and wherein said determining if the second blockchain transaction is a valid transaction comprises determining, based on the register, whether the second blockchain transaction has been generated by a party associated with the application mapped to the version value of the second blockchain transaction.

12. The method of claim 11, comprising maintaining the first register.

13. The method of any preceding claim, wherein the version value of the second blockchain transaction is linked to a multicast address, and wherein the method comprises sending the second blockchain transaction to the multicast address.

14. The method of claim 13, wherein a second register is maintained in which respective version values are mapped to respective multicast addresses, and wherein said sending of the second blockchain transaction to the multicast address comprises looking-up themulticast address in the second register using the version number of the second blockchain transaction.

15. A computer-implemented method of generating a blockchain transaction, wherein the method is performed by a first party and comprises: generating a first blockchain transaction comprising a first script, wherein the first script comprises one or more respective version opcodes, wherein each respective version opcode is configured so as to, when executed during execution of the first script together with a second script of a second blockchain transaction which references the first blockchain transaction, cause a version value of a second blockchain transaction to be output; and sending or causing the first blockchain transaction to be sent to one or more nodes of a blockchain network.

16. The method of claim 15, wherein one or more of the plurality of respective version opcodes are associated with a respective value, and wherein the one or more of the respective version opcodes are configured so as to, when executed, verify that the respective value matches the version value.

17. The method of claim 16, wherein one or more of the plurality of version opcodes are associated with a respective sub-script of the first script, and wherein the one or more of the respective version opcodes are configured so as to, when executed, cause the respective sub-script to be executed only if the respective value matches the version value.

18. The method of claim 15, wherein one or more of the plurality of respective version opcodes are associated with a respective value, and wherein the one or more of the respective version opcodes are configured so as to, when executed, verify that the respective value does not match the version value.

19. The method of claim 18, wherein one or more of the plurality of version opcodes are associated with a respective sub-script of the first script, and wherein the one or more of the respective version opcodes are configured so as to, when executed, cause the respective sub-script to be executed only if the respective value does not match the version value.

20. A computer-implemented method of generating a blockchain transaction, wherein a blockchain comprises a first blockchain transaction comprising a first script, wherein the first script comprises one or more respective version opcodes, wherein each respective version opcode is configured so as to, when executed during execution of the first script together with a second script of a second blockchain transaction which references the first blockchain transaction, cause a version value of a second blockchain transaction to be output, wherein the method is performed by a second party and comprises: generating second blockchain transaction comprising a version value, wherein the second blockchain references the first blockchain transaction and comprises a second script to be executed together with the first script of the first blockchain transaction; and sending or causing the second blockchain transaction to be sent to one or more nodes of a blockchain network.

21. A computer-implemented method of facilitating the processing of blockchain transactions, wherein the method is performed by a third party and comprises: maintaining a register, wherein the register comprises a plurality of respective version values, each respective version value being mapped to a respective application and / or a respective multicast address.

22. The method of claim 21, comprising making the register available to one or more transaction processors.

23. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 22.

24. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 22.

Images