# Membranes in Optic Nerve Models

Yi Zhu  Department of Mathematics and Statistics, York University, Toronto,
ON, M3J 1P3, Canada  Shixin Xu  Duke Kunshan University, Jiangsu, Kunshan,
215316, China.  Corresponding author<EMAIL_ADDRESS>Robert S.
Eisenberg  Department of Applied Mathematics, Illinois Institute of
Technology, Chicago IL 60616 USA  Department of Physiology $\&$ Biophysics,
Rush University Chicago IL 60612, USA  Huaxiong Huang  Research Centre for
Mathematics, Advanced Institute of Natural Sciences, Beijing Normal University
(Zhuhai), 519087, China  Division of Science and Technology, BNU- HKBU United
International College, Zhuhai, 519087, China  Department of Mathematics and
Statistics, York University, Toronto, ON, M3J 1P3, Canada  Department of
Mathematics and Statistics, York University, Toronto, ON, M3J 1P3, Canada

###### Abstract

Membranes are present in all cells and tissues. Mathematical models of cells
and tissues need a compact mathematical description of membranes with a
resolution of about 1 nm. Membranes isolate cells because ions have difficulty
penetrating the dielectric barrier they create. Here we introduce a dielectric
mathematical membrane condition to replace a condition that did not include
dielectric properties. Our mathematical membrane condition includes a
dielectric lipid bilayer punctured by channels that conduct ions selectively.

##  1 Introduction

Membranes isolate cells and organelles from the solutions around them.
Membranes are lipid bilayers that isolate regions because of their
polarization. The energy to move an ion from salt solution into the lipid of
the bilayer is very large. As it moves, an ion must be separated from its
ionic atmosphere (measured by the Debye length) and dielectric surround
(measured by the Bjerrum length) that balance its permanent charge. The
dielectric lipid has zero ionic atmosphere and little dielectric atmosphere to
balance its charge. The movement of the ion from solution into the lipid of
the membrane involves a huge energy barrier. The energy barrier isolates the
interior of cells and organelles from their surround. Membranes are punctured
by channels that provide pathways for ion flow with relatively small energy
barriers (when the channel is open). In recent papers on the optic nerve [1],
we followed Mori [2, 3] and described the membranes by a condition involving
just the channels and their conductance

$\boldsymbol{J_{k}^{i}}\cdot\boldsymbol{n}=\frac{g_{m}^{i}}{z^{i}e}(\phi_{in}-\phi_{ex}-E^{i}),$
(1)

where $i=\mathrm{Na}^{+},\mathrm{K}^{+},\mathrm{Cl}^{-}$,
$E^{i}=\frac{k_{B}T}{z^{i}e}log\left(\frac{c_{ex}^{i}}{c_{in}^{i}}\right)$ is
the Nernst potential.

Here we introduce a mathematical membrane condition involving membrane
dielectric properties (represented realistically as a capacitance) as well as
membrane conductance. We show that our previous results are not significantly
changed by introducing the new mathematical membrane condition. We choose the
resolution of the membrane condition so it describes membrane properties
important in Hodgkin Huxley computations of the action potential and
calculations of the associated ionic and water fluxes. Other effects, such as
the ionic atmosphere surrounding the membrane, or the permanent charge inside
the ion channel require higher resolution models. We will use the realistic
membrane condition (that includes capacitance) in future work lest readers and
students misunderstand the physical basis of the main function of membranes,
namely to provide a large dielectric energy barrier that isolates cells and
organelles from their surrounds.

##  2 Mathematical membrane condition

In this section, we discuss the effect of the new mathematical membrane
condition for both axon cell membrane and glial cell membrane.

The cell membrane can be viewed as a capacitor representing the lipid
dielectric and a set of conductances representing ion channels following ample
precedent. In the model, we introduce the
$J^{i}_{m,k},(k=gl,ax,i=\mathrm{Na}^{+},\mathrm{K}^{+},\mathrm{Cl}^{-})$ for
this ion flux and the transmembrane source term in the [1] can be written as

$J_{k}^{m,i}=J_{p,k}^{i}+J_{c,k}^{i}+J^{i}_{m,k},\quad k=gl,ax,\quad
i=\mathrm{Na}^{+},\mathrm{K}^{+},\mathrm{Cl}^{-}.$

where

$J^{i}_{m,k}=\lambda^{i}\frac{C_{m}}{z^{i}e}\frac{d(\phi_{k}-\phi_{ex})}{dt},$

and active ion pump source $J_{p,k}^{i}$ and passive ion channel source
$J_{c,k}^{i}$, on the $k$th membrane. The conservation of ion concentration
implies the following system of partial differential equations to describe the
dynamics of ions in each region, for $i=\mathrm{Na^{+},K^{+},Cl^{-}}$

$\displaystyle\frac{\partial\left(\eta_{gl}c_{gl}^{i}\right)}{\partial
t}+\mathcal{M}_{gl}J^{m,i}_{gl}+\nabla\cdot\left(\eta_{gl}\boldsymbol{j}_{gl}^{i}\right)=0,~{}~{}~{}$
$\displaystyle\text{ in }\Omega_{OP},$
$\displaystyle\frac{\partial\left(\eta_{ax}c_{ax}^{i}\right)}{\partial
t}+\mathcal{M}_{ax}J^{m,i}_{ax}+\frac{\partial}{\partial
z}\left(\eta_{ax}j_{ax,z}^{i}\right)=0,~{}~{}~{}~{}~{}$ $\displaystyle\text{
in }\Omega_{OP},$
$\displaystyle\frac{\partial\left(\eta_{ex}c_{ex}^{i}\right)}{\partial
t}-\mathcal{M}_{ax}J^{m,i}_{ax}-\mathcal{M}_{gl}J^{m,i}_{gl}+\nabla\cdot\left(\eta_{ex}\boldsymbol{j}_{ex}^{i}\right)=0,~{}~{}~{}~{}$
$\displaystyle\text{ in }\ \Omega_{OP},$

The electric potentials in the axon compartment, glial compartment and
extracellular space are

$\displaystyle\sum_{i}z^{i}e\mathcal{M}_{gl}J^{m,i}_{gl}+\sum_{i}z^{i}e\nabla\cdot\left(\eta_{g}\boldsymbol{j}_{gl}^{i}\right)$
$\displaystyle=0,$
$\displaystyle\sum_{i}z^{i}e\mathcal{M}_{ax}J^{m,i}_{ax}+\sum_{i}z^{i}e\frac{\partial}{\partial
z}\left(\eta_{ax}j_{ax,z}^{i}\right)$ $\displaystyle=0,$
$\displaystyle\sum_{i}z^{i}e\nabla\cdot\left(\eta_{gl}\boldsymbol{j}_{gl}^{i}\right)+\sum_{i}z^{i}e\frac{\partial}{\partial
z}\left(\eta_{ax}j_{ax,z}^{i}\right)+\sum_{i}z^{i}e\nabla\cdot\left(\eta_{ex}\boldsymbol{j}_{ex}^{i}\right)$
$\displaystyle=0,$

