# Survey on Quality Assurance of Smart Contracts

Zhiyuan Wei  Beijing Institute of TechnologyBeijingChina<EMAIL_ADDRESS>,  Jing Sun  University of AucklandAucklandNew Zealand<EMAIL_ADDRESS>,  Zijian Zhang<EMAIL_ADDRESS>,  Xianhao Zhang
<EMAIL_ADDRESS>,  Xiaoxuan Yang<EMAIL_ADDRESS>and
Liehuang Zhu<EMAIL_ADDRESS>Beijing Institute of TechnologyBeijingChina

(2018; 1 June 2023; 1 June 2023; 1 June 2023)

###### Abstract.

With the increasing adoption of smart contracts, ensuring their security has
become a critical concern. Numerous vulnerabilities and attacks have been
identified and exploited, resulting in significant financial losses. In
response, researchers have developed various tools and techniques to identify
and prevent vulnerabilities in smart contracts. In this survey, we present a
systematic overview of the quality assurance of smart contracts, covering
vulnerabilities, attacks, defenses, and tool support. By classifying
vulnerabilities based on known attacks, we can identify patterns and common
weaknesses that need to be addressed. Moreover, in order to effectively
protect smart contracts, we have created a labeled dataset to evaluate various
vulnerability detection tools and compare their effectiveness.

smart contract, security, vulnerabilities, attacks, defenses

††copyright: acmcopyright††journalyear: 2023††doi: XXXXXXX.XXXXXXX††journal:
CSUR††price: 15.00††isbn: 978-1-4503-XXXX-X/18/06††ccs: General and reference
Surveys and overviews††ccs: Security and privacy Distributed systems security

##  1\. Introduction

With the development of the internet, blockchain technology has gained
popularity among academia and industries as a means to explore diverse
applications where security and privacy are of utmost importance (Wood et al.,
2014; Hughes et al., 2019). As a distributed ledger, blockchain technology is
replicated and shared among a network of peer-to-peer nodes. It eliminates the
need for intermediaries, thereby providing decentralization, transparency,
immutability, security, and reliability. By maintaining a chronologically
growing and immutable data record, the blockchain system becomes an ideal
infrastructure for future business networks. This can lead to a significant
reduction in operational costs for the business system (Casino et al., 2019).

Within the realm of blockchain technology, smart contracts have gained
significant prominence. Smart contracts are self-executing contracts with
terms agreed upon by buyers and sellers, implemented through lines of code
(Luu et al., 2016; Atzei et al., 2016). They ensure the transparency and
immutability of contract rules, which are enforced by all participants of the
blockchain network. Smart contracts allows decentralized applications (DApps)
to be built on the blockchain network. These DApps can be applied to a wide
range of domains, such as financial services (Zhang et al., 2022), healthcare
services (Qahtan et al., 2023), Internet of Things (Gupta et al., 2023),
crowdfunding management (Saadat et al., 2019) and supply chain (Singh et al.,
2023; Sultana et al., 2022). In most cases, smart contracts are associated
with the native cryptocurrency of the blockchain, which is used to facilitate
payment for their execution on the network. This incentivizes network
participants to validate and execute smart contracts, ensuring that the
blockchain remains secure and decentralized. Since smart contracts are a
relatively new technology that has the potential to revolutionize the way
business transactions are conducted, researchers are drawn to the novelty and
potential impact of smart contracts and are interested in exploring their
potential applications. Despite the growing interest, there are still many
open research questions that need to be addressed.

Compared to traditional software programs, smart contracts indeed have
characteristics that make them more vulnerable to software attacks. First,
smart contracts are immutable, meaning that once deployed on the blockchain,
their code cannot be modified. While immutability ensures trust and
transparency, it also means that any vulnerabilities or errors in the code
cannot be easily rectified without deploying a new version of the contract.
Second, smart contracts often handle valuable digital assets, such as
cryptocurrencies or digital tokens. The presence of these valuable assets
attracts attackers who are more actively exploiting vulnerabilities in the
smart contract code. Third, public blockchains, such as Ethereum, are
permissionless, meaning that anyone can access and interact with smart
contracts deployed on the blockchain. This open access reduces the barrier to
entry for potential attackers, making it easier for them to identify and
exploit vulnerabilities in smart contracts. Moreover, many smart contract
developers choose to publish the code of their contracts openly on websites
like Etherscan (eth, 2018b). While this promotes transparency and
collaboration within the community, it also makes it easier for attackers to
analyze the code, identify weaknesses, and devise attack strategies. Due to
these factors, the exploitation of smart contracts has resulted in significant
financial losses in the past. A notorious malicious attack occurred in 2016
when attackers successfully diverted over 3.6 million ether into a “child DAO”
(Decentralized Autonomous Organization). This exploit resulted in a staggering
loss of approximately 70 million USD, causing a significant drop in the price
of each ether from 20 USD to 13 USD (Falkon, 2017). Another significant
incident involved the theft of a substantial amount of ether in the Parity
Multisig Wallet version 1.5+. This exploit led to a loss of approximately 30
million USD (Palladino, 2017).

Due to the novelty and potential impact of smart contracts, there are some
notable surveys involving vulnerable smart contracts from various
perspectives. Atzeri et al. (Atzei et al., 2016) were pioneers in providing a
survey on smart contract security. They classified 12 vulnerabilities into
three categories: Solidity, EVM bytecode, and blockchain. This classification
has been widely adopted by subsequent researchers. Zheng et al. (Zheng et al.,
2020b) compared different smart contract platforms and provided a
categorization of applications. Their survey focused on evaluating the
features and characteristics of various platforms. Chen et al. (Chen et al.,
2021b) went beyond vulnerability analysis and considered defense mechanisms
for blockchain security. Their survey discussed different defense techniques
and strategies employed to enhance the security of smart contracts. Angelo and
Salzer (Angelo and Salzer, 2019) conducted a survey on vulnerability detection
tools specifically designed for Ethereum smart contracts. Their study
encompassed tools from both academia and industry, providing insights into the
available tools for identifying vulnerabilities. Durieux et al. (Durieux et
al., 2020) conducted an evaluation review of nine smart contract detection
tools. They assessed these tools using a labeled dataset and a large number of
real-world smart contracts, providing a comprehensive analysis of their
effectiveness. Tolmach et al. (Tolmach et al., 2022) focused their study on
the formal verification of smart contracts across various applications. Their
survey delved into the application of formal verification techniques to verify
the correctness and security of smart contracts.

While previous surveys offer valuable insights into specific aspects of smart
contract security, they may not provide a comprehensive analysis of vulnerable
smart contracts from all perspectives. It is crucial to develop a thorough
understanding of vulnerabilities, attacks, defenses, and tool evaluation to
gain a holistic view of the challenges and potential solutions related to
smart contract security. To bridge this gap and offer a more complete
analysis, our paper aims to incorporate multiple perspectives. By examining
vulnerabilities, attacks, defenses, and tools, we seek to provide a
comprehensive understanding of the challenges posed by vulnerable smart
contracts and explore potential solutions. The primary objective of our paper
is to provide a comprehensive and up-to-date analysis that contributes to the
existing body of research on smart contract security. To achieve this, we
outline the following key contributions:

  * •

Novel Vulnerability Classification: We propose a novel vulnerability
classification that enhances the understanding of the underlying causes of
vulnerabilities in smart contracts. This classification will aid researchers
in categorizing and analyzing vulnerabilities more effectively, providing a
solid foundation for targeted security measures and improved vulnerability
management.

  * •

In-depth Analysis of Real-World Attacks: We conduct an extensive analysis of
real-world attacks on smart contracts to gain valuable insights into the
methods employed by attackers and the potential consequences of these attacks.
By examining and dissecting these attacks, we aim to provide a clearer
understanding of the exploitation of vulnerabilities in practice, enabling
developers and auditors to proactively address potential threats.

  * •

Exploration of Defense Mechanisms: We thoroughly explore existing defense
mechanisms employed to mitigate smart contract attacks. Through this
exploration, we identify areas for improvement and potential new approaches to
enhance the security of smart contracts. By analyzing the strengths and
weaknesses of current defense mechanisms, we aim to contribute to the
development of more robust and effective security practices.

  * •

Evaluation of Vulnerability-Detecting Tools: We conduct a comprehensive
evaluation of 12 representative vulnerability-detecting tools used in smart
contract analysis. This evaluation encompasses the accuracy, performance, and
effectiveness of each tool. By providing insights into the strengths and
weaknesses of these tools, we assist researchers and practitioners in
selecting the most suitable tools for identifying vulnerabilities in smart
contracts.

  * •

Benchmark Dataset for Tool Evaluation: To facilitate the evaluation of
vulnerability-detecting tools, we create a benchmark dataset comprising 100
vulnerable contract cases and 10 correct contract cases. This benchmark
dataset serves as a standardized reference for evaluating the effectiveness of
these tools. It enables fair and objective comparisons, allowing researchers
and practitioners to assess the capabilities of different tools in a
consistent manner.

Through these key contributions, our paper aims to serve as a comprehensive
resource for researchers, developers, and auditors in the field of smart
contract security. We aspire to advance secure smart contract development
practices and promote the widespread adoption of secure smart contracts in
real-world applications.

The rest of this paper is constructed as follows. Section 2 provides a brief
overview of smart contract platforms and discusses the methodology employed in
this survey to ensure a comprehensive analysis. Section 3 presents a detailed
analysis of 40 smart contract vulnerabilities, examining their root causes and
shedding light on the underlying factors that contribute to their existence.
Section 4 explores 8 representative attacks and demonstrates how these
vulnerabilities can be exploited. By illustrating real-world attack scenarios,
we aim to enhance our understanding of the potential consequences of these
vulnerabilities. Section 5 examines various defense methodologies and repair
techniques available for smart contracts. We discuss the effectiveness of
these defensive measures in mitigating vulnerabilities and reducing the
likelihood of successful attacks. Section 6 focuses on the evaluation of 12
commonly used tools for detecting vulnerabilities in smart contracts. We
assess the accuracy and performance of these tools by subjecting them to a
rigorous evaluation against a carefully curated benchmarking dataset. Section
7 concludes the paper by summarizing the key findings and contributions. We
also discuss future directions and potential research areas to further advance
the field of smart contract security. The Appendix includes information on
detection tools specifically designed for smart contracts.

##  2\. Overview of Smart Contracts and Survey Methodology

###  2.1. Smart Contracts

The basic idea of smart contracts can be attributed to Nick Szabo, who
introduced the concept in 1996, predating the creation of blockchain
technology. Szabo envisioned smart contracts as computer protocols that enable
parties to engage in digitally verifiable and self-executing agreements. These
contracts are written in code format and facilitate secure and efficient
transactions, reducing costs and expediting execution compared to traditional
contracts (Szabo, 1996). However, the development of smart contracts faced
challenges in trustless systems until the emergence of Ethereum in 2015 (Khan
et al., 2021). Ethereum’s introduction of a blockchain-based platform
specifically designed for executing smart contracts revolutionized the field.
Ethereum’s success paved the way for the proliferation of other blockchain
platforms that also support smart contract development. These platforms
include Hyperledger (Saad et al., 2020), EOSIO (He et al., 2021), Tezos
(Bernardo et al., 2020), NEO (Nguyen et al., 2019), and even Bitcoin, which
implemented its own version of smart contracts (Bartoletti and Zunino, 2019).
We present a comprehensive comparison of four prominent blockchain platforms,
highlighting their similarities and differences in terms of smart contract
implementation and security.

  * •

Bitcoin primarily aims to facilitate secure peer-to-peer currency transactions
without the need for intermediaries. While Bitcoin was not originally designed
to support extensive smart contract functionalities such as those of Ethereum,
it does provide limited capabilities for executing cryptographic protocols.
Bitcoin smart contracts are primarily written in a programming language named
Script, which is a simple, stack-based programming language that is
specifically designed for transactions. These smart contracts on Bitcoin are
often referred to as script-based contracts. Researchers have focused on
studying the construction and capabilities of Bitcoin’s scripting language,
such as Ivy (ivy, 2017), BALZAC (Atzei et al., 2018b), SIMPLICIT (O’Connor,
2017), and BITML (Atzei et al., 2019).

  * •

Ehtereum is the pioneering blockchain platform that introduced the deployment
of smart contracts. It allows developers to create their own smart contracts
using Solidity, a Turing-complete programming language. These smart contracts
are executed on the Ethereum Virtual Machine (EVM), which provides a runtime
environment for their execution. The introduction of smart contracts on
Ethereum has significantly expanded the range of applications and use cases
for blockchain technology. This development has given rise to a new paradigm
known as Decentralized Applications (DApps), which leverage the capabilities
of smart contracts to enable decentralized and trustless interactions.
Solidity is designed specifically for Ethereum and allows developers to write
code that complies with EVM bytecode, which is the low-level representation of
smart contracts.

  * •

Hyperledger Fabric (HF) is a blockchain platform designed primarily for
enterprise. Unlike public blockchains like Bitcoin and Ethereum, HF operates
on a permissioned network where a defined set of trusted organizations
participate through a membership service provider (Androulaki et al., 2018).
In Hyperledger Fabric, smart contracts are referred to as chaincode. One of
the notable advantages of HF is its flexibility in terms of programming
language support for writing chain codes. Developers can choose from various
programming languages such as Golang, Java, and JavaScript to implement their
smart contracts, allowing them to leverage their existing expertise and use
the most suitable language for their application (Khan et al., 2021). Privacy
is another key feature of HF smart contracts.

  * •

EOSIO introduces several innovative features to the field of blockchain
technology, e.g., delegated proof of stake consensus (DPOS) and updatable
smart contracts (He et al., 2021). EOSIO supports a range of programming
languages, including C++, Python, and JavaScript, giving developers the
flexibility to choose the language they are most comfortable with and that
best suits their application requirements. This multi-language support enables
developers to leverage their existing skills and expertise, making it easier
to create and deploy smart contracts on the EOSIO platform. One key advantage
of EOSIO smart contracts is their ability to handle high transaction
throughput with almost 4,000 transactions per second (TPS) (EOS, 2022).

