electronics

Article
Advanced Security Auditing Methods for Solidity-Based
Smart Contracts
Meihua Xiao, Yangping Xu *, Zehuan Li and Hongbin Wan

School of Information and Software Engineering, East China Jiaotong University, Nanchang 330013, China;
[email protected] (M.X.); [email protected] (Z.L.); [email protected] (H.W.)
* Correspondence: [email protected]

Abstract: The development of smart contracts remains in its early stages, with significant differences
in underlying programming languages and application platforms resulting in a lack of standard-
ization. This lack of standardization increases the susceptibility to vulnerabilities and associated
financial losses. To address security vulnerabilities in smart contracts on the Ethereum blockchain
platform, this paper proposes a security audit method based on formal verification. The method
integrates an input module, static analysis module, formal verification module, analog execution
module, and report and recommendation module, which can accurately discover the security vulnera-
bilities and logical flaws of smart contracts through formal verification and other analysis techniques,
thus realizing correctness detection. During the experiment, the method detects 8 types of common
vulnerabilities in 148 smart contracts and marks 21 smart contracts with vulnerabilities. After manual
review and analysis, it is found that 17 of these 21 marked smart contracts do have security vulner-
abilities. The experimental results show that the proposed method can accurately detect security
vulnerabilities and logic flaws in smart contracts through formal verification and other analysis
techniques before smart contracts are deployed, thus significantly improving the security of smart
contracts and reducing the economic losses that may be caused by code defects.

Keywords: smart contracts; blockchain; formal methods; model checking; Ethereum

Citation: Xiao, M.; Xu, Y.; Li, Z.; Wan,

H. Advanced Security Auditing 1. Introduction
Methods for Solidity-Based Smart
Blockchain technology was first described by Satoshi Nakamoto in his published article
Contracts. Electronics 2024, 13, 4093.
in 2008. Blockchain is a kind of distributed shared ledger [1], which saves the information
https://doi.org/10.3390/
of Bitcoin transactions in individual blocks by means of distributed storage, and the data
electronics13204093
of each block determine the generation of its sub-blocks. However, Bitcoin is relatively
Academic Editors: Aryya single-function and cannot realize complex applications on the blockchain network, which
Gangopadhyay and Mehdi Sookhak limits its practical application value. In the development of blockchain technology, the
emergence of Ethereum has solved this problem well, making the commercial application
Received: 20 September 2024
Revised: 11 October 2024
of blockchain possible.
Accepted: 16 October 2024
Ethereum [2] is a decentralized application platform that, similar to cryptocurrencies
Published: 17 October 2024 such as Bitcoin, has electronic payment and digital asset transfer capabilities. In addition,
any user can build decentralized applications (DApps) [3] on Ethereum to interact with
other applications. These decentralized applications are composed of smart contracts,
which manage many of the key features, operations, and user behaviors of Ether. The con-
Copyright: © 2024 by the authors. cept of smart contracts [4,5] was first introduced by cryptographer Szabo as computerized
Licensee MDPI, Basel, Switzerland. transaction protocols stored digitally that automatically enforce the terms of a contract.
This article is an open access article In recent years, with the growing maturity of smart contract technology and its
distributed under the terms and
wide application on blockchain platforms, more and more scholars have noticed that
conditions of the Creative Commons
vulnerabilities in smart contracts pose a significant threat to the security of users and
Attribution (CC BY) license (https://
blockchain platforms [6]. For example, DAO, the world’s largest crowdfunding project
creativecommons.org/licenses/by/
deployed on Ether, was hacked, resulting in the loss of more than ETH 3 million from the
4.0/).

Electronics 2024, 13, 4093. https://doi.org/10.3390/electronics13204093 https://www.mdpi.com/journal/electronics

Electronics 2024, 13, 4093 2 of 22

DAO pool [7], and Parity, an Ether multi-signature wallet, also suffered from a security
vulnerability, resulting in the theft of more than ETH 150,000 (about USD 30 million) [8],
and the painful lessons of such incidents highlight the importance of ensuring the security
and correctness of smart contracts.
The current blockchain ecosystem is highly heterogeneous, with various platforms
using distinct smart contract programming languages such as Solidity for Ethereum, C++
for EOS, and Go for Hyperledger. While this diversity has enabled unique functionalities,
it has also led to significant standardization issues. Different languages and technical
architectures result in poor cross-platform code compatibility, complicating migration and
validation. Moreover, this diversity impacts the consistency of development tools and
frameworks, posing challenges for establishing unified security auditing standards. Each
language has its own vulnerabilities and risks, making standardized security measures
difficult to implement across platforms. For instance, recursive attacks can exhaust contract
resources, excessive privileges can lead to malicious manipulation, and issues with ran-
domness can introduce uncertainty and increase manipulation risks. Detailed attack types
are listed in Appendix A.
Traditional security auditing methods, which rely on manual reviews and testing, are
inefficient and prone to overlooking unforeseen logic errors and vulnerabilities. To address
these challenges, this paper integrates an input module, static analysis module, formal
verification module, simulation execution module, and a report and recommendation
module, making the following contributions:
• Capable of accurately identifying issues such as security vulnerabilities and logic flaws
in smart contracts through formalized verification and other technologies before smart
contracts are deployed, thereby significantly improving the security of smart contracts
and reducing the economic losses that may be caused by code defects.
• Proposes a scalable, automated smart contract review methodology that minimizes
reliance on manual review and ensures comprehensive and consistent assessment
of smart contracts, thereby improving the overall security and reliability of
blockchain applications.
• Simplifies the review process, shortens the development cycle, and generates clear
and actionable audit reports, thereby improving audit efficiency and reducing human
security risks.
The rest of this paper is organized as follows. Section 2 gives a presentation of
the related proposals carried out in the area of smart contract formal verification. We
propose a security audit method to discover the vulnerabilities of current smart contracts
and make timely modifications before deploying smart contracts in Section 3. Section 4
detects all smart contracts deployed on the test network against various vulnerabilities.
Section 5 analyzes the advantages and disadvantages of the proposed approach. Finally,
the conclusions and future work are discussed in Section 6.

2. Relative Work
Many researchers have carried out several works on vulnerability detection and
formal verification of smart contracts. The main work can be categorized into the following
two aspects: the first aspect is for vulnerability detection of smart contracts, and the
second aspect focuses on ensuring the security and correctness of smart contracts.

2.1. Detecting Vulnerabilities

The vulnerability detection tool Oyente [9] was one of the earliest to apply symbolic
execution techniques for validating smart contracts, marking a significant advancement in
the field. Building on this foundational work, Manticore [10] was introduced as a dynamic
symbolic execution tool designed to simplify the validation process and make it more
accessible to users, thereby lowering the barrier for effective vulnerability detection.
TEETHER [11], another specialized verification tool, utilizes symbolic execution to con-
vert the challenge of verifying temporal logic security properties into a program reachability
Electronics 2024, 13, 4093 3 of 22

analysis, ensuring robust verification of temporal logic-based expressions and enhancing

their security.
Osiris [12] is designed specifically to detect integer-related vulnerabilities, addressing a
common type of flaw in smart contracts. Similarly, HoneyBadger [13] focuses on identifying
honeypot contracts, which are designed to attract and exploit users.
TokenScope [14], developed to analyze inconsistencies within smart contracts, pro-
vides valuable insights into the operational correctness of token-based systems, helping to
ensure that token logic functions as intended.
Securify [15] offers a scalable verification framework that relies on data flow and
control flow analysis to comprehensively assess contract security. The Slither [16] static
analysis framework converts Solidity code into an intermediate representation known as
SlithIR, utilizing data flow and taint analysis to uncover potential vulnerabilities effectively.
SmartCheck [17] further contributes by generating XML parse trees and applying
XPath for pattern matching to detect security risks within contracts. EThor [18] enhances
verification by applying Horn logic [19] to perform program reachability analysis, validat-
ing the security properties of smart contracts. Lastly, MadMax [20], a static analysis tool,
specializes in identifying security risks associated with gas exhaustion—a crucial issue for
Ethereum smart contract execution.
These tools represent a broad spectrum of methodologies for smart contract security
verification, ranging from symbolic execution to static analysis. They collectively aim to
mitigate vulnerabilities and enhance the overall security and robustness of blockchain appli-
cations. Although symbolic execution and static analysis techniques provide strong support
for smart contract vulnerability detection and help developers avoid common security
risks, these tools are still unable to fully guarantee the security of the contract. Therefore,
although these tools provide important security guarantees for contract development,
they need to be used in conjunction with other methods to achieve more comprehensive
vulnerability detection and security verification.

2.2. Verification of Smart Contracts

