Content uploaded by Ziyaad Qasem
Author content
All content in this area was uploaded by Ziyaad Qasem on Mar 29, 2019
Content may be subject to copyright.
Do Smart Contract Languages Need to be
Turing Complete?
Marc Jansen, Farouk Hdhili, Ramy Gouiaa, and Ziyaad Qasem
Computer Science Institute,
University of Applied Science Ruhr West, Bottrop, Germany
marc.jansen@hs-ruhrwest.de
Abstract. Blockchain based systems become more and more prominent.
While starting by developing (crypto)currency payment schemes, a lot
of the latest development goes in the direction of executing source code
directly in the peer-to-peer network blockchains are usually built on.
These so called smart contracts have become popular in order to reduce
the amount of necessary middle-mans involved in different processes.
Despite the large amount of research already invested in the design of
languages which support smart contracts, there are still a lot of problems
in the existing approaches, regularly resulting in security flaws. One of
these problems is the complexity of the used languages. Therefore, this
paper provides an evaluation of currently deployed smart contracts with
respect of the requirements of those contracts concerning computability.
The finding is that most of the currently deployed smart contracts do not
need Turing complete languages, but could also be implemented based
on a simpler design of the underlaying language.
Keywords: computability, Turing complete language, blockchain
1 Introduction
In recent years, blockchain based systems gained a lot in popularity. Beside
the most usual and first use case of a cryptocurrency, blockchains are nowa-
days discussed for a much broader amount of use cases, e.g., title registers [1],
automatic contract execution [2] and so on. Therefore, additional requirements
came up, especially the requirement to directly execute small programs on the
blockchain, usually referred to as smart contracts. Here, smart contracts refer to
distributed coordination task performed by nodes in the peer-to-peer network
of a blockchain [3]. Smart contracts have especially become popular in order
to remove middle-man activities in coordination tasks, while at the same time
guarantee the consensus in the network. Due to the increased interest in this
kind of automatic contract execution technology, a lot of research has already
been invested in the design of languages that support the development of smart
contracts. Still a lot of problems in the existing approaches, regularly resulting
in security flaws, exist which lead to large, mostly financial, damage. One of
these problems is the complexity of the used languages. Therefore, one question
2 Jansen et al.
currently discussed heavily in the blockchain communities is if programming lan-
guages with a lower complexity might be able to increase the security of those
systems on the one hand and on the other hand if such programming languages
are appropriate for the development of smart contracts. In order to answer one
of those questions, this paper provides an evaluation of smart contracts on the
Ethereum blockchain, as the currently largest blockchain network supporting
those contracts. The major perspective of the presented research is to gather the
requirements of those deployed smart contracts with respect to basic questions
about computability theory. Therefore, a large number of smart contracts have
been analyzed in order to identify if a Turing complete programming language
is necessary for their implementation, or if less complex programming languages
could be used.
The remainder of the paper is organized as follows: first the current research
status with respect to the topic of this paper is presented in a state of the art
section. Afterwards, the research question and analysis strategy used for the
presented research is described, followed by a detailed description of the found
results. Finally, the paper finishes by short discussion of the results and the
presentation of possible future lines of research.
2 Background
After the introduction of the blockchain technology in 2008 [4], Bitcoin was the
first implementation of this approach which went live in 2009. Ever since, a
large number of different blockchain implementations appeared and all of them
implemented a different notion of the proposed architecture. While Bitcoin itself
is primarily meant to be a cryptocurrency, other implementations, e.g., Ethereum
concentrated more on being a runtime environment for code executed directly
on the blockchain, often referred to as chaincode or smart contracts.
Due to the high amount of values that are distributed by those blockchain
implementations, they provide interesting targets to attack, partly with great
success [5]. Therefore, this section provides a small overview of scripting ap-
proaches by different blockchains, allowing to implement code that is executable
directly on the blockchain.
Sometimes not so well understood, every transaction in the cryptocurrency
blockchain of Bitcoin is protected by a small script. This script is formulated
in the Bitcoin Script language, stack based and attached to a transaction. If
and only if the script attached to a transaction is successfully executed, the
corresponding transaction is executed in the Bitcoin network, hence the corre-
sponding funds are transferred from one to another address. Certain operations
are possible in Bitcoin scripts like defining constants, doing basic flow control,
splicing strings, bitwise logic, basic arithmetics and cryptographic functions. One
important aspect about the Bitcoin scripting language is that although it does
provide basic flow control mechanisms, e.g., conditions, it does not provide a
Turing complete language, e.g., it does not provide means for loops and / or
complex recursion.
Do Smart Contract Languages Need to be Turing Complete? 3
Ethereum, as the currently second most prominent blockchain implementa-
tion, is an open-source distributed computing platform featuring smart contracts.
It provides the ability to formulate smart contracts base on a language called
Solidity. It provides an object oriented programming paradigm and made use
of prominent ideas from JavaScript community, e.g., when it comes to syntax.
While Solidity itself is a Turing complete programming language, the runtime en-
vironment in which Solidity based smart contracts are executed on the Ethereum
blockchain limits the amount of computational power that each smart contract
can consume, so that the developers of this approach speak of a pseudo-Turing
complete approach. Users of the system are able to create their own token via
smart contracts. Those tokens can basically be used for different purposes, e.g.,
represent shares of a company, could provide access to certain services or act as
an investment fund. One of the advantages of this approach is, that developers of
smart contracts are very flexible with respect of the functionality implemented
in the smart contracts. On the other hand, the more complex the implementa-
tion of smart contracts are, the more error prone they are at the same time. A
couple of prominent hacks on the Ethereum blockchain are due to errors in the
complex implementation of their corresponding smart contracts, e.g., the DAO
hack [6].
In contrast to Bitcoin and Ethereum, NEO did not introduce a new pro-
gramming language for the formulation of smart contracts, but it targets on
the integration of well-known, respected and widely spread existing program-
ming languages in which smart contracts for the NEO platform should be im-
plemented. The major idea of this approach is on the one hand to open the
blockchain world for a larger community by offering interfaces to blockchains
based on well-known programming languages so that developers do not need to
learn new programming languages in order to interact with the technology. On
the other hand, this approach allows to some extent to mitigate the risks in-
volved with the developed smart contracts. As the developer uses his/her usual
IDE debugging tool, it is less likely that there will be bugs that could affect the
contract behavior at runtime.
In contrast to the approach of Ethereum or NEO to provide Turing complete
languages for the development of smart contracts, the Waves Platform decided
to take a two steps approach. In the first step a non-Turing complete program-
ming language, called RIDE, was developed in order to provide basic scripting
functionality, while at the same time to reduce the risk of security relevant errors
in those scripts. The RIDE language does, e.g., not support recursion or any kind
of loops. This, on the one hand, makes the programming structure very simple
so that scripts could easily be tested against security flaws, while at the same
time it allows to estimate the computational effort necessary for the execution
of the smart contract, e.g., for calculating costs associated with the execution
and/or ensuring that there are no smart contracts deployed that allow for denial
of service attacks against nodes of the blockchain. In general it could be said,
that the halting problem [7] is easy to decide for scripts implemented in RIDE.
4 Jansen et al.
Indeed, there is an active discussion going on with respect to the question if
the scripting language in Bitcoin is actually Turing complete. There is a bit of
research already available on that topic, e.g., [8], [9] and [10]. Basically, the idea
here is that the forging / mining mechanism that generates new blocks, could
also be seen as an endless loop that could, together with conditions, be used
in order to provide the functionality of a while loop, allowing while-computable
calculations and thus providing a Turing complete approach.
The next section describes the research question of the presented work along
with the analysis strategy that was implemented in order to analyze the current
situation with respect to the research question.
3 Research Question and Analysis Strategy
The research question driving the motivation of the presented research was to
identify the need of Turing complete languages for the implementation of smart
contracts in blockchain based systems. As discussed in section 2, different ap-
proaches exist, which either use Turing complete languages (like Ethereum and
NEO) while other approaches intentionally use non-Turing complete languages
for the implementation of smart contracts, e.g., Bitcoin and Waves. This ques-
tion is particularly interesting having in mind that most attacks on blockchain
based systems, have either been due to stolen passwords, server misconfigura-
tions or attack vectors against poorly implemented smart contracts. Therefore,
a prominent idea in the blockchain community is to provide less complicated
programming languages in order to make errors in smart contract codes less
probable and increase potential security checks on smaller and less complicated
implementations. In this context, we can refer to the programming language
Vyper1. Vyper is a python-like scripting language that targets the Ethereum
Virtual Machine (EVM). The goal of this language is to write secure and maxi-
mally human-readable smart contacts by losing some Turing complete features.
This shows that the developers have indeed begun to think about solutions to
the problems of smart contracts caused by the Turing complete languages. At
the same time, a non-Turing complete programming language for the implemen-
tation of smart contracts would definitely limit the type of contracts that could
be implemented.
Yet often mentioned scenarios as examples from the blockchain field as Atomic
Swaps, securing funds in crowdfunding campaigns and further more could also
be implemented based on non-Turing complete programming languages. In this
context, Atomic Swaps [11] refer to sending tokens from one blockchain based
implementation to another one in which either the corresponding transactions
on both sides are executed or none of them. The other example of securing
funds during a crowdfunding campaign is reasonable in order to prevent funds
being transferred from a certain address before a certain point in time. This is
a very usual demand during crowdfunding campaigns, e.g., in order to prevent
1https://vyper.readthedocs.io
Do Smart Contract Languages Need to be Turing Complete? 5
someone from spending the funds before the campaign is finished. Of course this
concept of putting time restrictions on spending funds could more generalized
also be used in other scenarios. Therefore, since there is a significant amount
of examples that do not rely on Turing complete programming languages, it is
fair to raise the question on how big the percentage of contracts is, that actu-
ally need Turing complete programming languages. In order to further analyze
this, the smart contracts currently deployed to the Ethereum blockchain seem
to be a good point of reference, since the Ethereum platform is currently by far
the largest platform that allows for the deployment of Turing complete smart
contracts.
The next section describes the implementation of the different steps in or-
der to perform the described analysis of Ethereum based smart contracts with
respect to their demand for Turing complete languages.
4 Implementation
As described in the last section, the goal of this research is to answer the ques-
tion if Turing complete languages are necessary for smart contracts. In order to
do this, the verified smart contracts on the Ethereum blockchain are analyzed
with respect to different paradigms used in the contracts, e.g., like loops and/or
recursion.
4.1 Dataset
Smart contracts as code that could be executed on the blockchain directly offer
functions that can be used by participants all over the world and they are acces-
sible to everyone, making them a valuable target for hackers. Therefore, a formal
verification process has been deployed on the Etherscan platform. Each Solidity
smart contract code is compiled to EVM Bytecode that runs on the Ethereum
network which means each Solidity script has its own Creation Address Byte-
code. A hacker or even malicious miner may try to cheat by not running the
program or running it incorrectly [12]. To verify a smart contract, the developer
has to apply a proof that the contract behaves as intended, in order to reduce
the risk of malicious scripts, otherwise if the Bytecode generated matches the
existing Creation Address Bytecode, the contract is verified.
Unfortunately, the publicly available API of the platform does not provide
access to smart contracts. Therefore, a web scraping tool [13] was implemented
allowing to extract data from one of the websites that provide access to the
smart contracts. Etherscan.io 2provides a central starting point for accessing
verified smart contracts on the Ethereum blockchain using the web scraping
tool. Additionally, Etherscan.io also provides access to specific verified smart
contracts in order to access certain details of a particular contract.
In order to actually download and store the available verified smart contracts
from Etherscan, a NodeJS program with the cherioo web scraping module was
2https://etherscan.io/
6 Jansen et al.
implemented. By utilizing this program all available verified smart contracts on
the Ethereum blockchain at the point of writing have been downloaded and
stored. This results in a total of 53757 verified smart contracts that have been
made available for later analysis, providing a rich enough base for the conclusions
drawn by the results presented later in this paper.
4.2 Analysis of the Smart Contracts
Based on the usual classification of different computability classes, as shown in
Figure 1, the stored smart contracts have been analyzed with respect to the flow
control mechanisms they provide.
Fig. 1: Usual differentiation of computability classes
According to the well-known theory, while-computability is equivalent to Tur-
ing completeness and to µ-recursive functions. At the same time, loop-computability
is equivalent to primitive recursion, while both computability classes are less
powerful in comparison to while-computability, µ-recursive functions or Turing
completeness, since there exist functions from the latter computability classes
that are not loop-computable or could not be expressed with primitive recursion,
while all loop-computable/primitive recursive functions are while-computable/µ-
recursive/Turing complete. Therefore, the performed analysis identified the flow
control mechanisms used by the extracted smart contracts and assigned each
smart contract to a corresponding computability class in order to check for the
percentage of smart contracts that actually need a Turing complete smart con-
tract for their implementation and by this answer the raised research question.
Regular expressions [14] provide a powerful tool for the analysis of texts. There-
fore, the source codes of the stored smart contracts have been interpreted as text
files and been analyzed with regular expressions in order to check for different
control flow mechanisms in the contract’s codes.
5 Evaluation results
Based on the mentioned analysis steps in the previous sections, we have found
that about 24.8% (13347 of the analyzed 53757 contracts) of all verified con-
tracts use for-loops. It is important to stress here, that this kind of contracts
Do Smart Contract Languages Need to be Turing Complete? 7
do strictly speaking not fall in the computability class that demands for Turing
complete smart contracts. With respect to the problems related to the halting
problem raised by these kinds of loops in blockchains, we considered these kinds
of contracts also to the same complexity class.
Furthermore, we have found that about 3.6% make use of recursive functions.
It is important to note once again that this type of contracts do not strictly
speaking fall into the class of computability that requires Turing complete, but
for the same practical reasons mentioned before, we counted them to the more
complex computability class.
Related to the while-loops, about 6.9% of all analyzed smart contracts make
use of while-loops. Apparently, this result was a bit surprising since strictly
spoken, only those 6.9% of all analyzed smart contracts made use of a control flow
mechanism that usually demands for a Turing complete programming language.
In addition, it is highly probable that some of those smart contracts could be
implemented without while-loops (can be implemented with for-loops with a
variable amount of runs).
5.1 Discussion of the results
The obtained results show that only a very small amount of currently verified
smart contracts on the Ethereum blockchain (6.9% of while-loops) really fall into
the complexity class of Turing complete functions. In other words, only 6.9% of
all currently deployed smart contracts use problematic control-flow mechanisms.
Even if we take a more practical perspective, namely the for-loops and prim-
itive recursive functions and the problems related to the halting problem associ-
ated with this type of function, we got only 35.3% (6.9% of while-loops, 24.8%
of for-loop and 3.6% of contracts that use recursion). In such a case, 35.3%
of all currently deployed smart contracts use problematic control-flow mecha-
nisms. Therefore, the results imply that making use of non-Turing complete
smart contracts in the context of blockchain based systems makes perfect sense.
Nevertheless, it might be reasonable to provide a twofold approach in which
one non-Turing complete language for smart contracts is provided, alongside a
second programming language that allows for the execution of Turing complete
smart contracts.
6 Outlook and future work
The presented work provides an answer to the research question if programming
languages for smart contracts need to be Turing complete. It therefore analyzed
verified smart contracts on the Ethereum blockchain with respect to the com-
plexity of flow-control mechanisms used in those contracts. The results show that
by far the larger amount of smart contracts do not need Turing complete lan-
guages for their formulation. Future steps to extend the results of this research
might include a deeper analysis in two dimensions: first of all, the anomaly of
not analyzing indirect recursive method calls could be analyzed further; second,
8 Jansen et al.
the identified while-loops could be analyzed for possible implementations with
other flow-control mechanisms. Nevertheless, the results presented in this re-
search might have an important impact on the security of smart contracts based
on blockchain technology, if developers of those smart contracts will be provided
by non-Turing complete programming languages for the implementation of their
smart contracts.
References
1. Tama, B.A., Kweka, B.J., Park, Y. and Rhee, K.H., 2017. A critical review of
blockchain and its current applications. In Proceedings of the International Con-
ference on Electrical Engineering and Computer Science (ICECOS) (pp. 109-113).
IEEE.
2. Wright, C. and Serguieva, A., 2017. Sustainable blockchain-enabled services: Smart
contracts. In Proceedings of the International Conference on Big Data. (pp. 4255-
4264). IEEE.
3. Alharby, M. and van Moorsel, A., 2017. Blockchain-based smart contracts: A sys-
tematic mapping study. arXiv preprint arXiv:1710.06372.
4. Nakamoto, S., 2008. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.
org/bitcoin.pdf.
5. Atzei, N., Bartoletti, M. and Cimoli, T., 2017. A survey of attacks on ethereum
smart contracts (sok). In Principles of Security and Trust (pp. 164-186). Springer,
Berlin, Heidelberg.
6. Mehar, M.I., Shier, C.L., Giambattista, A., Gong, E., Fletcher, G. et al, 2017. Un-
derstanding a Revolutionary and Flawed Grand Experiment in Blockchain: The
DAO Attack. SSRN Electronic Journal. doi:10.2139/ssrn.3014782.
7. Church, A., 1936. An unsolvable problem of elementary number theory. American
journal of mathematics, 58(2), pp.345-363.
8. Wright, C., 2016. Turing Complete Bitcoin Script White Paper. Available at SSRN:
https://ssrn.com/abstract=3160279.
9. Wright, C., 2018. Beyond Godel. Available at SSRN:
https://ssrn.com/abstract=3147440.
10. Sgantzos, K., 2017. Implementing A Church–Turing–Deutsch Principle Machine
on a Blockchain. Department of Computer Science and Biomedical Informatics,
University of Thessaly, Lamia, Greece.
11. Herlihy, M., 2018. Atomic cross-chain swaps. arXiv preprint arXiv:1801.09515.
12. Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Gollamudi, A., Gonthier, G. et al,
2016, October. Formal verification of smart contracts: Short paper. In Proceedings
of the Workshop on Programming Languages and Analysis for Security (pp. 91-96).
ACM.
13. Castrillo-Fern´andez, O., 2005. Web Scraping: Applications and tools.
https://www.europeandataportal.eu/sites/default/files/2015 web scraping
applications and tools.pdf
14. Goyvaerts, J. and Levithan, S., 2012. Regular expressions cookbook. O’reilly.
