0% found this document useful (0 votes)
92 views23 pages

Smart Contract Development Challenges and Opportunities

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
92 views23 pages

Smart Contract Development Challenges and Opportunities

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

2084 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO.

10, OCTOBER 2021

Smart Contract Development: Challenges


and Opportunities
Weiqin Zou , David Lo , Pavneet Singh Kochhar , Xuan-Bach Dinh Le, Xin Xia , Yang Feng,
Zhenyu Chen , and Baowen Xu , Member, IEEE

Abstract—Smart contract, a term which was originally coined to refer to the automation of legal contracts in general, has recently seen
much interest due to the advent of blockchain technology. Recently, the term is popularly used to refer to low-level code scripts running
on a blockchain platform. Our study focuses exclusively on this subset of smart contracts. Such smart contracts have increasingly been
gaining ground, finding numerous important applications (e.g., crowdfunding) in the real world. Despite the increasing popularity, smart
contract development still remains somewhat a mystery to many developers largely due to its special design and applications. Are
there any differences between smart contract development and traditional software development? What kind of challenges are faced
by developers during smart contract development? Questions like these are important but have not been explored by researchers yet.
In this paper, we performed an exploratory study to understand the current state and potential challenges developers are facing in
developing smart contracts on blockchains, with a focus on Ethereum (the most popular public blockchain platform for smart contracts).
Toward this end, we conducted this study in two phases. In the first phase, we conducted semi-structured interviews with 20
developers from GitHub and industry professionals who are working on smart contracts. In the second phase, we performed a survey
on 232 practitioners to validate the findings from the interviews. Our interview and survey results revealed several major challenges
developers are facing during smart contract development: (1) there is no effective way to guarantee the security of smart contract code;
(2) existing tools for development are still very basic; (3) the programming languages and the virtual machines still have a number of
limitations; (4) performance problems are hard to handle under resource constrained running environment; and (5) online resources
(including advanced/updated documents and community support) are still limited. Our study suggests several directions that
researchers and practitioners can work on to help improve developers’ experience on developing high-quality smart contracts.

Index Terms—Smart contract, challenges, empirical study, blockchain

1 INTRODUCTION
the release of Bitcoin in 2009 [105], decentralized maintain and secure a public and append-only ledger of
S INCE
cryptocurrencies have gained considerable attention
and adoption [2]. For instance, till February 2018, the
transactions, i.e., blockchain. In recent years, the poten-
tial of blockchain technology has been exploited beyond
numbers of coins and tokens hosted on the coinmarket- cryptocurrencies, among which a promising use of
cap1 were 896 and 649, respectively. A cryptocurrency is blockchain is smart contract.
administrated not by a central authority, but by auto- The term “smart contract” was originally coined to refer
mated consensus among networked users. The users in to the automation of legal contracts in general [140]. The
the cryptocurrency network run a consensus protocol to term was (and is still) used to refer to a legal contract which
or at least parts of which is capable of being expressed and
implemented in software [66]. The advent of blockchain
1. http://coinmarketcap.com technology has recently brought much interest on smart
contracts. Today, the term is popularly used to refer to as
 W. Zou, Y. Feng, Z. Chen, and B. Xu are with the State Key Laboratory for
Novel Software Technology, Nanjing University, Nanjing 210008, China.
code scripts that run synchronously on multiple nodes of a
E-mail: [email protected], [email protected], {zychen, distributed ledger (e.g., a blockchain) [30]. In this paper,
bwxu}@nju.edu.cn. we mainly focus on the latter, more specific definition of
 D. Lo is with the School of Information Systems, Singapore Management smart contracts, i.e., low-level code scripts running on
University, Singapore 188065. E-mail: [email protected].
 P.S. Kochhar is with Microsoft, Mississauga, Canada. blockchains.
E-mail: [email protected]. As a program running on a blockchain, a smart contract
 X.-B. Dinh Le is with the School of Computing and Information Systems, can be correctly executed by a network of mutually distrust-
University of Melbourne, Parkville, VIC 3010, Australia.
ing nodes without the need of an external trusted authority.
E-mail: [email protected].
 X. Xia is with the Faculty of Information Technology, Monash University, The self-executing nature of smart contracts provides a tre-
Clayton, VIC 3800, Australia. E-mail: [email protected]. mendous opportunity for use in many fields that rely on
Manuscript received 3 Jan. 2019; revised 31 Aug. 2019; accepted 10 Sept. data to drive transactions [139]. In the beginning of 2018,
2019. Date of publication 24 Sept. 2019; date of current version 15 Oct. 2021. more than 10 percent of the jobs advertised on Guru2 (one
(Corresponding author: Zhenyu Chen.)
Recommended for acceptance by R. Mirandola.
Digital Object Identifier no. 10.1109/TSE.2019.2942301 2. http://www.guru.com/

0098-5589 © 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See ht_tps://www.ieee.org/publications/rights/index.html for more information.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2085

of the biggest freelancer sites) were related to smart con- mentioned by developers, the current programming lan-
tracts and blockchains [56]. Currently, more and more guages and virtual machines that were specifically designed
developers are devoting themselves to developing smart for smart contracts still had a number of limitations (e.g.,
contracts in various domains, e.g., finance, game, and lack of general purpose libraries and limited support for
notary [11]. The number of smart contracts deployed on debugging). These limitations often adversely affected their
Ethereum3 (the most popular public blockchain for running project development experience, especially for complex
smart contracts with market capitalization exceeding $80 projects. Another big challenge for developers was perfor-
billions) has also sharply increased to more than 2 million mance issues-they were interested in tools and resources
in March 2018.4 that could help them write efficient smart contracts that con-
The emergence of smart contracts brings about a grow- sume fewer resources on the blockchain. Besides, lack of
ing and widespread interest in the research community. advanced/updated documents and delay in responses from
More and more researchers are taking smart contracts as the online community also had an impact on smart contract
study targets [21], [69], [90]. A growing number of papers development.
have been published in events such as ACM/IEEE The major contributions of our study are as follows:
International Workshop on Emerging Trends in Software
Engineering for Blockchain (WETSEB),5 and International  To the best of our knowledge, this is the first in-
Workshop on Blockchain Oriented Software Engineering depth study that explores practitioners’ perceptions
(IWBOSE),6 as well as some tracks at conferences such on current state of smart contract development and
as ACM Conference on Computer and Communications challenges ahead through interviews and survey.
Security (CCS) and International Symposium On Leverag-  We perform an analysis of the qualitative and quan-
ing Applications of Formal Methods, Verification and titative data and highlight actionable insights and
Validation (ISoLA)7[122], etc. implications that developers, tool builders, and
Despite the increasing popularity of smart contract, the researchers can use to improve developer experience
potential challenges that developers are facing when devel- during smart contract development.
oping smart contracts have not yet been clearly explored. The remaining parts of this paper are structured as fol-
Without understanding these challenges, practitioners and lows: In Section 2, we provide background materials on
researchers may spend much efforts developing techniques smart contracts. In Section 3, we present our empirical study
and tools that are not appreciated by developers and thus methodology in detail. The findings of our study are pre-
are underused in practice. sented in Section 4. Section 5 presents some potential
To help advance research in smart contract development, research directions based on our findings. Section 6 dis-
we conducted an empirical study to explore the work prac- cusses the threats to validity of our study. The last two sec-
tice and potential challenges faced by developers during tions present the related work and summarize our study.
smart contract development on blockchains, with a focus on
Ethereum. We followed a mixed-method approach that is a
combination of interviews (qualitative) and survey (quanti- 2 BACKGROUND
tative). Specifically, we first interviewed 20 developers with Blockchain. A blockchain in its very simple form is a chain of
different backgrounds and expertise. During interviews, we records called blocks, in which blocks are linked and
asked participants about their normal work practices secured using cryptography. Each block is characterized by
and relevant challenges faced during different stages (e.g., some transaction data, a time stamp, and the hash value of
coding, testing, debugging) of smart contract development. its previous block. Blockchain can be considered as a public
Then we used open card sorting [135] to analyze the ledger where each block contains records of some transac-
interview results. The resulting categories produced by tions. The blockchain is not stored in a single location but
open card sorting were grouped into six groups, i.e., secu- on a network of nodes, where each network node has a
rity, debugging, programming language, Ethereum virtual copy of this blockchain. This means all the records are pub-
machine, gas, and online learning resources & community lic and easily verifiable to all network nodes, which makes
support. After that, we performed a validation survey with it very expensive for a node to modify any data in the block-
232 developers to confirm various insights from the inter- chain. Once a block is appended to the blockchain, it is
views, including challenges, best practices, and desired extremely hard to modify the block’s transactions without
improvements. achieving consensus of all nodes. All these features are by
Based on the interviews and survey, we found that design and based on peer-to-peer consensus protocol [105].
developers cared a lot about code security but did not have The blockchain technology allows two untrusted parties to
effective ways to prove the correctness, reliability and secu- make transactions securely without the participation of a
rity of their code; meanwhile, the lack of powerful tools trusted third party. This makes blockchain suitable for
especially step-through/interactive debuggers often made record keeping tasks such as storage of ownership rights of
it painful to program smart contracts. Furthermore, as musical work, financial transactions, etc. Cryptocurrencies
which are based on blockchain have attracted considerable
attention lately [90]. An emerging area of blockchain tech-
3. http://www.ethereum.org/ nology is smart contract.
4. https://etherscan.io/accounts/c. Last Access: March 2018 Smart Contract. The term “smart contract” was coined by
5. http://conferences.computer.org/icse-w/2018/#!/toc/28
6. http://saner.unimol.it/blockchainOrientedSoftwareEngineering Nick Szabo in the mid 1990s [140]. He suggested translating
7. http://www.isola-conference.org/isola2018/tracks.html the clauses of a contract into code and embedded them into

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2086 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