To ensure the security and correctness of smart contracts, researchers have proposed
various formal verification methods and developed various tools to check the correctness of
smart contracts. Bhargavan, K [21] proposed a programming-language-based verification
method that converts smart contracts written in Solidity to F* language to check their
security. Kalra, S proposed a framework called ZEUS [22] that automatically verifies
the correctness of smart contracts and their fairness through abstract interpretation and
symbolic model detection.
However, these methods do not test the behavior of smart contracts in specific sce-
narios of interaction with clients. For this reason, the use of model detection is an ef-
fective approach. Model checking is an automated technique that systematically checks
whether the finite state model and formal properties of a given system satisfy a particular
specification [23]. Model-checking tools such as NuSMV [24] and Spin [25–27] verify that
each state of the model satisfies a user-defined specification. If a property is not satisfied,
the model checker provides a counterexample to help identify and correct the error. If each
state of the model satisfies the specification, the model is formally verified as correct.
Amani, S. et al. [28] used the theorem prover Isabelle/HOL and an existing EVM
formal model to verify bytecode for smart contracts, created a framework to express EVM
bytecode using logic, and successfully applied it to a case study. However, the framework
does not support the full syntax of solidity. Grigorenko et al. [29] proposed the first
static analysis tool for EVM bytecode that supports reachability properties, including key
security properties of smart contracts such as single-entry and transactional environment
dependencies. Although this approach will not detect vulnerabilities, it can guarantee that
the code is free from certain known types of vulnerabilities. Nehai, Z proposed a generic
modeling approach for smart-contract-based Ethernet applications [30] and considered
model-checking methods to verify that implementations conform to the specification. The
 Electronics 2024, 13, x FOR PEER REVIEW 4 of 22

Electronics 2024, 13, 4093 4 of 22

modeling approach for smart-contract-based Ethernet applications [30] and considered
model-checking methods to verify that implementations conform to the specification. The
proposedmodel
proposed modelisiswritten
written using
using thethe NuSMV
NuSMV inputinput language,
language, andand the
the properties
propertiesto tobe
be
checked are formalized as a temporal logic CTL [31]. Osterland, T. [32] proposed
checked are formalized as a temporal logic CTL [31]. Osterland, T. [32] proposed a toolchain a tool-
chain
for for seamlessly
seamlessly transforming
transforming smart contracts
smart contracts from thefrom the specification
specification level tolevel
theto the oper-
operational
level. The final step of this toolchain is to generate a code representation in PromelaPromela
ational level. The final step of this toolchain is to generate a code representation in [33] and
[33] anditvalidate
validate with theit model
with the model Spin.
checker checker Spin. However,
However, the toolchain
the toolchain is limitedis limited to cor-
to correctness
rectness verification
verification of individual
of individual contracts contracts
and needsand needs
to be to be extended
extended to interactive
to interactive veri-
verification of
fication of smart contract
smart contract networks. networks.

3.3.Security
SecurityAudit
Audit Method
Method
Toenhance
To enhance the
the security
security ofofsmart
smartcontracts,
contracts,this paper
this paperintroduces a security
introduces auditaudit
a security ap-
proach that
approach thatintegrates formalization
integrates formalization andandmodel-checking
model-checking techniques
techniqueswith
withformal verifica-
formal verifi-
tion. The
cation. Themethod
methodemploys
employsunified
unifiedspecifications
specificationstotoaudit
auditsmart
smartcontract
contractcode,
code,enabling
enabling
userstotosystematically
users systematicallyidentify
identifyandand mitigate
mitigate vulnerabilities
vulnerabilities before
before deployment.
deployment. ByBy for-
formal-
malizing contract behavior and leveraging model checking to explore all
izing contract behavior and leveraging model checking to explore all potential states, this potential states,
this approach
approach improves
improves the precision
the precision of vulnerability
of vulnerability detection,
detection, allowing
allowing for timely
for timely mod-
modifica-
ifications
tions and reducing
and reducing theof
the risk risk of security
security flawsflaws in deployed
in deployed contracts.
contracts.
Themain
The main method proposed
proposedininthis thispaper
paperis is
illustrated
illustratedin Figure 1, consisting
in Figure of five
1, consisting of
modules:
five modules:an input module,
an input a static
module, analysis
a static module,
analysis a formal
module, verification
a formal module,
verification a sim-a
module,
ulation execution
simulation module,
execution module,andand
a report andand
a report recommendation
recommendation module.
module.

Static Analysis

Grammar Semantic Constructing

Smart Contract Pattern Matching
Detection Detection AST

Formal Verification
Building formal Logical Inference
Smart Contract Simulation
models Algorithm
Security Audit
Method Generate State Verifying Security
LTL
Paths Attributes

Analog Execution
Constructing Generating State Simulating
State Machines Space Diagrams Smart Contracts
Audit Reports

Recording the Generate Simulation

Execution Path Execution Results

Figure 1. Schematic diagram of smart contract security audit method.

Figure 1. Schematic diagram of smart contract security audit method.

Theinput
The input module
modulereceives
receivesand
and parses
parsesthethe
smart contract
smart source
contract code,code,
source while while
the static
the
analysis module uses the ACL2 [34] tool to detect potential issues in the code.
static analysis module uses the ACL2 [34] tool to detect potential issues in the code. The formal
The
verification
formal modulemodule
verification ensuresensures
the security of the contract
the security through through
of the contract formal methods, and the
formal methods,
simulation execution module evaluates the contract’s performance in different
and the simulation execution module evaluates the contract’s performance in different environ-
ments. Finally,Finally,
environments. the report and recommendation
the report and recommendation module synthesizes
module the results
synthesizes fromfrom
the results all
modules to generate an audit report and provide targeted improvement suggestions.
all modules to generate an audit report and provide targeted improvement suggestions.

3.1.Input
3.1. InputModule
Module
Thismodule
This moduleisisdesigned
designed to
to receive
receive and
and parse smart contract
contract source
source code
code for
for formal
formal
verificationand
verification andmodel
model testing.
testing. It processes
processes contracts
contracts written
written in
in Solidity,
Solidity, identifying
identifyingkey
key
functions and variables while ensuring the integrity of the original code’s semantics during
conversion. By preprocessing and normalizing the input, this module enhances the accuracy
and efficiency of subsequent reviews.
 Electronics 2024, 13, x FOR PEER REVIEW 5 of 22

Electronics 2024, 13, 4093 functions and variables while ensuring the integrity of the original code’s semantics 5dur- of 22
ing conversion. By preprocessing and normalizing the input, this module enhances the
accuracy and efficiency of subsequent reviews.
Forinstance,
For instance,consider
consider a smart
a smart contract
contract implementing
implementing an online
an online store.store. The owner
The store store
owner
can add can
newadd new products,
products, update update
existingexisting inventory,
inventory, and withdraw
and withdraw ETH from ETHthe from the
store’s
store’s balance.
balance. Users canUsers
viewcan view product
product details
details and make andpurchases.
make purchases.
The ETH The ETH
paid bypaid
usersbyis
users is adjusted
adjusted according according to the product
to the product price andprice and quantity,
quantity, The excess
The excess will bewill be refunded
refunded to the
to the
user. user.successful
Upon Upon successful purchase,
purchase, the item’s
the item’s inventory
inventory is reduced,
is reduced, andtransactions
and all all transactions
and
and inventory
inventory changes
changes are logged
are logged on-chain
on-chain through
through events.
events. Figure
Figure 2 shows
2 shows an example
an example of
of the
the code of a smart contract.
code of a smart contract.

Figure 2. Source code of a solidity contract.

Figure 2. Source code of a solidity contract.
• With the smart contract code in Figure 2, we can find the source code at
• With the smart contract code in Figure 2, we can find the source code at https://
https://etherscan.io/address/0x27054b13b1b798b345b591a4d22e6562d47ea75a (ac-
etherscan.io/address/0x27054b13b1b798b345b591a4d22e6562d47ea75a (accessed on
cessed on16 October 2024), the contract owner can add items, set the name, price, and
16 October 2024), the contract owner can add items, set the name, price, and inventory,
inventory, and update the inventory; the user can purchase items by paying Ether,
and update the inventory; the user can purchase items by paying Ether, with the
with the system checking the inventory and processing the payment. Any excess pay-
system checking the inventory and processing the payment. Any excess payment will
ment will be returned to the user. The contract owner can withdraw funds from the
be returned to the user. The contract owner can withdraw funds from the store, and
store, and the contract also provides functionality for querying item information.
the contract also provides functionality for querying item information. Events notify
the contract of actions such as adding items, purchasing items, increasing inventory,
and withdrawing funds. Importantly, each role within the contract is verified through
specific functions to ensure that only authorized users can perform certain actions.
Role validation mechanisms are integrated into the contract to check permissions
Electronics 2024, 13, 4093 6 of 22

before executing sensitive operations, such as modifying inventory or withdrawing

funds. This ensures that all actions comply with the contract’s role-based access control.
Some of the functions in Figure 2 are explained as follows:
• addItem(): Allows store owners to add new item information, including item name,
price, and initial inventory, and assign a unique ID to the item. TheaddItem event is
triggered after recording the item ID, name, price, and inventory information.
• getItem(): Users can purchase a specified number of items and pay the corresponding
ETH, and the system checks whether the item exists, whether there is enough inventory,
and whether the Ether paid is enough. After successful purchase, the inventory will
be reduced and the ItemPurchased event will be triggered to record the purchase
information. If the paid Ether exceeds the total price, the excess will be refunded to
the user.
• purchaseItem(): Allows store owners to add inventory to existing items. The system
checks if the item exists and adds the stock quantity. When the stock is successfully
added, the StockAdded event is triggered, logging the item ID and the amount of
stock added.
• addStock(): The store owner can withdraw all the Ether accumulated in the contract.
After calling this function, the ETH balance in the contract will be transferred to
the owner’s address, and the FundsWithdrawn event will be triggered when the
withdrawal is successful, recording the owner’s address and the amount withdrawn.
• withdraw(): Allows any user to query the details of a specific item, including item
name, price, and current stock. This information can be retrieved by item ID and
returned to inform the user of the item's status.
• The smart contracts received by this module are written in Solidity, and after being
received and converted by the input unit, the next unit can receive the appropriate
statements.