##  3 Simulation

Here we repeat the simulations of the optic nerve published previously but
with modified parameters. We choose the capacitance on both axon and glial
membrane as $C_{m}=7.5\times 10^{-3}\ \mathrm{F\cdot m^{-2}}$ [4] and
$\lambda^{i}=\frac{1}{3}$ for each ion specie. Furthermore, action potentials
are generated by the axon with the parameters in the following Table 1.

Parameters | Previous Value | New Value
---|---|---
$\mathcal{M}_{ax}$ | $5.98\times 10^{6}\mathrm{m}^{-1}$ | $2.392\times 10^{5}\mathrm{m}^{-1}$
$I_{ax,1}$ | $9.56\times 10^{-4}\mathrm{~{}A}/\mathrm{m}^{2}$ | $2.39\times 10^{-2}\mathrm{~{}A}/\mathrm{m}^{2}$
$I_{ax,2}$ | $1.3\times 10^{-4}\mathrm{~{}A}/\mathrm{m}^{2}$ | $3.25\times 10^{-3}\mathrm{~{}A}/\mathrm{m}^{2}$
$g_{leak}^{Na}$ | $4.8\times 10^{-3}\mathrm{~{}S}/\mathrm{m}^{2}$ | $1.2\times 10^{-1}\mathrm{~{}S}/\mathrm{m}^{2}$
$g_{leak}^{K}$ | $2.2\times 10^{-2}\mathrm{~{}S}/\mathrm{m}^{2}$ | $5.5\times 10^{-1}\mathrm{~{}S}/\mathrm{m}^{2}$
$\bar{g}^{Na}$ | $1.357\times 10^{1}\mathrm{~{}S}/\mathrm{m}^{2}$ | $3.393\times 10^{2}\mathrm{~{}S}/\mathrm{m}^{2}$
$\bar{g}^{K}$ | $2.945\mathrm{~{}S}/\mathrm{m}^{2}$ | $7.364\times 10^{1}\mathrm{~{}S}/\mathrm{m}^{2}$
$g_{ax}^{Cl}$ | $1.5\times 10^{-1}\mathrm{~{}S}/\mathrm{m}^{2}$ | $3.75\mathrm{~{}S}/\mathrm{m}^{2}$
$I_{shock}$ | $3\times 10^{-3}\mathrm{~{}A\cdot m^{-2}}$ | $7.5\times 10^{-2}\mathrm{~{}A\cdot m^{-2}}$
Table 1: Parameters Table

######  Remark 3.1.

The parameters are adjusted based on the following facts

  1. 1.

The size of necturus optic nerve is much smaller that squid;

  2. 2.

In [1], we estimated the membrane conductance based on the experimental
results [5] and the fact that the density of ion channel in Necturus ($24/\mu
m^{2}$) is lower that that of squid ($170-290/\mu m^{2}$). Without the
capacitance effect, the conductance of axon may be underestimated.

At the same time, in [5], the measured $\mathrm{K^{+}}$ variation is around
$0.2mM$ for single action potential. In order to match this, we keep the value
$\mathcal{M}_{ax}*\bar{g}_{k}$ to be same, while decrease the value of
$\mathcal{M}_{ax}$ and increase the value of conductance. The other parameters
are adjusted based the rest state ion concentrations.

Figure 1: Comparison between the model with and without cell membrane
capacitance effect.

Fig. 1 shows results from simulations using the parameters in Table 1. We
simulate Orkand’s experimental setup with the bath solution containing
$\mathrm{3mM~{}K}^{+}$. In Figure 1, we compare the glial membrane potential,
potassium concentration in the extracellular space and axon membrane
potential. The results do not differ significantly from those published using
Mori’s purely conductive model of the membrane.

## References

  * [1] Y. Zhu, S. Xu, R. S. Eisenberg, H. Huang, Optic nerve microcirculation:Fluid flow and electro-diffusion, arXiv preprint arXiv:2101.12152 (2021).
  * [2] Y. Mori, C. Liu, R. S. Eisenberg, A model of electrodiffusion and osmoticwater flow and its energetic structure, Physica D: Nonlinear Phenomena240 (22) (2011) 1835–1852.4
  * [3] Y. Mori, A multidomain model for ionic electrodiffusion and osmosis withan application to cortical spreading depression, Physica D: Nonlinear Phe-nomena 308 (2015) 94–108.
  * [4] G. Major, A. U. Larkman, P. Jonas, B. Sakmann, J. . Jack, Detailed passivecable models of whole-cell recorded ca3 pyramidal neurons in rat hippocam-pal slices, Journal of Neuroscience 14 (8) (1994) 4613–4638.
  * [5] R. Orkand, J. Nicholls, S. Kuffler, Effect of nerve impulses on the membranepotential of glial cells in the central nervous system of amphibia., Journal ofneurophysiology 29 (4) (1966)


# An Empirical Study of Impact of Solidity Compiler Updates on Vulnerabilities
in Ethereum Smart Contracts

Chihiro Kado<EMAIL_ADDRESS>0009-0006-4400-4638 ,  Naoto Yanai
<EMAIL_ADDRESS>0000-0002-0817-6188 ,  Jason Paul Cruz
<EMAIL_ADDRESS>0000-0002-9935-1534 ,  Kyosuke Yamashita
<EMAIL_ADDRESS>
Osaka University1-5 YamadaokaSuitaOsakaJapan565-0871 and  Shingo Okamura
<EMAIL_ADDRESS>National Institute of Technology, Nara College22
YatachoYamatokoriyamaNaraJapan639-1058

(2018; 20 February 2007; 12 March 2009; 5 June 2009)

###### Abstract.

Vulnerabilities of Ethereum smart contracts often cause serious financial
damage. Whereas the Solidity compiler has been updated to prevent
vulnerabilities, its effectiveness has not been revealed so far, to the best
of our knowledge. In this paper, we shed light on the impact of compiler
versions of vulnerabilities of Ethereum smart contracts. To this end, we
collected 503,572 contracts with Solidity source codes in the Ethereum
blockchain and then analyzed their vulnerabilities. For three vulnerabilities
with high severity, i.e., Locked Money, Using tx.origin, and Unchecked Call,
we show that their appearance rates are decreased by virtue of major updates
of the Solidity compiler. We then found the following four key insights.
First, after the release of version 0.6, the appearance rate for Locked Money
has decreased. Second, regardless of compiler updates, the appearance rate for
Using tx.origin is significantly low. Third, although the appearance rate for
Unchecked Call has decreased in version 0.8, it still remains high due to
various factors, including code clones. Fourth, through analysis of code
clones, our promising results show that the appearance rate for Unchecked Call
can be further decreased by removing the code clones.