software or hardware to make them self-execute, in order to fee for transactions on Ethereum) and the validation of rele-
minimise contracting cost between transacting parties and vant transactions may take a long time (due to replicated exe-
to avoid accidental exceptions or malicious actions during cution of smart contracts among nodes). As an alternative
contract performance. solution towards these problems, the idea of “off-chain”
Currently people in different disciplines used the term smart contract has been proposed [41], [83]. Off-chain smart
“smart contract” in different ways. Some referred “smart contracts are executed outside of the blockchain. Unlike on-
contract” as a legal contract which (or at least elements of chain smart contracts, an off-chain smart contract only needs
which) could be represented by software. While some to be signed and executed by interested participants. As pro-
others took “smart contract” as code scripts which are posed, an off-chain smart contract is generally designed to
designed to execute certain tasks once pre-defined condi- encapsulate functions involving high-cost computation or
tions are met; these scripts typically (although not necessar- private information about the participants; while an on-
ily) run on distributed ledgers (e.g., blockchains) [27], [136]. chain smart contract is suggested to conduct some low-cost
Clack et al. proposed a definition of smart contract which is and non-sensitive tasks. To preserve the properties and bene-
broad enough to cover the breath of above-mentioned defi- fits of a blockchain, in practice, the results of off-chain smart
nitions. They defined a smart contract as “an automatable contracts would be for example logged on-chain [41]. In case
and enforceable agreement. Automatable by computer, of any disagreement on the execution results of an off-chain
although some parts may require human input and control. smart contract, an on-chain smart contract may be used to
Enforceable either by legal enforcement of rights and obliga- fork the off-chain smart contract and execute it on blockchain
tions or via tamper-proof execution of computer code” [29]. to solve the dispute [83].
In this paper, we mainly focus on low-level code scripts Blockchain Platforms for Smart Contracts. Blockchains can
running on blockchains. As a program running on a block- be divided into public and non-public categories. Public
chain, a smart contract can facilitate a contract between two blockchain platforms allow any user to join the network
parties without relying on a trusted third party. Technically while non-public blockchain platforms allow only permit-
speaking, a smart contract is a program that contains both ted users to join. Examples of public blockchains are Ether-
data (e.g., account balance) and executable code. Smart con- eum, and NEO.8 Some examples of non-public blockchains
tract can be stored in the blockchain, and can be automati- are Fabric9 and Quorum.10 Different blockchain platforms
cally executed when certain pre-condition is met. After each provide different support for smart contracts. Some (e.g.,
execution of the smart contract, its state can be updated on Bitcoin) may only allow users to use a simple scripting
the blockchain [152]. language to develop smart contracts with simple logic;
Smart Contracts Running on Corda. Corda is an open- while some platforms, such as Ethereum, support much
source permissioned blockchain platform that is explicitly more advanced programming languages for writing smart
designed to account for the highly regulated environment contracts [127].
of the financial service industry [92]. Within Corda, each Ethereum. Since its release in July, 2015, Ethereum has
node has a certificate that maps their network identity to a grown to become the most popular blockchain platform for
real-world legal identity. The communication between smart contracts [21]. Ethereum provides a decentralised
Corda nodes is point-to-point and the transaction history is Turing-complete machine, namely the Ethereum Virtual
fully encrypted and private to only necessary parties [17]. Machine (EVM), to execute scripts using an international
Smart contracts running on Corda are allowed to consist of network of public compute nodes [19]. On Ethereum, peo-
both code and legal prose [146]. The associated legal prose ple can use programming languages, e.g., Solidity11 and
could be referred back to traditional legal systems in case of Vyper,12 to develop complex smart contract applications.
legal disputes in smart contract performance. A smart con- All smart contracts written in high-level languages would
tract in Corda has three key elements, namely executable be compiled to the same format, i.e., Ethereum bytecode,
code, state objects, and commands [119]. The executable and be executed by the EVM. Ethereum also has its own
code mainly validates the changes to state objects in transac- cryptocurrenty, namely Ether. Ether can be transferred
tions. State objects are data that record the existence, content between accounts and used to compensate participants who
and current state of an agreement between two or more par- mine blocks for computations performed [19].
ties, and work as input or output of transactions. Com- Gas. Ethereum adopts an internal pricing mechanism,
mands are additional data that are included within i.e., gas for all transactions running on it [19]. Gas is a mea-
transactions. They mainly describe what is going on and tell sure of how much computing resource a transaction would
the executable code the way to verify a transaction. All cost. People need to pay gas fee (in Ethers) for each transac-
smart contracts could be programmed in Kotlin or Java and tion they make; and a transaction would fail if it runs out of
could be compiled into Java Virtual Machine (JVM) gas. If users want to have their transactions mined by min-
bytecode. ers faster, they can choose to increase the gas price. By using
On-Chain and Off-Chain Smart Contracts. Due to the nature the gas mechanism, Ethereum is able to better allocate
of blockchain technology, smart contracts deployed on resources and mitigate spam on the network.
blockchains (i.e., on-chain smart contracts) generally need to
be executed and validated by each node, with all relevant
transactions being visible to the entire blockchain network. 8. http://neo.org/
This reduces the privacy of smart contracts. Further, for 9. http://www.hyperledger.org/
10. http://www.jpmorgan.com/global/Quorum
smart contracts especially those with complex computation, 11. http://github.com/ethereum/solidity
the transaction cost may be high (e.g., users need to pay gas 12. http://github.com/ethereum/vyper

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2087

Fig. 1. Overview of methodology design.

Trusted Execution Environment (TEE). To preserve the con- validate the findings of the interviews. We describe
fidentiality or privacy of smart contracts, some efforts are the details how we conduct the interview and survey
being made to integrate trusted execution environments below.
(TEEs) with blockchains [26], [46], [70]. A TEE is a secure
area of a main processor which ensures sensitive data to be 3.1 Interview
stored, processed, and protected in an isolated environment Protocol. In our study, we conducted semi-structured
called an enclave. Data inside an enclave could only be interviews [133]. Specifically, we began each interview
accessed by code residing in the same enclave. Within an with an introduction, a short explanation of our research,
enclave, both the code and data are protected by hardware and some demographic questions about the interviewee.
enforced access control policies. The operating system and Next, we used some open questions to guide the discus-
other applications are not able to tamper with or eavesdrop sion–some of them are listed in Table 1. The full list of
on the state of any application running inside the enclave open questions can be found at https://github.com/
unless the hardware is breached. There have been several SurfGitHub/smartcontractStudy/blob/master/
realizations of TEE, including Intel SGX (the most promi- interview_questions.pdf. These open questions probed
nent TEE technology today) [5], TrustZone [7], etc. By using our interviewees about their views on major differences
a TEE, one does not need to trust the host (which runs the between smart contract development and traditional soft-
blockchain code) of the enclave. ware development and their impacts, challenges involved
in performing various smart contract development activi-
ties, etc. Since the interview was semi-structured, we also
3 METHODOLOGY asked follow-up questions to dig deeper into our inter-
Fig. 1 shows the overview of our methodology design. view participant’s viewpoints when appropriate. At the
On the whole, our study includes two parts: a series of end of the interview, we asked the interviewee to provide
interviews with 20 expert developers to get insights into any other important information that we may have
smart contract development and a follow-up survey to missed during the interview.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2088 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

TABLE 1 TABLE 2
Open Interview Questions (Excerpt) Basic Information of Interviewees

ID Question ID General Exp. SC Exp. Role


1 What are the main differences between smart contract P1 21 0.7 CEO and Developer
development and traditional software development? P2 17 0.7 Architect
2 How do the differences affect your smart contract P3 15 2.8 CEO, Core developer of Ethereum
P4 15 2.0 Developer
development? P5 6 1.5 Developer
3 What practices do you often use to ensure code quality? P6 4 0.6 Research Assistant
4 What kind of tools do you often use to develop smart P7 9 1.5 Project Manager
contract? Are they useful enough? Why? P8 6 1.5 Developer
5 What is your way to debug/test smart contract? Any P9 6 0.8 Developer
problems encountered? P10 7 0.9 Tester
6 Do you think current programming languages are good P11 18 1.8 Developer
enough? Why? P12 22 2.0 CEO, Advisor, CTO
P13 15 0.6 Developer
P14 15 1.6 Blockchain speaker and trainer,
co-founder
We totally had 31 interviewee candidates (more details in P15 8 0.5 Developer, co-founder
Participant Recruitment below). During interviews, we fol- P16 7 1.5 Developer, Token Sale Advisor
lowed the methodology employed in [6], [134] to decide P17 15 0.8 Project Manager
when to stop interviewing, i.e., stopping interviews when P18 4 2.8 Designer
P19 9 1.5 Developer
saturation of findings was reached. Saturation is a widely- P20 8 0.3 Developer
used methodological principle in qualitative research [55],
[101], [106]. It is often taken to indicate that further data col- General Exp. and SC Exp. represent a participant’s experience in general soft-
ware development and smart contract development respectively (in years) till
lection or analysis are unnecessary based on the data that the time of interview.
have been collected or analyzed hitherto [124]. More specifi-
cally, if the collected data is considered already sufficient
and further data collection does not generate new informa- i.e., adding additional participants recommended by cur-
tion, then the sampling should not be continued [137]. rent participants. Finally, 31 persons agreed to participate in
Taking into account the findings in behavior and brain our interviews.
sciences which claim that “there is substantial variability in Data Analysis. For each interview, the audio recording was
experimental results across populations” [58], we made first transcribed into text. After that, the first author read the
sure to interview participants from different backgrounds transcripts and converted them into separate units each with
(as shown in Table 2) before deciding whether saturation coherent meaning. Then, we performed card sorting [135] to
had been reached. During each interview, the authors (who identify the categories from these units. Card sorting is a com-
conducted interviews) worked together to ask questions monly used technique that helps to derive categories from
and take notes. Upon finishing an interview, they would data [75], [76]. There are three types of card sorting, namely
compare their notes with previous ones to check whether closed card sorting with predefined categories for data, open
the interview was bringing any new insights. Finally, we card sorting with no predefined categories (i.e., the categories
stopped our interviews when we achieved saturation of the of open card sorting are totally derived from the data), and a
findings after we interviewed 20 people. hybrid card sorting which combines the previous two types
All interviews were performed remotely via Skype, [159]. Considering our study is an exploratory one with cate-
WeChat, or Google Hangouts, and were audio recorded gories (i.e., challenges of smart contract development) being
with the permission of participants. The average and stan- unknown in advance, we decided to adopt an open card sort-
dard deviation of the interview time were 52.34 and 15.74 ing process to analyze the interview data.
minutes, respectively. Table 2 shows the basic demo- Specifically, during card sorting, after a card was created
graphics of the interviewees. According to the table, the for each textual unit, the cards were then clustered into
interviewees had an average experience of 11.35 years in meaningful groups, with each group having a topic or a
general software development, and 1.27 years in smart con- theme. These groups, i.e., low-level subcategories, further
tract development by the time of interviews. Besides, they evolved into high-level categories. The results of such an
held various roles, including developers, testers, project open card sorting would let us obtain a hierarchical struc-
managers, architects, designers, CEO/CTO, research assis- ture of the categories. Four researchers including two non-
tants, and smart contract trainers. This to a large extent, authors were involved in the card sorting process. Each
guarantees the heterogeneity of those 20 persons. card was analyzed and verified by two researchers.
Participant Recruitment. We contacted potential partici- Through card sorting, we identified six high-level catego-
pants in multiple ways. We sent emails to smart contract ries, i.e., security, debugging, gas, programming language,
developers on GitHub. We also contacted some developers the Ethereum Virtual Machine, and online resources & com-
in well-known companies working on smart contract devel- munity support, with each category containing several sub-
opment such as ConsenSys,13 and OpenZepplin.14 Then, we categories (more details in Section 4).
expanded the initial group by using a snowball process [47],
3.2 Survey
13. https://new.consensys.net/ Design. Our survey includes a number of demographic
14. https://openzeppelin.org/ questions and smart contract questions. The demographic

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2089

questions are mainly designed to understand the back- blockchains; and the ratio of developers who mostly spent
ground and experience of respondents. Specifically, we cre- time on open source projects and closed source projects are
ated 8 demographic questions that ask respondent’s main 40.1 and 36.2 percent, respectively.
role (e.g., development, testing, etc.), experience in software Data Analysis. After we got all the responses from
engineering and smart contract development, country, respondents, we adopted different analysis methods for
highest educational qualification, and the kind of projects closed-ended and open-ended questions. Specifically, for
and blockchains they mainly work on. each closed-ended question, we counted the votes that went
The smart contract questions are designed to validate to each answer option. Then for each answer option, we cal-
insights that we got by analyzing the interviewee com- culated its vote ratio by dividing the number of votes for
ments. For each of the six categories (i.e., security, debug- the option over 232 (i.e., the number of all respondents).
ging, programming language, Ethereum virtual machine, While for the open-ended questions, we collected all the
gas, and online resources & community support) that we comments respondents made. Then we removed some com-
identified by analyzing our interview responses, we created ments that were either not meaningful (e.g., “Yes”) or not
a set of survey questions. In total, we created 27 questions. related to our research topic (e.g., “happy to help you with
For some of them, we asked respondents to rate statements your research”). After that, we tried to place the remaining
on a Likert scale of 1 to 5 (1 = strongly disagree, and 5 = comments into their corresponding categories obtained
strongly agree). For some others, we asked respondents to from the interview analysis. If a comment involved more
pick one or a few out of a number of options. Two of the than one category (e.g., belonging to both debugging and
questions were open-ended. The full list of our survey ques- security), then we split it into separate comments with each
tions can be found at http://github.com/SurfGitHub/ assigned to only one category. Whenever we present survey
smartcontractStudy. comments, we refer it as (S?), e.g., S5 refers to the fifth sur-
Survey Respondent Recruitment and Statistics. Our potential vey respondent.
survey respondents are developers who contributed to To better understand participants’ perspectives of smart
smart contract related projects on GitHub. To identify those contract development, we divided all survey respondents
projects, we first referred to the topic list15 of GitHub, and into different demographic groups, and compared their vot-
chose three topics that are most related with smart con- ing results towards various challenges and desired
tracts, i.e., Ethereum, Solidity and Truffle.16 Then we down- improvements mentioned by interviewees. Following prior
loaded all the repositories under these three topics. To studies [80], [89], we considered the following demographic
ensure that we did not miss any popular smart contract groups:
projects, we further used GitHub’s search API to get a list of
projects whose name, description or readme contain the key-  Respondents who are developers (Dev)
word “smart contract”. After that, we selected and manu-  Respondents who are testers (Test)
ally checked 1,000 smart contract related repositories that  Respondents who are project managers (PM)
have the most stars. For each repository, we obtained the e-  Respondents with high experience in general soft-
mail accounts by analyzing its commit logs. In the end, we ware development (>=10.0 years17) (seExpH)
had 4,466 distinct email addresses. Out of these, more than  Respondents with low experience in general soft-
2,590 developers were involved in multiple repositories. ware development (<=3.0 years17 ) (seExpL)
Then we randomly selected 2,000 smart contract developers  Respondents with medium experience in general
and sent our survey invitations to them through emails. In software development (remaining respondents with
two weeks time, we got 205 responses, with a response rate more than 3.0 but less than 10.0 years of experience)
of 10.2 percent. This response rate is similar to those (seExpM)
reported by prior studies [94], [118]. Besides GitHub devel-  Respondents with high experience in smart contract
opers, we also asked our friends in industry to help broad- development (>=2.0 years18) (scExpH)
cast our survey to their friends and colleagues who may be  Respondents with low experience in smart contract
interested to participate in our survey. With their help, we development (<=1.0 year18 ) (scExpL)
got another 27 responses from industry. In the end, we had  Respondents with medium experience in smart con-
232 responses from respondents coming from 48 countries. tract development (remaining respondents) (scExpM)
Among the 232 respondents, 81.9 percent respondents’  Respondents with advanced degree, e.g., Master,
main role is development; and 43.1 percent respondents Ph.D. (Adv)
have advanced degrees (e.g., Master, Ph.D.). The respond-
ents have different expertise in general software develop-
17. The threshold settings of 10 and 3 helped us obtain three exper-
ment and smart contract development: 32.8 percent of the
tise groups with roughly equal numbers of respondents–the numbers
respondents have >10 years of general software develop- of respondents with high experience (>=10 years), medium experience
ment experience, and 66.8 percent have >4 years of experi- (3-10 years) and low experience (<=3 years) in general software devel-
ence; 13.8 percent respondents have >2 years of smart opment were 76, 79, and 77, respectively).
18. As the first platform that supports general smart contract devel-
contract development experience, and 46.6 percent have >1 opment, Ethereum (released on July 30, 2015) was only about 3.0 years
year of experience. We found that 69.4 percent of the old by the time we conducted our survey. This indicated that even the
respondents mainly developed smart contracts on public most experienced developers would generally have no more than 3.0
years of experience in smart contract development. Taking this into
account, we chose 2 and 1 as thresholds in determining whether a
15. GitHub Topics list can be accessed at https://github.com/topics. developer has high experience (>=2 years), medium experience (1-2
16. http://truffleframework.com/ years), or low experience (<=1 year) in smart contract development.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2090 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

 Respondents without advanced degree (nAdv) dealing with money or money flows through code. People would of
 Respondents who mainly develop on public block- course have a high requirement on the code security because it
chains (pubBlk) controls their assets”.
 Respondents who mainly develop on non-public Irreversible Transactions. Unlike traditional software
blockchains (nPubBlk) development, users cannot recover any loss they experience
 Respondents who develop on both public and non- while making transactions on a blockchain based financial
public blockchains (bothBlk) system using smart contracts. Since smart contracts run on
For each demographic group, we calculated the number the blockchain (on which transactions cannot be reverted),
of respondents who said yes or (strongly) agree, as well as if you lose your money, you lose it forever. One developer
the number of respondents who said no or (strongly) dis- mentioned: “Smart contract development is very unforgiving in
agree, to individual challenges and desired improvements the sense that you might lose a lot of money and it is impossible to
(mentioned by interviewees), respectively. Then following get back. You know, we cannot revert any transactions on block-
[160], we adopted Fisher’s exact test [43] with Bonferroni chain” (P12).
correction [98] on these numbers to see whether one group Code Unmodifiable After Deployment. Code of smart con-
tended to vote differently from other group(s). Fisher’s tract cannot be changed after it has been deployed to the
exact test is a statistical significance test used in the analysis blockchain. Unlike traditional software, developers cannot
of contingency tables, which displays the frequency distri- provide a patch to fix a bug. As P9 stated: “Smart contracts
bution of the variables (i.e., the numbers of yes/(strongly) are fundamentally different than regular programming languages
agree and no/(strongly) disagree votes from each group in due to the blockchain. Once deployed, smart contracts are difficult
our study). It could assess whether the observed difference to change”.
between two proportions, e.g., the ratios of yes/(strongly)
agree votes from two groups, is statistically significant. Bon- 4.1.2 Hard to Guarantee Security
ferroni correction could help to control the family-wise error We found that 71.6 percent survey respondents agreed that
rate when conducting multiple comparisons. Section 4.7 it was difficult to guarantee the security of smart contacts
presents the detailed analysis results. during development. Based on our interviews, we were
able to uncover four major aspects of these difficulties.
4 FINDINGS Public Code Access. As highlighted by one interviewee, the
In this section, we first report our findings for each of the six code of smart contract (e.g., on Ethereum) is always publicly
categories that were identified by using open card sorting accessible. This means that anyone can try to exploit the
code, design an attack, and execute it. Also, as smart con-
on interview contents. Each category has several subcatego-
tracts deal with money, they are always under focus by
ries. For each subcategory, we pick some of the most mean-
attackers willing to exploit any loophole. Such reasons place
ingful comments and highlight some statistics that we
a great burden on smart contract developers who need to
derived based on our survey responses to highlight the gen-
secure their code from many potential attacks. One devel-
eralizability of the findings. Then we present the voting
oper mentioned: “Blockchain environment provides a kind of a
results of each demographic group towards those chal-
unique environment, because all of the code running on the eco-
lenges and desired improvements mentioned by interview- system is deployed publicly and is accessible to anyone. Anyone
ees, as well as relevant significance tests over these results. can exploit it and may conduct an attack if they find some security
Last, we provide a brief summary of our interview and sur- vulnerability within code. You need to think like a hacker and
vey results. defend your code. It is not easy to anyone” (P3).
Flaws in Compiler. Another factor that makes it hard to
4.1 Security guarantee code security lies in the compiler itself. Compared
4.1.1 High Requirement for Code Security with compilers for traditional programming languages,
Based on our interviews and survey, we found that there compilers for smart contracts are not mature enough. Many
was a very high emphasis on ensuring code security for security bugs have been found within smart contract com-
smart contracts. Security concerns bypass all other factors, piler.19 Also as the compiler is continually evolving, new
as highlighted by one survey respondent: “Contract security bugs may be uncovered in future which developers are not
concerns and operational security concerns when managing even aware of at present. As P4 stated: “People have discovered
deployed contracts (e.g., key management, contract artifact man- a list of security bugs within different compiler versions. I do not
agement) permeate all decisions” (S71). In our survey, we know what new bugs we may encounter within the compiler since
found that 75.0 percent respondents agreed to the assertion it still evolves. This is bad I mean, you risk your Solidity code at
that smart contract development has a much higher require- unseen flaws within future-version compiler”.
ment for code security than traditional software develop- Besides, as some survey respondents commented, the
ment. Based on the reasons highlighted by interviewees, we compiler changes constantly and does not always have back-
were able to find three major themes on why there was an ward compatibility, which makes it hard to ensure the cor-
increased focus on security in smart contract development: rectness of code especially for a long-running project. “Due
Sensitive Nature of Information Handled. Since smart con- to constant changes on compilers, backward compatibility usually
tracts often control and manage sensitive digital assets is a problem.” (S43) “Solidity changes very rapidly, and complains
(such as virtual currencies, token, digital art files, etc.), peo- that code that identifies itself as for an older compiler version uses
ple naturally show greater concern for its security, than
they do for traditional software. As P20 stated: “Developer is 19. https://solidity.readthedocs.io/en/develop/bugs.html

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2091