As the use of smart contracts becomes more widespread, the importance of their
security cannot be overstated. In the past few years, smart contracts have
suffered from an increasing number of security issues, leading to financial
losses and reputational damage. Therefore, it is crucial for academics and
industries to pay attention to the security of smart contracts and develop
techniques and tools to ensure their safety. Figure 1 illustrates an
increasing trend in both academic papers and software tools from 2016 to 2020,
indicating a growing interest and activity in smart contract research and
development. However, there has been a slight linear descent in the number of
papers and tools in the subsequent years of 2021 and 2022, which may suggest a
possible stabilization or saturation of the field. This further indicates a
perfect timing for conducting a substantial literature review of the field.
Nevertheless, it is important to note that the numbers alone do not provide
insights into the quality or impact of the papers and tools.

Figure 1. Papers published in the previous study from 2016 to 2022

###  2.2. Survey Methodology

The objective of our survey is to provide a comprehensive analysis of
different approaches to dealing with vulnerable smart contracts. To achieve
this, we have formulated a set of Research Questions (RQ) that outline the
scope of our review:

  1. RQ 1:

[Vulnerabilities] What are the common vulnerabilities that exist in smart
contracts, and how can we classify them based on their characteristics?

  2. RQ 2:

[Attacks] How do attackers exploit these vulnerabilities, and what are the
consequences of these attacks on smart contracts?

  3. RQ 3:

[Defenses] What defense methodologies are available to protect smart contracts
against attacks, and how do these defenses mitigate the risks associated with
vulnerabilities?

  4. RQ 4:

[Effectiveness] How effective are the existing vulnerability analysis tools in
identifying and detecting vulnerabilities in Solidity smart contracts, and
what are the strengths and limitations of these tools in terms of accuracy,
performance, and coverage?

  5. RQ 5:

[Tools and Benchmark] How do we select representative vulnerability analysis
tools for evaluation, and how can we create a standardized benchmark of
vulnerable and correct smart contract cases to evaluate the effectiveness of
these tools?

By addressing these research questions, our survey aims to provide
comprehensive insights into the vulnerabilities, attacks, defense mechanisms,
effectiveness of analysis tools, and the creation of a benchmark for smart
contracts. To achieve this, we conducted extensive searches across various
databases and search engines, including Google Scholar, IEEE Xplore, ACM
Digital Library, Springer Link, Scopus, and preprint repositories. We employed
the following keywords and search terms: “blockchain” AND “smart contracts”
AND “vulnerabilities” OR “security” OR “attacks”. Next, we anticipate a
substantial number of search results that require screening to identify
relevant papers. The screening process generally consists of two stages: a
title and abstract screening stage, followed by a full-text screening stage
(Polanin et al., 2019). Once we have identified the relevant papers, we assess
their quality based on predefined inclusion criteria. This generally involves
assessing the relevance, methodology, validity, reliability, credibility,
clarity, and impact. The selected papers should address the topic of smart
contracts in a meaningful way and provide valuable insights for our
investigation. The methodology employed should be suitable for addressing our
research questions, transparent, and capable of being replicated. The results
should be accurate and consistent, and the conclusions drawn should be well-
supported by the data. The authors should present their ideas clearly and
concisely, with the paper being free of errors and inconsistencies.
Furthermore, the paper should have made a significant contribution to the
field of smart contracts.

After evaluating these quality attributes, we have collected 174 related
papers from 72 conference proceedings (including CCS, IEEE S&P, NDSS, USENIX,
Euro S&P, Financial Crypto, ASIA CCS, ICSE, ASE) and 11 journals (including
IEEE TSE, IEEE COMST), as well as preprints published between 2015 and 2022.
Once we have assessed the quality of the selected papers, we proceed to
extract the relevant data from them. This process involves gathering
information about the research questions, methodology, findings, and
conclusions presented in each paper. We have described the collected articles
in an online repository available at: https://sites.google.com/view/weifar-sc-
survey-publication.

##  3\. Vulnerability in Smart Contracts

Figure 2. A classification of smart contracts vulnerabilities and their
causes, where $\CIRCLE$ means the vulnerability has already been solved,
$\Circle$ means the vulnerability is widely discussed (not solved), and
$\LEFTcircle$ means the vulnerability has been fixed by specific approaches or
tools, VE means vulnerabilities of Ethereum, VH means vulnerabilities of HF,
VS means vulnerabilities of ESOIO.

This section presents a robust methodology for effectively identifying and
categorizing vulnerabilities in blockchain smart contracts. To ensure
comprehensive coverage of various vulnerability types, our investigation is
conducted from multiple perspectives. For Ethereum smart contracts, we
primarily rely on two key projects: the Decentralized Application Security
Project (DASP) 111https://dasp.co/ and the Smart Contract Weakness
Classification (SWC) Registry 222https://swcregistry.io/. DASP provides a
ranking of the top 10 smart contract vulnerabilities. However, it should be
noted that this list has not been updated since its initial release in 2018.
On the other hand, the SWC Registry provides an implementation of weakness
classification and currently lists 37 vulnerabilities (as of the time of
writing). Although it lacks a concrete classification and ranking, it offers
valuable insights into specific vulnerability types.

In addition to these projects, we also draw insights from several related
research papers, including (Atzei et al., 2018a; Lv et al., 2021; He et al.,
2021; Perez and Livshits, 2021; Hu et al., 2021b; Rameder et al., 2022). By
diligently collecting and examining all identified smart contract
vulnerabilities and their respective causes, our aim is to establish a
comprehensive methodology for categorizing the root causes of vulnerabilities
in blockchain smart contracts. This methodology is built upon the well-
established Common Weakness Enumeration (CWE) rules and effectively identifies
four primary root causes of vulnerabilities: coding standards, data
authenticity, access control, and control flow management. To illustrate our
classification framework, Figure 2 provides a visual representation of smart
contract vulnerabilities based on their root causes and corresponding
secondary causes. Our classification framework encompasses 14 distinct
secondary causes, which are associated with 40 specific vulnerabilities found
in Ethereum, Hyperledger Fabric (HF), and EOSIO. Furthermore, the figure also
indicates the status of each vulnerability, indicating whether it has been
eliminated, can be mitigated by specific methods, or remains unsolved.
Recognizing the lack of consistency in the naming and definition of
vulnerabilities across various studies, we have taken measures to ensure
clarity and uniformity in our analysis. As part of our research, we have
standardized the names of these vulnerabilities. Furthermore, we offer
detailed explanations for each vulnerability to promote better comprehension
and facilitate future research and analysis.

###  3.1. Improper Adherence to Coding Standards

This type of weakness happens when a smart contract is not developed in
accordance with established coding rules and best practices. This issue often
arises due to the relative novelty of programming languages used for smart
contracts, leading to a shortage of experienced developers in the domain.
Furthermore, some developers may lack a comprehensive understanding of the
specific coding standards for these programming languages, resulting in
mistakes and vulnerabilities within the smart contract code. Improper
adherence to coding standards can manifest in various ways:

####  3.1.1. Syntax Errors (VE1, VE2)

These errors occur when the code violates the syntax rules of the programming
language, such as spelling and punctuation flaws. Two specific examples of
syntax errors are typographical error (VE1) and Right-To-Left-Override control
character (VE2). VE1 refers to a typographical error in the code where an
incorrect operator is used, and VE2 involves the misuse of the U+202E unicode
character. Both of these vulnerabilities can be mitigated by following best
practices and employing preventive measures.

####  3.1.2. Version Issues (VE3, VE4, VE5, VE6, VE7)

Version issues in smart contracts can arise due to the rapid progress and
updates in smart contract technology, including changes in compiler versions.
When developers write code using outdated or deprecated functions, operators,
or coding standards in a new compiler version, it can result in unexpected
behaviors and potentially exploitable states. This category of vulnerabilities
includes five specific flaws: outdated compiler version (VE3), floating pragma
(VE4), use of deprecated Solidity functions (VE5), incorrect constructor name
(VE6), and uninitialized storage pointer (VE7). To avoid these
vulnerabilities, it is essential to stay updated on the latest version of the
compiler and adhere to the recommended coding standards and best practices.

####  3.1.3. Irrelevant Code (VE8, VE9, VE10)

Irrelevant code in smart contracts refers to code that is not essential for
the execution or functionality of the contract. While this code may not
directly impact the correctness of the contract, it can introduce security
vulnerabilities or make them harder to detect. It is not uncommon for
programming code to contain unused or shadowing parts. This category of
vulnerabilities includes three specific flaws: presence of unused variables
(VE8), code with no effects (VE9), and shadowing state variables (VE10). To
mitigate these vulnerabilities, it is important for contract writers to
thoroughly test the functionality and behavior of the code before deployment.

####  3.1.4. Visibility (VE11, VE12)

Solidity provides visibility labels for functions and variables, namely
public, external, private, or internal. Each visibility label determines who
can access or call specific functions or variables. The default visibility
setting in Solidity is public, which means that if the contract writer does
not explicitly specify the visibility, functions and variables will be treated
as public by default. Forgetting to set the appropriate visibility for a
function or variable can lead to two vulnerabilities: function default
visibility (VE11) and state variable default visibility (VE12). To mitigate
these risks, contract writers should carefully consider the suitable
visibility for each function and variable.

###  3.2. Insufficient Verification of Data Authenticity

This type of weakness occurs when systems fail to properly verify the origin
or authenticity of data, which can allow attackers to manipulate or access
sensitive information. This can lead to a wide range of security issues,
including cryptographic signatures and cryptographic data.

####  3.2.1. Cryptographic Signatures (VE13, VE14, VE15)

Cryptographic signatures play a crucial role in validating the authenticity
and integrity of data within blockchain systems. In Ethereum (and Bitcoin),
the Elliptic Curve Digital Signature Algorithm (ECDSA) is commonly used for
cryptographic signature generation and verification. However, there are
certain vulnerabilities related to cryptographic signatures that can be
exploited by attackers: signature malleability (VE13), missing protection
against signature replay attacks (VE14), and lack of proper signature
verification (VE15). To mitigate these vulnerabilities, it is of utmost
importance to implement robust signature verification mechanisms.

####  3.2.2. Cryptographic Data (VE16, VS1, VS2)

This type of vulnerability in smart contracts refers to situations where
sensitive data, despite being marked as private, can still be accessed by
unauthorized parties. This vulnerability arises due to the inherent
transparency of blockchain transactions, which allows the content of
transactions to be readable by anyone. Attackers can easily access and acquire
the data stored in the contract, leading to significant financial losses for
the contract creator and participants. The vulnerabilities associated with
cryptographic data include unencrypted private data on-chain (VE16), fake EOS
(VS1), and forged notification, fake receipt (VS2). To address these
vulnerabilities, it is crucial to prioritize the proper encryption of
sensitive data before storing it on-chain.

###  3.3. Improper Access Control

This type of weakness arises when unauthorized users gain access to a contract
and can perform actions that they should not be allowed to. Such
vulnerabilities can have significant repercussions for the smart contract
ecosystem, including financial losses and other adverse outcomes. Improper
access control vulnerabilities manifest in two primary forms: unprotected low-
level function and coding issues. Addressing these vulnerabilities is crucial
to maintaining the security and integrity of smart contracts.

####  3.3.1. Unprotected Low-level Function (VE17, VE18, VE19)

Users can utilize Solidity’s low-level functions SELFDESTRUCT, tx.origin, and
DELEGATECALL to control contracts. These low-level functions provide powerful
capabilities but can be easily abused by malicious users if not used with
caution. The following are the vulnerabilities associated with unprotected
low-level functions:

  * •

Unsafe suicide (VE17) The SELFDESTRUCT function allows a contract to be
removed from the blockchain, returning any remaining Ether to a designated
target address. While this can be useful in certain scenarios, it carries
risks. If Ether is sent to a contract that has self-destructed, the funds will
be permanently lost and cannot be recovered. Consequently, it is imperative to
exercise caution when utilizing the SELFDESTRUCT function. Developers should
carefully consider the variables and conditions involved before employing this
function.

  * •

Authorization through tx.origin (VE18) The tx.origin variable represents the
address that initiated a transaction, while msg.sender represents the
immediate invoker of a function. This vulnerability happens when one contract
calls another contract, tx.origin does not represent the calling address but
rather the original initiator of the transaction. This can result in funds
being transferred to the wrong address. To mitigate this vulnerability, it is
recommended to use msg.sender instead of tx.origin for authorization checks.

  * •

Unsafe delegatecall (VE19) This vulnerability arises from the DELEGATECALL
instruction, which allows third-party code to be executed within the context
of a current contract. This vulnerability, also known as delegatecall to
untrusted callee, can be exploited by attackers to take control of another
contract, especially in proxy contracts where code can be dynamically loaded
from different addresses at runtime. If an attacker can manipulate the address
used in DELEGATECALL, they may modify storage or execute malicious code,
leading to unauthorized actions such as fund theft or contract destruction.

####  3.3.2. Coding Issues (VE20, VE21)

Due to unintentionally exposing some functions, malicious parties can withdraw
some or all Ether from the contract account. This type of flaw leads to
unprotected Ether withdrawal (VE20) and write to arbitrary storage location
(VE21). This type of flaw can be avoided by carefully designing the code or
structure.

###  3.4. Insufficient Control Flow Management

This type of weakness occurs when attackers can exploit the openness of the
public blockchain to gain control over the program’s execution in unexpected
ways. This weakness can manifest in various forms as follows:

####  3.4.1. Improper Input (VE22, VE23, VE24)

