Vulnerabilities and Open Issues of Smart Contracts: A Systematic Mapping

A Blockchain platform is a decentralized ledger. It stores transactions permanently, in a secure and auditable way [3]. Blockchain technology was popularized by Bitcoin in 2008 [12], enabling reliable digital financial transactions without a trusted third party between anonymous entities. Bitcoin merged the qualities of cryptography techniques and peer-to-peer networks. In this network, miners verify transactions as they occur, checking signatures and balances. Then, a distributed consensus algorithm is used to create a block with the validated transactions. The block is broadcasted to the entire network so that all nodes can, after validating its correctness, add the new blocks to their copy of the ledger [1]. The consensus algorithm maintains a trusted network without the need to trust any node in particular [@5].

A Smart Contract (SC) is software that runs on the Blockchain and represents an agreement between non-trusting participants [1]. The most popular Blockchain platform that supports SCs is Ethereum [4, 18]. However, the development of complex SCs is not trivial [1]. For example, the Ethereum platform uses a network of Turing complete virtual machines to validate transactions [1]. In Ethereum, the programmer uses a high-level programming language (e.g., Solidity) to write the SCs. The interaction between users and SCs occurs by sending a transaction to the contract address. An SC can call other SCs during its execution and can pass data as parameters, making it possible to execute untrusted code [2]. So there is a need to ensure the correctness of the executable codes, but that is a challenging task [@13].

Before the Blockchain technology arising, although the concept of SCs already existed [16], they were not well developed [@5]. The participation of central authorities or resource managers was a requirement at the time, limiting strongly the usefulness of smart contracts since these third parties are able to handle agreements themselves [@10, @13]. Since there is no need for a trusted third party in the Blockchain, smart contracts can be advantageously employed.

This mapping presents an overview of the current state of research on the problems/issues directly involved with SCs in the Blockchain context. Table LABEL:Table:RQ shows the Research Questions (RQ) and the rationales considering them in this SLM.

The search resulted in 341 publications from Scopus. We followed a selection process with 2 main stages in this SLM (Figure 1).

In stage 1, we applied the selection criteria (inclusion and exclusion criteria) over title, abstract and keywords, resulting in 62 papers (reduction of approximately 82%). 1 paper was eliminated by EC1 (Study has no abstract); 10 by EC2 (Study without full text); 34 by EC3 (Study is not a primary study); 8 by EC4 (Study is not written in English) 3 by EC5 (Study is a copy or an older version of another study already considered); 2 by EC7 (Study with publication date prior to 2015); and 221 by EC8 (Study should contain problems related to smart contracts itself, problems about smart contract applications aren’t enough). In stage 2, we applied the selection criteria considering the full text, resulting in 32 studies (a reduction of approximately 48%). 1 paper was eliminated by EC2, EC3 and EC5; and 26 by EC8. From the first stage on, secondary works were also selected among the EC3 excluded papers. We separated those that didn’t fit other exclusion criteria, obtaining 17 papers at the end of the 2nd stage. One more was included outside the search results because it was indicated by an expert due to its relevance, totaling 18 papers. The related work supported the determination of answers to our research questions through taxonomies, classifications and other contributions.

Over the years, publications on smart contracts for Blockchain, had a growth similar to quadratic for both the primary and secondary papers, as presented in Figure 2. We conducted our search in January 2021. So, we have only two papers this year, but considering that the period was less than a month, the number was not bad. Even with this growth rate, we find that the maturity of this field is still low. The majority, 72% of all 50 papers were from conferences, and only 26% from journals, is that in absolute terms it is still new compared to fields already established in the Information Technology. This is expected since it has not been even a decade since the first platform with support for SCs was inaugurated.

We count the frequency of the countries from where the papers were written. They are shown in Figure 3. Countries that appeared only once (3.67% each) were Italy, Malta, Saudi Arabia, Hong Kong, Thailand, Qatar and Morocco; twice (6.67% each) were Austria, Switzerland, United Kingdom, France, Japan and Russia; three times (10%) was Germany; four times (13.33% each) were Singapore and Australia; seven times (23.33%) was the USA; and eleven times (36.67%) was China.

Most of the problems/issues pointed out in the literature were the exploitation of specific vulnerabilities in Ethereum. Solidity, the most used language in Ethereum, has several known problems³³3The address https://swcregistry.io/ has an updated list of known vulnerabilities..

In general, the articles seek to automatically find vulnerabilities by analyzing the source code, identifying the use of critical instructions (e.g., transfer funds), and analyzing the possibility of the code reaching these critical instructions.

The most common critical instructions mentioned were reentrancy, integer overflow, withdrawn and unprotected SELFDESTRUCT instruction. Besides security issues, some papers mention issues related to privacy [@8, @9, @11], performance [@5, @8, @9], governance and legality [@11].

