Digital contract using blockchain transaction

Abstract

A computer-implemented method of encoding a digital contract between a first party and a second party of a blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition being fulfilled; the method comprising: obtaining a plurality of data elements, each data element representing a different contract condition, wherein at least one of the conditions relates to the second party; generating a hash tree based on the data elements, wherein the hash tree comprises: a first leaf hash value, the first leaf hash value generated by hashing a respective data element; and a second leaf hash value, the second leaf hash value comprising at least one hash key, the at least one hash key generated by hashing a secret value known only to the trusted third party; ii) an inner hash value; and iii) a root hash value; and making the root hash value available to the first party for inclusion in a transaction of the blockchain.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method for enabling nodes of a blockchain network to agree on and enforce digital contracts, also known as so-called "smart contracts". BACKGROUND

[0002] A blockchain refers to a form of distributed data structure wherein a duplicate of the blockchain is maintained at each of a plurality of nodes in a peer-to-peer (P2P) network. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction can reference a previous transaction in the sequence, which can extend over one or more blocks.

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

[0004] Each node in the network can have either or both of the following roles: forwarding and storage. Forwarding nodes propagate transactions throughout the network of nodes. Storage nodes each store their own copy of the blocks in the blockchain. In order for a transaction to be recorded in the blockchain, a party sends that transaction to one of the nodes in the network for propagation. Each node is configured to adhere to the same node protocol, which will include one or more conditions for validating a transaction as valid. Invalid transactions will not be propagated to blocks. Assuming a transaction has been validated as valid, and thus accepted on the blockchain, the additional user data will therefore continue to be stored at each of the nodes in the P2P network as an unalterable public record.

[0005] One of the largest applications of blockchain technology growth is digital (or smart) contracts. A smart contract is a computer implemented agreement that enables parties to agree on and enforce a digital contract in a way that is both secure and untrustworthy. SUMMARY

[0006] Some well-known blockchain ledgers use a stack-based scripting language for transactions. The current nature of the scripting language and the limitations of the size of the script are seen as obstacles to creating a blockchain-based smart contract platform. One example of a smart contract that can be coded using the scripting language is a hosted smart contract (a conditional pay-to protocol) where the right to redeem a transaction output depends on the outcome of an event. However, the number of such dependencies that can be included in a transaction is very low due to the linear relationship between the number of scripts required to code such a contract and the number of dependencies.

[0007] According to one aspect disclosed herein, there is provided a computer- implemented method of encoding a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by a trusted third party and comprising: obtaining a plurality of data elements, each data element representing a different condition of the contract, wherein at least one of the different conditions is associated with the second party; generating a hash tree based on the plurality of data elements, wherein the hash tree comprises: i) a leaf layer comprising a first set of leaf hash values each generated by hashing a respective data element and a second set of leaf hash values comprising at least one hash key generated by hashing a secret value known only to the trusted third party; and ii) one or more internal layers each comprising a respective set of internal hash values, wherein each internal hash value of a respective internal layer is generated by hashing a concatenation of at least two hash values produced by a lower layer; and iii) a root layer comprising a root hash value generated by hashing a concatenation of at least two hash values produced by a highest internal layer; and making the root hash value available to the first party to cause the root hash value to be included in a transaction of the blockchain.

[0008] According to another aspect disclosed herein, there is provided a computer- implemented method of generating a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the first party and comprising: obtaining a root hash value of a hash tree generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different condition of the contract, and wherein at least one of the different conditions is associated with the second party; and ii) one or more different hash keys, the one or more different hash keys being generated based on a secret value known only to the trusted party; and generating a transaction to cause the transaction to be included in the blockchain, wherein the transaction comprises a locking script for locking the quantity of the digital asset to the first party, and wherein the locking script comprises the root hash value.

[0009] According to another aspect disclosed herein, there is provided a computer- implemented method of executing a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a data element, the data element representing the condition of the contract, the condition relating to the second party; obtaining an authentication path, the authentication path for generating a candidate root hash value of a hash tree that has been generated by the trusted third party, and wherein the authentication path comprises a set of hash values, wherein the set of hash values comprises a hash key generated based on a secret value known only to the trusted third party, and one or more sets of internal hash values, each set of internal hash values belonging to a different internal layer of the hash tree; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises an unlocking script for unlocking the quantity of the digital asset from the first party, and wherein the unlocking script comprises the obtained data element and the obtained authentication path.

[0010] A hash tree (also known as a Merkle tree) contains cryptographic hash values. The term "Merkle tree" is sometimes used in the literature to refer to a binary hash tree, although Merkle's original disclosure is not limited to binary hash trees, and "hash tree" and "Merkle tree" are used as synonyms elsewhere in the literature. Merkle tree and hash tree are used interchangeably herein unless the context requires otherwise. The term "tree" refers to a branching data structure, with a "root" at the top and "leaves" at the bottom. The construction method for a Merkle tree is to recursively hash pairs of nodes until there is only one hash value, which is called the root hash value or Merkle root. The root hash value represents an overall digital fingerprint of a set of data elements, providing an efficient process to verify whether a particular data element is included in the set. To prove that a particular data element is included in the set, a prover only needs to produce a relatively small number of hash values, constituting an authentication path or "Merkle path" that connects the particular data element to the root hash value of the hash tree.

[0011] The present disclosure recognizes that there is a way to compress and encode the conditions of a smart contract in a transaction using a single hash value (Merkle root) with a Merkle tree (or more generally, a hash tree). Furthermore, the smart contract ensures that if a trusted party attests that a prover satisfies a certain condition, then the prover node has access to and can spend a quantity of a digital asset.

[0012] Only a trusted party (e.g., an oracle) has access to the secret values on which the one or more leaf hash values are based. Thus, only a trusted party can generate the Merkle root and valid Merkle path for the conditions that have been satisfied. On this basis, if a prover (or spender) can provide a valid Merkle proof that results in the trusted party generating the same Merkle root, a verifier (or payee) can be confident that the trusted party has provided the Merkle path to the prover.

[0013] The present disclosure enables secure smart contract execution with minimal requirements on scripting. A verifier only needs to know the Merkle root to verify that a prover has the required data and correct key hash values provided to them by a trusted party. This is because the leaf hash values, when paired with the hash values of data elements, require knowledge of the key hash value to calculate other hash values of the Merkle tree. The specific Merkle path that applies to valid data will also be transmitted by the trusted party, thereby minimising the computational requirements on the verifier. In effect, the Merkle path acts as proof that the data has been certified by the trusted party. By only providing the Merkle root to the verifier, the way in which the smart contract is coded does not leak data (data required to transfer a digital asset from a payee to a spender) prior to the submission of a spend transaction.

[0014] The depth of the Merkle tree constructed by the trusted party scales logarithmically with the number of data elements (or conditions, results, etc.). This allows for more efficient coding of smart contracts that rely on many conditions.

[0015] According to another aspect disclosed herein, there is provided a computer- implemented method of encoding a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract being for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: in response to determining that the condition of the contract associated with the second party has been fulfilled, providing a signature of the trusted third party to the second party for inclusion in a transaction of the blockchain, wherein the signature signs a data element representing the fulfilled condition.

[0016] According to another aspect disclosed herein, there is provided a computer- implemented method of generating a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a root hash value of a hash tree, wherein the hash tree comprises a layer of leaf hash values, and wherein at least some of the leaf hash values are each generated based on a respective one of a plurality of data elements, each data element representing a different condition of the contract, and wherein at least one of the different conditions is associated with the second party; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises a locking script for locking the quantity of the digital asset to the first party, and wherein the locking script comprises the root hash value, and wherein the locking script is configured to, when executed with an unlocking script of a subsequent transaction, determine whether the unlocking script comprises: i) a data element representing a condition of the contract that has been signed with a signature of a trusted third party; and ii) an authentication path for generating a candidate root hash value that matches the obtained root hash value using the signed data element.

[0017] According to another aspect disclosed herein, there is provided a computer- implemented method of executing a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a data element representing a fulfilled condition of the contract, the condition being associated with the second party; obtaining an authentication path for generating a candidate root hash value of a hash tree using the obtained data element, wherein the hash tree comprises a layer of leaf hash values, and wherein at least some of the leaf hash values are each generated based on a respective one of a plurality of data elements, each data element representing a different condition of the contract, and wherein the plurality of data elements comprises the obtained data element; obtaining a signature and a public key of a trusted third party, wherein the signature signs the fulfilled condition; generating a transaction for inclusion in the blockchain, wherein the transaction comprises an unlocking script for unlocking the quantity of the digital asset from the first party, and wherein the unlocking script comprises the obtained data element signed with the signature, the public key, and the obtained authentication path.

[0018] The present disclosure also provides techniques for generating and enforcing a condition-dependent smart contract without requiring a trusted party to perform a computation on each new transaction that includes the same data.

[0019] The mutually exclusive conditions of a contract can be used (e.g. by a trusted party) to construct a Merkle tree, and the payee only needs the Merkle root to construct the smart contract. This reduces the overall size of the contract and requires less unused script data.

