A SYSTEMATIC MAPPING STUDY ON DEVELOPMENT OF BLOCKCHAIN-BASED SMART CONTRACTS

(1)

School of Innovation Design and Engineering

V¨

aster˚

as, Sweden

Thesis for the Degree of Master of Science in Computer Science with

Specialization in Software Engineering - 30.0 credits

A SYSTEMATIC MAPPING STUDY

ON DEVELOPMENT OF

BLOCKCHAIN-BASED SMART

CONTRACTS

William Nordberg

wng19001@student.mdh.se

Examiner: Federico Ciccozzi

M¨alardalen University, V¨aster˚as, Sweden

Supervisor: Saad Mubeen

M¨alardalen University, V¨aster˚as, Sweden

(2)

Acknowledgement

I would like to express my gratitude to the following people, without whom I would not finish this study or complete my master’s degree.

First, I want to express my heartfelt gratitude and admiration to my supervisor, Saad Mubeen, without whom this study would not have been possible. Saad has given me the academic freedom to undertake my thesis while ensuring that I do not stray from the study’s heart. His guidance and experience have been valuable throughout this journey. I would like to thank the professors at Malardalen University for their helpful advice and insightful recommendations, which have enriched my educational experience.

Last but not least, I would like to thank the people who shared this journey with me. Their support and motivation are greatly valued, despite the fact that they are bearing a huge burden of their own.

(3)

Abstract

Context - Blockchain-based smart contracts have drawn the attention of scientific com-munities and businesses in recent years. The development of blockchain-based smart con-tracts is different from the development of conventional software due to the blockchain characteristics such as immutability, trustlessness, being append-only, and being decen-tralized. Therefore, standard software engineering processes need to be adjusted to address the unique characteristics of blockchain.

Objective - This thesis aims to create a structured map of current research on the de-velopment of blockchain-based smart contracts, with a focus on identifying and classifying the development phases.

Method - To accomplish our objective, we carried out a systematic mapping study on blockchain-based smart contract development. Our search yielded 1257 potentially related studies that were subjected to a selection process. Subsequently, in the final set appeared 41 primary studies.

Result - Our main findings after analysis of the data are as follow: (i) researches mainly contribute to methods and providing tools, (ii) a large number of workshop papers indicate smart contracts’ high acceptance rate, (iii) there is a lack of research on the finalization as a development phase, (iv) there is no common or standard language for specifying smart contracts that are valid regardless of the blockchain platform, (v) the most com-mon language paradigm for smart contracts specification is imperative/declarative and for smart contracts implementation is declarative, (vi) the research community has put too much effort into the Ethereum blockchain, while it requires putting more attention to other blockchains, and (vii) there is a lack of studies tackling trustworthy oracle and scam chal-lenges.

conclusion - These results can benefit the research community to identify trends, con-straints, and research gaps. In addition, they share potential directions for future research.

(4)

4. Data extraction results 16 5. Results and evaluation 17 5.1 Results analysis of RQ1 . . . 17 5.2 Results analysis of RQ2 . . . 19 5.3 Results analysis of RQ3 . . . 20 5.4 Results analysis of RQ4 . . . 21 5.5 Results analysis of RQ5 . . . 22 6. Discussion 23 7. Threats to validity 25 8. Related work 27 8.1 Systematic mapping studies . . . 28

8.2 Systematic literature reviews . . . 30

8.3 Surveys . . . 30

9. Conclusions 31

References 36

Appendix A Primary studies 37

(5)

List of Figures

1 Simplified diagram of a blockchain . . . 4

2 Steps of the systematic mapping study [1] . . . 7

3 Process followed to conduct the review . . . 8

4 Percentage of obtained studies from databases . . . 9

5 Summary of the results of the different phases in StArt . . . 16

6 Quality assessment . . . 16

7 Publications trend per year . . . 17

8 Publications venues . . . 18

9 Distribution of publication types per year . . . 18

10 Contribution types . . . 19

11 Distribution of primary studies base on development phases . . . 19

12 Smart contract languages paradigms . . . 20

13 Blockchain platform mentioned in studies . . . 21

(6)

List of Tables

1 Blockchain and their consensus algorithms . . . 4

2 Search strings used in the different search engines . . . 10

3 Exclusion and inclusion criteria . . . 11

4 Categories for each study depends on their type and ranking . . . 11

5 Assessment of intrinsic information quality . . . 12

6 Assessment of contextual information quality . . . 12

7 Fields of data extraction form and related research question . . . 13

8 Contribution types . . . 13

9 Development phases . . . 14

10 Challenges in smart contracts [2] . . . 15

11 List of programming language names and paradigms in the primary studies 20 12 Summary of related work . . . 27

13 Number of extracted studies and research questions of mapping studies . . 29

(7)

List of Acronyms

SMS Systematic Mapping Study SLR Systematic Literature Review MMS Multivocal Mapping Study PoW Proof of Work

PoS Proof of Stake PoH Proof of History IQ Information Quality

(8)

1. Introduction

In 2008 an unknown person or a group of people known by the pseudonym Satoshi Nakamoto wrote a paper called “Bitcoin: A Peer-to-Peer Electronic Cash System” [3]. Satoshi Nakamoto did not mention the term blockchain in this paper but introduced the cryptocurrency Bitcoin as the first use case of a peer-to-peer network. This peer-to-peer network is currently named blockchain. In that paper, Satoshi proposed a solution to the double-spending problem using a peer-to-peer network. The risk of a digital currency spending twice is known as double-spending. The blockchain is a distributed database that records all transactions in a network that have ever taken place [4]. In current financial structures, transactions between parties are carrying in a centralized manner. This man-ner needs the presence of a trusted third party. It is becoming vital to find a way to make secure, automated business arrangements as processes increasingly become digitalized. A centralized manner might lead to security problems and high transaction fees. Blockchain technology has evolved to solve these problems by allowing untrusted individuals to trade without the intervention of a trustworthy third party.

Smart contracts are one of the most popular and widely discussed topics built on top of the blockchain. An executable code that runs on the blockchain to facilitate, exe-cute, and enforce the terms of an agreement between untrustworthy parties is known as a blockchain-based smart contract. It can consider as a system once agreements satisfy then the system releases digital assets. Smart contracts are a perfect substitute to replace conventional contracts, which are often complicated, sluggish, and costly. Today, due to the contribution of blockchain consortiums such as Hyperledger, smart contracts are pos-sible to simplify multiple financial and business processes [4].

Compared to conventional software engineering, the discipline of developing smart con-tracts not matured enough. In addition, blockchain-based smart concon-tracts depend on a non-standard life-cycle of software, which, for example, can hardly upgrade delivered im-plementations [5]. The need for being timely on the market and the lack of experience in a brand new field led to epic disasters, such as DAO in 2016 and Parity Ethereum wal-let in 2017, and there have been several hacks successfully performed on cryptocurrency exchanges, the biggest being those of MtGox in 2014 (350 million US dollars), Bitfinex in 2016 (72 million US dollars), and Coincheck in 2017 (400 million US dollars) [6]. The application of software engineering practices to blockchain software development is crucial to the success of this new field. Here the issues are the need for specific design and analy-sis methods, quality control through testing and metrics, security assessment, and overall development process. A stabler understanding of this topic from the software engineering perspective will be helpful to identify issues related to blockchain-based smart contracts that help to make a discipline for blockchain software engineering.