Ethereum smart contracts, vulnerabilities, empirical study, Solidity compiler

††copyright: acmcopyright††journalyear: 2018††doi: XXXXXXX.XXXXXXX††journal:
JACM††journalvolume: 37††journalnumber: 4††article: 111††publicationmonth:
8††ccs: Security and privacy Software and application security††ccs: Software
and its engineering Empirical software validation

##  1\. Introduction

Smart contracts that provide a platform for decentralized applications have
attracted attention as applications of blockchains in recent years. Loosely
speaking, smart contracts enable automated transactions by storing program
code on blockchains, along with information about cryptocurrency transactions.
Ethereum (theyellowpaper, 33) is the most popular platform of smart contracts.
(Hereafter, we refer to Ethereum smart contracts simply as “smart contracts.”)

Smart contracts often contain security issues due to the properties of
blockchains (zou2019smart, 35). Program code of smart contracts is stored on
the blockchain, and hence it can be analyzed by an adversary due to its
transparency, allowing anyone to check the information on the blockchain.
Furthermore, the semantics of Solidity, a high-level language for developing
smart contracts, is neither formally nor completely specified
(hwang2020gapbetweentheoryandpractice, 11). As a result, many security
incidents have been reported involving smart contracts so
far111https://rekt.news. For example, $150 million was stolen through the
parity-wallets vulnerabilities222https://techcrunch.com/2017/11/07/a-major-
vulnerability-has-frozen- hundred-of-millions-of-dollars-of-ethereum/. In an
effort to address the security issues, researchers have developed
vulnerability analysis tools (luu2016making, 16, 27, 9, 6, 10, 24, 32, 3, 13,
28, 17). Concurrently, the Solidity compiler has been updated to prevent
vulnerable code as another important effort (crafa2019solidity0.5, 7, 26, 11,
1).

Although the vulnerability analysis tools have been evaluated in various ways
(chen2020survey, 4, 15, 8, 18, 2, 14), it is unknown whether the updates of
the Solidity compiler have improved the security of smart contracts, to the
best of our knowledge. Solidity is a relatively new language that was
introduced in 2015, which could potentially contain vulnerabilities
(wang2022realbugfixes, 30), regardless of the vulnerability analysis tools
mentioned above. Despite the fact that compiler updates are essential
countermeasures against vulnerabilities, the impact of Solidity compiler
updates remains unclear. Therefore, to guide research and development in
designing practical analysis tools for smart contracts, it is essential to
investigate the current status of vulnerabilities in smart contracts from the
standpoints of compiler versions.

In this paper, we answer the following question: How do Solidity compiler
updates affect each vulnerability? To this end, we first conduct an empirical
study for compiler versions. Specifically, we examine how many vulnerable
contracts are deployed in the real world. We note the above question is non-
trivial. According to the existing empirical study
(wan2021securityperspective, 29), developers may prefer to use an older
version of the compiler, which is more stable, than the latest version since
it is often unstable (tantikul2020exploring, 26, 7). It may indicate that
there are more vulnerable contracts than the theoretical estimation
(alt2022solcmc, 1) for the compiler updates of Solidity. Although there are
several empirical studies (durieux2020empirical47587, 8, 19) that investigate
vulnerable contracts, these studies do not discuss the impact of compiler
versions on vulnerabilities. Thus, the existing studies above do NOT imply any
insight into the impact of compiler versions on vulnerabilities, which is our
key question.

To answer the above question, we collect 503,572 contracts deployed by
2022/8/31 and then analyze these contracts with respect to vulnerabilities
with high severity (tikhomirov2018smartcheck, 27), i.e., Locked Money, Using
tx.origin, and Unchecked Call333We refer to GitHub for the latest version of
severity.
https://github.com/smartdec/smartcheck/tree/master/rule_descriptions. More
specifically, the collected contracts are classified by compiler versions, and
then vulnerabilities of these contracts are evaluated by existing
vulnerability analysis tool (tikhomirov2018smartcheck, 27). We then show that
major updates of the Solidity compiler are effective for the decrease in
vulnerabilities as our main findings. We also found the following four
insights:

  1. (1)

Locked money is significantly decreased after version 0.6 or later versions.

  2. (2)

Using tx.origin is initially limited; hence, its impact is regarded as minimal
independently of the compiler update.

  3. (3)

Unchecked Call is decreased in version 0.8. However, it is slightly high even
in the latest compiler versions due to false positives and the cloning of
vulnerable code.

  4. (4)

When we analyze code clones that are the reuses of existing contracts, we
found that the appearance rate for Unchecked Call can be further decreased by
removing code clones.

This paper is the full version of our previous work (kado2023empirical, 12)
which will be presented at BRAIN 2023. In the previous work, we conducted
empirical analysis and then showed that the appearance rates of
vulnerabilities were decreased by major updates. In this paper, we focus on
the existence of code clones, that are reuse of existing contracts with minor
changes, and then evaluate newly appeared vulnerabilities precisely by
removing the code clones. We also consider the use of older compiler versions.
They were future works mentioned in the previous work. We currently show that
the appearance rates will be more reduced than the results in the previous
work.

##### Paper Organization

The rest of this paper is organized as follows. Section 2 describes Ethereum
smart contracts and related works. Section 3 presents our methodology for the
empirical study, including the underlying tool, vulnerabilities, and data
collection. Section 4 describes the results of the empirical study, and then
Section 5 describes the impacts of compiler versions on the vulnerabilities,
including code clones and threats of validity in this paper. The conclusion
and future directions are presented in Section 6.

##  2\. Background

In this section, we describe Ethereum smart contracts and their related works
as technical backgrounds.

###  2.1. Ethereum Smart Contracts

Smart contracts in Ethereum are known as an _immutable_ computer program that
is deployed on the blockchain, and are executed _deterministically_ in
Ethereum Virtual Machines (EVMs) managed by peers in the Ethereum network. The
immutability means that the code of smart contracts cannot be changed once
deployed. On the other hand, the deterministic property means that the
execution of functions of the smart contracts will produce the same result
even when anyone runs them.

Smart contracts in Ethereum are implemented with source code written in a
high-level language such as Solidity (solidityDoc0.8.0, 25) in general. Once
deployed on the blockchain, a contract is self-enforcing on EVMs. Each smart
contract is given a contract address as a unique identifier. Using this
address, the smart contract can receive Ether, the cryptocurrency of Ethereum,
when its contract address is designated as the destination of a transaction
transmitted over the network and then its functions are executed. When a
contract is invoked, the transaction and the execution result are recorded on
the blockchain. The transaction data also represents the function to be
executed and its parameters in the contract. To give the peers incentives for
executing functions of contracts, Ethereum relies on _gas_ as payment of Ether
to “fuel computations”.