[0020] The fulfilled conditions of a contract are authenticated by a trusted third party, for example by signing using a Lamport signature. The authenticated conditions are included directly in the spending (unlocking) script, reducing the amount of work required by the data provider.

[0021] The parties can then ensure that the conditions of the smart contract are adhered to without the need to explicitly record the entire contract in a transaction. Instead, the spender or winner of the digital asset needs to prove that he / she has fulfilled certain conditions and that meeting the particular condition is part of the contract.

[0022] According to another aspect disclosed herein, there is provided a computer readable storage medium comprising a transaction for implementing a digital contract law between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second node based on conditions of the contract being fulfilled, wherein the transaction comprises a locking script for transferring the quantity of the digital asset to the first party, wherein the locking script comprises a root hash value, and wherein the root hash value of a hash tree is generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different condition of the contract, wherein at least one of the different conditions is associated with the second party, and wherein at least one of the different conditions is associated with the second party; and ii) one or more different hash keys, the one or more different hash keys being generated based on a secret value known only to the trusted party. BRIEF DESCRIPTION OF DRAWINGS

[0023] To assist in the understanding of embodiments of the present disclosure and to show how the same can be carried out, reference will now be made, by way of example only, to the accompanying drawings in which:

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

[0025] Figure 2 some examples of transactions that can be recorded in a blockchain are schematically illustrated;

[0026] Figure 3 is a schematic block diagram of another system for implementing a blockchain;

[0027] Figure 4 is a schematic block diagram of node software for processing transactions according to an output-based model of a node protocol;

[0028] Figure 5 is a schematic representation of an example Merkle tree;

[0029] Figure 6 is a schematic representation of a Merkle proof;

[0030] Figure 7 is an example block diagram representing interactions between parties when executing a smart contract;

[0031] Figure 8 is an example block diagram representing interactions between parties when executing a smart contract;

[0032] Figure 9 is a schematic representation of an example Merkle tree in which hash keys generated using secret values form some of the leaves of the tree;

[0033] Figure 10 is a schematic representation of an example Merkle tree in which the results of a smart contract form the leaves of the tree; and

[0034] Figure 11 and Figure 12 shows example transactions generated by a verifier and a prover respectively, in which a Merkle root is used to encode a condition of a smart contract. DETAILED DESCRIPTION

[0035] Example System Overview

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

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

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

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

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

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

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

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

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

[0045] In addition to verification, at least some of the nodes 104M race to create transaction blocks, a process that is based on a "proof of work." Based on the announced solution by the winner that has been checked at each such node for a pool of transactions 154 for which the winner has solved the puzzle, the winner is recorded in the blockchain 150 as a new block 151 by at least some of the nodes 104 that act as storage nodes 104S. Block pointers 155 are also assigned to the new block 151n that points to a previously created block 151n-1 in the blockchain. The proof of work helps to reduce the risk of double spending because creating a new block 151 requires a lot of work and does not allow double spending to be included in its block since any block that contains double spending can be rejected by other nodes 104. Once created, a block 151 cannot be modified because it is identified and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose an order to the blocks 151. Since transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

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

[0047] The memory of each node 104 stores software configured to run on the processing device of the node 104 to perform its respective role and process transactions 152 according to the node protocol. It will be appreciated that any action attributed herein to a node 104 can be performed by software running on the processing device of the respective computer device. Furthermore, the term "blockchain" used herein is a generic term for the general class of technology and is not limited to any particular proprietary blockchain, protocol, or service.

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

[0049] The computer device 102 of each party 103 comprises a respective processing apparatus comprising one or more processors, for example one or more CPUs, graphics processing units (GPUs), other accelerator processors, application specific processors, and / or FPGAs. The computer device 102 of each party 103 also comprises a memory, i.e. a computer-readable memory in the form of a non-transitory computer-readable medium. This memory can comprise one or more memory units in the form of one or more memory media, for example magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROM, and / or optical media such as optical disk drives. The memory on the computer device 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 appreciated that any action attributed herein to a given party 103 can be performed by software running on the processing apparatus of the respective computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, for example a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 can also comprise one or more other network resources, such as cloud computing resources accessed through the user terminal.

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

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

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

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

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

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

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

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

[0058] 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 can include an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO specifies an amount of a digital asset (a store of value). It can also contain the transaction ID of the source transaction and other information. The transaction data structure can also include a header 201 that can include an indicator of the size of the input field 202 and the output field 203. The header 201 can also include an ID of the transaction. In an embodiment, the transaction ID is a hash value of the transaction data (not including the transaction ID itself), and is stored in the header 201 of the original transaction 152.

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

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

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

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

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

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

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

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

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

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

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

[0070] Note also that 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 basis for invalidity in most transaction models. Therefore, such a transaction will not propagate into the blockchain 151.

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

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

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

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

[0075] Optional side channel

[0076] Figure 3 Another system 100 for implementing blockchain 150 is shown. In addition to additional communication functions, system 100 is connected to… Figure 1 The content shown is essentially the same. The client applications on each of Alice and Bob's computer devices 102a and 120b include additional communication capabilities. That is, this allows Alice 103a to establish a side channel 301 separate from Bob 103b (at the instigation of either party or a third party). Side channel 301 enables data exchange independently of the P2P network. Such communication is sometimes referred to as "off-chain" communication. For example, when exchanging transaction 152 between Alice and Bob, if they do not want to publish the transaction (yet) to the P2P network 106 or add it to chain 150, this communication can be used until one party chooses to broadcast the transaction to network 106. Alternatively or additionally, this side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0077] Side channel 301 can be established via the same packet-switching network 101 as the P2P overlay network 106. Alternatively, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between Alice and Bob's devices 1021, 102b. Generally, side channel 301 as referred to herein can include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e., independently of the P2P overlay network 106). When multiple links are used, the entire bundle or collection of off-chain links can be referred to as side channel 301. Therefore, it is important to note that while Alice and Bob may exchange specific information or data fragments or similar items via side channel 301, this does not necessarily mean that all these data fragments must be sent via the same link or even the same type of network.

[0078] Node software

[0079] Figure 4An example of node software 400 running on each node 104 of a P2P network 106 is shown, in examples of UTXO-based or output-based models. Node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a collection 405 of one or more blockchain-related functional modules. At any given node 104, these modules may include any or all of the following modules: a forwarding module 405F and a storage module 405S (depending on one or more roles of the node). Protocol engine 401 is configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a transaction with a pointer to another previous transaction 152m-1(Tx) is received... m-1 The output (e.g., UTXO) of the transaction's input is 152m (Tx). m When ), the protocol engine 401 identifier Tx m The unlock script is then passed to script engine 402. Protocol engine 401 is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 in blockchain 150 stored on the corresponding node or another node 104. Regardless of the method used, script engine 401 will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 402.

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

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

[0082] In the output-based model, the result "TRUE" from the script engine 402 is one of the conditions for the transaction to be valid. Typically, one or more further protocol-level conditions must also be satisfied, assessed by the protocol engine 401; for example, the total number of digital assets pointed to in the output of Tx m does not exceed the total number specified by the input(s), and the pointed-to output of Tx m-1 has not yet been spent by another valid transaction. The protocol engine 401 assesses the result from the script engine 402 and the one or more protocol-level conditions, and only if they are all TRUE, does the protocol engine 401 validate the transaction Tx m as valid. The protocol engine 401 outputs an indication of whether the transaction is valid to the application-level decision engine 404. Only if Tx m is indeed validated under the conditions, can the decision engine 404 select the control forwarding module 405F to execute their respective blockchain-related functions involving Tx m . This can include: the forwarding module 405F that forwards Tx m to another node 104 in the P2P network 106. It should be noted, however, that in embodiments, while the decision engine 404 will not select to forward an invalid transaction, this does not necessarily mean that the decision engine must trigger the forwarding of a transaction just because it is valid. Optionally, in embodiments, the decision engine 404 can apply one or more additional conditions before triggering one or both of these functions.

[0083] It should also be noted that in this document, the terms "TRUE" and "FALSE" are not necessarily limited to returning results represented in the form of a single binary number (bit) only, although this is indeed one possible implementation. More generally, "TRUE" can refer to any state that indicates a successful or affirmative result, while "FALSE" can refer to any state that indicates an unsuccessful or non-affirmative result. For example, in the account-based model (not shown here), the result can be indicated as "TRUE" by a combination of implicit protocol-level validation of the signature by the node 104 and an additional affirmative output of the smart contract (the overall result is considered TRUE if both individual results are TRUE). Figure 4

[0084] Merkle tree

[0085] Figure 5 ​An exemplary structure of a Merkle tree 500 is shown. Merkle trees are also known in the art as hash trees. These terms are used interchangeably herein. Each node in the tree (shown by a circle) has an index pair (i,j), denoted as N(i,j). The indices i,j are numerical labels associated with a particular location in the tree. One feature of a Merkle tree is that the construction of each of its nodes is governed by the following equation:

[0086]