deprecated features that were current at that version. This means TABLE 3
that, for a long-running project, you either have to update your old Major Challenges of Testing Smart Contracts
contracts to new language versions (and have them not correspond
Challenge Votes
to the real, deployed code when you run tests), or you have to ignore
a screen full of warnings every time you build.” (S69) Difficult to consider all corner cases and scenarios 69.4%
Potential unseen flaws in compilers and virtual machines 53.4%
Lack of Best Practices for Writing Safe Code. Many inter- No mature testing frameworks like other languages 40.5%
viewees highlighted the fact that it is harder for them to Testing needs to be done in an asynchronous way 31.0%
find coding and security best practices for smart contract Lack of useful guidance for testing 28.0%
development than for traditional software development. As No tool to measure the quality of smart contract test suite 22.4%
Testing consumes gas if tested on testnets or mainnet 22.4%
mentioned by several interviewees, there are efforts by
organizations such as ConsenSys, to constantly develop and
organize some common best practices to help developers in
writing safe code. P2 mentioned, “ConsenSys wrote quite a testing they conducted and what kinds of code coverage
good guide on smart contact best practices. We would always they used, then we asked the potential challenges they faced
check its update and tend to adopt them”. However, developers during smart contract testing. We verified their answers in
said that such efforts still fall short of meeting the require- the survey. Our survey results show that 84.9 percent devel-
ments of smart contract application development. One opers conducted unit testing, 61.6 percent developers per-
interviewee mentioned, “ConsenSys or one of the big compa- formed integration testing, and 25.4 percent developers
nies doing smart contracts may have that best practices. I can’t performed performance testing. The most code coverage
find it as an independent developer. When I develop something used by them was function coverage (with 68.1 percent
new, I just cannot find any best practice that help me to make it votes); the statement, branch, and condition coverages were
safe. So I am gonna do with whatever I think is the best” (P13). less preferred with 37.1, 34.1, and 35.8 percent developers
Lack of Tools/Techniques to Verify Code Correctness. In tradi- mentioning that they used them, respectively.
tional software development, developers could use various Despite the small/medium size of smart contract pro-
tools to help them ensure the quality of their code. Whereas gram,20 72.4 percent survey respondents agreed it was more
in smart contract development, many interviewees com- difficult to test smart contracts than traditional software
plained that there are no mature tools to verify the correct- projects. Table 3 presents the major challenges of testing
ness of smart contacts. Specifically, they mentioned two smart contract rated by survey respondents. The top three
kinds of tools that they desired most to better help guaran- challenges are: (1) developers need to consider all corner
tee code security: code auditing tools and formal verifica- cases and scenarios; (2) there exist potential unseen flaws in
tion techniques (49.1 and 42.2 percent survey respondents compilers and virtual machines themselves; (3) there are no
listed them as their most desired tools, respectively). mature testing frameworks like other languages, e.g., Java.
Code Review. 84.9 percent survey respondents agreed that
 Code auditing tools are the ones which can help devel- code review is an essential way to ensure the correctness of
opers to discover bugs, security breaches or viola- smart contacts. Our survey statistics do reflect that different
tions of programming conventions. As P1 stated: kinds of reviews are performed in reality: 83.6 percent
“There are no reliable code auditing tools to help you do a respondents said they would often perform peer code
comprehensive analysis of smart contract code. I hope we review within team; 26.3 percent respondents said they
can have such tools to help us analyze the code, and tell us would often request help in GitHub for code review; and
whether there are some potential bugs, security problems, 27.2 percent developers said they would often hire third
or convention violations”. party agency to audit their code.
 Formal verification techniques ensure the security of Meanwhile, compared to traditional software develop-
code because they are based on mathematical proof. ment, some interviewees mentioned that it is more costly to
Some interviewees and survey respondents said that perform code reviews for smart contracts. They mentioned
they hoped more research work can be done. As one two major challenges of code review that were also verified
survey respondent stated: “Mature and robust formal by our survey results. One challenge is that it is very time
verification tools would be a godsend; code coverage can consuming to conduct code review (agreed by 66.4 percent
only get you so far in terms of correctness. Call for formal of respondents). One developer commented, “Within our
verification” (S128). company, all members of our team participate in the code review.
We sit together, read and sometimes discuss code line by line. It is
4.1.3 Current Best Practices for Security indeed good for improving code quality, but it is too time con-
As writing secure code is one of the major focus of develop- suming” (P8).
ing smart contract applications, we asked developers what The other challenge is that it is very difficult to find quali-
steps they followed to ensure security in face of a number of fied developers to find security flaws in smart contracts
challenges. Interviewees mentioned that testing and code (agreed by 80.2 percent respondents). One survey respondent
review are their major ways to ensure the correctness of commented that you cannot find people help you unless you
smart contracts, which are discussed in details below. pay them: “It’s hard to find another developer to test or even read
Testing. As P11 stated: “To ensure the quality of smart con-
tract, I think one best practice is to mostly make heavy use of unit
20. After exploring the size of source code from 10000+ smart con-
testing”. To better understand the situation of smart contract tracts on Ethereum, we found that more than half smart contract have
testing in practice, we asked interviewees what kinds of <300 code lines.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2092 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

your smart contract without spending extra funds. I think develop-  17.2 percent respondents of our survey mentioned
ers that involved in open-source, should help each other” (S32). that they would often request the help of GitHub
community or other developers through some
4.2 Debugging forums, e.g., Stack Overflow, when they encounter
bugs.
4.2.1 Debugging Is Painful
All aforementioned debugging practices, as some inter-
During our interviews, most participants complained that it viewees mentioned, are “very primitive and very inefficient”
is more painful to debug smart contract code compared to (P7). They hope that in the future, the community can
traditional software development. In our follow-up survey develop some powerful debugging tools and can help
with developers, 88.8 percent survey respondents also developers to find “an easy way to quickly visualize the effects
agreed that it is difficult to debug smart contract applica- of a smart contract, such as a particular execution, such as show-
tions. In our semi-structured interviews, two main catego- ing the call graph for a smart contract in a solidity dependency
ries of debugging challenges came up, which were also graph format, and allowing you to highlight a particular section,
given as answer options to developers during our survey. debug just the execution section. I think things like that would
The categories are briefly described below: make an enormous difference” (P11).
Lack of Powerful Interactive Debuggers. As smart contract
development is a very recent technology, there is a lack of
powerful debuggers in this domain. As one interviewee 4.3 Programming Language
explained, “Current debuggers, e.g., Remix, can only provide 4.3.1 Limitations of Solidity
bytecode level debugging (which requires high skills of developers) Unlike traditional software which are developed in mature
and basic interactions, you cannot use it to e.g., visualize the general-purpose programming languages (e.g., Java/
memory state, step through the code line by line and check the cur- Python), most smart contracts are developed in specifically-
rent values of variables” (P1). 69.0 percent survey respondents designed programming languages (e.g., Solidity). Through
also agreed that there is a lack of powerful interactive our survey, we found that the programming languages
debuggers, which makes debugging painful and challeng- themselves are a major barrier during smart contract devel-
ing during smart contract development. opment. 39.7 percent of our survey respondents, agreed
Non-Informative Error Messages. Some interviewees high- that this is one of the top 3 concerns. There are several spe-
lighted the fact that apart from the lack of debugging tools, cific programming languages (e.g., Solidity, Vyper, Bam-
Solidity (the language used for smart contract development) boo21) that can be used for smart contract development.
and EVM (the run time environment used for smart con- However, as P12 stated: “Only Solidity is ready for production
tracts) have a poor support for displaying informative error and used by many developers, others are still under experiments”.
messages. One interviewee explained, “Solidity cannot sup- In practice, even Solidity has issues, as mentioned by some
port people to e.g., print error messages in code. Instead, we can interviewees. Since it has emerged only in the last 3 years, it
only use events or throw exceptions to track the state of the trans- is still not mature and has many limitations. Based on our
actions” (P19). EVM in some cases does not even provide survey and interviews, we found that the major limitations
support to display error messages for certain failures such of Solidity include:
as when a transaction fails. This was highlighted by one of Lack of General Purpose Libraries. Based on our survey sta-
the interviewee who said, “Sometimes when transactions fail, tistics, 56.9 percent survey respondents said that they often
EVM even cannot throw out the exception” (P2). In that case, reuse existing libraries for their own development. How-
developers totally have no idea what went wrong. ever, 77.2 percent respondents agreed that the existing
libraries are not enough for smart contract development.
4.2.2 Current Debugging Practices Some interviewees and respondents said they need to
implement various kinds of libraries (such as string manip-
As highlighted in previous section, there is a lack support
ulation libraries) by themselves again and again. “There is a
for debugging for smart contract development; we were
strong need for a well-tested (ideally: verified) standard library for
curious to explore if smart contract developers follow cer-
smart contract development. The current state leads to reinvent-
tain practices while debugging their code. Based on our
ing-the-wheel over and over again for simple things such as string
interviews and survey results, we summarize the current
manipulation.” (S105)
debugging practices followed by smart contract developers
Lack of Support for Error Logging/Reporting. Unlike other
below :
traditional programming languages, Solidity does not sup-
 In our survey, 65.1 percent respondents said that port direct printing (or logging) of errors, thus developers
they use existing debugging tools, e.g., Remix or face a lot of challenges in developing and debugging smart
truffle debugger, to debug buggy code. However, contracts. As one developer opined, “In terms of the language,
another 65.1 percent respondents mentioned that I think if a few features such as error reporting is available,
they often manually comment out code step-by-step that will make a big difference to ease the developments in the
to narrow down buggy code search space. future” (P11).
 56.5 percent respondents mentioned that they would Lack of Standards/Rules. Several interviewees mentioned
often write additional methods/events to check vari- that there is a scarcity of standard/rules (e.g., like the
ables and transaction states. This can be attributed to ERC20 token standard interface) which can serve the whole
the fact that existing tools do not support checking
variable values and transaction states. 21. http://github.com/pirapira/bamboo

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2093

development community. P3 mentioned: “Providing stan- TABLE 4


dard interface (such as the ERC20 for token), is even more impor- Improvements Developers Would Most Like to Have in Solidity
tant than providing general purpose libraries. We lack standards
Improvement Votes
in this field currently”.
Lack of Safety Checks for Data Types. Two interviewees More general purpose libraries 53.0%
More powerful error logging/reporting functions 48.7%
mentioned that Solidity does not provide a good check for More standard interfaces (e.g., ERC20) 45.7%
the safety of data types. P14 stated: “Solidity does not do well Better support for security checking of data types 44.8%
in checking the safety of data types. The compiler does not help More convenient and secure way to call external functions 35.8%
you enough. We cannot rely on the compiler to let us know there More powerful memory management 18.1%
Loosen the limited number of global and local variables 13.4%
could be a bug here”.
I think Solidity is good enough 6.5%
Inconvenient Way to Call External Functions. Many Others 5.6%
interviewees mentioned that passing parameters to
call external functions is odd, e.g., a developer cannot
directly pass his/her own defined structure to the func-
4.4 Ethereum Virtual Machine (EVM)
tion, instead, he/she should split them and pass them
one by one. P17 stated: “In solidity, struct is only recognized 4.4.1 Limitations of EVM
within a smart contract. If Solidity can create a way of packag- Unlike traditional software which run on mature and well-
ing the struct in a transportable sort of data structure that tested virtual machines like JVM and CLR, smart contracts
would be useful”. on Ethereum blockchains are executed by a relatively new
Lack of Support for Memory Management. One interviewee virtual machine, namely Ethereum Virtual Machine. Com-
mentioned that Solidity allocates memory in an invisible pared to traditional VM like JVM, the current EVM has sev-
way that you cannot control. This makes it difficult for eral limitations. Our survey results show that 35.3 percent
developers to develop smart contract in a resource con- of respondents voted that limitations of the current EVM to
strained environment. “Solidity disguises some of the underly- be one of the top-3 major challenges that prevent them from
ing operations of what you’re doing more than I would prefer effectively developing smart contracts. Four main limita-
personally, so sometimes you can do things in Solidity that tions of EVM mentioned by our interviewees are as follows:
appeared simple but actually resulted in conflicts underlying state Limited Support for Debugging. When failures happen,
changes or more work than you would expect. It does things like developers need help to know where, why, and how their
allocate memory invisibly and you have no control over that, so in code fails. Unfortunately, the support of debugging features
a resource constrained environment sometimes that can be less that can provide this needed information is limited in EVM.
than ideal.” (P11) For example, although EVM supports throwing exceptions,
Constrained Number of Local Variables. Some interviewees no informative error messages are given to developers, thus
said that Solidity supports a limited number of local varia- giving no clues on what might be the root cause of the prob-
bles and to solve this problem, developers need to use more lem. As commented by a developer, “You can only throw
state variables, which affects the efficiency of code. “If a exceptions in code. But actually, when your transactions fail in
function uses more than 16 local variables, it cannot be compiled. EVM, sometimes even the exceptions cannot be thrown. In that
So you may have to use state variables; but they are slow to read case, we totally have no idea what is going on” (P2).
and write as they are stored in the storage rather than in the stack Lack of Support of Traditional Languages. Popular program-
or memory. If you do not want to lose program efficiency, you ming languages (e.g., Rust or Python) are not supported by
may have to refactor your code.” (P8) EVM. EVM instead only supports languages such as Solidity
and Vyper, which are newly invented by the smart contract
community. Thus, developers’ familiarity with popular pro-
4.3.2 Most Desired Solidity Improvements gramming languages may not be applicable for those EVM-
To help the community solve the limitations that developers supported languages, incurring considerable amount of
are most concerned about, we asked each survey respon- learning cost. “I am familiar with Python. It is really good. Is it
dent to select up to 3 improvements that they would like to possible for EVM to support python-like language?” (P6)
see in Solidity. Since it is not possible to cover all limitations Inefficiency of Bytecode Execution. Execution of bytecode in
by interviews, we provide an “Other” text option that EVM is not speedy due to its design to be single-threaded,
allows respondents to fill relevant improvements they according to our interviewees. To mitigate this problem,
would like to have, which did not come out during inter- developers have to find ways to execute bytecode more effi-
views. Besides, we provide an “I think Solidity is good ciently by themselves. “EVM is a single-threaded machine that
enough” option for answer completeness. cannot run transactions in parallel. I mean it is inefficient in exe-
Table 4 shows the votes. In Table 4, we observe that only cuting bytecode. This may be a big problem for people who have a
6.5 percent of the survey respondents agreed that Solidity is higher requirement on the timely reaction and verification of their
good enough. Most developers’ concerns are mainly transactions. And this further makes developers’ life harder.” (P4)
focused on the availability of libraries (including general Limited Stack Size. The EVM is a stack machine and all the
purpose libraries (with 53.0 percent votes) and some stan- computations are performed on an area called the stack.
dard interfaces (with 45.7 percent votes)), error reporting The stack has a maximum size of 1,024 items with each item
functions (with 48.7 percent votes), data type checking having a size of 256 bits. This limited stack size could make
(with 44.8 percent votes), and better way to call external it very painful for developers to code their smart contracts.
functions (with 35.8 percent votes). One interviewee said that even a slightly complex smart

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2094 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

TABLE 5 that they (often) paid attention to gas consumption when