Since Vulnerabilities of smart contracts may cause expensive financial damage
as found in The DAO hack, their countermeasure tools have been developed so
far (chen2020survey, 4). Remarkably, compiler updates can prevent vulnerable
code from deployment and execution. For instance, execution of code with
integer overflow vulnerability fails even when a transaction is given, as long
as the code is compiled with the Solidity compiler version 0.8.0 (and later
versions).

###  2.2. Related Work

Empirical studies for smart contracts and designs of vulnerability analysis
tools are described below.

####  2.2.1. Empirical Study

Hwang et al. (hwang2020gapbetweentheoryandpractice, 11) found that 98.14% of
contracts did not have security patches for known vulnerabilities. They
conducted research until the compiler version 0.5. Our work is a subsequent
work of their work, and we conduct research until version 0.8. Perez et al.
(perez2021smartcontract, 19) analyzed the financial damage by vulnerable
contracts. Combining our work with the above works, it is expected that the
financial damage caused by vulnerabilities is estimated for each compiler
version.

Durieux et al. (durieux2020empirical47587, 8) and Ren et al.
(ren2021empirical, 22) investigated the performance of existing vulnerability
analysis tools with smart contracts, respectively. There are also surveys on
developments and their release status of vulnerability analysis tools
(Angelo2019surveytools, 2, 15, 8, 22). According to a questionnaire survey
(wan2021securityperspective, 29) for smart contract developers by Wan eta al.,
only about half of the developers use the latest compiler versions and
vulnerability analysis tools. Indeed, a new compiler version is often unstable
(tantikul2020exploring, 26, 7), and it may need time until the compiler is
stable. The surveys described above were conducted from the standpoints of the
performance analysis of tools or their developers’ viewpoints. However, they
have not indicated how many vulnerabilities are involved in the real world. We
believe that it is possible to identify specific vulnerabilities that should
be addressed in the future by combining the above works with our work.

####  2.2.2. Design of Vulnerability Analysis Tools

According to existing empirical studies for analysis tools
(parizi2018empiricalanalysis, 18, 8, 15), SmartCheck
(tikhomirov2018smartcheck, 27) and Mythril (mueller2018mythril, 17) can
provide high accuracy. SmartCheck is also faster than Mythril, and hence we
utilize SmartCheck for our empirical study.

##  3\. Methodology of Empirical Study

In this section, we describe the research methodology of our empirical study.
We first describe a vulnerability analysis tool to be utilized in the
empirical study and then the preliminary study that was conducted in advance.
We then describe the empirical study setting, including vulnerabilities to be
analyzed, data collection, and metrics.

###  3.1. Vulnerability Analysis Tool

We utilize SmartCheck (tikhomirov2018smartcheck, 27) for an empirical study of
vulnerabilities. SmartCheck is a tool to analyze vulnerabilities in contracts
written in Solidity. Roughly speaking, SmartCheck generates an XML parse tree
as an intermediate representation of code and then detects vulnerability
patterns by using XPath444https://www.w3.org/TR/xpath20/ on the intermediate
representation. It can provide a high accuracy (durieux2020empirical47587, 8,
18) as described in Section 2.2 and the source code is publicly available via
GitHub555https://github.com/smartdec/smartcheck.

We follow the definition by Perez et al. (perez2021smartcontract, 19) as
vulnerability: a contract is vulnerable if it has been detected by an analysis
tool. It may indicate that some contracts are to be vulnerable due to false
positives. According to Perez et al., while false positives are not a serious
problem, false negatives need to be reduced possibly. We adopt the above
definition in this paper.

###  3.2. Preliminary Study

We first conducted a preliminary study on contracts deployed by April 2022.
The goal of this preliminary study is to choose compiler versions discussed in
this study because several versions may be unstable (tantikul2020exploring,
26, 7).

We then found only 32 contracts for version 0.1 and 127 contracts for version
0.2. These contracts were deployed by April 2016, and there was no contract
compiled with version 0.1 and version 0.2 after that, as shown in Fig. 1.

Figure 1. The Ratio of each compiler version. The horizontal axis represents
each month and the vertical axis represents the use ratio of contracts
complied with each version.

It is considered that these versions were seldom used, and this result is
consistent with the existing empirical study (pinna2019massiveanalysis, 21).
Meanwhile, there were many empty contracts in version 0.3. These contracts
contain only 0x as bytecode. They might fail to deploy or be erased from the
blockchain. Consequently, we decided that the analysis of version 0.1 to
version 0.3 is unstable. Hereafter, version 0.4 and later versions are used
for the empirical study. We note that the compiler version 0.4 was released on
2016/9/4.

We also focused on vulnerabilities with the highest severity
(tikhomirov2018smartcheck, 27) in the preliminary study. In general, the
severity of vulnerabilities is correlated to the amount of damage caused by
them, and hence the analysis based on the highest severity is a more important
issue in the real world than other vulnerabilities. When we analyzed
vulnerabilities with the highest severity, Constructor Return, one of those
with the highest severity, was not detected. Thus, we analyze three
vulnerabilities except for the Constructor Return in this study.

###  3.3. Vulnerabilities to Be Analyzed

We focus on Locked Money, Using tx.origin, and Unchecked Call as
vulnerabilities with the highest severity in our empirical study. We describe
each vulnerability in detail below.

####  3.3.1. Locked Money

It was discovered through a parity wallet
attack666https://www.comae.com/posts/the-280m-ethereums-parity-bug./ whereby a
transaction with signatures by multiple users is invalid because one of the
signatures is incorrect. It will then cause Ether to be frozen. Locked Money
occurs when a function is defined to receive Ether with the payable modifier,
but there is no function to send Ether, e.g., send() or transfer(). The
received Ether is then frozen in the contract. It is necessary to implement
functions to send Ether in order to prevent Locked Money.

####  3.3.2. Using tx.origin

It occurs due to the global variable, tx.origin, which represents a user’s
address who sends a transaction. A global variable similar to tx.origin is
msg.sender, which represents the caller contract. If tx.origin is used for
authentication instead of msg.sender, Ether may be sent to an unauthorized
party.

####  3.3.3. Unchecked Call

It is known as Mishandled Exception and occurs when a contract calls another
contract without considering the exception on the callee (luu2016making, 16).
If the callee contract causes the exception when the caller contract sends
Ether to the callee, it then rewinds the process of the callee and the callee
cannot receive Ether. However, since the caller does not handle the exception,
it will lead to lose Ether. In version 0.4.10, the transfer() function was
introduced to handle an exception for a caller contract when the exception
occurs in a callee contract. It is recommended to use the transfer() function
for sending Ether.

###  3.4. Setting

####  3.4.1. Data Collection

We utilized Etherscan777https://etherscan.io/ for data collection of the
empirical study. Etherscan is a block explorer for Ethereum and provides an
API to retrieve information on the blockchain. We collected all the contracts
deployed by August 31, 2022, with Etherscan’s API for the empirical study. We
then collected and analyzed 503,572 contracts in total, whose source codes are
publicly available and written in Solidity.