[0087] where k = (i + j - 1) / 2 and H is a cryptographic hash function.

[0088] Figure 5 The case where i = j corresponds to a leaf node 501, which is simply a data D i corresponding i th block's hash value. The case where i ≠ j corresponds to an internal node 502 or a root node 503, which is generated by recursively hashing and concatenating the child nodes in the tree until the particular node or the root node is reached. The leaf nodes of the tree are also referred to herein as leaf hash values. Similarly, the internal nodes and the root node are also referred to as internal hash values and root hash value, respectively. The construction of a Merkle tree requires the use of a cryptographic hash function.

[0089] In most applications, the main function of a hash tree is to facilitate the proof that certain data blocks D i 504 are members of a list or set of N data blocks Given a root hash value and a candidate data block D i , it can be considered as a "proof of existence" of the block within the set. Such a proof mechanism is known as a hash tree proof (or Merkle proof), and involves obtaining a set of hash values, referred to as the hash values or authentication path (or Merkle path) for the given data block D i and the root R. The authentication path for a data block is the minimal list of hash values required to reconstruct the root R by iteratively hashing and concatenating.

[0090] Figure 6 A Merkle proof of existence of a data block D1 in the tree represented by root R using a Merkle path is shown. Given a Merkle root R, the proof that data block D1 belongs to the set represented by R can be made by performing a Merkle proof as follows:

[0091] 1) Obtain the Merkle root R from a trusted source.

[0092] 2) Obtain the Merkle value Γ from the source. In this case, Γ is a set of hash values:

[0093] Γ = {N(2,2), N(3,4), N(5,8)}.

[0094] 3) Calculate the Merkle proof for D1 and R as follows:

[0095] a. Hash (or double-hash, depending on implementation) the data block D1 to obtain: N(1,1) = H(D1).

[0096] b. Concatenate and hash with N(2,2) to obtain: N(1,2) = H(N(1,1) || N(2,2)).

[0097] c. Concatenate and hash with N(3,4) to obtain: N(1,4) = H(N(1,2) || N(3,4)).

[0098] d. Concatenate and hash with N(5,8) to obtain the root: N(1,8) = H(N(1,4) || N(5,8)),

[0099] R' = N(1,8).

[0100] e. Compare the calculated root R' with the root R obtained in (1):

[0101] I. If R' = R, then confirm that D1 exists in the tree, and thus confirm that the data set

[0102] II. If R' ≠ R, then the proof fails and D1 cannot be confirmed as a member of .

[0103] This demonstrates that a Merkle proof can be performed for a given D1 and root R, using only the minimum necessary number of hash values to effectively "walk up" the Merkle tree. This is an efficient mechanism to provide a proof of existence for certain data that is part of a data set represented by a Merkle tree and its root.

[0104] A hash tree proof includes concatenating a hash value of a candidate data field with at least one leaf hash value in the ordered set of hash values (the hash tree path). This results in an internal hash value (or an internal node of the hash tree). The resulting internal hash value is then concatenated with one or more hash values in the hash tree path (a single hash value if the hash tree is a binary hash tree). The concatenated internal hash value is then hashed to generate a next hash value. Depending on the size of the hash tree (e.g., the number of data fields), the next hash value can be another internal hash value or a root hash value. If the next hash value is another internal hash value, one or more internal hash values from the hash tree path are concatenated and hashed to generate a root hash value. It should be noted that each hash value in the hash tree path is used only once.

[0105] Importantly, the number of operations required to verify that a given data packet belongs to a Merkle tree scales logarithmically with the number of leaf nodes.

[0106] Rabin signature

[0107] In current blockchain protocols, a valid Elliptic Curve Digital Signature Algorithm (ECDSA) signature can only be generated if the message being signed is a (serialized) transaction. This means that if a party needs to sign data to execute a contract encoded in a transaction, the party also needs to sign the entire transaction. Thus, the current protocol prevents the reuse of data signatures.

[0108] However, the Rabin cryptosystem can be used to generate and verify signatures against arbitrary data types used in blockchain transactions. Rabin signatures are familiar to those skilled in the art. Unlike the ECDSA signature scheme, which uses elliptic curve algorithms, Rabin signatures rely on the difficulty of integer factorization to achieve security. The Rabin signature algorithm can be summarized as follows.

[0109] Key generation: The signer’s private key is a pair of prime numbers (p, q), where p≡3 mod 4 and q≡3 mod 4 are prime numbers. The public key is n = p·q.

[0110] Signature generation: For a message m, a random number U is chosen such that and The Rabin signature is then given by

[0111]

[0112] where H is a hash function with the same number of output bits as n.

[0113] Signature verification: Given (S, U, n) and a message m, check that

[0114] S 2 ≡ H(m || U) mod n.

[0115] Verifying a Rabin signature is computationally easy and can be done in a script using stack operations. Importantly, when the verification process is used as part of a larger transaction, the verification process does not need to know the contents of the message being signed (except in the case where the message is an arbitrarily sized array of data). This means that the creator of the locking script only needs to know the public address of the data source. Another feature of the Rabin digital signature algorithm is that the signer can choose the level of security by completely controlling the size of the bits of the signing key.

[0116] Verifying a Rabin signature requires a small number of arithmetic and stack opcodes. The opcodes listed below are familiar to those skilled in the art. The “redeem script” for verifying a Rabin signature is as follows:

[0117] OP_2OP_PICK OP_TOALTSTACK OP_DUP OP_TOALTSTACK OP_DUP OP_TOALTSTACK OP_HASH160<H 160 (n) > OP_EQUALVERIFY OP_SWAP OP_CAT FUNC_HASH3072 OP_FROMALTSTACK OP_MOD OP_SWAP OP_DUP OP_MUL OP_FROMALTSTACK OP_MOD OP_EQUALVERIFY OP_FROMALTSTACK

[0118] In this case, the script will execute without failing, and will only keep the signed message on the stack if and only if the input is provided:

[0119] <s> <m> <n>

[0120] where m is a message and (S, U) is a valid rabin signature. Alternatively, the redeem script can be designed to push TRUE (or a representation of TRUE) as the top stack item if the following script is used:

[0121] OP_2 OP_PICK OP_TOALTSTACK OP_DUP OP_TOALTSTACK OP_DUP OP_TOALTSTACK OP_HASH160 160 (n) OP_EQUALVERIFY OP_SWAP OP_CAT FUNC_HASH3072 OP_FROMALTSTACK OP_MOD OP_SWAP OP_DUP OP_MUL OP_FROMALTSTACK OP_MOD OP_EQUAL OP_FROMALTSTACK OP_SWAP

[0122] If a successful rabin signature verification is used to execute the OP_IF branch (as in the case of a blockchain-hosted contract), this version of the rabin signature check can be used. For brevity, the above example of the rabin signature verification opcode is referred to hereinafter as [RABIN SIG CHECK].

[0123] Digital (smart) contracts

[0124] Embodiments of the present disclosure provide techniques for constructing and executing digital contracts, or so-called smart contracts, and for facilitating the construction and execution of those contracts.

[0125] A digital contract enables the first party 103a to transfer a digital asset to the second party 103b only when and if the conditions of the contract are met. Similarly, the digital contract ensures that the second party 103b can enforce the contract if the conditions are met. This contrasts with a traditional contract in which either party can breach the contract or there can be no agreement on whether the conditions of the contract are met.

[0126] Embodiments will first be described with reference to Figure 7 Embodiments. Figure 7 A system 700 is shown comprising a first party (Alice) 103a, a second party (Bob) 103b and a trusted third party (oracle) 701. Alice and Bob are both users of a blockchain network and computer devices 102a, 102b configured to perform the methods described herein are operated by Alice and Bob. The oracle 701 can or can not be a user of the blockchain network. The oracle 701 also operates a computer device (not shown) configured to perform the methods described herein. The third party (oracle) is trusted in the sense that Alice 103a and Bob 103b trust data generated and / or published by the third party. For example, the third party 701 can be a weather service that publishes temperature readings (e.g. average daily temperature readings for a particular city).

[0127] The oracle can take the form of a server, which comprises one or more physical server units, or even an entire data centre. Alternatively, the oracle can take the form of a user terminal or a group of user terminals networked together. That is, the oracle can be an individual user or a group of users such as an organisation, for example a company, academic institution, charity, and the like. Typically, the oracle comprises a computer device. The computer device comprises a processing apparatus comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (FPGAs). The computer device also comprises a memory, i.e. a computer-readable storage in the form of a non-transitory computer-readable medium. The memory can comprise one or more memory units in the form of one or more memory media, for example magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory or electrically erasable programmable read only memory (EEPROM), and / or optical media such as optical disk drives. The memory of the oracle stores software configured to run on the processing apparatus of the computer device of the node to perform its respective role(s). It will be appreciated that any measures attributed herein to the oracle can be performed by the software running on the processing apparatus of the computer device of the oracle.

