Smart Contract Security: A Software Lifecycle Perspective

Smart contract security is an emerging research area that deals with security issues arising from the execution of smart contracts in a blockchain system. Generally, a smart contract is a piece of executable code that automatically runs on the blockchain to enforce an agreement preset between parties involved in the transaction. As an innovative technology, smart contracts have been applied in various business areas, such as digital asset exchange, supply chains, crowdfunding, and intellectual property. Unfortunately, many security issues in smart contracts have been reported in the media, often leading to substantial financial losses. These security issues pose new challenges to security research because the execution environment of smart contracts is based on blockchain computing and its decentralized nature of execution. Thus far, many partial solutions have been proposed to address specific aspects of these security issues, and the trend is to develop new methods and tools to automatically detect common security vulnerabilities. However, smart contract security is systematic engineering that should be explored from a global perspective, and a comprehensive study of issues in smart contract security is urgently needed. To this end, we conduct a literature review of smart contract security from a software lifecycle perspective. We first analyze the key features of blockchain that can cause security issues in smart contracts and then summarize the common security vulnerabilities of smart contracts. To address these vulnerabilities, we examine recent advances in smart contract security spanning four development phases: 1) security design; 2) security implementation; 3) testing before deployment; and 4) monitoring and analysis. Finally, we outline emerging challenges and opportunities in smart contract security for blockchain engineers and researchers.


I. INTRODUCTION
As a decentralized and tamper-proof ledger, blockchain has been portrayed as an ultimate security technology in many respects, such as artificial intelligence (AI) [1]-[4], big data [5], [6], Internet of Things (IoT) [7]- [9] and digital property (e.g., Deepfake [10] and Proof of delivery [11]). However, blockchain technology still faces numerous security issues [12]- [14]. Especially with the increase of decentralized applications (Dapps) running on blockchains, smart contract security is becoming more and more sig- The associate editor coordinating the review of this manuscript and approving it for publication was Francisco J. Garcia-Penalvo . nificant (see Figure 1) and has attracted much attention from researchers [16]- [19]. Although the consensus protocol ensures the faithful execution of smart contracts, smart contracts still have many security issues. These security issues are especially severe in public blockchains because the environment where smart contracts execute is mostly decentralized, and a vulnerable smart contract is hard to patch. For this reason, an attacker in the DAO [20] was able to exploit a bug in a smart contract to repeatedly siphon off money, which caused the investors to lose approximately $50 million in cryptocurrency value. Therefore, effective security solutions for smart contracts are urgently needed. This paper proposes a specific software lifecycle approach to rationalize how to tackle the issue of smart contract security. Compared to previous works [16], [19], [21] concerning this topic, our paper excels in several aspects.
1) Previous works have focused only on vulnerability detection. Our research has a wider focus and includes not only vulnerability detection but also security modeling, security monitoring, bug bounties, etc. Specifically, our paper offers a novel perspective for understanding smart contract security in a visualized manner, which enables developers to track, control, and avoid blockchain project risks systematically.
2) By considering smart contract security as a new type of software weakness mitigation in a blockchain setting, our paper systematically analyzes the causes of security issues in smart contracts for the first time.
3) Most previous works surveyed smart contract security only in Ethereum. However, our research outcome has broad impact and is not limited to Ethereum. Without precedent, we have compared security vulnerabilities of smart contracts in Ethereum [22] and Fabric [23], two widely used blockchain platforms, from three aspects: programming languages, blockchain platforms, and misunderstanding of common practices. The same comparison can be extended to other blockchain platforms.
The rest of this paper is organized as follows. Section II analyzes the causes of security issues in smart contracts. A discussion of security vulnerabilities in different platforms and anomalous activities in smart contracts is presented in Section III. Section IV examines the existing solutions of smart contract security in terms of security themes from the perspective of the software lifecycle. Then, the emerging challenges and opportunities are proposed in Section V. Finally, Section VI concludes the paper.

II. ANALYSIS OF SECURITY ISSUES IN SMART CONTRACTS
A smart contract can be assumed as a mapping of a legal agreement in reality. Once a smart contract is confirmed by the consensus protocol and submitted to the blockchain, it will be run in terms of the prior negotiation without the interference of any third party. Owing to success in Ethereum [22], smart contracts have been widely supported by most of the current blockchains, such as Fabric [23], Corda [24], and EOS [25]. However, several key features of current blockchains may cause security issues in smart contracts.
1) Decentralization and tamper-proofing are doubleedged swords. Blockchain is decentralized and tamperproof. Moreover, smart contracts can be developed and deployed by pseudonymous malicious people (only public addresses or public keys are known to others in most public blockchains). Therefore, a vulnerable smart contract is hard to patch and can easily become out of control once deployed.
2) Open-source code and public ledgers. Generally, a smart contract is open-source. Contract transactions and data may be visible to an adversary. The exposure leads to the fact that smart contract vulnerability is easy to exploit.
3) Immaturity of blockchain platforms and smart contract languages. Dapps development in the blockchain is different from traditional application development. Developers of Dapps need a thorough understanding of the operations on the blockchain. Otherwise, the intention of smart contract developers is often inconsistent with smart contract implementation. Moreover, the blockchain technologies are evolving so fast that design flaws may exist in blockchain platforms or smart contract languages. Developers of Dapps are always confronted with changing platform features. Thus, common software weaknesses [26] (we have illustrated some weaknesses related to smart contract security in Table 1) may be amplified on blockchain platforms. 4) Misunderstanding of common practices. Smart contract developers often do not thoroughly understand the principles of some practices of the blockchain. For example, a misunderstanding of cryptography may lead to security being for granted, which does not facility true security.