Need for a systematic mapping study

The key purpose of this thesis is to identify the research topics that have been carried out on blockchain-based smart contracts development and existing issues that need to be addressed from a software engineering perspective. There is also a sharp rise in the number of studies and findings made available as the study field matures, and offering a summary is necessary. To accomplish this purpose, we perform a systematic mapping by following the guidelines by Petersen et al. [1].

(9)

The main contributions in this thesis are as follows:

• A classification of the current research topics on blockchain-based smart contracts development.

• An overview of the publication trends on blockchain-based smart contracts develop-ment.

• A classification of studies based on smart contracts development phases.

• Identify programming languages for developing blockchain-based smart contracts and classify them based on the programming language paradigm.

• An overview of blockchain platforms for developing blockchain-based smart con-tracts.

• Identification of research gaps that need to be addressed in future studies.

The remainder of this report is organized as follows. Section 2. describes the background of the research, and Section 3. presents the research methodology for the thesis. Section 4. details the data extraction results, and Section 5. describes the main findings and evaluates them. Section 6. discusses the results, and Section 7. analyzes the threats to the validity of this work. Section 8. details related work and Section 9. concludes the paper and highlights future work.

(10)

2. Background

2.1 Blockchain

It is usual to think of blockchain invented by Satoshi Nakamoto as the backbone of the Internet 3.0. But blockchain was invented in early 1990 by Haber and Stornetta [7]. Blockchain is a distributed database that records all transactions in a network that is decentralized, peer-to-peer, public, immutable, and append-only [4]. Transactions are the permanent record of writes and multiple transactions grouped in blocks. Each block in a blockchain contains its hash, the previous block’s hash (called parent block), and trans-action data, as shown in Figure 1. Hash of blocks computes using a hashing algorithm [8]. The hashing algorithm calculates the hash of each block by the transaction data, cur-rent timestamp, and pacur-rent block hash. We can consider blockchain as a database where each node in the network has the same copy of the database. And all the changes in the blockchain are reflected in all the copies of the database [9].

Any alteration to a block’s data alters its hash, invalidating all subsequent blocks, and the tampering is automatically clear to every member node in the chain. In other words, blockchain is a sequence of blocks that are simultaneously permanent and immutable. To hacking a blockchain majority of the network (51 percent) must change, which is impos-sible in the case of a massive blockchain [10]. The reliability of a blockchain relies on the premise that tampering will have to proceed through the bulk of a network’s nodes (51 percent) in the same manner at the same time. As a result, if a blockchain net-work hits critical mass, modifying the blockchain becomes infeasible [11]. We can classify blockchains based on the access level to three different types as follow: (i) public with no access restrictions, (ii) private which requires an appeal to access, and (iii) hybrid which combines private and public properties [12].

Various clients or nodes within a cryptocurrency’s peer-to-peer network verify transac-tions within a blockchain using one of many different consensus algorithms for solving the problem of authenticity in a network involving multiple nodes [13]. The Proof of Work (PoW) and Proof of Stake (PoS) algorithms are the most widely used consensus algo-rithms [13]. The most popular blockchain, such as Bitcoin and Ethereum, use the PoW consensus algorithm. It requires a participant node to demonstrate that the work they have completed and submitted qualifies them to add new transactions to the blockchain. Miners compete against one another in PoW to complete network transactions and earn rewards [14]. Moreover, the PoS algorithm selects a node to be the validator of the next block using a pseudo-random election process based on a combination of factors such as staking age, randomization, and the node’s wealth [15]. Other blockchains like Binance Smart Chain (BSC) use the PoS algorithm [16]. Between the several blockchains and consensus algorithms, Solana blockchain uses the Proof of History (PoH) algorithm that produces a historical record to prove an event has occurred at a particular moment in time [17]. Table 1 shows the algorithms, transaction per second, and finality time for some of the most popular blockchain platforms.

(11)

Figure 1: Simplified diagram of a blockchain

Blockchain Consensus algorithm Transaction per second Finality time

Bitcoin PoW 4.6 3600 second

Ethereum PoW 15 300 second

BSC PoS 100 75 second

Avalanche PoS 4500 1-5 second

Solana PoH 50000 0.4 second

Table 1: Blockchain and their consensus algorithms

2.2 Blockchain-based smart contract

An executable code that runs on the blockchain to facilitate, execute, and enforce the terms of an agreement between untrustworthy parties is known as a blockchain-based smart contract. It can consider as a system once the agreement mets, then the system releases digital assets [18]. In other words, blockchain-based smart contracts are computer protocols intended to automatically support, verify, and execute the agreement and imple-mentation of digital contracts without central administrations. Blockchain-based smart contracts do not rely on a trusted third party to perform like traditional contracts that require a trusted third party to enforce and perform the terms of an agreement. Generally, they enable transactions between untrusted parties without any intermediary charge, the third-party dependence and the need for mutual interaction directly of the counter-parties [19].

It is possible to develop smart contracts and deploy them on centralized platforms or de-centralized (blockchain) platforms. Blockchain-based smart contracts operate in a decen-tralized manner, which ensures that even though a member leaves the blockchain network, the network can continue to run with no loss of data or legitimacy. On the other hand, a centralized smart contract deploys on a trusted third party. Because there is no blockchain involved, this method is also known as off-blockchain implementation. Ethereum is the most widely used blockchain platform for smart contract development [2].

2.3 Blockchain-based smart contract development

The development of smart contracts is somewhat different from the production of conven-tional applications, presenting new problems and challenges [20]. Due to the immutability of the blockchain and the sensitivity of digital assets frequently handled, developers must maintain code security for smart contracts. The execution of smart contracts on blockchain

(12)

networks such as Ethereum applies via the gas system, and developers must pay attention to gas usage. The execution of a transaction on Ethereum involves certain computing energy (called gas) to be paid for by the initiator of the transaction [21]. Importantly the production of smart contracts involves particular limitations and characteristics of the applications running on them.

Sillaber et al. [22] introduce an integrated process model for the blockchain-based smart contracts development that explicitly accounts for the immutable, trustless, append-only, and decentralized ecosystem. The model consists of five successive and closely intertwined phases: conceptualization, implementation, approval, execution, and finalization. Soft-ware engineers can use this model to better understanding the smart contract development processes. Furthermore, we use this model to classify development phases.

2.4 Blockchain-based smart contract programming languages

To build blockchain-based smart contracts various languages have been suggested. Every blockchain platform, in general, includes a programming language for developing smart contracts. For instance, a smart contract language called Solidity was developed for Ethereum, while for Bitcoin, Script developed. Note that blockchains can support other programming languages. For instance, Ethereum supports around 25 different program-ming languages [9]. Since smart contract languages are principal to the operation of a blockchain, a flaw or failure in one will cause security issues [23]. Concerning their level of use, we can distinguish programming languages as follow.