Due to error handling in EVM, improper input can cause assert violation
(VE22), requirement violation (VE23) and wrong address (VE24). The Solidity
assert(), require(), as guard functions are introduced to improve the
readability of contract code. However, assert() and require() require strong
logical conditions, and improper input will cause errors. Moreover, the length
of a contract address should be 40 hexadecimal characters. If the address
length is incorrect, the contract can still be deployed without any warning
from the compiler. Ethereum automatically registers a new address that is
owned by nobody, and any Ether sent to this address becomes inaccessible. To
mitigate these vulnerabilities, it is important to carefully handle input
validation.

####  3.4.2. Incorrect Calculation (VE25, VH1, VE26, VS3)

This type of weakness happens when contracts perform a calculation that
generates incorrect results and that may lead to a larger security issue such
as arbitrary code execution. Arithmetic overflow/underflow (VE25, VH1) is the
most common error in software, and it both happens in Ethereum and HF. Call-
stack overflow (VE26) occurs due to EVM imposing a limit on the depth of the
call-stack, allowing a maximum of 1024 nested function calls. If an attacker
successfully reaches this limit by repeatedly invoking functions, it can
result in a call-stack overflow vulnerability. Once the call-stack reaches its
maximum depth, subsequent instructions, such as the send instruction, will
fail. Asset overflow (VS3) specifically pertains to the EOSIO blockchain. It
occurs when there is an overflow in the asset type, which represents token
balances and other asset values on the EOSIO platform.

  * •

Arithmetic overflow/underflow (VE25) This vulnerability, commonly known in
software programming, is not specific to smart contracts. It occurs when an
arithmetic operation produces a value that exceeds the maximum or minimum
range of integer representation. In Ethereum contracts, this vulnerability
arises due to the behavior of the EVM’s integer arithmetic and the lack of
automatic checks for arithmetical correctness. For instance, if the result of
an addition operation surpasses the maximum value representable by a specific
integer type, it wraps around to a lower-than-expected value without raising
an error or warning. Research by Torres et al. (Torres et al., 2018) has
identified over 42,000 contracts, particularly ERC-20 Token contracts,
vulnerable to arithmetic overflow/underflow. To mitigate this issue, it is
advisable to employ libraries such as SafeMath (Saf, 2018).

####  3.4.3. Denial of Service (VE27, VE28, VE29)

Denial of Service vulnerabilities can affect smart contracts and result in
exceptions that may lead to undesirable consequences such as contract lock-ups
or freezing of funds. There are multiple ways in which DoS attacks can be
carried out, with two primary incentives: failed calls and gas consumption.
One type of DoS vulnerability is DoS with failed call (VE27), where an
external call, whether accidental or deliberate, fails. This vulnerability is
particularly relevant in payment scenarios where multiple calls are executed
within a single transaction. The failure of an external call can disrupt the
intended flow of the contract, potentially leading to undesired consequences.
Another DoS problem can be concluded as gas-related vulnerabilities. Although
gas is a mechanism designed to prevent resource abuse, attackers can exploit
this mechanism to trigger the other two vulnerabilities: insufficient gas
griefing (VE28) and DoS with block gas limit (VE29). Mitigating these DoS
vulnerabilities requires careful design and consideration of gas usage.

  * •

DoS with block gas limit (VE29) To safeguard the network, each block has a
predetermined maximum amount of gas that can be consumed, known as the Block
Gas Limit. The gas consumption of a transaction must be less than or equal to
the Block Gas Limit; otherwise, the transaction will fail to execute and any
changes made during its execution will be rolled back. This ensures that no
single transaction monopolizes excessive resources within a block, promoting
fair usage and preventing DoS attacks that could overwhelm the network. It is
important to note that different EVM instructions have varying gas costs. Some
operations, such as ADD, AND, and POP, have relatively low gas costs, while
others, like SSTORE, incur higher gas costs. This differentiation encourages
efficient and responsible use of gas resources.

####  3.4.4. Use of Low-level Function (VE30, VE31, VE32, VE33)

Solidity’s low-level functions, such as call, transfer, send,mstore and
abi.encodePacked, provide users with control and flexibility when interacting
with smart contracts. However, improper use of these low-level functions can
introduce unexpected behavior and vulnerabilities into the contract’s program
logic. These vulnerabilities include unchecked send (VE30), arbitrary jump
with function type variable (VE31), hash collisions (VE32), and message call
with hardcoded gas amount (VE33). To mitigate these vulnerabilities, it is
crucial to carefully review and validate the usage of low-level functions,
handle exceptions appropriately, account for potential changes in gas costs,
and implement robust input validation and verification mechanisms.

  * •

Unchecked send (VE30) This vulnerability is also described as unchecked low-
level call unhandled exceptions, or exception disorder. This vulnerability
happens when the call fails accidentally or an attacker forces the call to
fail. In some cases, developers may include code to check the success of the
call, but they neglect to handle the exceptions properly. As a result, funds
intended for transfer may not reach the intended recipient. This vulnerability
stems from the inconsistent exception-handling behavior in Solidity, which can
lead to unexpected outcomes if not handled correctly.

####  3.4.5. Improper Behavioral Workflow (VE34, VE35, VE36, VE37)

It refers to vulnerabilities that arise when the expected order or sequence of
operations within a smart contract is manipulated by malicious users, leading
to unexpected states or undesired behavior. These vulnerabilities include
reentrancy (VE34), unexpected Ether balance (VE35), incorrect inheritance
order (VE36), and infinite loop (VE37). Unexpected Ether balance (VE35) occurs
when malicious users intentionally send funds to a contract in a specific
manner to disrupt its intended behavior or cause a denial-of-service
condition. By manipulating the contract’s ether balance, attackers can affect
the contract’s functionality and, in extreme cases, render it unusable.
Incorrect inheritance order (VE36) is a vulnerability that arises from the
improper ordering of contract inheritance. Malicious users can manipulate the
inheritance order to achieve unexpected outcomes and potentially exploit
vulnerabilities. Infinite loop (VE37) refers to a vulnerability where a
contract falls into an infinite loop, leading to non-termination of contract
execution.

  * •

Reentrancy (VE34) This vulnerability occurs when a contract invokes a function
from an external contract, and the called contract has sufficient gas to
invoke a callback into the calling contract. This creates a loop where the
called contract re-enters the calling contract before the initial invocation
is completed. Malicious attackers can exploit this vulnerability to manipulate
the execution flow and potentially exploit vulnerabilities present in the
contract. It is crucial to carefully review and secure contract interactions
to prevent re-entrance attacks and ensure the integrity and security of the
smart contract system.

####  3.4.6. Consensus Issues (VE38, VE39, VE40, VS4)

In the blockchain, the synchronization of subsequent blocks with the majority
of the network relies on following a consensus protocol, such as Proof of Work
(PoW) or Proof of Stake (PoS). This consensus protocol allows network
participants sufficient time to reach an agreement on which transactions
should be included in the blocks. However, the synchronization process itself
introduces vulnerabilities that can be exploited by attackers. These
vulnerabilities include transaction order dependency (VE38) (TOD), time
manipulation (VE39), and bad randomness (VE40, VS4).

  * •

TOD (VE38) This vulnerability, also known as Frontrunning, occurs due to the
prioritization mechanism for transactions in blockchain blocks. Miners have
the ability to choose which transactions to include in a block and the order
in which they are arranged. Since transactions are often prioritized based on
gas price, a malicious miner who can see and react to transactions before they
are mined may manipulate the transaction order to their advantage. By varying
the order of transactions and manipulating the output of the contract, they
can manage undesirable outcomes or financial losses for users.

  * •

Time manipulation (VE39) This vulnerability arises when smart contracts rely
on the timestamp information from blocks to perform certain functions. In
Solidity, the current timestamp can be obtained using block.stamp or now.
However, this timestamp value can be manipulated by miners. If a contract’s
functionality is dependent on the timestamp, miners can profit by choosing a
suitable timestamp to manipulate the contract’s behavior. This vulnerability
is also referred to as block values as a proxy for time.

  * •

Bad randomness (VE40) This vulnerability refers to vulnerabilities in the
generation of random numbers within smart contracts. Random numbers are often
used to make decisions or determine outcomes. If the random number generation
process is flawed, malicious actors may be able to predict the outcome of the
contract and exploit it. One example of bad randomness is the use of a
predictable seed value for the random number generator. If an attacker can
guess or determine the seed value, they can predict the generated random
numbers and manipulate the contract accordingly to their advantage.

###  3.5. Common Vulnerability Ranking

Figure 3. Vulnerabilities Frequency Statistics

Since the last update of the DASP (Decentralized Application Security Project)
in 2018, we have created a new list of the top 10 smart contract
vulnerabilities that pose significant risks to the security and functionality
of contracts. This list is based on the frequency of occurrence among various
analysis tools available at https://sites.google.com/view/sc-analysis-
toollist. Figure 3 provides statistics on the occurrence of 22
vulnerabilities. The top 10 vulnerabilities are as follows: reentrancy (VE34),
arithmetic overflow/underflow (VE25), DoS with block gas limit (VE29), unsafe
suicidal (VE17), unsafe delegatecall (VE19), unchecked send (VE30), TOD
(VE38), time manipulation (VE39), authorization through tx.origin (VE18), and
various other vulnerabilities. These vulnerabilities have been identified as
the most common and high-risk issues that developers should prioritize when
assessing the security of their smart contracts.

Reentrancy attracts significant attention from researchers due to its
difficulty in detection and mitigation. The complex and decentralized nature
of smart contracts makes it challenging to ensure the atomic execution of
functions and proper handling of reentrant calls. Arithmetic
overflow/underflow is a common issue in software programs, particularly those
written in low-level languages. Gas usage plays a crucial role in the EVM and
the smart contract ecosystem, and accurately estimating the required gas for
an operation can be difficult. Given that smart contract applications often
handle sensitive data and substantial amounts of value, DoS with block gas
limit can lead to denial-of-service attacks, data corruption, and financial
losses for users. Unsafe suicidal, unsafe delegatecall, and authorization
through tx.origin vulnerabilities occur when the access control of a smart
contract is flawed. Access control determines which entities can interact with
the contract and what actions they can perform. These vulnerabilities can
result in security risks and potential financial losses when access control is
compromised. Unchecked send occurs when a contract fails to handle exceptions
from failed calls appropriately. This vulnerability causes the smart contract
to behave unexpectedly and compromises its secure operation. TOD, time
manipulation, and bad randomness vulnerabilities are related to consensus
issues influenced by the blockchain network. Smart contracts are executed on
the blockchain and must follow the same transaction order as the underlying
blockchain. This means that even if a smart contract is designed to be
resistant to TOD and time manipulation, it can still be vulnerable if the
blockchain is not resistant to these issues.

In this section, we performed a comprehensive analysis of the root causes of
vulnerabilities in the smart contract domain and introduced a novel
classification system to effectively categorize them. Furthermore, we
conducted a statistical ranking of the most frequently encountered
vulnerabilities based on existing research. These findings offer conclusive
and precise answers that effectively address our research question, RQ1, as
outlined in Section 2.2.

By gaining a good understanding of these vulnerabilities in smart contracts
and their ranking, developers can effectively allocate their time and
resources, prioritizing the resolution of the most critical security concerns.
Additionally, to fully comprehend the potential damage caused by these
vulnerabilities, it is crucial to explore the common types of attacks that can
exploit them. By carefully examining the relationship between vulnerabilities
and attacks, developers can identify potential attack vectors and proactively
implement robust measures to mitigate these risks.

##  4\. Attacks on Smart Contracts

Over the past six years, smart contracts have experienced a substantial
increase in daily transaction volume, rising from an average of 23
transactions per day in 2016 to an average of 4 million transactions per day
in 2021 (eth, 2018a). Unfortunately, this growth has also led to an increase
in the number of attackers exploiting vulnerabilities in smart contracts.
Consequently, several high-profile attacks have occurred, resulting in
substantial financial losses (Harrison, 2023).

Figure 4. Several high-profile attacks from 2016 to 2021

One of the most notable attacks on smart contracts was the DAO attack in 2016,
which led to millions of dollars worth of Ether being drained from the
organization. Since then, smart contracts has experienced several high-profile
attacks from 2016 to 2021, as shown in Figure 4. To gain a better
understanding of these attacks, we have analyzed and identified eight
representative attack patterns. Figure 5 illustrates the major application
domains of smart contracts and the corresponding targeted attack patterns.
Additionally, we conduct an examination of the vulnerabilities that contribute
to these attacks. Through the classification of vulnerabilities based on known
attack patterns, we can identify common weakness that require attention.
Following this analysis, we provide a comprehensive breakdown of each attack,
shedding light on the specific vulnerabilities that contribute to these
attacks.

Figure 5. The relationships between attacks and vulnerabilities

###  4.1. The DAO Attack (A1)

The DAO (Decentralized Autonomous Organization) was a groundbreaking project
launched on the Ethereum blockchain in 2016. It aimed to create a
decentralized venture capital fund where participants could invest in projects
and vote on funding decisions through the use of smart contracts. The DAO
project gained significant attention and raised over $150 million USD in
funding from investors. However, the DAO’s success was short-lived as it fell
victim to a critical security vulnerability. In June 2016, an attacker
exploited a flaw in the DAO’s smart contract code, allowing them to drain
approximately $60 million USD worth of ether from the organization (The,
2022). This event, known as the DAO attack, was a significant setback for the
Ethereum community and led to a contentious debate about the immutability of
blockchain transactions and the need for a hard fork to recover the stolen
funds. Ultimately, a hard fork was implemented to create a new version of the
Ethereum blockchain that reversed the effects of the hack and returned the
stolen funds to their rightful owners. Following the occurrence of The DAO
hack, other smart contracts, such as Spankchain (Palmer, 2018) and Lendf.me
(Riley, 2020), also experienced losses due to comparable security
vulnerabilities. Atzei et al. (Atzei et al., 2017) provided two attack
contract examples, called Mallory and Mallory2. In Mallory, attacker
manipulates the control flow and exploits reentrancy (VE34). In Mallory2,
attacker efficiently exploits arithmetic overflow/underflow (VE25) and
unchecked send (VE30) vulnerabilities by using only two calls.