5) Pseudonymous transactions.
On most of the public blockchains, transactions are pseudonymous. This feature also stimulates criminal activities such as money laundering [27] or Ponzi schemes [28] in smart contracts.
Smart contracts are often used to transfer financial assets. Security issues in smart contracts may lead to a large number of financial losses. An example is the DAO hack in Ethereum [20], which caused a hard fork of the blockchain to nullify the malicious transactions. Therefore, the risk of security issues in smart contracts is generally more severe than that in traditional applications.

III. CLASSIFICATION OF SECURITY ISSUES IN SMART CONTRACTS
Different vulnerabilities may exist in different blockchain systems. In this section, we mainly discuss security vulnerabilities in smart contracts on Ethereum [22] and Fabric [23]. As the two most widely applied blockchains, Ethereum and Fabric adopt two different but representative technologies in smart contract implementation. Ethereum utilizes the domain-specific language (DSL) Solidity to write smart contracts, whereas Fabric uses a general-purpose programming language (e.g., Go or Java) to develop smart contracts (also called chaincodes in Fabric). Different platforms and languages cause these two types of smart contracts to exhibit distinguishing security vulnerabilities.

A. SECURITY VULNERABILITIES IN ETHEREUM SMART CONTRACTS
Based on the previous works of [16], [19], [21], [29], [30], we summarize primary security vulnerabilities in Ethereum smart contracts in Table 2. We think that these vulnerabilities arise from three aspects: the Solidity language, the blockchain platform, and a misunderstanding of common practices. We relate these vulnerabilities to common software weaknesses. In Table 2, we offer a preliminary understanding of security vulnerabilities in Ethereum smart contracts. In the following, we will restate these vulnerabilities, explain their rationale, and propose simple schemes to fix them. 1) Reentrancy. A reentrancy attack may occur when a contract calls an external contract that takes over the control flow and calls back into the calling contract before the first invocation is finished. This attack may have an unexpected consequence. As shown in Figure 2, when an external contract calls the function withdrawBalance, the function withdrawBalance will call the fallback of msg.sender when calling require. In turn, the fallback function can call into withdrawBalance again. Thus, the contract SimpleReentracy will send the balance to msg.sender repeatedly because the assignment statement ''userBalances [msg.sender] = 0'' has not been executed thus far.
Fix Scheme. Do not call an external function until the developer has done all of the internal work he needs to do.
2) Unprotected selfdestruct. This vulnerability arises from a logic flaw in Solidity. A smart contract incorrectly permits access to an unauthorized actor. For example, due to missing or insufficient access controls, malicious parties can call the function selfdestruct (see Figure 3) to destruct the contract. Thus, the balance in the destructed contract will be transferred to an unauthorized account.
Fix Scheme. Consider removing the selfdestruct functionality unless it is needed.
3) Integer underflow (overflow). An underflow (overflow) occurs when an arithmetic operation reaches the minimum 150186 VOLUME 7, 2019   (maximum) of a type. As shown in Figure 4, an integer underflow occurs when a subtract operation attempts to create a value that is outside of the unit type range (0∼255), which will cause a misjudgment of the count value. This vulnerability exists in many platforms and smart contract languages.
Fix Scheme. Use SafeMath [35] libraries for all arithmetic operations in the smart contract. 4) Locked money. This vulnerability stems from the immaturity of blockchain platforms. An operator sometimes forgets to enter the address he expects to transfer to. Because the default value of an empty field for an address is 0x0 in some wallets such as Parity, money is often locked in this address.
Fix Scheme. Check the address before transferring. 5) Delegatecall to untrusted contracts. This vulnerability mainly arises from the Solidity language. A special function in contract A, namely delegatecall, may call a function of another untrusted contract B (e.g., callee in Figure 5). When calling into contract B, the context such as msg.sender is still identical to the previous context of contract A. Calling into untrusted contract B is very dangerous, because the code in B can change any storage values of A and thus can completely control the balance of A.
Fix Scheme. Use the function delegatecall with caution and ensure that you never call into an untrusted contract.