3.2. Static Analysis Module

The static analysis module is designed to detect potential issues early in the smart
contract development process, ensuring security and reliability. By utilizing the ACL2
tool, this module automatically detects syntax and semantic errors, as well as potential
security vulnerabilities, addressing them before they become significant failures or risks.
This automated approach reduces the manual review workload while enhancing both
detection efficiency and thoroughness. Moreover, it identifies and resolves issues affecting
smart contract performance and gas consumption, thereby optimizing execution efficiency.
The module consists of several integrated components. First, the syntax-checking
unit scans the source code of the smart contract and constructs an abstract syntax tree
(AST). This process ensures that the code adheres to Solidity language specifications. Key
parameters such as Solidity versioning, code consistency, security rule configuration, and
compiler settings are employed to automatically detect and correct issues during the early
stages of development, thereby improving both security and reliability.
Next, the semantic analysis unit traverses the AST using a depth-first search algo-
rithm to detect semantic errors, such as variable type mismatches, improper handling of
function return values, and logical inconsistencies. The code is first broken down into
tokens—keywords, variable names, and operators—through lexical analysis and then
organized into an internal structure according to Solidity’s syntax rules. As the AST is
traversed, the semantic analyzer evaluates each node to verify type consistency and logical
correctness, ensuring that the source code remains semantically sound.
The security rule unit applies predefined security rules to detect vulnerabilities in the
code. It consists of two subcomponents: the security rule base, which contains detection
rules for common vulnerabilities like reentrancy attacks and integer overflows, and the
security audit subunit, which applies these rules to the code. During the security scan,
the tool analyzes key elements like function calls and state variable modifications, using
pattern recognition algorithms to identify potential security risks.
Electronics 2024, 13, 4093 7 of 22

Finally, the result output unit generates a comprehensive report detailing syntax and
semantic errors, as well as potential security vulnerabilities. Each issue is documented with
its location, type, impact, and remediation recommendations. While automated tools catch
many problems, a manual review is often necessary to confirm the validity of warnings
and ensure that all issues have been accurately resolved. After corrections, the contract
undergoes re-auditing to confirm that vulnerabilities have been eliminated and no new
issues have been introduced.
An example of a static analysis algorithm transforms a program’s instruction sequence
into a chain of blocks and a jump graph. The instructions are organized into blocks, and
“JUMPI” instructions are processed to establish jump relationships, resulting in a jump
graph that visually represents the control flow between blocks. This ensures that the
structure of the contract is clear and can be verified for correctness.
Algorithm 1 constructs a program’s control flow graph by dividing the instruction
sequence into basic blocks and establishing relationships between these blocks using
jump instructions. Through this process, the static analysis tool organizes the program’s
execution logic into distinct blocks and defines the jump paths, resulting in a clear control
flow structure. This approach accurately represents the program’s execution path, helping
developers understand the sequence of instructions and their branching behavior.

Algorithm 1 Building jump graphs

Input: Program P
Output: Blocks B and edges E
1: B ← [] // List of blocks
2: currentBlock ← null // Current block
3: E ←∅ // Edges between blocks
4: for each instruction S in P do
5: if S is the first instruction then
6: newBlock ← CreateNewBlock()
7: B.append(newBlock)
8: currentBlock ← newBlock
9: InsertIntoBlock(currentBlock,S)
10: end if
11: if S is “JUMPI” then
12: InsertIntoBlock(currentBlock,S)
13: EndBlock(currentBlock)
14: E[currentBlock] ←∅
15: targetBlock←
DetermineTargetBlock(S)
16:
E[currentBlock].append(targetBlock)
17: newBlock ← CreateNewBlock()
18: B.append(newBlock)
19: currentBlock ← newBlock
20: end if
21: InsertIntoBlock(currentBlock,S)
22: end for
23: for each block in B do
24: if block ∈ E then
25: for each target in E[block] do
26: AddEdge(block,target)
27: end for
28: end if
29: end for

In the review process, Algorithm 1 is employed to detect control flow issues by

analyzing the jump relationships between blocks. It effectively identifies unreachable code,
Electronics 2024, 13, 4093 8 of 22

validates the safety of conditional jumps, and flags potential loops or recursive behavior,
which contributes to robust control flow validation.
Proper parameter configuration is crucial for automating the detection and correction
of issues in smart contract source code, enhancing both security and reliability. The Solidity
code is scanned by a syntax analyzer to ensure compliance with language specifications,
with parameters tailored to the specific Solidity version for compatibility. Code style settings
are enforced for consistency and readability, while permitted and prohibited features are
defined to avoid common vulnerabilities. Security rules are configured to prevent risky
operations and unauthorized access, while compiler warnings and errors are adjusted to
detect issues such as unused variables or unsafe functions. Additionally, code structure
parameters ensure better organization, and optimization settings are configured to improve
execution efficiency and reduce gas consumption, ultimately making the smart contract
more secure and efficient.

3.3. Formal Verification Module

The tool configuration unit is responsible for selecting and configuring the appropriate
formal verification tools. The parameter configuration unit sets verification parameters
such as search depth, search width, and the security properties to be validated. The model
construction unit builds the formal model of the smart contract based on its source code and
the selected verification tool. Lastly, the verification analysis unit utilizes the configured
tools to analyze the formal model against the predefined security attributes and produces
the formal verification results.
Formal verification tools include the theorem prover Coq [35], which constructs math-
ematical proofs to verify system correctness, and the model checker Spin, which systemati-
cally explores all possible states to validate system properties. Additionally, an algorithm
library supports logical inference, state space exploration, and abstract interpretation to
derive logical formulas, traverse system states, and approximate program behavior.
Selecting the appropriate formalization tools and algorithm libraries is critical to the
success of the verification process. This selection depends on project needs, security and
reliability requirements, tool maturity, ease of integration, and cost-effectiveness. For
instance, Spin, along with the Promela language and linear temporal logic (LTL), is well-
suited for smart contract systems with finite states, allowing the detection of security
vulnerabilities through randomized state path generation.
During the verification process, the search depth controls how many state variables
the tool considers, with greater depth uncovering more issues but requiring increased
computational resources. Search width limits the number of state variables explored at
each step, affecting search breadth and parallelism. Together, these parameters determine
the scope and granularity of the verification.
The security attributes to be validated are clearly defined based on actual require-
ments and converted into formal specifications. As verification progresses, the auditor
may need to adjust the formal model or verification parameters to refine the process.
Once all security attributes are satisfied, the developer addresses the issues identified in
the formal verification results. After the smart contract is repaired and optimized, the
code is re-verified to ensure that previous vulnerabilities are resolved and no new issues
are introduced.
The formal verification process is considered complete only when the smart contract
successfully passes all verifications and fully meets the security attributes. This iterative
approach ensures that the smart contract is secure and reliable for real-world deployment.
Examples of Promela modeling code and properties to be verified are shown in Figure 3.
Electronics 2024, 13,
Electronics 2024, 13, 4093
x FOR PEER REVIEW 9 9ofof22
22

/*process for state machine behavior*/ /*Supplier model*/

/*Subfactory model*/ proctype Su_stm(){
proctype Fa_stm(){ int re_truck_id;
int re_truck_id; int payment;
int truck_id; int fare;
int payment; int nb_goods;
int nb_goods = 1000; do
do //simulate the actions of the supplier
//simulate the operation of production :: R_su();
:: R_fa(); od
od }
} /*Truck modle*/
/*Smart contract between supplier and proctype Tr_stm(){
subfactory */ int fare;
proctype SCa_stm(){ int id = 1;
int payment; do
do // simulate transport operations
//simulate the behavior of smart contract A :: R_tr();
:: R_sca(); od
od }
}
/*Smart contract between supplier and
truck */
proctype SCb_stm(){
int fare;
do
//simulate the behavior of smart contract B
:: R_scb();
od}
init {
(_nr_pr == 1) -> printf(“The trade is over!\n”);
assert(fa_Acc + su_Acc + t_Acc + sca_Acc + scb_Acc != invar0);
}
ltl p1 { [](fa_Acc + su_Acc + t_Acc + sca_Acc + scb_Acc == invar0) }
Figure
Figure 3.
3. Promela
Promela model
model of
of aa smart
smart contract.
contract.

