Computer-implemented systems and methods to enable complex functionality on a blockchain while preserving security-based restrictions on script size and opcode limits

Abstract

The invention relates to blockchain technologies such as the Bitcoin blockchain. The invention uses a novel technique to decompose the functionality of a blockchain transaction script into several chunks or functional parts, and to use the output of a chunk as the input of the next chunk. Advantageously, this allows the blockchain to be used for ever complex tasks and computations while minimising script size, and also provides a novel architecture for the distributed execution of computational processes. The invention comprises a method of using a plurality of blockchain transactions to execute a computer implemented task, the method comprising the steps: using an unlocking script (ULS1) in a blockchain transaction (Tx2) to present at least one data item to a locking script (LS1) of another transaction (Tx1) so as to provide a result on a stack; generating a further unlocking script (ULS2) which comprises the result provided on the stack; presenting the further unlocking script (ULS2) to a further locking script (LS2) such that the result from the stack is provided as input to the further locking script.

Claims

1. A method of using a plurality of blockchain transactions to execute a computer-implemented task, the method comprising the steps: using an unlocking script (ULS1) in a blockchain transaction (Tx2) to present at least one data item to a locking script (LS1) of another transaction (Tx1) so as to provide a result on a stack; generating a further unlocking script (ULS2) which comprises the result provided on the stack; and presenting the further unlocking script (ULS2) to a further locking script (LS2) such that the result from the stack is provided as input to the further locking script (LS2), wherein the unlocking script (ULS1) and the further unlocking script (ULS2) are provided in association with inputs within different blockchain transactions.

2. A method according to claim 1, and further comprising: performing one or more of the steps of claim 1 more than once.

3. A method according to claim 1, and further comprising the step of: using the at least one data item in the execution of a calculation or sequence of instructions provided within the locking script (LS1).

4. A method according to claim 1, and further comprising the step of: using the result provided on the stack in the execution of a calculation or sequence of instructions provided within the further locking script (LS2).

5. A method according to claim 1, and further comprising the step of: obtaining the result from the stack.

6. A method according to claim 1, and further comprising the step of: validating the blockchain transaction (Tx2) and/or the other transaction (Tx1) to generate the result on the stack.

7. A method according to claim 1, wherein: the unlocking script (ULS1) and the further unlocking script (ULS2) are provided in association with different inputs within the same blockchain transaction (Tx2).

8. A method according to claim 1, wherein: the locking script (LS1) and the further locking script (LS2) are provided in association with different outputs within the same blockchain transaction (Tx1).

9. A method according to claim 1, wherein: the locking script (LS1) and the further locking script (LS2) are provided in association with outputs within different blockchain transactions.

10. A method according to claim 1, wherein: the step of presenting the further unlocking script (ULS2) to a further locking script (LS2) provides a further result on the stack, or on a different stack.

11. A method according to claim 1, wherein the step of generating the further unlocking script (ULS2) comprises: amending the blockchain transaction (Tx2) to insert an input (In2), wherein the further unlocking script (ULS2) is associated with the inserted input (In2).

12. A method according to claim 1, and further comprising the step of: using a blockchain client to obtain the result from the stack.

13. A method according to claim 12 wherein: the blockchain client is a Bitcoin client.

14. A method according to claim 1, and further comprising the step of: submitting the blockchain transaction (Tx2) and/or other blockchain transaction (Tx1) to a blockchain network.

15. A method according to claim 1, wherein: the plurality of blockchain transactions are for a blockchain, the blockchain being consensus-based, distributed, electronic ledger; and/or the blockchain is the Bitcoin blockchain; one, some or all of the plurality of blockchain transactions are Bitcoin transactions; and/or the method is arranged for execution on the Bitcoin blockchain.

16. A method according to claim 1, wherein: the at least one data item is provided as metadata within the unlocking script (ULS1); and/or the result is provided as metadata within the further unlocking script (ULS2).

