Conference PaperPDF Available

Do Smart Contract Languages Need to be Turing Complete?

Authors:

Abstract and Figures

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.
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.
... Therefore, in applications based on smart contracts, the computations onchain must be minimized [23]. A study of the code complexity of smart contracts conducted in [24] found that out of 53,757 contracts analyzed, only a very small fraction of the verified smart contracts on the Ethereum blockchain (6.9%) actually fall into the Turing Complete Functions complexity class. Solving the OPF problem of a given power grid through a smart contract would force network participants to follow the computed solution in a fully decentralized manner, optimally managing energy demand without the need for a central authority. ...
... P Gi and Q Gi are accordingly calculated within the smart contract using sin and cos functions available in the smart contract in [37]. Thus, provers should only upload for each bus the respective bus voltage magnitudes and phase angles corresponding to the bus, both the power active and reactive generation, in Equation (24). The pseudocode in Algorithm 6 illustrates how the interested prover candidates apply to solve the OPF problem by depositing the required amount. ...
Article
Full-text available
Recent advances in control, communication, and management systems, as well as the widespread use of renewable energy sources in homes, have led to the evolution of traditional power grids into smart grids, where passive consumers have become so-called prosumers that feed energy into the grid. On the other hand, the integration of blockchain into the smart grid has enabled the emergence of decentralized peer-to-peer (P2P) energy trading, where prosumers trade their energy as tokenized assets. Even though this new paradigm benefits both distribution grid operators and end users in many ways. Nevertheless, there is a conflict of interest between the two parties, as on the one hand, prosumers want to maximize their profit, while on the other hand, distribution system operators (DSOs) seek an optimal power flow (OPF) operating point. Due to the complexity of formulating and solving OPF problems in the presence of renewable energy sources, researchers have focused on mathematical modeling and effective solution algorithms for such optimization problems. However, the control of power generation according to a defined OPF solution is still based on centralized control and management units owned by the DSO. In this paper, we propose a novel, fully decentralized architecture for an OPF-based demand response management system that uses smart contracts to force generators to comply without the need for a central authority or hardware.
... The creation of documents and the subsequent use of those templates by counterparties becomes feasible in large-scale cooperation. Technically, Ethereum-based smart contract utilizes Turing-complete scripting languages to achieve complicated functionalities [3] and execute thorough state transition/replication over consensus algorithms for final consistency. Based on that, the contracts running in a distributed network can still be checked publicly and traced by all participants. ...
Preprint
Full-text available
Smart contracts have recently been adopted by many security protocols. However, existing studies lack satisfactory theoretical support on how contracts benefit security protocols. This paper aims to give a systematic analysis of smart contract (SC)-based security protocols to fulfill the gap of unclear arguments and statements. We firstly investigate \textit{state of the art studies} and establish a formalized model of smart contract protocols with well-defined syntax and assumptions. Then, we apply our formal framework to two concrete instructions to explore corresponding advantages and desirable properties. Through our analysis, we abstract three generic properties (\textit{non-repudiation, non-equivocation, and non-frameability}) and accordingly identify two patterns. (1) a smart contract can be as an autonomous subscriber to assist the trusted third party (TTP); (2) a smart contract can replace traditional TTP. To the best of our knowledge, this is the first study to provide in-depth discussions of SC-based security protocols from a strictly theoretical perspective.
... Other EVM languages like Vyper and Simplicity, follow a similar route and forbid them. Further, only 6.9% of SCs use unbounded loops or recursion, and it is highly probable that some of these could be rewritten without using these constructs [9]. When unlimited repetition is required, it is often possible to express it with a bounded loop in the SC and then require that the user sends multiple TXs, each executing a fixed amount of iterations [8]. ...
Conference Paper
Full-text available
Transactions (TX) sent and executed by a public Blockchain (BC) need to pay a TX fee. The fee is relative to the resources consumed when including the TX into a block. The sender of the TX pays the fee in the native currency of the BC used. Such a fee protects the network from Denial-of-Service (DoS) attacks and incentivizes the TXs inclusion. BCs that support Smart Contracts (SC), where TXs can execute user-provided code, require a mechanism for fee calculation depending on resources consumed by the code execution. Ethereum uses an elaborated mechanism compared to Bitcoin, leading to an increase in the attack surface of their SCs. The mechanism that makes the Bitcoin script-a limited version of SCs-more secure is the ability to compute, independent from the BC state, an upper-bound on the resources needed to execute a TX. Thus, this work here proposes a new approach that enables security benefits by defining an upper-bound on resource usage for general SCs. Furthermore, the approach allows for the payment of fees in any currency and not just the native currency of the BC.
... Jansen et al. [12] ask the question of whether or not smart contract languages need to be Turing complete. They analyzed deployed smart contracts on the Ethereum blockchain and found that only 35.3% of them used while-loops, for-loops, or recursion. ...
Preprint
Full-text available
The development of smart contracts has become increasingly popular in recent history. This has, however, led to a new attack vector for malicious forces. Some recent attacks on smart contracts have resulted in the loss of tens of millions of dollars. Since smart contracts are immutable by nature, new approaches need to be considered in the mitigation of these attacks. One approach to detect defects in software is the use of static code analyis tools. Another approach is the development of new smart contract specific programming languages which, through their design, inhibit certain classes of vulnerabilities in deployed code. Popular languages such as Solidity and Vyper are being rapidly developed, but researchers are also pursuing novel ideas in less well known languages. In this paper, we will explore the current landscape of smart contract language design and compare and contrast the languages and their suitability for smart contract development. Particulary attention will be paid to how these languages address the security concerns inherent in smart contract development.
... There is discussion about the need of Turing-completeness. In 2019, only 35, 3% of 53757 smart contracts from Ethereum included loops and recursions [37], which are related to the halting problem. The Turing-completeness of the language creates more risk for bugs. ...
Preprint
Full-text available
Algocracy is the rule by algorithms. This paper summarises technologies useful to create algocratic social machines and presents idealistic examples of their application. In particular, it describes smart contracts and their implementations, challenges of behaviour mining and prediction, as well as game-theoretic and AI approaches to mechanism design. The presented idealistic examples of new algocratic solutions are picked from the reality of a modern state. The examples are science funding, trade by organisations, regulation of rental agreements, ranking of significance and sortition. Artificial General Intelligence is not in the scope of this feasibility study.
... However, specifically for Bitcoin, the possible contracts that are natively supported by this platform are very limited, since its language is not Turing-complete, an aspect investigated by the authors in [53]. ...
Article
Full-text available
Nowadays, an increasing number of third-party applications exploit the Bitcoin blockchain to store tamper-proof records of their executions, immutably. To this purpose, they leverage on the few extra bytes available for encoding custom metadata in Bitcoin transactions. A sequence of records of the same application can thus be abstracted as a stand-alone subchain inside the Bitcoin blockchain. However, several existing approaches do not make any assumptions about the consistency of their subchains, either (i) neglecting the possibility that this sequence of messages can be altered, mainly due to unhandled concurrency, network malfunctions, application bugs, or malicious users; or (ii) giving weak guarantees about their security. To tackle this issue, in this paper we propose an improved version of a consensus protocol formalized in our previous work, built on top of the Bitcoin protocol, to incentivize third-party nodes to extend consistently their subchains. Besides, we perform an extensive analysis of this protocol, both defining its properties and presenting some real-world attack scenarios, to show how its specific design choices and parameter configurations can be crucial to prevent malicious practices.
Conference Paper
Full-text available
Genetic Algorithms are the elementary particles of a brand-new world of computing. In recent years, technology has evolved exponentially in terms of Hardware, but not in terms of Software. Genetic Algorithms (GAs) are already filling this gap in fields like Big Data mining, Protein Folding predictions, Finance, etc. In this paper we present the possibility of using an "Unbounded Single Taped Turing" medium like a Blockchain to store a Genetic Algorithm that will be able to provide Turing Complete results on any mathematically given problem.
Conference Paper
Full-text available
An atomic cross-chain swap is a distributed coordination task where multiple parties exchange assets across multiple blockchains, for example, trading bitcoin for ether. An atomic swap protocol guarantees (1) if all parties conform to the protocol, then all swaps take place, (2) if some coalition deviates from the protocol, then no conforming party ends up worse off, and (3) no coalition has an incentive to deviate from the protocol. A cross-chain swap is modeled as a directed graph D, whose vertexes are parties and whose arcs are proposed asset transfers. For any pair (D, L), where D = (V,A) is a strongly-connected directed graph and L ⊂ V a feedback vertex set for D, we give an atomic cross-chain swap protocol for D, using a form of hashed timelock contracts, where the vertexes in L generate the hashlocked secrets. We show that no such protocol is possible if D is not strongly connected, or if D is strongly connected but L is not a feedback vertex set. The protocol has time complexityO(diam(D)) and space complexity (bits stored on all blockchains) O(|A|2).
Conference Paper
Full-text available
Blockchain technology has been known as a digital currency platform since the emergence of Bitcoin, the first and the largest of the cryptocurrencies. Hitherto, it is used for the decentralization of markets more generally, not exclusively for the decentralization of money and payments. The decentralized transaction ledger of blockchain could be employed to register, confirm, and send all kinds of contracts to other parties in the network. In this paper, we thoroughly review state-of-the-art blockchain-related applications emerged in the literature. A number of published works were carefully included based on their contributions to the blockchain's body of knowledge. Several remarks are explored and discussed in the last section of the paper.
Conference Paper
Full-text available
An appealing feature of blockchain technology is smart contracts. A smart contract is executable code that runs on top of the blockchain to facilitate, execute and enforce an agreement between untrusted parties without the involvement of a trusted third party. In this paper, we conduct a systematic mapping study to collect all research that is relevant to smart contracts from a technical perspective. The aim of doing so is to identify current research topics and open challenges for future studies in smart contract research. We extract 24 papers from different scientific databases. The results show that about two thirds of the papers focus on identifying and tackling smart contract issues. Four key issues are identified, namely, codifying, security, privacy and performance issues. The rest of the papers focuses on smart contract applications or other smart contract related topics. Research gaps that need to be addressed in future studies are provided.
Conference Paper
Smart contracts are computer programs that can be correctly executed by a network of mutually distrusting nodes, without the need of an external trusted authority. Since smart contracts handle and transfer assets of considerable value, besides their correct execution it is also crucial that their implementation is secure against attacks which aim at stealing or tampering the assets. We study this problem in Ethereum, the most well-known and used framework for smart contracts so far. We analyse the security vulnerabilities of Ethereum smart contracts, providing a taxonomy of common programming pitfalls which may lead to vulnerabilities. We show a series of attacks which exploit these vulnerabilities, allowing an adversary to steal money or cause other damage.
Conference Paper
Ethereum is a framework for cryptocurrencies which uses blockchain technology to provide an open global computing platform, called the Ethereum Virtual Machine (EVM). EVM executes bytecode on a simple stack machine. Programmers do not usually write EVM code; instead, they can program in a JavaScript-like language, called Solidity, that compiles to bytecode. Since the main purpose of EVM is to execute smart contracts that manage and transfer digital assets (called Ether), security is of paramount importance. However, writing secure smart contracts can be extremely difficult: due to the openness of Ethereum, both programs and pseudonymous users can call into the public methods of other programs, leading to potentially dangerous compositions of trusted and untrusted code. This risk was recently illustrated by an attack on TheDAO contract that exploited subtle details of the EVM semantics to transfer roughly $50M worth of Ether into the control of an attacker. In this paper, we outline a framework to analyze and verify both the runtime safety and the functional correctness of Ethereum contracts by translation to F*, a functional programming language aimed at program verification.