###  4.2. Parity Wallet Attack (A2)

The Parity Wallet attack encompasses two distinct incidents that occurred in
2017. During these incidents, the Parity Multisig Wallet suffered breaches,
leading to substantial financial losses. The Parity Wallet is comprised of two
components: a library contract and wallet contracts. The library contract
contains the essential functions of a wallet, while the wallet contracts act
as proxies that delegate calls to the library contract through the
delegatecall mechanism. In both incidents, the vulnerabilities enabled the
attackers to obtain unauthorized control over the wallets. The first incident
is caused by exploiting unsafe delegatecal (VE19) and more than 30M USD worth
of ether is drained (Palladino, 2017). In this incident, the attacker
initiated two transactions to manipulate each contract involved. The first
transaction was aimed at gaining ownership of the victim’s wallet contract.
The second incident on the Parity Multisig Wallet exploited the vulnerability
known as suicide (VE17) and resulted in the locking of more than $280 million
USD worth of funds (Petrov, 2017). In this incident, the attacker leveraged
the delegatecall mechanism to initialize themselves as the owner of the wallet
contract, similar to the first incident.

###  4.3. Fomo3D Attacks (A3)

The Fomo3D contract was an Ethereum game where participants could purchase
keys using Ether and refer others to the game to earn more Ether. The
objective of the game was to be the last participant to purchase a key before
the timer expired, thereby winning the entire pot of Ether. The attacker
purchased a ticket and then sent multiple transactions with high gas prices in
rapid succession, effectively consuming a significant portion of the block’s
gas limit. This action caused other transactions related to Fomo3D, including
the key purchases made by other participants, to be delayed or stuck in a
pending state until the timer ran out. The attackers gain an advantage by
exploiting two vulnerabilities: bad randomness (VE40) and DoS with block gas
limit (V29).

###  4.4. KotET Attack (A4)

The King of the Ether Throne (KotET) contract was also a game contract where
participants competed to win the throne and receive all the Ether held in the
contract. This game contract was implemented as a contract account on the
Ethereum blockchain. The KotET attack, which occurred in February 2016 (of the
Ether Throne, 2016), exploited two vulnerabilities: unchecked send (VE30) and
insufficient gas griefing (VE28). In the attack, when the KotET contract
attempted to transfer funds to another wallet contract, both contracts
required sufficient gas to successfully process the transaction. However, if
the wallet contract had insufficient gas, it would fail to complete the
payment, resulting in the funds being returned to the KotET contract.
Importantly, the KotET contract was not aware of the payment failure, and the
latest player would be crowned as the King, while the compensation payment
intended for the previous player would not be sent.

###  4.5. BatchOverflow Attack (A5)

The BatchOverflow attack, which occurred in April 2018, targeted the Beauty
Ecosystem Coin (BEC) token. The attack exploited arithmetic overflow/underflow
(VE25) vulnerability to achieve an unauthorized increase in digital assets.
This vulnerability resulted in the theft of BEC tokens and a temporary
shutdown of the exchange platform (BEC, 2018). According to the blockchain
security firm, PeckShield (pec, 2018), the BatchOverflow attack was not
limited to the BEC token. According to the blockchain security firm
PeckShield, they discovered similar integer overflow vulnerabilities in around
12 other token smart contracts. Some examples include SMT (proxyOverflow), UET
(transferFlow), SCA (multiOverflow), HXG (burnOverflow), and others.

###  4.6. Frontrunning Attack (A6,A7)

Both the DEXs attack and the Bancor attack can be categorized as Frontrunning
attacks. The concept of Frontrunning is not exclusive to blockchain and is
commonly observed in traditional financial markets. Frontrunning involves
manipulating financial markets by gaining undisclosed information about
transactions beforehand (Torres et al., 2021a). This practice is generally
deemed illegal in most countries. In the context of blockchain, every
transaction is publicly visible in the pending pool before being included in a
block. Miners, who have the authority to choose which transactions to include,
often prioritize those with higher gas prices. This creates an opportunity for
attackers to manipulate the transaction order and maximize their own profits.
Frontrunning attacks exploit the vulnerability known as TOD (VE38), which is
also referred to as the Frontrunning vulnerability. Eskandari et al.
(Eskandari et al., 2019) categorize this vulnerability into three types of
attacks: displacement, insertion, and suppression attacks.

####  4.6.1. DEXs Attack (A6)

The decentralized exchange (DEX) is an exchange platform built on smart
contracts where users can exchange their ERC-20 tokens for ether or other
tokens. Frontrunning attacks have become a significant concern in DEXs. These
attacks exploit TOD vulnerability to manipulate the execution of transactions
and gain an unfair advantage in trading. When a searcher detects a transaction
that can yield a profit, it attempts to front-run that transaction by
submitting its own transaction with higher gas fees to ensure its execution
before the victim’s transaction. These front-running attacks are performed by
highly competitive bots that aim to maximize their profits by extracting
Miner’s Extractable Value (MEV). According to Flashbots (flashbots, 2023),
searchers extracted approximately 691 million USD worth of value from Ethereum
in January 2023 alone.

####  4.6.2. Bancor Event (A7)

The Bancor ICO is a decentralized exchange platform that allows users to
create and trade their own tokens. During the audit of its exchange smart
contract, two vulnerabilities were discovered: TOD (VE38) and function default
visibility (VE11). The attacker exploited the TOD vulnerability, which enabled
them to execute transactions ahead of others, resulting in a profit of 135,229
USD worth of ether (ZenGo, 2020). Fortunately, no real-world attack occurred,
but the vulnerability itself was identified and addressed.

###  4.7. Honeypots (A8)

Honeypots in the context of smart contracts are a type of fraudulent scheme
that capitalizes on security vulnerabilities while employing deceptive
tactics. The fundamental concept of a honeypot involves intentionally creating
a smart contract that appears to possess an obvious flaw or vulnerability,
enticing potential victims to exploit it for financial gain. However, the
contract is deliberately designed in a way that when someone attempts to take
advantage of the apparent vulnerability, they end up losing their funds
instead. Honeypots manipulate human greed and the desire for quick profits,
luring unsuspecting users into falling for the trap. The aim is to present an
enticing opportunity for financial gain, while in reality, it is a trap
orchestrated by malicious actors. According to Torres et al. (Torres et al.,
2019b), honeypots typically take advantage of specific vulnerabilities to
carry out their deceptive schemes such as incorrect constructor name (VE6),
shadowing state variables (VE10), and incorrect inheritance order (VE36).

In this section, we have examined eight common attack patterns and their
associated lists of vulnerabilities. This analysis has allowed us to address
the second research question, RQ2, as outlined in Section 2.2, which focuses
on how these common attacks exploit vulnerabilities and the consequences of
such attacks. By studying past attacks, we gain valuable insights into common
vulnerabilities and attack patterns. This knowledge can be utilized by smart
contract developers to enhance the security of their contracts. While it may
be challenging to completely eliminate all attacks on vulnerable smart
contracts, there are steps that can be taken to minimize risks and improve
contract security. By implementing best practices and employing appropriate
security measures, developers can reduce the likelihood of their contracts
being exploited by attackers. Building upon our understanding of attack
patterns, we can now explore various defense methodologies in the next
section.

##  5\. Defense Methodologies

Defense technologies evolve alongside the advancement of attacks, and there is
a substantial body of work on security measures for smart contracts (Zhou et
al., 2020; Chen et al., 2021b; Torres et al., 2021a). Figure 6 provides an
overview of a comprehensive set of research solutions for smart contract
defense. Generally speaking, defense strategies for smart contracts can be
categorized into two main groups: proactive and reactive. Proactive defense
strategies involve taking preventive measures to mitigate attacks before they
occur, while reactive defense strategies focus on responding to attacks after
they have happened. Proactive defense strategies aim to address known attacks
that have been previously identified and studied, with defense mechanisms
developed specifically for them. These attacks can be prevented or mitigated
using contract analyzers or security enhancements. Reactive defense
strategies, on the other hand, pertain to attacks that have not been
previously identified or studied, and for which defense mechanisms may not
exist. Monitoring contracts play a crucial role in addressing such attacks.
However, it is important to note that identifying vulnerabilities and
deploying monitoring contracts alone are insufficient for effective smart
contract defenses. The repair of vulnerable smart contracts is also a key
technology in the defense process (Rodler et al., 2021; Torres et al., 2022).
While defene encompasses a broader range of strategies and measures, repair
serves as a specific action to fix or address vulnerabilities. The following
section provides a detailed description of the defense methodologies involved.

Figure 6. Research ideas for the defense of smart contracts

###  5.1. Contract Analyzer

Contract analyzers play a crucial role in reducing the risk of vulnerabilities
in smart contracts before their deployment. Researchers employ various
methodologies to analyze smart contracts, many of which are publicly available
under open-source licenses. There are five common methodologies for smart
contract analysis, such as formal verification, symbolic execution, fuzzing,
intermediate representation, and machine learning.

####  5.1.1. Formal Verification

It is a mathematical-based technique to build and check formal proofs that
satisfy a particular property. Formal verification is applied to ensure that
software behaves and performs as expected in its specifications and
requirements based on large reachable state spaces. Smart contracts are often
written in programming languages that are amenable to formal verification
(Harz and Knottenbelt, 2018; Jiao et al., 2020). For example, the Solidity
programming language used for Ethereum smart contracts has a well-defined
syntax and semantics that can be precisely modeled and verified. For smart
contracts, we distinguish mainly two families of formal verification methods,
namely model checking and theorem proving.

Model checking It lists all possible states and checks them individually to
confirm whether the contract has the corresponding characteristic. Compared to
other programs, smart contracts have some unique characteristics that make
model checking particularly well-suited for vulnerability detection (Garfatta
et al., 2021; Abdellatif and Brousmiche, 2018; Ahrendt et al., 2019; Crincoli
et al., 2022). First, model checking is most effective on systems with a
finite number of states, and smart contracts are often small enough to be
modeled in their entirety. Second, smart contracts are often designed to be
deterministic, which makes it easier to construct formal models to accurately
capture their behavior. This technique is relevant to check partial
specifications early in the design process (Nehai et al., 2018). Model
checkers, such as SIPN (Bai et al., 2018), FDR (Qu et al., 2018), and NuSMV
(Nehai et al., 2018), are utilized to successfully verify the correctness and
necessary properties of smart contracts (Qu et al., 2018). Model checking is
typically used to detect specific types of vulnerabilities, such as buffer
overflows or integer overflows.

Theorem proving It is a technique that describes the desired properties of a
system using mathematical logic and uses a theorem prover to generate proofs
that verify these properties based on evidence rules. In the context of smart
contracts, theorem proving is used to ensure that a contract satisfies a
specific set of properties, such as correctness, safety, or liveness. Since
smart contracts are typically deterministic, theorem proving can construct
mathematical proofs to demonstrate the satisfaction of these properties.
Unlike model checking, which is limited to finite systems, theorem proving can
handle the verification of infinite systems. This makes it well-suited for
analyzing smart contracts that may involve complex interactions and potential
infinite behaviors. Several theorem provers, such as Coq and Isabelle/HOL,
have been developed to provide formal semantics and support the theorem-
proving process for smart contracts. For instance, Amani et al. extended the
existing definition of the Ethereum Virtual Machine (EVM) into Isabelle/HOL
with the consideration of gas, allowing for formal verification of EVM-based
smart contracts. However, it’s worth noting that formal verification through
theorem proving is a semi-automated process that often requires manual
interaction. It is commonly used to detect broader classes of vulnerabilities,
including logic errors and design flaws, rather than specific instances of
vulnerabilities.

####  5.1.2. Symbolic Execution

It systematically explores more possible execution paths simultaneously to
trigger deep program errors. This approach does not require a specified input
value but abstracts the input values into symbols. From the vulnerability
detection perspective, symbolic execution offers developers specific input to
the triggered vulnerability, which can be used to confirm or debug. Symbolic
execution has the advantage of achieving high test coverage with as few test
cases as possible, thereby digging out deep program errors. Moreover, symbolic
execution is often combined with constraint solving to reason whether an
execution path is reachable. However, when the program is large and complex,
symbolic execution will generate too many paths which may lead to path
explosion. A smart contract can be a maximum of 24KB or it will run out of gas
(Ehtereum, 2023). Therefore, symbolic execution is perhaps the most popular
approach for smart contracts. Moreover, Z3 SMT solvers are used to check which
paths are flexible. Oyente (Luu et al., 2016) was the first attempt for smart
contract verification, using a Control Flow Graph (CFG) representation of the
bytecode to identify vulnerabilities like transaction-ordering dependence,
timestamp dependence, mishandled exceptions and reentrancy. Other tools, like
Manticore and Maian, have extended the capabilities of symbolic execution to
detect additional vulnerabilities such as arithmetic overflow/underflow,
unsafe suicide, and unchecked send. However, scalability is a concern with
symbolic execution, especially in complex application scenarios. The
exploration of deep program paths can be slow and resource-intensive. SMARTEST
uses symbolic execution to identify vulnerable transaction sequences in smart
contracts (So et al., 2021). By combining symbolic execution with a language
model, SMARTEST can effectively prioritize program paths that are likely to
reveal vulnerabilities.

####  5.1.3. Fuzzing

It is a software testing technique that involves executing target programs
with a large number of abnormal or random test cases to detect
vulnerabilities. It has gained significant attention in both industry and
academia (Li et al., 2021; He et al., 2019) due to its simplicity and
practical effectiveness in identifying software vulnerabilities. Major
software vendors like Google (google, 2019) and Microsoft (Miscrosoft, 2019)
employ fuzzing techniques to uncover vulnerabilities in their products. In the
context of smart contracts, fuzzing has been utilized as a means of
vulnerability detection, although there are relatively fewer works
specifically focused on smart contract fuzzing in recent years. ContractFuzzer
(Jiang et al., 2018), for example, uses the Application Binary Interface (ABI)
specification of contracts as input for fuzzing to detect vulnerabilities. It
relies on user-provided input seeds. Echidna (crytic, 2019a), on the other
hand, uses falsified user-defined predicates or Solidity assertions as input
seeds, which are then subjected to grammar-based fuzzing to detect
vulnerabilities. Harvey (Wüstholz and Christakis, 2020) incorporates a
prediction component to generate new input seeds for gray box fuzzing. sFUZZ
(Nguyen et al., 2020) adopts an adaptive strategy to select input seeds, which
are then fed into the prominent fuzzer AFL (American Fuzzy Lop) (crytic,
2017).