[0128] The oracle can communicate with Alice and Bob, for example via the internet 101. Alice and Bob are each configured to transmit transactions to nodes of a blockchain network 106. Alice and Bob can also communicate via a side channel 301 (not shown in Figure 7

[0129] ​Alice and Bob wish to construct a digital contract that ensures that Alice transfers a quantity of digital assets if one of a plurality of possible conditions V of the contract is fulfilled. The possible conditions can be, for example, the price of a commodity or the outcome of an insurable event. Alice wishes to ensure that the conditions of the contract are fulfilled before Bob can claim the digital assets. Alice and Bob also wish to ensure that a trusted party is the arbiter of whether the conditions are satisfied.

[0130] To protect the privacy level of Alice and Bob, Alice can not wish to include the conditions of the contract in a transaction, as the transaction will constitute part of the blockchain 150 when validated, and is accessible to any user of the blockchain. Alice therefore wishes to encode the conditions of the contract in the transaction such that they cannot be determined by any unnecessary third party user of the blockchain 150.

[0131] Additionally or alternatively, the contract can contain more conditions. One of the main obstacles to using script execution for smart contracts is the strict size limit that applies to individual scripts. There is a 520 byte limit for pay-to-script-hash (P2SH) and a 10,000 byte limit for bare scripts. While these limits reduce the security risk by removing the possibility of denial-of-service (DoS) type attacks, they place a very strict limit on the number of raw scripts that can be used to represent a smart contract. Alice therefore wishes to encode the conditions of the contract in a way that reduces the size of the script, in an efficient manner.

[0132] Once the conditions are agreed, Alice and / or Bob transmit the set of conditions V (or data representing the conditions) to an oracle. The oracle generates a Merkle tree 500 using the different contract conditions. That is, each condition is hashed (or double hashed) using a hash function to generate a leaf hash value 501 of the tree. The root 503 of the hash tree (the Merkle root R) is a hash value that encodes the conditions of the contract. The Merkle root R cannot be obtained by reverse engineering the conditions.

[0133] To ensure that Alice and Bob cannot build the Merkle root R themselves using only the data elements, the oracle includes a hash key K as one or more leaves of the hash tree 500. Each hash key K is a hash value derived from a secret S (e.g., a randomly generated number or string) known only to the oracle. Each hash key K can be the same hash key. Alternatively, each hash key K can be a different hash key. For example, a first hash key K1 can be a hash value of the secret S, and a second hash key K2 can be a hash value of the first hash key K1. Alternatively, a first hash key K1 can be a hash value of the secret and a first value (e.g., S + i), a second hash key K2 can be a hash value of the secret and a second, different value (e.g., S + 2i), and so on. Since the secret is known only to the oracle, only the oracle can reconstruct the Merkle root R.

[0134] The oracle transmits the Merkle root R to Alice for inclusion in the digital contract. Alternatively, the oracle can publish the Merkle root R, e.g., on the Internet 101, so that Alice can access the Merkle root. Alice can now build a transaction Tx1 that uses the Merkle root. Alice builds the transaction Tx1, which includes a locking script that locks a quantity of digital assets to Alice. The locking script includes the Merkle root. The locking script is described in more detail below. Once the transaction is built, Alice transmits the transaction Tx1 to the network for inclusion in the blockchain.

[0135] At a later time, the condition V1 of the contract is fulfilled, so Bob wishes to receive the agreed quantity of digital assets. For example, the condition V1 can be a data packet encoding an insurable event that enables Bob to receive the payment. To do so, Bob needs to generate a transaction Tx2 that has an unlocking script that unlocks the locking script of Alice’s transaction Tx1. As discussed, Alice and Bob have agreed that the oracle can decide whether the condition is satisfied. Upon determining that the condition V1 is satisfied, the oracle transmits an authentication path (Merkle path) Γ to Bob. The Merkle path Γ will include the hash keys K generated by the oracle during the generation of the Merkle tree, as well as one or more hash values of the Merkle tree needed to reconstruct the Merkle root. The Merkle path Γ obtained from the oracle can also include V1 (or a data element representing V1). Alternatively, V1 can be accessible to Bob. Bob now builds the unlocking script of Tx2, which includes V1, the hash keys K, and the one or more hash values. Together, these values can be used to perform a Merkle proof, i.e., to generate a candidate Merkle root and compare it to the Merkle root generated by the oracle (and included in Tx1). Bob transmits the transaction Tx2 to the network for inclusion in the blockchain.

[0136] Now returning to the locking script built by Alice. As Figure 4 As shown, during the validation of Tx2, the locking script of Tx1 is executed together with Tx2. The locking script generated by Alice is configured to perform a Merkle proof using the Merkle root contained in the locking script of Tx1 and the element contained in the unlocking script of Tx2. If the candidate Merkle root generated using the element in the unlocking script of Tx2 matches (i.e., is identical to) the Merkle root contained in the locking script of Tx1, the digital asset is unlocked from Alice and can be transferred to a party of Bob’s choice. In other words, the unlocking amount (e.g., a partial or full amount) of the digital asset can be included in the unused transaction output of Tx2.

[0137] Figure 7 One example of the flow of information between Alice 103a, Bob 103b, and the oracle 701 according to these embodiments is shown. As shown, the oracle obtains the conditions V of the contract from Alice. The oracle uses these conditions and the secret to construct a Merkle tree with a Merkle root R. The oracle transmits the Merkle root R to Alice so that Alice can construct a transaction Tx1 that incorporates the root R into the locking script of the transaction Tx1. Alice broadcasts the transaction to the P2P network. When the oracle believes that the condition V1 of the contract has been fulfilled, the oracle provides the Merkle path Γ and the hash key K (generated using the secret) to Bob. The Merkle path Γ and the hash key K can be used together to generate the Merkle root R. Bob then constructs a transaction Tx2 that incorporates the Merkle path Γ, the condition V1, and the hash key K into the unlocking script of the transaction Tx2.

[0138] Reference will now be made to Figure 9 The embodiments are described. The oracle runs a protocol that authenticates and compresses a large amount of indexed data using a Merkle tree. In this way, the oracle can create multiple transactions that require external data to execute. The oracle is not a party to the smart contract or the blockchain transaction. Alice and Bob are the two parties to the smart contract of the blockchain transaction, where Alice is the payer of the digital asset and Bob is the intended recipient of the digital asset. In order to spend the digital asset, Bob must prove that he satisfies certain requirements in the contract, and part of that proof will include external data. Therefore, Bob will be referred to as the prover and Alice will be referred to as the verifier.

[0139] First, the oracle creates a secret bit string or secret number that is never shared. For example, the secret can be the number 10. Using a cryptographic hash function (such as SHA256), the key is securely generated by hashing the secret:

[0140] H(secret) = Key

[0141] When appropriate, the hash digest (represented as the Key) can be transmitted to the prover. Furthermore, a deterministic key generation protocol can be used to generate a key hash sequence. For example:

[0142] H(secret+i) = Key i i = {0, 1, ..., N}

[0143] like Figure 9 As shown, the oracle can construct a Merkle tree 900, where each right-leaf node Key i 901 and each left leaf node 902 are index data V k ,k∈{1,…,N}. The purpose of Merkle Tree 900 is to provide evidence that Alice needs data from the prover without having to publish the data itself onto the blockchain before using it. Upon request, the oracle then publishes Merkle root R, which can be used in future blockchain transactions to verify the authenticity of the data.

[0144] Once you obtain the key i This proves that the hash value is part of Merkle Tree 900. The prover can provide a Merkle path that can be verified against a Merkle root that has been published by an oracle (e.g., transmitted to Alice). In this case, the Merkle proof verifies the data and its authenticity.

[0145] The advantages mentioned above include the ability to authenticate data using Merkle trees, the simplicity and computational efficiency of key and Merkle tree generation, and the ability to pre-sign large amounts of independent data using a single key. Furthermore, the depth of the Merkle tree (and the Merkle proof) scales logarithmically with the number of possible values, meaning that large amounts of indexed data can be signed.

[0146] Since the key hash associated with the Merkel tree is revealed once the prover provides a valid Merkel proof, the key hash needs to be discarded, and a new Merkel tree needs to be built for each new transaction. However, this would require minimal computation because the data in the left leaf nodes remains unchanged.

[0147] For example, suppose an oracle has four conditions V1, ..., V4, which are either public or sent by Alice. First, the oracle publishes a Merkle root so that a validator can create a verification (i.e., locking) script. Once the validator has constructed the locking script using the Merkle root, i.e., created the transaction that encodes the smart contract, the oracle can check whether Alice used the correct Merkle root. Once the oracle determines the outcome, the key and the Merkle proof are transmitted to the prover (Bob).

[0148] Consider the following script snippet and verify the Merkel proof for V1:

[0149] Step 1: Alice agrees to the smart contract that if outcome V1 occurs, Alice will transfer a certain amount of digital assets to Bob. Alice and Bob send this data to the Oracle.

[0150] Step 2: The Oracle uses this data V1-V4 and the secret key as leaves to build a Merkle tree (see Figure 9 ). Then, the Oracle sends Alice R as part of Alice’s verification algorithm.

[0151] Alice’s locking script (sighash): OP_SHA256[OP_CAT OP_SHA256]*3 <r>OP_EQUAL

[0152] The oracle can look up this script in Alice's transaction and ensure that the correct Merkle root has been included. If the correct Merkle root has not been included, the oracle can alert Bob and / or the public that Alice has not created (the correct) contract script. This is not a security vulnerability, but rather a requirement that Alice first create a transaction using the correct R (Alice must create the transaction using the script and sign it). This method only allows the oracle to verify that the contract has been created.

[0153] Step 3: V1 is a valid result. The oracle sends Key1 and the Merkle path to Bob. Bob can construct the Merkle proof of V1.

[0154] Bob's unlocking script (fragment): <z2> <z4> <key1> <v1>

[0155] When this proof is executed, it demonstrates that the prover knows both the key hash and the leaf data, and that the data itself is included in the unlocking script.

[0156] Clearly, Alice's locking script will hash V1 and concatenate with Key1 (i.e. generate Z3). Concatenate the result with Z4 and hash it (i.e. generate Z1). Concatenate the result with Z2 and hash it (i.e. generate R). Then check if the result is equal to R.

[0157] The data and the Merkle path together prove that the data exists and that it is included in the contract. The key hash demonstrates that the oracle has granted Bob permission to use the data. Because the oracle can only provide the key hash to Bob if the result is valid.

[0158] Embodiments will now be described with reference to Figure 8 the drawings. Figure 8 A system 800 similar to Figure 7 is shown, which includes Alice 103a, Bob 103b and a trusted third party (oracle) 701.

[0159] As detailed above, Alice and Bob wish to construct a digital contract that ensures that Alice transfers a quantity of digital assets if one of a plurality of possible conditions V of the contract is fulfilled. Alice and Bob also wish to ensure that a trusted party is the arbiter of whether the condition is fulfilled.

[0160] In these embodiments, Alice and Bob can agree on the conditions of the contract and they can agree on a Merkle tree that encodes these conditions. That is, the Merkle tree can be constructed without interacting with the oracle. For example, Alice can generate a Merkle tree with a Merkle root. Bob can also generate a Merkle tree with a Merkle root. Bob can then verify that Alice has correctly generated the Merkle root. To do this, Alice and Bob must agree on the method (i.e. algorithm) used to generate the Merkle tree. Alternatively, Alice and Bob can rely on the oracle to generate the Merkle tree and transmit the Merkle root to Alice and, optionally, Bob.

[0161] The Merkle trees used in these embodiments can be constructed without using secret values. The leaves of the Merkle tree can be hash values of the conditions of the contract (i.e. hash values of data elements representing the conditions). Depending on the number of conditions, one or more padding elements can be used as nodes (e.g. leaves) of the Merkle tree. For example, if the contract has seven conditions, one of the hash leaves can be padded (e.g. with a hash value of zero) so as to form a Merkle tree with eight hash leaves. This can be applied to any of the embodiments described herein.

[0162] Once Alice has obtained the Merkle root R (e.g., by generating the Merkle root), Alice can generate a transaction Tx3 that transfers a quantity of digital assets to Bob based on a requirement that a condition of the digital contract is met. Alice wants to ensure that a trusted party (oracle) attests that the condition has been met, so Alice generates a transaction Tx3 that has a locking script that determines whether an unlocking script attempting to unlock an output of the transaction includes a signature R of the oracle s The data element that is signed. As with the transaction described with reference to Figure 7 As with the transaction described with reference to Alice’s transaction also has a locking script that determines whether an unlocking script includes a Merkle path Γ for performing a Merkle proof using the data element. That is, the locking script is configured to determine whether the (signed) data element and the Merkle path Γ can generate a candidate Merkle root that is the same as the Merkle root R included in the locking script of Alice’s transaction Tx3.

[0163] The signature R of the oracle s may be a Rabin signature. Rabin signatures and how to sign a data element using a Rabin signature have been described in detail above. Alice’s locking script can be configured to perform a Rabin signature check on the data included in Bob’s unlocking script, e.g., [RABIN SIG CHECK].

[0164] Alternatively, the signature of the oracle can be an ECDSA signature.

[0165] In some examples, Alice can also include additional information in the transaction, e.g., metadata related to the digital contract. For example, the metadata can include a description of the contract. For example, the metadata can be included in an OP_RETURN output of the transaction.

[0166] In some examples, if Bob does not successfully transfer ownership of the digital assets within a predetermined amount of time, Alice can include a time-based claim option for claiming a quantity of the digital assets. For example, the locking script can be configured to allow Alice to unlock the locking script (using an unlocking script of a different transaction generated by Alice) after a period of time (e.g., one month, two months, three months, etc.) after the transaction is generated onto the blockchain. If Bob does not claim the digital assets (e.g., due to not fulfilling a condition of the contract or the oracle not providing a valid signature to Bob), Alice can transmit the transaction to the blockchain network with an unlocking script that is configured to unlock the locking script of her previous transaction. The unlocking script can include a signature and public key (or hash thereof) of Alice.

[0167] Once the transaction is generated, Alice transmits the transaction to one or more nodes of the blockchain network for the transaction to be included in the blockchain.

[0168] If the conditions of the contract are met, the oracle transmits the signed data element to Bob. The data element represents the fulfilled condition and is the same data element that was used to construct the Merkle root R. The data element is signed with the oracle's signature R s (e.g., a rabbinical signature of the oracle). The oracle can also provide the (rabbinical) public key of the oracle to Bob, e.g., by publishing the (rabbinical) public key or transmitting the (rabbinical) public key directly to Bob.

[0169] Bob can now generate a transaction Tx4, which has an unlocking script configured to unlock the output of Alice's transaction Tx3, i.e., to unlock the locking script in Alice's transaction. The unlocking script of Bob's transaction Tx4 includes the signed data element, the public key of the oracle, and the Merkle path Γ used to perform the Merkle proof. Bob can obtain the Merkle path from Alice and / or the oracle (e.g., in examples where Alice and / or the oracle generated the Merkle tree). Another example is that Bob can obtain the Merkle path Γ by generating the Merkle path (e.g., in examples where Alice and Bob agreed on the data elements that form the leaves of the Merkle tree). Once generated, Bob can transmit the transaction to one or more nodes of the network to have the transaction included in the blockchain 150.

[0170] Figure 8 One example of the flow of information between Alice, Bob, and the oracle according to these embodiments is shown. Alice and Bob can agree on a Merkle tree. This can involve sharing the Merkle root R between them (e.g., Alice can transmit the Merkle root R to Bob and / or vice versa). In some examples, the oracle can have generated the conditions V of the contract for generating the Merkle tree (or data elements representing these conditions). In these examples, the oracle can publish these conditions V or transmit the conditions V directly to Alice and / or Bob, i.e., not to other third parties. Alice broadcasts the transaction Tx3 to the P2P network. When the oracle believes that the condition V1 of the contract has been fulfilled, the oracle provides a signature R s to Bob, which signs the fulfilled condition V1. Bob then obtains the Merkle path Γ for the conditions that can be used to generate the Merkle root R. The Merkle path Γ can have been transmitted by Alice or the oracle, or generated by Bob himself. Bob then constructs a transaction Tx4 that incorporates the Merkle path Γ and the signed condition V1 in the unlocking script of the transaction Tx4.

[0171] A condition-dependent spending script (smart contract) can use the following aspects. First, the mutually exclusive parts of the smart contract script can be used to build a Merkle tree, and the payor uses only the Merkle root. This reduces the overall size of the contract and reduces the amount of unused script data. The full script can be replaced by the Merkle root. Second, raw data from a third party, authenticated by a rabbinic signature or Merkle proof, can be used directly in the spending script, reducing the amount of work required by the data provider. Third, the third-party data provider can use a published indexing system to encode complex messages. Then, the parties can ensure compliance with the conditions of the smart contract without having to explicitly record the entire contract in a transaction. Instead, the spender or winner of the digital asset needs to prove that he / she has met certain conditions, and meeting the specific conditions is part of the contract.

[0172] In some cases, it can not be possible or feasible for an oracle to transmit a plaintext message with a signature, as this can require the oracle to have a large amount of memory and processing power. Instead, by using binary / hexadecimal values to represent a specific range of continuous data, the number of possible states (and thus the workload) of the oracle can be minimized. In some examples, the oracle can be used only to report data related to a specific set of queries (e.g., air temperature). The oracle conditions can be indexed and the index can be published in advance. An example scheme is shown in the following table:

[0173]

[0174] Using this scheme, there can be up to 256 oracle conditions in the range A < x < B (where A = a0and B = a 255 ) can be represented using a single byte. This precision can be increased with an increase in the number of bytes. For example, if the maximum byte push allowed in a script is 520, then in theory, the above table can be extended to represent up to approximately 3.4 x 10 153 continuous data intervals.

[0175] For example, if the oracle is reporting data for a platinum resistance thermometer, the oracle can use a set of binary values to represent temperatures in a suitable range, for example, in unit intervals between -50 and 50 degrees Celsius, as shown in the following table:

[0176]

[0177] This simple encoding system can result in the direct representation of almost unlimited ranges of oracle conditions in a script.

[0178] Embodiments will now be described with reference to Figure 10 In these embodiments, a third party (oracle) can authenticate data, but does not have to perform calculations for every new transaction that includes the data.

[0179] Furthermore, to ensure the validity of the independent verification conditions, Alice and Bob both agreed to use data provided by the oracle. Since Alice and Bob must have previously agreed on the form of the smart contract, they can also agree on the structure of the "Merkel contract," specifically the Merkel root. When creating a transaction containing the smart contract, both Alice and Bob must know the oracle's Rabin public key. Alternatively, Carroll might prefer to publish the index first, rather than the associated data and signature.

[0180] If the output is not transmitted to Bob within a fixed time period, additional security can be provided by imposing conditions on the return of the digital asset to Alice. This also provides additional security if Carol decides not to cooperate (i.e., not to provide a signature).

[0181] Different conditions are encoded as hexadecimal data. Then, the hexadecimal value 1001 can be used as a leaf to construct a Merkle tree 1000, as shown below. Figure 10 As shown, where:

[0182] Z6=H(01), Z7=H(02), Z8=H(03), Z9=H(04), Z 10 =H(05),

[0183] Z3 = H(Z7||Z8), Z4 = H(Z9 ... 10 Z5 = H(Z) 11 ||Z 11 ),

[0184] Z1 = H(Z3||Z4), Z2 = H(Z5||0) and

[0185] R = H(Z1||Z2).

[0186] Here, H(·) denotes a double SHA-256 hash function, i.e., H(x) = SHA256(SHA256(x)). Alternatively, a single hash value can be used. In this example, the padding value 1002 is used as a node in the tree. Alice creates a transaction that transfers a certain amount of digital assets to the winner (who may not be known at the time the transaction is created). This could be a non-standard transaction output, or it could be a payment-to-script hash (P2SH) output if the contract creator requires further compression.

[0187] Merkel smart contracts allow parties to store and execute contracts in an efficient and secure manner. Alice and Bob did not explicitly state the complete contract in the script, but instead agreed on its Merkel form. Bob has now obtained the signature from the oracle and wants to demonstrate:

[0188] i) The conditions that allow Bob to spend UTXOs have been met, and