17. A method according to claim 1, and further comprising the step of: using the method to compute a final result, and using the final result to control a process performed off a blockchain.

18. A computer-implemented system arranged and configured to perform the method of claim 1.

Description

(1) These and other aspects of the present invention will be apparent from and elucidated with reference to, the embodiment described herein. An embodiment of the present invention will now be described, by way of example only, and with reference to the accompany drawings, in which:

(2) FIG. 1 illustrates the chain of transactions and the sequential steps involved in a multiple inputs/outputs approach according to a first embodiment of the invention.

(3) FIG. 2 shows Transaction 1 (Tx1) according to an illustrative version of a first embodiment of the invention.

(4) FIG. 3 shows Transaction 2 (Tx2) according to an illustrative version of a first embodiment of the invention.

(5) FIG. 4 shows an illustrative chain of transactions according to an illustrative version of embodiment 2

(6) FIGS. 5 to 8 show transactions 1, 2, 3, and 4 in accordance with an illustrative version of embodiment 2.

(7) FIGS. 9a and 9b show illustrations of how an example version of the invention may be provided in accordance with embodiment 1.

(8) FIG. 10 shows a simple illustration of a blockchain client being used to obtain an item left on top of the stack.

ILLUSTRATIVE EMBODIMENTS OF THE INVENTION

(9) In the following examples, we shall use Bitcoin as our illustrative blockchain implementation and protocol, because it is the most widely known. This is for the purposes of illustration only and it should be noted that the invention is not limited in this regard. Other blockchain implementations will also fall within the scope of the invention.

(10) In order to prevent deployment of DoS (Denial of Service) attacks, the default Bitcoin client sets a limit on the maximum number of bytes and op_codes that can be include in a valid script. As it stands at the priority date of the present application, this limit is 10,000 bytes and 201 op codes. Any script comprising more than 201 op-codes or 10,000 bytes will not be valid. While imposed for worthwhile reasons, this restriction hampers the development of more sophisticated script functionality and, therefore, the complexity of the technical solutions that can be designed to operate in conjunction with blockchain technology.

(11) The present invention provides two techniques (embodiments) which enable users to split blockchain scripts into multiple inputs/outputs via the use of two or more blockchain transactions. Both embodiments may rely on the capability of automated computing agents (or “bots”) which are configured to: read the state of the stack, propagate i.e. communicate the result(s) of executed script(s) to the input(s) of unspent transaction output(s), split up large complex scripts into multiple smaller, simple units.

(12) It should be noted that in some blockchain implementations, such as Bitcoin, a customised reference client may be required to enable the state of the stack to be read after a script has terminated, as the default Bitcoin client does not provide access to this item of information. The stack is represented as a list in a .cpp file, which is included in the bitcoin core program. By inserting a few lines of code into the class which emulates the stack behaviour, it is possible to obtain and return information contained in the list. The information can then be passed on for use by another computing resource and/or in another computation. This is shown in FIG. 10. Thus, the invention provides a novel form of blockchain client and apparatus.

(13) The propagation of the result of the executed script does not require any automation and could be performed manually (at least in principle). However, in a typical implementation it is expected that external systems such as compilers would handle the automation of the operations involved in splitting complex scripts.

(14) Advantageously, no modification of the Bitcoin protocol is required by the present invention. In other words, while a custom client may be needed to prepare the transaction(s), once the transactions have been broadcast, all nodes of the Bitcoin network will be able to validate them.

(15) Thus, in accordance with (all versions of) the invention, the underlying concept is to split the script into several chunks or functional parts, and to use the output of a chunk as the input of the next chunk. This is an important deviation from the prior art. It allows the blockchain to be used for ever complex tasks and computations while preserving the security-based limit on script size, and provides a novel technique and architecture for the distributed execution of computational processes. Thus, the invention provides an improved, secure blockchain.