However, these methods are more effective in finding shallow bugs and less
effective in identifying bugs that lie deep in the execution flow. This
limitation is due to the heavy reliance on input seeds in fuzzing. An
alternative approach that has shown promising results in traditional programs
is hybrid fuzzing, which combines fuzzing with symbolic execution. ILF
(Imitation Learning Fuzzer) (He et al., 2019) addresses this limitation by
using a symbolic execution expert to generate a large number of training
sequences, which are then fed into imitation learning prior to fuzzing. ILF
achieves improved coverage and performs well on both large and small
contracts. However, ILF is limited to the contracts used for imitation
learning in its training phase. ConFuzzius (Torres et al., 2021b), on the
other hand, leverages lightweight symbolic execution to analyze execution
traces and employs a constraint solver to obtain input seeds for the fuzzer.
This approach enhances the effectiveness of fuzzing by incorporating symbolic
execution-based analysis. By combining fuzzing with symbolic execution or
other complementary techniques, researchers aim to enhance the effectiveness
of vulnerability detection in smart contracts, addressing both shallow and
deep vulnerabilities.

####  5.1.4. Intermediate Representation

To accurately analyze smart contracts, some researchers also explore
converting contracts into an intermediate representation (IR) with highly
semantic information, which is more suitable for the analysis and detection of
common security issues. Different from formal verification, IR relies on
semantic-based transformation. The analysis process can be divided into four
stages: lexical analysis, syntax analysis, semantic analysis, and
transformation. The lexical analysis uses Scanner to check whether the input
code is a combination of several legitimate words; the syntax analyzer checks
whether the combination of these legitimate words meets grammatical rules;
semantic analysis checks whether semantics are reasonable; the transformer
converts source code or bytecode into machine code, such as XML. Then, the
analyzer detects vulnerabilities through specific methods.

Slither (Feist et al., 2019) transfer contracts to its internal representation
language (SlithIR) which uses Static Single Assignment (SSA) form to
facilitate the computation of code analyses. EthIR (Albert et al., 2018) based
on Oyente translates CFGs to a rule-based representation (RBR) of the
bytecode. Smartcheck (Tikhomirov et al., 2018) directly translates source code
into an XML-based IR and then checks it against XPath patterns. MadMax (Grech
et al., 2018) based on the Vandal (Brent et al., 2018) decompiler translates
EVM bytecode to a structured IR to check gas-related Vulnerabilities. NeuCheck
(Lu et al., 2021) employs the Solidity parser ANTLR to complete the
transformation from source code to an IR (XML parse tree). VRust (Cui et al.,
2022) successfully translates Rust source code of Solana smart contracts into
Mid-level IR.

However, there are two challenges in IR analysis: (1) Because of semantic
heterogeneity, it is unavoidable to produce semantic missing during the
security analysis; (2) IR takes more processing time.

####  5.1.5. Machine Learning

It has achieved encouraging results in the field of program security (Zheng et
al., 2020a; Chakraborty et al., 2022; Hanif et al., 2021). Compared with the
above methods, machine learning combines static analysis and dynamic
detection, so as to solve the problems of the high false negative rate of
static analysis and low code coverage of dynamic analysis. Moreover, machine
learning has good scalability and adaptability for novel vulnerabilities type.

There exist a few prior works that use machine learning methods to analyze
smart contracts. Tann et al. (Tann et al., 2018) introduced a long short-term
memory (LSTM) (Zheng et al., 2020a) model to handle the semantic
representations of smart contract opcode to detect contract security threats.
Their model can achieve higher detection accuracy than symbolic execution
analyzer Maian (Nikolic et al., 2018), where both are based on the same
vulnerabilities taxonomy. Qian et al. (Qian et al., 2020) applied the bi-
directional long short-term memory with the attention (BLSTM-ATT) mechanism in
their sequential model to reentrancy detection. This framework transforms
source code into contract snippets and feeds the sequential model with feature
vector representations parsed from these snippets. Zhuang et al. (Zhuang et
al., 2020) proposed a degree-free graph convolutional neural network (DR-GCN)
and a novel temporal message propagation network (TMP) detect vulnerabilities.
The source code of a contract is converted to a contracted graph and then to
the normalized graphs by a node elimination process. The normalized graphs are
fed to DR-GCN and TMP for vulnerability modeling and detection. ContractWard
(Wang et al., 2021) trains its machine learning model on bigram features
extracted from the opcodes of the compiled smart contract. SmartMixModel
(Shakya et al., 2022) extracts high-level syntactic features from source code
as well as low-level bytecode features from the smart contract. And then these
features are trained on a machine learning model.

Some researchers also proposed that machine learning will be more efficient if
it is in conjunction with fuzzing. SoliAudit (Liao et al., 2019) employs
machine learning to detect known vulnerabilities without expert knowledge or
predefined patterns and fuzzing to identify potential weaknesses. However,
there is no correlation between the two methods, and fuzzing is more of a
complement to machine learning in terms of the detection of vulnerabilities.
ILF (He et al., 2019) uses an imitation learning model to learn a fuzzer from
training sequences.

###  5.2. Security Enhancement

Before deployment, some measures can be done to enforce the security of smart
contracts. Gas and data are the most important factors for smart contracts.
Thus, if gas cost and data privacy have been carefully checked before being
deployed, the security of smart contracts will be enhanced. There are some
methods for gas cost and data privacy.

####  5.2.1. Gas Estimation and Optimization

Gas is one of the most important mechanisms in EVM to assign a cost to the
execution of an instruction. This mechanism can effectively prevent resource
abuse (especially DoS attack) and avoid “infinite” loops (Chen et al., 2017).
When issuing a transaction, the sender needs to specify a gas limit and a gas
price before submitting it to the network. Gas represents much more than just
the cost of processing transactions on the Ethereum network. A smart contract
is capable of running various applications, allowing it to form a
decentralized web. As such, while gas could technically be described as
“transaction fees”, it should be used with caution. Referring to Section 3,
there are several gas-related vulnerabilities. The EVM throws an exception
when a transaction run out of gas during its execution, and then EVM will
immediately return to the former state.

To prevent this, many Ethereum wallets, such as Metamask (METAMASK, 2023), can
statically estimate the cost of a transaction before it is executed. However,
there are many operations that are difficult to estimate during executions. In
order to address this problem, some researchers proposed some methods that
estimate gas and optimize smart contracts (Albert et al., 2019; Ashraf et al.,
2020; Danielius et al., 2020). Albert et al. proposed an automatic gas
analyzer Gastap that infers gas upper bounds for all its public functions
(Albert et al., 2019). Gastap requires complex transformation and analysis of
the source code that includes several key techniques: Oyente (Luu et al.,
2016), EthIR (Albert et al., 2018), Saco (Albert et al., 2014) and Pubs
(Albert et al., 2008). Gasol (Albert et al., 2020), as an extension of Gastap,
introduces an automatic optimization of the selected function that reduces
inefficient gas consumption. Li et al. (Chen et al., 2021a) developed a
GasChecker tool that identifies the gas-inefficient code of smart contracts.
They summarized ten gas-inefficient programming patterns that assisted users
in better tailoring contracts to avoid gas waste. Gas Gauge (Nassirzadeh et
al., 2021) can automatically estimate the gas cost for the target function and
the loop-bound threshold. Besides, Gas Gauge can find all the loops and
furnish the gas-related instances to help developers with suggestions. Li et
al. (Li et al., 2020b) estimated the gas for new transactions by learning the
relationship between the historical transaction traces and their gas costs.

####  5.2.2. Data Privacy-Preserving

In addition to gas concerns, another major concern for the smart contract is
private data (Kalodner et al., 2018). Since the openness and transparency of
public blockchains, the privacy overlay feature on the chain is absent. This
not only leads to some security issues but also prevents their wider adoption.
It is problematic for applications that handle sensitive data such as voting
schemes (McCorry et al., 2017), electronic medical records(Liu et al., 2018),
or crowdsensing (Perez and Zeadally, 2022).

A promising approach to address private data is to design new blockchain
infrastructures supporting private data (Kosba et al., 2016). Several
blockchain infrastructures have been proposed to support private data by
adding trust third-party assumptions, such as Hawk (Kosba et al., 2016),
Arbitrum (Kalodner et al., 2018), Ekiden (Cheng et al., 2019), and Town Crier
(Zhang et al., 2016). Hawk (Kosba et al., 2016) helps programmers write a
private smart contract without any specialists and generates an efficient
cryptographic protocol for interacting with other parties. Arbitrum (Kalodner
et al., 2018) helps programmers create a private smart contract by following
the specific behavior of a virtual machine (VM) and allows honest parties to
advance the VM state on-chain. Both Hawk and Arbitrum rely on trusted
managers, which may be instantiated with trusted computing hardware or a
multi-party computation among the users themselves. Ekiden (Cheng et al.,
2019) processes a smart contract over private data off-chain in trusted
execution environments (TEEs) and provides safe interaction among smart
contracts on-chain.

An alternative approach is hiding it with cryptographic primitives, such as
zero-knowledge proofs. Hawk (Kosba et al., 2016) relies on zero-knowledge
proofs to enforce the correctness of contract execution and money conservation
on the chain. Steffen et al. (Steffen et al., 2019) proposed zkay contracts
containing private data and utilized non-interactive zero-knowledge (NIZK)
proof to protect private data. To be more executable on blockchains, zkay
contracts are transferred into contracts equivalent in terms of privacy and
functionality. Zapper (Steffen et al., 2022) also leverages NIZK proof to
correct state updates without revealing private information and an oblivious
Merkle tree construction to hide the sender and receiver.

###  5.3. Runtime Monitoring

The capability to deploy smart contracts is one of the most important features
of blockchains. Once deployed on a blockchain, smart contracts become
immutable, including any vulnerabilities they may have. While tools are
available for scanning smart contracts prior to deployment, they often have
limited scopes and may not detect all vulnerabilities, leaving room for
unknown runtime attacks. As a solution to enhance the security of post-
deployment smart contracts, runtime monitoring techniques analyze and monitor
the runtime behavior of smart contracts, providing higher coverage and
precision in detecting attacks compared to pre-deployment analysis alone
(Ellul and Pace, 2018). Runtime monitoring can be categorized into transaction
monitoring and state monitoring.

####  5.3.1. Transactions Monitoring

As Ethereum can be seen as a transaction-based state machine, a transaction
contains much information aiming to change the blockchain state. This
information also can be used to detect and prevent attacks. ECFChecker
(Grossman et al., 2018) examines transactions to determine if they exhibit the
characteristics of a reentrancy attack, where a contract can be called
recursively before previous invocations have been completed. Sereum (Rodler et
al., 2019) aims to prevent reentrancy attacks by employing taint tracking
techniques. It tracks the flow of data from storage variables to control-flow
decisions, helping identify potential vulnerabilities (Hu et al., 2021a; Chen
et al., 2020). Both ECFChecker and Sereum rely on modified versions of
Ethereum Virtual Machine (EVM) and primarily focus on detecting reentrancy
attacks. In contrast, ÆGIS (Torres et al., 2019a, 2020) takes a broader
approach by providing an extensible framework for detecting new
vulnerabilities in smart contracts. It maintains attack patterns and reverts
transactions that match these patterns, thereby enhancing security. The
framework allows for the storage and voting of new attack patterns through a
smart contract, enabling the community to actively contribute to the detection
and prevention of novel attacks. SODA (Chen et al., 2020) based on a modified
EVM-based client provided a platform for developing various applications to
detect malicious transactions in real time. SODA has been integrated into
popular blockchains that support the EVM, increasing its accessibility and
usability. Horus (Zhou et al., 2021) leverages transaction graph-based
analysis to identify the flow of stolen assets. By examining the transaction
graph, Horus traces the movement of assets and detect potential theft or
unauthorized transfers.

####  5.3.2. State Monitoring

In addition to transactions, blockchain state variables can provide valuable
information about the real-time status of a smart contract. Monitoring and
analyzing the state variables can be an effective approach to detecting and
preventing attacks. Solythesis (Li et al., 2020a) allows users to instrument
user-specified invariants into smart contract code. These invariants represent
specific conditions that should always hold true during the execution of the
contract. By tracking the transactions that violate these invariants,
Solythesis can efficiently enforce powerful monitoring of the contract’s
state. This approach helps identify abnormal or unexpected changes in the
state variables and allows for proactive detection of potential
vulnerabilities. ContractGuard (Wang et al., 2020) takes a similar approach
but introduces the concept of an intrusion detection system (IDS) to monitor
the behavior of a deployed smart contract. The IDS continuously monitors the
state variables and looks for abnormal or suspicious behaviors that deviate
from expected patterns.

###  5.4. Post-deployment Repair

Ideally, smart contracts should be deployed with the highest possible level of
security. However, this presents a challenge not only for smart contracts but
also for all software programs. Furthermore, the underlying blockchain
technology ensures immutability, meaning that the past cannot be altered.
Consequently, updating the code of a deployed contract or addressing
vulnerabilities becomes unfeasible. Apart from fixing vulnerabilities, there
are numerous other reasons to modify contract code, including adapting
business logic or enhancing functionality.

####  5.4.1. Contract Migration