Improvements that Developers Would developing smart contracts. According to our interviewees,
Like to Have the Most in EVM two reasons for why gas consumption is specially important
Better support for debugging 65.5% are as follows:
Improve execution speed of byte code 31.9% Gas is Money. One interviewee explained that, on public
Loosen the stack size limit 27.6% blockchain platforms like Ethereum, all the resources that a
Ability to support traditional languages 26.7% smart contract used would translate into actual direct costs
I think EVM is good enough 12.5% that need to be paid by users in terms of gas. In other words,
Others 9.6% “Gas is money for users” (P1), thus developers need to be
much more conscious on resource consumption. “Contracts
for the Ethereum blockchain have to be executed under very tight
contract would easily reach the limit of the stack. In this constraints. All the resources they used would translate into
case, a considerable amount of work is required to redesign actual direct costs.” (P11)
the code. “We once developed a relatively complex application, Transaction Failure Due to Insufficient Amount of Gas. Some
that application could not be compiled only because we have an interviewees mentioned that on EVM, if a transaction of
additional temporary arguments in code...To solve this problem, smart contract is not given sufficient amount of gas, the
we had to split one function into several small functions, which transaction might fail. Indeed, our survey results showed
makes the code very ugly.” (P1) that 35.3 percent of respondents often encountered transac-
tion failures caused by running out of gas. “You can specify
4.4.2 Most Desired Improvements for EVM how much gas your transaction is allowed to use; if your transac-
Next, we want to identify the most desirable improvements tion run out of gas, it would fail. I often met transaction failures
of EVM for which the community should focus more on. due to insufficient gas for my application.” (P6)
Our survey lists a number of EVM’s desirable improve-
ments (as shown in Table 5) derived from our initial inter- 4.5.2 Difficulty in Handling Gas Problems
views. From this list, our survey respondents can select the
In our survey, 63.4 percent respondents agreed that gas
improvements that they desire the most. In addition to the
optimization is always painful, especially for complex
four predefined choices given to respondents, we also pro-
applications. According to our interviewees, two aspects
vided an “Other” option to allow survey respondents to
that contribute to difficulties in performing gas optimization
propose complementary improvements that they wish to
are as follow:
have.
No Gas Estimation Tool at Source Code Level. Developers
Table 5 depicts EVM improvements options given to
often desire to write and optimize source code rather than
respondents and their popularity among respondents’
bytecode, because it is more intuitive when working at
choices. The results suggest that better support for debug-
source code level. Unfortunately, there currently exists no
ging is desired the most (65.5 percent of survey respondents
gas estimation tool for source code. To optimize their source
pick this improvement), followed by improvement in execu-
code with respect to gas consumption, developers thus
tion speed of bytecode (31.9 percent). The ability to support
have to alternatively resort to available gas estimation tools
other programming languages is desired by 26.7 percent of
at bytecode level (such as Remix22), which may not fully
respondents. Interestingly, although many of our interview-
reflect the effect of changes at source code. This approach is
ees initially wish EVM to loosen stack size limit, it is desired
hence not intuitive and error-prone, rendering it difficult
by only 27.6 percent of the respondents in the survey.
for developers to perform source code optimization. “We
Respondents that are satisfied with current features that
only have bytecode level dynamic gas estimation tools. What we
EVM offers only made up of 12.5 percent of total votes.
do right now to optimize code, is to modify the code and run the
modified program, and try to compare the gas consumption with
4.5 Gas the previous program before modified. It is very time consuming
Some interviewees mentioned that one significant differ- to do this actually.” (P2)
ence between smart contract development and traditional A high demand on effective source-code-level gas esti-
software development lies in the gas mechanism. The gas mation tools is mentioned by a majority of our interviewees.
mechanism is unique to smart contract development, where Such tools, which can directly identify the piece of source
the execution of smart contracts would cost gas and users code that is most gas costly, would be of tremendous value,
need to pay the gas fee. As a result, developers need to pay according to interviewees. “We have a bad need in gas estima-
special attention to gas consumption during smart contract tion tools. Ideally, I hope we can have a tool that does not need to
development. Some interviewees also mentioned some dif- compile your code and can tell you how much gas each source
ficulties they encountered in handling gas problems. code line costs.” (P1)
Tradeoff between Gas Optimization and Code Readability.
4.5.1 Special Attention to Gas Consumption According to our interviewees, optimizing gas without
As mentioned in Section 2, platforms like Ethereum use the hurting code readability is often a tricky problem. “If you
gas mechanism to control the executions of smart contracts. want to spend less gas, you have to make your code more efficient,
Majority of interviewees mentioned that gas consumption so shorter basically, have fewer instructions. But if you have fewer
deserves special attentions. This is also later validated in
our survey–86.2 percent of survey respondents declared 22. http://remix.ethereum.org

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2095

instructions, it tends to make your code less readable as well, so be better if it had more code examples. Truffle, when I used, it had
it’s a dilemma.” (P14) like ’hello world’, how to get say ’hello’ and had a smart contract,
smart token, and that’s all that had. There’s a lot of things people
4.6 Online Resource and Community Support are building with truffle, but they really had nothing, they didn’t
Some interviewees told us that for traditional software have a lot of examples for you to build up the truffle, for me these
development, we can get a lot of help online when we are really simple examples.” (P13)
encounter problems; while for smart contract development,
the resource and mentors are scarce because “smart contract 4.6.2 Community Support
is very new on the blockchain” (P16). 22.8 percent of the survey Some interviewees said that although the community sup-
respondents voted that lacking enough online learning port for smart contract development is increasing, the sup-
resource and supportive community is one of the top-3 port is still limited. When they encounter some problems or
major challenges that prevent them from effectively devel- want to ask for some help to e.g., review their code, they
oping smart contracts. cannot easily find relevant developers. One of them men-
tioned, “Since the technique is new, the community is still in
4.6.1 Online Learning Resources development. Sometimes you cannot get timely help from the com-
After analyzing the interview and survey results, we find munity when you get stuck” (P16). Another interviewee P13
developers mainly mentioned three kinds of online learning commented, “if you go on code review for a javascript or python,
resources that are missing, i.e., reference code, standardized you will get lots of people who give you feedback, but in Solidity,
knowledge, and up-to-date documentations. you got no feedback. As a hobby developer, we rely on the commu-
Lack of Reference Code. Some interviewees told us that nity to give us feedback and code review, and if you don’t have
since there are not enough online reference code to reuse, that, we’re gonna do whatever we think is right”.
when they build new smart contract applications, they have
to build them from scratch. “So I programmed a lot in python 4.7 Survey Results
and c++ and javascript, and they all have frameworks, they all Table 6 lists 28 challenges and desired improvements men-
have lots of code. The solidity has nothing to test your code on. If I tioned by interviewees in the above Sections 4.1, 4.2, 4.3, 4.4,
want to do something new, there was nothing on the internet like 4.5, and 4.6. C1 to C6 were six major challenges on the whole
that, I had to invent it, I feel like from scratch.” (P13) of smart contract development. C7 to C17 were challenges
Lack of Standardized Knowledge. One survey respondent developers were facing during different stages (e.g., coding,
commented that no strict standardized knowledge can testing, debugging) of smart contract development. I18 to
guide developers to write better code in an easier way. I28 represented desired improvements of Solidity and
“Chaotic non standardized knowledge. i.e., no strict standards EVM, respectively. The last column of Table 6 is the number
(even though there are recommendations-erc). Community inten- (ratio) of respondents who voted for the corresponding
tionally (scam) or unintentionally allow bugs that are later challenges or desired improvements. For challenges/
exploited. Basically not mature enough approaches.” (S92) improvements with “(top-3)”, the values represented how
One interviewee highlighted the importance of coding many respondents rated them as one of the top-3 challenges
convention and best practices. “What’s missing is, when or desired improvements. For example, 166 (71.6 percent)
you write python code there are code standards, and I didn’t out of 232 respondents rated C1 as one of top-3 challenges
find anything like that for Solidity. I don’t know what best (out of six) during their smart contract development.
practices are for code, and so even if I want it to follow them As the overall voting results of individual challenges or
I couldn’t.” (P13) desired improvements have been mentioned in Sections 4.1,
Some interviewees think we should have guides to help 4.2, 4.3, 4.4, 4.5, and 4.6, here we mainly focus on analyzing
developers better test their smart contracts, and as shown in the voting results of different demographic groups towa-
Table 3, 22.4 percent survey respondents consider the lack rds these 28 challenges and desired improvements (c.f.,
of testing guidance as a major testing challenge. “I do not Section 3.2 for a description of the methodology that we
know what is the best way to do testing, there is no testing guid- follow). Table 7 shows the detailed voting results.
ance that I can follow.” (P10) From Table 7, we could observe that the voting results
Lack of Up-to-Date Documentations. Some interviewees varied from demographic groups. For example, for C2, the
mentioned that documentations are often out-of-date due to ratios of scExpM and scExpL were 57.9 and 58.1 percent
the quick evolution of relevant tools. Such outdated docu- while the ratio was only 34.4 percent for group scExpH.
mentation often make developers feel helpless to make full Another example, for C3, the ratios of Dev, Test, and PM
and correct use of the tools. “Right now you have documenta- were 38.4, 83.3, and 47.6 percent, respectively. To check
tion about Truffle, about Solidity, about web3, about testrpc. whether the observed ratio differences are statistically sig-
They’re all separate, they are all evolving at different speeds, and nificant, for each challenge/desired improvement, we
they are not updated as fast as they could. In the end, developers applied Fisher’s exact test with Bonferroni correction on
need to use all those tools together, and yet the documentation is five sets of demographic groups, i.e., groups with different
really inconsistent and not always up-to-date.” (P14) roles (Dev versus Test versus PM), groups with different
One interviewee suggested that it is necessary to enrich experience in general software development (seExpH ver-
the documentation for some important tools (such as Truf- sus seExpM versus seExpL), groups with different experi-
fle), e.g., by trying to provide more code examples of some ence in smart contract development (scExpH versus
medium and complicated applications. “I think Truffle would scExpM versus scExpL), groups with different education

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2096 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

TABLE 6 the relevant difference is statistically significant. They are


28 Challenges and Desired Improvements scExpM versus scExpL on C6 (p-value=0.002<0.05/3
(Mentioned by Interviewees) with Survey Voting Results
after Bonferroni correction), pubBlk versus nPubBlk on I24
ID Challenges/Desired improvements #Votes (Ratios) (p-value=0.006<0.05/3 after Bonferroni correction),
and Adv versus nAdv on I28 (p-value=0.038<0.05,
Major challenges on the whole (top-3)
Bonferroni correction is not needed for the single test).
C1 It is hard to guarantee the security of smart 166 (71.6%)
Based on the testing results, we can say with some cer-
contracts.
C2 There is a lack of powerful tools (e.g., 127 (54.7%) tainty that:
debugger, testing framework).
C3 Current programming languages have a 92 (39.7%)  Developers with low experience in smart contract
number of limitations. development (scExpL) are significantly more likely
C4 The Ethereum virtual machine that runs 82 (35.3%) to rate C6 (limited online learning resource and com-
smart contracts have a number of munity help) as a major challenge they are facing
limitations.
C5 It is hard to handle performance problems. 79 (34.1%)
during smart contract development, than those with
C6 Online learning resources and community 53 (22.8%) median experience (scExpM) (32.3 percent versus
support are limited. 13.2 percent).
Challenges of debugging, gas  Developers who mainly worked on non-public
optimization, and code review blockchains desired I24 (loosening the limited num-
C7 It is difficult to debug during smart contract 206 (88.8%) ber of global and local variables of Solidity) more,
development. than those mainly working on public blockchains
C8 Doing gas optimization is always painful 147 (63.4%)
(pubBlk) (37.5 percent versus 9.9 percent).
especially for complex applications.
C9 It is hard to find qualified developers to find 186 (80.2%)  Developers without advanced degree (nAdv) desi-
security flaws in smart contract code. red I28 (EVM’s support for traditional programm-
C10 Code review of smart contracts is very time 154 (66.4%) ing languages) more than those with an advanced
consuming. degree (nAdv) (32.1 percent versus 19.8 percent).
Challenges of testing (top-3)
C11 Difficult to consider all corner cases and 161 (69.4%) 4.8 Summary of Results
scenarios. Through the analysis of interview and survey data, we
C12 Potential unseen flaws in compilers and 124 (53.4%) could find that:
virtual machines.
C13 No mature testing frameworks like other 94 (40.5%)  Smart contract has a high requirement for code secu-
languages, e.g., Java.
rity. However, developers currently have no effective
C14 No tools to measure the quality of smart 72 (31.0%)
contract test suite. way to assure code security; some tools like code
C15 Testing needs to be done in an 65 (28.0%) auditing and formal verification techniques are highly
asynchronous way. desired. Currently, developers mainly used testing
C16 Testing consume gases if tested on testnets 52 (22.4%) and code reviews to help ensure code correctness.
or mainnet.
C17 Lack of useful guidance for testing, e.g., best 52 (22.4%)
 Current debugging tools are primitive and inefficient,
practice, tutorials, etc. which makes debugging very painful in practice;
Desired improvements of Solidity (top-3) more powerful interactive debuggers which provide
informative error messages are badly needed.
I18 More general purpose libraries. 123 (53.0%)
I19 More powerful error logging/reporting 113 (48.7%)  Undesirable characteristics of Solidity language
functions. (e.g., difficulty in passing data to external func-
I20 More standard interfaces. 106 (45.7%) tions, limitations in the number of variables),
I21 Better support for security checking of data 104 (44.8%) compiler (backward compatibility and reliability
types.
issues due to rapidly changing compiler and its
I22 More convenient and secure way to call 83 (35.8%)
external functions. unseen flaws) and EVM (e.g., non-informative
I23 More powerful memory management. 42 (18.1%) error messages, limited stack size, inefficient exe-
I24 Loosen the limited number of global and 31 (13.4%) cution due to single-threaded EVM), make it very
local variables. challenging to program smart contracts effectively
Desired improvements of EVM and efficiently in practice.
I25 Better support in debugging. 152 (65.5%)  There is a need for source-code-level gas-estimation
I26 Improve execution speed of byte code. 74 (31.9%) and optimization tools that consider code readability.
I27 Loosen the stack size limitation. 64 (27.6%)  There is a lack of best practice, code examples, com-
I28 Be able to support other traditional 62 (26.7%)
languages. munity support, third-party libraries, and standards
for smart contract development.
degrees (Adv versus nAdv), and groups working on differ-
ent kinds of blockchains (pubBlk versus nPubBlk versus 5 FUTURE DIRECTIONS
bothBlk). 5.1 Security and Reliability of Smart Contracts
After conducting 392 (14 group pairs  28 challenges/ Developers perceive security to be critical to smart contracts.
improvements) Fisher’s exact tests with Bonferroni correc- Past reports highlight a wide range of vulnerabilities that
tions, we found that there were three tests showing that affect security of smart contracts, e.g., reentrancy bug [90],

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2097

TABLE 7
Voting Results of Different Demographic Groups Towards 28 Challenges and Desired Improvements Mentioned by Interviewees

ID Dev Test PM seExpH seExpM seExpL scExpH scExpM scExpL Adv nAdv pubBlk nPubBlk bothBlk
Total 190 6 21 76 79 77 32 76 124 101 131 161 16 55
C1 73.2 50.0 57.1 73.7 72.2 68.8 75.0 71.1 71.0 67.3 74.8 71.4 75.0 70.9
C2 54.7 66.7 52.4 59.2 49.4 55.8 34.4 57.9 58.1 60.4 50.4 52.8 75.0 54.5
C3 38.4 83.3 47.6 38.2 35.4 45.5 43.8 40.8 37.9 43.6 36.6 37.3 50.0 43.6
C4 34.7 33.3 42.9 35.5 32.9 37.7 46.9 34.2 33.1 35.6 35.1 36.0 25.0 36.4
C5 32.6 33.3 47.6 27.6 34.2 40.3 37.5 39.5 29.8 34.7 33.6 29.8 56.3 40.0
C6 21.1 16.7 42.9 27.6 13.9 27.3 9.4 13.2 32.3 21.8 23.7 22.4 25.0 23.6
C7 89.5 100.0 85.7 94.7 86.1 85.7 81.3 89.5 90.3 89.1 88.5 90.7 87.5 83.6
C8 62.6 50.0 61.9 67.1 57.0 66.2 46.9 67.1 65.3 67.3 60.3 60.2 81.3 67.3
C9 82.1 66.7 71.4 85.5 75.9 79.2 75.0 80.3 81.5 84.2 77.1 80.7 81.3 78.2
C10 65.3 50.0 66.7 63.2 68.4 67.5 78.1 67.1 62.9 67.3 65.6 70.2 62.5 56.4
C11 70.0 83.3 61.9 77.6 63.3 67.5 75.0 71.1 66.9 65.3 72.5 69.6 56.3 72.7
C12 53.7 66.7 61.9 43.4 60.8 55.8 53.1 55.3 52.4 48.5 57.3 50.3 56.3 61.8
C13 40.5 50.0 33.3 32.9 39.2 49.4 34.4 47.4 37.9 40.6 40.5 36.0 56.3 49.1
C14 31.1 0.0 33.3 32.9 24.1 36.4 28.1 30.3 32.3 32.7 29.8 26.1 37.5 43.6
C15 29.5 33.3 19.0 27.6 31.6 24.7 37.5 28.9 25.0 21.8 32.8 28.0 43.8 23.6
C16 24.7 16.7 19.0 21.1 25.3 20.8 18.8 25.0 21.8 22.8 22.1 21.1 25.0 25.5
C17 23.2 16.7 28.6 28.9 20.3 18.2 18.8 21.1 24.2 22.8 22.1 22.4 12.5 25.5
I18 51.1 50.0 85.7 52.6 50.6 55.8 59.4 51.3 52.4 52.5 53.4 50.9 56.3 58.2
I19 50.0 33.3 23.8 60.5 45.6 40.3 43.8 60.5 42.7 51.5 46.6 46.6 50.0 54.5
I20 47.4 16.7 57.1 44.7 49.4 42.9 53.1 42.1 46.0 43.6 47.3 47.2 31.3 45.5
I21 43.2 83.3 47.6 56.6 38.0 40.3 46.9 46.1 43.5 47.5 42.7 44.7 56.3 41.8
I22 35.8 33.3 42.9 34.2 32.9 40.3 21.9 30.3 42.7 37.6 34.4 31.7 43.8 45.5
I23 18.9 16.7 14.3 9.2 21.5 23.4 15.6 13.2 21.8 14.9 20.6 18.6 6.3 20.0
I24 12.1 33.3 9.5 5.3 10.1 24.7 6.3 18.4 12.1 17.8 9.9 9.9 37.5 16.4
I25 66.8 66.7 61.9 73.7 58.2 64.9 65.6 63.2 66.9 69.3 62.6 60.9 68.8 78.2
I26 31.6 66.7 28.6 27.6 26.6 41.6 34.4 31.6 31.5 31.7 32.1 30.4 56.3 29.1
I27 28.9 0.0 19.0 28.9 26.6 27.3 31.3 34.2 22.6 27.7 27.5 24.2 31.3 36.4
I28 26.8 33.3 23.8 18.4 27.8 33.8 21.9 22.4 30.6 19.8 32.1 26.7 18.8 29.1