6)
Transaction order dependence. This vulnerability arises from a feature of the blockchain. As shown in Figure 6, a contract EthClaimReward will give a reward to the first person who solves a math problem (the contract owner will initialize the value of the reward by calling the function setReward). Assuming that Alice solves the problem and submits the answer by calling claimReward with a standard gas price, Eve can see the answer that Alice just submitted because the ledger is public. Now Eve can resubmit the answer with a much higher gas price, and thus Eve's transaction probably  gets processed and committed before Alice's. In that case, Eve will receive the reward even though Alice was the first person to solve the problem.
Fix Scheme. Use a commitment scheme that is carried out in two phases. (I) Instead of submitting a transaction with the answer, any person who solves the problem first submits a transaction with a hash of [salt, address, answer], where salt may be a random value and [] is a combination operator of multiple values. The contract stores this hash value and the sender's address. (II) To claim the reward, any person who submits the hash in the previous phase will continue to submit a transaction with his salt and answer. The contract then calculates the hash of [salt, msg.sender, answer] and checks this hash against the stored hash. The person who first submits the matched hash receives the reward. 7) Weak randomness from chain attributes. Because many contracts in Ethereum are open-source, it is challenging to create a sufficiently strong source of randomness in Ethereum. Attackers can easily predict the random number generated by an algorithm with custom seeds using the corresponding block information. An example is gambling Dapps, such as UnsafeDependenceOnBlock in Figure 7, where a pseudo-random number generator is used to pick the winner, and thus the answer can be easily guessed because the value of block.number is predictable when people guesses.
Fix Scheme. Use a commitment scheme that is carried out in two phases: (I) the commit phase, during which a random number for the answer is chosen and specified; in this phase, the answer is quite unpredictable; and (II) the reveal phase during which the answer is revealed and verified; in this phase, the answer becomes a determined value. 8) Timestamp dependence. Smart contracts often use a block timestamp to trigger conditions to execute some critical operations. For example, a smart contract may depend on a block timestamp to send out money (see theRun [34]). Malicious miners can adjust the timestamp to a specific value that influences the timestamp-dependent condition and favors them.
Fix Scheme. Do not use a block timestamp as a random seed to trigger conditions. Meanwhile, use the previous commitment scheme. 9) Mishandled exceptions. This vulnerability mainly arises from Solidity. If an external function in a contract contains many operations that may use up gas, calling such a costly function may trigger an exception. A mishandled exception may cause an attack, such as DOS (denial of service), on the on-going contract. As shown in Figure 8 (a), if a malicious bidder in an auction becomes a leader, he can remain the leader forever because he can prevent anyone else from successfully calling the function bid via a costly fallback function.
Fix Scheme. Set up a pull payment system to isolate each external call into an independent transaction from the function bid so that the recipient of the call can initiate the independent transaction. As shown in Figure 8 (b), the function withdrawRefund enables users to withdraw funds by themselves rather than pushing funds to them in the function bid, which reduces the chance of calling an external function in bid.
10) Replay attack. Digital signatures can be used for identity authentication. However, by intercepting and replaying the user's previous signature, a malicious user can impersonate a specific user [36]. Figure 9 shows a smart contract that aims to solve the problem of users being unable to transfer their tokens unless they have enough ether to pay for the transaction fees. By invoking transferProxy, a user _from can transfer tokens with a value of _value to another user _to with a valid elliptic curve signature represented by (_v, _r, _s). A replay attack is performed as follows. (I) Alice, i.e., A, initiates a transaction by calling transferProxy (A, B, 100, 3, sig) in which 100 Token will be sent to Bob, i.e., B, and 3 Token will be paid to Proxy as a service fee. To identify herself, Alice then signs the transaction with her signature 150188 VOLUME 7, 2019 Fix Scheme. Add an incremental nonce, the name of the blockchain and the address of the calling user into the signature. Use the information submitted by the calling user and the shared nonce to construct the hash value (i.e., byte32 h in transferProxy) to verify the signature [36].

B. SECURITY VULNERABILITIES IN FABRIC CHAINCODES
There are very few papers [37], [38] focused on security vulnerabilities in Fabric chaincodes. Based on [37] and [38], we summarize primary security vulnerabilities in Fabric chaincodes in Table 3, where we consider Go as the programming language because Go is most widely used in Fabric chaincode development.
Similar to the vulnerabilities in Ethereum smart contracts, the vulnerabilities in Fabric chaincodes also arise from three aspects: the Go language, the blockchain platform, and a misunderstanding of common practices. Different from common software weaknesses, most security vulnerabilities in Fabric chaincodes arise from the nondeterministic behavior of Go, which may lead to consensus failure. Examples of the vulnerabilities in Table 3 can be found in [38] (e.g., Listing 2 in [38]) or [39] (readers are able to run a demo on the homepage of [39] to get a report that includes examples of nine security vulnerabilities in [37]). Moreover, because Fabric has no native cryptocurrency, it is difficult to determine the severity of these vulnerabilities.

C. DISCUSSION OF VULNERABILITIES ON DIFFERENT PLATFORMS
Different platforms and programming languages cause the vulnerabilities in smart contracts on different platforms to exhibit distinguishing characteristics regarding three aspects.

1) SOME VULNERABILITIES ARISE FROM SPECIFIC LANGUAGES
These vulnerabilities, such as no.1∼ no.5 in Table 2 and no.1∼ no.5 in Table 3, may only appear in the corresponding platform. For instance, the vulnerability of unprotected selfdestruct arises from a flaw of Solidity. Accordingly, this vulnerability may only exist in Ethereum (no. 3 in Table 2 may be an exception because this vulnerability may exist in many programing languages). Moreover, because nondeterminism may exist in general-purpose programming languages (e.g., Go), some vulnerabilities, such as global variables and iterate over map, may appear in Fabric chaincodes. However, due to specific restrictions on Solidity (e.g., there are no explicit instructions in Solidity to generate random numbers or access files outside of the EVM), these nondeterministic vulnerabilities do not exist in Ethereum smart contracts.

2) SOME VULNERABILITIES ARISE FROM FEATURES OF THE SPECIFIC BLOCKCHAIN PLATFORM
These security vulnerabilities, such as no. 6∼ no. 8 in Table 2 and no. 9∼ no. 10 in Table 3, only appear on the corresponding platform. For example, the vulnerability of transaction order dependence only occurs when an accounting measure for runtime with gas [22] exists in the blockchain. This vulnerability does not exist in Fabric chaincodes. Alternately, the vulnerability of read your write does not exist in Ethereum smart contracts.

3) SOME VULNERABILITIES ARISE FROM A MISUNDERSTANDING OF COMMON PRACTICES
These vulnerabilities may appear on most blockchain platforms, including Ethereum and Fabric.
To date, there are at least dozens of blockchain platforms that support smart contracts. Saini summarized the characteristics of 40 different smart contract platforms [40]. These platforms may use different programming languages and have distinguishing platform features. It is difficult to compare all of these platforms. However, the same analysis regarding their comparison to Fabric chaincodes or Ethereum smart contracts concerning vulnerabilities can be conducted based on the above three aspects.

D. ANOMALOUS ACTIVITIES
In most of the existing blockchain platforms, pseudonymous transactions provide a nest for criminal smart contracts [27]. Because a smart contract is hard to patch for bugs, how to monitor anomalous activities in a smart contract after its deployment and apply appropriate countermeasures should be considered in advance. Some approaches for effectively detecting and preventing the proliferation of malicious behaviors in smart contracts are encouraged [28], [41].

