Do Smart Contract Languages Need

to Be Turing Complete?

Marc Jansen, Farouk Hdhili, Ramy Gouiaa, and Ziyaad Qasem(B)

Computer Science Institute, University of Applied Science Ruhr West,

Bottrop, Germany
{marc.jansen,ziyaad.qasem}@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
c Springer Nature Switzerland AG 2020
J. Prieto et al. (Eds.): BLOCKCHAIN 2019, AISC 1010, pp. 19–26, 2020.
https://doi.org/10.1007/978-3-030-23813-1_3
20 M. Jansen et al.

these problems is the complexity of the used languages. Therefore, one question
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
approaches by different blockchains, allowing to implement code that is exe-
cutable 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? 21

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 environ-
ment 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 program-
ming language for the formulation of smart contracts, but it targets on the inte-
gration of well-known, respected and widely spread existing programming lan-
guages in which smart contracts for the NEO platform should be implemented.
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 program-
ming languages in order to interact with the technology. On the other hand, this
approach allows to some extent to mitigate the risks involved with the devel-
oped 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.
22 M. 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 Sect. 2, different
approaches 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 lan-
guages. In this context, Atomic Swaps [11] refer to sending tokens from one
blockchain based implementation to another one in which either the correspond-
ing 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 someone from spending the funds before the campaign is finished. Of
1
https://vyper.readthedocs.io.
 Do Smart Contract Languages Need to Be Turing Complete? 23

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 lan-
guages, it is fair to raise the question on how big the percentage of contracts is,
that actually 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 order
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.io2 provides 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

2
https://etherscan.io/.
24 M. 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
Fig. 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

Turing 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 func-
tions or Turing completeness, since there exist functions from the latter com-
putability 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 anal-
ysis 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 com-
plete smart contract for their implementation and by this answer the raised
research question. Regular expressions [14] provide a powerful tool for the anal-
ysis of texts. Therefore, 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? 25

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
26 M. Jansen et al.

not analyzing indirect recursive method calls could be analyzed further; sec-
ond, the identified while-loops could be analyzed for possible implementations
with other flow-control mechanisms. Nevertheless, the results presented in this
research 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 implementa-
tion of their smart contracts.

References
1. Tama, B.A., Kweka, B.J., Park, Y., Rhee, K.H.: A critical review of blockchain
and its current applications. In: Proceedings of the International Conference on
Electrical Engineering and Computer Science (ICECOS), pp. 109–113. IEEE (2017)
2. Wright, C., Serguieva, A.: Sustainable blockchain-enabled services: smart contracts.
In: Proceedings of the International Conference on Big Data, pp. 4255–4264. IEEE
(2017)
3. Alharby, M., Van Moorsel, A.: Blockchain-based smart contracts: a systematic
mapping study (2017). arXiv preprint arXiv:1710.06372
4. Nakamoto, S.: Bitcoin: a Peer-to-peer Electronic Cash System (2008). https://
bitcoin.org/bitcoin.pdf
5. Atzei, N., Bartoletti, M., Cimoli, T.: A survey of attacks on Ethereum smart con-
tracts (SoK). In: Principles of Security and Trust, pp. 164–186. Springer, Heidel-
berg (2017)
6. Mehar, M.I., Shier, C.L., Giambattista, A., Gong, E., Fletcher, G., et al.: Under-
standing a revolutionary and flawed grand experiment in blockchain: the DAO
attack. SSRN Electron. J. (2017). https://doi.org/10.2139/ssrn.3014782
7. Church, A.: An unsolvable problem of elementary number theory. Am. J. Math.
58(2), 345–363 (1936)
8. Wright, C.: Turing Complete Bitcoin Script White Paper (2016). https://ssrn.com/
abstract=3160279
9. Wright, C.: Beyond Godel (2018). https://ssrn.com/abstract=3147440
10. Sgantzos, K.: Implementing a church-turing-deutsch principle machine on a
Blockchain. Department of Computer Science and Biomedical Informatics, Uni-
versity of Thessaly, Lamia, Greece (2017)
11. Herlihy, M.: Atomic cross-chain swaps (2018). arXiv preprint arXiv:1801.09515
12. Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Gollamudi, A., Gonthier, G.,
et al.: Formal verification of smart contracts: short paper. In: Proceedings of the
Workshop on Programming Languages and Analysis for Security, pp. 91–96. ACM,
October 2016
13. Castrillo-Fernández, O.: Web Scraping: Applications and Tools (2005). https://
www.europeandataportal.eu/sites/default/files/2015 web scraping applications
and tools.pdf
14. Goyvaerts, J., Levithan, S.: Regular Expressions Cookbook. O’reilly, Sebastopol
(2012)