The Total row represents the number of respondents each group has. The rows C1 to I28 represent the percentages (%) of respondents from each demographic
group who voted for 28 challenges and desired improvements; for example, the value 73.2 in the C1 row means that 73.2% respondents from the Dev group
(which has 190 respondents) rated C1 as one of top-3 major challenges they were facing during smart contract development.

etc. Since many developers working on smart contract devel- researchers have tried to use formal verification methods to
opment are new in the area, they may not be aware of these prove the correctness of smart contracts [4], [14], [61]. How-
vulnerabilities. There is also much code duplication in ever, these approaches are still not mature yet and have not
smart contracts [71]; copy-paste is a common development been demonstrated to scale to a large number of smart con-
method. By copy-and-pasting, vulnerable code can easily tracts of varying sizes.
“infect” other code. Thus, there is a need for tool supports to Program repairs have recently become more mature with
help developers not only to detect but also repair vulnerabil- industrial adoption. Facebook is now using automated pro-
ities to prevent them from “spreading” further. gram repair to fix its apps.24 Smart-contract specific repair
Relatively mature bug finding and automated code solutions can also be designed to automatically patch vul-
inspection tools exist for conventional software, e.g., Find- nerabilities in smart contract. Generic repair is very difficult;
bugs,23 Facebook INFER [20], etc.; however these tools are but what works very well in practice are patching specific
not able to be used to statically check and identify smart kinds of vulnerabilities. A novel program transformation
contract vulnerabilities. Existing tools that detect smart con- tool extending existing tools that work for C and Java, such
tact bugs, e.g., Oyente [90], are relatively new, and much as Coccinelle [111] or Spoon [115], can potentially be
more study is needed to demonstrate their efficacy in terms designed for Solidity. Next, required transformations can be
of low false positive and false negative rate. Such studies specified as semantic patches [104] and applied to patch
have been done for Findbugs, and other tools for conven- existing smart contracts that suffer from vulnerabilities.
tional software [120] but there are no similar studies yet for Developers also mentioned bugs in Solidity compiler.
smart contract tools. More testing, fuzzing, and concolic This is a serious issue since such bugs can translate to vul-
testing tools can also be designed to augment existing static nerabilities and unreliable executions of many smart con-
analysis tools to improve their efficacy. Besides, formal veri- tracts. More mature compilers like gcc have shown to be
fication is also of great demand to reduce the possible buggy [138] and compiler testing solutions have found
adverse impact of smart contract vulnerabilities. Some
24. https://code.fb.com/developer-tools/finding-and-fixing-
23. http://findbugs.sourceforge.net/ software-bugs-automatically-with-sapfix-and-sapienz/

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2098 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

many of such bugs. There is a need for a further study to 5.2.2 Better Resource Management
demonstrate the extent existing compiler testing solutions Smart contract developers need to optimize for gas and effi-
can work to identify bugs in Solidity compilers and design ciency while constrained with stack size, number of local var-
steps to adapt the solutions for them to be more effective for iables, etc. This makes it harder for developers to focus on
Solidity. designing cool new features. Manual optimization of these
Developers are also in need for best practices and considerations also pose other issues (e.g., readability). Thus,
code smells that may prevent them from introducing new support to help developers optimize for gas considering
vulnerabilities. Systematic literature review and catalog- the various constraints is needed. Current solution only pro-
ing of such vulnerabilities is one first step. Designing vides estimate for bytecode but developers may need support
common repositories to store common vulnerabilities for source code and developers may also need recommenda-
specific to smart contact-in similar fashion like CVE25–is tions on ways to optimize code. Solutions that can automati-
another step. Operationalizing CVE into tools, e.g., [132] is cally and safely transform a code that is readable (to
yet another step. developers) but do not satisfy constraints into another code
that satisfy constraints (but is less readable) seamlessly may
also be in demand. These solutions are non-trivial and further
5.2 Other Factors Affecting Smart Contract
Development research is needed in these directions. Existing research on
program transformations, e.g., [91], [99], [141] can be a good
Aside from security, many other factors affect smart con-
starting point in designing these solutions.
tract development. Here, we highlight five different aspects
of smart contract development that pose open research
5.2.3 Library Construction
problems requiring advances in the field.
Developers are in serious need of libraries. The level of code
redundancies among deployed smart contracts is high–this
5.2.1 Programming Language and Virtual highlights that developers are reinventing-the-wheel often.
Machine Design This is not surprising as modern software are often built on
top of libraries–for example, libraries can comprise of more
Solidity and Ethereum VM are in their infancy and develop-
than 90 percent of a web application.26 Tools are needed to
ers often encounter difficulties in developing smart con-
identify reusable common components used in many smart
tracts due to their limitations (e.g., type checking, memory
contracts and organize them into easy-to-find and easy-to-
management, multi-threading support, etc.). These high-
use classes, methods, and libraries. Methods from clone
lights opportunities for research to add additional features
detection [72], [148] and code categorization [73], [102],
in Solidity and Ethereum VM. Additional consideration
[130] can potentially be employed to construct such librar-
needs to be put in the design of these features considering
ies. Security considerations need to also be considered in
specific constraints for smart contract and the unique way it
the construction of such libraries to ensure that vulnerabil-
is deployed and run in a distributed manner. For example,
ities do not spread through library dependencies, c.f., [36].
adding multi-threading support to Ethereum VM is non-
trivial. “A miner cannot simply execute these contracts in
parallel, because they may perform conflicting accesses to 5.2.4 Evolution, Maintenance, and Deployment of
shared data, and an arbitrary interleaving could produce an Smart Contracts
inconsistent final state.” [39] We have seen recent early As one developer mentions, once a smart contract is
work proposing these missing features, e.g., [33], [116], that deployed it is not possible for it to be modified. There are
require deep technical novelty as “porting” features from a workarounds to address the evolution of contracts (with
popular programming language (e.g., Java) to Solidity varying levels of difficulty and impact to users), such as by
and a popular VM (e.g., Java VM) to Ethereum VM are non- using detegatecall (i.e., separating data and logic of a smart
trivial. Existing proposed research solutions often have contract in separate contracts and letting the data contract
trade-off or introduce additional complexities that may pre- call the logic contract through delegatecall),27 or using a reg-
vent their adoptions; further research is needed to develop istry contract to store latest version of a contract,28 etc. How-
additional solutions that may consider other trade-offs to ever, no systematic study has been done on the advantages
help Ethereum VM and Solidity language designers/main- and disadvantages of different maintenance options. Fur-
tainers decide the most promising approach or direction ther study is needed to explore this and to possibly develop
that the community should take. These decisions need to be new maintenance, evolution, and deployment methods that
taken carefully as it will have long term implications. prevent smart contract evolution to adversely affect devel-
Another possible direction is to enable developers to opers and users.
code in their language of choice (or a restricted subset of Solidity API also changes frequently and are often not
that language) and allow their code to be translated to Solid- backward compatible. There are needs to help developers
ity. Recent research have explored ways to transform Java to evolve Solidity code to “catch up” with API evolution.
C# [107], [157]. There may also be solutions developed to
transform code written in languages such as Javascript 26. http://www.linkedin.com/pulse/how-can-you-ensure-your-
(which has a large developer base, and is similar to Solidity) open-source-components-secure-sharma/
to Solidity code. 27. http://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-
patterns/
28. https://ethereum.stackexchange.com/questions/2404/
25. http://cve.mitre.org/ upgradeable-smart-contracts?noredirect=1&lq=1

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2099

Studies are needed to explore if existing research solu- in our paper. (2) We allowed our survey respondents to
tions [57], [63] work well for Solidity API and if not, novels be anonymous; they are untraceable if they do not leave
solutions are needed. Developers also expressed their desire email addresses; and they can also leave new/anonymous
for up-to-date documentations for tools/languages they are email addresses. According to [110], confidentiality and
using. It would be valuable to find proper approaches that anonymity helped in obtaining un-biased answers from
can help automatically update or even generate documenta- survey respondents.
tion and link pieces of documentation from different sour- Besides, following the advice in [78], i.e., using the
ces on the internet. Ideas from exiting studies that proper language medium for intended respondents, we
recommending adaptive changes for documentation evolu- also translated our survey into Chinese to ensure that
tion [35] and detecting API documentation errors [156] may respondents from China can understand our survey ques-
help in this direction. tions well. We only have our survey in English and Chinese
since English is a lingua franca and Chinese is the most spo-
5.2.5 Supporting End-Users ken language in the world. During result analysis, similarly,
Smart contract technology has a great potential in the finan- it is also possible that we may draw wrong conclusions
about survey respondents’ perceptions based on their com-
cial domain while its development is still nascent. To facili-
ments. To alleviate this threat, we also tried to read the sur-
tate the widespread adoption of smart contracts in finance
vey comments several times.
industry, some big investment banks (e.g., European Bank
External Validity. Following the strategy of previous stud-
for Reconstruction and Development (EBRD)), International
ies [6], [134], we stopped our interviews when we reached
Swaps and Derivatives Association (ISDA), leading law
the saturation of findings after interviewing 20 persons (this
firms (e.g., Linklaters), as well as some researchers, have
been working to develop a set of best practice and industry- number was also similar as prior studies [60], [94]). We
wide standards in terms of the construction, execution, and have to admit that the notion of “saturation of findings”
validation of smart contracts from both legal and technical may introduce interviewer subjectivity and risk missing
perspectives [28], [29], [32], [65], [66]. Related to the construc- information. To avoid these problems, we tried to include
tion of smart contracts, a noticeable problem is that develop- two interviewers for each interview based on both inter-
ers of smart contracts may not be finance domain experts. viewees’ and interviewers’ schedules. In total, 15 out of the
20 interviews were conducted by two interviewers. They
There is a need to enable financial experts to write smart
worked together to take memos and asked questions during
contracts directly without intermediaries. Intermediaries
interviews. Having two interviewers could help us: (1) cap-
may introduce miscommunication and bugs [1]. Simplified
ture as much relevant information as possible during inter-
domain-specific languages have been designed for many
views (some information may be missed by single
areas, e.g., ABB have designed a simplified language to
enable end users to directly program robots with more interviewer), and (2) reduce the chance of unfair subjective
ease [131]. Similar solutions can also be designed for smart bias in the discussion of whether the saturation of findings
contract development. These solutions may involve design has been reached (we had a more comprehensive note for
of a specialized Domain Specific Language, text-to-code sol- comparison with previous interview notes, and by having
utions, program synthesis from examples, bots that can clar- multiple interviewers, collectively, we could better recall
ify requirements from financial experts, etc. Prior work have the details of what happened or what was discussed).
Considering there may exist other populations who
shown that these technologies are feasible for specialized
might add new insights, we also need to acknowledge that
domains [8], [150], but more effort needs to be invested in
the opinions provided by our interviewees may not be rep-
their design.
resentative of and agreeable to the whole community. To
reduce this threat, we ensured that our interviewees hold
6 THREATS TO VALIDITY various roles and have different levels of expertise, e.g.,
Internal Validity. In our paper, we designed our survey developers, trainers, CEOs in companies developing smart
questions based on the interview results. However, it is pos- contract applications, etc. We believe that their comments
sible that we may draw wrong conclusions from inter- still uncovered various insights into the challenges of smart
viewees’ comments. To alleviate this threat, we tried to read contract development.
the interview transcription several times; and each step of To validate our interview findings, we conducted a sur-
card sorting of interview comments was performed and ver- vey with 232 developers from 48 countries. As our respond-
ified by two researchers. Besides, before sending the ques- ents were mainly recruited through GitHub, we may risk
tions to our potential survey respondents, we conducted a ignoring some developers (e.g., from proprietary smart con-
pilot study in which we asked 5 developers to fill the survey tract development) who are unlikely or are not permitted to
and collected their feedbacks on the questions and answer respond to our survey. Thus we cannot guarantee that our
options. Refinement is subsequently made based on devel- findings could be generalized to all relevant smart contract
opers’ comments. practitioners. However, our respondents had different expe-
It is also possible that survey respondents may have pro- rience levels, educational qualifications, and contribute to
vided dishonest answers (e.g., saying what they want us to various projects (including open-source and close-source
hear or saying what we want to hear) due to various rea- projects) on different blockchain platforms (including pub-
sons. To help reduce this bias, we made the following lic and non-public blockchains). Such a diversity in back-
efforts: (1) In our survey invitation letter, we explicitly men- grounds to a large extent, made us believe that our survey
tioned that no personal information would be disseminated results still projected valuable insights into the challenges of

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2100 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

smart contract development. To further improve the gener- Unlike the above studies that mainly focus on perform-
alizability of our findings, we encourage other researchers ing empirical analyses on specific aspects of smart contracts
to replicate our study with more developers in the future. (e.g., specific application domains or security patterns), our
study explored the major challenges developers are facing
during smart contract development. Through interviews
7 RELATED WORK and a follow-up survey, we identified several major barriers
In this section, we highlight related work on smart con- that prevent developers from effectively developing smart
tract, including empirical studies on smart contract, tools contracts.
developed for smart contract, and studies on challenges Tools for Smart Contract. Various kinds of tools have been
and opportunities in other domains outside of smart proposed to resolve smart contract related problems, rang-
contract. ing from detecting bugs [4], [50], [61], [90], guarding data
Empirical Studies on Smart Contract. The rapid growth of privacy/quality [123], [154], to easing smart contract crea-
smart contract development motivated a series of empirical tion [44], [97] and manual analysis [15], [158].
studies. These studies mainly aimed to explore the charac- Due to the nature of smart contracts, bugs tend to be
teristics and potential impact of smart contracts [11], [69], costly, thus substantial efforts have been made to detect vul-
summarize development patterns or lessons [37], [151], nerabilities of smart contracts or to prove the correctness of
evaluate existing programming languages and techniques smart contracts. Luu et al. developed Oyente to identify sev-
[53], [112], propose some feasible strategies for smart con- eral pre-defined kinds of security bugs (such as transaction
tract programming and altering/undoing [1], [64], [96], etc. order dependency) [90]. Nikolic et al. developed MAIAN to
Bartoletti et al. studied the application domains and identify greedy, prodigal, and suicidal smart contracts
design of 834 verified smart contracts from Bitcoin and [108]. Liu et al. developed ReGuard to detect reentrancy
Ethereum [11]. Fr€ owis et al. investigated the problem of con- bugs through fuzz testing [87]. Chen et al. and Grech et al.
trol flow immutability of smart contacts on Ethereum [45]. attempted to identify gas-related problems [22], [23], [50].
Bartoletti et al. analyzed how smart contract can be used to Marescotti et al. further proposed two approaches inspired
implement Ponzi schemes on Ethereum [9] while Juels et al. by model-checking techniques to compute the exact worst-
mentioned the feasibility of performing criminal activities case gas consumption for smart contracts [95]. Chen et al.
on Ethereum, e.g., leaking secret documents [69]. proposed a method to detect potential Ponzi schemes on
Delmolino et al. summarized some common mistakes Ethereum [24]. Tsankov et al. developed Securify to detect
that students made during smart contract programming several kinds of security bugs by inspecting whether or not
classes and provided a guide to help people avoid those smart contract behavior violated certain semantic patterns
mistakes [37]. By applying grounded theory into collected derived from control- and data-flow dependencies within
smart contract data, Wohrer et al. summarized some secu- smart contract [143], [144]. Grishchenko et al. and Grossman
rity patterns and corresponding solutions [151]. Unterweger et al. tried to detect vulnerabilities through reachability
et al. presented some lessons they learned during their analysis [51] and effective-callback-free objects detection
implementation of a privacy-preserving smart contract in [54]. Jiang et al. developed ContractFuzzer to detect security
the energy domain [145]. vulnerabilities through generating fuzzing inputs and
Parizi et al. did an evaluation of usability and security of instrumenting EVM [67]. Liu et al. attempted to predict
smart contract programming languages [112]. They also did potential vulnerabilities by identifying irregular token
an assessment over existing smart contract testing techni- sequences [88]. Tikhomirov et al. developed SmartCheck to
ques on Ethereum [113]. Grishchenko et al. did an overview detect potential problems by checking against XPath pat-
of various static analysis tools that can be applied to smart terns [142]. Krupp et al. developed TEETHER to automati-
contracts, covering formal semantics, security definitions, cally generate an exploit for a smart contract given its
and verification tools [53]. Miller et al. provided an over- binary code [81]. Wang et al. proposed a random based and
view of existing smart contract languages and tools for ana- a NSGA-II based multi-objective approach to generate cost-
lyzing smart contracts; they also presented some research effective test suites for smart contracts [149]. They further
challenges for formal verification methods and program explored the potential of applying mutation testing into
analysis applied to smart contracts [100]. smart contracts [84], [153].
Idelberger et al. studied the utility of logic-based smart To prove the correctness of smart contracts, some
contracts and explored how they could be used in block- researchers proposed to use formal verification methods to
chains [64]. Sergey and Hobor suggested to use existing for- perform complete analysis of smart contracts by using inter-
mal methods to reason about concurrency of smart contract active theorem provers [4], [13], [14], [61], [109], such as
[128]. Marino and Juels developed a set of standards for Isabelle/HOL,29 F*,30 Why3 [42], and K,31 etc. Recently,
altering and undoing smart contacts [96]. Khalil et al. sug- Grishchenko et al. has formalized a complete small-step
gested that more attention being paid to the traditional semantics of EVM bytecode for the F* proof assistant [52].
developers (i.e., the lawyers) of contracts [1]. Clack et al. Rosu et al. also developed KEVM, a formal semantics of the
argued that a formal language which handles over-the- EVM in the K framework [25], [121]; and further evaluated
counter financial smart contract derivatives needs to com-
bine temporal, deontic and operational aspects for such a
formalism [31]. Destefanis et al. called for a definition of 29. Isabelle. http://isabelle.in.tum.de/
30. F*. https://www.fstar-lang.org/
blockchain software engineering to help solve/avoid some 31. K Framework. http://www.kframework.org/index.php/
smart contract issues [38]. Main_Page

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2101