The specific process of the data collection is as follows: (1) refer to blocks
generated until August 31, 2022; (2) search transactions in the blocks whose
destinations are empty, i.e., contract-creating transactions, and then obtain
their transaction hashes; (3) refer to the transaction information using the
hash and obtain the address of the created contract; (4) from the address,
obtain the source code and its compiler version information if available.

####  3.4.2. Metrics

We analyzed the source code by SmartCheck (tikhomirov2018smartcheck, 27) to
determine whether it is vulnerable or not. We then define two metrics for the
empirical study, i.e., appearance rate and monthly appearance rate. They are
defined as follows;

(1) Appearance rate $\displaystyle=$ $\displaystyle\frac{\mbox{number of
vulnerable contracts}}{\mbox{number of deployed contracts}}.$

The numerator of the above equation represents the number of contracts
detected by SmartCheck as vulnerable, and the denominator represents the
number of contracts whose Solidity code is publicly available. When the above
value is computed for each month, we say it the monthly appearance rate.
Hereafter, we use the above metrics for the empirical study.

##  4\. Results of Empirical Study

In this section, we demonstrate the results of the empirical study conducted
in the setting described in the previous section. Specifically, we measure the
monthly appearance rates and the appearance rate for each compiler version.

###  4.1. Monthly Appearance Rate

The monthly appearance rates of Locked Money for each compiler version are
shown in Fig. 2. Considering the stability of the compiler, we focus on the
monthly appearance rates other than version 0.4 and version 0.7 in the period
after one year has passed since the latest version, version 0.8, appeared,
i.e., from January 2022 to August 2022. According to the figure, the monthly
appearance rate decreased for version 0.6 from version 0.5 during this period.
A similar result as version 0.6 was obtained for version 0.8. It means that
the monthly appearance rates are almost stable between version 0.6 and version
0.8.

Figure 2. Monthly appearance rates for Locked Money in each version.

Next, the monthly appearance rates of Using tx.origin for each compiler
version are shown in Fig. 3. According to the figure, except for version 0.7,
the monthly appearance rates were less than 5% on average. The monthly
appearance rates seem to be stable.

Figure 3.  Monthly appearance rates for Using tx.origin in each version.

Finally, the monthly appearance rates of Unchecked Call for each compiler
version are shown in Fig. 4. According to the figure, except for version 0.4
and version 0.7, the monthly appearance rate decreased proportionally to
compiler updates in the same period as Locked Money except for a small part.
The reason why the monthly appearance rates for version 0.4 and version 0.7
are outliers is described in Section 5.1.3.

Figure 4.  Monthly appearance rates for Unchecked Call in each version.

###  4.2. Appearance Rate

The appearance rates of the vulnerabilities for each compiler version are
shown in Table 1. According to the table, the appearance rate has increased
for all vulnerabilities after the update from version 0.4 to version 0.5. In
contrast, looking at the update to version 0.6 and version 0.8, we can observe
similar results as those in the previous section, i.e., Locked Money and Using
tx.origin are stable while Unchecked Call is decreasing. It indicates that
similar results will be obtained entirely because of the increase in the
number of deployed contracts.

Table 1. Appearance rate for each compiler version. For the columns of vulnerabilities, each value represents the appearance rate, and the value in parentheses represents the number of contracts whose results on SmartCheck are vulnerable, respectively.  Version |  Num. of Deployed Contracts |  Locked Money |  Using tx.origin |  Unchecked Call
---|---|---|---|---
version 0.8 | 132912 |  6.86% (9120) |  1.87% (2491) |  22.04% (29297)
version 0.7 | 22442 |  5.73% (1286) |  4.90% (1099) |  38.14% (8560)
version 0.6 | 54402 |  6.66% (3624) |  2.97% (1614) |  49.10% (21271)
version 0.5 | 83390 |  33.60% (28017) |  1.84% (1538) |  32.90% (27434)
version 0.4 | 210426 |  10.66% (22421) |  0.61% (1286) |  1.73% (3644)

##  5\. Discussion

In this section, we discuss the impact of compiler updates, including the
consideration of version 0.4 and version 0.7 as exceptions. Next, we discuss
Unchecked Call, whose monthly appearance rate is high even on the latest
version with respect to false positives. We also discuss the impact of code
clones on the appearance rates for each vulnerability. Finally, we discuss
threats to the validity of this work, including future work.

###  5.1. Impact of Compiler Updates

####  5.1.1. Impact of Major Updates

We discuss the appearance rates for major updates. As shown in Section 4,
since the appearance rate tends to decrease with major updates on the overall
scale, it is considered that compiler updates are a contributing factor to the
decrease in vulnerabilities. We describe the reason based on Table 1 below.

First, for Locked Money, the appearance rate is significantly decreased by the
compiler update from version 0.5 to 0.6: for instance, it is continuously
about 6% after version 0.6. Unfortunately, we could not identify the reason
for the decrease in the appearance rate. Nonetheless, we still consider that
the compiler update is effective for the decrease in Locked Money. The
appearance rate for version 0.5 is still high even after version 0.6 is
released, according to Fig. 2. There were 60,267 contracts for version 0.5 as
contracts deployed since December 2019, i.e., version 0.6 was released. We
also found 18,717 vulnerable contracts for version 0.5 among them with respect
to Locked Money, i.e., 31.06% appearance rate. Namely, there is a clear gap
between version 0.6 (and later versions) and version 0.4/version 0.5. We leave
it as an open question to deeply understand the decrease in the appearance
rate for Locked Money.

Next, for Using tx.origin, the appearance rates are lower than 5% for any
version. Indeed, avoiding tx.origin for authentication has been described in
the Solidity official document (solidityDoc0.8.0, 25). We believe that the
description in the official document significantly affects the decrease of
Using tx.origin. We could not confirm the impact of the compiler update for
Using tx.origin because the number of its vulnerable contracts is quite
limited. We note that there is no real-world attack for Using tx.origin
(zhou2022stateofethereum, 34), and hence the impact of Using tx.origin itself
is regarded as minimal.

Finally, for Unchecked Call, we focus on version 0.6 or later versions.
Indeed, although version 0.6 introduced the try-catch syntax, it does not
adapt to Unchecked Call well (wang2021soliditylanguagefeatures, 31).
Furthermore, we focus on only version 0.6 and version 0.8 because version 0.7
is an exception, as described above. Then, the appearance rate for Unchecked
Call is decreased in version 0.8 to less than half of version 0.6.

Based on the results described above, we conclude as the major updates
strikingly affect the decrease in vulnerabilities. Although one might think
that the appearance rate for Unchecked Call is still high even for version
0.8, we discuss this viewpoint in the next subsection in detail.

####  5.1.2. Impact of Minor Updates

We discuss the appearance rates for minor updates to investigate the causal
relationship between compiler updates and appearance rates in more detail. As
a result, there were both decreasing and increasing tendencies of appearance
rate according to minor updates, and there was no similar change among most of
the versions.