IV. SECURITY SOLUTIONS FOR SMART CONTRACTS
Smart contract security is systematic engineering that should be explored from a global perspective. Accordingly, we classify current smart contract security solutions in terms of the evolution of the contract lifecycle. Similar to the traditional software lifecycle, we divide the contract lifecycle into four phases: security design, security implementation, testing before deployment, and monitoring and analysis. In any of these phases, contract security is paramount. Figure 10 illustrates the state of the art of smart contract security based on these phases.
The horizontal axis in Figure 10 shows the evolution of the smart contract lifecycle. We clustered related research works into different themes spanning one or more phases. Each theme is represented by a rounded rectangle with a red title. For each theme, different types of related works, which are separated by commas, are shown in the body of the corresponding rectangle. We illustrate these themes in terms of different lifecycle phases in the following sections.

A. SECURITY DESIGN
As shown in Figure 10, three themes (i.e., design principle, design pattern, and security modeling) span the phase of security design. These themes focus on how contracts are designed to avoid security issues. Notably, models constructed in the theme of security modeling may be transformed into contract implementation directly. We have summarized all related works in

1) DESIGN PRINCIPLE
To design secure smart contracts, reference [42] proposed a general philosophy for Ethereum and reference [43] proposed security guidelines for EOS. Both of them proposed five essential design principles (see the keywords in Table 4), which present the methodology for designing secure contracts on the blockchain. For example, the principle of Prepare for failure indicates that the contract code must be able to respond to bugs gracefully due to the lack of patching schemes. For instance, if an attack such as DAO [20] occurs, the contract must be able to pause to avoid further financial losses.

2) DESIGN PATTERN
In software engineering, a design pattern describes an abstraction of a reoccurring problem and presents a standard solution. Six security patterns (see the keywords in Table 4) are outlined in [44] to address vulnerabilities in Ethereum. For example, the mutex pattern can provide a solution to reentrancy vulnerability, and the emergency stop pattern can stop the execution of a contract if malicious behaviors are detected. By manually inspecting the source code of 811 Solidity contracts, Bartoletti et al. [45] identified some common design patterns (see the keywords in Table 4), some of which, such as authorization and time constraint, can also address some security issues in the blockchain.

3) SECURITY MODELING
Due to semantic inconsistency between the code implementation and the contract requirements, the process of coding a contract using a Turing-complete language such as Solidity can be error-prone. Moreover, the order of instruction also affects the correctness of the contract execution. Accordingly, recent works [46], [47] were proposed to formalize contract clauses to enhance security. We summarize them into the theme of security modeling. As shown in Figure 10, this theme spans two phases: security design and security implementation. In this theme, a high-level specification derived from business logic is characterized by rigorous and precise semantics, which facilitates formal verification while mitigating the vulnerabilities in the implementation.
FSolidM [46] allows developers to define smart contracts as finite state machines (FSMs) to help developers create more secure contracts by design. For instance, Figure 11 shows an example of FSMs for blind auctions [46], where ABB is the initial state of the FSM. Each transition (e.g., bid and close) is associated with an action that a user can perform and may have a corresponding guard for the action. FSolidM provides an easy-to-use editor and a code generator for creating FSMs and automatically generating Ethereum contract code. Additionally, FSolidM offers a plugin mechanism to enable developers to easily eliminate security vulnerabilities in contracts.
Recently, Idelberger et al. proposed the concept of logicbased smart contracts [47]. Compared with a smart contract based on a procedural language, such as Solidity, a logicbased smart contract has distinct technical advantages in bridging the gap between the contract implementation and the legal prose because a logic-based smart contract is easy to understand by involved entities during the process of negotiation and dispute resolution. With the logic-based approach, the programmer can write smart contracts only by describing contractual clauses (what has to be done) instead of writing VOLUME 7, 2019 down detailed steps (how to do it). These contractual clauses will then be encoded into logic rules, upon which a rule-based engine would reason and execute. Accordingly, many security issues could be avoided due to the absence of manual coding in this process.

B. SECURITY IMPLEMENTATION
Security implementation includes three themes: security development, security template, and security modeling. We have explained Security Modeling previously. In this subsection, we mainly discuss security development and security template. We have summarized these two themes in Table 5.

1) SECURITY DEVELOPMENT
This theme concerns how developers of smart contracts can avoid security vulnerabilities during the process of contract implementation.
OpenZeppelin [48] is a security library for developing Ethereum smart contracts. It offers out-of-the-box role-based access control of the blockchain, as well as cryptography utilities such as SafeMath [35]. OpenZeppelin can be installed directly into Dapps using node.js and integrated with Truffle [54], an Ethereum development environment.
Security EIPs (Ethereum improvement proposals [49]) present appropriate proposals to avoid security vulnerabilities on the Ethereum platform. For example, EIP 155 provides a way to address simple replay attacks. Security EIPs are very significant for the implementation of secure smart contracts.
Some implementation skills are also exploited to enhance contract security. Reference [50] presents four standard techniques (see the keywords in Table 5) to develop upgradeable Ethereum smart contracts. This work shows that although the deployed contract code is immutable on Ethereum, a workaround still exists as long as we consider the security issues in advance. Moreover, fix schemes in section III aiming to address specific security vulnerabilities can also be seen as part of security development (we will not restate them here).