[0189] ii) The condition that has been satisfied is a specific clause in the contract.

[0190] The following shows an example of a Merkle smart contract, where the locking script is from Alice's transaction and the unlocking script is from Bob's transaction.

[0191]

[0192] The first part of the locking script (<Merkle path length>…OP_CHECKSIG OP_ENDIF) checks that the unlocking script contains the Merkle path used to generate the Merkle root, the condition of the contract signed with the oracle's rabin signature, and whether to transfer the ownership of the digital asset to Bob.

[0193] Bob can spend the digital asset by showing (i) "Round 3" is the condition required to spend the escrowed asset and (ii) "Round 3" is actually the result. If Bob shows (i) and (ii), the second part of the script (OP_ELSE…OP_ENDIF) will be unused data. If Bob does not transfer the ownership within a month, the second part of the script allows Alice to reclaim the digital asset.

[0194] Bob's unlocking script includes the Merkle path, the condition signed with the oracle's public key, Bob's public key, and Bob's signature.

[0195] The size of the locking script is reduced, and unused and unexecuted scripts are minimized. The size of the locking script can be further compressed using P2SH, for example, by transferring the contract execution cost from the contract creator to the spender using the following transaction template:

[0196] Transaction 1 (Alice) P2SH:

[0197] Unlocking script / scriptSig<…inputs…>

