Contents Introduction
Blockchain technology can be defined as an immutable, shared distributed ledger, spread over thousands of computer systems. Blockchain technology [1] gained implausible attention after the publication of Satoshi Nakamoto’s [2] white paper in 2008. In the white paper, Satoshi gave the solution to the double-spending problem for digital currency in a decentralized P2P [3] network. Dubai appointed a minister in charge of Artificial Intelligence with a vision of becoming the world’s first blockchain-powered government [4].
Saudi Arabia, one of the Middle Eastern countries, recently announced to use blockchain technology [5] for crediting a part of the liquidity to be injected into the banking sector. Distributed consensus building is replacing the role of a trusted third party in decentralized P2P networks [6]. Ethereum is a most generally used Turing Complete [5] blockchain platform, which allows developers to write a smart contract with their own random rules for ownership, transaction format, and state transition functions. Anyone can run an Ethereum node [6], [7] on their machine to participate in the Ethereum blockchain network. Figure 1 describes the layered architecture of the Ethereum blockchain [8].
Blockchain is a chain of immutable [9] blocks and this feature is increasing its popularity worldwide. Figure 2 explains the structure of an Ethereum blockchain node. Each node in the chain is linked to the other using the hash of the previous node. Transactions are hashed in the form of a Merkle tree, which is an important part of the blockchain. It is used for efficient and secure verification of consistency and integrity of large sets of transactional data. The use of Merkle trees in blockchain was introduced by W. Scott Stornetta and Stuart Haber in 1993 [10], but this data structure had already been patented by Ralph Merkle in 1979 [11].
A. Motivation
The motivation for this survey is to serve developers, students, and researchers in the field of Ethereum smart contract security vulnerabilities. The existing surveys did not provide a systematic understanding of Ethereum security issues and their root causes. So, there is a strong requirement for a concise source of systematized information and best practices for understanding Ethereum smart contract security vulnerabilities, their root causes, sub-causes, detection tools, and preventive mechanism.
B. Contributions
We perform a systematic survey of Ethereum smart contract security vulnerabilities, detection tools, real-life attacks, and preventive mechanisms over the period 2016 to 2021. Our work contributes to a detailed understanding of the Ethereum blockchain smart contract vulnerabilities with real-life attacks/examples. Our key contributions are as follows:
Ethereum smart contract vulnerabilities are categorized into three main root causes and seventeen sub-causes categories.
A deep insight into twenty-four Ethereum smart contract vulnerabilities with their preventive methods, detection, and analysis tools is provided under three root causes and seventeen sub-causes.
A brief comparison of detection and analysis tools for these vulnerabilities based on five parameters such as type of tool, input to the tool, type of analysis, implementation language, and availability of the tool to use is provided. This survey cannot be considered complete since Ethereum blockchain smart contract technology is constantly expanding at a very fast speed.
C. Related Work
Recently, many researchers have published review papers in this field with different point of view. Li et al. [127] surveyed 20 types of vulnerabilities with attacks and defense mechanisms, without marking a difference in the type of blockchains like Bitcoin or Ethereum. Zhu et al. [128] reviewed 11 security vulnerabilities with attacks and defenses but their survey was limited to the bitcoin blockchain platform only. Saad et al. [129] surveyed about attacks and defenses but not about the vulnerabilities. They discussed attacks on the blockchain and their prevention mechanism. Harz et al. [130] discussed smart contract programming languages and their verification tools and methods but did not discuss more about security vulnerabilities. Angelo et al. [54] discussed about smart contract security analysis tools irrespective of their provenance. They discussed 27 tools for analyzing Ethereum smart contracts. Luu et al. [10] studied security vulnerabilities but did not discuss their detection and defense mechanisms. They presented a security analysis tool, named Oyente, which is based on formal verification. They analyzed Ethereum smart contracts for 4 to 5 security vulnerabilities using this tool. Atzei et al. [48] presented some of the security vulnerabilities and their related real-world attacks. They discussed the Ethereum smart contract security vulnerabilities in the context of common programming issues. Tang et al. [144] reviewed Ethereum smart contract vulnerabilities detection tools in three categories such as static analysis, dynamic analysis, and formal analysis. They considered 15 different security vulnerabilities and presented related detection tools. They suggested to use machine learning methods to analyze smart contracts. They discussed only 15 security vulnerabilities and missed several other important vulnerabilities. H. Chen et al. [145] discussed Ethereum smart contract vulnerabilities, their defenses, and attacks in relation with Ethereum smart contract architecture layers. They presented a good survey by giving good insight of each vulnerability but they did not cover the detection tool. T. Durieux et al. [145] discussed evaluation of 9 automated analysis tools on 47587 Ethereum smart contracts. In their work they mainly discuss about tools comparison only.
The above-mentioned surveys did not cover all Ethereum smart contract security vulnerabilities and also some of the surveys missing details about detection tools and defense mechanisms. A survey can not be considered complete until it covers all the problems of their area. To fill this research gap, we present 24 security vulnerabilities with their detection tools, defense mechanisms, and real-time attacks.
D. Paper Outline
The remainder of this paper is structured as follows: Section II discusses the survey methodology, Section III reviews the key concepts, functionality, and structure of the Ethereum blockchain smart contract. Section IV presents a review of vulnerabilities in the Ethereum smart contract, categorized under three main root causes named Solidity programming language, EVM, and Ethereum blockchain design.These are further categorized into 17 sub-causes. This section briefly describes vulnerabilities with their preventive methods and detection tools against some well-known attacks. Section V gives a summary of Ethereum smart contract analysis tools to analyze the vulnerabilities based on the type of tools, input to the tool, type of analysis, implementation language, and availability of the tool to use. Section VI describes challenges and outlines future directions. Finally, Section VII concludes this survey by presenting a summary of the contributions.
Survey Methodology
In this section, various research questions and selection criteria of related articles are presented.
A. Research Questions
Several blockchain smart contract development platforms are available with different-different characteristics, opportunities, and challenges. Developers can select blockchain platforms as per their convenience from Ethereum [3], Hyperledger [12], Cardano, EOS [13], TRON [14], Steller, NEO, Waves, Tezos [15], NEM, etc. Ethereum is the most used prominent blockchain platform, so in this paper, we surveyed the vulnerabilities present in the Ethereum smart contract. The literature deficiencies are a definite and organized review of the current Ethereum blockchain smart contract vulnerabilities. It was the main reason for conducting this research. Systematic study methods of Kitchenham et al. [16] and Peterson et al. [17] are followed to define the following research questions:
RQ1: What are the existing vulnerabilities in Ethereum Smart Contracts?
RQ2: What are the main root causes of vulnerabilities in Ethereum Smart Contracts?
RQ3: What are the sub-causes of vulnerabilities in Ethereum Smart Contracts?
RQ4: What are the detection tools of vulnerabilities in Ethereum Smart Contracts?
B. Process Adopted for the Selection of Related Articles
To address these questions, 454 research articles are identified from peer-reviewed scientific research databases. Out of these, 335 articles are excluded and 119 articles are included for the final survey based on the exclusion and inclusion criteria mentioned in Table 1.
We applied keyword searching to find Ethereum smart contract security vulnerability-related articles for our initial search. We performed this search in five peer-reviewed scientific databases like Elsevier Science Direct, IEEE Xplore Digital Library, Springer Online Library, ACM Digital Library, and Google Scholar. Our main focus is on Ethereum smart contracts, so we selected articles containing Ethereum in their abstracts. Literature articles identification, exclusion, eligibility, and inclusion methodology are shown in Figure 3.
Literature articles identification, exclusion, eligibility, and inclusion methodology.
We selected articles from conference proceedings, journal articles, repositories, and others like book chapters, etc. Selected articles bifurcation is shown in Figure 4 as per year of publication and scientific database.
Selected research articles bifurcation according to the year of publication and scientific database.
Ethereum Blockchain Smart Contract
Smart Contract [18] is one of the use cases of blockchain technology. It was introduced by Nick Szabo [19] in 1997. It is a small piece of self-executable [20] program code. It is deployed on the blockchain and used for auto enforcement of terms and conditions between two untrusted parties. Consensus protocols [5], [21] are used for the precise implementation of smart contracts, otherwise, the effect of the same will be nullified. Figure 5 elaborates the structure of the Ethereum Smart Contract [12], [24].
Ethereum smart contracts’ main components are functions, events, and state variables written in solidity [3]. Solidity programming language’s Turing completeness [5] makes it perfect for writing a smart contract. After compilation, the smart contract code is converted into EVM byte code [23], [24] and stored on Ethereum blockchain by a contract creation transaction. After a successful contract creation transaction, the smart contract is recognized by a unique contract address.
An Ethereum Smart Contract account consists of [25] its executable code, contract address, a state consisting of private storage, and balance in terms of virtual coins (Ether). A smart contract can be invoked using a contract invoking transactions to its inimitable address, with some parameters like invocation data and payment in terms of ether as transaction fees (Gas) [26]. Ethereum Virtual Machine or EVM [27] is a Turing complete stack-based virtual machine. It provides a run-time environment that is isolated from the network to execute the smart contract code. Computation in EVM [28] is essentially bounded by transaction fees. Smart contracts contain ethers (a type of cryptocurrency) as their balance. Ethers can be sent to other contracts for executing the smart contract. It is a very crucial task because any type of vulnerability can be the reason for the loss of millions of Ether [28]. A smart contract cannot be changed after the deployment [29] on the blockchain due to the immutable [30] nature of the blockchain. Therefore, security vulnerabilities and best practices should be considered by the smart contract developers during the coding of smart contracts.
Ethereum Smart Contract Vulnerabilities and Preventive Methods
In this section, we have reviewed Ethereum Smart Contract vulnerabilities [9], [31]–[45], [122], [123], [131], [132], [138]–[142] with some well-known attacks/example [32], [46]–[49], detection tools [30], [37], [50]–[58], [125], [133]–[137], [143], and their suggested preventive methods [30], [47], [59]–[63], [124], [126]. Researchers classified these vulnerabilities based on different criteria such as seriousness, root cause, flaws in solidity, security flaws, privacy flaws, performance flaws, flaws in EVM [27] byte code, and blockchain [64] characteristics. We have divided these vulnerabilities under the following three main root causes:
Root Cause 1: Solidity Programming Language (SPL)
Root Cause 2: Features of Ethereum Virtual Machine (EVM)
Root Cause 3: Design features of Ethereum Blockchain (EBD)
We further categorize these vulnerabilities in sub-cause categories, which are highlighted in Figure 6.
Root cause and sub-cause categorization of Ethereum smart contract vulnerabilities.
For ease of use and proper understanding, Figure 7 explains the nomenclature used to denote the vulnerabilities. Vulnerabilities in each root cause category are numbered from 1 to
Figure 8 elaborates the Ethereum smart contract vulnerabilities, numbered starting from 1 to the total number of vulnerabilities in the respective root cause category.
In the following section, we present each vulnerability in detail according to its root cause, sub-cause, detection tool, and its prevention mechanism. Tables 2 to 24 highlights summarized details like sub-cause, attacks, detection tools related to each vulnerability as mentioned in Figure 8.
SPL -V1 (Denial of Service With Block Gas Limit) [26]: Each block in the Ethereum smart contract has an upper limit on the amount of gas (10,000,000 gas [67]) that can be spent for computation. Thus, if the gas spent on any transaction exceeds this block gas limit, then this leads to denial of service and the transaction will fail. This is the case with the unknown size of arrays which grow over time.
Preventive Method: Rather than modifying these arrays completely at once in a single block, several blocks should be taken. Because taking several blocks will break a single transaction into multiple transactions, hence it reduces the gas required for each transaction. This will reduce the risk of exceeding the block gas limit, and hence prevent denial of service.
SPL -V2 (Denial of Service With Failed Call) [70]: External calls in a smart contract can fail accidentally (due to programming errors) or intentionally (by an attacker). In a situation when an attacker combines several calls in a single transaction and executes in a loop, then this can prevent other smart contracts nodes to interact with it. This scenario is shown in the Figure 9 solidity code.
Preventive Method: The contract logic to handle failed calls should be executed in such a way that several calls of Ether transfer must not be combined in a single transaction with the assumption that the external calls will always fail to choose ‘pull’ over ‘push’ for external calls. It should implement contract logic to handle failed calls.
SPL-V3 (Randomness Using ‘Block Hash’) [9], [46]: Sometimes randomness is required in operations and block hash can be used for this purpose. However, it can be manipulated like timestamp because the same can be predictable by the miners. The use of ‘block hash’ as a source of randomness is shown in Figure 10 solidity code.
Preventive Method: The block hash can be read by any other transaction within the same mined block. If the attacker is also a miner, then it can be manipulated and worse can happen. Therefore, the external sources of randomness should be used, for example, Oracle, RNG [61], RANDAO, etc.
SPL -V4 (‘tx.origin’ Usage) [9]: This global variable of solidity returns the address of the transaction initiator, which in turn attracts the adversaries to imitate the initiator that makes the contract vulnerable. The victims of this attack are wallet-type smart contracts.
Preventive Method: For security reasons, the origin address should not be passed as a parameter, because an attacker can easily figure out the right address to perform spoofing. Therefore, it is suggested to use ‘msg.sender’ in place of ‘tx.origin’ to check the authorization of ownership, because tx.origin is the original sender of the transaction but msg.sender is the immediate sender. One more point to consider is to not use address.call.value(amount)(); instead, use address.transfer(). Because address.transfer throws an exception in case of failure and stipend requirement for executing address. The transfer is 2300 ether, which means assaulting contracts would not have enough gas for additional calculation.
SPL -V5 (Integer Overflow/Underflow) [47], [72]: This kind of situation will occur when the value in a calculation exceeds the lower or upper range of the variable size type, so cannot be expressed by that type. This can be the case with smaller data types. If the balance will be at the upper limit uint value
Preventive Method: To tackle integer overflow and underflow issues, arithmetic operations should be implemented very carefully by comparing the operators and operands before the operation. It is suggested to use assert(), require() functions, and ‘SafeMath.sol’ [38] library for arithmetic functions.
SPL-V6 (Re-Entrancy) [74], [76], [77]: It is also known as a recursive call attack. In re-entrance vulnerability, a malicious contract calls back into the calling contract before the first invocation of the function is finished. Therefore, due to this recursive nature of the call, the malicious user can do multiple repetitive withdrawals without affecting his balance. An attacker stole 60 million US dollars by utilizing this vulnerability in the Decentralized Autonomous Organizations (DAO).
Preventive Method: For protecting against re-entrancy attacks, a reliable method can be used such as the “Check-Effect-Interaction pattern”. This defines the order in which we should structure our functions to assure all internal state changes before the next call. After resolving all state changes, the function should be allowed to interact with other contracts. To prevent cross-function re-entrance attacks, mutex locks are suggested to use. Any contract’s state can be locked using a mutex lock and can only be modified by the owner of the lock. It prevents the recursive call of ‘withdraw function’ by an attacker. OpenZeppelin has its mutex implementation called as Re-entrance guard which acts as a re-entrancy lock.
SPL -V7 (Mishandled Exception) [79]: When a contract is called by another contract and an exception or error is raised in the Calle contract. But if the same might not be reported to the Calle contract, then it might lead to threats. Therefore, it can attract the attackers to execute the malicious code in the contract.
Preventive Method: An exception in the callee may or may not be propagated to the caller depending on how the function was called. Exception handling operators should be used to avoid such types of situations. The return value of functions must always be checked and an exception should be thrown.
SPL -V8 (Gasless ‘Send’) [26]: Gas is required in Ethereum smart contract as an execution fee. When ethers are transferred to a smart contract via send and if the fallback function in the Calle contract has the maximum gas limit [80] of twenty-three hundred units, then an out-of-gas exception can be thrown. If this exception is not handled properly, then malicious users can take benefit from this vulnerability by keeping non-transferred ethers wrongfully even though it was assumed to give them away. This scenario can be understood in Figure 11. If the pay function of contract A is called with the address of contract B. Then contract A is supposed to send ’X’ wei (the smallest denomination of ether) to contract B. If the fallback function of contract B revert due to insufficient gas and the contract behaves maliciously then it will keep those ’X’ wei to itself.
Preventive Method: Gas consumption limits change regularly because of the change in the transaction fees. Therefore, an exception should be thrown properly if failure happens due to gas consumption. The fallback functions should be designed in such a way that they do not require too much gas for execution or are less expensive to execute. It will mitigate the purpose of failing and the cost of executing the contract.
SPL -V9 (Gas Costly Pattern) [79], [83]: Every instruction in Ethereum smart contract requires gas (Ethers) as execution fee. Under-optimized [40] smart contracts can contain unnecessary and irrelevant code or expensive patterns, which can cost a lot of execution fees. Chen et al. [42] identified seven programming patterns and developed a tool ‘GASPER’ to determine such types of patterns.
Preventive Method: Chen et. al [42] developed a tool named ‘GASPER’, which performs the following operations to detect gas costly patterns:
Do a depth-first search and detect the dead code by scanning the control flow graph.
Detects the opaque predicates by executing the smart contract symbolically.
Detects expensive loop operations like SLOAD, SSTORE, and BALANCE.
These types of gas costly patterns should be identified and should be replaced by gas efficient patterns for optimizing the execution cost.
SPL -V10 (Call to the Unknown) [54]: The cause of this vulnerability is the execution of the fallback function under certain conditions. The function with the given signature does not exist. This can happen due to the invocation of certain functions of Calle’s contract or the transfer of ether to another smart contract.
Preventive Method: Call to unknown contracts can be very risky, so the following points should be considered:
Be vigilant while making external calls
External calls to unknown addresses should be performed as the last operation in a localized function or piece of code execution.
Unknown contracts should be marked unsafe
Use checks effect interaction pattern to avoid state changes after an external call
SPL -V11 (Hash Collision With Multiple Variable-Length Arguments): ‘abi.encodePacked()’ is a nonstandard packed mode that is mainly used for indexed packed parameters. ‘abi.encodePacked()’ can lead to a hash collision in some specific situations due to multiple variable-sized parameters. ‘abi.encodePacked()’ packs elements in order regardless of their original order in the array, which can be exploited by the attacker in signature verification by changing the position of the elements.
Preventive Method: The following points should be considered to prevent this vulnerability:
Rather than passing arrays as parameters, pass a single value.
Array’s positions are modifiable, so allow arrays of fixed length only.
Use abi.encode() instead of abi.encodePacked()
SPL -V12 (Insufficient Gas Griefing) [9]: Smart contracts that accept data from external sources and use the same in a subcall to another contract, are vulnerable to insufficient gas griefing attacks. Because in case of subcall failure [85], the whole transaction can be reverted. The attacker can effectively censor transactions by using just enough gas [86] to execute the transaction, but not enough for the sub-call to succeed. This scenario is shown in Figure 12 solidity code.
Preventive Method: To prevent this vulnerability, trusted users should be allowed to relay transactions. A type of logic should be applied to check whether a sufficient amount of gas is provided or not. Relayers can be encouraged by a reward to give the right amount of gas for a successful transaction.
SPL -V13 (Unprotected Ether Withdrawal): Ether can be withdrawn by attackers due to missing or inadequate access control. Improper naming of functions intended to be a constructor and constructor code can be accessed by malicious users to reinitialize the contract.
Preventive Method: Access control should be implemented in such a way that only authorized users can access the same. The function’s naming should be done very carefully so that the function’s name should not be intended to be a constructor. Because the constructor code, which will be ended up in the run time, byte code can be called by anyone to initialize the contract again.
SPL-V14 (Floating Pragma) [91]: Different compiler versions can be used to compile the solidity smart contract. But compilation with an outdated compiler might introduce a bug and can affect the smart contract system. At the time of deployment, the compiler version of the smart contract should be the same as that testing time.
Preventive Method: Smart contracts can be compiled using different compiler versions. But if an older version of the solidity compiler is used to compile the smart contract, leads to errors in the form of bugs. A smart contract must be compiled on the same solidity compiler on which it has already been tested during the creation phase. Before deployment on the blockchain, the compiler version mentioned in the solid source code of the smart contract must be ensured for similarity and as a preventive technique Pragma version should be locked before deployment
SPL -V15 (Function’s Default Visibility) [9], [46]: In solidity, visibility specifiers are used to make functions external, public, internal, or private. Incorrect use of these visibility specifiers can make smart contracts vulnerable and attract attackers.
Preventive Method: It is an acceptable practice to consistently determine the visibility of all functions in a contract, regardless of whether they are intentionally public. Recent versions of Solidity presently show warnings during the compilation of functions that have no explicit visibility set, to help empower this training. So as a preventive method, special attention is required while using them.
SPL-V16 (Delegate Call) [92]: For calling another contract’s function, the target function’s ABI (Application Binary Interface - the standard way of interaction with smart contracts in the Ethereum blockchain environment) is required. If ABI is known then the target function’s signature can be used directly for calling purposes. But what if we don’t know the target function’s ABI, then we can use the “DELEGATECALL”. For example, suppose there is contract A and contract B. The contract A delegate call to contract B’s function. If the user calls contract A then contract A delegate call to contract B and the function would be executed. But in this scenario, all the state changes will be reflected in contract A, not in contract B. The context preserving nature of ‘DELEGATECALL’ can create vulnerabilities when it runs in the context of other applications. It can lead to unexpected execution such as self-destruction and balance loss of contracts.
Preventive Method: “Library” keyword is provided in the solidity programming language to execute library contracts. This guarantees that the library contract is stateless and non-self-destructible. Stateless libraries help in mitigating several issues related to storage context. Stateless libraries additionally forestall assaults whereby aggressors change the condition of the library straightforwardly to influence the contracts that rely upon the library’s code. So as a preventive method, more attention must be paid while utilizing “DELEGATECALL” especially in the calling context of calling contract and library contract. For ensuring the safety of storage context, Delegate calls must be used to call trusted contracts only.
SPL-V17 Unprotected ‘Self-Destruct’: This vulnerability is named because of the self-destruct opcode. Before deleting the contract permanently, this opcode can transfer the ethers of the contract to a predefined contract. If the access control is not given properly, the malicious user can destroy the contract to snip all ethers of the contract.
Preventive Method: This vulnerability regularly emerges from the misuse of ’this.balance’. Whenever we send ether to any contract then called contracts fallback function is called. But the fallback function is not called if the ether transfer is initiated using “selfdestruct()” function call. Self-destruct functionality should be removed from the smart contract unless it is compulsorily required. And if there is a need to use the functionality of “selfdestruct()” then it must be used in the multi-signature scheme environment. Because in multi-signature environment, the execution of “selfdestruct()” must be approved by multiple parties.
EVM-V1 (Immutable Bugs or Mistakes) [9], [46]: It is related to the immutability of the Ethereum blockchain. Because once a contract is deployed on the blockchain, it cannot be altered due to the immutability feature of blockchain. It is against the legal law that allows being modified and terminated. However, it may lead to problems if the deployed smart contract contains bugs because after deployment it is impossible to alter.
Preventive Method: Immutability of Ethereum smart contracts creates several issues. Marino et al. [94] tackled this vulnerability by presenting a set of standards taken from legal contracts and redefined to be fit in the context of Ethereum smart contracts. This set of standards enable Ethereum smart contracts to be changed or terminated whenever required as per the need. Marino et al. demonstrated their success by applying this set of standards in the scenario of the Ethereum smart contract.
EVM-V2 (Ether Lost in Transfer) [31]: Ethers can be transferred to a contract to its unique address, but the contract must not be orphan, because in that case the transferred ether will be lost forever. There is a mechanism to revert the ether transfer.
Preventive Method: Since the lost ether cannot be recuperated, developers need to physically guarantee the rightness of the recipient addresses. The address of the recipient contract must be verified manually to avoid the loss of ether in the transfer.
EBD-V1 (Timestamp Dependency) [9]: It is classified as a security vulnerability by Maher and Alharby [96]. It leads to a vulnerable situation when the triggered condition to execute the transaction is the block timestamp, because the dishonest miners can utilize the block timestamp value in an unethical way.
Preventive Method: Luu et al. [8] suggested to use block number instead of block timestamp. Because the block number cannot be altered by the malicious miner. Therefore, it is suggested not to assign a block timestamp to a variable in the smart contract code.
EBD-V2 (Lack of Transactional Privacy) [96], [97]: Transactions balance details of the users are publicly available. But, users want that their financial details and transactions should not be visible to others. It may limit the users of smart contracts since attackers can monitor the transaction-related details of users. Attackers can use this information for various kinds of unethical uses.
Preventive Method: Watanabe et al. [21] suggested the encryption of the smart contracts before deploying them on the blockchain. Kosba et al. [97] developed a tool to create a privacy-preserving contract. They included the important features of privacy protection not only in Ethereum blockchain-based smart contract applications but also for all types of blockchains. As a preventive method to this issue, they implemented a decentralized smart contract framework, Hawk, which does not store financial transactions in the blockchain and spares the developers from implementing any cryptographic function.
EBD-V3 (Transaction Ordering Dependency) [54]: This vulnerability is related to the execution order of two dependant transactions that are invoking the same smart contract. A malevolent user can utilize this vulnerability to attack if the transactions are not executed in the proper order. The order of transaction execution is decided by the miners, but if the adversary is the miner itself, then this will be a very disastrous situation.
Preventive Method: Natoli et al. [100] used Ethereum-based functions (e.g., SendIfReceived) to enforce the order of transactions. Luu et al. [10] recommended a guard condition such that “a contract code either returns the expected output or fails”. To defend against Transaction Ordering Dependancy attacks, Shuai Wang et al. [56] suggested a pre-commit scheme
EBD-V4 (Untrustworthy Data Feeds) [99]: Some smart contracts need data feeds from outside the blockchain, but there is no guarantee that the external data source is trustworthy. So, in the case when an attacker is intentionally sending wrong information to fail the smart contract operation then it will be a hazardous situation.
Preventive Method Zhang et al. [99] developed a tool named Town Crier (TC). TC works as a trustworthy more mediate in between the external source and a smart contract. In other words, it acts as an authenticator and provides data feed privacy using encryption. Town Crier tool comprises a Town Crier smart contract that dwells on the blockchain, and a Town Crier worker which lives exterior the blockchain. The data feed request can be sent to the Town Crier contract by the client contract, which finally will send to the Town Crier worker. The Town Crier worker at that point speaks to outside information sources using HTTPS to get the information. After getting the necessary information, the worker will advance those feed requests to the Town Crier contract, which finally will ssend to the client contract.
Figure 13 depicts the timeline discovery of famous attacks on Ethereum blockchain-based smart contracts. The figure depicts the attack’s sub-cause, its related vulnerability, any financial loss, and the resolution and suggestions.
Ethereum Smart Contract Analysis Tools
Smart contracts need to perform as intended because bugs may lead to terrific losses. Security analysis tool [30], [37] [53], [92] [100] are necessary to analyze the security vulnerabilities of the smart contract because after the deployment of the blockchain we are unable to alter the smart contract due to the immutability feature of blockchain.
We have already described an analysis tool for each vulnerability in Section III. Several surveys are presented about tools to analyze Ethereum smart contracts based on different parameters. Table 25 highlights a summary based on following parameters:
Input to the tool byte code or solidity code: Some of the tools directly work with solidity code, but due to the incompatibility of solidity code on different platforms, some tools use EVM byte code [54] for analysis.
Type of analysis (static or dynamic): Some of the tools analyze the code dynamically during execution, while some analyze the code without executing the code.
Type of tool (academic or company): Some of the tools are designed for academic purposes. Some of them are developed by private companies while some of the tools like Remix and Oyente are community tools. We have mentioned the respective company name if the tool is company-made.
Implementation language: The majority of the tools are implemented in Python. Some of them in JAVA, C++, etc.
Public Availability of the tool: Not all tools are publicly available. Some of them are private that developed by companies. Some of them are not released by the developers, only the methodology is shown in their research papers.
Discussion
In this systematic review, we have discussed Ethereum smart contract security vulnerabilities, detection tools, real-life attacks, and preventive mechanisms. For this purpose, we have referred 119 research articles and some online resources over the period 2016 to 2021. The comparison among the related works are then presented to evaluate various shortcomings with the existing techniques. Finally, various future directions are also discussed in the field of the Ethereum blockchain-based smart contract that can help the researchers to set the directions for future research in this domain.
A. Comparison with Related Work
This paper is an extension of the existing surveys [10], [48], [54], [127]–[130], [144]–[146] on the Ethereum smart contract security vulnerabilities, well-known attacks, detection tools, and their suggested preventive methods. This work encompasses more detailed and systematic aspects for filling the research gaps related to systematic information source for Ethereum smart contract security vulnerabilities. We categorized the security vulnerabilities into three main root cause and seventeen sub-causes. This paper presents a deep insight into each vulnerability as well as its detection tools, real life attacks and prevention mechanisms. Table 26 highlights the comparisons between the present survey with the existing surveys on Ethereum smart contract vulnerabilities. It is found that the present survey covers more features as compared to the existing survey articles. Additionally, we have considered more recent literature to highlight the future research directions.
B. Limitations
Mostly our discussion is related to Ethereum blockchain-based smart contract security vulnerabilities. As research on the Ethereum blockchain contributes most of the research literature but other blockchain platforms like Solana, EOS, and Hyperledger Fabric, etc. are also having important concerns. We have not discussed security vulnerabilities related to blockchain platforms other than Ethereum. We leave the same for future work.
C. Ethereum Blockchain Design Challenges
Blockchain is having an image problem because it is mostly connected with cryptocurrency and assumed as a world of frauds and attackers. Smart contract technology is growing at a very fast speed. Ethereum blockchain design and EVM features pose several security challenges [38], [117]–[121]. However, the following are some of the security challenges due to Ethereum’s blockchain design.
Verifier’s nobility: In the transaction verification process, if the majority of verifiers are dishonest, then invalid transactions can be approved and added to the chain of the block.
Selfish mining: Miner’s honesty plays an important role in the mining process. An ill-intended miner can work as an adversary and affect the honest mining process.
Immutability: It does not allow editing a buggy smart contract after deployment on the blockchain. There should be some mechanism to alter the buggy or faulty smart contracts.
Transaction processing time: Transaction processing time in the Ethereum blockchain makes smart contract execution very slow, which affects the efficiency.
Lack of standards: Limited number of standards related to smart contracts increases the difficulty in the maintenance process of smart contracts.
Lack of Concurrency: Concurrency is not supported by Ethereum. Thus, to ensure security in the blockchain construction process, each blockchain node has to store Ethereum’s current state and the whole transaction history. By this process, fifteen transactions per second are supported by Ethereum, which leads to serious scalability problems.
D. EVM Features Challenges
EVM, that is, Ethereum Virtual Machine, provides a virtual environment for the smart contract execution.
EVM stack size: Maximum stack size in EVM is up to 1024 items with 256 bits for each. It increases the chances of vulnerability. The restricted stack size can without much of a stretch, lead to weaknesses and increase the trouble of creating complex applications.
Gas consumption Limit: As the number of users increases in large-scale projects, the number of transactions will also increase accordingly. This will increase the gas consumption of the contract. Because the gas limit cannot be changed, then there are more chances of “out-of–of-gas error”.
Above mentioned open issues should be investigated to develop safe smart contracts.
E. Future Research Directions
In the future, more features and functionalities will be added in Ethereum blockchain smart contracts that may lead to more security flaws. Therefore, the present vulnerability detection tools should be enhanced and new detection tools should be developed for the detection and mitigation of new security flaws. Further work could be led to finding the unknown vulnerabilities and how we can forestall them. For example, have a self-protection (revocable) mechanism for the smart contract to consequently play it safe if an attack happens. This is essential because, after the deployment on the blockchain, the smart contract is immutable. As the size of Ethereum projects increases over time, then it will pose scalability and new security issues. Thus, these challenges should be considered in the near future on the smart contract.
Conclusion
We have presented a systematic review of the Ethereum smart contract security vulnerabilities including well-known security attacks with their preventive methods. We discussed the vulnerabilities according to their root cause, sub causes. We systematically presented the well-known attacks and their detection and analysis tools. Ethereum smart contract analysis tools are highlighted based on five parameters such as type of tool, input to the tool, type of analysis, implementation language, and availability of the tool to use. It has been found that due to the security flaws in Ethereum smart contracts, it is vulnerable to attack from adversaries. Smart contract deals in digital assets, so a single error or security flaw can cause a loss in millions. Therefore, the smart contract developers must consider such vulnerabilities and use best practices and principles while creating safe smart contracts. We have also provided insights into security challenges and future research directions for developing more robust advanced and robust vulnerabilities detection tools.