The property
property verified
verified by
by p1
p1isisthe
theinvariance
invarianceofofthe
thetotal
totalaccount
accountbalance.
balance.Specifically,
Specifically,
the total balance
balance of
of each
each account
account in
inthe
thesmart
smartcontract
contractshould
shouldremain
remainconstant
constantthroughout
throughout
the entire
entire transaction process. InIn other
other words,
words, the
thecombined
combined balance
balanceof
ofall
allaccounts
accountsshould
should
not change
change during
duringany
anytransactions
transactionsororoperations.
operations.Below
Below areare explanations
explanations forfor
thethe func-
functions
tions involved
involved in verifying
in verifying this property:
this property:
•• Fa_stm(): Represents
Represents the
theproduction
productionprocess
process with
with re_truck_id,
re_truck_id, truck_id,
truck_id, payment,
payment, and
and nb_goods
nb_goods variables,
variables, wherewhere nb_goods
nb_goods is initialized
is initialized to 1000,
to 1000, andprocess
and this this process calls
calls R_fa()
in a loop
R_fa() in atoloop
simulate the operation
to simulate of production.
the operation of production.
• SCa_stm(): represents the smart contract A process with the payment variable, and
R_sca() is called in a loop to simulate the behavior of smart contract A.
Electronics 2024, 13, 4093 10 of 22

Electronics 2024, 13, x FOR PEER REVIEW 10 of 22

• SCa_stm(): represents the smart contract A process with the payment variable, and
R_sca() is called in a loop to simulate the behavior of smart contract A.
• • SCb_stm():
SCb_stm(): represents the the
represents smart contract
smart B process
contract with a fare
B process withvariable, calling R_scb()
a fare variable, calling
inR_scb()
a loop to simulate the behavior of smart contract B.
in a loop to simulate the behavior of smart contract B.
• • Su_stm():
Su_stm():represents
representsthe thesupplier
supplierprocess
processwithwithre_truck_id,
re_truck_id,payment,
payment,fare, fare,and
and
nb_goods variables, and R_su() is called in a loop to simulate the actions
nb_goods variables, and R_su() is called in a loop to simulate the actions of the supplier. of
• theTr_stm():
supplier.represents a transport process with fare and id variables, where id is ini-
• Tr_stm():
tialized represents a transport
to 1, and R_tr() process
is called withtofare
in a loop and idtransport
simulate variables,operations.
where id is initial-
ized to 1, and R_tr() is called in a loop to simulate transport operations.
To conduct model checking on a Promela model using the Spin tool 6.5.1, begin by
To conduct model checking on a Promela model using the Spin tool 6.5.1, begin by
generating the model checker and compiling the resulting c source files in the terminal or
generating the model checker and compiling the resulting c source files in the terminal
command line interface. Subsequently, execute the model checker to carry out the verifi-
or command line interface. Subsequently, execute the model checker to carry out the
cation process. Upon completion, Spin will produce detailed model-checking results and
verification process. Upon completion, Spin will produce detailed model-checking results
a verification report, which are essential for assessing whether the system adheres to the
and a verification report, which are essential for assessing whether the system adheres
specified properties and requirements across all possible execution scenarios. This proce-
to the specified properties and requirements across all possible execution scenarios. This
dure ensures a rigorous validation of the system’s behavior. The figure below shows the
procedure ensures a rigorous validation of the system’s behavior. The figure below shows
verification results of the Promela model using Spin.
the verification results of the Promela model using Spin.
Figure 4 illustrates the application of Spin, demonstrating a thorough and precise
Figure 4 illustrates the application of Spin, demonstrating a thorough and precise anal-
analysis with no errors found.. The tool comprehensively explored 2,269,701 state transi-
ysis with no errors found.. The tool comprehensively explored 2,269,701 state transitions
tions
and and identified
identified 1,510,0391,510,039
distinctdistinct states, storing
states, storing 759,662759,662
of theseofasthese as unique
unique states.
states. The The
state
state vector size was 272 bytes, and the search depth reached 9999 steps.
vector size was 272 bytes, and the search depth reached 9999 steps. Memory utilization Memory utiliza-
tion
was was efficiently
efficiently managed,
managed, with awith
total aconsumption
total consumption of 262.226
of 262.226 MB, including
MB, including 217.341217.341
MB
MB for state storage and 128 MB allocated for the hash table. The state
for state storage and 128 MB allocated for the hash table. The state storage compression storage compres-
sion efficiency
efficiency reachesreaches
61.60%, 61.60%, highlighting
highlighting the toolʹs
the tool's effective
effective management
management of state
of state stor-
storage.
age. and indicates a robust verification process with optimal
and indicates a robust verification process with optimal resource usage. resource usage.

Figure 4. Promela model verification result.

Figure 4. Promela model verification result.

3.4.
3.4. Analog
Analog Execution
Execution Module
Module
The
The main
main objective
objective of this
of this module
module is toisevaluate
to evaluate
the the performance
performance of smart
of smart contracts
contracts in
different operating
in different environments
operating environments through
through exhaustive simulations
exhaustive and and
simulations in-depth analysis
in-depth analy-
tosis
ensure their their
to ensure security and and
security robustness.
robustness.TheThe
module consists
module of five
consists core
of five units:
core a state
units: a state
machine
machine model
model building
buildingunit, state
unit, space
state space graph
graphconstruction
constructionunit,
unit,anomaly
anomaly detection
detectionunit,
unit,
simulation unit, and evaluation unit.
simulation unit, and evaluation unit.
The Figure 5 show the workflow of this module starts with constructing a state ma-
chine model derived from the source code of the smart contract, encompassing all possible
states and their transitions. The state machine model building unit is responsible for
Electronics 2024, 13, 4093 11 of 22

Electronics 2024, 13, x FOR PEER REVIEW 11 of 22

The Figure 5 show the workflow of this module starts with constructing a state machine
model derived from the source code of the smart contract, encompassing all possible states
and their transitions. The state machine model building unit is responsible for creating this
creating
model, this model, systematically
systematically detailing
detailing the various theofvarious
states states
the smart of the
contract smart
and contract and
the relationships
between them. This model not only offers a comprehensive view of the smartview
the relationships between them. This model not only offers a comprehensive of the
contract’s
smartbut
states contract’s states but
also facilitates also facilitates
a deeper a deeper
understanding of itsunderstanding
behavior underofdifferent
its behavior under
operations
different
and events. operations and events.

Constructing state machine model from the source code of a smart State Machine Model Building
contract Unit

State Space Graph Construction

Generate state space graph of smart contracts
Unit

Traverse the state space graph to detect and record potentially

Anomaly Detection Unit
risky execution paths during state transitions

Simulate the actual operation of the smart contract to be audited Simulation Unit
and test the smart contract response results

Generate simulation execution results Evaluation Unit

Figure5.5.Analog
Figure Analogexecution
executionmodule
moduleworkflow.
workflow.

Thestate
The statespace
spacegraph
graphconstruction
constructionunit unitisisbased
basedon onthe thestate
statemachine
machinemodel,
model,and and
fromwhich
from whichthethestate
statespace
spacegraph
graphisisdeveloped.
developed.The Thestate
statespace
spacegraph
graphcomprehensively
comprehensively
coversall
covers allthe
thestate
statechanges
changesthatthataasmart
smartcontract
contract may
may experience
experience during
during itsits life
life cycle,
cycle,
providing
providinga abasis
basisfor
forsubsequent
subsequent anomaly
anomaly detection and
detection simulation.
and simulation.Through
Through thisthis
graphical
graph-
representation,
ical representation,the state flowflow
the state andandpotential
potentialpaths of of
paths smart
smart contracts
contracts can
canbebeunderstood
understood
intuitively.
intuitively. The anomaly detection unit is responsible for traversing the state spacegraph,
The anomaly detection unit is responsible for traversing the state space graph,
detecting
detectingand andrecording
recording potential
potentialriskrisk
paths thatthat
paths maymayexistexist
during state state
during transitions. The task
transitions. The
oftask
theof
anomaly detection
the anomaly unit isunit
detection to identify potential
is to identify anomalies
potential and risky
anomalies andpaths
riskyinpaths
the smart
in the
contract that maythat
smart contract leadmayto unexpected behaviors behaviors
lead to unexpected or system vulnerabilities, thus providing
or system vulnerabilities, thus
critical information for further security analysis. The simulation unit
providing critical information for further security analysis. The simulation unit employs employs advanced
techniques to simulatetosmart
advanced techniques simulatecontract
smart operations in real-world
contract operations scenarios.
in real-world It generates
scenarios. It gen-
various transactions, including normal, boundary conditions and
erates various transactions, including normal, boundary conditions and intentionally intentionally malicious ma-
ones,
licioustoones,
test how thehow
to test smartthe contract handles
smart contract different
handles inputs.inputs.
different The unit
The also
unit simulates
also simu-
blockchain event event
lates blockchain triggers, such as
triggers, reaching
such specific
as reaching time thresholds
specific time thresholdsor account
or accountbalance
bal-
changes, to verify the correctness of the smart contract’s response logic.
ance changes, to verify the correctness of the smart contract’s response logic. Additionally, Additionally, it
it introduces abnormal conditions like transaction failures, network delays, and resource
constraints to assess the smart contract’s performance under such scenarios.
Electronics 2024, 13, 4093 12 of 22