[0198] Locking script / scriptPubkey OP_HASH160<H(Smart contract redeemscript)>OP_EQUAL

[0199] Transaction 2 (Winner) P2PKH:

[0200] Unlocking script / scriptSig<Response to smart contract redeem script><smart contract redeem script byte array>

[0201] Locking script / scriptPubkey OP_DUP OP_HASH160<H(P.K.)>OP_EQUALVERIFYOP_CHECKSIG

[0202] For a Merkel smart contract, the locking script scales logarithmically with the number of leaf nodes N, as the opcode sequence (OP_SWAP OP_IF OP_SWAP OP_ENDIF OP_CAT OP_SHA256) must be repeated for each level of the Merkel tree. For a small contract, the [RABIN SIG CHECK] sequence would constitute the largest proportion of bytes in the script. By Merkelizing the contract, the repeated Rabin signature check sequence is avoided, which greatly reduces the transaction size.

[0203] For a redeem script to be validated, a response specifying the Merkel path is required, which means the size of the response also scales logarithmically with the number of leaf nodes. The majority of the data contained in the response is the Rabin signature and public key (approximately 300-400 bytes each for the most secure signature).

[0204] The table below highlights the savings in transaction size when using a Merkel contract.

[0205] Scaling properties Locking script Unlocking script ScriptSig + ScriptPubkey fields Standard contract Linear N Constant Linear N Merkle contract [log2N] [log2N] [log2N]

[0206] Figure 11 is an example of a transaction template 1100 that Alice can use. Alice’s contract can be encoded as a single transaction output 1101. Additional metadata for the contract can be embedded in an OP_RETURN output 1102.

[0207] The locking script for Alice’s transaction can contain three different elements 1103, 1104, 1105. The first element 1103 checks that the data in the unlocking script attempting to unlock Alice’s transaction is indeed the condition of the contract. The second element 1104 checks that Bob is the intended recipient of the digital asset. If Bob does not claim the digital asset within a predetermined period of time (one month in this example), the third element 1105 allows Alice to reclaim the digital asset.

[0208] Figure 12 is an example of a transaction that Bob can use to unlock the digital asset locked to Alice using Figure 11 the example transaction shown. Bob provides the Merkel path, data (representing the fulfilled condition), and Rabin signature from the oracle, as well as his own (ECDSA) signature and public key.

[0209] It will be appreciated that the above embodiments are described by way of example only.

[0210] More generally, according to a first example of the teachings disclosed herein, there is provided a computer-implemented method of encoding a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract being for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by a trusted third party and comprising: obtaining a plurality of data elements, each data element representing a different condition of the contract, wherein at least one of the different conditions is associated with the second party; generating a hash tree based on the plurality of data elements, wherein the hash tree comprises: i) a leaf layer comprising a first set of leaf hash values each generated by hashing a respective data element, and a second set of leaf hash values comprising at least one hash key generated by hashing a secret value known only to the trusted third party; and ii) one or more internal layers each comprising a respective set of internal hash values, wherein each internal hash value of a respective internal layer is generated by hashing a concatenation of at least two hash values produced by a lower layer; and iii) a root layer comprising a root hash value generated by hashing a concatenation of at least two hash values produced by a highest internal layer; and making the root hash value available to the first party for including the root hash value in a transaction of the blockchain.

[0211] According to a second optional example, there can be provided a method according to the first example, wherein the obtaining the data elements comprises receiving the data elements from the first party and / or the second party.

[0212] According to a third optional example, there can be provided a method according to the first or second example, wherein the making the root hash value available comprises transmitting the root hash value to the first party.

[0213] According to a fourth optional example, there can be provided a method according to any one of the first to third examples, the method comprising: identifying a transaction of the blockchain generated by the first party, wherein the transaction comprises the digital contract, and wherein the digital contract comprises a locking script locking the quantity of the digital asset to the first party; determining whether the locking script comprises the root hash value; and if the locking script does not comprise the root hash value, notifying the second party.

[0214] According to a fifth optional example, there can be provided a method according to any of the first to fourth examples, the method comprising: determining that the condition of the contract associated with the second party has been satisfied; and in response, transmitting an authentication path to the second party, wherein the authentication path comprises a set of hash values, wherein the set of hash values comprises the hash key and one or more sets of internal hash values, each set of internal hash values belonging to a different internal layer of the hash tree.

[0215] According to a sixth optional example, there can be provided a method according to any of the first to fifth examples, wherein the second set of leaf hash values comprises a plurality of different hash keys, each generated based on the secret value.

[0216] According to a seventh optional example, there can be provided a method according to any of the first to sixth examples, wherein each of the first set of leaf hash values is paired with a different one of the hash keys, and wherein each internal hash value of the lowest internal layer of the hash tree is generated by hashing a concatenation of a different pair of leaf hash values.

[0217] According to an eighth optional example, there can be provided a method according to any of the seventh and fifth examples, wherein the authentication path comprises the hash key paired with the leaf hash value of the condition associated with the second node.

[0218] According to a ninth example of the teachings disclosed herein, there is provided a computer device of a trusted third party, the computer device of the trusted third party comprising: a memory, the memory comprising one or more memory units; and a processing arrangement, the processing arrangement comprising one or more processing units, wherein the memory stores code arranged to run on the processing arrangement, the code being configured so as, when run on the processing arrangement, to perform the teachings of any of the first to eighth examples.

