Turing Complete Blockchain on Serpent, Solidity

Alexander Pirlya - 28 October 2018 - 1 comment

Turing Complete Blockchain on Serpent Solidity

There is much debate in the crypto community about Turing-completeness and how Ethereum boasts such capability. At the same time, another major network – Bitcoin – does not have such a feature. Let’s dig deep to determine if it is really that big of a deal.


In computer science, Turing-completeness is a classification for a system of rules that manipulate data. It is named after computer scientist Alan Turing, inventor of the Turing machine. In layman’s terms, a modern Turing-complete machine can simulate any other machine. Say, you have two distinct systems that need to perform the same task. Neither one has ever done that task though. For the Turing-incomplete machine, you will need to upload and install a new set of code which provides the ability to perform the necessary task. For the Turing-complete machine, however, you will simply need to provide the machine with instructions (for example, ‘achieve objective X, while not breaking rule A to Z’) and the machine will then relay that to its existing code base and arrange itself appropriately to perform the task. A programming language is considered to be Turing-complete once it resides in the same computational class as a Turing machine. It can perform any calculation that a universal Turing machine can.


Some notable examples of Turing-completeness in languages and machines include:

  • Many procedural programming languages, including C and Pascal
  • Most object-oriented programming languages, such as Java and C++
  • Logic programming languages, such as Prolog
  • Many finite automata systems, such as Conway’s Game of Life

Turing-complete blockchain

Ethereum is considered a Turing-complete blockchain as it makes use of a fully featured programming language. By contrast, the Bitcoin blockchain is not Turing-complete since it has little to no ability for data manipulation. Ethereum has the ability to take on contracts because its codebase can act as a third-party. The blockchain can understand and codify contracts so that actions are completed upon the contract. Bitcoin has no need for Turing-completeness because it’s primary goal is to process transactions. Ethereum, on the other hand, is being asked to understand the underlying agreements which facilitate and process such transactions. It has no way of knowing what agreements it might be asked to understand ahead of time, therefore, it must be coded in a way that enables the blockchain to potentially understand anything – which makes it Turing-complete.

Turing-complete languages

Ethereum uses two programming languages, Solidity and Serpent, that are easy for developers to build with. They can solve any computational problem, being advanced enough to be described as Turing-complete.



Solidity is a contact-oriented programming language for writing smart contracts. It was developed by Gavin Wood, Christian Reitwiessner, Alex Beregszaszi, Liana Husikyan, Yoichi Hirai and several former Ethereum core contributors. The language is not native to Ethereum, which means it can enable writing smart contracts on blockchain platforms other than Ethereum. Solidity is currently available on both Ethereum and Ethereum Classic, Tendermint, Hyperledger Burrow, and Counterparty.


Solidity is a statically-typed programming language compiled to bytecode that is executable on the EVM. With Solidity, developers are able to write applications that implement self-enforcing business logic embodied in smart contracts, leaving a non-repudiable and authoritative record of transactions. It is widely considered easy to write smart contracts in Solidity for those who already have a certain level of programming skills.


Solidity is designed around the ECMAScript syntax to make it familiar for existing web developers. Compared to other EVM-targeting languages like Serpent, Solidity contains a number of important differences. It supports complex member variables for contracts including arbitrarily hierarchical mappings and structs. Contracts support inheritance, including multiple inheritance with C3 linearization. An application binary interface (ABI) facilitates multiple type-safe functions within a single contract. Natural Language Specification is another major feature which introduced a documentation system for specifying a user-centric description.



Serpent is a programming language designed for use in real-time systems, especially interactive multimedia. The language itself draws inspiration from Python. It has a simple, minimal syntax, dynamic typing, and support for object-oriented programming. Serpent is heavily influenced by XLisp, Squeak, SmallTalk, Ruby, and Basic providing a host of unique feature combinations.


Serpent features real-time garbage collection like Squeak but performs even better with a parallel mark-sweep garbage collector. With multiple EVM functionality, Serpent can run a number of independent instances concurrently in one address space. This allows each thread to have its own copy of Serpent and to rely on the operating system for scheduling and preemption.


Being a low-level language, however, Serpent contains a number of vulnerabilities and was deprecated in favor of Solidity as a default choice. Its spirit successor Viper is free of Serpent’s many limitations, though it remains in its experimental state.


Not to undermine the advantages of Turing-completeness, to successfully build with these types of languages requires understanding of the major limitations and challenges that come along with them.

Major Limitations


Quite ironically, especially considering the Turing-complete blockchain basic premise, but it is what it is – the technology presents certain transparency implications. As part of the requirements to evaluate a Turing-complete contract, the code to that contract must be publicly available. In Turing-complete blockchains, this code is presented at the time that its participants engage in an agreement.


While transparency is certainly an advantage in and of itself, especially in value-transfer scenarios, the problems associated with disclosing all of the inner workings of a deal across the whole network of actors are fairly obvious. Most financial contracts require non-disclosure between the parties involved, thus preventing uninvolved traders from inside-trading on these agreements.


Imagine a hypothetical situation. A major bank takes a position on a futures contract, and the whole market is aware that this move is coming. The market goes on to publicly trade on it and determine the future of that bank before the contract was even executed. Though there are some theoretical fixes to the problems of disclosure, these solutions will be a long time coming, and may never arrive at all.


Cost benefits

Storing data on the blockchain is nothing cheap. With Bitcoin, for instance, even one megabyte every 10 minutes is controversially expensive. And with Turing-complete blockchains like Ethereum, the size and processing issues costs skyrocket exponentially. This overhead reduces the ability for small computers and nodes to run the blockchain with low energy and bandwidth. This also impacts any node operating in a remote location. Costly support may seem like a drop in the ocean for enterprise and banking projects, but let’s not forget why blockchain is a thing in the first place – to serve as a distributed, open and available-to-all technology.


It’s hard to argue against the benefits of Turing-completeness on the blockchain especially as adoption rates for smart contracts rise over time and costs go down. However, in their current state, Turing-complete languages for smart contracts are needlessly dangerous because you can’t figure out in advance what they do and how much they will cost. Refer to the latest tweet by Nick Szabo, the progenitor of the ‘smart contract’ as we know it: “At scale, a Turing-complete blockchain can be a platform for extremely expensive trust-minimized computations. Not a ‘World Computer’ or ‘Web3.0’. With very carefully written & very small no-library programs, it would be suitable for large-sum financial smart contracts.”


As such, we at DataRoot Labs insist on using only non-Turing-complete languages underpinned by formal reasoning and verification practice ensuring that a smart contract fulfills its intended purpose and price range.


Agree or disagree? We’d love to hear your thoughts about the validity of Turing-complete smart contracts and dig deeper into the topic. Feel free to reach out to us anytime!