(16) However, it must be kept in mind that the ultimate outcome of the execution of a script is binary, i.e. either the transaction is marked invalid or it is marked valid (assuming that it satisfies also the other requirements). Therefore, in order to “connect” the outputs of one chunk of computation with the inputs of the next chunk of computation one must use a non-reference client that can access the values on the stack and reuse them, as explained above.

(17) We start with the following simple example:
x+y>3
which can be written in terms of OP codes in the following way:
OP_<x>OP_<y>OP_ADD OP_3 OP_GREATERTHAN

(18) We split this into the following two chunks:
z=x+y
z>3

(19) In accordance with a first approach, a solution could be adopted as now described.

(20) Alice prepares Tx1 as follows:

(21) Tx1

(22) In0:

(23) amount: A+<dust>+tf ref: . . . unlocked by: . . .
Out1: amount: <dust> locked by: OP_ADD OP_SWAP<Bob's pubKey>OP_SWAP OP_CHECKSIG OP_DROP
Out2: amount: A locked by: OP_3 OP_GREATERTHAN OP_SWAP<Bob's pubKey>OP_DROP

(24) Now Bob begins to prepare Tx2 in the following way:

(25) Tx2

(26) In0:

(27) amount: tf ref: . . . unlocked by: . . .
In1: amount: <dust> ref: Tx1:Out1 unlocked by: <Bob's signature>OP_2 OP_3
Out0: amount: <dust> locked by: . . .

(28) Bob will now sign the transaction, validate it, and (use the customised client to) read from the stack the output of the unlocking script of Tx2:In1 chained with the unlocking script of Tx1:Out1.

(29) He will then proceed to alter Tx2 by adding the following input and output:

(30) In2:

(31) amount: A ref: Tx1:Out2 unlocked by: <Bob's signature>OP_5
Out1: amount: A locked by: . . .
where obviously OP_5 is the result of the first chunk of the computation. Also in this case, one could use multi-signatures to prevent Bob from broadcasting a transaction within which OP_5 is replaced with something else. This approach has the advantage that a large number of chunks (up to the limit on the number of inputs and outputs in a transaction) can be chained using only two transactions. Therefore, complex functionality and computation can be performed in an efficient manner, requiring only two transactions to be validated and mined by the blockchain network, and using minimal storage requirements on the blockchain.

(32) In accordance with an alternative approach the following steps could be taken.

(33) The first transaction Tx1 is prepared and jointly signed by all the owners of the inputs. Inputs are sent to Alice's public key using the following locking script:
OP_ADD OP_SWAP<Alice's pubKey>OP_SWAP OP_CHECKSIG OP_DROP
Tx1
In: amount: A+tf ref: . . . unlocked by: . . .
Out1: amount: A locked by: OP_ADD OP_SWAP<Alice's pubKey>OP_SWAP OP_CHECKSIG OP_DROP

(34) Alice will now prepare Tx2 in the following way:

(35) Tx2

(36) In1:

(37) amount: 2*<dust>+tf ref: . . . unlocked by: . . .
In2: amount: A ref: Tx1:Out1 unlocked by: <Alice's signature>OP_2 OP_3
Out1: amount: <dust> locked by: . . .
where Tx2:In2 will be now signed with the flag SIGHASH_NONE, so that other outputs can be added. As known in the art, SIGHASH_NONE is a Bitcoin signature hash type which signs only inputs. Therefore, when SIGHASH_NONE is used, anyone is able to modify the outputs in any manner that they choose.

(38) Tx2:In1 presumably references Alice's funds and can be unlocked with SIGHASH_SINGLE so that, again, other outputs can be added. In the current form, the transaction will transfer amount A as transaction fees. However, Alice does not broadcast the transaction in the current form, but simply verifies it locally. In the verification process the unlocking script of Tx2:In2 will be executed together with the locking script of Tx1:Out:
<Alice's signature>OP_2 OP_3 OP_ADD OP_SWAP<Alice's pubKey>OP_SWAP OP_CHECKSIG OP_DROP
and at the end of the execution of the stack the remaining result will be 5, i.e. the result of the first chunk of computation. Alice's custom Bitcoin client will now save or record the result of the first chunk of computation and modify Tx2 by adding the following two outputs:
Out2: amount: A locked by: OP_3 OP_GREATERTHAN OP_SWAP<Bob's pubKey>OP_DROP
Out3: amount: <dust> locked by: OP_RETURN OP_5
but she will sign Tx2's inputs again, this time with the usual flag SIGHASH_ALL, so that now none of the outputs of the transaction can be modified. Bob can now complete the computation by reading the data stored in Out3 after OP_RETURN.