[0219] According to a tenth example of the teachings disclosed herein, there is provided a computer program embodied on a computer readable storage and configured so as, when run on the computer device of the trusted third party, to perform the teachings of any of the first to eighth examples.

[0220] According to an eleventh example of the teachings disclosed herein, there is provided a computer-implemented method of generating a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on conditions of the contract being fulfilled; the method being performed by the first party and comprising: obtaining a root hash value of a hash tree generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different condition of the contract, and wherein at least one of the different conditions is associated with the second party; and ii) one or more different hash keys, the one or more different hash keys being generated based on a secret value known only to the trusted party; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises a locking script for locking the quantity of the digital asset to the first party, and wherein the locking script comprises the root hash value.

[0221] According to a twelfth optional example, there can be provided a method according to the eleventh example, the method comprising: transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0222] According to a thirteenth optional example, there can be provided a method according to the eleventh or twelfth example, wherein the obtaining the root hash value comprises receiving the root hash value from the trusted third party.

[0223] According to a fourteenth optional example, there can be provided a method according to any one of the eleventh to thirteenth examples, wherein a subsequent transaction of the blockchain generated by the second party comprises an unlocking script, the unlocking script comprising: i) a data element representing a condition of the contract; and ii) an authentication path comprising a hash key of the hash tree and one or more inner hash values; and wherein the locking script is configured to, when executed together with the unlocking script, generate a candidate root hash value by performing a hash tree proof using the data element and the authentication path; and generate a value representing true or false depending on whether the root hash value matches the candidate root hash tree.

[0224] According to a fifteenth example of the teachings disclosed herein, there is provided a computer device of the first party, the computer device of the first party comprising: a memory comprising one or more memory units; and a processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured to, when run on the processing apparatus, perform the teachings of any one of the eleventh to fourteenth examples.

[0225] According to a sixteenth example of the teachings disclosed herein, there is provided a computer program embodied on a computer-readable storage medium and configured so as, when run on a computer device of the first party, to perform the teachings of any one of the eleventh to fourteenth examples.

[0226] According to a seventeenth example of the teachings disclosed herein, there is provided a computer-implemented method of executing a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a data element, the data element representing the condition of the contract, the condition being associated with the second party; obtaining an authentication path, the authentication path for generating a candidate root hash value of a hash tree that has been generated by the trusted third party, and wherein the authentication path comprises a set of hash values, wherein the set of hash values comprises a hash key generated based on a secret value known only to the trusted third party, and one or more sets of internal hash values, each set of internal hash values belonging to a different internal layer of the hash tree; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises an unlocking script for unlocking the quantity of the digital asset from the first party, and wherein the unlocking script comprises the obtained data element and the obtained authentication path.

[0227] According to an eighteenth optional example, there can be provided a method according to the seventeenth example, the method comprising: transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0228] According to a nineteenth example of the teachings disclosed herein, there is provided a computer device of the second party, the computer device of the second party comprising: a memory, the memory comprising one or more memory units; and a processing apparatus, the 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 run on the processing apparatus, to perform the teachings of any one of the seventeenth to nineteenth examples.

[0229] According to a twentieth example of the teachings disclosed herein, there is provided a computer program embodied on a computer-readable storage medium and configured so as, when run on a computer device of the second party, to perform the teachings of any one of the seventeenth to nineteenth examples.

[0230] According to a twenty-first example in accordance with the teachings disclosed herein, there is provided a computer-implemented method of encoding a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: in response to determining that the condition of the contract associated with the second party has been fulfilled, providing the second party with a signature of the trusted third party for inclusion in a transaction of the blockchain, wherein the signature signs a data element representing the fulfilled condition.

[0231] According to a twenty-second optional example, there can be provided a method according to the twenty-first example, wherein the signature is a Rabin signature.

[0232] According to a twenty-third optional example, there can be provided a method according to the twenty-second example, the method comprising providing the second party with a Rabin public key.

[0233] According to a twenty-fourth optional example, there can be provided a method according to any one of the twenty-first to twenty-third examples, wherein the providing the signature comprises transmitting the signature directly to the second party.

[0234] According to a twenty-fifth optional example, there can be provided a method according to any one of the twenty-first to twenty-fourth examples, the method comprising: providing the first party with a plurality of data elements, each data element representing a different condition of the contract, and wherein the plurality of data elements includes the data element representing the condition associated with the second party.

[0235] According to a twenty-sixth optional example, there can be provided a method according to the twenty-fifth example, the method comprising: generating a root hash value of a hash tree, wherein the hash tree comprises a layer of leaf hash values, and wherein at least some of the leaf hash values are each generated based on a respective one of the plurality of data elements; and providing the first party with the root hash value.

[0236] According to a twenty-seventh optional example, there can be provided a method according to the twenty-sixth example, the method comprising: providing the second party with an authentication path for generating a candidate root hash value of the hash tree using the data element representing the fulfilled condition.

[0237] According to a twenty-eighth optional example, there can be provided a method according to any one of the twenty-first to twenty-sixth examples, wherein each data element is a different binary or hexadecimal value representing a different condition of the contract.

[0238] According to a twenty-ninth example of the teachings disclosed herein, there is provided a computer device of a trusted third party, the computer device of the trusted third party comprising: a memory, the memory comprising one or more memory units; and a processing apparatus, the 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 teachings of any of the twenty-first to twenty-eighth examples.

[0239] According to a thirtieth example of the teachings disclosed herein, there is provided a computer program embodied on a computer readable storage and configured so as when run on a computer device of a trusted third party, to perform the teachings of any of the twenty-first to twenty-eighth examples.

[0240] According to a thirty-first example of the teachings disclosed herein, there is provided a computer-implemented method of generating a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a root hash value of a hash tree, wherein the hash tree comprises a layer of leaf hash values, and wherein at least some of the leaf hash values are each generated based on a respective one of a plurality of data elements, each data element representing a different condition of the contract, and wherein at least one of the different conditions is associated with the second party; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises a locking script for locking the quantity of the digital asset to the first party, and wherein the locking script comprises the root hash value, and wherein the locking script is configured to, when executed together with an unlocking script of a subsequent transaction, determine whether the unlocking script comprises: i) a data element representing a condition of the contract that has been signed with a signature of a trusted third party; and ii) an authentication path for generating a candidate root hash value that matches the obtained root hash value using the signed data element.

[0241] According to a thirty-second optional example, there can be provided a method according to the thirty-first example, wherein obtaining the root hash value comprises generating the root hash value.

[0242] According to a thirty-third optional example, there can be provided a method according to the thirty-first example, wherein obtaining the root hash value comprises obtaining the root hash value from the second party and / or the trusted third party.

[0243] According to a thirty-fourth optional example, there can be provided a method according to any one of the thirty-first to thirty-third examples, wherein the signature is a Rabin signature.

[0244] According to a thirty-fifth optional example, there can be provided a method according to any one of the thirty-first to thirty-fourth examples, wherein the authentication path comprises a sequence of hash values, each hash value being from a respective layer of the hash tree, and wherein the locking script comprises a sequence of opcodes for performing a hash tree proof using the obtained root hash value and the sequence of hash values.

[0245] According to a thirty-sixth optional example, there can be provided a method according to any one of the thirty-first to thirty-sixth examples, wherein the locking script is configured to allow the first party to redeem the quantity if the quantity of the digital assets is not transferred to the second party within a predetermined amount of time.

[0246] According to a thirty-seventh optional example, there can be provided a method according to any one of the thirty-first to thirty-sixth examples, wherein the locking script is configured to determine whether the unlocking script comprises iii) a valid signature and a public key of the second party.

[0247] According to a thirty-eighth optional example, there can be provided a method according to any one of the thirty-first to thirty-seventh examples, wherein the transaction comprises a first output and a second output, wherein the first output comprises the locking script, and wherein the second output comprises metadata based on the digital contract.

[0248] According to a thirty-ninth optional example, there can be provided a method according to any one of the thirty-first to thirty-eighth examples, the method comprising transmitting the transaction to one or more nodes of the blockchain network for inclusion of the transaction in the blockchain.

[0249] According to a fortieth optional example, there can be provided a method according to any one of the thirty-ninth to thirty-sixth examples, the method comprising generating a second transaction for inclusion in the blockchain, wherein the second transaction comprises an unlocking script configured to unlock the locking script, wherein the unlocking script comprises a public key and a signature of the first party.

[0250] According to a forty-first example of the teachings disclosed herein, there is provided a computer device of a first party, the computer device of the first party comprising: a memory comprising one or more memory units; and a processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the teachings of any one of the thirty-first to forty-first examples.

[0251] According to a forty-second example of the teachings disclosed herein, there is provided a computer program embodied on a computer readable storage and configured so as when run on a computer device of a first party to perform the teachings of any one of the thirty-first to forty-first examples.

