There are a couple things that people tend to overlook when talking about blockchain smart contracts. Going into intricacies of EVM’s and complicated interplay between smart contracts calls one can forget that blockchain is actually not meant for doing complicated calculations. One might even say that blockchain architecture is the worst architecture for doing computations. The reason is, of course, simple and determined by the very nature of the blockchain approach, which consists in replicating everything onto as many independent parties as possible.
When doing computations you might consider distributing the task amongst different parties by providing them with different bits of the task, not making them calculate the same thing all together. Blockchain approach is the exact opposite of this, you decentralize things by replication, not by distribution. So any attempt to do any kind of complicated calculation which go beyond basic scripting as in Bitcoin might face more fundamental challenges than optimizing EVM’s and such.
That’s the current situation in Ethereum exactly. Meant to be Turing complete and promoted as such effectively we have a system where an ability to do arbitrary computations has to be restricted artificially to account for the fact that you can’t actually do them on the blockchain. And the question arises whether the most obvious approach of making contracts callers to pay for their execution (I think this idea comes to mind to anybody starting to think how to implement blockchain computation) might be not such a brilliant idea, at least in the current state of DLT technology.
Effectively it is quite obvious that you should be able to achieve the same functionality as in “Turing complete” systems with gas without introducing any gas and by restricting complexity of computations from the get-go, not imposing it artificially through gas limits accounting for the fact that you actually CAN’T do complicated calculations and all you can get is a pocket calculator the size of the Internet.
Another thing with current approach (at least with the most popular tools such as Solidity language) is the desire to provide a programming tool that is very similar to “normal” programming languages. It is of course a valid idea, especially from the marketing point of view, but doing so there’s a risk to forget about the context of your calculations, that they are being done on a pretty unusual medium with its own properties. Re-entrancy bugs, the need to do a very thorough audit of Ethereum smart contracts and so on is the direct fallout of this.
When taking into account the context of computations it becomes possible to restore Turing completeness even if the smart contract language is restricted in its complexity. By “chaining” calculations done over several blocks you get the “Turing completeness” you crave for, but in a way that is more akin to the computational context.
Really “hard” computations interacting with blockchains currently should be built on top of them, as an application layer. To integrate them deeply into the blockchains would require creating new architecture for them, the architecture that scales from the ground up, and distributes the load, not replicates it.
In the next release of Ride language we will provide the mechanism to do meaningful computation covering all the functionality that is demanded from blockchain systems without introducing new entities such as gas, in a more secure and effectively more natural way.
ETA is Q1 2019 on the testnet.
Now DLT technology is coming to maturity in its current state; there are of course many directions to take even with the current underlying architecture. But the real breakthrough is still ahead of us, and most probably it is going to require totally new approaches. We should move forward with that in mind.