(39) As known in the art, OP_RETURN is a Bitcoin OP_CODE which can be used to mark a transaction output (TxO) as invalid. Any data provided after OP_RETURN is ignored in respect of Bitcoin payments, and thus OP_RETURN has been used in the prior art as a mechanism for conveying non-payment related data via the blockchain.

(40) Bob now prepares the following transaction:

(41) Tx3

(42) In:

(43) amount: A ref: Tx2:Out2 unlocked by: <Bob's signature>OP_5

(44) Out: . . .

(45) In principle, after OP_RETURN one could store a hash indexed in a DHT, so that arbitrarily long intermediate results can be passed between transactions. Obviously, in this example Alice trusts that Bob will prepare Tx3 as above, so that the computation can be completed successfully. A simple extension could require that Tx2:Out2 is signed by both Alice and Bob, so that Alice can verify that Bob has prepared the correct transaction. However, Bob could indefinitely delay the execution by refusing either to prepare the transaction or to sign it. Alice could also prepare Tx3, send it to Bob, and avoid to store data after OP_RETURN. It is noted that this approach requires one to wait for confirmation that each chunk of computation is in the blockchain.

(46) Detailed examples of these two implementations of the underlying technique are provided below, and in reference to the accompanying figures. The following description is organized as follows: “Embodiment 1” describes the first approach that uses only two transactions; multiple inputs and outputs are manipulated “Embodiment 2” describes the alternative approach which “links” or chains multiple transactions to achieve the same technical effect. It is worth noting that combinations of the two approaches are also possible.

(47) To illustrate the use of both embodiments, we now consider the following example which evaluates a function ƒ(x,y,z) defined as follows
ƒ(x,y,z)=(x.Math.y+z).Math.x

(48) We (or the compiler) express ƒ(x,y,z) as a sum of simple functions
g.sub.1(x,y)=x.Math.y
g.sub.2(g.sub.1(x,y)z)=g.sub.1(x,y)+z
ƒ(g.sub.2(g.sub.1(x,y),z),x)=g.sub.2(g.sub.1(x,y),z).Math.x

(49) In both embodiments, the variables x, y, and z, which represent the arguments of g.sub.1 and g.sub.2, will be contained in transaction unlocking scripts, while the functions g.sub.1 and g.sub.2 themselves will be contained in locking scripts. Therefore, hereafter, we will use the terms “function” and “locking script” interchangeably. In particular, x and y will be in the script that unlocks the locking script containing g.sub.1. Similarly, g.sub.1(x,y) and z will be in the script that unlocks the locking script containing g.sub.2.

(50) In the subsequent section of this paper, the example we use include the op_codes OP_ADD and PrO_MULT. These identifiers represent the arithmetic operations addition (+) and multiplication (.Math.) respectively. The op_codes OP_X, OP_Y, and OP_Z represent the variables x, y, and z. The symbols G.sub.1 and G.sub.2 represent the values at the top of the stack after the locking scripts corresponding to g.sub.1 and g.sub.2 will have been unlocked. OP_ADD is an op_code which forms part of the Bitcoin script language. We use the term “PrO_MULT”, short for “primitive operator” to refer to an operation which can be executed to perform a multiplication operation. In the current version of Bitcoin, the op_codes for multiplication (such as OP_MUL, OP_2MUL) are disabled and so PrO_MULT could be a custom-defined operation to provide that currently disabled functionality. Of course, if the OP_MUL etc opcodes are re-enabled then these could be used instead. Thus, the present invention can be used solely with functions that use standard (enabled) opcodes, and the implementation details of custom-built operators are not part of, or relevant to, the present invention. Therefore, details relating to how PrO_MULT could be implemented are not necessary to the understanding of the present invention, and have not been included herein for the sake of clarity.