Figure 5.  The number of deployed contracts and days until the next minor
version in each compiler version.

It is because the period until the next minor version and the number of
deployed contracts vary significantly for each minor version. For instance,
the period is from one day to more than half a year by the next version, and
at least three to at most 97,589 contracts are deployed as shown in Fig. 5. If
the number of deployed contracts is limited, the appearance rate is unstable.
Therefore, it is difficult to confirm the impact of minor updates. The
compiler update may be executed when a bug is discovered or new language
constructions are necessary (pinna2019massiveanalysis, 21). To confirm the
detailed factors, we need to investigate the relationship between each
vulnerability and the added functions or bugs that have been fixed. We leave
it as an open question to confirm the impact of minor updates.

####  5.1.3. Consideration on version 0.4 and version 0.7

We discuss why version 0.4 and version 0.7 are excluded from the results in
Section 4 below.

First, for version 0.4, there are drastic breaking changes from version 0.4 to
version 0.5. In particular, for sending Ether, we can call any address until
version 0.4 and can call only addresses that are payable after version 0.5.
Furthermore, functions such as transfer() and require() were not implemented
until version 0.4.9. Since version 0.5 and later versions contain these
points, the behavior of version 0.4 and version 0.5 (and later versions) are
significantly different.

Next, version 0.7 has a shorter period until version 0.8 is released compared
to the other versions. The period between version 0.7 and version 0.8 is four
and a half months, and the period from version 0.7 to version 0.8.x, the pre-
release version of version 0.8, is three months. It is much shorter than the
seven months from version 0.6 to version 0.7, which is the next shortest, and
for the other versions, more than a year has passed by the next version. Even
for minor updates, the number of updates is minimal, i.e., only six times for
version 0.7, which is half of version 0.6, the next minimal version. According
to the number of deployed contracts shown in Table 1, version 0.7 has been
underutilized in less than half of the other versions. Based on the reasons
above, it is considered that version 0.7 stopped providing minor updates
before it stabilized. Therefore, version 0.7 is unstable behavior compared to
the other versions.

###  5.2. Detailed Analysis of Unchecked Call

As shown in Table 1, the appearance rate for Unchecked Call decreases to
22.04% in version 0.8. Nevertheless, the decrease in the monthly appearance
rate is moderated compared to the other vulnerabilities. In this section, We
discuss the reason for the high appearance rate for Unchecked Call with
respect to false positives. Another reason, Code clone is mentioned in Section
5.3

To identify false positives, we checked the codes detected as vulnerable by
SmartCheck. We then found the delegatecall() function of the OpenZeppelin
library888https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable,
whose return values are recognized as unchecked by SmartCheck, in several
codes. We show the code in Listing 1. Since the OpenZeppelin library is known
for providing in-depth security (pierro2021analysis, 20) and static analysis
tools often have a high false positive rate (ren2021empirical, 22), we further
analyzed the OpenZeppelin library. As a result, we confirm that the return
values described above are checked by the if statement in line 6 of the code,
as shown in Listing 2. Namely, they did not contain Unchecked Call and thus
were false positives.

⬇

