Self-reproducing Coins as Universal Turing Machine

Abstract

Turing-completeness of smart contract languages in blockchain systems is often associated with a variety of language features (such as loops). On the contrary, we show that Turing-completeness of a blockchain system can be achieved through unwinding the recursive calls between multiple transactions and blocks instead of using a single one. We prove it by constructing a simple universal Turing machine using a small set of language features in the unspent transaction output (UTXO) model, with explicitly given relations between input and output transaction states. Neither unbounded loops nor possibly infinite validation time are needed in this approach.

A    Appendix

This section addresses a question of guarding script conversion into the procedure being executed by a client or a miner. Note that the guarding script itself does not explicitly prescribe the course of computational actions needed to produce a valid transaction. It rather describes the algorithm of telling whether the result of the actions is correct or not. As an example, one could set a guarding script in the form $5^{out[0].x}\,\text {mod}\, 23 = 13$. This script structure is admissible, but it is hard to say that it describes an actual program of discrete logarithm calculation. In our particular case the solution is simple. If the guarding script is of the form $(out[0].x=f(in))\wedge (something)$ with f being some function, then in order to satisfy the condition one can replace the equality check with a variable assignment. Hence if we require the script to be conjunction of equality checks containing the fields of the outputs solely on the left hand sides, and functions of the inputs on the right hand sides, then it actually defines the program (assuming that the inputs are fixed). It is fully present in the Algorithm 2. Another problem is collecting the right set of inputs for the transaction. Suppose one wants to spend in[0]. If the condition for in[1] is conjunction of the expressions of type $in[1].x=f(in[0])$, then finding the suitable in[1] is the lookup over the possible inputs with field x being the key. Therefore, if the guarding script can be represented in the form

$$\begin{aligned} \nonumber&\left( \bigwedge _i\bigwedge _j(out[i].x_j=f_{ij}(in))\right) \wedge \\&\left( \bigwedge _i in[1].x_i = g_{1i}(in[0])\right) \wedge \left( \bigwedge _i in[2].x_i = g_{2i}(in[0],in[1])\right) \wedge \dots , \end{aligned}$$

(1)

it can be efficiently converted to the transaction generation algorithm:

Here the last if-statement is the consistency check. Note that both Algorithms 2 and 3 can be represented as the desired form (1) with the length checks.