introduces abnormal conditions like transaction failures, network delays, and resource
constraints to assess the smart contract’s performance under such scenarios.
The evaluation unit integrates results from the anomaly detection and simulation units
to provide a comprehensive assessment of the smart contract. It analyzes the contract’s
performance under normal and extreme conditions, focusing on stability and performance
metrics such as execution efficiency, resource consumption, and response time. The unit also
evaluates the contract’s security, identifying potential vulnerabilities and attack surfaces.
Simulated execution results detail the execution paths of potential risks, successful and
failed transactions, and reasons for any anomalies.
The simulation execution unit plays a key role in the vulnerability detection process
of smart contracts, spanning the entire workflow from source code analysis to perfor-
mance and security assessment. First, a state machine model is constructed based on the
smart contract’s source code, and a state space graph is generated, covering all possible
state changes throughout the contract’s life cycle, providing a foundation for subsequent
anomaly detection and simulation. The anomaly detection module traverses the state space
graph to identify potential risky execution paths, uncovering abnormal behaviors and
unsafe operation patterns that may lead to vulnerabilities, such as reentrancy attacks and
timestamp manipulation. Building on this, the simulation unit employs advanced simula-
tion techniques to emulate various scenarios in a real blockchain environment, including
normal transactions, malicious attacks, and boundary conditions, to assess the contract’s
performance under different inputs and extreme conditions. Finally, the evaluation unit
integrates the results from the simulation execution to comprehensively evaluate the smart
contract’s performance and security, ensuring stability and reliability before formal deploy-
ment. This process effectively reduces the security risks associated with the contract after it
goes live.
Through this detailed and comprehensive simulation execution process, the simulated
execution module provides developers with a powerful tool to help identify and fix po-
tential problems before the smart contract is formally deployed. This pre-assessment and
optimization can significantly improve the reliability and security of smart contracts, ensur-
ing that they can stably and reliably perform their intended functions in actual operation.

3.5. Reporting and Recommendations Module

The report and recommendations module is designed to synthesize the results from
static analysis, formal verification, and simulation execution to form a detailed safety audit
report and provide targeted recommendations for improvement. The main functions and
processing flow of the module consist of five parts: a data extraction and processing unit,
semantic analysis and comprehension unit, knowledge base integration and query unit,
customized proposal generation unit, and interactive proposal optimization unit.
Initially, the data extraction and processing unit handles the extraction and consolida-
tion of key data from these various sources. This process involves essential preprocessing
tasks such as data cleaning, terminology standardization, and text normalization. Once
processed, the data undergo disambiguation and lexical annotation to isolate critical infor-
mation, laying the groundwork for subsequent semantic analysis.
The semantic analysis and comprehension unit then leverages advanced natural lan-
guage processing technologies to convert the processed data into clear and understandable
natural language descriptions. It employs text classification and clustering algorithms to
categorize errors and warnings, resulting in a detailed security audit report. This report
not only lists the identified issues but also assesses and classifies them based on severity,
aiding developers in swiftly identifying and prioritizing key security risks.
In the knowledge base integration and query unit, a comprehensive knowledge base
is integrated and queried. This knowledge base includes security best practices for smart
contracts, historical remediation cases, and common vulnerability patterns. By matching
the reported issues with this information, the unit derives relevant remediation strategies
and recommendations, ensuring the relevance and effectiveness of the proposed solutions.
Electronics 2024, 13, 4093 13 of 22

Leveraging semantic analysis results and knowledge base insights, the customized rec-
ommendation generation module formulates tailored enhancement strategies. By utilizing
advanced rule engines, it constructs remediation plans to address real-world challenges.
For more complex scenarios, the module synthesizes multiple knowledge sources and
historical case data to deliver comprehensive solutions. These solutions may encompass
code refactoring, vulnerability mitigation, and performance optimization, all with the
objective of improving the security and operational efficiency of smart contracts.
Finally, the interactive suggestion optimization unit offers an interactive interface for
developers to review and provide feedback on the customized suggestions. This feedback
allows the unit to refine the detail and applicability of the recommendations, ensuring
their practical feasibility. This interactive feature enhances the relevance and realism
of the suggestions, optimizing the recommendation generation process and improving
user experience.
In essence, the module produces a clear security audit report and personalized recom-
mendations by thoroughly analyzing multiple data sources. This approach not only boosts
the efficiency and accuracy of smart contract audits but also provides a solid foundation
for the secure deployment and operation of smart contracts, ensuring their security and
stability in diverse operating environments.

4. Experiments
This paper adopts a systematic approach to smart contract vulnerability detection.
First, the types of vulnerabilities to be detected are identified, and the relevant smart
contracts deployed on the test network are screened. Next, targeted vulnerability detection
is performed on these contracts to analyze whether the selected vulnerability type exists.
Eventually, the detection results are presented in the form of a report listing the names of all
the contracts in which vulnerabilities are found. This method effectively reduces redundant
detection steps, improves detection efficiency, and optimizes the detection process by
making the vulnerability detection results more explicit.

4.1. Data Sources