its effectiveness in verifying EVM smart contracts [59], Unlike the above studies which aimed to develop specific
[114]. Sergey et al. proposed a verification framework based tools/techniques for smart contract, we focused on identify-
on Scilla (an intermediate representation languages specifi- ing major challenges developers are facing during smart
cally designed for verification) to apply formal verification contract development. Our study also identified several
methods to reason about temporal properties of smart con- kinds of tools that developers desired most, such as
tracts [129]. Alt. et al. built an SMT-based formal verification advanced debuggers, source-code-level gas estimations,
module inside the Solidity compiler, where during com- advanced formal verification techniques, etc. Our study
pilation, users could get automatic warnings of and cou- provides a guide for tool builders to develop tools that are
nterexamples for several kinds of potential problems like needed by developers.
unreachable code, assertion failures, etc. [3]. Hirai used Studies on Challenges and Opportunities. There have been
Kripke models of the modal logic to check the atomicity several papers studying the challenges and corresponding
property of a protocol called “atomic cross-chain swap” opportunities in specific domains or software practices. Two
(expressed in a form of hashed timelock smart contracts) studies done by Porru et al. [117] and Lin et al. [86] are mostly
[62]. Besides formal verification, some researchers proposed related to our study. Porru et al. [117] studied the challenges
to abstract smart contacts to a certain form before conduct- and new directions of blockchain-oriented software engineer-
ing relevant verification tasks [50], [71]. ing, from defining new professional roles, enhancing security
To guard the quality or confidentiality of data and reliability, to developing novel tools for software archi-
involved in smart contract execution, Zhang et al. tecture/modeling, ensuring effective testing activities, etc.
designed a data feed system called Town Crier [154] to Their study mainly discussed some high-level challenges/
provide trusted input data for smart contracts and keep- directions in developing blockchain-oriented software,
ing data requests secret from others. S anchez and Cerezo including both blockchain platforms and general blockchain
proposed a system called Raziel to help securely execut- applications. Unlike their study, our work specifically stud-
ing smart contracts while guaranteeing their privacy, ied the challenges of smart contract (a special kind of block-
correctness, and verifiability [123]. Liang et al. proposed chain application) development from the practitioners’ view.
a framework called DESC to automatically control access Our study provided some concrete and actionable directions
in the domain of secure data exchange and protect data for both researchers and practitioners to take on to facilitate
owners’ rights [85]. the development of smart contracts. Lin et al. [86] briefly
To ease smart contract creation, Frantz and Nowostawski summarized some issues and challenges that people need to
proposed to semi-automatically create smart contracts by concern when trying to embrace the blockchain technologies,
translating textual contract into smart contract rules [44]. e.g., regulations problems, scale of blockchain problems, etc.
Mavridou et al. proposed a framework called FSolidityM to Unlike them, we did not study the adoption of blockchain
allow developers to design smart contract as Finite State itself; instead, we focused on exploring the challenges and
Machines [97]. Schrans et al. invented a programming lan- opportunities of developing smart contracts which run on
guage called Flint introducing caller capabilities, and safe blockchain platforms.
atomic operations [125]. Seijas et al. explored the design of Zhang et al. did a survey of cloud computing technology
Marlowe, a domain specific language targeted at financial and presented some design challenges of cloud computing
contracts on blockchains, together with examples of its use; [155]. Similarly, Dillon et al. presented several challenges
they further described a tool, called Meadow, that allows from the cloud computing adoption perspective and figured
users to interact with and simulate the operations of Mar- out that the cloud interoperability issue deserved substan-
lowe contracts [126]. Valliappan et al. combined Simplicity tial attention [40]. Kephart [74] outlined some scientific and
(a language for programming smart contracts with a formal engineering challenges of autonomic computing. Labrinidis
semantic) with a categorical model, to facilitate the addition and Jagadish discussed some controversies and myths sur-
of local definitions, functions, and bounded loops [147]. Bar- rounding big data and summarized some challenges and
toletti et al. designed a high-level domain specific language opportunities with big data [82]. Manferdelli listed some
with a computationally sound compiler, namely BitML, for challenges and opportunities during software development
Bitcoin smart contracts. BitML creates smart contracts in the based on many-core computing [93].
form of symbolic expressions, then compiles these expres- Knight summarized some challenges and directions in
sions to Bitcoin scripts [10], [12]. To help people better developing safety critical systems [79]. Broy studied
understand and analyze smart contracts, Brent et al. pro- the challenges in automotive software engineering [18].
posed a framework called Vandal that decompiled EVM Muccini et al. [103] and Joorabchi et al. [68] explored rele-
bytecode and allowed developers to analyze bytecode via vant challenges in software testing and software develop-
logic specification [16]. Zhou et al. developed Erays to gen- ment of mobile applications respectively. Hilton et al.
erate high-level pseudocode from binary code of smart con- investigated the barriers and unmet needs faced by devel-
tracts [158]. Bragagnolo et al. developed SmartInspect opers during their adoption of continuous integration sys-
which allowed users to understand contract stored state tems [60]. Gousios et al. studied work practices and
without redeploying a smart contract [15]. Additionally, challenges in pull-based development from both the con-
Dickerson et al. proposed a way to allow smart contracts to tributor’s and integrator’s perspective [48], [49]. Kim et al.
be executed in parallel by adapting techniques from soft- did an empirical study to understand refactoring challenges
ware transactional memory [39]. Colombo et al. developed and benefits at Microsoft [77].
CONTRACTLARVA to recover smart contract from viola- Unlike these studies, we explored challenges and oppor-
tions dynamically [34]. tunities of a new topic, i.e., the development of smart

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2102 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

contracts. We summarized six major categories of chal- [8] D. W. Barowy, S. Gulwani, T. Hart, and B. Zorn, “FlashRelate:
Extracting relational data from semi-structured spreadsheets
lenges and further identified some potential research direc- using examples,” in Proc. 36th ACM SIGPLAN Conf. Program.
tions specific to the smart contract domain. Lang. Des. Implementation, 2015, pp. 218–228.
[9] M. Bartoletti, S. Carta, T. Cimoli, and R. Saia, “Dissecting Ponzi
8 CONCLUSION AND FUTURE WORK schemes on Ethereum: Identification, analysis, and impact,”
CoRR, vol. abs/1703.03779, 2017. [Online]. Available: http://
Smart contract, which originally refers to the automation of arxiv.org/abs/1703.03779
legal contracts in general, has recently seen much interest [10] M. Bartoletti, T. Cimoli, and R. Zunino, “Fun with Bitcoin smart
contracts,” in Proc. Int. Symp. Leveraging Appl. Formal Methods,
due to the rise of blockchain technology. Today, it is popu- 2018, pp. 432–449.
larly used to refer to low-level code scripts running on [11] M. Bartoletti and L. Pompianu, “An empirical analysis of smart con-
blockchains. In this study, we investigated the challenges tracts: Platforms, applications, and design patterns,” in Proc. 21st
Int. Conf. Financial Cryptography Data Security, 2017, pp. 494–509.
developers are facing in developing such smart contracts, [12] M. Bartoletti and R. Zunino, “BitML: A calculus for Bitcoin smart
especially focusing on the Ethereum platform. Our interview contracts,” in Proc. 25th ACM SIGSAC Conf. Comput. Commun.
and survey results indicate that smart contract development Security, 2018, pp. 83–100.
is still in its infancy: there is no generally accepted way to [13] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi,
G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-
secure smart contract code; the existing development tool- Pinote, N. Swamy, et al., “Formal verification of smart contracts:
chain is not powerful enough; development and runtime Short paper,” in Proc. Workshop Program. Lang. Anal. Security,
platforms (i.e., programming languages, virtual machines) 2016, pp. 91–96.
still have a lot of limitations; online learning resources and [14] G. Bigi, A. Bracciali, G. Meacci, and E. Tuosto, “Validation of
decentralised smart contracts through game theory and formal
community supports are limited. Based on our findings, we methods,” in Programming Languages with Applications to Biology
summarized some concrete and actionable directions in and Security. Berlin, Germany: Springer, 2015, pp. 142–161.
which researchers and practitioners could take on in the [15] S. Bragagnolo, H. Rocha, M. Denker, and S. Ducasse,
“Smartinspect: Smart contract inspection technical report,” PhD
future (e.g., automated smart contract patching, Solidity com- thesis, Lille, Department: Inria - National Institute for Research
piler testing, source-code-level gas optimization, automated in Computing and Automation, France: Inria Lille, 2017.
Solidity library construction, etc.). Progress in such directions [16] L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli,
would further facilitate smart contract development. R. Holz, and B. Scholz, “Vandal: A scalable security analysis
framework for smart contracts,” CoRR, vol. abs/1809.03981,
2018. [Online]. Available: http://arxiv.org/abs/1809.03981
ACKNOWLEDGMENTS [17] R. G. Brown, J. Carlyle, I. Grigg, and M. Hearn, “Corda: An
introduction,” R3 CEV, pp. 1–15, 2016. [Online]. Available: https://
We are grateful for the interview and survey participants docs.corda.net/_static/corda-introductory-whitepaper.pdf
who provided many insightful comments and answered [18] M. Broy, “Challenges in automotive software engineering,” in
our survey questions. We strongly thank the anonymous Proc. 28th Int. Conf. Softw. Eng., 2006, pp. 33–42.
[19] V. Buterin, “A next-generation smart contract and decentralized
reviewers for their constructive comments. The work is application platform,” White Paper, 2014.
partly supported by the National Key Research and Devel- [20] C. Calcagno and D. Distefano, “Infer: An automatic program ver-
opment Program of China (2018YFB1403400), the National ifier for memory safety of C programs,” in Proc. 3rd Int. Symp.
NASA Formal Methods, 2011, pp. 459–465.
Natural Science Foundation of China (61690201, 61772014), [21] T. Chen, X. Li, X. Luo, and X. Zhang, “Under-optimized smart
and the program B for Outstanding PhD candidate of Nanj- contracts devour your money,” in Proc. 24th Int. Conf. Softw.
ing University. Any opinions, findings, and conclusions in Anal. Evolution Reeng., 2017, pp. 442–446.
this paper are those of the authors only and do not necessar- [22] T. Chen, X. Li, Y. Wang, J. Chen, Z. Li, X. Luo, M. H. Au, and
X. Zhang, “An adaptive gas cost mechanism for Ethereum to
ily reflect the views of our sponsors. defend against under-priced DoS attacks,” in Proc. 13th Int. Conf.
Inf. Secur. Practice Experience, 2017, pp. 3–24.
REFERENCES [23] T. Chen, Z. Li, H. Zhou, J. Chen, X. Luo, X. Li, and X. Zhang,
“Towards saving money in using smart contracts,” in Proc. 40th
[1] F. Al Khalil, T. Butler, L. O’Brien, and M. Ceci, “Trust in smart Int. Conf. Softw. Eng.: New Ideas Emerging Results, 2018, pp. 81–84.
contracts is a process, as well,” in Proc. 21st Int. Conf. Financial [24] W. Chen, Z. Zheng, J. Cui, E. Ngai, P. Zheng, and Y. Zhou,
Cryptography Data Security, 2017, pp. 510–519. “Detecting Ponzi schemes on Ethereum: Towards healthier
[2] M. Alharby and A. van Moorsel, “Blockchain-based smart con- blockchain technology,” in Proc. 27th World Wide Web Conf. World
tracts: A systematic mapping study,” CoRR, vol. abs/1710.06372, Wide Web, 2018, pp. 1409–1418.
2017. [Online]. Available: http://arxiv.org/abs/1710.06372 [25] X. Chen, D. Park, and G. Roşu, “A language-independent
[3] L. Alt and C. Reitwiessner, “SMT-based verification of solidity approach to smart contract verification,” in Proc. Int. Symp.
smart contracts,” in Proc. Int. Symp. Leveraging Appl. Formal Meth- Leveraging Appl. Formal Methods, 2018, pp. 405–413.
ods, 2018, pp. 376–388. [26] R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson,
[4] S. Amani, M. Begel, M. Bortin, and M. Staples, “Towards verify- A. Juels, A. Miller, and D. Song, “Ekiden: A platform for confi-
ing Ethereum smart contract bytecode in Isabelle/HOL,” in Proc. dentiality-preserving, trustworthy, and performant smart con-
7th Int. Conf. Certified Programs Proofs, 2018, pp. 66–77. tracts,” IEEE Eur. Symp. Secur. Privacy, pp. 185–200, 2019.
[5] I. Anati, S. Gueron, S. Johnson, and V. Scarlata, “Innovative [27] C. D. Clack, “Smart contract templates: Legal semantics and code
technology for CPU based attestation and sealing,” in Proc. 2nd validation,” J. Digital Banking, vol. 2, no. 4, pp. 338–352, 2018.
Int. Workshop Hardware Architectural Support Secur. Privacy, 2013, [28] C. D. Clack, “Smart contract templates: The semantics of smart
vol. 13, pp. 1–7. legal agreements,” J. Digital Banking, vol. 2, no. 4, pp. 1–15, 2018.
[6] M. Aniche, C. Treude, I. Steinmacher, I. Wiese, G. Pinto, [29] C. D. Clack, V. A. Bakshi, and L. Braine, “Smart contract tem-
M.-A. Storey, and M. A. Gerosa, “How modern news aggregators plates: Foundations, design landscape and research directions,”
help development communities shape and share knowledge,” in CoRR, vol. abs/1608.00771, 2016. [Online]. Available: http://
Proc. 40th Int. Conf. Softw. Eng., 2018, pp. 499–510. arxiv.org/abs/1608.00771
[7] ARM, “Arm security technology–building a secure system [30] C. D. Clack and C. McGonagle, “Smart derivatives contracts: The
using trustzone technology,” ARM Technical White Paper, ISDA Master Agreement and the automation of payments and
2009. [Online]. Available: http://infocenter.arm.com/help/ deliveries,” CoRR, vol. abs/1904.01461, 2019. [Online]. Available:
topic/com.arm.doc.prd29genc009492c/PRD29%- http://arxiv.org/abs/1904.01461
GENC009492C_trustzone_security_whitepaper.pdf

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2103