[0252] According to a forty-third example of the teachings disclosed herein, there is provided a computer-implemented method of executing a digital contract between a first party performing a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a data element, the data element representing a fulfilment condition of the contract, the condition being associated with the second party; obtaining an authentication path, the authentication path for generating a candidate root hash value of a hash tree using the obtained data element, wherein the hash tree comprises a layer of leaf hash values, and wherein at least some of the leaf hash values are each generated based on a respective one of a plurality of data elements, each data element representing a different condition of the contract, and wherein the plurality of data elements comprises the obtained data element; obtaining a signature and a public key of a trusted third party, wherein the signature signs that the condition has been fulfilled; generating a transaction for inclusion in the blockchain, wherein the transaction comprises an unlocking script for unlocking the quantity of the digital asset from the first party, and wherein the unlocking script comprises the obtained data element signed with the signature, the public key, and the obtained authentication path.

[0253] According to a forty-fourth optional example, there can be provided a method according to the forty-third example, wherein the signature is a Rabin signature.

[0254] According to a forty-fifth optional example, there can be provided a method according to the forty-third or forty-fourth example, wherein obtaining the authentication path comprises obtaining the authentication path from the trusted third party.

[0255] According to a forty-sixth optional example, there can be provided a method according to the forty-third or the forty-fourth example, wherein obtaining the signature and / or the public key of the trusted third party comprises obtaining the signature and / or the public key directly from the trusted third party.

[0256] According to a forty-seventh optional example, there can be provided a method according to any one of the forty-third to the forty-sixth example, wherein the authentication path comprises a sequence of hash values, each hash value being from a respective layer of the hash tree.

[0257] According to a forty-eighth optional example, there can be provided a method according to any one of the forty-third to the forty-seventh example, the method comprising:

[0258] transmitting the transaction to one or more nodes of the blockchain network for inclusion of the transaction in the blockchain.

[0259] According to a forty-ninth example of the teachings disclosed herein, there is provided a computer device of the second party, the computer device of the second party comprising: a memory, the memory comprising one or more memory units; and a processing apparatus, the 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 running on the processing apparatus, to perform the teachings of any one of the forty-third to the forty-eighth examples.

[0260] According to a fiftieth example of the teachings disclosed herein, there is provided a computer program embodied on a computer-readable storage and configured so as, when running on a computer device of the second party, to perform the teachings of any one of the forty-third to the forty-eighth examples.

[0261] According to a fifty-first example of the teachings disclosed herein, there is provided a computer-readable storage medium comprising a transaction for implementing a digital contract law between a first party of a blockchain network and a second party of the blockchain network, the digital contract being for transferring a quantity of a digital asset from the first party to the second node based on conditions of the contract being fulfilled, wherein the transaction comprises a locking script for transferring the quantity of the digital asset to the first party, wherein the locking script comprises a root hash value, and wherein the root hash value of a hash tree is generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different condition of the contract, and wherein at least one of the different conditions is associated with the second party; and ii) one or more different hash keys, the one or more different hash keys being generated based on a secret value known only to the trusted party.

[0262] According to another example of the teachings disclosed herein, there can be provided a method comprising measures of the first party, the second party, any of the trusted third parties.

[0263] According to another example of the teachings disclosed herein, there can be provided a system comprising the computer devices of the first party, the second party, any of the trusted third parties.

[0264] Other variants or use cases of the disclosed technology can become apparent to those of ordinary skill in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments, but only by the claims appended hereto. < / key1> < / z4> < / z2> < / r> < / n> < / m> < / s>

Claims

1. A computer-implemented method for encoding a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; The method is performed by a trusted third party and comprises: obtaining a plurality of data elements, each data element representing a different condition of the contract, wherein at least one of the different conditions is associated with the second party; generating a hash tree based on the plurality of data elements, wherein the hash tree comprises: i) a leaf layer comprising a first set of leaf hash values each generated by hashing a respective data element but not a secret value known only to the trusted third party and a second set of leaf hash values comprising at least one hash key generated by hashing a secret value known only to the trusted third party but not any of the respective data elements; and ii) one or more internal layers each comprising a respective set of internal hash values, wherein each internal hash value of a respective internal layer is generated by hashing a concatenation of at least two hash values produced by a lower layer; iii) a root layer comprising a root hash value generated by hashing a concatenation of at least two hash values produced by a highest internal layer; and making the root hash value available to the first party for inclusion in a transaction of the blockchain; determining that the condition of the contract associated with the second party has been satisfied; and in response, transmitting an authentication path to the second party, wherein the authentication path comprises a set of hash values, wherein the set of hash values comprises the hash key and one or more sets of internal hash values, each set of internal hash values belonging to a different internal layer of the hash tree.

2. The method of claim 1, wherein the obtaining the data elements comprises receiving the data elements from the first party and / or the second party.

3. The method of claim 1, wherein the making the root hash value available comprises transmitting the root hash value to the first party.

4. The method of claim 1, the method comprising: identifying a transaction of the blockchain generated by the first party, wherein the transaction comprises the digital contract, and wherein the digital contract comprises a locking script that locks the quantity of the digital asset to the first party; determining whether the locking script comprises the root hash value; and if the locking script does not comprise the root hash value, notifying the second party.

5. The method of claim 1, wherein the second set of leaf hash values comprises a plurality of different hash keys each generated based on the secret value.

6. The method of claim 5, wherein each of the first set of leaf hash values is paired with a different one of the hash keys, and wherein each internal hash value of a lowest internal layer of the hash tree is generated by hashing a concatenation of a different pair of leaf hash values. ​ 7. The method of claim 6, wherein the authentication path comprises the hash key paired with the leaf hash value of the condition associated with the second party.

8. A computer device of a trusted third party, the computer device comprising: a memory, the memory comprising one or more memory units; and a processing apparatus, the 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 7.

9. A computer readable memory on which is embodied a computer program, the computer program being configured so as when run on a computer device of a trusted third party, to perform the method of any of claims 1 to 7.

10. A computer-implemented method for generating a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the first party and comprising: obtaining a root hash value of a hash tree generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different condition of the contract, wherein at least one of the different conditions is associated with the second party; and ii) one or more different hash keys, the one or more different hash keys being generated based on a secret value known only to the trusted third party; the hash tree comprising a leaf layer, the leaf layer comprising a first set of leaf hash values each generated by hashing a respective data element but not a secret value known only to the trusted third party, and a second set of leaf hash values comprising at least one hash key generated by hashing a secret value known only to the trusted third party but not any of the respective data elements; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises a locking script for locking the quantity of the digital asset to the first party, and wherein the locking script comprises the root hash value; wherein a subsequent transaction of the blockchain generated by the second party comprises an unlocking script comprising: i) a data element representing a condition of the contract; and ii) an authentication path comprising a hash key of the hash tree and one or more inner hash values; and wherein the locking script is configured so as when executed together with the unlocking script, to: generate a candidate root hash value by performing a hash tree proof using the data element and the authentication path; and generate a value representing true or false depending on whether the root hash value matches the candidate root hash tree.

11. The method of claim 10, the method comprising: transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

12. The method of claim 10 or 11, the method comprising: generating a hash tree proof using the data element and the authentication path; and generating a value representing true or false depending on whether the root hash value matches the candidate root hash tree.

12. The method of claim 10, wherein the obtaining the root hash value comprises receiving the root hash value from the trusted third party.

13. A computer device of a first party, the computer device comprising: a memory, the memory comprising one or more memory units; and a processing apparatus, the 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 one of claims 10 to 12.

14. A computer readable memory on which is embodied a computer program, the computer program being configured so as when run on a computer device of a first party to perform the method of any one of claims 10 to 12.

15. A computer-implemented method for executing a digital contract between a first party of a blockchain network and a second party of the blockchain network, the digital contract for transferring a quantity of a digital asset from the first party to the second party based on a condition of the contract being fulfilled; the method being performed by the second party and comprising: obtaining a data element, the data element representing a condition of the contract, the condition being associated with the second party; obtaining an authentication path for generating a candidate root hash value of a hash tree that has been generated by a trusted third party, the hash tree comprising a leaf layer, the leaf layer comprising a first set of leaf hash values and a second set of leaf hash values, the first set of leaf hash values each being generated by hashing a respective data element but not by hashing a secret value known only to the trusted third party, the second set of leaf hash values comprising at least one hash key generated by hashing a secret value known only to the trusted third party but not by hashing any of the respective data elements; and wherein the authentication path comprises a set of hash values, wherein the set of hash values comprises a hash key generated based on the secret value known only to the trusted third party, and one or more sets of internal hash values, each set of internal hash values belonging to a different internal layer of the hash tree; and generating a transaction for inclusion in the blockchain, wherein the transaction comprises an unlocking script for unlocking the quantity of the digital asset from the first party, and wherein the unlocking script comprises the obtained data element and the obtained authentication path.

16. The method of claim 15, the method comprising: transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

17. A computer device of a second party, the computer device comprising: a memory, the memory comprising one or more memory units; and a processing apparatus, the 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 claim 15 or claim 16.

18. A computer readable memory on which is embodied a computer program configured to perform the method of any one of claim 15 or claim 16 when run on a computer device of a second party.

Images