1function _functionDelegateCall(address target, bytes memory data) private
returns (bytes memory) {

2 require(AddressUpgradeable.isContract(target), "Address: delegate call to
non-contract");

3 (bool success, bytes memory returndata) = target.delegatecall(data);

4 return AddressUpgradeable.verifyCallResult(success, returndata, "Address:
low-level delegate call failed");

5}

Listing 1: delegatecall() in OpenZeppelin library

⬇

1function verifyCallResult(

2 bool success,

3 bytes memory returndata,

4 string memory errorMessage

5) internal pure returns (bytes memory) {

6 if (success) {

7 return returndata;

8 } else {

9 _revert(returndata, errorMessage);

10 }

11}

Listing 2: checking delegatecall() in OpenZeppelin library

###  5.3. Impact of Code Clone

We discuss the impact of code clones on the appearance rates of the
vulnerabilities. Besides false positives described in the previous subsection,
another possible reason for the high appearance rate for Unchecked Call is the
reuse of source codes because code in smart contracts is often reused as code
clones (chen2021understanding, 5). Based on the fact of code clones, we built
a hypothesis that the clones of vulnerable codes cause the high appearance
rate for Unchecked Call. We first test the hypothesis as a preliminary
analysis. After that, based on the hypothesis, we describe how to collect code
clones to understand the impact of them on the appearance rates. Next, we
discuss the impact of code clones on the appearance rates.

####  5.3.1. Preliminary Analysis

We conduct a preliminary analysis to test whether the hypothesis is true.
Specifically, we first focus on version 0.4 since it has increased from May
2022 as shown in Fig. 4.

During this period, SmartCheck detected 31 contracts with Unchecked Call,
while we found that the source codes of 23 contracts are almost the same codes
when we manually checked these codes. It means that 23 contracts among the
detected contracts were clones of the same contract. Notably, eleven contracts
were exactly the same, and the remaining twelve contracts contained one
additional function compared to the original contract. (Hereafter, we say the
original contract if it is unique and the origin of other code clones.)

Based on this result, we believe that the above hypothesis is true. Therefore,
we explore code clones in more detail as the remaining parts of this
subsection.

####  5.3.2. Collection of Code Clone

We describe how we collect code clones. Afterward, we discuss their impact on
vulnerabilities and compiler versions used by developers in Section 5.3.3 and
Section 5.3.4. We note that the following results are based on the last six
months. The original contracts during this period might be clones of those
deployed before this period. It indicates that there might be more code clones
than this result.

We define code clones as having all the same code or just adding a few lines
with the original contract under the same compiler version. It is known as the
type-3 clone (Roy07asurvey, 23). We utilize the compare function of the
difflib.Differ object in Python3 to identify code clones of Solidity code.
This function can search for differences between two files and then output
added or deleted lines of the files. We deal with only the contracts, that
consist of a single file and are deployed in the last six months, i.e., from
March to August 2022.

####  5.3.3. Consideration of Unchecked Call

We analyze the contracts collected in Section 5.3.2 to identify the impact of
code clones on the appearance rates of each vulnerability. In particular, we
identify how the appearance rates change by removing the code clones of
Unchecked Call. We also identify the appearance rates of Locked Money and
Using tx.origin by removing code clones for comparison with Unchecked Call.
Hereafter, we call the contracts before removing the code clones as all
contracts for the sake of convenience.

Figure 6. Difference of appearance rates for Locked Money between all
contracts and original contracts in each version. The all_contracts contain
the all collected contracts, and the original_contracts contain only the
original contracts by removing clones.  Figure 7. Difference of appearance
rates for Using tx.origin between all contracts and original contracts in each
version. The setting is common with Fig. 6.  Figure 8. Difference of
appearance rates for Unchecked Call between all contracts and original
contracts in each version. The setting is common with Fig. 6.

Figs. 6, 7, and 8 show the comparison of the appearance rates for each
vulnerability with respect to each compiler version, where all the code clones
described above are removed.

For version 0.7 of Locked Money and version 0.5 of Using tx.origin, the
appearance rates of the original contracts are higher than the all contracts,
respectively. On the other hand, For Unchecked Call, all the appearance rates
of the original contracts are lower than the all contracts.

Here, we focus on the differences between the appearance rates of the all
contracts and the original contracts on version 0.8 in comparison between the
vulnerabilities. We can see that the appearance rates of both Locked Money and
Unchecked Call decrease by removing code clones. Based on this fact, as might
have been expected, code clones are not a reason why the appearance rate for
Unchecked Call on version 0.8 is higher than that of the other two
vulnerabilities.

Nevertheless, we can still confirm if removing the code clones decreases the
appearance rates for Unchecked Call in all the versions as shown in Fig. 8. In
other words, the appearance rates are increased due to the code clones.
Therefore, for Unchecked Call, it is considered that code clones are a reason
why the appearance rate is high and it can be decreased by removing the
clones.

####  5.3.4. Consideration of the Use of Older Versions

We analyze the use of older compiler versions to provide further evidence for
code clones. Since compiler updates reduce the vulnerabilities as shown in
Section 5.1.1, using newer compiler versions is strongly recommended. However,
several contracts have been created using the compiler with older versions,
and these contracts may contain many code clones: for instance, the appearance
rates for the all contracts and the original contracts shown in Fig. 8 quite
differ in version 0.5. Consequently, we measure the ratio of the original
contracts for each compiler version. We show the result in Table 2.

Table 2. Details of contracts deployed during the six months version | Num. of Deployed Contracts | Ratio of Original Contracts
---|---|---
version 0.4 | 701 | 67.05%
version 0.5 | 1771 | 47.15%
version 0.6 | 2241 | 81.62%
version 0.7 | 716 | 78.91%
version 0.8 | 38891 | 91.14%

From the table, the ratio of the original contracts over the all contracts
tends to increase as a compiler version becomes newer. In other words, clones
of contracts tend to increase as the compiler version becomes older during the
latest six months. Besides, the number of the deployed contracts decreases as
a compiler version becomes older, except for version 0.7 which is rarely used.
Considering the high ratio of code clones and the number of deployed contracts
altogether, we are able to assume that a reason for using older compiler
versions is the reuse of contracts created by older versions.

When clones of some contracts are compiled with different compiler versions
from the original contracts, the specification change in the Solidity language
will lead to errors. Namely, they cannot be compiled. Furthermore, developers
need to specify the Solidity compiler versions with pragma solidity in their
source codes. It is written in most of the contracts, and the compiler with
the other versions cannot compile them. For the reasons described above, we
consider that code clones of contracts are compiled with the same version as
the original contracts.

However, these clones may have vulnerabilities common with their original
contracts as shown in Section 5.3.3 while developers need to create secure
contracts. Consequently, as mentioned at the beginning of this section, when
the developers need to reuse the contracts, we recommend the use of a newer
compiler version, which fixes errors.

###  5.4. Threats to Validity

Our empirical study has three threats to validity, i.e., long-term analysis of
code clones, false negatives, and developer’s skills. They are issues that
need to be addressed in the future. The details are described below.

####  5.4.1. Long-Term Analysis of Code Clones

Our analysis of code clones is limited to the last six months. As described in
Section 5.3.2, the original contracts during this period might be clones
deployed in earlier periods. Moreover, the number of code clones may differ
for periods after each compiler version is released. Further studies, which
take a long-term analysis of code clones into account, will need to be
performed.

####  5.4.2. False Negatives

We only used SmartCheck for the vulnerability analysis of the empirical study.
It means that the results rely on the analysis accuracy of SmartCheck, and
hence there may exist vulnerable codes that are false negatives. According to
the existing study (perez2021smartcontract, 19), the number of false negatives
in analysis can be reduced by introducing more analysis tools and then
deciding contracts as vulnerable if any tool decides them as vulnerable. Thus,
further studies, which introduce more existing analysis tools
(mueller2018mythril, 17, 16, 9, 24) other than SmartCheck, will need to be
undertaken to reduce false negatives possibly.

####  5.4.3. Developer’s Skill

The developer’s coding skills may affect the number of vulnerable contracts,
but they were not considered in this paper. According to the current
questionnaire survey (wan2021securityperspective, 29), many developers of
smart contracts are no longer worried about security, and hence there should
exist vulnerable codes due to developer’s skills. We are in the process of
interviewing developers to understand code skills.

##  6\. Conclusion

In this paper, we collected 503,572 contracts deployed by 2022/8/31 with
version 0.4 and later version compilers and then conducted the empirical study
for vulnerabilities with the highest severity (tikhomirov2018smartcheck, 27).
Based on the analysis with SmartCheck, we identified that the appearance rates
for Locked Money, Using tx.origin, and Unchecked Call are decreased by virtue
of major updates for the Solidity compiler. We also found that the appearance
rate for Locked Money is decreased by about 6% after version 0.6 while that of
Using tx.origin is limited initially. We also demonstrated that the appearance
rate for Unchecked Call is decreased by 22.04% in version 0.8, and it will be
further decreased if code clones are removed. We plan to conduct extensive
evaluations for long-term analysis of code clones and reducing false negatives
with more tools (mueller2018mythril, 17, 16, 9).

###### Acknowledgements.

This work was supported in part by MEXT ”Innovation Platform for Society 5.0”
Program Grant Number JPMXP0518071489 and by JST, CREST Grant Number
JPMJCR21M5, Japan.

## Reproducibility

Our code is available via GitHub
(https://github.com/c-kado/Ethereum_empirical).

## References

  * (1) Leonardo Alt, Martin Blicha, Antti E.. Hyvärinen and Natasha Sharygina  “SolCMC: Solidity Compiler’s Model Checker”  In _Proc. of CAV 2022_ 13371, LNCS  Springer, 2022, pp. 325–338
  * (2) Monika Di Angelo and Gernot Salzer  “A Survey of Tools for Analyzing Ethereum Smart Contracts”  In _Proc. of DAPPCON 2019_ IEEE, 2019, pp. 69–78
  * (3) Nami Ashizawa, Naoto Yanai, Jason Paul Cruz and Shingo Okamura  “Eth2Vec: Learning Contract-Wide Code Representations for Vulnerability Detection on Ethereum Smart Contracts”  In _Proc. of BSCI 2021_ ACM, 2021, pp. 47–59
  * (4) Huashan Chen, Marcus Pendleton, Laurent Njilla and Shouhuai Xu  “A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses”  In _ACM Computing Surveys_ 53.3 ACM, 2020, pp. 1–43
  * (5) Xiangping Chen et al.  “Understanding Code Reuse in Smart Contracts”  In _Proc. of SANER 2021_ IEEE, 2021, pp. 470–479
  * (6) Yuichiro Chinen, Naoto Yanai, Jason Paul Cruz and Shingo Okamura  “RA: Hunting for Re-Entrancy Attacks in Ethereum Smart Contracts via Static Analysis”  In _Proc. of Blockchain 2020_ IEEE, 2020, pp. 327–336
  * (7) Silvia Crafa and Matteo Di Pirro  “Solidity 0.5: when typed does not mean type safe”  In _arXiv preprint arXiv:1907.02952_ , 2019
  * (8) Thomas Durieux, João F. Ferreira, Rui Abreu and Pedro Cruz  “Empirical review of automated analysis tools on 47,587 Ethereum smart contracts”  In _Proc. of ICSE 2020_ ACM, 2020, pp. 530–541
  * (9) Josselin Feist, Gustavo Grieco and Alex Groce  “Slither: A Static Analysis Framework for Smart Contracts”  In _Proc. of WETSEB 2019_ IEEE, 2019, pp. 8–15
  * (10) Joel Frank, Cornelius Aschermann and Thorsten Holz  “ETHBMC: A Bounded Model Checker for Smart Contracts”  In _Proc. of USENIX Security 2020_ USENIX Association, 2020, pp. 2757–2774
  * (11) Sungjae Hwang and Sukyoung Ryu  “Gap between Theory and Practice: An Empirical Study of Security Patches in Solidity”  In _Proc. of ICSE 2020_ ACM, 2020, pp. 542–553
  * (12) Chihiro Kado, Naoto Yanai, Jason Paul Cruz and Shingo Okamura  “An Empirical Study of Impact of Solidity Compiler Updates on Vulnerabilities”  In _Proc. of BRAIN 2023_ IEEE, 2023, pp. 92–97
  * (13) Sukrit Kalra, Seep Goel, Mohan Dhawan and Subodh Sharma  “ZEUS: Analyzing Safety of Smart Contracts.”  In _Proc. of NDSS 2018_ Internet Society, 2018
  * (14) Satpal Singh Kushwaha et al.  “Ethereum Smart Contract Analysis Tools: A Systematic Review”  In _IEEE Access_ 10 IEEE, 2022, pp. 57037–57062
  * (15) Satpal Singh Kushwaha et al.  “Systematic Review of Security Vulnerabilities in Ethereum Blockchain Smart Contract”  In _IEEE Access_ 10 IEEE, 2022, pp. 6605–6621
  * (16) Loi Luu et al.  “Making smart contracts smarter”  In _Proc. of CCS 2016_ ACM, 2016, pp. 254–269
  * (17) Bernhard Mueller  “Smashing Ethereum Smart Contracts for Fun and Real Profit”  In _9th HITB Security Conference_ , 2018
  * (18) Reza M. Parizi, Ali Dehghantanha, Kim-Kwang Raymond Choo and Amritraj Singh  “Empirical Vulnerability Analysis of Automated Smart Contracts Security Testing on Blockchains”  In _Proc. of CASCON 2018_ IBM Corp., 2018, pp. 103–113
  * (19) Daniel Perez and Benjamin Livshits  “Smart Contract Vulnerabilities: Vulnerable Does Not Imply Exploited”  In _Proc. of USENIX Security 2021_ USENIX Association, 2021, pp. 1325–1341
  * (20) Giuseppe Antonio Pierro and Roberto Tonelli  “Analysis of Source Code Duplication in Ethreum Smart Contracts”  In _Proc. of SANER 2021_ IEEE, 2021, pp. 701–707
  * (21) Andrea Pinna et al.  “A Massive Analysis of Ethereum Smart Contracts Empirical Study and Code Metrics”  In _IEEE Access_ 7 IEEE, 2019, pp. 78194–78213
  * (22) Meng Ren et al.  “Empirical Evaluation of Smart Contract Testing: What is the Best Choice?”  In _Proc. of ISSTA 2021_ ACM, 2021, pp. 566–579
  * (23) Chanchal Kumar Roy and James R. Cordy  “A Survey on Software Clone Detection Research”  In _SCHOOL OF COMPUTING TR 2007-541, QUEEN’S UNIVERSITY_ 115, 2007
  * (24) Clara Schneidewind, Ilya Grishchenko, Markus Scherer and Matteo Maffei  “EThor: Practical and Provably Sound Static Analysis of Ethereum Smart Contracts”  In _Proc. of CCS 2020_ ACM, 2020, pp. 621–640
  * (25) “Solidity v0.8.0 Breaking Changes”, https://docs.soliditylang.org/en/latest/080-breaking-changes.html
  * (26) Phitchayaphong Tantikul. and Sudsanguan Ngamsuriyaroj.  “Exploring Vulnerabilities in Solidity Smart Contract”  In _Proc. of ICISSP 2020_ SciTePress, 2020, pp. 317–324  INSTICC
  * (27) Sergei Tikhomirov et al.  “Smartcheck: Static analysis of ethereum smart contracts”  In _Proc. of WETSEB 2018_ ACM, 2018, pp. 9–16
  * (28) Petar Tsankov et al.  “Securify: Practical security analysis of smart contracts”  In _Proc. of CCS 2018_ ACM, 2018, pp. 67–82
  * (29) Zhiyuan Wan et al.  “Smart Contract Security: A Practitioners’ Perspective”  In _Proc. of ICSE 2021_ IEEE/ACM, 2021, pp. 1410–1422
  * (30) Yilin Wang et al.  “An Empirical Study on Real Bug Fixes in Smart Contracts Projects”  In _CoRR_ abs/2210.11990, 2022  URL: https://doi.org/10.48550/arXiv.2210.11990
  * (31) Ziyan Wang et al.  “An Empirical Study of Solidity Language Features”  In _Proc. of QRS-C 2021_ IEEE, 2021, pp. 698–707
  * (32) Konrad Weiss and Julian Schütte  “Annotary: A Concolic Execution System for Developing Secure Smart Contracts”  In _Proc. of ESORICS 2019_ 11735, LNCS  Springer, 2019, pp. 747–766
  * (33) Gavin Wood  “Ethereum: A secure decentralised generalised transaction ledger Byzantium Version”, 2022  URL: https://ethereum.github.io/yellowpaper/paper.pdf
  * (34) Haozhe Zhou, Amin Milani Fard and Adetokunbo Makanju  “The State of Ethereum Smart Contracts Security: Vulnerabilities, Countermeasures, and Tool Support”  In _Journal of Cybersecurity and Privacy_ 2.2 MDPI, 2022, pp. 358–378
  * (35) Weiqin Zou et al.  “Smart Contract Development: Challenges and Opportunities”  In _IEEE Transactions on Software Engineering_ 47.10 IEEE, 2021, pp. 2084–2106