Real computers vs Turing machines

What is a real computer?

A real computer can be defined as a computer which can exist practically rather than merely theoretically. The physics as we know it requires all computers have a limited amount of memory and a finite numbers of states. We can conclude from this that real computers may be modeled as finite automata. In my previous post I described how finite automata works, and how it is a finite state machine (the amount of states is not without limit).

What is a Turing machine?

A Turing machine can be defined as a computer which can only ever exist theoretically. It has infinite memory, and infinite states. A Turing machine at best is just a hypothetical model of a fictitious computer defined by a precise mathematical model to function as an abstract machine. To say a programming language is Turing complete simply means it can simulate or function equivalently to a Turing machine.

Some thoughts

Ethereum claims to be Turing complete. This is significant because it means it can be applied in a manner which can where the resource limitations are without boundaries. At the same time the halting problem in Ethereum is side-stepped by gas which acts as a measure for the amount of resources a smart contract may use which puts in place an upper bound. On the same token, the Turing complete nature of an Ethereum smart contract prevents us from taking necessary security procedures to limit the behavior of a particular smart contract.

In a system where all possible states are known, all impossible states are also known. This allows for a verifiable security where logic can restrict the possible behaviors of any program or in other words limit the possible states. Because real software runs on real computers, and because resources in the universe are fixed, as in a constant (energy is not created or destroyed), there would seem to be no practical benefit to building on such a foundation unless you truly cannot predict exactly how much resources a specific application will require in advance. This opens up the possibility of infinite loops, and unpredictable behavior, but some problems require it. A Turing machine offers theoretical flexibility but for purposes of practical and secure computation over a blockchain is unnecessary as at least to my current knowledge it offers no advantages and many drawbacks.

A smart contract developer may not be able to predict the amount of memory his program will require but gas does put a hard limit. A smart contract developer on the other hand has no way to know in what ways these resources get used or what the smart contract can do prior to testing it because it's hard to find the boundaries. Something as simple as managing input becomes a major challenge because the input has to be structured and if for instance an input can be without limit with regard to size and structure then of course it can lead to the buffer overflow. The DAO suffered from a fate similar to this where an input in the form of a "recursive send pattern" was enough to confuse the behavior of the DAO smart contract away from it's intended purposes. A smart contract which allowed anyone to issue a command to it, without any way to put verified limits on these input capabilities, was confused into behaving in a way which most token holders were unaware of.

Any bug or exploit in an input function or remote command function leaves the door open for whomever is first to for lack of a better phrase, say the magic words. Solidity without formal verification requires a trial and error approach and with no central authority to correct the problem the idea of code is law is anarchy of the code. The ideal would be for developers and users to be able to trust the behavior of a block of code to act exactly as defined, and to have the precise limits on behavior so that certain possibilities aren't possible. In the case of an input, if for instance every input must meet a quality standard in order to be accepted, and this quality standard places limits such as on the amount of resources an input can take, what kind of behaviors are "legal" or "illegal" as input, then over time you can reduce the amount of possible states a smart contract can be in.