In many cases, an available approach is to deploy a new instance of the
contract and migrate old contract data to it. This approach is called contract
migration and has been successfully implemented in various token migration
events, such as Augur (Augur, 2018), VeChainThor(vechain, 2018), and TRON
(TRON, 2018). A contract migration process typically involves two steps: data
recovery and data writing (josselinfeist, 2018b). During data recovery, the
data from the old contract is extracted, including both public and private
variables. While retrieving public variables is relatively straightforward,
handling private variables and mappings can be more complex. Special measures
need to be taken to ensure the integrity and consistency of the migrated data.
To address the challenges associated with data migration, some developers
employ separate contracts to store and manage the data (OpenZeppelin, 2018).
This can simplify the migration process by separating the logic from the data
storage. By migrating the logic to a new contract and keeping the data in a
separate contract, the migration becomes more manageable. It’s important to
note that contract migration procedures can be costly, especially for token-
based contracts with a large number of accounts (josselinfeist, 2018b).
Migrating data for a large number of accounts requires careful planning and
execution to avoid potential issues and ensure the accuracy and security of
the migrated data.

####  5.4.2. Upgradable Contracts

Another promising approach to modify smart contracts code is upgradable
contract (josselinfeist, 2018a; Zheng et al., 2021; OpenZeppelin, 2018). This
approach involves incorporating an upgradability mechanism into smart
contracts, allowing for seamless upgrades without the need for data migration
or external reference updates. An upgradeable contract can be implemented by
setting up a proxy pattern architecture (Zheng et al., 2021). In this pattern,
one contract is split into two separate contracts, one for logic execution and
another for data storage. A logic contract stores no state but implements all
the business logic; a proxy contract holds all funds and all internal states,
but does not implement any business logic. Instead of replacing the entire
contract, only the logic contract needs to be modified or replaced. The proxy
contract remains intact, and all existing data and external references are
maintained. This allows for seamless upgrades without disrupting the
contract’s functionality or requiring data migration. Several approaches have
been proposed to realize upgradable contracts. Zeppelin (OpenZeppelin, 2018)
proposed three proxy pattern architectures: inherited storage, eternal
storage, and unstructured storage. All three patterns rely on the DELEGATECALL
instruction, thus these patterns are also called delegate-proxy patterns. For
example, EVMPatch (Rodler et al., 2021) uses a proxy pattern to enable the
quick and cost-effective upgrade of smart contracts. EVMPatch(Rodler et al.,
2021) utilizes the delegate-proxy pattern to enable quick and cost-effective
upgrades of smart contracts. It provides a framework for patching
vulnerabilities or adding new features to deployed contracts without requiring
data migration or disrupting the contract’s functionality.

In this section, we have thoroughly examined and categorized various defense
methodologies aimed at preventing or mitigating the damage caused by smart
contract attacks. The findings provide a clear and comprehensive response to
the third research question, RQ3, as outlined in Section 2.2. However, it is
important to acknowledge the existing dearth of empirical evidence that would
enable an evaluation of the effectiveness of these methodologies and their
associated tools. Despite their claims of superiority, it is imperative for
researchers and developers to undertake empirical studies to ascertain which
methods are truly practical and beneficial in real-world scenarios.

##  6\. Evaluation

Our objective is to provide a comprehensive overview of the state-of-the-art
automated analysis tools available for smart contracts. Given that the field
of smart contract analysis is relatively new and rapidly evolving, it can be
challenging to stay updated with the latest developments and understand the
strengths and limitations of existing tools. Therefore, we have conducted an
extensive review of the literature and websites to compile a list of the most
promising analysis tools for smart contracts. Additionally, to address RQ4 and
RQ5, which focus on evaluating the performance of existing tools, we propose a
systematic evaluation approach that involves selecting appropriate tools,
utilizing datasets of smart contracts, defining criteria for the assessment,
and conducting experiments.

###  6.1. Experimental Setup

####  6.1.1. Tool Selection

Vulnerability-detecting tools are the most widely used method to assist
developers in discovering security vulnerabilities in smart contracts. A wide
range of analysis tools has been developed for this purpose, and we have
compiled a list of 82 such tools based on academic literature and internet
sources. Table in https://sites.google.com/view/sc-analysis-toollist presents
the list of tools, along with key properties such as venue, methodology, input
object, open-source link, and vulnerability ID. However, despite the abundance
of vulnerability-finding tools, only a few papers have proposed a systematic
approach to evaluate their effectiveness (Ghaleb and Pattabiraman, 2020;
Durieux et al., 2020). To address this gap and answer RQ5, we adopted the four
selection criteria below proposed by Durieux et al. (Durieux et al., 2020).

  1. C1:

[Available] The tool must be publicly available and accessible for download or
installation with a command line interface (CLI).

  2. C2:

[Funcctionality] The tool must be designed especially for smart contracts and
must have the ability and detect vulnerabilities. This excludes constructing
artifacts like control flow graphs.

  3. C3:

[Compatibility] The tool must be the source code of the smart contract. That
excludes tools that only consider EVM bytecode.

  4. C4:

[Documentation] The tool must provide comprehensive documentation and user
guides.

These criteria were utilized to filter our list of tools, resulting in the
identification of 12 tools that meet the requirements: ConFuzzius
(christoftorres, 2021), Conkas (nveloso, 2020), Maian (ivicanikolicsg, 2018),
Manticore (trailofbits, 2019), Mythril (development team, 2019), Osiris
(christoftorres, 2018), Oyente (enzymefinance, 2018), Securify (eth sri,
2018), sfuzz (sfuzz, 2020), Slither (crytic, 2019b), Smartcheck (smartdec,
2018), and solhint (protofire, 2019).

####  6.1.2. Dataset Construction

One important issue when evaluating analysis tools is how to obtain a
sufficient number of vulnerable smart contracts. Although there are many open-
source analysis tools available, comparing and reproducing them can be
challenging due to the lack of publicly available datasets. Most analysis
tools primarily check or detect only some of the well-known Ethereum smart
contract vulnerabilities. To evaluate the effectiveness of any analysis tool,
it is crucial to establish a standard benchmark. While several researchers
have published their datasets (Durieux et al., 2020; Ghaleb et al., 2020;
ConFuzzius), these datasets have limitations such as small sample sizes or an
uneven distribution of vulnerable contracts. To address this limitation and
partially answer RQ5, we created an annotated dataset consisting of 110
contract test cases. These cases are divided into 11 sub-datasets, with 10
sub-datasets containing known vulnerabilities corresponding to the top 10
categories mentioned in Section 3, and one sub-dataset representing correct
contracts. These contracts vary in code sizes and encompass a wide range of
applications. We have made our benchmark publicly available on GitHub:
https://github.com/bit-smartcontract-analysis/smartcontract-benchmark.

####  6.1.3. Hardware Configuration

We obtained the most recent versions of the selected analysis tools from their
respective public GitHub repositories, except for version 0.3.4 of the
Manticore tool. The tools were executed on a 64-bit Ubuntu 18.04.5 LTS machine
with 32 GB of memory and an Intel(R) Core(TM) i5-13400 CPU (6 cores clocked at
4.4 GHz). To address RQ4, we evaluated the effectiveness of each tool in terms
of accuracy, performance, solidity version, and category coverage.

###  6.2. Experimental Results

####  6.2.1. Accuarcy

We first measure the accuracy of the selected tools in finding
vulnerabilities. There is currently no widely accepted standard or systematic
method to evaluate the accuracy of analysis tools for smart contracts in
finding security vulnerabilities. We test the selected tools on our benchmark,
and the results are summarized in Table 1. This table presents an overview of
the strengths and weaknesses of the selected tools across the Top 10
categories in Section 3. Each tool is represented as a column, while the
different vulnerability categories are listed as rows. The numbers in each
cell show the number of true positives identified by each tool for each
vulnerability category. The format used to report the results is “x/y”, where
x is the number of vulnerabilities correctly detected and y is the total
number of cases tested for that category. It is notable that none of the
tested tools was able to identify all categories of vulnerabilities. Mythril
and ConFuzzius outperformed the other tools by detecting 8 categories of
vulnerabilities among all the tools.

Table 1 shows that different tools perform better at identifying certain
vulnerability categories than others. For example, Conkas and Slither perform
well in detecting reentrancy vulnerabilities, while Smartcheck excels at
identifying time manipulation issues. The table provides valuable information
for developers and security analysts in selecting the most effective tools for
detecting specific types of vulnerabilities in smart contracts.

The last row of Table 1 shows the total number of true positives detected by
each tool out of a total of 100 test cases. This data gives an insight into
the accuracy of each tool’s performance in identifying Top 10 categories.
Mythril has the highest total number of 54 true positives, while Conkas has a
high number of 44 true positives and ConFuzzius has 42 true positives. The
interesting thing is that all the top 3 tools combine different analysis
methods. For example, Mythril uses symbolic execution, SMT calculation, and
taint analysis. The combination of different analysis methods can lead to a
more effective analysis, as it can leverage the strengths of each method to
overcome their respective weaknesses.

Table 1. True-positives identified per category by each tool Category |  ConFuzzius |  Conkas |  Maian |  Manticore |  Mythril |  Osiris |  Oyente |  Securify |  sFuzz |  Slither |  Smartcheck |  solhint
---|---|---|---|---|---|---|---|---|---|---|---|---
Reentrancy |  9/10 |  10/10 |  0/10 |  8/10 |  9/10 |  7/10 |  7/10 |  8/10 |  6/10 |  9/10 |  8/10 |  0/10
Arithmetic |  7/10 |  9/10 |  0/10 |  7/10 |  7/10 |  9/10 |  9/10 |  0/10 |  6/10 |  0/10 |  1/10 |  0/10
GaslessSend |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  3/10 |  0/10 |  7/10 |  0/10
UnsafeSuicidal |  4/10 |  0/10 |  4/10 |  0/10 |  3/10 |  0/10 |  0/10 |  0/10 |  0/10 |  6/10 |  0/10 |  4/10
UnsafeDelegatecall |  1/10 |  0/10 |  0/10 |  4/10 |  6/10 |  0/10 |  0/10 |  0/10 |  5/10 |  7/10 |  0/10 |  0/10
UncheckedSend |  9/10 |  10/10 |  0/10 |  2/10 |  9/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  8/10 |  6/10
TOD |  2/10 |  7/10 |  0/10 |  0/10 |  0/10 |  0/10 |  2/10 |  2/10 |  0/10 |  0/10 |  9/10 |  0/10
TimeManipulation |  8/10 |  8/10 |  0/10 |  7/10 |  6/10 |  2/10 |  0/10 |  0/10 |  1/10 |  8/10 |  0/10 |  10/10
tx.origin |  0/10 |  0/10 |  0/10 |  3/10 |  6/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  9/10
BadRandomness |  2/10 |  0/10 |  0/10 |  0/10 |  8/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  0/10 |  5/10
Total |  42/100 |  44/100 |  4/100 |  31/100 |  54/100 |  18/100 |  18/100 |  10/100 |  21/100 |  30/100 |  33/100 |  34/100

Table 2 displays the accuracy of each tool by calculating the number of true
positives and false negatives in each vulnerability category. The first row
lists the selected tools, and each subsequent row shows the true positives and
false negatives for each tool in that category. We obtained the false
negatives from 10 correct test cases. The last row presents the accuracy of
each tool, which is calculated as the ratio of the total number of true
positives to the sum of true positives and false positives. For example,
ConFuzzius has 42 true positives out of 100 test cases, and it also has 7
false negatives out of 10 test cases. Therefore, its accuracy is calculated as
(42+7)/(100+10)=45%. It is evident from the table that Mythril outperforms the
other tools in terms of correctly identifying vulnerabilities in the tested
smart contracts with an accuracy of 58%.

Table 2. Accuarcy of each tool |  ConFuzzius |  Conkas |  Maian |  Manticore |  Mythril |  Osiris |  Oyente |  Securify |  sFuzz |  Slither |  Smartcheck |  solhint
---|---|---|---|---|---|---|---|---|---|---|---|---
True-positives |  42/100 |  44/100 |  4/100 |  31/100 |  54/100 |  18/100 |  18/100 |  10/100 |  21/100 |  30/100 |  33/100 |  34/100
False-negatives |  7/10 |  6/10 |  10/10 |  10/10 |  10/10 |  8/10 |  8/10 |  10/10 |  9/10 |  10/10 |  10/10 |  10/10
Accuarcy |  45% |  46% |  13% |  37% |  58% |  24% |  24% |  18% |  27% |  36% |  39% |  40%

####  6.2.2. Performance

Execution time is another crucial factor to consider when evaluating the
effectiveness of a tool because the longer it takes for a tool to run, the
less efficient it is in terms of time. To assess performance, we calculated
the execution time for each tool, including the average time and total time,
as indicated in Table 3. The total time represents the cumulative execution
time for all the test processes, while the average time is obtained by
dividing the total time by the number of successful test cases. It is
important to note that unsuccessful test cases have been excluded from the
calculation of the average time. Slither and solhint demonstrate the shortest
average execution time, completing a test case in just 1 second, while
ConFuzzius and sFuzz exhibit the longest average execution time, requiring
approximately 18 minutes per test case. The total time taken by each tool also
varies significantly, with ConFuzzius consuming the longest duration of over
26 hours, while Slither proves to be the most time-efficient, requiring only 2
minutes. It is worth mentioning that the longer average execution times of
ConFuzzius and sFuzz could be attributed to their utilization of fuzzing
methods, which inherently entail lengthier execution times. In summary, Table
3 offers valuable insights into the performance of different analysis tools,
aiding software developers in selecting the most suitable tool for their
testing requirements.

Table 3. Execution time for each tool |  ConFuzzius |  Conkas |  Maian |  Manticore |  Mythril |  Osiris |  Oyente |  Securify |  sFuzz |  Slither |  Smartcheck |  solhint
---|---|---|---|---|---|---|---|---|---|---|---|---
Average Time |  0:18:9 |  0:0:48 |  0:0:57 |  0:11:2 |  0:4:17 |  0:1:32 |  0:0:4 |  0:0:27 |  0:18:0 |  0:0:1 |  0:0:3 |  0:0:1
Total Time |  26:01:4 |  1:13:38 |  1:35:50 |  9:33:40 |  6:29:40 |  1:47:31 |  0:5:38 |  0:45:55 |  18:0:19 |  0:2:15 |  0:4:42 |  0:2:40