[31] C. D. Clack and G. Vanca, “Temporal aspects of smart contracts [55] G. Guest, A. Bunce, and L. Johnson, “How many interviews are
for financial derivatives,” in Proc. Int. Symp. Leveraging Appl. For- enough? An experiment with data saturation and variability,”
mal Methods, 2018, pp. 339–355. Field Methods, vol. 18, no. 1, pp. 59–82, 2006.
[32] Clifford Chance and European Bank for Reconstruction and Devel- [56] P. Hegedus, “Towards analyzing the complexity landscape of
opment, “Smart contracts: Legal framework and proposed guide- Solidity based Ethereum smart contracts,” in Proc. 1st Int. Work-
lines for lawmakers,” pp. 1–52, 2017. [Online]. Available: https:// shop Emerging Trends Softw. Eng. Blockchain, 2018, pp. 35–39.
www.ebrd.com/documents/legal-reform/pdf-smart-contracts- [57] J. Henkel and A. Diwan, “CatchUp! Capturing and replaying
legal-framework-and-proposed-guidelines-for-lawmakers.pdf refactorings to support API evolution,” in Proc. 27th Int. Conf.
[33] M. Coblenz, “Obsidian: A safer blockchain programming Softw. Eng., 2005, pp. 274–283.
language,” in Proc. 39th Int. Conf. Softw. Eng. Companion, 2017, [58] J. Henrich, S. J. Heine, and A. Norenzayan, “The weirdest people
pp. 97–99. in the world?” Behavioral Brain Sci., vol. 33, no. 2/3, pp. 61–83,
[34] C. Colombo, J. Ellul, and G. J. Pace, “Contracts over smart con- 2010.
tracts: Recovering from violations dynamically,” in Proc. 8th Int. [59] E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu, P. Daian,
Symp. Leveraging Appl. Formal Methods Verification Validation, D. Guth, B. Moore, D. Park, Y. Zhang, A. Stefanescu, et al.,
2018, pp. 300–315. “KEVM: A complete formal semantics of the Ethereum Virtual
[35] B. Dagenais and M. P. Robillard, “Using traceability links to rec- Machine,” in Proc. 31st Comput. Security Found. Symp., 2018,
ommend adaptive changes for documentation evolution,” IEEE pp. 204–217.
Trans. Softw. Eng., vol. 40, no. 11, pp. 1126–1146, Nov. 2014. [60] M. Hilton, N. Nelson, T. Tunnell, D. Marinov, and D. Dig,
[36] A. Decan, T. Mens, and E. Constantinou, “On the impact of secu- “Trade-offs in continuous integration: Assurance, security, and
rity vulnerabilities in the npm package dependency network,” in flexibility,” in Proc. 11th Joint Meeting Found. Softw. Eng., 2017,
Proc. 15th Int. Conf. Mining Softw. Repositories, 2018, pp. 181–191. pp. 197–207.
[37] K. Delmolino, M. Arnett, A. Kosba, A. Miller, and E. Shi, “Step by [61] Y. Hirai, “Formal verification of Deed contract in Ethereum name
step towards creating a safe smart contract: Lessons and insights service,” pp. 1–81, Nov. 1, 2016. [Online]. Available: Available:
from a cryptocurrency lab,” in Proc. 20th Int. Conf. Financial Cryp- https://yoichihirai.com/deed.pdf
tography Data Security, 2016, pp. 79–94. [62] Y. Hirai, “Blockchains as Kripke models: An analysis of atomic
[38] G. Destefanis, M. Marchesi, M. Ortu, R. Tonelli, A. Bracciali, and cross-chain swap,” in Proc. Int. Symp. Leveraging Appl. Formal
R. Hierons, “Smart contracts vulnerabilities: A call for blockchain Methods, 2018, pp. 389–404.
software engineering?” in Proc. Int. Workshop Blockchain Oriented [63] A. Hora and M. T. Valente, “apiwave: Keeping track of API pop-
Softw. Eng., 2018, pp. 19–25. ularity and migration,” in Proc. 31st Int. Conf. Softw. Maintenance
[39] T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding Evolution, 2015, pp. 321–323.
concurrency to smart contracts,” in Proc. 36th Symp. Principles [64] F. Idelberger, G. Governatori, R. Riveret, and G. Sartor,
Distrib. Comput., 2017, pp. 303–312. “Evaluation of logic-based smart contracts for blockchain sys-
[40] T. Dillon, C. Wu, and E. Chang, “Cloud computing: Issues tems,” in Proc. 10th Int. Symp. Rules Rule Markup Lang. Semantic
and challenges,” in Proc. 24th Int. Conf. Adv. Inf. Netw. Appl., Web, 2016, pp. 167–183.
2010, pp. 27–33. [65] ISDA and King & Wood Mallesons, “Smart derivatives contracts:
[41] J. Eberhardt and S. Tai, “On or off the blockchain? Insights on off- From concept to construction,” pp. 1–28, 2018. [Online].
chaining computation and data,” in Proc. 6th Eur. Conf. Serv.- Available: https://www.isda.org/a/cHvEE/Smart-Derivatives-
Oriented Cloud Comput., 2017, pp. 3–15. Contracts-From-Concept-to-Construction-Oct-2018.pdf
[42] J.-C. Filli^
atre and A. Paskevich, “Why3—Where programs meet [66] ISDA and Linklaters, “Smart contracts and distributed
provers,” in Proc. 22nd Eur. Symp. Program., 2013, pp. 125–128. ledger—A legal perspective,” pp. 1–23, 2017. [Online].
[43] R. A. Fisher, “On the interpretation of x 2 from contingency Available: https://www.isda.org/a/6EKDE/smart-contracts-
tables, and the calculation of P,” J. Roy. Statistical Soc., vol. 85, and-distributed-ledger-a-legal-perspective.pdf
no. 1, pp. 87–94, 1922. [67] B. Jiang, Y. Liu, and W. Chan, “ContractFuzzer: Fuzzing smart
[44] C. K. Frantz and M. Nowostawski, “From institutions to code: contracts for vulnerability detection,” in Proc. 33rd Int. Conf.
Towards automated generation of smart contracts,” in Proc. 1st Autom. Softw. Eng., 2018, pp. 259–269.
Int. Workshops Found. Appl. Self* Syst., 2016, pp. 210–215. [68] M. E. Joorabchi, A. Mesbah, and P. Kruchten, “Real challenges in
[45] M. Fr€ owis and R. B€ ohme, “In code we trust?” in Proc. Int. Work- mobile app development,” in Proc. 7th Int. Symp. Empirical Softw.
shops Data Privacy Manage. Cryptocurrencies Blockchain Technol., Eng. Meas., 2013, pp. 15–24.
2017, pp. 357–372. [69] A. Juels, A. Kosba, and E. Shi, “The ring of gyges: Investigating
[46] H. S. Galal and A. M. Youssef, “Trustee: Full privacy preserving the future of criminal smart contracts,” in Proc. 23rd Conf.
vickrey auction on top of ethereum,” CoRR, vol. abs/1905.06280, Comput. Commun. Secur., 2016, pp. 283–295.
2019. [Online]. Available: http://arxiv.org/abs/1905.06280 [70] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, and
[47] L. Goodman, “Snowball sampling,” Ann. Math. Statist., vol. 32, E. W. Felten, “Arbitrum: Scalable, private smart contracts,” in
no. 1, pp. 148–170, 1961. Proc. 27th USENIX Security Symp., 2018, pp. 1353–1370.
[48] G. Gousios, M.-A. Storey, and A. Bacchelli, “Work practices and [71] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: Analyzing
challenges in pull-based development: The contributor’s safety of smart contracts,” in Proc. 25th Annu. Netw. Distrib. Syst.
perspective,” in Proc. 38th Int. Conf. Softw. Eng., 2016, pp. 285–296. Security Symp., 2018, pp. 1–15.
[49] G. Gousios, A. Zaidman, M.-A. Storey, and A. Van Deursen, [72] T. Kamiya, S. Kusumoto, and K. Inoue, “CCFinder: A multilin-
“Work practices and challenges in pull-based development: The guistic token-based code clone detection system for large scale
integrator’s perspective,” in Proc. 37th Int. Conf. Softw. Eng., 2015, source code,” IEEE Trans. Softw. Eng., vol. 28, no. 7, pp. 654–670,
pp. 358–368. Jul. 2002.
[50] N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and [73] S. Kawaguchi, P. K. Garg, M. Matsushita, and K. Inoue,
Y. Smaragdakis, “MadMax: Surviving out-of-gas conditions in “MUDABlue: An automatic categorization system for open
Ethereum smart contracts,” in Proc. ACM Program. Lang., 2018, source repositories,” J. Syst. Softw., vol. 79, no. 7, pp. 939–953,
pp. 14–18. 2006.
[51] I. Grishchenko, M. Maffei, and C. Schneidewind, “EtherTrust: [74] J. O. Kephart, “Research challenges of autonomic computing,” in
Sound static analysis of Ethereum bytecode,” Technische Proc. 27th Int. Conf. Softw. Eng., 2005, pp. 15–22.
Universit€ at Wien, Tech. Rep., pp. 1–41, 2018. [75] M. Kim, T. Zimmermann, R. DeLine, and A. Begel, “The emerg-
[52] I. Grishchenko, M. Maffei, and C. Schneidewind, “A semantic ing role of data scientists on software development teams,” in
framework for the security analysis of Ethereum smart contrac- Proc. 38th Int. Conf. Softw. Eng., 2016, pp. 96–107.
ts,” in Proc. 7th Int. Conf. Principles Secur. Trust, 2018, pp. 243–269. [76] M. Kim, T. Zimmermann, R. DeLine, and A. Begel, “Data
[53] I. Grishchenko, M. Maffei, and C. Schneidewind, “Foundations scientists in software teams: State of the art and challenges,”
and tools for the static analysis of Ethereum smart contracts,” in IEEE Trans. Softw. Eng., vol. 44, no. 11, pp. 1024–1038,
Proc. 30th Int. Conf. Comput. Aided Verification, 2018, pp. 51–78. Nov. 2018.
[54] S. Grossman, I. Abraham, G. Golan-Gueta, Y. Michalevsky, [77] M. Kim, T. Zimmermann, and N. Nagappan, “An empi-
N. Rinetzky, M. Sagiv, and Y. Zohar, “Online detection of effec- rical study of refactoringchallenges and benefits at Micro-
tively callback free objects with applications to smart contracts,” soft,” IEEE Trans. Softw. Eng., vol. 40, no. 7, pp. 633–649,
in Proc. ACM Program. Lang., 2017, vol. 2, pp. 1–28. Jul. 2014.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2104 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

[78] B. A. Kitchenham and S. L. Pfleeger, “Personal opinion surveys,” [103] H. Muccini, A. Di Francesco, and P. Esposito, “Software
in Guide to Advanced Empirical Software Engineering, Berlin, testing of mobile applications: Challenges and future research
Germany: Springer, 2008, pp. 63–92. directions,” in Proc. 7th Int. Workshop Autom. Softw. Test, 2012,
[79] J. C. Knight, “Safety critical systems: Challenges and directions,” pp. 29–35.
in Proc. 24th Int. Conf. Softw. Eng., 2002, pp. 547–550. [104] G. Muller, Y. Padioleau, J. L. Lawall, and R. R. Hansen,
[80] P. S. Kochhar, X. Xia, D. Lo, and S. Li, “Practitioners’ expecta- “Semantic patches considered helpful,” ACM SIGOPS Operating
tions on automated fault localization,” in Proc. 25th Int. Symp. Syst. Rev., vol. 40, no. 3, pp. 90–92, 2006.
Softw. Testing Anal., 2016, pp. 165–176. [105] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”
[81] J. Krupp and C. Rossow, “TEETHER: Gnawing at Ethereum to Working Paper, pp. 1–9, 2008. [Online]. Available: https://
automatically exploit smart contracts,” in Proc. 27th USENIX bitcoin.org/bitcoin.pdf
Security Symp., 2018, pp. 1317–1333. [106] L. R. Ness and P. I. Fusch, “Are we there yet? Data saturation
[82] A. Labrinidis and H. V. Jagadish, “Challenges and opportunities in qualitative research,” The Qualitative Rep., vol. 20, no. 9,
with big data,” The VLDB Endowment, vol. 5, no. 12, pp. 2032– pp. 1408–1416, 2015.
2033, 2012. [107] A. T. Nguyen, H. A. Nguyen, T. T. Nguyen, and T. N. Nguyen,
[83] C. Li, B. Palanisamy, and R. Xu, “Scalable and privacy-preserving “Statistical learning approach for mining API usage mappings
design of on/off-chain smart contracts,” CoRR, vol. abs/ for code migration,” in Proc. 29th Int. Conf. Autom. Softw. Eng.,
1902.06359, 2019. [Online]. Available: http://arxiv.org/abs/ 2014, pp. 457–468.
1902.06359 [108] I. Nikolic, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor,
[84] Z. Li, H. Wu, J. Xu, X. Wang, L. Zhang, and Z. Chen, “MuSC: A “Finding the greedy, prodigal, and suicidal contracts at scale,”
Tool for mutation testing of Ethereum smart contract,” in Proc. CoRR, vol. abs/1802.06038, 2018. [Online]. Available: http://
34th Int. Conf. Autom. Softw. Eng.-Demonstrations (Accepted), 2019, arxiv.org/abs/1802.06038
pp. 1–4. [109] T. Nipkow, L. C. Paulson, and M. Wenzel, “Isabelle/HOL: A
[85] J. Liang, W. Han, Z. Guo, Y. Chen, C. Cao, X. S. Wang, and F. Li, proof assistant for higher-order logic,” Springer, vol. 2283, 2002.
“DESC: Enabling secure data exchange based on smart contrac- [110] A. D. Ong and D. J. Weiss, “The impact of anonymity on
ts,” Sci. China Inf. Sci., vol. 61, no. 4, 2018, Art. no. 049102. responses to sensitive questions,” J. Appl. Social Psychology,
[86] I.-C. Lin and T.-C. Liao, “A survey of blockchain security issues vol. 30, no. 8, pp. 1691–1708, 2000.
and challenges,” IJ Netw. Security, vol. 19, no. 5, pp. 653–659, [111] Y. Padioleau, J. Lawall, R. R. Hansen, and G. Muller,
2017. “Documenting and automating collateral evolutions in Linux
[87] C. Liu, H. Liu, Z. Cao, Z. Chen, B. Chen, and B. Roscoe, device drivers,” ACM SIGOPS Operating Syst. Rev., vol. 42, no. 4,
“ReGuard: Finding reentrancy bugs in smart contracts,” in Proc. pp. 247–260, 2008.
40th Int. Conf. Softw. Eng. Companion, 2018, pp. 65–68. [112] R. M. Parizi, Amritraj, and A. Dehghantanha, “Smart contract
[88] H. Liu, C. Liu, W. Zhao, Y. Jiang, and J. Sun, “S-gram: Towards programming languages on blockchains: An empirical evalua-
semantic-aware security auditing for Ethereum smart contracts,” tion of usability and security,” in Proc. 1st Int. Conf. Blockchain,
in Proc. 33rd Int. Conf. Autom. Softw. Eng., 2018, pp. 814–819. 2018, pp. 75–91.
[89] D. Lo, N. Nagappan, and T. Zimmermann, “How practitioners [113] R. M. Parizi, A. Dehghantanha, K.-K. R. Choo, and A. Singh,
perceive the relevance of software engineering research,” in Proc. “Empirical vulnerability analysis of automated smart contracts
10th Joint Meeting Found. Softw. Eng., 2015, pp. 415–425. security testing on blockchains,” CoRR, vol. abs/1809.02702,
[90] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making 2018. [Online]. Available: http://arxiv.org/abs/1809.02702
smart contracts smarter,” in Proc. 23rd Conf. Comput. Commun. [114] D. Park, Y. Zhang, M. Saxena, P. Daian, and G. Rosu, “A formal
Security, 2016, pp. 254–269. verification tool for Ethereum VM bytecode,” in Proc. 27th Int.
[91] S. Ma, D. Lo, T. Li, and R. H. Deng, “CDRep: Automatic repair of Symp. Found. Softw. Eng., 2018, pp. 18–21.
cryptographic misuses in android applications,” in Proc. 11th [115] R. Pawlak, M. Monperrus, N. Petitprez, C. Noguera, and
ACM Asia Conf. Comput. Commun. Security, 2016, pp. 711–722. L. Seinturier, “Spoon: A library for implementing analyses and
[92] D. Magazzeni, P. McBurney, and W. Nash, “Validation and veri- transformations of Java source code,” Softw.: Practice Experience,
fication of smart contracts: A research agenda,” Comput., vol. 50, vol. 46, no. 9, pp. 1155–1179, 2016.
no. 9, pp. 50–57, 2017. [116] J. Pettersson and R. Edstr€ om, “Safer smart contracts through
[93] J. L. Manferdelli, N. K. Govindaraju, and C. Crall, “Challenges type-driven development,” Master’s thesis, Department of
and opportunities in many-core computing,” Proc. IEEE, vol. 96, Computer Science and Engineering, Chalmers University of
no. 5, pp. 808–815, May 2008. Technology and University of Gothenburg, Gothenburg, Swe-
[94] I. Manotas, C. Bird, R. Zhang, D. Shepherd, C. Jaspan, den, 2016.
C. Sadowski, L. Pollock, and J. Clause, “An empirical study of [117] S. Porru, A. Pinna, M. Marchesi, and R. Tonelli, “Blockchain-
practitioners’ perspectives on green software engineering,” in oriented software engineering: Challenges and new directions,”
Proc. 38th Int. Conf. Softw. Eng., 2016, pp. 237–248. in Proc. 39th Int. Conf. Softw. Eng. Companion, 2017, pp. 169–171.
[95] M. Marescotti, M. Blicha, A. E. Hyv€arinen, S. Asadi, and [118] T. Punter, M. Ciolkowski, B. Freimut, and I. John, “Conducting
N. Sharygina, “Computing exact worst-case gas consumption for on-line surveys in software engineering,” in Proc. 2nd Int. Symp.
smart contracts,” in Proc. Int. Symp. Leveraging Appl. Formal Meth- Empirical Softw. Eng., 2003, pp. 80–88.
ods, 2018, pp. 450–465. [119] R3, “Corda documents,” 2018. [Online]. Available: https://docs.
[96] B. Marino and A. Juels, “Setting standards for altering and undo- corda.net/
ing smart contracts,” in Proc. 10th Int. Symp. Rules Rule Markup [120] F. Rahman, S. Khatri, E. T. Barr, and P. Devanbu, “Comparing
Lang. Semantic Web, 2016, pp. 151–166. static bug finders and statistical prediction,” in Proc. 36th Int.
[97] A. Mavridou and A. Laszka, “Designing secure Ethereum Conf. Softw. Eng., 2014, pp. 424–434.
smart contracts: A finite state machine based approach,” [121] G. Roşu and T. F. Şerbanuţa, “An overview of the K semantic frame-
CoRR, vol. abs/1711.09327, 2017. [Online]. Available: http:// work,” J. Logic Algebr. Program., vol. 79, no. 6, pp. 397–434, 2010.
arxiv.org/abs/1711.09327 [122] C. Sanchez, G. Schneider, and M. Leucker, “Reliable smart con-
[98] J. H. McDonald, Handbook of Biological Statistics, vol. 2. Baltimore, tracts: State-of-the-art, applications, challenges and future
MD, USA: Sparky House Publishing, 2009. directions,” in Proc. Int. Symp. Leveraging Appl. Formal Methods,
[99] N. Meng, M. Kim, and K. S. McKinley, “LASE: Locating and 2018, pp. 275–279.
applying systematic edits by learning from examples,” in Proc. [123] D. C. Sanchez, “Raziel: Private and verifiable smart contracts on
35th Int. Conf. Softw. Eng., 2013, pp. 502–511. blockchains,” CoRR, vol. abs/1807.09484, 2018. [Online]. Avail-
[100] A. Miller, Z. Cai, and S. Jha, “Smart contracts and opportunities able: http://arxiv.org/abs/1807.09484
for formal methods,” in Proc. Int. Symp. Leveraging Appl. Formal [124] B. Saunders, J. Sim, T. Kingstone, S. Baker, J. Waterfield,
Methods, 2018, pp. 280–299. B. Bartlam, H. Burroughs, and C. Jinks, “Saturation in qua-
[101] J. M. Morse, “Data were saturated...,” Qualitative Health Res., litative research: Exploring its conceptualization and oper-
vol. 25, no. 5, pp. 587–588, 2015. ationalization,” Quality Quantity, vol. 52, no. 4, pp. 1893–1907, 2018.
[102] L. Mou, G. Li, L. Zhang, T. Wang, and Z. Jin, “Convolutional neu- [125] F. Schrans, S. Eisenbach, and S. Drossopoulou, “Writing safe
ral networks over tree structures for programming language proc- smart contracts in Flint,” in Proc. Conf. Companion 2nd Int. Conf.
essing,” in Proc. 30th AAAI Conf. Artif. Intell., 2016, pp. 1287–1293. Art Sci. Eng. Program., 2018, pp. 218–219.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
ZOU ET AL.: SMART CONTRACT DEVELOPMENT: CHALLENGES AND OPPORTUNITIES 2105