In this experiment, we used a Python-based web crawler to gather data from Ether-
scan (https://etherscan.io (accessed on 16 October 2024)) for 148 smart contracts. The
crawler collected important details such as source code, ABI, binary code, and constructor
parameters. Etherscan, known for its comprehensive public access to Ethereum blockchain
data, is a key resource for viewing, verifying, and interacting with smart contracts, making
it ideal for our data retrieval needs.
The contract selection process adhered to two main criteria. Firstly, only contracts
with complete source codes were chosen to ensure the accuracy of static analysis and
vulnerability detection based on the source code. Secondly, contracts were selected based
on their interaction with external accounts or other smart contracts, ensuring that the
interaction addresses were valid and that the operational environment in the test network
accurately reflected real-world conditions.
To ensure comprehensive testing, the contracts were categorized by functionality,
covering a wide range of types such as ERC-20 tokens, DeFi protocols, decentralized
autonomous organizations (DAOs), and NFT contracts (https://github.com/olstussy/
Auditing (accessed on 16 October 2024)). This diverse selection provides broad coverage
and ensures that vulnerability detection and analysis are representative across various
application scenarios.

4.2. Experimental Procedure

The input module is tasked with receiving the source code of the smart contract for
auditing purposes. This code, written in Solidity, often includes functionalities such as
token transfers, permission management, and event logging.
Electronics 2024, 13, 4093 14 of 22

The static analysis module uses the ACL2 8.0 to examine the Solidity code’s syntax
and semantics. Configured for Solidity version 0.8.3 with all security checks enabled,
this analysis is essential for detecting vulnerabilities. It focuses on evaluating the ABI
and bytecode of the smart contract, establishing key mappings between the contract, its
ABI functions, and the functions those ABI functions invoke. This foundational anal-
ysis is crucial for identifying potential issues and supporting the overall vulnerability
detection process.
The execution of a smart contract involves transactions between distinct accounts
based on the contract’s rules, including calls to ABI functions. To ensure accurate exe-
cution, it is essential to simulate these transactions with external accounts. For specific
vulnerabilities, such as reentrancy, which involves complex interactions between contracts
and nested function calls, standard transaction analysis may be inadequate. Consequently,
proxy accounts are constructed according to defined attack scenarios to simulate and detect
such vulnerabilities effectively. These proxy accounts are designed to interact in ways that
can trigger reentrancy attacks, thereby identifying and highlighting contracts with such
vulnerabilities. The number of smart contracts tested for different types of vulnerabilities is
shown in Table 1.

Table 1. Vulnerability types against the number of smart contracts.

Vulnerability Type Number of Contracts with Vulnerabilities Detected

Reentrancy 14
Disorder 10
Timestamp dependency 8
Block number dependency 8
Stack overflow 28
Denial of service 15
Integer overflow 21
Race condition 44

After completing the static analysis, we started to detect the vulnerability of each
deployed smart contract for a specific type of vulnerability. First, a random number
generator is used to generate an integer in a certain interval as the number of times the
smart contract is detected, which needs to be selected in a moderate interval.
To achieve an optimal balance between detection efficiency and coverage, a function
from the corresponding function call set of the smart contract is randomly selected for fuzzy
input in each vulnerability detection process. Multiple random selections are involved in a
vulnerability detection process, and the reason for emphasizing randomness is to maximize
the coverage as well as the accuracy of vulnerability detection and to simulate the execution
of the smart contract under different function call sequences by means of randomization.
Table 2 shows the number of smart contracts containing vulnerabilities detected by the
static analysis module.

Table 2. Vulnerability detection results.

Number of Contracts Containing Percentage of

Vulnerability Type Correctness/%
the Vulnerability Incorrect Contracts/%
Reentrancy 4 28.6 100
Disorder 0 0 100
Timestamp dependency 1 12.5 100
Block number dependency 3 37.5 66.7
Stack overflow 2 7.1 100
Denial of service 0 0 100
Integer overflow 2 9.5 100
Race condition 9 20.4 66.7
Electronics 2024, 13, 4093 15 of 22

We tested 148 smart contracts and detected 18 smart contracts with vulnerabilities,
of which three block number dependency vulnerabilities were detected and the number
of actual smart contracts with block number dependency was two, with a 66.9% correct
rate. Nine conditional competition vulnerabilities were detected, and the actual number of
smart contracts with conditional competition vulnerabilities was six, with a 66.7% correct
rate. All other smart contracts with vulnerabilities were correctly identified.
Race condition vulnerabilities are usually caused by mutual interference between
multiple concurrent operations or transactions, especially when accessing shared resources;
at the same time, detecting such vulnerabilities becomes more challenging due to the
complexity of the block numbering dependency logic, which often leads to false positives
and decreased accuracy. This is further verified by the experimental data, which shows
that the detection of block number dependency vulnerabilities has a low correct rate, and
this complexity makes the detection of such vulnerabilities more difficult and uncertain.
To more intuitively demonstrate the performance of the method proposed in this paper
for detecting Ethereum smart contract vulnerabilities, as well as the current challenges it
faces, comparative experiments were conducted, selecting relevant work in the field of
smart contract vulnerability detection for evaluation. Specifically, the proposed method
was compared against five mainstream vulnerability detection tools: Oyente, ReGuard,
Manticore, Securify, and Slither. These tools were tested on the same dataset and for
the same types of vulnerabilities. As shown in Table 3, following the experiments, an
in-depth analysis and discussion of the differences in detection results between each tool
were conducted to comprehensively assess the effectiveness and performance of various
detection methods in practical applications.

Table 3. Vulnerability detection results of various tools.

Vulnerability Type Oyente ReGuard Manticore Securify Slither Our Work

√ √ √ √ √ √
Reentrancy √ √ √ √
Disorder ×
√ × √ √ √
Timestamp dependency × ×
Block number √ √ √ √
× ×
dependency √
Stack overflow × × ×
√ ×
√ ×
√ √
Denial of service ×
√ × √ √ √
Integer overflow × × √
Race condition × × × × ×

To streamline the experiments, we focused solely on testing for reentrant, disorder,

and stack overflow vulnerabilities using a range of detection tools. The data obtained from
these tests are summarized below.
Table 4 presents a thorough comparative analysis of various smart contract analysis
tools, detailing their respective strengths and limitations in the context of vulnerability
detection. Oyente, one of the pioneering tools in this domain, is noted for its relatively
high error rate, particularly in the identification of reentrancy vulnerabilities, with a false-
positive rate of 3/7. Oyente utilizes symbolic execution to traverse multiple execution
paths; however, its fundamental analytical approach often results in a considerable number
of false positives, reflecting the constraints of its basic methodology. Reguard demonstrates
notable accuracy in detecting reentrancy vulnerabilities, excelling in this specialized area.
However, its primary drawback is its narrow focus; it exclusively targets reentrancy issues
and does not address other potential vulnerabilities, thereby limiting its overall applicability.
Manticore can explore complex paths in-depth for reentrancy attack detection but may
miss some cases due to path explosion. While it can analyze issues like order confusion and
stack overflow, its effectiveness may be limited in more complex contracts. Securify quickly
identifies common reentrancy patterns and sequential issues, providing clear reports, but
its detection is weaker when handling dynamic calls and more complex vulnerabilities.
Its stack overflow detection is constrained by the rules engine, making it difficult to catch
Electronics 2024, 13, 4093 16 of 22

lower-level errors. Slither, meanwhile, efficiently identifies obvious reentrancy risks and
sequential problems but falls short in detecting issues in complex multi-contract interactions
and deep calls. Its ability to identify stack overflow vulnerabilities is also relatively limited.

Table 4. Comparison of tools experimental results.

Oyente Reguard Manticore Securify Slither Our Work

Vulnerability Number Number Number Number Number Number Number Number Number Number Number Number
Type of Vulne- of False of Vulne- of False of Vulne- of False of Vulne- of False of Vulne- of False of Vulne- of False
Rabilities Positive Rabilities Positive Rabilities Positive Rabilities Positive Rabilities Positive Rabilities Positive
Reentrancy 7 3 4 0 4 0 5 1 4 0 4 0
Disorder 1 1 — — 3 2 0 0 1 1 0 0
Stack 5 4 — — 3 1 — — — — 2 0
overflow

In comparison, the tool proposed in this paper demonstrates significantly higher

accuracy in identifying mature vulnerabilities. It preprocesses the smart contract code at
the input module stage, enabling timely detection of potential errors early in the reception
process. During the static analysis phase, ACL2 is employed for an in-depth examination of
Solidity’s syntax and semantics, ensuring that issues are effectively addressed before they
escalate into major failures or risks. Following a comprehensive evaluation of the formal
verification and simulation execution modules, the tool utilizes Spin to validate the Promela
code generated from the smart contract source code. This step offers valuable insights
into potential issues within the contract. Subsequently, the behavior of the smart contract
under real-world operating conditions is simulated using an Ethereum simulator to further
assess and validate its performance. This dual assessment method, which combines formal
verification and simulation, not only enables comprehensive identification of vulnerabilities
but also verifies the stability of the contract’s operation across various scenarios. As a result,
it significantly enhances the overall effectiveness of vulnerability detection, providing a
more reliable assurance for the security of smart contracts.
The use of the tool demonstrates excellent performance in detecting reentrancy attacks,
order confusion, and stack overflow, primarily due to the combination of in-depth analysis
and comprehensive static analysis. By employing formal verification and simulation execu-
tion, it is possible to thoroughly examine contract logic, identify potential errors in a timely
manner, and reduce the complexity of the analysis. Additionally, ACL2 can accurately
detect syntax and semantic errors in Solidity, effectively preventing order confusion and
stack overflow. The Ethereum simulator’s evaluation provides insights into the contract’s
performance under real-world conditions, significantly enhancing the detection capability
for these vulnerabilities.
Figures 6 and 7 show some of the issues and suggestions generated by this tool after
analyzing a subset of smart contracts in the current experiment.
In the security audit report, the detected issues are thoroughly described along with
optimization recommendations. For instance, to address the conditional contention vul-
nerability, it is advised to implement a locking mechanism to prevent concurrent access to
shared resources. This can be achieved by incorporating require statements to verify the
contract’s state before executing critical operations. Additionally, to mitigate issues related
to block numbering dependencies, it is recommended to avoid using block numbers in crit-
ical logic. Instead, utilizing timestamps or other on-chain metrics that are less susceptible
to manipulation is suggested. These measures aim to enhance the security and stability of
smart contracts, reduce the risk of potential attacks, and ensure the contract’s reliability
across various environments. Following the suggestions provided in the report, the recom-
mended changes were implemented, and the contract was subsequently re-audited. The
contract address and link used in the experiment are shown below, and Table 5 illustrates
the results of this re-audit after the modifications were applied.
Electronics 2024, 13, x FOR PEER REVIEW 17 of 22
Electronics 2024, 13, x FOR PEER REVIEW 17 of 22
Electronics 2024, 13, 4093 17 of 22

Figure 6. An issue after detection.

Figure 6. An issue after detection.
Figure 6. An issue after detection.

Figure 7. Suggestion
Suggestion for
for the issue.
Figure 7. Suggestion for the issue.
Contract
In Address:
the security audit report, the detected issues are thoroughly described along with
0x27054b13b1b798b345b591a4d22e6562d47ea75a
optimization
In recommendations.
the security audit report, For instance,issues
the detected to address the conditional
are thoroughly contention
described vul-
along with
Link Address:
nerability,
optimization it isrecommendations.
advised to implement a lockingtomechanism
For instance, address thetoconditional
prevent concurrent
contention access
vul-
to https://etherscan.io/address/0x27054b13b1b798b345b591a4d22e6562d47ea75a
shared resources. This can be achieved by incorporating require
nerability, it is advised to implement a locking mechanism to prevent concurrent access statements to (ac-
verify
cessed
theshared
to on 16
contract’s October
resources. 2024)
state before executing
This can critical
be achieved byoperations.
incorporating Additionally, to mitigate
require statements to issues
verify
related This
to tool
the contract’sblock uses formal
numbering
state verification,
dependencies,
before executing static
it is
critical analysis,
recommended
operations. and manual
to avoid
Additionally, review
using
to toblock
conduct
mitigate num-a
issues
multi-dimensional
bers
related in critical
to blocklogic. comprehensive security
Instead,dependencies,
numbering utilizing timestamps audit of the code specifications,
or other on-chain
it is recommended to avoidmetrics security,
using that and
arenum-
block less
business
susceptible logic
bers in critical of the smart
to manipulation contract
logic. Instead,isutilizing in
suggested. three aspects. Table
These measures
timestamps or other5 shows
aim the deployment
to enhance
on-chain address
the security
metrics that are and
less
and relevant
stability of links
smart for the smart
contracts, contract,
reduce the as
risk well
of as the
potential results of
attacks, an
susceptible to manipulation is suggested. These measures aim to enhance the security andandaudit conducted
ensure the during
contract’s
the experiment.
reliability
stability smartBased
ofacross various onenvironments.
contracts, the recommendations
reduce Following
the risk in the
the suggestions
of potential audit report,
attacks, and the source
provided
ensure in code
the the of the
report,
contract’s
smart
the contract
recommended
reliability was
across various modified
changes and resubmitted
were implemented,
environments. Following for further
andthethe audit.
contract was
suggestions The new security
subsequently
provided audit
re-au-
in the report,
report
dited. indicates that
The contractchanges
the recommended all identified
address were
and linksecurity issues
used in theand
implemented, have been
experiment effectively
the contractare shown resolved.
below, andre-au-
was subsequently Table
5dited.
illustrates the results
The contract of this
address re-audit
and link usedafterinthe
themodifications
experiment are were applied.
shown below, and Table
Contract
5 illustrates theAddress:
results of this re-audit after the modifications were applied.
0x27054b13b1b798b345b591a4d22e6562d47ea75a
Contract Address:
0x27054b13b1b798b345b591a4d22e6562d47ea75a
Electronics 2024, 13, 4093 18 of 22

Table 5. The audit results of this smart contract experiment.

Number Audit Category Audit Subcategories Audit Results

√
1 Reentrancy —
√
2 Disorder —
√
3 Denial of Service —
√
4 Integer Overflow —
√
5 Race Condition —
Compiler Version Security
Hardcoded Address Security
Fallback Functions Security √
6 Security Design
Revealing Encoding Security
Function Return Value Security
Call Invocation Security
Privilege Vulnerability Audit √
7 Privilege Control
Excessive Privilege Audit
√
8 Timestamp Dependency —
Block Number √
9 —
Dependency
√
10 Stack Overflow —

5. Discussion and Limitations

The use of blockchain technology offers numerous advantages but also presents
significant development challenges, particularly in the area of smart contract security
auditing. Formal verification-based auditing approaches are effective in identifying security
vulnerabilities and logic flaws, but they come with limitations. First, detection accuracy
requires improvement due to false positives and omissions, pointing to the need for
optimizing algorithms and test cases. Additionally, code coverage is insufficient, especially
when dealing with complex contract logic and edge cases, highlighting the necessity to
enhance both the comprehensiveness of coverage assessments and detection algorithms.
Moreover, the current approach targets only eight common vulnerabilities, limiting its
ability to address the increasing variety of vulnerabilities in the rapidly evolving blockchain
landscape. Expanding the detection scope is therefore essential. The method’s current focus
on the Ethereum platform further underscores the need for cross-platform detection to
accommodate smart contracts across different blockchain ecosystems. Although automated
detection improves efficiency, manual review is still necessary to confirm vulnerabilities,
which constrains both accuracy and speed. Additionally, the formal verification and
simulation modules impose performance challenges, particularly with large-scale contracts,
emphasizing the need for optimizations to enhance overall audit efficiency.
Furthermore, the detection rules and model updates may not adapt quickly to newly
emerging attack vectors, resulting in inadequate identification of new vulnerabilities.
Certain complex attack patterns, especially those involving cross-contract interactions or
dynamic state changes, may exceed current analytical capabilities, making comprehensive
risk capture difficult for static analysis. Additionally, static analysis faces limitations in
identifying vulnerabilities that depend on specific inputs, as it relies primarily on static
features of contract source code, failing to reflect dynamic changes during execution. This
may lead to overlooked vulnerabilities, reducing overall detection effectiveness.
In summary, the approach requires further refinement in terms of accuracy, coverage,
detection scope, and cross-platform compatibility, along with performance optimizations,
to effectively address the growing complexities of smart contract security.
Electronics 2024, 13, 4093 19 of 22

6. Conclusions and Future Work

This paper presents a formal verification-based security auditing approach for smart
contracts, integrating modules for input, static analysis, formal verification, simulation
execution, and report generation. This approach detects security vulnerabilities, logic flaws,
and other potential problems before deployment, thereby improving security and reducing
the risk of code defects. It also greatly improves review efficiency, reducing development
time by up to 70% compared to traditional manual reviews. Finally, certain optimization
recommendations are made, enabling developers to refine their code and build greater
user trust.
During the audit, 17 security issues were identified and resolved, and the updated
contract successfully passed all checks without any false positives or omissions. However,
there is still room for improvement in detection accuracy, code coverage, and the range of
vulnerabilities detected. Improving accuracy requires more comprehensive test cases and
data to minimize false positives. Improving code coverage can be achieved by improving
randomization techniques to ensure more exhaustive testing. Finally, expanding the types
of vulnerabilities that can be detected will further enhance the effectiveness of the audit
process. Currently, the approach focuses on Ethernet-based contracts, but future work aims
to extend this approach to cross-platform smart contract auditing.

Author Contributions: Conceptualization, M.X. and Y.X.; methodology, Y.X.; validation, Y.X.,
Z.L. and H.W.; formal analysis, Y.X.; investigation, Y.X.; writing—original draft preparation, Y.X.;
writing—review and editing, M.X. and Z.L. All authors have read and agreed to the published
version of the manuscript.
Funding: This research was funded by the National Natural Science Foundation of China (grant num-
ber 62362033, 61962020), the Double Thousand Talent Plan of Jiangxi Province (No. jxsq2023201009),
and the Natural Science Foundation of Jiangxi Province (No. 20224ACB202006).
Data Availability Statement: The authors confirm that the data supporting the findings of this study
are available within the article.
Conflicts of Interest: The authors declare no conflicts of interest.

Appendix A
This appendix provides a comprehensive overview of eight prevalent types of smart
contract vulnerabilities, which are critical for understanding and mitigating potential risks
in blockchain applications.
1. Reentrancy
Reentrancy vulnerabilities arise when a smart contract makes an external call to
another contract before fully completing its internal state updates. This can create a scenario
where the external contract can repeatedly call back into the original contract before its state
is finalized, potentially leading to unintended consequences. This type of vulnerability
was notably exploited in the DAO hack, where attackers exploited the reentrancy flaw to
drain funds from the contract. Proper safeguards, such as using checks–effects–interactions
patterns and reentrancy guards, can help mitigate this risk.
2. Disorder
Disorder vulnerabilities involve problems related to the sequence of operations or the
order in which transactions are processed. These vulnerabilities occur when a contract’s
functionality depends on a specific order of operations, but an attacker can invoke functions
out of the expected order. Such issues can lead to unexpected behaviors or security
breaches, such as unauthorized access or improper state changes. Ensuring that functions
are invoked in a controlled manner and implementing comprehensive validation checks
can help address disorder vulnerabilities.
3. Timestamp Dependency
Electronics 2024, 13, 4093 20 of 22

Timestamp dependency vulnerabilities occur when a contract relies on block times-

tamps for critical operations. Since miners have some influence over block timestamps,
contracts that depend on these values can be vulnerable to manipulation. For example, con-
tracts that use timestamps for time-based logic or deadlines can be exploited if an attacker
adjusts the block timestamp to their advantage. To mitigate this risk, contracts should
avoid using block timestamps for crucial decisions and consider alternative approaches,
such as using block numbers or other on-chain metrics.
4. Block Number Dependency
Block number dependency vulnerabilities arise when contracts use the current block
number as a factor in their logic. Similar to timestamp dependency, block numbers can
be influenced by miners to a limited extent. Contracts that rely on block numbers for
key functionality, such as randomness or timing, may be susceptible to exploitation if an
attacker manipulates the block number. To reduce this risk, it is advisable to use more
secure sources of randomness and avoid critical logic that depends solely on block numbers.
5. Stack Overflow
Stack overflow vulnerabilities occur when a contract’s execution exceeds the maxi-
mum stack depth allowed by the Ethereum Virtual Machine (EVM). This can happen if a
contract performs too many nested function calls or recursive operations, leading to a stack
overflow error. Such vulnerabilities can cause the contract to fail or behave unpredictably,
potentially resulting in service interruptions or other issues. Implementing safeguards
against excessive recursion and optimizing function call structures can help prevent stack
overflow vulnerabilities.
6. Denial of Service (DoS)
Denial of service (DoS) vulnerabilities occur when a contract becomes unable to
process further transactions or operations due to specific conditions being met. These
conditions might include excessive gas consumption, computational complexity, or re-
source exhaustion. A successful DoS attack can render the contract unusable, affecting its
functionality and accessibility. To mitigate DoS risks, it is essential to optimize gas usage,
manage computational complexity, and implement robust error handling and resource
management strategies.
7. Integer Overflow
Integer overflow vulnerabilities occur when arithmetic operations exceed the maxi-
mum value that can be stored in a variable, causing it to wrap around to zero or a negative
number. This can lead to incorrect calculations or unexpected behavior, such as manipulat-
ing contract balances or triggering erroneous logic. Proper validation and the use of safe
math libraries can help prevent integer overflows and ensure that arithmetic operations
remain within expected bounds.
8. Race Condition
Race condition vulnerabilities arise when the outcome of a contract’s execution de-
pends on the timing of transactions or external events. If multiple transactions can interact
with a contract simultaneously, an attacker may exploit this by manipulating the timing
of their transactions to achieve unintended results. Race conditions can lead to issues
such as double-spending or inconsistent state changes. Implementing proper synchroniza-
tion mechanisms and ensuring atomicity in transaction processing can help mitigate race
condition risks.
This appendix provides a detailed examination of these vulnerabilities, emphasiz-
ing the importance of designing and auditing smart contracts to address these common
issues effectively.
Electronics 2024, 13, 4093 21 of 22

References
1. Yaga, D.; Mell, P.; Roby, N.; Scarfone, K. Blockchain technology overview. arXiv 2019, arXiv:1906.11078.
2. Ethereum: A Secure Decentralised Generalised Transaction Ledger. 2019. Available online: https://ethereum.github.io/
yellowpaper/paper.pdf (accessed on 19 September 2024).
3. Antonopoulos, A.M.; Wood, G. Mastering Ethereum: Building Smart Contracts and DApps; O’Reilly Media: Sebastopol, CA,
USA, 2018.
4. Szabo, N. The idea of smart contracts. Nick Szabo’s Pap. Concise Tutor. 1997, 6, 199.
5. He, H.; Yan, A.; Chen, Z. Survey of Smart Contract Technology and Application Based on Blockchain. J. Comput. Res. Dev. 2018,
55, 2452–2466. (In Chinese)
6. Atzei, N.; Bartoletti, M.; Cimoli, T. A survey of attacks on ethereum smart contracts (SoK). In Proceedings of the International
Conference on Principles of Security and Trust, Uppsala, Sweden, 24–25 April 2017; Springer: Berlin/Heidelberg, Germany, 2017;
pp. 164–186.
7. Kushwaha, S.S.; Joshi, S.; Singh, D.; Kaur, M.; Lee, H.N. Systematic review of security vulnerabilities in ethereum blockchain
smart contract. IEEE Access 2022, 10, 6605–6621. [CrossRef]
8. Liu, J.; Liu, Z. A survey on security verification of blockchain smart contracts. IEEE Access 2019, 7, 77894–77904. [CrossRef]
9. Luu, L.; Chu, D.H.; Olickel, H.; Saxena, P.; Hobor, A. Making smart contracts smarter. In Proceedings of the 2016 ACM SIG-SAC
Conference on Computer and Communications Security, Vienna, Austria, 24–28 October 2016; pp. 254–269.
10. Mossberg, M.; Manzano, F.; Hennenfent, E.; Groce, A.; Grieco, G.; Feist, J.; Brunson, T.; Dinaburg, A. Manticore: A User-Friendly
Symbolic Execution Framework for Binaries and Smart Contracts. In Proceedings of the 2019 34th IEEE/ACM International
Conference on Automated Software Engineering (ASE), San Diego, CA, USA, 11–15 November 2019; pp. 1186–1189. [CrossRef]
11. Krupp, J.; Rossow, C. teEther: Gnawing at Ethereum to Automatically Exploit Smart Contracts. In Proceedings of the 27th
USENIX Security Symposium, Baltimore, MD, USA, 15–17 August 2018.
12. Torres, C.F.; Schütte, J.; State, R. Osiris: Hunting for integer bugs in ethereum smart contracts. In Proceedings of the 34th Annual
Computer Security Applications Conference, San Juan, PR, USA, 3–7 December 2018; pp. 664–676.
13. Miller, A.K.; Xia, Y.; Croman, K.; Shi, E.; Song, D.X. The Honey Badger of BFT Protocols. In Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security, Vienna, Austria, 24–28 October 2016.
14. Chen, T.; Zhang, Y.; Li, Z.; Luo, X.; Wang, T.; Cao, R.; Xiao, X.; Zhang, X. TokenScope: Automatically Detecting Inconsistent
Behaviors of Cryptocurrency Tokens in Ethereum. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and
Communications Security, London, UK, 11–15 November 2019.
15. Tsankov, P.; Dan, A.M.; Drachsler-Cohen, D.; Gervais, A.; Buenzli, F.; Vechev, M.T. Securify: Practical Security Analysis of Smart
Contracts. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Toronto, ON,
Canada, 15–19 October 2018.
16. Feist, J.; Grieco, G.; Groce, A. Slither: A Static Analysis Framework for Smart Contracts. In Proceedings of the 2019 IEEE/ACM
2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), Montreal, QC, Canada, 27
May 2019; pp. 8–15. [CrossRef]
17. Tikhomirov, S.; Voskresenskaya, E.; Ivanitskiy, I.; Takhaviev, R.; Marchenko, E.; Alexandrov, Y. SmartCheck: Static Analysis of
Ethereum Smart Contracts. In Proceedings of the 2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software
Engineering for Blockchain (WETSEB), Gothenburg, Sweden, 27 May 2018; pp. 9–16.
18. Schneidewind, C.; Grishchenko, I.; Scherer, M.; Maffei, M. eThor: Practical and Provably Sound Static Analysis of Ethereum
Smart Contracts. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (CCS’20),
Virtual Event, 9–13 November 2020; Association for Computing Machinery: New York, NY, USA, 2020; pp. 621–640. [CrossRef]
19. Krötzsch, M.; Rudolph, S.; Hitzler, P. Complexities of Horn Description Logics. ACM Trans. Comput. Logic 2013, 14, 2. [CrossRef]
20. Grech, N.; Kong, M.; Jurisevic, A.; Brent, L.; Scholz, B.; Smaragdakis, Y. MadMax: Surviving out-of-gas conditions in Ethereum
smart contracts. Proc. ACM Program. Lang. 2018, 2, 116. [CrossRef]
21. Bhargavan, K.; Delignat-Lavaud, A.; Fournet, C.; Gollamudi, A.; Gonthier, G.; Kobeissi, N.; Kulatova, N.; Rastogi, A.; Sibut-
Pinote, T.; Swamy, N.; et al. Formal verification of smart contracts: Short paper. In Proceedings of the 2016 ACM Workshop on
Programming Languages and Analysis for Security, Vienna, Austria, 24 October 2016; pp. 91–96.
22. Kalra, S.; Goel, S.; Dhawan, M.; Sharma, S. Zeus: Analyzing safety of smart contracts. In Proceedings of the 25th Annual Network
and Distributed System Security Symposium (NDSS), San Diego, CA, USA, 18–21 February 2018; pp. 1–12.
23. Baier, C.; Katoen, J. Principles of Model Checking; MIT Press: Cambridge, MA, USA, 2008.
24. Cimatti, A.; Clarke, E.; Giunchiglia, E.; Giunchiglia, F.; Pistore, M.; Roveri, M.; Sebastiani, R.; Tacchella, A. Nusmv 2: An
opensource tool for symbolic model checking. In Proceedings of the International Conference on Computer Aided Verification,
Copenhagen, Denmark, 27–31 July 2002; Springer: Berlin/Heidelberg, Germany, 2002; pp. 359–364.
25. Holzmann, G.J. The model checker SPIN. IEEE Trans. Softw. Eng. 1997, 23, 279–295. [CrossRef]
26. Xiao, M.; Zhao, H.; Yang, K.; Ouyang, R.; Song, W. A formal analysis method for composition protocol based on model checking.
Sci. Rep. 2022, 12, 8493. [CrossRef] [PubMed] [PubMed Central]
27. Bai, X.; Cheng, Z.; Duan, Z.; Hu, K. Formal Modeling and Verification of Smart Contracts. In Proceedings of the 2018 7th
International Conference on Software and Computer Applications, Kuantan, Malaysia, 8–10 February 2018.
Electronics 2024, 13, 4093 22 of 22