2) SECURITY TEMPLATE
Clack et al. [51] introduced smart contract templates, which connect a legal agreement to the final executable code via operational parameters. Figure 12 illustrates their work, where an agreement template often contains legal prose and parameters. The prose and parameters can be customized in the negotiation stage and then formed into a legal agreement. Correspondingly, the standardized smart contract code can be generated directly in terms of the agreement template and modified in negotiation. After the agreement is signed, the values of parameters are defined and then passed to the code template, which enables the final executable contract code. In their later work, Clark et al. [52] identified the essential requirement and design options of templates. Moreover, Clark proposed a series of approaches to verify whether the smart contract code faithfully performs the provisions of the legal contract [53]. Although they did not explicitly mention smart contract security in their works, we argue that standard code templates with security enhancements (see Figure 12), such as security patterns and security libraries, can be extracted from business logic to significantly reduce errors in manual coding. If such security templates are built, they could be tested and certified only once and then used by others while avoiding security issues.

C. TESTING BEFORE DEPLOYMENT
Because smart contracts are difficult to patch after deployment, it is necessary to perform sufficient testing to ensure their security before their deployment. Table 6 classifies smart contract security solutions in the phase of testing before deployment into three security themes: rigorous formal verification, code analysis tools, and security audit.

1) RIGOROUS FORMAL VERIFICATION
Rigorous formal verification is a mathematical approach to verifying the correctness and security of a program. Smart contracts are very suitable for rigorous formal verification because the contract program is small and time-bounded.  Rigorous formal verification is usually applied after the completion of the contract code, although more precisely, it can also be used to verify the correctness of the middle representation of smart contracts in the design or implementation phase (e.g., a high-level specification derived from business logic in security modeling).
There are several approaches to rigorously formalize and verify smart contracts. Among them, some are based on contract code [55], [56], whereas some are based on Ethereum virtual machine (EVM) semantics [57]- [59]. The latter can be viewed as tailored implementations of EVM that take into account the proof of security properties.
Abdellatif and Brousmich [55] proposed a novel approach for modeling smart contract behavior with strong semantics using a behavior interaction priorities (BIP) framework based on the source code of smart contracts. In addition, they simulated this behavior model with a series of runtime verification and simulation engines. The results from the simulation were further analyzed to verify security properties with a statistical model checking (SMC) tool, which revealed some malicious operations. However, under most circumstances, formalizing smart contract behavior based on existing source code is nontrivial. Using two prototype tools, Solidity * and EVM * (see Figure 13), Bhargavan et al. [56] translated Ethereum contracts into F * , a functional language equipped with an VOLUME 7, 2019  interactive proof assistant for program verification. However, the translation only supports a fragment of EVM bytecode and leaves out many essential constructs.
To develop secure contracts, Hirai [57] formalized EVM semantics using Lem, from which the interactive theorem prover Isabelle/HOL can be extracted to prove security properties of smart contracts (see Figure 14). This work is the first formal EVM definition for smart contract verification. However, the semantics are only a sound overapproximation of the original semantics in [57] and thus cannot serve as a general-purpose basis for static analysis. To demonstrate the significance of rigorous semantic foundations for the design of security verification, Grishchenko et al. [58] presented the first complete small-step semantics of EVM bytecode, which they formalized in the F * proof assistant. Based on this formalization, program verifications, as well as proofs for fundamental security properties, were proposed. Moreover, Hildenbrandt et al. [59] presented fully executable rigorous formal semantics on EVM using the K framework [71]. They also showed how the existing language-independent tools, such as the reachability logic prover [72] for the K framework, can be applied to security analysis on EVM programs. Both [58] and [59] obtained executable code that was successfully validated against the Ethereum test suite to show the correctness of their semantic definitions. They successfully identified various mistakes and imprecisions in the existing semantics and enabled the verification of security properties for Ethereum smart contracts, thus offering formal verification and a precision guarantee for these smart contracts. Nevertheless, full automation of the verification of security properties still needs to be explored further.
Beckert et al. [60] proposed a formal specification and verification of smart contracts written in Java in Fabric using KeY [73], a semi-interactive deductive theorem prover for statically verifying sequential Java programs. Notably, they extended KeY to support the verification of smart contracts, and this extension operates on the Fabric ledger and handles serialization. As far as we know, the work of Beckert et al. is the only work on formal verification of Fabric smart contracts thus far.