Low-level: These languages are structured to be specifically implemented by the un-derlying execution environment. Low-level code is regularly cryptic and incomprehensible to humans. Bitcoin-script and Michelson are examples of these languages [24].

High-level: These languages can make it easier for developers to write new blockchain-based smart contracts and reasoning about existing contracts. These languages make it easy for developers to write contracts by readability and safer high-level syntactic struc-tures. Furthermore, parallel multiple high-level languages can execute on the same ledger. Examples of such languages are Solidity and Liquidity [9].

Intermediate-level: Languages that present a settlement between high-level and low-level languages. They simplify the verification or static analysis of systems, depending on the model of computation, type system, logic, and semantics. An instance of such a language is Simplicity [25].

2.5 StArt tool

We used a tool called StArt 1 _{- State of the Art through Systematic Review that was} developed at the Federal University of S˜ao Carlos (UFSCar) to conduct a more structured systematic review [26]. StArt is a software tool that supports the systematic review protocol proposed by Petersen et al. [1]. Marshall, Brereton, and Kitchenham et al. [27] identify four tools to support the whole systematic review process in software engineering: SLR-Tool, SLuRp, SLRTOOL, and StArt. Furthermore, they compare and evaluate tools by a feature analysis. The StArt is classified as the second-highest amount the tools. We used StArt because we intend to make the processes as transparent and replicable as

1

(13)

possible. We have published a bundle with all artifacts and the final results of this thesis in a complete replication package2. Further, we provide a file generated by StArt(.start) in the mentioned address that can import into the software tools to get all information to repeat the study. By importing the provided file in the software tools, researchers access all artifacts, protocol, quality assessment forms, and extraction forms.

2

(14)

3. Method

Evidence-Based Software Engineering refers to research methods applied to develop a body of knowledge in the discipline of software engineering [28]. A systematic mapping study is a specific method for reviewing research literature that has a suite of methods along the process of conducting a review that aims to maximize transparency, objectivity, and com-prehensiveness. In the traditional literature review, we might synthesize literature from an evidence base that could be susceptible to a number of different biases. For example, subconscious bias or potentially deliberate bias or results that the researcher gets might not be representative of the real body of evidence. The goal of a systematic mapping study is to provide an overview of a research area, to establish if research evidence exists, and quantify the amount of data. In this thesis, we follow the systematic mapping process proposed by Petersen et al. [1] and the guidelines for snowballing proposed by Wohlin et al. [29]. We chose the systematic mapping study as the research methodology because the goal is to explore the existing studies related to blockchain-based smart contracts. The process for the systematic mapping study is presented in Figure 2 and consists of five process steps and outcomes. The thesis focuses on blockchain-based smart contracts development from a technical perspective and excluded studies with other perspectives (e.g., papers with an economic perspective). Furthermore, we have used StArt [26] to support the review processes.

Figure 2: Steps of the systematic mapping study [1]

The approach of this study can divide into three well-defined phases: planning, conduct-ing, and reporting. During the planning stage, the protocol and a schedule with all of the review’s specifics developed. Study questions, search and selection procedures, inclu-sion/exclusion criteria, quality assessment, data collection forms, and analysis techniques included in the review protocol. The conducting stage (also known as the execution stage in StArt) entails carrying out the various steps of the plan defined in the previous phase. Finally, the reporting stage (also known as summarization in StArt) generates a report as a final product. Figure 3 shows a procedure with the various tasks carried out during the study.

(15)

Figure 3: Process followed to conduct the review

3.1 Research questions

Since these questions guide the whole review process, defining the research questions is critical. This thesis aims to provide an overview of the research area and identify, classify, and assess trends in the current literature concerning the development of blockchain-based smart contracts. The research questions to be answered from this systematic mapping study are as follows:

• RQ1 What are the current research topics on blockchain-based smart contracts de-velopment?

Rational: To recognize the existing state of research on blockchain-based smart contracts and evaluate the density of scientific publications over the years.

Outcome: A representation of the current state of research on blockchain-based smart contracts in terms of publication year, publication venue, and contribution type.

• RQ2. Which development phases are there for blockchain-based smart contracts? Rational: To recognize the investigated development phases in studies.

Outcome: A classification of studies based on investigating development phases.

• RQ3. Which programming languages are there in the literature for smart contracts development?

Rational: To identify the programming languages used to develop blockchain-based smart contracts and classify them.

Outcome: A list of programming languages in the primary studies and classify them based on the paradigm.

• RQ4. Which blockchain platforms are there in the literature for smart contracts development?

Rational: To identify the blockchain platforms used to develop blockchain-based smart contracts.

(16)

Outcome: An illustration of the most popular blockchain platform for the devel-opment of smart contracts.

• RQ5. What are the research gaps in the development of blockchain-based smart contracts that need to be addressed in future studies?

Rational: To identify research gaps that need to be considered in future studies. Outcome: Research gaps that can be studied by researchers as future works.

3.2 Search process

We split the search into two parts: an automated search and a manual backward snow-balling approach to the studies chosen in the previous step. The search and selection processes are intertwined since backward snowballing performed to studies that approved for extraction. We discovered that the chosen academic primary studies contain citations to grey literature such as white papers, blogs, GitHub accounts, and blog posts. However, we exclude gray literature in backward snowballing processes. It is worth mentioning that we will briefly touch upon the gray literature in the discussion (Section 6). The following are the two steps of the search process:

• Initial search: We searched the digital libraries, and load the results in the StArt tool. StArt automatically detects some duplicate papers and marks references as duplicated. However, StArt did not find all the duplicated references. So we screen papers manually to discover all duplicates. Moreover, a set of studies obtained after the selection processes (see Section 3.3).

• Backward snowballing: We use the backward snowballing strategy proposed by Wohlin et al. [29]. We use the reference list of papers obtained in the previous step to search for new studies. Furthermore, we load the results in the StArt tool as a new search. Finally, we repeat the procedure until we could not find any new paper. We use a “Trail-and-error Search” method to come up with appropriate search strings. As a result, we have generated relatively simple search strings, as recommended by Kitchen-ham et al. in [30]. Table 2 shows search strings have used in each search engine. Fur-thermore, Figure 4 shows the percentage of studies obtained from each search engine and snowballing process. Note that the total number of studies is 1257. The number of stud-ies obtained from each database and snowballing is as follows: IEEE (444), Scopus (112), ACM (146), Web of Science(295), and Snowballing (260). Note that these numbers are after removing duplicated papers.

(17)

Source Search string

IEEE

((“All Metadata”:smart contract*) AND (“All Meta-data”:blockchain)) AND ((“All Metadata”:programming language) OR (“All Metadata”:development) OR (“All Metadata”:modeling language))

Scopus