Some articles studied problems not directly related to the source code of the SCs. They deal with external conditions of application execution, such as malicious or irrational use of applications, redesign of software engineering techniques to suit better the context of Blockchain, or monitoring of the use of decentralized applications (auditing).

There was no common proposal to classify problems. Among primary papers, Luu et al. [#1], for example, organized vulnerabilities based on their origin or cause, namely: dependence on the order of transactions, dependence on time, inadequate handling of exceptions and indentation. [#15] used a similar classification. Another article by Petar Tsankov [#4] organized the vulnerabilities as follows: insecure coding, unsafe transfers, unsafe inputs, transaction reordering, and reentrancy issues. Groce et al. [#19] prefer to classify the vulnerabilities by their severity and the difficulty of being exploited.

Regarding secondary papers, Wang et al. [@17] provides an interesting taxonomy over SC security issues, also categorizing respective solutions for them, being the main problems: abnormal contract, program vulnerability and exploitable habitat. Huang et al. [@4] overview security themes from an SC lifecycle perspective. In each phase, vulnerabilities may be introduced or exploited, just as methods can be used to avoid them, being the phases: security design, security implementation, testing before deployment and monitoring and analysis. The systematization of 10 SC vulnerabilities classes based on Common Weakness Enumerator, provided by [@15], is worth mentioning.

Even though all the proposed problem classifications are different, they can be the basis to design a more complete taxonomy for the critical issues in SC. Also, there are examples where that issue and solution classifications fit well together [@17]. It might be worth considering combining them.

The material extracted for this question was organized considering related work that had categories or taxonomies for solutions[17][@4, @13, @17]. Based on the resulting papers, we defined the categories as in Table LABEL:Table:RQ4-distribution, showing their distribution.

Regarding the proposed solutions, we only included papers that were certain of their classifications. The dominant category was Design Modeling with 19 papers, among them: Event-B, a set-based method [#31]; State-Transition Systems like Colored Petri nets [#28], Markov decision processes [#16], Kripke structure [#15], Dynamic Automata with Events [#8] and state machines [#7]; Abstract Syntax Tree-Level Analysis [#12, #25, #29]; Control Flow Graph [#1, #2, #4, #5, #10, #12, #14, #16, #20, #24, #32]; and Agent-based model [#3], borrowed from Game Theory. Yet in Design realm, Specification has 8 papers, among them: logic like Computation Tree Logic [#7] and Linear Temporal Logic [#15]; Horn Clauses [#24]; Hoare-Style Properties [#25]; and Program Path-Level Patterns like execution traces [#14, #16, #18] and datalog [#4].

In the Verification aspect, the most often approach is Symbolic Execution with 10 articles [#1; #5, #10, #13, #14, #16, #18, #19, #26, #30] followed by: Theorem Proving like Z3 [#1, #5, #10, #18], Isabelle/HOL [#27] and Yices2 [#30], with 7 articles in total; Software Testing, with approaches like unit testing [#19], fuzzing [#16, #19], mutation testing [#21] and Test Case Generation [#32], with 5 papers; Machine Learning, among the approaches there are Random Forest [#9], Imitation Learning [#16], degree-free graph convolutional neural network [#22], temporal message propagation network [#22] and bidirectional long-short term memory with attention mechanism [#23], totaling 4 papers; Model Checking, leveraging tools like NuSMV [#7, #15] and ProB [#31], with 3 papers in total; Abstract Interpretation with 2 papers [#2, #24]; Runtime Verification [#8] and Manual Auditing [#19], each of them with 1 paper.

Note that it is common for Symbolic Execution approaches to leverage a satisfiability modulo theories solver, from the Theorem Prover category. Another consideration is that not only proposals for approaches were included in Table LABEL:Table:RQ4-distribution. We also include leveraged methods and tools used with experimental proposals. Hence, the Verification category contains 23 (71.875%) papers, Design has 20 (62.5%) and Implementation 4 (12.5%) papers [#6, #8, #11, #17], all belonging to its only subcategory, the Design Pattern.

The material extracted for this question was schematized considering that the tool(s)/method(s): (i) are proposed; (ii) have implementation available (studies that no mention how to access or obtain the implementation, even if it exists, wasn’t included); (iii) even if not proposed in the paper, are evaluated in experiments (reproducible cases will be mentioned); (iv) aren’t proposed, but have relevant contributions; and (v) the possibility of conflict of interest is considerable (studies with less than half of the authors being part of a for-profit organization wasn’t included). Table LABEL:Table:RQ5-distribution shows the distribution over this scheme.

As category (i) has a dominant frequency, with 29 papers (87.50%), the category (iv) has the lowest representativeness, with only four papers (12.50%). Even though the proposal for solutions is a category with a larger number, there are considerably fewer papers with available implementations, with only nine articles (28.13%) in that category. About category (iii), it’s worth mentioning papers that facilitate the reproduction of experiments/analyses [#1, #5, #12, #16, #18, #23, #24, #28]. We emphasize that we consider only those papers that have made available/indicated a dataset and tools/methods used to allow public access, being potentially reproducible.

Regarding the contributions presented in (iv) we highlight: the importance of Software Engineering in the area of Blockchain and SCs, being mentioned testing, design patterns and best development practices [#6]. Regarding software testing, an important limitation pointed out in SC are the few options for execution environments for testing. In the case of the Ethereum platform there are only the main (the real), test (for developers) and simulation (local) networks [#6]; In [#18], we mention as the main contributions the security analysis framework to classify security issues in on-chain wallet contracts and the reproducible experiments; and, in [#19], a very interesting flaws categorization, involving 22 categories, is used to outline 246 flaws found in audits. In addition, each of the flaws found is classified according to its severity (potential impact) and difficulty of exploitation. After an in-depth examination of empirical evidence, the authors came to interesting conclusions, such as: unit tests are ineffective in identifying failures, as the correlation between the number of pre-existing unit tests and the audit results was weak; there’s a trade-off between cost/degree of automation and flaws detection with the exploitation of high severity and low difficulty; and many failures can be solved by adopting the ERC20 standard.

In relation to category (v), it is clear that identifying cases of conflict of interest having as criterion that at least half of the authors of an article are part of a for-profit organization is not really a good decisive criterion. Identifying cases like these is not a simple task, after all, conflicting interests are not necessarily financial, even though the existence of a conflict of interest in some cases may be evident. On the other hand, how much this affects the content is generally not clear. Then, category (v) indicates only the possibility of conflict of interest and might be worth remembering this detail during reading.

Summarizing what was seen in the studies addressed, we can understand that the observed vulnerabilities have as common cause the difficulty of detecting incompatibilities between the intended and the real behavior. This is largely due to the platform’s immaturity, which still has high-level resources with complicated and unexpected low-level behaviors for conventional developers. But the technology is considerably new, and it is expected to mature.

Beyond this scenario, in which there is an increase in attacks exploiting vulnerabilities in SCs, and the existence of already published vulnerable contracts is known, Almakhour et al. [@13] mention three reasons to apply formal specification and verification to SCs before their deployment: once an SC is published, any vulnerabilities in its code will become permanent; programmers’ lack of knowledge about proper programming semantics to reflect high-level workflow may lead to misconception issues, resulting in “unfair contracts”; and, many programming paradigms used to develop SCs were not designed to be used in the context of the Blockchain environment [8][@13]. Besides, Liu and Liu [@5] recommended carrying out more research to design more complete formal verification tools, combining formal verification methods with vulnerability analysis methods that complement each other. Observing the results presented in Table LABEL:Table:RQ4-distribution, Modeling and Specification have been extensively studied. The solutions least explored in the research, that were related to Formal Verification are: Runtime Verification (3.13%), Abstract Interpretation (6.25%), and Model Checking (9.38%). It’s an indicative that little was exploited of such techniques to deal with vulnerabilities in SCs, which points us to a direction to be investigated.

A limitation often mentioned in relation to some methods, e.g. symbolic execution and model checking, is path/state explosion [@13, @18], a situation predominantly caused by unbounded iterations. It’s important to remember that, in practice, there are no unbounded iterations because there is a well-defined limit: the gas. Therefore, an adequate modeling of the gas usage by SCs is a promising way to mitigate this limitation of the methods. In this case, simple heuristics can be applied to define values for variables such as the balance of SCs and the cost per instruction.

Regarding to software testing approaches, a considerable part of them have a dynamic nature, requiring the execution of system under test. We known that there is no suitable environment for dynamic analysis. Those that are available range from simulated or real network environments, but each of them with own drawbacks. The resulting papers that mention software testing often wasn’t clear if the context was static or dynamic, so we suggest that future work in this topic should address these details.

With respect to reasoning on security vulnerabilities, attacks often are based on exploitation of more than one vulnerability. In this sense there is a certain similarity between the attacks and the propagation [@15]. In addition, it is highly likely that new vulnerabilities will be discovered only after they have already been exploited, and only after that, low-level properties may be defined to mitigation. So, one may consider anticipating new attacks to handle them. One possibility may be to consider the issue of finding new attacks as an optimization problem where the search space are the infinite combinations of vulnerabilities, applying some metrics, like gas cost.