2) CODE ANALYSIS TOOLS
Thus far, only a few static code analysis tools, whether they rely on a rigorous formalization or not, have been implemented to improve code quality and security. The tools conduct static code analysis on the source code or bytecode of smart contracts without executing the programs. The analysis may include some or all of the following steps. (I) Build an intermediate representation (IR), e.g., an abstract syntax tree (AST), for subsequent in-depth analysis. (II) Enrich the IR with some additional information, likely coming from static control or date flow analysis and formal verification techniques, such as symbolic execution [74], abstract interpretation [75], and symbolic model checking [76]. (III) Perform vulnerability detection according to a security pattern (anti-pattern or secure property) that defines the vulnerability criteria in IR terms.
Oyente [34], one of the most popular automatic security analysis tools for EVM smart contracts, leverages symbolic execution with the constraint solver Z3 [77] to find four common bugs (namely, transaction ordering dependence, timestamp dependence, mishandled exceptions, and reentrancy). Reference [11] uses Oyente to help eradicate these common bugs in smart contracts. Figure 15 shows the architecture of Oyente, which takes bytecode and the current Ethereum global state as input. Four components, namely CFG (Control Flow Graph) Builder, Explorer, Core Analysis, and Validator, form the core of Oyente. CFG Builder constructs a control flow graph of smart contracts, which feeds the Explorer and Graph visualizer. Explorer symbolically executes the contract, and the result is then fed to Core Analysis, where Oyente targets the common bugs. Finally, Validator filters out false positives before final reporting. Among   vulnerabilities with false positives. Additionally, it only implements a lightweight semantics of the EVM bytecode, and thus misses a few critical commands concerning contract calls and creations.
Symbolic execution used by Oyente is a powerful technique for identifying vulnerabilities. However, it does not guarantee the exploration of all execution paths, which may result in false negatives. In contrast to Oyente, Securify [18] is an abstract interpreter that explores all possible paths. Additionally, Securify, though non-open-source, is a tool available for smart contract code analysis using a web page. Securify analyzes the contract dependency graph in stratified Datalog [78] to infer precise semantic information from EVM bytecode. Then, it checks compliance and violation patterns to verify whether a security property holds. Compared with Oyente, Securify's analysis is fully automated. Because patterns are expressed in a designated domain-specific language (DSL) in Securify, anyone can easily extend new patterns to address new vulnerabilities. Kalra et al. proposed Zeus [17], a completely automated tool, to reason about the correctness and fairness of smart contracts using formal approaches including abstract interpretation and symbolic model checking along with constrained Horn clauses [79]. Zeus takes as input contract source code and security policy (written in XACML-styled templates). It performs static analysis atop the source code to determine the points at which the verification predicates must be asserted. Then, Zeus transforms the smart contract source code embedded with policy assertions into a low-level IR such as LLVM bitcode. Finally, Zeus feeds the bitcode to a verification engine to determine whether the security policy is satisfied. The evaluation shows that Zeus is sound with zero false negatives and a low false-positive rate, and it offers a significant improvement in analysis time over previous works, such as Oyente. Because most high-level languages already have mature LLVM bitcode translators, Zeus is scalable and is now available for the Fabric and Ethereum platforms. Unfortunately, Zeus is not open-source and is only used to analyze contracts whose source code is available.
Chaincode Scanner is a static security analyzer designed for Fabric smart contracts [61]. It often takes smart contracts written in the Go language as input. Some automated security analyses, such as control flow graph analysis and dependency graph analysis, are conducted to check for nine vulnerability patterns [37]. However, due to the lack of a detailed description of Chaincode Scanner, we cannot fully disclose the theory of the tool. Yamashita et al. [38] surveyed various artifacts and identified fourteen potential risks in Fabric. They argued that smart contracts written in general-purpose programming languages, such as Go and Java, lack restrictions and are more likely to cause nondeterministic risks. Some ready-made tools, such as Go tools [80], can be utilized to conduct static security analysis for some common risks, but this does not take into consideration some risks in the blockchain context. Therefore, Yamashita et al. implemented a prototype tool to cover these risks, which analyzed the AST of contracts. Moreover, they compared Chaincode Scanner and Go tools with their tool. Comparison results showed that their tool has more effective coverage and better performance.
Octopus [62] is a security analysis tool for smart contracts with EVM and WASM (WebAssembly [81]) support. To improve analysis efficiency, Octopus can translate bytecode into an assembly representation (another IR format) using a disassembler and then simplify the assembly into static single assignment (SSA) representation for further optimization. Moreover, Octopus utilizes control flow graphs and call flow graphs to analyze security vulnerabilities and exploits symbolic execution to find new paths into a program. Compared to other tools, Octopus can perform security analysis of smart contracts on multiple blockchain platforms, including BTC, ETH, NEO, and EOS.
Meanwhile, some other security analysis tools, such as TEETHER [63], Mythril [64], SmartCheck [65], and Manticore [66], also perform security analysis using formal verification approaches. References [19], [21] and [82] present empirical vulnerability analysis to compare the performances of these tools. Among these tools, TEETHER provides not only a methodology to find vulnerabilities but also end-to-end exploit generation. Moreover, an overview of foundations and tools for the static analysis of Ethereum smart contracts can be found in [83].
Another thing worth noting is that, unlike the approaches in security themes mentioned before, most code analysis tools, including Oyente, Securify, Zeus, Chaincode Scanner, Octopus, and TEETHER, analyze the control flow graph or contract dependency graph. Accordingly, with these tools, it is possible to address some security issues in the situation where multiple smart contracts interact. That is, although a smart contract is not vulnerable, it still may be dangerous because it calls a vulnerable one.

3) SECURITY AUDIT
Security issues and incorrectness in smart contracts can cause devastating financial consequences. Consequently, security audits are necessary to ensure the security and correctness of smart contracts. If developers are not confident enough in their professional ability to perform security audits, they can entrust the audit task to some professional constitutions [67]- [69], who will write a qualified auditing report for security issues they identify.
An ideal audit will be a combination of automatic and manual code analysis. Generally, the automatic code analysis uses VOLUME 7, 2019 static code analysis tools, such as Oyente and Securify, to find vulnerabilities. These tools can save a significant amount of time for security auditors, but they may miss some critical security vulnerabilities. As a supplement, auditors can review every line of code and test them for different vulnerabilities by manual analysis.
Additionally, regulatory bodies also need to carry out public audits of smart contracts. Many smart contracts in public blockchains, such as Ethereum, do not have readily available source code, which makes audits challenging. To address this problem, Zhou et al. proposed a reverse-engineering tool entitled Erays [70] to reconstruct high-level pseudocode based on EVM bytecode. With Erays, security auditors can not only explore code complexity and code reuse of Ethereum smart contracts but also uncover contract intention and behavior. Moreover, any other approaches adopted by contract developers for security audit can still be used here.

D. MONITORING AND ANALYSIS
Even if a contract has been deployed and run, users still need some measures to discover vulnerabilities that were missed in the previous phase for improvement in new releases. These measures include bug bounty, security monitoring, and post hoc analysis. We have summarized all of these measures in Table 7.