28. Amani, S.; Bégel, M.; Bortin, M.; Staples, M. Towards verifying ethereum smart contract bytecode in Isabelle/HOL. In Proceedings
of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs, Los Angeles, CA, USA, 8–9 January 2018;
pp. 66–77.
29. Grishchenko, I.; Maffei, M.; Schneidewind, C. Ethertrust: Sound Static Analysis of Ethereum Bytecode; Technische Universität Wien:
Vienna, Austria, 2018; pp. 1–41.
30. Nehai, Z.; Piriou, P.Y.; Daumas, F. Model-checking of smart contracts. In Proceedings of the 2018 IEEE International Conference
on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and
Social Computing (CPSCom) and IEEE Smart Data (SmartData), Halifax, NS, Canada, 30 July–3 August 2018; pp. 980–987.
31. Browne, M.C.; Clarke, E.M.; Grümberg, O. Characterizing finite Kripke structures in propositional temporal logic. Theor. Comput.
Sci. 1988, 59, 115–131. [CrossRef]
32. Osterland, T.; Rose, T. Model checking smart contracts for ethereum. Pervasive Mob. Comput. 2020, 63, 101129. [CrossRef]
33. Mikk, E.; Lakhnech, Y.; Siegel, M.; Holzmann, G.J. Implementing statecharts in PROMELA/SPIN. In Proceedings of the 2nd IEEE
Workshop on Industrial Strength Formal Specification Techniques, Boca Raton, FL, USA; 1998; pp. 90–101. [CrossRef]
34. Kaufmann, M.; Moore, J.S. ACL2: An industrial strength version of Nqthm. In Proceedings of the 11th Annual Conference on
Computer Assurance—COMPASS ’96, Gaithersburg, MD, USA, 17–21 June 1996; pp. 23–34. [CrossRef]
35. Paulin-Mohring, C. Inductive definitions in the system Coq rules and properties. In Typed Lambda Calculi and Applications—TLCA
1993; Bezem, M., Groote, J.F., Eds.; Lecture Notes in Computer Science; Springer: Berlin/Heidelberg, Germany, 1993; Volume 664.
[CrossRef]

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.