####  6.2.3. Effectiveness

During our experiments, we discovered that aside from accuracy and execution
time, there are two additional crucial factors to consider when assessing the
overall quality of analysis tools. These factors are version compatibility and
category coverage. Version compatibility refers to the ability of a tool to
support different versions of the programming language or framework used in
smart contracts. It is essential because smart contract development frameworks
often undergo updates and introduce new features or changes. An effective
analysis tool should be compatible with a wide range of versions to ensure its
usefulness and relevance in different development environments. Category
coverage refers to the extent to which an analysis tool can detect
vulnerabilities across various categories or types. Smart contract
vulnerabilities can vary in nature, and different tools may have varying
levels of effectiveness in detecting them. A comprehensive analysis tool
should have a broad category coverage, capable of identifying vulnerabilities
across multiple categories, ensuring a more thorough and comprehensive
evaluation of smart contracts. By considering these factors alongside accuracy
and execution time, we can obtain a more comprehensive assessment of the
overall quality and effectiveness of analysis tools for smart contracts.

  * •

Version compatibility: The Solidity language is constantly evolving, and new
versions may introduce new features, syntax, or changes that may affect the
behavior of smart contracts. Tools that cannot analyze contracts written in
newer versions of Solidity may be limited in their ability to detect
vulnerabilities or may produce inaccurate results, which could lead to false
positives. Until January 2023, the latest version of Solidity was 0.8.19. We
have assigned a rating value to different Solidity versions based on their
compatibility with the tool. The score starts from 1 for version 0.4.x and
increases to 5 for version 0.8.x. We use $S_{v}$ to represent this score.

  * •

Category coverage: The category coverage of each tool is also important in
evaluating their effectiveness. This allows the developers to determine if a
tool is suitable for detecting specific categories of vulnerabilities in smart
contracts. A tool that has a wide category coverage and can detect multiple
categories of vulnerabilities may be more effective than a tool that can only
detect a limited number of vulnerabilities. We assign a score to each tool
based on the categories of vulnerabilities it can detect. For example, if a
tool can detect 5 categories of vulnerabilities, you can assign it a score of
5 points. We use $S_{c}$ to represent this score.

Based on the scoring criteria mentioned above, we have determined the score
values of $S_{v}$ (version compatibility) and $S_{c}$ (category coverage) as
presented in Table 4. The highest compatibility version for each tool is
indicated in the second row, which was used to calculate the rating value for
each tool.

Table 4. The scores of compatibility version ($S_{v}$) and category coverage ($S_{c}$) for each tool |  ConFuzzius |  Conkas |  Maian |  Manticore |  Mythril |  Osiris |  Oyente |  Securify |  sFuzz |  Slither |  Smartcheck |  solhint
---|---|---|---|---|---|---|---|---|---|---|---|---
Comp.version |  0.8.x |  0.5.x |  0.8.x |  0.8.x |  0.8.x |  0.4.21 |  0.4.19 |  0.5.11 |  0.4.24 |  0.6.x |  0.8.x |  0.8.x
$S_{v}$ |  5 |  2 |  5 |  5 |  5 |  1 |  1 |  2 |  1 |  3 |  5 |  5
$S_{c}$ |  8 |  5 |  1 |  6 |  7 |  3 |  3 |  2 |  5 |  4 |  5 |  5

It is crucial to obtain a balance between accuracy, average execution time,
compatibility version, and category coverage when evaluating the effectiveness
of a tool. One common approach to achieving this balance is by using a
weighted sum method, where the four factors are assigned different weights
based on their relative importance. In this approach, we assign a weight of
$\alpha$ to accuracy, $\beta$ to average execution time, $\gamma$ to
compatibility version, and $(1-\alpha-\beta-\gamma)$ to category coverage. We
then calculate the overall score ($Score$) using the following formula:

$\displaystyle Score=\alpha\times A*100+\beta\times(1/AEX)*100+\gamma\times
S_{v}+(1-\alpha-\beta-\gamma)\times S_{c}$

where $A$ is the accuracy value and $AEX$ is the average execution time.

The scores for each tool can be found in Table 5. The table consists of three
sets of scores, each with different weightings for the four measuring
attributes: accuracy, execution time, version compatibility, and category
coverage. The highest-scoring tool in each row is highlighted in bold. In the
first row, where the weightings for $A$ (accuracy) and $AEX$ (execution time)
are higher, Slither and solhint receive the highest scores. Similarly, in the
second and third rows, where the weightings for $S_{v}$ (version
compatibility) and $S_{c}$ (category coverage) are higher, respectively,
Slither and solhint still achieve the highest scores. It is important to note
that each tool has its own strengths and weaknesses, and the choice of tool
should depend on the specific needs and goals of the user. For example,
Slither excels in semantic-level analysis, while solhint is better suited for
canonical code. This explains why solhint performs well in detecting
vulnerabilities related to low-level opcodes such as call and tx.origin, but
may not be able to detect vulnerabilities like reentrancy and unsafe
delegatecall as shown in Table 1. Maian, on the other hand, differs from other
tools as it focuses on vulnerabilities involving a long sequence of
invocations of a contract.

Table 5. The overall scores for each tool $\alpha$ |  $\beta$ |  $\gamma$ |  ConFuzzius |  Conkas |  Maian |  Manticore |  Mythril |  Osiris |  Oyente |  Securify |  sFuzz |  Slither |  Smartcheck |  solhint
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---
0.4 |  0.4 |  0.1 |  19.3 |  19.9 |  6.5 |  16.0 |  24.7 |  10.4 |  18.0 |  9.1 |  11.4 |  55.1 |  29.9 |  57.0
0.25 |  0.25 |  0.25 |  14.5 |  13.7 |  5.2 |  12.0 |  17.8 |  7.3 |  12.0 |  6.4 |  8.3 |  35.8 |  20.6 |  37.5
0.1 |  0.1 |  0.4 |  9.7 |  7.6 |  3.9 |  8.1 |  11.0 |  4.1 |  6.0 |  3.8 |  5.1 |  16.4 |  11.2 |  18.0

Overall, the scores presented in Table 5 offer valuable insights into the
performance of each tool when different weighting schemes are applied. By
adjusting the weights assigned to the measuring factors, users can customize
the evaluation criteria based on their specific requirements and priorities.
This flexibility allows users to emphasize the aspects that are most critical
to the evaluation process. By doing so, they can make more targeted decisions
when selecting a tool. These findings provide a clear response to the fourth
research question, RQ4, as outlined in Section 2.2. The evaluation of the
selected analysis tools based on various factors such as accuracy, execution
time, version compatibility, and category coverage has shed light on their
overall effectiveness. By considering these factors, developers and
researchers can make informed decisions about the most suitable tools for
their smart contract analysis needs.

In addition, it is worth mentioning that using a combination of analysis tools
could be an effective approach to improve the overall quality of code and
detect potential vulnerabilities. For instance, solhint can be used to perform
grammatical checks and ensure code adherence to standards, while Mythril can
identify known vulnerabilities and help prevent attacks. Slither, on the other
hand, can provide a deeper analysis of the code and detect some semantic-level
issues. By using these tools in combination, developers can ensure that their
code is well-written, adheres to standards, and is free from vulnerabilities
to the extent possible.

Finally, in order to address the fifth research question, RQ5, as outlined in
Section 2.2, we have employed established criteria for selecting the different
analysis tools and developed an annotated dataset comprising 110 smart
contracts. The dataset is divided into 11 sub-datasets, with 10 sub-datasets
containing the faulty contracts with the top 10 known vulnerabilities
discussed in Section 3, and one sub-dataset consisting of correct contracts.
This dataset serves as a valuable resource for researchers and practitioners
to conduct comprehensive evaluations of the capabilities and limitations of
various tools. It enables them to make fair judgments when selecting the most
appropriate tools for their specific requirements. By providing a standardized
and annotated set of smart contracts, the dataset facilitates objective
comparisons and assessments, promoting transparency and reliability in smart
contract tool evaluation.

###  6.3. Threat to validity

Threats to validity are factors that have the potential to impact the results
of an experiment and the validity of its findings. In our research, we have
identified two specific aspects that could pose threats to the validity of our
study: the categorization of smart contract vulnerabilities and the generality
of the evaluation datasets.

One potential threat to the validity of our evaluation is the subjectivity and
variation among researchers in evaluating and categorizing vulnerabilities and
their associated smart contracts. Different researchers may have diverse
perspectives, criteria, and interpretations when assessing the severity and
classification of vulnerabilities. This subjectivity can introduce bias and
affect the validity of the comparisons presented in the evaluation. To
mitigate this threat, we have adopted a systematic approach based on industry
standards and best practices in Section 3. We have thoroughly reviewed and
discussed each vulnerability category to ensure a consistent and objective
classification. This involved extensive research, consultation with experts,
and careful consideration of existing literature. We have also provided clear
definitions, criteria, and explanations for each vulnerability category
considered in our analysis. By providing this transparency and documentation
of our evaluation process, we aim to minimize ambiguity and facilitate a more
consistent understanding of the vulnerabilities across different researchers
and readers.

The generality of the evaluation datasets represents another potential threat
to the validity of our research. This threat refers to the extent to which the
datasets used for evaluation accurately reflect real-world scenarios and the
usage patterns of smart contracts. If the evaluation datasets are limited in
scope or fail to encompass the diversity of smart contract applications, the
findings and conclusions may lack generalizability. To mitigate this threat,
we have made significant efforts to address dataset limitations. We have
conducted an extensive collection of contract tests from various sources,
including publicly available datasets and our own developed test cases. Our
dataset consists of 110 contract test cases, which have been carefully
selected to cover a wide range of applications and different code sizes. By
incorporating diverse contract test cases, we aim to provide a more
representative evaluation of smart contract vulnerabilities and increase the
generalizability of our findings.

While we have taken measures to address these threats, it is important to
acknowledge that limitations may still exist. To further enhance the validity
of future studies, researchers can focus on refining vulnerability
categorization criteria and collecting larger, more diverse datasets that
better capture real-world scenarios.

##  7\. Conclusions

The adoption of smart contract technology is rapidly increasing, leading to
significant research efforts focused on enhancing smart contract security. In
this survey, we have conducted a comprehensive study on smart contract
security, encompassing vulnerabilities, attacks, defenses, and tool support.
Our analysis has contributed to novel classifications of common vulnerability
types and attack patterns, with a specific focus on the connection between
them. Additionally, we have investigated defense methodologies aimed at
mitigating the risks associated with these vulnerabilities. Moreover, we have
conducted experiments using 12 open-source vulnerability-detecting tools and
applied weighting-based assessment criteria to evaluate their accuracy,
performance, and overall effectiveness. This evaluation provides valuable
insights into the capabilities and limitations of the representative tools in
the field, helping researchers and practitioners in selecting the most
suitable options. Additionally, we have created an annotated dataset
comprising 110 smart contracts, serving as a standardized benchmark for
conducting thorough evaluations of smart contract analysis tools. This dataset
facilitates comparative studies and enables researchers to assess the
performance of different tools in detecting vulnerabilities and improving
overall security. These findings emphasize the critical importance of
continuous research and development in the field of smart contract security.

However, the smart contract landscape is evolving rapidly, with new
functionalities and protocols leading to the emergence of new security
vulnerabilities. To make smart contract languages more robust, it is crucial
to continue investing in research and development. For instance, there has
been a growing interest in using programming languages other than Solidity for
smart contract development. Languages like Go and Rust have gained attention
due to their stronger syntax and logical soundness, offering potential
solutions to address some of the security issues associated with Solidity.
Furthermore, there is a need for more powerful analysis tools capable of
identifying dynamic or logic errors within smart contracts. Existing tools
primarily focus on known vulnerabilities and attacks, while effective
methodologies for dealing with unknown attacks are still limited. Thus,
protecting smart contracts from unknown attacks poses a significant challenge
for future research. Additionally, developing automated approaches for
repairing vulnerable smart contracts after deployment could prove to be a
fruitful direction. In conclusion, the security of smart contracts remains an
ongoing concern that demands continuous attention and innovation to address
evolving threats.

###### Acknowledgements.

This work is supported by National Key Research and Development Program of
China under the grant No.2021YFB2701202, and National Natural Science
Foundation of China (NSFC) under the grant No.62172040, and Anhui Provincial
Natural Science Foundation under the grant No.2008085MF196.