(51) The example presented herein corresponds to the execution of a very simple smart contract in which funds are transferred from Alice to Bob, conditional on the successful execution of a long script. The script inputs are provided by Bob, and one can envisage two possible malicious behaviours. Firstly, Bob might provide incorrect inputs such that the script executes successfully and the funds are transferred to him. However, when the transaction(s) is/are stored in the blockchain, the inputs become publicly available allowing Alice to dispute the contract. Secondly, if Bob has any reason to refuse the transfer from Alice, he might decide to stall the transaction indefinitely, therefore preventing the execution of the contract. In the most straightforward scenario, Alice must simply trust that Bob will not stall the execution of the contract and that he will provide the correct inputs. Additional security mechanisms may be utilised in conjunction with the inventive concept to enhance security.

Embodiment 1: Splitting Scripts into Multiple Inputs and Outputs

(52) FIGS. 1, 9a and 9b illustrate the chain of transactions and the sequential steps involved in a multiple inputs/outputs approach of embodiment 1. Tx1 contains a set of Unspent Transaction Outputs (UTXOs) that will be consumed by Tx2. The construction of Tx2 proceeds incrementally, step by step. At each phase, an (automated software) agent presents an unlocking script to one UTXO of Tx1. The agent validates Tx2, reads the value(s) on top of the stack, and prepares a new unlocking script. The automated generation of blockchain transactions and scripts is known in the art and therefore not explained herein.

(53) The agent may use the information obtained from the stack in the previous step (or from earlier steps), and presents this new unlocking script to another UTXO contained within Tx1. Tx2 is broadcasted when all the necessary steps are accomplished for the present task.

(54) Advantageously, this technique decouples the functions contained in the locking scripts of Tx1 from the arguments contained in the unlocking scripts provided by Tx2. Functions become immutable once Tx1 has been added to the blockchain and verified. In addition, at this stage, the function arguments (inputs) may even be unknown. They are revealed only later, when Tx2 is prepared. This may be advantageous and provide enhanced security.

(55) The sequence of steps for embodiment 1 is shown in FIG. 1, FIGS. 9a and 9b and can be described as follows: Step 0: Alice submits transaction 1 (as shown in FIG. 1) to the Bitcoin network. Step 1: Bob prepares an initial version of transaction 2 Step 3: Bob presents <Bob's signature><OP_X><OP_Y><Redeem script 2> to output0. Bob validates transaction 2, reads the value G.sub.1 on top of the stack, but does not broadcast transaction 2. Step 4: Bob presents <Bob's signature><G.sub.1><OP_Z><Redeem Script 2> to output1. Bob validates transaction 2, reads the value G.sub.2 on top of the stack, but does not broadcast transaction 2. Step 5: Bob presents <Bob's signature><G.sub.2><OP_X><Redeem script 3> to output2. Bob validates transaction 2 and broadcasts it.

(56) For the sake of simplicity, we do not provide extensive details regarding Tx1's inputs and Tx2's output(s). FIG. 2 shows Transaction 1 (Tx1). FIG. 3 shows transaction 2 (Tx2).

Embodiment 2: Splitting Scripts in Multiple Transactions

(57) The second embodiment uses blockchain transactions to compose functions (see FIG. 4). This approach is similar in principle to the previous embodiment. However, during the validation phase, the agent reads the value(s) on top of the stack, and adds it/them after an OP_RETURN as explained above.

(58) FIGS. 5 to 8 show transactions 1, 2, 3, and 4 in accordance with an illustrative version of embodiment 2.

(59) It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word “comprising” and “comprises”, and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.