(TITLE-ABS-KEY ((“smart AND contract*” AND “blockchain” AND (“programming AND language” OR “development” OR “mod-eling AND language”)))

ACM

((Title:(smart contract*) OR Abstract:(smart contract*) OR Keyword:(smart contract*)) AND (Title:(blockchain*) OR Ab-stract:(blockchain*) OR Keyword:(blockchain*)) AND ((Ti-tle:(programming language*) OR Abstract:(programming language*) OR Keyword:(programming language*)) OR (Title:(development*) OR Abstract:(development*) OR Keyword:(development*)) OR (Title:(modeling language*) OR Abstract:(modeling language*) OR Keyword:(modeling language*)))

Web of science (TOPIC:(“smart contract*” AND “blockchain” AND (“programming language” OR “development” OR “modelling language”))

Table 2: Search strings used in the different search engines

3.3 Study selection

We screened papers in two phases. First, the screening was based on title, abstract, and keywords, and studies that are irrelevant or duplicates are excluded. Second, a thorough full-text review of the selected studies from the first phase is made and studies are selected for extraction. Next, We assessed all papers for quality in the second phase, and the result helps us to select papers for extraction. Once a study has been selected for extraction, a backward snowballing process of the reference list is included in the paper made. Further-more, papers that were chosen went through screening processes. We repeat this process until no new reference is found. As a result of screening, 67 studies have been selected in the first phase. The thorough full-text review of the studies resulted in 41 studies that are used for data extraction. The native tool that provides the StArt tool for snowballing does not work properly so we load selected references in StArt as a new search. We have used several standard exclusion criteria proposed by Kuhrmann et al. [31] that are listed in Table 3. The symbols “I” represent Inclusion criteria, while “E” represents Exclusion criteria in the table.

3.4 Quality assessment

The quality assessment helped us to make more accurate decisions in the second phase of study selection. The quality assessment was not a measure to assess the general studies quality, but an assessment of information quality for our thesis. We use the information quality framework proposed by Wieringa et al. in [32]. Intrinsic, contextual, representa-tional, and accessibility are the four dimensions of Information Quality (IQ) defined by this system. The information quality can measure by one or more dimensions. It depends on the attributes extracted from the data. In our thesis, intrinsic and contextual are rel-evant, so we skip other dimensions. The intrinsic dimension assesses the data’s precision, objectivity, trustworthiness, and credibility in the context of the task at hand. And the contextual dimension checks whether data’s contextual parameters are suitable for the

(18)

Criteria Description

Inclusion I1. The study is about blockchain-based smart contract development.

Exclusion

E1. Book or book chapter;

E2. Early access article not reviewed;

E3. Magazine not reviewed (unlike IEEE IES, and IEEE Spectrum); E4. The study in the form of tutorial paper, short paper, poster paper, editorial, manual;

E5. Secondary and tertiary study;

E6. The study related to non blockchain-based smart contract;

E7. The study dealing with topics not belonging to the corpus of knowledge of Software Engineering (mining algorithm, cryptography, ICOs);

E8. The study is not written in English; E9. Full text is not available for the study;

E10. The study dealing with topics not belonging to the development of smart contract(Ethereum VM performance);

E11. Master thesis.

Table 3: Exclusion and inclusion criteria

task at hand. The following are the assessments and measurements methods used for the IQ dimensions listed above:

• Intrinsic IQ: The type of publication, the forum where it is published, and the forum’s ranking determining believability and credibility to assess intrinsic IQ. As a result, each study was grouped into one of the J1, J2, J3, C1, C2, C3 groups. Table 4 shows categories that each study falls in depends on their type and ranking that further use to calculate the intrinsic IQ.

Group Conference / Workshop / Journal

J1 Journal indexed as Q1 or Q2 in the ISI WoK and/or Scimago Journal rankings. J2 Journal indexed as Q3 or Q4 in the ISI WoK and/or Scimago Journal rankings. J3 Journal not indexed in the ISI WoK nor Scimago Journal rankings.

C1 Conference indexed as A or B in www.conferenceranks.com. C2 Conference indexed as C in www.conferenceranks.com.

C3 Workshop or conference not indexed in www.conferenceranks.com. Table 4: Categories for each study depends on their type and ranking

Furthermore, intrinsic IQ calculated using a three-point likert scale with A, B, and C values besd on catigorization that explain earlier. A is the highest chance to be selected, and C is the lowest chance to be selected. Table 5 shows the criteria for the assessment of Intrinsic quality level based on their groups. Note that workshops classified as C3.

• Contextual IQ: We defined the following questionnaire to measure the amount of data and completeness of each study.

—Q1 Could the contribution type be extracted?

—Q2 Could we extract the development phase or phases that the paper focuses on? —Q3 Could we extract the smart contracts programming language paradigm?

(19)

Group Intrinsic IQ Output

J1 or C1 A

J2 or C2 B

J3 or C3 C

Table 5: Assessment of intrinsic information quality

—Q4 Could we extract the programming language name?

—Q5 Could we extract the blockchain platform name that the paper mention for developing smart contracts?

—Q6 Could we extract the tackled smart contracts challenge or challenges in the paper?

The contextual IQ calculated using a three-point Likert scale of A, B, and C values. A is the highest chance to be selected, and C is the lowest chance to be selected. The contextual IQ assessment completed using the criteria mentioned in Table 6.

Metric Number of answered question Contextual IQ Output

Completeness 5 or 6 A

Completeness 3 or 4 B

Completeness 1 or 2 C

Table 6: Assessment of contextual information quality

A study’s quality is measured by the degree of quality achieved in the two dimensions of intrinsic and contextual IQ.

3.5 Data extraction process

Filling out a form created in the StArt tool is used to collect data. Note that we could select several options from the list. The following fields included in the form:

• Publication type: Conference paper, workshop paper, or journal paper. • Contribution: Metric, tool, model, method, process.

• Development phase: Conceptualization, implementation, approval, execution, final-ization.

• Programming language paradigm: Imperative, declarative, symbolic.

• Programming language name: A String representing the name of the programming language.

• Programming language purpose: Implementation, specification. • Blockchain platform: Ethereum, Bitcoin, ...

• Tackled challenge: Readability, functional issues, contract correctness, dynamic con-trol flow, transaction-ordering, execution efficiency, privacy and security, trustworthy oracle, scam.

(20)

We revise the extracted data and use extracted data to answer research questions. Table 7 shows each field of data extraction form and related research questions. StArt provides a generic form for each publication that contains some fields like name, authors, publication venue, publication year. Therefore, we did not add those fields to the extraction form.

Field of data extraction form Research question

Publication type RQ1

Contribution RQ1

Development phase RQ2

Programming language paradigm RQ3 Programming language name RQ3 Programming language purpose RQ3 Blockchain platform name RQ4

Tackled challenge RQ5

Table 7: Fields of data extraction form and related research question

3.5.1 Contribution type

The studies were categorized into five groups based on the grouping suggested by Petersen et al. [1]. Table 8 shows the different contributions and their descriptions. Note that a study can have several contributions.

Contribution type Definition

Metric The research provides specific metrics and measures to assess at-tributes in smart contracts.

Tool The research offers a tool or prototype for evaluating, analyzing, assessing, improving, or developing smart contracts.

Model The research gives an abstract representation that use to test, in-terpret, measure, or create smart contracts as a model or a system. Method

The research presents a systemic approach to evaluating, analyz-ing, assessanalyz-ing, or developing smart contracts, which involves gen-eral principles and operating procedures.

Process

The research identifies a group of practices that work together to test, review, measure, or enhance the production of smart con-tracts.

Table 8: Contribution types

3.5.2 Development phases

The development of smart contracts is different from the production of conventional soft-ware. Sillaber et al. [22] provide an optimized process model for the development of smart contracts concerning blockchain characteristics such as immutability, trustlessness, being append-only, and being decentralized. As shown in Table 9, the model consists of five interconnected steps, and we use this model to classify the studies. It’s worth mention that if smart contract creators have access to the right tools, specification, deployment, validation, and testing would all go hand in hand.

(21)

Development phase Definition

Conceptualization

In this step, the smart contract’s preliminary scope, specifications, and goals define and transfer to a conceptual model. The model specifies groups of objects, as well as the desired relationships between them. The outcomes convert the requirements of all con-nected parties into a smart contract (e.g., transactions).

Implementation In this phase, the conceptual model is mapped onto an executable model (e.g., in Bitcoin by using Script code).

Approval

Review, testing, and verification of an executable smart contract. Verification and simulation of the smart contract against the scope and stakeholder conditions to see if there are any bugs in the code, such as programming errors or misaligned parameters.

Execution

An instance of the smart contract freeze and submit for execution in the live test blockchain environment (known as Testnet) for testing and monitoring.

Finalization

Validating whether the intended results are achieved or not after the smart contract has reached the end of its life (for example, by using the Ethereum blockchain’s “self-destruction” operation).

Table 9: Development phases

3.5.3 programming language paradigms

Varela et al. [9] identify and categorize the current languages for the development of smart contracts based on their primary characteristics. They identify 101 smart con-tract programming languages and group them according to the paradigm of imperative, declarative, and symbolic. We use the same grouping system to classify the identified programming languages. It is worth noting that a language can belong to both impera-tive and declaraimpera-tive paradigm. The languages classified into the following programming paradigms:

• Imperative language: An imperative programming language means that language changes statements to the state program [33].

• Declarative language: A Declarative programming language paradigm means that language statements are stateless [33].

• Symbolic language: A Symbolic programming language paradigm means that language can treat itself as data [9].

3.5.4 Blockchain platform name

Firstly, we identify the blockchain platform or platforms mentioned in each primary study for smart contract development. Further, we filled this field of the extraction form with the name of blockchain or blockchains mentioned in each study. Lastly, to answer RQ4 we categorize the primary studies based on identified blockchain platforms.

3.5.5 Challenges in smart contracts

There are several challenges to be tackled in smart contracts. We categorize these major challenges into nine types that are relevant to smart contract development according to the challenges listed in [2]. Table 10 shows the challenges and their definitions.

(22)

Challenges Definition

Readability

Smart contracts are written in programming languages like So-lidity, and compiled and implemented from source code. As a result, certificates have different types of codes at different times.

Functional issues

Mainly, the issues related to the functional aspect of smart contracts. Some common functional issues are: (i) re-entrancy means that the interrupted function can be safely recalled again, (ii) block randomness which means blockchain is thought to be a promising technology for generating public and random values. Miners could monitor the generation of blocks and re-lease them before they find one that is lucrative, (iii) overcharg-ing means that smart contracts can be overcharged due to the under-optimization, developers of smart contract also need to pay attention to their execution costs (e.g., gas in Ethereum).

Contract correctness

It is almost impossible to make changes to smart contracts af-ter they have been deployed on the blockchain. As a result, evaluating the correctness of smart contracts before their for-mal implementation is critical. However, owing to the difficulty of modeling smart contracts, verifying their correctness can be difficult. Some advances are bytecode analysis, source code analysis, and machine learning-based analysis.

Dynamic control flow

The control flow of smart contracts is not immutable, but smart contracts themselves are. A smart contract can communicate with other smart contracts, and control flow must be carefully planned. Some advances for addressing the issue are graph-based analysis, dynamic control flow, and path-searching.

Transaction-ordering

Users submit transactions to a smart contract’s features, which are then packed into blocks by miners. Due to the complexity of the bisected blockchain divisions, the sequence of transactions is not deterministic. Order-dependent transactions can become inconsistent as a result of this confusion. Some advances are sequential execution and predefining contract.

Execution efficiency

Miners conduct smart contracts in a sequential order. In other terms, once the existing contract is done, a miner can not ex-ecute another contract. The system’s performance is basically limited by the execution serialization. Some advances are exe-cution serialization and inspection of contract.

Privacy and security

Transaction logs are spread across the whole blockchain net-work, and anyone in the network can see all of the transactions. Furthermore, transactional graph analysis can be used to ex-tract information from transaction records, and smart conex-tract implementations have their own set of software vulnerabilities. Trustworthy oracle

An oracle provides the data from the real world, and how to determine a trustworthy oracle that is decentralized is challeng-ing.

Scam

Scam identification is critical, particularly for contract users, because it allows them to terminate their investments early and avoid incurring excessive losses.

(23)

4. Data extraction results

In this section, we present results obtained during extraction. Figure 5 shows a diagram and a StArt screenshot that review results obtained during the three stages of the execution (identification, selection, and extraction). Initially, we Identified 1442 papers, while 185 papers were duplicates. Therefore 1257 papers were screened in the first phase based on title, abstract, and keywords. Furthermore, 67 studies were selected for full-text screening. And finally, 41 studies were selected for data extraction. Note that we list primary studies in Appendix A. The data synthesis and analysis methods developed using the mapping research analysis and qualitative synthesis methods suggested in [30].

Figure 5: Summary of the results of the different phases in StArt

We calculated the quality of primary studies by measuring the intrinsic IQ and contextual IQ (see Section 3.4). Figure 6 shows the quality metrics by a bubble chart. The chart represents the two dimensions (one on each axis) and their values (A, B, and C). A bubble represents the number of studies with two quality dimensions. Note that primary studies have an appropriate level of quality for inclusion in the current work, based on the quality criteria defined in Section 3.4. Besides, each bubble can contains three colors that indicate the publication type.

(24)

5. Results and evaluation

In this section, we present the data extraction results. Furthermore, we list the biblio-graphical information of our primary studies in Appendix A.

5.1 Results analysis of RQ1

Publication year

Figure 7 depicts the smart contracts development publications trends over time. The primary studies are published over a short period of time, from 2016 to 2020, with only three studies published until 2017, and a surge in interest peaked in 2019. Our initial search has no time limits, but the primary studies were published in a limited time range of 2016 to 2020. We have an average of 12.6 publications per year from 2018 to the present, with a peak in 2019, indicating that we do not have a consistent publication rate. The first research study published in 2016 (S6) proposing a modeling approach that supports the semi-automated translation of human-readable contract representations into computational equivalents. This study was referenced many times in further research in the field. The search took place in February 2021, but no studies were selected from this year. Furthermore, since not all journal articles have been added to libraries yet, the search for 2020 could only be partially complete.

Figure 7: Publications trend per year

Publication venues

The distribution of primary studies by type of publication is presented in Figure 8 (work-shop, journal, and conference). Conference papers (25/41) are the most common form of publication, followed by workshop papers (11/41) and journal papers (5/41). Eight venues hosted more than one study, while six are conferences and two are workshops. The high number of workshop papers may be an indicator of the fact that the smart con-tracts acceptance rate is high. There are workshops fully dedicated to the blockchain topic that creates a clearly defined dedicated research community, for example, International Workshop on Blockchain Oriented Software Engineering (hosted three primary studies). Appendix B provides The complete list of publication venues and the number of published studies from our set of primary.

(25)

Figure 8: Publications venues

Figure 9 depicts the distribution of publication types by year. Workshops have a more consistent trajectory of at least one publication per year since 2016, with a strong peak in 2018, while journals had a more steep line, with all publications in 2018. We discovered some fascinating ideas after doing a more in-depth review of these findings. Firstly, there are only three studies that are part of the “inception process” until 2018. After the Bit-coin price explosion in 2017, the area of smart contracts become popular. This popularity leads to build many smart contract projects and research. Further, as mentioned in the introduction, the security issues revealed, and many hacks happened. After, a wave of research effort began in 2017, which lead to publishing several papers in 2018 and 2019.

Figure 9: Distribution of publication types per year

Contribution Type

Figure 10 depicts the overall number of primary studies per contribution type. The main contribution types, according to the extracted results, are tool and method (each with 21), and following by model (7), process (5), and metric (2). It’s noteworthy that only two

(26)

primary studies suggest smart contracts metrics, while others only reference them briefly. It is worth noting that each paper can have multiple contributions.

Figure 10: Contribution types

In this section, we consider the development phases for smart contracts development pre-sented in [22] as a base for grouping studies. The smart contracts development differ from conventional software due to the blockchain characteristics such as immutability, trust-lessness, being append-only, and being decentralized. Figure 11 illustrates the details of development phases categorization, as found focus on each phase in the 41 selected pri-mary studies. Note that each paper can focus on more than one development phase. The majority of the studies focus on the conceptualization phase and implementation phase (20 each), followed by approval (16) and execution (6). And no papers focus on the final-ization phase. It is worth mention that specification (conceptualfinal-ization), implementation, and approval will go hand in hand once the appropriate tools are available.

(27)

To answer this question, we have collected the name of identified languages, their pur-poses (implementation, specification), and paradigms in the extraction form. Table 11 shows the name of founded programming languages and their paradigm, purpose, and blockchain platform can run them. In total, we identified eleven languages. Only three of these languages are for the specification, while the rest of the languages are for the implementation. Furthermore, between all languages, the declarative paradigm (5/11) is the most common paradigm, followed by the imperative/declarative paradigm (3/11), and imperative paradigm (2/11), and symbolic paradigm (1/11). Note that agnostic means supported by all blockchain platforms (CML and FSolidM). We could not extract the blockchain platform that supports the SPESC language because the study (S11) does not mention any blockchain platform.

Language name Paradigm Purpose Blockchain platform Solidity Imperative Implementation Ethereum

FSolidM Imperative Implementation Agnostic

Michelson Declarative Implementation Tezos

Plutus Declarative Implementation Cardano

Simplicity Declarative Implementation Bitcoin

BitML Declarative Implementation Bitcoin

DSL4ASC Declarative Implementation Hyperledger CML Imperativ, declarative Implementation Agnostic ADICO-Solidity Imperative, declarative Specification Ethereum

SPESC Imperative, declarative Specification n/a

Blocky Symbolic Specification Ethereum

Table 11: List of programming language names and paradigms in the primary studies Figure 12 depicts a breakdown of the languages by paradigm. For the sake of accuracy, we show the languages classified by their purpose (implementation, specification, and both). In every group, the languages classified into the three programming paradigms explained in Section 3.5.3. Keep in mind that a language may have both imperative and declarative paradigm.

(28)

To answer this research question, we identify the ecosystem of blockchain platforms men-tioned in primary studies for smart contracts development. Figure 13 shows the blockchain platforms and the number of studies that mention them for smart contracts development. Note that a study can mention more than one blockchain. For example, S7 introduces a tool that can corporate with 8 blockchain platforms. We have found 12 different blockchain platforms. The most commonly used platform is that of Ethereum, which is mentioned in 29 studies. There are 5 studies that are platform agnostic, that is, they introduce a tool or method for all blockchain platforms. Far from Ethereum, in the third fourth and five positions of the ranking are Tezos, Bitcoin, and Hyperledger (3 each), and Libra(2).

(29)

To answer this research question, we categorize studies based on addressed smart contract challenges. The challenges are explained in Section 3.5.5. We can use the classification result to identify untackled smart contract challenges and recognize the research gaps. Figure 14 shows the number of studies focused on each challenge. There are 24 studies that tackled contract correctness issues. In the second, and third and fourth positions of the ranking, are privacy and security issues, readability issues, and execution efficiency issues, with 15 and 9 and 4 studies respectively. And right after comes transaction-ordering issues, functional issues, dynamic control flow issues (3 each). Finally, no study tackled the trustworthy oracle issues and scam issues.

(30)

6. Discussion

This systematic mapping research was carried out to reveal relevant insights into the de-velopment of smart contracts. This section presents obtained results that presented in the previous section to explain and interpret the importance of our findings.

Considering publication trends (RQ1), conferences have published the majority of pri-mary studies, followed by workshops and journals. These findings are uncommon in the software engineering literature, and journal publications’ quantities are typically more than workshop publications. The larger number of workshop papers could indicate that smart contracts have a high acceptance rate. We could find two preferred venues that in each of those, three primary studies from our corpus were included. Those two venues are IEEE International Conference on Blockchain and Cryptocurrency (ICBC)3_{, and} Inter-national Workshop on Blockchain Oriented Software Engineering (IWBOSE)4. Moreover, the majority of primary studies contribute to a tool or method. That could indicate the studies focus on providing infrastructure for developing smart contracts rather than fo-cusing on the improvement of the current infrastructure. The research community focuses on providing solutions in the form of methods or tools rather than metrics. Finally, it is worth noting that the majority of the studies were presented at conferences rather than in journals, that indicating that the research area is still in its infancy.

Regarding development phases (RQ2), no primary studies focus on the finalization phase. When a smart contract has reached the end of its life, a validation process needs to check if desired outcomes have been reached or not in the blockchain or external system. Smart contracts remain in the blockchain, but can no longer be executed by the nodes. To validate the desired outcome, smart contracts need an oracle to communicate with external systems. Trustworthy oracle is one of the smart contract challenges we defined in Section 3.5.5. As the result of RQ5 in Section 5.5 shows, no paper focuses on this chal-lenge either. The finalization phase is interconnected with this chalchal-lenge, and both need to be investigated in future studies. Furthermore, the research community paid a lot of attention to the conceptualization and implementation of smart contracts. Model-driven engineering is one of the mentioned approaches to increase understandability. Addition-ally, in the approval phase, some approaches introduce specific kinds of tests like mutation testing. However, some other popular approaches in conventional software development such as integration and regression testing are not mentioned. Lastly, the execution phase has been investigated hand in hand with the blockchain platform.

Regarding programming languages (RQ3), to begin with, identified smart contract languages are generally designed to run on a specific blockchain platform. However, some smart contract languages have been identified that are designed for an agnostic blockchain platform, meaning they can be executed on any blockchain (e.g, CML). Second, the paradigm is influenced by the language’s purpose. There isn’t a single specification language that is associated with either the imperative or declarative paradigms. While, no implementation language, on the other hand, is associated with the symbolic paradigm. Three languages use a mixed (declarative-imperative) paradigm, with two languages being used for implementation and one for specification. Finally, there is no universal language for specifying smart contracts that are valid across all blockchain platforms. Even though

3

https://icbc2021.ieee-icbc.org/

4

(31)

the CML language is considered agnostic, it does transfer the model to Solidity code, which is Ethereum’s dedicated programming language. As a result, working toward the standardization of a smart contract language that can be executed on any technology would be attractive.

Regarding blockchain platforms (RQ4), companies are strictly bound to a blockchain platform once they deploy their smart contract on that blockchain. Several problems arise when a company deploys smart contracts on a specific blockchain and subsequently wishes to transfer the smart contract to another blockchain. In our set of primary studies, the most commonly used platform for developing smart contracts is Ethereum, which is men-tioned in 29 studies. However, as we explained earlier in Section 2.1 Ethereum can handle just 15 transactions per second while Solana blockchain can handle 50000 transactions per second. In comparison, during the 2013 holidays, the centralized payment network Visa processed 47,000 transactions per second [34]. Furthermore, Ethereum uses the POW con-sensus algorithm that causes many problems. For example, nodes (miners) consume an enormous amount of energy (e.g., electricity). In contrast, the blockchains with the POS and POH algorithms do not have that problem. With that all said, we can see the research community efforts on Ethereum blockchain might not become fully practical, and other blockchains might have the higher potentials to research. Finally, tools that can translate and move smart contracts from one blockchain platform to another can be helpful. Regarding research gaps (RQ5), the first gap is the lack of studies tackling trustwor-thy oracle and scam challenges. For starters, due to their underlying consensus protocols and smart contracts, blockchains are unable to support native communication with ex-ternal systems. The solution to this problem is to add new functionality, known as an oracle, that connects blockchains to the outside world. Using a centralized oracle makes it no more secure than a traditional contract-based, centrally managed digital agreement. Therefore, a decentralized and trustworthy oracle is essential for a smart contract, and this challenge needs to investigate in future studies. Furthermore, as smart contracts become more popular and provide more value, they become more attractive targets for scammers. The scammers create frauds to steal money, which can impact smart contract acceptance. This challenge needs to investigate in future studies by proposing approaches like machine learning methods to detect scams.

The second gap is that there is too much research effort on the Ethereum blockchain for smart contracts deployment and execution. Some other blockchains can support the creation of smart contracts with high potential that we discussed earlier. It’s worth noting that each blockchain has its own set of characteristics and features that make it ideal for specific applications. As a result, future research could look into other blockchains for deploying and running smart contracts (e.g., Solana).

The third gap is the lack of studies on the finalization phase. The validation of desired outcomes is essential for smart contracts. However, smart contracts need a trustworthy oracle to communicate with external systems to validate the desired outcomes on real-world.

(32)

7. Threats to validity

This section looks into the threats to our study’s validity and the methods we used to counteract them. According to Wohlin et al. [35], there are four aspects of validity to consider.

External validity

The ability to generalize the final results and outcomes is known as external validity [35]. The first external validity is including the studies that are written in English and excluding studies in other languages. Though this threat is minor because English is the standard language for scientific papers. The second risk is that our study’s generalizability may be hampered with applying a sample of primary studies while they are insufficiently representative of the research on this topic. To counteract this threat, we used four of the largest and most comprehensive electronic databases in software engineering to conduct an automatic search (IEEE Xplore Digital Library, Web of Science, ACM, and SCOPUS). To eventually expand the corpus of primary studies, the search was supported by a backward snowballing activity. Furthermore, we limited our search to peer-reviewed publications, excluding gray literature. The rationale for this decision is that these publications are expected to provide peer-reviewed scientific work of a certain standard. Moreover, the criteria for inclusion and exclusion have been clearly stated.

Internal validity

The degree of influence of external variables on the study design is referred to as internal validity [35]. We carefully defined and validated a detailed study protocol that follows the guidelines proposed in [1] and [35] to mitigate biases in regard to internal validity. Furthermore, any ambiguities or uncertainties were resolved in collaboration with the thesis supervisor. Lastly, we have put together a package with all of the datasets and artifacts generated during our research (see Section 2.5) that make data available for researchers or practitioners who want to replicate or expand on our study.

Construct validity

The validity of primary studies and extracted data in relation to the defined research questions is known as construct validity [35]. First, primary studies may not sufficiently represent the population defined by the research questions. To counteract this threat, we ran an automatic search across four electronic databases, supplemented by a fully recursive backward snowballing activity. Furthermore, we are confident in the validity of the search string because it was created using the “Trail-and-error Search” method as recommended by Kitchenham et al. [30]. We also ran preliminary searches on the four electronic databases and fine-tuned the search string based on the results of a set of sample studies. Moreover, all relevant studies were screened using predetermined and well-defined criteria. To assess the quality of the studies in terms of the information they provide, we used standard inclusion and exclusion criteria as well as an information quality framework proposed by Wieringa et al. [32]. Furthermore, to classify and answer some of the research questions, we used taxonomies published in relevant references.

(33)

Conclusion validity

This aspect is concerned with the relation between the data that was extracted and the results that were obtained [30]. This study avoids possible bias that could jeopardize the validity of the conclusions by following the widely accepted systematic methods docu-mented in the study protocol. We mitigated this risk by thoroughly documenting why and how we built the thesis. Moreover, for transparency and replicability, we made a public replication package with all artifacts. Lastly, other researchers can use the protocol and replication package (optionally StArt tool) to verify and replicate our findings.

(34)

8. Related work

Other current literature reviews (e.g., mapping studies, literature reviews, multivocal map-ping studies, and surveys) pertaining to blockchain-based smart contracts are discussed in this section. Note that surveys are not performed in a systematic or protocol-driven man-ner [36]. Systematic literature reviews (SLRs) and systematic mapping studies (SMSs), on the other hand, tend to provide unbiased and repeatable in-depth reviews of primary studies. Furthermore, the key distinction between SMSs and SLRs is that systematic map-ping is a tool for creating a classification schema for topics studied in a field of interest, while a systematic review is concerned with the study of the specific details of primary studies. The multivocal mapping study nature is near to SMSs however containing gray literature. A multivocal study helps incorporate practitioners’ perspectives and identify emerging research topics [37]. In the past few years, growing attention has been directed to the blockchain-based smart contracts research area as the lack of experience in a brand new field cause epic disasters. We classify studies based on their aim into three groups, (i) systematic mapping studies (SMS) and multivocal mapping studies (MMS), (ii) system-atic mapping literature (SLR), and (iii) surveys. We consider tertiary studies with a focus on smart contracts as related work. Table 12 shows a list of studies that we introduce in the following subsections.

We present a summary and list some shortcomings for each study. In this thesis, we address those shortcomings and also extend the study field to date. Moreover, this thesis identifies the quantity and type of research and the results available within it and maps the frequencies of publication overtime to present the trends.

ID Ref Year Title

SMS1 [38] 2017 A systematic mapping study on current research topics in smart contracts

SMS2 [39] 2018 Smart contract applications within blockchain technology: A sys-tematic mapping study

SMS3 [40] 2019 Use of blockchain smart contracts in software engineering: A sys-tematic mapping

MMS1 [9] 2021 Smart Contract Languages: A multivocal mapping study

SLR1 [41] 2021 A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges

SLR2 [42] 2018 A comparison of approaches for visualizing blockchains and smart contracts

SLR3 [43] 2020 Blockchain smart contracts formalization: Approaches and chal-lenges to address vulnerabilities

Surv1 [44] 2018 An overview of smart contract: Architecture, applications, and future trends

Surv2 [45] 2019 Smart contract development: Challenges and opportunities Surv3 [25] 2018 Towards safer smart contracts: A survey of languages and

verifi-cation methods

Surv4 [46] 2018 Understanding the software development practices of blockchain projects: A survey

(35)

8.1 Systematic mapping studies

Generally, no study in this group addressed the development of smart contracts. Table 13 lists the mapping studies that were considered related works and the number of primary studies they included, and the study questions they answered. The multivocal studies are included in this category since it is the most closely related. The main difference between a systematic mapping study and a multivocal literature review is that a multivocal liter-ature review includes both white and grey literliter-ature while a systematic mapping study contains white literature [37].

Alharby et al. [38] aim to identify emerging areas of study and open problems in the blockchain-based smart contract research area. From a technological standpoint, the study aims to identify current research topics, applications, and challenges that are still open. The study is not focusing on smart contract development but rather on various aspects such as contract source code, security, privacy, and efficiency. The findings show that about two-thirds of the papers concentrate on identifying and addressing smart contract issues (codifying, security, privacy, and performance issues). The paper’s conclusion concerns general aspects of blockchain-based smart contract rather than smart contract develop-ment. It seems that this paper could perform a more comprehensive analysis expected from such a study. Some shortcomings include: (i) analyzed the results in a limited way (lacking comprehensive analysis), (ii) insufficient graphical representation of the results, and (iii) lack of a quality assessment method.

Macrinici et al. [39] concentrate on smart contract applications within the blockchain but does not address smart contract development. The study covers a wide range of top-ics, including demographtop-ics, approaches, problems identified, and solutions. They divide smart contracts issues into three categories: blockchain issues, virtual machine issues, and contract source code issues. The study concludes that the most frequently discussed problems and solutions in the literature are related to blockchain protection, privacy, and scalability, as well as the programmability of smart contracts. Furthermore, they conclude that smart contract publications at conferences, and journals, mainly reflecting experiments and presenting methods, tools, and models. The study could use a quality assessment method to minimize the construct validity .

Tarig et al. [40] focus on identifying the challenges and benefits of using smart contracts in software engineering. Their research wants to determine how smart contracts can sup-port software engineering rather than specific smart contract development. They select eight studies for extraction, and they conclude to solving security issues in blockchain, professionals with skills in both blockchain and software engineering can help. Some shortcomings include (i) the result could present and discuss more comprehensively, (ii) a quality assessment method for study selection could use, and (iii) a small number of selected studies for extraction may not be repressive enough.

Finally, Varela et al. [9] carry out a multivocal mapping study on smart contract lan-guages. In contrast to other studies in this section, they discuss gray literature and white literature. This study focuses on smart contract languages and not on smart contract development. Note that implementation is one of the development phases, but this study focused on identifying languages. Their research questions range from demographic ques-tions to quesques-tions related to the smart contract language features. In conclusion, they provide a replicable overview of the state-of-the-art of smart contract language that can

(36)

benefit researchers and practitioners.

ID Ref Num Research questions

SMS1 [38] 24

RQ1. What are the current research topics on smart contracts? RQ2. What are the current smart contract applications? RQ3. What are the research gaps that need to be addressed in future studies?

SMS2 [39] 64

RQ1. Which publication channels are the main targets for re-search within the field of blockchain-based smart contracts? RQ2. How has the frequency of identified publication channels related to the field of blockchain-based smart contracts changed over time?

RQ3. What are the research types found in the identified papers related to the field of blockchain-based smart contracts?

RQ4. Are the identified papers empirically validated?

RQ5. What are the reported approaches in blockchain-based smart contract research that address the problems identified in RQ6?

RQ6. What are the problems that relate to the applications of smart contracts within the blockchain-based platforms?

RQ7. What are the corresponding solutions to the problems identified in RQ6?

SMS3 [40] 8

RQ1. What are the challenges or benefits of using blockchain-based smart contracts in software engineering?

RQ2. What are the most reported uses of blockchain-based smart contracts in software engineering?

RQ3. What aspects of software engineering are most affected by initiatives in blockchain-based smart contracts?

MMS1 [9] 109

RQ1: Which contributions were made over the years?

RQ2: Which are the main researchers in the area of smart con-tract languages and where are they from?

RQ3: Which are the most influential studies in the area? RQ4: Which are the top venues?

RQ5: What languages are there in the literature for specifying or implementing smart contracts?

RQ6: Are the languages supported by industry or academia? RQ7: Which features do these languages have?

(37)

8.2 Systematic literature reviews

In contrast to the questions proposed in mapping studies, the research questions of sys-tematic literature reviews are more concentrated. Vacca et al. [41] conducted a systematic literature review on blockchain and smart contract techniques, tools, and challenges and not on smart contracts development. The paper highlights emerging challenges and poten-tial strategies related to smart contracts and the advancement of blockchain applications. The paper describes 96 percent of articles based on six areas of concern (i.e., smart con-tract testing, smart concon-tract code analysis, smart concon-tract metrics, smart concon-tract security, Dapp performance, and blockchain application). Moreover, the paper concludes the tech-nology can improve by introducing software engineering practices. Another, H¨arer et al. [42] concentrate solely on visualizing smart contracts. The study focuses on modeling and visualization but not on smart contract development phases. Finally, Singh et al. [43] focus on smart formalization. The paper reviews 35 primary studies that concentrate on smart contracts formalization. The study focuses on the formalization of smart contracts rather than smart contract development.

8.3 Surveys

In general, studies in this category have not performed in a systematic manner. Further-more, replication of these studies is difficult because the result and research questions are not straightforward. First, Wang et al. [44] overview smart contract advancements and possible growth patterns, focusing solely on the Ethereum and Hyperledger systems. Next, Zou et al. [45] focuses mainly on Ethereum and determines the distinctions between conventional software development and smart contracts development from the developer’s viewpoint. Moreover, Chakraborty et al. [46] carry out a survey to investigate the software engineering practices including requirement analysis, task distribution, testing, and veri-fication of blockchain projects. Finally, Harz et al. [25] surveyed blockchain-based smart contracts with a focus on implementation issues. The paper introduces several smart contract languages concentrating on security by giving an overview concerning paradigm, type, instruction set, semantics, and metering. The paper examines verification tools and techniques for smart contracts and distributed ledgers. Subsequently, the paper reviews their verification approach, level of automation, coverage, and supported languages.