## References

  * (1)
  * ivy (2017) 2017\.  _ivy lang.org_.  https://docs.ivylang.org/bitcoin/
  * BEC (2018) 2018\.  _A disastrous vulnerability found in smart contracts of BeautyChain (BEC)_.  https://medium.com/secbit-media/a-disastrous-vulnerability-found-in-smart-contracts-of-beautychain-bec-dbf24ddbc30e
  * eth (2018a) 2018a.  _Ethereum Daily Transactions Chart_.  https://etherscan.io/chart/tx
  * eth (2018b) 2018b.  _Etherscan_.  https://etherscan.io/
  * Saf (2018) 2018\.  _OpenZeppelin SafeMath_.  https://docs.openzeppelin.com/contracts/2.x/api/math
  * pec (2018) 2018\.  _PeckShield com_.  https://peckshield.com/
  * EOS (2022) 2022\.  _EOSIO network monitor_.  https://eosnetworkmonitor.io/
  * The (2022) 2022\.  _What was The DAO?_ https://www.gemini.com/cryptopedia/the-dao-hack-makerdao
  * Abdellatif and Brousmiche (2018) Tesnim Abdellatif and Kei-Léo Brousmiche. 2018.  Formal Verification of Smart Contracts Based on Users and Blockchain Behaviors Models. In _9th IFIP International Conference on New Technologies, Mobility and Security, NTMS 2018, Paris, France, February 26-28, 2018_. IEEE, 1–5.
  * Ahrendt et al. (2019) Wolfgang Ahrendt, Richard Bubel, Joshua Ellul, Gordon J. Pace, Raúl Pardo, Vincent Rebiscoul, and Gerardo Schneider. 2019.  Verification of Smart Contract Business Logic - Exploiting a Java Source Code Verifier. In _Fundamentals of Software Engineering - 8th International Conference, FSEN 2019, Tehran, Iran, May 1-3, 2019, Revised Selected Papers_ _(Lecture Notes in Computer Science, Vol. 11761)_. Springer, 228–243.
  * Albert et al. (2014) Elvira Albert, Puri Arenas, Antonio Flores-Montoya, Samir Genaim, Miguel Gómez-Zamalloa, Enrique Martin-Martin, German Puebla, and Guillermo Román-Díez. 2014.  SACO: Static Analyzer for Concurrent Objects. In _Tools and Algorithms for the Construction and Analysis of Systems - 20th International Conference, TACAS 2014, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2014, Grenoble, France, April 5-13, 2014. Proceedings_ _(Lecture Notes in Computer Science, Vol. 8413)_. Springer, 562–567.
  * Albert et al. (2008) Elvira Albert, Puri Arenas, Samir Genaim, and Germán Puebla. 2008.  Automatic Inference of Upper Bounds for Recurrence Relations in Cost Analysis. In _Static Analysis, 15th International Symposium, SAS 2008, Valencia, Spain, July 16-18, 2008. Proceedings_ _(Lecture Notes in Computer Science, Vol. 5079)_. Springer, 221–237.
  * Albert et al. (2020) Elvira Albert, Jesús Correas, Pablo Gordillo, Guillermo Román-Díez, and Albert Rubio. 2020.  GASOL: Gas Analysis and Optimization for Ethereum Smart Contracts. In _Tools and Algorithms for the Construction and Analysis of Systems - 26th International Conference, TACAS 2020, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2020, Dublin, Ireland, April 25-30, 2020, Proceedings, Part II_ _(Lecture Notes in Computer Science, Vol. 12079)_. Springer, 118–125.
  * Albert et al. (2018) Elvira Albert, Pablo Gordillo, Benjamin Livshits, Albert Rubio, and Ilya Sergey. 2018.  EthIR: A Framework for High-Level Analysis of Ethereum Bytecode. In _Automated Technology for Verification and Analysis - 16th International Symposium, ATVA 2018, Los Angeles, CA, USA, October 7-10, 2018, Proceedings_ _(Lecture Notes in Computer Science, Vol. 11138)_. Springer, 513–520.
  * Albert et al. (2019) Elvira Albert, Pablo Gordillo, Albert Rubio, and Ilya Sergey. 2019.  Running on Fumes - Preventing Out-of-Gas Vulnerabilities in Ethereum Smart Contracts Using Static Resource Analysis. In _Verification and Evaluation of Computer and Communication Systems - 13th International Conference, VECoS 2019, Porto, Portugal, October 9, 2019, Proceedings_ _(Lecture Notes in Computer Science, Vol. 11847)_. Springer, 63–78.
  * Androulaki et al. (2018) Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco, and Jason Yellick. 2018.  Hyperledger fabric: a distributed operating system for permissioned blockchains. In _Proceedings of the Thirteenth EuroSys Conference, EuroSys 2018, Porto, Portugal, April 23-26, 2018_. ACM, 30:1–30:15.
  * Angelo and Salzer (2019) Monika Di Angelo and Gernot Salzer. 2019.  A Survey of Tools for Analyzing Ethereum Smart Contracts. In _IEEE International Conference on Decentralized Applications and Infrastructures, DAPPCON 2019, Newark, CA, USA, April 4-9, 2019_. IEEE, 69–78.  https://doi.org/10.1109/DAPPCON.2019.00018
  * Ashraf et al. (2020) Imran Ashraf, Xiaoxue Ma, Bo Jiang, and Wing Kwong Chan. 2020.  GasFuzzer: Fuzzing ethereum smart contract binaries to expose gas-oriented exception security vulnerabilities.  _IEEE Access_ 8 (2020), 99552–99564.
  * Atzei et al. (2016) Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2016.  A survey of attacks on Ethereum smart contracts.  _IACR Cryptol. ePrint Arch._ (2016), 1007.
  * Atzei et al. (2017) Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017.  A Survey of Attacks on Ethereum Smart Contracts (SoK). In _Principles of Security and Trust - 6th International Conference, POST 2017, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2017, Uppsala, Sweden, April 22-29, 2017, Proceedings_ _(Lecture Notes in Computer Science, Vol. 10204)_. Springer, 164–186.
  * Atzei et al. (2018a) Nicola Atzei, Massimo Bartoletti, Tiziana Cimoli, Stefano Lande, and Roberto Zunino. 2018a.  SoK: Unraveling Bitcoin Smart Contracts. In _Principles of Security and Trust - 7th International Conference, POST 2018, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2018, Thessaloniki, Greece, April 14-20, 2018, Proceedings_ _(Lecture Notes in Computer Science, Vol. 10804)_. Springer, 217–242.
  * Atzei et al. (2019) Nicola Atzei, Massimo Bartoletti, Stefano Lande, Nobuko Yoshida, and Roberto Zunino. 2019.  Developing secure bitcoin contracts with BitML. In _Proceedings of the ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/SIGSOFT FSE 2019, Tallinn, Estonia, August 26-30, 2019_. ACM, 1124–1128.
  * Atzei et al. (2018b) Nicola Atzei, Massimo Bartoletti, Stefano Lande, and Roberto Zunino. 2018b.  A Formal Model of Bitcoin Transactions. In _Financial Cryptography and Data Security - 22nd International Conference, FC 2018, Nieuwpoort, Curaçao, February 26 - March 2, 2018, Revised Selected Papers_ _(Lecture Notes in Computer Science, Vol. 10957)_. Springer, 541–560.
  * Augur (2018) Augur. 2018.  _Deployment Details & REP Migration_.  https://medium.com/@AugurProject/deployment-details-rep-migration-e5413ff9fb65
  * Bai et al. (2018) Xiaomin Bai, Zijing Cheng, Zhangbo Duan, and Kai Hu. 2018.  Formal Modeling and Verification of Smart Contracts. In _Proceedings of the 7th International Conference on Software and Computer Applications, ICSCA 2018, Kuantan, Malaysia, February 08-10, 2018_. ACM, 322–326.
  * Bartoletti and Zunino (2019) Massimo Bartoletti and Roberto Zunino. 2019.  Formal Models of Bitcoin Contracts: A Survey.  _Frontiers Blockchain_ 2 (2019), 8.
  * Bernardo et al. (2020) Bruno Bernardo, Raphaël Cauderlier, Guillaume Claret, Arvid Jakobsson, Basile Pesin, and Julien Tesson. 2020.  Making Tezos Smart Contracts More Reliable with Coq. In _Leveraging Applications of Formal Methods, Verification and Validation: Applications - 9th International Symposium on Leveraging Applications of Formal Methods, ISoLA 2020, Rhodes, Greece, October 20-30, 2020, Proceedings, Part III_ _(Lecture Notes in Computer Science, Vol. 12478)_. Springer, 60–72.
  * Brent et al. (2018) Lexi Brent, Anton Jurisevic, Michael Kong, Eric Liu, François Gauthier, Vincent Gramoli, Ralph Holz, and Bernhard Scholz. 2018.  Vandal: A Scalable Security Analysis Framework for Smart Contracts.  _CoRR_ abs/1809.03981 (2018).  arXiv:1809.03981 http://arxiv.org/abs/1809.03981
  * Casino et al. (2019) Fran Casino, Thomas K Dasaklis, and Constantinos Patsakis. 2019.  A systematic literature review of blockchain-based applications: Current status, classification and open issues.  _Telematics and informatics_ 36 (2019), 55–81.
  * Chakraborty et al. (2022) Saikat Chakraborty, Rahul Krishna, Yangruibo Ding, and Baishakhi Ray. 2022.  Deep Learning Based Vulnerability Detection: Are We There Yet?  _IEEE Trans. Software Eng._ 48, 9 (2022), 3280–3296.
  * Chen et al. (2021b) Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu. 2021b.  A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses.  _ACM Comput. Surv._ 53, 3 (2021), 67:1–67:43.
  * Chen et al. (2020) Ting Chen, Rong Cao, Ting Li, Xiapu Luo, Guofei Gu, Yufei Zhang, Zhou Liao, Hang Zhu, Gang Chen, Zheyuan He, Yuxing Tang, Xiaodong Lin, and Xiaosong Zhang. 2020.  SODA: A Generic Online Detection Framework for Smart Contracts. In _27th Annual Network and Distributed System Security Symposium, NDSS 2020, San Diego, California, USA, February 23-26, 2020_. The Internet Society.
  * Chen et al. (2021a) Ting Chen, Youzheng Feng, Zihao Li, Hao Zhou, Xiapu Luo, Xiaoqi Li, Xiuzhuo Xiao, Jiachi Chen, and Xiaosong Zhang. 2021a.  GasChecker: Scalable Analysis for Discovering Gas-Inefficient Smart Contracts.  _IEEE Trans. Emerg. Top. Comput._ 9, 3 (2021), 1433–1448.
  * Chen et al. (2017) Ting Chen, Xiaoqi Li, Ying Wang, Jiachi Chen, Zihao Li, Xiapu Luo, Man Ho Au, and Xiaosong Zhang. 2017.  An Adaptive Gas Cost Mechanism for Ethereum to Defend Against Under-Priced DoS Attacks. In _Information Security Practice and Experience - 13th International Conference, ISPEC 2017, Melbourne, VIC, Australia, December 13-15, 2017, Proceedings_ _(Lecture Notes in Computer Science, Vol. 10701)_. Springer, 3–24.
  * Cheng et al. (2019) Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah M. Johnson, Ari Juels, Andrew Miller, and Dawn Song. 2019.  Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contracts. In _IEEE European Symposium on Security and Privacy, EuroS &P 2019, Stockholm, Sweden, June 17-19, 2019_. IEEE, 185–200.
  * christoftorres (2018) christoftorres. 2018.  _Osiris_.  https://github.com/christoftorres/Osiris
  * christoftorres (2021) christoftorres. 2021.  _ConFuzzius_.  https://github.com/christoftorres/ConFuzzius
  * Crincoli et al. (2022) Giuseppe Crincoli, Giacomo Iadarola, Piera Elena La Rocca, Fabio Martinelli, Francesco Mercaldo, and Antonella Santone. 2022.  Vulnerable smart contract detection by means of model checking. In _Proceedings of the Fourth ACM International Symposium on Blockchain and Secure Critical Infrastructure_. 3–10.
  * crytic (2017) crytic. 2017.  _american fuzzy lop_.  https://lcamtuf.coredump.cx/afl/
  * crytic (2019a) crytic. 2019a.  _echidna_.  https://github.com/crytic/echidna
  * crytic (2019b) crytic. 2019b.  _slither_.  https://github.com/crytic/slither
  * Cui et al. (2022) Siwei Cui, Gang Zhao, Yifei Gao, Tien Tavu, and Jeff Huang. 2022.  VRust: Automated Vulnerability Detection for Solana Smart Contracts. In _Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, CCS 2022, Los Angeles, CA, USA, November 7-11, 2022_. ACM, 639–652.
  * Danielius et al. (2020) Paulius Danielius, Piotr Stolarski, and Saulius Masteika. 2020.  Vulnerabilities and excess gas consumption analysis within ethereum-based smart contracts for electricity market. In _Business Information Systems Workshops: BIS 2020 International Workshops, Colorado Springs, CO, USA, June 8–10, 2020, Revised Selected Papers 23_. Springer, 99–110.
  * development team (2019) MythX development team. 2019.  _Mythril_.  https://github.com/ConsenSys/mythril
  * Durieux et al. (2020) Thomas Durieux, João F. Ferreira, Rui Abreu, and Pedro Cruz. 2020.  Empirical review of automated analysis tools on 47, 587 Ethereum smart contracts. In _ICSE ’20: 42nd International Conference on Software Engineering, Seoul, South Korea, 27 June - 19 July, 2020_. ACM, 530–541.
  * Ehtereum (2023) Ehtereum. 2023.  _Ehtereum_.  https://ethereum.org/
  * Ellul and Pace (2018) Joshua Ellul and Gordon J Pace. 2018.  Runtime verification of ethereum smart contracts. In _2018 14th European Dependable Computing Conference (EDCC)_. IEEE, 158–163.
  * enzymefinance (2018) enzymefinance. 2018.  _oyente_.  https://github.com/enzymefinance/oyente
  * Eskandari et al. (2019) Shayan Eskandari, Seyedehmahsa Moosavi, and Jeremy Clark. 2019.  SoK: Transparent Dishonesty: Front-Running Attacks on Blockchain. In _Financial Cryptography and Data Security - FC 2019 International Workshops, VOTING and WTSC, St. Kitts, St. Kitts and Nevis, February 18-22, 2019, Revised Selected Papers_ _(Lecture Notes in Computer Science, Vol. 11599)_. Springer, 170–189.
  * eth sri (2018) eth sri. 2018.  _securify2_.  https://github.com/eth-sri/securify2
  * Falkon (2017) Samuel Falkon. 2017.  _The Story of the DAO — Its History and Consequences_.  https://medium.com/swlh/the-story-of-the-dao-its-history-and-consequences-71e6a8a551ee
  * Feist et al. (2019) Josselin Feist, Gustavo Grieco, and Alex Groce. 2019.  Slither: a static analysis framework for smart contracts. In _Proceedings of the 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain, WETSEB@ICSE 2019, Montreal, QC, Canada, May 27, 2019_. IEEE / ACM, 8–15.
  * flashbots (2023) flashbots. 2023.  _MVE-Explore v1_.  https://explore.flashbots.net/