1) BUG BOUNTY
Although measures in the phase of testing before deployment can help us find most bugs, some bugs are still hard to identify. Bug bounty programs are often used to discover deeply hidden bugs. Unlike formal verification, a type of static analysis technique, bug bounty is a type of dynamic analysis technique. In a bug bounty program, hackers expecting financial rewards generally find bugs when the system is running. Many Ethereum ecosystems, such as EtherScan [84] and Raiden [85], provide bug bounty programs to further improve system security.
However, bug bounties lack rigorous principles for pricing bounties appropriately. Because the financial value of critical bugs in gray markets may significantly exceed the bounty value [86], some hackers would rather sell or exploit bugs than claim them. Moreover, bounty payers often do not want to pay before confirming an exploit, whereas hackers worry that revealing exploits risks nonpayment. All of these things compromise the generalization of bug bounty programs. To address these challenges, Breidenbach et al.
proposed Hydra [86], a bug bounty framework, and then applied it to smart contracts.
As the first general, principled bug bounty system on the blockchain, Hydra utilizes an exploit gap technology named N-of-N-version programming (NNVP). The rationale of Hydra is shown in Figure 16, where multiple versions of smart contract programs (Hydra heads) with the same functionality are independently developed. A hacker 150196 VOLUME 7, 2019 can obtain the bounty only when a head outputs a different result from the others, which shows that a bug exists in the head. In Hydra, a bug is exploitable only if it affects all heads similarly. That is, the same bug exists in all heads and causes the same exceptional output, which is almost impossible because those heads are independently developed. This property makes critical bugs detectable at runtime, but hard to exploit. In particular, with the Hydra smart contract, a fair exchange between bounty payers and hackers is also enabled. Bounty payers do not need to pay before confirming an exploit, whereas hackers no longer have to worry that revealing exploits risks nonpayment. Moreover, using an adjustable bounty value and submarine commitments, Hydra encourages economically rational hackers to disclose bugs while effectively preventing bug withholding. Although the authors designed the Hydra framework for the Ethereum platform, its fundamental methodology is easy to extend to any other blockchain, such as Fabric or EOS.

2) SECURITY MONITORING
Compared with static code analysis, which can reveal security vulnerabilities based on contract code before deployment, monitoring and analyzing transaction data on the blockchain can uncover many vulnerability exploits in real-time.
By analyzing multiple invocations of an Ethereum contract during its run-time, Nikolić et al. [87] systematically characterized a class of vulnerabilities that they call trace vulnerabilities. They focused their attention on three categories of contracts with trace vulnerabilities: greedy contracts (contracts that remain alive and lock Ether indefinitely), prodigal contracts (contracts that leak funds carelessly to arbitrary users), and suicidal contracts (contracts that can be killed by any arbitrary user). They implemented MAIAN [91] to specify and reason about trace properties. By employing symbolic analysis and a concrete validator, MAIAN finds exploits for the infamous Parity bug, which previous analyses failed to capture.
Grossman et al. [88] defined the notion of effectively callback free (ECF) objects. They argued that identifying vulnerabilities by monitoring ECF objects in the execution traces of Ethereum is feasible. Therefore, they proposed an efficient online algorithm for discovering reentrancy. Other known vulnerabilities can also be discovered similarly. To avoid unexpected consequences, they suggested that smart contracts should first be executed on the testnet before they are finally deployed on the mainnet [92].
Similar to ECF online detection, DappGuard [89] is an active monitoring and defense tool for Ethereum smart contracts that searches for attack fingerprints from transaction logs or receipts to identify attacks. For example, vulnerability exploits for smart contracts can be discovered through high gas usage, strange message values, and suspicious fallback invocations in transaction logs or receipts. Combined with code analysis tools such as Oyente, DappGuard can be extended to monitor the anomalous behavior of smart contracts in real-time.
Monitoring UI [90] is a blockchain monitoring platform that uses React.js, the Watson IoT platform [93] and the Fabric Node SDK to interact with a Fabric blockchain service. Operators can use this UI platform to monitor assets, perform transactions, and query the state of the blockchain. Unlike DappGuard [89], Monitoring UI does not provide secure monitoring of smart contracts. However, because all transaction data related to the contract are available on this platform, it can be extended to detect attacks in real-time by analyzing the transfer of assets.

3) POST HOC ANALYSIS
With the increasing volume of blockchain transaction data, some data analysis or machine learning approaches can be applied to discover attacks or abnormal activities on the blockchain.
Chen et al. [41] conducted the first systematic study of Ethereum transactions by graph analysis. They designed an approach to collect all transactions, including internal transactions resulting from the execution of smart contracts. From the transaction data, they built three graphs: a money flow graph (MFG), contract creation graph (CCG), and contract invocation graph (CIG). With these graphs, they characterized major activities on Ethereum and discovered many new insights, including degree distribution and node importance. According to contract invocation analysis, some security issues concerning multiple contracts interacting with each other may also be solved. For instance, two security issues, i.e., attack forensics and anomaly detection, were addressed. Attack forensics can be used to find all accounts controlled by an attacker. Anomaly detection can discover abnormal contract creation, which consumes many disks or network resources by creating many contracts that are rarely used. Figure 17 illustrates their approach. The Ponzi scheme, a classic fraud, can acquire a large amount of money and have a very negative impact on Ethereum. Chen et al. [28] proposed an effective classifier to detect Ponzi schemes on Ethereum. Their approach utilizes data mining and machine learning to detect Ponzi contracts even if the source code for smart contracts is not available. By verifying smart contracts manually, account features and code features of Ponzi contracts were first VOLUME 7, 2019 FIGURE 18. The framework of smart Ponzi scheme detection [28]. extracted from the transactions and operation codes, respectively. Then, the authors proposed a classifier model based on XGBoost [94], which is proven to be effective in detecting Ponzi schemes. Figure 18 illustrates the framework of their approach.