[126] P. L. Seijas and S. Thompson, “Marlowe: Financial contracts on [151] M. Wohrer and U. Zdun, “Smart contracts: Security patterns in
blockchain,” in Proc. Int. Symp. Leveraging Appl. Formal Methods, the Ethereum ecosystem and Solidity,” in Proc. Int. Workshop
2018, pp. 356–375. Blockchain Oriented Softw. Eng., 2018, pp. 2–8.
[127] P. L. Seijas, S. J. Thompson, and D. McAdams, “Scripting smart [152] G. Wood, “Ethereum: A secure decentralised generalised trans-
contracts for distributed ledger technology,” IACR Cryptology action ledger,” Ethereum Project Yellow Paper, vol. 151, pp. 1–32,
ePrint Archive, vol. 2016, 2016, Art. no. 1156. 2014.
[128] I. Sergey and A. Hobor, “A concurrent perspective on smart con- [153] H. Wu, X. Wang, J. Xu, W. Zou, L. Zhang, and Z. Chen,
tracts,” in Proc. 21st Int. Conf. Financial Cryptography Data Security, “Mutation testing for Ethereum smart contract,” arXiv e-prints,
2017, pp. 478–493. 2019.
[129] I. Sergey, A. Kumar, and A. Hobor, “Temporal properties of [154] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town
smart contracts,” in Proc. Int. Symp. Leveraging Appl. Formal crier: An authenticated data feed for smart contracts,” in Proc.
Methods, 2018, pp. 323–338. 23rd Conf. Comput. Commun. Security, 2016, pp. 270–282.
[130] A. Sharma, F. Thung, P. S. Kochhar, A. Sulistya, and D. Lo, [155] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing:
“Cataloging GitHub repositories,” in Proc. 21st Int. Conf. Eval. State-of-the-art and research challenges,” J. Internet Serv. Appl.,
Assessment Softw. Eng., 2017, pp. 314–319. vol. 1, no. 1, pp. 7–18, 2010.
[131] D. Shepherd, P. Francis, D. Weintrop, D. Franklin, B. Li, and [156] H. Zhong and Z. Su, “Detecting API documentation errors,” in
A. Afzal, “[Engineering Paper] An IDE for easy programming of Proc. 27th Int. Conf. Object Oriented Program. Syst. Lang. Appl.,
simple robotics tasks,” in Proc. 18th Int. Work. Conf. Source Code 2013, pp. 803–816.
Anal. Manipulation, 2018, pp. 209–214. [157] H. Zhong, S. Thummalapenta, T. Xie, L. Zhang, and Q. Wang,
[132] O. Sheyner and J. Wing, “Tools for generating and analyzing “Mining API mapping for language migration,” in Proc. 32nd Int.
attack graphs,” in Proc. 2nd Int. Symp. Formal Methods Components Conf. Softw. Eng., 2010, pp. 195–204.
Objects, 2003, pp. 344–371. [158] Y. Zhou, D. Kumar, S. Bakshi, J. Mason, A. Miller, and M. Bailey,
[133] F. Shull, J. Singer, and D. I. Sjøberg, Guide to Advanced Empirical “Erays: Reverse engineering Ethereum’s opaque smart contrac-
Software Engineering. Berlin, Germany: Springer, 2007. ts,” in Proc. 27th USENIX Security Symp., 2018, pp. 1371–1385.
[134] L. Singer, F. Figueira Filho, and M.-A. Storey, “Software engi- [159] T. Zimmermann, “Card-sorting: From text to themes,” in Perspec-
neering at the speed of light: How developers stay current using tives on Data Science for Software Engineering. Amsterdam, Nether-
Twitter,” in Proc. 36th Int. Conf. Softw. Eng., 2014, pp. 211–221. lands: Elsevier, 2016, pp. 137–141.
[135] D. Spencer, Card Sorting: Designing Usable Categories. San Francisco, [160] W. Zou, D. Lo, Z. Chen, X. Xia, Y. Feng, and B. Xu, “How practi-
CA, USA: Rosenfeld Media, 2009. tioners perceive automated bug report management techniques,”
[136] J. Stark, “Making sense of blockchain smart contracts,” CoinDesk, IEEE Trans. Softw. Eng., 2018, doi: 10.1109/TSE.2018.2870414.
Jun. 2016. [Online]. Available: https://www.coindesk.com/
making-sense-smart-contracts Weiqin Zou received the bachelor’s degree in
[137] A. Strauss and J. M. Corbin, Grounded Theory in Practice. software engineering and the master’s degree in
Thousand Oaks, CA, USA: SAGE, 1997. computer science from the Dalian University of
[138] C. Sun, V. Le, and Z. Su, “Finding and analyzing compiler warn- Technology, China, in 2010 and 2013, respec-
ing defects,” in Proc. 38th Int. Conf. Softw. Eng., 2016, pp. 203–213. tively. She is working toward the PhD degree in
[139] M. Swan, Blockchain: Blueprint for a New Economy. Newton, MA, the Software Institute, Nanjing University, China,
USA: O’Reilly Media, 2015. advised by Prof. Baowen Xu and Prof. Zhenyu
[140] N. Szabo, “Formalizing and securing relationships on public Chen. Her research interests include empirical
networks,” First Monday, vol. 2, no. 9, pp. 1–25, 1997. study and mining software repositories.
[141] F. Thung, X.-B. D. Le, D. Lo, and J. Lawall, “Recommending code
changes for automatic backporting of Linux device drivers,” in
Proc. 32nd Int. Conf. Softw. Maintenance Evolution, 2016, pp. 222–
232. David Lo received the PhD degree from the
[142] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev, School of Computing, National University of Sin-
E. Marchenko, and Y. Alexandrov, “SmartCheck: Static analysis gapore, in 2008. He is currently an associate pro-
of Ethereum smart contracts,” in Proc. 1st IEEE/ACM Int. Work- fessor with the School of Information Systems,
shop Emerging Trends Softw. Eng. Blockchain, 2018, pp. 9–16. Singapore Management University. He has more
[143] P. Tsankov, “Security analysis of smart contracts in datalog,” than 10 years of experience in software engineer-
in Proc. Int. Symp. Leveraging Appl. Formal Methods, 2018, ing and data mining research and has more than
pp. 316–322. 200 publications in these areas. He received the
[144] P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli, and Lee Foundation and Lee Kong Chian fellow for
M.Vechev, “Securify: Practical security analysis of smart contracts,” Research Excellence from the Singapore Man-
in Proc. 25th Conf. Comput. Commun. Security, 2018, pp. 67–82. agement University, in 2009 and 2018, and a
[145] A. Unterweger, F. Knirsch, C. Leixnering, and D. Engel, “Lessons number of international research and service awards including multiple
learned from implementing a privacy-preserving smart contract ACM distinguished paper awards for his work on software analytics. He
in Ethereum,” in Proc. 9th IFIP Int. Conf. New Technol. Mobility has served as general and program co-chair of several prestigious inter-
Security, 2018, pp. 1–5. national conferences (e.g., IEEE/ACM International Conference on
[146] M. Valenta and P. Sandner, “Comparison of Ethereum, Hyperledger Automated Software Engineering), and editorial board member of a
Fabric and Corda,” [ebook] Frankfurt School, Blockchain Center, pp. 1–8, number of high-quality journals (e.g., Empirical Software Engineering).
2017. [Online]. Available: https://pdfs.semanticscholar.org/00c7/
5699db7c5f2196ab0ae92be0430be4b291b4.pdf
[147] N. Valliappan, S. Mirliaz, E. L. Vesga, and A. Russo, “Towards Pavneet Singh Kochhar received the PhD
adding variety to simplicity,” in Proc. Int. Symp. Leveraging Appl. degree from Singapore Management University.
Formal Methods, 2018, pp. 414–431. He is a software engineer at Microsoft. During the
[148] P. Wang, J. Svajlenko, Y. Wu, Y. Xu, and C. K. Roy, “CCAligner: PhD, he completed an exchange programme at
A token based large-gap clone detector,” in Proc. 40th Int. Conf. Carnegie Mellon University. His research inter-
Softw. Eng., 2018, pp. 1066–1077. ests include empirical software engineering,
[149] X. Wang, H. Wu, W. Sun, and Y. Zhao, “Towards generating software testing, bug localization, and mining
cost-effective test-suite for Ethereum smart contract,” in Proc. software repositories. His research has been
26th Int. Conf. Softw. Anal. Evolution Reeng., 2019, pp. 549–553. published in several top-tier conferences and
[150] D. Weintrop, A. Afzal, J. Salac, P. Francis, B. Li, D. C. Shepherd, journals in software engineering.
and D. Franklin, “Evaluating CoBlox: A comparative study of
robotics programming environments for adult novices,” in Proc.
36th CHI Conf. Human Factors Comput. Syst., 2018, Art. no. 366.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.
2106 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 47, NO. 10, OCTOBER 2021

Xuan-Bach Dinh Le received the PhD degree Zhenyu Chen is a professor of Software Institute
from Singapore Management University, in 2018. in Nanjing University. His research interests are
He is currently a lecturer at The University of Mel- mainly the area of intelligent software engineer-
bourne Australia. Before that, he was a postdoc- ing. He is the founder of mooctest.net. He served
toral researcher at CyLab, Carnegie Mellon as the editor board of the IEEE Transactions on
University. His research interests span software Reliability Journal associate editor, the guest edi-
engineering and programming languages, includ- tor of the Journal of Systems and Software and
ing: software mining, empirical software engi- the SP&E Journal, the PC co-chair of QRS 2016,
neering, program analysis, repair, synthesis, and TSA 2016, QSIC 2013, AST 2013. He has pub-
verification. His research has been published in lished more than 100 papers in the leading aca-
several top-tier conferences and journals in soft- demic conferences and journals such as the
ware engineering. ACM Transactions on Software Engineering and Methodology, the IEEE
Transactions on Software Engineering, ICSE, FSE, ISSTA, ICST, etc.
He owns more than 40 patents (22 granted), and some of his patents
Xin Xia received both of the bachelor’s and PhD have been transferred into well-known software companies such as
degrees in computer science and software engi- Baidu, Alibaba and Huawei.
neering from Zhejiang University, in 2009 and
2014, respectively. He is a lecturer with the Fac-
ulty of Information Technology, Monash Univer- Baowen Xu received the bachelor’s, master’s,
sity, Australia. Prior to joining Monash University, and PhD degrees in computer science from
he was a post-doctoral research fellow with the Wuhan University, Huazhong University of Sci-
Software Practices Lab, University of British ence and Technology, and Beihang University, in
Columbia in Canada, and a research assistant 1982, 1985 and 2002, respectively. He is currently
professor at Zhejiang University in China. To help a professor with the Department of Computer Sci-
developers and testers improve their productivity, ence and Technology, Nanjing University. His
his current research focuses on mining and analyzing rich data in soft- major research interests are programming lan-
ware repositories to uncover interesting and actionable information. guages, software testing, software maintenance,
More information at: https://xin-xia.github.io/ and software metrics. He has published exten-
sively in premiere software engineering journals
and conferences such as the ACM Transactions on Software Engineering
Yang Feng received the bachelor’s and master’s and Methodology, the IEEE Transactions on Software Engineering, the
Journal of Systems and Software, the IEEE Transactions on Reliability,
degrees in software engineering from Nanjing
ICSE, FSE, ICSME, ICST, etc. He is a member of the IEEE.
University, in 2011 and 2013, respectively. He is
advised by Prof. Baowen Xu and Prof. Zhenyu
Chen, and his current research interests include
" For more information on this or any other computing topic,
software testing, debugging, program analysis,
mining software repositories, and program com- please visit our Digital Library at www.computer.org/csdl.
prehension. He also has a strong interest in
crowdsourcing techniques, especially crowd-
sourcing testing, debugging, and task assign-
ment strategies.

Authorized licensed use limited to: UNIVERSIDAD SAN FRANCISCO DE QUITO. Downloaded on October 24,2022 at 20:02:25 UTC from IEEE Xplore. Restrictions apply.

You might also like