V. CHALLENGES AND OPPORTUNITIES A. SECURITY DESIGN
With the application of smart contracts in different industries [95]- [97], more security patterns and security anti-patterns should be extracted from the emerging security vulnerabilities.
Security Modeling is a promising research direction. There is still considerable room for this direction. In FSMs-based approaches, the number of states and transitions grows exponentially with the number of contracts, which makes this modeling approach inappropriate for complex business logic. Moreover, a logic-based approach is still in the proof-ofconcept stage even if this approach has distinct advantages in negotiation, notarizing, and enforcement of a contract. The algorithm for a logic approach is not efficient in blockchain scenarios. Moreover, how to effectively extract FSMs [46] and logic rules from legal agreements [47] to mitigate vulnerabilities is worth exploring. How to make the logic and procedural approaches compatible is also challenging.
With the popularity of blockchain, more domain-specific modeling approaches and logic languages with precise semantics should be proposed to avoid vulnerabilities. These models and languages should be easy to convert into code or real legal contracts adopted by the court directly.

B. SECURITY IMPLEMENTATION
A promising research direction in security implementation of smart contracts is the integration of more security libraries, such as OpenZeppelin [48], into the contract development environment in the form of security plugins. These libraries will provide security enhancement for the development of smart contracts.
Another promising research direction in security implementation of smart contracts is the development of a formal high-level domain-specific language with explicit semantics and security enhancements. With this language, developers could write contract templates, from which legal agreements and executable smart contract code could be automatically extracted, thereby avoiding error-prone manual coding and eliminating major security issues. Moreover, to keep templates simple and semantics precise, developers could also integrate logic rules in a logic-based approach [47] [98] is such an attempt. With the popularity of the Ethereum platform, more and more such intermediate-level languages that are easy to understand but that have strong expressive power and precise operational semantics will appear. Different from Ethereum, Fabric uses a general-purpose programming language to write smart contracts [23]. Accordingly, the formalization of smart contracts for Fabric may be more complicated than that for Ethereum. Fortunately, some provers (e.g., KeY [73]) associated with general programming languages are available, and how to adapt these provers to blockchain scenarios is also worth exploring.
In addition to rigorous formal verification, code analysis tools are also exploited to find security vulnerabilities in smart contracts. However, these tools are still in the infancy stage. Their performance is not ideal. Many of them do not cover the full range of security vulnerabilities outlined in this paper. Moreover, there is still considerable room to improve their accuracy, false-positive rate, and false-negative rate in the process of vulnerability detection. For this aspect, deep learning may be useful. Moreover, because new security vulnerabilities continue to emerge, an excellent code analysis tool should be extensible. The tool should be able to identify new security vulnerabilities by defining new security properties. However, security properties are now often specified ad hoc and are mostly verified manually. A method for the unified and flexible specification of security properties to facilitate automatic verification is urgently needed.
In brief, because smart contracts are hard to patch once they are deployed on the blockchain, testing before deployment is significant. A convenient test platform for smart contracts, especially new test techniques such as mocking objects capable of effectively emulating the blockchain, are also worth exploring further. Additionally, the construction of standard test datasets for a specific blockchain platform to mitigate the difficulty of testing smart contracts is also a promising research direction.

D. MONITORING AND ANALYSIS
Real-time monitoring and analysis are very significant for blockchain security. Blockchain platforms, such as Ethereum and Fabric, are expected to provide an internal framework for efficient monitoring of the execution of smart contracts in the future. Based on such a framework, organizations can expand the scope of security monitoring according to their business.
As more and more transactions of different businesses are dealt with on the blockchain, a variety of attacks and scams will emerge due to the enormous value transfer associated with these transactions, which provides a promising research direction for data mining on the blockchain. For instance, we may discover more new insights regarding anomalous behavior in smart contracts by in-depth graph analysis.

E. OTHER DIRECTIONS
If the security of smart contracts is considered at the system level (e.g., EVM implementation), we will spend less on security in the contract development lifecycle. However, consideration of security at the system level is a more general problem and thus is also a significant challenge.
Corresponding to traditional software, some researchers advocate for a discipline of blockchain software engineering to address the issues posed by smart contract programming [99], [100]. We also hold this viewpoint. With the progress of blockchain security, blockchain engineers and researchers may propose more new best practices and security tools concerning blockchain software engineering.

VI. CONCLUSION
As examined in this paper, the environment in which smart contracts are executed is decentralized and hard to patch for bugs. Consequently, smart contracts have many security issues in terms of security vulnerabilities and anomalous activities. Our focus on smart contract security from the perspective of the software lifecycle enabled us to reveal the practical and theoretical aspects of smart contract security to a greater degree than any previous study. We achieved this vital research outcome as follows. First, we illustrated key features of blockchains that cause security issues in smart contracts, including 1) decentralized, tamper-proof and public ledgers; 2) open-source smart contract code; 3) immature platforms and languages, and 4) pseudonymous transactions. We revealed the most common security vulnerabilities of smart contracts in Ethereum and Fabric. We also discussed the differences in vulnerabilities on different blockchain platforms. Then, we demystified the puzzles of security solutions for smart contracts in terms of numerous security themes spanning four contract development phases: 1) security design; 2) security implementation; 3) testing before deployment; and 4) monitoring and analysis. Finally, we summarized the challenges of security research for smart contracts as a software engineering problem and suggested several research directions to improve smart contract security. We hope that this paper builds on the current research outcomes of smart contract security and signifies a milestone in information security in the age of blockchain. We expect that many more research efforts will follow by expanding on the works classified in this paper and by applying the techniques outlined here to various business contexts.

APPENDIX
For the convenience of reference, Table 8 shows the websites of all open-source tools in Section IV. These websites were available as of September 6, 2019. . He is also the in charge of the National Natural Science Foundation of China (NSFC). His current research interests include wireless sensor networks, QoS guarantee based on cross-layer approach, and Blockchain security and its applications based on the consortium Blockchain architecture. 150202 VOLUME 7, 2019